Knowledge Search


×
 

[SRX] How does SRX handle asymmetric traffic?

  [KB21983] Show Article Properties


Summary:

This article provides information about how an SRX device handles asymmetric traffic flows, including TCP, UDP, and ICMP traffic types.

 

Symptoms:

Consider the following scenarios:

First scenario (asymmetric traffic caused within the SRX device):

  • The interfaces of the device are assigned to the following zones:

    • ge-0/0/1 belongs to zone A.

    • ge-0/0/2 belongs to zone B.

    • ge-0/0/3 belongs to zone C.

  • An initiating traffic flow reaches the SRX device via the ge-0/0/1 interface and goes out through the ge-0/0/2 interface (that is from zone A to zone B) and the returning traffic flow comes in to the SRX device via the ge-0/0/2 interface but will be sent out via the ge-0/0/3 interface (that is from zone B to zone C).

How is the ICMP, UDP, and TCP traffic affected by this setup?

 

Second scenario (asymmetric traffic caused outside the SRX device):

  • The interfaces of the device are assigned to the following zones:

    • ge-0/0/1 belongs to zone 1.

    • ge-0/0/2 belongs to zone 2.

    • ge-0/0/3 belongs to zone 3.

  • An initiating traffic flow reaches the SRX device via the ge-0/0/1 interface and goes out through the ge-0/0/2 interface (that is from zone 1 to zone 2) but the returning traffic flow comes in to the SRX device via the ge-0/0/3 interface and will be sent out via the ge-0/0/1 interface (that is from zone 3 to zone 1).

    How is the ICMP, UDP, and TCP traffic affected by this setup?

 

Solution:

First scenario (asymmetric traffic caused within the SRX device)

All type of traffic (TCP, UDP, and ICMP) will be handled in the same way by the SRX device. The output from a security flow traceoptions is used for illustration purposes here.

  • The initiating traffic flow comes in to ge-0/0/1 (zone A).

    Aug 28 05:28:34 05:28:34.415937:CID-0:RT: flow process pak fast ifl 69 in_ifp ge-0/0/1.0
    Aug 28 05:28:34 05:28:34.415937:CID-0:RT:  ge-0/0/1.0:192.168.40.2->192.168.4.2, icmp, (8/0)
  • The device checks if a session is already present to match this traffic. If there is no previous session, the device does a route lookup, and in this case, the route directs the traffic towards ge-0/0/2 (zone B).

Aug 28 05:28:34 05:28:34.415937:CID-0:RT:  no session found, start first path. in_tunnel - 0x0, from_cp_flag - 0
Aug 28 05:28:34 05:28:34.415937:CID-0:RT:  flow_first_create_session

[output truncated]

Aug 28 05:28:34 05:28:34.415937:CID-0:RT:Doing DESTINATION addr route-lookup
Aug 28 05:28:34 05:28:34.415937:CID-0:RT:flow_ipv4_rt_lkup success 192.168.4.2, iifl 0x45, oifl 0x47
Aug 28 05:28:34 05:28:34.415937:CID-0:RT:  routed (x_dst_ip 192.168.4.2) from ZONE_A (ge-0/0/1.0 in 0) to ge-0/0/2.0, Next-hop: 192.168.4.2
  • Then a security-policy lookup is performed, and this is successful only if a policy permitting this traffic exists (from zone A to zone B).

Aug 28 05:28:34 05:28:34.415937:CID-0:RT:flow_first_policy_search: policy search from zone ZONE_A-> zone ZONE_B (0x0,0x490001,0x1)
Aug 28 05:28:34 05:28:34.415937:CID-0:RT:Policy lkup: vsys 0 zone(6:ZONE_A) -> zone(8:ZONE_B) scope:0
Aug 28 05:28:34 05:28:34.415937:CID-0:RT:             192.168.40.2/2048 -> 192.168.4.2/19730 proto 1
Aug 28 05:28:34 05:28:34.415937:CID-0:RT:Policy lkup: vsys 0 zone(5:global) -> zone(5:global) scope:0
Aug 28 05:28:34 05:28:34.415937:CID-0:RT:             192.168.40.2/2048 -> 192.168.4.2/19730 proto 1
Aug 28 05:28:34 05:28:34.415937:CID-0:RT:  app 0, timeout 60s, curr ageout 60s
Aug 28 05:28:34 05:28:34.415937:CID-0:RT:  permitted by policy default-policy-logical-system-00(2)
Aug 28 05:28:34 05:28:34.415937:CID-0:RT:  packet passed, Permitted by policy.
  • A reverse route lookup occurs, a session gets installed, and the packet goes through. However, the session is created with the following message "Reject route in make_nsp_ready_no_resolve. zone mismatch."

