Bug 463250 - No network connections on boot when set "auto connect with priority to Wireguard VPN" - manually re-connecting WG VPN is necessary
Summary: No network connections on boot when set "auto connect with priority to Wiregu...
Status: CONFIRMED
Alias: None
Product: plasmashell
Classification: Plasma
Component: Networking in general (show other bugs)
Version: master
Platform: Other Linux
: NOR normal
Target Milestone: 1.0
Assignee: Plasma Bugs List
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2022-12-19 23:28 UTC by Rigoberto Leyva Salmeron
Modified: 2024-12-23 18:23 UTC (History)
4 users (show)

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Rigoberto Leyva Salmeron 2022-12-19 23:28:28 UTC
SUMMARY:
Network Manager does not connect automatically on boot to Wireguard VPN Server using a Profile file. I would like to have my computer automatically connect to Wireguard VPN server on boot every time. 

When booting/re-booting  with default value for "Connect automatically with priority", network connection is lost.

Tried different settings for "Connect automatically with priority" [-15, -1, 0, 10] but same issue happens.

After Disconnect from VPN, and Connect VPN again,  network access works and successfully connects to Wireguard VPN. 


STEPS TO REPRODUCE
1. On Network Manager import a Wireguard VPN profile file.
2. Click on newly created VPN profile and choose "General Configuration" tab 
3. Click checkbox "Connect automatically with priority"
4. Reboot 

OBSERVED RESULT
After Click checkbox "Connect automatically with priority" and reboot, the computer boots without network access. VPN has to be Disconnected and reconnected to gain network acccess.

EXPECTED RESULT
After Click checkbox "Connect automatically with priority" and reboot, the computer automatically connects to selected 
 VPN profile on boot.

SOFTWARE/OS VERSIONS
Windows: 
macOS: 
Linux/KDE Plasma:  KDE NEON 
(available in About System)
KDE Plasma Version: 5.26.4
KDE Frameworks Version: 5.101.0
Qt Version: 5.15.7
ADDITIONAL INFORMATION
Comment 1 postix 2023-11-06 11:56:06 UTC
I can fully reproduce this on

Operating System: Fedora Linux 38
KDE Plasma Version: 5.27.8
KDE Frameworks Version: 5.110.0
Qt Version: 5.15.11
Kernel Version: 6.5.9-200.fc38.x86_64 (64-bit)
Comment 2 postix 2023-11-06 12:03:44 UTC
Directly after booting and logging in, `ip addr` actually shows that the system intended to connect to WG over wlp3s0, as the interface is listed and everything looks like it should. However, there has not been any handshake and I cannot connect to any but my own IP addresses of this machine. 

```
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 noprefixroute 
       valid_lft forever preferred_lft forever
4: wlp3s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether <MAC> brd ff:ff:ff:ff:ff:ff
    inet 192.168.120.30/24 brd 192.168.100.255 scope global dynamic noprefixroute wlp3s0
       valid_lft 7112sec preferred_lft 7112sec
    inet6 fe80::<snip>/64 scope link noprefixroute 
       valid_lft forever preferred_lft forever
5: WireGuard: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1420 qdisc noqueue state UNKNOWN group default qlen 1000
    link/none 
    inet 10.10.20.30/32 scope global noprefixroute WireGuard
       valid_lft forever preferred_lft forever
```
Comment 3 postix 2023-11-08 10:08:56 UTC
This is actually a two-fold issue:
1) if you in principle always use a corporate vpn, you'd need to re-connect manually on every boot
2) if you use a vpn to circumvent untrusted networks by default, it requires you to shortly run your connections over the untrusted network until you re-connect to the vpn.
Comment 4 Ben Cooksley 2024-12-23 18:23:48 UTC
Bulk transfer as requested in T17796