I have a Slate 7 (GL-BE3600) which has a wireguard client on it. I want to configure it such that only traffic that matches my VPN subnet will be routed through it. I have tried setting my AllowedIPs section, but this doesn’t have the effect I intended it to. For example:
If I use AllowedIPs = 10.43.237.0/0 then all traffic is directed over the VPN
If I use AllowedIPs = 10.43.237.0/24 then only VPN traffic is forwarded, and everything else is blocked.
I have had a look in the router configuration several times but I can’t seem to get it working. I would really appreciate any ideas on how to make this work. Thank you.
There is a common misconception about the AllowedIps field.
When a peer gets defined inside the server, you may choose a fixed ip something like: 10.43.237.2/32 this means that ip is allowed for the serverside peer to communicate, but when you export this peer, then the AllowedIps have a completely different meaning, in that case it means which ip are allowed inside the tunnel, if you put 0.0.0.0/0 it means the full internet goes in the tunnel.
There is a clear abstraction between this field between server and client.
I hope this helps understanding something crucial and that fixes your issue
Hi, thanks for your reply! I think my original explanation may not have been quite right. I’m not changing the server side AllowedIPs value, I’m changing it client side so I can have a split tunnel. I have used this method on other servers and macbooks successfully before, setting AllowedIPs = 10.43.237.0/0 usually works but not on the gl-inet router for some reason. I saw some other community posts saying the same thing so I wonder if this is down to the wireguard implementation in the gl-inet firmware?
The AllowedIP on the client defines what destinations subnets are through the tunnel. So if you use e.g 192.168.10.0/24 that’s the subnet of the devices you want to reach at the remote locations beyond the server. It’s not the subnets of the devices on the client LAN side.
Which of these you are trying to achieve? If it’s client LAN and not destination then setting allowedIPs isn’t supposed to work for this. (Universally not GL specific)
edit: Someone has made a handy guide to help explain this here
Thank you everyone for your replies, this has been very helpful. The solution I have chosen is to use a policy-based tunnel, which routes traffic as I had hoped, but it doesn’t use the DNS field from my WireGuard config anymore. Instead of changing it globally on the router, I’ve changed it on my devices as I will always be connected to my VPN when using the router.
From the example shared by @oorweeg, I want to achieve ”Split Tunnel (Corporate Only Resources)” as well as preventing “Mistake 4: DNS Leaks in Split Tunnel“ - policy mode has allowed the split tunnel to work, but DNS isn’t working yet. My fix for this was to manually change my DNS on my phone and laptop which is fine, but ideally the router would change to use the DNS from my VPN tunnel.
If client devices are using the router as their DNS server, this is expected behavior.
When Policy-based VPN is enabled and AdGuard Home is not turned on / Custom DNS:
Only domains in the specified list are resolved using the VPN DNS
All other domains are resolved via the WAN DNS
This design ensures that DNS resolution matches the actual traffic path (VPN or WAN), preventing cases where domains accessed via WAN are resolved to servers reachable only through the VPN tunnel, or not optimal for WAN access.
If you’d like to use a DNS server located on the remote subnet behind the VPN tunnel, you’ll need to configure it manually on the client devices, or update the DNS settings pushed via DHCP under Admin Panel → Network → LAN.
10.43.237.0/0 worked on some devices for me when 10.43.237.0/24 didn’t. I had it on a previous version of MacOS, though I don’t remember the version. It’s never been an issue for me on Ubuntu/Debian. When I only want to use the subnet now, I always use /24 on my laptop and on my android phone. I tried using /0 here because I have had experience of it working before and wondered if it was the same behaviour. I think you’re right though, 10.43.237.0/0 would be the same as 0.0.0.0/0
anything/0 is going to translate to everything. So if 10.43.237.0/24 is the lan for the router acting as a wireguard client, having the allowed ips be 10.43.237,0/24 means that nothing goes over the tunnel; 10.43.237.0/0 means everything goes over the tunnel. If you want everything to go over the tunnel, 0.0.0.0/0 is easier to read. If you want only some remote network traffic to go over the tunnel, you set the allowed ips to be the server's /32 ip plus the remote network /24 (or whatever the larger or smaller subnet is).
