What's new

Need help to resolve VPN Director issue

  • SNBForums Code of Conduct

    SNBForums is a community for everyone, no matter what their level of experience.

    Please be tolerant and patient of others, especially newcomers. We are all here to share and learn!

    The rules are simple: Be patient, be nice, be helpful or be gone!

wmd1942

New Around Here
I'm running Merlin (3004.388.7) on Asus RT-AX86U router. With wgcf, I successfully created a WireGuard client config file for Cloudflare WARP. The WireGuard client status shows connected. In VPN Director, I made a rule to direct all devices through VPN. However, it seems VPN does not work. The "https://ipleak.net" still shows my ISP-assigned IP address. Any help is greatly appreciated.

By the way, the syslog does not show any issue:

Jul 24 21:02:06 WireGuard: Starting client 1.
Jul 24 21:02:06 custom_script: Running /jffs/scripts/service-event-end (args: restart wgc)
Jul 24 21:03:43 rc_service: httpds 531381:notify_rc restart_vpnrouting0
Jul 24 21:03:43 custom_script: Running /jffs/scripts/service-event (args: restart vpnrouting0)
Jul 24 21:03:43 vpndirector: Routing Cloudflare warp for all from 192.168.10.0/24 to any through wgc1
Jul 24 21:03:43 wireguard: Forcing 192.168.10.0/24 to use DNS server 1.1.1.1 for WGC1
Jul 24 21:03:43 wireguard: Forcing 192.168.10.0/24 to use DNS server 1.0.0.1 for WGC1
Jul 24 21:03:43 wireguard: Forcing 192.168.10.0/24 to use DNS server 2606:4700:4700::1111 for WGC1
Jul 24 21:03:43 wireguard: Forcing 192.168.10.0/24 to use DNS server 2606:4700:4700::1001 for WGC1
Jul 24 21:03:43 custom_script: Running /jffs/scripts/service-event-end (args: restart vpnrouting0)


1721870867215.png


1721870966332.png
 
Dump the routing tables, and the ip rules.

Code:
ip route
ip route show table wgc1
ip rule
 
