fenris14

Palo Alto unknown IKEv2 Peer

Hallo,

hat jemand mal ein IPsec VPN zwischen einer Palo Alto (PA-220) und einer OPNsense (24.7.12) zum laufen bekommen?

Ich habe hier leider die unrühmliche Aufgabe eine veraltete PA anzubinden und ich bekomme es ums verrecken nicht hin. Ich habe Zugriff auf diese. Nicht nur das Design und Funktion direkt aus der Hölle zu kommen scheinen, ist bei meiner zwei Tage andauernden Recherche einige Abgründe zu Tage gekommen. PA hatte da wohl in der Vergangenheit öfters Probleme mit verschiedenen Herstellern. Ist mir bisschen schleierhaft was da als "Enterprise" verkauft wurde. Der Commit der Einstellungen dauert geschlagene 10 Minuten. Ist das normal?

Ich habe verschiedene Einstellungen probiert und mittlerweile wieder auf die ursprüngliche Config zurück und dort jetzt mehrmals penibelst auf gleiche Config geachtet, doch leider klappt nach Ablauf von der Lifetime der Phase 2 das Rekeying nicht. Der VTI-Tunnel ist ansonsten funktionell und macht was er soll. Wenn ich ihn manuell wieder anstarte geht alles wieder.

In der PA steht unter Monitor folgendes:

clipboard - june 26, 2025 11_15 pm

Das habe ich überprüft. Unter Network>Network Profiles>IKE Gateways wurde die OPNsense explizit mit "IKEv2 only mode" angelegt. Leider geht aus der Meldung nicht wirklich hervor welche Peer Adresse er meinen könnte.

In der OPNsense habe ich folgende Einstellungen gewählt "VPN>IPSEC>Connections":

Phase1

Proposals: default
Version: IKEv2
MOBIKE: Check
Rekey time: 14400
Over Time: 1440
DPD delay: 6s
PSK

Phase2

sha256_96: Check
Mode: Tunnel
Policies: Uncheck
Start Action: Start
Close Action: Start
DPD Action: Start
Reqid: 10
ESP Proposals: default
Rekey time: 7200

Ansonsten ist der Rest default. Manche Sachen wie Rekey time oder DPD delay hatte ich bereits auf default, macht keinen Unterschied.

In der Log von der OPNsense fallen paar Einträge auf:

2025-06-26T22:42:08	Informational	charon	09[KNL] creating acquire job for policy IP-PA == IP-OPN with reqid {10}	
2025-06-26T22:42:04	Informational	charon	05[CFG] trap not found, unable to acquire reqid 10

Wenn ich verschiedene Beiträge aus Foren richtig interpretiert habe, ist das beim VTI-Tunnel normal und die Meldung kommt immer.

2025-06-26T22:41:11	Informational	charon	14[MGR] IKE_SA checkout not successful	
2025-06-26T22:41:11	Informational	charon	14[MGR] checkout IKEv2 SA by message with SPIs 380483_i 9cd1726c_r	
2025-06-26T22:41:11	Informational	charon	03[NET] waiting for data on sockets

Das kommt, wenn das Rekeying fehlgeschlagen ist. Auf der PA sieht man allerdings keine konkreten Einträge zu diesem Ereignis. Meine Vermutung ist das die PA gar nicht selbst versucht, eine Neuverbindung aufzubauen obwohl sie nicht im Passive Mode ist. Einstellungen in der PA:

screenshot 2025-06-27 080938

screenshot 2025-06-27 081044

screenshot 2025-06-27 081151

screenshot 2025-06-27 081240

Ich habe mit der OPNsense bereits zu anderen Gegenstellen erfolgreich IPsec VPNs aufgebaut. Viel Cisco, vielleicht auch mal eine neuere PA, immer über andere Dienstleister. Da hatte ich solche Probleme nicht und es ging meistens prompt.

Jemand eine Idee woran das liegen kann?

Gruß
Auf Facebook teilen
Auf X (Twitter) teilen
Auf Reddit teilen
Auf Linkedin teilen

Content-ID: 673576

Url: https://administrator.de/forum/palo-alto-ipsec-vpn-opnsense-673576.html

Ausgedruckt am: 18.07.2025 um 00:07 Uhr

