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
