LANCOM IKEv2 zu OPNsense - AUTHENTICATION_FAILED

Forum zum Thema allgemeinen Fragen zu VPN

Moderator: Lancom-Systems Moderatoren

Antworten
BestFred
Beiträge: 8
Registriert: 25 Apr 2023, 12:44

LANCOM IKEv2 zu OPNsense - AUTHENTICATION_FAILED

Beitrag von BestFred »

Guten Tag allerseits!

Ich habe einen Haupt-Standort der im Moment zwei Internetleitungen hat.
Es gibt ein paar Außenstellen, die per LANCOM mit IPsec verbunden sind. (IKEv1 sowie IKEv2)

Der Hauptstandort hat bei der neuen Internetleitung eine OPNsense Firewall, die bald den LANCOM vom Hauptstandort an der anderen Internetleitung ablösen soll.
Im Moment bin ich dabei die Außenstandorte per IPsec mit der OPNsense zu verbinden (LANCOM zu LANCOM steht schon länger, wird wie gesagt bald abgelöst) und stoße dabei immer wieder auf Probleme, die ich meistens bisher beheben konnte.

Nun komme ich zum aktuellen Problem:

Die Konfiguration auf der OPNsense und LANCOM scheinen korrekt zu sein, aber, wenn ich eine Verbindung aufbauen will, sagt die OPNsense Firewall: AUTHENTICATION_FAILED

Code: Alles auswählen

Fehlermeldung auf OPNsense: (P.S.: Die IP Adressen sind gefaked!)
2025-04-14T16:21:39   Informational   charon   06[IKE] <con7|344> received AUTHENTICATION_FAILED notify error   
2025-04-14T16:21:39   Informational   charon   06[ENC] <con7|344> parsed IKE_AUTH response 1 [ N(AUTH_FAILED) ]   
2025-04-14T16:21:39   Informational   charon   06[NET] <con7|344> received packet: from 4.12.9.23[4500] to 21.27.30.16[4500] (96 bytes)   
2025-04-14T16:21:39   Informational   charon   06[NET] <con7|344> sending packet: from 21.27.30.16[4500] to 4.12.9.23[4500] (496 bytes)
Im LANmonitor sehe ich keinen Fehler
- er sagt "Verbindungen ohne Fehler: 2" - das sind andere VPNs
- "Verbindungen mit Fehler: Keine"

Code: Alles auswählen

Konfiguration OPNsense:
- IPsec -> Tunnel Settings [legacy] mit IPv4 IKEv2
- Anschlussart Standard mit V2, IPv4, die einzige WAN Schnittstelle
- Fernes Gateway ist eine DynDNS Adresse die sich korrekt pingen lässt (auch von der OPNsense aus, er bekommt eine Antwort)
- Mutual PSK
- Meine Kennung: Eindeutiger Benutzername (mail1@domain1.tld)
- Peer-Identifizierer: Eindeutiger Benutzername (mail1@domain1.tld)
- PSK an OPNsense und LANCOM hinterlegt
- AES -> 256
- SHA256, SHA512
- DH 14
- Richtlinie installieren: Häkchen gesetzt
- NAT-T: AKtiviert
- Close Action: Keines
- Unique: Ersetzen
- der Rest ist leer
Phase2:
- Tunnel IPv4
- LAN Subnetz
- 192.168.0.0/24 Remote Netz
- ESP
- AES256, aes256gcm16
- SHA256, SHA512
- PFS: 14
- Lebenszeit: 3600

Code: Alles auswählen

