This article describes the logic behind what will happen with a given session when there is a route change.
When there is a route change, it may be observed that sometimes existing sessions continue unaffected, other sessions are deleted, and other sessions may go dead until they time out.
First, we will cover how a session is created, considering only the zone and route aspects.
The SRX security policies are based on zone to zone context. The route lookups determine what interfaces should be used, and any given interface is assigned to only one zone.
Consider the following session:
Session ID: 60129543116, Policy name: WirelessGuest/10, Timeout: 1756, Session State: Valid In: 192.168.99.55/55108 --> 192.168.10.100/443;tcp, Conn Tag: 0x0, If: ge-0/0/0.0, Pkts: 14, Bytes: 2701, Out: 192.168.1.100/443 --> 192.168.99.55/55108;tcp, Conn Tag: 0x0, If: ge-0/0/1.0, Pkts: 13, Bytes: 6801,
When the session was created with the initial SYN packet, it went through the following steps relevant to the topic of this KB.
How will a route change affect our existing session?
For example, if the destination route to 192.168.10.100 changes from next-hop 192.168.0.1 to next-hop 192.168.1.1, the SRX will need to do a session scan to see what sessions might be affected by this route change.
It finds that our example session is affected and therefore, it must be updated.
A. If Next Hop 192.168.1.1 is also reached via ge-0/0/0.0:Given that this is the same interface, there is no zone change and the session will continue uninterrupted from the SRX point of view.
B. If Next Hop 192.168.1.1 is reached via new interface ge-0/0/2.0: 1. If ge-0/0/2.0 is in the same zone as ge-0/0/1.0, ZONE_B, the session will be retained without interruption from the SRX point of view. 2. If ge-0/0/2.0 is in a different zone, ZONE_C, a new policy lookup must be done. a. If the policy lookup results in the traffic being permitted, the session will be updated and will continue uninterrupted from the SRX point of view. b. If the new policy lookup results in the traffic not being permitted, the session will be invalidated and deleted.
The SRX will take the same steps if the reverse route lookup back to 192.168.99.55 changes.
If the original route is lost and there is no new route, the session will be invalidated and deleted.
Note that if the SRX decides to delete the session, it will not sent a tcp reset by default. It will silently drop additional packets unless "tcp-rst" is configured on the security zone. This is typically not configured as it can allow malicious actors get an idea of what is and is not allowed on the network and identify the firewall.
The last consideration is that even if the SRX decides to retain the session, that does not mean that the new route will be valid from the perspective of the rest of the network. For example, the new route may be the default route out to the Internet and may be permitted by a generic internal to external policy. If that is the case, the session may still be valid to the SRX, but the destination to the private IP will not be valid via the ISP. The ISP will drop the traffic, the client will stop getting replies, and the session will either time out, or the client will be proactive and send a reset.
2024-09-26: minor non tech changes
2025-11-10: Article overhaul for clarity.