IKEv2 Verbindungsaufbau zu einem LANCOM 1790VA Problem

[Gutfred]

Guten Tag!

Ich versuche von einer OPNsense-business 24.10.1 eine IPsec Verbindung zu einem LANCOM 1790VA (Firmware: 10.80.0833RU9 14.10.2024) Router aufzubauen, ohne Erfolg bisher.

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

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)

Fehlermeldung: (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)

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)

Ich freue mich natürlich sehr über Rückmeldung, ich wünsche eine schöne Woche und verbleibe
mit freundlichen Grüßen
GutFred

P.S.: Ich habe natürlich auch anstatt FQUN einen Domain-Name versucht, die eigene IP als lokal und die entfernte IP als remote Identifier - ich habe eine Menge versucht und bin am verzweifeln (deswegen auch der IKEv1 Versuch)

[dmark]

Moin!

Grundsätzlich sieht die Config plausibel aus. Der "Eindeutige Benutzername" hat bei mir eigentlich immer gut funktioniert, das würde ich daher so lassen.

In Deinem charon-Log steht als Port die 4500, das wäre der NAT-T-Port. Hast Du zwischen den Geräten noch ein NAT? Sicherheitshalber kannst Du auf der OPNsense in den Firewall-Regeln für das WAN-Interface die UDP-Ports 500 und 4500 für das Ziel "WAN-IP" freigeben. Außerdem für ESP-Pakete eine Pass-Regel.

Am Lancom würde ich per SSH im Live-Trace den VPN-Verbindungsaufbau beobachten: Per SSH auf dem Lancom anmelden und dann "trace # vpn-status" einschalten. Der gleiche Befehl nochmals eingegeben schaltet das Tracing auch wieder aus.

Notfalls könntest Du noch checken, ob überhaupt Pakete der OPNsense beim Lancom ankommen. Mit "trace # ip-router @ wan.ip.der.opnsense" solltest Du da etwas sehen können.

[Gutfred]

Hi! :D

1 Eindeutiger Benutzername, Ok!

2 Charon Log und NAT-T: Auf der OPNsense laufen noch andere IPsec Tunnel, alle mit NAT-T - aus diesem Grund wurden die nötigen Regeln für Port 500 (ISAKMP) und Port 4500 (NAT-T) sowie das ESP Protokoll schon gemacht - ein zusätzliches NAT sollte es nicht geben

3 LANCOM bietet ja mit der LANconfig Software auch ein Trace an: Habe "VPN-Status" aktiviert und auf der OPNsense ein Verbindungsaufbau angeklickt:
Von der OPNsense sehe ich keinen einzigen Eintrag - dafür aber von anderen IPsec's des LANCOM Routers (eine ins RZ und eine zu einem anderen Standort)
P.S.: Da kam doch ein Eintrag von der IKEv1 Verbindung die ich versucht habe und noch nicht gelöscht habe - ich denke da brauche ich nichts zu machen

Code Select Expand

[VPN-Status] 2025/04/17 13:13:17,543  Devicetime: 2025/04/17 13:13:20,767
starting external DNS resolution for OPNSENSEIKEV1
IpStr=>standort.dyndns.de<, IpAddr(old)=2.7.3.96, IpTtl(old)=300s

[VPN-Status] 2025/04/17 13:13:17,620  Devicetime: 2025/04/17 13:13:20,828
external DNS resolution for OPNSENSEIKEV1
IpStr=>standort.dyndns.de<, IpAddr(old)=2.7.3.96, IpTtl(old)=300s
IpStr=>standort.dyndns.de<, IpAddr(new)=2.7.3.96, IpTtl(new)=300s
P.S.: Etwas später hat er dasselbe DNS Lookup gemacht für die OPNsense IKEv2

Code Select Expand

[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
4 Trace mit ip-router @ WAN.IP.OPNsense gestartet: Mit der IP sowie der DynDNS Adresse kam kein Eintrag auf dem Trace vom LANconfig

Code Select Expand

[TraceStarted] 2025/04/17 13:20:41,583
Used config:
# Trace config
trace + IP-Router @ 2.7.3.96

# Show commands
show bootlog
show locked-jobs

Code Select Expand

[TraceStarted] 2025/04/17 13:21:54,659
Used config:
# Trace config
trace + IP-Router @ standort.dyndns.de

# Show commands
show bootlog
show locked-jobs
Ich habe von der OPNsense Testweise Pings rausgehauen.
Egal ob IP oder DynDNS Adresse, diese wurden im LANconfig Trace nicht angezeigt.
(Gehört ICMP nicht auch unter den "IP-Router" Abschnitt? :D)

-----

Ich bin im Moment Ideenlos!
Wie gesagt - wenn ich anstatt "AES" und "265" ein anderes Protokoll wähle, sagt er eine Proposal Fehlermeldung.
Mit AES 256 sagt er, Authentication failed - ich meine, damit eine Authentication failed muss es ja eine Verbindung geben?

Ich habe noch mal einen anderen Trace gestartet:

Code Select Expand

[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)

Über Ideen/Rat/Tipps freue ich mich sehr!

P.S.: Das Trace vom LANconfig: Ich habe schon vor einer Weile versucht damit zurecht zu kommen: Ich sollte im Moment alles richtig gemacht haben. Aber, da er mir nicht mal das Ping/ICMP anzeigt, vermute ich, vielleicht bin ich das Problem beim Trace vom LANconfig ... (auch wenn ich im Moment nicht davon ausgehe - die anderen Ausgaben hat er mir ja korrekt gebracht)

[Gutfred]

Ein Update von mir:

Es wurde mir geraten, da ich DynDNS auf beiden Seiten benutze, die DynDNS Adressen als "Meine Kennung" und "Peer Identifier" einzutragen.
(und auf dem LANCOM als "Lokale Identität" und "Entfernte Identität". Daten-Typ auf OPNsense: "Eindeutiger Name" - Daten-Typ auf LANCOM: "FQDN")

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 habe dies dann erneut getestet, da ich mich erinnere, schon IP als ID sowie FQDN als ID getestet zu haben:
- 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 Select Expand

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 danach 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! :)

[dmark]

Moin!

Mich irritiert nach wie vor, dass am Lancom nichts von der OPNsense ankommen soll. Jetzt schreibst Du, dass Du auf beiden Seiten dynamische IPs hast. Kann es sein, dass Du da Internetzugänge mit CGNAT hast, d.h. Deine zugewiesene IPv4 gar nicht direkt von außen erreicht werden kann?

Die Sache mit CGNAT könntest Du hier überprüfen: https://simpleip.de/
Jwewils aufrufen von einem Rechner hinter der OPNsense bzw. hinter dem Lancom.

Da werden Dir deine momentanen IPs (v4 und ggf. v6) angezeigt, wie sie im Internet gesehen werden. Speziell bei IPv4 kannst Du überprüfen, ob die IP-Adresse identisch zu der ist, welche das WAN-Interface der OPNsense bzw. des Lancoms hat.

Wenn das gegeben ist, sollte prinzipiell ein Verbindungsaufbau über IPSEC auch mit dynamischen IPs auf beiden Seiten machbar sein. Wichtig ist, dass zumindest die Seite, zu der die Verbindung aufgebaut wird, wirklich eine erreichbare IPv4 hat. Notfalls müsste die Richtung des Verbindungs-Aufbaus umgedreht werden.

Beim Identifier neige ich eher zur Mailadresse gegenüber dem FQDN. Bei der Authentifizierung mit Zertifikaten kann die Mailadresse aus dem Identifier in das Zertifikat übernommen werden und ist so eindeutig. Beim FQDN kann ein DNS-Lookup im Fall von Dyndns je nach Timing ggf. noch eine falsche IP zurückliefern. Dann gibt es einen Mismatch zwischen ankommender IP und per DNS zurückgemeldeter IP. Bei der Zertifikats-Authentifizierung habe ich hierbei auch schon Fehler gesehen. Daher der Rückgriff auf die Mailadresse (FQUN). Aber diese Problematik ist bei PSK anstelle von Zertifikaten weniger relevant.

[Gutfred]

Hi!

Auf beiden Seiten sind die korrekten DynDNS eingetragen als Ziel (konnte ich eben bei einem Ping erfolgreich auflösen, wobei die OPNsense den WAN-Ping nicht beantwortet hat! :D)

Die OPNsense hat am WAN Port eine feste IP

Der LANCOM hat zwei andere funktionierende/aktive IPsec Tunnel vorhanden

Die OPNsense hat noch ca. 5 andere IPsec Tunnel vorhanden, die funktionieren

Kurz: Ich bin mir 100% sicher dass hier kein CGNAT vorhanden ist! :)

P.S:: Der LANCOM hat auf den Ping reagiert :D

-----

Du sagst dass es bei der Verwendung von PSK anstelle von Zertifikaten weniger relevant ist?

Ich habe die Erfahrung bei vorherigen IPsec Tunnel mit OPNsense/LANCOM/noch ein anderer Hersteller gemacht, dass bei der Authentifizierung ich rumspielen musste mit "FQDN" oder "FQUN" oder "IP Adresse" und es irgendwann mal funktioniert hat.
(ich habe hier leider die Logik noch nicht ganz verstanden)

Auf beiden Seiten ist überall der gleiche PSK eingetragen
(an der OPNsense unter "pre-Shared Schlüssel" und im LANCOM bei der lokalen Identität als PW und bei der entfernten Identität als PW - Typ ist korrekt gewählt (Domänen-Name im Moment) und der Eintrag der Identität ist im Moment korrekt (so hoffe ich doch! :D - die lokale und entfernte DynDNS Adresse) )
- wie gesagt - ich spielte bisschen herum mit der Einstellung (FQDN/FQUN/IP-Adresse) und irgendwann hatte es funktioniert.
- leider aber nicht bei diesem Tunnel ;-(

Hast du noch eine Idee? :D
( P.S.: Vielen lieben Dank für deine Antworten bisher! :) )

Schönes Wochenende! :)

[dmark]

Der LANCOM hat zwei andere funktionierende/aktive IPsec Tunnel vorhanden

OK, damit scheidet auch eine Überschreitung der VPN-Lizenz (bei den kleinen Lancoms sind das 5 gleichzeitige Tunnel) aus.

Du sagst dass es bei der Verwendung von PSK anstelle von Zertifikaten weniger relevant ist?

Zertifikate können dahingehend tricky werden, dass man schon bei der Erstellung penibel genau aufpassen muss, welche zusätzlichen Infos man in den SAN-Feldern hinterlegt: FQDN, FQUN, IP-Adressen, ...
Strongswan scheint da recht genau zu prüfen, ob das präsentierte Zertifikat auch wirklich zur angelegten Verbindung passt. Das hat viele Fehlermöglichkeiten und hat mich auch schon die eine oder andere Stunde Debugging gekostet... PSK hingegen nimmt einige zusätzliche Variablen aus dem Spiel und ist speziell bei IPSEC mit Gegenstellen anderer Hersteller da unempfindlicher.

Um es klar zu sagen: Zertifikate sind natürlich sicherer und bei PSK gibt es den einen oder anderen Angriffsvektor, je nach Passwort und IKE-Version/Konfig.

Ich habe die Erfahrung bei vorherigen IPsec Tunnel mit OPNsense/LANCOM/noch ein anderer Hersteller gemacht, dass bei der Authentifizierung ich rumspielen musste mit "FQDN" oder "FQUN" oder "IP Adresse" und es irgendwann mal funktioniert hat.
(ich habe hier leider die Logik noch nicht ganz verstanden)

Ich habe die Erfahrung gemacht, dass man primär auf beiden Seiten für jede Stellschraube exakt die gleichen Werte einstellen muss. Dann klappt es in aller Regel auch. Problem ist natürlich auch die unterschiedliche Benennung. Problematisch sind da die Identitätstypen (meine Empfehlung: FQUN / E-Mail-Adresse, speziell bei Dyndns) und die Einstellungen für PFS (in der Regel DH14, sowohl bei Phase1 als auch bei Phase2). Dann müssen die Hash-Funktionen übereinstimmen (SHA256 oder SHA512). Und AES-256 ist was anderes als AES-256-GCM, also genau prüfen. Ein bisschen Transferleistung ist auch immer nötig, leider.

Auf beiden Seiten ist überall der gleiche PSK eingetragen

Auf der OPNsense wird der PSK nur 1x eingegeben, bei Lancom gibt es den lokalen PSK und den entfernten PSK. Da also 2x das gleiche Passwort rein.

Ansonsten gehen mir die Ideen leider langsam aus.

[dmark]

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"   

Der Part von deinem Log auf der OPNsense irritiert mich. Anscheinend wird versucht, eine Authentifizierung mit Zertifikat vorzunehmen. Bei PSK auf der Lancom-Seite ist dies jedoch zum Scheitern verurteilt.

Hast Du schonmal versucht, die Verbindung auf der OPNsense komplett zu löschen und neu anzulegen? Vielleicht ist irgendwo im Hintergrund durch die Testerei Schrott hängen geblieben, der jetzt stört.

[Gutfred]

Zertifikate können dahingehend tricky werden, dass man schon bei der Erstellung penibel genau aufpassen muss, welche zusätzlichen Infos man in den SAN-Feldern hinterlegt: FQDN, FQUN, IP-Adressen, ...
Strongswan scheint da recht genau zu prüfen, ob das präsentierte Zertifikat auch wirklich zur angelegten Verbindung passt. Das hat viele Fehlermöglichkeiten und hat mich auch schon die eine oder andere Stunde Debugging gekostet... PSK hingegen nimmt einige zusätzliche Variablen aus dem Spiel und ist speziell bei IPSEC mit Gegenstellen anderer Hersteller da unempfindlicher.

Um es klar zu sagen: Zertifikate sind natürlich sicherer und bei PSK gibt es den einen oder anderen Angriffsvektor, je nach Passwort und IKE-Version/Konfig.

Bei IPsec habe ich noch nie mit Zertifikaten herumgespielt/getestet/etc - bin da noch bei 0 - weswegen es mich wundert, warum da die Zertifikatsmeldung war und deswegen habe ich diese genannt

Ich habe die Erfahrung gemacht, dass man primär auf beiden Seiten für jede Stellschraube exakt die gleichen Werte einstellen muss. Dann klappt es in aller Regel auch. Problem ist natürlich auch die unterschiedliche Benennung. Problematisch sind da die Identitätstypen (meine Empfehlung: FQUN / E-Mail-Adresse, speziell bei Dyndns) und die Einstellungen für PFS (in der Regel DH14, sowohl bei Phase1 als auch bei Phase2). Dann müssen die Hash-Funktionen übereinstimmen (SHA256 oder SHA512). Und AES-256 ist was anderes als AES-256-GCM, also genau prüfen. Ein bisschen Transferleistung ist auch immer nötig, leider.

Meine Erfahrung zeigt, dass bei einem FQUN funktioniert und beim anderen FQDN! :D Ich checke noch nicht die Logik, wann genau es funktioniert, da ich hier echt rumspielen/testen musste und es dann mal geklappt hat, obwohl es eigentlich schon vorher hätte funktionieren müssen

Auf der OPNsense wird der PSK nur 1x eingegeben, bei Lancom gibt es den lokalen PSK und den entfernten PSK. Da also 2x das gleiche Passwort rein.

Ansonsten gehen mir die Ideen leider langsam aus.

Habe ich so gemacht, ohne Erfolg.

Dir gehen die Ideen aus? - Freut mich trotzdem sehr dich kennen gelernt zu haben! :D

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"   

Der Part von deinem Log auf der OPNsense irritiert mich. Anscheinend wird versucht, eine Authentifizierung mit Zertifikat vorzunehmen. Bei PSK auf der Lancom-Seite ist dies jedoch zum Scheitern verurteilt.

Hast Du schonmal versucht, die Verbindung auf der OPNsense komplett zu löschen und neu anzulegen? Vielleicht ist irgendwo im Hintergrund durch die Testerei Schrott hängen geblieben, der jetzt stört.

Ich kann am Montag die Verbindung neu anlegen. Vielleicht hilft es wenn ich das inklusive Neustarts mache. Vielleicht lag es nicht an mir, dass sich da eine PSK eingeschlichen hat sondern an der OPNsense/LANCOM. (wobei im Moment und auch schon die ganze Zeit nichts eingestellt war soweit ich weiß)

Ich habe schon eine IKEv1 Verbindung getestet, ohne Erfolg.

-----

Danke für deine Antworten! :) Ich melde mich am Montag wieder!
Liebe Grüße! Schönes Restwochenende bzw. schöne neue Woche! :)

[awado]

Oje, das Drama mit den LANCOMs kenne ich auch. Ich kann nicht wirklich viel dazu beitragen, aber meine Erfahrungen: Es hat mit FQDN eigentlich bei mir nie funktioniert. Aber mit FQUN, solange das eine Mail-Adresse darstellt. Diese muss natürlich nicht existieren. Den Wizard habe ich nur zum Anlegen der Basics genutzt und dann die Knowledgebase-Artikel von der LANCOM-Webseite für das jeweilige Szenario. Ich hab dann die folgende Reihenfolge der Bedingungen gecheckt: 1. (Falls eingestellt) Prüfung des Peers. 2. Prüfung der Phase1-Algorithmen. (SHA256, SHA512 etc.) 3. Prüfung der FQUNs. 4. Prüfung der Phase2-Algorithmen. In der Reihenfolge scheitert's dann i.d.R. auch. Sobald Phase1 mal erfolgreich ist, sollte der Rest auch klappen. Leider ist der LANCOM-Support alles andere als brauchbar. Bei https://www.lancom-forum.de/ sitzen aber ein paar sehr schlaue Leute, die mir oft schon geholfen haben – falls es also nicht an der OPNsense liegen sollte.