Bug 1214276

Summary:	openvpn applying nonsensical route / killing all network traffic
Product:	[openSUSE] openSUSE Tumbleweed	Reporter:	robert spitzenpfeil <rs.opensuse>
Component:	Network	Assignee:	Jonathan Kang <songchuan.kang>
Status:	RESOLVED NORESPONSE	QA Contact:	E-mail List <qa-bugs>
Severity:	Normal
Priority:	P5 - None	CC:	rs.opensuse
Version:	Current	Flags:	songchuan.kang: needinfo? (rs.opensuse)
Target Milestone:	---
Hardware:	x86-64
OS:	openSUSE Tumbleweed
Whiteboard:
Found By:	---	Services Priority:
Business Priority:		Blocker:	---
Marketing QA Status:	---	IT Deployment:	---

Description robert spitzenpfeil 2023-08-14 22:17:47 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.

Comment 1 robert spitzenpfeil 2023-08-14 22:22:10 UTC

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.

Comment 2 robert spitzenpfeil 2023-08-14 23:48:02 UTC

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 
...

Comment 3 robert spitzenpfeil 2023-08-15 00:05:10 UTC

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 ;-)

Comment 4 robert spitzenpfeil 2023-08-18 16:43:20 UTC

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.

Comment 5 Jonathan Kang 2023-09-04 07:00:49 UTC

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

Comment 6 Jonathan Kang 2024-05-09 07:38:34 UTC

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.