Tunnl.gg(tunnl.gg) |
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.
It's still live though.
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 don’t have tunnl.gg usage numbers but I’m going to guess they are no where near the threshold — we were also rejected.
> 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.
So anyway try it like:
tailscale funnel --set-path=/A8200B0F-6E0E-4FE2-9135-8A440DB9469D http://127.0.0.1:8001 or whatever
I use uuidgen and voila.
https://tunnl.gg/assets/index-Bjpn0hFX.js
If the requesting party knows it's possible they might ask for traffic to be logged
It wouldn't take much for law enforcement or a judge to force cooperation.
For the second point, you might want to implement some kind of browser warning similar to what Ngrok does.
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.
Any plan to make it oss?
``` tunnl() { if [ -z "$1" ]; then echo "Usage: tunnl <local-port>" return 1 fi
ssh -t -R 80:localhost:"$1" proxy.tunnl.ggThere's also https://tunnelmole.com but requires binary or npm install
What it does:
- Expose localhost to the internet (HTTP/TCP/WebSockets) - Zero signup – just works immediately - Free
Nothing groundbreaking, just scratching my own itch for a no-friction tunnel service. Written in Go.
Link: https://tunnl.gg
Happy to answer questions or hear how you'd improve it.
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'd rather pay a few dollars for a service that will be around 5 years from now, than pay nothing and have to deal with churn.
I can create any subdomain I want and tunnel the connexion to any port on my computer.
=> I can spinup a new subdomain in seconds, no data leakage, url that doesn't change, and it's cost nothing.
Also do you collect any data? Privacy says
> We do not collect, store, or sell your personal data.
But I guess personal data is a bit ambiguous. You're at the very least collecting my IP (which is fine, I'm just curious)
Only regular SSH to serve, regular SSH to connect. No public URLs though (it's not for web services).
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.
Direct real-time connections could be a path like nl.gg/# or a private key that someone could change. Some way to have a public site thats hosted globally for 'nearly free' while also being able to locally host a private url to the dev version for sharing temporarily while your connected. Maybe even a totally different domain.
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.
One path I looked at was to use the VirusTotal API to help identify C2's that other security organizations were identifying and leverage that to automatically take down malicious TCP endpoints. I wrote some POCs but did not deploy them. It's something I plan on taking up again at some point next year.
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.
Though the public address is going to be random here so how will the hacker figure out which tunnl.gg subdomain to gobble up?
A permanent SSH connection is not exactly discreet, though...
Specifically: https://github.com/BrowserBox/ariadne/blob/f07e3b0d445f5d4a8...
feel free to give me a ping on https://discord.gg/AXAbujx @patrick.
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.
It's possible when it gets to be a drain, even charging pennies for the service could drive off the bad actors making it unsustainable though.