VPN weirdness

Does anyone know the significance of a small exclamation point by the network icon for Network Manager in the KDE system tray?

Here’s the thing: when I first boot up Tumbleweed KDE, the network manager icon appears with an exclamation point next to it. Everything about the network seems to work fine, except VPN. I can ask Network Manager to connect one of the VPN servers I have access to, and although it says it’s connected, when I open a browser it indicates that I am still in Scottsdale, rather than in, say, Paris if I think I’m connected to a french server. In addition, if I use a VPN kill script which limits traffic to tun0, nothing gets through.

However, at this point I can disconnect my primary network connection (wired), and then reconnect. After doing so, the Network Manager icon comes up with no exclamation point and VPN connections then work normally, passing through the tun0 device and then locating me where the VPN server resides.

I suspect the exclamation point is telling me that something is wrong but I don’t know how to find out what. There are no error messages in boot.log and nothing unusual in dmesg.

Any thoughts?

You can follow the connection process using something like

sudo journalctl -fu NetworkManager

Attempt to connect to the VPN

Compare the following output from the first time you are connected and the second…

ip a
ip r

Here’s the outputs just after startup, before attempting to switch to VPN:

**#** journalctl -fu NetworkManager
-- Logs begin at Thu 2018-08-23 11:05:03 MST. --
Aug 23 11:05:21 linux-8chy NetworkManager[970]: <info>  [1535047521.7785] policy: set 'Home' (enp4s0) as default for IPv4 routing and DNS
Aug 23 11:05:21 linux-8chy NetworkManager[970]: <info>  [1535047521.9651] device (enp4s0): Activation: successful, device activated.
Aug 23 11:05:21 linux-8chy NetworkManager[970]: <info>  [1535047521.9660] manager: startup complete
Aug 23 11:05:39 linux-8chy NetworkManager[970]: <info>  [1535047539.4562] device (vmnet1): driver '(null)' does not support carrier detection.
Aug 23 11:05:39 linux-8chy NetworkManager[970]: <info>  [1535047539.4566] device (vmnet1): driver 'unknown' does not support carrier detection.
Aug 23 11:05:39 linux-8chy NetworkManager[970]: <info>  [1535047539.4574] manager: (vmnet1): new Ethernet device (/org/freedesktop/NetworkManager/Devices/3)
Aug 23 11:05:40 linux-8chy NetworkManager[970]: <info>  [1535047540.1868] device (vmnet8): driver '(null)' does not support carrier detection.
Aug 23 11:05:40 linux-8chy NetworkManager[970]: <info>  [1535047540.1872] device (vmnet8): driver 'unknown' does not support carrier detection.
Aug 23 11:05:40 linux-8chy NetworkManager[970]: <info>  [1535047540.1886] manager: (vmnet8): new Ethernet device (/org/freedesktop/NetworkManager/Devices/4)
Aug 23 11:06:39 linux-8chy NetworkManager[970]: <info>  [1535047599.7442] manager: NetworkManager state is now CONNECTED_GLOBAL

 ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host  
       valid_lft forever preferred_lft forever
2: enp4s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether bc:5f:f4:3a:8f:a2 brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.127/24 brd 192.168.1.255 scope global dynamic enp4s0
       valid_lft 86308sec preferred_lft 86308sec
    inet6 fe80::1994:faec:2088:8a3c/64 scope link noprefixroute  
       valid_lft forever preferred_lft forever
3: vmnet1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN group default qlen 1000
    link/ether 00:50:56:c0:00:01 brd ff:ff:ff:ff:ff:ff
    inet 172.16.106.1/24 brd 172.16.106.255 scope global vmnet1
       valid_lft forever preferred_lft forever
    inet6 fe80::250:56ff:fec0:1/64 scope link  
       valid_lft forever preferred_lft forever
4: vmnet8: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN group default qlen 1000
    link/ether 00:50:56:c0:00:08 brd ff:ff:ff:ff:ff:ff
    inet 192.168.225.1/24 brd 192.168.225.255 scope global vmnet8
       valid_lft forever preferred_lft forever
    inet6 fe80::250:56ff:fec0:8/64 scope link  
       valid_lft forever preferred_lft forever