Konfiguration LANCOM:
- VPN -> IKEv2/IPsec
- Entferntes Gateway auch eine DynDNS Adresse die sich korrekt auflöst bei einem Ping von meinem W11 Client
- Verschlüsselung, folgendes aktiviert:
- DH: 14
- PFS: Ja
- IKE-SA: AES-CBC-256, AES-GCM,356
- Hash-Liste: SHA-512, SHA-256
- Child-SA folgt:
- Verschlüsselungsliste: AES-CBC256, AES-GCM,256
- Hash-Liste: SHA-512, SHA-256
- Authentifizierung folgt:
- lokaler/Entfernter Identitätstyp: "E-MailAdresse (FQUN)": dieselbe wie bei der OPNsense - lokal und remote dasselbe! (mail1@domain1.tld)
- Passwort habe ich bei lokal und entfernt den PSK eingetragen von der OPNsense (hatte bei anderen Geräten schon funktioniert wie ich mich erinnere)
- der Rest wie vor eingestellt!
- P.S.: Ich nutzte den LANCOM Wizard zum erstellen des Tunnels und wählte Responder als Art (er reagiert auf Verbindungen, baut keine Aktiv auf)
Im Trace Modul vom LANCOM sah ich keine Verbindungsaufbauversuche/etc. - das einzige was ich finden konnte von der OPNsense ist folgendes:

Code: Alles auswählen

[VPN-Status] 2025/04/17 13:14:30,984  Devicetime: 2025/04/17 13:14:34,214
starting external DNS resolution for XXOPNSENSE
IpStr=>standort.dyndns.de<, IpAddr(old)=2.7.3.96, IpTtl(old)=293s

[VPN-Status] 2025/04/17 13:14:30,984  Devicetime: 2025/04/17 13:14:34,221
external DNS resolution for XXOPNSENSE
IpStr=>standort.dyndns.de<, IpAddr(old)=2.7.3.96, IpTtl(old)=293s
IpStr=>standort.dyndns.de<, IpAddr(new)=2.7.3.96, IpTtl(new)=227s
P.S.: Meine Skills mit dem Trace Tool von LANCOM sind anscheinend nicht die besten - wenn Ihr bestimmte Traces wünscht, einfach fragen! :D

Ich belege mal meine LANCOM Trace Skills:
- habe folgenden Trace aktiviert, aber meine (erfolgreichen) Pings auf das WAN Interface konnte ich mir nicht anzeigen lassen:

Code: Alles auswählen

[TraceStarted] 2025/04/17 13:29:22,018
Used config:
# Trace config
trace + IPSEC
trace + VPN-Status
trace + VPN-Packet
trace + VPN-IKE
trace + VPN-Debug
trace + VPN
trace + IPv4-WAN-Packet
trace + IPv4-Packet
trace + IP-Router
trace + ICMP

# Show commands
show bootlog
show locked-jobs
Ich habe die Ergebnisse nach der IP + DynDNS Adresse gefiltert - ich sehe nicht mal die Pings/ICMP von der OPNsense, obwohl die eine Antwort bekommen und obwohl im LANconfig Trace ICMP mit aktiviert wurde ... (ich sehe genau 0 Einträge der IP/Adresse)

Ich habe schon verschiedenes versucht wie z.B. IKEv1 (da sah ich laut LANCOM Trace nicht mal ein Verbindungsaufbauversuch, gar nichts) und verschiedene Proposals getestet (OPNsense akzeptiert anscheinend nur "AES" mit "256" - alle andere will er anscheinend nicht - sonst sagt er "NO PROPOSAL CHOOSEN" was ich so verstehe: keine Proposals ausgewählt auf beiden Seiten die übereinstimmen)

Über Tipps/etc. freue ich mich natürlich sehr! :)

Vielen lieben Dank! Euch eine schöne Restwoche!
Grüße! Bestfred!
Dr.Einstein
Beiträge: 3224
Registriert: 12 Jan 2010, 14:10

Re: LANCOM IKEv2 zu OPNsense - AUTHENTICATION_FAILED

Beitrag von Dr.Einstein »

AUTHENTICATION_FAILED und du benutzt einen DynDNS Account. Sicher, dass du nicht eher FQDN als FQUN benutzen musst und dann als Remote ID in der OPNSense den Domainnamen hinterlergst?
BestFred
Beiträge: 8
Registriert: 25 Apr 2023, 12:44

