OpenVPN - Zugriff aus 192.168.x.x nicht möglich

[aschne1]

Hallo Leute

Nachdem L2TP nur eine Verbindung aus einem entfernten Netz zulässt, wollte ich noch OpenVPN einrichten. Das funktioniert eigentlich auch gut, sofern ich mich nicht in einem WLan mit dem Adressbereich 192.168.x.x. befinde.

Das Syno hat die Adresse 192.168.1.x und ist an einem Anschluss mit einer fixen iP-Adresse vom ISP. Wenn ich nun über mein Mobile zugreife dann klappt auch alles ordentlich, wenn ich mich in bestimmten WLan's befinde dann aber nicht. Was mache ich falsch?

Syno Netzwerk: 192.168.1.0

WLan: 192.168.7.0 -> Verbindung klappt nicht!
WLan: 192.168.0.0 -> Verbindung klappt nicht.
WLan: 192.168.179.0 -> Verbindung klappt nicht.
WLan: 10.41.38.0 -> Verbindung klappt !!!!
Mobile: Klappt auch!!!!!

Eigentlich müssten doch auch die 192'er Adressen gehen, sofern sie nicht im gleichen Bereich wie das Syno (192.168.1.0) liegen? Und an der Firewall liegt es auch nicht, denn die L2TP Verbindung klappt....

Danke für Eure Hilfe

Gruss

Armin

 

[Fusion]

Die IP allein definiert ja nicht das Netzwerk. Hinzu kommt die Subnet-Maske und Routing und von Einstellungen die dann entscheiden wohin eine Anfrage läuft oder eben nicht.

Mit der Einstellung 'redirect-gateway def1' in der openvpn client config sollte es klappen, solange das lokale remote Netz nicht 192.168.1.0/24 bzw 192.168.1.0 subnet 255.255.255.0 lautet (bzw vermutlich auch dann). Damit leitet er auch vermeintlich lokalen Verkehr erst über das von anstatt es direkt im jeweiligen LAN zu probieren.

Oder du legst dein privates Netz woanders hin
https://de.wikipedia.org/wiki/Private_IP-Adressen
Irgendwo bei Irgendwem wird man allerdings immer auf IP Kollisionen treffen, oder einen anderen Grund wieso es mal nicht klappt.

 

[aschne1]

Danke für Deine Antwort.

Genau im Netzwerk 192.168.1.0/24 befindet sich das Synology, Und als OpenVPN Adressbereich habe ich es bei der Standardeinstellung belassen. Ich glaube 10.8.0.0/24. 'reject-gateway def1' ist eingestellt. Und so funktioniert die Verbindung nicht aus einem 192'er Netz!

Ich weiss, dass das Netz 192.168.1.0 nicht optimal ist, denn viele Router verwenden Standardmässig diesen Adressbereich. Ist nicht auf meinem Mist gewachsen und kann es im Moment leider nicht umstellen. Wäre es sinnvoller später das Remote-Netz auf 10.x.x.x umzustellen?

 

[Fusion]

Dann stimmt aber denke ich etwas anderes auf dem Client nicht. Von dort wird ja zuerst deine öffentliche IP/Domain angefragt auf Port 1194 um den VPN Tunnel herzustellen. Mit redirect gateway schickt er alle Netzwerkanfragen über dieses Interface.

Bitte immer vollständig definierte Netze angeben (IP+Sub, oder CIDR Schema). Ja, man kann meist erraten was gemeint ist, aber ein eindeutig ist es nicht.

Bei openvpn ist der Client nach Verbindung im VPN Server Netz mit der IP der Syno unterwegs. Vielleicht liegt da der Hund begraben.

Hilft vermutlich nur das vpn log und mal pathpings oder trace / traceroute vom Client um zu sehen wo es hängt.

 

[aschne1]

Wie bereits erwähnt handelt es sich extern um eine fixe IP-Adresse vom ISP.

Das ISP Modem verwendet intern den Bereich 192.168.1.0 Subnet 255.255.255.0. Der Router selbst die 192.168.1.1 und das Synology 192.168.1.15 (fix). DHCP ab 192.168.1.33.

Wenn ich mich mit einem Client mobil verbinde, bin ich dann 10.8.0.6, also im Adressbereich welcher für OpenVPN definiert wurde. Das meinst Du mit Netz der Syno, oder?
Wenn ich verbunden bin, dann sehe ich einen Eintrag im log der Syno, sonst nix.

Werde mal pathpings und trace machen.

Thx

 

[Fusion]

Die fixe öffentliche IP hat der Router auf seinem WAN Interface?
Ist das nur ein Modem, oder ein Modem Router? Hat der also nur einen Verwaltungszugang auf 192.168.1.100 oder ähnlich, oder noch weitere Netzwerkfunktionen?

