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 <[email protected]> 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 in > https://lists.zx2c4.com/pipermail/wireguard/2021-November/007324.html > > ip route del <NET> > ip route add <NET> dev <ALIAS_DEV> src <SRC_IP> > > 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 <[email protected]> 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