Re: LANCOM IKEv2 zu OPNsense - AUTHENTICATION_FAILED

Beitrag von BestFred »

Das hört sich logisch an, aber im Moment gehe ich davon aus, dass auch FQUN benutzt werden können ohne "Zusammenhang" zu den restlichen Einstellungen.
(z.B. dass man irgendeine FQUN oder irgendeine random ausgedachte IP für lokal/remote hinterlegt werden kann - muss aber nur an beiden Seiten gleich sein)

Ich teste jetzt deinen Vorschlag erneut, da ich mich erinnere, schon IP als ID sowie FQDN als ID getestet habe:
- habe in der OPNsense unter "Meine Kennung" die im LANCOM eingetragene DynDNS Adresse angegeben (Im LANCOM als Ziel für den Verbindungsaufbau sowie als entfernte Identität, die ich eben auch eingetragen habe)
- beim "Peer-Identifizier" die DynDNS Adresse des LANCOM Routers (und im LANCOM als lokale Identität)

Das kam raus:

Code: Alles auswählen

2025-04-22T14:33:15	Informational	charon	12[IKE] <con7|491> received AUTHENTICATION_FAILED notify error	
2025-04-22T14:33:15	Informational	charon	12[ENC] <con7|491> parsed IKE_AUTH response 1 [ N(AUTH_FAILED) ]	
2025-04-22T14:33:15	Informational	charon	12[NET] <con7|491> received packet: from 4.1.7.8[4500] to 2.2.3.1[4500] (96 bytes)	
2025-04-22T14:33:15	Informational	charon	12[NET] <con7|491> sending packet: from 2.2.3.1[4500] to 4.1.7.8[4500] (512 bytes)	
2025-04-22T14:33:15	Informational	charon	12[ENC] <con7|491> generating IKE_AUTH request 1 [ IDi N(INIT_CONTACT) CERTREQ IDr AUTH N(ESP_TFC_PAD_N) SA TSi TSr N(MOBIKE_SUP) N(ADD_4_ADDR) N(ADD_4_ADDR) N(ADD_4_ADDR) N(ADD_6_ADDR) N(EAP_ONLY) N(MSG_ID_SYN_SUP) ]	
2025-04-22T14:33:15	Informational	charon	12[IKE] <con7|491> establishing CHILD_SA con7{981}	
2025-04-22T14:33:15	Informational	charon	12[IKE] <con7|491> authentication of 'subdomain.dyndns.tld' (myself) with pre-shared key	
2025-04-22T14:33:15	Informational	charon	12[IKE] <con7|491> sending cert request for "C=DE, ST=##, L=##########, O=##########, E=mail@domain.tld, CN=CA"	
2025-04-22T14:33:15	Informational	charon	12[CFG] <con7|491> selected proposal: IKE:AES_CBC_256/HMAC_SHA2_512_256/PRF_HMAC_SHA2_512/MODP_2048	
2025-04-22T14:33:15	Informational	charon	12[ENC] <con7|491> parsed IKE_SA_INIT response 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) ]	
2025-04-22T14:33:15	Informational	charon	12[NET] <con7|491> received packet: from 4.1.7.8[500] to 2.2.3.1[500] (432 bytes)	
2025-04-22T14:33:14	Informational	charon	12[NET] <con7|491> sending packet: from 2.2.3.1[500] to 4.1.7.8[500] (508 bytes)	
2025-04-22T14:33:14	Informational	charon	12[ENC] <con7|491> generating IKE_SA_INIT request 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) N(FRAG_SUP) N(HASH_ALG) N(REDIR_SUP) ]	
2025-04-22T14:33:14	Informational	charon	12[IKE] <con7|491> initiating IKE_SA con7[491] to 4.1.7.8	
2025-04-22T14:33:14	Informational	charon	01[CFG] received stroke: initiate 'con7'
Mich wundert es, dass er die Certificate Authority erwähnt, die wir für OpenVPN Verbindungen benutzen.
In den IPsec Einstellungen sehe ich nirgends eine aktive CA für IPsec.
(wir benutzen die CA bisher auch ausschließlich für OpenVPN)

