Tipps & Tricks: Warum eine VPN-Proxy-ID verwenden?

Denken Sie an unser Dilemma aus der letzten Woche, in dem wir überlappende Subnetze über einen IPSec VPN-Tunnel hatten? Wir suchten nach einem Weg, um Peer-Netzwerke kommunizieren zu lassen. Proxy-IDs zur Rettung. Wenn Sie eine Palo Alto Networks Firewall haben, die mit einem Peer-unterstützenden, politikbasierten VPN arbeitet, benötigen Sie Proxy-IDs.

 

Die Diskussion der Woche (DotW) in der vergangenen Woche ist Hilfe bei Proxy-IDs, aber lassen Sie uns mehr über VPN-Proxy-IDs sprechen und warum es wichtig ist, Sie zu verwenden.

 

Wenn wir über IPSec VPN-Tunnel sprechen, wenn Sie die Palo Alto Networks Firewall einrichten, um mit einem Peer zu arbeiten, der Policy-basiertes VPN unterstützt, müssen Sie Proxy-IDs definieren. Geräte, die Politik basiertes VPN unterstützen, verwenden spezifische Sicherheitsregeln/-Richtlinien oder Zugriffslisten (Quelladressen, Zieladressen und Ports), um interessanten Verkehr durch einen IPSec-Tunnel zu ermöglichen. Diese Regeln werden während der Quick-Mode/IKE-Phase-2-Verhandlung referenziert und in der ersten oder zweiten Botschaft des Prozesses als Proxy-IDs ausgetauscht.

 

Wenn Sie also die Palo Alto Networks Firewall so konfigurieren, dass Sie mit einem Policy-basierten VPN-Peer arbeitet, müssen Sie für eine erfolgreiche Phase-2-Verhandlung die Proxy-ID definieren, damit die Einstellung auf beiden Peers identisch ist. Wenn die Proxy-ID nicht konfiguriert ist, weil die Palo Alto Networks Firewall das Routen basierte VPN unterstützt, sind die Standardwerte, die als Proxy-ID verwendet werden, Quelle IP: 0.0.0.0/0, Destination IP: 0.0.0.0/0 und Anwendung: Any; und wenn diese Werte mit dem Gutachter ausgetauscht werden, ist das Ergebnis ein Versäumnis, die VPN-Verbindung einzurichten.

 

Werfen wir nun einen Blick auf das Proxy-ID-Fenster und die Optionen:

Innerhalb des Abschnitts Proxy-ID (innerhalb des WebGUI-Netzwerks > IPSec-Tunnel > wählen Sie einen Tunnel > Proxy-IDs-Tab), werden Sie viele Optionen sehen:

• Proxy ID — Klicken Sie auf Hinzufügen und geben Sie einen Namen, um den Proxy zu identifizieren. Kann jeder Name sein. Wenn nur Zahlen verwendet werden, wird es nicht akzeptiert.
• Lokale — geben eine IP-Adresse oder ein Subnetz im Format ip_address/Maske ein (zum Beispiel 10.1.2.1/24).
• Remote — , wenn es vom Peer benötigt wird, geben Sie eine IP-Adresse oder ein Subnetz im Format ip_address/mask ein (zum Beispiel 10.1.1.1/24).
• Protokoll -spezifizieren Sie die Protokoll-und Portnummern für die lokalen und entfernten Ports:
• Nummer — Geben Sie die Protokollnummer an (die für die Interoperabilität mit Drittanbietern verwendet wird).
• Alle — erlauben TCP und/oder UDP-Verkehr.
• TCP — die lokalen und entfernten TCP-portNummern angeben.
• UDP — geben die lokalen und entfernten UDP-Portnummern an.

Hinweis: jede Proxy-ID wird als VPN-Tunnel gezählt und zählt daher zur IPSec-VPN-Tunnel Kapazität der Firewall. (Beispiel: Site-toiSite IPSec VPN Tunnel Limit-PA-3020-1000, PA-2050-100, PA-200-25)

 

Der Vorteil bei den Proxy-IDs ist die Fähigkeit, granulär mit Protokoll Nummern oder TCP/UDP-Portnummern zu erhalten, wenn Sie einen bestimmten Traffic haben, den Sie nur über den VPN-Tunnel reisen möchten. Proxy-IDs ermöglichen eine solche Granularität leicht.

 

