Re: Source IP incorrect on multi homed systems

[tlhackque]

BTW, DNS is a common UDP (well, mostly) protocol that encountered the same issue. See RFC 2181 <https://www.rfc-editor.org/rfc/rfc2181.html> (1997), where you'll find (emphasis added):

4 <https://www.rfc-editor.org/rfc/rfc2181.html#section-4>. Server Reply Source Address Selection

    Most, if not all, DNS clients, expect the address from which a reply
    is received to be the same address as that to which the query
    eliciting the reply was sent.  This is true for servers acting as
    clients for the purposes of recursive query resolution, as well as
    simple resolver clients.  The address, along with the identifier (ID)
    in the reply is used for disambiguating replies, and filtering
    spurious responses.  This may, or may not, have been intended when
    the DNS was designed, but is now a fact of life.

    Some multi-homed hosts running DNS servers generate a reply using a
    source address that is not the same as the destination address from
    the client's request packet.

_**Such replies will be discarded by the client because the source address of the reply does not match that of a host to which the client sent the original request.** _ That is, it

    appears to be an unsolicited response.

4.1 <https://www.rfc-editor.org/rfc/rfc2181.html#section-4.1>. UDP Source Address Selection

***To avoid these problems, servers when responding to queries using UDP _must _cause the reply to be sent with the source address field in the IP header set to the address that was in the destination address field of the IP header of the packet containing the query causing the response.** *

If this would cause the response to be sent from an IP
    address that is not permitted for this purpose, then the response may
    be sent from any legal IP address allocated to the server.  That
    address should be chosen to maximise the possibility that the client
    will be able to use it for further queries.  Servers configured in
    such a way that not all their addresses are equally reachable from
    all potential clients need take particular care when responding to
    queries sent to anycast, multicast, or similar, addresses.

On 19-Feb-23 12:05, tlhackque 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...

On 19-Feb-23 11:32, David Kerr wrote:

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.

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>



Kind regards,
Christoph

Am 19.02.2023 um 13:13 schrieb Nico Schottelius:

This way I was able to (at least temporary) fix this issue on multi homed systems.

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/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

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

the returning packet does not match the state session database.

Best regards,

Nico

--
Sustainable and modern Infrastructures by ungleich.ch

appreciate binding support, I am not sure whether the linked patch does contacted with, packets will get dropped on stateful firewalls, because

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

OpenPGP_signature
Description: OpenPGP digital signature