Source IP incorrect on multi homed systems

[David Kerr]

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