Development discussion of WireGuard
 help / color / mirror / Atom feed
* Incorrect Source Addr Selection On Initiate and Asymmetric Routing
       [not found] <6fc9765d-f4ef-84d2-c65a-97bab58e3e4b@bluematt.me>
  2020-08-15 20:00 ` Incorrect Source Addr Selection On Initiate and Asymmetric Routing Matt Corallo
@ 2020-08-18 15:26 ` Matt Corallo
  2021-11-23 18:32   ` Matt Corallo
  1 sibling, 1 reply; 3+ messages in thread
From: Matt Corallo @ 2020-08-18 15:26 UTC (permalink / raw)
  To: WireGuard mailing list

[Resending this few-month-old mail because apparently the list bounced it the first time.]


Oops, should have mentioned, this may have always been the case, with only recent addition of asymmetric routing leading
me to identify it, but its at least been the case on 5.6.X and currently is the case on 5.7.6.

Matt

On 6/28/20 3:03 PM, Matt Corallo wrote:
> I run wireguard on some endpoints with anycast IP addresses (which mostly workes seamlessly, which is awesome!), however
> of late it seems the source address selection in Wireguard incorrectly selects the default source address when it most
> recently received packet(s) to a different address.
> 
> Most of the routes on such boxes have an explicit default source that is different from the anycast addresses, as
> otherwise regular connections from such boxes would fail, eg:
> 1.0.0.0/24 via XXX dev XXX src (non-anycast-address) metric 32
> 
> Ive observed wireguard selecting the default source in two cases:
> 
> a) when the server is the one sending the handshake initiation due to the handshake timer, it appears the server selects
> a new source address based on the default. I haen't had practical issues with this, but its worth noting, and probably
> fixing.
> 
> b) when the path outbound to the client is different from the path inbound. In my case, inbound v4 traffic from my phone
> on T-Mobile US (which passes through CG-NAT) comes into my server on one interface, but the path back out to TMO is via
> a different interface. In this case, wireguard selects the default source address and sends a packet which T-Mobile's
> CG-NAT drops as there is no NAT entry for it.
> 
> Matt
> 

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: Incorrect Source Addr Selection On Initiate and Asymmetric Routing
  2020-08-18 15:26 ` Matt Corallo
@ 2021-11-23 18:32   ` Matt Corallo
  0 siblings, 0 replies; 3+ messages in thread
From: Matt Corallo @ 2021-11-23 18:32 UTC (permalink / raw)
  To: WireGuard mailing list

Hit this problem again today on 5.10, seems like there's renewed interest in fixing wg's source 
address selection - any chance one of the recent patches may address this?

On 8/18/20 11:26, Matt Corallo wrote:
> [Resending this few-month-old mail because apparently the list bounced it the first time.]
> 
> 
> Oops, should have mentioned, this may have always been the case, with only recent addition of 
> asymmetric routing leading
> me to identify it, but its at least been the case on 5.6.X and currently is the case on 5.7.6.
> 
> Matt
> 
> On 6/28/20 3:03 PM, Matt Corallo wrote:
>> I run wireguard on some endpoints with anycast IP addresses (which mostly workes seamlessly, which 
>> is awesome!), however
>> of late it seems the source address selection in Wireguard incorrectly selects the default source 
>> address when it most
>> recently received packet(s) to a different address.
>>
>> Most of the routes on such boxes have an explicit default source that is different from the 
>> anycast addresses, as
>> otherwise regular connections from such boxes would fail, eg:
>> 1.0.0.0/24 via XXX dev XXX src (non-anycast-address) metric 32
>>
>> Ive observed wireguard selecting the default source in two cases:
>>
>> a) when the server is the one sending the handshake initiation due to the handshake timer, it 
>> appears the server selects
>> a new source address based on the default. I haen't had practical issues with this, but its worth 
>> noting, and probably
>> fixing.
>>
>> b) when the path outbound to the client is different from the path inbound. In my case, inbound v4 
>> traffic from my phone
>> on T-Mobile US (which passes through CG-NAT) comes into my server on one interface, but the path 
>> back out to TMO is via
>> a different interface. In this case, wireguard selects the default source address and sends a 
>> packet which T-Mobile's
>> CG-NAT drops as there is no NAT entry for it.
>>
>> Matt
>>

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: Incorrect Source Addr Selection On Initiate and Asymmetric Routing
       [not found] <6fc9765d-f4ef-84d2-c65a-97bab58e3e4b@bluematt.me>
@ 2020-08-15 20:00 ` Matt Corallo
  2020-08-18 15:26 ` Matt Corallo
  1 sibling, 0 replies; 3+ messages in thread
From: Matt Corallo @ 2020-08-15 20:00 UTC (permalink / raw)
  To: WireGuard mailing list

Oops, should have mentioned, this may have always been the case, with only recent addition of asymmetric routing leading
me to identify it, but its at least been the case on 5.6.X and currently is the case on 5.7.6.

Matt

On 6/28/20 3:03 PM, Matt Corallo wrote:
> I run wireguard on some endpoints with anycast IP addresses (which mostly workes seamlessly, which is awesome!), however
> of late it seems the source address selection in Wireguard incorrectly selects the default source address when it most
> recently received packet(s) to a different address.
> 
> Most of the routes on such boxes have an explicit default source that is different from the anycast addresses, as
> otherwise regular connections from such boxes would fail, eg:
> 1.0.0.0/24 via XXX dev XXX src (non-anycast-address) metric 32
> 
> Ive observed wireguard selecting the default source in two cases:
> 
> a) when the server is the one sending the handshake initiation due to the handshake timer, it appears the server selects
> a new source address based on the default. I haen't had practical issues with this, but its worth noting, and probably
> fixing.
> 
> b) when the path outbound to the client is different from the path inbound. In my case, inbound v4 traffic from my phone
> on T-Mobile US (which passes through CG-NAT) comes into my server on one interface, but the path back out to TMO is via
> a different interface. In this case, wireguard selects the default source address and sends a packet which T-Mobile's
> CG-NAT drops as there is no NAT entry for it.
> 
> Matt
> 

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2021-11-23 18:33 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
     [not found] <6fc9765d-f4ef-84d2-c65a-97bab58e3e4b@bluematt.me>
2020-08-15 20:00 ` Incorrect Source Addr Selection On Initiate and Asymmetric Routing Matt Corallo
2020-08-18 15:26 ` Matt Corallo
2021-11-23 18:32   ` Matt Corallo

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).