Neu ODBC Verbindung funktioniert nicht

[Specker]

Hi zusammen

Wir haben seit ein paar Tagen einen Windows 10 PC im Keller stehen, auf dem die Wawi Datenbank installiert ist. Auf diesem Rechner läuft nun auch permanent der Worker. Nun zu meiner Frage:

Ich möchte von unterwegs auf die Datenbank zugreifen. Möglichst ohne Teamviewer, wie wir es bisher gemacht haben.

Dafür habe ich eine ODBC Verbindung eingerichtet, allerdings wohl irgendwas im nächsten Schritt dann falsch gemacht.

Mit dem Rechner wurde nach dieser Anleitung vorgegangen:

https://guide.jtl-software.de/Datenbank-FAQ#ODBC-Verbindung_.28Datenbankverbindung.29

Habe auch über den Befehl netstat -an -b

die Portnummer ausgelesen, um sie manuell einzutragen bei Clientkonfiguration. (Unter dem Reiter System-DNS)

Danach habe ich dann unter eigene-ip.de meine IP Adresse ausgelesen und im nächsten Schritt dann ein neues Wawi Profil angelegt. Schätze mal hier ist irgendwo der Fehler.

Ich habe bei Server „meineIP\JTLWAWI“ angegeben und bekomme beim Anmelden mit dem Nutzer „sa“ die Fehlermeldung „error 26, Fehler beim Bestimmen des angegebenen Servers/ der angegebenen Instanz“.

Was läuft falsch bzw. was muss noch gemacht werden?


Wäre wirklich klasse wenn ihr mir da weiterhelfen könntet.

Gruß ans Forum - Ben

 

[Aze]

Hallo, mal mit „meineIP,1433\JTLWAWI“ probieren, bei mir ging das so.

mfg

 

[elevennerds.de]

Unter der Annahme, dass Du IPv4 mit einem privaten Adressbereich einsetzt: Du musst dafür sorgen, dass Du von außen an den Port kommst. VPN, Port-Forwarding vom Router oder ein Reverse-Tunnel sind mögliche Lösungen für das Problem.

MfG

Rene

 

[gutberle]

@Specker - Mit ODBC hat das alles überhaupt nichts zu tun und der Guide Link ist ein unglückliches Überbleibsel aus den 0.9er Tagen, denn die 1er Wawi benutzt überhaupt keine ODBC Verbindung - Siehe unten ...

Was @dropshipout hier drüber schreibt ist natürlich dennoch richtig, denn die Wahrscheinlichkeit, dass Du hinter Deinem Router einen privaten und damit nicht-routbaren Adressbereich (typisch 192.168.n.n) benutzt, ist ziemlich groß. Dann brauchst Du tatsächlich nicht nur ein "Loch" in Deiner Firewall, sondern muß Dir einen der von @dropshipout genannten Mechanismen einrichten, grundsätzlich einen Mechanismus, der in der Lage ist, eine Anfrage, die dann offiziell an einen Port auf Deinem Router gerichtet ist (denn nur der ist aus dem öffentlichen Netz erreichbar), "heimlich" weiterleitet auf einen Port Deiner Wahl auf Deinem nur intern erreichbaren Win10 DB-Rechner.

Das wäre dann eine Portfreigabe und die ist ohne große Kenne in allen modernen Routern leicht einrichtbar, hat aber den GROSSEN Nachteil, dass JEDER, aber auch absolut JEDER aus dem großen weiten Netz damit den Port 1433 Deines Wawi DB Servers erreichen kann. Das käme für mich NIE in Frage, weshalb ich Dir dringend raten würde, Dich mit VPN, z.B. OpenVPN zu beschäftigen. Entweder schon Dein Router beherrscht eine VPN Art (z.B. die omnipräsenten Fritzboxen) oder aber Du mußt hinter Router/Firewall eine VPN Server laufen lassen und dann zwar immer noch eine Portfreigabe oder beim (deutlich unsicheren PPTP sogar 2) einrichten, aber die laufen auf einen VPN Server Port und der ist deutlich weniger attackenanfällig als ein regulärer Anwendungsport.

