Blog

Closer look at static NAT

December 17, 2016 6:01 pm

Address translation is one of the main things keeping the IPv4 still alive. Nowadays it is considered as one of the basic router or firewall functionalities. On SRXs address translation is divided into three main types:

  • source NAT – the source address is translated in the initial flow
  • destination NAT – the destination address is translated in the initial flow
  • static NAT – combines source and destination NAT. The address translated in the initial flow depends on the flow direction (inbound flows have the destination address translated and outbound flows have the source address translated)

For source and destination NAT the port translation can be enabled or disabled through configuration. In static NAT the ports are not translated. Let’s look closer at the static NAT and its operation, configuration and troubleshooting.

One of the most common use cases for static NAT is to provide bidirectional reachability for a host (or hosts). In other words  the traffic initial on the host is translated to the same IP address as the external hosts use to reach it. The image below illustrates which type of translation is used in static NAT. It depends on the direction of the initiating flow.

inetzero-blog-static-NAT-resized-image-1-overview

Let’s review few basic things about static NAT first. Generally within SRX the address translation processing is separated from the security policies. This means the address translation will take place only on traffic permitted by security policy.

Static NAT configuration is located under the [edit security nat static] stanza. The structure is based on rule-sets and rules (same as source and destination NAT). Multiple rule-sets can exist within the configuration.  The first step in NAT processing is to find out which rule-set to select and evaluate for the arrived traffic. The matching criteria for the rules-sets is defined using the “from” statement (similarly as in the destination NAT configuration). The allowed values are either routing-instance/s or zone/s or interface/s. In case the traffic is matching the “from” statement from multiple rule-sets the rule-set with the most specific criteria will be selected (interface over zone over routing-instance).

For example:

interface ge-0/0/1.0 and ge-1/1/1.0 belong to the zone DMZ and the zone DMZ belongs to the routing-instance R1

rule-set TEST1

from interface ge-0/0/1.0

rule-set TEST2

from zone DMZ

rule-set TEST3

from routing-instance R1

A packet arriving on the interface ge-0/0/1.0 matches the “from” statement of all three rule-sets. However the TEST1 rules-set will be selected because of its most specific criteria (interface). In case the packet arrives on interface ge-1/1/1.0 (matches TEST2 and TEST3 rule-sets) the TEST2 rule-set will be used because its criteria (zone) is more specific than rule-set TEST3 criteria (routing-instance).

Once the rule-set is selected the rules within are evaluated sequentially one by one in the order they appear in the configuration. Each rule contains a match (criteria) and a then (action) statement. The evaluation stops on the 1st rule that has matching criteria and the action from that rule is executed. In case no rule in the whole rule-set produced a match the packet will not be translated.

Static NAT rule-set structure example:

inetzero-blog-static-NAT-text-image-01

The complete NAT hierarchy can be found here: http://www.juniper.net/techpubs/en_US/junos12.1/topics/reference/statement-hierarchy/security-hierarchy-nat.html

The procedure above describes the destination part of the static NAT, i.e. for the connections initiated towards the host. It takes place similarly as normal destination NAT before the forwarding lookup and security policies evaluation. As a result the SRX uses the new changed IP address for route lookup and not the one from the received packet. Also the security policies have account for the changed destination IP address in their match criteria.

For the connections in the opposite direction, e.g. from the host, the firewall checks if the source address translation should take place at a later stage in the processing. It happens after the route lookup and security policies evaluation (the same place as normal source NAT). So the security policies match criteria have to reflect the original source IP address from the received packet. To device uses again the criteria from static NAT configuration to determine whether the source address should be translated or not. But in this case they are reverted. The “match destination-address” value in the rule must match the source IP of the received packet and the traffic must be routed out as defined in the “from” statement in the rule-set (e.g. through interface or zone or routing-instance).

Please keep in mind on SRXs in case of criteria overlap static NAT takes priority over destination and source NAT.

Because I was curious about the operation and matching of the source part of the static NAT  I did put it to a test. The test setup was very simple as shown on the image below.

inetzero-blog-static-NAT-resized-image-2-setup

I used the available options within Junos – CLI operational mode commands and traceoptions – to examine and validate the tests. They provide useful and helpful information about static NAT which makes them quite suitable for troubleshooting too.

For the test simplicity sake the SRX had the default-policy set to “permit”.

The information provided by the “show security flow session” command helped to me to verify if the address translation took place. For purpose of deeper analysis I enabled the traceoptions for the NAT.

inetzero-blog-static-NAT-text-image-02

The trace file however contained mainly messages related to the processing of the NAT configuration rather than information about the actual data processing. That makes it useful for situations where problems related to the NAT configuration processing and parsing are suspected.

Few example entries from the NAT trace file:

inetzero-blog-static-NAT-text-image-03

The example messages above indicate:

  • no destination NAT configuration is present
  • the “from” statement in the static NAT rule-set A1 has changed from “interface ge-0/0/1.3” to “zone untrust”
  • only the destination address 1.1.1.1 is defined in the rule A matching criteria and the address should be translated to 172.17.1.2

Security flow traceoptions are much better option to examine or even troubleshoot the NAT processing on the traffic. Below is the configuration I used. I defined packet filter to allow only messages related to the test traffic to go into the trace file.

inetzero-blog-static-NAT-text-image-04

The test results contain messages from the traceoptions file. For brevity I removed the messages unrelated to NAT processing.