Ich stelle die OPNsense von "Authentifizierungsmethode" von "Mutual PSK" und danach wieder zurück - vielleicht hat sich doch intern etwas aufgehangen/etc. wobei ich mir 100% sicher bin, nie bei IPsec den "Mutual RSA" oder "Mutual Public Key" aktiviert zu haben.
(habe dann den PSK manuell wieder eintragen müssen)
- es kam beim Verbindungsaufbau genau der gleiche Output wie vorher - mit Zertifikats-Daten im Log!

Hast du Tipps welche Trace ich im LANCOM Trace Tool aktivieren soll um zu sehen, ob und was von der OPNsense kommt?

Vielen lieben Dank nochmal! :)
GrandDixence
Beiträge: 1150
Registriert: 19 Aug 2014, 22:41

Re: LANCOM IKEv2 zu OPNsense - AUTHENTICATION_FAILED

Beitrag von GrandDixence »

Wenn das StrongSwan (charon) im OPNsense ein IKE-Telegramm mit dem Inhalt "AUTHENTICATION_FAILED" erhält, muss man mit dem VPN-Traces Debug, Status und IKE untersuchen, weshalb die LANCOM-Kiste den VPN-Tunnelaufbau verweigert.

Beim Einsatz von PSK sind die Sicherheitshinweise unter:
https://docs.strongswan.org/docs/latest ... hared_keys
zu beachten.

Entsprechende VPN-Anleitung (LANCOM-Router <-> LANCOM-Router) anwenden:
fragen-zum-thema-vpn-f14/vpn-via-androi ... tml#p97795

StrongSwan ist so etwas wie eine Art Referenzimplementierung von IKEv2/IPSec, da braucht man nicht mit hoffnungslos veraltetem IKEv1 rumzubasteln.
https://wiki.strongswan.org/projects/st ... umentation

Die Proposals sind nach den Empfehlungen im BSI TR-02102-3 zu konfigurieren.
https://www.bsi.bund.de/DE/Themen/Unter ... _node.html
Zuletzt geändert von GrandDixence am 22 Apr 2025, 14:56, insgesamt 2-mal geändert.
Dr.Einstein
Beiträge: 3224
Registriert: 12 Jan 2010, 14:10

Re: LANCOM IKEv2 zu OPNsense - AUTHENTICATION_FAILED

Beitrag von Dr.Einstein »

Code: Alles auswählen

tr # vpn-sta
tr # vpn-deb
tr # vpn-ike
vom VPN-Aufbau und einfach hier posten. Evtl. vorher IPs/Domainnamen anonymisieren.
BestFred
Beiträge: 8
Registriert: 25 Apr 2023, 12:44

Re: LANCOM IKEv2 zu OPNsense - AUTHENTICATION_FAILED

Beitrag von BestFred »

Leider sehe ich im LANCOM Trace Tool mit den 3 genannten Optionen keinen einzigen Eintrag der OPNsense (keine WAN-IP, keine DynDNS-Adresse, nichts)

Ich sehe lediglich Einträge der anderen beiden IPsec Tunnel, die auf dem LANCOM laufen.

- da die OPNsense sagt: Authentication failed - da müsste doch etwas auf dem LANCOM auftauchen? Wie gesagt - ich sehe nichts!
- andere IPsec IKEv2 Tunnel (und auch ein paar IKEv1) laufen auf der OPNsense ohne Probleme - ich denke nicht, dass eine Firewall-Regel blockt (bzw. bin mir sicher)
- da ich auf dem LANCOM den Wizard verwendet habe für den Tunnel, denke ich, dass hier auch keine Firewall stört (bzw. bin mir sicher) (auch hier gibt es zwei weitere funktionierende Tunnel - 1 x IKEv1, 1 x IKEv2)