Fenris14
Lösung Fenris14 27.06.2025 um 12:31:14 Uhr
Ich habe jetzt über das alte Legacy Menü für IPsec in der OPNsense eine neue parallele Verbindung aufgebaut und dort bin ich explizit auf IKEv1 gegangen. Ebenfalls dann auf der PA jeweils neue Profile angelegt. Damit läuft es.

Warum die PA das nicht hinbekommt, weiß ich nicht. Da es sich um ein HA-Cluster aus zwei PA-220 handelt und auf beiden scheinbar die Lizenzen abgelaufen sind, ist meine Vemutung das die einen Split-Brain haben. Anders kann ich mir das Verhalten und die Probleme nicht erklären. Generell frage ich mich wie PA es geschafft hat so einen produzierten Müll für viel Geld an den Mann zu bringen.
aqui
aqui 27.06.2025 um 12:51:45 Uhr
Dazu muss man aber auch sagen das das "neue" OPNsense Menü scheinbar problematische Tunnelverbindungen generiert und nicht sauber arbeitet. Ich hatte bis jetzt 3 IPsec Tunnel auf externe Geräte die mit dem neuen Setup nicht zustande kamen. Nutze man das Legacy Setup klappte es sofort bei absolut gleichen Settings.
Etwas verwirrend ist das du jetzt von IKEv1 redest obwohl die PA Konfig IKEv2 explizit vorgibt was eigentlich nicht klappen kann. Komisch auch das NAT Traversal dort nicht aktiv ist, denn das ist bei fast allen Endgeräten grundsätzlich aktiv egal ob NAT Traversal erkannt wird im Pfad oder nicht.
Fenris14
Fenris14 27.06.2025 um 13:05:24 Uhr
Zitat von @aqui:

Dazu muss man aber auch sagen das das "neue" OPNsense Menü scheinbar problematische Tunnelverbindungen generiert und nicht sauber arbeitet. Ich hatte bis jetzt 3 IPsec Tunnel auf externe Geräte die mit dem neuen Setup nicht zustande kamen. Nutze man das Legacy Setup klappte es sofort bei absolut gleichen Settings.
Etwas verwirrend ist das du jetzt von IKEv1 redest obwohl die PA Konfig IKEv2 explizit vorgibt was eigentlich nicht klappen kann. Komisch auch das NAT Traversal dort nicht aktiv ist, denn das ist bei fast allen Endgeräten grundsätzlich aktiv egal ob NAT Traversal erkannt wird im Pfad oder nicht.

Ich sage es mal so: Bin kein PA-Profi und will es glaube auch nicht mehr werden. Ladezeiten und Bedienung ist absoluter Schrott.

Die Config habe ich mir zusammengesucht aus bestehenden Tunnel-Settings die bereits installiert waren und teilweise aus der Doku. IKEv1 habe ich dann verwendet, als es mit IKEv2 nicht klappte.

Das neue Menü in der OPNsense ist tatsächlich etwas komisch. Es unterschlägt einige Optionen. Weshalb ich dann zu Legacy explizit bei diesem Tunnel gewechselt bin. Vielleicht hätte ich es nochmal mit IKEv2 probieren können, vielleicht hätte es dann funktioniert.
aqui
aqui 27.06.2025 aktualisiert um 13:44:49 Uhr
Ein Versuch wäre es in jedem Falle wert gewesen. Der Fehler oben mit dem "neuen" GUI war immer replizierbar so das es de facto ein Bug im neuen GUI ist. face-sad
Einer der nicht funktionierenden Tunnel war sogar ein Strongswan Gegenpart wo, wie fast überall auch, der charon IPsec Daemon werkelt. Selbiger wird sehr wahrscheinlich auch in der PA seine Dienste tun. Im Moment traue ich dem "neuen" Setup in der OPNsense nicht über den Weg und bleibe, solange möglich, erstmal weiter beim Legacy.
Fenris14
Fenris14 27.06.2025 um 17:09:49 Uhr
Zitat von @aqui:

Ein Versuch wäre es in jedem Falle wert gewesen. Der Fehler oben mit dem "neuen" GUI war immer replizierbar so das es de facto ein Bug im neuen GUI ist. face-sad
Einer der nicht funktionierenden Tunnel war sogar ein Strongswan Gegenpart wo, wie fast überall auch, der charon IPsec Daemon werkelt. Selbiger wird sehr wahrscheinlich auch in der PA seine Dienste tun. Im Moment traue ich dem "neuen" Setup in der OPNsense nicht über den Weg und bleibe, solange möglich, erstmal weiter beim Legacy.

