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:

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:
Wenn ich verschiedene Beiträge aus Foren richtig interpretiert habe, ist das beim VTI-Tunnel normal und die Meldung kommt immer.
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:




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ß
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:

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:




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ß
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 673576
Url: https://administrator.de/forum/palo-alto-ipsec-vpn-opnsense-673576.html
Ausgedruckt am: 18.07.2025 um 00:07 Uhr
15 Kommentare
Neuester Kommentar
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.
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.
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. 
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.
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.
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:
Logs:
Dann grep du z. B. den Teil hier: { 2: } -> " 2: " also so:
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.
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
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.
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!
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!
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:
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.
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)
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.
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):

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
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... 👍
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. 