Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

Was hat sich in Version 21.4R3 geändert?

Flow-basierte paketbasierte Verarbeitung

  • Verbindung mit dem OCSP-Server für die Sperrprüfung nicht möglich (Geräte der SRX-Serie und vSRX): Wenn die Sperrprüfung mit OCSP durchgeführt wird, versucht das SRX-Gerät nicht, eine Verbindung mit dem OCSP-Server herzustellen, wenn die URL des OCSP-Servers einen Domänennamen enthält, den der DNS-Server nicht auflösen kann. In diesem Fall, wenn das SRX-Gerät keine Verbindung zum OCSP-Server herstellen kann und eine der folgenden Konfigurationsoptionen festgelegt ist, lässt die OCSP-Sperrprüfung entweder die Verwendung von CRL:u zu oder greift auf die Verwendung von CRL:u zurück

    • set security pki ca-profile OCSP-ROOT revocation-check ocsp connection-failure disable

    • set security pki ca-profile OCSP-ROOT revocation-check ocsp connection-failure fallback-crl

    Wenn das SRX-Gerät keine Verbindung zum OCSP-Server herstellen kann und diese Optionen nicht konfiguriert sind, schlägt die Zertifikatsüberprüfung fehl.

    [Siehe ocsp (Sicherheits-PKI).]

  • Änderungen an der TCP-MSS-Überschreibungspriorität für GRE (SRX-Serie und vSRX 3.0)

    Bei Firewalls der SRX-Serie und virtuellen vSRX-Firewalls darf die maximale Segmentgröße (TCP-MSS) des Transmission Control Protocol in GRE über IPsec-Szenarien (GREoIPsec) nicht außer Kraft gesetzt werden. Dies kann zu einer stärkeren Fragmentierung des Netzwerks führen, da der GREoIPsec-Datenverkehr nicht für TCP-MSS modifiziert wird. Um sicherzustellen, dass TCP-MSS mit GREoIPsec funktioniert, stellen Sie sicher, dass Sie die Priorität von MSS, die auf den TCP-Datenverkehr angewendet wird, in der folgenden Reihenfolge festlegen (höchste bis niedrigste):

    • gre-in und gre-out basierend auf der Richtung für den GREoIPSec-TCP-Datenverkehr.

    • ipsec-vpn für GREoIPsec und IPsec-Datenverkehr.

    • all-tcp für den gesamten TCP-Datenverkehr.

Netzwerkmanagement und -überwachung

  • Änderungen an der NETCONF <edit-config> RPC-Antwort (ACX-Serie, EX-Serie, MX-Serie, PTX-Serie, QFX-Serie, SRX-Serie, vMX und vSRX) – Wenn der Vorgang einen Fehler zurückgibt, gibt der NETCONF-Server kein <load-error-count> Element in der <edit-config> RPC-Antwort aus. In früheren Versionen enthält die <edit-config> RPC-Antwort das <load-error-count> Element, wenn der Vorgang fehlschlägt.

Plattform und Infrastruktur

  • Das Gerät bricht die Sitzung nicht mit einer Serverzertifikatkette von mehr als 6 ab. PR1663062

Unified Threat Management (UTM)

  • CLI-Updates für die Inhaltsfilterung (SRX-Serie und vSRX): Wir haben die folgenden Aktualisierungen für die CLI für die Inhaltsfilterung:

    • Die Liste der Dateitypen, die für die Übereinstimmungskriterien für Inhaltsfilterregeln unterstützt werden, wurde gekürzt. Anstatt verschiedene Varianten eines Dateityps eindeutig darzustellen, repräsentiert jetzt nur noch eine file-type Zeichenfolge alle Varianten. Daher wird die Ausgabe auch aktualisiert, um sie an die neuen Dateitypen anzupassen, die show security utm content-filtering statistics in den Regelübereinstimmungskriterien verfügbar sind.
    • Die Sicherheitsprotokollierungsoption seclog für die Inhaltsfilterung wurde umbenannt, damit log sie dem Junos OS-Konfigurationsstandard entspricht.
    • Die Zeichenfolge, die reason der Sicherheitsprotokollmeldung für die Inhaltsfilterung zugeordnet ist, wurde umformuliert.

    [Siehe Inhaltsfilterung (Sicherheits-UTM-Richtlinie), Inhaltsfilterung (Sicherheitsfunktionsprofil) und UTM-Statistik zur Sicherheits-UTM-Inhaltsfilterung anzeigen.]