Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

Navigation  Back up to About Overview 
  
[+] Expand All
[-] Collapse All

Known Behavior

Application Layer Gateways (ALGs)

  • In Junos OS Release 12.1X46-55 and earlier, on SRX Series devices, the mapping of Microsoft remote procedure call Application Layer Gateway (MS-RPC ALG) universally unique identifier (UUID) to the object identifier (OID) does not associate with the security zone information. Because the MS-RPC ALG data traffic matching a specific UUID fails to search the correct security policy, the traffic may be dropped.

    Starting in Junos OS Release 12.1X46-D60, the mapping of MS-RPC ALG (UUID-to-OID) is now associated with the security zone information, which the MS-RPC ALG data traffic matches with the UUID security policy, which in turn allows the MS-RPC ALG data traffic to flow.

  • On all SRX Series devices, you can define the Sun RPC and MS-RPC mapping entry ageout value using the set security alg sunrpc map-entry-timeout value and set security alg msrpc map-entry-timeout value commands. The ageout value ranges from 8 hours to 72 hours, and the default value is 32 hours.

    If either the Sun RPC ALG or the MS-RPC ALG service does not trigger the control negotiation even after 72 hours, the maximum RPC ALG mapping entry value times out and the new data connection to the service fails.

  • The maximum size of the jbuf is 9 Kb. If the message buffer size is more than 9 Kb, the entire message cannot be transferred to the ALG packet handler. This causes subsequent packets in the session to bypass ALG handling, resulting in a transaction failure.

The limitations for SCCP ALGs are as follows:

  • The SCCP is a Cisco proprietary protocol. So, any changes to the protocol by Cisco cause the SCCP ALG implementation to break. However, workarounds are provided to bypass strict decoding and allow any protocol changes to be handled gracefully.
  • The SCCP ALG validates protocol data units (PDUs) with message IDs in the ranges [0x0 - 0x12], [0x20 - 0x49], and [0x81 - 0x14A]. By default, all other message IDs are treated as unknown messages and are dropped by the SCCP ALG.
  • Any changes to the policies will drop the sessions and impact already established SCCP calls.
  • The SCCP ALG opens pinholes that are collapsed during traffic or media inactivity. This means that during a temporary loss of connectivity, media sessions are not reestablished.
  • CallManager (CM) version 6.x and later does not support TCP probe packets in chassis cluster mode. As a result, the existing SCCP sessions will break when there is a failover. You can still create new SCCP sessions during failover.

The PPTP ALG with IPv6 support has the following limitation:

  • Because PPP packets are compressed with Microsoft Point-to-Point Encryption (MPPE) protocol after the tunnel is set up, translation of the IP header in the PPP package cannot be handled; therefore, to make sure PPTP connection works well, the PPTP client must be able to work in dual stack mode. So that an IPv6 PPTP client can accept an IPv4 address for PPP tunnel interface, by which it can communicate with the IPv4 PPTP server without IP address translation for PPP packets.

The RTSP ALG with IPv6 support has the following limitations:

  • Real-Time Streaming Protocol (RTSP) is an Application Layer protocol for controlling the delivery of data with real-time properties. The RTSP ALG supports a peer client, and the server transmits real-time media; it does not support third-party endpoints involved in the transaction.
  • In case of destination NAT or NAT64 for IP address translation, if the RTSP message (including the Session Description Protocol (SDP) application content) length exceeds 2500 bytes, then the RTSP ALG processes only the first 2500 bytes of the message and ignores the rest of the message. In this scenario, the IP address in the RTSP message is not translated if the IP address does not appear in the first 2500 bytes.

The SIP ALG with IPv6 support has the following limitation:

  • When NAT64 with persistent NAT is implemented, the SIP ALG adds the NAT translation to the persistent NAT binding table if NAT is configured on the Address of Record (AOR). Because persistent NAT cannot duplicate the address configured, coexistence of NAT66 and NAT64 configured on the same address is not supported.

    Only one binding is created for the same source IP address.

AppSecure

  • J-Web pages for AppSecure are preliminary.
  • Custom application signatures and custom nested application signatures are not currently supported by J-Web.
  • When ALG is enabled, application identification includes the ALG result to identify the application of the control sessions. Application firewall permits ALG data sessions whenever control sessions are permitted. If the control session is denied, there will be no data sessions. When ALG is disabled, application identification relies on its signatures to identify the application of the control and data sessions. If a signature match is not found, the application is considered unknown. Application firewall handles applications based on the application identification result.

AX411 Access Points

  • On SRX210, SRX240, and SRX650 devices, you can configure and manage a maximum of four access points.
  • On all branch SRX Series devices, managing AX411 WLAN Access Points through a Layer 3 ae interface is not supported.