Die Idee beim Reverse Tunneling ist eine Andere. Die Ports, die üblicherweise von Malware auf erreichbaren Servern geprobed werden, sind die IANA well known ports, also Ports, deren Bedeutung richtiggehend festgeschrieben ist, wie z.B. der Standard Port des MS SQL Servers 1433. Um Software mit solchen Ports betreiben zu können, ohne sich solchen Gefahren auszusetzen sind verschiedene Verfahren entwickelt worden, um Ports überhaupt erst bei Anforderung einer Verbindung zu öffnen. Beim Reverse Tunneling mit SSH fragt man beim Server eine Verbingung auf einem "abstrusen" Port an, auf den keine Malware kommen würde und der SSH Server baut bei korrekter Identifizierung auf diesem schrägen Port selbst eine Verbindung zu einem SSH Server auf, der wiederum auf einem schrägen Port auf Deinem PC "da draußen" läuft. Klingt kompliziert und ist es auch (nicht wirklich), aber das Ganze wird vor allem von Backdoors und anderer Malware benutzt und macht eigentlich nur dann Sinn, wenn Du Dich da draußen in Gegenden tummelst, in denen die loklen (Hotel...) Firewalls SSH Traffic blockieren, denn das ist die Idee, fehldende Firewall Löcher zu umgehen. Ich persönlich würde davon dringend abraten, denn im Gegensatz zu Port Forwarding und insbesondere VPN (!!!) ist das Ganze eher Hacker-Technologie und Du willst hier einen stinknormalen SQL Server hinter einer Firewall erreichen.

Ok, jetzt zurück zur Wawi: Sobald Du auf eine der genannten Arten und Weisen ein kleines oder großes, unsicheres (Port Forwarding) oder sicheres (VPN) Loch in Deine Firewall gehackt hast, bist Du schon fast auf der Wawi DB. Für VPN spricht hier auch, dass die gängigen VPN Clients (OpenVPN) völlig automatisch die korrekten Routen erzeugen und aktivieren. Du musst dann *überhaupt nichts* an Deiner ganz normalen Wawi Konfiguration schrauben, sondern der Client findet die DB, Punkt! Das ist beim Port Forwarding schon wieder anders, denn jetzt mußt Du der Wawi (Client) ja bekannt geben, dass die Wawi ~auch~ unter der Adresse des öffentlichen Interface Deines Routers erreichbar ist. Das ist auch nicht schwer, aber deutlich involvierter als VPN und da es auch noch deutlich unsicherer ist, verrate ich Dir auch erst gar nicht, wie das geht, denn Du solltest wirklich OpenVPN probieren, oder falls Deine Router eine Fritzbox ist, gerne auch die leicht erzeugbare VPN Verbindung mit dem Fritzbox VPN Client, das ist völlig schmerzfrei ...

 

[Specker]

Hallo, mal mit „meineIP,1433\JTLWAWI“ probieren, bei mir ging das so.

mfg

Gerade mal probiert, kommt leider auch ne Fehlermeldung.

Unter der Annahme, dass Du IPv4 mit einem privaten Adressbereich einsetzt: Du musst dafür sorgen, dass Du von außen an den Port kommst. VPN, Port-Forwarding vom Router oder ein Reverse-Tunnel sind mögliche Lösungen für das Problem.

MfG

Rene

Ich schätze auch, dass da der Fehler liegt. Leider bin ich was Netzwerke angeht ziemlicher Laie. IPv4 mit privaten Adressbereich sagt mir gerade nichts.
Innerhalb von meinem Telekom Router (Speedport) gibt es die Option "Port-Umleitungen und Port-Weiterleitungen" und "Dynamische Portfreischaltungen".

Bei dynamische Portfreischaltung sind die Felder "auslösender Port" und "zu öffnende Ports".

Was muss in die Felder rein? Der Port den ich mit netstat -an -b ausgelesen habe oder 1433?

Vielen Dank schonmal für euer Bemühen!

 

[gutberle]

