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<[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 inhttps://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/5fa98082093344c86345f9f63305cae9d5f9f281the 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
OpenPGP_signature
Description: OpenPGP digital signature
