This is nice and for those who's asking, it's different from ngrok and the others in that you don't need a separate client, (almost) everyone has ssh installed.
To the author, I wish you best of luck with this but be aware (if you aren't) this will attract all kind of bad and malicious users who want nothing more than a "clean" IP to funnel their badness through.
serveo.net [2] tried it 8 years ago, but when I wanted to use it I at some point I found it was no longer working, as I remember the author said there was too much abuse for him to maintain it as a free service
Even the the ones where you have to register like cloudflare tunnels and ngrok are full of malware, which is not a risk to you as a user but means they are often blocked.
Also a little rant, tailscale has their own one also called funnel. It has the benefit of being end-to-end encrypted (in theory) but the downside that you are announcing your service to the world through the certificate transparency logs. So your little dev project will have bots hammering on it (and trying to take your .git folder) within seconds from you activating the funnel. So make sure your little project is ready for the internet with auth and has nothing sensitive at guessable paths.
Just want to say that I appreciate you maintaining this list. It's one of those things I need to do every now and then, so having a place that gives me a current summary of the options is very handy.
My service (which doesn't have public access, only via SSH as a client) was used by a ransomware gang, which involved the service in investigation from Dutch CERT and Dubai police.
As someone who has launched something free on HN before, the resulting signups were around 1/3rd valid users doing cool things and checking things out, and 2/3rds nefarious users.
I run playit.gg. Abuse is a big problem on our free tier. I’d get https://github.com/projectdiscovery/nuclei setup to scan your online endpoints and autoban detections of c2 servers.
Thanks for sharing this. I run packetriot.com, another tunneling service and I ended up writing my own scanner for endpoints using keyword lists I gathered from various infosec resources.
I had done some account filtering for origins coming out of Tor, VPN networks, data centers, etc. but I recently dropped those and added an portal page for free accounts, similar to what ngrok does.
It was very effective at preventing abuse. I also added mechanism for reporting abuse on the safety page that's presented.
Do you have funding to cover the paying the bandwidth costs which will ultimately result from this? Or if you're running this from a home network, does anyone know if OP should be concerned of running into issues with their ISP?
The tunnel host appears to be a Hetzner server, they are pretty generous with bandwidth but the interesting thing I learned about doing some scalability improvements at a similar company [0] is that for these proxy systems, each direction’s traffic is egress bandwidth. Good luck OP, the tool looks cool. Kinda like pinggy.
Yeah, this is the next step. I first wanted to understand if this gets any traction. I think I will provide a dockerized version for the server part that you can just run with a simple command and maybe some interface to create api keys and distribute them to your users.
Fair enough from a business standpoint, but seeing as there are massive privacy/security risks involved in exposing your data to an opaque service, the open source component is probably a non-optional aspect of the value prop.
You should also consider grouping your random hostnames under a dedicated subdomain. e.g. "xxx-xxx-xxx.users.tunnl.gg", that separates out cookies and suchlike.
I run a similar site (https://pico.sh) with public urls and thought the same thing for us. The public suffix has some fuzzy limits on usage size before they will add domains (e.g. on the scale of thousands of active users).
I don’t have tunnl.gg usage numbers but I’m going to guess they are no where near the threshold — we were also rejected.
"We cooperate with law enforcement agencies when required by law. While we do not inspect traffic content, we will provide connection logs and IP address information in response to valid legal process (such as a subpoena or court order) to assist in investigations regarding illegal activity."
I used ngrok when it was the to-go answer for serving localhost (temporarily, not permanent) to the public, but the last time I searched for alternatives I stumbled upon the following jewel.
> tailscale funnel 3000
Available on the internet:
https://some-device-name.tail12345.ts.net/
|-- proxy http://127.0.0.1:3000
Press Ctrl+C to exit.
I've tailscale installed on my machine anyway for some connected devices. But even without this would convince me using it, because it's part of the free tier, dead simple and with tailscale it's coming from kind of a trusted entity.
Hey really recommend using a big long random string in that URL, because as you will have read above TAILNET NAMES ARE PUBLIC. You can find them here: https://crt.sh/?Identity=ts.net [warning, this will probably crash browser if you leave it open too long -- but you can see it's full of tailnet domains].
So anyway try it like:
tailscale funnel --set-path=/A8200B0F-6E0E-4FE2-9135-8A440DB9469D
http://127.0.0.1:8001 or whatever
Hey, I didn't mean to sell another tool over yours! It's just an experience that popped into my mind and I wanted to share. I appreciate your work and contributing to the problem space of exposing a local service. Thank you.
Thats a fair point, there are some protections in place for abuse already. I will have a look at what ngrok does for browser warnings. Thanks a lot for the suggestions.
Be aware of threat actors, too: you're giving them an easy data exfil route without the hassle and risk of them having to set up their own infrastructure.
Back in the day you could have stood up something like this and worried about abuse later. Unfortunately, now, a decent proportion early users of services like this do tend to be those looking to misuse it.
I'm not who you asked, but essentially, when you write malware that infects someone's PC, that in itself doesn't really help you much. You usually want to get out passwords and other data that you might have stolen.
This is where an exfil (exfiltration) route is needed. You could just send the data to a server you own, but you have to make sure that there are fallbacks once that one gets taken down. You also need to ensure that your exfiltration won't be noticed by a firewall and blocked.
Hosting a server locally, easily, on the infected PC, that can expose data under a specific address is (to my understanding) the holy grail of exfiltration; you just connect to it and it gives you the data, instead of having to worry much about hosting your own infrastructure.
That's actually a fair defence against this kind of abuse. If the attacker has to get some information (the tunnel ID) out of the victim's machine before they can abuse this service, then it is less useful to them because getting the tunnel ID out is about as hard as just getting the actual data out.
However, if "No signup required for random subdomains" implies that stable subdomains can be obtained with a signup, then the bad guys are just going to sign up.
I've seen lots of weird tricks malware authors use, people are creative. My favorite is that they'd load up a text file with a modified base64 table from Dropbox which points to the URL to exfiltrate to. When you report it to Dropbox, they typically ignore the report because it just seems like random nonsense instead of being actually malicious.
> Hosting a server locally, easily, on the infected PC, that can expose data under a specific address is (to my understanding) the holy grail of exfiltration; you just connect to it and it gives you the data, instead of having to worry much about hosting your own infrastructure.
A permanent SSH connection is not exactly discreet, though...
On the VPS we use:
- 80 (standard http)
- 443 (standard https)
- 22 (obv for standard ssh)
- 9090 (metrics / internal so I can have an idea of the generic usage like reqs/s and active connections)
Client-Side: The -R 80:localhost:8080 Explained
The 80 in -R 80:localhost:8080 is not a real port on the server. It's a virtual bind port that tells the SSH client what port to "pretend" it's listening on.
No port conflicts - The server doesn't actually bind to port 80 per tunnel. Each tunnel gets an internal listener on 127.0.0.1:random (ephemeral port). The 80 is just metadata passed in the SSH forwarded-tcpip channel. All public traffic comes through single port 443 (HTTPS), routed by subdomain.
So What Ports Are "Available" to Users?
Any port - because it doesn't matter! Users can specify any port in -R:
ssh -t -R 80:localhost:3000 proxy.tunnl.gg # Works
ssh -t -R 8080:localhost:3000 proxy.tunnl.gg # Also works
ssh -t -R 3000:localhost:3000 proxy.tunnl.gg # Also works
ssh -t -R 1:localhost:3000 proxy.tunnl.gg # Even this works!
The number is just passed to the SSH client so it knows which forwarded-tcpip requests to accept. The actual routing is done by subdomain, not port.
Why Use 80 Convention?
It's just convention - many SSH clients expect port 80 for HTTP forwarding. But functionally, any number works because:
- Server extracts BindPort from the SSH request
- Stores it in the tunnel struct
- Sends it back in forwarded-tcpip channel payload
- Client matches on this to forward to correct local port
- The "magic" is that all 1000 possible tunnels share the same public ports (22, 80, 443) and are differentiated by subdomain.
Not that you'd usually need this if you have IPv6 but might still be useful to bypass firewalls or forward access for IPv4 clients from your newer IPv6-only resources.
I can't promise anything this is a pet project. I might turn it into an open source project, and I might also provide some kind of service for a few bucks if it gets traction.
Good luck with your future mim data sniffing or selective takeovers, I guess? Not sure what the business model would be, unless you’re planning on injecting ads, which would be funny.
Unless the author is insanely rich, they probably don't want to spend increasingly large amounts on hosting unless they have a way to make money back (even if it's just to break even).
I love the concept, but I have one gripe: the subscription email is coming from a Gmail address, so I have no trust. I'd love to see it coming from the same domain. Also, it went to spam.
That is wrong (and I need to update any docs that mention this), the traffic is not encrypted end to end, we do TLS termination on our side. From that point on traffic is forwarded back as plain HTTP. However I would in any case not suggest to host any production applications using this service. It is mostly for local dev testing.
It's not my target audience. Also as a dev I hate spending more than a couple of seconds to do this. This service exists mainly to scratch my own itch.
If you’re in the EU or have users in the EU, that distinction matters, and you should be more precise. You likely have a solid legitimate use case for collecting IPs under the GDPR, but only if you’re fully transparent.
Probably not an exciting answer but my work focused on stability and performance. There are indeed a lot of cool alternatives. I think Localxpose is for businesses who aren't interested in self-hosting and just need a service that will reliably handle production traffic. I don't know if that's unique (or cool, lol)
If you want to do this another way, Tailscale funnel can send public traffic into your tailnet Traefik supports pulling the Tailscale cert from its socket.
Periodic reminder that just because Go having an easy to use SSH package made these easy to write, connecting to SSH servers and doing TOFU all the time with the keys is far far less safe than webpki, and this service could be relatively easily mitm'd in key scenarios like people being tricked at conferences. It's not as terrifying as the coffee shop taking payments over SSH, but still, this isn't doing E2EE, it's terminating TLS upstream.
There's no SSHFP record (not that openssh uses it by default, and you'd need DNSSEC to make it actually useful), and no public keys documented anywhere to help people avoid MITM/TOFU events.
I get the UX, but it saddens me to see more SSH products that don't understand the SSH security model.
To the author, I wish you best of luck with this but be aware (if you aren't) this will attract all kind of bad and malicious users who want nothing more than a "clean" IP to funnel their badness through.
serveo.net [2] tried it 8 years ago, but when I wanted to use it I at some point I found it was no longer working, as I remember the author said there was too much abuse for him to maintain it as a free service
I ended up self-hosting sish https://docs.ssi.sh instead.
Even the the ones where you have to register like cloudflare tunnels and ngrok are full of malware, which is not a risk to you as a user but means they are often blocked.
Also a little rant, tailscale has their own one also called funnel. It has the benefit of being end-to-end encrypted (in theory) but the downside that you are announcing your service to the world through the certificate transparency logs. So your little dev project will have bots hammering on it (and trying to take your .git folder) within seconds from you activating the funnel. So make sure your little project is ready for the internet with auth and has nothing sensitive at guessable paths.
[2] https://news.ycombinator.com/item?id=14842951
reply