Siehe Post #4 oben. Die Speedports erlauben im Normalfall keine eingehenden VPN Verbindungen und ich bin überrascht, dass Du Portweiterleitungen machen kannst. Damit würde das gehen und Du würdest Dir auf Deinem Win10 Rechner einen OpenVPN Server einrichten, auf dem Speedport eine Portweiterleitung von eingehendem UDP Port 1194 auf den gleichen UDP Port 1194 auf Deinem Win10 Rechner anlegen und sobald Du alles auf dem Client fertig hast, Zertifikate, etc. sollte es sofort funktoinieren.

>> Ist zwar für einen Netzwerk-Laien schon eine Hausnummer, nur ist VPN inzwischen auch in "normalen Haushalten" derart verbreitet, dass Du im Web Tutorials für die Einrichtung auf jedem Level und in jeder Farben finden wirst, probier's mal aus.

 

[Specker]

@ gutberle

Wow, ich bin begeistert von deinem Posting! Alles sehr aufschlussreich, vielen Dank dafür!

Ich muss das jetzt erstmal alles sacken lassen, da ich heute schon den halben Tag mit der Sache zugange war.
Es sieht aber so aus, als ob kein Weg an VPN vorbeikommt. Sicher soll die ganze Angelegenheit ja schließlich sein.

Melde mich morgen wieder.

 

[gutberle]

Noch ein Hinweis: Ich habe selbst zu Hause einen Speedport W921V stehen gehabt und habe es dort partout nicht geschafft eine stabile UDP Weiterleitung 1194-1194 auf 1194-1194 für <MeinPC> einzurichten oder auch nur irgendetwas vernünftiges mit diesem Router hinzubekommen. Insgesamt sind meine Erfahrungen mit diesen neueren Speedports, die nicht mehr auf AVM Technologie (Fritzbox) basieren, sondern China Schrott mit einem total grottigen und unsicheren Embedded WindowsCE sind, völlig unterirdisch und ich habe nicht lange gefackelt und das Ding mit einer Fritzbxo 7490 ersetzt. Die Telekom hat Blut gekotzt, weil da auch "Service relevantes" wie Comfort TV etc. drüber läuft, aber ich habe denen klar gemacht, dass ich es mir einfach nicht leisten kann, ihre Scheiße einzusetzen, dann war "a Ruh".

>> Probier also Dein Glück, aber es könnte haarig werden, weil VPN entweder funktioniert, oder nicht (OpenVPN Log ist gut, aber kompliziert zu lesen). Versuch also erst mal was ganz einfaches, lass einfach *irgendeinen* deppigen Server (Webserver, FTP Server...) auf Deinem Win10 Rechner laufen, mach eine Portfreigabe darauf und übe damit. Wenn das funktioniert, macht Du die Portfreigabe aus der ersten Zeile dieses Posts und gehst nach Weeb-Tutorial vor. Damit ist immer noch nicht gesagt, dass Dein Speedport die OpenVPN Verbindung auch akzeptiert und vernünftig weiterleitet, aber die Chancen stehen dann zumindest deutlich besser, dass die Fehler (noch) Deine sind und z.B. in der Server oder Client-Config liegen. Und falls nicht, kann ich Dir die neuen Fritzboxen wirklich empfehlen.

Edit 17.08.17 06:38: Oben sollte es "stabile" heißen.

 

[elevennerds.de]

Mit den neuen FritzBoxen lassen sich dann auch sehr einfach VPNs einrichten, für Windows per App, alles sehr gut dokumentiert und auf einem sehr hohen Sicherheitsniveau.

MfG

Rene

 

[gutberle]

@dropshipout hat auch hier wieder Recht, hatte ich oben ja auch schon geschrieben. Ich selbst mache keine FritzBox VPN Verbindungen, weil ich komplizierteres Zeugs mit meinen VPN Verbindungen mache und der Firmen-Router bei mir auch komplett außerhalb jeder sicherheitsrelevanten Zone liegt, aber für reine Punkt-zu-Punkt Verbindungen, wie Du sie hier vorhast, wäre das perfekt. - Und falls Du keine Telefonie-Funktionen im Router brauchst, ginge auch die FB 7390, die exakt die 7490 aber ohne Telefonie ist und die man teilweise schon für ~85€ bekommt ...

 