Da es 2 Versionen von IKE gibt, ist das Verhalten mit Proxy-IDs anders:
-mit ikev1 unterStützen Palo Alto Networks-Geräte nur Proxy-ID-exakte Übereinstimmung. Falls die Proxy-ID des Peers nicht übereinstimmen, wird es Probleme mit dem korrekten Funktionieren des VPN geben.
-Mit IKEv2 wird die Unterstützung des Verkehrs Wählern verengt, wenn sich die Proxy-ID-Einstellung auf den beiden VPN-Gateways unterscheidet, nur die implementierte Wahl wird in den unten aufgeführten Anwendungsfällen beschrieben.

 

Anwendungsfälle IKEv2

Bitte sehen Sie unten eine Liste von AnwendungsFällen mit IPSEC und IKEv2, die helfen können, viele IPSEC-VPN-Setups zu erklären, und wie Sie die Proxy-ID richtig verwenden.

 

Beispiel: Es gibt zwei VPN-Gateways: A und B. IKE-Verhandlung wird von VPN GW-A gestartet. i = Initiator, r = Responder

 

Angenommen VPN GW-ein definierter Verkehrs Wähler TSi-a/TSr-a; VPN GW-b hat Einstellung für Verkehrs Wähler TSi-b/TSr-b. TSr-a ist das gleiche wie TSr-b, so dass es ignoriert werden kann. TSi-a kann sich von TSi-b unterscheiden.

 

A. TSI-a ist das gleiche wie TSI-b, zum Beispiel sind beide 5.10.11.0/24.

Erwartet: dann gibt es keine Verengung erforderlich, das Verhalten ist das gleiche wie bestehende IKEv1 Proxy ID Case. Der Verkehr wäre nicht in der Lage, zu passieren, in diesem Beispiel, NAT wäre erforderlich, um eine angemessene Kommunikation zu ermöglichen.

 

VPN GW-a: Send: TSi: 5.10.11.0-5.10.11.255

VPN GW-b: Reply: TSi: 5.10.11.0-5.10.11.255 [Endergebnis]

 

Diese Lösung ist im DotW-Artikel hier detailliert beschrieben:

Hilfe bei Proxy ID es

B. TSI-a ist Superset von TSI-B:

B1. VPN GW-a schlägt TSi-a = 5.10.0.0/16; Auf VPN GW-b: TSi-b = 5.10.11.0/24.

 

i. Der Tunnel wird ohne Verkehr aufgezogen (zum Beispiel während der Initialisierung oder per Test Befehl).

 

Erwartet: als Responder antwortet VPN GW-b auf VPN GW-a mit 5.10.11.0/24. VPN GW-a sollte es akzeptieren und CHILD SA erstellen.

 

VPN GW-a: Send: TSi: 5.10.0.0-5.10.255.255

VPN GW-b: Reply: TSi: 5.10.11.0-5.10.11.255 [verengt auf den gemeinsamen unter Satz]

 

II. EIN Host hinter VPN GW-a (zum Beispiel Host IP 5.10.11.2) versucht, den Tunnel zu bringen.

 

Erwartet: als Responder antwortet VPN GW-b auf VPN GW-a mit 5.10.11.0/24. VPN GW-a sollte es akzeptieren und CHILD SA erstellen. Der Verkehr soll passieren.

 

VPN GW-a: senden: TSi: 5.10.11.2; 5.10.0.0-5.10.255.255

VPN GW-b: Reply: TSi: 5.10.11.0-5.10.11.255 [verengt auf den gemeinsamen unter Satz]

 

Wenn wir der Initiator sind, verschicken wir nicht die erste spezifische Verkehrs Auswahl (5.10.11.2) in IKE-Nutzlast.

Als Responder sollten wir in der Lage sein, mit dem Gutachter umzugehen, der die jeweilige Verkehrs Auswahl schickt. Wir werden auch die Verkehrs Wähler auf die gemeinsame Untermenge beschränken.

 

III. EIN Host hinter VPN GW-a (zum Beispiel Host IP 5.10.6.2) versucht, den Tunnel zu bringen.

Erwartet: als Responder antwortet VPN GW-b auf VPN GW-a mit 5.10.11.0/24. VPN GW-a sollte es akzeptieren und CHILD SA erstellen.

 

VPN GW-a: Send: TSi: 5.10.6.2; 5.10.0.0-5.10.255.255

