Limitations connues

Découvrez les limitations connues de cette version pour les pare-feu SRX Series.

Pour obtenir les informations les plus complètes et les plus récentes sur les défauts connus de Junos OS, utilisez l’application en ligne Junos Problem Report Search de Juniper Networks.

Traitement basé sur les flux et les paquets

Les pare-feu SRX configurés en mode paquet, après la mise à niveau vers Junos 24.2R1 et les versions supérieures des versions antérieures, ne transféreront pas le trafic directement après la mise à niveau, car la configuration en mode paquet a changé. Dans les anciennes versions de Junos, lorsque vous configurez la famille d’options de transfert de sécurité définies pour utiliser le mode paquet, MPLS et IPv4 (famille inet) sont automatiquement définis en mode paquet.

À partir de la version 24.2R1 de Junos OS, chaque famille d’adresses peut être configurée séparément en mode paquet ou en mode flux. La valeur par défaut pour IPv4 et IPv6 est le mode flux. Par conséquent, si votre appareil contient la configuration set security forwarding-options family mpls mode packet-based antérieure à la mise à niveau, qui définit la famille IPv4 en mode paquet. Après la mise à niveau, pour restaurer IPv4 en mode paquet, vous devez configurer set security forwarding-options family inet mode packet-based. Validez la configuration et redémarrez l’appareil pour que la modification prenne effet.

Vous pouvez vérifier le mode de transfert actuel du périphérique à l’aide de la commande show security flow statusCLI .

Remarque :
Aucune action requise pour IPv6 ou le mode paquet sélectif à l’aide de filtres de pare-feu

Haute disponibilité

Sur le pare-feu SRX Series, le trafic SCTP (Stream Control Transmission Protocol) échoue en trafic asymétrique sur une configuration haute disponibilité multi nœuds. Pour contourner ce problème, vous pouvez configurer la set security forwarding-process application-services enable-sctp-port-hash commande masquée.
Les pare-feu sur SRX5000 ligne ne prennent pas en charge GTPv1 et GTPv2 pour la configuration asymétrique du trafic. Les pare-feu SRX4600, SRX4300, SRX4200, SRX4100, SRX2300, SRX1600 et SRX1500 prennent en charge GTPv0, GTPv1 et GTPv2 pour une configuration asymétrique du trafic. Pour activer cette fonctionnalité, vous devez configurer le set security forwarding-process application-services enable-gtpu-distribution paramètre.
Avec le routage avancé basé sur des stratégies (APBR), les changements de route en fonction de la configuration fonctionnent correctement. Cependant, il y a un problème lié aux journaux RT_FLOW sur le nœud pair dans la topologie asymétrique de haute disponibilité multi-nœuds. Plus précisément, les journaux n’incluent pas d’informations sur le nom de l’interface entrante de liaison montante ni sur le nombre d’octets/paquets reçus sur cette interface.
Bien que la fonctionnalité de proxy SSL fonctionne sans problème sur le nœud principal, il existe un problème lié aux informations de classification des applications sur le nœud pair. Nous vous recommandons de vous référer aux journaux de session RT_FLOW du nœud principal pour obtenir des détails précis sur l’application.
Exemple : Lorsque le trafic HTTPS passe par les nœuds, le nœud actif identifie l’application standard de couche 7 comme IP :TCP :SSL :HTTP. Toutefois, le nœud pair signale l’application sous la forme IP :TCP :SSL.