Incorrect Source Addr Selection On Initiate and Asymmetric Routing
wg-lists at bluematt.me
Tue Nov 23 18:32:52 UTC 2021
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.
> 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:
>> 184.108.40.206/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
>> 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.
More information about the WireGuard