VPN GW-b: Reply: TSi: 5.10.11.0-5.10.11.255 [verengt auf den gemeinsamen unter Satz]

 

Wenn wir der Initiator sind, verschicken wir nicht die erste spezifische Verkehrs Auswahl (5.10.6.2) in IKE-Nutzlast.

 

Als Responder werden wir die Verkehrs Wähler auf die gemeinsame Untermenge beschränken. Wenn die erhaltene TS-Nutzlast die spezifische Traffic-Selektor enthält, obwohl Sie aus der lokalen Politik heraus ist, tun wir immer noch die Verengung, aber ignoriert die spezifische Traffic-Selektor per RFC 5996.

 

B2. VPN GW-a schlägt TSi-a = 5.10.0.0/16; Auf VPN GW-b: Es sind mehr als ein Einträge definiert: TSi-b = 5.10.11.0/24 + 5.10.12.0/24.

 

i. Tunnel wird ohne Verkehr aufgezogen.

 

Mehrere Einträge pro Traffic-Selektor werden von strongswan unterstützt. So kann strongswan verwendet werden, um als VPN GW-b einzurichten. Wenn PANOS GW-b ist, müssen wir mehrere Proxy-IDs konfigurieren.

 

VPN GW-a: Send: TSi: 5.10.0.0-5.10.255.255

VPN GW-b: Reply: TSi: 5.10.11.0-5.10.11.255 [PANOS: der gemeinsame unter Satz aus dem ersten passenden Eintrag]

 

Das obige zeigt das Ergebnis für PANOS als Responder (VPN GW-b). Es antwortet auf VPN GW-a mit einem der Einträge: 5.10.11.0/24 oder 5.10.12.0/24 (der erste Eintrag auf der Grundlage der Bestellung in "Show VPN Tunnel", alphabetische Reihenfolge der vollen Tunnel Namen).

 

Einige Anbieter (als VPN GW-b) können eine TS mit beiden Einträgen (5.10.11.0-5.10.11.255 + 5.10.12.0-5.10.12.255) zurückgeben, aber wir installieren nur den ersten Eintrag.

 

II. EIN Host hinter VPN GW-a (z.b. Host IP 5.10.11.2) versucht, den Tunnel zu bringen.

Erwartet: als Responder antwortet VPN GW-b auf VPN GW-a mit 5.10.11.0/24. Der Verkehr soll passieren.

 

VPN GW-a: Send: TSi: 5.10.11.2; 5.10.0.0-5.10.255.255

VPN GW-b: Reply: TSi: 5.10.11.0-5.10.11.255 [PAN-OS: der gemeinsame unter Satz aus dem ersten passenden Eintrag, bevorzugt die Richtlinien, die 5.10.11.2 abdecken können]

 

Wenn wir der Initiator sind, verschicken wir nicht die erste spezifische Verkehrs Auswahl (5.10.11.2) in IKE-Nutzlast.

 

Wenn wir der Responder sind, suchen wir die gesamte konfigurierte Proxy-ID, bis ein Eintrag den jeweiligen Traffic-Selektor abdecken kann und verengt oder exakt aufeinander abgestimmt werden kann. Wenn der jeweilige Verkehrs Wähler nicht durch den gemeinsamen unter Satz abgedeckt werden kann, versuchen wir immer noch, die Verengung zu machen.

 

III. Nach Schritt II versucht ein weiterer Host hinter VPN GW-a (z.b. Host IP 5.10.12.2), das andere Ende des VPN zu erreichen.

Erwartet: da der Verkehr nicht mit dem zuvor geschaffenen VPN-Tunnel übereinstimmt, wird eine weitere IPSec SA verhandelt.

 

VPN GW-a: Send: TSi: 5.10.12.2; 5.10.0.0-5.10.255.255

VPN GW-b: Reply: TSi: 5.10.12.0-5.10.12.255 [PANOS: der gemeinsame unter Satz aus dem ersten passenden Eintrag, bevorzugt die Richtlinien, die 5.10.12.2 abdecken können]

 

Zu diesem Zeitpunkt sind VPN-Tunnel für beide Proxy-ID auf-und vorbei Verkehr.

 

Einige Anbieter dürfen keine weitere IKE-Verhandlung starten. Sie senden Pakete mit vorhandenem Tunnel, der in Schritt II errichtet wurde, obwohl es nicht mit 5.10.12.2 übereinstimmt. Wir müssen den gesamten Tunnel Verhandlungsprozess überprüfen, um diese Art von Verhalten zu analysieren.

 

