Session-Setup scheitert an Session-Hash-Kollisions Fehler

Session-Setup scheitert an Session-Hash-Kollisions Fehler

65738
Created On 09/25/18 19:22 PM - Last Modified 03/26/21 16:47 PM


Symptom


  • Eingehende Verbindungen Scheitern gelegentlich
  • Der firewall ist mit einer Dynamic- und IP Port-Quelle NAT policy für ausgehenden Datenverkehr konfiguriert.
  • Der firewall ist mit einem NAT statischen Ziel  für policyeingehenden Datenverkehr konfiguriert.

 



Environment


  • PAN-OS
  • NAT


Cause


In einem Palo Alto Networks firewall wird eine Sitzung durch zwei unidirektionale Flows definiert, die jeweils eindeutig durch einen 6-Tupel-Schlüssel identifiziert werden: Quelladresse, Zieladresse, Quellport, Zielport, Protokoll und Sicherheitszone.

A Hashkollision tritt auf, wenn die firewall Versuche, eine neue Sitzung zu erstellen, mit einem der beiden Flows, die dem 6-Tupel-Schlüssel einer vorhandenen Sitzung entsprechen. In diesem Fall firewall wird das eingehende Paket abgestellt und der globale Leistungsindikator session_hash_insert_duplicateerhöht.

In den nächsten beiden Diagrammen können Sie dieses Sitzungskollisionsverhalten mit zwei SIP Aufrufen sehen. Jedes Diagramm enthält ein lokales firewall Telefon, und ein Remotetelefon.Darüber hinaus haben wir die Netzwerkbeine des Client-Server-Flusses sowie die IP Adress- und UDP Portinformationen für jedes Paket aufgezählt.

70539-1.1. png
 
  1. Das lokale Telefon (192.168.1.2) initiiert einen SIP Anruf beim Remotetelefon (10.10.10.10) mit einem Quell- und UDP Zielport von 5060.
  2. Der ausgehende Datenverkehr entspricht einer Quelle NAT policy auf dem , die Quelle in firewall IP 10.10.10.1 und den Quellport in 56611 übersetzt. Der firewall erstellt dann eine Sitzung mit zwei unidirektionalen Flows.Hier sehen wir die Sitzungsdetails der ersten SIP Sitzung, die von der erstellt firewall wurde.
    > 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
  3. A die zweite Verbindung wird kurz darauf über das Remote-Telefon versucht. Diese Verbindung ist für die firewall IP Adresse von '10.10.10.1 bestimmt. Der firewall hat ein eingehendes Ziel für die Adresse NAT policy des internen Telefons von IP 192.168.1.2 konfiguriert.Dieser Aufruf wird nie etabliert, aber warum?

70539-2.1. png


Nach dem Ausführen einer gefilterten Paketerfassung sehen wir, dass die firewall Pakete vom SIP INVITE 10.10.10.10.
Die globalen Leistungsindikatoren weisen darauf hin, dass die Fehler während der Sitzungserstellung auftreten und durch eine Sitzungshashkollision verursacht werden.
> 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


Der firewall entspricht dem Anruf vom 10.10.10.10 mit einem eingehenden Ziel und übersetzt die NAT policy IP Zieladresse von 10.10.10.1 bis 192.168.1.2. Wenn der firewall Versuch, eine Sitzung zu erstellen, überprüft, ob der Sitzungshash mit einem vorhandenen c2s- oder s2c-Fluss übereinstimmt.

Wenn wir den c2s-Fluss der ersten Sitzung und den erwarteten s2c-Fluss der fehlgeschlagenen Sitzung vergleichen, haben wir Folgendes:
c2s Flow:
Quelle: 192.168.1.2 [l3-trust]
dst: 10.10.10.10
proto: 17
sport: 5060 dport: 5060
Zustand: ACTIVE Typ: FLOW
src Benutzer: unbekannter
Dst Benutzer: unbekannt
s2c Flow:
Quelle: 192.168.1.2 [l3-trust]
dst: 10.10.10.10
proto: 17
sport: 5060 dport: 5060
Zustand: ACTIVE Typ: FLOW
src Benutzer: unbekannter
Dst Benutzer: unbekannt

Beachten Sie, dass diese beiden Ströme identisch sind. Wenn der firewall die zweite Sitzung erstellt hätte, wäre es nicht möglich zu identifizieren, welcher Flow für ein übereinstimmendes Paket verwendet werden soll.Der firewall erstellt aufgrund dieses Konflikts keine zweite Sitzung.
 


Resolution


Dieses Verhalten kann sich je nach Umsetzung auf einzigartige Weise manifestieren. In diesem Szenario kann ein Benutzer seine Quelle von Dynamic und Port zu Static neu NAT IP konfigurieren. NAT Dadurch kann der zweite Aufruf mit dem anfänglichen s2c-Fluss übereinstimmen, anstatt eine neue Sitzung durch die zu firewall erstellen.

Wenn session_hash_insert_duplicate in den globalen Leistungsindikatoren sichtbar ist, denken Sie daran, wie NAT sich Richtlinien auf neue Sitzungen auswirken können, die mit vorhandenen Flows übereinstimmen.



Actions
  • Print
  • Copy Link

    https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA10g000000ClWrCAK&lang=de&refURL=http%3A%2F%2Fknowledgebase.paloaltonetworks.com%2FKCSArticleDetail

Choose Language