Development discussion of WireGuard
 help / color / mirror / Atom feed
From: tlhackque <tlhackque@yahoo.com>
To: wireguard@lists.zx2c4.com
Subject: Re: Source IP incorrect on multi homed systems
Date: Sun, 19 Feb 2023 13:42:02 -0500	[thread overview]
Message-ID: <c2bc4ed2-e8c5-ff68-9fe8-c59c8be2804c@yahoo.com> (raw)
In-Reply-To: <bdeefdd3-d821-591f-b5fc-701be0e345fb@yahoo.com>


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

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...
>
> 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 --]

  parent reply	other threads:[~2023-02-19 18:45 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-02-18 20:14 Nico Schottelius
     [not found] ` <CAHx9msc1cNV80YU7HRmQ9gsjSEiVZ=pb31aYqfP62hy8DeuGZA@mail.gmail.com>
2023-02-18 22:34   ` Nico Schottelius
2023-02-19  0:45 ` Mike O'Connor
2023-02-19  8:01   ` Nico Schottelius
2023-02-19  9:19     ` Mikma
2023-02-19 12:04       ` Nico Schottelius
2023-02-19 12:10     ` Nico Schottelius
2023-02-19 18:59       ` Peter Linder
     [not found]     ` <2ed829aaed9fec59ac2a9b32c4ce0a9005b8d8b850be81c81a226791855fe4eb@mu.id>
2023-02-19 12:13       ` Nico Schottelius
2023-02-19 14:39         ` Christoph Loesch
2023-02-19 16:32           ` David Kerr
2023-02-19 16:54             ` Sebastian Hyrvall
2023-02-19 18:04               ` Janne Johansson
2023-02-19 18:08                 ` Sebastian Hyrvall
2023-02-19 20:11                 ` Nico Schottelius
2023-02-19 17:05             ` tlhackque
2023-02-19 18:37               ` David Kerr
2023-02-19 18:52                 ` tlhackque
2023-02-19 18:42               ` tlhackque [this message]
2023-02-19 20:18                 ` Nico Schottelius
2023-02-19 20:42                   ` Roman Mamedov
2023-02-19 21:19                     ` Nico Schottelius
2023-02-19 22:06                       ` tlhackque
2023-02-19 22:42                       ` Src addr code review (Was: Source IP incorrect on multi homed systems) Daniel Gröber
2023-02-20  0:28                         ` 曹煜
2023-02-20 10:40                           ` Nico Schottelius
2023-02-20 11:21                             ` 曹煜
2023-02-20  9:47                         ` Nico Schottelius
2023-02-20 20:43                           ` dxld
2023-02-19 21:39                     ` Source IP incorrect on multi homed systems tlhackque
     [not found]               ` <CADGd2DoE6TCtCxxWL7JWyNW5+yy_Pe+9MNzHznbudMWLTXQreA@mail.gmail.com>
2023-02-19 18:30                 ` Fwd: " John Lauro
2023-02-19 22:28                 ` tlhackque
2023-02-20  0:58                   ` Luiz Angelo Daros de Luca
2023-02-19 20:02           ` Nico Schottelius
2023-02-20 11:09 Janne Johansson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=c2bc4ed2-e8c5-ff68-9fe8-c59c8be2804c@yahoo.com \
    --to=tlhackque@yahoo.com \
    --cc=wireguard@lists.zx2c4.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).