Development discussion of WireGuard
 help / color / mirror / Atom feed
From: Mike O'Connor <mike@pineview.net>
To: Nico Schottelius <nico.schottelius@ungleich.ch>,
	WireGuard mailing list <wireguard@lists.zx2c4.com>
Subject: Re: Source IP incorrect on multi homed systems
Date: Sun, 19 Feb 2023 11:15:55 +1030	[thread overview]
Message-ID: <c83fee12-bef7-d09f-0cc5-d0a193d783c5@pineview.net> (raw)
In-Reply-To: <87bklqd7vb.fsf@ungleich.ch>

Generally all OSs will if sending from a local process will use the 
address of the outgoing interface for the packet.

If the packet is forwarded and no NAT is used the address will be routed 
via the interface suggested by the routing table.

So local routing can be a real pain, policy based routing is an option. 
The other option could be to setup an 'output' NAT to an address which 
is multi-homed.

I have a system running which is multi-homed with out issue other than 
the actual routing machine. This machine is BGP connected to three 
locations.

There is no NAT setup and because I also add the wireguard link 
addresses to the BGP sessions.

Cheers



On 19/2/2023 6:44 am, Nico Schottelius wrote:
> Dear group,
>
> I was wondering how wireguard [Linux kernel] or wireguard-go [FreeBSD]
> are supposed to decide which IP address to use for replying?
>
> I have seen both on FreeBSD and Linux that wireguard seems to use the IP
> address of the outgoing interface, i.e. the one with the route returning
> to the sender. However in multi homed situations, this can be wrong,
> let's take this example:
>
>        19:57:24.607526 net1  In  IP 194.5.220.43.60770 > 147.78.195.254.51820: UDP, length 148
>        19:57:24.608358 net2  Out IP 195.141.200.73.51820 > 194.5.220.43.60770: UDP, length 92
>
> The initiator sends from 194.5.220.43 to the receiver 147.78.195.254.
> Wireguard then replies with the source IP of 195.141.200.73 instead of
> 147.78.195.254.
>
> As the node is multi homed, the packet might leave through any of its
> uplinks and thus return with a random (unexpected) IP address and will
> not pass NAT rules on firewalls and finally be dropped. F.i. in above
> example the firewall drops the packet from 195.141.200.73, because there
> is no session entry for that.
>
> I have observed this behaviour both on Linux 6.1.11 as well as
> wireguard-go 0.0.20220316_8,1 on FreeBSD and in both cases the
> connection will break depending on which active interface is taken as
> exit.
>
> I would argue that wireguard should by default invert the IP
> addresses, i.e. switch dst=src, src=dst and then reply with that,
> instead of adapting an interface specific address, or is there a good
> reason for the current behaviour?
>
> Best regards,
>
> Nico
>
> --
> Sustainable and modern Infrastructures by ungleich.ch



  parent reply	other threads:[~2023-02-19  0:46 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-02-18 20:14 Nico Schottelius
     [not found] ` <CAHx9msc1cNV80YU7HRmQ9gsjSEiVZ=pb31aYqfP62hy8DeuGZA@mail.gmail.com>
2023-02-18 22:34   ` Nico Schottelius
2023-02-19  0:45 ` Mike O'Connor [this message]
2023-02-19  8:01   ` Nico Schottelius
2023-02-19  9:19     ` Mikma
2023-02-19 12:04       ` Nico Schottelius
2023-02-19 12:10     ` Nico Schottelius
2023-02-19 18:59       ` Peter Linder
     [not found]     ` <2ed829aaed9fec59ac2a9b32c4ce0a9005b8d8b850be81c81a226791855fe4eb@mu.id>
2023-02-19 12:13       ` Nico Schottelius
2023-02-19 14:39         ` Christoph Loesch
2023-02-19 16:32           ` David Kerr
2023-02-19 16:54             ` Sebastian Hyrvall
2023-02-19 18:04               ` Janne Johansson
2023-02-19 18:08                 ` Sebastian Hyrvall
2023-02-19 20:11                 ` Nico Schottelius
2023-02-19 17:05             ` tlhackque
2023-02-19 18:37               ` David Kerr
2023-02-19 18:52                 ` tlhackque
2023-02-19 18:42               ` tlhackque
2023-02-19 20:18                 ` Nico Schottelius
2023-02-19 20:42                   ` Roman Mamedov
2023-02-19 21:19                     ` Nico Schottelius
2023-02-19 22:06                       ` tlhackque
2023-02-19 22:42                       ` Src addr code review (Was: Source IP incorrect on multi homed systems) Daniel Gröber
2023-02-20  0:28                         ` 曹煜
2023-02-20 10:40                           ` Nico Schottelius
2023-02-20 11:21                             ` 曹煜
2023-02-20  9:47                         ` Nico Schottelius
2023-02-20 20:43                           ` dxld
2023-02-19 21:39                     ` Source IP incorrect on multi homed systems tlhackque
     [not found]               ` <CADGd2DoE6TCtCxxWL7JWyNW5+yy_Pe+9MNzHznbudMWLTXQreA@mail.gmail.com>
2023-02-19 18:30                 ` Fwd: " John Lauro
2023-02-19 22:28                 ` tlhackque
2023-02-20  0:58                   ` Luiz Angelo Daros de Luca
2023-02-19 20:02           ` Nico Schottelius
2023-02-20 11:09 Janne Johansson

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=c83fee12-bef7-d09f-0cc5-d0a193d783c5@pineview.net \
    --to=mike@pineview.net \
    --cc=nico.schottelius@ungleich.ch \
    --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).