WireGuard VPN Manager

Quote from Fabbz

OK, I thought something like it was missing!

I only have routing issues with wireguard; normally no issues on other systems. Have you experienced this ?

Thanks so far; maybe this needs to be added to your Wiki including the config template ?

Routing issues is not wireguard if your wireguard config file has settings for a VPN provider it is OK. It is connman that handles the routing. Do this cmd in ssh before connecting to a VPN:

route

Then connect to your VPN and do that "route" command again provide that here so I can see. And provide the wireguard file note edit your WireGuard.PrivateKey = ******* we do not need that!

Quote from Fabbz

Yes I'm busy to tackle that all day; normally I don't have issues with my own endpoints.

There is a route to my router which doesn't know anything about the WG subnet. I think that is strange.

My default routing table:

# route  
Kernel IP routing table 
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface 
default         router-01       0.0.0.0         UG    0      0        0 wlan0 
172.17.0.0      *               255.255.0.0     U     0      0        0 docker0 
172.18.0.0      *               255.255.0.0     U     0      0        0 br-6f5896045ba5 
172.19.0.0      *               255.255.0.0     U     0      0        0 br-19a4612b6a85 
172.20.0.0      *               255.255.0.0     U     0      0        0 br-e10d004d3074 
172.21.0.0      *               255.255.0.0     U     0      0        0 br-f3438bd3805a 
172.22.0.0      *               255.255.0.0     U     0      0        0 br-572a21dfb173 
192.168.101.0   *               255.255.255.0   U     0      0        0 wlan0 
192.168.101.254 *               255.255.255.255 UH    0      0        0 wlan0 
212.8.*.*  router-01       255.255.255.255 UGH   0      0        0 wlan0

WG Config:

[provider_wireguard] 
Type = WireGuard 
Name = NL-PROTON-98-FREE 
Host = 212.8.250.216 
WireGuard.Address = 10.2.0.2/32 
WireGuard.ListenPort = 51820 
#WireGuard.MTU = 1420 
WireGuard.PrivateKey = *** 
WireGuard.PublicKey = ***
WireGuard.DNS = 10.2.0.1 
WireGuard.AllowedIPs = 0.0.0.0/0, ::/0 
WireGuard.EndpointPort = 51820 
WireGuard.PersistentKeepalive = 25

WG routing table:

# route 
Kernel IP routing table 
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface 
default         *               0.0.0.0         U     0      0        0 wg0 
10.2.0.0        *               255.255.255.0   U     0      0        0 wg0 
10.2.0.1        192.168.101.254 255.255.255.255 UGH   0      0        0 wlan0 
172.17.0.0      *               255.255.0.0     U     0      0        0 docker0 
172.18.0.0      *               255.255.0.0     U     0      0        0 br-6f5896045ba5 
172.19.0.0      *               255.255.0.0     U     0      0        0 br-19a4612b6a85 
172.20.0.0      *               255.255.0.0     U     0      0        0 br-e10d004d3074 
172.21.0.0      *               255.255.0.0     U     0      0        0 br-f3438bd3805a 
172.22.0.0      *               255.255.0.0     U     0      0        0 br-572a21dfb173 
192.168.101.0   *               255.255.255.0   U     0      0        0 wlan0 
192.168.101.254 *               255.255.255.255 UH    0      0        0 wlan0 
212.8.*.*   192.168.101.254 255.255.255.255 UGH   0      0        0 wlan0

I can ping 8.8.8.8 but DNS resolving - so pinging the WG gateway 10.2.0.1 or using it as DNS is not working. Because of that my route print and my traceroute are very slow because of RDNS lookup.

Display More

I looked into your routing table, and your analysis is 100% correct. The problem is a known ConnMan DNS routing conflict. Look at this specific line in your VPN routing table:

10.2.0.1        192.168.101.254 255.255.255.255 UGH   0      0        0 wlan0

Because you declared WireGuard.DNS = 10.2.0.1 inside your config file, ConnMan mistakenly generated a hardcoded Host route (UGH) that traps your DNS traffic. Instead of sending DNS requests inside the secure wg0 tunnel, it is forcing them out over your Wi-Fi card (wlan0) to your local router (192.168.101.254). Your local router has no idea what 10.2.0.1 is, so it drops the packets. This is why you can ping public IPs like 8.8.8.8 perfectly (via the VPN), but your DNS lookup times out, making your traceroute and reverse-DNS lookups extremely slow.

Force the internal DNS into the tunnel you need to force the Linux kernel to override ConnMan's broken Wi-Fi route. You can do this by splitting the internet route into two smaller halves. Open your .config file and change the AllowedIPs line:

1. Remove: WireGuard.AllowedIPs = 0.0.0.0/0
2. Add: WireGuard.AllowedIPs = 0.0.0.0/1, 128.0.0.0/1

Because a /1 netmask is more specific than a /0 default gateway, the kernel will ignore the Wi-Fi card and force your 10.2.0.1 DNS requests straight into the wg0 tunnel. Make sure to clean the network cache, restart ConnMan, and reconnect:

rm -f /storage/.config/vpn-services/*
ip route flush cache
systemctl restart connman

Quote from Fabbz

Hi,

Thank for the update; I tried what you said but it didn't fix the route.

Any other suggestions to check ?

If the split routing did not override the table, ConnMan is likely aggressively caching your old network state under a temporary session. To see exactly what is going on under the hood, please run these two commands in your terminal while the VPN is active and paste the output back here:

route
connmanctl services

Without seeing your active routing table flags, it is impossible to see which interface is currently trapping your traffic. Paste those logs, and we will try to get it sorted.

grep -i "service.wireguard.manager" /storage/.kodi/temp/kodi.log | pastebinit

What happens: It pushes the filtered data straight to LibreELEC's default pastebin server and prints a clean link right inside your terminal window. Please share that link directly in this thread. Do not post full raw logs here!