[Specker]

Die Telekom hat also ein Problem damit, wenn man den Speedport Router gegen einen anderen ersetzt?

„ich bin überrascht, dass Du Portweiterleitungen machen kannst.“

Also ich besitze auch den W921V. Hat bei dir diese Funktion wirklich gefehlt?
An unserem Speedport hängen 2 VoiceoverIP Telefone dran. Ich denke, ich werde es erstmal mit dem probieren.

Hast du denn irgendwelche Empfehlugen für einen geeigneten openVPN Server?

 

[gutberle]

Die Telekom muss den Tausch des Routers natürlich akzeptieren, denn die Routerbindung wurde ja per Gesetz abgeschafft, aber die hassen das, weil sie dann keinen Zugriff mehr auf den Router haben, sich im Servicefall nicht aufschalten können und weiß der Henker, was die da sonst noch so allen treiben (wollen). Die Verfahren und der Port für diese Aufschaltungen sind übrigens genau das, was die Speedport Attacke im letzten Herbst überhaupt erst möglich gemacht hat und mein Router war 2 Tage down, also betroffen!

Nein, die grundsätzliche Möglichkeit Portweiterleitungen einzurichten, gab es auch bei meinem Speedport W921V Router, das Ganze ist nur total unterkomplex angelegt, so dass man nur ganz einfache Dinge machen kann. Ich hätte Dir zum Beispiel gerne zumindest als Fallback, falls Dir die Einrichtung von OpenVPN zu kompliziert wird, die Einrichtung von PPTP auf dem ServerPC vorgeschlagen. Das ist supereinfach mit Bordmitteln einzurichten und jaaaa, es gilt nicht mehr als sicher, aber vergiß das, das ist für Dich komplett ohne Belang. Falls es Dich interessiert, schau mal hier wegen Einrichtung und hier wegen Sicherheit.

PPTP braucht aber zwei Portweiterleitungen, eine für den Datenverkehr mit Protokoll TCP und Port 1723 und für den Verbindungsaufbau das Spezialprotokoll GRE. Nur leider erlaubt der Speedport ausschließlich TCP und UDP Weiterleitungen, GRE, was ist das denn und die Firewall, die das steuert, die kann man - nun ja - an- und ausschalten. Danke, aber das ist Kinderspielzeug. Ich bin gar kein so verbohrter Freak, der Verstopfung bekommt, wenn er die Firewall nicht unter Kontrolle hat, aber die Speedports sind eben für Lieschen Müller gedacht und die Telekom trifft alle Entscheidungen für Lieschen und die sind eben so "weise", wie es die Telekom ist. Da würde ich schon gerne zumindest über die Schulter schauen können...

Windows unterstützt noch ein weiteres VPN Protokoll von Haus aus, L2TP über IPsec, aber das ist unendlich sperrig, langsam und kann nicht ohne weiteres über NAT geroutet werden und so weiter. Davon bleibst Du besser fern, bleibt also nur OpenVPN. Ich habe noch keinen OpenVPN Server unter Windows aufgesetzt, weil ich eh alles, was mit Sicherheit zu tun hat, auf und hinter Linux-Servern mache, aber es spricht für Dich auch nichts dagegen, den Server auf Windows einzurichten, zumal die OpenVPN Installation beides, Client und Server mitbringt und ehrlich gesagt ist das, was ich mir gerade einmal im Netz über OpenVPN Server Windows angeschaut habe, nicht wesentlich komplexer, als wenn Du schon "irgendwo" einen laufenden OpenVPN Server hättest und Dir jetzt "nur noch" die OpenVPN Client Zertifikate erstellen müsstest, also ran an den Speck aber richte Dich mit Mineralwasser und Salzstangen ein, denn die meisten Sätze wirst Du 2-3 mal lesen müssen, es kommt alles echt fremd daher. Aber Schritt-für-Schritt geht das, keine Sorge ...