Chassis Cluster

  • SRX100, SRX210, SRX240, and SRX650 devices have the following chassis cluster limitations:

    • VRRP is not supported.
    • Unified ISSU is not supported.
    • The 3G dialer interface is not supported.
    • On SRX Series device failover, access points on the Layer 2 switch reboot and all wireless clients lose connectivity for 4 to 6 minutes.
    • VDSL Mini-PIMs are not supported in chassis cluster.
    • Queuing on the ae interface is not supported.
    • Group VPN is not supported.
    • On SRX100 and SRX110 devices, switching is not supported in chassis cluster mode.
    • The Chassis Cluster MIB is not supported.
    • Any packet-based services such as MPLS and CLNS are not supported.
    • On the lsq-0/0/0 interface, Link services MLPPP, MLFR, and CRTP are not supported.
    • On the lt-0/0/0 interface, CoS for RPM is not supported.

    Starting with Junos OS Release 12.1X45-D10 and later, sampling features such as flow monitoring, packet capture, and port mirroring are supported on reth interfaces.

    • On all SRX Series devices in a chassis cluster, flow monitoring for version 5 and version 8 is supported. However, flow monitoring for version 9 is not supported.
    • If you use packet capture on reth interfaces, two files are created, one for ingress packets and the other for egress packets based on the reth interface name. These files can be merged outside of the device using tools such as Wireshark or Mergecap.
    • If you use port mirroring on reth interfaces, the reth interface cannot be configured as the output interface. You must use a physical interface as the output interface. If you configure the reth interface as an output interface using the set forwarding-options port-mirroring family inet output command, the following error message is displayed.

      Port-mirroring configuration error.
      Interface type in reth1.0 is not valid for port-mirroring or next-hop-group config

  • Packet-based forwarding for MPLS and ISO protocol families is not supported.
  • The factory default configuration for SRX100 devices automatically enables Layer 2 Ethernet switching. Layer 2 Ethernet switching is not supported in chassis cluster mode for SRX100 devices. If you use the factory default configuration, you must delete Ethernet switching before you enable chassis clustering.
  • On all J Series devices, a Fast Ethernet port from a 4-port Ethernet PIM cannot be used as a fabric link port in a chassis cluster.
  • On all branch SRX Series devices, reth interfaces and the lo0 interface are supported for IKE external interface configuration in IPsec VPN. Other interface types can be configured, but IPsec VPN might not work.
  • On all J Series devices, the ISDN feature on chassis cluster is not supported.

Command-Line Interface (CLI)

  • On all branch SRX Series and J Series devices, the clear services flow command is not supported.
  • On all J Series devices, RADIUS accounting is not supported.
  • On SRX210 and SRX240 devices, J-Web crashes if more than nine users log in to the device by using the CLI. The number of users allowed to access the device is limited as follows:

    • For SRX210 devices: four CLI users and three J-Web users
    • For SRX240 devices: six CLI users and five J-Web users
  • On J6350 devices, there is a difference in the power ratings provided by user documentation (J Series Services Routers Hardware Guide and PIM, uPIM, and ePIM Power and Thermal Calculator) and the power ratings displayed by CLI (by a unit of 1). The CLI display rounds off the value to a lower integer, and the ratings provided in user documentation round off the value to the higher integer. As a workaround, follow the user documentation for accurate ratings.
  • On all branch SRX Series devices, the tunnel-queuing option is not supported in chassis cluster mode.

Connectivity Fault Management (CFM)

  • CFM is not supported on the following interfaces:
    • 8-Port Gigabit Ethernet SFP XPIM
    • 2-Port 10-Gigabit Ethernet XPIM
    • 1-Port SFP Mini-PIM
  • CFM is supported only on interfaces with the Ethernet switching family.

Dynamic Host Configuration Protocol (DHCP)

  • On all branch SRX Series devices, DHCP relay is unable to update the binding status based on DHCP_RENEW and DHCP_RELEASE messages.
  • On all branch SRX Series and J Series devices, DHCPv6 client authentication is not supported.
  • On all branch SRX Series and J Series devices, DHCP client and server functionality is not supported in a chassis cluster.
  • On all branch SRX Series devices, DHCPv6 client does not support:
    • Temporary addresses
    • Reconfigure messages
    • Multiple identity association for nontemporary addresses (IA_NA)
    • Multiple prefixes in a single identity association for prefix delegation (IA_PD)
    • Multiple prefixes in a single router advertisement

