A service can be running on your home server and still be unreachable from the internet. If the server sits behind a router using NAT, the router needs a rule telling it where to send new inbound connections. That rule is port forwarding.
Understanding the path—and the other things that must be in place—makes it much easier to set up safely and troubleshoot.
What a port-forwarding rule changes
Devices on a home network usually have private IP addresses, such as 192.168.1.50. Your router has a public IP address that outside clients can reach. Network address translation (NAT) lets multiple devices share that public address for outbound connections.
When a device inside the network requests a website, the router tracks the connection so it can route the reply back to the right device. But a new inbound connection has no such history. Without a rule, the router generally doesn't know which internal device should receive it.
Port forwarding supplies that destination. For example, a rule could map:
Public address:8080 → 192.168.1.50:80
An outside client connects to port 8080 on the public address. The router forwards the connection to port 80 on the private device. The external and internal ports don't have to match.
The router does not start the service. The destination machine still needs to be running the service and listening on the internal port.
The fields you need to get right
Router interfaces use different labels, but a typical rule asks for:
- Destination device or private IP: the machine running the service.
- External port: the port an outside client will connect to.
- Internal port: the port where the service listens on that machine.
- Protocol: TCP, UDP, or both, as required by the service.
Use the protocol the service actually expects. Forwarding TCP when the service needs UDP—or the other way around—won't make it reachable. Use a port range only if the service requires multiple consecutive ports.
Keep the destination address stable. If the device gets a different private IP address, the rule may point to the wrong machine. A DHCP reservation or a fixed address managed on the network can help prevent that.
Forwarding is not the same as allowing a firewall port
A router rule and a firewall rule solve different parts of the problem. Port forwarding directs matching inbound traffic to a device. The device's own firewall may still block it. The service must also be listening on the expected port.
Think of the connection as a sequence: the router receives it, the forwarding rule selects a destination, the machine's firewall permits or blocks it, and the service handles it. A failure at any step can look like “port forwarding doesn't work.” For a Linux machine using UFW, the UFW port rule guide explains the separate host-firewall step.
Router forwarding and SSH tunnels are different
Router port forwarding makes a service reachable through your public IP. An SSH tunnel carries traffic through an existing SSH connection instead; it doesn't require a router forwarding rule. If you only need to reach a database or dashboard through a server you can already SSH into, SSH tunneling may be a better fit than making that service internet-accessible.
A VPN or managed remote-access option can also be more appropriate when you need access to a private network, rather than public access to one service.
Troubleshoot in a useful order
If a forwarded service is unreachable, check each layer:
- Confirm the service is running and listening on the expected internal port.
- Check the rule's destination IP and ports. Make sure the private IP is the service's device and that the external-to-internal mapping is correct.
- Verify TCP or UDP. The rule must match the service's protocol.
- Check the device firewall. A router rule does not automatically permit traffic through the machine's firewall.
- Test from outside your network. Some routers don't support connecting to their public address from a device on the same LAN, so an inside-the-house test can mislead you.
- Look for another NAT layer. If there's an ISP gateway plus a separate router, both may need appropriate forwarding. If the ISP uses carrier-grade NAT (CGNAT), the inbound connection may never reach your router at all.
A router WAN address in 100.64.0.0/10 is a strong sign of CGNAT. More generally, if the router's WAN address differs from the public IP reported by an external service, another NAT layer may be upstream. Router configuration alone can't fix traffic that is stopped before it reaches your router. Options can include asking the ISP for a public IP, using IPv6 where both the ISP and connecting clients support it, or using a reverse tunnel or relay that doesn't depend on inbound access.
If your public IP changes, the forwarding rule can remain intact while clients continue trying the old address. Dynamic DNS can keep a hostname pointed at the current public IP.
Expose only what you intend
A forwarded port makes the service reachable to people on the internet—not just to you. The risk depends on the service, its authentication, and whether it is maintained and patched. Forward only services designed to be exposed, use strong authentication, and remove rules you no longer need.
Avoid using a DMZ as a quick fix. Unlike a rule for a particular service, a DMZ can forward every port to one internal device, exposing far more than intended.
Port forwarding doesn't improve bandwidth or reduce latency by itself. Its job is to direct new inbound connections to a chosen device and service. When you configure one, verify the service, router rule, protocol, and firewall as separate parts of the path.
I originally published a more detailed version of this guide on the SSHFlow blog.
I'm also building SSHFlow — an SSH client where every server gets its own workspace for terminals, SFTP, code, and databases.
Top comments (0)