Fang mal mit dieser Anleitung der PC-Welt an, die ist Schritt-für-Schritt und praktisch alles macht Sinn. Allerdings schreiben die, man müsse die Windows Firewall - dauerhaft - abschalten, weil der PC sonst keine eingehenden Verbindungen annehmen könne. Das halte ich für einen nach zu viel Rotwein geschriebenen Satz, aber während der Einrichtung macht es natürlich auf jeden Fall Sinn, die Firewall *vorrübergehend* auszuschalten, um die Fehlerquellen einzuschränken. Und dass Du dann in der Firewall eine Server-Ausnahme definieren musst, damit der OpenVPN Server erreicht werden kann, ist ja klar. Der Port ist bekannt, UDP 1194, sonst nichts, das sollte zu schaffen sein.

Wichtig ist nur, dass Du akzeptierst, dass bei der Konfiguration von OpenVPN nichts unwichtig oder weniger wichtig ist. Jeder Schritt in der Anleitung muss sitzen, die Ausgaben müssen stimmen und wenn dort steht soundso, dass heißt das soundso, denn ansonsten funktioniert es einfach nicht. ABER, sobald es funktioniert, funktioniert es immer und ohne dass Du in Zukunft noch irgendwann darüber nachdenken musst, OpenVPN GUI starten, anmelden und arbeiten, fertsch!

Nachtrag: Ich habe gerade ein Update meiner Client OpenVPN Installation auf die Version 2.4.3 gemacht und dabei gesehen, dass die EasyRSA Skripte per Default NICHT mit installiert werden. Die brauchst Du, Haken bei der Installation setzen ...

 

[Specker]

Ok, ja auf der openVPN download Seite war ich gestern auch schonmal. War mir nurnicht sicher, ob das ein brauchbarer Server ist.
Da es von Google aber weit oben gerankt wird, gehe ich mal davon aus. Ich werde es auf jeden Fall damit probieren.

Portfreischaltungen in der Firewall ist ja unter Windows kindereinfach.. auch der Rest wird schon klappen. Falls ich nicht weiterkommen sollte, bin ich so frei und poste das Problem hier nochmal.
Danke für den Hinweis mit den EasyRSA-Skripte.

Jetzt geht es ran an den Speck! Aber ohne Salzstangen, die hasse ich

 

[Specker]

So, jetzt bin ich wirklich jeden Schritt aus der Anleitung durchgegangen. Leider funktioniert es noch nicht.

Zu allererst sollte gesagt werden, dass ich vorläufig die Firewall auf dem Server deaktiviert habe und auch die UDP Weiterleitung 1194-1194 auf 1194-1194 für „MeinPC“ auf dem Speedport eingestellt habe.

Als der Server zum ersten Mal startete, wurde folgendes geloggt: „Initialization Sequence Completed“. Fehler konnte ich keine ausmachen.

Sobald ich jedoch eine Verbindung vom Client zum Server herstellen will, kommt innerhalb der openVPN Gui die Meldungen:

Sat Aug 19 23:13:11 2017 OpenVPN 2.4.3 x86_64-w64-mingw32 [SSL (OpenSSL)] [LZO] [LZ4] [PKCS11] [AEAD] built on Jul 14 2017

Sat Aug 19 23:13:11 2017 Windows version 6.2 (Windows 8 or greater) 64bit

Sat Aug 19 23:13:11 2017 library versions: OpenSSL 1.0.2l  25 May 2017, LZO 2.10

Sat Aug 19 23:13:11 2017 MANAGEMENT: TCP Socket listening on [AF_INET]Adressen lösche ich jetzt mal

Sat Aug 19 23:13:11 2017 Need hold release from management interface, waiting...

Sat Aug 19 23:13:12 2017 MANAGEMENT: Client connected from [AF_INET]adresse

Sat Aug 19 23:13:12 2017 MANAGEMENT: CMD 'state on'

Sat Aug 19 23:13:12 2017 MANAGEMENT: CMD 'log all on'

Sat Aug 19 23:13:12 2017 MANAGEMENT: CMD 'echo all on'