Flow and Processing

  • On all branch SRX Series devices, GRE fragmentation is not supported in packet-based mode.
  • On all branch SRX Series and J Series devices, a mismatch between the Firewall Counter Packet and Byte Statistics values, and between the Interface Packet and Byte Statistics values, might occur when the rate of traffic increases above certain rates of traffic.
  • On SRX100, SRX210, SRX220, SRX240, and SRX650 devices, due to a limit on the number of large packet buffers, Routing Engine based sampling might run out of buffers for packet sizes greater than or equal to 1500 bytes and hence those packets will not be sampled. The Routing Engine could run out of buffers when the rate of the traffic stream is high.
  • On SRX100 and SRX240 devices, the data file transfer rate for more than 20 Mbps is reduced by 60 percent with the introduction of Junos Pulse 1.0 client as compared to the Acadia client that was used before Junos OS Release 11.1.
  • On SRX100, SRX210, SRX220, SRX240, and SRX650 devices, the default authentication table capacity is 10,000; the administrator can increase the capacity to a maximum of 15,000.
  • On all branch SRX Series and J Series devices, when devices are operating in flow mode, the Routing Engine side cannot detect the path MTU of an IPv6 multicast address (with a large size packet).
  • On all branch SRX Series devices, you cannot configure route policies and route patterns in the same dial plan.
  • On all J Series devices, even when forwarding options are set to drop packets for the ISO protocol family, the device forms ES-IS adjacencies and transmits packets because ES-IS packets are Layer 2 terminating packets.
  • On all branch SRX Series and J Series devices, high CPU utilization triggered for reasons such as CPU intensive commands and SNMP walks causes the BFD protocol to flap while processing large BGP updates.
  • On SRX210, SRX240, and J Series devices, broadcast TFTP is not supported when flow is enabled on the device.
  • On all branch SRX Series devices, the maximum number of concurrent sessions for SSH, Telnet, and Web is as follows:

    Sessions

    SRX100

    SRX210

    SRX220

    SRX240

    SRX550

    SRX650

    SSH

    3

    3

    250

    5

    5

    5

    Telnet

    3

    3

    250

    5

    5

    5

    Web

    7

    7

    7

    7

    7

    7

    Note: These defaults are provided for performance reasons.

  • On SRX210 and SRX240 devices, for optimized efficiency, we recommend that you limit use of CLI and J-Web to the numbers of sessions listed in the following table:

    Device

    CLI

    J-Web

    Console

    SRX210

    3

    3

    1

    SRX240

    5

    5

    1

  • On SRX100 devices, Layer 3 control protocols (OSPF, using multicast destination MAC address) on the VLAN Layer 3 interface work only with access switch ports.

Hardware

  • On all branch SRX Series devices, a chassis cluster is only supported when both devices are the same model and have the same amount of memory. Thus, a chassis cluster is not supported if it combines SRX Series branch devices with 1-GB and 2-GB memory in the same cluster.

