What's Changed

Flow-label configuration status for EVPN ELAN services The output for the show evpn instance extensive command now displays the flow-label and flow-label-static operational status for a device and not for the routing instances. A device with flow-label enabled supports flow-aware transport (FAT) flow labels and advertises its support to its neighbors. A device with flow-label-static enabled supports FAT flow labels but does not advertise its capabilities.

Specify the UDP source port in a ping overlay or traceroute overlay operation — In Junos OS releases prior to 22.4R1, you could not configure the udp source port in a ping overlay or traceroute overlay operation. You may now configure this value in an EVPN-VXLAN environment using hash. The configuration option hash will override any other hash-* options that may be used to determine the source port value.

PMI Mode Passthrough ESP traffic: Starting in Junos OS Release 22.1R3, we support the PMI express path processing for passthrough ESP traffic on the SRX4100, SRX4200, and vSRX.

Flow session operational command support for content security (SRX Series and vSRX)—We've extended the show security flow session operational command support to view the details of the content filtering and Web filtering content security features.

[See show security flow session.]

When subscribing to the resource path /junos/system/linecard/environment, the prefix for the streamed path at the collector side was displaying as /junos/linecard/environment. This issue is resolved in Junos OS 23.1R1 and Junos OS Evolved 23.1R1 and the subscription path and the streamed path match to display /junos/system/linecard/environment.

Time zone support for local certificate verification (SRX1500 and SRX5600)—Starting in this release, when the local certificate verification fails, you can see the time zone for the failed local certificate in the command output and system log messages.

Packet Capture is now called Control Plane Packet Capture (SRX Series)— Starting in Junos OS 23.1R1 Release, we’ve renamed Packet Capture to Control Plane Packet Capture under Device Administration menu. You can use this page to capture and analyze control plane traffic on a router.

[See Control Plane Packet Capture.]

operator login class is restricted from viewing NETCONF trace files that are no-world-readable (ACX Series, EX Series, MX Series, QFX Series, SRX Series, vMX, and vSRX)—When you configure NETCONF tracing options at the [edit system services netconf traceoptions] hierarchy level and you restrict file access to the file owner by setting or omitting the no-world-readable statement (the default), users assigned to the operator login class do not have permissions to view the trace file.

Support for the junos:cli-feature YANG extension (ACX Series, EX Series, MX Series, QFX Series, SRX Series, vMX, and vSRX)—The cli-feature YANG extension identifies certain CLI properties associated with some command options and configuration statements. The Junos YANG modules that define the configuration or RPCs include the cli-feature extension statement, where appropriate, in schemas emitted with extensions. This extension is beneficial when a client consumes YANG data models, but for certain workflows, the client needs to generate CLI-based tools.

[See Understanding the Junos DDL Extensions YANG Module.]

XML tag in the get-system-yang-packages RPC reply changed (ACX Series, EX Series, MX Series, QFX Series, SRX Series, vMX, and vSRX)—The get-system-yang-packages RPC reply replaces the xmlproxy-yang-modules tag with the proxy-xml-yang-modules tag in the XML output.

Changes to the NETCONF server's <rpc-error> element when the operation="delete" operation deletes a nonexistent configuration object (ACX Series, EX Series, MX Series, QFX Series, SRX Series, vMX, and vSRX)—We've changed the <rpc-error> response that the NETCONF server returns when the <edit-config> or <load-configuration> operation uses operation="delete" to delete a configuration element that is absent in the target configuration. The error severity is error instead of warning, and the <rpc-error> element includes the <error-tag>data-missing</error-tag> and <error-type>application</error-type> elements.

Deprecating options related to certificate enrollment (Junos)—Starting in Junos OS Release 23.2R1, we’re deprecating earlier CLI options related to Public Key Infrastructure (PKI) to enroll and reenroll local certificate through Simple Certificate Enrolment Protocol (SCEP). The table below shows the Junos CLI commands and configuration statements with the options being deprecated. You can find the same CLI options now available under scep option in these commands and statements.

[See auto-re-enrollment (Security), request security pki local-certificate enroll scep, and request security pki node-local local-certificate enroll.]

Change format of remote-access profile names (SRX Series and vSRX 3.0)—Starting in Junos OS Release 23.1R1, we’ve changed the format of remote-access profile names to enhance end-user experience using Juniper Secure Connect. In releases before Junos OS Release 23.1R1, you configure the remote-access profile name using the realm name at the [edit security remote-access profile realm-name] hierarchy level. But with organizations connecting to several gateways, using the remote-access profile names, such as hr, multiple times in the remote-access connection profile becomes unmanageable.

To address this issue, we introduce a new convention for configuring remote-access profile names. You can now configure profile names with URLs using any of the following formats at the [edit security remote-access profile realm-name] hierarchy level, so that end users can connect to the relevant gateway:

• FQDN/RealmName

• FQDN

• IP address/RealmName

• IP address

For example, you can now use ra.example.com/hr, ra1.example.com/hr and ra.example.com as realm names.

With the introduction of this convention, we need to deprecate the existing default-profile option at the [edit security remote-access] hierarchy level. Your remote-access profiles names will refer to URLs either with an FQDN or with an IP address, depending on how the end users would connect—for example, ra.example.com/hr, ra.example.com, 192.168.1.10/hr or 192.168.1.10. With this change, the end user will now see the connection profile name in the Juniper Secure Connect application as ra.example.com/hr instead of hr, as was the case in earlier releases.

