This article illustrates the behavior of Persistent NAT (formerly Cone NAT) and describes different types of Persistent NAT available on SRX devices.
Persistent NAT is a special type of Source NAT. As with a usual Source NAT, this feature creates a NAT binding for a particular combination of internal IP address and port (called internal transport address). All the traffic sourced from this combination matches the same NAT binding, and thus is translated to the same combination of reflexive IP address and port (called reflexive transport address). The NAT binding is created when an internal host establishes a flow session to an external host.
A special property of Persistent NAT is that the created Persistent NAT binding remains active even after the original session is closed. Furthermore, as long as Persistent NAT binding is active, it allows packets to be sent from the external network to the internal host (possibly establishing separate flow sessions). This is described in more detail in the Solution section, below.
Note: The term “transport address” means a combination of IP address and port (not just an IP address).
Topology
The configuration snippet below is used in the examples at the end of this section:
[edit]
user@srx# show security nat
source {
pool pnat-pool {
address {
172.16.10.1/32 to 172.16.10.100/32;
}
}
rule-set pnat {
from zone Internal;
to zone External;
rule pnat-rule {
match {
source-address 0.0.0.0/0;
}
then {
source-nat {
pool {
pnat-pool;
persistent-nat {
permit any-remote-host;
inactivity-timeout 1800;
}
}
}
}
}
}
}
proxy-arp {
interface ge-0/0/14.0 {
address {
172.16.10.1/32 to 172.16.10.100/32;
}
}
}
The configuration above defines a NAT rule that applies Source NAT to all the traffic from the Internal network to the External network. The reflexive IP address is selected from the pool: 172.16.10.1 – 172.16.10.100. In addition, the configuration enables Persistent NAT.
At this point, the security policy called itoe-pol is configured:
[edit]
user@srx# show security policies
from-zone Internal to-zone External {
policy itoe-pol {
match {
source-address host-192.168.1.1;
destination-address any;
application any;
}
then {
permit;
}
}
}
Creating Persistent NAT binding
An SSH connection is opened from the internal host, 192.168.1.1, to the external host, 172.16.1.1. The created flow session and Persistent NAT binding are shown below:
user@srx> show security flow session destination-prefix 172.16.1.1 Session ID: 12610, Policy name: itoe-pol/5, Timeout: 1792, Valid In: 192.168.1.1/39192 --> 172.16.1.1/22;tcp, If: ge-0/0/15.0, Pkts: 201, Bytes: 12861 Out: 172.16.1.1/22 --> 172.16.10.2/7592;tcp, If: ge-0/0/14.0, Pkts: 263, Bytes: 27277 Total sessions: 1 user@srx> show security nat source persistent-nat-table pool pnat-pool Internal Reflective Source Type Left_time/ Curr_Sess_Num/ Source In_IP In_Port I_Proto Ref_IP Ref_Port R_Proto NAT Pool Conf_time Max_Sess_Num NAT Rule 192.168.1.1 39192 tcp 172.16.10.2 7592 tcp pnat-pool any-remote-host -/1800 1/30 pnat-rule
The session matched the itoe-pol policy, as expected. The internal transport address is 192.168.1.1/39192. The allocated reflexive transport address is 172.16.10.2/7592.
The SSH session is now closed, but the Persistent NAT binding remains active:
user@srx> show security nat source persistent-nat-table pool pnat-pool Internal Reflective Source Type Left_time/ Curr_Sess_Num/ Source In_IP In_Port I_Proto Ref_IP Ref_Port R_Proto NAT Pool Conf_time Max_Sess_Num NAT Rule 192.168.1.1 39192 tcp 172.16.10.2 7592 tcp pnat-pool any-remote-host 1792/1800 0/30 pnat-rule
Traffic from External Hosts
While Persistent NAT binding is active, external hosts are allowed to establish new flow sessions to the internal host using internal host’s reflexive transport address (172.16.10.2/7592 in the example).
IMPORTANT: The Security policy from-zone External to-zone Internal is NOT required for this traffic.
To establish a new flow session from an external host to the internal host, two conditions must be met:
- Incoming packets must match the Persistent NAT binding.
- The Security policy must be matched, using reverse policy lookup.
These two requirements are described below.
Matching Persistent NAT Binding
Packets from an external host must match an active Persistent NAT binding.
The SRX supports three types of Persistent NAT used to control this behavior:
-
permit any-remote-host
-
permit target-host
-
permit target-host-port
These types are configured using the permit keyword (permit any-remote-host in the configuration snippet).
These types are described below.
permit any-remote-host
With this type configured, the SRX allows ANY external host to match Persistent NAT binding by sending packets to the reflexive transport address. In the topology example, any host in the External zone can match the binding by sending TCP packets to 172.16.10.2/7592, which will be translated into 192.168.1.1/39192.
permit target-host
With this type configured, the SRX allows an external host to match Persistent NAT binding by sending packets to the reflexive transport address, but ONLY if this binding was used to communicate with the same external host. In the topology example, a flow session is established to 172.16.1.1. Therefore, only 172.16.1.1 can match the binding, by sending TCP packets to 172.16.10.2/7592, which will be translated into 192.168.1.1/39192.
permit target-host-port
With this type configured, the SRX allows an external host to match Persistent NAT binding by sending packets to the reflexive transport address, but ONLY if this binding was used to communicate with the same external host and port (that is, with the same external transport address). In the topology example, a flow session is established to 172.16.1.1/22. Therefore, only 172.16.1.1/22 can match the binding, by sending TCP packets to 172.16.10.2/7592, which will be translated into 192.168.1.1/39192. In other words, the host, 172.16.1.1, will have to use source-port 22.
Address Mapping
By default, a separate Persistent NAT binding is created for each internal transport address (IP address and port of the internal host), similar to the default behavior of the usual Source NAT. This means that if another SSH connection is opened from the same internal host, 192.168.1.1, to the same external host, 172.16.1.1, a new Persistent NAT binding is created, as shown below:
user@srx> show security flow session destination-prefix 172.16.1.1 Session ID: 28634, Policy name: itoe-pol/5, Timeout: 1792, Valid In: 192.168.1.1/39193 --> 172.16.1.1/22;tcp, If: ge-0/0/15.0, Pkts: 247, Bytes: 15253 Out: 172.16.1.1/22 --> 172.16.10.3/26681;tcp, If: ge-0/0/14.0, Pkts: 263, Bytes: 27277 Total sessions: 1 user@srx> show security nat source persistent-nat-table pool pnat-pool Internal Reflective Source Type Left_time/ Curr_Sess_Num/ Source In_IP In_Port I_Proto Ref_IP Ref_Port R_Proto NAT Pool Conf_time Max_Sess_Num NAT Rule 192.168.1.1 39192 tcp 172.16.10.2 7592 tcp pnat-pool any-remote-host 1752/1800 0/30 pnat-rule 192.168.1.1 39193 tcp 172.16.10.3 26681 tcp pnat-pool any-remote-host -/1800 1/30 pnat-rule
The previous binding, as well as a new binding, is created for a new internal transport address, 192.168.1.1/39193. As shown earlier, this also means that external hosts can match the bindings by sending packets ONLY to the allocated ports (that is, only to ports 7592 and 26681 in the above output). Sometimes, a binding must be created based solely on the IP address. Such a binding would be used for ALL the traffic sourced from or destined to the same internal host, regardless of the ports. This can be achieved with an option called address-mapping:
[edit]
user@srx# show security nat
source {
pool pnat-pool {
address {
172.16.10.1/32 to 172.16.10.100/32;
}
port no-translation;
}
rule-set pnat {
from zone Internal;
to zone External;
rule pnat-rule {
match {
source-address 0.0.0.0/0;
}
then {
source-nat {
pool {
pnat-pool;
persistent-nat {
permit any-remote-host;
address-mapping;
inactivity-timeout 1800;
}
}
}
}
}
}
}
proxy-arp {
interface ge-0/0/14.0 {
address {
172.16.10.1/32 to 172.16.10.100/32;
}
}
}
Note: This option is supported only when permit any-remote-host is configured and only when port translation is disabled, as shown above.
An SSH connection is now opened from the internal host, 192.168.1.1, to the external host, 172.16.1.1, and the Persistent NAT binding is revealed:
user@srx> show security flow session destination-prefix 172.16.1.1 Session ID: 9969, Policy name: itoe-pol/5, Timeout: 1794, Valid In: 192.168.1.1/39194 --> 172.16.1.1/22;tcp, If: ge-0/0/15.0, Pkts: 20, Bytes: 3449 Out: 172.16.1.1/22 --> 172.16.10.1/39194;tcp, If: ge-0/0/14.0, Pkts: 22, Bytes: 3401 Total sessions: 1 user@srx> show security nat source persistent-nat-table pool pnat-pool Internal Reflective Source Type Left_time/ Curr_Sess_Num/ Source In_IP In_Port I_Proto Ref_IP Ref_Port R_Proto NAT Pool Conf_time Max_Sess_Num NAT Rule 192.168.1.1 * * 172.16.10.1 * * pnat-pool any-remote-host -/1800 1/30 pnat-rule
Note that the ports are no longer mentioned in the binding; they are now replaced by stars (*). This results in the following behavior:
- All subsequent flow sessions from the internal host, 192.168.1.1, to the external host, 172.16.1.1, will use the same binding (and thus will use the same reflexive IP address, 172.16.10.1).
- No port translation will take place (and thus, 192.168.1.1/39194 is translated into 172.16.1.1/39194 in the above output).
- ANY external host will be able to match this binding by sending packets to 172.16.10.1, using ANY TCP or UDP port.
While this section shows how external hosts can match an active Persistent NAT binding, the security policy must be matched in order to establish a flow session to the internal host, as covered in the section below.
Reverse Policy Lookup
For this, consider again the topology example, with the following Persistent NAT binding:
user@srx> show security nat source persistent-nat-table pool pnat-pool Internal Reflective Source Type Left_time/ Curr_Sess_Num/ Source In_IP In_Port I_Proto Ref_IP Ref_Port R_Proto NAT Pool Conf_time Max_Sess_Num NAT Rule 192.168.1.1 39192 tcp 172.16.10.2 7592 tcp pnat-pool any-remote-host -/1800 1/30 pnat-rule
A flow session is established from an external host, 172.16.1.2, to 172.16.10.2/7592. The newly established flow session looks as follows (the internal host listens on TCP port 39192, to make this work):
user@srx> show security flow session source-prefix 172.16.1.2 Session ID: 35620, Policy name: itoe-pol/5, Timeout: 1786, Valid In: 172.16.1.2/51389 --> 172.16.10.2/7592;tcp, If: ge-0/0/14.0, Pkts: 2, Bytes: 116 Out: 192.168.1.1/39192 --> 172.16.1.2/51389;tcp, If: ge-0/0/15.0, Pkts: 1, Bytes: 60 Total sessions: 1
Note that this flow session matches the same itoe-pol policy. Instead of looking for a policy from-zone External to-zone Internal that would match source-address 172.16.1.2 and destination-address 192.168.1.1, the SRX looks for a “reversed” policy from-zone Internal to-zone External that would match source-address 192.168.1.1 and destination-address 172.16.1.2. The itoe-pol policy matches this criteria.
Example 1: Limiting External Hosts
The permit any-remote-host type of Persistent NAT is configured. Thus, any external host can establish a flow session to 172.16.10.2/7592. However, the list of allowed hosts can be limited by modifying the itoe-pol security policy.
[edit]
user@srx# show security policies
from-zone Internal to-zone External {
policy itoe-pol {
match {
source-address host-192.168.1.1;
destination-address allowed-external-hosts;
application any;
}
then {
permit;
}
}
}
[edit]
user@srx# show security zones security-zone External address-book
address allowed-external-hosts 172.16.1.0/24;
With this policy, the external hosts, 172.16.1.1 and 172.16.1.2, can still establish flow sessions to 172.16.10.2/7592, but an external host 172.16.2.1 will fail:
user@srx> show security flow session source-prefix 172.16.2.1 Total sessions: 0
The flow trace clarifies the reason:
Jun 13 14:41:43 14:41:43.106053:CID-0:RT:<172.16.2.1/65320->172.16.10.2/7592;6> matched filter pf0: Jun 13 14:41:43 14:41:43.106053:CID-0:RT:packet [64] ipid = 14465, @0x4094fd9c <...skipped...> Jun 13 14:41:43 14:41:43.106053:CID-0:RT:persistent-nat outgoing policy search from zone Internal-> zone External Jun 13 14:41:43 14:41:43.106053:CID-0:RT:Policy lkup: vsys 0 zone(11:Internal) -> zone(12:External) scope:0 Jun 13 14:41:43 14:41:43.106053:CID-0:RT: 192.168.1.1/39192 -> 172.16.2.1/65535 proto 6 Jun 13 14:41:43 14:41:43.106053:CID-0:RT:Policy lkup: vsys 0 zone(5:Unknown) -> zone(5:Unknown) scope:0 Jun 13 14:41:43 14:41:43.106053:CID-0:RT: 192.168.1.1/39192 -> 172.16.2.1/65535 proto 6 Jun 13 14:41:43 14:41:43.106053:CID-0:RT: packet dropped, no permit policy found. <...>
As shown above, the SRX failed to find a policy that would match source-address 192.168.1.1 and destination-address 172.16.2.1.
Note: This security policy will also affect the traffic from-zone Internal to-zone External. The host 192.168.1.1 will not be able to establish a flow session to 172.16.2.1.
Example 2: Restricting Applications
Note that application any is used in the policy. This might be not desirable, however. If the original flow session from-zone Internal to-zone External is SSH, the policy could be configured as follows:
[edit]
user@srx# show security policies
from-zone Internal to-zone External {
policy itoe-pol {
match {
source-address host-192.168.1.1;
destination-address allowed-external-hosts;
application junos-ssh;
}
then {
permit;
}
}
}
This policy would allow the original flow session, but would NOT allow any incoming sessions from-zone External. The reverse policy lookup would fail because the itoe-pol policy would not match the required application. To prevent this situation, Junos defines a special application that enables the reverse policy lookup to match: – junos-persistent-nat. The resulting policy would look like this:
[edit]
user@srx# show security policies
from-zone Internal to-zone External {
policy itoe-pol {
match {
source-address host-192.168.1.1;
destination-address allowed-external-hosts;
application [ junos-ssh junos-persistent-nat ];
}
then {
permit;
}
}
}
With this configuration, the traffic from allowed external hosts to 172.16.10.2/7592 match the itoe-pol policy:
user@srx> show security flow session source-prefix 172.16.1.2 Session ID: 6786, Policy name: itoe-pol/5, Timeout: 1790, Valid In: 172.16.1.2/50712 --> 172.16.10.2/7592;tcp, If: ge-0/0/14.0, Pkts: 2, Bytes: 116 Out: 192.168.1.1/39192 --> 172.16.1.2/50712;tcp, If: ge-0/0/15.0, Pkts: 1, Bytes: 60 Total sessions: 1