Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

What’s Changed

Learn about what changed in this release for vSRX.

General Routing

  • Verified the qualification of ordered-by-user in the hierarchies (ACX Series, EX Series, MX Series, QFX Series, SRX Series, vMX, and vSRX)—The requested hierarchies are reviewed and checked to confirm if they qualify for the ordered-by-user list type. If they do not, the flag autosort is included in the DDL definition for the list, making it ordered-by-system. The hierarchies are now indexed. The benefits from this arrangement are we get accurate data modeling and optimized configuration load in the user interface infrastructure.

  • In the past inet6flow.0 was not allowed to be a primary rib in a rib-group. Starting with Release 22.3 this is now allowed.

Junos XML API and Scripting

  • The xmlns:junos attribute includes the complete software version string (ACX Series, EX Series, MX Series, PTX Series, QFX Series, SRX Series, vMX, and vSRX)—The xmlns:junos namespace string in XML RPC replies includes the complete software version release number, which is identical to the version emitted by the show version command. In earlier releases, the xmlns:junos string includes only partial software version information.

Network Management and Monitoring

  • operator login class is restricted from viewing NETCONF trace files that are no-world-readable (ACX Series, EX Series, MX Series, PTX 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.

VPNs

  • 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.