Re: Source IP incorrect on multi homed systems

[tlhackque <tlhackque@yahoo.com>]

[-- Attachment #1.1: Type: text/plain, Size: 5226 bytes --]

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<tlhackque@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-mail@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@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


-- 
This communication may not represent my employer's views,
if any, on the matters discussed.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 840 bytes --]