The whole test is divided into 3 scenarios.

Scenario 1:

inetzero-blog-static-NAT-resized-image-3-scenario-1

NAT configuration:

inetzero-blog-static-NAT-text-image-05

Test1

“ping 1.1.1.1” initiated from host2 towards the host1. The expected result is the destination address 1.1.1.1 will be translated to 172.17.1.2.

Test1 result:

inetzero-blog-static-NAT-text-image-06

As the session shows the destination address 1.1.1.1 has been translated correctly to 172.17.1.2. Exactly as defined in the configuration. The  traceoptions logs contains the string “mip” which is carried over from the ScreenOS.  MIP means “mapped IP“ and in ScreenOS it is used for bidirectional translation (same as static NAT in SRXs).

inetzero-blog-static-NAT-text-image-07

Test2

“ping 172.17.2.2” initiated from the host1 towards host2 to test the source address translation (172.17.1.2 to 1.1.1.1).

Test2 result:

inetzero-blog-static-NAT-text-image-08

The device did correctly translate the source IP address from 172.17.1.2 to 1.1.1.1.  As indicated by the messages the reverse static NAT (i.e. source address translation) has been found and applied on the traffic.

inetzero-blog-static-NAT-text-image-09

Test3

“ping 172.17.3.2” initiated from the host1 towards host3. In this case no source translation has to be performed because the outgoing interface is different (ge-0/0/3.0) than the interface in the “from” statement (ge-0/0/2.0).

Test3 result:

inetzero-blog-static-NAT-text-image-10

The session details confirmed the expected behavior – no translation took place.  No criteria for reverse static NAT has been found even tough the IP 172.17.1.2 is present in the static NAT configuration. The matching failed on the outgoing interface (ge-0/0/3.0 instead of ge-0/0/2.0).

inetzero-blog-static-NAT-text-image-11

In the scenarios 2 and 3 I did only the tests focused on the reverse static NAT.

Scenario 2:

inetzero-blog-static-NAT-resized-image-4-scenario-2

NAT configuration:

inetzero-blog-static-NAT-text-image-12

Test4

Again “ping 172.17.2.2” initiated from the host1 towards host2 to test the source address translation (172.17.1.2 to 1.1.1.1). But this time with different static NAT configuration – the “from” statement lists the zone instead of the interface.

Test4 result:

inetzero-blog-static-NAT-text-image-13

The session above validates that correct source address translation took place.

inetzero-blog-static-NAT-text-image-14

Test5

“ping 172.17.3.2” initiated from the host1 towards host3. In this case no address translation should take place because the outgoing zone does not match the configuration.

Test5 result:

inetzero-blog-static-NAT-text-image-15

As expected no translation took place. Below are the log entries from the flow traceoptions file that confirm it too.

inetzero-blog-static-NAT-text-image-16

Scenario 3:

inetzero-blog-static-NAT-resized-image-5-scenario-3

NAT configuration:

inetzero-blog-static-NAT-text-image-17

Test6

The same as test2 and test4. “ping 172.17.2.2” initiated from the host1 towards host2. Here the static NAT configuration has the routing instance in the “from” statement.

Test6 result:

inetzero-blog-static-NAT-text-image-18

The result is as expected – the source IP address 172.17.1.2 is translated to 1.1.1.1.

inetzero-blog-static-NAT-text-image-19

Test7

Similar as test3 and test5.  “ping 172.17.3.2” initiated from the host1 towards host3. In this case no address translation should take place because the outgoing routing instance does not match the static NAT configuration.

Test7 result:

inetzero-blog-static-NAT-text-image-20

Again as expected no translation happens as indicated also by the log messages below (routing instance mismatch is the reason).

inetzero-blog-static-NAT-text-image-21

The “show security nat static rule“ is an another useful operational mode command for verifying and checking the static NAT. It displays the static NAT details based on the configuration. And generally operational mode commands should be favored in troubleshooting over examining configuration directly. The command output contains in addition the counter showing the number of translation hits for each rule.

inetzero-blog-static-NAT-text-image-22

The “translation hits” counter represents all sessions translated using the rule regardless of the translation type (source or destination address). To illustrate the behavior I did sent 5 pings that resulted in destination address translation.

inetzero-blog-static-NAT-text-image-23

The counter value increased by 5.inetzero-blog-static-NAT-text-image-24

Then I generated another 5 pings. But this time to invoke source address translation.

inetzero-blog-static-NAT-text-image-25

The counter value incremented by another 5.

inetzero-blog-static-NAT-text-image-26

Conclusion

Today it is quite difficult to find a router or a firewall not capable to perform address translation. The translation is typically being performed by the devices closer to or at the network edge. This post focuses on the static NAT  functionality available on the SRX devices. Brief description and configuration overview are provided together with few test cases and their results. The options used for presenting the test results can serve very well also for static NAT troubleshooting purposes.

 

 

 

Richard Pracko

Richard Pracko

Richard Pracko lives in Slovakia. Right after finishing his studies at the university with telecommunications as a major, he joined the Siemens Networking department, and focused on the integration of Juniper Networks and Siemens products. In the beginning of 2009, he left Siemens on his own initiative, and became a full time instructor for and technical consultant, over a vast geographic area (EMEA and more).

More Posts

Categorised in:

Leave a Reply

Your email address will not be published. Required fields are marked *