Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Already on GitHub? Sign in to your account

Better support for private tunnels #13

nirvdrum opened this Issue May 6, 2011 · 5 comments


None yet
2 participants

nirvdrum commented May 6, 2011

This may be beyond the scope of localtunnel, and if so, feel free to close out and let me know.

The only way to access a site over a tunnel is via a private URL. But that URL could be guessed by anyone. It'd be nice if it were possible to register a tunnel on one port and serve up the tunnel on another. This would allow a client to register over a publicly exposed port, but for the tunnel to only be available on a private port.

The use case here may be esoteric, but we have people that want us to be able to access their sites, but don't want the sites accessible by anyone else. The random name provides security through obscurity. This would add the ability to do security via firewall, too. Then our users can access their sites publicly through our service where we can impose user restrictions and such.


progrium commented May 6, 2011

Do you mean serve the web proxy for a particular tunnel on a private port? Say we did that, how would somebody access the port? Curious how you would manage security on your deployment -- open the port temporarily for them?


nirvdrum commented May 6, 2011

The registration endpoint would sit on port 8888, but the Web proxy would sit on 8889. 8888 would be open to the world so clients could connect and register. 8889 would only be open to hosts within the localtunnel server's subnet. The user would not be able to access the tunneled URL directly, but whoever is running the localtunnel server could. They could then expose the tunneled URL through their own reverse proxy, but use their own user authentication mechanisms and what not.


progrium commented May 20, 2011

So I guess this would just mean splitting the tunnel registration handler and proxy handler into separate HTTP services that can listen on different ports. Perhaps another way to solve this problem is to add some kind of IP whitelisting for each?


nirvdrum commented May 21, 2011

IP whitelisting could work as well. That might get tricky with proxies and NATs, but probably an acceptable tradeoff.


progrium commented Dec 1, 2012

In the latest version running in beta you can specify long, unguessable tunnel names. Alternatively, in the near future, basic HTTP authentication will be added.

@progrium progrium closed this Dec 1, 2012

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment