Starting wireguard configuration via systemd does nothing

English Network/Internet
1

Hello there,
So for some reason after reinstalling Tumbleweed on a laptop now I am not able to use my wireguard configurations. I have wireguard-tools installed and I have copied my config files to /etc/wireguard/, however when I run sudo systemctl start wg-quick@DE-FRA-440.service nothing happens after I put in my password, unlike before where it would start the VPN connection and the padlock icon showing in the NetworkManager applet. The VPN does however work if I run sudo wg-quick up DE-FRA-440, but I do not want to have to do that every time, I would rather use systemd as I prefer to do it that way.

Here’s what I get if I try to run sudo systemctl status wg-quick@DE-FRA-440.service:

Screenshot_2026-03-06_19-09-08
Screenshot_2026-03-06_19-09-081333×523 225 KB

If there really is no fix for this I suppose I will have to resort to wg-quick up but I hope you guys can help me fix this as it does work on all other machines I have Tumbleweed installed so I don’t understand why this isn’t working here.

Many thanks.

2

P.s. I wish to do it via systemd as it is better that way as it allows me to enable the service automatically at boot without having to issue a command every time the machine boots.

3

I can only offer general advice here, but please start by shewing us the unit configuration…
systemctl cat wg-quick@.service

Maybe also

sudo systemctl status wg-quick@DE-FRA-440.service
sudo journalctl -eu wg-quick@DE-FRA-440.service --no-pager

Please post this as preformatted text output rather than via screen shots if possible.

4 
~$ systemctl cat wg-quick@.service
# /usr/lib/systemd/system/wg-quick@.service
[Unit]
Description=WireGuard via wg-quick(8) for %I
After=network-online.target nss-lookup.target
Wants=network-online.target nss-lookup.target
PartOf=wg-quick.target
Documentation=man:wg-quick(8)
Documentation=man:wg(8)
Documentation=https://www.wireguard.com/
Documentation=https://www.wireguard.com/quickstart/
Documentation=https://git.zx2c4.com/wireguard-tools/about/src/man/wg-quick.8
Documentation=https://git.zx2c4.com/wireguard-tools/about/src/man/wg.8

