Understanding Persistent NAT behavior and its different types

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

Understanding Persistent NAT behavior and its different types

The configuration snippet below is used in the examples at the end of this section:

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:

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:

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:

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:

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:

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:

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:

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:

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):

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.

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:

The flow trace clarifies the reason:

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:

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:

With this configuration, the traffic from allowed external hosts to 172.16.10.2/7592 match the itoe-pol policy:

 

About the author

Prasanna

Leave a Comment