What Is Port Forwarding? How Inbound NAT Rules Work

Standard many-to-one translation, usually called PAT or NAT overload, keeps a state table of outbound conversations. Each entry records the internal address and port, the external address and port the translator substituted, the protocol, and the remote endpoint. Return traffic is matched against that table and translated back. The table is built by outbound packets, so an unsolicited inbound packet arrives with nothing to match and is discarded — not as a security decision, but because the translator genuinely does not know where to send it.

A port-forwarding rule is a permanent, pre-populated entry in that logic. It declares that TCP or UDP traffic arriving at the public address on a given port belongs to a particular internal host and port, so the translator rewrites the destination and forwards it. The external and internal port numbers do not have to match — publishing an internal service listening on 8080 as public port 443 is a normal configuration — and the rule is per protocol, so a service that uses both TCP and UDP needs both. This is destination NAT, the mirror image of the source NAT that handles outbound traffic.

Two structural properties follow from that. First, a given public port on a given public address can only be forwarded to one internal host, which is why publishing several internal web servers on port 443 requires a reverse proxy or additional public addresses rather than more forwarding rules. Second, the internal host must keep the address named in the rule, so it needs a static address or a reserved DHCP lease — a device that gets a new address after a reboot silently breaks the rule, which is one of the most common causes of a service that worked last month and does not today.

Consumer routers collapse translation and permission into one setting, and that collapse is the source of most of the trouble. On an enterprise firewall the two are separate: a destination-NAT rule describes the rewrite, and a security policy decides whether the rewritten traffic is allowed. Getting the NAT rule right and forgetting the policy produces traffic that is translated and then dropped; getting the policy right and forgetting the NAT rule produces traffic that never arrives. Both failures look identical from outside, which is why the first troubleshooting step on a firewall is always to check which of the two rules matched.

The separation is worth the extra step because the policy can be narrowed in ways a router checkbox cannot. The source can be restricted to a named set of addresses — a partner's range, a monitoring provider, a small list of office and site addresses — so the service is published to those sources rather than to the internet. The policy can be time-bounded, logged per session, attached to an application signature rather than a raw port, and routed through inspection. A forwarded port with a source restriction is a different risk from an open one, and the difference is entirely in the policy.

Where the destination lands matters as much as who can reach it. A published service belongs in a screened segment, not on the internal LAN, so that a compromise of the exposed host does not put the attacker on the same broadcast domain as everything else. That is the entire purpose of a DMZ: the forwarding rule delivers to the segment, and a second policy governs what that segment may initiate back into the internal network — which should be a short, specific list rather than any.

A forwarding rule is a routing instruction, not a security control. It does not authenticate the client, inspect the payload, rate-limit anything, or distinguish a legitimate user from an automated scanner. Once the rule exists, the entire public internet can reach that service, and whatever authentication the service itself implements has become the perimeter. If the service has a default credential, an unpatched vulnerability, or no authentication at all, the forwarding rule has published exactly that.

Address translation is often described as a firewall because unsolicited inbound traffic is dropped by default. That side effect is real and it is not a security policy: it has no concept of allow or deny, it applies no rules you wrote, and it disappears entirely for any port you forward. Treating translation as protection is the reason forwarded ports are so often left in place after the project that needed them finished — nobody recorded them as exposure, because nobody thought of them as holes.

Remote administration is the case where this goes wrong most expensively. Remote desktop, SSH, VNC, database ports, hypervisor consoles, camera and building-control interfaces and device management pages are all routinely forwarded for convenience, and all are continuously scanned. CISA's Binding Operational Directive 23-02, issued in June 2023, requires federal civilian agencies to remove internet-exposed networked management interfaces from the public internet — or place them behind a zero-trust policy enforcement point separate from the interface itself — within fourteen days of discovery, with the second option stated as the preferred one. The directive binds federal agencies; the reasoning behind it applies to any organization with a management interface on a forwarded port.

Three protocols let an application on the inside create its own forwarding rule without an administrator. UPnP Internet Gateway Device is the oldest and most widespread. NAT-PMP, documented in RFC 6886, was the lighter alternative, and it was superseded in 2013 by the Port Control Protocol in RFC 6887, which adds IPv6 support, management of outbound mappings and firewall rules, and compatibility with large-scale carrier translators. All three exist to solve a genuine problem: peer-to-peer applications, real-time voice and video, and games need inbound reachability that a static rule cannot anticipate.

The security consequence is direct. On a network where automatic mapping is enabled, any process on any internal device — including malware and including a guest's laptop — can ask the gateway to open an inbound path to itself, and in the common implementations that request is not authenticated against any administrative identity. The rule appears in the gateway, it does not appear in anyone's change record, and it can outlive the application that requested it.

For business and government networks the answer is usually to disable automatic mapping on the edge device and provision the small number of genuinely required inbound paths by hand, where they can be reviewed, source-restricted and audited. PCP does define authentication mechanisms and gives an operator far more control than UPnP, so on equipment that implements it properly there is a middle path — but the decision should be an explicit one, and the starting position on a managed network is off.

When a correctly written rule does not work, the cause is usually upstream of the firewall. If the circuit sits behind a provider-side translator, there is no public address to forward from — the router's WAN address is one the provider shares among subscribers, and inbound connections never reach it. A second translating device in series produces the same result for a rule written on the inner one. Both are worth confirming before rewriting the rule, and both are covered in more detail on the address-translation page, along with the related loopback problem where a service is reachable from outside and not from inside.

The other frequent causes are local. The internal host changed address; the service is bound to localhost rather than to the interface; a host firewall on the destination is dropping the traffic the network firewall correctly delivered; or the rule specifies TCP for a service that also needs UDP. On a firewall, the session log tells you which of these it is in one look — whether a session was created, which policy matched, and whether the far end responded — which is a good reason to enable logging on the rule at the moment you create it rather than the day it breaks.

IPv6 removes the translation step entirely. With globally routable addresses on internal hosts there is nothing to rewrite, so there is no forwarding rule — only a firewall policy that permits or denies inbound traffic to a specific address and port. That is a simpler and more honest model, and it removes the accidental protection that translation provided, which means the firewall policy is now doing all of the work explicitly. Networks running both protocols should check that an IPv4 rule and its IPv6 equivalent actually match; a service correctly restricted on IPv4 and wide open on IPv6 is a recurring finding.

For administrative access, the durable answer is not to publish the interface at all. A remote-access VPN puts the administrator on the network before they touch the management port, so the port is never internet-facing. A zero-trust network access broker goes further: the internal connector dials outward to the broker, there is no listening port on the public internet, and each session is authorized per application against identity and device posture rather than per network. For device and console access specifically, a hardened jump host in a screened segment collapses many exposed ports into one monitored path, and a dedicated out-of-band management network — the arrangement NSA and CISA guidance recommends, with physical separation as the strongest form — keeps management traffic off the operational network entirely.

For services that genuinely must be public, put something in front of the origin rather than forwarding to it. A reverse proxy or web application firewall terminates the connection, inspects the request and forwards only what passes, which also lets many internal services share one public address and port. That is a different architecture from port forwarding even when the packet ends up in the same place, because there is now a component whose job is to judge the traffic.

If a forwarded port is the answer, treat it as an exception with an owner. Restrict the source addresses to the smallest workable set, terminate in a screened segment rather than on the internal LAN, log the rule, require multi-factor authentication on the service behind it, keep that service patched on a shorter cycle than the rest of the estate, and put a review date on the rule so it is removed when the reason for it ends. And do not count port obfuscation as a control — moving a service to a high, unusual port removes it from casual scanning and not from anything that scans the full range, which is most of what finds it.