Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
ON THIS PAGE
 

Known Limitations

Learn about known limitations in this release for SRX Series Firewalls.

For the most complete and latest information about known Junos OS defects, use the Juniper Networks online Junos Problem Report Search application.

Flow-Based and Packet-Based Processing

  • SRX firewalls configured in packet mode, after upgrade to Junos 24.2R1 and higher releases from earlier releases, will not forward traffic directly after the upgrade, because the packet mode configuration has changed. In the older Junos releases, when you configure set security forwarding-options family to use packet mode, MPLS and IPv4 (family inet) are set to packet mode automatically.

    Starting in Junos OS releases 24.2R1, each address family can be configured separately to packet mode or flow mode. The default for IPv4 and IPv6 is flow mode. As a result, if your device contains the configuration set security forwarding-options family mpls mode packet-based before the upgrade, which sets the family IPv4 to packet mode. After the upgrade, to restore IPv4 to packet mode, you must configure set security forwarding-options family inet mode packet-based. Commit the configuration and reboot the device for the change to take effect.

    You can check the current forwarding mode of the device using the CLI command show security flow status.

    Note:

    No action required for IPv6 or selective packet mode using firewall filters

High Availability

  • On SRX Series Firewall, Stream Control Transmission Protocol (SCTP) traffic fails in asymmetric traffic on a Multinode High Availability setup. As a workaround, you can configure the set security forwarding-process application-services enable-sctp-port-hash hidden command.

  • On SRX5000-line firewalls do not support GTPv1 and GTPv2 for asymmetric traffic configuration. The SRX4600, SRX4300, SRX4200, SRX4100, SRX2300, SRX1600, and SRX1500 firewalls support GTPv0, GTPv1, and GTPv2 for asymmetric traffic configuration. To enable this functionality, you need to configure the set security forwarding-process application-services enable-gtpu-distribution setting.

  • When using Advanced policy-based routing (APBR), switching routes based on the configuration is functioning correctly. However, there is an issue related to the RT_FLOW logs on the peer node in the Multinode High Availability asymmetric topology. Specifically, the logs do not include information about the uplink incoming interface name and the number of bytes/packets received on that interface.
  • While the SSL proxy functionality operates smoothly on the primary node, there is an issue related to the application classification information on the peer node. We recommend you to refer the RT_FLOW session logs from the primary node to obtain accurate application details.

    Example: When HTTPS traffic flows through the nodes, the active node identifies the Layer 7 standard application as IP:TCP:SSL:HTTP. However, the peer node reports the application as IP:TCP:SSL.