On a NAT router, what is port forwarding, and what happens to a packet when a rule maps public port 8443 to 192.168.1.10:443?
answer
- unsolicited inbound has no entry
- a static, administrator-written mapping
- destination rewritten on the way in
- same entry un-translates the reply
basics
~20 sPort forwarding is a static inbound NAT mapping: packets for the router's public address on a chosen port get their destination rewritten to an internal host and port, and the replies get their source rewritten back.
solid answer
~40 sWithout a rule, an unsolicited packet to the router's public address matches no mapping, so the NAT treats the router itself as the destination and nothing inside is reached. A rule such as `203.0.113.7:8443/TCP -> 192.168.1.10:443` is a static destination translation written before any traffic arrives: the router rewrites the destination address and port, updates the IP header checksum and the TCP checksum (which covers the addresses through its pseudo-header), and forwards the packet. The server sees the client's real address as the source. Its reply from `192.168.1.10:443` matches the same entry and leaves with source `203.0.113.7:8443`, so the client sees one consistent endpoint. Rules are per protocol: TCP 8443 and UDP 8443 are separate entries.
go deeper
Recall that unsolicited inbound traffic has no NAT entry, and that a forward is a static entry rewriting the destination address and port; walk one packet in and its reply out.
Explain which fields change in each direction, why the checksums must be updated, and why the server sees the client's real address.
Show how you would diagnose a forward that does not work: listener, internal address drift, reply path through another gateway, wrong protocol, an upstream NAT.
Frame a forward as exposure to every source on the internet, and weigh it against a relay, a dedicated address or IPv6 when deciding how a service should be reachable.
## Why inbound traffic needs a rule A NAT router that shares one public IPv4 address among a private network creates mappings automatically only for traffic that starts **inside**: an outbound packet creates the entry that later lets its replies back in. A packet that arrives unsolicited from the internet, addressed to the router's public address, matches no entry. Traditional NAT (RFC 3022) says such inbound sessions are treated as directed at the NAT router itself unless the target port is **statically mapped** to an internal node. So without a rule, a client cannot reach a web server at `192.168.1.10`: the packet's destination is the router, and the router either answers with its own service or discards the packet. **Port forwarding** is that static mapping. The administrator writes it once and it exists before any traffic arrives, unlike the dynamic entries that outbound traffic creates. The Port Control Protocol specification (RFC 6887) treats "mapping", "port mapping" and "port forwarding" as one term: packets sent *to* the external address, protocol and port have their destination translated to the internal address and port, and packets *from* the internal endpoint have their source translated to the external one. ## The rule in NAT terms | Field | Example value | |---|---| | Protocol | TCP | | External (public) endpoint | `203.0.113.7:8443` | | Internal endpoint | `192.168.1.10:443` | | Who may use it | any source address | | Lifetime | until the administrator removes it | The router selects the entry by the inbound packet's **destination address, protocol and destination port**. The packet's source is not part of a plain forwarding rule, which is why every host on the internet can use it. ## The packet walk Take a client at `198.51.100.20` connecting from its port 50000. 1. The client sends a TCP SYN from `198.51.100.20:50000` to `203.0.113.7:8443`. 2. The router finds the static entry for TCP 8443 and rewrites the **destination** to `192.168.1.10:443`. It also updates the IP header checksum and the TCP checksum, because the TCP checksum covers a pseudo-header that contains both IP addresses (RFC 3022). 3. The server receives a SYN from `198.51.100.20:50000` to `192.168.1.10:443`. The source is untouched, so the server sees, and can log, the client's real address. 4. The server replies from `192.168.1.10:443` to `198.51.100.20:50000` and hands the packet to its default gateway. 5. The router matches the reply to the same entry and rewrites the **source** to `203.0.113.7:8443`. 6. The client receives a reply from exactly the endpoint it contacted, and the handshake completes. No second rule is needed for the reply direction: one mapping translates both ways. ## What has to be true for it to work - **The service listens** on port 443 on an address the router can reach, not only on the loopback address. - **The internal address stays put.** If the server's address changes, the rule points at nothing or at another device; a fixed address or a DHCP reservation keeps the two in step. - **Replies go back through the same router.** If the server's default gateway is a different router, the replies never pass through this mapping, and the client discards them because they do not come from `203.0.113.7:8443`. - **The protocol matches.** A rule for TCP 8443 does nothing for UDP 8443; each protocol needs its own entry. - **The router's public address is really public.** If the router's own WAN address sits behind an upstream NAT, inbound traffic never reaches the router at all. - **Testing from inside is a different path.** Reaching the public address from the same LAN depends on the router reflecting that traffic, which is a separate behaviour from forwarding. ## External port vs internal port The two ports do not have to match. Forwarding `8443` to `443` lets the internal server keep its usual port while the public side uses another, typically because public `443` is already forwarded to another host or is held by the router's own management service. Clients must then put the external port in the URL. Changing the number is not a defence: scanners probe every port, so a service on an unusual external port is found about as quickly as one on its usual port. ## What port forwarding is not A forwarding rule is not an access-control rule. It makes the internal service reachable from **any** source address, so the service's own authentication and patching become the only protection on that port. Restricting which sources may use the mapping is a filtering decision made alongside the mapping, not part of the translation itself.
- Why does the internal server see the client's real address rather than the router's, and what does that require of the server's routing?A port-forwarding rule rewrites only the destination of inbound packets, so the source stays the client's own address, which lets the server log real clients. The price is that the reply is addressed to the outside client, so it must leave through the same router to be un-translated. If the server's default gateway is another router, the reply bypasses the mapping and the client discards it.
- Does the external port of a port-forwarding rule have to equal the internal port?No. A rule can translate the port as well as the address, as in public 8443 to internal 443. That is useful when the public port is already forwarded elsewhere or held by the router. Clients must then use the external port explicitly. It is not a security measure, because scanners probe the whole port range.
saying these in an interview costs you the question
- Port forwarding rewrites the outside client's source address to the router's address.
- The reply direction needs its own second forwarding rule.
- A forwarded port works even if the service listens only on loopback.
- A forwarding rule for TCP 8443 also covers UDP 8443.
- Moving the service to an unusual external port keeps attackers from finding it.