Nein, wenn der Client verbunden ist hat er im vpn Transfernetz z.b. Die 10.8.0.6. Alle Anfragen die er jetzt an Rechner im 192.168.1.0/24 Netz schickt haben als Absender die 192.168.1.15 der Synology. Dein PC könnte also nicht unterscheiden, ob die Anfrage direkt von der Syno kommt oder vorher noch via vpn Tunnel dorthin gelangt ist.

Was sagt das Client Log, oder hast du auf dem Client keines zugänglich?

 

[aschne1]

Ist ein Modem Router und die fixe IP ist am WAN.

Die Verwaltung mache ich von extern über die GUI vom Anbieter auf diese fixe IP. Diese muss ich vorab aktivieren. Verwaltungszugang 192.16.1.1 kann ich im Moment nicht testen....

Log
Enter Management Password:
Mon Aug 12 10:41:37 2019 WARNING: No server certificate verification method has been enabled. See http://openvpn.net/howto.html#mitm for more info.
Mon Aug 12 10:41:37 2019 TCP/UDP: Preserving recently used remote address: [AF_INET]213.3.xxx.xxx:1194
Mon Aug 12 10:41:37 2019 UDP link local (bound): [AF_INET][undef]:1194
Mon Aug 12 10:41:37 2019 UDP link remote: [AF_INET]213.3.xxx.xxx:1194
Mon Aug 12 10:42:37 2019 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Mon Aug 12 10:42:37 2019 TLS Error: TLS handshake failed
Mon Aug 12 10:42:37 2019 SIGUSR1[soft,tls-error] received, process restarting
Mon Aug 12 10:42:42 2019 WARNING: No server certificate verification method has been enabled. See http://openvpn.net/howto.html#mitm for more info.
Mon Aug 12 10:42:42 2019 TCP/UDP: Preserving recently used remote address: [AF_INET]213.3.xxx.xxx:1194
Mon Aug 12 10:42:42 2019 UDP link local (bound): [AF_INET][undef]:1194
Mon Aug 12 10:42:42 2019 UDP link remote: [AF_INET]213.3.xxx.xxx:1194

 

[Fusion]

Mmh. Hast du dann eine Routerkaskade? Also Portfreigabe im 'modem' auf den zweiten Router und dort auf das Endgerät? Oder ist der zweite Router nur noch switch oder WLAN access point, aber routet nicht mehr?

Sorry für die blöden fragen, aber wenn man das Konstrukt nicht versteht fallen einem auch schwerer Lösungsansätze ein.
Normal ist das Modem transparent und die feste IP landet auf dem Router dahinter. So kenne ich das jedenfalls.

Mit zwei Routern wird das komplexer.
Der zweite Router hat 192.168.1.1 intern oder am WAN?
Wie kann der gescheit routen, wenn er intern 192.168.1.0/24 hat und selbst im 192.168.1.0/24 Netz des Modem Routers hängt...

Edit:
In dem log ist ja außer der Zertifikatsbemängelung nichts auffällig (weil du ja auf IP und nicht Name verbindest). Überprüfung kann man eventuell ausschalten. Als Sicherheit kann man vielleicht noch einen tls key einrichten der auf den Clients vorhanden sein muss, zusätzlich zum benutzer/Pass, wenn es dann mal gescheit läuft.

 

[aschne1]

Das mit dem Zertifikat ist doch üblich, oder nicht?

Und Routerkaskade verwende ich nicht. Dann würde doch das L2TP auch nicht laufen? Ich werde einmal für's OpenVPN einen anderen Adressbereich versuchen. Vielleicht hilft das. So schnell geb ich nicht auf...
IP von 10.8.0.0 auf 10.11.0.0 bringt nix.

 

[Fusion]

Ja, das TLS-Zertifikat ist üblich. Aber dieses lautet halt auf www.example.com oder ähnlich. Nur dann kann auch der Name im Zertifikat überprüft werden. Es ist zwar technisch denke auch möglich und nicht verboten ein Zeritifkat auf eine IP auszustellen aber eben komplett unüblich.
Du hast zwar eine feste IP, aber da würde ich mir trotzdem überlegen, ob ich es nicht per Domain betreibe. Kostet ja nur ein paar Euro im Jahr und du kannst dann einfach die Domain per A/AAAA Record auf deine IP setzen. Kannst prinzipiell auch mit einem dynDNS Dienst machen, wenn du keine eigene Domain hast oder willst.

VPN Transfernetz brauchst nicht rumprobieren, daran liegt es nicht.

Welche WAN IP hat denn der Router?
Baut der Router eine eigene PPoE Verbindung über das Modem im Modem-Router auf (dann würde er aber über eine andere IP erreichbar sein), oder spielt er nur IP Client und benutzt die Internetverbindung die das Modem für sich aufbaut mit?

 

