Development discussion of WireGuard
 help / color / mirror / Atom feed
From: Matt Corallo <wg-lists@bluematt.me>
To: WireGuard mailing list <wireguard@lists.zx2c4.com>
Subject: Re: Incorrect Source Addr Selection On Initiate and Asymmetric Routing
Date: Tue, 23 Nov 2021 13:32:52 -0500	[thread overview]
Message-ID: <3c8c2e52-7a1a-2397-d6f4-769032b93044@bluematt.me> (raw)
In-Reply-To: <eeee1fa3-8b42-1122-3123-d3b07b150036@bluematt.me>

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

      reply	other threads:[~2021-11-23 18:33 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <6fc9765d-f4ef-84d2-c65a-97bab58e3e4b@bluematt.me>
2020-08-15 20:00 ` Matt Corallo
2020-08-18 15:26 ` Matt Corallo
2021-11-23 18:32   ` Matt Corallo [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3c8c2e52-7a1a-2397-d6f4-769032b93044@bluematt.me \
    --to=wg-lists@bluematt.me \
    --cc=wireguard@lists.zx2c4.com \
    --subject='Re: Incorrect Source Addr Selection On Initiate and Asymmetric Routing' \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

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