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 12:05:11 -0500	[thread overview]
Message-ID: <bdeefdd3-d821-591f-b5fc-701be0e345fb@yahoo.com> (raw)
In-Reply-To: <CAJJxGdGSYR_mofRVpZDQsifjZJXXSNNsPqUV-RfWDMO0N2P2dQ@mail.gmail.com>


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

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


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

  parent reply	other threads:[~2023-02-19 17:07 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 [this message]
     [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 18:37               ` David Kerr
2023-02-19 18:52                 ` tlhackque
2023-02-19 18:42               ` tlhackque
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
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=bdeefdd3-d821-591f-b5fc-701be0e345fb@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).