18
VPN mit Lancom Router
Hi,
mehrere Lancom Router haben untereinander VPN Tunnel, die sind stabil. Etliche gehen von Router zu Router, aber es gibt auch welche für Home Office. Die wurden über den Config Wizard + ini Import erzeugt. Nun wollte ich ein Surface Tablett hinzufügen, aber ich bekomme das nicht richtig zu Laufen.
Ich habe über den Wizard mit default-Einstellungen eine ini erzeugen lassen, importiere die im Client und versuche zu verbinden. Es kommt zu Timeouts:
Ich hab testweise das Pad mal in das dortige lokale WLAN connected, gleiches Ergebnis. Dann habe ich die WLAN IP in der VPN Verbindung im Lancome eingetragen (also statt 0.0.0.0 meine WLAN IP, 192.168.x.y), dann klappte der connect! Das Netz ging dann nicht, aber kann auch nicht, weil VPN und WLAN im gleichen IP Netz sind, aber Passwort usw sind offensichtlich richtig und der Client zeigte einen grünen Status.
Meine WLAN Verbindungen liegen alle hinter mindestens 1x NAT.
Nun sehe ich im VPN Client log, dass Port 443 connected wird, sicherlich weil HTTPS zum Tunneln des Tunnels verwendet wird. Gehe ich da mit einem Browser rauf, sehe ich die Login-Seite vom Lancom, wenn das in den Einstellungen aktiviert ist (hab ich lieber nur von intern weil man weiß ja nie). Die HTTPS Verbindung funktioniert also. Nun wundert mich, dass man da was von anderen Ports in Log sieht, port 500, was nach ISAKMP riecht, aber ja im SSL Tunnel versteckt sein müsste, und was von port 4500. Ich hatte in den 90er mal mit IPSec zu tun, das ging aber nicht immer / nicht gut durch NAT.
Hier sitze ich hinter 2x NAT, das erste ist ein Lancom (mit laufendem VPN) und das zweite ist ein billig Router, und nun sei das Passwort falsch:
Das Passwort wurde natürlich nicht geändert. Das Lancom log ist nicht brauchbar, das trace nicht besonders gut, da sehe ich nicht viel. Wenn ich jetzt raten müsste, würde ich mal denken, dass mein Gegenstellen Lancom jetzt die Verbindung falsch zuordnet, weil aus Sicht dessen die IP ja die vom hiesigen Lancom ist (NAT), der für seinen VPN Tunnel natürlich ein anderes Passwort hat. Kurz: ich fürchte, er verwendet nicht den eingestellten Verbindungsnamen sondern die IP, obwohl es einen Eintrag für 0.0.0.0 gibt. Das war jedenfalls in den 90ern mit IPSec ein typisches Problem. Deswegen tunnelt man heute IPSec ja auch (oder was auch immer da verwendet wird).
Allerdings kann ich mir nicht vorstellen, dass so ein teures VPN (hundert Euro pro Client) das nicht alles automatisch richtig macht. Irgendwas machen wir wohl falsch.
Verwendet zufällig jemand Lancoms und kann dazu etwas sagen, idealerweise auch, wie man das Problem löst?
Leider gibts hier nur Windows, und damit kenne ich mich kaum aus. Könnte mir ein Linux in ein Hyper-V installieren und einen UDP Port forwarden lassen, dann könnte ich da ein OpenVPN UDP encap machen, oder geht das besser?
mehrere Lancom Router haben untereinander VPN Tunnel, die sind stabil. Etliche gehen von Router zu Router, aber es gibt auch welche für Home Office. Die wurden über den Config Wizard + ini Import erzeugt. Nun wollte ich ein Surface Tablett hinzufügen, aber ich bekomme das nicht richtig zu Laufen.
Ich habe über den Wizard mit default-Einstellungen eine ini erzeugen lassen, importiere die im Client und versuche zu verbinden. Es kommt zu Timeouts:
17.12.2020 12:45:22 - Isakmp: re-sending packet to=217.77.77.77:443,size=524
17.12.2020 12:45:26 - ERROR - 4021: IKEv2(INIT) - Could not contact Gateway. Please check your internet connection.
17.12.2020 12:45:26 - Ikev2: phase1:name(DSL-xxx-yyy) - ConRef=52,ERROR - retry timeout - max retriesIch hab testweise das Pad mal in das dortige lokale WLAN connected, gleiches Ergebnis. Dann habe ich die WLAN IP in der VPN Verbindung im Lancome eingetragen (also statt 0.0.0.0 meine WLAN IP, 192.168.x.y), dann klappte der connect! Das Netz ging dann nicht, aber kann auch nicht, weil VPN und WLAN im gleichen IP Netz sind, aber Passwort usw sind offensichtlich richtig und der Client zeigte einen grünen Status.
Meine WLAN Verbindungen liegen alle hinter mindestens 1x NAT.
Nun sehe ich im VPN Client log, dass Port 443 connected wird, sicherlich weil HTTPS zum Tunneln des Tunnels verwendet wird. Gehe ich da mit einem Browser rauf, sehe ich die Login-Seite vom Lancom, wenn das in den Einstellungen aktiviert ist (hab ich lieber nur von intern weil man weiß ja nie). Die HTTPS Verbindung funktioniert also. Nun wundert mich, dass man da was von anderen Ports in Log sieht, port 500, was nach ISAKMP riecht, aber ja im SSL Tunnel versteckt sein müsste, und was von port 4500. Ich hatte in den 90er mal mit IPSec zu tun, das ging aber nicht immer / nicht gut durch NAT.
Hier sitze ich hinter 2x NAT, das erste ist ein Lancom (mit laufendem VPN) und das zweite ist ein billig Router, und nun sei das Passwort falsch:
17.12.2020 14:39:41 - Ikev2: ConRef=53,Received notify ERROR message -
17.12.2020 14:39:41 - Ikev2: Notifymsg=<IKEV2_NOTIFY_AUTHENTICATION_FAILED>
17.12.2020 14:39:41 - ERROR - 2110: XAUTH wrong UserId or PasswordDas Passwort wurde natürlich nicht geändert. Das Lancom log ist nicht brauchbar, das trace nicht besonders gut, da sehe ich nicht viel. Wenn ich jetzt raten müsste, würde ich mal denken, dass mein Gegenstellen Lancom jetzt die Verbindung falsch zuordnet, weil aus Sicht dessen die IP ja die vom hiesigen Lancom ist (NAT), der für seinen VPN Tunnel natürlich ein anderes Passwort hat. Kurz: ich fürchte, er verwendet nicht den eingestellten Verbindungsnamen sondern die IP, obwohl es einen Eintrag für 0.0.0.0 gibt. Das war jedenfalls in den 90ern mit IPSec ein typisches Problem. Deswegen tunnelt man heute IPSec ja auch (oder was auch immer da verwendet wird).
Allerdings kann ich mir nicht vorstellen, dass so ein teures VPN (hundert Euro pro Client) das nicht alles automatisch richtig macht. Irgendwas machen wir wohl falsch.
Verwendet zufällig jemand Lancoms und kann dazu etwas sagen, idealerweise auch, wie man das Problem löst?
Leider gibts hier nur Windows, und damit kenne ich mich kaum aus. Könnte mir ein Linux in ein Hyper-V installieren und einen UDP Port forwarden lassen, dann könnte ich da ein OpenVPN UDP encap machen, oder geht das besser?
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 632609
Url: https://administrator.de/contentid/632609
Printed on: April 25, 2024 at 14:04 o'clock
18 Comments
Latest comment
Macht dein Lancom bei den Client Dialin VPNs denn überhaupt IKEv2 ?? Windows 10 macht nur noch IKEv2 und wenn der Lancom nur IKEv1 kann kommen die nicht zueinander. Bei IKEv1 benötigt Windows einen separaten Client wie z.B. den kostenfreien Shrew Client: https://www.shrew.net/download/vpn
Nur das du das auf dem Radar hast...
https://www.shrew.net/support/Howto_Lancom
Nur das du das auf dem Radar hast...
https://www.shrew.net/support/Howto_Lancom
Hi,
Lancom hat eine ziemlich gute Hilfe zu fast jedem Punkt der Konfiguration im Lanconfig.
Das "?" anklicken und auf den Eintrag gehen, dann wid dir gezeigt, was damit gemeint ist.
Bspw. steht das bei "IP-Sec-overHTTPS annehmen":
Wenn du nicht sicher bist, ob es am Surface Tablet liegen könnte, dann nimm doch die Konfiguration und teste diese mit einem anderen Clienten.
Sollte nur wenige Augenblicke dauern.
Die Fehlermeldungen stehen ja eigentlich im Klartext in deinem Trace:
Schon seltsam, dass sich jemand im administrativen IT-Bereich so gar nicht mit Windows auskennt.
Der TO schreibt, er nutzt den teuren Client (ist der von Lancom). Der beherrscht auch IKEv2.
Lancom hat eine ziemlich gute Hilfe zu fast jedem Punkt der Konfiguration im Lanconfig.
Das "?" anklicken und auf den Eintrag gehen, dann wid dir gezeigt, was damit gemeint ist.
Bspw. steht das bei "IP-Sec-overHTTPS annehmen":
Wählen Sie hier, ob eingehende Verbindungen auch angenommen werden sollen, bei denen die IPSec-over-HTTPS Technologie verwendet wird.
Dabei erfolgt eine Kapselung der IPsec-Verbindung in TCP-Paketen auf Port 443, wodurch ein Passieren von Firewalls ermöglicht wird, deren Port-Konfiguration IPsec-Kommunikation grundsätzlich verhindern.
∗ basierend auf NCP VPN Path Finder Technologie
Wichtig:
Wird das Feature IPSec-over-HTTPS verwendet, darf in dem Menü IP-Router → Maskierung → Port-Forwarding-Tabelle kein Port-Forwarding für das Protokoll HTTPS (TCP-Port 443) konfiguriert werden, da ansonsten per IPSec-over-HTTPS keine VPN-Verbindung aufgebaut werden kann.
Dabei erfolgt eine Kapselung der IPsec-Verbindung in TCP-Paketen auf Port 443, wodurch ein Passieren von Firewalls ermöglicht wird, deren Port-Konfiguration IPsec-Kommunikation grundsätzlich verhindern.
∗ basierend auf NCP VPN Path Finder Technologie
Wichtig:
Wird das Feature IPSec-over-HTTPS verwendet, darf in dem Menü IP-Router → Maskierung → Port-Forwarding-Tabelle kein Port-Forwarding für das Protokoll HTTPS (TCP-Port 443) konfiguriert werden, da ansonsten per IPSec-over-HTTPS keine VPN-Verbindung aufgebaut werden kann.
Wenn du nicht sicher bist, ob es am Surface Tablet liegen könnte, dann nimm doch die Konfiguration und teste diese mit einem anderen Clienten.
Sollte nur wenige Augenblicke dauern.
Die Fehlermeldungen stehen ja eigentlich im Klartext in deinem Trace:
17.12.2020 12:45:26 - ERROR - 4021: IKEv2(INIT) - Could not contact Gateway. Please check your internet connection.
17.12.2020 14:39:41 - ERROR - 2110: XAUTH wrong UserId or Password
Leider gibts hier nur Windows, und damit kenne ich mich kaum aus.
Das ist in mehr als 90% aller Firmen auf der Mehrheit der Clients.Schon seltsam, dass sich jemand im administrativen IT-Bereich so gar nicht mit Windows auskennt.
Zitat von @aqui:
Macht dein Lancom bei den Client Dialin VPNs denn überhaupt IKEv2 ?? Windows 10 macht nur noch IKEv2 und wenn der Lancom nur IKEv1 kann kommen die nicht zueinander.
Der Lancom Router kann sowohl IKEv1 als auch IKEv2, auch gleichzeitig.Macht dein Lancom bei den Client Dialin VPNs denn überhaupt IKEv2 ?? Windows 10 macht nur noch IKEv2 und wenn der Lancom nur IKEv1 kann kommen die nicht zueinander.
Der TO schreibt, er nutzt den teuren Client (ist der von Lancom). Der beherrscht auch IKEv2.
Also nutzt du scheinbar die NCP Pathfinder-Technik, wenn da https mit im Spiel ist. Bei LANCOM heißt es IPSec-over-HTTPS.
Hast du dieses aktiviert? Von außerhalb muss dabei der HTTPS-Zugang zum Router nicht aktiv sein. Du bekommst dann zwar dennoch eine HTTPS-Seite angezeigt, aber anders gehts nicht und die Seite ist nur eine Fehlerseite.
Ist die eingetragene Adresse richtig? Hast du die notwendigen Portweiterleitungen drin und landen die beim Router? Also TCP/443, UDP/500, UDP/4500, ESP.
Wenn möglich, solltest du auf den Einsatz von IPSec-over-HTTPS verzichten, weil hierbei baust du dir einen Tunnel im Tunnel im Tunnel. Die Technik ist dafür da, um im Zweifelsfall eine Verbindung zu bekommen, wenn das Netz, in dem der Client ist, so dichtgeschraubt wurde, dass wirklich nur Surfen möglich ist.
Hast du dieses aktiviert? Von außerhalb muss dabei der HTTPS-Zugang zum Router nicht aktiv sein. Du bekommst dann zwar dennoch eine HTTPS-Seite angezeigt, aber anders gehts nicht und die Seite ist nur eine Fehlerseite.
Ist die eingetragene Adresse richtig? Hast du die notwendigen Portweiterleitungen drin und landen die beim Router? Also TCP/443, UDP/500, UDP/4500, ESP.
Wenn möglich, solltest du auf den Einsatz von IPSec-over-HTTPS verzichten, weil hierbei baust du dir einen Tunnel im Tunnel im Tunnel. Die Technik ist dafür da, um im Zweifelsfall eine Verbindung zu bekommen, wenn das Netz, in dem der Client ist, so dichtgeschraubt wurde, dass wirklich nur Surfen möglich ist.
Das Lancom log ist nicht brauchbar, das trace nicht besonders gut, da sehe ich nicht viel.
Ansichtssache. Ein vpn-status-trace hilft mir immer enorm und meistens find ich in Minuten damit den Fehler.
1er nutzt den teuren Client (ist der von Lancom). Der beherrscht auch IKEv2.
Fragt sich dann warum er in dem Falle nicht den bordeigenen von Windows nimmt. Wäre ja ne Runde einfacher und erspart die Installation von Drittsoftware. Aber egal...Zitat von @aqui:
er nutzt den teuren Client (ist der von Lancom). Der beherrscht auch IKEv2.
Fragt sich dann warum er in dem Falle nicht den bordeigenen von Windows nimmt. Wäre ja ne Runde einfacher und erspart die Installation von Drittsoftware. Aber egal...Weil der Assistent des Routers eine Konfigurationsdatei erzeugt, die man in den NCP-Client (LANCOM tauscht nur ein Bild) laden kann, aber nicht in Windows.
Danke für die schnellen Antworten!
Bei shrew finde ich nur Versionen von 2013, und OpenSSL war mit CVEs ja nicht geizig in den letzten Jahren, das sollte man vielleicht lieber nicht über das Internet lassen.
Bei shrew finde ich nur Versionen von 2013, und OpenSSL war mit CVEs ja nicht geizig in den letzten Jahren, das sollte man vielleicht lieber nicht über das Internet lassen.
Danke für den Tipp.
Ah ich sehe, scheinbar kann der das nicht automatisch ermitteln (alle encaps probieren), sondern man muss es auf beiden seiten fest einstellen. Die versprochene "one klick Magie" ist damit leider nur ein Versprechen. Ist bloß blöd, wenn man https nur nutzen möchte, wenn man unbedingt muss, dann braucht man zwei Profile und muss die paar Hand auswählen. Na ja, ich wäre schon froh, wenn es erstmal überhaupt geht.
Ah ich sehe, scheinbar kann der das nicht automatisch ermitteln (alle encaps probieren), sondern man muss es auf beiden seiten fest einstellen. Die versprochene "one klick Magie" ist damit leider nur ein Versprechen. Ist bloß blöd, wenn man https nur nutzen möchte, wenn man unbedingt muss, dann braucht man zwei Profile und muss die paar Hand auswählen. Na ja, ich wäre schon froh, wenn es erstmal überhaupt geht.
Ja, die Fehlermeldungen stehen klar in Text, sind nur leider falsch: das Passwort wurde ja nicht geändert.
Warum sollte es am Surface tablet liegen, da ist ja auch Windows drauf, das sollte sich doch immer gleich verhalten?
90% Windows? Das gilt für Windows Netzwerke?
Keine Erfahrung damit ist seltsam? Dafür bin ich ja jetzt hier
Nee, bisher hatte ich wenig mit Windows zu tun. Selbst in den Microsoft data centers ist ca die Hälfte Linux, bei embedded ist Windows (CE) auch endlich ziemlich tot (nur bank Automaten haben noch Windows XP). Und damals am der Uni hatten wir auch nur HP UX, SUNOS und Irix. Mein Telefon hat auch Linux. Windows benutze ich, um die Spiele zu starten
Ja, IKEv2 ist auf beiden Seiten ausgewählt. Der automatische Modus sollte ja nichts einstellen, was er nicht kann. Ich wollte eigentlich nichts per Hand ändern.
Warum sollte es am Surface tablet liegen, da ist ja auch Windows drauf, das sollte sich doch immer gleich verhalten?
90% Windows? Das gilt für Windows Netzwerke?
Keine Erfahrung damit ist seltsam? Dafür bin ich ja jetzt hier
Nee, bisher hatte ich wenig mit Windows zu tun. Selbst in den Microsoft data centers ist ca die Hälfte Linux, bei embedded ist Windows (CE) auch endlich ziemlich tot (nur bank Automaten haben noch Windows XP
). Und damals am der Uni hatten wir auch nur HP UX, SUNOS und Irix. Mein Telefon hat auch Linux. Windows benutze ich, um die Spiele zu starten Ja, IKEv2 ist auf beiden Seiten ausgewählt. Der automatische Modus sollte ja nichts einstellen, was er nicht kann. Ich wollte eigentlich nichts per Hand ändern.
Ja, ich muss vielleicht selbst udp encap einstellen, sowas gibt es immerhin. Schade, dass der wizard nix taugt, bezahlt man Lizenz und machts dann auch selbst...
Port Weiterleitungen habe ich nicht, warum sollte ich welche brauchen, das ist doch gerade der Vorteil von https tunneling? Und das https hat ja funktioniert. Wenn bei https tunneling noch andere ports gebraucht würden, trifft "Tunnel" aber nicht, finde ich.
Ich fürchte, man muss das auf beiden Seiten selbst einstellen, ich glaube, es ist gar kein https Tunnel.
Ja klar hilft ein trace, ich bin vermutlich nur durch leistungsfähigere Werkzeuge verwöhnt. Aber gute Meldungen in Logs zu schreiben (und nicht nur viele) ist aber auch eine wahre Kunst.
Port Weiterleitungen habe ich nicht, warum sollte ich welche brauchen, das ist doch gerade der Vorteil von https tunneling? Und das https hat ja funktioniert. Wenn bei https tunneling noch andere ports gebraucht würden, trifft "Tunnel" aber nicht, finde ich.
Ich fürchte, man muss das auf beiden Seiten selbst einstellen, ich glaube, es ist gar kein https Tunnel.
Ja klar hilft ein trace, ich bin vermutlich nur durch leistungsfähigere Werkzeuge verwöhnt. Aber gute Meldungen in Logs zu schreiben (und nicht nur viele) ist aber auch eine wahre Kunst.
Windows boardeigenen würde ich nur ungern ins Internet lassen, Windows wird ja leider sehr gern angegriffen, das klingt riskant.
Port Weiterleitungen habe ich nicht, warum sollte ich welche brauchen, das ist doch gerade der Vorteil von https tunneling? Und das https hat ja funktioniert. Wenn bei https tunneling noch andere ports gebraucht würden, trifft "Tunnel" aber nicht, finde ich.
Du sprichst von Doppel-NAT, also wie kommt dann die Anfrage vom Internet zum VPN-Router? Hängt der VPN-Router jetzt direkt im Internet und hat die öffentliche IP oder ist da noch ein NAT-Gerät vor? Wenn da ein NAT-Gerät vor ist, benötigst du selbst verständlich auf diesem eine Portweiterleitung auf den VPN-Router.
Ist denn XAuth aktiv bei dir?
Doppel NAT bei manchen AP und nur clientseitig (geht aber auch mit einfach NAT nicht, ohne NAT kann ich nicht testen). Der lancom ist nicht hinter NAT (der macht NAT für das Netz dahinter). Laut log gibt's xauth. (Xauth kenne ich von x11, aber das heißt vermutlich nur zufällig gleich). Https aufs web front end geht.
Meine Frage zu doppel NAT war, warum das per Voreinstellung nicht geht (falls dem überhaupt so ist), das ist im Mobilfunk Netz nicht besonders ungewöhnlich, oder in Hotels, das hätte ja schon mal jemand bemerken müssen.
Meine Frage zu doppel NAT war, warum das per Voreinstellung nicht geht (falls dem überhaupt so ist), das ist im Mobilfunk Netz nicht besonders ungewöhnlich, oder in Hotels, das hätte ja schon mal jemand bemerken müssen.
Was besagt denn ein vpn status- sowie ein vpn ike-Trace des Router? Bisher sehe ich nur die Logs (vielleicht) vom VPN-Client oder du hast die traces umformatiert. Ich selbst nutze den LANCOM Client nicht, daher vermute ich, dass es die Logs vom Client sind.
Kurzes Update:
- Frohe Weihnachten noch!
- Lancom mit UDP encap konnte ich noch nicht testen
- OpenVPN funktioniert einfach nur, war schnell und einfach einzurichten (nach Tutorial)
ausführlicher:
Ich habe eine Hyper-V Linux Maschine erzeugt, nach einem Tutorial, dauerte zwei Minuten. Und ging nicht. Der erste Start scheiterte, weil der Wiederherstellungspunkt nicht gefunden werden könne (ja, erster Start halt?!). Irgendwo konnte man einen Fehlercode finden, den ich gegoogelt habe. Da hieß es denn, die Meldung sei einfach nur falsch, in Wirklichkeit läge es an Rechten. Als Lösung solle man die Maschine in einen anderen Ordner verschieben. Keiner wußte warum, aber es solle helfen. Tat es bei mir auch. Komisch.
Dann fix ein Linux installiert, leider ein paar Monate alt. Über 350 Patches! Da musste ich nochmal fast acht Minuten warten.
Endlich OpenVPN installiert, nach Tutorial drei Test-Zertifikate und .ovpns erstellt, kopiert, aufs Android Handy. Portforwarder im Lancom eingestellt. Android connect ging sofort. Also mit OpenVPN Installation vielleicht 10 Minuten. Hat Spaß gemacht.
Dann OpenVPN Client aufs MS Surface. Installation läuft druch, .ovpn Datei importiert und nichts geht. Stellt sich heraus, IPv6 wird nicht automatisch erkannt, also fest auf IPv4 gestellt. Auth klappt, aber tan device geht nicht. Per Hand anlegen auch nicht. Da gibts aber immerhin eine Fehlermeldung, und zwar dass Treibersignaturen erzwungen sind. OK, gegoogelt, wie man das abstellt. Gibt's ein Kommando. Das geht aber natürlich nicht, und zwar weil das beim Systemstart erzwungen wurde. Also Shift-Neustart und 7 oder sowas. Dann kam was von Updates. Ich habe nach einer halben Stunde aufgehört zu warten und bin was essen gegangen. Nachdem ich wieder da war, kam dann "Hallo? Wir machen nur schnell noch was" oder so und ich musste schon wieder warten! Warum macht das die Updates nicht komplett? Nein, muss man nach zwei Stunden kommen und auf nen Knopp drücken, damit es nochmal zwei Stunden rödelt. Egal, irgendwann war es wieder oben. Geht aber immer noch nicht, jetzt plötzlich wegen "secure boot". OK, google sagt, welche Tasten zu drücken sind, startet mit rotem Balken, aber Kommando geht, Treiber lässt sich installieren, tun Device lässt sich anlegen und zack! Tunnel ist da! Hat leider fast den ganzen Tag gedauert, vor allem wegen der Updates.
Interessant ist, dass nach Aktivierung von Secure Boot der Treiber immer noch geht. Super. Genau davor soll das doch schützen? Wenn das Zimmermädchen einen Trojanertreiber installiert und das so machen kann, dass man es dann nicht merkt, wenn sie am Ende secure boot einfach wieder anschaltet, ist das doch vollkommen nutzlos.
Weiß jemand was dazu? Sollte ich ne neue Frage stellen?
Dann abend zu Hause noch mal probieren wollen, macht das Teil schon wieder Updates! Abendbrotesszeit hat nicht gereicht, es dauerte länger. Bin dann ins Bett. Irgendwie mag mich das Windows nicht
Am nächsten Tag nochmal getestet, scheint alles richtig zu funktionieren. Auch hinter Doppel-NAT (OpenVPN macht standardmässig UDP encap).
Ja, jetzt hab ich meine drei Test OpenVPN Geräte am Laufen. 300 Euro gespart. Gut, NSA Backdoor fehlt dafür vermutlich, da kann ich mit leben.
Ich glaube, ich lasse das jetzt so.
Welche Nachteile hat das? Ich war überrascht, dass das so schnell und einfach geht, warum macht man das dann nicht immer so? Stabilität muss sich zeigen; die Lancoms laufen bei mir superstabil. OpenVPN kenn ich nur eine größere Installation und da können die Clients automatisch reconnecten (ich weiß also nicht, ob die Tunnel immer stehen). Der Server lief jedenfalls jahrelang ohne Probleme.
Per default werden die Clients vom OpenVPN Server IP-maskiert, das ist einfach, praktisch aber funktioniert nicht für alle Protokolle. Ich brauchte aber nur RDP und SSH. Kann man bestimmt konfigurieren, wenn man möchte.
Ich hoffe, ich finde nochmal Zeit, die Lancom-Lösung mit händisch eingestellten UDP Encap zu testen, ob das dann funktioniert, falls mal jemand das gleiche Problem hat.
- Frohe Weihnachten noch!
- Lancom mit UDP encap konnte ich noch nicht testen
- OpenVPN funktioniert einfach nur, war schnell und einfach einzurichten (nach Tutorial)
ausführlicher:
Ich habe eine Hyper-V Linux Maschine erzeugt, nach einem Tutorial, dauerte zwei Minuten. Und ging nicht. Der erste Start scheiterte, weil der Wiederherstellungspunkt nicht gefunden werden könne (ja, erster Start halt?!). Irgendwo konnte man einen Fehlercode finden, den ich gegoogelt habe. Da hieß es denn, die Meldung sei einfach nur falsch, in Wirklichkeit läge es an Rechten. Als Lösung solle man die Maschine in einen anderen Ordner verschieben. Keiner wußte warum, aber es solle helfen. Tat es bei mir auch. Komisch.
Dann fix ein Linux installiert, leider ein paar Monate alt. Über 350 Patches! Da musste ich nochmal fast acht Minuten warten.
Endlich OpenVPN installiert, nach Tutorial drei Test-Zertifikate und .ovpns erstellt, kopiert, aufs Android Handy. Portforwarder im Lancom eingestellt. Android connect ging sofort. Also mit OpenVPN Installation vielleicht 10 Minuten. Hat Spaß gemacht.
Dann OpenVPN Client aufs MS Surface. Installation läuft druch, .ovpn Datei importiert und nichts geht. Stellt sich heraus, IPv6 wird nicht automatisch erkannt, also fest auf IPv4 gestellt. Auth klappt, aber tan device geht nicht. Per Hand anlegen auch nicht. Da gibts aber immerhin eine Fehlermeldung, und zwar dass Treibersignaturen erzwungen sind. OK, gegoogelt, wie man das abstellt. Gibt's ein Kommando. Das geht aber natürlich nicht, und zwar weil das beim Systemstart erzwungen wurde. Also Shift-Neustart und 7 oder sowas. Dann kam was von Updates. Ich habe nach einer halben Stunde aufgehört zu warten und bin was essen gegangen. Nachdem ich wieder da war, kam dann "Hallo? Wir machen nur schnell noch was" oder so und ich musste schon wieder warten! Warum macht das die Updates nicht komplett? Nein, muss man nach zwei Stunden kommen und auf nen Knopp drücken, damit es nochmal zwei Stunden rödelt. Egal, irgendwann war es wieder oben. Geht aber immer noch nicht, jetzt plötzlich wegen "secure boot". OK, google sagt, welche Tasten zu drücken sind, startet mit rotem Balken, aber Kommando geht, Treiber lässt sich installieren, tun Device lässt sich anlegen und zack! Tunnel ist da! Hat leider fast den ganzen Tag gedauert, vor allem wegen der Updates.
Interessant ist, dass nach Aktivierung von Secure Boot der Treiber immer noch geht. Super. Genau davor soll das doch schützen? Wenn das Zimmermädchen einen Trojanertreiber installiert und das so machen kann, dass man es dann nicht merkt, wenn sie am Ende secure boot einfach wieder anschaltet, ist das doch vollkommen nutzlos.
Weiß jemand was dazu? Sollte ich ne neue Frage stellen?
Dann abend zu Hause noch mal probieren wollen, macht das Teil schon wieder Updates! Abendbrotesszeit hat nicht gereicht, es dauerte länger. Bin dann ins Bett. Irgendwie mag mich das Windows nicht
Am nächsten Tag nochmal getestet, scheint alles richtig zu funktionieren. Auch hinter Doppel-NAT (OpenVPN macht standardmässig UDP encap).
Ja, jetzt hab ich meine drei Test OpenVPN Geräte am Laufen. 300 Euro gespart. Gut, NSA Backdoor fehlt dafür vermutlich, da kann ich mit leben.
Ich glaube, ich lasse das jetzt so.
Welche Nachteile hat das? Ich war überrascht, dass das so schnell und einfach geht, warum macht man das dann nicht immer so? Stabilität muss sich zeigen; die Lancoms laufen bei mir superstabil. OpenVPN kenn ich nur eine größere Installation und da können die Clients automatisch reconnecten (ich weiß also nicht, ob die Tunnel immer stehen). Der Server lief jedenfalls jahrelang ohne Probleme.
Per default werden die Clients vom OpenVPN Server IP-maskiert, das ist einfach, praktisch aber funktioniert nicht für alle Protokolle. Ich brauchte aber nur RDP und SSH. Kann man bestimmt konfigurieren, wenn man möchte.
Ich hoffe, ich finde nochmal Zeit, die Lancom-Lösung mit händisch eingestellten UDP Encap zu testen, ob das dann funktioniert, falls mal jemand das gleiche Problem hat.
die Lancoms laufen bei mir superstabil.
Ciscos rennt noch superstabiler. Solche nichtssagenden Ausagen sind wie immer relativ... Per default werden die Clients vom OpenVPN Server IP-maskiert,
Was meinst du mit "maskiert" ?? Das ist unverständlich und verwirrend. Solltest du damit NAT meinen (IP Adress Translation) irrst du so oder so denn OVPN macht kein NAT im Tunnel. Siehe auch:Merkzettel: VPN Installation mit OpenVPN
Zitat von @aqui:
die Lancoms laufen bei mir superstabil.
Ciscos rennt noch superstabiler. Solche nichtssagenden Ausagen sind wie immer relativ... Ja, natürlich ist das relativ. Relativ zur Stablität von Planetenbahnen ist es natürlich nicht sehr stabil, weil es keine tausend Jahre hält.
Relativ zu IT Systemen ist es sehr stabil, weil es monatelang ohne Störungen läuft.
(wenn Cisco monatelang durchläuft, wurden aber etliche Backdoor-Patches verpasst :D SCNR)
Per default werden die Clients vom OpenVPN Server IP-maskiert,
Was meinst du mit "maskiert" ?? Das ist unverständlich und verwirrend. Solltest du damit NAT meinen (IP Adress Translation)Ja, mit "maskiert" meine ich N:1 SNAT auf die IP des sendenden Interfaces des Routers, das damit strenggenommen ein Port und Network translate ist und daher auch manchmal auch PAT,NPAT oder NAPT genannt wird, ganz früher auch "address hiding".
Siehe auch Wikipedia.
Was findest Du daran unverständlich und verwirrend?
irrst du so oder so denn OVPN macht kein NAT im Tunnel. Siehe auch:
Merkzettel: VPN Installation mit OpenVPN
Merkzettel: VPN Installation mit OpenVPN
Tja, also bei mir schon ¯\_(ツ)_/¯ (sonst hätte ich ja auch eine "Rückroute" anlegen müssen):
root@host:~# iptables -t nat -nvL POSTROUTING
Chain POSTROUTING (policy ACCEPT 12180 packets, 945K bytes)
pkts bytes target prot opt in out source destination
0 0 SNAT all -- * * 10.8.0.0/24 !10.8.0.0/24 to:192.168.x.y
root@host:~# ip addr list tun0|grep 10\.8\.0
inet 10.8.0.1/24 brd 10.8.0.255 scope global tun0Wird gesetzt in /etc/systemd/system/openvpn-iptables.service.
Relativ zur Stablität von Planetenbahnen ist es natürlich nicht sehr stabil
Und auch die sind ja wieder relativ zum Universum gesehen nicht stabil... 😀Ja, mit "maskiert" meine ich N:1 SNAT auf die IP des sendenden Interfaces des Routers
Sowas ist natürlich immer völliger Quatsch und sollte man nie machen. Wozu auch ?? Auf eigenen lokalen IP Netzen muss man ja nicht NATen. Den überflüssigen Unsinn solltest du also besser lassen. Kostet unnötig Performance, verkompliziert das Management und ist sinnfrei, denn welchen Vorteil sollte das haben ?Sowas ist natürlich immer völliger Quatsch und sollte man nie machen.
"immer" und "nie" sind aber harte Worte. Man soll doch nie "nie" sagen
verkompliziert das Management und ist sinnfrei, denn welchen Vorteil sollte das haben ?
Der Vorteil ist, das das Management im LAN ganz einfach bleibt, weil das von dem ganzen VPN nichts sieht. Es gibt dem (virtuellen) VPN Server eine IP über DHCP und das wars. Nicht mal eine Rückroute muss man stetzen, der VPN server kann sogar ne dynamische lease nehmen, was Arbeit sparen könnte, wenn man ihn zb verschiebt oder morgen fünf davon hat. Die VPN clients können auch pool IPs nutzen und sich in beliebigen VPN gateway einwählen, es geht immer und belastet die DHCP Range nicht (hier sind alles nur C Netze mit zb 70 dynamischen DHCP IPs). Für mobil Geräte (Handys) praktisch.
