14
VPN (IPsec) Windows zu pfsense nicht möglich
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.
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.
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.
Vielleicht hat ja jemand identisches Problem gehabt, oder sieht ggf. direkt meinen Fehler?
Grüße
ToWa
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.
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.
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.
Vielleicht hat ja jemand identisches Problem gehabt, oder sieht ggf. direkt meinen Fehler?
Grüße
ToWa
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: 1921613642
Url: https://administrator.de/contentid/1921613642
Ausgedruckt am: 19.12.2024 um 08:12 Uhr
14 Kommentare
Neuester Kommentar
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. 
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 !
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:
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. 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)
> CHILD_SA con-mobile{6} established with SPIs c2f00c0e_i da4a8b06_o and TS 192.168.1.0/24|/0 === 10.77.77.1/32|/0
> SPI 0xda4a8b06, src 10.88.1.88 dst 10.88.1.120
> adding outbound ESP SA
> SPI 0xc2f00c0e, src 10.88.1.120 dst 10.88.1.88> adding inbound ESP SA
> using HMAC_SHA1_96 for integrity
> using AES_CBC for encryption
> CHILD_SA con-mobile{6} state change: CREATED => INSTALLING
> selecting traffic selectors for us:
> selected proposal: ESP:AES_CBC_256/HMAC_SHA1_96/NO_EXT_SEQ
> configured proposals: ESP:AES_GCM_16_256/NO_EXT_SEQ, ESP:AES_GCM_12_256/NO_EXT_SEQ, ESP:AES_GCM_8_256/NO_EXT_SEQ
> received proposals: ESP:AES_CBC_256/HMAC_SHA1_96/NO_EXT_SEQ, ESP:AES_CBC_128/HMAC_SHA1_96/NO_EXT_SEQ
> proposal matches
> assigning virtual IP 10.77.77.1 to peer 'user'
> reassigning offline lease to 'user'
> peer requested virtual IP %any
> maximum IKE_SA lifetime 26541s
> scheduling rekeying in 23661s
> IKE_SA con-mobile[3] state change: CONNECTING => ESTABLISHED
> IKE_SA con-mobile[3] established between 10.88.1.88[pfSense.test.home.arpa]...10.88.1.120[10.88.1.120]
> authentication of 'pfSense.test.home.arpa' (myself) with EAP
> authentication of '10.88.1.120' with EAP successful
> EAP method EAP_MSCHAPV2 succeeded, MSK established
> parsed IKE_AUTH request 4 [ EAP/RES/MSCHAPV2 ]
> received cert request for "CN=internal-ca, ST=M, L=M, O=Private, OU=Test"
> found matching ike config: 10.88.1.88...0.0.0.0/0, ::/0 with prio 1052
> candidate: 10.88.1.88...0.0.0.0/0, ::/0, prio 1052
> looking for an IKEv2 config for 10.88.1.88...10.88.1.120
> parsed IKE_SA_INIT request 0 [ SA KE No N(FRAG_SUP) N(NATD_S_IP) N(NATD_D_IP) V V V V ]
> received packet: from 10.88.1.120[500] to 10.88.1.88[500] (1104 bytes - 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 ?
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.
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.
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: IPsec IKEv2 VPN für mobile Benutzer auf der pfSense oder OPNsense Firewall einrichten
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?
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.
Danke schon mal.
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. 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 !
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. 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: IPsec IKEv2 VPN für mobile Benutzer auf der pfSense oder OPNsense Firewall einrichten
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?
* 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. * 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: IPsec IKEv2 VPN für mobile Benutzer auf der pfSense oder OPNsense Firewall einrichtenDanke schon mal.
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 ?!
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.
IKEv2 VPN Server für Windows und Apple Clients mit Raspberry Pi
Beide nutzen den gleichen Server (Strongswan)
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? 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
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 ?!
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.Hilfreich wären ein Trace mit dem Diagnostic Tool am WAN Port auf UDP 500
und der Output des IPsec Logs der FW.
Ich logge später noch mal und stelle mal ein, letztlich ist es vermutlich irgendeine dämliche Kleinigkeit.
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.
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:
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?
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:
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?
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.
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).Der fixt ein generelles Problem aller Windows lokalen VPN Clients was mit dem Januar Update kam !
Da das System auf einem frischen Stand ist, ja der Fix ist drin.
Ich schmeiss mal eben mein Windows 11 Testsystem an und checke das mal mit Win 11. Nur um auf Nummer sicher zu gehen.
So, gleiche Firewall wie bei Windows 10 und auch mit Windows 11 die gleichen Log Messages, Captures und Connection. Funktioniert auch mit 11 fehlerfrei:
Was hast du da bloß verfummelt auf deinem Windows Client ??
So, gleiche Firewall wie bei Windows 10 und auch mit Windows 11 die gleichen Log Messages, Captures und Connection. Funktioniert auch mit 11 fehlerfrei:
Also aktuell sind wir bei 22000.493.
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...
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.
...nein, das Gerät hat keine Richtlinien der Firma, denn die müsste ich selbst definieren...
Also aktuell sind wir bei 22000.493
Das Update läuft grad noch durch... 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.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!
Edit: Securepoint ist unschuldig.
Fehlermeldung bleibt, trotz Deinstallation und entfernen des TAP-Netzwerkadapters.
...scheine aber nicht allein mit dem Problem: klick
Ü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...
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...
1
👍 👏
Ggf. sollte man diese Warnung nochmal mit ins Tutorial aufnehmen.
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... 1
