surmka
Goto Top

Lancom zu Palo Alto VPN IKE Phase-2 Probleme

Hallo face-smile

Ich habe derzeit einige Probleme bei der Einrichtung eines Site-to-Site-VPN zwischen einem Lancom 1783va-4g und einem Palo Alto PA-220, um die zwei lokalen Netzwerke zu verbinden (192.168.100.0/24 an dem Lancom und 192.168.4.0/24 an der PA). Die PA befindet sich hinter einer anderen Firewall (192.168.0.0/24), die die öffentliche IP-Adresse hat und die Ports 500 und 4500 an die PA weiterleitet, das NAT und Routing sind kein Problem. Beide Seiten haben eine statische IP-Adresse. Ich bin neu in Palo Alto, es tut mir so leid, wenn ich etwas vergesse.

Die ausgehende Verbindung der PA zur anderen Firewall erfolgt über Ethernet 1/1 (192.168.0.1) und mein lokales Netz, das ich mit dem VPN verbinden möchte, ist über Ethernet 1/3 (192.168.4.254). Ich habe das IKE-Gateway für 1/1 eingerichtet, IKE-Krypto und IPSec-Krypto konfiguriert, den IPsec-Tunnel mit einem Proxy konfiguriert (da Lancom policy-based VPN ist) und einen Tunnel für die vpn-security-zone konfiguriert.

Der Lancom verbindet sich mit der PA und IKE phase-1 funktioniert gut, soweit ich das an den Logs erkennen kann.

IKE phase-1 negotiation is started as responder, aggressive mode. Initiated SA: 192.168.0.1[4500]-x.x.x.x[4500] cookie: ******************************.
IKE phase-1 negotiation is succeeded as responder, aggressive mode. Established SA: 192.168.0.1[4500]-x.x.x.x[4500] cookie: ****************************** lifetime 2800 Sec.
IKE phase-2 negotiation is started as responder, quick mode. Initiated SA: 192.168.0.1[4500]-x.x.x.x[4500] message id: *********.
IKE phase-2 negotiation failed when processing SA payload. no suitable proposal found in peer's SA payload.  
IKE protocol notification message sent: NO-PROPOSAL-CHOSEN (14).

Die Lancom bietet keine große Hilfe:

VPN: Error for peer PPA-220: IPSEC-I-No-proposal-matched
Disconnected from peer PA-220: VPN-no-channel

Das Problem scheint mit meiner PA-Konfiguration zu sein, vielleicht hat jemand eine Idee, wie man das beheben kann. Es ist vermutlich etwas, das irgendwie offensichtlich ist, aber mein Kopf ist irgendwie Matsche momentan.


die PA-Konfiguration:
screenshot from 2019-06-13 11-09-16
screenshot from 2019-06-13 11-12-12
screenshot from 2019-06-13 11-12-22
screenshot from 2019-06-13 11-12-26
screenshot from 2019-06-13 11-12-49
screenshot from 2019-06-13 11-12-54
screenshot from 2019-06-13 11-13-02
screenshot from 2019-06-13 11-13-27


LG und schonmal vielen Dank face-smile

Content-ID: 461760

Url: https://administrator.de/contentid/461760

Ausgedruckt am: 26.11.2024 um 01:11 Uhr

127132
Lösung 127132 13.06.2019 um 13:18:10 Uhr
Goto Top
Mahlzeit!

Passen denn die IKE-Proposals des LANCOM zu denen vom PA.
Das Log sagt da nein, was ich rauslese.
SHA128 statt SHA256? Zahlendreher?

h.
aqui
Lösung aqui 13.06.2019 aktualisiert um 13:33:51 Uhr
Goto Top
Bitte lasse den Unsinn mit überflüssigen externen Links oder Bilderlinks hier im Forum !!! face-sad
Das kann man alles auch lokal einbinden in den Thread !! (Und auch noch nachträglich !)
Außerdem ist einfach cut and pasten von HIER ja nun wahrlich recht plump. face-sad
Zurück zum Thema...

die die öffentliche IP-Adresse hat und die Ports 500 und 4500 an die PA weiterleitet
Das nützt nichts und ist nur die Hälfte der Miete. Die Produktivdaten werden in einem ESP Tunnel (IP Protokoll Nummer 50) geforwartet. Wenn du kein ESP auf dem davor kaskadierten Router/Firewall forwardest wirst du niemals einen IPsec VPN Tunnel zum Fliegen bekommen und scheiterst logischerweise.
Für die Details siehe hier:
IPsec IKEv2 VPN für mobile Benutzer auf der pfSense oder OPNsense Firewall einrichten
Du brauchst also immer drei Protokollkomponenten: UDP 500, 4500 und das ESP Protokoll !!

