Hey, back to trying GL.INET after many years. Bought a Beryl AX to play and mostly been super impressed, but a few queries and niggles….for reference I'm a long time PFSense user. I'm not particularly proficient in networking and part of the appeal is the ease of config on the GL.INET routers.
So 1st topic, why the seemingly arbitrary 5 VPN policy limit? I guess there has to be a limit but 5 is quite restrictive. My current policies are:
Devices that must always go through VPN - not strictly needed but helps avoid and config mistakes causing leaks.
Domains excluded from VPN - main use is to enable WiFi calling on devices that are otherwise going through VPN (not any devices in rule 1).
Devices not to go through VPN e.g. Roku Stick
Guest network not to go through VPN based on connection type
Primary catch all to send anything else through VPN
I also have the toggle for all other traffic to go via VPN and this picks up devices connected to wireguard sever and cascades them through the VPN.
I know I could probably ditch the 1st rule but I like those devices to go through their own tunnel anyway. Ideally I want an addition rule or 2. For example, I also have another client I would like to use it's own tunnel. It would be good if the limit wasn't a hard limit, maybe this is a feature request. At the moment things are workable but it's putting me of investing more into GL.INET kit.
For some reason I can't edit the above but it looks like 4.9 has a major overhaul of VPN policies. Will try when it is a stable release. Will 4.9 give me the flexibility I'm after or will it have similar limitations?
Since each VPN tunnel may require its own dedicated VPN instance, DNSMASQ instance, firewall marks, and other related resources, we set a limit of 5 tunnels after considering overall system resource usage. This limit applies to both v4.8 and v4.9.
For your particular use case, we may be able to simplify the setup slightly. For example, rules 4 and 5 could potentially be merged into:
“All zones except Guest use the VPN”
(In this case, the Guest network would naturally bypass the VPN, while all other connection methods would go through it.)
Yes, that will certainly free up one policy slot and that will probably be sufficient for me for now. Overall I'm quite impressed with how far GL.Inet has come on since I last looked a long time ago. I want to keep one other client in it's own isolated tunnel and this will allow me to achieve that.
I've been complaining about this for a while now. What will it take to set the limit to 10? In 2026, there are so many use cases, and a limit of 5 seems low. Is this a potential CPU or RAM issue? If it's RAM, why isn't GL.iNet including more RAM? For newer and more powerful devices, it would be nice to have a limit of at least 10.
You can test out your performance by moving to vanilla Openwrt and setting up 10 tunnels. It would be interesting to others I expect.
If you don't need more than 5 active tunnels, you can usually segment your network so PBR sends traffic over the right tunnel based on CIDR ranges.The tunnels are the limit, not the PBR.
Scratch that, it doesn't work, and I think I tried that to start with. You can't do all connection types excluding guest as far as I can see on 4.8.1. If you specify the connection types to include, you need to select the ones you want to not route via VPN and specify no VPN as otherwise they get caught by the ‘all other traffic’ toggle which I want set to off. However, this breaks the ‘all other traffic’ anyway as this appears to use the Primary Tunnel policy including if this is set to route not via the VPN. I might still be able to squash my policies a bit some other way but I must use specific exclude policies as the alternative is too error prone and fragile, particularly for devices that like using randomised MAC addresses (sure you can turn off randomised MAC per WiFi network but again a simple WiFi config change on router or client and that all falls apart). Also, keeping policies robust and easy to understand (hard to inadvertently screw up) is super important. I can't see myself needing more than 5 VPN clients on the router, but at the moment I can really only use 2 with my desired exclude policies based on domain, device and connection type and that isn't really sufficient. For my particular use case more sophisticated policies may help, I'll take a look at 4.9 at some point.
I can see why restricting to say 5 VPN clients may be necessary from a resource perspective but the current implementation restricts to 5 policies, not 5 VPN clients. An unrestricted number of policies but a restricted number of VPN clients would add considerably more configuration flexibility.
I would also like to understand this. I'm new to OpenWrt and GL.Inet so in learning mode. My understanding is that PBR can be configured at OpenWRT level but any policies set on GL.Inet UI will overwrite or at least conflict with PBR configured directly in OpenWRT. Happy to be re-educated if that's wrong. I'm not necessarily against not using the GL.Inet policies but usability of config is important to me.
It will conflict, the last time I did this I ensured that the settings in the gl vpn dashboard where set to no routing mode.
Then there is another issue there is a possibility the luci-app-pbr cannot detect the tunnel because the wireguard is different than the real OpenWrt version but I think you can get away with this by adding the interface naming into supported interfaces inside the luci app.
Then you can take a example of this screenshot how to define policies:
Note that when you want multiple wireguard clients in vanilla OpenWrt with the same key, you just create the same interface as wgclient, only the peer here is important to be different and in such way you can route the peer differently but feels a little inconvient, but it is fine.
Make sure that peers do not have 'Route Allowed IPs' checked only for wireguard server this is needed, pbr replaces the full routing.
And to allow local clients to not get kill switched in advanced settings inside luci-app-pbr you have a checkbox to show the ignore target, then add src range with the target ignore
Honestly if I were you I would go to vanilla OpenWrt directly also because you can get the right support, with gl firmware not because the maintainer does not support it officially, besides GL firmware also have older packages, which is not good for PBR because sometimes the newer version includes alot of fixes.
There is also no need to have different dnsmasq instances with luci-app-pbr, but I guess they do this on the gl firmware because of the iptables firewall, ipset have a fixed limit how many domains can get in it, also now that I think about this you need a older pbr for iptables too or it will not work.