[the other]

Moinsen,
kurz gefragt: die oben von dir eingetippte log Datei ist bezogen auf Mobilen Zugang, also nicht eines der fehlerhaften WLANs, richtig? Logo. Was sagt denn die log Datei, wenn du aus den nicht funzenden 192.168.X.X Netzen versuchst?
Wäre vielleicht zielführender zur weiteren Hilfe...

Und eigentlich muss das gehen, da sich die Netze ja anscheinen nicht überschneiden. Sind das WLANs bei Freunden, Bekannten etc? Oder hast du Multi SSID daheim?

Grüßle
the other

 

[aschne1]

Log ist vom Client bei dem keine Verbindung zustande kommt.
Und es sind WLan's an verschiedenen Standorten, kein Multi SSID.
Mit dem öffentlichen WLan welches sich alle upc Kunden teilen klappt die Verbindung....

@Fusion: WAN IP kläre ich noch ab.

Thx

 

[aschne1]

@Fusion

Guats Mörgele..


Hab jetzt wegen dem Router geschaut.

Also der Router baut die Internetverbindung selbst auf, es ist kein zusätzliches Modem vorhanden. Es handelt sich um ein Swisscom Centro Business Router, noch die alte erste Version. Kannst Du Dir wie eine Fritzbox vorstellen, nur halt vom ISP Swisscom. Eigentlich hasse ich die Teile, da man vom ISP abhängig ist....


Der Router hat selbst die IP 192.168.1.1

Folgende Einstellungen habe ich noch:
WAN-Zugriff: VDSL2
Verbindungstyp: DHCP und PPPoE
Connectivity-Modus: Dualsession Business Internet
DNS-Server: 195.186.4.162 und 195.186.1.162
IP-Adresse Swisscom Services: 100.94.104.113


Hilf Dir das weiter?

Danke + Gruss

 

[Fusion]

Jetzt bin ich verwirrt. Also jetzt doch nur 1 Gerät? Oder kommt hinter dem SCBR noch ein weiteres Gerät?

 

[aschne1]

Sorry, vielleicht werden wir Schweizer so schlecht verstanden?

Ist nur ein Router mit integriertem Modem an welchem das Syno angeschlossen ist. Ausserdem ist da noch eine Art WLan-Verstärker, doch ich kann im Moment nicht in diese Räumlichkeiten und Dir nicht genau sagen was für einer.

Ich denke nur, dass es trotzdem klappen sollte, denn mobil läuft es auch. Und die L2TP Verbindung macht keine Probleme, auch nicht aus einem 192.168.x.x Netz heraus.

 

[Fusion]

Dass es prinzipiell klappt wissen wir ja durch L2TP.
Wenn man allerdings hilfreiche Tipps generieren soll ist es nötig die Lage vor Ort zu verstehen. Das hat nichts mit Nationalität, sondern nur mit akuraten und vollständigen Beschreibungen zu tun.

Denke es hängt eher Richtung Routing am Client.
Redirect gateway hattest du ja gesetzt gehabt?
Ebenso 'clients den Server LAN Zugriff erlauben' in den Server Einstellungen?
Hast du mal das Log von einem Netz wo es funktioniert hat mit dem nicht funktionierenden verglichen?
Eventuell noch den Client auf mehr Geschwätzigkeit getrimmt (müsste ich auch erst nachsehen wie das geht).

Und nochmal die Frage, auch wenn du es schon erwähnt hast, nur die Syno ist nicht erreichbar, andere Ziele im LAN schon?

 

[aschne1]

Das mit der Herkunft war nicht ernst gemeint. ;-)


So jetzt mal meine Einstellungen:



Nun zum Log:
Aus einem Netz 192.168.7.x -> keine Verbindung möglich.

Thu Aug 15 13:25:01 2019 OpenVPN 2.4.7 x86_64-w64-mingw32 [SSL (OpenSSL)] [LZO] [LZ4] [PKCS11] [AEAD] built on Apr 25 2019
Thu Aug 15 13:25:01 2019 Windows version 6.2 (Windows 8 or greater) 64bit
Thu Aug 15 13:25:01 2019 library versions: OpenSSL 1.1.0j 20 Nov 2018, LZO 2.10
Enter Management Password:
Thu Aug 15 13:25:06 2019 WARNING: No server certificate verification method has been enabled. See http://openvpn.net/howto.html#mitm for more info.
Thu Aug 15 13:25:06 2019 TCP/UDP: Preserving recently used remote address: [AF_INET]xxx.x.44.134:1194
Thu Aug 15 13:25:06 2019 UDP link local (bound): [AF_INET][undef]:1194
Thu Aug 15 13:25:06 2019 UDP link remote: [AF_INET]xxx.xxx.44.134:1194
Thu Aug 15 13:26:06 2019 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Thu Aug 15 13:26:06 2019 TLS Error: TLS handshake failed
Thu Aug 15 13:26:06 2019 SIGUSR1[soft,tls-error] received, process restarting


