Hallo Netzwerk-Fachleute! Beim Versuch, die VPN-Verbindung herzustellen, kommt immer der berühmte und "vielsagende" Fehler "619". Ausgangssituation: Server: Synology DS216j, Konto eingerichtet, VPN-Server (PPTP) gestartet, alle Einstellungen nach https://www.synology.com/de-de/knowledgebase/DSM/help/VPNCenter/vpn_setup durchgeführt. DDNS mit der DS216j und *.synology.me Client: Laptop MEDION AKOYA, Win8.1, VPN eingerichtet mit PPTP. Router: Port 1723 durchgereicht Ausprobiert: Mit und ohne Firewall. Geht weder über Mobile noch WLAN zu Hause. IP-Adresse manuell eingegeben, ohne DDNS. Geht alles nicht. Da die Fehlermeldung so nichtssagend ist, wollte ich fragen, ob es noch Möglichkeiten gibt, das Problem einzugrenzen. Wireshark? Ping geht, 70-80ms Response-Time. Danke und Gruss Chregu
PPTP ist nicht mehr zeitgemäß. Steige um auf IPSec, oder von mir aus wenn es denn unbedingt sein muß, auf OpenVPN.
Christian M. schrieb: > Router: Port 1723 durchgereicht Reicht nicht, Du musst auch noch das Protokoll GRE durchreichen. Allerdings: PPTP gilt aus gutem Grund als angezählt und wird von etlichen neueren Clients auch nicht mehr unterstützt.
Rufus Τ. F. schrieb: > auch noch das Protokoll GRE durchreichen Habe noch nie einen Router gesehen, der ein anderes Protokoll als TCP und UDP hatte... Gerd E. schrieb: > PPTP ist nicht mehr zeitgemäß. Steige um auf IPSec Rufus Τ. F. schrieb: > PPTP gilt aus gutem Grund als angezählt Werde dann auf IPSec umsteigen. Da ich ja nicht mehr zu Hause bin, muss ich irgendwie meine Frau dazu bringen, den Router entsprechend einzustellen. Fürchte, das wird eine Zangengeburt... Gruss Chregu
Christian M. schrieb: > Habe noch nie einen Router gesehen, der ein anderes Protokoll als TCP > und UDP hatte... u.a. Fritzboxen können das schon immer, und auch in DLink-Geräten habe ich die Option schon verwendet. Damals, als ich auch noch PPTP nutzte. > Da ich ja nicht mehr zu Hause bin, muss ich irgendwie meine Frau dazu > bringen, den Router entsprechend einzustellen. Manche Router kann man via https aus dem Internet administrieren, wenn mans freischaltet, oder Du könntest Deine Frau dazu überreden, ausnahmsweise mal einen Teamviewer zu verwenden. Beides dürfte am Telephon leichter verhandelbar sein, als eine komplette Blindflug-ich-diktiert-Dir-was-Du-wo-einstellen-musst-Orgie.
Rufus Τ. F. schrieb: > aus dem Internet administrieren, wenn > mans freischaltet Habe ich ja eben nicht! :-(( Rufus Τ. F. schrieb: > einen Teamviewer zu verwenden Ja, gute Idee. Soviel ich weiss, muss man da keine Ports freischalten. Sonst verwende ich VNC, aber da muss man freischalten... Gruss Chregu
Christian M. schrieb: > Habe noch nie einen Router gesehen, der ein anderes Protokoll als TCP > und UDP hatte... Ich hingegen bin mir recht sicher, dass du noch nie einen TCP/IP Router gesehen hast, der kein anderes Protokoll drauf hatte. ICMP sitzt zwingend als drittes Protokoll neben TCP und UDP oberhalb IP.
:
Bearbeitet durch User
Christian M. schrieb: > Habe noch nie einen Router gesehen, der ein anderes Protokoll als TCP > und UDP hatte... Dann hast du praktisch noch nix gesehen, was auch nur andeutungsweise tauglich als VPN-Router wäre... > Werde dann auf IPSec umsteigen. Das ist keinesfalls einfacher, eher genau das Gegenteil. Während bei PPTP ziemlich eng definiert ist, was Initiator und Responder zu tun haben, ist IPSEC ein regelrechter Riesen-Zoo von verwendbaren Protokollen in tausenden von Varianten ihrer Nutzung (reicht 10^3? Ich bin da jetzt nichtmal sicher, es könnte auch Größenordnung 10^4 sein...). U.a. wird z.B. ggf. auch ESP verwendet, natürlich sogar in zwei Varianten, eine hat mal wieder nicht gereicht... Wie auch immer: ESP ist jedenfalls ein Protokoll auf genau derselben Ebene wie GRE. D.h.: Wenn dein verschissener Router kein GRE forwarden kann, kann er mit einiger Wahrscheinlichkeit ESP genausowenig... Kurzfassung: Kauf' dir zumindest einen tauglichen Router! Und wenn du tatsächlich ein IPSEC-VPN einrichten willst: kauf dir jemanden ein, der weiss, was er tut und das für dich einrichtet. Tatsache ist nämlich: man kann problemlos ein IPSEC-VPN einrichten, was noch wesentlich unsicherer ist als das (zu Recht) als praktisch geknackt betrachtete PPTP. Das ist tatsächlich leider sogar sehr viel einfacher, als ein sicheres IPSEC-VPN einzurichten. Und gewöhnlich ist es genau das, was rauskommt, wenn es Leute einrichten, die nicht wissen, was sie da eigentlich tun. Naja, falls sie überhaupt etwas zum Laufen bekommen. Die Chancen stehen sowieso eher schlecht...
c-hater schrieb: > Kurzfassung: Kauf' dir zumindest einen tauglichen Router! Und wenn du > tatsächlich ein IPSEC-VPN einrichten willst: kauf dir jemanden ein, der > weiss, was er tut und das für dich einrichtet. na komm, jetzt übertreibst Du aber, so eine Geheimwissenschaft ist das nicht. > Tatsache ist nämlich: man kann problemlos ein IPSEC-VPN einrichten, was > noch wesentlich unsicherer ist als das (zu Recht) als praktisch geknackt > betrachtete PPTP. Die Aussage halte ich für gewagt. Sagen wir mal Du lässt die Finger vom Aggressive Mode, richtest nur eine einzige Verbindung ein und Deine VPN-Software hat eine sinnvolle Voreinstellung bezüglich der Proposals (z.B. AES, SHA2, DH-Modp >= 2048 Bit). Was soll dann wesentlich unsicherer als PPTP werden?
IPSec ist mehr zu Koppelung von netzen, für einen einzelnen PC ist es nicht Ideal. Das ist PPTP besser geeignet - leider aber nicht mehr sicher. Es gibt aber die Kombination aus beiden. L2TP, da wird per IPSec verschlüsselt und darüber für PPTP gemacht. Die Serverseite ist etwas komplizierter einzurichten (IPSEC + PPPD) aber auf der Client-Seite ist das Standard - man muss nur der Assistent für VPN Verbindungen aufrufen.
Peter II schrieb: > IPSec ist mehr zu Koppelung von netzen, für einen einzelnen PC ist es > nicht Ideal. Das würde ich jetzt nicht sagen. Nur weil Microsoft zu blöd ist einen gescheiten IPSec-Client zu programmieren, heißt daß jetzt nicht daß IPSec dafür nicht geeignet wäre. Unter Windows musst Du halt einen extra Client installieren. Z.B. den Shrew oder NCP.
Ich bin da ganz bei Peter II, IPSec ist recht um zwei Netze miteinander zuverbinden Box to Box, zur Einwahl in ein Netz kann man IPSec zwar durchaus auch verwenden, aber es ist hat aufwendiger. Nicht jede Fireall lässt die Ports für IPSec durch und es ist nicht unbedingt leicht zu debuggen. Gerd E. schrieb: > wenn es denn unbedingt sein muß, auf OpenVPN. Was spricht denn gegen OpenVPN? Ich kenne und schätze OpenVPN nun schon seit einigen Jahren und hatte nie wirklich Probleme damit.
Also ich weiß ja nicht. IPSEC VPN ist das Maß aller Dinge. Mit vernünftigen Geräten und Software ist da auch nichts schwierig zu debuggen. Für Client to Site VPN ist SSL VPN auch gut und halbwegs verbreitet, jedoch soviel ich weiß, meistens proprietär. Vor Allem PPTP (weil unsicher) und L2TP over IPSEC ist nicht so meins. OpenVPN hat bei mir irgendwie auch so einen "Billigheimer" Bastellösungsstatus. Im Enterprise Bereich wird VPN aber ohnehin immer mehr durch andere Zugriffsarten abgelöst. Der Cloud und der dahingehenden Ausrichtung der Hersteller und Produktdesigns "sei Dank".
:
Bearbeitet durch User
Ja jetzt bin ich verunsichert! Vor ein paar Jahren lief das mal ausgezeichnet, auf Anhieb! Aber Server war auch Windows-Rechner. Router war aber ein D-Link DI-524: https://www5.unitymedia.de/content/dam/unitymedia-de/assets-de/pdf/ume/di-524-benutzerhandbuch.pdf Interessant ist Seite 35 PPTP auch nur mit TCP freigegeben. Ich bin jetzt aber hier in der Schweiz auf Arbeit bis wenigstens Weihnachten. Wollte an meinen Projekten arbeiten, und das wäre halt viel bequemer über VPN gegangen. Aber ich habe ja über das Web-Interface Zugang zu meinen Daten, nur halt ein bisschen aufwändiger. Ich dachte, ich könnte die Verbindung einfach debuggen, vielleicht hängt es ja schon beim Router hier (Hotel)... Gruss Chregu PS: Kann jemand einen guten Router für solche Sachen empfehlen?
Christian M. schrieb: > Interessant ist Seite 35 PPTP auch nur mit TCP freigegeben. Rufus Τ. F. schrieb: > Christian M. schrieb: >> Router: Port 1723 durchgereicht > > Reicht nicht, Du musst auch noch das Protokoll GRE durchreichen. Weiterleitung von Port 1723 genügt. GRE läßt sich gar nicht "durchreichen", weil es keine Ports verwendet. Richtig ist aber, daß der Router damit gescheit umgehen können muß. Jeder halbwegs moderne sollte dies allerdings beherrschen. Christian M. schrieb: > Kann jemand einen guten Router für solche Sachen empfehlen? LANCOM. Die Preise werden dir aber nicht gefallen. Gebraucht manchmal günstig zu bekommen. Was läuft denn WAN-seitig bei dir? DSL, Glasfaser, Kabel?
Christian M. schrieb: > PS: Kann jemand einen guten Router für solche Sachen empfehlen? Lancom wurde schon genannt. Ist recht komplex wenn man einmal den Wizard verlässt. Preise eher gehobenes Niveau. Ist sonst aber solide. Wenn es billiger sein soll, gäbe es noch die Zyxel Zywalls. Die haben keine integrierten Modems, du brauchst also noch ein ADSL/VDSL-Modem dazu. Ansonsten gäbe es als Alternative noch die Variante einen alten PC zu nehmen oder einen Mini-PC dafür zusammenzustellen und da pfSense drauf zu installieren. Auch hier brauchst Du noch ein ADSL/VDSL-Modem dazu. Wenn Dein bisheriger Router sich nicht in einen Nur-Modem-Modus schalten lässt, würde ich zu einem separaten Modem raten und nicht empfehlen zu versuchen das mit biegen und brechen per Portforwarding umsetzen zu wollen.
Icke ®. schrieb: > Weiterleitung von Port 1723 genügt. GRE läßt sich gar nicht > "durchreichen", weil es keine Ports verwendet. Was soll das mit Ports zu tun haben? GRE-Traffic wird an einen Host hinter dem Router weitergeleitet, und welcher das ist, wird in der Administrationsoberfläche des Routers konfiguriert.
Ich würde jetzt mal Teamviewer nehmen. Da schaut wenigstens höchstens der Hersteller von Teamviewer zu und nicht die ganze Welt wie bei PPTP. Im privaten Umfeld sind wohl die Fritzboxen beliebt und gut und können wohl auch IPSEC VPN. Anleitungen zum Einrichten wirst du wegen der Verbreitung auch zu Hauf finden. PPTP würde ich umgehend aufhören zu nutzen. Da kannst du gleich unverschlüsselt arbeiten. Gruß
Rufus Τ. F. schrieb: > Was soll das mit Ports zu tun haben? GRE-Traffic wird an einen Host > hinter dem Router weitergeleitet, und welcher das ist, wird in der > Administrationsoberfläche des Routers konfiguriert. Die Weiterleitung des GRE-Protokolls wird i.d.R. mit dem Forwarding des Ports 1723 automatisch gehandelt. Also gibt es normalerweise nur Einstellmöglichkeiten für TCP und UDP. Wie ich gerade gesehen habe, scheint AVM da jedoch wieder sein eigenes Süppchen zu kochen. Insofern muß ich dir in Bezug auf Fritzboxen Recht geben.
Gerd E. schrieb: > Auch hier brauchst Du noch ein ADSL/VDSL-Modem dazu. Das Modem ist eh separat von der Telecom-Firma. Ueber Fernseh-Kabel. 50Mb/s up UND down! Der "Router" muss nur noch PPPoE machen. Icke ®. schrieb: > LANCOM. Die Preise werden dir aber nicht gefallen. Schluck. Ja. Gruss Chregu
Angehängte Dateien:
-
GRE.jpg
98 KB
Bei der FritzBox kann man durchaus GRE weiterleiten... Für die Setups, die ich mit IPSec am laufen habe, hat es immer gereicht Port 4500 und 500 UDP an den VPN-Server weiterzuleiten. Wie schon erwähnt gibt es viele Firewalls bei denen diese Ports geblockt sind. Lucas N. schrieb: > Also ich weiß ja nicht. > IPSEC VPN ist das Maß aller Dinge. Mit vernünftigen Geräten und Software > ist da auch nichts schwierig zu debuggen. IPSec hat immer den Ruf so komplex zu sein, das es duch die komplexität potemtiell unsicher ist. >Für Client to Site VPN ist SSL > VPN auch gut und halbwegs verbreitet, jedoch soviel ich weiß, meistens > proprietär. Ja, weil man nur einen Port braucht, oft einen Port nehmen kann, den die meisten Firewalls sowieso freigeben und man kann es hinter Proxyservern verwenden. Von OpenVPN gibt es auch einige komerzielle Versionen, deren Namen mir nicht einfallen. Ansonsten ganz klar Cisco hat da auch was im Portofolio mit AnyConnect. > OpenVPN hat bei mir irgendwie auch so einen "Billigheimer" > Bastellösungsstatus. Es ist OpenSource, die IPSec-Implementierung auf vielen Routern, die ein OpenSource Betriebssystem verwenden wird OpenSource sein. Und nur weil es zu einer Software keine offenen Quellen gibt, muss diese ja nicht automatisch sicherer sein.
Lucas N. schrieb: > Im privaten Umfeld sind wohl die Fritzboxen beliebt und gut und können > wohl auch IPSEC VPN. Anleitungen zum Einrichten wirst du wegen der > Verbreitung auch zu Hauf finden. Von VPN mit Fritzboxen kann ich nur abraten. Fritzboxen mögen ihre Stärken haben, aber bei VPN liegen die garantiert nicht. - Für die Syntax der Konfigurationsdateien gibt es keine Referenzdokumentation, nur ein paar Beispiele, aus denen man sich dann zusammenreimen darf wie das gedacht ist - Wenn man nicht wirklich aufpasst, bekommt man den Aggressive Mode. Der ist nicht mehr zeitgemäß, da er keinen Diffie-Hellman-Austausch enthält und damit die Authentifizierung mitgeschnitten und hinterher per brute force geknackt werden kann - Keine Unterstütztung von Zertifikaten, nur Pre-Shared-Key - Die Konfiguration geht erfahrungsgemäß manchmal nach einiger Zeit kaputt. Also die Fritzbox enthält noch die Konfiguration so wie man sie gemacht hat, ein Verbindungsaufbau geht aber nicht mehr. Dann muss man die Konfiguration zurücksetzen, die Config noch mal neu einspielen und dann geht es wieder eine Weile. Irgendwann dann das selbe wieder von vorne. Habe ich selbst bei mehreren Geräten beobachtet, aber betrifft nicht alle, bei anderen geht es über Monate problemlos. Ich rate daher von VPN mit Fritzboxen ab.
Christian M. schrieb: > Das Modem ist eh separat von der Telecom-Firma. Ueber Fernseh-Kabel. > 50Mb/s up UND down! Der "Router" muss nur noch PPPoE machen. Oh, was für ein Kabelnetzprovider bietet denn Einwahl über PPPoE an? Das kannte ich bisher nicht. Normalerweise wird bei Kabel direkt per DHCP eine IP an den Router vergeben, also ohne zusätzliche PPP oder PPPoE-Schicht dazwischen.
Gerd E. schrieb: > Oh, was für ein Kabelnetzprovider bietet denn Einwahl über PPPoE an? http://www.rcs-rds.ro/ Gruss Chregu
Lucas N. schrieb: > IPSEC VPN ist das Maß aller Dinge. Mit vernünftigen Geräten und Software > ist da auch nichts schwierig zu debuggen. Bisschen Glück und rumprobieren kann freilich nötig sein. Wird einfacher, wenn man den betreffenden Typ von Gegenstelle schon mal dabei hatte, denn jede Implementierung hat ihre Eigenheiten. Mal gehts nur mit Proxy-IDs, mal nur ohne. Mancher kann IKEv2, mancher nicht, oder SHA-2 nur bei IKEv2, was wiederum aus irgendeinem anderen Grund nicht geht. Oder genau eine Strecke fliegt bei bestimmten Wartungsaktivitäten zuverlässig raus, alle anderen hingegen nicht. Und mal bringt alles Debugging nichts, weil der Hersteller mit einem der letzten Patches einen Bug eingebaut hat und im Debugging alles perfekt aussieht, nur dass da dann sowas wie "1!=1, fail" drin steht. > Für Client to Site VPN ist SSL > VPN auch gut und halbwegs verbreitet, jedoch soviel ich weiß, meistens > proprietär. Bei Enterprise-Firewalls gibts öfter auch SSL statt IPSEC für die Client-Connections, oder beides. Wobei ich auf einer Strecke mit DS-lite bei IPSEC Probleme habe, bei SSL nicht. Bei SSL muss man freilich ziemlich fix dabei bleiben, da liefen die letzten Jahre recht viele Sicherheitsprobleme auf.
:
Bearbeitet durch User
Gerd E. schrieb: > Das würde ich jetzt nicht sagen. Nur weil Microsoft zu blöd ist einen > gescheiten IPSec-Client zu programmieren, heißt daß jetzt nicht daß > IPSec dafür nicht geeignet wäre. > > Unter Windows musst Du halt einen extra Client installieren. Z.B. den > Shrew oder NCP. welche Probleme hast du mit dem VPN Client von MS? Das Problem ist ein generelles das es bei IPSec keine "Einwahl" gibt. Es gibt auch keine Private IpAdresse im Host-Host Modus. L2TP ist schon gut umgesetzt. Es wird eine Host-Host Verbindung mit IpSec aufgebaut ohne das dabei Extra Ip-Adresse verwendet werden. Darüber erfolgt dann die Einwahl per PPP. Dort bekommt man dann eine IP aus dem Firmennetz. Man hat die Doppelte Sicherheit. Einmal braucht man das Zertifikat und dann noch Usernane und Passwort.
Peter II schrieb: > welche Probleme hast du mit dem VPN Client von MS? > > Das Problem ist ein generelles das es bei IPSec keine "Einwahl" gibt. Es > gibt auch keine Private IpAdresse im Host-Host Modus. Alle gescheiten VPN-Client kennen das Konzept der virtuellen IP, die entweder fest im Client eingestellt wird (eher seltener verwendet), oder üblicherweise per Mode Config dem Client zugewiesen wird. Der Client von Microsoft für IKEv1 kann das (neben vielen anderen Dingen) nicht. Erst der "Agile VPN Client" von Microsoft für IKEv2 ist da etwas besser. Aber auch der erfordert einige Sonderlocken und unterstützt z.B. keine DH-Gruppen mit Modp > 1024 wenn man nicht speziellen Registry-Keys setzt. Das geht aber wiederum wohl nur unter Win 10 und nicht vorher. Siehe z.b. hier: https://github.com/trailofbits/algo/issues/9 > L2TP ist schon gut umgesetzt. Nö, das ist unnötigerweise doppelt gemoppelt und fügt zusätzlichen Overhead hinzu, IPSec alleine hat alles was Du brauchst. Nur hat Microsoft es damals nicht hinbekommen normales IPSec umzusetzen oder sie wollten unbedingt was eigenes, inkompatibles machen. Daher haben die sich dann das L2TP ausgedacht.
kann das mikrotik zeug ipsec? router mit tomato, openwrt oder ddwrt? wenn ein rechner 24/7 läuft ist pfsense eine möglichkeit oder opnsense oder die virtuelle sophos utm appliance, die aus dem astaro-gedöns hervorgegangen ist. IPSEC oder SSL VPN sind die "ways to go". Alles andere ist mehr oder weniger halbseidener Mist. Wissen was man tut, sollte man aber in jedem Fall.
Lucas N. schrieb: > kann das mikrotik zeug ipsec? weiß ich nicht sicher, habe ich bisher nicht ausprobiert. > router mit tomato, openwrt oder ddwrt? Kein Problem, einfach das strongswan-Paket installieren und loslegen. Bei höheren Bandbreiten kommen viele von den Dingern allerdings an ihre Grenzen. Der TO hat ja von 50 MBit symmetrisch geschrieben, ob das dann mit so nem kleinen Prozessor auch durchs VPN geht weiß ich nicht. Manche haben einen Hardware-Cryptobeschleunigung drin, da geht evtl. etwas mehr. Kleine PCs, z.B. mit Intel Baytrail J1900, schaffen so etwa 180MBit bei einer Verbindung mit AES128. Intel AES-Beschleunigung natürlich an.
Gerd E. schrieb: > Nur hat Microsoft es damals nicht hinbekommen normales IPSec umzusetzen > oder sie wollten unbedingt was eigenes, inkompatibles machen. Daher > haben die sich dann das L2TP ausgedacht. zu was inkompatible? PPP ist Standard und Ipsec auch. Einwahl klappt mit Linux und MAC - keine Ahnung was da inkompatible sein soll. Gerd E. schrieb: > Der Client von Microsoft für IKEv1 kann das (neben vielen anderen > Dingen) nicht. es steht sogar gleich in Wiki, das IPSec nicht geignet ist. > IKEv1 ist bei Verwendung von dynamischen IP-Adressen, wie bei > DSL-Anschlüssen üblich ist, wenig geeignet
Peter II schrieb: > Gerd E. schrieb: >> Nur hat Microsoft es damals nicht hinbekommen normales IPSec umzusetzen >> oder sie wollten unbedingt was eigenes, inkompatibles machen. Daher >> haben die sich dann das L2TP ausgedacht. > > zu was inkompatible? PPP ist Standard und Ipsec auch. Einwahl klappt mit > Linux und MAC - keine Ahnung was da inkompatible sein soll. > > Gerd E. schrieb: >> Der Client von Microsoft für IKEv1 kann das (neben vielen anderen >> Dingen) nicht. > > es steht sogar gleich in Wiki, das IPSec nicht geignet ist. > >> IKEv1 ist bei Verwendung von dynamischen IP-Adressen, wie bei >> DSL-Anschlüssen üblich ist, wenig geeignet Client to Site IPSEC VPN geht einwandfrei, auch mit dynamischen IPs und auch wenn man sich hinter einem NAT Device befindet. Sollte damit dann wohl auch mit CGN gehen. Reines IPSEC bekommt MS nicht hin oder sie wollen es nicht hinbekommen. Immer braucht man dieses dreckige L2TP dazu oder überhaupt PPTP. Mittlerweile können sie ja auch SSTP, was so etwas ist wie SSL VPN nur halt wieder proprietär und wieder mit PPTP würg.
:
Bearbeitet durch User
Gerd E. schrieb: > Nur hat Microsoft es damals nicht hinbekommen normales IPSec umzusetzen Ja, allerding haben sie schon für WindowsXP den IPSEC-Client eines Fremdanbieters eingekauft (Name fällt mir gerade nicht ein). Jedenfalls konnte man damit schon mit WindowsXP eine IPSEC-Verbindung aufsetzen, die durchaus den damaligen Sicherheitstandards entsprach. Es gab nur kein einfach zu bedienendes GUI für diesen Zweck. Dafür allerdings (im Gegensatz zum heutigen Stand des microsoftschen "Fortschritts") immerhin ein tatsächlich aussagefähiges Debug-Log... Allerdings war diese eingekaufte IPSEC-Implentierung darauf angewiesen, dass beide Peers eine feste IP-Adresse haben. Aber mit ein wenig Scripting konnte man dem Initiator die Konfiguration für seine gerade gültige öffentliche IP verpassen. In Frage kommende Responder waren damals ja sowieso nur *x-Maschinen mit fester IP, freier Konfiguration und sinnvollen Debug-Möglichkeiten. Oder Windows-Server, die den Scheiss natürlich von Haus aus genauso so gemacht haben, wie der Initiatior es erwartet hat... Und: im Prinzip ist es heute noch genauso. Microsoft hält sich mit der Dokumentation seines IPSEC-Clients extrem zurück, die ist praktisch völlig unbrauchbar. Genauso wie das Debug-Log. Da steht viele Seiten lang nur völlig räudiger Scheiss drin, der mit dem eigentlichen Problemen absolut garnix zu tun hat. Man ist darauf angewiesen, dass der Responder sinnvolle Debug-Möglichkeiten hat (und man damit auch etwas anfangen kann). Oder man kauft für viel Geld fertige Lösungen, die auch mit der Microsoft-Gülle von Haus aus umgehen können (weil bei deren Hersteller ein fähiger Programmierer diese MS-Scheisse analysiert hat). Besonders krass: IKEv2 mit Zertifikaten. Microsoft hat bis dato nicht einmal korrekt dokumentiert, wie deren Inhalt aussehen muss, damit ein Wixdos-Client bereit ist, sie zu akzeptieren. Das muss man sich mühsam selber ausklingeln. Hier haben diese Wichser wieder alle Register gezogen, um die Sache zwar formal standardgerecht zu halten, aber trotzdem möglichst alle auszusperren. Das ganz klassische MS-Schema der Besitzübernahme eines Standards in Reinkultur...
c-hater schrieb: > Besonders krass: IKEv2 mit Zertifikaten. Microsoft hat bis dato nicht > einmal korrekt dokumentiert, wie deren Inhalt aussehen muss, damit ein > Wixdos-Client bereit ist, sie zu akzeptieren. komisch, ich habe sie einfach mit openssl erstellt und dann unter Windows Importiert und es hat funktioniert. Musste dabei nicht rumprobieren. Das gleiche Zertifikat geht auch unter Linux.
Peter II schrieb: > komisch, ich habe sie einfach mit openssl erstellt und dann unter > Windows Importiert und es hat funktioniert. Zeige die Kommandozeile(n), die du zur Erstellung des "Serverzertifikats" (eigentlich: Responderzertifikats) benutzt hast. Und ich sage dir, ob du ein Lügner bist... > Musste dabei nicht rumprobieren. Das geht nur, wenn man vorher weiss, wie das Zertifikat auszusehen hat. Genau das aber ist, was Microsoft verheimlicht. Heute weiss ich auch, wie ich mit openssl die passenden Zertifikate erzeugen kann. Diesen Wissensstand habe ich aber nur durch Probieren (naja, gezieltes Probieren nach Web-Recherche mit in einigen Punkten deutlich widersprüchlichen Ergebnissen) erreichen können. Am wenigsten hilfreich war dabei Microsoft selber. Von den Anbietern kommerzieller VPN-Lösungen war schon mehr an Doku zu verwerten, aber auch die haben immer etwas Entscheidendes verschwiegen und/oder in mindestens einem Punkt sogar etwas falsches angegeben. Glücklicherweise nicht alle jeweils das Gleiche ;o)
Angehängte Dateien:
-
cert.png
33 KB
c-hater schrieb: >> komisch, ich habe sie einfach mit openssl erstellt und dann unter >> Windows Importiert und es hat funktioniert. > > Zeige die Kommandozeile(n), die du zur Erstellung des > "Serverzertifikats" (eigentlich: Responderzertifikats) benutzt hast. Und > ich sage dir, ob du ein Lügner bist... kann ich leider nicht (mehr) machen, das war für meinen alten Arbeitgeber. der aufrufst sagt eh wenig aus, wichtig ist was in der conf für Openssl steht. Aber als Nachweis das ich nicht komplett Ahnungslos bin, ein Screenshot von meinen private CA. Wird aber nicht für VPN genutzt. wir hatte auch ein Root CA, davon abgeleitet dann ein Server CA für den VPN-Server und dann ein weiteres SUB-CA für die VPN-Clients. Jeder Mitarbeiter hat dann die P12 Datei erhalten und konnte sich mit L2TP einfach einwählen.
Peter II schrieb: > der aufrufst sagt eh wenig aus, wichtig ist was in der conf für Openssl > steht. Richtig. Sehr viel wird bei openssl über Umgebungsvariablen gesteuert, die letztlich aus der conf stammen. > Aber als Nachweis das ich nicht komplett Ahnungslos bin Das sagte mir bereits dein erster Satz. Ich stelle aber fest: Es ist so, wie ich sagte: von alleine stellt auch openssl keine passenden Zertifikate her. Man muss aktiv und (mangels brauchbarer Doku von MS) mit relativ viel Aufwand dafür sorgen, dass es das tut. Genau das wollte ich sagen. Capisce? In deinem Fall hat wohl irgendjemand bei deinem letzten AG für eine passende conf gesorgt. Das warst aber wohl nicht du selber...
c-hater schrieb: > In deinem Fall hat wohl irgendjemand bei deinem letzten AG für eine > passende conf gesorgt. Das warst aber wohl nicht du selber... ich habe das eingeführt und den Server aufgesetzt. Das gab es niemand anders. Aber was war schon ein paar Jahre her. Eventuell hat MS ja etwa geändert. Aber zu Win2k und Win7 ging es ohne Probleme. (Wobei man bei Win2k noch das High encrytion Pack installieren mussste)
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.