Wireguard VPN says connected, but no traffic

I have been having issues with using a Wireguard tunnel and Fedora KDE. I’ve asked before on the Fedora Reddit, but despite over 2k people looking at the post, didn’t really get anywhere:

Basically what is happening is the interface wg0 shows as connected, but no traffic goes through it and I am unable to access the LAN on the VPN server’s side. I set it up by importing the config files Wireguard generated, and it works perfectly fine when I use the Wireguard app on my Android phone importing those same files.

Connect the VPN and check the output:

ip address show
ip route show table all
ip rule show
resolvectl status --no-pager
sudo wg show

Here is the output to those commands. The VPN should be Link 5, wg0

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
2: wlp192s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether aa:4e:bc:0a:a4:88 brd ff:ff:ff:ff:ff:ff permaddr d8:b3:2f:bd:bc:75
    altname wlxd8b32fbdbc75
    inet 192.168.1.57/24 brd 192.168.1.255 scope global dynamic noprefixroute wlp192s0
       valid_lft 86209sec preferred_lft 86209sec
    inet6 fe80::12a5:2dae:970c:1e07/64 scope link noprefixroute 
       valid_lft forever preferred_lft forever
4: docker0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default 
    link/ether 26:b4:3b:76:b8:9f brd ff:ff:ff:ff:ff:ff
    inet 172.17.0.1/16 brd 172.17.255.255 scope global docker0
       valid_lft forever preferred_lft forever
5: wg0: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1420 qdisc noqueue state UNKNOWN group default qlen 1000
    link/none 
    inet 10.253.0.1/32 scope global noprefixroute wg0
       valid_lft forever preferred_lft forever
default via 192.168.1.1 dev wlp192s0 proto dhcp src 192.168.1.57 metric 600 
10.253.0.2 dev wg0 proto static scope link metric 50 
172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1 linkdown 
192.168.1.0/24 dev wlp192s0 proto kernel scope link src 192.168.1.57 metric 600 
local 10.253.0.1 dev wg0 table local proto kernel scope host src 10.253.0.1 
local 127.0.0.0/8 dev lo table local proto kernel scope host src 127.0.0.1 
local 127.0.0.1 dev lo table local proto kernel scope host src 127.0.0.1 
broadcast 127.255.255.255 dev lo table local proto kernel scope link src 127.0.0.1 
local 172.17.0.1 dev docker0 table local proto kernel scope host src 172.17.0.1 
broadcast 172.17.255.255 dev docker0 table local proto kernel scope link src 172.17.0.1 linkdown 
local 192.168.1.57 dev wlp192s0 table local proto kernel scope host src 192.168.1.57 
broadcast 192.168.1.255 dev wlp192s0 table local proto kernel scope link src 192.168.1.57 
fe80::/64 dev wlp192s0 proto kernel metric 1024 pref medium
local ::1 dev lo table local proto kernel metric 0 pref medium
local fe80::12a5:2dae:970c:1e07 dev wlp192s0 table local proto kernel metric 0 pref medium
multicast ff00::/8 dev wlp192s0 table local proto kernel metric 256 pref medium
0:	from all lookup local
32766:	from all lookup main
32767:	from all lookup default
Global
         Protocols: LLMNR=resolve -mDNS -DNSOverTLS DNSSEC=no/unsupported
  resolv.conf mode: stub

Link 2 (wlp192s0)
    Current Scopes: DNS LLMNR/IPv4 LLMNR/IPv6
         Protocols: +DefaultRoute LLMNR=resolve -mDNS -DNSOverTLS
                    DNSSEC=no/unsupported
Current DNS Server: 192.168.1.1
       DNS Servers: 192.168.1.1
     Default Route: yes

Link 4 (docker0)
    Current Scopes: none
         Protocols: -DefaultRoute LLMNR=resolve -mDNS -DNSOverTLS
                    DNSSEC=no/unsupported
     Default Route: no

Link 5 (wg0)
    Current Scopes: none
         Protocols: -DefaultRoute LLMNR=resolve -mDNS -DNSOverTLS
                    DNSSEC=no/unsupported
     Default Route: no
interface: wg0
  public key: (hidden)
  private key: (hidden)
  listening port: 51820

peer: (hidden)
  preshared key: (hidden)
  allowed ips: 10.253.0.2/32

It looks like you don’t have any handshake in the WireGuard output.
You need to add the server’s LAN subnet to the AllowedIPs on the client.
Also allow traffic forwarding and enable masquerading on the server.

Thank you for the help so far!
I know I haven’t gotten any handshakes, but I don’t know how to fix that. I have received them when connecting via my phone. I didn’t realize I had to add the server’s LAN subnet to AllowedIPs, but after I did that on the client it still will not function. I’m not sure about the IP masquerading, from a brief search it seems like that should be enabled by default?

Is the peer the one establishing the connection to your Fedora system ?

If not, you need to configure the Peer endpoint with the public address and port to reach this peer.

Did you generate unique config for each client?
You can use the exact sane config on each client.
They must have unique keys and addresses.

The screenshot indicates that 10.253.0.1 is the server.
But the above text output has the same IP address on the wg0 interface.
You should clarify the IP address and software stack used by each peer.

The Wireguard server is running on Unraid, with it’s built-in implementation. The only client/peer I am trying to get set up at the moment is my Fedora KDE laptop, which refuses to connect. The only other device I have tested with is my android phone, which worked perfectly fine using the wireguard app’s auto importer.

I’m not entirely sure what I am doing, and I would like to learn. The 10.253.0.1 address was automatically assigned when I set up the tunnel, and then the peer. Which I then exported the config to import into Fedora. Should I be manually changing the peer to another address somehow?

The Fedora system is the client, not the server. I think after reading this I may know what I did wrong, but I can’t test until my laptop is on a separate network again tomorrow.

Actually, I just tried it by using my phone as a hotspot to be on a different network. The peer .config file doesn’t want to auto-import, saying it isn’t a valid config. So I tried manually plugging in the numbers, and all that I accomplished was breaking my laptop’s connection to the internet until I disconnect from the VPN. Still no handshake or communication over that interface.

Alright, so I’m still not sure why my manual setups weren’t working. I have got it functional, however. I did some more research and found that the command nmcli connection import type wireguard file wg0.conf actually allows me to import the peer config, and that works immediately. For some reason the GUI does not allow me to import the peer config, saying it is not a valid config, but it does allow me to import the server config.

If anyone can help me understand why that works the way it does, I’m all ears. Thank you to everyone for the help.

You could compare what the working configuration looks like in the GUI compared to your screenshot to try and understand what is different.