In existing deployments, to ensure a smooth transition with this change, we recommend that you modify the profile name hr in the current configuration to ra.example.com/hr or 192.168.1.10/hr at the [edit] hierarchy level using the follow commands -

[See profile (Juniper Secure Connect).]

Enhancements to automatic reenrollment of a local end-entity (EE) certificate (SRX300, SRX320, SRX550HM, SRX1500, SRX4100, SRX4600, SRX5400, SRX5600, SRX5800)—Starting in Junos OS Release 23.2R1, the option re-enroll-trigger-time-percentage is made optional. But you must configure either re-enroll-time or re-enroll-trigger-time-percentage for the commit-check to be successful.

[See auto-re-enrollment (Security).]

Removal of power mode IPsec Intel QAT option in IPsec VPN (SRX Series)—We have removed the option power-mode-ipsec-qat at [edit security flow] hierarchy level from Junos CLI for display. This option is now hidden as it is not recommended to be configured with multiple IPsec VPN tunnels. We continue to use AES-NI in PMI mode for better performance than QAT.

[See Improving IPsec Performance with PowerMode IPsec.]

Unavailability of default-profile option for remote-access VPN solution (SRX Series and vSRX 3.0)—Starting in Junos OS Release 23.1R1, we’ve hidden the default-profile option at the [edit security remote-access] hierarchy level. In releases before Junos OS Release 23.1R1, you use this option to specify one of the remote-access profiles as the default profile in Juniper Secure Connect. But with changes to the format of remote-access profile names, we no longer require the default-profile option.

We’ve deprecated the default-profile option—rather than immediately removing it—to provide backward compatibility and a chance to make your existing configuration conform to the changed configuration. You’ll receive a warning message if you continue to use the default-profile option in your configuration. However, modifying the current configuration does not affect existing deployments.

In existing deployments, to ensure a smooth transition with this change, we recommend that you modify the profile name in the current configuration hr to ra.example.com/hr or 192.168.1.10/hr at the [edit] hierarchy level using the following commands -

For new configurations, consider the following scenarios to create a new remote-access profile based on how your end users connect using the Juniper Secure Connect application:

• If your end users connect using an IP address, specify the IP address in the profile name.

• If your end users connect using an FQDN, specify the FQDN in the profile name.

• If you need to separate users with different realm values such as hr, append /hr to the IP address or FQDN as follows:

  • [edit security remote-access profile ra.example.net/hr]

  • [edit security remote-access profile 192.168.1.10/hr]

[See default-profile (Juniper Secure Connect) .

Remote-access VPN solution doesn't support hexadecimal pre-shared (SRX Series and vSRX 3.0)—With remote-access VPN solution, for pre-shared-key based authentication method, we support ascii-text format. This means, do not use hexademical format for the pre-shared keys in your configuration for remote-access VPN solution. Therefore, configure the statement ascii-text with ascii text format at [edit security ike policy policy-name pre-shared-key] hierarchy level for use with Juniper Secure Connect.

Enhancement to SCEP PKI Certificate Enrollment—Logical-system option is added to SCEP PKI certificate enrollment.

[See request security pki local-certificate enroll scep.]

Changes to certificate-request payload in IPsec VPN IKE negotiation (SRX Series)—For the trusted-ca/ca-profile configured in the IKE policy for IKE SA negotiation, certificate-request payload of that IKE SA negotiation will contain the CA certificate associated with that trusted-ca/ca-profile. For example, for the trusted-ca/ca-profile in the IKE policy at edit security ike policy policy-name certificate trusted-ca ca-profile certificate-authority , the certificate-request payload of the IKE SA negotiation using this IKE policy policy-name will contain the CA certificate of the CA certificate-authority.

Limited ECDSA Certificate Support with SSL Proxy (SRX Series and vSRX 3.0)—With SSL proxy configured on SRX Series firewall and vSRX Virtual firewalls,

• ECDSA based websites with P-384/P-521 server certificates are not accessible with any root-ca certificate as the security device has limitation to support only P-256 group.

• When RSA based root-ca and P-384/P-521 ECDSA root-ca certificate is configured, all ECDSA websites will not be accessible as SSL-Terminator is negotiated with RSA, which is why the security device is sending only RSA ciphers and sigalgs to the destination web server while doing the SSL handshake. To ensure both ECDSA and RSA-based websites are accessible along with the RSA root certificate, configure a 256-bits ECDSA root certificate.

• In some scenarios, even if 256-bit ECDSA root certificate is used in the SSL proxy configuration, ECDSA based websites with P-256 server certificates are not accessible if the server does not support P-256 groups.

• In other scenarios, even if 256-bit ECDSA root certificate is used in the SSL proxy configuration, ECDSA based websites with P-256 server certificates are not accessible if the server supports sigalgs other than P-256. The issue is seen in hardware offload mode with failing signature verification. As hardware offload for ECDSA certificate is introduced in Junos OS release 22.1R1, this issue will not be observed if you use Junos OS released prior to 22.1R1. Also, the issue is not seen if the SSL-proxy for ECDSA certificate is handled in software.