What do they do? Network address translation (NAT) modifies the IP addresses and optionally also ports in the packet. And filter based forwarding changes the forwarding table where the lookup is performed. Previous blogs did look at them separately. Now the question is what happens if they are used together, how do they coexist and what is their influence on each other?
To be able to better understand and analyze their influence on each other let's review the traffic processing sequence on SRXs. The image below displays it (http://www.juniper.net/techpubs/images/g034201.gif).
For our focus the following information is important: “input firewall filters are processed before destination NAT and destination NAT is executed before forwarding lookup”. We can disregard source NAT because is happens after the forwarding lookup and therefore has no impact on anything we investigate now.
Based on this information the expected behavior (the sequence of the relevant steps and their result) should be:
- 1st – FBF changes the forwarding table for lookup
- 2nd – Destination NAT modifies the destination IP address of the packet
- 3rd – Forwarding lookup is done with the modified destination IP address in the changed forwarding table
We did few tests to validate or invalidate this expected behavior. Our test topology (show below) was similar to the topology in the filter based forwarding blog.
The SRX was configured to:
- translate the 1.1.1.1 destination IP address to address 172.17.10.10 (destination NAT)
- direct the http traffic received on the ge-0/0/1.0 interface to the ge-0/0/3.0 (using FBF) while other traffic received on the ge-0/0/1.0 is send out of the ge-0/0/2.0 interface
Below are the relevant configuration excerpts of destination NAT, routing instance and firewall filter:
The security polices were configured to allow all traffic for test simplicity. The interfaces and security zones associations was following (depicted also on the topology image):
The firewall filter was associated with the ge-0/0/1.0 interface:
Routing to the 172.17.10.10 IP address:
- in the default routing instance:
- in the HTTP-redirect routing instance:
Some log messages reference the routing instance IDs instead of their names. The output below is helpful for understanding such logs because it displays the mapping between routing instance names and their internal IDs.
We started the tests with the connection from the external network to the 1.1.1.1 IP address on the port 23. The device created following session for it.
This traffic did not match the FBF criteria (particularly the destination port 80). The NAT translated the destination address to 172.17.0.0/32 and based on routing table inet.0 the outgoing interface was ge-0/0/2.0.
The messages from the flow traceoptions shown below confirm the routing result as well as the address translation. (For brevity only the relevant messages are displayed.)
On the other hand for the connection to 1.1.1.1 with destination port 80 the FBF kicked in and the outgoing interface changed to ge-0/0/3.0.
The traceoptions above confirm that for FBF together with destination NAT the forwarding lookup is done with the translated destination IP address (in our case 172.17.10.10) in the changed table (HTTP-redirect – VR-id: 4).
Please keep in mind with FBF asymmetric routing can manifest if routing improperly done in the network. The example above illustrates such example – the “Pkts” and “Bytes” counters for the reverse flow are 0. And the trace file contains these entries for the returning flow:
The solution is to put both interface in the same zone (more details are provided in the blog about FBF). Then the connection will work.
The remaining two test cases double check whether the firewall filter is evaluated and executed before the destination NAT.
At first the firewall filter criteria was adjusted to match against the destination IP 1.1.1.1 (the original IP from the packet) in addition to protocol TCP and destination port 80.
The resulting session for the connection to 1.1.1.1 and destination port 80 was following:
And the traceoptions file had following entries:
For the second case the firewall filter criteria matched on the post translation IP – 172.17.10.10 instead of the destination IP from the packet (1.1.1.1).
The session and flow traceoptions are below:
In the first case the VR-id: 4 was listed (routing instance “HTTP-redirect”) as being selected for the route lookup. This was the reason why the ge-0/0/3.0 was selected as the outgoing interface. Simply put – FBF was done.
In the second case the route lookup was carried out in the VR-id: 0 (“default” routing instance) because the firewall filter condition (included the post translated ip 172.17.10.10) was not met.
The experienced results prove the firewall filter is executed before the translation.
Conclusion
On SRXs destination NAT and FBF are being executed in following sequence when used together:
- 1st – FBF changes the table for lookup
- 2nd – the destination NAT modifies the destination IP address in the packet
- 3rd – the route lookup is performed
This means the combination of destination NAT and FBF influences which table as well which address are used for the lookup. In other words: the SRX performs the route lookup in the table selected by FBF with the post-translated IP address.
