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

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

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 =

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

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

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

Re: [RESEND PATCH v3] wg: Support restricting address family of DNS resolved Endpoint

19.02.2023 21:31, Roman Mamedov пишет: On Sun, 19 Feb 2023 19:04:28 +0100 Daniel Gröber wrote: +static inline bool parse_address_family(int *family, const char *value) +{ + if (strcmp(value, "inet") == 0) + *family = AF_INET; + else if (strcmp(value, "inet6") == 0) +

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

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

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

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,

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.

Re: [RESEND PATCH v3] wg: Support restricting address family of DNS resolved Endpoint

On Sun, 19 Feb 2023 19:04:28 +0100 Daniel Gröber wrote: > +static inline bool parse_address_family(int *family, const char *value) > +{ > + if (strcmp(value, "inet") == 0) > + *family = AF_INET; > + else if (strcmp(value, "inet6") == 0) > + *family = AF_INET6;

[PATCH v2] wg: Allow config to read secret keys from file

This adds two new config keys PrivateKeyFile= and PresharedKeyFile= that simply hook up the existing code for the `wg set ... private-key /file` codepath. By using the new options wireguard configs can become a lot easier to manage and deploy as we don't have to treat them as secrets anymore.

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

[RESEND PATCH v3] wg: Support restricting address family of DNS resolved Endpoint

When using wireguard tunnels for providing IPv6 connectivity to machines it can be important to pin which IP address family should be used. Consider a peer using a DNS name with both A/ records, wg will currently blindly follow system policy and use the first address returned by

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

Missing translation keys from recent on-demand updates

Hello, I noticed that some translations are missing on macOS and iOS as just the translation-keys are shown. According to a diff (at least) the following keys from the original/English version are neither in the German Localizable.strings nor in the German crowdin. Looks like this in other

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

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

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

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

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

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

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