Jun 17, 2024
Jun 17, 2024
You’re running a local LLM on your workstation and a teammate on the other side of the country wants to try it out. Or you need to expose a webhook endpoint so Stripe can reach your laptop during development. Or you’re connecting branch office networks so services in one location can talk to services in another. The classic answer to all of these is port forwarding. In 2026, that answer comes with a lot of asterisks.
Port forwarding is a networking technique that lets devices outside a private network reach applications, services, or devices running inside it. It works by mapping a port on the network’s gateway, like a router or firewall, to an address on the internal network. Think of it as opening a specific door on your network and telling traffic exactly where to go once it walks through.
In networking, these doors are called ports. Each one gets a unique number, and by configuring your router or firewall to forward traffic from an external port to an internal one, you selectively grant access to whatever is listening on the other side.
Port forwarding shows up in a surprising number of workflows, from development to operations to just getting two networks to talk to each other.
Webhook and API development is one of the most common use cases. Services like Stripe, GitHub, and Twilio need to send HTTP callbacks to your application, but your app is running on localhost. Port forwarding (or a tunnel) gives those services a way to reach you during development without deploying to a staging server every time you change a line of code.
Sharing local AI and LLM apps has become a daily workflow for many teams. You’re fine-tuning a model or building a chat interface on your local GPU, and you want a colleague, a PM, or a client to interact with it live. Port forwarding lets you hand someone a URL to your machine without pushing anything to the cloud. That keeps large model weights off remote servers and your iteration cycles fast.
Site-to-site connectivity is the enterprise version of the same idea. Organizations with multiple offices, data centers, or edge locations need services in one network to reach services in another. Traditional approaches involve VPN tunnels and complex routing rules, but the goal is the same: make a service on network A reachable from network B as if it were local.
Remote management lets system administrators access servers, IoT devices, and edge infrastructure without being physically present. Whether it’s SSHing into a Raspberry Pi at a remote site or managing a fleet of devices behind NAT, port forwarding provides the path in.
Self-hosting and gaming still rely on port forwarding too. Hosting a Minecraft server, running a media server, or making any self-hosted application reachable from outside your home network all require opening the right ports.
Let’s say you want to share a web app you’re building with a client, or let a teammate hit a local LLM endpoint. Port forwarding makes this possible by letting people outside your network connect to a specific device inside it. Here’s the flow:
Think of your router as a receptionist. When someone outside your network tries to connect, the router checks its directory (the port-forwarding rules) to figure out which internal device should take the call. The receptionist doesn’t handle the conversation. They just make sure it gets to the right desk.
The textbook version of port forwarding assumes you have a public IP address and full control of your router. That assumption is breaking down.
Carrier-Grade NAT (CGNAT) is the biggest obstacle. As IPv4 addresses have run out, many ISPs now share a single public IP across dozens or hundreds of customers. If you’re behind CGNAT, you don’t have a public IP to forward ports on. Your router’s “public” address is actually a private one inside your ISP’s network. Traditional port forwarding simply doesn’t work in this scenario, and there’s no router setting that can fix it.
Nested network layers make things worse. If you’re running a service inside a Docker container, a devcontainer, a VM, or a cloud development environment like GitHub Codespaces, you may need to forward ports through multiple layers: container to host, host to router, router to the internet. Each layer adds configuration and potential failure points.
Dynamic IP addresses remain an issue for anyone without a static IP from their ISP. Your carefully configured port-forwarding rules break every time your public IP changes, and most residential ISPs change them regularly.
Even when port forwarding works, it comes with real security trade-offs.
You’re painting a target. Every open port is visible to automated scanners. Tools like Shodan and Censys continuously index the internet, and botnets probe exposed ports around the clock looking for vulnerable services. An open port on a residential IP will get scanned within minutes.
There’s no built-in access control. Traditional port forwarding is all-or-nothing. The port is open to the entire internet. There’s no authentication, no IP allowlisting, and no rate limiting at the forwarding layer. Any protection has to come from the application itself, and if that application has a vulnerability, it’s directly reachable.
Configuration errors compound fast. Port forwarding requires getting the right combination of internal IPs, port numbers, and protocols exactly right. A misconfiguration can silently expose the wrong service, leave ports open longer than intended, or create security holes that are hard to audit.
Zero-trust networking has become the standard security posture: no connection should be trusted by default, regardless of where it originates. Opening a port to the entire internet runs directly counter to that.
ngrok gives you what port forwarding promises, making local services reachable from anywhere, without the security risks, network headaches, or brittle configuration.
It works everywhere, including behind CGNAT. ngrok establishes an outbound connection from your machine to ngrok’s global network, so it doesn’t matter what your ISP, router, or network topology looks like. No ports to open, no router admin panels to dig through, no praying your IP doesn’t change overnight.
Security is built in, not bolted on. Every ngrok tunnel uses TLS encryption by default. Layer on OAuth authentication, IP restrictions, rate limiting, and other Traffic Policy actions, all without touching your application code. This aligns with zero-trust principles: every request is verified before it reaches your service.
It handles the nested-network problem. Running your app in Docker, a devcontainer, or a cloud IDE? ngrok runs alongside your app wherever it lives. One command and you have a public URL, no matter how many network layers sit between your service and the internet.
Site-to-site connectivity is a first-class feature. With ngrok endpoints, you can connect services across networks, offices, and cloud environments without configuring VPN tunnels or managing complex routing. Services on one network become reachable from another through ngrok’s network, with no firewall changes required.
Port forwarding is a fundamental networking concept, and understanding it is useful. But for actually getting things done, whether that’s sharing a local LLM with your team, testing webhooks, or connecting branch office services, ngrok is the tool that gets out of your way and lets you focus on your work.
