Pare-feu incapable de se connecter à Panorama en raison de la fragmentation

30863

Created On 10/24/19 03:44 AM - Last Modified 06/09/23 01:16 AM

Symptom

Le pare-feu ne peut pas se connecter à Panorama en raison de la fragmentation et du problème MTU

Environment

Tous les pare-feu de Palo Alto.
Panorama 7.1 et au-dessus.
PAN-OS 7.1 et au-dessus.

Cause

La fragmentation des périphériques réseau entre Firewall et Panorama provoque le problème. Les communications FW vers panorama sont basées sur SSL (TCP-3978) qui est marqué comme ne pas fragmenter.
Lorsqu’un paquet Ethernet standard (1500 octets de long) est envoyé, il peut être abandonné si l’infrastructure a une valeur MTU inférieure à 1500.
Dans l’exemple ci-dessous, la MTU est définie sur 1500 octets (par défaut) et les paquets de taille supérieure à 1400 octets devront être fragmentés avant de pouvoir être envoyés hors de l’interface. Si l'indicateur Ne pas fragmenter (DF) est défini sur l'en-tête IP du paquet, les périphériques situés le long de la route devront abandonner le paquet et envoyer le code d'erreur ICMP « Fragmentation nécessaire mais jeu de bits DF » (type 3, code 4) à la source. Étant donné qu’une connexion SSL (HTTPS) est utilisée, les paquets avec le certificat de serveur sont généralement de gros paquets et peuvent être abandonnés, ce qui entraîne l’échec de la négociation SSL/TLS.

Ceci peut être vérifié à l’aide des trois étapes suivantes.

Confirmez sur le pare-feu que l’état Panorama est considéré comme déconnecté à l’aide de l’état du panorama d’exposition.

fw01 (active)> afficher le panorama-statut
Panorama Server 1 : 10.66.57.131
    Connecté : non
    État HA : déconnecté

Panorama Server 2 : 10.32.6.131
    Connecté : non
    État HA : déconnecté

Confirmez sur le pare-feu que la connexion à Panorama est affichée comme « établie ».

fw01(actif)> afficher netstat tout oui numérique oui | match 3978
tcp 0 0 10.4.110.26:37305 10.66.57.131:3978 ÉTABLI
tcp 0 0 10.4.110.26:48055 10.32.6.131:3978 ÉTABLI

À l’aide de TCPdump, capturez les paquets sur la gestion du pare-feu. Le PCAP montre« mauvaise longueur hdr 32 - trop long, > 24 » message

20:11:44.017947 IP 10.66.57.131.pan-panorama > 10.4.110.26.34412: P 2897:3250 (353) ack 296 victoire 61 <nop,nop,timestamp 1667104066="" 660833754="">
20:11:44.017980 IP 10.4.110.26.34412 > 10.66.57.131.pan-panorama: . ack 1 victoire 115 <nop,nop,timestamp 660833767="" 1667104066,nop,nop,sack="" 1="" {2897:3250}="">
20:11:44.017986 IP 10.66.57.131.pan-panorama > 10.4.110.26.34412: . [mauvaise longueur hdr 32 - trop long, > 24]
20:11:44.364196 IP 10.66.57.131.pan-panorama > 10.4.110.26.34412: . [mauvaise longueur hdr 32 - trop long, > 24]
20:11:44.367325 IP 10.66.57.131 > 10.4.110.26: tcp</nop,nop,timestamp> </nop,nop,timestamp>

Ping du pare-feu à Panorama sans fragment et valeur MTU définie sur le pare-feu. Le ping échoue avec les messages nécessaires à Frag .La sortie ci-dessous sera reçue si les périphériques réseau le long de l’itinéraire peuvent répondre avec un ICMP inaccessible.

fw01(actif)> ping do-not-fragment yes taille 1500 hôte 10.66.57.131
À partir de 10.4.110.26 icmp_seq=1 Frag nécessaire et DF set (mtu = 1500)
À partir de 10.4.110.26 icmp_seq=1 Frag nécessaire et DF set (mtu = 1500)
À partir de 10.4.110.26 icmp_seq=1 Frag nécessaire et DF set (mtu = 1500)

REMARQUE: 10.66.57.131 est l’IP Panorama

Répétez l’étape ci-dessus dans la direction opposée, du panorama au pare-feu pour déterminer où se trouve notre problème.

Resolution

Solution-1

Déterminez l’unité de transmission maximale (MTU) exacte qui peut être utilisée entre le pare-feu et Panorama. Pour ce faire, effectuez un ping du pare-feu vers Panorama (ou vice versa) sans option de fragment avec différentes valeurs MTU commençant par le ping le plus élevé jusqu’à ce que le ping réussisse. Dans cet exemple, la taille de paquet de 1450 fonctionne correctement sans aucune option de fragment utilisée.

fw01 (active)> ping do-not-fragment oui taille 1450 hôte 10.66.57.131
PING 10.66.57.131 (10.66.57.131) 1450(1478) octets de données.
1458 octets à partir de 10.66.57.131 : icmp_seq=1 ttl=48 temps=238 ms
1458 octets à partir de 10.66.57.131: icmp_seq=2 ttl=48 temps=178 ms

REMARQUE: 10.66.57.131 est l’IP Panorama

Une fois la taille MTU déterminée, accédez à l’interface de gestion du pare-feu et de Panorama et remplacez la MTU par la valeur déterminée. Dans cet exemple, c’est 1450.

GUI : Configuration de >'> interfaces > gestion >

Une fois que le MTU est modifié, engagez les modifications sur le pare-feu et panorama. La connectivité à Panorama doit être établie en quelques secondes.

Solution-2

La plupart des pare-feu et des routeurs ont la capacité d’ajuster la valeur MSS sur une connexion TCP à travers eux.Ils peuvent réécrire la valeur MSS sur les paquets SYN et SYN-ACK échangés entre le Client et le Serveur. Cela peut être utilisé pour définir la valeur MSS sur la valeur MSS optimale calculée afin que le client et le serveur construisent leurs segments à cette taille.
Le MSS TCP, la taille maximale du segment, est un paramètre du champ options de l’en-tête TCP qui spécifie la plus grande quantité de données, spécifiée en octets, qu’un ordinateur ou un périphérique de communication peut recevoir dans un seul segment TCP. Il n’inclut pas l’en-tête TCP (20octets) ou l’en-tête IP (20octets).
Cette valeur MSS est annoncée (souvent appelée à tort une négociation) des deux côtés pendant le TCP 3WHS.

Chaque côté dit: Je peux accepter des segments TCP jusqu’à la taille de x.

Une fois que chaque partie annonce son MSS, la partie distante est censée envoyer des paquets contenant un segment TCP ne dépassant pas la valeur MSS annoncée.Vous trouverez ci-dessous un exemple de MSS annoncé dans le cadre du 3WHS :

10.1.1.100 192.1.1.100 [SYN] Seq=0 Len=0 MSS=1460 TSV=556758839
192.1.1.100 10.1.1.100 [SYN, ACK] Seq=0 Ack=1 Win=16484 Len=0 MSS=1280 WS=0  
10.1.1.100 192.1.1.100 [ACK] Seq=1 Ack=1 Win=5888 Len=0

Additional Information

KBs associés :
Dépannage de la connectivité Panorama