2017-08-03 20:59 GMT+08:00 Jason A. Donenfeld <ja...@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. _______________________________________________ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard
