VPN (IPsec) Windows zu pfsense nicht möglich

dertowa
Goto Top
Hallo zusammen,
ich habe mich durch das Tutorial hier gearbeitet und war guter Dinge alles beachtet zu haben.
Leider zickt die Verbindung und ich sehe den Fehler nicht. ace-sad"
aqui hat im Tutorial Thread schon versucht einen ersten Diagnoseschritt zu gehen, allerdings kommt bei meinem Paketmitschnitt 0,0 bei raus.

Würde für mich bedeuten, dass Port 500 nicht an der pfsense ankommt (pfsense ist an der Fritz!Box als Exposed Host, manuelles Portforwarding wurde auch versucht, die Fritz!Box macht kein VPN).
Leider ändert sich dies auch nicht, wenn ich das Testnotebook (Windows 11) in das Transfernetz (Fritz!Box) packe und von dort die WAN-IP der pfsense anspreche.
Zwar wird beim Verbindungsaufbau nach einem Benutzernamen und Kennwort gefragt, danach folgt allerdings generell: Das Netzwerk ist nicht vorhanden oder wurde nicht gestartet.

Ein paar Screenshots hatte ich hier schon gepostet: klick
Das ist nun ähnlich einer Wimmelbildaufgabe. face-sad

Meine Vermutung geht in Richtung Firewallregeln, aber ich sehe keine WAN-Zugriffe von der Fritz!Box auf UDP 500, 18000 oder 4500 im Log der pfsense.
Gemäß Tutorial (bzw. Ergänzung) muss dort aber nichts mehr eingerichtet werden, was mich nun entsprechend verwirrt. face-big-smile

Vielleicht hat ja jemand identisches Problem gehabt, oder sieht ggf. direkt meinen Fehler?

Grüße
ToWa

Content-Key: 1921613642

Url: https://administrator.de/contentid/1921613642

Ausgedruckt am: 16.08.2022 um 14:08 Uhr

Mitglied: aqui
aqui 16.02.2022 aktualisiert um 12:28:31 Uhr
Goto Top
Ich hab es geade nochmal mit der neuen 2.6er Version und einem Windows 10 (21H2) getestet und rennt alles fehlerfrei wie es soll ! An der pfSense liegt es also nicht. face-wink
allerdings kommt bei meinem Paketmitschnitt 0,0 bei raus.
Das zeigt dann eindeutig das die IPsec Frames in deiner FritzBox hängen bleiben und erst gar nicht an der pfSense am WAN Port ankommen. Dann ist natürlich klar das es nicht funktionieren kann !
Primär ist das also ein Problem der FritzBox bei dir !!
Hier musst du absolut sicherstellen das keine irgendwelche VPN Settings der FritzBox selber noch aktiv sind. Das bewirkt das die FritzBox keine IPsec Pakete mehr forwardet, auch wenn sie fürs Forwarding eingetragen sind. Die FB "denkt" dann der IPsec Traffic ist für sie und ihr eigenes VPN.
Du solltest also nochmal die Konfig deiner FB genau ansehen !
Leider ändert sich dies auch nicht, wenn ich das Testnotebook (Windows 11) in das Transfernetz (Fritz!Box) packe und von dort die WAN-IP der pfsense anspreche.
Mmmhhh...das zeigt das dann zusätzlich auch noch ein Konfigurationsfehler gemacht wurde in deinem Setup. face-sad
Wenn du in diesem Fall den Packet Sniffer an der pfSense startest, kannst du dann wenigstens eingehende IKE (UDP 500) Pakete sehen ?? Das MUSS klappen !
Wenn nicht ist es eine WAN Port Firewall Regel die dann generell den IPsec Traffic auf die WAN Adresse der pfSense verbietet. Dann geht natürlich auch nix in Sachen VPN, das ist klar.
Es kann auch sein das diese Regel explizit alles verbietet und damit die eigentliche Ursache ist.
Wichtig ist das du in einer Kaskade wie bei dir auf dem WAN Port unten den Haken bei "RFC 1918 Netze erlauben" gesetzt hast !
Das Einrichten des IPsec VPN erzeugt automatisch eine ALLOW Regel der IPsec Protokoll Komponenten UDP 500, UDP 4500 und ESP Protokoll auf die WAN Port Adresse der FW. Natürlich nur sofern du das Erzeugen dynamischer Regeln nicht im Setup unterbunden hast.

Als allererster Schritt MUSS ein VPN Access des Clients im Transfernetz auf die pfSense funktionieren. Das stellt dann absolut sicher das das VPN an sich sauber und fehlerfrei funktioniert.
Sehr hilfreich wären hier in jedem Falle ein Auszug des IPsec Logs der Firewall !! (Bitte immer VOR dem Test über "Reset Logs" löschen damit nicht vorangegangener Log Müll die relevanten Infos überdeckt !!)
Da sollte sowas wie das hier (stark gekürzt) zu sehen sein. Wichtig ist das "established".
(10.77.77.0/ ist das Client IP Netz, 10.88.1.0 das Koppelnetz, .88 pfSense WAN, .120 Win10 Client, "user" MS-CHAPv2" Username)
Also strategisch vorgehen:
  • Erstmal nur aus dem Transfernetz testen um ggf. FB Fehler erstmal sicher auszuschliessen
  • Regelwerk checken das IPsec auf die WAN Adresse passieren darf, auch Default Regel
  • IPsec Log löschen und danach einen Verbindungsversuch machen. Was steht im IPsec Log ?
  • Was sagt der Win 10 Client als Fehlermeldung ?

Mitglied: dertowa
dertowa 16.02.2022 aktualisiert um 12:25:02 Uhr
Goto Top
Zitat von @aqui:
Primär ist das also ein Problem der FritzBox bei dir !!
Nope, die Fritz!Box ist nackt, da war nie was konfiguriert und ist auch nicht.
Die macht: Telefonie (DECT), Internet, DynDNS Connect
Zudem ist das Verhalten ja identisch ob nun aus dem Transfernetz (LAN) oder aus dem Internet.

Leider ändert sich dies auch nicht, wenn ich das Testnotebook (Windows 11) in das Transfernetz (Fritz!Box) packe und von dort die WAN-IP der pfsense anspreche.
Mmmhhh...das zeigt das dann zusätzlich auch noch ein Konfigurationsfehler gemacht wurde in deinem Setup. face-sad
Wenn du in diesem Fall den Packet Sniffer an der pfSense startest, kannst du dann wenigstens eingehende IKE (UDP 500) Pakete sehen ?? Das MUSS klappen !
Nein, da kommt gar nix, ich sehe auch nichts was geblockt wird.

Wichtig ist das du in einer Kaskade wie bei dir auf dem WAN Port unten den Haken bei "RFC 1918 Netze erlauben" gesetzt hast !
Jap, ist das ist der Fall, stand ja auch im Tutorial. face-wink

Das Einrichten des IPsec VPN erzeugt automatisch eine ALLOW Regel der IPsec Protokoll Komponenten UDP 500, UDP 4500 und ESP Protokoll auf die WAN Port Adresse der FW. Natürlich nur sofern du das Erzeugen dynamischer Regeln nicht im Setup unterbunden hast.
Hä?
Nun bin ich vollständig verwirrt.
Im Tutorial stand ja, dass das automatisch erzeugt wird, was bei mir nicht passiert ist.
Daher hatte ich die Regeln bei mir manuell angelegt und hier gelistet, da ich etwas irritiert war was genau dabei einzustellen ist: https://administrator.de/contentid/337198#comment-1849145645
Deine Antwort darauf war, dass ich die auch vollständig entfernen könne, da es dann trotzdem gehen muss, da es "Default Regeln" dafür geben würde? face-big-smile

* Erstmal nur aus dem Transfernetz testen um ggf. FB Fehler erstmal sicher auszuschliessen
So gestern geschehen, daher vermute ich ja die liebe Firewall an sich. face-smile
* Regelwerk checken das IPsec auf die WAN Adresse passieren darf, auch Default Regel
Wer wo sind denn diese Default Regeln?
Eigentlich ist die pfsense genauso nackt wie die Fritz!Box, es gibt eine NAT Regel für Port 18000 und die manuell angelegte im Bereich IPSec für "Allow all" wie im Tutorial beschrieben.
Die anderen Firewallregeln hatte ich wie oben beschrieben ja wieder entfernt.
* IPsec Log löschen und danach einen Verbindungsversuch machen. Was steht im IPsec Log ?
Da steht genauso wie im Paketmitschnitt 0,0.
* Was sagt der Win 10 Client als Fehlermeldung ?
Der sagt Das Netzwerk ist nicht vorhanden oder wurde nicht gestartet. Ereignislog-Auszug findest du gern hier: https://administrator.de/contentid/337198#comment-1866431441

Danke schon mal. face-smile
Mitglied: aqui
aqui 16.02.2022 aktualisiert um 12:48:01 Uhr
Goto Top
Nope, die Fritz!Box ist nackt, da war nie was konfiguriert und ist auch nicht.
OK, dann bleibt nur das Regelwerk am pfSense WAN Port !!
Im Tutorial stand ja, dass das automatisch erzeugt wird, was bei mir nicht passiert ist.
Bitte lies mal genau was oben steht ! Die automatisch erzeugten Regeln kannst du im Rulset nicht sehen !
"pfSense® software automatically adds hidden firewall rules which allow traffic required to establish enabled IPsec tunnels."
https://docs.netgate.com/pfsense/en/latest/vpn/ipsec/firewall-rules.html

Sehr wahrscheinlich hast du den Blocker für die RFC 1918 Netze vergessen zu entfernen am WAN Port, kann das sein ?!
pfwan

In jedem Fall MUSS im IPsec Log der Firewall eingehender IKEv2 Traffic zu sehen sein !
Hier kannst du testweise auch mal jeden beliebigen IPsec Client mit irgendwelchen Phantasiecredentials auf die WAN Port IP loslassen um Log Meldungen generieren zu können. (Siehe Beispiel oben).
Wenn du willst kannst du auch sicherheitshalber die IPsec Rules etablieren und sie später wieder löschen. Doppelt schadet nicht. Sie werden aber definitiv automatisch angelegt.
Der Test und Output oben hat keine extra Rules am WAN Port.

Es sieht ja de facto so aus als ob gar kein IPsec Traffic an deiner pfSense ankommt ! Warum auch immer...?!
Hilfreich wären ein Trace mit dem Diagnostic Tool am WAN Port auf UDP 500
und der Output des IPsec Logs der FW.

Wenn alle Stricke reissen kannst du deinen Client auch einmal lokal mit einem Raspberry Pi aus der Bastelschublade checken wenn du für den RasPi noch ein Server Zert. in der pfSense erzeugst. face-wink
https://administrator.de/tutorial/ikev2-vpn-server-fuer-windows-und-appl ...
Beide nutzen den gleichen Server (Strongswan)
Mitglied: dertowa
dertowa 16.02.2022 um 13:42:25 Uhr
Goto Top
Zitat von @aqui:

Bitte lies mal genau was oben steht ! Die automatisch erzeugten Regeln kannst du im Rulset nicht sehen !
"pfSense® software automatically adds hidden firewall rules which allow traffic required to establish enabled IPsec tunnels."
https://docs.netgate.com/pfsense/en/latest/vpn/ipsec/firewall-rules.html
Irgendwie mag ich es nicht, wenn Dinge automatisch passieren sollen, ich aber keine Chance habe nachzuvollziehen ob diese auch wirklich passiert sind? face-wink
Ich muss mir also mal ansehen ob die Firewall überhaupt automatisch etwas tun darf, oder ob ich das im Anflug von Kontrollwahnsinn ggf. verhindert habe.
To override the automatic addition of these rules check Disable all auto-added VPN rules under System > Advanced on the Firewall & NAT tab.


Sehr wahrscheinlich hast du den Blocker für die RFC 1918 Netze vergessen zu entfernen am WAN Port, kann das sein ?!
pfwan
Das prüfe ich später gern noch mal, bin aber sehr sicher, dass ich speziell das hinsichtlich Routerkaskade berücksichtigt habe.
Zumal sollte die NAT Regel für Port 18000 bei aktivem Haken ebenfalls nicht gehen und auch meine testweise durchgeführte Umleitung von Port 80 (WAN) auf Port 5000 (Synology-NAS) hätte mich aus dem Internet per DynDNS nicht auf meine Synology verwiesen.

Es sieht ja de facto so aus als ob gar kein IPsec Traffic an deiner pfSense ankommt ! Warum auch immer...?!
Hilfreich wären ein Trace mit dem Diagnostic Tool am WAN Port auf UDP 500
und der Output des IPsec Logs der FW.
Die Logs habe ich gestern schon intensiv durchgeackert und genau da klemmte es bei mir, dass ich nicht verstehen kann warum ich eben keine Eingänge auf UDP 500 sehe, selbst fehlerhafte müssten ja drin sein und abgewiesen werden, es gibt aber einfach keine.
Ich logge später noch mal und stelle mal ein, letztlich ist es vermutlich irgendeine dämliche Kleinigkeit. face-smile
Mitglied: aqui
aqui 16.02.2022 aktualisiert um 14:40:55 Uhr
Goto Top
Ich aber keine Chance habe nachzuvollziehen ob diese auch wirklich passiert sind?
Ja, da hast du Recht. Die OPNsense ist da etwas besser, denn die hat einen Extra Button im Regel GUI um sich die automatischen und Default Regeln anzeigen zu lassen. Ich meine auf der pfSense geht das nicht oder wenn, dann vermutlich nur über die Shell und iptables direkt.
To override the automatic addition of these rules check Disable all auto-added VPN rules under System
Jepp, das ist der Setup Punkt. Wenn du den aktivierst MUSST du natürlich die IPsec Regeln setzen.
und genau da klemmte es bei mir, dass ich nicht verstehen kann warum ich eben keine Eingänge auf UDP 500 sehe
Das ist in der Tat sehr sehr ungewöhnlich ! Auch wenn du den Paket Capture z.B. mal ganz offen capturen lässt ohne Filter auf UDP 500 MUSST du dort eingehende UDP 500 Pakets sehen wenn du einen Zugriffsversuch machst vom VPN Client !
Es kann natürlich ggf. auch der Winblows Client selber sein das du da sowas wie Kaspersky oder eine andere (meist überflüssige) Security Appliance nutzt die alles blockt was nicht explizit freigegeben ist, so das der Win VPN Client schon gar kein IPsec aussendet...auch möglich !
Das kannst du aber sehr schnell checken indem du den Client VPN Traffic mal auf einen Wireshark Sniffer sendest und das überprüfst.
letztlich ist es vermutlich irgendeine dämliche Kleinigkeit.
Irgend sowas wird's sicher sein ! Die VPN Konfig auf der pfSense ist wasserdicht. face-wink
Mitglied: dertowa
dertowa 17.02.2022 um 11:05:46 Uhr
Goto Top
So, gestern leider nicht mehr zu gekommen, nun erstmal der Screenshot zur WAN-Schnittstelle anbei, bzgl. RFC 1918.
Die Protokolle bleiben aber einfach leer, auch nach Verbindungsversuch.

So, nun hatte ich keine Lust mehr und habe mir mal mein Android-Tablet geschnappt und aus dem Transfernetz eine VPN Verbindung mit der strongSwan App probiert.
Et voila läuft doch und das Protokoll der pfsense zeigt mir endlich mal Einträge an mit denen ich was anfangen kann.

Bleibt also der Windows 11 Client und die integrierte VPN die ich nicht verstehe:
vpn
error
zert

Den Punkt Security Powershell im Tutorial hatte ich übersprungen, da ich erstmal einfach nur checken wollte ob es im Standard funktioniert, vielleicht ist das ein Fehler? face-big-smile
wan
Mitglied: aqui
aqui 17.02.2022 aktualisiert um 14:04:38 Uhr
Goto Top
Bleibt also der Windows 11 Client und die integrierte VPN
Das war dann bei dem Fehlerbild auch das Einzige was übrigblieb...!
Nur noch einmal dumm nachgefragt:
Den wichtigen KB 5010793 Patch für Windows hast du hoffentlich installiert, oder ?
Der fixt ein generelles Problem aller Windows lokalen VPN Clients was mit dem Januar Update kam !
Den Punkt Security Powershell im Tutorial hatte ich übersprungen, da ich erstmal einfach nur checken wollte ob es im Standard funktioniert, vielleicht ist das ein Fehler?
Nope, war definitiv kein Fehler, denn du hast ja SHA1 entsprechend im Setup aktiviert. Alles gut also... Deine Win VPN Konfig ist soweit auch absolut richtig. Nur...
Wenn der Win Client überhaupt keinerlei IPsec sendet dann ist das definitiv kein FW Problem wenn du im Gegenzug dazu bei Android ja solchen eingehenden Traffic siehst.
Mitglied: dertowa
dertowa 17.02.2022 um 14:08:44 Uhr
Goto Top
Zitat von @aqui:
Der fixt ein generelles Problem aller Windows lokalen VPN Clients was mit dem Januar Update kam !
Der Fix ist nicht mehr nötig, da jedes neuere Build den Patch ja integriert hat (kumulative Updates).
Da das System auf einem frischen Stand ist, ja der Fix ist drin.
Mitglied: aqui
aqui 17.02.2022 aktualisiert um 16:47:03 Uhr
Goto Top
Ich schmeiss mal eben mein Windows 11 Testsystem an und checke das mal mit Win 11. Nur um auf Nummer sicher zu gehen. face-wink

So, gleiche Firewall wie bei Windows 10 und auch mit Windows 11 die gleichen Log Messages, Captures und Connection. Funktioniert auch mit 11 fehlerfrei:
ik2v2
Was hast du da bloß verfummelt auf deinem Windows Client ??
Mitglied: dertowa
dertowa 17.02.2022 aktualisiert um 16:45:43 Uhr
Goto Top
Zitat von @aqui:
ik2v2
Was hast du da bloß verfummelt auf deinem Windows Client ??

Also aktuell sind wir bei 22000.493. face-smile
Verbummt hab ich da eigentlich nix, ist nen ganz normales ThinPad aktualisiert von Win 10 auf Win11, der hat für die Firma noch ein Securepoint SSL VPN Client drauf, ich werd mir wohl mal gerade einen anderen Client schnappen. Hmm...

win10

Einfach mal ne Win 10er VM, die ist aber nicht am Stand, die geht auch.
Toll, speziell für das Arbeitsnotebook wollt ich doch ne VPN ins Heimnetz. face-big-smile

...nein, das Gerät hat keine Richtlinien der Firma, denn die müsste ich selbst definieren...
Mitglied: aqui
aqui 17.02.2022 um 16:46:05 Uhr
Goto Top
Also aktuell sind wir bei 22000.493
Das Update läuft grad noch durch... face-wink
der hat für die Firma noch ein Securepoint SSL VPN Client
Das wird sehr wahrscheinlich der pöhse Puhmann sein der den lokalen VPN Client killt mit der Installation. Nimm mal eine jungfräuliche Kiste ohne den Client.
Mitglied: dertowa
dertowa 17.02.2022 aktualisiert um 16:59:58 Uhr
Goto Top
Zitat von @aqui:
der hat für die Firma noch ein Securepoint SSL VPN Client
Das wird sehr wahrscheinlich der pöhse Puhmann sein der den lokalen VPN Client killt mit der Installation. Nimm mal eine jungfräuliche Kiste ohne den Client.

S.o., hmm vielleicht sollte ich dann mal überlegen ob ich den Securepoint Client gegen nen OpenVPN tausche, damit läuft die Firmenfirewall nämlich auch, also Securepoint ist kompatibel.
Das check ich jetzt! face-big-smile

Edit: Securepoint ist unschuldig.
Fehlermeldung bleibt, trotz Deinstallation und entfernen des TAP-Netzwerkadapters.
...scheine aber nicht allein mit dem Problem: klick
Mitglied: dertowa
Lösung dertowa 17.02.2022 um 17:06:15 Uhr
Goto Top
Übeltäter gefunden!
Auf dem Notebook war mal für die Verbindung zu einer Außenstelle der FRITZ!Fernzugang installiert.
Das Ding scheint die Netzwerkeinstellungen von Windows zu verdrehen.

Runtergeworfen, Notebook neugestartet, VPN Verbindung angeklickt - geht.

Manchmal könnte man AVM...
Mitglied: aqui
aqui 17.02.2022 um 18:29:32 Uhr
Goto Top
👍 👏
Das Ding scheint die Netzwerkeinstellungen von Windows zu verdrehen.
Ja, der tötet den lokalen VPN Client wie das z.B. auch der Shrew Client macht. Man sollte nur einen IPsec Client zur Zeit nutzen.
Ggf. sollte man diese Warnung nochmal mit ins Tutorial aufnehmen.
Manchmal könnte man AVM...
He he he... face-wink