Aug 28 05:28:34 05:28:34.415937:CID-0:RT:flow_ipv4_rt_lkup success 192.168.40.2, iifl 0x45, oifl 0x46
Aug 28 05:28:34 05:28:34.415937:CID-0:RT:  route lookup: dest-ip 192.168.40.2 orig ifp ge-0/0/1.0 output_ifp ge-0/0/3 orig-zone 6 out-zone 7 vsd 0
Aug 28 05:28:34 05:28:34.415937:CID-0:RT:Reject route in make_nsp_ready_no_resolve. zone mismatch

[output truncated]

Aug 28 05:28:34 05:28:34.415937:CID-0:RT:first path session installation succeeded
Aug 28 05:28:34 05:28:34.415937:CID-0:RT:  flow got session.
Aug 28 05:28:34 05:28:34.415937:CID-0:RT:  flow session id 2
  • The returning traffic flow arrives at ge-0/0/2 (zone B).

Aug 28 05:28:34 05:28:34.417748:CID-0:RT: flow process pak fast ifl 71 in_ifp ge-0/0/2.0
Aug 28 05:28:34 05:28:34.417748:CID-0:RT:  ge-0/0/2.0:192.168.4.2->192.168.40.2, icmp, (0/0)
  • The device checks if a session is present and the traffic matches the existing session from zone A to zone B. However, the packet's processing fails with the following message "pak dropped since re-route failed."

Aug 28 05:28:34 05:28:34.417748:CID-0:RT:  flow got session.
Aug 28 05:28:34 05:28:34.417748:CID-0:RT:  flow session id 2
Aug 28 05:28:34 05:28:34.417748:CID-0:RT:flow_ipv4_rt_lkup success 192.168.40.2, iifl 0x0, oifl 0x46
Aug 28 05:28:34 05:28:34.417748:CID-0:RT:  route lookup failed: dest-ip 192.168.40.2 orig ifp ge-0/0/1.0 output_ifp ge-0/0/3 fto 0x491d4568 orig-zone 6 out-zone 7 vsd 0
Aug 28 05:28:34 05:28:34.417748:CID-0:RT:  readjust timeout to 6 s
Aug 28 05:28:34 05:28:34.417748:CID-0:RT:  packet dropped,   pak dropped since re-route failed

This situation can be fixed by avoiding the generation of asymmetric flows. Also the solutions mentioned in KB21363 - [SRX] Workaround for Reject route in 'make_nsp_ready_no_resolve. zone mismatch' can be followed.

 

Second scenario (asymmetric traffic caused outside the SRX device)

UDP and ICMP will be handled in the same way by the SRX device.

  • The initiating traffic flow comes in to ge-0/0/1 (zone 1).

  • The device checks if a session is already present to match this traffic. If there is no previous session, the device does a route lookup, and in this case, the route directs the traffic towards ge-0/0/2 (zone 2).

  • Then a security-policy lookup is performed, and this is successful only if a policy permitting this traffic exists (from zone 1 to zone 2).

  • A reverse route lookup occurs (this time without problems), a session gets installed, and the packet goes through. Note that there are no problems on the reverse route lookup because the incoming interface of the initiating flow is the outgoing interface for the returning flow.

    Aug 28 08:38:34 08:38:33.903692:CID-0:RT:flow_ipv4_rt_lkup success 192.168.40.2, iifl 0x45, oifl 0x45
    Aug 28 08:38:34 08:38:33.903692:CID-0:RT:  route lookup: dest-ip 192.168.40.2 orig ifp fe-0/0/1.0 output_ifp fe-0/0/1.0 orig-zone 8 out-zone 8 vsd 0
    Aug 28 08:38:34 08:38:33.903692:CID-0:RT:  route to 192.168.10.1
    Aug 28 08:38:34 08:38:33.903692:CID-0:RT:no need update ha
    Aug 28 08:38:34 08:38:33.903692:CID-0:RT:Installing c2s NP session wing
    Aug 28 08:38:34 08:38:33.903692:CID-0:RT:Installing s2c NP session wing
    Aug 28 08:38:34 08:38:33.903692:CID-0:RT:first path session installation succeeded
    Aug 28 08:38:34 08:38:33.903692:CID-0:RT:  flow got session.
    Aug 28 08:38:34 08:38:33.903692:CID-0:RT: flow fast tcp/udp session id 7
  • The returning traffic flow arrives at ge-0/0/3 (zone C).

  • The device checks if a session is present but this traffic looks like a new session because it is returning via a different security-zone than the one that the SRX device is expecting the traffic on. If there is a security-policy permitting traffic in this new direction, a new session is created and there are two different sessions in the firewall, both showing only initiating flow traffic:

    Aug 28 08:38:34 08:38:33.938319:CID-0:RT: flow process pak fast ifl 71 in_ifp fe-0/0/3.0
    Aug 28 08:38:34 08:38:33.938319:CID-0:RT: find flow: table 0x532b9f80, hash 33850(0xffff), sa 192.168.20.1, da 192.168.40.2, sp 161, dp 59396, proto 17, tok 7
    Aug 28 08:38:34 08:38:33.938319:CID-0:RT:  flow_first_create_session
