13
Kein VPN Zugriff ins interne Netzwerk per Android Fritzbox IPV6 Synology OpenVPN
Hallo zusammen,
bräuchte mal eure Hilfe.
Komm nicht weiter beim Zugriff ins interne Netzwerk per VPN unter DS-lite.
Konfiguration ist:
Fritzbox 7590 an Glasfaser (DHCP mit Standard IP Bereich 192.168.178...) und IPV6 DS-lite Anschluß.
Daran angeschlossen ein Synology-NAS.
Darauf läuft der VPN-Server mit OpenVPN in der Standard-Konfig (IP Bereich 10.8.0....)
In der Fritzbox ist UDP 1194 freigegeben. Statische Route ist angelegt mit 10.8.0.0 255.255.255.0 auf 192.168.178.20 (NAS)
Möchte von meinem Android Smartphone (Vodafone mit IPv6) über VPN auf die lokalen Netzwerkadressen zugreifen (webcams...)
VPN Verbindung wird aufgebaut und läuft.
Internet per VPN geht. Alle internen Adressen lassen sich anpingen und traceroute läuft säuber durch.
Wenn ich im Browser jedoch eine lokale IP (192.168.178.xxx angebe, passiert genau... nichts...
Was fehlt mir zu meinem Glück ? Wo ist mein Denkfehler ?
schöne Grüße
arzthilfe
bräuchte mal eure Hilfe.
Komm nicht weiter beim Zugriff ins interne Netzwerk per VPN unter DS-lite.
Konfiguration ist:
Fritzbox 7590 an Glasfaser (DHCP mit Standard IP Bereich 192.168.178...) und IPV6 DS-lite Anschluß.
Daran angeschlossen ein Synology-NAS.
Darauf läuft der VPN-Server mit OpenVPN in der Standard-Konfig (IP Bereich 10.8.0....)
In der Fritzbox ist UDP 1194 freigegeben. Statische Route ist angelegt mit 10.8.0.0 255.255.255.0 auf 192.168.178.20 (NAS)
Möchte von meinem Android Smartphone (Vodafone mit IPv6) über VPN auf die lokalen Netzwerkadressen zugreifen (webcams...)
VPN Verbindung wird aufgebaut und läuft.
Internet per VPN geht. Alle internen Adressen lassen sich anpingen und traceroute läuft säuber durch.
Wenn ich im Browser jedoch eine lokale IP (192.168.178.xxx angebe, passiert genau... nichts...
Was fehlt mir zu meinem Glück ? Wo ist mein Denkfehler ?
schöne Grüße
arzthilfe
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: 620579
Url: https://administrator.de/contentid/620579
Printed on: May 10, 2024 at 22:05 o'clock
13 Comments
Latest comment
Hallo,
Ein Ping auf die IP der FRitte geht? Im Browser bei bestehender VPN die Web GUI der Fritte (192.168.178.1) geht? WebCAMs per GastNetz angebunden? Wie sieht deine VPN Konfig denn aus?
Gruß,
Peter
Ein Ping auf die IP der FRitte geht? Im Browser bei bestehender VPN die Web GUI der Fritte (192.168.178.1) geht? WebCAMs per GastNetz angebunden? Wie sieht deine VPN Konfig denn aus?
Gruß,
Peter
Ping auf die IP der Fritz geht (und auch auf alle anderen Geräte)
Im Browser komm ich nicht auf die GUI der Box
Es hängt nichts im Gastnetz, alle Gerätschaften in 192.168.178...
Config sieht so aus
dev tun
tls-client
remote diskstation.xxxxxxxx.myfritz.net 1194
#float
redirect-gateway def1
#dhcp-option DNS DNS_IP_ADDRESS
dhcp-option DNS 192.168.178.1
dhcp-option DNS 8.8.8.8
pull
route add 10.8.0.0 255.255.255.0 192.168.178.20
script-security 2
#reneg-sec 0
remote-cert-tls server
cipher AES-256-CBC
auth SHA512
auth-nocache
auth-user-pass
Im Browser komm ich nicht auf die GUI der Box
Es hängt nichts im Gastnetz, alle Gerätschaften in 192.168.178...
Config sieht so aus
dev tun
tls-client
remote diskstation.xxxxxxxx.myfritz.net 1194
- The "float" tells OpenVPN to accept authenticated packets from any address,
- not only the address which was specified in the --remote option.
- This is useful when you are connecting to a peer which holds a dynamic address
- such as a dial-in user or DHCP client.
- (Please refer to the manual of OpenVPN for more information.)
#float
- If redirect-gateway is enabled, the client will redirect it's
- default network gateway through the VPN.
- It means the VPN connection will firstly connect to the VPN Server
- and then to the internet.
- (Please refer to the manual of OpenVPN for more information.)
redirect-gateway def1
- dhcp-option DNS: To set primary domain name server address.
- Repeat this option to set secondary DNS server addresses.
#dhcp-option DNS DNS_IP_ADDRESS
dhcp-option DNS 192.168.178.1
dhcp-option DNS 8.8.8.8
pull
route add 10.8.0.0 255.255.255.0 192.168.178.20
- If you want to connect by Server's IPv6 address, you should use
- "proto udp6" in UDP mode or "proto tcp6-client" in TCP mode
script-security 2
#reneg-sec 0
remote-cert-tls server
cipher AES-256-CBC
auth SHA512
auth-nocache
auth-user-pass
Was fehlt mir zu meinem Glück ?
Was da fehlt ist das Aktivieren vom IP Forwarding (Routing) auf dem NAS bzw. dessen Betriebssystem. Das NAS bzw. ein OpenVPN Server ist ja quasi auch immer ein Router der zwischen dem internen OpenVPN IP Netz und dem lokalen IP Netz routen muss.Folglich muss also immer das IP Forwarding (Routing) im Betriebssystem des OpenVPN Servers aktiviert werden. Das gilt für Winblows ebenso wie für unixoide OS wie Linux. Letzteres ist bei so gut wie allen NAS Betriebssystemen und damit auch in der Synology im Einsatz.
Normal ist bei allen OS das IP Forwarding (Routing) immer deaktiviert. Will man also nicht nur den Server selber sondern auch Endgeräte im lokalen LAN erreichen, muss man immer IP Forwarding aktivieren.
Das hiesige OpenVPN_Tutorial weist (wenn man es denn einmal liest...) explizit darauf hin:
Merkzettel: VPN Installation mit OpenVPN
Genau DAS fehlt bei dir zu deinem Glück !
http://www.huckfeldt.eu/IPForward.html
https://www.synology-forum.de/threads/startscript-zur-aktivierung-von-ip ...
Danke für den Hinweis... aber leider noch nicht glücklich...
hab jetzt das IP-Forwarding eingebaut.
Meine sysctl.conf sieht jetzt so aus
kernel.panic = 3
net.core.somaxconn = 65535
net.ipv4.tcp_tw_reuse = 1
net.ipv4.ip_forward = 1
Synology neu gestartet
komm immer noch nicht ins lokale Netzwerk
noch statische Route anlegen in Synology ? (192.168.178.0 255.255.255.0 ????)
bei Angabe Gateway 10.8.0.1 wird aber beim Speichern nicht aktiviert. Oder was muß da rein
oder brauch das überhaupt nicht und es liegt noch an was anderem.
gerade genau NULL Peilung
hab jetzt das IP-Forwarding eingebaut.
Meine sysctl.conf sieht jetzt so aus
kernel.panic = 3
net.core.somaxconn = 65535
net.ipv4.tcp_tw_reuse = 1
net.ipv4.ip_forward = 1
Synology neu gestartet
komm immer noch nicht ins lokale Netzwerk
noch statische Route anlegen in Synology ? (192.168.178.0 255.255.255.0 ????)
bei Angabe Gateway 10.8.0.1 wird aber beim Speichern nicht aktiviert. Oder was muß da rein
oder brauch das überhaupt nicht und es liegt noch an was anderem.
gerade genau NULL Peilung
noch statische Route anlegen in Synology ?
Nein, das wäre Blödsinn und überflüssig, denn die Synology hat ja (hoffentlich !?) ein Default Gateway auf die FB eingetragen. Zudem ist sie ja auch selber direkt mit einem Interface im .178.0er und 10.8.0.0er Netz angeschlossen und "kennt" somit diese IP Netze so das Routen hier üerflüssig sind.Was passiert wenn du von einem aktiven OVPN Client die LAN IP .178.20 der Synology pingst oder traceroutest ? Ebenso die IP der FB .178.1 ?
Nochwas:
Wenn du vom VPN Client einen anderen Host im Netzwerk pingst und dieser ein Winblows Host ist dann bedenke immer das die lokale Windows Firewall...
- Per Default das ICMP Protokoll (Ping) blockiert.
- Per Default jeglichen Zugriff aus fremden, nicht lokalen IP Netzen (wie z.B. dein 10er OVPN Clientnetz) blockiert.
Ping muss man bei Windows explizit erlauben:
https://www.windowspro.de/wolfgang-sommergut/ping-windows-10-erlauben-gu ...
und zudem die IP Range im Setup unter "Windows Firewall mit besonderer Sicherheit" auf "Beliebig" setzen.
Sinnvollerweise sollte man also immer nicht Windows Endgeräte pingen wie z.B. die LAN IP der FB .178.1 oder Drucker etc.
gerade genau NULL Peilung
Keine besonders guten Voraussetzungen für ein zielführendes Troubleshooting in einem Administrator Forum. 
vom aktiven OVPN Client zur Syno .20
ping
3 übertragen, 3 empfangen
traceroute
1. DiskStation.fritz.box
vom aktiven OVPN Client zur Fritz .1
ping
3 übertragen, 3 empfangen
traceroute
1. 10.8.0.1
2. fritz.box
ping
3 übertragen, 3 empfangen
traceroute
1. DiskStation.fritz.box
vom aktiven OVPN Client zur Fritz .1
ping
3 übertragen, 3 empfangen
traceroute
1. 10.8.0.1
2. fritz.box
Dann geht doch alles und funktioniert wie es soll !
Kannst du ja auch als Laie selber sehen. Dadurch das du die LAN IP Adresse der FritzBox pingen kann zeigt dies, das das IP Forwarding der Synology inms lokale LAN sauber funktioniert.
Vermutlich kannst du dann auch bei aktivem OVPN Client mit http://192.168.178.1 die Web GUI der FritzBox öffnen, richtig ?
Das zeigt dann das dein VPN sauber funktioniert und nur die Windows Firewall an den Clients die du von remote per VPN erreichen willst falsch bzw. fehlerhaft konfiguriert ist.
Das ist hier gefühlt 20mal in der Woche der Fehler bei VPNs.
Kannst du ja auch als Laie selber sehen. Dadurch das du die LAN IP Adresse der FritzBox pingen kann zeigt dies, das das IP Forwarding der Synology inms lokale LAN sauber funktioniert.
Vermutlich kannst du dann auch bei aktivem OVPN Client mit http://192.168.178.1 die Web GUI der FritzBox öffnen, richtig ?
Das zeigt dann das dein VPN sauber funktioniert und nur die Windows Firewall an den Clients die du von remote per VPN erreichen willst falsch bzw. fehlerhaft konfiguriert ist.
Das ist hier gefühlt 20mal in der Woche der Fehler bei VPNs.
Loopback zu meinem ersten Post
dort steht ja schon ping und tracerout geht, aber kein Zugriff auf die Geräte /GUI
also nein, es geht eben nicht, irgendeine GUI aufzurufen (von Webcams, Fritz oder oder...)
nein ich rufe kein Windows Client auf, wo eine Firewall stören könnte
ja, das sehe ich auch das ping und traceroute geht...
funktioniert aber trotzdem leider nicht....
dort steht ja schon ping und tracerout geht, aber kein Zugriff auf die Geräte /GUI
also nein, es geht eben nicht, irgendeine GUI aufzurufen (von Webcams, Fritz oder oder...)
nein ich rufe kein Windows Client auf, wo eine Firewall stören könnte
ja, das sehe ich auch das ping und traceroute geht...
funktioniert aber trotzdem leider nicht....
Wenn man die Firewall ausschliessen kann, dann kann es letztlich nur noch ein MTU Problem und daraus resultierende Fragmentierung.
Dazu müsstest du mal den MTU Test mit OpenVPN machen oder einen einfachen Ping mit entsprechender Paketlänge: https://kb.netgear.com/19863/Ping-Test-to-determine-Optimal-MTU-Size-on- ...
Das es IP technisch generell ja geht zeigt ja der erfolgreiche Ping des FritzBox Interfaces. Vermutlich kannst du auch Drucker usw. im lokalen Netz pingen.
Gut, zwingende Voraussetzung sind natürlich die 2 wichtigsten Punkte:
Eine hilfreiche und gute Lektüre für OpenVPN in einem Dual Stack Umfeld mit v4 und v6 ist auch das hier:
https://www.heise.de/select/ct/2018/13/1529374309620058
bzw.
https://www.heise.de/ratgeber/OpenVPN-Vernetzung-mit-IPv4-und-IPv6-41628 ...
Dazu müsstest du mal den MTU Test mit OpenVPN machen oder einen einfachen Ping mit entsprechender Paketlänge: https://kb.netgear.com/19863/Ping-Test-to-determine-Optimal-MTU-Size-on- ...
Das es IP technisch generell ja geht zeigt ja der erfolgreiche Ping des FritzBox Interfaces. Vermutlich kannst du auch Drucker usw. im lokalen Netz pingen.
Gut, zwingende Voraussetzung sind natürlich die 2 wichtigsten Punkte:
- ALLE Geräte haben die FritzBox als Default Gateway eingetragen
- Die FritzBox hat eine statische Route: Zielnetz: 10.8.0.0 Subnetzmaske: 255.255.255.0 Gateway: 192.168.178.20 (NAS IP)
Eine hilfreiche und gute Lektüre für OpenVPN in einem Dual Stack Umfeld mit v4 und v6 ist auch das hier:
https://www.heise.de/select/ct/2018/13/1529374309620058
bzw.
https://www.heise.de/ratgeber/OpenVPN-Vernetzung-mit-IPv4-und-IPv6-41628 ...
tja.. mein Test bzgl. MTU Werte..
Wenn ich ein Ping mit Paketlänge 1492 (nach www.yahoo.com) abschicke, gehen alle verloren
Ping abgesetzt im Smartphone VPN Client geht bis max 1231
Ping direkt in LTE ohne VPN abgesetzt, geht irgendwas unter 1000
Ping in Windows abgesetzt geht max 1424 ohne Verlust
Meine Ethernet-Karte sagt 1500
In der Fritz-Box kann man zwar manuell einen Wert vorgeben, der scheint aber nicht benutzt zu werden.
AVM sagt laut Recherche: kann man nicht in der Box anpassen, die handelt optimalen Wert selber aus.
Hab ein Glasfaseranschluß, ist wohl 1500 vorgegeben ?
Und ich muß eine Aussage von oben revidieren: Surfen unter VPN geht doch nicht. Da waren wohl noch Seiten im Cache, die da angezeigt wurden. Nach Cache leeren bleiben auch alle Browserversuche hängen, so wie ich auch keine GUI von internen Gerätschaften aufrufen kann.
Und ja, ich kann auch den Drucker anpingen und tracen, aber nicht GUI
Wenn ich ein Ping mit Paketlänge 1492 (nach www.yahoo.com) abschicke, gehen alle verloren
Ping abgesetzt im Smartphone VPN Client geht bis max 1231
Ping direkt in LTE ohne VPN abgesetzt, geht irgendwas unter 1000
Ping in Windows abgesetzt geht max 1424 ohne Verlust
Meine Ethernet-Karte sagt 1500
In der Fritz-Box kann man zwar manuell einen Wert vorgeben, der scheint aber nicht benutzt zu werden.
AVM sagt laut Recherche: kann man nicht in der Box anpassen, die handelt optimalen Wert selber aus.
Hab ein Glasfaseranschluß, ist wohl 1500 vorgegeben ?
Und ich muß eine Aussage von oben revidieren: Surfen unter VPN geht doch nicht. Da waren wohl noch Seiten im Cache, die da angezeigt wurden. Nach Cache leeren bleiben auch alle Browserversuche hängen, so wie ich auch keine GUI von internen Gerätschaften aufrufen kann.
Und ja, ich kann auch den Drucker anpingen und tracen, aber nicht GUI
Das ist dann ein MTU Problem. Du musst dann die Tunnel MTU und die MSS in der OVPN Konfig anpassen.
1
Kaum macht man es richtig, schon funktioniert es...
Webseiten können jetzt aufgerufen werden.
Was hab ich gemacht ?
Auf der Synology unter Systemsteuerung/Netzwerk/Netzwerk-Schnittstelle
unter verbundenes LAN den MTU manuell einstellen, auf 1500.
Danach konnte ich den Haken auch wieder entfernen und es geht trotzdem weiterhin.
Auch nach Neustart der Synology.
Schon eigenartiges Verhalten. Vielleicht fehlte nur einmal das grundsätzliche Setzen oder Bug.
Wie auch immer.
Hab mich dann mal extern über (fremdes) WLAN verbunden (vorher immer nur über LTE).
Und siehe da, auch die lokalen Gerätschaften kann ich jetzt mit GUI erreichen.
Was weiterhin nicht ging, über die Mobilfunkverbindung direkt (LTE Vodafon) auf die internen Geräte zuzugreifen.
Also nochmal an die MTU und MSS ran, wie aqui geschrieben hat.
Hab mir auf der Seite https://www.speedguide.net/analyzer.php die Werte unter LTE ausgeben lassen.
MSS war 1460. Davon hab ich 28 Byte für "Overhead" abgezogen, ergab 1432.
Diesen Wert in der OVPN Config vom Client eingetragen. MTU hab ich bei 1500 gelassen.
Und schon läuft nun alles wie gewünscht...
Vielen Dank an @aqui für die Hilfestellung
Webseiten können jetzt aufgerufen werden.
Was hab ich gemacht ?
Auf der Synology unter Systemsteuerung/Netzwerk/Netzwerk-Schnittstelle
unter verbundenes LAN den MTU manuell einstellen, auf 1500.
Danach konnte ich den Haken auch wieder entfernen und es geht trotzdem weiterhin.
Auch nach Neustart der Synology.
Schon eigenartiges Verhalten. Vielleicht fehlte nur einmal das grundsätzliche Setzen oder Bug.
Wie auch immer.
Hab mich dann mal extern über (fremdes) WLAN verbunden (vorher immer nur über LTE).
Und siehe da, auch die lokalen Gerätschaften kann ich jetzt mit GUI erreichen.
Was weiterhin nicht ging, über die Mobilfunkverbindung direkt (LTE Vodafon) auf die internen Geräte zuzugreifen.
Also nochmal an die MTU und MSS ran, wie aqui geschrieben hat.
Hab mir auf der Seite https://www.speedguide.net/analyzer.php die Werte unter LTE ausgeben lassen.
MSS war 1460. Davon hab ich 28 Byte für "Overhead" abgezogen, ergab 1432.
Diesen Wert in der OVPN Config vom Client eingetragen. MTU hab ich bei 1500 gelassen.
Und schon läuft nun alles wie gewünscht...
Vielen Dank an @aqui für die Hilfestellung
Immer gerne...
👏 Glückwunsch das es klappt !
Das scheint ein generelles Problem bei NAS Systemen zu sein und tritt auch bei QNAP auf. Normal setzt man die MTU bei NAS höher um vom Jumbo Framing und besserer Performance zu profitieren.
Da es immer eine Layer 2 Path MTU Discovery gibt sollte das also auch bei VPN oder generell WAN Verbindungen kein Thema sein, ist es aber scheinbar nicht.
Ich hatte das schon bei fast allen Implementierungen gesehen die die NAS MTU vergrößert hatten das der VPN Zugriff dann nicht mehr klappt. Ein Rücksetzen auf 1500 hat dann alles gefixt.
Kann man nur vermuten das das wohl ein Bug in der NAS Firmware ist.
👏 Glückwunsch das es klappt !
Das scheint ein generelles Problem bei NAS Systemen zu sein und tritt auch bei QNAP auf. Normal setzt man die MTU bei NAS höher um vom Jumbo Framing und besserer Performance zu profitieren.
Da es immer eine Layer 2 Path MTU Discovery gibt sollte das also auch bei VPN oder generell WAN Verbindungen kein Thema sein, ist es aber scheinbar nicht.
Ich hatte das schon bei fast allen Implementierungen gesehen die die NAS MTU vergrößert hatten das der VPN Zugriff dann nicht mehr klappt. Ein Rücksetzen auf 1500 hat dann alles gefixt.
Kann man nur vermuten das das wohl ein Bug in der NAS Firmware ist.