Interfaces and Routing

  • When using SRX Series devices in chassis cluster mode, we recommend that you do not configure any local interfaces (or combination of local interfaces) along with redundant Ethernet interfaces.

    For example:

    The following configuration of chassis cluster redundant Ethernet interfaces, in which interfaces are configured as local interfaces, is not recommended:

    ge-2/0/2 {unit 0 {family inet { address 1.1.1.1/24;}}}

    The following configuration of chassis cluster redundant Ethernet interfaces, in which interfaces are configured as part of redundant Ethernet interfaces, is recommended:

    interfaces {ge-2/0/2 {gigether-options {redundant-parent reth2;}}reth2 {redundant-ether-options {redundancy-group 1;}unit 0 {family inet {address 1.1.1.1/24;}}}}
  • On SRX100, SRX110, SRX210, and SRX220 devices, you cannot configure the same VRRP group ID on different interfaces of a single device.
  • On all branch SRX Series devices, PIM does not support upstream and downstream interfaces across different virtual routers in flow mode
  • On all branch SRX Series devices, the Link Layer Discovery Protocol (LLDP) is not supported on reth interfaces.
  • On all J Series devices, the flow monitoring version 9 has the following limitations:
    • Routing Engine based flow monitoring V5 or V8 mode is mutually exclusive with inline flow monitoring V9.
    • Flow aggregation for V9 export is not supported.
    • Only UDP over IPv4 or IPv6 protocol can be used as the transport protocol.
    • Only the standard IPv4 or IPv6 template is supported for exporting flow monitoring records.
    • User-defined or special templates are not supported for exporting flow monitoring records.
  • On all branch SRX Series and J Series devices, flow monitoring IPv6 version 9 has the following limitations:
    • MPLS in not supported.
    • User-defined version 9 templates are not supported.
    • Routing Engine based flow monitoring version 9 is not supported.
    • Flow monitoring and accounting are not supported in chassis cluster mode.
    • Flow monitoring and accounting are not supported on an ae interface.
    • J-Web for IPv6 sampled packets is not supported.
    • SNMP queries for IPv6 sampled packets are not supported
    • Flow monitoring can be configured in version 5, version 8, or version 9 export mode. Up to eight version 9 collectors are supported in export mode.
    • Scope of accounting of IPv6 flow monitoring version 9 packets associated with pseudointerfaces (such as IRB, ML, LAG, VLAN, and GRE) is not supported.
    • Creation of an SCTP session (parallel to TCP) between an exporter and a collector for gathering flow monitoring information is not supported.
    • Maximum flow sessions that might be supported include:
      • A device with 1-GB RAM, such as an SRX220 device, might support up to 15,000 flow monitoring sessions at a time.
      • A device with 2-GB RAM, such as an SRX650 device, might support up to 59,900 flow monitoring sessions at a time.
    • Changes in source AS and destination AS are not immediately reflected in exported flows.
  • On all branch SRX Series devices, IPv6 traffic transiting over IPv4 based IP over IP tunnel (for example, IPv6-over-IPv4 using ip-x/x/x interface) is not supported.
  • The ATM interface takes more than 5 minutes to come up when CPE is configured in ANSI-DMT mode and CO is configured in automode. This occurs only with ALU 7300 DSLAM, due to limitation in current firmware version running on the ADSL Mini-PIM.
  • On SRX100 and J Series devices, dynamic VLAN assignments and guest VLANs are not supported.
  • On all branch SRX Series devices, the subnet directed broadcast feature is not supported.
  • On SRX650 devices, Ethernet switching is not supported on Gigabit Ethernet interfaces (ge-0/0/0 through ge-0/0/3 ports).
  • On SRX210, SRX220, SRX240, and SRX650 devices, when using stream mode security logging, security logs cannot be sent to NSM or another syslog server if the server is in the same subnet as interface fxp0. Stream mode syslog can only be routed out via revenue ports and not via the fxp0 interface. This implies that you cannot configure the security log server in the same subnet as the fxp0 interface.
  • On all branch SRX Series devices, the number of child interfaces per node is restricted to 4 on the reth interface and the number of child interfaces per reth interface is restricted to 8.
  • On SRX240 High Memory devices, traffic might stop between the SRX240 device and the Cisco switch due to link mode mismatch. We recommend setting the same value to the autonegotiation parameters on both ends.
  • On SRX100 devices, the link goes down when you upgrade FPGA on 1xGE SFP. As a workaround, run the restart fpc command and restart the FPC.
  • On SRX210 devices with VDLS2, ATM COS VBR-related functionality cannot be tested.
  • On SRX210 devices, IGMPv2 JOINS messages are dropped on an IRB interface. As a workaround, enable IGMP snooping to use IGMP over IRB interfaces.
  • On all J Series devices, the DS3 interface does not have an option to configure multilink-frame-relay-uni-nni (MFR).
  • On SRX210, SRX220, and SRX240 devices, every time the VDSL2 Mini-PIM is restarted in the ADSL mode, the first packet passing through the Mini-PIM is dropped.
  • On all branch SRX Series devices, the RPM server operation does not work when the probe is configured with the option destination-interface.
  • On all J Series devices, LLDP is not supported on routed ports.
  • In J Series xDSL PIMs, mapping between IP CoS and ATM CoS is not supported. If the user configures IP CoS in conjunction with ATM CoS, the logical interface level shaper matching the ATM CoS rate must be configured to avoid congestion drops in segmentation and reassembly (SAR) as shown in the following example:

    set interfaces at-5/0/0 unit 0 vci 1.110set interfaces at-5/0/0 unit 0 shaping cbr 62400 ATM COSset class-of-service interfaces at-5/0/0 unit 0 scheduler-map sche_map IP COSset class-of-service interfaces at-5/0/0 unit 0 shaping-rate 62400 ADD IFL SHAPER
  • On SRX650 devices, MAC pause frame and FCS error frame counters are not supported for the interfaces ge-0/0/0 through ge-0/0/3.
  • On SRX240 and SRX650 devices, the VLAN range from 3967 to 4094 falls under the reserved VLAN address range, and the user is not allowed any configured VLANs from this range.
  • On SRX650 devices, the last four ports of a 24-Gigabit Ethernet switch GPIM can be used either as RJ-45 or small form-factor pluggable transceiver (SFP) ports. If both are present and providing power, the SFP media is preferred. If the SFP media is removed or the link is brought down, then the interface will switch to the RJ-45 medium. This can take up to 15 seconds, during which the LED for the RJ-45 port might go on and off intermittently. Similarly, when the RJ-45 medium is active and an SFP link is brought up, the interface will transition to the SFP medium, and this transition could also take a few seconds.
  • On SRX210 devices, the USB modem interface can handle bidirectional traffic of up to 19 Kbps. On oversubscription of this amount (that is, bidirectional traffic of 20 Kbps or above), keepalives do not get exchanged, and the interface goes down.
  • On SRX100, SRX210, SRX240, and SRX650 devices, on the Layer 3 ae interface, the following features are not supported:
    • Encapsulations (such as CCC, VLAN CCC, VPLS, and PPPoE)
    • J-Web
    • 10-Gigabit Ethernet
  • On SRX100 devices, the multicast data traffic is not supported on IRB interfaces.
  • On SRX240 High Memory devices, when the system login deny-sources statement is used to restrict the access, it blocks a remote copy between nodes, which is used to copy the configuration during the commit routine. Use a firewall filter on the lo0.0 interface to restrict the Routing Engine access, However, if you choose to use the system login deny-sources statement, check the private addresses that were automatically on lo0.x and sp-0/0/0.x and exclude them from the denied list.
  • On SRX100, SRX210, SRX220, SRX240, SRX650, and all J Series devices, on VLAN-tagged routed interfaces, LLDP is not supported.
  • On SRX210 devices, the DOCSIS Mini-PIM delivers speeds up to a maximum of 100 Mbps throughput in each direction.
  • On SRX550 and SRX650 devices, the aggregate Ethernet (ae) interface with XE member interface cannot be configured with the Ethernet switching family.
  • On all branch SRX Series and J Series devices, the Q-in-Q support on a Layer 3 interface has the following limitations:
    • Double tagging is not supported on reth and ae interfaces.
    • Multitopology routing is not supported in flow mode and in chassis clusters.
    • Dual tagged frames are not supported on encapsulations (such as CCC, TCC, VPLS, and PPPoE).
    • On Layer 3 logical interfaces, input-vlan-map, output-vlan-map, inner-range, and inner-list are not applicable
    • Only TPIDs with 0x8100 are supported, and the maximum number of tags is 2.
    • Dual tagged frames are accepted only for logical interfaces with IPV4 and IPv6 families.
  • On SRX650 devices, LLDP is not supported on the base ports of the device and on the 2-Port 10 Gigabit Ethernet XPIM.
  • On SRX100, SRX110, SRX210, SRX220, SRX240, and SRX550 devices, LACP is not supported on the 1-Port Gigabit Ethernet SFP Mini-PIM.
  • IKEv2 does not support the following features:

    • Policy-based VPN.
    • Dialup tunnels.
    • VPN monitoring.
    • EAP.
    • Multiple child SAs for the same traffic selectors for each QoS value.
    • IP Payload Compression Protocol (IPComp).
    • Traffic selectors.

