# https://tunnels.io/learn/what-is-a-reverse-tunnel

[Home](https://tunnels.io/) / [Learn](https://tunnels.io/learn) / What is a reverse tunnel?

Concepts

# What is a reverse tunnel?

A reverse tunnel is a network connection that a private machine opens outward to a public server, which the public server then uses to send traffic back in. The private machine never accepts an inbound connection, so it works from behind NAT, a home router, or a corporate firewall without any port being opened.

## How does a reverse tunnel actually work?

Three parties are involved: the service running on your machine, a small client process sitting next to it, and a public server with a routable address. The client dials out to that public server and holds the connection open. When a visitor hits the public address, the server does not try to connect to you; it hands the request down the connection you already established, and your client passes it to the local port and carries the response back the same way.

## How is it different from a normal tunnel?

Only the direction of the first connection changes, and that one detail changes everything else. A forward tunnel opens a port on your machine and reaches a service that already exists somewhere else, so the far end has to be reachable. A reverse tunnel publishes a service that lives on your side, so the far end only has to be reachable by you.

| | Forward tunnel | Reverse tunnel |
| --- | --- | --- |
| Who opens the connection | The machine that wants to reach the service | The machine that hosts the service |
| Where the public listener runs | Locally, on your own machine | Remotely, on the public server |
| Needs an inbound port at the service | Yes, the destination must already be reachable | No |
| SSH equivalent | `ssh -L``, local forwarding | `ssh -R``, remote forwarding |
| Typical use | Reaching a database inside a network you can log into | Publishing a laptop service to the internet |

## Why does the direction matter for NAT and firewalls?

A home router performs network address translation, and it can only deliver a packet inward if it recognises the flow that packet belongs to. It learns those flows from connections you start, so an unsolicited packet arriving from the internet matches nothing in the table and gets dropped. Corporate firewalls apply the same rule on purpose, and carrier-grade NAT removes the workaround entirely, because there is no public address of your own to forward a port from. A reverse tunnel steps around all three, since the only connection anyone opens is an ordinary outbound one that every default policy already permits.

## What problem does this actually solve?

Your laptop has no public address, and the things that need to call it do not care. A payment provider delivering a webhook, a client opening a staging build on their phone, an identity provider redirecting to a callback URL, a test device on a different network hitting your API: every one of them needs a hostname that resolves and an address that answers. A reverse tunnel supplies both without touching your router, your DNS, or your employer's firewall policy. [Exposing localhost](https://tunnels.io/learn/how-to-expose-localhost) covers the alternatives and why most of them are worse.

## Is it the same as SSH remote port forwarding?

SSH remote forwarding is the original reverse tunnel. `ssh -R 8080:localhost:3000 user@server`` asks the remote SSH daemon to listen on port 8080 and push whatever arrives back down your session to port 3000 on your machine. It is a real reverse tunnel and it stops there: you still need a server you control, a DNS record, a TLS certificate, and `GatewayPorts yes`` in the daemon config before anyone other than that server can reach the port. [SSH tunneling](https://tunnels.io/learn/what-is-ssh-tunneling) has the full command set.

## How does a reverse tunnel stay open?

The connection has to be long lived, and much of the network between you and the server would prefer otherwise. NAT devices expire idle mappings after minutes, and the operating system default for TCP keepalives is far too slow to prevent that, so the client sends its own heartbeat to hold the path open and to detect a dead peer quickly. When the link does break, on a laptop suspending, a Wi-Fi change, or a server restart, the client reconnects and registers again. On a plan that issues a random URL, each fresh registration means a fresh hostname, which is why anything with a callback registered against it wants a stable subdomain.

## What are the security implications?

A reverse tunnel is an inbound path that your perimeter firewall never approved, which is precisely why the same technique shows up in intrusion reports. Treat starting one as publishing: whoever holds the URL reaches whatever is listening on that port, and development servers routinely ship with debug endpoints, verbose stack traces, and no authentication, because they assume nothing outside can talk to them. Expose the narrowest port you can, put authentication in front of anything that matters, and shut the tunnel down when you are finished. On a managed network, check the policy before you start; the fact that it works is not the same as being allowed.

## Related reading

[Reaching a home server behind CGNAT What this looks like on a box that runs permanently, and what it costs in bandwidth.](https://tunnels.io/use-cases/homelab) [What is tunneling? The general idea: carrying one protocol inside another so it crosses a network that would not otherwise take it.](https://tunnels.io/learn/what-is-tunneling) [What is SSH tunneling? Local, remote and dynamic forwarding, the exact commands, and where SSH stops being enough on its own.](https://tunnels.io/learn/what-is-ssh-tunneling) [How to expose localhost Tunnel, SSH forwarding, router port forwarding, or deploy it. The honest trade-offs of each approach.](https://tunnels.io/learn/how-to-expose-localhost)

More in the [Learn hub](https://tunnels.io/learn).

## Common questions

### Is a reverse tunnel the same as a reverse proxy?

No. A reverse proxy accepts requests and forwards them to a backend it can already reach across the network. A reverse tunnel is what creates that reachability in the first place, by having the backend dial outward. Tunnel services usually run both: a reverse proxy at the public edge, and a reverse tunnel from that edge down to your machine.

### Do I need to open a port on my router?

No, and avoiding that is the entire point. The only connection made is an outbound one from your machine to the tunnel server, which home routers and most corporate firewalls already permit by default. Port forwarding, dynamic DNS and a static IP address all become unnecessary.

### Does a reverse tunnel work behind CGNAT?

Yes. Under carrier-grade NAT your router holds no public address of its own, so port forwarding cannot work however you configure it. A reverse tunnel does not need one, because the public address belongs to the tunnel server and your side only ever makes outbound connections.

### Can a reverse tunnel carry protocols other than HTTP?

That depends on the implementation. The tunnels.io engine carries HTTP, HTTPS and raw TCP, which covers web apps, APIs, webhooks, SSH and most databases. It does not carry UDP or SMTP, so anything built on those needs a different approach. TCP tunnels require a paid plan; the free plan is HTTP only.

### How long can a reverse tunnel stay connected?

As long as the client process runs and the network path survives. Heartbeats keep NAT mappings alive and reconnect logic handles the drops, so a tunnel can stay up for days. Each reconnect on a random-URL plan produces a new hostname, which is why a registered webhook wants a reserved subdomain instead.

## How does tunnels.io use a reverse tunnel?

tunnels.io is a reverse tunnel with the operational parts already handled. You run one command next to your service, the client opens an outbound encrypted connection to our edge, the edge allocates a public HTTPS hostname with a valid certificate, and requests land on your local port. Nothing is opened on your router, and there is no interstitial or warning page on any plan, including the free one.

The free Basic plan costs nothing and gives you 4 GB a month, one tunnel and a random URL, at a sustained 1,024 requests per second. Pro is $4 a month, or $40 a year, for 128 GB, five tunnels, up to three reserved subdomains, TCP tunnels and 8,192 requests per second. Gold at $10 a month adds custom domains, 256 GB and 16,384 requests per second, and Premium at $20 a month brings 512 GB, unlimited tunnels and an unlimited request rate.

[Get started →](https://tunnels.io/get-started) [Back to Learn](https://tunnels.io/learn)