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 not all, DNS clients, expect the address from which a reply > is received to be the same address as that to which the query > eliciting the reply was sent. This is true for servers acting as > clients for the purposes of recursive query resolution, as well as > simple resolver clients. The address, along with the identifier (ID) > in the reply is used for disambiguating replies, and filtering > spurious responses. This may, or may not, have been intended when > the DNS was designed, but is now a fact of life. > > Some multi-homed hosts running DNS servers generate a reply using a > source address that is not the same as the destination address from > the client's request packet. > _**Such replies will be discarded by the client because the source > address of the reply does not match that of a host to which the client > sent the original request.** _ That is, it > appears to be an unsolicited response. > > 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 set to the address that was in the destination address > field of the IP header of the packet containing the query causing the > response.** * > If this would cause the response to be sent from an IP > address that is not permitted for this purpose, then the response may > be sent from any legal IP address allocated to the server. That > address should be chosen to maximise the possibility that the client > will be able to use it for further queries. Servers configured in > such a way that not all their addresses are equally reachable from > all potential clients need take particular care when responding to > queries sent to anycast, multicast, or similar, addresses. > On 19-Feb-23 12:05, tlhackque wrote: > 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 interface... > > With IPv6 it's common to assign an address to a service rather than a > host so services can move easily.  So multiple addresses per interface > are the rule, not the exception. > > I do the same with IPv4 inside addresses, though these days public > IPv4 addresses are scarce enough that it's not common for public IPs.  > It amounts to the same issue - the NAT tracking is stateful. > > Trying to work around this with routing seems like a maze of twisty > passages - so I agree that the right solution is for WG to respond > from the address that receives a packet. > > On 19-Feb-23 11:32, David Kerr wrote: >> 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 new ip route table that sets the default route to go out >> on the interface with the source address you want (same as destination >> address in iptables) >> 3. Create a new ip rule that sends all packets with firewall mark set >> in iptables to the routing table you just created >> >> Repeat above for each interface/address you need to mangle, with a >> unique firewall mark and routing table for each. >> >> It may be necessary to use CONNMARK in PREROUTING and OUTPUT to >> --restore_mark.  I can't remember if this is needed or not, its been a >> while since I configured iptables with this. >> >> This should ensure that any packet that comes into an >> interface/address is replied to from the same interface/address. >> >> David >> >> >> On Sun, Feb 19, 2023 at 9:44 AM Christoph >> Loesch  wrote: >>> 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 >>> inhttps://lists.zx2c4.com/pipermail/wireguard/2021-November/007324.html >>> >>> ip route del >>> ip route add dev src >>> >>> This way I was able to (at least temporary) fix this issue on multi >>> homed systems. >>> >>> Kind regards, >>> Christoph >>> >>> Am 19.02.2023 um 13:13 schrieb Nico Schottelius: >>>> 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 since src ip could not be configured. >>>>> >>>>> There is an unofficial patch however, >>>>> >>>>> https://github.com/torvalds/linux/commit/5fa98082093344c86345f9f63305cae9d5f9f281 >>>>> >>>> the binding is somewhat related to this issue and I was looking for >>>> that >>>> feature some time ago, too. While it is correlated and I would really >>>> appreciate binding support, I am not sure whether the linked patch >>>> does >>>> actually fix the problem I am seeing in multi homed devices. >>>> >>>> As long as wireguard does not reply with the same IP address it was >>>> contacted with, packets will get dropped on stateful firewalls, >>>> because >>>> the returning packet does not match the state session database. >>>> >>>> Best regards, >>>> >>>> Nico >>>> >>>> -- >>>> Sustainable and modern Infrastructures by ungleich.ch > -- This communication may not represent my employer's views, if any, on the matters discussed.