Incorrect Source Addr Selection On Initiate and Asymmetric Routing

[Matt Corallo]

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