Make sure you are not using IPv6, and that you aren`t connected to a Guest Network as that would bypass the tunnel (Guest Network 1 uses a different subnet).
 
IPv6 is disabled and I'm not connected to the guest WiFi network. Here are the results of the commands. "xx.xx.xx" is the ISP assigned IP. "192.168.10.0" is the main subnet. "192.168.2.0" is the subnet for WiFi guests. "192.168.20.0" is the subnet for IP cameras.

admin@RT-AX86U-B0B0:/tmp/home/root# ip route
default via xx.xx.xx.1 dev eth0
1.0.0.1 dev wgc1 scope link
1.1.1.1 dev wgc1 scope link
8.8.4.4 via xx.xx.xx.1 dev eth0 metric 1
8.8.8.8 via xx.xx.xx.1 dev eth0 metric 1
10.6.0.2 dev wgs1 scope link
10.6.0.3 dev wgs1 scope link
10.8.0.0/24 dev tun21 proto kernel scope link src 10.8.0.1
xx.xx.xx.0/23 dev eth0 proto kernel scope link src xx.xx.xx.118
xx.xx.xx.1 dev eth0 proto kernel scope link
127.0.0.0/8 dev lo scope link
192.168.2.0/24 dev wl0.1 proto kernel scope link src 192.168.2.1
192.168.10.0/24 dev br0 proto kernel scope link src 192.168.10.1
192.168.20.0/24 via 192.168.10.201 dev br0 metric 2


admin@RT-AX86U-B0B0:/tmp/home/root# ip route show table wgc1
default via xx.xx.xx.1 dev eth0
8.8.4.4 via xx.xx.xx.1 dev eth0 metric 1
8.8.8.8 via xx.xx.xx.1 dev eth0 metric 1
10.8.0.0/24 dev tun21 proto kernel scope link src 10.8.0.1
xx.xx.xx.0/23 dev eth0 proto kernel scope link src xx.xx.xx.118
xx.xx.xx.1 dev eth0 proto kernel scope link
127.0.0.0/8 dev lo scope link
162.159.192.1 via xx.xx.xx.1 dev eth0
192.168.10.0/24 dev br0 proto kernel scope link src 192.168.10.1
192.168.20.0/24 via 192.168.10.201 dev br0 metric 2

admin@RT-AX86U-B0B0:/tmp/home/root# ip rule
0: from all lookup local
90: from all to 10.6.0.2 lookup main
90: from all to 10.6.0.3 lookup main
11210: from 192.168.10.0/24 lookup wgc1
32766: from all lookup main
32767: from all lookup default
 
Unfortunately, I don't have access to Wireguard on my router at the moment. So my comments are based on what I would have expected to see in those dumps given my knowledge of how the VPN Director works w/ OpenVPN.

What I find strange is that the WG network interface (wgc1) is never referenced AT ALL in the wgc1 routing table. In fact, the wgc1 routing table appears to have the same default gateway as the main routing table (eth0), and no overrides for the wgc1 network interface either. Yet I can see the ip rule for the 192.168.10.0/24 network is there to direct that network through the wgc1 routing table.

The only routing for the wgc1 network interface exists in the main routing table (specifically DNS), which does NOT include 192.168.10.0/24.

So based on what I'm seeing, I can understand why it's NOT working. What I can't understand is why it is (apparently) misconfigured.

One other curiosity; I can see there's an OpenVPN server reference in the wgc1 routing table (tun21), but nowhere else. I'm not saying that's a contributing factor, but I wasn't expecting it, and it's ONLY in the wgc1 routing table, NOT the main routing table.

Anyway, definitely NOT what I was expecting. Some real oddities there.

Again, I'm coming at this w/ no ability to test it myself, but simply based on what I would typically have expected to see given comparable configurations w/ OpenVPN.
 
Last edited:
It would be interesting to see if it starts working if you copy/paste the following into ssh w/ the router.

Code:
ip route add 128.0.0.0/1 dev wgc1 table wgc1
ip route add 0.0.0.0/1 dev wgc1 table wgc1
ip route flush cache
 
What in the world has happened here to this thread?! Someone has merged it w/ part of another thread, and merged this thread w/ part of the other thread. It's a mess!
 
What in the world has happened here to this thread?! Someone has merged it w/ part of another thread, and merged this thread w/ part of the other thread. It's a mess!
I moved the support requests/discussions from the other thread here, because otherwise we were ending up with two separate threads meant for troubleshooting. I thought your other thread was intended for keeping it separate specifically for technical discussions instead. Sorry if I misunderstood.

I might have merged in the wrong thread, checking now.

EDIT: Moved to the correct thread, sorry about that.
 
admin@RT-AX86U-B0B0:/tmp/home/root# ip route show table wgc1
default via xx.xx.xx.1 dev eth0
8.8.4.4 via xx.xx.xx.1 dev eth0 metric 1
8.8.8.8 via xx.xx.xx.1 dev eth0 metric 1
10.8.0.0/24 dev tun21 proto kernel scope link src 10.8.0.1
xx.xx.xx.0/23 dev eth0 proto kernel scope link src xx.xx.xx.118
xx.xx.xx.1 dev eth0 proto kernel scope link
127.0.0.0/8 dev lo scope link
162.159.192.1 via xx.xx.xx.1 dev eth0
192.168.10.0/24 dev br0 proto kernel scope link src 192.168.10.1
192.168.20.0/24 via 192.168.10.201 dev br0 metric 2
Check you client AllowedIPs import. It should be 0.0.0.0/0


It would be interesting to see if it starts working if you copy/paste the following into ssh w/ the router.
It wouldn't work if AllowedIPs are not 0.0.0.0/0. Even if you make the routes yourself it won't be allowed over the tunnel. Now, you may wonder how I know that 😉...
 
Check you client AllowedIPs import. It should be 0.0.0.0/0



It wouldn't work if AllowedIPs are not 0.0.0.0/0. Even if you make the routes yourself it won't be allowed over the tunnel. Now, you may wonder how I know that 😉...

Good point. Although given this is coming from a third-party, I would assume the config file does contain that directive. To NOT do do would roughly be the equivalent of a commercial OpenVPN provider NOT providing a redirect-gateway directive in their config file. You just never see that happen, lest the user would never see any access across the VPN, at least by default.

It still makes me wonder why there's no default gateway for WG in the wgc1 routing table. Unless perhaps the router has seen no 0.0.0.0/0 and has decided not to bother. Still seems kind of weird. If it fails to cross the tunnel due to a missing 0.0.0.0/0, it's still going to fail w/ a valid default gateway that points to WG.
 
Good point. Although given this is coming from a third-party, I would assume the config file does contain that directive. To NOT do do would roughly be the equivalent of a commercial OpenVPN provider NOT providing a redirect-gateway directive in their config file. You just never see that happen, lest the user would never see any access across the VPN, at least by default.
It's probably there in the config file but either failed to import or the user have been messing with it.


It still makes me wonder why there's no default gateway for WG in the wgc1 routing table. Unless perhaps the router has seen no 0.0.0.0/0 and has decided not to bother. Still seems kind of weird. If it fails to cross the tunnel due to a missing 0.0.0.0/0, it's still going to fail w/ a valid default gateway that points to WG.
The routes are created based on AllowedIPs. So if this field is missing or contains Invalid characters no routes will be created.
 
The generated WireGuard client config file does include "AllowedIPs = 0.0.0.0/0" as shown below and I didn't modify anything:

[Interface]
PrivateKey =
Address = 172.16.0.2/32
Address = 2606:4700:110:889d:c1ef:27f:14c3:9932/128
DNS = 1.1.1.1, 1.0.0.1, 2606:4700:4700::1111, 2606:4700:4700::1001
MTU = 1280
[Peer]
PublicKey =
AllowedIPs = 0.0.0.0/0
AllowedIPs = ::/0
Endpoint = engage.cloudflareclient.com:2408

Also, I ran the commands recommended below but the issue is not resolved:

ip route add 128.0.0.0/1 dev wgc1 table wgc1
ip route add 0.0.0.0/1 dev wgc1 table wgc1
ip route flush cache

Regarding "OpenVPN server", I do have 2 VPN servers set up in the router, OpenVPN and WireGuard. But I have no idea why "OpenVPN server referenced in the wgc1 routing table".

Thanks a lot for all your help though.
 
That AllowedIPs setting is for IPv6, NOT IPv4. It needs to be 0.0.0.0/0 if you expect to route IPv4 over the tunnel. Or else specify both.

P.S. Looks like the import has a bug and only picked up the last directive of the same name. Or maybe the config file itself is wrong and should have specified both IPv4 and IPv6 on the same line. I'm not sure which is the case.
 
Found this from your link:

AllowedIPs — a comma-separated list of IP (v4 orv6) addresses with CIDR masks from which incoming trafficfor this peer is allowed and to which outgoing traffic forthis peer is directed. The catch-all 0.0.0.0/0 may bespecified for matching all IPv4 addresses, and ::/0may be specified for matching all IPv6 addresses. May be specified multiple times.

So it does appear to be a bug in the router.

So the OP should just edit the config file and specify both arguments on one AllowedIPs directive, separated by a comma, then import again.
 

Similar threads

Latest threads

Support SNBForums w/ Amazon

If you'd like to support SNBForums, just use this link and buy anything on Amazon. Thanks!

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!
Top