Development discussion of WireGuard
 help / color / mirror / Atom feed
* Responses send by wireguard always use the default route
@ 2020-12-30 17:41 Dominik Sander
  2021-01-02 19:54 ` David Kerr
  0 siblings, 1 reply; 5+ messages in thread
From: Dominik Sander @ 2020-12-30 17:41 UTC (permalink / raw)
  To: wireguard

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

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: Responses send by wireguard always use the default route
  2020-12-30 17:41 Responses send by wireguard always use the default route Dominik Sander
@ 2021-01-02 19:54 ` David Kerr
       [not found]   ` <67cc2ffb-cf1c-1321-ac68-d0116512847b@wim.email.be>
  2021-01-07 21:33   ` Dominik Sander
  0 siblings, 2 replies; 5+ messages in thread
From: David Kerr @ 2021-01-02 19:54 UTC (permalink / raw)
  To: wireguard

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

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: Responses send by wireguard always use the default route
       [not found]   ` <67cc2ffb-cf1c-1321-ac68-d0116512847b@wim.email.be>
@ 2021-01-02 20:47     ` David Kerr
  2021-01-02 20:51       ` David Kerr
  0 siblings, 1 reply; 5+ messages in thread
From: David Kerr @ 2021-01-02 20:47 UTC (permalink / raw)
  To: wireguard

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

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: Responses send by wireguard always use the default route
  2021-01-02 20:47     ` David Kerr
@ 2021-01-02 20:51       ` David Kerr
  0 siblings, 0 replies; 5+ messages in thread
From: David Kerr @ 2021-01-02 20:51 UTC (permalink / raw)
  To: wireguard

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

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: Responses send by wireguard always use the default route
  2021-01-02 19:54 ` David Kerr
       [not found]   ` <67cc2ffb-cf1c-1321-ac68-d0116512847b@wim.email.be>
@ 2021-01-07 21:33   ` Dominik Sander
  1 sibling, 0 replies; 5+ messages in thread
From: Dominik Sander @ 2021-01-07 21:33 UTC (permalink / raw)
  To: wireguard

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


^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2021-01-07 21:56 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-12-30 17:41 Responses send by wireguard always use the default route Dominik Sander
2021-01-02 19:54 ` David Kerr
     [not found]   ` <67cc2ffb-cf1c-1321-ac68-d0116512847b@wim.email.be>
2021-01-02 20:47     ` David Kerr
2021-01-02 20:51       ` David Kerr
2021-01-07 21:33   ` Dominik Sander

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).