| Summary: | Wireguard connection with Table=off kills internet | ||
|---|---|---|---|
| Product: | [Plasma] plasmashell | Reporter: | Rokas Kupstys <rokupstys> |
| Component: | Networking in general | Assignee: | Jan Grulich <jgrulich> |
| Status: | RESOLVED UPSTREAM | ||
| Severity: | normal | CC: | bcom, jgrulich |
| Priority: | NOR | ||
| Version First Reported In: | master | ||
| Target Milestone: | 1.0 | ||
| Platform: | Other | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed/Implemented In: | ||
| Sentry Crash Report: | |||
|
Description
Rokas Kupstys
2019-01-18 08:57:32 UTC
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 |