31
Diskstation als VPN-Zugang hinter Fritzbox
Hallo zusammen,
ich administriere des Netzwerk einer kleinen Firma mit einer Aussenstelle, im Haupthaus steht ein Windowsserver mit einer VM als OpenVPN-Server.
Der ist für alle externen Clients auch gut erreichbar, jetzt habe ich mir die Aufgabe gestellt, unsere Aussenstelle über enen Tunnel permanent mit dem Hauptnetzwerk zu verbinden. Hier fungiert eine Fritzbox als Modem und Router, als Lokaler Server dient eine Synology DS218+.
Jetzt habe ich die DS per OPENVPN mit dem Hauptnetzverbunden, in der FRitze ein Routing gesetzt, dass alle Anfragen an das Hauptnetz über die DS leitet.
Da ich nicht immer Vorort bin, habe ich das ganze per VPN zur Fritzbox eingerichtet und jetzt wirddie Sache kurios. Verbinde ich mich aus dem Homeoffice per Fritz-VPN mit der Aussenstelle kann ich den VPN-Tunne ins Haupthaus nutzen, bin ich dagegen in der Aussenstelle so ist die Verbindung nicht nutzbar.
Dort eine OPenVPN-Verbindung als Client auf zubauen ist kein Problem, aber dafür sollte ja eigentlich der Tunnel da sein...
Vieleicht hat hier jemand einen Tip dazu, gerne kann ich auch tiefergehende Fragen beantworten.
Gruß
Skipper
ich administriere des Netzwerk einer kleinen Firma mit einer Aussenstelle, im Haupthaus steht ein Windowsserver mit einer VM als OpenVPN-Server.
Der ist für alle externen Clients auch gut erreichbar, jetzt habe ich mir die Aufgabe gestellt, unsere Aussenstelle über enen Tunnel permanent mit dem Hauptnetzwerk zu verbinden. Hier fungiert eine Fritzbox als Modem und Router, als Lokaler Server dient eine Synology DS218+.
Jetzt habe ich die DS per OPENVPN mit dem Hauptnetzverbunden, in der FRitze ein Routing gesetzt, dass alle Anfragen an das Hauptnetz über die DS leitet.
Da ich nicht immer Vorort bin, habe ich das ganze per VPN zur Fritzbox eingerichtet und jetzt wirddie Sache kurios. Verbinde ich mich aus dem Homeoffice per Fritz-VPN mit der Aussenstelle kann ich den VPN-Tunne ins Haupthaus nutzen, bin ich dagegen in der Aussenstelle so ist die Verbindung nicht nutzbar.
Dort eine OPenVPN-Verbindung als Client auf zubauen ist kein Problem, aber dafür sollte ja eigentlich der Tunnel da sein...
Vieleicht hat hier jemand einen Tip dazu, gerne kann ich auch tiefergehende Fragen beantworten.
Gruß
Skipper
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: 1615093421
Url: https://administrator.de/contentid/1615093421
Printed on: April 24, 2024 at 11:04 o'clock
31 Comments
Latest comment
Hast du wirklich alles so umgesetzt wie es in diesem Tutorial beschrieben ist ?!
Merkzettel: VPN Installation mit OpenVPN
bzw. bei einer Site to Site:
OpenVPN - Erreiche Netzwerk hinter Client nicht
Für ein Firmennetz krankt deine VPN Lösung an der sicherheitstechnischen Problkematik das du einen internen VPN Server betreibst und damit dann immer ungeschützten Traffic in dein internes Netzwerk lässt. Sowas mal für ein Laien- oder Heimnetz ggf. tolerabel sein für ein Firmennetz ist das ein NoGo. Das dannoch in einer VM auf einem internen Hypervisor muss man siche rnicht noch weiter kommentieren.
VPNs gehören deshalb aus guten Gründen immer in die Peripherie auf dediziertes Blech wie Router oder Firewall wie man es als Firmen Netzwerk Administrator auch wissen sollte.
Wenn du mit der mickrigen VPN Performance der FritzBox leben kannst stellt sich daher die Frage warum du solch einen Unsinn mit der Fricklei von 2 verschiedenen VPN Protokollen bzw. Verfahren machst und nicht alles einheitlich auf der FB abfackelst was sicher das Sinnvollste hier wäre.
Oder die FritzBox sinnigerweise gegen einen vernünftigen Firmenrouter oder Firewall zu ersetzen der den Namen auch verdient statt mit einer billigen Consumer Plastebox zu arbeitet die in einem Firmennetz da eigentlich nicht hingehört !
Diese tiefergehenden Fragen hättest du dir eigentlich schon längst vorher überlegen sollen wenn man ein VPN Design vernünftig angeht.
Wie man sowas vernünftig im Firmenumfeld löst erklären dir die zahllosen VPN Tutorials hier im Forum !
Merkzettel: VPN Installation mit OpenVPN
bzw. bei einer Site to Site:
OpenVPN - Erreiche Netzwerk hinter Client nicht
bin ich dagegen in der Aussenstelle so ist die Verbindung nicht nutzbar.
Wie immer die statische Route auf das interne OpenVPN Netz oder das remote Site-to-Site Netz dort vergessen einzuragen. Traceroute ist hier wie immer des Admins bester Freund !Für ein Firmennetz krankt deine VPN Lösung an der sicherheitstechnischen Problkematik das du einen internen VPN Server betreibst und damit dann immer ungeschützten Traffic in dein internes Netzwerk lässt. Sowas mal für ein Laien- oder Heimnetz ggf. tolerabel sein für ein Firmennetz ist das ein NoGo. Das dannoch in einer VM auf einem internen Hypervisor muss man siche rnicht noch weiter kommentieren.
VPNs gehören deshalb aus guten Gründen immer in die Peripherie auf dediziertes Blech wie Router oder Firewall wie man es als Firmen Netzwerk Administrator auch wissen sollte.
Wenn du mit der mickrigen VPN Performance der FritzBox leben kannst stellt sich daher die Frage warum du solch einen Unsinn mit der Fricklei von 2 verschiedenen VPN Protokollen bzw. Verfahren machst und nicht alles einheitlich auf der FB abfackelst was sicher das Sinnvollste hier wäre.
Oder die FritzBox sinnigerweise gegen einen vernünftigen Firmenrouter oder Firewall zu ersetzen der den Namen auch verdient statt mit einer billigen Consumer Plastebox zu arbeitet die in einem Firmennetz da eigentlich nicht hingehört !
Diese tiefergehenden Fragen hättest du dir eigentlich schon längst vorher überlegen sollen wenn man ein VPN Design vernünftig angeht.
Wie man sowas vernünftig im Firmenumfeld löst erklären dir die zahllosen VPN Tutorials hier im Forum !
Übersetzung: Das musst Du erstmal (auch gedanklich) ordnen. Ich verstehe Dich so:
1. Du hast die DS in der Außenstelle als OVPN-Client mit dem OVPN-Server im Haupthaus verbunden
2. Du verbindest Dich zur Außenstelle über FB-VPN (IPSec)
3. Aus dem Netz der Außenstelle hast Du keine VPN-Verbindung ins Haupthaus
4. Aus dem VPN-der FB kommst Du über die Außenstelle ins Haupthaus
so korrekt?
Bitte zeichne das (auch für Dich) doch mal sauber auf, mit IPs und Bezeichnung der eingebundenen Geräte sowie Ausgabe der Config und den Routingtabellen, dann wirst Du (oder einer der Kollegen hier) vielleicht das Problem lösen können. Auf den ersten Blick sieht es ja so (seltsam) aus, als ob das Routing aus dem Außenstellen-Netz nicht funktioniert, aus dem FB-VPN aber schon.
Die vom Kollegen @aqui bemängelte Frickelei mit einem zweiten VPN über die Fritzbox könntest Du Dir sparen, wenn Du die DS als VPN-Server eingerichtet hättest und den Tunnel (als weiteren Tunnel natürlich) vom HH aus aufbaust. Dann bleibt aber das Problem der Platzierung des VPN-Gerätes.
Hierzu
@aqui folgende Frage:
Welches Risiko siehst Du hier konkret? Mir ist Dein Ansatz schon klar und ich halte ihn auch für besser, aber
a) VServer stehen nun überall im Internet und werden, wenn geschützt und gewartet, auch nicht ständig übernommen. Warum also nicht VPN oder Firewall virtuell terminieren? Das Gerät gehört dann (wenn nicht selbst Firewall) natürlich in eine eigene DMZ und nicht hinter eine Fritzbox.
b) welche Gefahr ergibt sich konkret bei dem Szenario "ungeschützter Traffic im internen Netz"? Wenn das Peripherie-VPN-Gerät gehackt wird, ist der Angreifer doch genauso im Netz, wie beim Hacken des internen Gerätes (oder sogar schlimmer)? Der von Dir beklagte "ungeschützte" Traffic selbst kann ja nichts weiter ausrichten, als das Gerät kompromittieren. Deshalb erscheint mir der Aspekt wichtiger, ein sicheres Gerät zu verwenden, egal wo das terminiert. DS und Windows-VM scheiden da natürlich begriffslogisch aus
Aber hier ist es eine kleine Firma, die vielleicht keine große Sicherheit braucht (und sicher ein super-Backup hat), da kann man die Hardware vielleicht auch vertreten.
Viele Grüße, commodity
1. Du hast die DS in der Außenstelle als OVPN-Client mit dem OVPN-Server im Haupthaus verbunden
2. Du verbindest Dich zur Außenstelle über FB-VPN (IPSec)
3. Aus dem Netz der Außenstelle hast Du keine VPN-Verbindung ins Haupthaus
4. Aus dem VPN-der FB kommst Du über die Außenstelle ins Haupthaus
so korrekt?
Bitte zeichne das (auch für Dich) doch mal sauber auf, mit IPs und Bezeichnung der eingebundenen Geräte sowie Ausgabe der Config und den Routingtabellen, dann wirst Du (oder einer der Kollegen hier) vielleicht das Problem lösen können. Auf den ersten Blick sieht es ja so (seltsam) aus, als ob das Routing aus dem Außenstellen-Netz nicht funktioniert, aus dem FB-VPN aber schon.
Die vom Kollegen @aqui bemängelte Frickelei mit einem zweiten VPN über die Fritzbox könntest Du Dir sparen, wenn Du die DS als VPN-Server eingerichtet hättest und den Tunnel (als weiteren Tunnel natürlich) vom HH aus aufbaust. Dann bleibt aber das Problem der Platzierung des VPN-Gerätes.
Hierzu
@aqui folgende Frage:
Welches Risiko siehst Du hier konkret? Mir ist Dein Ansatz schon klar und ich halte ihn auch für besser, aber
a) VServer stehen nun überall im Internet und werden, wenn geschützt und gewartet, auch nicht ständig übernommen. Warum also nicht VPN oder Firewall virtuell terminieren? Das Gerät gehört dann (wenn nicht selbst Firewall) natürlich in eine eigene DMZ und nicht hinter eine Fritzbox.
b) welche Gefahr ergibt sich konkret bei dem Szenario "ungeschützter Traffic im internen Netz"? Wenn das Peripherie-VPN-Gerät gehackt wird, ist der Angreifer doch genauso im Netz, wie beim Hacken des internen Gerätes (oder sogar schlimmer)? Der von Dir beklagte "ungeschützte" Traffic selbst kann ja nichts weiter ausrichten, als das Gerät kompromittieren. Deshalb erscheint mir der Aspekt wichtiger, ein sicheres Gerät zu verwenden, egal wo das terminiert. DS und Windows-VM scheiden da natürlich begriffslogisch aus
Aber hier ist es eine kleine Firma, die vielleicht keine große Sicherheit braucht (und sicher ein super-Backup hat), da kann man die Hardware vielleicht auch vertreten.
Viele Grüße, commodity
Du hast Recht. Der OpenVPN Server könnte in einem separaten Segment stehen. Ist aber nur wild geraten weil der TO keinerlei Angaben dazu macht ob er eine sinnvolle (und sichere) Segementierung im vSwitch des Hypervisors etabliert hat.
War auch eher auf die Installation des OpenVPN Servers im Haupthaus bezogen denn der befindet sich im internen Netz. Gut, der TO hat nicht gesagt wo und da gäbe es die DMZ. Ggf. etwas vorschnell also ohne das Layer 3 Design des TO genau zu kennen, da hast du Recht. Ein VPN Server in einem produktiven internen LAN birgt aber ein hohes Risiko und ist kein gutes VPN Design. Da gilt in der Tat das Thema sicheres Gerät.
Es bezog sich nicht auf die Zweigstelle, denn dort werkelt VPN technisch ja vermutlich eh einzig nur die Fritze und sonst nix (geraten).
War auch eher auf die Installation des OpenVPN Servers im Haupthaus bezogen denn der befindet sich im internen Netz. Gut, der TO hat nicht gesagt wo und da gäbe es die DMZ. Ggf. etwas vorschnell also ohne das Layer 3 Design des TO genau zu kennen, da hast du Recht. Ein VPN Server in einem produktiven internen LAN birgt aber ein hohes Risiko und ist kein gutes VPN Design. Da gilt in der Tat das Thema sicheres Gerät.
Es bezog sich nicht auf die Zweigstelle, denn dort werkelt VPN technisch ja vermutlich eh einzig nur die Fritze und sonst nix (geraten).
Nein, nein, ich meinte überhaupt nicht, dass Du da falsch liegen könntest. Bei den beschriebenen Netzen wird (derzeit) ganz bestimmt nicht segmentiert. Das kann man schon reinlesen.
Meine Frage bezog sich vor allem darauf,
a) warum Du meinst, Virtualisierung sei prinzipiell unsicherer als Blech und
b) warum Du meinst, ein internes (sicheres) Gerät fürs VPN sei gefährlicher als ein Gerät auf der Peripherie.
Habe beides schon oft von Dir gelesen, kann es technisch aber nur zum Teil nachvollziehen und würde es gern richtig verstehen.
(Gedanke: Ein gepflegtes Raspbian mit einer einzigen Aufgabe ist vielleicht sogar deutlich sicherer als manch kommerzielle "ichkannalles"-Firewall, die VPN mehr so nebenbei macht). Blech hin, Peripherie her.
Viele Grüße, commodity
Meine Frage bezog sich vor allem darauf,
a) warum Du meinst, Virtualisierung sei prinzipiell unsicherer als Blech und
b) warum Du meinst, ein internes (sicheres) Gerät fürs VPN sei gefährlicher als ein Gerät auf der Peripherie.
Habe beides schon oft von Dir gelesen, kann es technisch aber nur zum Teil nachvollziehen und würde es gern richtig verstehen.
(Gedanke: Ein gepflegtes Raspbian mit einer einzigen Aufgabe ist vielleicht sogar deutlich sicherer als manch kommerzielle "ichkannalles"-Firewall, die VPN mehr so nebenbei macht). Blech hin, Peripherie her.
Viele Grüße, commodity
Moin,
Danke schonmal für erste Kommentare, ja, die Lösung ist nicht die Besste, mein Problem ist dabei, das ich einen GF habe der IT für überteuerte spielerei pickeliger Nerds hält. Zusätzlich irgend einen Bekannten hat der ihm jeden Vorschalg von mir oder angefragten Systemhäusern bewerten läßt, was jedes Projekt im Kern erstickt.
Ja, Hardwarelösung mit zwei Securepoint Geräten war mein Favorit, gibt da sicher noch andere Lösungen.
Ich werde das ganze nochmal grafisch versuchen darzustellen, dauert etwas, aber auch Rom wurde ja nicht an einem Tag gebaut.
Ich mach die IT hier auch nur neben meiner eigentlichen Tätigkeit, habe da also auch eine lange Lernkurve und verstehe sicher nicht alle üblichen Fachwörter, werde dann sicher nochmals nachfragen.
Gruß
Skipper
Danke schonmal für erste Kommentare, ja, die Lösung ist nicht die Besste, mein Problem ist dabei, das ich einen GF habe der IT für überteuerte spielerei pickeliger Nerds hält. Zusätzlich irgend einen Bekannten hat der ihm jeden Vorschalg von mir oder angefragten Systemhäusern bewerten läßt, was jedes Projekt im Kern erstickt.
Ja, Hardwarelösung mit zwei Securepoint Geräten war mein Favorit, gibt da sicher noch andere Lösungen.
Ich werde das ganze nochmal grafisch versuchen darzustellen, dauert etwas, aber auch Rom wurde ja nicht an einem Tag gebaut.
Ich mach die IT hier auch nur neben meiner eigentlichen Tätigkeit, habe da also auch eine lange Lernkurve und verstehe sicher nicht alle üblichen Fachwörter, werde dann sicher nochmals nachfragen.
Gruß
Skipper
Da bin ich jetzt aber froh, dass Dein Chef ein vernünftiger Kaufmann ist. In der IT wird viel zu viel Geld für miese Hardware verbrannt, die dann niemand vernünftig einrichtet/wartet. Wenn Du Freude dran hast, lerne weiter und wenn der Chef Dir dafür Raum gibt, ist das ein deutlich sinnvollerer Weg.
Viele Grüße, commodity
Viele Grüße, commodity
einen GF habe der IT für überteuerte spielerei pickeliger Nerds hält.
Schalte mal einen Tag das Netzwerk ab. Sowas hilft bei solchen Heinis (vernüftige Kaufmänner sind was anderes !) meist umfassend. Ein GF der heute solche Einstellung zur Infrastruktur hat die eine Firma am Leben hält ist nicht mehr zeitgemäß. Muss man sicher auch nicht mehr weiter kommentieren sowas... Kollege @commodity hat ja schon alles dazu gesagt !
Hallo zusammen,
ja, über den mannischen Sparzwang meines GFs könnte ich stundenlang lamentieren, hilft mir nur leider nicht weiter, bisher habe ich es geschaft mit einem fast nicht vorhandenen Budget die IT am laufen zu halten. Dazu habe icm ir stück für Stück das nötige Wissen angeeignet, aber sicher gibt es auch Lücken, die sich jetzt rächen.
Ich habe mal versucht das Netzwerk darzustellen, als Basis die Darstellung aus dem von aqui erwähnten Tutorial.
Bei einer Routingeinstellung werde ich sicher etwas übersehen haben, nur was?
Die Fritz VPN-Verbindung habe ich eigentlich nur aufgebaut um externen Technikern zugriff auf Anlagen innerhalb der Aussenstelle zu gewähren, wäre sicher über den OpenVPN Server innerhalb der DS cleverer, ich habe das nur nie zum laufen bekommen und wie immer drängt in solchen Fälle die Zeit und man braucht schnell etwas.
Da die Daten im HH liegen und auch andere Clients einzelne VPN-Verbindungen dorthin aufbauen, die keinen Zugriff zur Aussenstelle benötigen ist ein Verlagern des VPN Servers kein Thema.
ja, über den mannischen Sparzwang meines GFs könnte ich stundenlang lamentieren, hilft mir nur leider nicht weiter, bisher habe ich es geschaft mit einem fast nicht vorhandenen Budget die IT am laufen zu halten. Dazu habe icm ir stück für Stück das nötige Wissen angeeignet, aber sicher gibt es auch Lücken, die sich jetzt rächen.
Ich habe mal versucht das Netzwerk darzustellen, als Basis die Darstellung aus dem von aqui erwähnten Tutorial.
Bei einer Routingeinstellung werde ich sicher etwas übersehen haben, nur was?
Die Fritz VPN-Verbindung habe ich eigentlich nur aufgebaut um externen Technikern zugriff auf Anlagen innerhalb der Aussenstelle zu gewähren, wäre sicher über den OpenVPN Server innerhalb der DS cleverer, ich habe das nur nie zum laufen bekommen und wie immer drängt in solchen Fälle die Zeit und man braucht schnell etwas.
Da die Daten im HH liegen und auch andere Clients einzelne VPN-Verbindungen dorthin aufbauen, die keinen Zugriff zur Aussenstelle benötigen ist ein Verlagern des VPN Servers kein Thema.
Bei einer Routingeinstellung werde ich sicher etwas übersehen haben, nur was?
Die zwei statischen Routen am Router 1 für das interne OVPN Netz und das remote Netz.Merkzettel: VPN Installation mit OpenVPN
Moin Skipper,
you made my day dankeschön
darf ich den Satz hier im Haus in einer Präsentation verwenden, bitte ?
Zitat: mein Problem ist dabei, das ich einen GF habe der IT für überteuerte Spielerei pickeliger Nerds hält.
gruss ulti
you made my day dankeschön
darf ich den Satz hier im Haus in einer Präsentation verwenden, bitte ?
Zitat: mein Problem ist dabei, das ich einen GF habe der IT für überteuerte Spielerei pickeliger Nerds hält.
gruss ulti
Zuvor dann aber noch schnell die Rechtschreibung korrigieren:
https://www.duden.de/rechtschreibung/manisch
https://www.duden.de/rechtschreibung/manisch
Zitat von @aqui:
Die zwei statischen Routen am Router 1 für das interne OVPN Netz und das remote Netz.
Bei einem Client to Site - Aufbau ist das nicht nötig, hatten wir hier schon öfter. Client to Site macht OVPN NAT, deshalb werden im Zielnetz immer alle Clients erreicht, auch ohne Routing.Die zwei statischen Routen am Router 1 für das interne OVPN Netz und das remote Netz.
Sehr hübsch ist das dargestellt hier (auch gleich mit Differenzierung zum (natürlich für das Szenario ohnehin sinnvolleren Site to Site-Aufbau): https://openvpn.net/vpn-server-resources/reach-openvpn-clients-directly- ...
Wenn die Route im Zielnetz notwendig wäre, erklärte dies auch nicht den Umstand, dass ein über das FB-VPN zum OVPN-Client ins Zielnetz verbundener Client kommunizieren kann. Ich glaube daher, im Quellnetz ist etwas nicht korrekt konfiguriert, kann aber - trotz einigen Grübelns - leider nicht auflösen, was das ist.
Der OVPN-Client ist in einem Client to Site - Szenario aber bestimmt auch gar nicht dafür gemacht, Pakete von anderen Rechnern im Netz weiter zu leiten. ER allein ist als Quelle des Datenverkehrs vorgesehen. Dass da ein Tunnel existiert heißt noch nicht, dass andere Clients diesen unproblematisch nutzen können. Vielleicht liegt da schon das Problem. Irgendwie werden die Pakete aus dem FB-VPN aber dennoch weiter geleitet.
Mein (sehr vager) Erklärungsansatz ist, dass der OVPN-Client die Pakete auf dem Rückweg nicht routet, sondern an das Gateway (die Fritzbox) zustellt, so dass die Fritzbox sie noch verarbeiten (ins eigene VPN schicken) kann, nicht jedoch weiter ins Clientnetz schickt. Aber das ist nur eine Idee und vielleicht auch völlig falsch. Wireshark wäre da ein hilfreicher Freund.
Umgehen kannst (und musst) Du, @Skipper71 das Problem mit einem ordentlichen Site to Site Aufbau (mit Routen auf beiden Seiten), wie von @aqui im Tutorial und auch im obigen Link beschrieben.
Viele Grüße, commodity
Edit: Weil ich die Bilder so gut finde, hier auch noch die Quelle von OVPN zum Site to Site - Aufbau. Zwar für den "Access Server", aber das ändert nichts am Aufbau.
Moin Ultiman,
bringt mich zwar kein Stück weiter, aber wenn es deinen Tag rettet, kannst du das Zitat gerne weiter verwenden, für mich ist es leider Realität.
Wer Rechtschreibfehler findet, darf sie gerne behalten...
bringt mich zwar kein Stück weiter, aber wenn es deinen Tag rettet, kannst du das Zitat gerne weiter verwenden, für mich ist es leider Realität.
Wer Rechtschreibfehler findet, darf sie gerne behalten...
Ich glaube, er ist ein Leidensgenosse und wollte damit sein Mitgefühl ausdrücken.
Viele Grüße, commodity
Viele Grüße, commodity
OpenVPN Site-to-Site auch hier:
OpenVPN - Erreiche Netzwerk hinter Client nicht
Oder als Kaskade
Zugriff auf Gerät an LTE Router via VPN
OpenVPN - Erreiche Netzwerk hinter Client nicht
Oder als Kaskade
Zugriff auf Gerät an LTE Router via VPN
okay konstruktiv würde ich nach
"asynchronem routing" suchen, das passt zum Fehlerbild
also "hin"routing und "rück"routing aufmalen und dann an allen beteiligten kontrollieren / tracert , route print oder ähnl.
VG
ulti
"asynchronem routing" suchen, das passt zum Fehlerbild
also "hin"routing und "rück"routing aufmalen und dann an allen beteiligten kontrollieren / tracert , route print oder ähnl.
VG
ulti
Moin,
ich habe noch etwas rum probiert, mir scheint das routing der Fritze arbeitet nicht korrekt, eingestellt ist (Beispieldaten)
Ziel: 192.168.1.0/24 Gateway 192.168.100.254
Wenn ich von einem Client im Netz ein Tracert auf 192.168.1.254 sende kommt die Meldung "Zielhost nicht erreichbar"
stelle ich auf dem Client das gleiche Routing ein, erreiche ich den Zielhost mit dem Zwischenschritten 192.168.100.254 - 192.168.1.1
Soweit so gut, was ich jetzt so garnicht verstehe ist warum die Fritze bei einer von aussen eingehenden VPN-Verbindung auf selbige das Routing korrekt nutzt?
Ich werde das mal mit dem Support von AVM diskutieren...
ich habe noch etwas rum probiert, mir scheint das routing der Fritze arbeitet nicht korrekt, eingestellt ist (Beispieldaten)
Ziel: 192.168.1.0/24 Gateway 192.168.100.254
Wenn ich von einem Client im Netz ein Tracert auf 192.168.1.254 sende kommt die Meldung "Zielhost nicht erreichbar"
stelle ich auf dem Client das gleiche Routing ein, erreiche ich den Zielhost mit dem Zwischenschritten 192.168.100.254 - 192.168.1.1
Soweit so gut, was ich jetzt so garnicht verstehe ist warum die Fritze bei einer von aussen eingehenden VPN-Verbindung auf selbige das Routing korrekt nutzt?
Ich werde das mal mit dem Support von AVM diskutieren...
Du hast vermutlich übersehen das du die zu routenden Netzwerke hinter der FritzBox in deren VPN Konfig angeben musst (Phase 2 SA bei IPsec).
VPN Zugang mit einem VPN Client (z.B. Fernzugang oder Shrew):
https://avm.de/service/vpn/praxis-tipps/mit-fritzfernzugang-auf-mehrere- ...
Site-to-Site VPN:
https://avm.de/service/vpn/praxis-tipps/ueber-vpn-verbindung-zwischen-zw ...
VPN Zugang mit einem VPN Client (z.B. Fernzugang oder Shrew):
https://avm.de/service/vpn/praxis-tipps/mit-fritzfernzugang-auf-mehrere- ...
Site-to-Site VPN:
https://avm.de/service/vpn/praxis-tipps/ueber-vpn-verbindung-zwischen-zw ...
Hmm, das hat sicher Auswirkungen auf das Verhalten bei einer VPN-Verbindung zum Fritzbox-Netzwerk von außen, aber mein Problem besteht ja hauptsächlich von Innen. Wenn ich aus dem Homeoffice mich per VPN mit der Fritze Verbinde habe ich ja seltsamer weise beide Netzwerke (AS und HH) zur Verfügung, im Netz der AS habe ich aber keinen Zugriff auf das Netz der HH (via Tunnel). Wenn ich die Ereichbarkeit per tracert prüfe kommt folgendes Ergebnis:
Ziel 192.168.1.254 -> Zielhost nicht erreichbar
Ziel 10.8.100.1
1 <1ms Fritz.box [192.168.100.1]
2 <1ms Diskstation [192.168.100.254]
3 176ms 10.8.100.1
Dabei stehe ich doch bei der 10.8.100.1 schon auf dem OpenVPN-Server...
Für mich sieht es aus als sei das Routing defekt/falsch, ich komme ins OpenVPN-Netz, nur nicht dahinter.
Nutze ich die gleichen Konfig-Einstellungen an einem Client mit OpenVPN Gui, komme ich ohne Probleme ins Zielnetz.
Ziel 192.168.1.254 -> Zielhost nicht erreichbar
Ziel 10.8.100.1
1 <1ms Fritz.box [192.168.100.1]
2 <1ms Diskstation [192.168.100.254]
3 176ms 10.8.100.1
Dabei stehe ich doch bei der 10.8.100.1 schon auf dem OpenVPN-Server...
Für mich sieht es aus als sei das Routing defekt/falsch, ich komme ins OpenVPN-Netz, nur nicht dahinter.
Nutze ich die gleichen Konfig-Einstellungen an einem Client mit OpenVPN Gui, komme ich ohne Probleme ins Zielnetz.
Hast du denn wirklich die zwei statischen Routen in der FritzBox und dem Router eingetragen:
FritzBox:
Ziel: 192.168.1.0 /24, Gateway: 192.168.100.254
Ziel: 10.8.100.0 /24, Gateway: 192.168.100.254
"Router":
Ziel: 192.168.100.0 /24, Gateway: 192.168.1.254
Ziel: 10.8.100.0 /24, Gateway: 192.168.1.254
Achte darauf das der OVPN Client auf der DS218+ kein NAT (IP Adress Translation) aktiviert hat und das dort auch IPv4 Forwarding im Betriebssystem aktiviert ist ! Oft ist das bei kommerziellen Implementationen von OVPN der Fall was aber hier in dem Site-to-Site VPN kontraproduktiv wäre und zum Scheitern führt.
Routing technisch gesehen besteht keinerlei Unterschied ob ein Client dann über sein Default Gateway geht (FB) und von dort über die statischen Routen oder ob es diese Route direkt eingetragen hat.
Ersteres ist natürlich immer sinnvoller, denn Endgeräte sollten niemals routen. Dafür hat man ja einen "Router" !
Behalte zudem bei Winblows Endgeräten immer auch die dortige lokale Firewall im Auge. Die blockt in der Regel generell ICMP und allen Traffic der aus fremden IP Netzen kommt.
- remotes LAN (192.168.1.0 /24) hinter dem VPN Router im Netz der FB und...
- internes OpenVPN Netz
FritzBox:
Ziel: 192.168.1.0 /24, Gateway: 192.168.100.254
Ziel: 10.8.100.0 /24, Gateway: 192.168.100.254
"Router":
Ziel: 192.168.100.0 /24, Gateway: 192.168.1.254
Ziel: 10.8.100.0 /24, Gateway: 192.168.1.254
Achte darauf das der OVPN Client auf der DS218+ kein NAT (IP Adress Translation) aktiviert hat und das dort auch IPv4 Forwarding im Betriebssystem aktiviert ist ! Oft ist das bei kommerziellen Implementationen von OVPN der Fall was aber hier in dem Site-to-Site VPN kontraproduktiv wäre und zum Scheitern führt.
Routing technisch gesehen besteht keinerlei Unterschied ob ein Client dann über sein Default Gateway geht (FB) und von dort über die statischen Routen oder ob es diese Route direkt eingetragen hat.
Ersteres ist natürlich immer sinnvoller, denn Endgeräte sollten niemals routen. Dafür hat man ja einen "Router" !
Behalte zudem bei Winblows Endgeräten immer auch die dortige lokale Firewall im Auge. Die blockt in der Regel generell ICMP und allen Traffic der aus fremden IP Netzen kommt.
Moin habe am Freitag noch etwas herum gedocktort und mich über den Support von AVM geärgert...
Man tut es sich dort leicht, Kommentar des Supports: "Uns sind aktuell keine Probleme mit dem IP-Routing der FRITZ!Box bekannt. Bitte haben Sie Verständnis, dass wir Ihnen hier keinen Support für die VPN-Verbindung anderer Hersteller, die Sie im Heimnetz der FRITZ!Box aufbauen." höchst aufschlussreich, zumal hat man sich das Problem offenbar nicht angesehen.
@aqui ja ich habe beide Routen in der FB der Aussenstelle gesetzt, das Haupthaus habe ich bisher nicht weiter betrachtet, da ich mit der gleichen VPN-Verbindung von einem anderen Client, egal aus welchem Netz eine Verbindung in das Netz des Haupthauses herstellen kann und auf dort vorhandene Resourcen zugreifen kann.
Wenn ich tracert auf den VPN-Router (10.8.100.1) des HH setzte zeigt er mir die Hops zur Fritzbox, dann zur DS und dann zu dem VPN-Router, bei den ersten beiden unter 1ms bei dem letzten 50-100ms.
Setzte ich tracert zu dem Server des HH (192.168.1.254), dann springt er nicht einmal zur Fritzbox, sagt das etwas über das funktionieren der Route aus oder nicht?
Man tut es sich dort leicht, Kommentar des Supports: "Uns sind aktuell keine Probleme mit dem IP-Routing der FRITZ!Box bekannt. Bitte haben Sie Verständnis, dass wir Ihnen hier keinen Support für die VPN-Verbindung anderer Hersteller, die Sie im Heimnetz der FRITZ!Box aufbauen." höchst aufschlussreich, zumal hat man sich das Problem offenbar nicht angesehen.
@aqui ja ich habe beide Routen in der FB der Aussenstelle gesetzt, das Haupthaus habe ich bisher nicht weiter betrachtet, da ich mit der gleichen VPN-Verbindung von einem anderen Client, egal aus welchem Netz eine Verbindung in das Netz des Haupthauses herstellen kann und auf dort vorhandene Resourcen zugreifen kann.
Wenn ich tracert auf den VPN-Router (10.8.100.1) des HH setzte zeigt er mir die Hops zur Fritzbox, dann zur DS und dann zu dem VPN-Router, bei den ersten beiden unter 1ms bei dem letzten 50-100ms.
Setzte ich tracert zu dem Server des HH (192.168.1.254), dann springt er nicht einmal zur Fritzbox, sagt das etwas über das funktionieren der Route aus oder nicht?
sagt das etwas über das funktionieren der Route aus oder nicht?
Ja, vermutlich...Bedeutet ja dann das der OVPN Server im HH das lokale Netzwerk nicht erreichen kann.
Da gibt es dann mehrere Fehlerquellen:
- Die statische Route auf der FritzBox Außenstelle ins 192.168.1.0 Netz wurde vergessen
- Das IPv4 Forwarding/Routing wurde vergessen im Server OS zu aktivieren
- Der OVPN Server macht fälschlicherweise NAT im VPN Tunnel
- Auf dem Server ist eine lokale Firewall aktiv die den Zugang zu 192.168.1.0 oder 10.8.100.0 verhindert
- Die statische Route auf der FritzBox HH ins 192.168.100.0 und 10.8.100.0 Netz wurde vergessen
Ebenso wäre die lokale Routing Tabelle sowohl des OVPN Servers und Clients hier sehr hilfreich.
Diese bekommst du mit route print (Winblows) oder ip r oder netstat -n -r (Linux bzw. unixoide OS)
Route Screenshots der beiden FritzBoxen könnten auch nicht schaden.
Ich hatte es oben ja schon gesagt: Ich denke, das Problem liegt daran, dass Du den Synology-OVPN-Client für den Tunnel einsetzt.
Baue ein richtiges Site-to-Site, wie oben beschrieben, dann sollte das klappen, jedenfalls hängst Du dann nicht in einer Blackbox-Implementierung.
Der Client muss (nach Deiner Zeichnung) ja im Netz 192.168.100.0 sein.
Viele Grüße, commodity
Jetzt habe ich die DS per OPENVPN mit dem Hauptnetzverbunden,
Woher willst Du wissen, ob der Synology-OVPN-Client überhaupt Anfragen von anderen Geräten im Netz weiter leiten kann? Vielleicht ja, vielleicht nein.Baue ein richtiges Site-to-Site, wie oben beschrieben, dann sollte das klappen, jedenfalls hängst Du dann nicht in einer Blackbox-Implementierung.
Setzte ich tracert zu dem Server des HH (192.168.1.254), dann springt er nicht einmal zur Fritzbox,
Das spricht für mich allerdings nicht für ein fehlerhaftes Routing, sondern für eine fehlerhafte Gateway-Einrichtung. Wenn er das Gateway nicht findet, ist das entweder falsch eingetragen oder Du stellst die Anfrage an 192.168.1.254 aus dem Netz 192.168.1.0. Nach Letzterem sieht es für mich aus, denn bei Aufruf von 10.8.100.1 wird ja das Gateway korrekt angesteuert.Der Client muss (nach Deiner Zeichnung) ja im Netz 192.168.100.0 sein.
Viele Grüße, commodity
Kollege @commodity hat da absolut Recht. Der Synology-OVPN-Client muss das Routing (IPv4 Forwarding) supporten !
Der Server benötigt ebenso die entsprechenden Routing Einträge des Client IP Netzes mit ifconfig-push <ip_und_maske> und iroute <client_netz_ip_und_maske>. (Siehe hier).
Der Fehler sieht in der Tat etwas danach aus das der OVPN Client kein IPv4 Forwarding/Routing macht was bei NAS Implementationen von OpenVPN nicht unüblich ist. Die Warnung des Kollegen @commodity oben ist also durchaus berechtigt.
Eine wasserdichte Klärung mit einem SSH Shell Zugriff via PuTTY und Überprüfung der beiden OpenVPN Konfig Dateien (server und Client) wäre wichtig damit du nicht ggf. sinnfrei weiter testest wenn es schon am Routing scheitert.
Die ggf. fehlerhafte Gateway Einrichtung solltest du in jedem Falle ebenso genau überprüfen ! Screenshots der FB Route Settings wären, wie bereits erwähnt, hilfreich.
Der Server benötigt ebenso die entsprechenden Routing Einträge des Client IP Netzes mit ifconfig-push <ip_und_maske> und iroute <client_netz_ip_und_maske>. (Siehe hier).
Der Fehler sieht in der Tat etwas danach aus das der OVPN Client kein IPv4 Forwarding/Routing macht was bei NAS Implementationen von OpenVPN nicht unüblich ist. Die Warnung des Kollegen @commodity oben ist also durchaus berechtigt.
Eine wasserdichte Klärung mit einem SSH Shell Zugriff via PuTTY und Überprüfung der beiden OpenVPN Konfig Dateien (server und Client) wäre wichtig damit du nicht ggf. sinnfrei weiter testest wenn es schon am Routing scheitert.
Die ggf. fehlerhafte Gateway Einrichtung solltest du in jedem Falle ebenso genau überprüfen ! Screenshots der FB Route Settings wären, wie bereits erwähnt, hilfreich.
Wenn's das denn war bitte dann nicht vergessen den Thread auch zu schliessen !
How can I mark a post as solved?
How can I mark a post as solved?
Moin, sorry, habe die Weihnachtstage das ganze ruhen lassen.
Vorher hatte ich noch ein paarmal mit dem Support von AVM ausgetauscht.
die dortige Aussage ist, das die Routen in der Fritzbox den Traffik von Aussen auf ein mögliches Subnet routen, jedoch nicht von innen auf ein subnet (letzlich versuche ich hier ja nichts anderes).
Das will mir nicht ganz einleuchten, aber es scheint so zu sein. Jetzt ist mein Problem auf den Umstand geschrumpft, dass ich zwar eine Standleitung mit der NAS aufbauen kann, diese aber nicht von anderen Geräten im Netz nutzen kann.
Wenn ich jedoch mich von Aussen (Homeoffice) per VPN mit der Fritzbox verbinde habe ich Zugriff auf die Geräte in der AS und auf den VPN-Tunnel zum HH. Befinde ich mich in der AS so bleibt der Zugang zu dem VPN-Tunnel Verwehrt.
ich habe in der Fritzbox alle Anfragen bezüglich des Netzes im HH auf die NAS geroutet, ich habe in der NAS ebenfalls alle Anfragen bezüglich des HH-Netztes alles auf den VPN-Tunnel geroutet.
Ich scanne grade den Markt nach einem Router, der Openvpn kann und werde den dann wohl als Subnet hinter der Fritz betreiben, die dann nur noch für den Internetzugang zuständig ist.
Vorher hatte ich noch ein paarmal mit dem Support von AVM ausgetauscht.
die dortige Aussage ist, das die Routen in der Fritzbox den Traffik von Aussen auf ein mögliches Subnet routen, jedoch nicht von innen auf ein subnet (letzlich versuche ich hier ja nichts anderes).
Das will mir nicht ganz einleuchten, aber es scheint so zu sein. Jetzt ist mein Problem auf den Umstand geschrumpft, dass ich zwar eine Standleitung mit der NAS aufbauen kann, diese aber nicht von anderen Geräten im Netz nutzen kann.
Wenn ich jedoch mich von Aussen (Homeoffice) per VPN mit der Fritzbox verbinde habe ich Zugriff auf die Geräte in der AS und auf den VPN-Tunnel zum HH. Befinde ich mich in der AS so bleibt der Zugang zu dem VPN-Tunnel Verwehrt.
ich habe in der Fritzbox alle Anfragen bezüglich des Netzes im HH auf die NAS geroutet, ich habe in der NAS ebenfalls alle Anfragen bezüglich des HH-Netztes alles auf den VPN-Tunnel geroutet.
Ich scanne grade den Markt nach einem Router, der Openvpn kann und werde den dann wohl als Subnet hinter der Fritz betreiben, die dann nur noch für den Internetzugang zuständig ist.
Ich scanne grade den Markt nach einem Router, der Openvpn kann
https://www.amazon.de/GL-iNet-GL-MT300N-V2-Repeater-Performance-Compatib ......und alle Router die OpenWRT und DD-WRT Firmware supporten...
Befinde ich mich in der AS so bleibt der Zugang zu dem VPN-Tunnel Verwehrt.
Was ist mit "AS" gemeint ? Außen..?Sehr wahrscheinlich gilt dort in der AS ein anderes Default Gateway und dieses Gateway hat dann keine Routen in die VPN IP Netze kmonfiguriert. Der typische Fehler....
Das hiesige [ OpenVPN Tutorial] und deren weiterführende Links beschreibt die Settings dazu im Detail.
Für ein hiesiges Troubleshooting müsste man dein aktuelles IP Design in der "AS" kennen um hier zielführend helfen zu können. Eine kurze Skizze dazu wird das "Problem" vermutlich sofort lösen.
Die dortige Aussage ist, das die Routen in der Fritzbox den Traffik von Aussen auf ein mögliches Subnet routen, jedoch nicht von innen auf ein subnet.
Das klingt für mich nach 1st-level-Support-Quatsch. Der wollte Dir ein gutes Gefühl geben, aber Dich trotzdem los werden (Kannst Du aber auch nicht erwarten, dass der AVM-Support Dein persönliches VPN-Fehlkonstrukt aufdröselt). Ein Router routet nach den ihm gegebenen Regeln, egal ob Traffic von innen oder außen kommt. Was ist denn auch "außen" beim Routing? Der Router unterscheidet beim Routing nur zwischen Netzen und nicht zwischen mein und dein. IP-Routing ist ein rein binärer Abgleich von IP-Adressen und Subnetzmasken mit dem Regelwerk (Routingtabelle).Sag mal, bist Du eigentlich an einer Lösung interessiert? Du sagst gar nichts zu dem Hinweis zu dem Aspekt des wahrscheinlich nicht routenden Clients. Zitat @aqui:
Der Fehler sieht in der Tat etwas danach aus das der OVPN Client kein IPv4 Forwarding/Routing macht was bei NAS Implementationen von OpenVPN nicht unüblich ist.
Vielleicht hast Du das ja schon geprüft, dann schreib doch bitte auch was dazu. Und wenn Du es nicht geprüft hast, mache es. Ein Fehler löst sich nicht durch Ignorieren. Wir versuchen Dir hier zu helfen und können das Problem nur weiter eingrenzen, wenn von Dir auch Inhalte kommen. Bislang sieht es für mich so aus, als ob Du die essentiellen Hinweise gar nicht beachtest (Dich um deren Verständnis bemühst?). So kommst Du auch in drei Jahren nicht weiter. Und das kann doch nicht der Plan sein?Viele Grüße, commodity
Moin,
Mit AS ist Aussenstelle gemeint, eben die Geschäftsräume die an der Fritze hängen und über die DS218+ (NAS) per VPN mit dem HH (Haupthaus) verbunden sein sollten.
Habe heute noch etwas mit tracert geprüft.
Wenn ich nur die Anfragen an 192.168.1.254 über die NAS Route (Fritzbox Routing) dann findet mein PC das Ziel nicht. Stell ich die Anfrage an das VPN-Netz (10.8.100.1) geht diese ins WWW wo die verständlicherweise nicht gefunden wird. Stelle ich in der Fritze zusätzlich die Route 10.8.100.0/24 über die dS218 ein, werden die tracert Anfragen korrekt geroutet.
Warum sperrt die Fritze sich so gegen das Routing in ein 192.168...Netz?
Mit AS ist Aussenstelle gemeint, eben die Geschäftsräume die an der Fritze hängen und über die DS218+ (NAS) per VPN mit dem HH (Haupthaus) verbunden sein sollten.
Habe heute noch etwas mit tracert geprüft.
Wenn ich nur die Anfragen an 192.168.1.254 über die NAS Route (Fritzbox Routing) dann findet mein PC das Ziel nicht. Stell ich die Anfrage an das VPN-Netz (10.8.100.1) geht diese ins WWW wo die verständlicherweise nicht gefunden wird. Stelle ich in der Fritze zusätzlich die Route 10.8.100.0/24 über die dS218 ein, werden die tracert Anfragen korrekt geroutet.
Warum sperrt die Fritze sich so gegen das Routing in ein 192.168...Netz?
dann findet mein PC das Ziel nicht.
Das ist gut möglich und passiert wenn der OpenVPN Client (NAS) die Route des lokalen Netzes nicht an den HH OpenVPN Server weitergibt und der die Route ins lokale AS Netz nicht kennt.Oben ist dir das ja schon mehrfach erklärt worden und HIER findest du eine genau Anleitung wie das routingtechnisch in der OpenVPN Konfig Datei auf OVPN Client und Server eingerichtet werden muss !!
Bei einem remoten Dialin fällt das nicht ins Gewicht weil der Client als Absender immer die virtuelle IP des internen OpenVPN Tunnelnetzes verwendet.
Mit dem PC vor Ort am AS Standort ist das aber komplett anders, denn der nutzt das lokale LAN als Absender IP.
Extrem wichtig für ein zielführendes Troubelshooting und damit einer schnellen Lösung ist wenn du die Routing Tabelle des OpenVPN Servers im HH hier einmal postest.
- Wenn es ein Winblows Server ist = route print
- Wenn es ein Linux oder unixoider Server ist = ip r
Weiterhin sehr hilfreich wären die anonymisierte Konfig Datei des OpenVPN Servers und des OpenVPN Clients (NAS) um hier zielgerichtet helfen zu können.
All das hast du bis dato nicht geliefert so das wir hier immer nur raten und vermuten können.
Kollege @commodity hat es oben schon gesagt !De facto ist das ein simples OVPN Allerweltsdesign was normal in 10 Minuten eingerichtet und online ist.
