GNOME Bugzilla – Bug 785667
Doesn't create IPv6 host route to remote VPN gateway if another IPv4-only connection is active
Last modified: 2020-11-12 14:27:17 UTC
Conditions that will reproduce this bug with 100% reliability on a fully updated Fedora 26: 1) An active IPv4-only connnection (in my case, a cabled Ethernet) 2) An active dual-stack connection (in my case, LTE WWAN) 3) A dual-stacked VPN server, configured in NM using a host-name 4) A pushed route that encompasses the IPv6 address of the VPN server In this case, NM will connect fine to the VPN (using IPv6 over the WWAN connection), negotiate all the parameters and receive all the pushed routes. However it will *not* install a host route to the IPv6 address of the VPN server through the WWAN connection. If, as is the case for me, the VPN server pushes a route that encompasses the VPN server address, we end up in a catch-22 - the packets carrying the encrypted VPN payload will be routed into the VPN tunnel device, instead of out the WWAN interface. That won't work, of course, so we end up blackholing traffic. If however I disable the cabled Ethernet connection before bringing up the VPN connection, the host route to the VPN server *is* installed, and everything works just fine. I will be happy to provide debug logs, but since this is the corporate VPN I would like to not have them in the public bugzilla. Whoever wants to look at it, feel free to look me up on IRC (tore_) and I'll provide a link. Tore
This bug is also reproducible if you have a dual-stack interface. As in my case, the interface has both IPv4 and IPv6 addresses and my OpenVPN server also is dual-stacked. The OS prefers IPv6 connection to the server. There is no route to the server added to v6 routes. IPv4 route to host is added.
does this also happen with NM 1.10?
Yes. I observed this with NM 1.10.0-1 package from Arch.
Having the exact same issue on Ubuntu 18.04. Quite annoying :) Would be nice to get this fixed!
Enabled debugging and checked the logs while connecting. Seems like the route is requested, but never added: NetworkManager[1031]: <debug> [1521794922.6687] platform: signal: route 6 added: 2a00:x:x::3/128 via fe80::230:48ff:fedc:5067 dev 2 metric 100 mss 0 rt-src rt-ra src ::/128 pref-src 2a02:x:x:x:x:x:x:5fc6 NetworkManager[1031]: <debug> [1521794922.6687] device[0x55566c34c4e0] (enxa44cc890f4c8): queued IP6 config change NetworkManager[1031]: <warn> [1521794922.6688] platform: route: get IPv6 route for: 2a00:x:x::3 failed with unspecified 2a00:x:x::3 => VPN Server IPv6 So it seems like something wents wrong there :)
(In reply to jean-louis from comment #5) > Enabled debugging and checked the logs while connecting. > Seems like the route is requested, but never added: > > NetworkManager[1031]: <debug> [1521794922.6687] platform: signal: route 6 > added: 2a00:x:x::3/128 via fe80::230:48ff:fedc:5067 dev 2 metric 100 mss 0 > rt-src rt-ra src ::/128 pref-src 2a02:x:x:x:x:x:x:5fc6 > NetworkManager[1031]: <debug> [1521794922.6687] device[0x55566c34c4e0] > (enxa44cc890f4c8): queued IP6 config change > NetworkManager[1031]: <warn> [1521794922.6688] platform: route: get IPv6 > route for: 2a00:x:x::3 failed with unspecified I think this was fixed by commit: https://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?id=2d1fad641b950520bec1a87c450d0e3b1439e262
I can confirm that patch fixes it for me!
bugzilla.gnome.org is being shut down in favor of a GitLab instance. We are closing all old bug reports and feature requests in GNOME Bugzilla which have not seen updates for a long time. If you still use NetworkManager and if you still see this bug / want this feature in a recent and supported version of NetworkManager, then please feel free to report it at https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/ Thank you for creating this report and we are sorry it could not be implemented (workforce and time is unfortunately limited).