Intrusion Detection and Prevention (IDP)

  • On all branch SRX Series devices, from Junos OS Release 11.2 and later, the IDP security package is based on the Berkeley database. Hence, when the Junos OS image is upgraded from Junos OS Release 11.1 or earlier to Junos OS Release 11.2 or later, a migration of IDP security package files needs to be performed. This is done automatically on upgrade when the IDP process comes up. Similarly, when the image is downgraded, a migration (secDb install) is automatically performed when the IDP process comes up, and previously installed database files are deleted.

    However, migration is dependent on the XML files for the installed database present on the device. For first-time installation, completely updated XML files are required. If the last update on the device was an incremental update, migration might fail. In such a case, you have to manually download and install the IDP security package using the download or install CLI command before using the IDP configuration with predefined attacks or groups.

    As a workaround, use the following CLI commands to manually download the individual components of the security package from the Juniper Security Engineering portal and install the full update:

    • request security idp security-package download full-update
    • request security idp security-package install
  • On all branch SRX Series devices, IDP does not allow header checks for nonpacket contexts.
  • On SRX100, SRX210, SRX220, SRX240, and SRX650 devices, the maximum supported number of entries in the ASC table is 100,000 entries. Because the user land buffer has a fixed size of 1 MB as a limitation, the table displays a maximum of 38,837 cache entries.
  • On all branch SRX Series devices, with regard to serialization limits, the maximum number of IDP sessions supported is shown in Table 4:

    Table 4: Maximum Number of IDP Sessions

    Branch SRX Series Device1-GB Memory2-GB Memory

    SRX100 and SRX110

    16,000

    16,000

    SRX210

    16,000

    32,000

    SRX220

    16,000

    32,000

    SRX240

    32,000

    64,000

    SRX550

    32,000

    64,000

    SRX650

    32,000

    64,000

  • On all branch SRX Series devices, all IDP policy templates are supported except All Attacks. There is a 100 MB policy size limit for integrated mode and a 150 MB policy size limit for dedicated mode. The current supported IDP policy templates are dynamic based on the attack signatures added. Therefore, be aware that supported templates might eventually grow past the policy size limit.

    On all branch SRX Series devices, the following IDP policies are supported:

    • DMZ_Services
    • DNS_Service
    • File_Server
    • Getting_Started
    • IDP_Default
    • Recommended
    • Web_Server
  • On all branch SRX Series devices, IDP deployed in both active/active and active/passive chassis clusters has the following limitations:
    • No inspection of sessions that fail over or fail back.
    • The IP action table is not synchronized across nodes.
    • The Routing Engine on the secondary node might not be able to reach networks that are reachable only through a Packet Forwarding Engine.
    • The SSL session ID cache is not synchronized across nodes. If an SSL session reuses a session ID and it happens to be processed on a node other than the one on which the session ID is cached, the SSL session cannot be decrypted and will be bypassed for IDP inspection.
  • On all branch SRX Series devices, IDP deployed in active/active chassis clusters has a limitation that for time-binding scope source traffic, if attacks from a source (with more than one destination) have active sessions distributed across nodes, then the attack might not be detected because time-binding counting has a local-node-only view. Detecting this sort of attack requires an RTO synchronization of the time-binding state that is not currently supported.

    Note: On SRX100 devices, IDP chassis cluster is supported in active/backup mode.

IPv6

  • Network and Security Manager (NSM)—Consult the NSM release notes for version compatibility, required schema updates, platform limitations, and other specific details regarding NSM support for IPv6 addressing on SRX Series and J Series devices.

