Wired Network Disabled on Startup when VPN Auto-Connect Enabled on Linux Mint Tessa Cinnamon

[explodingkittens]

Hey all!

I switched over to Linux Mint 17.1 Cinnamon (64-bit) from Ubuntu MATE about a month ago, and I've been having a minor papercut since installation regarding my networking.

My system is plugged in via ethernet to my home network, is configured to automatically connect to that ethernet connection on boot, and is configured to automatically connect to a VPN over that ethernet connection. Unfortunately, Mint is not automatically connecting to that ethernet connection on boot. After some investigation, I found that Mint automatically connects to the ethernet connection with no trouble if the automatic VPN connection option is disabled. However, when the automatic VPN is enabled, the computer will start with ethernet disabled completely, requiring me to manually enable ethernet. Additionally, logging out and logging back in has no effect on the network- it will neither enable nor disable ethernet. Interestingly, the ethernet connection can be enabled by disabling the automatic VPN connection option in the connection settings, which... doesn't quite seem like intended operation

Here is my inxi -Fxz output:

Code: Select all

System:
  Host: Kyurem Kernel: 4.15.0-43-generic x86_64 bits: 64 compiler: gcc 
  v: 7.3.0 Desktop: Cinnamon 4.0.8 Distro: Linux Mint 19.1 Tessa 
  base: Ubuntu 18.04 bionic 
Machine:
  Type: Desktop System: Dell product: Inspiron 3847 v: N/A serial: <filter> 
  Mobo: Dell model: 088DT1 v: A01 serial: <filter> UEFI: Dell v: A06 
  date: 01/15/2015 
CPU:
  Topology: Quad Core model: Intel Core i5-4460 bits: 64 type: MCP 
  arch: Haswell rev: 3 L2 cache: 6144 KiB 
  flags: lm nx pae sse sse2 sse3 sse4_1 sse4_2 ssse3 vmx bogomips: 25542 
  Speed: 806 MHz min/max: 800/3400 MHz Core speeds (MHz): 1: 798 2: 798 
  3: 798 4: 799 
Graphics:
  Device-1: Intel Xeon E3-1200 v3/4th Gen Core Processor Integrated Graphics 
  vendor: Dell driver: i915 v: kernel bus ID: 00:02.0 
  Display: x11 server: X.Org 1.19.6 driver: modesetting unloaded: fbdev,vesa 
  resolution: 1920x1080~60Hz 
  OpenGL: renderer: Mesa DRI Intel Haswell Desktop v: 4.5 Mesa 18.0.5 
  direct render: Yes 
Audio:
  Device-1: Intel Xeon E3-1200 v3/4th Gen Core Processor HD Audio 
  vendor: Dell driver: snd_hda_intel v: kernel bus ID: 00:03.0 
  Device-2: Intel 8 Series/C220 Series High Definition Audio vendor: Dell 
  driver: snd_hda_intel v: kernel bus ID: 00:1b.0 
  Device-3: Logitech Webcam C270 type: USB driver: snd-usb-audio,uvcvideo 
  bus ID: 3-3:2 
  Sound Server: ALSA v: k4.15.0-43-generic 
Network:
  Device-1: Realtek RTL8111/8168/8411 PCI Express Gigabit Ethernet 
  vendor: Dell driver: r8169 v: 2.3LK-NAPI port: e000 bus ID: 02:00.0 
  IF: enp2s0 state: up speed: 1000 Mbps duplex: full mac: <filter> 
  Device-2: Qualcomm Atheros QCA9565 / AR9565 Wireless Network Adapter 
  vendor: Dell driver: ath9k v: kernel port: e000 bus ID: 03:00.0 
  IF: wlp3s0 state: down mac: <filter> 
  Device-3: Atheros type: USB driver: btusb bus ID: 3-10:7 
  IF-ID-1: tun0 state: unknown speed: 10 Mbps duplex: full mac: N/A 
Drives:
  Local Storage: total: 2.27 TiB used: 34.00 GiB (1.5%) 
  ID-1: /dev/sda vendor: Seagate model: ST2000DM001-1ER164 size: 1.82 TiB 
  ID-2: /dev/sdb vendor: Samsung model: SSD 860 EVO 500GB size: 465.76 GiB 
Partition:
  ID-1: / size: 312.27 GiB used: 33.91 GiB (10.9%) fs: ext4 dev: /dev/sdb2 
Sensors:
  System Temperatures: cpu: 29.8 C mobo: 27.8 C 
  Fan Speeds (RPM): cpu: 525 mobo: 802 
Info:
  Processes: 234 Uptime: 26m Memory: 11.65 GiB used: 3.87 GiB (33.2%) 
  Init: systemd runlevel: 5 Compilers: gcc: 7.3.0 Shell: bash v: 4.4.19 
  inxi: 3.0.27

I have not experienced this issue with any of the main line members of the Ubuntu family before, which leads me to believe it may be a Cinnamon issue. Has anyone run into this problem before? Thanks!

[anotheri]

I actually have this exact issue myself and I usually have to manually "tick" the wired connection myself to get the connection going. Another thing I noticed is that if you actually just let your computer sit there for 5-10 minutes after boot up and once you enter your login password the wired connection with VPN will eventually connect by itself but it's not instant like if you "ticked" the box yourself to connect or if you didn't have the auto-VPN connection option enabled.

[Bender72]

I'm experiencing the exact same problem described by the original poster on a machine where the problem was NOT occurring with Linux Mint 20.1. It is now occurring on a fresh install with 20.2

Initially, the network wanted to start up with the VPN immediately, but asked for a keyring to be unlocked. (I use auto-login). Since the machine in question is a media center computer regularly controlled by an IR remote, entering a password at startup is not acceptable. I changed the password to an empty password. Since then, enabling VPN autostart with the physical network connection will prevent the network connection from autostarting at all.

Anyone know how to fix this? thanks

[TurboDan]

Hi Bender72,
I am having the same issue as well. If I configure the VPN to connect automatically, the wired network will be disabled when I log in. If i click the slider to enable the wired connection, it works fine.

One interesting thing I found when troubleshooting that you can try- If I quickly type in my password on the login screen when it first appears, it will usually enable and connect to the VPN just fine. If I let the computer sit on the login screen for a bit, the connection will not be enabled when I log in. Maybe something permission related with openVPN when not logged in as a user?

[TurboDan]

Hi Bender72,
I am having the same issue as well. If I configure the VPN to connect automatically, the wired network will be disabled when I log in. If i click the slider to enable the wired connection, it works fine.

One interesting thing I found when troubleshooting that you can try- If I quickly type in my password on the login screen when it first appears, it will usually enable and connect to the VPN just fine. If I let the computer sit on the login screen for a bit, the connection will not be enabled when I log in. Maybe something permission related with openVPN when not logged in as a user?

I figured out the issue. I had the option to remember the VPN password set to the default setting of remember for current user. It needed to be set to remember for all users in order to have the connection successfully establish while on the login screen. Looks like if I logged in quickly, the connection would establish since the password was available, but if I waited on the login screen it would not be able to connect. Hope this helps anyone with a similar issue.