Juniper SRX traffic flow knowledge is a requirement to troubleshoot connectivity over SRX device.
The way that the first packet of a new session is processed and forwarded in juniper SRX is different from processing and forwarding of a packet belonging to existing session.
In this section we will discuss how a new packet from a new session or a packet from existing session is forwarded in juniper SRX device.
juniper SRX Traffic Flow Diagram
As Juniper’s SRX traffic flow diagram shows that when a packet enters an interface, first of all, it checks whether the packet belongs to a new session or to an existing session.
How does it understand that a packet belongs to an existing session or that it is a new session?
With matching five fields in packet’s header in Layer 3 and Layer 4, including source IP, destination IP, source port, destination port, and protocol number, if there is a match with session table, then packet belongs to an existing session, otherwise it’s a new session.
As you can see, the traffic processing is different for the first packet of a new session or a packet from existing session.
As I have explained in the previous section, only the first packet of every session is checked against security policies. packet will be treated according to the matching policy. All other packets from the same session, incoming and outgoing, are treated exactly the same as the first packet.
For example, if the address of packet must be translated or the packet must be encrypted or any other resulting policies will be the same for all packets of the same session.
Screens policy in juniper SRX Traffic Flow
As you can see in the diagram, screen option is the first policy that will be applied to both packet of a new session or packets of existing session.
Screen option, is to prevent general attacks in layer 3 and layer 4 such as IP scan, port scan and SYN floods.
In a separate section, we will talk about screen policy in details.
Policy in juniper SRX Traffic Flow
Actually the policy is most important section of Juniper SRX traffic flow diagram.
As you can see, only for the first packet of every new session, SRX will try to find a matching policy to see how the packet must be treated.
The matching policy will be stored in session table and all other packets belonging to this session will not lookup for the policy and be treated exactly the same as the first packet.
Routing and NAT options in juniper SRX Traffic Flow
Now the question is, if the policy option is the most important option in traffic flow, why it is not the first option to be checked in traffic flow?
This is because the policy applies to traffic between zones. In other words, the policy cannot be applied until the incoming and outgoing zones of the traffic are determined.
On the other hand, the outgoing zone will be determined when packet’s outgoing interface is extracted from the routing table since zones are configured based on interfaces.
Therefore, the routing lookup process must be performed before policy matching. After the routing lookup, the outgoing interface is determined. Based on the outgoing interface, outgoing zone is extracted. when incoming and outgoing zones are clear to juniper SRX, then it is possible for juniper SRX to do policy matching.
Now the question is why static NAT and destination NAT options are processed before policy option and even before routing lookup?
This is because with static NAT and destination NAT, it is possible that the destination IP address of the packet is changed, and if the destination IP address is changed, it will affect the routing result with possibly different outgoing interface result and therefore a different outgoing zone and finally a different policy matching.
source NAT options in juniper SRX Traffic Flow
Why the source NAT is not processed before policy matching?
This is because even if the source NAT change the source IP address of the packet , it will not influence routing process and therefore it will not influence outgoing interface, outgoing zone and resulting policy match. This is because routing process is based on destination IP address and not source IP address.
ALG and services options in juniper SRX Traffic Flow
Then, application layer gateway and service options will be processed.
With application layer gateway, application layer information will be processed to determine if a packet is permitted to be forwarded. With application layer gateway, controlling, dynamic applications which have dynamic ports like FTP and RTP will be possible.
Application layer gateway will be discusses in a separate video.
With services option, the packet can optionally get some services like encryption and IDS/IPS if they are configured.
adding a new record in session table
And finally, a new record in the session table will be created since it is the first packet of a new session. Packet header information and also the policies matched with the packet will be stored in the session table.
Fast Path in juniper SRX Traffic Flow
All other packet belong to this session will be processed according to the below section of traffic flow diagram.
In this section, we will not have any more policy checking in control plane and only the result of policy, which is stored in the session table will be applied to the packet in data plane.
In other words, the address of packet will be changed if there is any NAT option for the session. And application layer services will be also applied to the packet if they are already matched and stored for the existing session.
This path is called “Fast Path”, since packets are quicky forwarded without looking policies in control plane.
Per Packet Policer/Shaper and Firewall Filter
There are some services that are always per packet. It means each packet will be processed separately without noticing if it is a packet from a new session or belonging to an existing session.
Policer, shaper and firewall filter are these services.
With policer and shaper we can limit the bandwidth of any traffic.
Traffic filter is actually like access list that we have discussed in the previous course JNCIA-Junos.