Responses send by wireguard always use the default route

Sat Jan 2 20:51:19 UTC 2021

I might just add... that it could be perfectly feasible to do
something in wg-quick (or create a separate script) that adds the
necessary iptables and ip rules / ip route tables to do as requested
in a user friendly way.

On Sat, Jan 2, 2021 at 3:47 PM David Kerr <david at kerr.net> wrote:
>
> William,
>   Yes, but this is expected behavior and nothing to do with wireguard.
> I could have two WAN interfaces eth0 and eth1 for redundancy, let's
> say one connected to Comcast other to Frontier (ex-AT&T) -- the two
> ISPs that serve where I live.  If these are both always up, and I
> accept connections on either, then it is important that replies to
> incoming packets go back out on the same interface they arrived on.
> Linux does not handle this by default.  Maybe it should and that is
> pretty much what you are asking wireguard to do -- handle it by
> default.  But that is not the role of wireguard, it is the role of
> kernel packet routing and the architected mechanism to do that is to
> mark incoming packets, etc etc.
>
> David.
>
> On Sat, Jan 2, 2021 at 3:04 PM William Golding
> <wireguard-gafgf at wim.email.be> wrote:
> >
> > Hi David,
> >
> > I agree that following the standard routing table rules is good, but
> > Wireguard should reply with the same IP as the one it received the
> > packet on.
> > Right now the reply packets doesn't use the endpoint IP (that the client
> > uses) as the source IP for the return packet.
> >
> > We have a situation where our Wireguard endpoint has 2 IPs (2 uplinks).
> > It receives a packet from the client on IP 1.1.1.1, but replies from IP
> > 2.2.2.2, meaning the client just discards this packet, since it never
> > sent a packet to 2.2.2.2 and has no clue what lives on 2.2.2.2 anyway.
> >
> > Kind regards,
> > William
> >
> >
> > On 2/01/2021 20:54, David Kerr wrote:
> > > This is expected behavior... outbound packets follow routing table
> > > rules to select the "best" interface to send from.  You can use
> > > iptables to mark packets coming in from one interface and then set up
> > > an ip routing table to make sure that replies to traffic on an
> > > incoming interface go back out on the same interface.  Search for that
> > > on google for suggested solutions.  By way of an example, here is what
> > > I have on my router to make sure that any traffic coming in on wg0 to
> > > my local network(s) is sent back out over wg0.
> > >
> > > # iptables -t mangle -S | grep restore-mark
> > > -A PREROUTING -j CONNMARK --restore-mark --nfmask 0xffffffff --ctmask 0xffffffff
> > > -A OUTPUT -j CONNMARK --restore-mark --nfmask 0xffffffff --ctmask 0xffffffff
> > > # iptables -t mangle -S | grep WG0
> > > -N PREROUTING_WG0
> > > -A PREROUTING -i wg0 -j PREROUTING_WG0
> > > -A PREROUTING_WG0 -m state --state NEW -j MARK --set-xmark 0x4/0x4
> > > -A PREROUTING_WG0 -m state --state NEW -j CONNMARK --save-mark
> > > --nfmask 0xffffffff --ctmask 0xffffffff
> > > # ip rule
> > > 0: from all lookup local
> > > 1000: from 192.168.1.1/24 fwmark 0x4/0x4 lookup 300
> > > 1001: from all to <redacted> lookup 51820
> > > 32766: from all lookup main
> > > 32767: from all lookup default
> > > # ip route show table 300
> > > default dev wg0 scope link
> > >
> > > David.
> > >
> > >
> > > On Sat, Jan 2, 2021 at 10:34 AM Dominik Sander <mail at dsander.de> wrote:
> > >> Hi!
> > >>
> > >> I would like to confirm if the behavior I am seeing is intended or if my
> > >> use case should be supported without additional configuration.
> > >>
> > >> When wireguard is configured on a server that has multiple network
> > >> interfaces the response is always send through the route with the lowest
> > >> metric, even when the connection was initiated via a different interface.
> > >>
> > >> The Wireguard server is exposed via my router, port 13377 is forwarded
> > >> to 192.168.1.246, the peer is connecting via an external IP:
> > >>
> > >> # ip route
> > >> default via 10.0.0.1 dev eth1 proto dhcp src 10.0.0.171 metric 50
> > >> default via 192.168.1.1 dev eth0 proto dhcp src 192.168.1.246 metric 100
> > >> 10.0.0.0/24 dev eth1 proto kernel scope link src 10.0.0.171 metric 50
> > >> 10.0.0.1 dev eth1 proto dhcp scope link src 10.0.0.171 metric 50
> > >> 192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.246 metric 100
> > >> 192.168.1.1 dev eth0 proto dhcp scope link src 192.168.1.246 metric 100
> > >>
> > >> # tcpdump -i any -vn "(host 80.xxx.xxx.xxx or src port 13377 or dst port 13377)"
> > >> tcpdump: listening on any, link-type LINUX_SLL (Linux cooked v1), capture size 262144 bytes
> > >> 14:13:08.767409 IP (tos 0x0, ttl 50, id 12125, offset 0, flags [none], proto UDP (17), length 176)
> > >>      80.xxx.xxx.xxx.17819 > 192.168.1.246.13377: UDP, length 148
> > >> 14:13:08.768076 IP (tos 0x88, ttl 64, id 180, offset 0, flags [none], proto UDP (17), length 120)
> > >>      10.0.0.171.13377 > .xxx.xxx.xxx.17819: UDP, length 92
> > >>
> > >> Because the response is send from the "wrong" IP address the router does not know
> > >> how to forward it and the client never is properly connected.
> > >>
> > >> I was wondering if the IP/interface of the request could also be used for the response,
> > >> to remove the need for policy based routing or iptable rules.
> > >>
> > >> The actual use case is wireguard on a OpenWRT router which has multiple WAN interfaces.
> > >> The WAN with the lowest metric is not the interface that should be used for wireguard
> > >> because it has better download speed, the wireguard WAN has better upload speed.
> > >>
> > >> Fore reference a thread discussing the problem on GitHub [1] and on the OpenWRT Forum [2].
> > >>
> > >> Thanks for creating/working on wireguard!
> > >>
> > >> Kind regards,
> > >>
> > >> Dominik
> > >>
> > >> [1] https://github.com/openwrt/packages/issues/9538
> > >> [2] https://forum.openwrt.org/t/wireguard-server-can-only-successfully-be-used-via-one-wan-interface/83374
> >