Re: Multihomed server issue

2017-09-20 Thread Jason A. Donenfeld
Hey again, It turns out that our new semantics -- of rejecting only if the src IP doesn't belong to _any_ interface, as opposed to the specific interface -- nicely map to Linux's PKTINFO interface for userspace. In working with Mathias on the Go implementation, I produced the following code

Re: Multihomed server issue

2017-09-09 Thread Wang Jian
2017-09-08 5:28 GMT+08:00 Jason A. Donenfeld : > Hey there, > > This all should be fixed and working well in the latest snapshot. Can > you test this and confirm that it behaves the way you were hoping? > Hi Jason, It works as expected now. Thanks a lot. -- Wang Jian

Re: Multihomed server issue

2017-09-07 Thread Jason A. Donenfeld
Hey there, This all should be fixed and working well in the latest snapshot. Can you test this and confirm that it behaves the way you were hoping? Thanks, Jason ___ WireGuard mailing list WireGuard@lists.zx2c4.com

Re: Multihomed server issue

2017-08-12 Thread Wang Jian
2017-08-10 22:29 GMT+08:00 Jason A. Donenfeld : > Hi Wang, > > Did you have any luck reproducing this with the netns.sh script? I managed to test with dummy interface but things are not as expected. I think it's because my test case patch is not equvalent to my real setup. I was

Re: Multihomed server issue

2017-08-11 Thread Jason A. Donenfeld
Work in progress of last email from airplane: https://git.zx2c4.com/WireGuard/commit/?id=afca9ef9ce88e8ef026e9c9deca98600c19c502e If you'd like to test or play with the code. (Will refine further when I'm home.) ___ WireGuard mailing list

Re: Multihomed server issue

2017-08-10 Thread Jason A. Donenfeld
Hey Baptiste, On Fri, Aug 11, 2017 at 12:16 AM, Baptiste Jonglez wrote: > This is essentially a difference of weak vs. strong host model, see > https://tools.ietf.org/html/rfc1122#page-61 > > The RFC is quite clear: Wow, thank you so much for knowing about this /

Re: Multihomed server issue

2017-08-10 Thread Baptiste Jonglez
Hi Jason, On Thu, Aug 10, 2017 at 04:29:54PM +0200, Jason A. Donenfeld wrote: > 1. Packet from peer P arrives from src:A dst:B > 2. WireGuard records that it should contact P at src:B dst:A > 3. When sending an encrypted packet to P, it asks for which interface > to use for src:B dst:A. The

Re: Multihomed server issue

2017-08-10 Thread Jan De Landtsheer
indeed, this looks the same On Thu, Aug 10, 2017 at 8:43 PM Jason A. Donenfeld wrote: > On Thu, Aug 10, 2017 at 4:29 PM, Jason A. Donenfeld > wrote: > > It seems like the problem you're facing is that B does not belong to > > I, because B belongs to an

Re: Multihomed server issue

2017-08-10 Thread Jason A. Donenfeld
On Thu, Aug 10, 2017 at 4:29 PM, Jason A. Donenfeld wrote: > It seems like the problem you're facing is that B does not belong to > I, because B belongs to an unrouted dummy0 interface. The solution > would be to change the question of step 4 to instead ask if _any_ > interface

Re: Multihomed server issue

2017-08-10 Thread Jason A. Donenfeld
Hi Wang, Did you have any luck reproducing this with the netns.sh script? Here's what's happening here: 1. Packet from peer P arrives from src:A dst:B 2. WireGuard records that it should contact P at src:B dst:A 3. When sending an encrypted packet to P, it asks for which interface to use for

Re: Multihomed server issue

2017-08-03 Thread Wang Jian
2017-08-03 20:59 GMT+08:00 Jason A. Donenfeld : > 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

Re: Multihomed server issue

2017-08-03 Thread Jason A. Donenfeld
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

Re: Multihomed server issue

2017-08-02 Thread Wang Jian
2017-08-01 19:28 GMT+08:00 Wang Jian : > 2017-08-01 11:06 GMT+08:00 Jason A. Donenfeld : >> On Tue, Aug 1, 2017 at 4:01 AM, Wang Jian wrote: >>> 2017-07-31 23:34 GMT+08:00 Jason A. Donenfeld : On Fri, Jul 28, 2017 at

Re: Multihomed server issue

2017-08-01 Thread Wang Jian
2017-08-01 11:06 GMT+08:00 Jason A. Donenfeld : > On Tue, Aug 1, 2017 at 4:01 AM, Wang Jian wrote: >> 2017-07-31 23:34 GMT+08:00 Jason A. Donenfeld : >>> On Fri, Jul 28, 2017 at 2:51 AM, Wang Jian wrote: The solution

Re: Multihomed server issue

2017-07-31 Thread Jason A. Donenfeld
On Tue, Aug 1, 2017 at 4:01 AM, Wang Jian wrote: > 2017-07-31 23:34 GMT+08:00 Jason A. Donenfeld : >> On Fri, Jul 28, 2017 at 2:51 AM, Wang Jian wrote: >>> The solution can be one of: >>> >>> 1. server can RTS (response to source), or can

Re: Multihomed server issue

2017-07-31 Thread Wang Jian
2017-07-31 23:34 GMT+08:00 Jason A. Donenfeld : > On Fri, Jul 28, 2017 at 2:51 AM, Wang Jian wrote: >> The solution can be one of: >> >> 1. server can RTS (response to source), or can bind to arbitary >> address for outgoing > > The server does already respond

Re: Multihomed server issue

2017-07-31 Thread Jason A. Donenfeld
On Fri, Jul 28, 2017 at 2:51 AM, Wang Jian wrote: > The solution can be one of: > > 1. server can RTS (response to source), or can bind to arbitary > address for outgoing The server does already respond to source. Can you send me a TCP dump and the output of `ip route`