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