Endpoint-Dependent vs Endpoint-Independent¶
VPF supports two main methods of performing dynamic NAT on outbound connections: endpoint-dependent NAT (also known as “Symmetric NAT”), which is the default behavior, and endpoint-independent NAT (also known as “Full Cone NAT”). These methods influence how VPF allocates addresses and ports when performing translation and also what traffic connection states allow from remote hosts.
Endpoint-Dependent¶
Endpoint-dependent NAT is the default dynamic NAT behavior in VPF, and the most common type of NAT in firewalls and routers.
This type of NAT is reasonably secure as it strictly controls inbound traffic. However, due to this strictness, it is primarily useful for making outgoing connections from local clients to remote servers.
Warning
NAT is not a firewall or packet filter. NAT alone is not a secure method of protecting internal networks or devices. The best practice is to also employ filtering to only allow intended connections through TNSR.
When performing endpoint-dependent NAT, VPF considers the source and destination address, port, and protocol in both directions. VPF translates a packet from an internal host and port combination to an external address and port when communicating with a remote host and port. Return traffic to the translated address and port is only possible from that exact remote host, port, and matching protocol. As VPF performs these checks the same way outbound and inbound, this is considered “symmetric” NAT.
VPF will maintain the connection state so long as there is activity on the connection in either direction between the local and remote hosts. Once the connection expires or terminates and VPF removes the state, no inbound communication is possible.
See also
See Runtime Options for information on state timeouts.
Endpoint-dependent NAT can re-use translation addresses and ports for multiple connections so long as the remote address and port combinations are unique. This allows endpoint-dependent NAT to overload numerous internal clients on a single external IP address with the default range of external ports (Startup Options).
Endpoint-Independent¶
Endpoint-independent NAT enables remote hosts to initiate inbound connections to an internal host after that internal host initiates an outbound connection. This behavior facilitates use cases such as online gaming, peer-to-peer connections, and VoIP.
This behavior is less strict and less secure than endpoint-dependent NAT, but it also lets providers allow inbound traffic to customers without allocating routable addresses, manually defining forwarding rules, or using services such as UPnP IGD or PCP.
See also
Endpoint-independent NAT can be manually enabled on outbound dynamic NAT rules.
When performing endpoint-independent NAT, VPF considers the source address, port, and protocol in the outbound direction when setting up a connection state. Like endpoint-dependent NAT, VPF translates a packet from an internal host and port combination to an external address and port when communicating with a remote host and port. However, endpoint-independent NAT does not check the remote host and port on incoming traffic. Once VPF establishes a translation and creates a connection state, any remote host may send packets to the translated address and port with the same protocol and VPF will forward those packets to the internal address and port on the connection state. VPF tracks these inbound connections in separate “child” connection state entries which tie back to the original “parent” outbound translation state.
This type of NAT allows an internal client to make an outbound connection, for example to a STUN Server, to discover its external translated address and port and then inform peers of those values. So long as the connection state exists to translate using that external address and port, remote peers such as other players of the same game or peer-to-peer file transfer hosts can initiate inbound connections to that external address and port and reach the internal host.
Danger
Endpoint-independent NAT allows inbound packets from any remote host to the external translation IP address, port, and protocol matching an active connection state. This bypasses VPF filter rules since the packets are passed when VPF checks the connection state. As such, potentially harmful traffic could be forwarded from remote hosts to the internal host. Take appropriate cautions to secure local devices when using this mode.
Like endpoint-dependent NAT, once the connection expires or terminates and VPF removes the state, no inbound communication is possible. However, with endpoint-independent NAT VPF will maintain the connection state when there is activity on the original outbound (“parent”) connection or activity on any inbound (“child”) connections to the translated port.
See also
See Runtime Options for information on state timeouts.
Endpoint-independent NAT is more limited than endpoint-dependent NAT with how it can use external IP addresses and ports. Because it does not check the remote endpoint, once it allocates a translated port number to an internal host, it cannot reuse that port for connections from other internal hosts unless the protocol is different. As a consequence, endpoint-independent NAT requires more external IP addresses and/or larger port ranges to accommodate the same volume of clients as endpoint-dependent NAT.
For ICMP echo requests, VPF will use the ICMP ID in an echo request as an identifier in place of a port number. Echo replies should already use this identifier, so return traffic will flow as expected. However, for a remote host to initiate an ICMP request to the internal client, it must use the same identifier initially used by the internal client.
Packets using protocols other than TCP, UDP, and ICMP echo requests do not have an identifier usable by VPF. Due to this limitation, the best practice is to limit endpoint-independent NAT rules to TCP and UDP only in most environments. With these other protocols, whichever internal host sends a packet first will be associated with all traffic for that protocol on the assigned translation address. Additional outgoing requests from other internal clients using the same protocol will fail unless those clients are translated to a different address explicitly.
Compatibility¶
Endpoint-dependent NAT does not respect ports used in translations made by endpoint-independent NAT, and vice versa. Even so, it is still possible to use both types of NAT in the same environment with some care.
If rules using both types of NAT use the same external IP address and port ranges for translation, this can cause a conflict. The conflict results in client connections failing when both choose the same translation IP address and port for different connections.
To work around this limitation, ensure rules for each type use different translation addresses and/or ports. IP addresses and port ranges for translation can be set on a per-rule basis as described in Network Address Translation Operations. Rules for both NAT types must set non-overlapping NAT port ranges, or rules for one NAT type must set ranges which do not overlap the default range of external translation ports.
See also
The default range of NAT translation ports can be configured as described in Startup Options.