Bearbeitung von IPSec-Durchlauf Verkehr auf der Palo Alto Networks Firewall

Bearbeitung von IPSec-Durchlauf Verkehr auf der Palo Alto Networks Firewall

61861
Created On 09/26/18 13:48 PM - Last Modified 11/19/19 04:34 AM


Resolution


 Wie in dem Dokument https://Live.paloaltonetworks.com/docs/doc-5819 erläutert, werden die Portnummern für die Erstellung der IPSec-Session von SPI-Werten abgeleitet, die entfernte IPSec-Peers während der IKE-Phase 2 der Tunnel Einrichtung austauschen. Aber diese Methode kann nur angewendet werden, wenn einer von IPSec-Peers die Firewall selbst ist, oder anders ausgedrückt, nur wenn der IPSec-Tunnel auf der Firewall beendet wird.

 

Im Falle des Durchgangs von IPSec Traffic, wo die Palo Alto Networks Firewall nur ein zwischen Gerät zwischen zwei IPSec-Peers ist, ist es praktisch unmöglich, eine Session zu erstellen, die auf ausgehandelten SPI-Werten basiert, da IKE Phase 2 verschlüsselt ist und ihr Inhalt für die Firewall nicht sichtbar.

 

Da SPI-Werte nicht im Voraus eingesehen werden können, erstellt die Palo Alto Networks Firewall für den IPSec-Durchlauf Verkehr eine Session, indem Sie den Generic Value 20033 sowohl für den Quell-als auch den Zielport verwendet. Im folgenden Beispiel können Sie sehen, dass Quell-und Zielports von C2S und S2C strömen den gleichen Wert erhalten, 20033:

 

admin @ VM-300 > Show Session ID 791

Session 791

C2S Flow:
Quelle: 192.168.0.11 [Trust]
DST: 129.187.7.11
Proto: 50
Sport: 20033 dport: 20033
Zustand: aktiver Typ: Flow
src User: Unbekannter
DST use r: unbekannt

S2C Flow:
Quelle: 129.187.7.11 [Untrust]
DST: 192.168.0.11
Proto: 50
Sport: 20033 dport: 20033
Zustand: aktiver Typ: Flow
src Nutzer: Unbekannter
DST-Nutzer: Unbekannte

Startzeit: Do Juni 10 11:58: 59 2015 Timeout: 3600 sec Zeit zum Leben: 3142 sec Gesamt-Byte-Zählung (C2S): 1080 Gesamt-Byte-Zählung (S2C): 1014 layer7 Paket Zahl (C2S): 8 layer7 Paket Zählung (S2C): 5 Vsys: vsys1 Anwendung: IPSec-ESP -Regel: Session, die am Ende protokolliert werden soll: true Session in Session Ager: true Session aktualisiert von ha Peer: false layer7 processing: fertige URL-Filterung aktiviert: wahre URL-Kategorie: jede Sitzung über SYN-Cookies: falsche Sitzung beendet auf Host: falsche Session-Traversen-Tunnel: falsche Captive-Portal-Session: false Eindringen-Interface: Ethernet1/2 Egress-Schnittstelle: Ethernet1/1 Session QoS rule: N/A (Klasse 4) Tracker Stage l7proc: CTD APP hat keinen Decoder < C46 > Ende-Grund: unbekannt

 

Auf der PA-7000 und PA-5200-Serie verwenden wir aufgrund eines architektonischen Unterschieds eine andere Technik für die Session-Erstellung des IPSec-Durchlauf Verkehrs. Auf diesen Plattformen werden die Session-Ports wieder auf der Grundlage von SPI-Werten abgeleitet, wie in https://Live.paloaltonetworks.com/T5/Learning-articles/What-do-the-Port-Numbers-in-an-IPsec-ESP-Sess beschrieben... , aber da SPI-Werte im Voraus nicht bekannt sind, erstellt Firewall Session, da echter ESP-Traffic auf der Firewall ankommt. Jede Strömung (client2server, server2client) eines einzigen IPSec-Tunnels mit einem einzigartigen SPI-Wert impliziert, dass Firewall zwei unabhängige IPsec-Sitzungen für einen IPSec-Tunnel erstellt, eine pro Richtung. Das bedeutet, dass die Sicherheitsrichtlinien so konfiguriert werden müssen, dass der durch Pass-durch-ESP-Verkehr in beide Richtungen auf den Plattformen PA-7000 und PA-5200-



Actions
  • Print
  • Copy Link

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

Choose Language