Understand that the firewall supports three types of source NAT: static IP, dynamic
IP, and dynamic IP and port (DIPP).
Internal users typically use source NAT to access the internet; the source address is translated
and thereby kept private. There are several types of source NAT: static IP, dynamic IP,
and dynamic IP and port (DIPP). DIPP can be configured as non-persistent or
persistent.
Static IP—Allows the one-to-one, static translation of a source IP address, but leaves the
source port unchanged. A common scenario for a static IP translation is an
internal server that must be available to the internet.
Dynamic IP—Allows the one-to-one, dynamic translation of a source IP address only (no port
number) to the next available address in the NAT address pool. The size of the
NAT pool should be equal to the number of internal hosts that require address
translations. By default, if the source address pool is larger than the NAT
address pool and eventually all of the NAT addresses are allocated, new
connections that need address translation are dropped. To override this default
behavior, use Advanced (Dynamic IP/Port Fallback) to
enable use of DIPP addresses when necessary. In either event, as sessions
terminate and the addresses in the pool become available, they can be allocated
to translate new connections.
Dynamic IP and Port (DIPP)—Allows multiple hosts to have
their source IP addresses translated to the same public IP address
with different port numbers. The dynamic translation is to the next
available address in the NAT address pool, which you configure as
a Translated Address pool be to an IP address,
range of addresses, a subnet, or a combination of these.
As
an alternative to using the next address in the NAT address pool,
DIPP allows you to specify the address of the Interface itself. The
advantage of specifying the interface in the NAT rule is that the
NAT rule will be automatically updated to use any address subsequently
acquired by the interface. DIPP is sometimes referred to as interface-based
NAT or network address port translation (NAPT).
(Affects only PA-7000 Series firewalls that do not use second-generation PA-7050-SMC-B or
PA-7080-SMC-B Switch Management Cards) When you use Point-to-Point
Tunnel Protocol (PPTP) with DIPP NAT, the firewall is limited to using a
translated IP address-and-port pair for only one connection; the firewall does
not support DIPP NAT. The workaround is to upgrade the PA-7000 Series firewall
to a second-generation SMC-B card.
When you configure regular (non-persistent) DIPP on a multi-data plane (DP)
firewall model, the oversubscription rate applies to the local pool; it's not
enforced across DPs. A source port from one DP can be reused by a different DP.
Reusing ports for regular DIPP is fine because regular traffic goes to different
destinations. In this graphic, both sessions have their source translated to
200.0.0.1/2001:
(
PAN-OS 11.1.0 and earlier releases)
Persistent NAT for DIPP
(also referred to as persistent DIPP or persistent NAT)—Available on all
firewalls. VoIP, video, cloud-based video conferencing, audio conferencing, and
other applications often use DIPP and may require the Session Traversal
Utilities for NAT (STUN) protocol. DIPP NAT uses symmetric NAT, which may have
compatibility issues with applications that use STUN. To alleviate these issues,
persistent NAT for DIPP
provides additional support for connectivity with such applications.
In PAN-OS 11.1.0 and earlier releases, when you enable persistent NAT for DIPP,
it applies to all NAT and
NAT64 rules; it is a global setting.
Management plane or dataplane logs will indicate
NAT DIPP/STUN
support has been enabled.
When persistent NAT for DIPP is enabled, the binding of a private source IP
address/port pair to a specific public (translated) source IP address/port pair
persists for subsequent sessions that arrive having that same original source IP
address/port pair. The following example shows three sessions:
In this example, original source IP address/port 10.1.1.5:2966 is bound to the
translated source IP address/port 192.168.1.6:1077 in Session 1. That binding is
persistent in Session 2 and Session 3, which have the same original source IP
address/port, but different destination addresses. The persistence of the
binding ends after all of the sessions for that source IP address/port pair have
ended.
In Session 1 of the example, the Destination port is 3478, the default STUN
port.
The persistent NAT for DIPP setting (enabled or disabled) survives across
firewall reboots.
With regular DIPP NAT rules, multiple pairs of the same [source IP address/port]
combination sending traffic to different destinations will get different
translations. With persistent DIPP rules, multiple pairs of the same [source IP
address/port] combination sending traffic to different destinations will get the
same translation, as illustrated with the three sessions above.
Persistent NAT cannot reuse port numbers among DPs because if multiple DPs tried
to use the same port number, some sessions might fail to reach STUN, as shown
here:
The solution is to partition the source ports among the DPs; thus port numbers
will be unique and you avoid duplicate sessions:
(
PAN-OS 11.1.1 and later releases)
Per-Policy Persistent
DIPP—Beginning with PAN-OS 11.1.1 and later releases, you
configure persistent DIPP in individual NAT
policy rules instead of globally. When you are using NAT or
NAT64 for video or voice applications
behind the firewall and you need to access STUN, create a NAT policy rule using
a translation type of
Persistent Dynamic IP And Port.
Per-policy persistent DIPP allows regular (non-persistent) DIPP and persistent
DIPP to coexist because persistent DIPP isn't global; the granularity is within
a NAT policy rule. When persistent DIPP is configured globally, there are only
64,512 source ports available system-wide, restricting the total number of
translations even for regular DIPP traffic. By allowing regular DIPP and
persistent DIPP rules to coexist in the system, regular DIPP doesn't have to
share ports with persistent DIPP, and can have an oversubscription rate greater
than 1, unleashing the total number of regular DIPP translations.
Persistent DIPP rules and regular DIPP
rules can be translated to the same IP address ranges. To achieve the best
performance, configure persistent DIPP and regular DIPP to manage separate
source port pools because the traffic should go to different destinations.
Separate port pools can have overlapping port ranges.
For persistent DIPP rules, the oversubscription rate is 1 (no oversubscription).
Regular DIPP rules use the oversubscription rate set in the system
configuration. This design yields the best performance when persistent DIPP is
enabled on the firewall.
As this graphic shows, the purple sessions from DP0 and DP1 use a regular NAT
rule and use the same translated source IP address/port (200.0.0.1/2000). They
have different destination IP addresses to the internet. The orange sessions
from DP0 and DP1 are destined for a STUN port. They use a persistent DIPP NAT
rule and use the same translated source IP address (200.0.0.1) but different
port numbers (32001 and 63488).
In summary, per-policy persistent DIPP allows two types of traffic to coexist on
a firewall (regular DIPP and persistent DIPP). Regular DIPP rules and persistent
DIPP rules can share a single translated IP address (note the four sessions in
the graphic all have a translated source address of 200.0.0.1). Regular DIPP
rules can share the same source translated IP address and port (the purple
sessions) because they have different destinations. Regular DIPP rule type and
persistent DIPP rule type can each control its own source port pool.
Persistent DIPP doesn't support hot swapping of line cards.