Bugzilla – Bug 1214276
openvpn applying nonsensical route / killing all network traffic
Last modified: 2024-05-09 07:38:34 UTC
On one of my machines openvpn + NetworkManager works as desired. I can import an .ovpn file from work, connect as usual: NAME="openSUSE Tumbleweed" # VERSION="20230807" plasma-nm5-openvpn-5.27.7-1.1.x86_64 Fri 04 Aug 2023 04:33:46 PM CEST openvpn-2.6.5-1.1.x86_64 Tue 20 Jun 2023 09:59:52 AM CEST NetworkManager-openvpn-1.10.2-1.3.x86_64 Mon 19 Jun 2023 11:24:56 AM CEST On the next machine, it applies a nonsensical route (default gw / wlan router IP --> 'tun' device - that just can't work): NAME="openSUSE Tumbleweed" # VERSION="20230813" NetworkManager-openvpn-lang-1.10.2-1.4.noarch Mon 14 Aug 2023 08:01:35 PM CEST NetworkManager-vpnc-lang-1.2.8-2.2.noarch Mon 14 Aug 2023 08:01:34 PM CEST NetworkManager-openvpn-1.10.2-1.4.x86_64 Mon 14 Aug 2023 07:58:47 PM CEST NetworkManager-vpnc-1.2.8-2.2.x86_64 Mon 14 Aug 2023 07:58:46 PM CEST openvpn-2.6.5-1.2.x86_64 Mon 14 Aug 2023 07:45:52 PM CEST vpnc-0.5.3r550-3.17.x86_64 Mon 14 Aug 2023 07:45:28 PM CEST plasma-nm5-openvpn-5.27.7-1.1.x86_64 Thu 03 Aug 2023 07:02:24 PM CEST plasma-nm5-vpnc-5.27.7-1.1.x86_64 Thu 03 Aug 2023 07:02:23 PM CEST yast2-vpn-4.6.1-1.1.noarch Thu 11 May 2023 07:32:16 PM CEST As you can see, I got some updates on the 14th. I assume they are the culprit.
Closing... It seems someone on the other side has just fixed the problem right before I switched to the other machine. The VPN server seems to have pushed the bad route.
Reopening... So far I've discovered: * If I use an IPv4 address as VPN gateway, it works all the time. * If I use an IPv6 address, the routes are always wrong. The VPN server I connect to has 3 IPv4 and 3 IPv6 addresses. Now the question is, whether the problem is on my side, or on the server side. IPv4 VPN GW: ============ default via XXX dev tun0 proto static metric 50 default via 192.168.2.1 dev wlp1s0 proto static metric 600 ... 192.168.2.1 dev wlp1s0 proto static scope link metric 50 ... IPv6 VPN GW: ============ default via XXX dev tun0 proto static metric 50 default via 192.168.2.1 dev wlp1s0 proto static metric 600 ... 192.168.2.1 dev >>>TUN0<<< proto static scope link metric 50 ...
I've created a ticket with our IT department, hoping they can tell me if they push different routes depending on IPv4 / IPv6. Now we wait ;-)
I've had a discussion with the guys running the eduvpn /openvpn server(s), sent a few logfiles back and forth... inconclusive. According to them, they don't do anything differently whether someone connects to their IPv4 or IPv6 instances. Also it seems I'm the only one complaining so far, so the problem might be with my system / os. But I guess the number of linux clients is rather limited, more Ubuntu than SuSE. I've closed the ticket with them. If I can send you a few logfiles, just let me know what you'd like to get. For now I'm happy with just connecting directly to the VPN gateway using an explicict IPv4 address and not its DNS name.
Thanks for the report, rebert. It'll be great to have some detailed NetworkManager logs. To collect those, add the following content to /etc/NetworkManager/conf.d/NetworkManager.conf, restart NetworkManager, reproduce this issue and attach the output of `journalctl -b` here. > [logging] > level=trace
Closing this due to lack of further information. If this is still an issue, feel free to reopen with verbose NetworkManager logs as requested in comment#5.