* Why does 'allowed-ips' affect route selection behavior?
@ 2018-04-15 18:49 Patrick O'Sullivan
2018-04-15 18:58 ` Roman Mamedov
2018-04-15 18:58 ` mikma.wg
0 siblings, 2 replies; 7+ messages in thread
From: Patrick O'Sullivan @ 2018-04-15 18:49 UTC (permalink / raw)
To: wireguard
Hi Folks,
Getting my feet wet with wireguard and enjoying the simplicity and
performance thus far. Nonetheless, I have a question about how the
normal route selection process is being affected by what's configured
for 'allowed-ips'.
I set up a peer and configured 'allowed-ips' for 0.0.0.0/0, as I was
going to be sending multiple routes over the peer link via BGP and
didn't want to keep modifying it. However, even though my default
route was over a different interface, this seemed to result in Linux
trying to route default traffic over wg0 despite there not being a
default route pointing to wg0.
Specifically:
$ sudo ip route show
default via 10.199.199.1 dev wlan0
10.111.111.0/24 dev wg0 proto kernel scope link src 10.111.111.100
10.199.199.0/24 dev wlan0 proto kernel scope link src 10.199.199.131
By this route table, traffic to e.g. 4.2.2.1 should use 10.199.199.1.
Packet captures were showing traffic trying to instead use wg0. Then I
found this:
$ sudo ip route get 4.2.2.1
4.2.2.1 dev wg0 table 51820 src 10.111.111.100
cache
Can someone please explain this behavior?
Obligatory... $ uname -rvm
4.14.30-v7+ #1102 SMP Mon Mar 26 16:45:49 BST 2018 armv7l
And... $ dpkg -l | grep wireguard
ii wireguard 0.0.20180413-1 all
fast, modern, secure kernel VPN tunnel (metapackage)
ii wireguard-dkms 0.0.20180413-1 all
fast, modern, secure kernel VPN tunnel (DKMS version)
ii wireguard-tools 0.0.20180413-1 armhf
fast, modern, secure kernel VPN tunnel (userland utilities)
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Why does 'allowed-ips' affect route selection behavior?
2018-04-15 18:49 Why does 'allowed-ips' affect route selection behavior? Patrick O'Sullivan
@ 2018-04-15 18:58 ` Roman Mamedov
2018-04-15 22:26 ` Jason A. Donenfeld
2018-04-15 18:58 ` mikma.wg
1 sibling, 1 reply; 7+ messages in thread
From: Roman Mamedov @ 2018-04-15 18:58 UTC (permalink / raw)
To: Patrick O'Sullivan; +Cc: wireguard
On Sun, 15 Apr 2018 14:49:23 -0400
"Patrick O'Sullivan" <irish@insaneirish.com> wrote:
> $ sudo ip route get 4.2.2.1
> 4.2.2.1 dev wg0 table 51820 src 10.111.111.100
^^^^^^^^^^^
> cache
> Can someone please explain this behavior?
Probably will be easier to do if you show the output of "ip -4 rule".
--
With respect,
Roman
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Why does 'allowed-ips' affect route selection behavior?
2018-04-15 18:49 Why does 'allowed-ips' affect route selection behavior? Patrick O'Sullivan
2018-04-15 18:58 ` Roman Mamedov
@ 2018-04-15 18:58 ` mikma.wg
1 sibling, 0 replies; 7+ messages in thread
From: mikma.wg @ 2018-04-15 18:58 UTC (permalink / raw)
To: wireguard
On 04/15/2018 08:49 PM, Patrick O'Sullivan wrote:
> $ sudo ip route show
> default via 10.199.199.1 dev wlan0
> 10.111.111.0/24 dev wg0 proto kernel scope link src 10.111.111.100
> 10.199.199.0/24 dev wlan0 proto kernel scope link src 10.199.199.131
>
> By this route table, traffic to e.g. 4.2.2.1 should use 10.199.199.1.
> Packet captures were showing traffic trying to instead use wg0. Then I
> found this:
>
> $ sudo ip route get 4.2.2.1
> 4.2.2.1 dev wg0 table 51820 src 10.111.111.100
> cache
>
> Can someone please explain this behavior?
Table 51820 is the default table used by wg-quick.
From wg-quick's man page:
> It infers all routes from the list of peers' allowed IPs, and automatically adds them to the system routing table. If one of those routes is the default route (0.0.0.0/0 or ::/0), then it uses ip-rule(8) to handle overriding of the default gateway.
/Mikma
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Why does 'allowed-ips' affect route selection behavior?
2018-04-15 18:58 ` Roman Mamedov
@ 2018-04-15 22:26 ` Jason A. Donenfeld
2018-04-16 1:06 ` Patrick O'Sullivan
2018-04-16 12:29 ` Tim Sedlmeyer
0 siblings, 2 replies; 7+ messages in thread
From: Jason A. Donenfeld @ 2018-04-15 22:26 UTC (permalink / raw)
To: Patrick O'Sullivan; +Cc: WireGuard mailing list
Hi Patrick,
I see some others on the wireguard mailing list have replied to a
ghost email. That is, I don't have the original that they're replying
to. Looking into it a bit further, it appears that reasonable spam
filters -- which includes but is not limited to gmail's -- will have
your mail immediately bounced, because of your strict dmarc entry
("v=DMARC1; p=reject; rua=mailto:dmarc@insaneirish.com"), since
mailing list servers like lists.zx2c4.com tend to "remail" things. You
might want to loosen these up a bit. Anyway, I've pulled it out of the
archives for quoting here:
> Hi Folks,
>
> Getting my feet wet with wireguard and enjoying the simplicity and
> performance thus far. Nonetheless, I have a question about how the
> normal route selection process is being affected by what's configured
> for 'allowed-ips'.
>
> I set up a peer and configured 'allowed-ips' for 0.0.0.0/0, as I was
> going to be sending multiple routes over the peer link via BGP and
> didn't want to keep modifying it. However, even though my default
> route was over a different interface, this seemed to result in Linux
> trying to route default traffic over wg0 despite there not being a
> default route pointing to wg0.
>
> Specifically:
>
> $ sudo ip route show
> default via 10.199.199.1 dev wlan0
> 10.111.111.0/24 dev wg0 proto kernel scope link src 10.111.111.100
> 10.199.199.0/24 dev wlan0 proto kernel scope link src 10.199.199.131
>
> By this route table, traffic to e.g. 4.2.2.1 should use 10.199.199.1.
> Packet captures were showing traffic trying to instead use wg0. Then I
> found this:
>
> $ sudo ip route get 4.2.2.1
> 4.2.2.1 dev wg0 table 51820 src 10.111.111.100
> cache
>
> Can someone please explain this behavior?
>
> Obligatory... $ uname -rvm
> 4.14.30-v7+ #1102 SMP Mon Mar 26 16:45:49 BST 2018 armv7l
>
> And... $ dpkg -l | grep wireguard
> ii wireguard 0.0.20180413-1 all
> fast, modern, secure kernel VPN tunnel (metapackage)
> ii wireguard-dkms 0.0.20180413-1 all
> fast, modern, secure kernel VPN tunnel (DKMS version)
> ii wireguard-tools 0.0.20180413-1 armhf
> fast, modern, secure kernel VPN tunnel (userland utilities)
Are you using wg-quick(8)? If so, wg-quick will by default do special
things to sync up the allowed ips and the system routing table, which
includes some special case rule tricks for 0.0.0.0/0. It sounds like
you know what you're doing and don't actually want this behavior. For
this, you can simply specify Table=off in the [Interface] section.
This overrides the default value of Table=auto. Alternatively, you can
choose Table=main if you want those routes added to the default table
with no special rule tricks. Or, you can choose an arbitrary
named-table or number if you'd like to add the allowed ips to some
other routing table. The man page has info.
Jason
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Why does 'allowed-ips' affect route selection behavior?
2018-04-15 22:26 ` Jason A. Donenfeld
@ 2018-04-16 1:06 ` Patrick O'Sullivan
2018-04-16 1:13 ` Jason A. Donenfeld
2018-04-16 12:29 ` Tim Sedlmeyer
1 sibling, 1 reply; 7+ messages in thread
From: Patrick O'Sullivan @ 2018-04-16 1:06 UTC (permalink / raw)
To: Jason A. Donenfeld; +Cc: WireGuard mailing list
Hi Jason,
First off--thanks for your work on WireGuard and just wanted to
mention that your appearance on FLOSS Weekly put my over the edge to
try out WireGuard.
> You might want to loosen these up a bit. Anyway, I've pulled it out of the archives for quoting here:
You are probably right. My over-aggression came from an increasing
amount of spam that was spoofing from addresses in my domain.
> Are you using wg-quick(8)?...
Indeed. Mikma's reply pointed me in this direction for investigation.
I had perused the wg man page, but not wg-quick's. I ended up doing
exactly what you said (Table=off) and it did the trick.
I suppose I was a victim of WireGuard's simplicity. I got it up and
running so quickly that I didn't bother to dig into the individual
components more than necessary at first. I ultimately may end up
foregoing wg-quick, but either way I now understand the mechanics to
accomplish what I want.
On Sun, Apr 15, 2018 at 6:26 PM, Jason A. Donenfeld <Jason@zx2c4.com> wrote:
> Hi Patrick,
>
> I see some others on the wireguard mailing list have replied to a
> ghost email. That is, I don't have the original that they're replying
> to. Looking into it a bit further, it appears that reasonable spam
> filters -- which includes but is not limited to gmail's -- will have
> your mail immediately bounced, because of your strict dmarc entry
> ("v=DMARC1; p=reject; rua=mailto:dmarc@insaneirish.com"), since
> mailing list servers like lists.zx2c4.com tend to "remail" things. You
> might want to loosen these up a bit. Anyway, I've pulled it out of the
> archives for quoting here:
>
>> Hi Folks,
>>
>> Getting my feet wet with wireguard and enjoying the simplicity and
>> performance thus far. Nonetheless, I have a question about how the
>> normal route selection process is being affected by what's configured
>> for 'allowed-ips'.
>>
>> I set up a peer and configured 'allowed-ips' for 0.0.0.0/0, as I was
>> going to be sending multiple routes over the peer link via BGP and
>> didn't want to keep modifying it. However, even though my default
>> route was over a different interface, this seemed to result in Linux
>> trying to route default traffic over wg0 despite there not being a
>> default route pointing to wg0.
>>
>> Specifically:
>>
>> $ sudo ip route show
>> default via 10.199.199.1 dev wlan0
>> 10.111.111.0/24 dev wg0 proto kernel scope link src 10.111.111.100
>> 10.199.199.0/24 dev wlan0 proto kernel scope link src 10.199.199.131
>>
>> By this route table, traffic to e.g. 4.2.2.1 should use 10.199.199.1.
>> Packet captures were showing traffic trying to instead use wg0. Then I
>> found this:
>>
>> $ sudo ip route get 4.2.2.1
>> 4.2.2.1 dev wg0 table 51820 src 10.111.111.100
>> cache
>>
>> Can someone please explain this behavior?
>>
>> Obligatory... $ uname -rvm
>> 4.14.30-v7+ #1102 SMP Mon Mar 26 16:45:49 BST 2018 armv7l
>>
>> And... $ dpkg -l | grep wireguard
>> ii wireguard 0.0.20180413-1 all
>> fast, modern, secure kernel VPN tunnel (metapackage)
>> ii wireguard-dkms 0.0.20180413-1 all
>> fast, modern, secure kernel VPN tunnel (DKMS version)
>> ii wireguard-tools 0.0.20180413-1 armhf
>> fast, modern, secure kernel VPN tunnel (userland utilities)
>
> Are you using wg-quick(8)? If so, wg-quick will by default do special
> things to sync up the allowed ips and the system routing table, which
> includes some special case rule tricks for 0.0.0.0/0. It sounds like
> you know what you're doing and don't actually want this behavior. For
> this, you can simply specify Table=off in the [Interface] section.
> This overrides the default value of Table=auto. Alternatively, you can
> choose Table=main if you want those routes added to the default table
> with no special rule tricks. Or, you can choose an arbitrary
> named-table or number if you'd like to add the allowed ips to some
> other routing table. The man page has info.
>
> Jason
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Why does 'allowed-ips' affect route selection behavior?
2018-04-16 1:06 ` Patrick O'Sullivan
@ 2018-04-16 1:13 ` Jason A. Donenfeld
0 siblings, 0 replies; 7+ messages in thread
From: Jason A. Donenfeld @ 2018-04-16 1:13 UTC (permalink / raw)
To: Patrick O'Sullivan; +Cc: WireGuard mailing list
Hi Patrick,
> I suppose I was a victim of WireGuard's simplicity. I got it up and
> running so quickly that I didn't bother to dig into the individual
> components more than necessary at first. I ultimately may end up
> foregoing wg-quick, but either way I now understand the mechanics to
> accomplish what I want.
Since you know what you're doing, you're probably best served by
getting rid of wg-quick and doing things manually. I suspect in the
end the setup will be /simpler/ when done without wg-quick in the way.
(wg-quick itself is just a silly bash script.)
Jason
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Why does 'allowed-ips' affect route selection behavior?
2018-04-15 22:26 ` Jason A. Donenfeld
2018-04-16 1:06 ` Patrick O'Sullivan
@ 2018-04-16 12:29 ` Tim Sedlmeyer
1 sibling, 0 replies; 7+ messages in thread
From: Tim Sedlmeyer @ 2018-04-16 12:29 UTC (permalink / raw)
To: Jason A. Donenfeld; +Cc: WireGuard mailing list
On Sun, Apr 15, 2018 at 6:26 PM, Jason A. Donenfeld <Jason@zx2c4.com> wrote:
> Hi Patrick,
>
> I see some others on the wireguard mailing list have replied to a
> ghost email. That is, I don't have the original that they're replying
> to. Looking into it a bit further, it appears that reasonable spam
> filters -- which includes but is not limited to gmail's -- will have
> your mail immediately bounced, because of your strict dmarc entry
> ("v=DMARC1; p=reject; rua=mailto:dmarc@insaneirish.com"), since
> mailing list servers like lists.zx2c4.com tend to "remail" things. You
> might want to loosen these up a bit. Anyway, I've pulled it out of the
> archives for quoting here:
More recent versions of the 2.1 series of mailman have features to
wrap messages from senders using DMARC instead of just straight
remailing them to help address this issue.
>
>> Hi Folks,
>>
>> Getting my feet wet with wireguard and enjoying the simplicity and
>> performance thus far. Nonetheless, I have a question about how the
>> normal route selection process is being affected by what's configured
>> for 'allowed-ips'.
>>
>> I set up a peer and configured 'allowed-ips' for 0.0.0.0/0, as I was
>> going to be sending multiple routes over the peer link via BGP and
>> didn't want to keep modifying it. However, even though my default
>> route was over a different interface, this seemed to result in Linux
>> trying to route default traffic over wg0 despite there not being a
>> default route pointing to wg0.
>>
>> Specifically:
>>
>> $ sudo ip route show
>> default via 10.199.199.1 dev wlan0
>> 10.111.111.0/24 dev wg0 proto kernel scope link src 10.111.111.100
>> 10.199.199.0/24 dev wlan0 proto kernel scope link src 10.199.199.131
>>
>> By this route table, traffic to e.g. 4.2.2.1 should use 10.199.199.1.
>> Packet captures were showing traffic trying to instead use wg0. Then I
>> found this:
>>
>> $ sudo ip route get 4.2.2.1
>> 4.2.2.1 dev wg0 table 51820 src 10.111.111.100
>> cache
>>
>> Can someone please explain this behavior?
>>
>> Obligatory... $ uname -rvm
>> 4.14.30-v7+ #1102 SMP Mon Mar 26 16:45:49 BST 2018 armv7l
>>
>> And... $ dpkg -l | grep wireguard
>> ii wireguard 0.0.20180413-1 all
>> fast, modern, secure kernel VPN tunnel (metapackage)
>> ii wireguard-dkms 0.0.20180413-1 all
>> fast, modern, secure kernel VPN tunnel (DKMS version)
>> ii wireguard-tools 0.0.20180413-1 armhf
>> fast, modern, secure kernel VPN tunnel (userland utilities)
>
> Are you using wg-quick(8)? If so, wg-quick will by default do special
> things to sync up the allowed ips and the system routing table, which
> includes some special case rule tricks for 0.0.0.0/0. It sounds like
> you know what you're doing and don't actually want this behavior. For
> this, you can simply specify Table=off in the [Interface] section.
> This overrides the default value of Table=auto. Alternatively, you can
> choose Table=main if you want those routes added to the default table
> with no special rule tricks. Or, you can choose an arbitrary
> named-table or number if you'd like to add the allowed ips to some
> other routing table. The man page has info.
>
> Jason
> _______________________________________________
> WireGuard mailing list
> WireGuard@lists.zx2c4.com
> https://lists.zx2c4.com/mailman/listinfo/wireguard
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2018-04-16 12:14 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-04-15 18:49 Why does 'allowed-ips' affect route selection behavior? Patrick O'Sullivan
2018-04-15 18:58 ` Roman Mamedov
2018-04-15 22:26 ` Jason A. Donenfeld
2018-04-16 1:06 ` Patrick O'Sullivan
2018-04-16 1:13 ` Jason A. Donenfeld
2018-04-16 12:29 ` Tim Sedlmeyer
2018-04-15 18:58 ` mikma.wg
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).