You should get into that debate. Proposing firewall workarounds is not a
correct solution so please don't do it. It needs to be fixed. It's an
immature VPN solution that always just proposed a workaround instead of
fixing the problem. It seems to be designed by people that are good at
software and cryptography but has no clue about networking stacks.
On 2023-02-19 23: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 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
