14
OpenVPN Datenübertragung nicht mehr möglich
Nabend,
Jahrelang lief mein OpenVPN.
Aktuell kann ich mich zwar verbinden, es springt auf grün um, jedoch werden keine Routen mehr gesetzt beim Windows Client.
Die pfSense habe ich von 2.5.2 auf jetzt 2.7.0 geupdatet (2.7.2. will er gerade nicht und meckert kurioserweise an der Festplattengröße rum)
Ansonsten ist die Serverconfig untouched und auch am Client wurde nichts geändert, aber es verhält sich bei 2 Windows Clients identisch.
Sprich von Windows gehts gerade nicht.
Mit meinem Android Smartphone funktioniert alles wie bisher.
Da es vom Android geht, würde ich den Fehler bei Windows suchen.
Admin bin ich und als Admin explizit wurde es ausgeführt.
Aber was kann das sein? Wurde da bei Windows vielleicht mal etwas geupdatet?
Jahrelang lief mein OpenVPN.
Aktuell kann ich mich zwar verbinden, es springt auf grün um, jedoch werden keine Routen mehr gesetzt beim Windows Client.
Sun Oct 27 19:19:45 2024 Route addition via IPAPI failed [adaptive]
Sun Oct 27 19:19:45 2024 Route addition fallback to route.exe
Sun Oct 27 19:19:45 2024 env_block: add PATH=C:\WINDOWS\System32;C:\WINDOWS;C:\WINDOWS\System32\Wbem
Sun Oct 27 19:19:45 2024 C:\WINDOWS\system32\route.exe ADD 192.168.40.0 MASK 255.255.255.0 10.20.30.1
Sun Oct 27 19:19:45 2024 ROUTE: route addition failed using CreateIpForwardEntry: Das Objekt ist bereits vorhanden. [status=5010 if_index=12]Die pfSense habe ich von 2.5.2 auf jetzt 2.7.0 geupdatet (2.7.2. will er gerade nicht und meckert kurioserweise an der Festplattengröße rum)
Ansonsten ist die Serverconfig untouched und auch am Client wurde nichts geändert, aber es verhält sich bei 2 Windows Clients identisch.
Sprich von Windows gehts gerade nicht.
Mit meinem Android Smartphone funktioniert alles wie bisher.
Da es vom Android geht, würde ich den Fehler bei Windows suchen.
Admin bin ich und als Admin explizit wurde es ausgeführt.
Aber was kann das sein? Wurde da bei Windows vielleicht mal etwas geupdatet?
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: 669058
Url: https://administrator.de/forum/openvpn-datenuebertragung-nicht-mehr-moeglich-669058.html
Ausgedruckt am: 21.12.2024 um 17:12 Uhr
14 Kommentare
Neuester Kommentar
Hallo,
Bei deinen ausführlichen Informationen bleibt nur dein Geschrei mit "geht nicht" übrig.
Gruss,
Peter
Bei deinen ausführlichen Informationen bleibt nur dein Geschrei mit "geht nicht" übrig.
Gruss,
Peter
Moin.
Naja, die Fehlermeldung ist doch sehr eindeutig - die Route besteht schon.
Ich würde die mal manuell löschen, nen Reboot machen und es dann nochmals versuchen.
Cheers,
jsysde
Naja, die Fehlermeldung ist doch sehr eindeutig - die Route besteht schon.
Ich würde die mal manuell löschen, nen Reboot machen und es dann nochmals versuchen.
Cheers,
jsysde
1
erstmal: bist du überhaupt im vpn drin? also bekommst du ne IP aus dem VPN-Bereich? Denn "nur nen update" ist der Beginn vieler Storys in der IT die am Ende im Desaster geendet sind ;).
Also er sagt er ist verbunden, er springt auf grün und ich habe eine passende IP zugewiesen bekommen.
Natürlich könnte man jetzt bei Urknall anfangen, jedoch dass es plötzlich bei Windows nicht mehr geht, jedoch ei Android unverändert, lässt mich eher Clientseitig suchen.
Oder es muss sich grundlegend etwas beim Update geändert haben, jedoch wüsste ich nicht, warum das Android kalt lässt.
Wie lösche ich die Routen, bzw. gibts eine Datei wo man alle sehen kann?
Natürlich könnte man jetzt bei Urknall anfangen, jedoch dass es plötzlich bei Windows nicht mehr geht, jedoch ei Android unverändert, lässt mich eher Clientseitig suchen.
Oder es muss sich grundlegend etwas beim Update geändert haben, jedoch wüsste ich nicht, warum das Android kalt lässt.
Wie lösche ich die Routen, bzw. gibts eine Datei wo man alle sehen kann?
Wie lösche ich die Routen, bzw. gibts eine Datei wo man alle sehen kann?
www.action1.com/how-to-how-to-add-or-remove-static-route-on-windows-systems/
Moin @fnbalu,
ja, weil wie es @jsysde bereits erwähnt hat, keine neue Route für dieses Netz gesetzt werden kann, weil ...
... bereits eine gleiche vorhanden ist. 🙃
Das ist eigentlich meist easy, einfach CMD öffnen und das folgende eintippeln.
Mit ...
... siehst du übrigens alle aktuellen Routen.
Gruss Alex
Aktuell kann ich mich zwar verbinden, es springt auf grün um, jedoch werden keine Routen mehr gesetzt beim Windows Client.
ja, weil wie es @jsysde bereits erwähnt hat, keine neue Route für dieses Netz gesetzt werden kann, weil ...
Sun Oct 27 19:19:45 2024 ROUTE: route addition failed using CreateIpForwardEntry: Das Objekt ist bereits vorhanden. [status=5010 if_index=12]... bereits eine gleiche vorhanden ist. 🙃
Wie lösche ich die Routen, bzw. gibts eine Datei wo man alle sehen kann?
Das ist eigentlich meist easy, einfach CMD öffnen und das folgende eintippeln.
ROUTE DELETE 192.168.40.0 MASK 255.255.255.0 10.20.30.1Mit ...
ROUTE PRINT... siehst du übrigens alle aktuellen Routen.
Gruss Alex
Also, so blöd wie es klingen mag, bei uns war es die Bluetooth Mouse von Logitech. HP Notebook (nagelneu), Sophos FW, OVPN Connect Client und/oder Sophos Client. WLAN steht, VPN wird sauber aufgebaut, aber sonst geht nix. Keine Verbindung ins Internet, keine Verbindung ins interne Netz. Sobald man die Mouse ausgeschaltet hat, ging alles wie gewünscht. Und zwar genau in diesem Moment.
Wie die Routingeinträge aussahen weiß ich jetzt nicht auswendig.
Unsere Lösung war logischerweise eine andere Mouse.
Wie die Routingeinträge aussahen weiß ich jetzt nicht auswendig.
Unsere Lösung war logischerweise eine andere Mouse.
@beck2oldschool
Interessant
Wir haben, ähnlich wie der TO ähnliches Problem:
baue ich mit meinem AD-User die Verbindung zur Sophos XGS auf. Hab ich irgendwas zwischen 2 und 20 Minuten einen Datentransfer. Irgendwann geht nichts mehr (Tu bei steht nach wie vor) reconnect geht dann wieder für x bis 30 Minuten.
Selbes VPN-Profil vom selben Enduser aber mit einem (lokalen) User: kann 2…4…h durcharbeiten.
Und das ist nicht nur auf meinem Gerät so. Muss das aber mal weiter analysieren. Eine GPO, die irgendwelchen Traffic/ Protokollw unterbindet, sind es eigentlich nicht. Haben in der Hinsicht keine Richtlinien definiert. Auch ein Neuaufesetzen des Endgerätes nebst Leeren des Profiles hat bisher nicht geholfen…
@beck2oldschool
@fnbalu
Welche Firewall (in welcher Version) kommt zum Einsatz?
Welcher OpenVPN Client? Wir haben es mit OpenVPN 3.x als auch 2.7 (oder 2.8?) probiert. Aber auch der Sophos Connect kam zum Einsatz…
Interessant
Wir haben, ähnlich wie der TO ähnliches Problem:
baue ich mit meinem AD-User die Verbindung zur Sophos XGS auf. Hab ich irgendwas zwischen 2 und 20 Minuten einen Datentransfer. Irgendwann geht nichts mehr (Tu bei steht nach wie vor) reconnect geht dann wieder für x bis 30 Minuten.
Selbes VPN-Profil vom selben Enduser aber mit einem (lokalen) User: kann 2…4…h durcharbeiten.
Und das ist nicht nur auf meinem Gerät so. Muss das aber mal weiter analysieren. Eine GPO, die irgendwelchen Traffic/ Protokollw unterbindet, sind es eigentlich nicht. Haben in der Hinsicht keine Richtlinien definiert. Auch ein Neuaufesetzen des Endgerätes nebst Leeren des Profiles hat bisher nicht geholfen…
@beck2oldschool
@fnbalu
Welche Firewall (in welcher Version) kommt zum Einsatz?
Welcher OpenVPN Client? Wir haben es mit OpenVPN 3.x als auch 2.7 (oder 2.8?) probiert. Aber auch der Sophos Connect kam zum Einsatz…
Zitat von @em-pie:
@beck2oldschool
@fnbalu
Welche Firewall (in welcher Version) kommt zum Einsatz?
Welcher OpenVPN Client? Wir haben es mit OpenVPN 3.x als auch 2.7 (oder 2.8?) probiert. Aber auch der Sophos > > Connect kam zum Einsatz…
@beck2oldschool
@fnbalu
Welche Firewall (in welcher Version) kommt zum Einsatz?
Welcher OpenVPN Client? Wir haben es mit OpenVPN 3.x als auch 2.7 (oder 2.8?) probiert. Aber auch der Sophos > > Connect kam zum Einsatz…
XGS 2100, letzter Patchstand. OpenVPN Connect, letztes Release, aber auch Sophos Connect vom VPN Portal geladen
Bei mir ist es halt die pfsense wie schon geschrieben.
Die wurde von 2.52 über 2.6 auf 2.7 geupdatet.
Irgendwie seitdem geht es von Windows nicht mehr.
Kurios, dass es nur Windows ist.
Norton habe ich deaktiviert, ohne Veränderung
Die wurde von 2.52 über 2.6 auf 2.7 geupdatet.
Irgendwie seitdem geht es von Windows nicht mehr.
Kurios, dass es nur Windows ist.
Norton habe ich deaktiviert, ohne Veränderung
Moin @em-pie,
das kommt mir ziemlich bekannt vor.
Ist das ein HA Cluster?
Wenn ja, kann es sein, dass du im AD unter "Computers", zusätzlich zu dem normalen AD Objekt für die XGW, auch noch mehrere Objekte mit dem Namen "Sophos*" hast?
Ist der Name der XGS auch korrekt als FQDN eingetragen, sprich "xgs.contoso.local"?
Gruss Alex
Interessant
Wir haben, ähnlich wie der TO ähnliches Problem:
baue ich mit meinem AD-User die Verbindung zur Sophos XGS auf. Hab ich irgendwas zwischen 2 und 20 Minuten einen Datentransfer. Irgendwann geht nichts mehr (Tu bei steht nach wie vor) reconnect geht dann wieder für x bis 30 Minuten.
Selbes VPN-Profil vom selben Enduser aber mit einem (lokalen) User: kann 2…4…h durcharbeiten.
Wir haben, ähnlich wie der TO ähnliches Problem:
baue ich mit meinem AD-User die Verbindung zur Sophos XGS auf. Hab ich irgendwas zwischen 2 und 20 Minuten einen Datentransfer. Irgendwann geht nichts mehr (Tu bei steht nach wie vor) reconnect geht dann wieder für x bis 30 Minuten.
Selbes VPN-Profil vom selben Enduser aber mit einem (lokalen) User: kann 2…4…h durcharbeiten.
das kommt mir ziemlich bekannt vor.
Ist das ein HA Cluster?
Wenn ja, kann es sein, dass du im AD unter "Computers", zusätzlich zu dem normalen AD Objekt für die XGW, auch noch mehrere Objekte mit dem Namen "Sophos*" hast?
Ist der Name der XGS auch korrekt als FQDN eingetragen, sprich "xgs.contoso.local"?
Gruss Alex
Korrekt. Version SFOS 19.5.4 MR-4
Ist der Name der XGS auch korrekt als FQDN eingetragen, sprich "xgs.contoso.local"?
Wo meinst du genau?
Unter System -> Administration -> Admin and user Settings steht unter
In den VPN-Settings ist für den externen Zugriff zudem der Eintrag vpn.company.com hinterlegt und zeigt auf die externen, festen IP-Adressen, die wir haben (der Redundanz wegen zwei Provider). Aber auch, wenn ich mal anstelle des FQDN eine der beiden IP-Adressen in der *.ovpn eintrage, habe ich die selben Effekte...
Wenn ja, kann es sein, dass du im AD unter "Computers", zusätzlich zu dem normalen AD Objekt für die XGW, auch noch mehrere Objekte mit dem Namen "Sophos*" hast?
Nöö. Nix mit Sophos* und aus Urzeiten nur ein Eintrag mit ASGIst der Name der XGS auch korrekt als FQDN eingetragen, sprich "xgs.contoso.local"?
Unter System -> Administration -> Admin and user Settings steht unter
- Hostname "nur" xgs, nicht aber xgs.company.local (ich warte auf irgendeinen Kommentar bzgl. *.local
) - Admin console and end-user-interaction im Punkt "Use a different hostname" xgs.company.com (um das Wildcard-Zertifikat u. a. für die Vouchers nutzen zu können).
In den VPN-Settings ist für den externen Zugriff zudem der Eintrag vpn.company.com hinterlegt und zeigt auf die externen, festen IP-Adressen, die wir haben (der Redundanz wegen zwei Provider). Aber auch, wenn ich mal anstelle des FQDN eine der beiden IP-Adressen in der *.ovpn eintrage, habe ich die selben Effekte...
Moin @em-pie,
😧 ... das nix gut, sprich, es ist so wie ich befürchtet habe ... deine AD Kopplung ist leider am A.... . 😬
Aber ... mach dir keinen Kopf, mit dieser Kinderkrankheit kenne ich mich mittlerweile 1A aus. 🤪
Ja, genau hier.
Und genau das ist bei einer AD gekoppelten Appliance/Cluster nicht wirklich richtig. 😬
Denn so bekommst du zwar NTLM halbwegs ans Laufen, aber ganz sicher kein Kerberos. 😔
Hier muss bei einer AD gekoppelten Appliance/Cluster unbedingt der korrekte FQDN, sprich, so was ähnliches wie "xgs.company.local" stehen. Bitte dies als erstes korrigieren.
Ohh ... 😱 ... ich muss gerade feststellen, dass genau dieser wichtige Punkt, in keiner Doku von Sophos so beschrieben ist. 😭
@LucarToni
Da müsst ihr glaube ich ASAP etwas nachbessern. 😔
Wie es aussieht, haben wir bisher wohl keine Apfel-Jünger unter den Mitlesern. 🙃
Das hat mit deinem Problem auch nicht wirklich etwas zu tun.
So, nun zu der Lösung.
Als erstes muss du dafür sorgen, dass deine Sophos richtig ans AD gekoppelt ist.
Sprich, zuerst solltest du wie oben schon angesprochen, den Namen korrekt, sprich, als FQDN eintragen.
Und bitte das veraltete "ASG" Objekt aus dem AD sicherheitshalber auch gleich löschen.
Dann als nächstes auf die XGS, am besten mit Putty draufspringen und in die "Advanced Shell" gehen und dort die folgenden Befehle nacheinander abschiessen.
Danach sollte, vorausgesetzt die folgenden Einstellungen sind auch korrekt ...
https://docs.sophos.com/nsg/sophos-firewall/19.0/Help/en-us/webhelp/onli ...
... in deinem AD unter Computers ein neues Objekt mit dem Namen gemäss zuvor eingegebenem FQDN auftauchen.
Wenn dass der Fall ist, dann hast du es geschafft und deine XG(S) ist sauber mit dem AD gekoppelt. 😁
Na ja, nicht so ganz ... wenn das ein Cluster ist ... auch wenn es ein reines Failover-Cluster ist, musst du die Putty Prozedur auch auf dem StandBy Node genauso ausführen.
Wenn dir das alles zu heiss ist, dann sag einfach bescheid und ich unterstütze dich gerne per z.B. Teamviewer. 😉
Gruss Alex
Nöö. Nix mit Sophos* und aus Urzeiten nur ein Eintrag mit ASG
😧 ... das nix gut, sprich, es ist so wie ich befürchtet habe ... deine AD Kopplung ist leider am A.... . 😬
Aber ... mach dir keinen Kopf, mit dieser Kinderkrankheit kenne ich mich mittlerweile 1A aus. 🤪
Wo meinst du genau?
Unter System -> Administration -> Admin and user Settings steht unter
Unter System -> Administration -> Admin and user Settings steht unter
Ja, genau hier.
* Hostname "nur" xgs, nicht aber xgs.company.local
Und genau das ist bei einer AD gekoppelten Appliance/Cluster nicht wirklich richtig. 😬
Denn so bekommst du zwar NTLM halbwegs ans Laufen, aber ganz sicher kein Kerberos. 😔
Hier muss bei einer AD gekoppelten Appliance/Cluster unbedingt der korrekte FQDN, sprich, so was ähnliches wie "xgs.company.local" stehen. Bitte dies als erstes korrigieren.
Ohh ... 😱 ... ich muss gerade feststellen, dass genau dieser wichtige Punkt, in keiner Doku von Sophos so beschrieben ist. 😭
@LucarToni
Da müsst ihr glaube ich ASAP etwas nachbessern. 😔
(ich warte auf irgendeinen Kommentar bzgl. *.local )
)Wie es aussieht, haben wir bisher wohl keine Apfel-Jünger unter den Mitlesern. 🙃
In den VPN-Settings ist für den externen Zugriff zudem der Eintrag vpn.company.com hinterlegt und zeigt auf die externen, festen IP-Adressen, die wir haben (der Redundanz wegen zwei Provider). Aber auch, wenn ich mal anstelle des FQDN eine der beiden IP-Adressen in der *.ovpn eintrage, habe ich die selben Effekte...
Das hat mit deinem Problem auch nicht wirklich etwas zu tun.
So, nun zu der Lösung.
Als erstes muss du dafür sorgen, dass deine Sophos richtig ans AD gekoppelt ist.
Sprich, zuerst solltest du wie oben schon angesprochen, den Namen korrekt, sprich, als FQDN eintragen.
Und bitte das veraltete "ASG" Objekt aus dem AD sicherheitshalber auch gleich löschen.
Dann als nächstes auf die XGS, am besten mit Putty draufspringen und in die "Advanced Shell" gehen und dort die folgenden Befehle nacheinander abschiessen.
service nasm:stop -ds nosync
rm -rf /content/nasm
service nasm:start -ds nosyncDanach sollte, vorausgesetzt die folgenden Einstellungen sind auch korrekt ...
https://docs.sophos.com/nsg/sophos-firewall/19.0/Help/en-us/webhelp/onli ...
... in deinem AD unter Computers ein neues Objekt mit dem Namen gemäss zuvor eingegebenem FQDN auftauchen.
Wenn dass der Fall ist, dann hast du es geschafft und deine XG(S) ist sauber mit dem AD gekoppelt. 😁
Na ja, nicht so ganz ... wenn das ein Cluster ist ... auch wenn es ein reines Failover-Cluster ist, musst du die Putty Prozedur auch auf dem StandBy Node genauso ausführen.
Wenn dir das alles zu heiss ist, dann sag einfach bescheid und ich unterstütze dich gerne per z.B. Teamviewer. 😉
Gruss Alex
Moin @em-pie,
noch eine kleine Ergänzung zu dem Authentifizierungsproblem.
Wenn du selber mal genauer nachschauen möchtest, was bei deiner XGS authentifizierungstechnisch Richtung AD gerade schief läuft, dann solltest du mal einen Blick ins nasm.log werfen.
Sprich, per Putty auf die XGS gehen und die "Advanced Shell" öffnen.
Dann als nächstes den "nasm" Dienst in den Debugging-Modus versetzen ...
... und schon kann man mit ...
... live zuschauen, welchen Schabernack dieser treibt. 😉
Und wenn man mit dem Durchschauen des Logs durch ist, sollte man den nasm Dienst mit dem folgenden Befehl ...
wieder in den Normal-Modus versetzen.
Den aktuellen Zustand des nasm Dienstes, kann man übrigens mit dem folgenden Befehl abfragen.
Gruss Alex
noch eine kleine Ergänzung zu dem Authentifizierungsproblem.
Wenn du selber mal genauer nachschauen möchtest, was bei deiner XGS authentifizierungstechnisch Richtung AD gerade schief läuft, dann solltest du mal einen Blick ins nasm.log werfen.
Sprich, per Putty auf die XGS gehen und die "Advanced Shell" öffnen.
Dann als nächstes den "nasm" Dienst in den Debugging-Modus versetzen ...
service nasm:debug -ds nosync... und schon kann man mit ...
tail -f /log/nasm.log... live zuschauen, welchen Schabernack dieser treibt. 😉
Und wenn man mit dem Durchschauen des Logs durch ist, sollte man den nasm Dienst mit dem folgenden Befehl ...
service nasm:debug -ds nosyncwieder in den Normal-Modus versetzen.
Den aktuellen Zustand des nasm Dienstes, kann man übrigens mit dem folgenden Befehl abfragen.
service -S | grep nasmGruss Alex