IV. EIN Host hinter VPN GW-a (zum Beispiel Host IP 5.10.6.2) versucht, das andere Ende des VPN zu erreichen (ohne Schritt II und III).

 

Erwartet: weil es auf VPN GW-a keine passende SA gibt, versucht Sie, mit VPN GW-b zu verhandeln. Die Reaktion kann die Umsetzung abhängig sein.

 

VPN GW-a: Send: TSi: 5.10.6.2; 5.10.0.0-5.10.255.255

VPN GW-b: Reply: TSi: 5.10.12.0-5.10.12.255 [PANOS: der gemeinsame unter Satz aus dem ersten passenden Eintrag]

 

V. Nach Schritt III versucht ein Host hinter VPN GW-a (zum Beispiel Host IP 5.10.6.2), das andere Ende des VPN zu erreichen.

 

Der Initiator könnte einen zuvor etablierten Tunnel nutzen, um den Verkehr an den Gutachter weiter zu leiten. Die Wahl, welcher Tunnel Verkäufer abhängig sein kann.

 

B3. Für VPN GW-b, die keine Verkehrs Selektor-Verengung unterstützt

 

Ein VPN-Gerät unterstützt nicht die Verengung der Verkehrs Wähler, z. Cisco IOS 15,0 antwortet NO_PROPOSAL_CHOSEN in diesem Fall.

 

Tunnel kann nicht eingerichtet werden und die Konfiguration muss geändert werden.

 

C. TSi-a ist Untergruppe von TSr-b:

VPN GW-a schlägt TSi-a = 5.10.11.0/24; Auf VPN GW-b: TSr-b = 5.10.0.0/16.

 

i. Tunnel wird ohne Verkehr aufgezogen.

 

Erwartet: VPN GW-b antwortet 5.10.11.0/24. Der Tunnel wird mit dem gemeinsamen Teil der Verkehrs Selektoren (5.10.11.0/24) errichtet.

VPN GW-a: Send: TSi: 5.10.11.0-5.10.11.255

VPN GW-b: Reply: TSi: 5.10.11.0-5.10.11.255 [Endergebnis-der gemeinsame unter Satz]

 

II. EIN Host hinter VPN GW-a (z.b. Host IP 5.10.11.2) versucht, den Tunnel zu bringen.

 

Erwartet: ein Tunnel mit Verkehrs Wähler 5.10.11.0/24 wird eingerichtet. Der Verkehr soll passieren können.

VPN GW-a: Send: TSi: 5.10.11.2; 5.10.11.0-5.10.11.255

VPN GW-b: Reply: TSi: 5.10.11.0-5.10.11.255 [Endergebnis]

 

Wenn wir der Initiator sind, verschicken wir nicht die erste spezifische Verkehrs Auswahl (5.10.11.2) in IKE-Nutzlast.

 

Als Responder sollten wir in der Lage sein, mit dem Gutachter umzugehen, der die jeweilige Verkehrs Auswahl schickt. Wir holen die Verkehrs Auswahl vom Initiator ab, da Sie kleiner ist.

 

III. EIN Host hinter VPN GW-a (zum Beispiel Host IP 5.10.6.2) versucht, den Tunnel zu bringen

 

Erwartet:

VPN GW-a: Send: TSi: 5.10.6.2; 5.10.11.0-5.10.11.255

VPN GW-b: Reply: TSi: 5.10.11.0-5.10.11.255 [Endergebnis]

 

Wenn PAN-OS der Initiator ist, wenn auf der gleichen Tunnel Schnittstelle keine Proxy-ID oder eine einzelne Proxy-ID definiert ist, wird der Tunnel wie oben verhandelt und der Verkehr wird durch den Tunnel geschickt.

 

Im Falle einer mehrfachen Proxy-ID werden wir weiterhin andere Proxy-ID (Tunnel-ID) prüfen, um zu sehen, ob es ein Match gibt. Wenn es kein Match gibt, wird die letzte Proxy-ID verwendet, um den Tunnel auszuhandeln und den Verkehr zu verschicken. Dies ist das Verhalten, das in IPsec Multiple Phase 2 Assoziationen definiert wird.

 

