Re: Src addr code review (Was: Source IP incorrect on multi homed systems)

Hi Nico, On Mon, Feb 20, 2023 at 10:47:36AM +0100, Nico Schottelius wrote: > Daniel Gröber writes: > > Let's look at the code (heavily culled): > > > > struct flowi4 fl = { > > .saddr = endpoint->src4.s_addr, > > }; > > if (cache) > > rt = dst_cache_get_ip4(cac

Fwd: Source IP incorrect on multi homed systems

I think the ip route with src would work, but only as a short lived work around. The problem with it is if dealing with dynamic routes is it could go a way when a link is down and then come back and the src setting would be lost. You would need the bgp software to add the src. UDP is connectionl

Re: Src addr code review (Was: Source IP incorrect on multi homed systems)

Hi Nico, That issue was closed by myself, but the patch didn't get applied cause the issue was came from wireguard itself, and the maintener told me that I should send my patch to wireguard upstream (but I just gave up for sending it to wireguard team). Nico Schottelius 于2023年2月20日周一 18:41写道： > >

Re: Source IP incorrect on multi homed systems

rewriting for the lists, managed to bold some pasted text and hence get blocked due to html-mails not allowed on list. Den sön 19 feb. 2023 kl 21:17 skrev Nico Schottelius : > Janne Johansson writes: > > *) https://en.wiktionary.org/wiki/Chesterton%27s_fence > > I am happy to have learned a new p

Re: Src addr code review (Was: Source IP incorrect on multi homed systems)

Hello 曹煜, on github it seems your patch was applied / the issue was closed - is that the correct current status? Best regards, Nico 曹煜 writes: > Hi all, > I've hacked that source code myself months ago, and it works well on > my use case (I have 4 dual stack pppoe wan set on my openwrt rout

Re: Src addr code review (Was: Source IP incorrect on multi homed systems)

Hey Daniel, thanks a lot for diving in ... Daniel Gröber writes: > Let's look at the code (heavily culled): > > struct flowi4 fl = { > .saddr = endpoint->src4.s_addr, > }; > if (cache) > rt = dst_cache_get_ip4(cache, &fl.saddr); What I am wonderin

Re: Source IP incorrect on multi homed systems

Yes, wg is not a request/response protocol. But it does have some state. Can't wireguard remember the last local address that each peer sent traffic? It is just like the tracking already in use for peer ip address. If there is an "last address" it would be nice if we could hint the kernel to use th

Re: Src addr code review (Was: Source IP incorrect on multi homed systems)

Hi all, I've hacked that source code myself months ago, and it works well on my use case (I have 4 dual stack pppoe wan set on my openwrt router, and seted a wireguard sever on it), my hack will pickup the dst_addr from incoming handshake packet in kernel sk_buff, and then use that addr as src_addr

Src addr code review (Was: Source IP incorrect on multi homed systems)

Hi, I though it might be useful to do some quick and dirty code review instead of speculating wildly to figure out where these source IP selection problems could be coming from ;) >From previous code deep dives I know the udp_tunnel_xmit_skb function is where tunnel packets get handed off to the

Re: Source IP incorrect on multi homed systems

Actually in my case (I'm not the originator of this thread), I don't run BGP.  But I do have both site-site and mobile-site clients.  Much simpler environment, but same issue. I do understand UDP. As I've noted, DNS UDP has the same issue, and an RFC was issued to clarify that responses MUST

Re: Source IP incorrect on multi homed systems

On 19-Feb-23 16:19, Nico Schottelius wrote: So far this situation doesn't exist for us, because only servers are multi homed. It's not that uncommon; consider a docked notebook that has a WiFi address and an Ethernet address on the same subnet. While typically the routing priorities favor th

Re: Source IP incorrect on multi homed systems

Hey Roman, Roman Mamedov writes: > On Sun, 19 Feb 2023 21:18:34 +0100 > Nico Schottelius wrote: > >> If I am not mistaken that would mean in practice: >> >>if orignal_pkg.ip_dst == one_of_my_ips then >> return_pkg.ip.src = orignal_pkg.ip_dst >> return_pkg.ip.dst = orignal_pkg.

Re: Source IP incorrect on multi homed systems

On 19-Feb-23 15:42, Roman Mamedov wrote: On Sun, 19 Feb 2023 21:18:34 +0100 Nico Schottelius wrote: If I am not mistaken that would mean in practice: if orignal_pkg.ip_dst == one_of_my_ips then return_pkg.ip.src = orignal_pkg.ip_dst return_pkg.ip.dst = orignal_pkg.ip_src

Re: Source IP incorrect on multi homed systems

On Sun, 19 Feb 2023 21:18:34 +0100 Nico Schottelius wrote: > If I am not mistaken that would mean in practice: > >if orignal_pkg.ip_dst == one_of_my_ips then > return_pkg.ip.src = orignal_pkg.ip_dst > return_pkg.ip.dst = orignal_pkg.ip_src >fi > > For me that sounds like a s

Re: Source IP incorrect on multi homed systems

tlhackque writes: >> [...] >> 4.1 . UDP >> Source Address Selection >> >> ***To avoid these problems, servers when responding to queries >> using UDP _must _cause the reply to be sent with the source address >> field in the IP header s

Re: Source IP incorrect on multi homed systems

Hey Janne, Janne Johansson writes: > *) https://en.wiktionary.org/wiki/Chesterton%27s_fence I am happy to have learned a new principle today, thanks for that. And to be sure that everyone is on the same page: Wireguard should reply by default with the source address that used to be t

