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