J-Web

  • SRX Series and J Series browser compatibility
    • To access the J-Web interface, your management device requires the following software:
      • Language support—English-version browsers
      • Supported OS—Microsoft Windows XP Service Pack 3
      • Supported browsers

        Device

        Application

        Supported Browsers

        Recommended Browser

        SRX100, SRX110, SRX210, SRX220, SRX240, SRX550, SRX650

        J-Web

        • Mozilla Firefox version 3.x
        • Microsoft Internet Explorer version 7.0

        Note: The New Setup wizard and the PPPoE wizard work best with Mozilla Firefox version 15.x or later.

        Mozilla Firefox version 3.x

    • To use the Chassis View, a recent version of Adobe Flash that supports ActionScript and AJAX (Version 9) must be installed. Also note that the Chassis View is displayed by default on the Dashboard page. You can enable or disable it using options in the Dashboard Preference dialog box, but clearing cookies in Microsoft Internet Explorer also causes the Chassis View to be displayed.
  • On all branch SRX Series devices, in the J-Web interface, there is no support for changing the T1 interface to an E1 interface or vice versa. As a workaround, use the CLI to convert from T1 to E1 and vice versa.
  • On all branch SRX Series and J Series devices, users cannot differentiate between Active and Inactive configurations on the System Identity, Management Access, User Management, and Date & Time pages.
  • On SRX210 devices, there is no maximum length when the user commits the hostname in CLI mode; however, only 58 characters, maximum, are displayed in the J-Web System Identification panel.
  • On all J Series devices, some J-Web pages for new features (for example, the Quick Configuration page for the switching features on J Series devices) display content in one or more modal pop-up windows. In the modal pop-up windows, you can interact only with the content in the window and not with the rest of the J-Web page. As a result, online Help is not available when modal pop-up windows are displayed. You can access the online Help for a feature only by clicking the Help button on a J-Web page.
  • On all branch SRX Series devices, you cannot use J-Web to configure a VLAN interface for an IKE gateway. VLAN interfaces are not currently supported for use as IKE external interfaces.

The PPPoE wizard has the following limitations:

  • While you use the load and save functionality, the port details are not saved in the client file.
  • The Non Wizard connection option cannot be edited or deleted through the wizard. Use the CLI to edit or delete the connections.
  • The PPPoE wizard cannot be launched if the backend file is corrupted.
  • The PPPoE wizard cannot be loaded from the client file if non-wizard connections share the same units.
  • The PPPoE wizard cannot load the saved file from one platform to another platform.
  • There is no backward compatibility between PPPoE wizard Phase 2 to PPPoE wizard Phase 1. As a result, the PPPoE connection from Phase 2 will not be shown in Phase 1 when you downgrade to an earlier release.

The New Setup wizard has the following limitations:

  • The Existing Edit mode might not work as expected if you previously configured the device manually, without using the wizard.
  • Edit mode might overwrite outside configurations such as Custom Application, Policy Name, and zone inbound services.
  • In create new mode, when you commit your configuration changes, your changes will overwrite the existing configuration.
  • VPN and NAT wizards are not compatible with the New Setup wizard; therefore the VPN or NAT wizard configuration will not be reflected in the New Setup wizard or vice versa.
  • By default, 2 minutes are required to commit a configuration using the New Setup wizard.
  • On SRX650 devices, the default mode configures only the ge-0/0/1 interface under the internal zone.
  • You might encounter usability issues if you use Microsoft Internet Explorer version 7 or 8 to launch the New Setup wizard.
  • If you refresh your browser after you download the license, the factory mode wizard is not available.
  • When you commit the configuration, the underlying Web management interface changes, and you do not receive a response about the commit status.
  • Webserver ports 80 (HTTP) and 443 (HTTPS) on the DMZ or internal zone are overshadowed if Web management is enabled on the Internet zone not configured for destination NAT. As a workaround, change the webserver port numbers for HTTP and HTTPS by editing the recommended policies on the Security policies page.
  • Images, buttons, and spinner (indicating that the configuration is being applied) on the wizard screen do not initially appear when the browser cache is cleared.

Layer 2 Transparent Mode

  • DHCP server propagation is not supported in Layer 2 transparent mode.
  • Layer 2 Bridging and Transparent Mode— On all SRX Series devices, bridging and transparent mode are not supported on Mini-Physical Interface Modules (Mini-PIMs).

