A SRX is a “security device”, or as we call it conventionally, a firewall. Modern layer-3 firewalls route packets just like a router, but unlike a router, a firewall can organize packets into connections (flows) and run ACLs on the entire flow. This unique functionality is the fundamental building block of every “advanced” security feature offered by a firewall: dynamic NAT (PAT/NPT), zone-based firewall (ZBFW), ACLs for in or out connections only, L7 filtering, etc. For the connection (flow) tracking to work, all the packets in a connection must go through the same device, and the 5-tuple of all the packets in a connection must be of expected values, which usually means:

• The packets from A to B and the packets from B to A must all go through the firewall at some point
• There shouldn’t be single-sided stateless NAT happening on the route

This was never an issue when everyone was single-homed and all the routers had only one routing table. But not today. SRXs now have built-in support for virtual routers which can create an asymmetric flow easily. Let’s look at this simplified topology:

First of all, we need to make sure the SRX works in flow mode. If it is in the packet mode, then it acts like a traditional packet-forwarding router and all the things we are talking about it today does not apply at all.

For flexibility (i.e. we will have multiple LAN tenants and we want to isolate them later), we put the ISP and the LAN in different virtual routers:

This created 2 IPv4 routing tables: ISP.inet.0 and LAN.inet.0, then assigned the two interfaces to their corresponding routing tables. Then we also imported all the routers in the ISP.inet.0 table into the LAN.inet.0 table. Let’s see if the routing tables contain the routes we expected:

So, if we ping 192.168.1.2 from a device on the ISP side (e.g. 192.0.2.1), it should not go through the SRX. This is because if we send a packet destinated to 192.168.1.2 into SRX’s interface ge-0/0/1.0, and since ge-0/0/1.0 is associated to the routing table ISP.inet.0, there are no detailed route to 192.168.1.2, thus the packet is routed back to ge-0/0/1.0 thanks to the default route.

Let’s put on the router hat and think another question: what will happen if we ping 192.0.2.1 from the LAN side (e.g. 192.168.1.2)? Obviously the ICMP echo request packet will go through the SRX since we do have routes to 192.0.2.0/24 in routing table LAN.inet.0 pointing to the correct interface, but the ICMP echo reply packet would not go through just like the first case, right? Well, let’s try it out.

Well, that’s a little unexpected. But why? It’s because the SRX’s flow based forwarding process is a little different from a router’s packet based forwarding process. Let’s look at our ICMP flow:

A flow consists of two match conditions for two packet directions. The “In” condition is taken from the first packet of a flow received by SRX, and the “Out” condition is derived from all the packet transformation rules. (NOTE: Everything displayed here with a direction assumes the current device is receiving the traffic. e.g. If you need to see the gateway of the “Out” direction, you need to look at the line after “In”.) This is how connection tracking works under the hood. In Junos, either direction will be associated with a route in the active routing table. By default, the reverse route lookup mode is “flow mode”, which causes the route associated with the “Out” direction is also calculated from the routing table of the “In” interface. This mode breaks the assumption that a packet should be forwarded according to the routing table the receiving interface is associated to, but flow symmetry is easily achieved.

Now let’s try set the reverse route lookup mode to “packet mode”:

You can verify yourself the routing table is the same, but the LAN device would not be able to ping the ISP device anymore. If you look at the flow session table again, you should see the associated route for the “Out” direction is now 0x0, denoting a route lookup failure.

If we do a packet capture on the ISP router, we should see it successfully receiving the echo request packet and sending out the echo reply packet. The reply packet will be discarded by the SRX (because of the route lookup failure) and never reach its intended destination, though.

In this configuration, you can still ping the SRX’s ISP-facing interface IP from the LAN device:

Why this is possible is trivial and left as an exercise to the reader.

Conclusion

One that is used to the VRFs on the routers might be confused by the default reverse route lookup mode when using SRXs for the first time. But the ability to change how returning packet is routed is particularly useful when familiarized. It allows us to easily achieve flow symmetry in a multi-VR environment without adding a lot complexity on route import/export policies, and it can simulate simple ZBFW functionality with pure routing table designs.

Appendix

The lab topology is verified under Junos OS 18.4R3.3 (vSRX3) and 20.1R1-S1.2 (SRX300).

For simplicity, the configuration above is not complete. If you are trying to replicate the lab topology, you also need the following configuration:

References:

• Reverse Route Packet Mode using Virtual Router
• How to avoid flow asymmetry on SRX
• show security flow session extensive node
• no-redirects (IPv4 Traffic)