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<tlhack...@yahoo.com> 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<wireguard-m...@chil.at> 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<s...@keff.org> 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
-- This communication may not represent my employer's views, if any, on the matters discussed.
OpenPGP_signature
Description: OpenPGP digital signature