Re: Source IP incorrect on multi homed systems

Hello Christoph, Christoph Loesch writes: > @Nico: did you try to delete the affected route and add it again with the > correct source IP ? No, I did not because the routes are really dynamic on the affected systems and I would need to overwrite the BGP routes with a better metric, which in t

Re: Source IP incorrect on multi homed systems

Indeed this is how you typically set up a multihomed service (addresses on lo and then announce that using BGP or something). If you use one of the network links directly for the service and that link network goes down (it may not even be in your AS so you may not know?) then the service is of

Re: Source IP incorrect on multi homed systems

On 19-Feb-23 13:37, David Kerr wrote: My proposed workaround specifically stated to match on both the interface and destination address, and to set a route with both interface and [source] address. This allows for multiple IP addresses on the same interface -- which you can do with both IPv4 and

Re: Source IP incorrect on multi homed systems

BTW, DNS is a common UDP (well, mostly) protocol that encountered the same issue. See RFC 2181 (1997), where you'll find (emphasis added): 4 . Server Reply Source Address Selection Most, if

Re: Source IP incorrect on multi homed systems

My proposed workaround specifically stated to match on both the interface and destination address, and to set a route with both interface and [source] address. This allows for multiple IP addresses on the same interface -- which you can do with both IPv4 and IPv6. But yes, it is a nasty hack. Yo

Re: Source IP incorrect on multi homed systems

It is the default behavior of the kernel. But all networking software dealing in security knows how to correctly behave. You are welcome to inform me of something else suffering the same problem. On 2023-02-20 01:04, Janne Johansson wrote: Den sön 19 feb. 2023 kl 18:06 skrev Sebastian Hyrvall

Re: Source IP incorrect on multi homed systems

Den sön 19 feb. 2023 kl 18:06 skrev Sebastian Hyrvall : > > You should get into that debate. Proposing firewall workarounds is not a > correct solution so please don't do it. It needs to be fixed. It's an > immature VPN solution that always just proposed a workaround instead of > fixing the problem

Re: Source IP incorrect on multi homed systems

You should get into that debate. Proposing firewall workarounds is not a correct solution so please don't do it. It needs to be fixed. It's an immature VPN solution that always just proposed a workaround instead of fixing the problem. It seems to be designed by people that are good at software

Re: Source IP incorrect on multi homed systems

FWIW, while clever, I don't think that iptables mark solves all cases.  E.g., consider an interface with multiple addresses, where a packet comes in on a secondary address.  The proposed rule would send it out the right interface, but still with the wrong (primary) address picked from the inter

Re: Source IP incorrect on multi homed systems

Without getting into the debate of whether wireguard is acting correctly or not, I think there is a possible workaround. 1. In the iptables mangle table PREROUTING, match the incoming interface and destination address and --set-xmark a firewall MARK unique to this interface/destination 2. Create a

Re: Source IP incorrect on multi homed systems

Hi, I don't think no one wants to fix it, there are several users having this issue. I rather guess no one could find a suitable solution to fix it. @Nico: did you try to delete the affected route and add it again with the correct source IP ? as I mentioned it in https://lists.zx2c4.com/pipe

Re: Source IP incorrect on multi homed systems

Hey Sebastian, Sebastian Hyrwall writes: > It is kinda. It's been mentioned multiple times over the years but no one > seems to want to fix it. Atleast you should be able to specify bind/src ip in > the > config. I gave up WG because of it. Wasn't accepted by my projects security > policy s

Re: Source IP incorrect on multi homed systems

Aside from nginx + icmp being handled correctly as a reference, I want to further elaborate on this case to show that something is really wrong with the current behaviour: A typical scenario for routers is to have a lot of global reachable IP addresses (IPv6, IPv4) assigned to the loopback inter

Re: Source IP incorrect on multi homed systems

Hello Mikma, Mikma writes: > Have you tried setting the preferred src address of the route(s) to the > addresses you desire? > > From "man ip": > >> src ADDRESS the source address to prefer when sending to the destinations >> covered by the route prefix. unfortunately this does not solve th

Re: Source IP incorrect on multi homed systems

Have you tried setting the preferred src address of the route(s) to the addresses you desire? From "man ip": > src ADDRESS the source address to prefer when sending to the destinations > covered by the route prefix. On 19 February 2023 09:01:31 CET, Nico Schottelius wrote: > >Let me rephras

Re: Source IP incorrect on multi homed systems

Let me rephrase the problem statement: - ping and http calls to the multi homed machine work correctly: I can ping 147.78.195.254 and the reply contains the same address. I can ping 195.141.200.73 and the reply contains the same address. I can curl 147.78.195.254 and the re

Re: Source IP incorrect on multi homed systems

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 ro

Re: Source IP incorrect on multi homed systems

Hello Omkhar, I tend to disagree. The problem is not the routing, but the selected source address, which is independent of routing. To be more specific: as there is BGP routing on all all interfaces, 147.78.195.254 is an accepted IP address on any interface. Best regards, Nico Omkhar Arasarat

Source IP incorrect on multi homed systems

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 th