4.9.4.7–4.9.4.9 - DHCP, NAT and port forwarding

Automatic configuration with DHCP

DHCP supplies a host with the network configuration it needs without someone manually entering every setting.

DHCP, Dynamic Host Configuration Protocol, uses a server to allocate configuration from an administratively controlled pool. A typical IPv4 client receives an IP address, subnet mask, default gateway/router address, DNS server addresses and a lease duration. The subnet mask determines local-network membership; the gateway is used to reach other networks; DNS resolves names. These are separate settings with different purposes.

A simplified new-client exchange has four stages:

1. Discover: the client initially broadcasts to find DHCP servers because it does not yet know which server can configure it.
2. Offer: a server offers an available address and associated configuration.
3. Request: the client requests the offered configuration it has selected.
4. Acknowledge: the server confirms the allocation; the client installs the settings and may use the address.

The server records the lease so it does not intentionally allocate the same address to two active clients on the same subnet. The client attempts renewal before its lease ends; if a lease expires without renewal, it must stop using that leased configuration. Releasing/expiring leases allows addresses to be reused. DHCP reduces repetitive administration and manual typing errors, particularly where laptops join and leave frequently. It cannot supply more addresses than the configured pool provides, and poor pool configuration can still cause problems.

Some equipment needs a predictable address. It can use a manually configured address outside the dynamic pool, or a server reservation which supplies a chosen address to a recognised client. “Dynamic configuration” does not require a different address every time a device connects. DHCP also does not translate traffic: that is NAT's role.

Address translation at a gateway

NAT changes address information as packets cross a gateway between private and public address spaces.

NAT, Network Address Translation, maps an address used on one side of the gateway to an address on the other side. A private IPv4 host cannot simply use its private source address as a globally unique return destination. On outgoing traffic, the gateway substitutes a public source address and records the association. On matching incoming replies, it translates the destination back to the private host and forwards the packet internally.

A common many-to-one arrangement also translates TCP/UDP ports, called NAPT or PAT. The outside address can then be shared by several hosts and connections. Distinct translated ports let the gateway determine which internal endpoint should receive each reply. Basic address-only NAT and address-plus-port translation should not be confused; the latter is what makes this common sharing example work.

Consider two hosts contacting the same external HTTPS service. The gateway creates these illustrative TCP mappings:

203.0.113.8 is a documentation address representing the gateway's public address in this example, not a live allocated destination. The two internal hosts can use the same source port because their internal IP addresses differ. The gateway uses different outside ports so incoming replies can be distinguished. A reply addressed to 203.0.113.8:62002 is translated to 192.168.10.13:51000. The external server's own service port is not the internal host's source port.

This conserves public IPv4 addresses: an organisation can use a private internal range while sharing a smaller number of public addresses. It can also reduce dependence on an external address allocation when organising internal addressing. NAT is not encryption or a substitute for authentication/firewall policy. Its stored state also complicates unsolicited incoming connections, because an incoming packet with no matching mapping may not identify an internal destination.

Incoming connections and port forwarding

Port forwarding provides a configured destination for an incoming connection that should reach a service behind a gateway.

An outside client knows the gateway's public address but cannot directly target a private internal address across the Internet. A port-forwarding rule associates an incoming protocol and public port with a specified internal IP address and service port. The gateway matches the rule, changes the destination as required and forwards the traffic. Return traffic is translated consistently so the outside client continues to see the gateway's public endpoint.

For example, a lab might configure TCP port 8443 at its public gateway to forward to 192.168.10.40:443, where an internal HTTPS server listens. The remote client connects to the public address on 8443. The gateway forwards that connection to internal port 443. The external and internal port numbers may be identical, but need not be. A rule for TCP does not automatically describe a UDP service.

The internal server needs a stable/predictable address, perhaps provided by a DHCP reservation, so the rule keeps pointing at the right machine. The server must be running and listening on the destination port, and firewall policy must permit the intended traffic. Port forwarding does not create the server or guarantee access through every upstream network. It is used when deliberate external access is required, such as access to a hosted service, rather than for every ordinary browser reply: those replies can use the outbound mapping already created by NAT.

Exposing a service allows connection attempts from outside. Administration should restrict permitted sources where appropriate, keep the service maintained and use its authentication/encryption protections. Moving a service to an unusual public port is not by itself strong security. The purpose of forwarding is reachability, not making application data secret.