Ok I cant for the live of me remember how I got these but going off this screenshot example (I actually have 5 tunnels setup) I was trying to add a 6th VPN client, which added but it forces me to select one of the already existing tunnels. I want to create a new policy but not seeing where/how to do that. Is 5 the max? Again screenshot only shows 2 as I borrowed from another post, I do infact have 5 working, I want a 6th now what am I missing.
I have been told it is indeed a limit.
Not sure why honestly, I noticed also that each instance ships its own dnsmasq instance which is also something which I think is strange maybe as preparation for nftables because nftsets iptables have a limit on elements on ipsets so either they need to be cut in portions or have different dnsmasq instance, but having alot of dnsmasq instances can be a bit much.
They still use iptables so this limit does not exist.
Edit:
Correction, the limit counts on ipsets from iptables not nftsets I just checked it is the opposite nftsets handle it dynamically.
Hi,
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.
So unfortunately, supporting 6 tunnels may not be possible.
However, if you could share your specific tunnel policy setup, we — or other users — may be able to help determine whether some of the rules can be consolidated.
2 Likes
Hello, essentially I have 1-2 devices that I want to be able to talk across the VPN client connections to a specific endpoint on each.
So basically each tunnel has this configuration and only routes traffic via the respective VPN Client only for the communication to the server all other traffic stays local or routes to the internet as normal.
From: 192.168.1.100
To: 192.168.10.100 or server.domain1.home (this is what changes with each client so just up the 3rd octet by 10 each time and the address changes to the next domain#.home.
What currently is a problem is upon adding the 6th client it wants me to pick 1 of the 5 tunnels regardless if they are enabled or not instead of assigning it its own configuration so if resources are the problem (which doesnt seem like it struggles with 5 at all but I admit I have not done any extensive testing in that regard as it has just been working up till the addition of #6 connection).
I suppose if 5 is the limit at least let us add more, but only enable max 5 at a time? Ultimately I can just use the local Wireguard Client on the endpoint but its nice to have it at the router all handled in the background.
Thank you for sharing your use case.
In this scenario, it does not seem like there is much room to simplify or consolidate the configuration further.
We will share your use case with the product team and discuss whether it may be possible to support more tunnels in the future.
However, at the moment, both the number of configurable tunnels and the number of concurrently running tunnels are limited to 5, so there may not be another workaround besides using a local WireGuard client directly on the end devices.
Ok thanks for confirming the limit of 5 and following up.
Hi everyone, I'm hitting the same wall with my setup on the MT3000 running the latest 4.9 beta. Right now I'm maxed out at exactly 5 tunnels:
1- Direct tunnel for console access
2- Work VPN (specific IPs & devices)
3- Homelab VPN (specific IPs & devices)
4- Direct VPN routing all devices to router/switch IPs
5- Commercial VPN for daily privacy
I'd really like to add a couple more, like a dedicated tunnel for streaming services and another for my guest network, but I'm blocked by the 5-tunnel cap.
Given how lightweight my current setup is on the MT3000 (0.08 CPU usage and ~33% RAM on the 4.9 beta), it feels like the limit is more of a software/UI constraint than a hardware bottleneck. Would it be possible to increase the cap to 15 tunnels, or maybe make it scale on a per-device/performance basis?
Also curious if the dnsmasq/ipset overhead mentioned above is the main reason for the hard limit, or if it's just a development constraint.
Thanks for considering it!
Thank you as well for sharing your use case with us.
We will also share your use case with the product team.
Best would be it can be designed that it has no limit or need for the extra dnsmasq instances, some of us can have a pretty sophisticated pbr design, and with the future with so many vpn censorships people move to also the more residental vpns.
For my normal vpn use I use Mullvad, for some of my seedbox docker instances I route through a different mullvad vpn, but Mullvad is basically easily blocked also due to history of being used as c&c traffic and public server list, I use protonvpn for indexers.
I guess there are people with even more sophisticated pbr than me.
Spot on. An unlimited, or at least a much higher ig, tunnel limit would be a game changer for power users. The technical overhead is fine, but the hard cap is really what holds us back.