Responses send by wireguard always use the default route

[Dominik Sander]

Thank you for confirming that this is working as intended.

regards,

Dominik

On 02/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