From: David Kerr <david@kerr.net>
To: wireguard@lists.zx2c4.com
Subject: Re: Source IP incorrect on multi homed systems
Date: Sun, 19 Feb 2023 13:37:52 -0500 [thread overview]
Message-ID: <CAJJxGdGjQ_m4LYWgvX4TEB=KsRWSM3oSM8dqVjL8wMkBvonqOQ@mail.gmail.com> (raw)
In-Reply-To: <bdeefdd3-d821-591f-b5fc-701be0e345fb@yahoo.com>
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.
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
>
next prev parent reply other threads:[~2023-02-19 18:39 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
[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 [this message]
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='CAJJxGdGjQ_m4LYWgvX4TEB=KsRWSM3oSM8dqVjL8wMkBvonqOQ@mail.gmail.com' \
--to=david@kerr.net \
--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).