OpenVPN Erreiche Router nicht durch ping
Habe eine Verbindung aufgebaut zu meinem OpenVPN Server im Heimnetz von unterwegs aus.
Heimnetz:
Router 192.168.1.1
VPN Server PC 192.168.1.150 (Windows 10 Pro PC)
VPN Server IP 10.8.0.1
Ich kann mich verbinden aber kann den Router 192.168.1.1 nicht anpingen.
Komischerweise habe ich eine Route auf dem 150er pc setzen können so dass dieser angepingt werden kann.
Bei "Route Print" habe ich mit folgendem Befehl dies erreicht:
"route add 10.8.0.0 mask 255.255.255.0 10.8.0.1 IF 7"
Meine Server.conf:
port 443
proto udp4
dev tun
ca ca.crt
cert Mr.crt
key M.key
dh dh2048.pem
server 10.8.0.0 255.255.255.0
push "redirect-gateway def1"
push "route 192.168.1.0 255.255.255.0"
;push "dhcp-option DNS 8.8.8.8"
client-to-client
keepalive 10 120
cipher AES-128-CBC
comp-lzo
persist-key
persist-tun
status openvpn-status.log
verb 4
Meine client.conf
dev tun
proto udp4
remote xx.de 443 (xx durch meine dyndns-ip ersetzt)
ca ca1.crt
cert client1.crt
key client1.key
cipher AES-128-CBC
auth SHA1
resolv-retry infinite
nobind
persist-key
persist-tun
client
verb 3
comp-lzo
route 192.168.1.0 255.255.255.0
Das komische ist, dass es schon einmal funktioniert hat. aber jetzt nicht mehr.
"Routing und RAS" / "Remote Access" Dienst ist aktiv
den Regedit IPForward.... hab ich auf 1 gesetzt und danach neu gestartet.
Firewall auf dem 150er ist deaktiviert.
Statische Route auf dem Router ist eingerichtet.... aber so oder so sollte doch ein ping auf den Router möglich sein?
Kann jemand weiterhelfen woran dies liegen kann dass ich den Router nicht anpingen kann?
Wenn ich den Router anpingen kann sollte die statische route für das 10.8.0.0 Netz greifen können um auf das gesamte lan zugreifen zu können?!?
Danke
MfG
Heimnetz:
Router 192.168.1.1
VPN Server PC 192.168.1.150 (Windows 10 Pro PC)
VPN Server IP 10.8.0.1
Ich kann mich verbinden aber kann den Router 192.168.1.1 nicht anpingen.
Komischerweise habe ich eine Route auf dem 150er pc setzen können so dass dieser angepingt werden kann.
Bei "Route Print" habe ich mit folgendem Befehl dies erreicht:
"route add 10.8.0.0 mask 255.255.255.0 10.8.0.1 IF 7"
Meine Server.conf:
port 443
proto udp4
dev tun
ca ca.crt
cert Mr.crt
key M.key
dh dh2048.pem
server 10.8.0.0 255.255.255.0
push "redirect-gateway def1"
push "route 192.168.1.0 255.255.255.0"
;push "dhcp-option DNS 8.8.8.8"
client-to-client
keepalive 10 120
cipher AES-128-CBC
comp-lzo
persist-key
persist-tun
status openvpn-status.log
verb 4
Meine client.conf
dev tun
proto udp4
remote xx.de 443 (xx durch meine dyndns-ip ersetzt)
ca ca1.crt
cert client1.crt
key client1.key
cipher AES-128-CBC
auth SHA1
resolv-retry infinite
nobind
persist-key
persist-tun
client
verb 3
comp-lzo
route 192.168.1.0 255.255.255.0
Das komische ist, dass es schon einmal funktioniert hat. aber jetzt nicht mehr.
"Routing und RAS" / "Remote Access" Dienst ist aktiv
den Regedit IPForward.... hab ich auf 1 gesetzt und danach neu gestartet.
Firewall auf dem 150er ist deaktiviert.
Statische Route auf dem Router ist eingerichtet.... aber so oder so sollte doch ein ping auf den Router möglich sein?
Kann jemand weiterhelfen woran dies liegen kann dass ich den Router nicht anpingen kann?
Wenn ich den Router anpingen kann sollte die statische route für das 10.8.0.0 Netz greifen können um auf das gesamte lan zugreifen zu können?!?
Danke
MfG
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 459072
Url: https://administrator.de/forum/openvpn-erreiche-router-nicht-durch-ping-459072.html
Ausgedruckt am: 27.04.2025 um 16:04 Uhr
11 Kommentare
Neuester Kommentar
Das "route" Kommando auf dem Client ist eigentlich Unsinn, denn genau dieses Netzwerk wird ja per "push route..." vom Server auf den Client automatisch übertragen. Da es überflüssig ist kann es entfernt werden.
Ebenso das "push route..." Kommando ist überflüssiger Unsinn weil zuvor ja schon ein Gateway Redirect mit "push "redirect-gateway def1" eingerichtet wurde.
Das tunnelt dann so oder so den GESAMTEN Client Traffic in den Tunnel und nicht nur spezifisch das lokale LAN des Server. Doppelt gemoppelt und kontraproduktiv da nur entweder Redirect oder dedizierte Route mit push route !!
Beides ist unsinnig und klappt nicht.
Das das Pingen des jeweils lokalen LAN Interfaces fehlschlägt hat meist 2 Ursachen:
Einfacher und stromsparender ist es immer den OVPN Server mit einem kleinen Raspberry Pi zu realisieren !
https://jankarres.de/2013/05/raspberry-pi-openvpn-vpn-server-installiere ...
oder kleinen stromsparenden Minirouter auf OpenWRT Basis:
https://www.amazon.de/GL-iNet-GL-MT300N-V2-Repeater-Performance-Compatib ...
Das erspart einem immer die frickeligen Sonderlocken in der Winblows Konfig.
Noch sinnvoller und sicherer ist es natürlich den VPN Server auf den Router oder Firewall in der Peripherie zu legen !
OpenVPN Server installieren auf pfSense Firewall, Mikrotik. DD-WRT oder GL.inet Router
Ebenso das "push route..." Kommando ist überflüssiger Unsinn weil zuvor ja schon ein Gateway Redirect mit "push "redirect-gateway def1" eingerichtet wurde.
Das tunnelt dann so oder so den GESAMTEN Client Traffic in den Tunnel und nicht nur spezifisch das lokale LAN des Server. Doppelt gemoppelt und kontraproduktiv da nur entweder Redirect oder dedizierte Route mit push route !!
Beides ist unsinnig und klappt nicht.
Das das Pingen des jeweils lokalen LAN Interfaces fehlschlägt hat meist 2 Ursachen:
- Das VPN Tunnel Interface bekommt durch die fehlgeschlagene Windows netzwerk Autodetection das Profil Public. Das bewirkt das die Firewall sämtlichen eingehenden Traffic blockiert. Hier muss man also im Setup Firewall mit erweiterter Sicherheit das Profil auf Private umstellen und zwar auf Client und Server !
- ICMP Traffic (Ping Traceroute etc.) ist generell in der Winblows Firewall blockiert. Das muss man zwingend freischalten damit ICMP Pakete passieren können: https://www.windowspro.de/tipp/ping-windows-7-server-2008-r2-zulassen
- Eine wichtige Ursache kommt noch dazu wenn der VPN Server im lokalen Netzwerk hinter einem NAT Router läuft. Dort im Internet Router muss zwingend eine statische Route auf das interne OVPN IP Netz installiert werden:
- Weiterhin sehr wichtig ist das bei Windows IPv4 Forwarding (Routing) auf dem server aktiviert ist. Per default ist das deaktiviert ! https://www.edv-lehrgang.de/ip-routing-aktivieren/
Einfacher und stromsparender ist es immer den OVPN Server mit einem kleinen Raspberry Pi zu realisieren !
https://jankarres.de/2013/05/raspberry-pi-openvpn-vpn-server-installiere ...
oder kleinen stromsparenden Minirouter auf OpenWRT Basis:
https://www.amazon.de/GL-iNet-GL-MT300N-V2-Repeater-Performance-Compatib ...
Das erspart einem immer die frickeligen Sonderlocken in der Winblows Konfig.
Noch sinnvoller und sicherer ist es natürlich den VPN Server auf den Router oder Firewall in der Peripherie zu legen !
OpenVPN Server installieren auf pfSense Firewall, Mikrotik. DD-WRT oder GL.inet Router
ich bin aber am vermuten dass diese nicht funktioniert weil vielleicht der Router spinnt.
Wäre recht ungewöhnlich aber warum nimmst du dir nicht einen kostenlosen Wireshark Sniffer an die Hand und prüfst das selber direkt in deinem Netz ??https://www.wireshark.org/#download
Da kannst du doch mit einem simplen Ping auf die 10.8.0.1 sehen ob diese ICMP Ping Pakete am OVPN Server ankommen !!! So kannst du in 3 Minuten verifizieren ob die statische Route greift oder nicht.
Syntaktisch richtig ist sie aber in jedem Falle !
Das komische ist ja, dass ich den 192.168.1.150 ping mit 10ms zurückkriege.
Von wo ??Ohne das du sagst von WO du pingst ist diese Aussage sinnfrei.
Nehmen wir mal an du pingst von einem aktiven OVPN Client. Das wäre dann schon mal ein gutes Zeichen !
Es zeigt:
- a. Das der Tunnel erforlgreich aufgebaut ist
- b. Das das Routing auf dem OVPN Server klappt, denn das ist ja sein LAN Interface
- c. Das du generell das lokale LAN 192.168.0.0 /24 erreichen kannst !
Sinnvoll ist es erstmal z.B. den Internet Router (vermutlich) mit der 192.168.0.1 zu pingen.
Oder einen Drucker oder irgendwas ohne Firewall und was als Default Gateway die 192.168.0.1 eingestellt hat.
Noch sinnvoller wäre es mal einen Rechner im 192.168.0.0er Netz zu pingen der einen Wireshark am Laufen hat !!!
Dann kannst du wieder live die eingehenden Pakete vom VPN Client sehen und checken wie Endgeräte darauf reagieren. Kannst du die Pakete z.B. nicht sehen schlägt die Windows Firewall zu !
kann dafür aber mehr als ein RaspPie und ich nutze ihn auch für mehrere sachen wie Streaming usw.
Das ist natürlich laienhafter Unsinn, denn das kann ein RasPi auch.Z.B. Fehlersuche im lokalem Netzwerk (RSTP, MRP, Multicast)
Aber egal...so oder so sollte es mit der Box auch klappen wenn man alles richtig macht.
Der Raspberry Pie braucht sicher auch 5 oder 10 Watt mindestens??!?!
https://www.heise.de/ct/artikel/Raspberry-Pi-3-Leistungsaufnahme-und-Cor ...Und die Stromverbraucher wie Festplatten
Der Raspberry hat keine Festplatte !! Er nutzt eine SD Karte als Speicher, hat also gleich eine SSD an Bord wenn du so willst. Zeigt aber eher das du dich noch nie mit einem RasPi beschäftigt hast was schade ist. So können Winblows Knechte mal ihren Horizont erweitern für kleines Geld !Aber wie bereits gesagt ist das erstmal nebensächlich, denn es klappt natürlich auch unter Winblows problemlos.
Kenne mich aber nicht damit aus und kann auch aus google anleitungen/tutorials nicht schlau werden.
Eigentlich kinderleicht, man muss ja nur auf die IP Adressen sehen um zu wissen was da kommt !Guckst du hier:
https://www.heise.de/ct/artikel/Fehler-erschnueffeln-221587.html
Was müsste denn angezeigt werden bei Source und Destination wenn ich von
Nicht dein Ernst oder...?? Source(Absender): 10.0.8.0.6 Destination(Ziel): 192.168.1.1 Protokoll: ICMP Echo Request
Das kannst du aber vergessen, denn das ist ein Paket was der Wireshark Rechner dir nicht anzeigt, denn es kommt ja an ihm selber gar nicht vorbei ! Mal nachdenken bitte....
Der OVPN Server schickt das ja dann direkt an den Router sprich vom OVPN Server Switchport direkt an den Router Switchport ohne das dein Wireshar rechner Switchport das "sieht" !
Pinge mal die IP Adresse des Wireshark Rechners an, dann "siehst" du das eingehende ICMP Echo Request Paket vom OVPN Client.
Darauf solltest du dann einen ICMP Echo Reply von deinem Wireshark Rechner sehen !
Source(Absender): 192.168.1.1 Destination(Ziel): 10.0.8.6 Protokoll: ICMP Echo Reply
Dazu sollte natürlich im Wireshark Rechner dann ICMP Pakete in der Winblows Firewall freigeschaltet sein !
https://www.windowspro.de/tipp/ping-windows-7-server-2008-r2-zulassen
(Siehe oben)
Kannst ja auch immer mal erst lokal üben und mit einem lokalen PC (OVPN Server) den Wireshark PC anpingen. Auch da siehst du dann diese Pakete. Nur um mal zu sehen wie die aussehen und mal reinzusehen
Wenn du Traffic eines Endgerätes sehen willst musst du entweder mit einem Mirror Port (Spiegel Port) am Switch arbeiten oder über eine Bridge sniffern. Ersteres müsste dein Switch supporten.
Letzteres geht so:
https://www.heise.de/ct/artikel/Ethernet-Bridge-als-Sniffer-Quelle-22148 ...
Dazu brauchst du dann einen 2ten NIC Adapter z.B. als USB:
https://www.amazon.de/AmazonBasics-Ethernet-LAN-Netzwerkadapter-USB-2-0- ...
iCh traue mich aktuell nicht den kompletten log davon beim ping hier rein zu schreiben
Screenshot Bild (Snipping Tool) des Fensters mit den relevanten Paketen reicht vollkommen.Du kannst auch im Display Filter nur diese Pakete rausfiltern für die Anzeige (ICMP)
OK, der erste Screenshot besagt nichts. Der sagt lediglich das das 10.8.0.6 Interface mit einer öffentlichen 74er und 172er IP per TCP kommuniziert.
Leider nicht welchen TCP Port deshalb erkennt man die Anwendung nicht. Das ist aber definitv kein ICMP Ping !
Der kommt am ersten Screenshot nicht an ! Weder Request noch Reply.
2ter Screenshot ist da schon besser !
Du kannst sehen das der Client 10.8.0.6 ein Ping Request an die 192.168.1.1 schickt, dieser aber nicht antwortet !
Dort müsste dann immer bbwechselnd auf einen Request dann ein Reply von der .1.1 and den 10.8.0.6 zu sehen sein.
Fazit: die 192.168.1.1 antwortet nicht auf den Ping und ist stumm ! Da stimmt also was nicht.
Was ist die .1.1 ? Ein Router ?
Wenn ja kann es sein das da ggf. ein Filter aktiv ist der ICMP (Ping) verbietet ? Gibt es manchmal auf Routern.
Deine statische Route oben stimmt soweit auch laut Screenshot.
Kann es evtl. sein das man die noch irgendwie separat aktivieren muss nach dem Einrichten ?
Leider nicht welchen TCP Port deshalb erkennt man die Anwendung nicht. Das ist aber definitv kein ICMP Ping !
Der kommt am ersten Screenshot nicht an ! Weder Request noch Reply.
2ter Screenshot ist da schon besser !
Du kannst sehen das der Client 10.8.0.6 ein Ping Request an die 192.168.1.1 schickt, dieser aber nicht antwortet !
Dort müsste dann immer bbwechselnd auf einen Request dann ein Reply von der .1.1 and den 10.8.0.6 zu sehen sein.
Fazit: die 192.168.1.1 antwortet nicht auf den Ping und ist stumm ! Da stimmt also was nicht.
Was ist die .1.1 ? Ein Router ?
Wenn ja kann es sein das da ggf. ein Filter aktiv ist der ICMP (Ping) verbietet ? Gibt es manchmal auf Routern.
Deine statische Route oben stimmt soweit auch laut Screenshot.
Kann es evtl. sein das man die noch irgendwie separat aktivieren muss nach dem Einrichten ?
Der OVPN Server war hinter einer WDS Bridge (Router als Repeater eingesetzt)
Igitt, Repeating ist der letzte Schrott !! Halbiert prinzipienbedingt die schon schwache WLAN Bandbreite und das daraus dann resultierende erhöhte Hidden Station Problem gibt dem WLAN dann den Rest.Vergiss sowas.... Sinn macht dann nur ein Kabel basiertes strukturiertes WLAN wo die APs über ein Kabelnetzwerk verbunden sind.
Wenn man das partout nicht verlegen kann nimmt man Power LAN aber niemals Repating. Siehe hier:
Kopplung von 2 Routern am DSL Port
Glückwunsch wenns nun alles klappt wie es soll. War ja eine schwere Geburt mit dir