Source IP incorrect on multi homed systems

[tlhackque]

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-mail at 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<sh at 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/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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 840 bytes
Desc: OpenPGP digital signature
URL: <http://lists.zx2c4.com/pipermail/wireguard/attachments/20230219/a3018c40/attachment.sig>