Network Address Translation (NAT)

  • Single IP address in a source NAT pool without PAT—The number of hosts that a source NAT pool without PAT can support is limited to the number of addresses in the pool. When you have a pool with a single IP address, only one host can be supported, and traffic from other hosts is blocked because there are no resources available.

    If a single IP address is configured for a source NAT pool without PAT when NAT resource assignment is not in active-backup mode in a chassis cluster, traffic through node 1 will be blocked.

  • For all ALG traffic, except FTP, we recommend that you not use the static NAT rule options source-address or source-port. Data session creation can fail if these options are used, because the IP address and the source port value, which is a random value, might not match the static NAT rule. For the same reason, we also recommend that you not use the source NAT rule option source-port for ALG traffic.

    For FTP ALG traffic, the source-address option can be used because an IP address can be provided to match the source address of a static NAT rule.

    Additionally, because static NAT rules do not support overlapping addresses and ports, they should not be used to map one external IP address to multiple internal IP addresses for ALG traffic. For example, if different sites want to access two different FTP servers, the internal FTP servers should be mapped to two different external IP addresses.

  • Maximum capacities for source pools and IP addresses have been extended on SRX650 devices, as follows:

    Devices

    Source NAT Pools

    PAT Maximum Address Capacity

    Pat Port Number

    Source NAT Rules Number

    SRX650 (High Memory devices)

    1024

    1024

    64M

    1024

    SRX650 (Low Memory devices)

    256

    256

    16M

    1024

    Increasing the capacity of source NAT pools consumes memory needed for port allocation. When source NAT pool and IP address limits are reached, port ranges should be reassigned. That is, the number of ports for each IP address should be decreased when the number of IP addresses and source NAT pools is increased. This ensures NAT does not consume too much memory. Use the port-range statement in configuration mode in the CLI to assign a new port range or the pool-default-port-range statement to override the specified default.

    Configuring port overloading should also be done carefully when source NAT pools are increased.

    For source pool with PAT in range (63,488 through 65,535), two ports are allocated at one time for RTP/RTCP applications, such as SIP, H.323, and RTSP. In these scenarios, each IP address supports PAT, occupying 2048 ports (63,488 through 65,535) for ALG module use.

  • NAT rule capacity change—To support the use of large-scale NAT at the edge of the carrier network, the device-wide NAT rule capacity has been changed.

    The number of destination and static NAT rules has been incremented as shown in Table 5. The limitation on the number of destination-rule-set and static-rule-set has been increased.

    Table 5 provides the requirements per device to increase the configuration limitation as well as to scale the capacity for each device.

    Table 5: Number of Rules on SRX Series and J Series Devices

    NAT Rule Type

    SRX100

    SRX210

    SRX240

    SRX650

    J Series

    Source NAT rule

    512

    512

    1024

    1024

    512

    Destination NAT rule

    512

    512

    1024

    1024

    512

    Static NAT rule

    512

    512

    1024

    6144

    512

    The restriction on the number of rules per rule set has been increased so that there is only a device-wide limitation on how many rules a device can support. This restriction is provided to help you better plan and configure the NAT rules for the device.

  • On all branch SRX Series devices, in case of SSL proxy, sessions are whitelisted based on the actual IP address and not on the translated IP address. Because of this, in the whitelist configuration of the SSL proxy profile, the actual IP address should be provided and not the translated IP addresses.

    Example:

    Consider a destination NAT rule that translates destination IP address 20.20.20.20 to 5.0.0.1 using the following commands:

    • set security nat destination pool d1 address 5.0.0.1/32
    • set security nat destination rule-set dst-nat rule r1 match destination-address 20.20.20.20/32
    • set security nat destination rule-set dst-nat rule r1 then destination-nat pool d1

    In the above scenario, to exempt a session from SSL proxy inspection, the following IP address should be added to the whitelist:

    • set security address-book global address ssl-proxy-exempted-addr 20.20.20.20/32
    • set services ssl proxy profile ssl-inspect-profile whitelist ssl-proxy-exempted-addr

Power over Ethernet (PoE)

  • On SRX210-PoE devices, SDK packages might not work.

Security Policies

  • On all branch SRX Series devices, the current SSL proxy implementation has the following connectivity limitations:
    • The SSLv2 protocol is not supported. SSL sessions using SSLv2 are dropped.
    • SSL sessions where client certificate authentication is mandatory are dropped.
    • SSL sessions where renegotiation is requested are dropped.
  • On all branch SRX Series devices, for a particular session, the SSL proxy is only enabled if a relevant feature related to SSL traffic is also enabled. Features that are related to SSL traffic are IDP, application identification, application firewall, and application tracking. If none of the above listed features are active on a session, the SSL proxy bypasses the session and logs are not generated in this scenario.
  • On all branch SRX Series and J Series devices, you cannot configure the following IP addresses as negated addresses in a policy:
    • Wildcard addresses
    • IPv6 addresses
    • Addresses such as any, any-ipv4, any-IPv6, and 0.0.0.0
  • When a range of addresses or a single address is negated, it can be divided into multiple addresses. These negated addresses are shown as a prefix or a length that requires more memory for storage on a Packet Forwarding Engine.
  • Each platform has a limited number of policies with negated addresses. A policy can contain 10 source or destination addresses. The capacity of the policy depends on the maximum number of policies that the platform supports.
  • J Series devices do not support the authentication order password radius or password ldap in the edit access profile profile-name authentication-order command. Instead, use order radius password or ldap password.

Simple Network Management Protocol (SNMP)

  • On all J Series devices, the SNMP NAT related MIB is not supported.

Switching

  • Layer 2 transparent mode support—On SRX100, SRX110, SRX210, SRX220, SRX240, SRX550, and SRX650 devices, the following features are not supported for Layer 2 transparent mode:

    • G-ARP on the Layer 2 interface
    • STP
    • IP address monitoring on any interface
    • Transit traffic through IRB
    • IRB interface in a routing instance
    • IRB interface handling of Layer 3 traffic

      Note: The IRB interface is a pseudointerface and does not belong to the reth interface and redundancy group.

  • On SRX100, SRX210, SRX240, and SRX650 devices, change of authorization is not supported with 802.1x.
  • On SRX100, SRX110, SRX210, SRX240, SRX550, and SRX650 devices, on the routed VLAN interface, the following features are not supported:
    • IPv6 (family inet6)
    • IS-IS (family ISO)
    • Class of service
    • Encapsulations (Ether CCC, VLAN CCC, VPLS, PPPoE, and so on) on VLAN interfaces
    • CLNS
    • PIM
    • DVMRP
    • VLAN interface MAC change
    • G-ARP
    • Change VLAN-Id for VLAN interface

