From: Wang Jian <larkwang@gmail.com>
To: "Jason A. Donenfeld" <Jason@zx2c4.com>
Cc: WireGuard mailing list <wireguard@lists.zx2c4.com>
Subject: Re: Multihomed server issue
Date: Fri, 4 Aug 2017 02:38:13 +0800 [thread overview]
Message-ID: <CAF75rJDj79FU7GMa1DKxPNZ9V2dSW0+rFUDQjmEJ_z3ZDeuuGA@mail.gmail.com> (raw)
In-Reply-To: <CAHmME9rJ7BiinhPRhOqzAjZJEdc=wKzdk80Dvi=xQnP2fu_eqw@mail.gmail.com>
2017-08-03 20:59 GMT+08:00 Jason A. Donenfeld <Jason@zx2c4.com>:
> Hi Wang,
>
> I understand your inquiry and I see what you're trying to accomplish
> with your use of ip rule and fwmark. However, *WireGuard already does
> this automatically*. We _do_ support reply-to-sender. We _do_
> supported multihomed servers. You wrote, "But I do wish that server
> can deduce public address which the client connects to, and use the
> public address to response to the client, then the configuration will
> be simple and straightforward." WireGuard _does_ do this.
>
> To demonstrate that, I've added a more explicit test of this to the test suite:
> https://git.zx2c4.com/WireGuard/commit/?id=bf44c07a805a5e40408059ac60dfc526196a3797
>
> If this is not working for you, then you're either doing something
> wrong, or you've uncovered a bug in either WireGuard or the kernel. In
> case it's the latter, would you send me a patch for netns.sh that
> demonstrated the problem in a clear way?
Your test case is straightforward. And I am confident that you're right in this
kind of setup.
But there's significant difference. In your test case, the endpoint
addresses are configured
directly on attached link. In my case, the wireguard server's endpoint
address is configured on
dummy interface, not attached link.
I reproduce the problem while using tcpdump to get some clues,
1. server can receives client's packet
2. server 'wg' output shows client's endpoint addr:port correctly
3. tcpdump on client only captures outgoing request packets, no
response from server
4. tcpdump on server only captures incoming request packets, no
response (on all physical interfaces)
I was wrong. Response is not routed via default gateway, or other
interfaces. There is NO response at all.
Very sorry for misleading.
I am not familiar with test in namespace. I will look into it.
Hopefully I can come back
with a patch.
next prev parent reply other threads:[~2017-08-03 18:17 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-07-28 0:51 Wang Jian
2017-07-31 15:34 ` Jason A. Donenfeld
2017-08-01 2:01 ` Wang Jian
2017-08-01 3:06 ` Jason A. Donenfeld
2017-08-01 11:28 ` Wang Jian
2017-08-03 3:00 ` Wang Jian
2017-08-03 12:59 ` Jason A. Donenfeld
2017-08-03 18:38 ` Wang Jian [this message]
2017-08-10 14:29 ` Jason A. Donenfeld
2017-08-10 18:43 ` Jason A. Donenfeld
2017-08-10 21:17 ` Jan De Landtsheer
2017-08-10 22:16 ` Baptiste Jonglez
2017-08-10 23:50 ` Jason A. Donenfeld
2017-08-12 1:55 ` Jason A. Donenfeld
2017-08-12 16:08 ` Wang Jian
2017-09-07 21:28 ` Jason A. Donenfeld
2017-09-09 8:26 ` Wang Jian
2017-09-20 13:15 ` Jason A. Donenfeld
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAF75rJDj79FU7GMa1DKxPNZ9V2dSW0+rFUDQjmEJ_z3ZDeuuGA@mail.gmail.com \
--to=larkwang@gmail.com \
--cc=Jason@zx2c4.com \
--cc=wireguard@lists.zx2c4.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).