Bug 463250

Summary:	No network connections on boot when set "auto connect with priority to Wireguard VPN" - manually re-connecting WG VPN is necessary
Product:	[Plasma] plasmashell	Reporter:	Rigoberto Leyva Salmeron <rleyvasal>
Component:	Networking in general	Assignee:	Plasma Bugs List <plasma-bugs-null>
Status:	CONFIRMED ---
Severity:	normal	CC:	jr, nate, neon-bugs-null, postix, sitter
Priority:	NOR
Version First Reported In:	5.26.4
Target Milestone:	1.0
Platform:	Other
OS:	Linux
See Also:	https://bugs.kde.org/show_bug.cgi?id=435603 https://bugs.kde.org/show_bug.cgi?id=425625 https://bugs.kde.org/show_bug.cgi?id=489739
Latest Commit:		Version Fixed/Implemented In:
Sentry Crash Report:

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