GNOME Bugzilla – Bug 787370
vpn: wrong host routes added
Last modified: 2017-09-07 11:38:39 UTC
When connecting to an OpenVPN server, NM somehow ends up crossing the streams, adding a route to the "inner" VPN gateway via LAN, and a route to the "outer" VPN server via VPN. Expected: default via 10.112.0.1 dev tun0 metric 50 [VPN] default via 192.168.1.254 dev wlan0 metric 600 [LAN] 193.219.181.253 via 192.168.1.254 dev wlan0 metric 600 [host] Actual: default via 10.112.0.1 dev tun0 metric 50 [VPN] default via 192.168.1.254 dev wlan0 metric 600 [LAN] 10.112.0.1 dev wlan0 metric 600 [???] 193.219.181.253 via 10.112.0.1 dev wlan0 metric 600 [¿¿¿] At first glance, this doesn't seem to affect OpenConnect VPNs. NetworkManager 1.9.2dev.r19.g4a5ab5f6c networkmanager-openvpn 1.2.10
Could you attach a logfile with trace logging enabled? Or, at least the part with "platform: route: get IPv4 route for:". Seems I messed https://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?id=fa7fafe8fd649b016dc4d0e736db669f21e8578f up
Created attachment 359301 [details] trace log of establishing the VPN nm3.log:283:<trace> [1504722655.1724] platform: route: get IPv4 route for: 193.219.181.253 nm3.log:290:<debug> [1504722655.1727] platform: route: get IPv4 route for: 193.219.181.253 succeeded: 193.219.181.253/32 via 10.112.0.1 dev 23 metric 0 mss 0 rt-src rt-unspec cloned scope global pref-src 10.112.0.4 That actually matches what `ip route get 193.219.181.253` shows, because the VPN indeed pushes a route for 193.219.181.192/26. Maybe the lookup should be done *before* the pushed routes are installed?
Your gateway is Data: VPN Gateway: 193.219.181.253 but at the same time, the VPN connection announces a route Data: Static Route: 193.219.181.192/26 Next Hop: 10.112.0.1 that seems odd configuration of route VPN. Anyway, NM should be able to cope with that. > Maybe the lookup should be done *before* the pushed routes are installed? There are many scenarios where NM would repeatedly apply IP configuration for the VPN (e.g. a new IP address was added from the VPN, or the parent device goes down). So, the mechanism must anyway be robust against having the routes on the VPN configured first. I think https://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?id=42edfb4a7ff2983fa081b969109f21ff4f693fe1 should fix your issue and improve the way how we determine the route. However, it's not perfect yet. Especially if you have more then one VPN (that would route each others external gateways) or when the parent device goes down and NM searches a new device where to inject the route to the external gateway. Please re-test. Thanks!! (closing BZ. Reopen if necessary)
(In reply to Thomas Haller from comment #3) > Your gateway is > Data: VPN Gateway: 193.219.181.253 > but at the same time, the VPN connection announces a route > Data: Static Route: 193.219.181.192/26 Next Hop: 10.112.0.1 > > that seems odd configuration of route VPN. > Anyway, NM should be able to cope with that. Hmm, isn't such configuration the main reason NM adds a host route in the first place? (The 193.219.181.253 address is the OpenVPN server I'm connecting to – it's _not_ a nexthop in any routes via the VPN.) I'd say it's relatively common (for example, some hosts have a public IP address and provide public services, but limit RDP access). > I think > https://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/ > ?id=42edfb4a7ff2983fa081b969109f21ff4f693fe1 should fix your issue and > improve the way how we determine the route. > However, it's not perfect yet. Especially if you have more then one VPN > (that would route each others external gateways) or when the parent device > goes down and NM searches a new device where to inject the route to the > external gateway. > > > Please re-test. Thanks!! Thanks, I'll test as soon as I get home.
(In reply to Mantas Mikulėnas (grawity) from comment #4) > (In reply to Thomas Haller from comment #3) > > Your gateway is > > Data: VPN Gateway: 193.219.181.253 > > but at the same time, the VPN connection announces a route > > Data: Static Route: 193.219.181.192/26 Next Hop: 10.112.0.1 > > > > that seems odd configuration of route VPN. > > Anyway, NM should be able to cope with that. > > Hmm, isn't such configuration the main reason NM adds a host route in the > first place? yes, NM adds the route to avoid that the external gateway is routed via the VPN itself. The mst common scenario where this would happen, is when the VPN has a (best) default-route. > (The 193.219.181.253 address is the OpenVPN server I'm connecting to – it's > _not_ a nexthop in any routes via the VPN.) > > I'd say it's relatively common (for example, some hosts have a public IP > address and provide public services, but limit RDP access). You mean, you have insecure services (RDP) on your public IP address, but restrict access to it from the internet (only allow to reach it via the VPN)? Ok, but sounds more complex to me. I would instead whitelist/filter access on public IP addresses and only allow accessing insecure services via subnets that are routed on the VPN (10.0.0.0/8). But OK, if this setup suits you: perfect. NM should support it (now again).