Sat Aug 19 23:13:12 2017 MANAGEMENT: CMD 'hold off'

Sat Aug 19 23:13:12 2017 MANAGEMENT: CMD 'hold release'

Sat Aug 19 23:13:12 2017 WARNING: No server certificate verification method has been enabled.  See http://openvpn.net/howto.html#mitm for more info.

Sat Aug 19 23:13:12 2017 MANAGEMENT: >STATE:1503177192,RESOLVE,,,,,,

Sat Aug 19 23:13:12 2017 TCP/UDP: Preserving recently used remote address: [AF_INET]blubb

Sat Aug 19 23:13:12 2017 Socket Buffers: R=[65536->65536] S=[65536->65536]

Sat Aug 19 23:13:12 2017 UDP link local: (not bound)

Sat Aug 19 23:13:12 2017 UDP link remote: [AF_INET]blubb

Sat Aug 19 23:13:12 2017 MANAGEMENT: >STATE:1503177192,WAIT,,,,,,

Sat Aug 19 23:14:12 2017 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)

Sat Aug 19 23:14:12 2017 TLS Error: TLS handshake failed

Sat Aug 19 23:14:12 2017 SIGUSR1[soft,tls-error] received, process restarting

Sat Aug 19 23:14:12 2017 MANAGEMENT: >STATE:1503177252,RECONNECTING,tls-error,,,,,

Sat Aug 19 23:14:12 2017 Restart pause, 5 second(s)

Sat Aug 19 23:14:17 2017 WARNING: No server certificate verification method has been enabled.  See http://openvpn.net/howto.html#mitm for more info.

Die „no server certifcate“ Meldung ist laut Forum keine kritische Meldung und hat mit dem Verbindungsvorgang nichts zu tun. Das Problem wird wohl eher die „Key negotiation failed“ Meldung sein.

Immerhin loggt der Server, dass von außen jemand zugreifen will. In der Log auf dem Server steht dann immer:

TLS: Initial packet from [AF_INET]ADRESSEN LASSE ICH WEG, sid=++++ TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)

TLS Error: TLS handshake failed

SIGUSR1[soft,tls-error] received, client-instance restarting

Sobald ich die UDP Umleitungen auf dem Speedport deaktiviere, loggt der Server nichts mehr. Das scheint also zu funktionieren. Firewall ist wie gesagt auch aus.



Auf dieser Seite werden mögliche Lösungsvorschläge aufgezeigt. Ich habe aber alles überprüft. Meine Angaben müssten korrekt sein.

https://openvpn.net/index.php/open-...-seconds-check-your-network-connectivity.html



So, jetzt habe ich mich den halben Tag damit rumgeärgert. Ich hoffe das war jetzt nicht alles für die Katz. Irgendwo muss ja der Fehler liegen.

Über mögliche Lösungsvorschläge wäre ich sehr dankbar.



Gruß - Ben

 

[gutberle]

Hallo Ben,

ich habe natürlich Deine Zertifikate nicht und kann deshalb keine 100%ige A-bis-Z Clearance geben, aber die .ovpn Dateien, die Du mir per PN geschickt hast, sind absolut sauber und nachdem ich mir selbst ein paar Testzertifikate erzeugt hatte, habe ich sofort eine Verbindung herstellen können. - Um also zu schauen, woran es dann liegt habe ich meinen alten Speedport W921V rausgekramt, angeschlossen, eine UDP/1194 Portfreigabe gesetzt ... und bekomme exakt den gleichen Fehler wie Du.

Dann habe ich ein bißchen gegooglet, weil es schon ein wenig her ist, dass ich zuletzt - und eben auch nicht gerade erfolgreich - OpenVPN mit dem Speedport probiert hatte und siehe da, sooo war das: Die interne Firewall des Speedport läßt sich NICHT abschalten, betrachtet aber TROTZ der geschalteten Portfreigabe den TLS Handshake des OpenVPN Verbindungsaufbaus als DDOS Attacke und macht dicht. - In diesem Thread findest Du die relevanten Infos.