Unified Access Control

  • During SRX device communication to the Infranet Controller (IC), the connection remains in attempt-next state preventing a successful communication. This happens when an outgoing interface used to connect the IC is a part of routing-instance.

Unified Threat Management (UTM)

  • The quarantine action is supported only for UTM Enhanced Web Filtering or Juniper enhanced type of Web filtering.
  • On SRX550 devices configured with Sophos Antivirus, certain files whose sizes are larger than the max-content-size might not go into fallback unlike other AV engines and instead end up being detected as clean file for few protocols which does not pre-declare the content size.

Upgrade and Downgrade

  • On all J Series devices, the Junos OS upgrade might fail due to insufficient disk space if the CompactFlash is smaller than 1 GB in size. We recommend using a 1-GB compact flash for Junos OS Release 10.0 and later.
  • On SRX100, SRX210, SRX220, SRX240, and SRX650 devices, when you connect a client running Junos Pulse 1.0 to an SRX Series device that is a running a later version of Junos Pulse, the client will not be upgraded automatically to the later version. You must uninstall Junos Pulse 1.0 from the client and then download the later version of Junos Pulse from the SRX Series device.
  • On the SRX240B2 and SRX240H2 models, when you try to upgrade from Junos OS Release 11.4 to Junos OS Release 12.1X44, 12.1X45, 12.1X46, or 12.1X47, the upgrade fails when attempting to validate the configuration. To resolve this, use the no-validate option.

USB

  • On all branch SRX Series devices, frequent plug and play of USB keys is not supported. You must wait for the device node creation before removing the USB key.

Virtual Private Networks (VPNs)

  • On SRX Series devices, if an IPsec VPN tunnel is established using IKEv2, a small number of packet drops might be observed during CHILD_SA rekey as a result of "bad SPI" being logged.

    This occurs only when the SRX Series device is the responder for this rekey and the peer is a non-Juniper Networks device, and the latency between the peers is low and the packet rate is high.

    To avoid this issue, ensure that the SRX Series device always initiates the rekeys by setting its IPsec lifetime to a lower value than that of the peer.

  • On all branch SRX Series devices, when you download the Pulse client using the Mozilla browser, the “Launching the VPN Client” page is displayed when Junos Pulse is still downloading. However, when you download the Pulse client using Microsoft Internet Explorer, the “Launching the VPN Client” page is displayed after Junos Pulse has been downloaded and installed.
  • On SRX100, SRX210, SRX240, and SRX650 devices, while configuring dynamic VPN using the Junos Pulse client, when you select the authentication-algorithm as sha-256 in the IKE proposal, the IPsec session might not get established.
  • RIP is not supported in point-to-multipoint (P2MP) VPN scenarios including AutoVPN deployments. We recommend OSPF or IBGP for dynamic routing when using P2MP VPN tunnels.
  • On all branch SRX Series devices, configuring XAuth with AutoVPN secure tunnel (st0) interfaces in point-to-multipoint mode and dynamic IKE gateways is not supported.

The IPv6 IPsec VPN implementation has the following limitations:

  • Devices with IPv6 addressing do not perform fragmentation. IPv6 hosts should either perform path MTU discovery or send packets smaller than the IPv6 minimum MTU size of 1280 bytes.
  • Because IPv6 addresses are 128 bits long compared to IPv4 addresses, which are 32-bits long, IPv6 IPsec packet processing requires more resources. Therefore, a small performance degradation is observed.
  • The dynamic VPN server must be a standalone branch SRX Series device. The dynamic VPN feature is not supported on high-end SRX Series devices or on branch SRX Series devices in a chassis cluster.
  • The IPv6 IPsec VPN does not support the following functions:
    • Remote Access—XAuth, config mode, and shared IKE identity with mandatory XAuth
    • IKE authentication—PKI or DSA
    • IKE peer type—Dynamic IP
    • NAT-T
    • VPN monitoring
    • NHTB
    • Packet reordering for IPv6 fragments over tunnels is not supported
    • IPv6 link-local address

See VPN Feature Support for IPv6 Addresses for more information about IPv6 address support in VPN features.

On all branch SRX Series devices, when you enable VPN, overlapping of the IP addresses across virtual routers is supported with following limitations:

  • An IKE external interface address cannot overlap with any other virtual router.
  • An internal/trust interface address can overlap across virtual routers.
  • An st0 interface address cannot overlap in route-based VPN in point-to-multipoint tunnels such as NHTB.
  • An st0 interface address can overlap in route-based VPN in point-to-point tunnels.

SRX100, SRX210, and SRX240 devices have the following limitations:

  • The IKE configuration for the Junos Pulse client does not support the hexadecimal preshared key.
  • The Junos Pulse client IPsec does not support the AH protocol and the ESP protocol with NULL authentication.
  • When you log in through the Web browser (instead of logging in through the Junos Pulse client) and a new client is available, you are prompted for a client upgrade even if the force-upgrade option is configured. Conversely, if you log in using the Junos Pulse client with the force-upgrade option configured, the client upgrade occurs automatically (without a prompt).

Related Documentation

Modified: 2017-04-24