20190702 leaking default routes

[dirtycache]

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!

[gutoandreollo]

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

[Lochnair]

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.