Was soll ich tun?

P.S.: Danke für die Links! Ich konnte dort nichts hilfreiches finden (ich habe auch Testweise die Haltezeit am LANCOM auf 9.999 gestellt und hoffte, er versucht eine Verbindung aufzubauen)
P.P.S.: Im OPNsense Log den ich hier gepostet habe sieht man ja, dass Pakete raus- und reingehen - trotzdem finde ich nichts auf dem LANCOM?
Dr.Einstein
Beiträge: 3224
Registriert: 12 Jan 2010, 14:10

Re: LANCOM IKEv2 zu OPNsense - AUTHENTICATION_FAILED

Beitrag von Dr.Einstein »

Wenn der LanMonitor abgehender Ruf für die OPNsense-VPN-Verbindung anzeigt, siehst du zu 99,999999% diesen Versuch auch im Trace.
GrandDixence
Beiträge: 1150
Registriert: 19 Aug 2014, 22:41

Re: LANCOM IKEv2 zu OPNsense - AUTHENTICATION_FAILED

Beitrag von GrandDixence »

Beim Einsatz von IKEv2 werden für den VPN-Tunnelaufbau 4 IKE-Telegramme benötigt.
https://www.heise.de/hintergrund/Einfac ... 70056.html

IKE_AUTH ist bereits das 3. IKE-Telegramm beim VPN-Tunnelaufbau. Vorgängig wurde das IKE_SA_INIT_Request vom Initiator an den Responder versendet und der Responder hat dem Initiator erfolgreich mit einem IKE_SA_INIT_Response geantwortet.

Da ein IKE_AUTH-Request-Telegramm versendet wurde, funktioniert die Zweiwegkommunikation zwischen den beiden VPN-Endpunkte (Initiator + Responder). Die Frage ist nun, ob die korrekten VPN-Endpunkt für diesen VPN-Tunnel verwendet werden?!

Mit Wireshark und "Packet Capture" die IKE-Telegramme einfangen und untersuchen:
https://community.f5.com/kb/technicalar ... ark/281164
BestFred
Beiträge: 8
Registriert: 25 Apr 2023, 12:44

Re: LANCOM IKEv2 zu OPNsense - AUTHENTICATION_FAILED

Beitrag von BestFred »

Ich habe im LANCOM Router das Häkchen bei "CRL"-Check entfernt und hoffte, damit den Zertifikatseintrag beim Verbindungsaufbau entgegenzukommen - ohne Erfolg! :D

Wegen folgendem Eintrag muss es an den Authentication Credentials liegen.

Code: Alles auswählen

2025-04-25T16:45:15	Informational	charon	09[IKE] <con7|792> received AUTHENTICATION_FAILED notify error	
2025-04-25T16:45:15	Informational	charon	09[ENC] <con7|792> parsed IKE_AUTH response 1 [ N(AUTH_FAILED) ]
Liege ich mit folgender Vermutung richtig?:
1 Da er Daten hin und zurück sendet, sollte die Phase 1 erfolgreich abgeschlossen sein? (ich bin mir eigentlich sicher)
2 Wenn ja, liegt es ausschließlich an den Phase 2 Einstellungen? (bin ich mir eigentlich auch sicher)

Wobei:
A Authentication ist laut der OPNsense Oberfläche eher Phase 1?!
B Vielleicht liegt der Wurm doch irgendwo in der Phase 1?!