Aus einem öffentlichen Netz -> Verbindung möglich
Thu Aug 15 13:34:53 2019 OpenVPN 2.4.7 x86_64-w64-mingw32 [SSL (OpenSSL)] [LZO] [LZ4] [PKCS11] [AEAD] built on Apr 25 2019
Thu Aug 15 13:34:53 2019 Windows version 6.2 (Windows 8 or greater) 64bit
Thu Aug 15 13:34:53 2019 library versions: OpenSSL 1.1.0j 20 Nov 2018, LZO 2.10
Enter Management Password:
Thu Aug 15 13:34:57 2019 WARNING: No server certificate verification method has been enabled. See http://openvpn.net/howto.html#mitm for more info.
Thu Aug 15 13:34:57 2019 TCP/UDP: Preserving recently used remote address: [AF_INET]xxx.x.44.134:1194
Thu Aug 15 13:34:57 2019 UDP link local (bound): [AF_INET][undef]:1194
Thu Aug 15 13:34:57 2019 UDP link remote: [AF_INET]xxx.x.44.134:1194
Thu Aug 15 13:34:57 2019 WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this
Thu Aug 15 13:34:59 2019 [synology.com] Peer Connection Initiated with [AF_INET]xxx.x.44.134:1194
Thu Aug 15 13:35:01 2019 open_tun
Thu Aug 15 13:35:01 2019 TAP-WIN32 device [Ethernet 2] opened: \\.\Global\{6E2109A3-07D5-4867-9CF7-6BA7364B234F}.tap
Thu Aug 15 13:35:01 2019 Notified TAP-Windows driver to set a DHCP IP/netmask of 10.8.0.6/255.255.255.252 on interface {6E2109A3-07D5-4867-9CF7-6BA7364B234F} [DHCP-serv: 10.8.0.5, lease-time: 31536000]
Thu Aug 15 13:35:01 2019 Successful ARP Flush on interface [9] {6E2109A3-07D5-4867-9CF7-6BA7364B234F}
Thu Aug 15 13:35:06 2019 Initialization Sequence Completed


Also die Verbindung aus dem lokalen Lan klappt nicht, wenn ich aber über einen Hotspot am Handy gehe dann klappt es...

Thx

 

[Fusion]

Verbindung aus dem lokalen LAN? Das klappt oft nicht, meist scheitert es am Router oder Routen. Oder meinst du ein remote LAN mit 192.168.7.x?

Gibt aber auch noch andere Möglichkeiten bis hin zur Paketgröße
https://openvpn.net/faq/tls-error-t...n-60-seconds-check-your-network-connectivity/

 

[aschne1]

Was meinst Du mit Client und Remote? Ich gehe einmal davon aus, dass ich mich von Extern mit den Clients mit dem Remote-LAN(Syno) verbinden will.

Habe bereits 192.168.7.x und 192.168.0.x als Client getestet. Das remote LAN hat den Adressbereich 192.168.1.x und darin das Syno 192.168.1.15.


Im Log sehe ich, dass bis zu dem UDP link remote die Verbindung identisch verhält. Nur danach findet halt im einen Fall keine Verbindung statt. Entweder geht beim Client nix mehr raus, oder Remote lässt keine Datenpakete zu?

Ping auf die öffentliche Remote-IP funktioniert jedoch tadellos.
Wenn ich Zuhause einen Hotspot mit dem Handy mache, dann funktioniert die Verbindung mit dem Notebook tadellos. Ebenfalls klappt die Verbindung mit diesem Handy wenn ich WLan deaktiviere. Sobald ich aber in einem WLan bin, geht nix mehr. Auch das Handy verbindet sich nicht mehr. Deshalb denke ich, dass ich die WIndows Firewall ausschliessen kann. Verschiedene Router/Modem helfen auch nicht weiter. Habe das mit Fritzbox und upc connect box getestet.

Könnte es an der Subnetmaske liegen? Denn wenn ich ein öffentliches WLan mit der 255.255.192.0 nehme, dann klappt die Verbindung. IP in diesem öffentlichen WLAN 10.41.38.132 (Gateway 10.41.0.1)

 

[Fusion]

Lokal bezieht sich normalerweise auf das Netz in dem der VPN Server läuft. Clients sind remote. Aber solange man weiß was der andere meint...

Beim öffentlichen WLAN glaube ich nicht, aber bei 192.168.x.y kann ein subnet 255.255.0.0 schon helfen... Wenn denn davor erst mal der VPN Tunnel zu stande kommt.

Echt vertrackt