Irgendwas wird da auch vermurkst seitens OPNsense. Wenn ich in der swanctl nachsehe und jeweils eine Instanz über "Neu" mit Legacy verlgeiche, gibt es da erhebliche Unterschiede. Während bspw. bei "Neu" kein Route-Based mehr möglich ist und selbst beim Traffic Selector 0.0.0.0/0 eingetragen wird, erscheint er in der swanctl als "dynamic". Äußerst eigenartig. Er macht zwar was er soll, aber das ist ein Hinweis das man dort an anderen Stellen vermutlich irgendwas anders macht.

Wenn meine Nerven sich wieder entspannt haben sollten, dann kann ich nochmal einen Versuch mit IKEv2 wagen. Vorerst bleibt es dabei. Ist auch nur vorübergehend.
ZeroTrustFW
ZeroTrustFW 27.06.2025 aktualisiert um 20:36:35 Uhr
Hi,

die PA-220 ist leider mit PAN-OS10/11 nicht die performanteste Firewall wenn man ein commit der config machen möchte.

Laut der Palo Alto Doku:
knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA10g0000 ...

"Unknown ikev2 peer" means that there is an IKE version mismatch between the VPN peers. One of the peer is using IKEv1, and another peer is using IKEv2. This could be verified through the packet captures as shown below.


Troubleshooting:

Tunnelaufbau initialisieren:
  • test vpn ike-sa gateway S2S-IKE-Name

Logs:
  • grep mp-log ikemgr.log pattern S2S-IKE-Name
Hier bekommst du z. B. folgendes zurück:
2025-06-27 19:58:20.000 +0200  [INFO]: {    2:     }: IKEv2 INFO transmit: gateway S2S-IKE-Name, message_id: 0x00000357, type 3 SA state ESTABLISHED

Dann grep du z. B. den Teil hier: { 2: } -> " 2: " also so:
  • grep mp-log ikemgr.log pattern " 2: "

Damit erhälst du alle Narichten für einen bestimmten Tunnel.

Ansonsten bekommst du hier weitere Troubleshooting Tipps:
knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA10g0000 ...
krakovic.de/palo-alto-vpn-vpn-tunnel-troubleshooting-tunnel-auf- ...


Ich hoffe das hier dir weiter.
jackdaniel
jackdaniel 27.06.2025 aktualisiert um 21:40:48 Uhr
Wie ZeroTrustFW schon sagt, die PA220 ist nicht sehr schnell. Vor allem seit PanOS 10.

Wir haben die bei Kollegen stehen denen ein VPN am Laptop nicht reicht und ich verabscheue diese Dinger.
Generell sind die neuen, z.B. die 440er, deutlich schneller. Empfehle ich auch statt die Lizenz für die 220er neu zu kaufen (wird vermutlich auch günstiger sein...).

Zu deinen Überlegungen wegen HA und der Lizenz: Wahrscheinlich laufen die in Active/Passive, dann übernimmt eh nur eine der beiden FW den Traffic. Dazu müssen aber die HA links bzw. das Monitoring vernünftig eingestellt sein.
Ob HA ohne Lizenz noch funktioniert weiß ich nicht sicher, gehe aber davon aus.
Ohne Lizenz bekommst du halt keine Updates für das OS oder die Wildfire, Thread usw. Definitionen. Funktionieren sollte sie aber noch.

Ich habe auf der Arbeit in einer ähnlichen Konstellation schon 2, bald 3 Tunnel zu OPNSENSE stehen. Läuft gut mit IKEv2. Kann dir die Config beider seiten am Montag geben, wenn du willst.
Wenn du mir die PanOS Version sagst kann ich auch mal schauen obs da irgendeinen bekannten Bug gibt. 11.2 ist noch sehr speziell (falls das überhaupt auf der 220 läuft).

VG und ein schönes WE!
Fenris14
Fenris14 30.06.2025 aktualisiert um 09:50:53 Uhr
Wäre auf jeden Fall interessant! Wenn du da mal Configs liefern könnte wäre ich sehr dankbar. Kann auch wirklich an der OPNsense liegen und deren neues VPN-IPSEC-Menü. Ich hoffe das dort noch wesentlich nachgebessert wird.