[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/usr/bin/wg-quick up %i
ExecStop=/usr/bin/wg-quick down %i
ExecReload=/bin/bash -c 'exec /usr/bin/wg syncconf %i <(exec /usr/bin/wg-quick strip %i)'
Environment=WG_ENDPOINT_RESOLUTION_RETRIES=infinity

[Install]
WantedBy=multi-user.target

~$ sudo systemctl status wg-quick@DE-FRA-440.service
[sudo] password for root: 
× wg-quick@DE-FRA-440.service - WireGuard via wg-quick(8) for DE/FRA/440
     Loaded: loaded (/usr/lib/systemd/system/wg-quick@.service; enabled; preset: disabled)
     Active: failed (Result: exit-code) since Fri 2026-03-06 23:04:54 GMT; 4min 34s ago
 Invocation: 51ed9e571e81436a9352aaa2566946ed
       Docs: man:wg-quick(8)
             man:wg(8)
             https://www.wireguard.com/
             https://www.wireguard.com/quickstart/
             https://git.zx2c4.com/wireguard-tools/about/src/man/wg-quick.8
             https://git.zx2c4.com/wireguard-tools/about/src/man/wg.8
    Process: 1505 ExecStart=/usr/bin/wg-quick up DE-FRA-440 (code=exited, status=1/FAILURE)
   Main PID: 1505 (code=exited, status=1/FAILURE)
        CPU: 129ms

Mar 06 23:04:54 Hippos-Laptop wg-quick[1505]: [#] ip link add dev DE-FRA-440 type wireguard
Mar 06 23:04:54 Hippos-Laptop wg-quick[1505]: [#] wg setconf DE-FRA-440 /dev/fd/63
Mar 06 23:04:54 Hippos-Laptop wg-quick[1505]: [#] ip -4 address add 10.2.0.2/32 dev DE-FRA-440
Mar 06 23:04:54 Hippos-Laptop wg-quick[1505]: [#] ip link set mtu 1420 up dev DE-FRA-440
Mar 06 23:04:54 Hippos-Laptop wg-quick[1505]: [#] mount `10.2.0.1' /etc/resolv.conf
Mar 06 23:04:54 Hippos-Laptop wg-quick[1699]: unshare: unshare failed: Operation not permitted
Mar 06 23:04:54 Hippos-Laptop wg-quick[1505]: [#] ip link delete dev DE-FRA-440
Mar 06 23:04:54 Hippos-Laptop systemd[1]: wg-quick@DE-FRA-440.service: Main process exited, code=exited, status=1/FAILURE
Mar 06 23:04:54 Hippos-Laptop systemd[1]: wg-quick@DE-FRA-440.service: Failed with result 'exit-code'.
Mar 06 23:04:54 Hippos-Laptop systemd[1]: Failed to start WireGuard via wg-quick(8) for DE/FRA/440.

~$ sudo journalctl -eu wg-quick@DE-FRA-440.service --no-pager
Mar 06 23:04:54 Hippos-Laptop systemd[1]: Starting WireGuard via wg-quick(8) for DE/FRA/440...
Mar 06 23:04:54 Hippos-Laptop wg-quick[1505]: [#] ip link add dev DE-FRA-440 type wireguard
Mar 06 23:04:54 Hippos-Laptop wg-quick[1505]: [#] wg setconf DE-FRA-440 /dev/fd/63
Mar 06 23:04:54 Hippos-Laptop wg-quick[1505]: [#] ip -4 address add 10.2.0.2/32 dev DE-FRA-440
Mar 06 23:04:54 Hippos-Laptop wg-quick[1505]: [#] ip link set mtu 1420 up dev DE-FRA-440
Mar 06 23:04:54 Hippos-Laptop wg-quick[1505]: [#] mount `10.2.0.1' /etc/resolv.conf
Mar 06 23:04:54 Hippos-Laptop wg-quick[1699]: unshare: unshare failed: Operation not permitted
Mar 06 23:04:54 Hippos-Laptop wg-quick[1505]: [#] ip link delete dev DE-FRA-440
Mar 06 23:04:54 Hippos-Laptop systemd[1]: wg-quick@DE-FRA-440.service: Main process exited, code=exited, status=1/FAILURE
Mar 06 23:04:54 Hippos-Laptop systemd[1]: wg-quick@DE-FRA-440.service: Failed with result 'exit-code'.
Mar 06 23:04:54 Hippos-Laptop systemd[1]: Failed to start WireGuard via wg-quick(8) for DE/FRA/440.
6

That’s a sandboxing restriction by systemd.

The simplest fix might be to try disabling namespace restrictions for this unit by overriding the service…

sudo systemctl edit wg-quick@.service
and add

[Service]
RestrictNamespaces=no

then do

sudo systemctl daemon-reexec
sudo systemctl start wg-quick@DE-FRA-440.service

See how that goes.

9

Sadly that didn’t do anything for me :frowning_with_open_mouth:

10

The interesting part of your log is this line just before the failure:

[#] mount `10.2.0.1' /etc/resolv.conf

That happens when wg-quick processes a DNS= entry in the WireGuard config. It tries and fails to create a temporary mount namespace (unshare) so it can adjust /etc/resolv.conf.

I’m out of my depth with going any further with analysis, but as NetworkManager is in use, why not use it to manage the connection natively?

11

Already tried that but that’s no good. Unfortunately it has to be done via systemd as if I do it via NetworkManager it leaks my DNS queries and my real IPv6 address, while only the IPv4 address shows the one from the VPN and websites immediately recognise my real IP address and geographic location making it impossible to bypass censorship and effectively hide my identity and location better. So in effect doing it via NetworkManager is useless.

If it may help I am using ProtonVPN’s wireguard configuration.

I’ve already contacted ProtonVPN’s customer support about this but we concluded that it must be an openSUSE bug for systemd

12

I’ve just noticed someone rise was having a similar issue as mine and apparently the issue was related to SELinux being in enforcing mode. As I noticed that now newer Tumbleweed are switched to SELinux instead of AppArmor by default, can someone please help me change the SELinux mode to see if it works for me too? I see no such option in YaST…and I don’t know/haven’t looked up how to do it via terminal.
Thanks

13

You can disable SELinux temporarily using setenforce 0, which switches it to permissive mode (enforcement is turned off), but violations will still be logged .Good for diagnostic purposes.

1 Like
14

Holy shoot, switching SELinux from Enforcing to Permissive fixes this issue. Running sudo systemctl start wg-quick@.service runs as it should and is activated straight away. No complaining with any silly error messages about failing to start the service. So what should I do then? Should I set SELinux to permissive permanently? It looks to me as this is the only way for me to be able to use the VPN and for it to be automatically activated at boot.
Unless I should switch SELinux for AppArmor as it used to be?

15

Or is there a way for me to edit the SELinux policy to let the systemd wg-quick command unrestricted without having to sacrifice everything else in security?

16

@malcolmlewis Ok, looks like your hunch about SELinux impacting was right. Are you able to advise next steps re adjusting policy here?

17

@dj_var Follow the steps listed here to create a bug report https://en.opensuse.org/Portal:SELinux#Summary_line the SELinux folks are very responsive. I’d also create a link to this thread in the report. Likewise, suggest you post the reference here.

2 Likes
19

What make you think that it should work with systemd?

Debugging IP leaks seems to me easier to me and doing it via the NetworkManager is a nicer solution.

20

When I do it via systemd it does not leak a single thing. All network traffic is strictly routed to the VPN tunnel and the killswitch works. When I do it via Network Manager my real ipv6 from my ISP is exposed and my DNS queries leak like hell to my ISP. Tested with ipleak.com and it also was giving me issues with some websites seeing me frkm my Country instead of the VPN Country I set.
So, as I said, no, doing it via NetworkManager does NOT work and it is as good as having the VPN disabled as it completely bypasses and leaks the real IP addresses and DNS queries.

21

I will look into it, thank you very much. For now I have switched from SELinux to AppArmor as that works just fine but will still look knto submitting a bug report to SELinux. Hopefully they can fix that.
Cheers guys :+1:t2:

22

This sounds like the wireguard dns config bug [0], have a look if the AVC looks similar. I am waiting for ages for an upstream response on the suggested fix.

There are different options for workarounds, as well as a test policy with the fix in that bug [1], i.e. might be of help to confirm if there are more issues.

[0] https://bugzilla.suse.com/show_bug.cgi?id=1243148
[1] https://bugzilla.suse.com/show_bug.cgi?id=1243148#c6

1 Like
23

So it looks like there is already a bug report on this then.