**#** ip r
default via 192.168.1.1 dev enp4s0 proto dhcp  
default via 192.168.1.1 dev enp4s0 proto dhcp metric 100  
172.16.106.0/24 dev vmnet1 proto kernel scope link src 172.16.106.1  
192.168.1.0/24 dev enp4s0 proto kernel scope link src 192.168.1.127  
192.168.1.0/24 dev enp4s0 proto kernel scope link src 192.168.1.127 metric 100  
192.168.225.0/24 dev vmnet8 proto kernel scope link src 192.168.225.1

Here’s after trying to connect to a VPN (traffic is blocked with ipfilters set to allow only tun0 traffic):

**#** journalctl -fu NetworkManager
-- Logs begin at Thu 2018-08-23 11:05:03 MST. --
Aug 23 11:11:07 linux-8chy NetworkManager[970]: <info>  [1535047867.9593] keyfile: add connection in-memory (409d01a4-c5b5-4bb6-be40-0f4f51c49936,"tun0")
Aug 23 11:11:07 linux-8chy NetworkManager[970]: <info>  [1535047867.9601] device (tun0): state change: unavailable -> disconnected (reason 'connection-assumed', sys-ifa
ce-state: 'external')
Aug 23 11:11:07 linux-8chy NetworkManager[970]: <info>  [1535047867.9615] device (tun0): Activation: starting connection 'tun0' (409d01a4-c5b5-4bb6-be40-0f4f51c49936)
Aug 23 11:11:07 linux-8chy NetworkManager[970]: <info>  [1535047867.9711] device (tun0): state change: disconnected -> prepare (reason 'none', sys-iface-state: 'externa
l')
Aug 23 11:11:07 linux-8chy NetworkManager[970]: <info>  [1535047867.9716] device (tun0): state change: prepare -> config (reason 'none', sys-iface-state: 'external')
Aug 23 11:11:07 linux-8chy NetworkManager[970]: <info>  [1535047867.9719] device (tun0): state change: config -> ip-config (reason 'none', sys-iface-state: 'external')
Aug 23 11:11:07 linux-8chy NetworkManager[970]: <info>  [1535047867.9720] device (tun0): state change: ip-config -> ip-check (reason 'none', sys-iface-state: 'external'
)
Aug 23 11:11:07 linux-8chy NetworkManager[970]: <info>  [1535047867.9726] device (tun0): state change: ip-check -> secondaries (reason 'none', sys-iface-state: 'externa
l')
Aug 23 11:11:07 linux-8chy NetworkManager[970]: <info>  [1535047867.9727] device (tun0): state change: secondaries -> activated (reason 'none', sys-iface-state: 'extern
al')
Aug 23 11:11:08 linux-8chy NetworkManager[970]: <info>  [1535047868.2168] device (tun0): Activation: successful, device activated.

**#** ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host  
       valid_lft forever preferred_lft forever
2: enp4s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether bc:5f:f4:3a:8f:a2 brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.127/24 brd 192.168.1.255 scope global dynamic enp4s0
       valid_lft 86037sec preferred_lft 86037sec
    inet6 fe80::1994:faec:2088:8a3c/64 scope link noprefixroute  
       valid_lft forever preferred_lft forever
3: vmnet1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN group default qlen 1000
    link/ether 00:50:56:c0:00:01 brd ff:ff:ff:ff:ff:ff
    inet 172.16.106.1/24 brd 172.16.106.255 scope global vmnet1
       valid_lft forever preferred_lft forever
    inet6 fe80::250:56ff:fec0:1/64 scope link  
       valid_lft forever preferred_lft forever
4: vmnet8: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN group default qlen 1000
    link/ether 00:50:56:c0:00:08 brd ff:ff:ff:ff:ff:ff
    inet 192.168.225.1/24 brd 192.168.225.255 scope global vmnet8
       valid_lft forever preferred_lft forever
    inet6 fe80::250:56ff:fec0:8/64 scope link  
       valid_lft forever preferred_lft forever
5: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN group default qlen 100
    link/none  
    inet 10.65.10.6 peer 10.65.10.5/32 brd 10.65.10.6 scope global noprefixroute tun0
       valid_lft forever preferred_lft forever
    inet6 fe80::a295:baf4:d7b7:8ec8/64 scope link stable-privacy  
       valid_lft forever preferred_lft forever

**#** ip r
default via 192.168.1.1 dev enp4s0 proto dhcp  
default via 10.65.10.5 dev tun0 proto static metric 50  
default via 192.168.1.1 dev enp4s0 proto dhcp metric 100  
10.65.10.1 via 10.65.10.5 dev tun0 proto static metric 50  
10.65.10.5 dev tun0 proto kernel scope link src 10.65.10.6 metric 50  
172.16.106.0/24 dev vmnet1 proto kernel scope link src 172.16.106.1  
192.168.1.0/24 dev enp4s0 proto kernel scope link src 192.168.1.127  
192.168.1.0/24 dev enp4s0 proto kernel scope link src 192.168.1.127 metric 100  
192.168.1.1 dev enp4s0 proto static scope link metric 100  
192.168.225.0/24 dev vmnet8 proto kernel scope link src 192.168.225.1  
194.187.249.37 via 192.168.1.1 dev enp4s0 proto static metric 100

Here’s the output after enp4s0 is disconnected and reconnected:

**#** journalctl -fu NetworkManager
-- Logs begin at Thu 2018-08-23 11:05:03 MST. --
Aug 23 11:13:51 linux-8chy NetworkManager[970]: <info>  [1535048031.4519] dhcp4 (enp4s0):   nameserver '192.168.1.1'
Aug 23 11:13:51 linux-8chy NetworkManager[970]: <info>  [1535048031.4519] dhcp4 (enp4s0): state changed unknown -> bound
Aug 23 11:13:51 linux-8chy NetworkManager[970]: <info>  [1535048031.4541] device (enp4s0): state change: ip-config -> ip-check (reason 'none', sys-iface-state: 'managed
')
Aug 23 11:13:51 linux-8chy NetworkManager[970]: <info>  [1535048031.4550] device (enp4s0): state change: ip-check -> secondaries (reason 'none', sys-iface-state: 'manag
ed')
Aug 23 11:13:51 linux-8chy NetworkManager[970]: <info>  [1535048031.4552] device (enp4s0): state change: secondaries -> activated (reason 'none', sys-iface-state: 'mana
ged')
Aug 23 11:13:51 linux-8chy NetworkManager[970]: <info>  [1535048031.4554] manager: NetworkManager state is now CONNECTED_LOCAL
Aug 23 11:13:51 linux-8chy NetworkManager[970]: <info>  [1535048031.5050] manager: NetworkManager state is now CONNECTED_SITE
Aug 23 11:13:51 linux-8chy NetworkManager[970]: <info>  [1535048031.5051] policy: set 'Home' (enp4s0) as default for IPv4 routing and DNS
Aug 23 11:13:51 linux-8chy NetworkManager[970]: <info>  [1535048031.7155] device (enp4s0): Activation: successful, device activated.
Aug 23 11:13:52 linux-8chy NetworkManager[970]: <info>  [1535048032.1028] manager: NetworkManager state is now CONNECTED_GLOBAL

**#** ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host  
       valid_lft forever preferred_lft forever
2: enp4s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether bc:5f:f4:3a:8f:a2 brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.127/24 brd 192.168.1.255 scope global dynamic noprefixroute enp4s0
       valid_lft 86388sec preferred_lft 86388sec
    inet6 fe80::1994:faec:2088:8a3c/64 scope link noprefixroute  
       valid_lft forever preferred_lft forever
3: vmnet1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN group default qlen 1000
    link/ether 00:50:56:c0:00:01 brd ff:ff:ff:ff:ff:ff
    inet 172.16.106.1/24 brd 172.16.106.255 scope global vmnet1
       valid_lft forever preferred_lft forever
    inet6 fe80::250:56ff:fec0:1/64 scope link  
       valid_lft forever preferred_lft forever
4: vmnet8: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN group default qlen 1000
    link/ether 00:50:56:c0:00:08 brd ff:ff:ff:ff:ff:ff
    inet 192.168.225.1/24 brd 192.168.225.255 scope global vmnet8
       valid_lft forever preferred_lft forever
    inet6 fe80::250:56ff:fec0:8/64 scope link  
       valid_lft forever preferred_lft forever

**#** ip r
default via 192.168.1.1 dev enp4s0 proto dhcp metric 100  
172.16.106.0/24 dev vmnet1 proto kernel scope link src 172.16.106.1  
192.168.1.0/24 dev enp4s0 proto kernel scope link src 192.168.1.127 metric 100  
192.168.225.0/24 dev vmnet8 proto kernel scope link src 192.168.225.1

And lastly, after reconnecting to VPN, now behaving properly with ipfilter:

**#** journalctl -fu NetworkManager
-- Logs begin at Thu 2018-08-23 11:05:03 MST. --
Aug 23 11:16:09 linux-8chy NetworkManager[970]: <info>  [1535048169.1722] keyfile: add connection in-memory (d14fd212-95ef-4b82-9958-65eded28f310,"tun0")
Aug 23 11:16:09 linux-8chy NetworkManager[970]: <info>  [1535048169.1729] device (tun0): state change: unavailable -> disconnected (reason 'connection-assumed', sys-ifa
ce-state: 'external')
Aug 23 11:16:09 linux-8chy NetworkManager[970]: <info>  [1535048169.1745] device (tun0): Activation: starting connection 'tun0' (d14fd212-95ef-4b82-9958-65eded28f310)
Aug 23 11:16:09 linux-8chy NetworkManager[970]: <info>  [1535048169.1847] device (tun0): state change: disconnected -> prepare (reason 'none', sys-iface-state: 'externa
l')
Aug 23 11:16:09 linux-8chy NetworkManager[970]: <info>  [1535048169.1854] device (tun0): state change: prepare -> config (reason 'none', sys-iface-state: 'external')
Aug 23 11:16:09 linux-8chy NetworkManager[970]: <info>  [1535048169.1862] device (tun0): state change: config -> ip-config (reason 'none', sys-iface-state: 'external')
Aug 23 11:16:09 linux-8chy NetworkManager[970]: <info>  [1535048169.1863] device (tun0): state change: ip-config -> ip-check (reason 'none', sys-iface-state: 'external'
)
Aug 23 11:16:09 linux-8chy NetworkManager[970]: <info>  [1535048169.1867] device (tun0): state change: ip-check -> secondaries (reason 'none', sys-iface-state: 'externa
l')
Aug 23 11:16:09 linux-8chy NetworkManager[970]: <info>  [1535048169.1869] device (tun0): state change: secondaries -> activated (reason 'none', sys-iface-state: 'extern
al')
Aug 23 11:16:09 linux-8chy NetworkManager[970]: <info>  [1535048169.4327] device (tun0): Activation: successful, device activated.

**#** ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host  
       valid_lft forever preferred_lft forever
2: enp4s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether bc:5f:f4:3a:8f:a2 brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.127/24 brd 192.168.1.255 scope global dynamic noprefixroute enp4s0
       valid_lft 86243sec preferred_lft 86243sec
    inet6 fe80::1994:faec:2088:8a3c/64 scope link noprefixroute  
       valid_lft forever preferred_lft forever
3: vmnet1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN group default qlen 1000
    link/ether 00:50:56:c0:00:01 brd ff:ff:ff:ff:ff:ff
    inet 172.16.106.1/24 brd 172.16.106.255 scope global vmnet1
       valid_lft forever preferred_lft forever
    inet6 fe80::250:56ff:fec0:1/64 scope link  
       valid_lft forever preferred_lft forever
4: vmnet8: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN group default qlen 1000
    link/ether 00:50:56:c0:00:08 brd ff:ff:ff:ff:ff:ff
    inet 192.168.225.1/24 brd 192.168.225.255 scope global vmnet8
       valid_lft forever preferred_lft forever
    inet6 fe80::250:56ff:fec0:8/64 scope link  
       valid_lft forever preferred_lft forever
6: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN group default qlen 100
    link/none  
    inet 10.66.10.6 peer 10.66.10.5/32 brd 10.66.10.6 scope global noprefixroute tun0
       valid_lft forever preferred_lft forever
    inet6 fe80::3bbc:710c:2ed8:af9a/64 scope link stable-privacy  
       valid_lft forever preferred_lft forever

**#** ip r
default via 10.66.10.5 dev tun0 proto static metric 50  
default via 192.168.1.1 dev enp4s0 proto dhcp metric 100  
10.66.10.1 via 10.66.10.5 dev tun0 proto static metric 50  
10.66.10.5 dev tun0 proto kernel scope link src 10.66.10.6 metric 50  
172.16.106.0/24 dev vmnet1 proto kernel scope link src 172.16.106.1  
192.168.1.0/24 dev enp4s0 proto kernel scope link src 192.168.1.127 metric 100  
192.168.1.1 dev enp4s0 proto static scope link metric 100  
192.168.225.0/24 dev vmnet8 proto kernel scope link src 192.168.225.1  
194.187.249.37 via 192.168.1.1 dev enp4s0 proto static metric 100

I don’t see anything obvious, but I also don’t know what to look for.

The only difference that I can see is the additional routes (without explicit metric values) with the first ‘non-working’ VPN connection…

default via 192.168.1.1 dev enp4s0 proto dhcp
192.168.1.0/24 dev enp4s0 proto kernel scope link src 192.168.1.127

This likely means that internet traffic will be routed via the enp4s0 interface…

default via 192.168.1.1 dev enp4s0 proto dhcp  
default via 10.65.10.5 dev tun0 proto static metric 50  
default via 192.168.1.1 dev enp4s0 proto dhcp metric 100

and is consistent with your opening post statement, while with the working VPN connection, the following ensures traffic goes over the tun0 interface

default via 10.66.10.5 dev tun0 proto static metric 50  
default via 192.168.1.1 dev enp4s0 proto dhcp metric 100

Are you using a custom VPN script, or is this completely managed by NetworkManager? VPN provider?

I am using Private Internet Access as VPN provider. It connects through openvpn managed by NetworkManager.

If I were to hazard a guess,
You have your VPN service to start, and perhaps even connect on boot but that won’t work unless you also set Network Manager to also set up your network connection on boot.

By default,
Network Manager doesn’t set up your network connection until the User logs on (and then applies network connection profiles specific to that User).

So, since a VPN can’t be set up until after there is a working network connection, you have a problem.

And, naturally,
If you initiate a VPN connection manually later, you will already have a working network connection no matter how it’s configured to start, so there is no problem.

Just make sure that the timing for your basic network connection and your VPN service is set up properly, and you shouldn’t have any problems.

TSU

That would not be the case. My system boots up initially to the normal enp4s0 connection. If I want VPN (which is sometimes, not always), I then go to the NetworkManager icon and select the VPN connection that I want.

So, up through boot to desktop, nothing out of the ordinary “network-wise” happens. The initial “journalctr” and “ip a” and “ip r” readouts should confirm this. “tun0” does not appear until after my first attempt to connect through the VPN.

It’s not that your enp4s0 connection is working by the time you log into your machine,
It’s <when> it’s set up.
If your system is configured to use Network Manger,
You need to modify your network connection (check the box) that enables the connection to be set up on boot, otherwise the network connection is set up much, much later when you login.
Or,
Maybe you can configure your VPN connection to not be set up automatically, only start it manually.

TSU

Well, as it turns out with most of the questions I bring to this forum, the problem ended up being “user error”.

The NetworkManager icon was appearing in the system tray, presumably indicating that NetworkManager was controlling the connections and not wicked service (most likely because I was configured to use NetworkManager from previous installations). However, I went to “Network settings” in yast and this indicated that Wicked service was managing the network. After changing this to “NetworkManager” and rebooting, everything works normally.

So apparently enp4s0 was being set up initially by Wicked service, and it was not until I disconnected and then reconnected that enp4s0 was then managed by NetworkManager.

I guess the moral of this story, for me at least, is that configurations can be carried over from one installation to the next if one uses the same “home” partition. It can be easy to forget to go through the proper setup after a reinstall.

Thanks for the update. That scenario does explain why the additional routes were in place the first time you tried to activate the VPN, and ‘cleaned up’ by the time the second attempt is made. Anyway, good to know you’ve managed to find the underlying issue and resolve it.