Den entscheidenden Tip gibt dir aber das Lancom Log !!! "IPSEC-I-No-proposal-matched"
Das bedeutet die PA ist Initiator und bietet dem Lancom eine Auswahl an Phase 2 Verschlüsselungs Verfahren an. Keines davon passt allerdings zu denen für die der Lancom konfiguriert ist.
Die PA meckert das übrigens ebenso an: "no suitable proposal found in peer's SA payload.".
Man muss also einfach nur mal in die Logs sehen !
Folglich kommen die also logischerweise niemals zueinander, da der eine Englisch sprechen will und der andere aber nur Französisch versteht um es mal salopp zu sagen !! Kollege @127132 hat es schon angesprochen oben.

Checke also was die PA in der Phase 2 anbietet. In der Regel ist das heute AES 256, AES 512 in Verbindung mit einem SHA256 (bevorzugt) oder SHA1 Hash.
Auch die DG Group muss überein stimmen ! Normal ist 14 (2048 Bit) möglicherweise arbeitet der Lancom noch mit 1024 Bit.
Sehr gut möglich das die PA, da professioneller, SHA256 macht und der Lancom auf dem üblichen SHA1 oder schlimmer MD5 konfiguriert ist. Möglicherweise sogar noch 3DES usw. Dann hast du den Mismatch.
Beide Seiten müssen natürlich mindestens ein übereinstimmendes Verfahren konfiguriert haben ! (Damit sie beide Englisch sprechen)
Beachte auch das du bei Hersteller fremden Komponenten immer besser den Aggressive Mode statt des Main Mode verwenden solltest !!
127132
127132 13.06.2019 um 13:53:10 Uhr
Goto Top
Über die Wizards läuft glaube ich wirklich MD5 und 1024 Bit bei den LANCOMs.
Surmka
Surmka 13.06.2019 um 13:53:26 Uhr
Goto Top
Bitte lasse den Unsinn mit überflüssigen externen Links oder Bilderlinks hier im Forum !!! face-sad
Das kann man alles auch lokal einbinden in den Thread !! (Und auch noch nachträglich !)
Danke für den Hinweis, habe ich korrigiert.
Außerdem ist einfach cut and pasten von HIER ja nun wahrlich recht plump. face-sad
an mehreren Stellen zu fragen und mehr Leute zu erreichen schien mir eine gute Idee. Schlecht umgesetzt an der Stelle, sorry.

So, zurück zum Thema:
Die ganzen Verschlüsselungsverfahren waren eigentlich auf einander abgestimmt weswegen ich auch erstmal nicht weiter wusste.
Vertrauen ist gut, Kontrolle ist besser, aber es hat soweit von AES256, SHA256 und DH Group 14 alles gestimmt.
Den Fehler hab ich dann in dem Palo Alto IPSec Crypto Profile gefunden: das IPSec Protocol war als AH eingestellt während Lancom nur ESP nimmt. Umgestellt und phase-2 funktioniert jetzt auch.

Eine Verbindung zwischen den beiden Netzen hab ich jetzt zwar immer noch nicht, aber da setze ich mich jetzt dran.
goscho
goscho 13.06.2019 um 14:05:45 Uhr
Goto Top
Mahlzeit
Zitat von @Surmka:
Die Lancom bietet keine große Hilfe:

Das glaube ich dir nicht.
Du kannst einen Trace über den Lanmonitor zu deinem 1783va-4g laufen lassen.
  • Lanmonitor -> Gerät auswählen -> Rechtsklick -> Traceausgabe erstellen
  • Diesen Trace kannst du noch schön auf VPN einschränken
lancom-trace-einstellungen-vpn


Jetzt wirst du bestimmt sehr genau gesagt bekommen, was nicht stimmt.
Dabei ist es ja wohl schon ziemlich ersichtlich:

Gehe zu:

IKE/IPSec -> Verbindungs-Parameter und wähle dort deine Verbindung zum PA aus.
Hier musst du jetzt die IPSEC-Proposals so anpassen, dass diese mit denen der Gegenstelle übereinstimmen.
Auf deinem PA sollten die unter "IPSEC-Crypto" stehen.
aqui
aqui 13.06.2019, aktualisiert am 28.06.2019 um 11:43:52 Uhr
Goto Top
war als AH eingestellt während Lancom nur ESP nimmt.
Was heisst "nur" ?? AH kann man im Internet technisch gar nicht über NAT übertragen, deshalb verwendet niemand AH bei IPsec VPNs. Denn die Absender-Adresse stimmt dann mit der Adresse im Original-Header nicht mehr überein. Der NAT-Router "manipuliert" durch NAT die IP-Adressen. Dadurch wird ein solches AH Datenpaket beim Empfänger immer als ungültig verworfen.
Das würde also nur in einem völlig NAT freien Umfeld klappen was es bei IPv4 mehr oder minder ja nirgendwo mehr gibt.
Sollte man als Netzwerker eigentlich wissen !
Eine Verbindung zwischen den beiden Netzen hab ich jetzt zwar immer noch nicht
Kann dann ja nur noch an falschen oder fehlenden Firewall Regeln auf den Tunnel Interfaces liegen ?!

Aber OK...Thread ist ja als "Gelöst" markiert also rennt jetzt scheinbar alles ?!