I have wireguard connection with Table=off and some custom routes. Importing this connection and connecting to it through plasma's network manager applet kills internet connection. Connecting to very same connection through `wg-quick up wg21` works as intended. Server config: [Interface] Address = 10.21.0.1/24 Table = off SaveConfig = true ListenPort = 43283 PrivateKey = <...> Client config: [Interface] Address = 10.21.0.10/32 ListenPort = 51821 PrivateKey = <...> Table = off PostUp = ip route add 10.20.0.100 dev wg21; ip route add 10.21.0.0/24 dev wg21 PreDown = ip route del 10.20.0.100 dev wg21; ip route del 10.21.0.0/24 dev wg21 [Peer] PublicKey = <...> AllowedIPs = 0.0.0.0/0 Endpoint = (removed) OBSERVED RESULT Pinging 10.20.0.100 works as intended (it is a VM running on 10.21.0.1). Normal internet access on client machine breaks (like opening pages in firefox). EXPECTED RESULT Pinging 10.20.0.100 and browsing internet should both work. Client does not route all of it's traffic through this vpn connection. SOFTWARE/OS VERSIONS Linux/KDE Plasma: archlinux kde-unstable packages (available in About System) KDE Plasma: 5.14.90 KDE Frameworks 5.54.0 Qt 5.12.0 (built against 5.12.0) ADDITIONAL INFORMATION Route tables: No wireguard VPN connected ~ % ip route default via 10.32.60.1 dev tun0 proto static metric 50 default via 192.168.1.254 dev eno1 proto dhcp metric 20100 10.32.60.0/24 dev tun0 proto kernel scope link src 10.32.60.101 metric 50 46.19.137.115 via 192.168.1.254 dev eno1 proto static metric 100 192.168.1.0/24 dev eno1 proto kernel scope link src 192.168.1.100 metric 100 192.168.1.254 dev eno1 proto static scope link metric 100 192.168.122.0/24 dev virbr0 proto kernel scope link src 192.168.122.1 linkdown 192.168.123.0/24 dev virbr1 proto kernel scope link src 192.168.123.1 linkdown Wireguard VPN through plasma-nm (internet does not work) ~ % ip route default via 10.32.60.1 dev tun0 proto static metric 50 default via 192.168.1.254 dev eno1 proto dhcp metric 20100 10.21.0.10 dev wg21 proto kernel scope link src 10.21.0.10 metric 50 10.32.60.0/24 dev tun0 proto kernel scope link src 10.32.60.101 metric 50 46.19.137.115 via 192.168.1.254 dev eno1 proto static metric 100 192.168.1.0/24 dev eno1 proto kernel scope link src 192.168.1.100 metric 100 192.168.1.254 dev eno1 proto static scope link metric 100 192.168.122.0/24 dev virbr0 proto kernel scope link src 192.168.122.1 linkdown 192.168.123.0/24 dev virbr1 proto kernel scope link src 192.168.123.1 linkdown Wireguard VPN through wg-quick (internet works) ~ % ip route default via 10.32.60.1 dev tun0 proto static metric 50 default via 192.168.1.254 dev eno1 proto dhcp metric 20100 10.20.0.100 dev wg21 scope link 10.21.0.0/24 dev wg21 scope link 10.32.60.0/24 dev tun0 proto kernel scope link src 10.32.60.101 metric 50 46.19.137.115 via 192.168.1.254 dev eno1 proto static metric 100 192.168.1.0/24 dev eno1 proto kernel scope link src 192.168.1.100 metric 100 192.168.1.254 dev eno1 proto static scope link metric 100 192.168.122.0/24 dev virbr0 proto kernel scope link src 192.168.122.1 linkdown 192.168.123.0/24 dev virbr1 proto kernel scope link src 192.168.123.1 linkdown It is not entirely clear to me what is going on here. Even though route table says route to 10.20.0.100 is missing - i can ping it. Doing naive thing and adding that route manually does not fix internet of course. No unexpected default route is added either so i have no idea what is going on. I also verified imported connection in plasma-nm UI. All configuration options specified in imported wg21.conf are present in UI.
Eh forgot to mention i also installed networkmanager-wireguard-git r54.fc454a8-1 from aur.
(In reply to Rokas Kupstys from comment #0) > I have wireguard connection with Table=off and some custom routes. Importing > this connection and connecting to it through plasma's network manager applet > kills internet connection. Connecting to very same connection through > `wg-quick up wg21` works as intended. > Could you please try running (from the command line): nmcli connection up wg21 and see if whether it works like wg-quick or fails like the plasma applet? Thanks.
`nmcli connection up wg21` also kills internet access. Think it is issue with networkmanager-wireguard plugin?
(In reply to Rokas Kupstys from comment #3) > `nmcli connection up wg21` also kills internet access. Think it is issue > with networkmanager-wireguard plugin? Yes, I suspect it is. As an explanation why, the nm-plasma app is really just a user interface that sits on top of Network Manager (including networkmanager-wireguard) which does all the actual work of interacting with the OS networking layer. From looking at the output, I'm not sure that it is the "Table = off" itself that is the problem. I know that in NetworkManager, the "PostUp" and "PreDown" are not handled quite the same way that they are handled in wg-quick so it *may* there that the problem lies. There are a few things I can suggest you try. 1) Try adding only one of the routes and see what happens. I know this isn't what you want to do but it might give another data point for debugging. 2) If 1) works, you might be able to put both of the 'ip route add ...' commands into a shell script and put that as the PostUp command. 3) (and this is how I add extra routes although not with Table = off): look into the use of NetworkManager's dispatcher scripts. Reading the NetworkManager man page will give you details about this. Personally, I created the file /etc/NetworkManager/dispatcher.d/vpn-static-links which contains: ============================= #! /bin/bash DEVICE="$1" COMMAND="$2" if test ${COMMAND} == "vpn-up" ; then /bin/ip route add 107.16.144.70 via 192.168.1.1 dev eth0 /bin/ip route add 166.16.100.1 via 192.168.1.1 dev eth0 fi ================================== Personally I think the third method is preferable to using the WireGuard PostUp and PreDown configs because as long as you are using NetworkManager, it handles things in a common way independent of the VPN protocol used. That way if I connect through an openVPN link or through a WireGuard link it will add the two routes either way.
You are right. Removing PostUp and PreDown from wg config in network connection UI and executing them manually works. Thanks for the tip on the workaround, that will do until upstream fixes the issue.
Bulk transfer as requested in T17796