Im Prinzip will ich keine neue PA kaufen. Die soll nur noch paar Monate überbrücken, bevor ich den Standort dort endgültig migriert habe und schließen kann. Trotz der sporadischen Aussetzer der Entwickler bei der OPNsense, hat diese immer noch mein Vertrauen. Als Alternative wäre da noch pfSense. Mittlerweile wäre ich sogar bereits Netgate oder Deciso Geld zuzuschieben um Support zu erhalten. Ist mir tausend Mal lieber, als PA, Cisco, Watchguard oder Fortinet zusammen. Abgesehen von der PA, habe ich mit den restlichen aufgezählten Appliances schon paar mehr Erfahrungen sammeln dürfen. Es war nicht immer Spaß.
aqui
aqui 08.07.2025 aktualisiert um 12:05:41 Uhr
Just for Info zum Thema IKEv2 Peer und dem neuen OPNsense IPsec GUI...

Mit dem Firmware Update auf die derzeit aktuelle 25.1.10 funktioniert nun auch das neue IPsec GUI fehlerlos.
Ein IPsec Connectivity Test mit IKEv2 Peers auf:
  • pfSense 2.8.0
  • Cisco IOS-XE
  • Cisco Firepower
  • Strongswan
  • Mikrotik
  • OpenWRT
  • Sophos
  • Fritzbox (IKEv1)
verlief fehlerlos und ohne jegliche Probleme.
Man kann wohl davon ausgehen das es mit allen anderen IPsec Gegenstellen, wie z.B. die Palo Alto des TOs, dann ebenso ohne Fehler klappt.
Fenris14
Fenris14 08.07.2025 um 12:06:15 Uhr
Vielen Dank für die Rückmeldung. Kommt gerade zur rechten Zeit.

Ich habe heute Abend eine große Umstellung und Neuinstallation vor mir. Unter anderem Wechsel von BareMetal-Linux zu OPNsense und auch einigen IPsec-Verbindungen sind mit dabei. Da kann ich das gleich mal testen.

Würde mich dann nochmal melden.
aqui
aqui 08.07.2025 aktualisiert um 13:27:19 Uhr
Da kann ich das gleich mal testen.
Das neue IPsec GUI ist zwar etwas logischer vom Aufbau, erfordert aber etwas mehr "Klickarbeit".
Wichtig ist nach dem Phase 2 (Children) Setup unten die beiden "+" für die local und remote Location nicht zu übersehen, denn dort werden die jeweiligen IDs der Peers definiert. (Nur die IDs)
Unter Preshared Keys werden dann für die ID Paare der Preshared Key gesetzt.

Da du von bare metal Linux redest hier einmal eine einfache Beispiel Konfig für einen Strongswan Responder (bare metal oder vServer) und einer OPNsense als Initiator.
Das Setup ist dann fast selbsterklärend.

vServer (Strongswan, Responder):
connections {

opnsense {
 unique = replace
 version = 2
 local_addrs = 212.31.x.y
 remote_addrs = 0.0.0.0/0
  local {
   auth = psk
   id = 212.31.x.y
   }
  remote {
   auth = psk
   id = keyid:opnsense@testlab.internal
   }
  children {
   net {
   local_ts = 172.27.26.0/23
   remote_ts = 192.168.111.0/24
   esp_proposals = aes256gcm16-sha256-modp2048,aes128gcm16-sha256-modp1024,aes256-sha256-modp1024
   }
  }
 proposals = aes256gcm16-sha256-modp2048,aes256-sha512-modp2048,aes256-sha512-modp1024,aes256-sha256-modp2048
 }

mikrotik {
 unique = replace
 version = 2
 local_addrs = 212.31.x.y
 remote_addrs = 0.0.0.0/0
  local {
   auth = psk
   id = 212.31.x.y
   }
  remote {
   auth = psk
   id = keyid:mikrotik@testlab.internal
   }
  children {
   net {
   local_ts = 172.27.26.0/23
   remote_ts = 10.11.1.0/24
   esp_proposals = aes256gcm16-sha256-modp2048,aes128gcm16-sha256-modp1024,aes256-sha256-modp1024
   }
  }
 proposals = aes256-sha512-modp2048,aes256-sha512-modp1024,aes256-sha256-modp2048
 }

}

secrets {
ike-1 {
 id = keyid:opnsense@testlab.internal
 secret = "GeheiM123!"  
 }
ike-2 {
 id = keyid:mikrotik@testlab.internal
 secret = "GeheiM321!"  
 }
} 

OPNsense IPsec neues "Connection" Setup (Initiator):
ikev2opnsense

