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
>>
prev parent 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 ` 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 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 \
/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
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).