Zusatz:
a Ich habe in der OPNsense bei Phase 2 mal alles aktiviert was geht ( AES128, AES182, AES256, aes128gcm16, aes192gcm16, aes256gcm16 ) ( SHA1, SHA256, SHA384, SHA512, AES_XCBC ) ( PFS: 14 - Protokoll: ESP ) (Zielnetz und lokales Netz sind korrekt ) ( Lebenszeit: 3600 ) ( P.S.: Zielnetz auf LANCOM ist auch korrekt - damit meine ich den Routing Eintrag )
b Da er beim Verbindungsaufbau aushandelt, sollte es vorher schon gepasst zu haben: Auf jeden Fall hat dies auch nicht geholfen - ich habe es zurück gestellt ( AES256, aes256gcm16 ) ( SHA256, SHA512 ) (ESP mit PFS 14 wie vorher)
c Da ich bei der OPNsense nicht mehr einstellen kann in Phase 2, liegt es dann entweder am LANCOM Phase 2 oder an der Phase 1 (LANCOM oder OPNsense)

Überlegung:
X Ich hatte schon bei anderen Tunneln das Erlebnis gehabt, dass das Ändern der lokalen / entfernten ID zum erfolgreichen Verbindungsaufbau führte - leider habe ich die Logik dahinter noch nicht ganz verstanden
Y da ich experimentiert hatte mit FQUN oder FDQN oder sogar IP Adresse und es irgendwann mal funktioniert hat
Z liegt es dann vermutlich doch an der Phase 1 Authentifizierung? (obwohl Step 3 von 4 (wobei Step 4 ein Informational Request ist laut dem heise Artikel und eigentlich mehr dafür da ist, aufgebaute Verbindungen zu "handhaben"?) schon am Ende des Verbindungsaufbau sein sollte und evtl dadurch Phase 2?
- oder es ist der letzte Step im Verbindungsaufbau von Phase 1 und somit dann wirklich bei den Authentication Credentials zu suchen?
Da ein IKE_AUTH-Request-Telegramm versendet wurde, funktioniert die Zweiwegkommunikation zwischen den beiden VPN-Endpunkte (Initiator + Responder). Die Frage ist nun, ob die korrekten VPN-Endpunkt für diesen VPN-Tunnel verwendet werden?!
Diese Frage verstehe ich nicht ganz!
Die "Endpunkte" sind korrekt eingetragen (DynDNS Adressen - auf beiden Seiten stets automatisch aktualisiert und funktionierend)
Eben konnte ich beide korrekt/erfolgreich auflösen bei einem Ping (wobei die OPNsense nicht auf Pings aus dem Internet reagiert :D )
(sowie die "lokalen" und "entfernte" Netze sollten korrekt eingetragen sein wie ich eben erwähnte)
Mit Wireshark und "Packet Capture" die IKE-Telegramme einfangen und untersuchen:
https://community.f5.com/kb/technicalar ... ark/281164
Ich hoffe durch den LANCOM Trace und die Bordmittel der OPNsense brauch ich nicht Wireshark/etc. zu installieren auf einem Gerät mit zwei NICs und zwischen Gerät <-> WAN hängen? :D

Schönes Wochenende!
Danke schonmal für Antworten!
Danke für den Artikel GrandDixence (der Heise Artikel ist echt gut! :D )

P.S.:
Wenn der LanMonitor abgehender Ruf für die OPNsense-VPN-Verbindung anzeigt, siehst du zu 99,999999% diesen Versuch auch im Trace.
Werde ich auch noch austesten! :D Danke auch für diesen Beitrag! :)
GrandDixence
Beiträge: 1150
Registriert: 19 Aug 2014, 22:41

Re: LANCOM IKEv2 zu OPNsense - AUTHENTICATION_FAILED

Beitrag von GrandDixence »

Ein ordentlicher Netzwerktechniker hat auf seinem Laptop Wireshark installiert:
https://wiki.wireshark.org/CaptureSetup ... Privileges

und ist in der Anwendung von "Paket-Capturing" (LANCOM-Router) und Port Mirroring (Switch) geübt. Wenn nicht, besteht hier akuter Nachholbedarf!
https://www.lancom-systems.de/docs/LCOS ... uring.html
Antworten