Connection Status (swanctl -l):
opnsense: #3711, ESTABLISHED, IKEv2, 6f5bf4222aa1c541_i 7f9f2f988ccac16d_r*
  local  '212.31.x.y' @ 212.31.x.y[4500]
  remote 'opnsense@testlab.internal' @ 80.x.y.z[9691]
  AES_CBC-256/HMAC_SHA2_512_256/PRF_HMAC_SHA2_512/MODP_2048
  established 1608s ago, rekeying in 12075s
  net: #2756, reqid 3, INSTALLED, TUNNEL-in-UDP, ESP:AES_GCM_16-256
    installed 1608s ago, rekeying in 1705s, expires in 2352s
    in  c8077d2b,  21792 bytes,   230 packets,     0s ago
    out cbd1f74f,  36264 bytes,   197 packets,    10s ago
    local  172.27.26.0/23
    remote 192.168.111.0/24 
Fenris14
Fenris14 11.07.2025 um 15:09:56 Uhr
Also ich habe letzten Mittwoch etwa 5 IPsec-VPN migiriert. Sowas ging alles ohne Probleme. Allerdings habe ich an anderer Stelle gestruggled: NAT auf Tunnel-Interface. Dazu musste ich erstmal verstehen wie das mit den Security Policies Manuell funktionierte. Bin dann irgendwann dahinter gekommen und funktionierte dann tadellos.

Da man ja kein VTI hat, muss man zwangsläufig eine manuelle Security Policy anlegen und dann jeweils die einzelnen internen Netzwerke erlauben. Wichtig dabei ist, das "Destination Network" entweder leer bleibt oder auf die Netzwerke aus dem SA verweist. Danach kann man auf IPsec auch verschiedene NAT-Regeln anwenden.
aqui
aqui 11.07.2025 aktualisiert um 15:36:32 Uhr
Allerdings habe ich an anderer Stelle gestruggled: NAT auf Tunnel-Interface.
Uuhhhh... Sowas extrem Gruseliges macht ein pfiffiger Admin nur wen er es auch wirklich muss und wirklich keinerlei Alternative hat... 🤣
Da man ja kein VTI hat...
Man? Damit meinst du aber jetzt nicht die OPNsense, oder?? 🤔 Zu mindestens die xSenses können ja VTIs.
Aber gut wenn nun alles rennt wie es soll. Kann das Wochenende 🍻 ja kommen... 👍
Fenris14
Fenris14 14.07.2025 um 10:15:00 Uhr
Zitat von @aqui:

Allerdings habe ich an anderer Stelle gestruggled: NAT auf Tunnel-Interface.
Uuhhhh... Sowas extrem Gruseliges macht ein pfiffiger Admin nur wen er es auch wirklich muss und wirklich keinerlei Alternative hat... 🤣

Ich hätte es mir auch gern erspart. Ich musste allerdings ein bestehendes Konstrukt migrieren, das auf einem sehr umfangreichen NAT-Regelwerk basiert. Da wollte ich nichts dem Zufall überlassen, weil es am nächsten Tag wieder laufen musste.

Da man ja kein VTI hat...
Man? Damit meinst du aber jetzt nicht die OPNsense, oder?? 🤔 Zu mindestens die xSenses können ja VTIs.
Aber gut wenn nun alles rennt wie es soll. Kann das Wochenende 🍻 ja kommen... 👍

VTI ja, aber eben nur wenn man Zugriff auf die andere Seite hat oder der gegenüber weiß wovon man spricht. Es muss ja eine Adresse ausgehandelt werden für das Peering. VTI finde ich in der Regel besser, weil man die Schnittstellen granularer ansprechen kann. Während man bei einem Tunnel mit Policies und Traffic Selektoren arbeiten muss.
aqui
aqui 14.07.2025 um 10:33:40 Uhr
Bei VPNs braucht es ja immer ein gewisses Maß an Koordination mit dem Gegenüber, es sei denn man lebt immer mit dynamischen Peers. Gut, wenn das Gegenüber technisch keine Option auf VTIs hat dann kann man das Thema natürlich gleich streichen, keine Frage. VTIs sind routingtechnisch gesehen zweifelsohne im Handling besser, da hast du recht. Allein schon weil sie Multicasting supporten, weil das für dynamische Routing Protokolle essentiell ist. Kann aber eben nicht jede HW. face-wink