Wenn PAN-OS der Responder ist und ein anderer Anbieter, der Policy VPN betreibt, der Initiator ist, kann es nicht mit Tunnel Verhandlungen beginnen, da das Paket aus dem Bereich seiner lokalen Politik heraus ist. Wenn es mit der Tunnel Verhandlung beginnt, werden wir den Verkehrs Wähler des Initiators verwenden, da er schmaler ist.

 

D. es gibt Überschneidungen zwischen TSi-a und TSr-b.

VPN GW-a schlägt TSi-a = 5.10.0.0/16; Auf VPN GW-b: TSr-b = 5.10.11.0/24 + 5.9.0.0/24.

i. Tunnel wird ohne Verkehr aufgezogen.

 

Erwartet: VPN GW-b antwortet 5.10.11.0/24. Der Tunnel wird mit dem gemeinsamen Teil der Verkehrs Selektoren (5.10.11.0/24) errichtet.

VPN GW-a: Send: TSi: 5.10.0.0-5.10.255.255

VPN GW-b: Reply: TSi: 5.10.11.0-5.10.11.255 [Endergebnis-der überlappte Untersatz]

 

II. EIN Host hinter VPN GW-a (z.b. Host IP 5.10.11.2) versucht, den Tunnel zu bringen.

 

Erwartet: ein Tunnel mit Verkehrs Wähler 5.10.11.0/24 wird eingerichtet. Der Verkehr soll passieren können.

VPN GW-a: Send: TSi: 5.10.11.2, 5.10.0.0-5.10.255.255 

VPN GW-b: Antwort: TSi: 5.10.11.0-5.10.11.255 [Common Unterset]

 

Wenn wir der Initiator sind, verschicken wir nicht die erste spezifische Verkehrs Auswahl (5.10.11.2) in IKE-Nutzlast.

 

Als Responder sollten wir in der Lage sein, mit dem Gutachter umzugehen, der die jeweilige Verkehrs Auswahl schickt. Wir werden auch die Verkehrs Wähler auf die gemeinsame Untermenge beschränken.

 

III. EIN Host hinter VPN GW-a (z.b. Host IP 5.10.12.2-innerhalb der Richtlinie für VPN GW-a, aber außerhalb der Richtlinie für VPN GW-b) versucht, den Tunnel zu bringen.

 

Erwartet:

VPN GW-a: Send: TSi: 5.10.12.2, 5.10.0.0-5.10.255.255
VPN GW-b: Antwort: TSI: 5.10.11.0-5.10.11.255 [Common Unterset]

 

Wenn PANOS der Initiator ist: der Responder kann keinen Bereich finden, der für 5.10.12.2 nützlich ist, so dass er den gemeinsamen Bereich zurückgibt (5.10.11.0/24). Tunnel aufgestellt werden kann. Wir verschicken nicht die jeweilige Verkehrs Auswahl.

 

Basierend auf unserem bestehenden Verhalten, das in IPsec Multiple Phase 2 Assoziationen definiert ist, wird das Paket durch diesen Tunnel gesendet, könnte aber von der Responder fallen gelassen werden. Der Sende-VPN-Tunnel darf es nicht bemerken.

 

IV. EIN Host hinter VPN GW-a (z.b. Host IP 5.9.0.2-innerhalb der Richtlinie für VPN GW-b, aber außerhalb der Richtlinie für VPN GW-a) versucht, den Tunnel zu bringen.

 

Erwartet:
VPN GW-a: Send: TSI: 5.9.0.2, 5.10.0.0-5.10.255.255
VPN GW-b: Antwort: TSI: 5.10.11.0-5.10.11.255 [Common Unterset]

 

Wenn der Initiator PAN-OS ist, wird die Proxy-ID 0.0.0.0/0 (wenn keine Proxy-ID definiert ist) oder die letzte Proxy-ID (falls mehrere Proxy-ID auf der Tunnel Schnittstelle definiert sind) in TSi verwendet.

 

Der Verkehr könnte durch den Responder (Policy-based VPN) fallen gelassen werden, da er die verengten TS verletzt.
Wenn der Initiator eine strikte VPN-Politik prüft (nicht PAN-OS), kann die IKE-Verhandlung nicht ausgelöst werden, da Sie gegen die VPN-Richtlinien verstößt.

 

Damit sind die Tipps & Tricks beendet. Ich hoffe, Sie haben etwas aus diesem Artikel gelernt.

 

Wie immer freuen wir uns über alle Rückmeldungen und Anregungen.

 

Sicher bleiben!

Joe Delio