Also habe ich noch versucht, auf einen alten Trick zurückzugreifen und habe Varianten von Server und Client erzeugt, die über die TCP Ports 443 und alternativ 3389 versuchen, eine Verbindung herzustellen, weil das mit HTTPS und RDP zwei übliche Protokolle sind, die normalerweise von Routern in Ruhe und durchgelassen werden. Aber hier - Pustekuchen, ich kriege trotz korrekt gesetzter 3389er Freigabe im Speedport nicht einmal eine echte RDP Verbindung von außen hin. Das Ding ist einfach nur Schrott!!!

Ich bin jetzt ehrlich gesagt mit meinen Optionen für Lösungen MIT DEM Speedport am Ende und kann Dir wirklich nur raten, Dich nach einem anderen Router umzuschauen, die bereits mehrfach erwähnten Fritzboxen können ja auch VOIP, etc. - Aber Obacht, falls der Speedport von der "Post" gemietet ist, z.B. im Rahmen eines Call & Surf oder Entertain Comfort IP Pakets, dann musst Du erst mit denen reden, bevor Du den Creme Brule Brenner anwirfst...

P.S. Falls Du mal selber schauen willst, ob Deine Zertifikate und .ovpn Dateien ~wirklich~ in Ordnung sind, ändere mal in der Client .ovpn die DDNS Adresse gegen die echte (interne) IP Adresse Deines OpenVPN Servers. Dann baut Dein Client PC die Verbindung lokal auf, was natürlich nur dann funktioniert, wenn Client und Server im gleichen Netz sind. Machen kannst Du mit der Verbindung auch nichts, weil Du ja eh schon im gleichen Subnetzt bist, aber Du siehst am Log und auch an den Statusmeldungen des OpenVPN GUI, DASS es funktioniert, der Fehler bei der Verbindung über den Speedport also nicht bei Dir liegt. - Das macht sogar dann Sinn, wenn der Frust jetzt tief sitzt, denn egal wie, irgendeine Lösung muss ja wohl her und zu wissen, dass man erfolgreich einen OpenVPN Server und Client erzeugt hat, ist definitiv ein Anfang!!!

Gruß,
Ingmar

 

[Specker]

Erstmal ein großes Lob an Ingmar, der mittlerweile die ein oder andere Minute für dieses Problem von mir geopfert hat!

Wie es aussieht, liegt es tatsächlich am Speedport, dass es nicht funktioniert.

P.S. Falls Du mal selber schauen willst, ob Deine Zertifikate und .ovpn Dateien ~wirklich~ in Ordnung sind, ändere mal in der Client .ovpn die DDNS Adresse gegen die echte (interne) IP Adresse Deines OpenVPN Servers.

Das habe ich eben mal gemacht und „leider“ funktioniert es. Hatte gehofft, dass irgendwas mit den Zertifikaten erstellen nicht richtig gelaufen ist. Das war es wohl nicht…

Ich werde mich jetzt mal mit meinem Geschäftspartner absprechen, ob es aktuell schon von Nöten ist direkt auf eine FritzBox umzusteigen oder doch vorläufig mit TeamViewer weiter zu machen.

Wichtig für uns wird es spätestens dann, wenn mir mit LS-POS im stationären Geschäft arbeiten und sowieso eine Anbindung an die Datenbank brauchen.

Um ein paar Erfahrungen bin ich jedenfalls reicher, dafür bin ich jetzt schon dankbar!


Beste Grüße - Ben

 

[gutberle]

Hallo Ben,

gern geschehen und wenn es auf einen anderen Router und OpenVPN hinausläuft, dann melde Dich hier noch einmal, denn dann wäre es wichtig, dass Du den Unterschied zwischen einer TAP und einer TUN Verbindung kennst und dann ist da noch das Management Interface und die User Authentication. Das ist alles schnell erklärt und insbesondere TAP vs. TUN ist wichtig. Für alles kann ich Dir Varianten Deiner .ovpn Dateien schicken, die Änderungen sind gering, die Auswirkungen aber groß ...

Gruß,
Ingmar