[output truncated]
    Aug 28 08:38:34 08:38:33.938319:CID-0:RT:Doing DESTINATION addr route-lookup
    Aug 28 08:38:34 08:38:33.938319:CID-0:RT:flow_ipv4_rt_lkup success 192.168.40.2, iifl 0x47, oifl 0x45
    Aug 28 08:38:34 08:38:33.938319:CID-0:RT:  routed (x_dst_ip 192.168.40.2) from ZONE_3 (fe-0/0/3.0 in 0) to fe-0/0/1.0, Next-hop: 192.168.10.1
    Aug 28 08:38:34 08:38:33.938319:CID-0:RT:flow_first_policy_search: policy search from zone ZONE_3-> zone ZONE_1 (0x0,0xa1e804,0xe804)
    Aug 28 08:38:34 08:38:33.938319:CID-0:RT:Policy lkup: vsys 0 zone(7:ZONE_3) -> zone(8:ZONE_1) scope:0
    Aug 28 08:38:34 08:38:33.938319:CID-0:RT:             192.168.20.1/161 -> 192.168.40.2/59396 proto 17
    Aug 28 08:38:34 08:38:33.938319:CID-0:RT:Policy lkup: vsys 0 zone(5:global) -> zone(5:global) scope:0
    Aug 28 08:38:34 08:38:33.938319:CID-0:RT:             192.168.20.1/161 -> 192.168.40.2/59396 proto 17
    Aug 28 08:38:34 08:38:33.938319:CID-0:RT:  app 0, timeout 60s, curr ageout 60s
    Aug 28 08:38:34 08:38:33.938319:CID-0:RT:  permitted by policy default-policy-logical-system-00(2)
    Aug 28 08:38:34 08:38:33.938319:CID-0:RT:  packet passed, Permitted by policy.
[output truncated]
    Aug 28 08:38:34 08:38:33.938319:CID-0:RT:  flow got session.
    Aug 28 08:38:34 08:38:33.938319:CID-0:RT: flow fast tcp/udp session id 8

   root@SRX-4# run show security flow session
    Session ID: 7, Policy name: default-policy-logical-system-00/2, Timeout: 18, Valid
      In: 192.168.40.2/59396 --> 192.168.20.1/161;udp, If: fe-0/0/1.0, Pkts: 1, Bytes: 66
      Out: 192.168.20.1/161 --> 192.168.40.2/59396;udp, If: fe-0/0/2.0, Pkts: 0, Bytes: 0

    Session ID: 8, Policy name: default-policy-logical-system-00/2, Timeout: 18, Valid
      In: 192.168.20.1/161 --> 192.168.40.2/59396;udp, If: fe-0/0/3.0, Pkts: 1, Bytes: 66
      Out: 192.168.40.2/59396 --> 192.168.20.1/161;udp, If: fe-0/0/1.0, Pkts: 0, Bytes: 0
    Total sessions: 2

For TCP, the returning traffic (SYN-ACK) will be recognized as part of a new session as well. However, the SRX device comes with a TCP check (SYN-CHECK) that ensures that every new TCP session starts with a SYN message and not with a SYN-ACK as in this case. At this point, a session will be created because of the initiating flow (SYN) but the returning traffic will be dropped due to this security check.

Aug 28 09:38:01 09:38:01.001915:CID-0:RT:  no session found, start first path. in_tunnel - 0x0, from_cp_flag - 0
Aug 28 09:38:01 09:38:01.001915:CID-0:RT:  packet dropped, first pak not sync
Aug 28 09:38:01 09:38:01.001915:CID-0:RT:flow_initiate_first_path: first pak no session
Aug 28 09:38:01 09:38:01.001915:CID-0:RT:  flow find session returns error.

For disabling this security check in a selective fashion, see KB25094 - [SRX]: How to selectively disable TCP SYN or Sequence checking.

 

Modification History:

2018-10-05: Article reviewed for accuracy and updated with scenario output for SRX devices

 

Related Links: