2
OPNsense IPsec (IKEv2) funktioniert nicht über PPPoE
Bin seit kurzem Besitzer einer "Appliance" auf Basis Intel N100 mit 4x Gb-LAN. Darauf habe ich mir OPNsense 23.7 gezogen und angefangen einzurichten. Ich möchte Win10/11 und Android 13 per VPN anbinden und würde dabei gern zusätzliche Software vermeiden, also lieber mit Bordmitteln arbeiten. Ich habe gestern mehrere Stunden verschiedene Anleitungen (u.a. von @aqui) gelesen und versucht letztlich auch IPsec zum Laufen zu bringen.
Nachdem gestern nichts mehr ging, habe ich heute alles nochmal platt gemacht und nur ein Minimalsetup auf der OPNsense gefahren. Mittels der Anleitung IPsec IKEv2 VPN für mobile Benutzer auf der pfSense oder OPNsense Firewall einrichten von aqui habe ich dabei auch endlich (zumindest erstmal von einem Win 10 aus) das VPN zum Laufen bekommen.
Musste dabei aber etwas tricksen. Ich habe das WAN Interface auf eine feste IP 192.168.2.1 gesetzt und die Häkchen bei Block private network rausnehmen müssen. Das Serverzertifikat enthielt dabei als Alternate CN den Hostname des OPNsense sowie die IP 192.168.2.1. Meinen Laptop habe ich dann direkt an WAN angeschlossen und konnte von Win 10 (22H2) eine VPN-Verbindung zu dieser IP aufbauen.
Nun die Herausforderung. Ich nutze Glasfaser der Telekom. Dazu habe ich WAN wieder auf DHCP umgestellt, ein VLAN 7 auf das WAN aufgesetzt, sowie ein PPPoE Device auf das VLAN 7 draufgesetzt. Ich muss die PPPoE Daten eingeben, ist im Kundencenter so eingestellt, bekomme auch jedes mal eine neue IPv4. Soweit erstmal kein Problem für mich, das Internet läuft ja damit, die OPNsense kommt ins Netz.
Nun habe ich ein neues Server-Zertifikat ausgestellt, was neben dem Hostname der OPNsense jetzt auch die öffentliche IPv4 enthielt, nachdem der Router online gegangen war. Im IPsec habe ich das Interface dann noch von WAN auf das PPPoE Device geändert und den IPsec Dienst neu gestartet.
Aber es läuft nicht. Ich gebe als Ziel jeweils die öffentliche IPv4 ein, so dass der Common Name des Zertifikats passen müsste. Das scheint auch erstmal zu funktionieren, weil Windows mir sonst "IKE-Authentifizierung-Anmeldeinformationen sind nicht akzeptabel" ausgeben würde. Stattdessen erhalte ich als Fehler "Ungültiges Aufkommen erhalten"/"Invalid payload received". Und ich weiß nicht weiter. In Phase 2 sind alle Algorithmen (SHA1/256/384/512) aktiviert. Die Firewallregeln werden auch automatisch auf dem PPPoE Device angelegt. Auf Android erhalte ich auch nur lapidar den Fehler "Nicht erfolgreich".
Vllt. hat hier noch jemand ein Weihnachtsgeschenk für mich und erlöst mich von dieser Qual
Nachdem gestern nichts mehr ging, habe ich heute alles nochmal platt gemacht und nur ein Minimalsetup auf der OPNsense gefahren. Mittels der Anleitung IPsec IKEv2 VPN für mobile Benutzer auf der pfSense oder OPNsense Firewall einrichten von aqui habe ich dabei auch endlich (zumindest erstmal von einem Win 10 aus) das VPN zum Laufen bekommen.
Musste dabei aber etwas tricksen. Ich habe das WAN Interface auf eine feste IP 192.168.2.1 gesetzt und die Häkchen bei Block private network rausnehmen müssen. Das Serverzertifikat enthielt dabei als Alternate CN den Hostname des OPNsense sowie die IP 192.168.2.1. Meinen Laptop habe ich dann direkt an WAN angeschlossen und konnte von Win 10 (22H2) eine VPN-Verbindung zu dieser IP aufbauen.
Nun die Herausforderung. Ich nutze Glasfaser der Telekom. Dazu habe ich WAN wieder auf DHCP umgestellt, ein VLAN 7 auf das WAN aufgesetzt, sowie ein PPPoE Device auf das VLAN 7 draufgesetzt. Ich muss die PPPoE Daten eingeben, ist im Kundencenter so eingestellt, bekomme auch jedes mal eine neue IPv4. Soweit erstmal kein Problem für mich, das Internet läuft ja damit, die OPNsense kommt ins Netz.
Nun habe ich ein neues Server-Zertifikat ausgestellt, was neben dem Hostname der OPNsense jetzt auch die öffentliche IPv4 enthielt, nachdem der Router online gegangen war. Im IPsec habe ich das Interface dann noch von WAN auf das PPPoE Device geändert und den IPsec Dienst neu gestartet.
Aber es läuft nicht. Ich gebe als Ziel jeweils die öffentliche IPv4 ein, so dass der Common Name des Zertifikats passen müsste. Das scheint auch erstmal zu funktionieren, weil Windows mir sonst "IKE-Authentifizierung-Anmeldeinformationen sind nicht akzeptabel" ausgeben würde. Stattdessen erhalte ich als Fehler "Ungültiges Aufkommen erhalten"/"Invalid payload received". Und ich weiß nicht weiter. In Phase 2 sind alle Algorithmen (SHA1/256/384/512) aktiviert. Die Firewallregeln werden auch automatisch auf dem PPPoE Device angelegt. Auf Android erhalte ich auch nur lapidar den Fehler "Nicht erfolgreich".
Vllt. hat hier noch jemand ein Weihnachtsgeschenk für mich und erlöst mich von dieser Qual
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 82055234635
Url: https://administrator.de/contentid/82055234635
Ausgedruckt am: 25.11.2024 um 00:11 Uhr
2 Kommentare
Neuester Kommentar
Ich habe das WAN Interface auf eine feste IP 192.168.2.1 gesetzt und die Häkchen bei Block private network rausnehmen müssen.
Dabei muss man NICHT tricksen! Zeigt wie leider so häufig das du das Tutorial nicht oder nicht richtig gelesen hast. 🧐Es weisst explizit auf diesen Setup Schritt hin wenn man die Firewall in einem Kaskaden Setup betreibt!
Der Haken darf keinesfalls entfernt werden wenn die Firewall direkt im Internet hängt z.B. per PPPoE mit einem NUR Modem oder Glasfaser ONT!
Feste IP ist nicht zwingend. Das klappt egal mit welcher IP auch DHCP IPs und natürlich auch PPPoE IPs.
Dazu habe ich WAN wieder auf DHCP umgestellt
Das ist Quatsch, denn wenn du PPPoE machst ist DHCP natürlich obsolet!PfSense direkt an Glasfasermodem der Telekom über PPPoE
Server-Zertifikat ausgestellt, was neben dem Hostname der OPNsense jetzt auch die öffentliche IPv4 enthielt
Das ist falsch und geht wegen der wechselnden PPPoE IP dann logischerweise in die Hose! Hier darf nur der DDNS Hostname stehen. Auch darauf weist das Tutorial hin.Der Fehler "Ungültiges Aufkommen" ist ebenso explizit im Kapitel "Phase 2" beschrieben.
(Zitat) “Hash Algorithms”: SHA1, SHA256, SHA384, SHA512 anhaken. (Fehlendes SHA1 ergibt "ungültiges Aufkommen" Fehler bei Windows!"
Siehe zu den Details der Windows Krypto Algorithmen auch HIER!
Nochmals:
Der Winblows IKEv2 Client hat im Gegensatz zu anderen IKEv2 Clients nicht die Möglichkeit den Local Identifier separat zu definieren wie z.B. bei Apple u.a.. Er übernimmt immer fest das, was als VPN Zieladresse konfiguriert wurde.
Damit verbietet sich bei Windows eine stetig wechselnde IP Adresse als Ziel einzugeben weil spätestens mit einer anderen IP am WAN Port das Zertifikat und damit der VPN Tunnel scheitert. Eine Eigenart des Winblows VPN Clients mit der man leben muss.
Du musst also bei dynamischen PPPoE Adressen das Zertifikat immer mit deinem DDNS Hostnamen plus dem lokalen Hostnamen erstellen und zumindestens im Windows Client auch immer diesen DDNS Hostnamen eingeben damit die Überprüfung des Local Identifiers unter Windows immer sauber mit dem SAN des Zertifikats übereinstimmt. Es darf damit bei wechselnden PPPoE Adressen keine IP im Zertifikat definiert sein und dann auch keine IP als Zieladresse im VPN Client stehen.
Einfache Logik und nun wahrlich keine Herausforderung. 😉
Du kannst für ein paar Euro aber problemlos bei der Telekom eine feste IP bekommen, dann klappt es natürlich auch mit allen dreien DDNS, fester Domain auf diese IP oder nackte IP.
Dabei muss man NICHT tricksen! Zeigt wie leider so häufig das du das Tutorial nicht oder nicht richtig gelesen hast. 🧐
Es weisst explizit auf diesen Setup Schritt hin wenn man die Firewall in einem Kaskaden Setup betreibt!
Der Fehler "Ungültiges Aufkommen" ist ebenso explizit im Kapitel "Phase 2" beschrieben.
Ok, ich habe vllt. vergessen zu erwähnen, dass ich mich hier iterativ vorarbeite. Aber niemand hat irgendwas von Kaskade gesagt. Auch steht in meinem Beitrag bereits, dass SHA1 schon längst aktiviert ist. Ja, ich habe Deinen Beitrag mehr als nur 3x sehr genau gelesen.Es weisst explizit auf diesen Setup Schritt hin wenn man die Firewall in einem Kaskaden Setup betreibt!
Der Fehler "Ungültiges Aufkommen" ist ebenso explizit im Kapitel "Phase 2" beschrieben.
Ich versuche gerade mit möglichst kleinen Schritten dem Problem nachzukommen. Und ich binde den neuen, dedizierten Router bewusst nicht in mein vorhandenes Setup ein (also nix mit Kaskade). Daher skizziere ich es nochmal:
Für einen ersten Test habe ich VPN nach der Anleitung aufgesetzt. Um VPN dann zu testen, habe ich WAN eine feste IP 192.168.2.1 verpasst und musste natürlich das Häkchen bei "Block private networks" rausnehmen, sonst tut sich da gar nichts, weil ich den Test-Laptop direkt am WAN-Anschluss angebunden habe. Wie gesagt, Hostname und diese 192.168.2.1 ins Zertifikat und ich konnte mich von Win 10 aus problemlos verbinden. Also: Es funktioniert!
PPPoE: Da habe ich mich unsauber bzw. falsch ausgedrückt. Ich habe ein VLAN7 auf den WAN Anschluss draufgesetzt. Das WAN-Interface selbst dann deaktiviert, aber für das VLAN7 dann PPPoE aktiviert (OPNsense legt dann automatisch ein PPPoE-Device dafür an). Wie gesagt: Internet läuft.
Ja, ich weiß, dass ich natürlich nicht mit der IP dauerhaft arbeiten kann. Aber: ich arbeite mich in kleinen Schritten voran. Daher war das naheliegendste, dass ich im Zertifikat bei den CNs die lokale 192.168.2.1 gegen die öffentliche IP austausche, VPN an das PPPoE-Interface binde und dann in Win 10 auf die öffentliche IP verbinde. Das ist die kleinstmögliche Änderung, die funktionieren sollte. Macht es aber nicht. Ich gehe davon aus, dass die Phase 1 bereits durchläuft, sonst käme ja was wie "IKE-Authentifizierung-Anmeldeinformationen sind nicht akzeptabel", aber ich erhalte stattdessen: "Ungültiges Aufkommen erhalten". Und jetzt nochmal: DH2 in Phase 1 und SHA1 in Phase 2 sind bereit aktiv. Also: Wieso funktioniert der Switch von lokaler IP am WAN auf PPPoE nicht, obwohl es nur diese minimale Änderung an der IP gab?
Ich könnte bei der Telekom natürlich das "Easy Login" wieder aktivieren, dann bekomme ich glaube eine statische IP. Aber DDNS habe ich bereits in Verwendung, sehe also langfristig kein Problem darin, mit dem DNS-Namen zu arbeiten. Mir ist das alles schon klar. Ich möchte nur das Problem verstehen und lösen.
BTW: Ich habe es jetzt auch schon mit dem DDNS-Namen versucht. Gleiches Verhalten, Phase 1 scheint zu laufen, Phase 2 scheitert (Android scheitert ebenfalls)
