[Feature Request] Natively Automate Commercial WireGuard Port Forwarding API in Firmware

Router VPN, DNS, Leaks
1

Hi GL.iNet Team,

First of all, loving my Flint3 - i’ve never had so much fun tinkering with a router!

The ability to manage WireGuard client profiles directly from the Admin Panel GUI is actually a killer feature, especially to offload the overhead from my primary PC.

Currently, the gli.net interface makes it incredibly simple to input commercial VPN login and password to generate a running WireGuard tunnel. However, for users who rely on VPN Port Forwarding (e.g., for optimised peer-to-peer applications, hosting lightweight services, or avoiding passive connection states), we encounter a major roadblock.

Because some providers issue dynamic, ephemeral forwarded ports that must be actively refreshed via an API, a standard static profile cannot handle the handshake. To get this working today, users must manage complex third-party Docker networks (like Gluetun) locally on their client machines, which completely defeats the purpose of offloading encryption processing to our routers.

The Feature Request:

I would love to see GL.iNet natively integrate support for Commercial VPN Port Forwarding APIs directly inside the native VPN Client interface.

Ideally, the feature would:

  1. Allow a toggle for "Enable Port Forwarding" when configuring supported providers.

  2. Natively execute the necessary background API handshake script to request an incoming port from the active VPN gateway.

  3. Automatically maps and injects the assigned port number into the router’s internal firewall zone rules so it routes seamlessly to the local client.

  4. Display the actively assigned forwarded port number cleanly right on the Admin Panel Dashboard.

Using PIA as an example:

Private Internet Access officially provides the complete open-source code and shell scripts detailing exactly how to query their API endpoints for both setting up the WireGuard tunnel and requesting/maintaining a dynamic port forward:

Having this automated at the firmware level would make GL.iNet routers the undisputed choice for prosumers wanting a bulletproof, high-performance, and maintenance-free network tunnel topology.

Thanks!

1 Like
2

I think I will see a issue for them to maintain this.

First of they have no control over what PIA decides remotely or if they gonna pull the api without explanatory, I know alot of vpn providers often have outdated documentation or simply out of nowhere remove api, Mullvad as example did this to with their portforwarding because of abuse.

I don't think it is impossible but I think having all this special threatment on specific vpn profiles will be a issue.

What I would think though what would be a better idea, is for GL-iNet to build something similar to ngrok or playit, using a smart way of reverse proxy for subdomains and make the router port punching access.

On my homelab env I did this on jenkins as webhook and on minecraft server simulating to be cgnat, and it worked really well, I liked ngrok even more because I could also restrict url access to paths like /admin in the url, I find it a much simpler solution and GL-iNet can make these techniques alot more simpler.

3

Hi

Thank you for your suggestions.

We will:

  • Forward your suggestions regarding port forwarding to the relevant team and explore whether we can work more closely with VPN providers that support port forwarding, such as PIA, in future releases.
  • The idea of using NAT hole punching to make services accessible from the Internet in CGNAT environments also sounds promising. However, there are a number of technical aspects that would need further investigation, including how well it would work across different NAT environments (for example, NAT4). We'll discuss this further with the relevant teams as well.
3 Likes
4

Thanks @will.qiu :smiley: