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 IPv6. Fair enough.  Of course, that means having a unique rule and mark for each if/destination address, which you now have to manage - and avoid conflicts with all other uses of mark.  One of which is wg-quick... "manage" includes remembering to add/remove the rule and allocate/deallocate the mark synchronously with wg-enabled IP addresses - and if wg is listening on all addresses, that means every ip address. You can get there, but as I said, it's a maze of twisty passages and the complications of managing it pile up. > But yes, it is a nasty hack. You really need to understand what is > going on between the firewall and routing tables/rules and it is easy > to get confused. > > > On Sun, Feb 19, 2023 at 12:10 PM 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.