20190702 leaking default routes
dirtycache opened this issue · comments
Hello,
It appears that this version injects a route for 0.0.0.0 with the interface netmask. It doesn't appear this route is ever used - which is good because it's more specific than 0.0.0.0/0 - but I submit it is unwanted behavior and might cause problems with routing protocol redistribution.
It seems to leak the route regardless of whether route-allowed-ips is true or false.
On an E50:
IP Route Table for VRF "default"
S *> 0.0.0.0/0 [210/0] via $ISP-EGRESS, eth0
C *> 0.0.0.0/24 is directly connected, wg1
C *> 0.0.0.0/30 is directly connected, wg3
C 0.0.0.0/30 is directly connected, wg0
C 0.0.0.0/30 is directly connected, wg2
Interface configs:
wireguard wg0 {
address 10.31.1.14/30
description "sumsite wg2"
mtu 1420
peer sumsite-pubkey {
allowed-ips 0.0.0.0/0
description sumsite
endpoint sumsite:51822
}
private-key /config/auth/e50-priv.key
route-allowed-ips false
}
wireguard wg1 {
address 10.31.3.1/24
description "remote access"
listen-port 51820
mtu 1420
peer sumdood1-pubkey {
allowed-ips 10.31.3.35/32
description "sumdood1"
}
peer summdood2-pubkey {
allowed-ips 10.31.3.34/32
description "sumdood2"
}
peer sumdood3-pubkey {
allowed-ips 10.31.3.36/32
description sumdood3
}
peer sumdood4-pubkey {
allowed-ips 10.31.3.37/32
description sumdood4
}
peer sumdood5-pubkey {
allowed-ips 10.31.3.33/32
description "sumdood5"
}
peer sumdood6-pubkey {
allowed-ips 10.31.3.37/32
description sumdood6
}
peer sumdood7-pubkey {
allowed-ips 10.31.3.33/32
description "sumdood7"
}
peer sumdood8-pubkey {
allowed-ips 10.31.3.38/32
description "sumdood8"
}
private-key /config/auth/e50-priv.key
route-allowed-ips true
}
wireguard wg2 {
address 10.31.1.17/30
description "sumsite2 wg2"
listen-port 51821
mtu 1420
peer sumsite2-pubkey {
allowed-ips 0.0.0.0/0
description sumsite2
}
private-key /config/auth/e50-priv.key
route-allowed-ips false
}
wireguard wg3 {
address 10.31.1.30/30
description "sumsite3 wg1"
mtu 1420
peer sumsite3-pubkey {
allowed-ips 0.0.0.0/0
description sumsite3
endpoint sumsite3-router:51826
}
private-key /config/auth/e50-priv.key
route-allowed-ips false
}
On a different router, this time an e200:
IP Route Table for VRF "default"
S *> 0.0.0.0/0 [1/0] via $ISP-EGRESS, eth0
S 0.0.0.0/0 [210/0] via $ISP-2-EGRESS, eth2
C *> 0.0.0.0/30 is directly connected, wg1
C 0.0.0.0/30 is directly connected, wg2
C 0.0.0.0/30 is directly connected, wg0
C *> 10.31.1.0/30 is directly connected, wg0
C *> 10.31.1.28/30 is directly connected, wg1
C *> 10.31.1.32/30 is directly connected, wg2
e200 interface configs:
wireguard wg0 {
address 10.31.1.1/30
description "sumsite wg1"
listen-port 51823
peer sumsite-pubkey {
allowed-ips 0.0.0.0/0
description sumsite
}
private-key /config/auth/e200.key
route-allowed-ips false
}
wireguard wg1 {
address 10.31.1.29/30
description "sumsite2 wg3"
listen-port 51826
peer sumsite2-pubkey {
allowed-ips 0.0.0.0/0
description sumsite2
}
private-key /config/auth/e200.key
route-allowed-ips false
}
wireguard wg2 {
address 10.31.1.33/30
description "sumsite3 wg1"
listen-port 51827
peer sumsite3-pubkey {
allowed-ips 0.0.0.0/0
description sumsite3
}
private-key /config/auth/e200.key
route-allowed-ips false
}
Worth noting is that wireguard running as part of a VyOS 1.2.2 instance doesn't exhibit the same behavior. It has routes for only the connected /30s assigned to the wgX interfaces, which is, I believe, correct.
Codes: K - kernel route, C - connected, S - static, R - RIP,
O - OSPF, I - IS-IS, B - BGP, E - EIGRP, N - NHRP,
T - Table, v - VNC, V - VNC-Direct, A - Babel, D - SHARP,
F - PBR, f - OpenFabric,
> - selected route, * - FIB route
S>* 0.0.0.0/0 [1/0] via $ISP-EGRESS, eth2, 05:09:42
S 10.31.0.0/16 [255/0] unreachable (blackhole), 01:17:44
S>* 10.31.0.0/16 [1/0] via 10.31.99.7, eth1, 05:11:50
C>* 10.31.1.36/30 is directly connected, wg1, 04:46:03
C>* 10.31.99.0/24 is directly connected, eth1, 05:12:38
C>* 10.31.116.0/24 is directly connected, eth0, 05:24:03
S>* 10.31.132.0/24 [1/0] via 10.31.1.38, wg1, 04:19:44
wireguard wg1 {
address 10.31.1.37/30
description "sumsite wg0"
peer sumsite {
allowed-ips 0.0.0.0/0
pubkey sumsite-pubkey
}
port 51828
}
Thanks!
It's not just this version, I can confirm it goes back to at least 20190123.
Also relevant, vyatta-tinc does the same thing (though I've no samples, as I've just finished tearing this down)
admin@ubnt-XXX:~$ show ip route
Codes: K - kernel, C - connected, S - static, R - RIP, B - BGP
O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
> - selected route, * - FIB route, p - stale info
IP Route Table for VRF "default"
K *> 0.0.0.0/0 [0/0] via pppoe0
C *> 0.0.0.0/24 is directly connected, wg0
B *> 10.10.1.0/24 [20/0] via 10.10.99.1, wg0, 00:38:28
C *> 10.10.2.0/24 is directly connected, switch0
C *> 10.10.99.0/24 is directly connected, wg0
C *> 127.0.0.0/8 is directly connected, lo
C *> [removed] is directly connected, pppoe0
C *> [removed] is directly connected, pppoe0
admin@ubnt-XXX:~$ dpkg -l wireguard
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
+++-===========================-==================-==================-===========================================================
||/ Name Version Architecture Description
ii wireguard 0.0.20190123-1 mipsel fast, modern, secure kernel VPN tunnel
Not sure when we first saw this behavior, it's been there as far as I can remember. There's also #95 describing the same thing.
I've seen the same thing with OpenVPN tunnels on the EdgeRouters, so I've put it down to some weird Ubiquiti thing and not bothered to investigate further. There's also people that seen the same issue with GRE tunnels.