L'installation de session échoue en raison d'une erreur de collision de hachage de session
65726
Created On 09/25/18 19:22 PM - Last Modified 03/26/21 16:47 PM
Symptom
Environment
- PAN-OS
- NAT
Cause
Sur un Réseau Palo firewall Alto, une session est définie par deux flux unidirections chacun identifiés de façon unique par une clé de 6 tuple : adresse source, destination-adresse, source-port, destination-port, protocole et zone de
A firewall sécurité. Lorsque cela se produit, la firewall baisse du paquet entrant et l’augmentation du compteur global appelé session_hash_insert_duplicate.
Dans les deux diagrammes suivant, vous pouvez voir ce comportement de collision de session avec deux SIP appels. Chaque diagramme comprend un téléphone local, firewall et un téléphone distant.En outre, nous avons énuméré les étapes réseau du flux client-serveur ainsi que les informations IP d’adresse UDP et de port pour chaque paquet.
- Le téléphone local (192.168.1.2) lance un SIP appel au téléphone distant (10.10.10.10) avec un port source et destination de UDP 5060.
- Le trafic sortant correspond à une source NAT policy sur le firewall , traduisant la source à IP 10.10.10.1 et le port source à 56611. Le firewall crée alors une session avec deux flux unidirectdirectnels.Ici, nous pouvons voir les détails de la session de la SIP première session créée par le firewall .
> show session id 27954 Session 27954 c2s flow: source: 192.168.1.2 [l3-trust] dst: 10.10.10.10 proto: 17 sport: 5060 dport: 5060 state: ACTIVE type: FLOW src user: unknown dst user: unknown s2c flow: source: 10.10.10.10 [l3-untrust] dst: 10.10.10.1 proto: 17 sport: 5060 dport: 56611 state: ACTIVE type: FLOW src user: unknown dst user: unknown
- A deuxième connexion est tentée par le téléphone distant peu de temps après. Cette connexion est destinée à firewall l’adresse IP du 10.10.10.1. Le firewall dispose NAT policy d’une destination entrante configurée pour l’adresse du téléphone interne IP de 192.168.1.2.Cet appel n’est jamais établi, mais pourquoi?
Après avoir exécutant une capture de paquet filtrée, nous voyons que le fait de laisser tomber les firewall SIP INVITE paquets de 10.10.10.10.
Les compteurs mondiaux indiquent que les gouttes se produisent pendant la création de session et sont causées par une collision de hachage de session.
> show counter global filter delta yes packet-filter yes Global counters: Elapsed time since last sampling: 9.170 seconds name value rate severity category aspect description -------------------------------------------------------------------------------- session_allocated 1 0 info session resource Sessions allocated session_freed 1 0 info session resource Sessions freed session_install_error 1 0 warn session pktproc Sessions installation error session_install_error_s2c 1 0 warn session pktproc Sessions installation error s2c session_hash_insert_duplicate 1 0 warn session pktproc Session setup: hash insert failure due to duplicate entry
firewallL’appel correspond à l’appel du 10.10.10.10 avec une destination NAT policy entrante et traduit l’adresse de destination IP du 10.10.10.1 au 192.168.1.2. Lorsque les firewall tentatives de création d’une session, il vérifie pour voir si le hachage de session correspond à un flux c2 ou s2c existant.
Si nous comparons le flux c2s de la première session et le flux s2c attendu de la session échouée, nous avons ce qui suit:
| flux c2s: source: 192.168.1.2 [l3-trust] dst: 10.10.10.10 proto: 17 sport: 5060 dport: 5060 état: ACTIVE type: FLOW src utilisateur: utilisateur dst inconnu: inconnu | flux s2c: source: 192.168.1.2 [l3-trust] dst: 10.10.10.10 proto: 17 sport: 5060 dport: 5060 état: ACTIVE type: FLOW src utilisateur: utilisateur dst inconnu: inconnu |
Notez que ces deux flux sont identiques. Si le firewall groupe avait créé la deuxième session, il ne serait pas en mesure d’identifier le flux à utiliser pour un paquet correspondant.Le firewall ne crée pas la deuxième session en raison de ce conflit.
Resolution
Ce comportement peut se manifester de manière unique en fonction de l'implémentation. Pour ce scénario, un utilisateur peut reconfigurer sa source NAT de Dynamic and Port à IP Static NAT. Cela permettra au deuxième appel de correspondre au flux s2c initial au lieu de créer une nouvelle session par le firewall .
Lorsque session_hash_insert_duplicate dans les compteurs mondiaux, gardez à l’esprit comment les politiques pourraient affecter les nouvelles sessions qui correspondent aux flux NAT existants.