14.01.2017

6790

Fritzbox 7490 und Zyxel USG20 - Zugriff auf LAN der USG20

Hallo zusammen,

ich hoffe mein Thema ist hier richtig am Platz, da ich hier noch relativ neu bin und es wahrscheinlich 1000e ähnliche Fragen / Beiträge gibt

Nun zu meinem Problem oder meiner Frage:

Ich nutze eine Fritzbox 7490, welche Internet zur Verfügung stellt. Hinter der Fritzbox ist eine Zyxel USG20 im Betrieb.

Die Fritzbox besitzt eine "Exposed Host" Freigabe zur WAN-IP der USG20, stellt aber selbst (zu Testzwecken) noch ein eigenes LAN zur Verfügung und ist dafür der DHCP Server. WLAN ist deaktiviert.

Ich versuche seit einiger Zeit aus dem LAN der Fritzbox auf das LAN hinter der USG20 zuzugreifen (zu Testzwecken) per HTTP, PING usw., was leider nicht funktioniert. Umgedreht dagegen schon. Ich nehme an das liegt an NAT.

Ich habe bereits eine statische IPv4-Route auf der Fritte eingerichtet und es zumindest geschafft vom LAN der Fritte auf die LAN-IP der USG20 zu kommen, aber nicht auf irgendeine andere IP im LAN der USG.

Nun zu den Konfigurationen im Detail:

Aufbau (grob):

Internet --> FB (mit eigenem LAN) --> Zyxel USG --> LAN1, LAN2, DMZ

(LAN2 kann ignoriert werden, DMZ wird derzeit nicht verwendet)

--

LAN Fritzbox:

IP: 192.168.2.1 (FB)
SM: 255.255.255.0
GW und DNS: 192.168.2.1
stellt (noch) DHCP bereit...

--

WAN USG20:

IP: 192.168.2.2
SM: 255.255.255.0
GW: 192.168.2.1

--

LAN1 USG20:

IP USG: 192.168.1.1
SM: 255.255.255.0
GW: 192.168.1.1

--

Statische Route von FB zu USG20:

IPv4 Netzwerk: 192.168.1.0
SM: 255.255.255.0
GW: 192.168.2.1

--

Wenn mehr Details benötigt werden gerne...

Alles funktioniert jedenfalls super, nur der Zugriff aus dem LAN der FB zum LAN der USG nicht... Habe auch bereits mal eine NAT-Regel und eine Policy Route gebaut, kam aber nicht weiter und erstmal wieder gelöscht. Auch zig Firewall Regeln durchprobiert aber keine Chance... Mit und ohne IPv4 Route auf der FB probiert...

Wichtig ist zu wissen, was genau nötig ist einzurichten, um das Ziel zu erreichen. NAT Regel auf der USG + Policy Route + IPv4 Route auf der FB???? Fragen über Fragen....

Kennt ihr das Problem und könnt helfen? Wäre genial!

Vielen Dank im Voraus und viele Grüße

Sebbi

Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben

Content-ID: 326403

Url: https://administrator.de/contentid/326403

Ausgedruckt am: 22.11.2024 um 07:11 Uhr

52 Kommentare

Neuester Kommentar

Hallo,

Zitat von @Sebbi87:
Statische Route von FB zu USG20:
IPv4 Netzwerk: 192.168.1.0
SM: 255.255.255.0
GW: 192.168.2.1

Was sagt deine USG20 den zu den Paketen die in deren LAN wollen? Sind die erlaubt? Was steht in deren Logs denn drinn? Mal ein dauerping auf ein VClient im USG20 LAN vom FrittenLan aus gemacht. Notfalls hilft dir eine Wireshark die Antwort zu finden.

Gruß,
Peter

Hallo Peter,

mit dieser Route auf der FB kommen lediglich Pakete auf der LAN-IP der USG an (192.168.1.1)...

Pinge ich z.b. einen Client im LAN der USG, z.b. 192.168.1.222, kommt leider nix an...

Stattdessen kommt die Rückmeldung von der FB: Antwort von 192.168.2.1: Zielhost nicht erreichbar...

Bei einem tracert auf die IP 192.168.1.222 die gleiche Antwort

Grüße
Sebbi

Hi,

Was für ein Endgerät ist denn an der 192.168.1.222 angebunden?
Ein PC, welcer ggf. eine Firewall hat?

Wäre ja denkbar, dass dieses Gerät den eingehenden Traffic blockiert, da die absendende IP nicht aus dem eigenen LAN (Subnet) stammt!?

Könnte aber auch sein, dass (durch ein NAT) die IP der USG am Client erscheint, das müsstest du mal prüfen.

Kannst' ja mal einen PC (Windows) in das Netz "LAN1" stellen und dort WireShark mitlaufen lassen (ggf. die Firewall deaktivieren, da die vermutlich auch das Capturen des WireSharks negativ beeinträchtigt). Dann würde man sehen, ob Pakete aus deinem Transfernetz (LAN zwischen FB und USG) am Client ankommen geblockt werden.

Gruß
em-pie

Hallo,

Zitat von @Sebbi87:
mit dieser Route auf der FB kommen lediglich Pakete auf der LAN-IP der USG an (192.168.1.1)...

Das ist doch mal gut so, oder?

Pinge ich z.b. einen Client im LAN der USG, z.b. 192.168.1.222, kommt leider nix an...

Kommt nichts am Ziel an oder kommt vom Ziel keine Antwort oder kommt die Antwort nicht mehr bei der Quelle an? Du wirst dir schon deine TCP/IP Strecke anschauen müssen wo es hängen bleibt.

Bei einem tracert auf die IP 192.168.1.222 die gleiche Antwort

Was sagen die Logs deiner USG20? Die hat doch welche?
Was sagt ein Wireshark im USG20 LAN drin?
Was sagt die Firewall deines unbekannten Clients im USG20 LAN? Standardmässig werden IP anfragen aus andere Netze nicht zugelassen. Und das 192.168.2.0 ist eben ein anderes netz als 192.168.1.0.

Dein geht Nicht ist keine Fehlermeldung, damit kann keiner etwas anfangen. Du willst zwingend Routing betreiben, dann setz dich damit auseinander und lern wie es geht, besonders wenn dann noch NAT ins Spiel kommt. Schau wo du welche Logs bzw. Analysen machen kannst um den Datenverkehr zu verfolgen oder die Stelle zu finden die blockt, egal in welcher Richting. Auch ein einfaches Ping lösst eine 2-Wege Kommunikation aus. Nur blöd wenn eine Richtung gesperrt / behindert wird.

https://en.wikibooks.org/wiki/Communication_Networks/Ping
https://wiki.wireshark.org/Internet_Control_Message_Protocol

Gruß,
Peter

Moin,

lies dir das mal durch.

Gruß

Uwe

1) Statische Route auf der FB setzen. Deine ist falsch: Next Hop muss selbstverständlich die WAN-IP der USG sein

2) Auf der USG: keine Policy-Route, keine (D)Nat-Settings, sondern:
2a) den Default-SNAT-Mechanismus deaktivieren unter Configuration>Interface>Trunk
2b) zulassende Firewall-Regel erstellen (WAN nach LAN)

Gruß
sk

Hallo zusammen,

der Tipp von sk war goldrichtig!!! besten Dank dafür! Es lag nur an der Route auf der FB, der Rest hatte bereits gepasst. Ging sofort als ich dir IP geändert habe.

Hatte vorher auch Wireshark noch getestet, wie ihr es empfohlen habt. Da konnt ich eben auch noch feststellen, dass die FB tatsächlich nicht wusste wohin damit "Host unreachable". Beim Wiresharken auf die IP der USG (mit alter Route), gabs einen "Redirect Host". Also war es ebenfalls der Beweis dass mit der alten Route bei der FB Schluss war...

Danke sk konnte ich den Wald vor lauter Bäumen wieder sehen und auch besten Dank an alle anderen!!!

Case solved

*freu*

Viele Grüße

Sebbi

Mit Suchfunktion wär' das nicht passiert. Hier ist erklärt wie es richtig gemacht wird mit Router Kaskaden sowohl mit als auch ohne NAT:
Routing von 2 und mehr IP Netzen mit Windows, Linux und Router

Digibox Premium / Fritzbox und Zyxel USG20 - Zugriff auf LAN der USG20

Hallo Leute,
mein Thema passt genau hier her, weshalb ich keinen neuen Thread eröffnen wollte – hoffe, das ist ok? Und gleich zu Beginn – ich bin nicht die hellste Kerze im IT-Bereich, jedoch konnte ich keinen „Spezialisten“ in unserer Umgebung finden, der mir meine Wünsche realisieren kann… Zu meinem Anliegen:

2 Betriebsstellen, VPN-Verbindung zwischen den beiden gewünscht (eigentlich genau wie bei Sebbi):

Hauptstelle:
- Fritzbox 6590 Cable
- 1.000 Mbit Vodafone
- Feste IP
- Fritzbox IP: 192.168.1.1
- Alle PC´s haben feste IP im Bereich 192.168.1.3-192.168.1.130
- Fritzbox DHCP ab 192.168.1.149-192.168.1.199
- Synology NAS DNS-Server 192.168.1.50 (läuft als ADS)
- 192.168.1.2 ist definitiv nicht vom Netzwerk vergeben

Filiale:
- Digibox Premium
- 100 Mbit Telekom
- Feste IP
- Digibox IP: 192.168.2.1
- Alle PC´s haben feste IP im Bereich 192.168.2.3-192.168.2.130
- Digibox DHCP ab 192.168.2.149-192.168.2.199
- Synology NAS DNS-Server 192.168.2.50 (läuft als ADS)
- 192.168.2.2 ist definitiv nicht vom Netzwerk vergeben

Nun zu den Konfigurationen im Detail – dto. oben (hoffe, das ist kein „copyright“ drauf? Danke an Sebbi!):

Internet --> FB (mit eigenem LAN) --> Zyxel USG 40 --> LAN1, LAN2, DMZ
(LAN2, DMZ wird nicht verwendet)
--
LAN Fritzbox: Hauptstelle
IP: 192.168.1.1
SM: 255.255.255.0
GW: 192.168.1.1, stellt DHCP bereit...
DNS: 192.168.1.50 (NAS)
--
WAN USG40:
IP: 192.168.1.2
SM: 255.255.255.0
GW: 192.168.1.1
--
LAN1 USG40:
IP USG: 192.168.10.1
SM: 255.255.255.0
GW: 192.168.10.1
--
Statische Route von FB zu USG40:
IPv4 Netzwerk: 192.168.10.0
SM: 255.255.255.0
GW: 192.168.1.1 (erst mal bewusst)
--
LAN Digibox: Filiale
IP: 192.168.2.1
SM: 255.255.255.0
GW: 192.168.2.1, stellt DHCP bereit...
DNS: 192.168.2.50 (NAS)
--
WAN USG20:
IP: 192.168.2.2
SM: 255.255.255.0
GW: 192.168.2.1
--
LAN1 USG20:
IP USG: 192.168.20.1
SM: 255.255.255.0
GW: 192.168.20.1
--
Statische Route von DB zu USG20:
IPv4 Netzwerk: 192.168.20.0
SM: 255.255.255.0
GW: 192.168.2.1 (ebenfalls erst mal bewusst)

Das VPN läuft, ich habe Verbindung zwischen den Routern, also sollten die Portweiterleitungen ok sein. Mein Problem liegt wohl eher an den statischen Routen und wo diese eingetragen werden müssen oder doch an einer der der Firewalls?

Statische Route auf der FB setzen:
Zur Lösung von sk:
„Deine ist falsch: Next Hop muss selbstverständlich die WAN-IP der USG sein“
Bei mir habe ich die in der Fritte erst wie folgt gesetzt: 192.168.10.0/24/192.168.1.2. Wenn ich das mache, komme ich von meinem Arbeitsplatz (192.168.1.23/24) nicht mehr auf das Webinterface der USG. Wenn ich die Route dagegen auf 192.168.1.1 setze, funktioniert das.
WAN funktioniert mit beiden Einstellungen – nachgeschaut habe ich das, indem ich das Netz meines Computers auf 192.168.10.23 gesetzt habe, dann kann ich mich auf die USG (192.168.10.1) auch mit der eingestellten Route an 192.168.1.2 aufschalten…

Zu 2b) zulassende Firewall-Regel erstellen (WAN nach LAN)
Firewall = Policy? Da habe ich mal WAN-LAN eingegeben. Ich merke keinen Unterschied

ALSO, was geht und was nicht:

Hauptstelle mit Route auf der Fritte 192.168.10.0/24/192.168.1.2.:
Kein Ping außerhalb der 192.168.1.0 und auch nicht an 192.168.1.2

Hauptstelle mit Route auf der Fritte 192.168.10.0/24/192.168.1.1.:
Ping innerhalb der 192.168.1.0 natürlich
Ping 192.168.10.1 und damit auch Aufruf des Webinterface USG40
Kein Ping auf 192.168.1.2 (WAN-Interface USG40)
Kein Ping auf 192.168.20.1 und kein Aufruf von Webinterface 192.168.20.1 (USG20) möglich
Kein Ping auf 192.168.2.1 (auch kein Webinterface DB Filiale)

Wenn ich meinen Arbeitsplatz auf 192.168.10.23 stelle, dann geht der
Ping auf 192.168.10.1 und damit auch Aufruf des Webinterface USG40
Ping auf 192.168.20.1 und damit auch Aufruf des Webinterface USG20
Ping auf 192.168.1.1
Ping auf 192.168.2.1 aber kein Aufruf von Webinterface DB auf der Filiale

Und nun noch zu allem Überfluss:

Aus der Filiale kann ich vom Arbeitsplatz aus mit Route auf der DB 192.168.20.0/24/192.168.2.1.:
Arbeitsplatz IP 192.168.2.21
Ping innerhalb der 192.168.2.0 natürlich
Ping 192.168.20.1 und damit auch Aufruf des Webinterface USG20
Ping 192.168.10.1 und damit auch Aufruf des Webinterface USG40
Kein Ping auf 192.168.1.1 (auch kein Webinterface Fritte Hauptstelle)

Also kann das doch nicht am VPN liegen?

Jemand ne Idee, welche Routen es noch wo benötigt? Oder ob die Firewall eine Rolle spielt?

Nun noch der größte Lacher, wenn es nicht so traurig wäre:
Ping von 192.168.1.23 aus an
Ping wird ausgeführt für 192.168.1.2 mit 32 Bytes Daten:
Antwort von 192.168.1.2: Bytes=32 Zeit=2ms TTL=64
Antwort von 192.168.1.2: Bytes=32 Zeit<1ms TTL=64
Antwort von 192.168.1.2: Bytes=32 Zeit<1ms TTL=64
Antwort von 192.168.1.2: Bytes=32 Zeit<1ms TTL=64

Ping-Statistik für 192.168.1.2:
Pakete: Gesendet = 4, Empfangen = 4, Verloren = 0 (0% Verlust),
Ca. Zeitangaben in Millisek.: Minimum = 0ms, Maximum = 2ms, Mittelwert = 0ms

…und weil ich es nicht glauben konnte unmittelbar danach nochmalige Anfrage:

Ping wird ausgeführt für 192.168.1.2 mit 32 Bytes Daten:
Zeitüberschreitung der Anforderung.
Zeitüberschreitung der Anforderung.
Zeitüberschreitung der Anforderung.
Zeitüberschreitung der Anforderung.

Ping-Statistik für 192.168.1.2:
Pakete: Gesendet = 4, Empfangen = 0, Verloren = 4 (100% Verlust),

Ich flippe noch aus…

Und jetzt auch noch das, wie kann denn so etwas passieren?

Tracert 192.168.1.2

Routenverfolgung zu TUCAP01.trcgd.local [192.168.1.2]
über maximal 30 Hops:

1 * * * Zeitüberschreitung der Anforderung.
^C

ping TUCAP01

Ping wird ausgeführt für TUCAP01.trcgd.local [192.168.1.21] mit 32 Bytes Daten:
Antwort von 192.168.1.21: Bytes=32 Zeit<1ms TTL=128
Antwort von 192.168.1.21: Bytes=32 Zeit<1ms TTL=128
Antwort von 192.168.1.21: Bytes=32 Zeit<1ms TTL=128
Antwort von 192.168.1.21: Bytes=32 Zeit<1ms TTL=128

Ping-Statistik für 192.168.1.21:
Pakete: Gesendet = 4, Empfangen = 4, Verloren = 0
(0% Verlust),
Ca. Zeitangaben in Millisek.:
Minimum = 0ms, Maximum = 0ms, Mittelwert = 0ms

Ich habe nochmals die feste IP im PC (Ethernet Adapter) geprüft, da steht definitiv 192.168.1.21 drinne, wie kann tracert den unter 192.168.1.2 finden? Wo steht das denn noch drin außer in den IP-Einstellungen des PC?

Ich hintersinn mich noch…

...ok, 2 Fehlerquellen hab ich nun ausgeschaltet: in der USG40 war noch das LAN2 auf 192.168.2.0! Ist nun raus, bei beiden USG´s habe ich nun nur noch LAN1 und WAN aktiv. Und im DNS habe ich die reverse lookup´s zu 192.168.1.2 gelöscht, da die Stationen ursprünglich statt auf .21 etc. mal auf .2 usw. gesetzt waren. Trotzdem noch kein Erfolg.

Die statischen Routen in den davorliegenden Router sind falsch und zudem überflüssig, denn sehr wahrscheinlich machen die Zyxels NAT (IP Translation) am WAN Port, sprich sie übersetzen also alle dahinter liegenden IP Netze auf ihre WAN IP.
Router davor können wegen dieses NATs diese lokalen Firewall IP Netze gar nicht erkennen. Folglich sind die Routen also überflüssig und zudem auch noch falsch. (Falsches Next Hop Gateway)
Dein Design krankt daran das du aktive Endgeräte in den Koppelnetzen hast was in einem Kaskaden Design niemals der Fall sein sollte.
Du solltest also dringenst dein VPN Konzept überdenken. So wird das ganz sicher nichts...

ok, erstmal vielen dak für die schnelle Antwort! Also nochmals zu dem was funktioniert: die jeweiligen Zyxels können das gegenüberliegende LAN Interface .10.1 und .20.1 anpingen, soweit ok.

Zu den Kaskaden:
1. Ich bekomme kein Modem lt. Vodafone für die 1.000Mbit, ich bin an die 6590 gebunden
2. Die Digibox ist von der TK-Anlage nicht durch eine FB o.ä. zu ersetzen, und eine andere TK-Anlage ist mir zu teuer (habe mir schon einiges angeschaut, selbst gebraucht). Ferner müsste ich dort noch zusätzlich ein Modem kaufen und die DB als nur TK-Anlage umkonfigurieren. Und dann noch die USG dazu, ich weiß nicht, ob das soooo viel besser ist. Und jedes einzelne Gerät ist wieder was, das den Abgang machen kann, und alles lahmlegen...
Der Grundgedanke war, dass ich ein stabiles VPN zwischen den Betriebsstellen wollte, mehr nicht. Na ja, so einfach gedacht, so kacke in meiner Ausführung. Ich lese mir nun nochmals den Leitfaden durch und schaue dann wieder hier vorbei. Ich dachte echt nicht, dass das so ein Akt ist, hatte mal 2 Ciscos (aber nur 100Mbit, auch intern), da war das VPN halt eingestellt und lief jahrelang klaglos...

Wie könnte man denn nun eine brauchbare, wenn vielleicht auch nicht optimale Lösung mit meinen vorhandenen Geräten anvisieren?
- FB nur als Kabelmodem nutzen - allerdings haben die USG´s kein WLAN

. Aber die WLAN-Geräte brauchen nur Online-Zugang, keinen Netzwerkzugang (Porto, EC-Cash), wielleicht würde das funktionieren?
- USG40 als Router/VPN über WAN PORT anklemmen (ist ja schon so dran)
- Alle PC´s / Drucker / NAS etc. statt auf der FB in das LAN1 192.168.10.0 der USG40?
Und in der Filiale
- Digibox als Modem und TK-Anlage lassen? Ebenfalls WLAN siehe oben?
- Alle PC´s, Drucker, NAS etc. in´s LAN1 192.168.20.0 der USG20?
Wäre das dann besser in der Anordnung?

Moin,

du hast bisher nur geschrieben, dass deine ROuter eine VPN-Verbindung herstellen.
Aber welche Router genau?

USG20 <> USG40
oder
FritzBox <> DigiBox?

Ferner zu den statischen Routen:
Sofern alle Clients hintern den USGs hängen und die VPN-Verbindung zwischen FB <> DB besteht, werden folgende Routen benötigt:

Hauptstandort

USG40

Zielnetz: 192.168.2.0/ 24
NextHopp: 192.168.1.1

Zielnetz: 192.168.20.0/ 24
NextHopp: 192.168.1.1

FritzBox

Zielnetz: 192.168.20.0/ 24
NextHopp: 192.168.2.1

Zielnetz: 192.168.10.0/ 24
NextHopp: 192.168.1.2

Niederlassung

USG20

Zielnetz: 192.168.1.0/ 24
NextHopp: 192.168.2.1

Zielnetz: 192.168.10.0/ 24
NextHopp: 192.168.2.1

DigiBox

Zielnetz: 192.168.10.0/ 24
NextHopp: 192.168.1.1

Zielnetz: 192.168.20.0/ 24
NextHopp: 192.168.2.2

Hoffe, habe in meiner geistigen Umnachtung nichts vergessen/ übersehen...
Wenn die USGs den Tunnel aufbauen, musst du das entsprechend umstellen.

Tipp: Male dir einmal auf dem Papier auf, wo was steht und wie der Datenverkehr geleitet (geroutet) werden muss, um entsprechend anzukommen.

Tipp2: Wenn du von einem Gerät eine Windows-Kiste anpingst, so muss die Firewall auf der Zielkiste das Absendernetz zulassen.
Für erste Tests empfiehlt es sich daher, immer einen Drucker o.Ä. im Zielnetz anzupingen, da wird am Drucker nichts geblockt/ verworfen..

Gruß
em-pie

Vielen Dank erstmal, mache mich nun an den Umstellungsversuch, da das VPN zwischen den USG´s läuft:

PC->FB->USG->VPN->USG->DB->Drucker
192.168.1.23(PC)->192.168.1.1(FB)->192.168.1.2(WAN USG40)/192.168.10.1(USG40)->192.168.20.1(USG20)/192.168.2.2(WAN USG20)->192.168.2.1(DB)->192.168.2.31(Drucker)... Grüße claudelamont

komisches Konstrukt.
Dann macht das 192.168.10.0er und 192.168.20.0er Netz ja gar keinen Sinn

Das heißt, du hast die USGs nur des VPNs wegen?

Wenn ja, schmeiss die raus und lass die Fritte sowie wie Digibox den VPN-Tunnel aufbauen:
Das Video zeigt dir alles: Site-to-Site VPN zwischen Fritzbox und Digitalisierungsbox

Dann macht das 192.168.10.0er und 192.168.20.0er Netz ja gar keinen Sinn

Eigentlich schon, denn DAS sind die einzig nutzbaren IP Netze in diesem Kaskaden Design für alle seine Standort Endgeräte.
Das sind ja die LAN Segmente direkt an den Firewalls. Nur die und keine anderen darf er in dem Design für seine Endgeräte am jeweiligen Standort nutzen.
Die Koppelnetze sind Tabu für Clients und rein nur zum Koppeln zwischen FW WAN Port und Router und nix anderes. Wie der Name schon sagt...

lass die Fritte sowie wie Digibox den VPN-Tunnel aufbauen:

Hat er schon gemacht (PM Support

)... Das VPN ist aber (warum auch immer) absolut instabil mit massiven Ping Aussetzern und unbrauchbar. Vermutlich irgendwelche Lifetime Mismatches.

Na sag ich doch, die machen keinen Sinn...

Denn:
die USGs hängen scheinbar parallel (mit dem WAN-Port) zu den Endgeräten...

Wenn die USGs zwischen Endgeräte und den Routern (Fritte + DigiBox) hängen würden, wäre ich wieder bei dir...

Oder habe ich hier doch (noch) einen Denkfehler?

Das Design macht nur Sinn in einer Kaskade. So einbeinig angebunden wie z.B. einen OpenVPN Server im lokalen LAN kann man die Firewalls natürlich nicht betreiben, da hast du Recht.

boahhhh 2. Stornowelle, ich komm zu nix mehr... bleibe dran, dauert aber noch etwas - nicht dass Ihr denk, ich würdige Euren EINsatz nicht! Grüße

Jetzt habe ich mal meinen PC mit 192.168.10.23 konfiguriert und damit ins UGS40 - Netz gehängt. Nun funktionert natürlich der Ping zu .10, .20 und der Aufruf der beiden UGS´ Webinterfaces. Jetzt komme ich aber nur auf´s VPN und nicht mehr ins Internet. Muss ich da nun noch TCP80 und TCP443 weiterleiten an die UGS40? Oder liegt das an irgend welchen anderen Einstellungen? Teste ich mit dem einen PC... Am Ende werde ich wahrscheinlich die IP der Fritte ändern und der UGS die IP 192.168.1.1 geben, da bereits alle Geräte im Netzwerk auf diese Adresse fest eingestellt sind... Viele Grüße

Und bitte nutze die Zitat klammern richtig ! Es macht keinen Spaß alles unformatiert ohne Absäte und in Zitat Gelg zu lesen.

Nun funktionert natürlich der Ping zu .10, .20 und der Aufruf der beiden UGS´ Webinterfaces.

Wie erwartet ! Siehe Ausführungen zum Kaskaden Setup oben !

Jetzt komme ich aber nur auf´s VPN und nicht mehr ins Internet.

Kein Wunder, denn du hast vermutlich vergessen ein entsprechendes Regelwerk in der Firewall einzutragen das vom LAN alles in die weite Welt erlaubt ist. Du erlaubst vermutlich nur den VPN Traffic.
Ohne dein aktuelles Setup zu kennen können wir aber nur im freien Fall raten oder die Kristallkugel nehmen.

Was sagt denn ein tracert 8.8.8.8 von dem Client ?? Welchen Weg gehen die Pakete ?

Oder liegt das an irgend welchen anderen Einstellungen?

Vermutlich nur fehlende Firewall Regeln...?!

Am Ende werde ich wahrscheinlich die IP der Fritte ändern und der UGS die IP 192.168.1.1 geben

Ja, das wäre erheblich einfacher ! Die bestehenden lokalen Netzwerk IPs solltest du immer identisch zu den derzeit bestehenden LAN IPs konfigurieren. Damit musst du dort nichts anfassen.
Du setzt dann rein nur die Koppelnetze neu wie z.B.
172.16.16.0 /25
Dann hast du 2 Netze z.B. für die Koppelnetze: (.1 bis .126 und .129 bis .254)
Router 1: 172.16.16.101
Zyxel 1: 172.16.16.102
Router 2: 172.16.16.201
Zyxel 2: 172.16.16.202

NEIIIIN! Das geht auch nicht - ich hab ja noch eine TK-Anlage mit Software über das Netz der Fritte, auch mit festen IP´s laufen mit Software (Dialer)... Det wird nix - ich glaub, ich haue die UGS wieder raus... Wie wäre das denn mit meinen Synology NAS? Ist das dann auch so ein Heckmeck? Da könnte ich OpenVPN oder alternativ L2TP / IPSec installieren. Wobei das OpenVPN schon mal gelaufen ist, das ist für mich einfacher zu konfigurieren. Nur hatte ich dort das Problem, dass ich nicht über das VPN-Netz hinaus gekommen bin. Konnte also in den jeweils gegenüber liegenden Netzen keine Geräte ansprechen, sondern nur die IP´s innerhalb des VPN anpingen. Was meint Ihr denn dazu? Kann so etwas mit Routing erledigt werden? Und ich meine, da muss man dann auch noch IP Forwarding auf der NAS konfigurieren, was dann nach Neustart wieder rausfällt (weshalb ich mich dann doch wieder für eine andere Lösung entscheiden wollte). Die Konstellation ist dann: wie zuerst genannt, nur ohne die USG´s, die NAS hat in der Hauptstelle die 192.168.1.50 und in der Filiale die 192.168.2.50., die VPN-Netze waren 10.8.0.0 / Hauptstelle 10.8.0.1, Filiale 10.8.0.5. Oder ist das 192.168.1.0 bzw. 192.168.2.0 dann auch ein "Koppelnetz", das ich nicht nutzen darf? Dann bringt mir das ja auch nix. Nochmals vorab vielen Dank für die Geduld mit mir! Viele Grüße

ahhh, du kamst mir zuvor - SORRY! Dachte nicht, dass am Feiertag wer arbeitet!

Also: das versuche ich jetzt noch mit den IP´s!

Routenverfolgung zu 8.8.8.8 über maximal 30 Hops

1 <1 ms <1 ms <1 ms 192.168.10.1
2 1 ms <1 ms 2 ms 192.168.1.1
3 17 ms 13 ms 14 ms 95.208.164.1
4 17 ms 11 ms 15 ms 81.210.148.36
5 24 ms 22 ms 18 ms 84.116.191.233
6 18 ms 17 ms 18 ms 84.116.132.178
7 19 ms 17 ms 15 ms 213.46.177.42
8 18 ms 17 ms 17 ms 108.170.251.193
9 17 ms 19 ms 15 ms 216.239.40.59
10 18 ms 15 ms 16 ms 8.8.8.8

Ablaufverfolgung beendet.

Wenn ich eine Seite aufrufen möchte, kommt aber "Seite wurde nicht gefunden"

UND wie war das noch mit der Klammer? Pfeil und leer immer zu Beginn?

Ok, das ist die Firewall, wenn ich die komplett ausschalte, dann habe ich Zugriff. Nun muss ich mich hier einlesen - nicht dass ich aus versehen Tür und Tor öffne. Exposed Host der FB hatte ich auch versucht, da ist es auch nicht anders...

das geht nicht, habe die Firewall lt. Handbuch konfiguriert: trotzdem kein Durchkommen. Wenn ich die ganz abschalte, geht es

WAN-ZyWALL, LAN1-ZyWALL und LAN1-WAN stehen bei Access alle auf "allow"... Muss mich nochmals in dieses Internet begeben, so´n Mist aber auch.

SORRY für die Verzögerungen, Grüße

Nun habe ich die Netze umgestellt - Koppelnetz auf eigene neue IP, die Digibox hat mir die Adressbereiche warum auch immer verweigert. dann habe ich eben die Adresse 192.168.20.1 (statt 2.1) genommen und die USG20 dafür auf 192.168.2.1 (seither bestehendes Netzwerk) gesetzt, um alle weiteren Daten im Netz nicht ändern zu müssen. Sowit hat das auch funktioniert (LAN intern alles ok). ABER jetzt versagt die integrierte TK-Anlage auf der Digibox ihren Dienst (die ist ja auf jeden Fall im Koppelnetz, der kann ich keine andere IP vergeben) und dazu komme ich aus den PC´s aus dem lokalen Netz nicht mehr ins Internet, obwohl die USG Verbindung hat (VPN-Tunnel steht auch). Trotz deaktivierter Firewall in der USG und auf dem PC (Windows 10 X64 aktuellste Version). BOAH - ich glaub, ich gebe auf! Denn dann habe ich trotzdem noch in der Hauptstelle die Änderung versucht - selbes Spiel (bis auf die TK, die dort nicht im PC-Netz hängt). Adressen umgestellt, kein Zugang der Arbeitsplätze ins Netz... Kann das auch an Windows liegen? Aktivierung RAS-Dienste oder so? Portweiterleitung 80 und 443 von der Fritte zur USG40 sowie auch statt Portweiterleitung durch exposed Host - Zugang, keine Veränderung. Gibts sonst noch ideen, woran das liegen kann?

Warum koppelst du die Fritt nicht mit der DigiBox?
Habe dir hier doch schon eine Anleitung bereitgestellt:
Fritzbox 7490 und Zyxel USG20 - Zugriff auf LAN der USG20

die USGs lässt du dann einfach weg.

Warum koppelst du die Fritt nicht mit der DigiBox?

War hier auch der erste Ansatz und hatten wir mit einer PM Session schon umgesetzt. Hat auch geklappt, allerdings berichtete der TO von massiven Ping Aussetzern über die Tunnel Session. Vermutlich ein IPsec Lifetime Problem bzw. Mismatch zwischen beiden Routern. Der Tunnel war sehr instabil.
Es lag auch de facto am Tunnel selber, denn ein Ping ins Internet auf beiden Seiten zeigte im Quercheck keinen Ausfall wenn der Tunnel betroffen war.
Allerdings hatte der TO die Konfig nicht gezeigt so das man nicht vergleichen konnte ob die Konfig des von dir geposteten Links identisch war mit dem Setup des TOs. Insbesondere das Anpassen der IPsec Phases 1 und 2, der PFS Funktion auf der Digi Box damit das passt zur FB.
Da bleibt also eine Unsicherheit. Auch hier kann man (vermutlich) davon ausgehen das diese Instabilitäten sehr wahrscheonlich durch eine nicht angepasste IPsec Konfig auf der DigiBox verursacht werden die sich an die starren IPsec Credentials der FB anpassen muss da diese ja nicht konfigurierbar sind. Hier sollte man sich also ans Video halten auch was den automatischen Ping Check angeht.

Auf alle Fälle ist das ja ein lächliches IPsec Site to Site Setup was mit 2 pfSense in 20 Minuten erledigt ist in einem Kaskaden Setup. Mit den kommerziellen Zyxels auf beiden Seiten sollte das dann allemal auch klappen. Eine simple Basis Funktion eines solchen Produkts.
Der fehlerhafte Internet Zugang der Clients basiert zu 99% auf falschen Firewall Regeln. Es ist sicher besser und schafft weniger graue Haare bei allen Beteiligten wenn der TO da mal jemanden ranlässt der weiss was er macht.

ja, danke nochmals dafür! Das Problem war, dass ich ständig nicht nachvollziehbare Abbrüche hatte. Das VPN wurde übrigens von den Spezialisten der Telekom eingerichtet, ich denke, das kann ich als Laie auch nicht besser... Den Video hab ich mir angeschaut und konnte keine grossen Änderungen zu den bestehenden Einstellungen ausmachen. Dann ist die FB ja nicht gerade gesprächig mit Fehlermeldungen, da kam nicht viel, da ist die Digibox noch ergiebiger, aber aqui konnte aus dem Verlauf auch nix direkt ableiten, woran das liegen könnte. Deshalb die Idee mit den USGs von mir. Die zwei haben mit nem 100er zusammen nicht übermäßig viel gekostet. Deshalb auch die Überlegung von mir, die wieder raus zu werfen. Hab heut wieder 8 Stunden für nix investiert... Nach der Digibox-Fritzbox hatte ich noch ein stabiles VPN (OpenVPN) zwischen den beiden Synology NAS in den Betriebsstellen. Nur bin ich da nicht über die VPN-Netze rausgekommen. So konnte ich die jeweiligen VPN Endpunkte anpingen, aber nicht die Netzteilnehmer dahinter. Vielleicht wäre das eher in den Griff zu bekommen... Womöglich haben da nur die Roten gefehlt oder waren falsch. Hast mit so einer Konfig Erfahrung?

aber die Firewallregeln würde ich schon ausschliessen, denn die hatte ich ja ausgeschaltet auf dem USG sowie auf dem PC nach Netzumstellung. Oder gibr es noch eine Sperre für ausgehende Zugriffe aufs Netz, das auf der Digi /Fritzbox sein könnte? Aber der witz dabei ist ja: Stelle ich die Netzwerke um geht gar nix (mit oder ohne Firewall), wenn ich die erste Konfiguration nehme, also die 10er bzw. 20er Adressen auf den USGs, einen PC auf diese Adresse einstelle und dann ins Netz will, funktioniert das, wenn ich die firewall auf der usg abschalte.

Also ich mach jetzt am we mal die neue Verbindung mit digibox - fritte. Da ich nun soviel geändert habe setzte ich die boxen auf den stand vor den versuchen per rücksicherung zurück. dann lösche ich die vpn-verbindungen und mache das schritt für schritt nach der Anleitung, vielleicht habe ich doch eine einstellung übersehen. Mal sehen...

... hatten den Ausdruck der Einstellungen zu Hause, definitv alles gleich, bis auf den Ping-Generator. Allerdings hatte ich die Abbrüche bzw. nicht erreichbarkwit per ping innerhalb weniger Sekunden, ich denke kaum, dass der Generator hier Wunder vollbringen kann. ABER mal sehen, ich will ja nicht auf der faulen haut rumliegen...

So, nun habe ich sämtliche Umstellungen wieder zurükgenommen und das VPN von Fritte zu Digibox eingerichtet. Backup der NAS gegenseitig bricht halt immer wieder ab ob der schlechten Verbindung. Die Daten des VPN haben übereingestimmt, nur die Lease-Time war bei mir bei 7800, nun habe ich die auf 28800 lt. Video gestellt. Datenverbindung trotzdem "hakelig":

Ping wird ausgeführt für 192.168.2.1 mit 32 Bytes Daten:
Zeitüberschreitung der Anforderung.
Antwort von 192.168.2.1: Bytes=32 Zeit=60ms TTL=62
Antwort von 192.168.2.1: Bytes=32 Zeit=43ms TTL=62
Antwort von 192.168.2.1: Bytes=32 Zeit=40ms TTL=62
Ping-Statistik für 192.168.2.1:
Pakete: Gesendet = 4, Empfangen = 3, Verloren = 1
(25% Verlust),
Ca. Zeitangaben in Millisek.:
Minimum = 40ms, Maximum = 60ms, Mittelwert = 47ms

Ping wird ausgeführt für 192.168.1.1 mit 32 Bytes Daten:
Antwort von 192.168.1.1: Bytes=32 Zeit<1ms TTL=64
Antwort von 192.168.1.1: Bytes=32 Zeit<1ms TTL=64
Antwort von 192.168.1.1: Bytes=32 Zeit<1ms TTL=64
Antwort von 192.168.1.1: Bytes=32 Zeit<1ms TTL=64
Ping-Statistik für 192.168.1.1:
Pakete: Gesendet = 4, Empfangen = 4, Verloren = 0
(0% Verlust),
Ca. Zeitangaben in Millisek.:
Minimum = 0ms, Maximum = 0ms, Mittelwert = 0ms

Ping wird ausgeführt für 192.168.2.1 mit 32 Bytes Daten:
Antwort von 192.168.2.1: Bytes=32 Zeit=35ms TTL=62
Antwort von 192.168.2.1: Bytes=32 Zeit=37ms TTL=62
Antwort von 192.168.2.1: Bytes=32 Zeit=36ms TTL=62
Antwort von 192.168.2.1: Bytes=32 Zeit=36ms TTL=62
Ping-Statistik für 192.168.2.1:
Pakete: Gesendet = 4, Empfangen = 4, Verloren = 0
(0% Verlust),
Ca. Zeitangaben in Millisek.:
Minimum = 35ms, Maximum = 37ms, Mittelwert = 36ms

Ping wird ausgeführt für 192.168.2.50 mit 32 Bytes Daten:
Zeitüberschreitung der Anforderung.
Antwort von 192.168.2.50: Bytes=32 Zeit=33ms TTL=62
Antwort von 192.168.2.50: Bytes=32 Zeit=35ms TTL=62
Antwort von 192.168.2.50: Bytes=32 Zeit=37ms TTL=62
Ping-Statistik für 192.168.2.50:
Pakete: Gesendet = 4, Empfangen = 3, Verloren = 1
(25% Verlust),
Ca. Zeitangaben in Millisek.:
Minimum = 33ms, Maximum = 37ms, Mittelwert = 35ms

Die Tränen kommen mir dann, wenn ich das NAS als VPN verwende (OpenVPN). Da sind gefühlt 100 Dateien im Backup nach einem "Fingerschnipp" ausgetauscht gewesen (erste Variante nach Rauswurf der USGs, da gabs dann ne Menge Daten auszutauschen). Bei der Fritte-Digibox - Verbindung kann ich den einzelnen Dateien zuschauen, wie sie langsam runterlaufen. Das Problem war einfach, dass ich nicht aus dem VPN-Netz auf die Laufwerke komme, auch nicht mit der IP-Angabe statt Netbios, z.B. \\192.168.1.6\Daten als Laufwerksfreigabe für 192.168.2.21.

Da bei mir die Hölle los ist schließe ich das mal ab - und wer weiß, vielleicht brauche ich das VPN ja in 1-2 Monaten eh´ nicht mehr bei der derzeitigen "Corona"-Lage...

Ggfs melde ich mich dann im Forum bzgl. der NAS-Geschichte.

An dieser Stelle nochmals meinen ausdrücklichen und herzlichen Dank für die Unterstützung!

Grüße Oliver

Backup der NAS gegenseitig bricht halt immer wieder ab ob der schlechten Verbindung.

Die Internet Verbindungen sind ja nicht schlecht wenn man deinen Ping Tests glauben kann. Wenn die nicht gestört sind (was sie ja nicht sind) kann es also nur am Tunnel selber liegen.
Wenn die Keepalives jetzt stimmen ist das verwunderlich.
Hast du den internen Ping Timer auf dem Bintec auch aktiviert auf die FritzBox IP ??
Das ist wichtig damit der dir den VPN Tunnel immer aktiv hält. Ggf. verringerst du das Intervall da auf 5 Minuten oder 3 Minuten. Das sollte reichen um den Tunnel immer aktiv zu halten.

Bei der Fritte-Digibox - Verbindung kann ich den einzelnen Dateien zuschauen, wie sie langsam runterlaufen.

Das war zu erwarten.
Die FritzBox VPN Performance ist bekanntermaßen unter aller Kanone. Real sind da netto nie mehr als 2-3 Mbit drin. Das ist ein billiger Plaste Consumer Massenrouter der dafür auch nicht gemacht ist. Das das NAS da mit einer potenten CPU erheblich mehr bewegen kann ist evident !
Wenn du das so lösen willst brauchst du auf der anderen Seite auch eine Hardware die OpenVPN kann. Mindestens einen 35 Euro Raspberry 4, besser eine OpenVPN fähige Firewall in der Kaskade oder dort auch ein Mini NAS im Netz was eine OpenVPN Option hat.
Mit dieser Konstellation könntest du das rein über OVPN und dann mit erheblich anderer Performance lösen. Mit je einem NAS beidseitig oder einem RasPi 4 dann auch ohne jegliche Änderung an deinen bestehenden Netzen.

Hi Aqui, ich habe ja 2 Synology NAS: Hauptstelle das DS3018xs und in der Filiale das DS1515+. Auf der Haupstelle ist der VPN-Server installiert, in der Filiale der Client, Verbindung via OpenVPN. Läuft störungsfrei und wirklich wunderbar. ABER es geht eben nur das gegenseitige Backup der NAS (supergut und superschnell, ohne Fehlermeldungen, nicht wie bei der FB-DB-Verbindung), sonst nix. Weder der gegenseitige Aufruf der Webinterfaces der NAS noch der Router, kein RDP, keine Laufwerksfreigaben etc. DIE LASSEN MICH EINFACH NICHT AUS DEM VERD... VPN - Netz 10.8.0.1 (Server), 10.8.0.5 (Gateway) oder 10.8.0.6 (Client). Ich vermute, dass das daran liegt, dass auf beiden Systemen der Active Directory Server installiert ist (unterschiedliche Domänen) und dadurch evtl. die Zugriffsberechtigungen fehlen. Wobei das mit den Webinterfaces und RDP bei der Fritte-DB-Verbindung geht (ohne statische Routen eintragen zu müssen)! Ich kann auch nicht in der einen Domäne die User der anderen aufnehmen. Das hatte ich schon versucht, und die Filiale in die Domäne aufzunehmen geht auch nicht, da ich über das VPN kein Netbios senden und damit auch nicht die Domäne zur Aufnahme finden kann - wäre ja meine erste Wahl gewesen - deshalb war ich ja auch so "scharf" auf die USG´s, weil die ja wiederum Netbios ermöglichen und so vielleicht die Aufnahme der Filiale in die Domäne der Hauptstelle möglich gewesen wäre... Die Firewalls der NAS sind übrigens nicht aktiv, daran kann das also auch nicht liegen. Ein ähnliches Problem gab es auch schonmal hier im Forum, aber die Lösung passte bei mir auch nicht (hatte ich schon durch, bevor ich mich bzgl. der USGs gemeldet habe). Und um von der 192.168.2.21 (Filiale) die 10.8.0.1 (VPN Hauptstelle) anpingen zu können, habe ich erts mal in der Digibox Filiale die Route 10.8.0.0/24 192.168.2.50 (NAS Filiale) und in der NAS Filiale die Route 10.8.0.0/24 10.8.0.5 eingegeben. Wie gesagt, weiter als bis zur VPN-Hauptstelle geht da nix... Und auch wenn die NAS eigentlich die 10.8.0.5 kennen sollte - wenn ich diese Route raus nehme, dann kommt kein Ping mehr! Und die 10.8.0.5 kann man ja eh´nicht pingen, da die ja nur "virtuell" ist und wohl niemand im System kennt, außer eben OpenVPN. Muss ich ja auch nicht anpingen können, hat ja eh keine sonstige Funktion.

Das ist ja grauselig.

Bitte tu uns alle einen gefallen:

Verwende nicht in jedem deiner Posts das Größer-Zeichen ( ">" ) vor deinem Text. Das setzt deinen ganzen Text als Zitat ein (braun/gelbe Box).
Baue bitte sinnvolle Absätze ein.

So kann man dir nur schlecht helfen.

Back2Topic:
Was mir jetzt noch einfällt, bei dem FritzBox DigiBox-Problem: Die MTU-Size.

In der Fritte kannst du die leider nicht anpassen https://avm.de/service/fritzbox/fritzbox-7490/wissensdatenbank/publicati ...
In der Digibox geht das hier Seite 229 und davor

Teste mal, wie sich die Pingzeiten verändern, wenn du folgenden Befehl mal ausführst:

ping [IP-ADRESSE] -f -l 1456

Wobei IP-ADRESSE die IP der "Gegenseite" ist
und die 1456 die MTU-Size. Wenn er hier noch fragmentiert, verringere mal den Wert, wegen meiner in 5er Schritten

@claudelamont
Hier auch nochmals der wiederholte Appell die Zitatklammern bitte richtig zu benutzen oder sie ganz wegzulassen !! Kollege @em-pie hat es ja auch schon richtigerweise angemerkt.
Deine Antwort oben ist ohne jegliche Struktur und Absätze und eine echte Qual zu lesen. Von der technischen Übersicht mal gar nicht zu reden...

OK - ich gebs zu - ich blicke das mit dem > Zeichen nicht, also wie soll ich hier beginnen?
Der Ping mit der Anweisung bringt folgendes Ergebnis:

Ping wird ausgeführt für 192.168.2.1 mit 1456 Bytes Daten:
Antwort von 109.192.213.30: Paket müsste fragmentiert werden, DF-Flag ist jedoch gesetzt.
Paket müsste fragmentiert werden, DF-Flag ist jedoch gesetzt.
Paket müsste fragmentiert werden, DF-Flag ist jedoch gesetzt.
Paket müsste fragmentiert werden, DF-Flag ist jedoch gesetzt.
Ping-Statistik für 192.168.2.1:
Pakete: Gesendet = 4, Empfangen = 1, Verloren = 3
(75% Verlust),

Dann wollte ich mich auf die Digibox aufschalten um den MTU - Wert testweise zu ändern: keine Verbindung

Ping wird ausgeführt für 192.168.2.1 mit 32 Bytes Daten:
Zeitüberschreitung der Anforderung.
Zeitüberschreitung der Anforderung.
Zeitüberschreitung der Anforderung.
Zeitüberschreitung der Anforderung.
Ping-Statistik für 192.168.2.1:
Pakete: Gesendet = 4, Empfangen = 0, Verloren = 4
(100% Verlust),

Wieder keine Verbindung möglich

, wie weiter oben zu sehen war, funktionierte das abe ja vor ca. ner Stunde noch.

In der Fritte sieht man aber das VPN mit grünem Punkt (also vorhanden)! Wenn ich die Verbindung öffne, steht in der ersten Zeile der Verbindungsname und darunter 2 x die feste IP der Gegenstelle untereinander, ist das normal? Vielleicht hat die FB ne Macke?
Sieht also so aus:
VPN_Verbindung
XX.XXX.XXX.XX 0.0.0.0 192.168.2.0 /24 Zugriffe auf entferntes Netz (grüne Lampe)
XX.XXX.XXX.XX

OK - ich gebs zu - ich blicke das mit dem > Zeichen nicht, also wie soll ich hier beginnen?

Ist doch kinderleicht....
Satz den du ziteiren willst per cut and paste in die Zwischenablage.
Ein ">" ganz VORNE an den Zeilenanfang, LEERZEICHEN und dann den Satz oder Abschnitt reinpasten...Fertisch
Das Ergebnis kannst du doch auch immer SELBER sehen danach. Und wenn es so gruselig aussieht wie oben korrigiert man das.
Zurück zum Thema...

Die MTU Size im Tunnel ist ein guter und wichtiger Punkt !
https://baturin.org/tools/encapcalc/

Setzt man Standard xDSL mit PPPoE voraus wie es üblich ist und ESP Header ist es sogar noch weniger. (1454)
Du solltest also erstmal darunter gehen um sicher zu sein (1420).

ABER es geht eben nur das gegenseitige Backup der NAS

Das ist klar, weil du vermutlich eine falsche Server und Client Konfig auf den OpenVPN Server und Client Prozessen hast die nicht routen zwischen beiden IP Netzen dann.
Das musst du, wenn man es über das GUI nicht machen kann, immer über die Shell auf dem NAS machen und manuell anpassen.
Das Tutorial hier zeigt dir wie die beiden Konfig Dateien auszusehen haben wenn man zwischen beiden Netzen transparent routen will:
OpenVPN - Erreiche Netzwerk hinter Client nicht

Ich vermute, dass das daran liegt, dass auf beiden Systemen der Active Directory Server installiert ist

Nein !
Das hat mit IPv4 Routing nicht das Geringste zu tun und dient einzig nur zur User Verwaltung welche wieder bei OpenVPN irrelevant ist. Ganz andere Baustelle.
Was wohl eher der Fall ist, ist das auf dem NAS das IPv4 Forwarding nicht aktiviert ist. Damit ist dann ein VPN Routing in die lokalen LAN Segmente technisch ausgeschlossen. Siehe hier:
Merkzettel: VPN Installation mit OpenVPN
Auch hier müsste man das über die NAS Shell dann mit PuTTY und SSH manuell machen wenns übers GUI nicht geht !!

da ich über das VPN kein Netbios senden und damit auch nicht die Domäne zur Aufnahme finden kann

Das muss man nur aktivieren im OpenVPN Setup.
Was aber Prinzipien bedingt nicht geht sind NetBios UDP Broadcasts. Also z.B. das Autodiscovery der Namen. Das ist aber auch überflüssig und zudem für die Tunnel Performance kontraproduktiv, denn das kann man genausogut statisch in die hosts oder lmhosts Datei der Clients eintragen.
Für dich aber so oder so auch überflüssig wenn du ein AD mit DNS Server und Namen da laufen hast da geht das eh automatisch.

Das grundsätzliche Problem ist ein Designproblem. Du versuchst maximale Performance aus etwas rauszukitzeln was mit billigem Consumer Equipment rennt oder auf Endgeräten die dafür nicht vorgesehen sind. Alles also mehr oder minder ein Workaround oder Frickellösung. Das geht in gewissen Grenzen auch wenn man weiss was man macht und an den entsprechenden richtigen Schrauben dreht.
Besser für die Betriebssicherheit wäre aber 2 Firewalls oder entsprechend potente VPN Router in beiden Locations, ein Site to Site Tunnel und gut iss.
So würde man sowas betriebssicher und verlässlich lösen. Aber du hast vermutlich auch in deiner nicht ganz einfachen Situation vermutlich ganz andere Dinge im Kopf. Zu Recht, macht aber natürlich die Aufgabenstellung nicht einfacher.

Antwort von 109.192.213.30: Paket müsste fragmentiert werden, DF-Flag ist jedoch gesetzt.

Wie befürchtet...

Größere Frames werden vermutlich im VPN Tunnel wegen der falschen MTU gedroppt. Daher auch die Aussetzer....
Richtige VPN Router und Firewalls würden sowas korrekt anpassen...

Vielleicht hat die FB ne Macke

Rennt da ein FritzOS größer oder gleich 7.1.0 ?

Besser für die Betriebssicherheit wäre aber 2 Firewalls oder entsprechend potente VPN Router in beiden Locations, ein Site to Site Tunnel und gut iss.

Was kostet so etwas denn ca.? Hard-, Software und Einrichtung? Irgend eine Ahnung?

Rennt da ein FritzOS größer oder gleich 7.1.0 ?

FRITZ!OS: 07.13 - da bin ich schon immer hinterher, dass alles aktuell ist (was aber manchmal auch nicht gut ist)...

Neue VPN-Verbindung über Syn NAS:
Hallo, ich schon wieder

Habe nun die VPN-Verbindung über die beiden NAS erstellt. Leider ist der Leitfaden für OpenVPN nicht 100% passend, da die Synos wohl eine "abgespeckte" Version haben.

Hier mal meiner Server-Config:

push "route 192.168.1.0 255.255.255.0"
push "route 192.168.2.0 255.255.255.0"
push "route 10.8.0.0 255.255.255.0"
route 192.168.1.0 255.255.255.0
route 192.168.2.0 255.255.255.0
client-to-client
dev tun
management 127.0.0.1 1195
server 10.8.0.0 255.255.255.0
dh /var/packages/VPNCenter/target/etc/openvpn/keys/dh3072.pem
ca /var/packages/VPNCenter/target/etc/openvpn/keys/ca.crt
cert /var/packages/VPNCenter/target/etc/openvpn/keys/server.crt
key /var/packages/VPNCenter/target/etc/openvpn/keys/server.key
max-clients 5
comp-lzo
persist-tun
persist-key
verb 3
#log-append /var/log/openvpn.log
keepalive 10 60
reneg-sec 0
plugin /var/packages/VPNCenter/target/lib/radiusplugin.so /var/packages/VPNCenter/target/etc/openvpn/radiusplugin.cnf
client-cert-not-required
username-as-common-name
duplicate-cn
status /tmp/ovpn_status_2_result 30
status-version 2
proto udp6
port 1194
cipher AES-256-CBC
auth SHA512

Und hier die vorkonfigurierte Client-Config:

dev tun
tls-client
remote 1XX.XXX.XXX.XXX 1194
pull
proto udp
script-security 2
comp-lzo
reneg-sec 0
cipher AES-256-CBC
auth SHA512
auth-user-pass
<ca>

BEGIN CERTIFICATE-----
XXX

END CERTIFICATE-----
</ca>

Hier fehlt mir z.B. das /ccd - Verzeichnis bzw. wie Möglichkeit, ifconfig-push und iroute über diesen Weg zu konfigurieren.
Könnte man den iroute auch direkt in die Config schreiben? Oder das Verzeichnis manuell anlegen - aber wo und welchen Namen müsste dann die Config haben? Ich hab ja kein ca/cert/key - Eintrag auf dem Client?

An der Fritte sind die statische Routes auf:
10.8.0.0/24 192.168.1.50 (NAS-VPN Hauptstelle)
192.168.2.0/24 192.168.1.50

Auf der Digibox hatte ich die Routes auf:
10.8.0.0/24 192.168.2.50 (NAS-VPN Filiale)
192.168.1.0/24 192.168.2.50
-> musste ich wieder rausnehmen, da dann die Verbindung via Quickconnct nicht mehr geht und über VPN ebenfalls nicht - da bin ich von der Filiale abgeschnitten und muss dauernd für Versuche hinfahren

!

Das Wichtigste ist erst mal: VPN rennt schnell und vvor allem stabil, das gegenseitige Backup der Synos klappt prima.
Bei der VPN-Verbindung zwischen FB und DB waren ja ständig Abbrüche.
Ping von Filiale auf die Endgeräte der Haupstelle geht!
z.B. Ping von Filiale 192.168.2.21 -> 192.168.1.25 (wo der SQL-Server sitzt) funktioniert!
192.168.1.25 ist eine Win10 64 Maschine, die auf einer virtuellen Maschine der Syno läuft (Domänenmitglied).

Leider kann keine Laufwerksfreigabe bekommen. Beispiel \\192.168.1.25\"Freigabe" -> hier wird nix rausgegeben bzw. gefunden.
Muss ich hierzu auf dem Windows-Client die RAS-Dienste aktivieren oder die Firewall ändern?

Dann funktioniert der Weg zurück nicht!
Ping von Hauptstelle 192.168.1.21 -> 10.8.0.6 = ok (VPN Filiale)
Aber
Ping 192.168.1.21 -> 192.168.2.31 (Drucker Filiale) = Zeitüberschreitung der Anforderung
Wäre nicht zwingend erforderlich, aber schon wirklich gut! Außerdem geht´s mir ums Prinzip - das muss doch gehen?

tracert 192.168.2.31 macht "Ringelreihen"? Fehlt da noch eine Route?

Routenverfolgung zu 192.168.2.31 über maximal 30 Hops

1 <1 ms 1 ms 1 ms 192.168.1.1
2 <1 ms <1 ms <1 ms XXX.trcgd.local [192.168.1.50]
3 2 ms 1 ms <1 ms 192.168.1.1
4 2 ms 2 ms <1 ms XXX.trcgd.local [192.168.1.50]
5 <1 ms * 3 ms 192.168.1.1
6 * * * Zeitüberschreitung der Anforderung.
7 5 ms * * 192.168.1.1
8 * * * Zeitüberschreitung der Anforderung.
9 * * * Zeitüberschreitung der Anforderung.
10 * * * Zeitüberschreitung der Anforderung.

Ach ja, auf beiden Synos gilt:
cat /proc/sys/net/ipv4/ip_forward = 1

Vielen Dank schon vorab für Vorschläge...

Hallo, ich schon wieder

Lange nichts gelesen von dir !

Hier mal meiner Server-Config:
push "route 192.168.1.0 255.255.255.0"
push "route 192.168.2.0 255.255.255.0"
push "route 10.8.0.0 255.255.255.0"

Leider wieder komplett falsch !!

Das interne OpenVPN Netz an die Clients zu "pushen" ist doch wieder kompletter Blödsinn ! Das muss da raus !
Hast du am Server 2 lokale IP Netze ???
Wenn ja ist das Push Kommando für .1.0 und .2.0 richtig. Wenn nein und das 2te Netz das Netz der remoten Seite ist ist das falsch und muss hier entfernt werden !!
Als Push Route Kommando steht einzig nur das lokale IP Netz drin. Logisch, denn das soll ja an den Client !
Und das remote Netz nur rein als Kernel Route des Servers mit route <remotes_ip_netz>
Das lokale IP netz ist völlig sinnfrei und kontraproduktiv als Kernel Route, denn das kennt der kernal logischerweise selber da es direkt an ihm angeschlossen ist !
Mit anderen Worten:
Routingtechnisch alles verbockt und es ist vollkommen klar das das in die Hose gehen muss !

Bitte halte dich an diese Vorgabe, da ist das doch alles im Detail erklärt:
OpenVPN - Erreiche Netzwerk hinter Client nicht

client-to-client

Auch Schwachsinn (sorry) bei einem Site-to-Site Netzwerk. Da gibts doch gar keine Kommunikation der Clients untereinander. Muss auch raus.

comp-lzo

Auf Kompression sollte man wegen der großen Security Gefahr besser komplett verzichten ! Siehe auch:
https://community.openvpn.net/openvpn/wiki/VORACLE

proto udp6

Das ist natürlich auch Unsinn, denn dann nutzt dein Server rein nur IPv6 für die Connectivity. Eher ziemlich kontraproduktiv wenn du deine gesamte IP Kommunikation IPv4 basieren hast ! Hier solltest du zwingend proto udp4 konfigurieren !!
Client....
Soweit OK. Auch hier besser proto udp4 verwenden !
Sauber sollten deine Konfigs so aussehen:
Server:
dev tun
proto udp4
port 1194
server 10.8.0.0 255.255.255.0
push "route 192.168.1.0 255.255.255.0"
route 192.168.2.0 255.255.255.0
iroute 192.168.2.0 255.255.255.0
management 127.0.0.1 1195
dh /var/packages/VPNCenter/target/etc/openvpn/keys/dh3072.pem
ca /var/packages/VPNCenter/target/etc/openvpn/keys/ca.crt
cert /var/packages/VPNCenter/target/etc/openvpn/keys/server.crt
key /var/packages/VPNCenter/target/etc/openvpn/keys/server.key
max-clients 5
persist-tun
persist-key
verb 3
#log-append /var/log/openvpn.log
keepalive 10 60
reneg-sec 0
plugin /var/packages/VPNCenter/target/lib/radiusplugin.so /var/packages/VPNCenter/target/etc/openvpn/radiusplugin.cnf
client-cert-not-required
username-as-common-name
duplicate-cn
status /tmp/ovpn_status_2_result 30
status-version 2
cipher AES-256-CBC
auth SHA512

Client:
dev tun
tls-client
remote <Provider_ip_FritzBox> 1194
pull
proto udp4
script-security 2
reneg-sec 0
cipher AES-256-CBC
auth SHA512
auth-user-pass
<ca>
BEGIN CERTIFICATE-----
XXX
END CERTIFICATE-----
</ca>

Die oben genannten statischen IPv4 Routen sind richtig und müssen zwingend auf den Routern sein ansonsten ist eine IP Verbindung nicht möglich. Wenigstens nicht mit IPv4 !
Da du aber den Kardinalsfehler begangen hast und das OpenVPN nur für IPv6 definiert hast sind die Routen sehr wahrscheinlich sinnfrei, weil deine gesamte VPN Connectivity dann auf IPv6 basiert. Deshalb kommen auch diese wirren Ergebnisse da raus beim Pingen und Tracerouten !
Das solltest du besser nochmal genau prüfen und natürlich korrigieren !
So wäre jedenfalls die OVPN Konfig routingtechnisch sauber anstatt des Kauderwelches was du da verbockt hast.

Der Rest sind Windows und Samba Sharing Probleme durch falsche und fehlerhafte Rechte.
Mit dem eigentlichen IP Netz und VPN hat das nichts mehr zu tun !

Leider wieder komplett falsch !!

ok ok - ABER zu meiner Verteidigung muss ich sagen, dass die Configs von der Synology ohne mein Zutun angelegt werden!
Die Originale Routings waren (vorgegeben bzw. von Syno vorkonfiguriert)
push "route 192.168.1.0 255.255.255.0"
push "route 10.8.0.0 255.255.255.0"
Auch das udp6 war vorgegeben sowie das comp-lzo...

DER Rest ist von mir verbockt - ich gestehe!

WIE IMMER! Herzlichen Dank, das spiele ich sofort ein und teste dann wieder - uuups! für die Routen auf der Digibox muss ich erst noch 30km hinfahren. Zum Glück ist morgen Feiertag, ich werde berichten

Bis die Tage...

dass die Configs von der Synology ohne mein Zutun angelegt werden!

Krank, denn die sind OpenVPN syntaktisch vollkommen falsch !
Aber muss man sich wohl auch nicht groß wundern wenn sich NAS Hersteller an Netzwerk VPN Techniken versuchen...

Dann hoffen wir mal das das nun alles VPN technisch in die richtigen Bahnen kommt...?!

Krank, denn die sind OpenVPN syntaktisch vollkommen falsch !

…nachdem ich wieder nach 20 Minuten Arbeit (Echtzeitbearbeitung Forum) rausgeflogen bin – hier die Kopie aus Word 😊 – das zweite Mal in meiner "Laufbahn" hier, vielleicht habe ichs nun gelernt…

Also die Kopie aus Deinem Vorschlag funktioniert leider nicht: Bild Fehler_Server01
Nach der Fehlermeldung steht eine andere Config drinne – wird irgendwo her kopiert (siehe mein Bruchteil-Beitrag oben vor Abbruch). Der Witz dabei: die geht nach einem erneuten Startversuch auch nicht! Erst nach Rücksicherung der ursprünglichen – von mir allerdings abgeänderten Datei – aus der Installation geht wieder: Bilder Bestätigung_Server01+02.
Nun habe ich Schritt für Schritt die (relevanten) Optionen aus der Config rausgenommen bzw. verändert und getestet:

push "route 10.8.0.0 255.255.255.0"
raus-> Server Start möglich, Verbindung da, lasse ich raus
ABER nach Start des Servers wars wieder drin… Wird schon nicht stören?

push "route 192.168.2.0 255.255.255.0"
raus-> Server Start möglich, Verbindung da, lasse ich raus

route 192.168.1.0 255.255.255.0
raus-> Server Start möglich, Verbindung da, lasse ich raus

client-to-client
raus-> Server Start möglich, Verbindung da, lasse ich raus

comp-lzo
raus-> Server Start möglich, Verbindung da, lasse ich raus

proto udp6
geändert auf udp4 -> Server Start möglich, Verbindung da
ABER: der „Sack“ ändert nun jedes Mal den Eintrag auf udp6! Egal ob ich udp4 oder udp reinschreibe. Dann ist´s halt so. Denn der Ping via IPV4 ging ja von der Filiale auf die Hauptstelle, so what…

Und zum Schluss noch den Eintrag hinzugefügt:
iroute 192.168.2.0 255.255.255.0
HA! Die letzte Option wars dann – wie immer ☹
Nach dem Eintrag kein Server Start möglich!
Heist das dann, dass ich deswegen das Netz der Filiale 192.168.2.0 hinter dem VPN 10.8.0.6 (Client) nicht sehen kann? Gibt es zur iroute eine Alternative? Per „push“ vom Server? oder sonst?

Server sieht jetzt so aus:

push "route 192.168.1.0 255.255.255.0"
push "route 10.8.0.0 255.255.255.0"
dev tun
#iroute 192.168.2.0 255.255.255.0
management 127.0.0.1 1195
server 10.8.0.0 255.255.255.0
dh /var/packages/VPNCenter/target/etc/openvpn/keys/dh3072.pem
ca /var/packages/VPNCenter/target/etc/openvpn/keys/ca.crt
cert /var/packages/VPNCenter/target/etc/openvpn/keys/server.crt
key /var/packages/VPNCenter/target/etc/openvpn/keys/server.key
max-clients 5
persist-tun
persist-key
verb 3
#log-append /var/log/openvpn.log
keepalive 10 60
reneg-sec 0
plugin /var/packages/VPNCenter/target/lib/radiusplugin.so /var/packages/VPNCenter/target/etc/openvpn/radiusplugin.cnf
client-cert-not-required
username-as-common-name
duplicate-cn
status /tmp/ovpn_status_2_result 30
status-version 2
proto udp6
port 1194
cipher AES-256-CBC
auth SHA512

Und bei der Client Config: udp4 geht nicht, aber udp (ohne 4 oder 6) nimmt er, habe ich dann so übernommen…

dev tun
tls-client
remote <feste IP>
pull
proto udp
script-security 2
reneg-sec 0
cipher AES-256-CBC
auth SHA512
auth-user-pass
<ca>

BEGIN CERTIFICATE-----
XXX

END CERTIFICATE-----

</ca>

Jetzt setze ich noch die statischen Routes auf der Digibox der Fliliale, dann mal sehen, ob´s nicht doch noch klappt…

Grüße

LÖSUNG: nun funktionierts – viel Text, aber wens interessiert 😉

Diese Schritte haben bei mir nun endlich zum Erfolg geführt. Vieles ist nicht auf meiner „Miste“ gewachsen, sondern ein Sammelsurium aus verschiedenen Foren, die ich leider nicht mehr alle nennen kann – man möge mir dies verzeihen!

Zuerst wird auf beiden NAS das IP Forwarding „dauerhaft“ (Autostart/Script) aktiviert:

Zugang zur Synology-NAS:
- Einfache Datei-Verwaltung: Midnight Commander auf Synology installieren
- Systemsteuerung – Terminal & SNMP – SSH-Dienst aktivieren
- Zugang mit PUTTY
- Midnight Commander wird mit „mc“ gestartet

Erstellen eines Scriptes: Syno-Forum von Fau/Götz
- Der Windows-Text-Editor ist weniger geeignet, da dieser Formatierungszeichen einfügt. Hab den trotzdem benutzt und die Zeichen eben gelöscht…
- Der Dateinamen muss mit 'SXX' anfangen, wobei das 'XX' 2stellige Zahl darstellt
- Beispiel: 'S01_IP_Forward.sh'
- Es benötigt folgende Rechte: '755'
- chmod 755 /usr/local/etc/rc.d/S01_IP_Forward.sh
- Das Script muss in folgendes Verzeichnis kopiert werden: /usr/local/etc/rc.d
- chmod 755 /usr/local/etc/rc.d/S01_IP_Forward.sh
- Erfolg nach Neustart prüfen mit: cat /proc/sys/net/ipv4/ip_forward (Antwort 0 = aus, 1 = ein)

Inhalt des Scriptes:
#!/bin/sh
case "$1" in
start)
echo "1" >/proc/sys/net/ipv4/ip_forward
;;
stop)
exit 1
;;
esac

Den VPN Server übers Paketzentrum auf der Hauptstelle installieren, OpenVPN wählen, Konfigurationsdateien (für Client) exportieren.

VPNConfig.ovpn (Client aus dem Export) anpassen: sieht bei mir so aus

dev tun
tls-client
remote <feste IP der Hauptstelle>
pull
proto udp
script-security 2
reneg-sec 0
cipher AES-256-CBC
auth SHA512
auth-user-pass
<ca>

BEGIN CERTIFICATE-----
XXX

END CERTIFICATE-----
</ca>

OpenVPN-Client auf der Filiale installieren über Systemsteuerung – Netzwerk – Netzwerk-Schnittstelle – Erstellen – VPN-Profil erstellen.

- VPNConfig.ovpn importieren
- ca.crt (aus der Export-Datei) importieren

Client ist damit erst mal feddich…

Server Bearbeiten:
Die openvpn.conf liegt in Verzeichnis:
/var/packages/VPNCenter/etc/openvpn

…und sieht bei mir so aus:

push "route 192.168.1.0 255.255.255.0"
push "route 10.8.0.0 255.255.255.0"
push "route 192.168.2.0 255.255.255.0"

dev tun
management 127.0.0.1 1195
server 10.8.0.0 255.255.255.0
dh /var/packages/VPNCenter/target/etc/openvpn/keys/dh3072.pem
ca /var/packages/VPNCenter/target/etc/openvpn/keys/ca.crt
cert /var/packages/VPNCenter/target/etc/openvpn/keys/server.crt
key /var/packages/VPNCenter/target/etc/openvpn/keys/server.key
max-clients 5
persist-tun
persist-key
verb 3
#log-append /var/log/openvpn.log
keepalive 10 60
reneg-sec 0
plugin /var/packages/VPNCenter/target/lib/radiusplugin.so /var/packages/VPNCenter/target/etc/openvpn/radiusplugin.cnf
client-cert-not-required
username-as-common-name
duplicate-cn
status /tmp/ovpn_status_2_result 30
status-version 2
proto udp6
port 1194
cipher AES-256-CBC
auth SHA512

Hier folgende Änderungen manuell vornehmen (von Frank / Syno-Forum):

Einen Ordner anlegen mit der Bezeichnung "ccd" unter folgendem Pfad. /var/packages/VPNCenter/etc/openvpn
In diesem Ordner ein File mit dem Namen deines Benutzers anlegen der sich über OpenVPN einwählt.
Also beispielsweise "admin". In diesem File muss folgender Inhalt stehen.
iroute 192.168.2.0 255.255.255.0

Jetzt das überschreiben der ccd Files verhindern. In der Datei
/var/packages/VPNCenter/target/etc/openvpn/radiusplugin.cnf
folgende Zeile entsprechend anpassen
overwriteccfiles=false

In der Config des OpenVPN-Servers unter
/var/packages/VPNCenter/etc/openvpn/openvpn.conf
folgende Zeilen einfügen.

route 192.168.178.0 255.255.255.0
client-config-dir ccd
client-to-client

Sieht bei mir dann aktuell komplett so aus:

push "route 192.168.1.0 255.255.255.0"
push "route 10.8.0.0 255.255.255.0"
push "route 192.168.2.0 255.255.255.0"
route 192.168.2.0 255.255.255.0

dev tun
management 127.0.0.1 1195
server 10.8.0.0 255.255.255.0
dh /var/packages/VPNCenter/target/etc/openvpn/keys/dh3072.pem
ca /var/packages/VPNCenter/target/etc/openvpn/keys/ca.crt
cert /var/packages/VPNCenter/target/etc/openvpn/keys/server.crt
key /var/packages/VPNCenter/target/etc/openvpn/keys/server.key
max-clients 5
client-config-dir ccd
client-to-client
persist-tun
persist-key
verb 3
#log-append /var/log/openvpn.log
keepalive 10 60
reneg-sec 0
plugin /var/packages/VPNCenter/target/lib/radiusplugin.so /var/packages/VPNCenter/target/etc/openvpn/radiusplugin.cnf
client-cert-not-required
username-as-common-name
duplicate-cn
status /tmp/ovpn_status_2_result 30
status-version 2
proto udp6
port 1194
cipher AES-256-CBC
auth SHA512

Und zu guter Letzt den VPN-Server neustarten nicht vergessen.

Wenn Du noch statische Routen auf den jeweiligen Routern angibst kannst Du sogar entsprechend von jedem Gerät auf die Geräte des anderen Subnetzes zugreifen. Dann Häkchen im Clienten "Anderen Geräten ...." nicht vergessen.

FEDDICH! Läuft bei mir prima…

Vielleicht wende ich mich dann jetzt doch noch der Variante mit den USG´s zu, mal schauen?

Grüße und erst mal Ende von der Nervensäge.

Wie bereits mehrfach gesagt das push "route 10.8.0.0 255.255.255.0" bei dir ist kompletter Blödsinn und solltest du zum Feinschliff auch besser nochmal entfernen auf der Konfig Datei um die Betriebssicherheit zu erhöhen.
Es ist doch vollkommen sinnfrei das der OVPN Server sein eigenes, internes IP Netz an den Client pusht was der so oder so immer automatisch beim Verbindungsaufbau mitbekommt.
Dieser Eintrag ist also falsch und überflüssig.

Aber gut wenns nun klappt wie es soll.
Wenn man allerdings diese Masse der gruseligen Klimmzüge sieht um ein NAS dann doch noch zu einem OVPN Server und Client zu "verbiegen" muss man sich ernsthaft fragen welchen Sinn sowas hat.
Ein NAS ist ein NAS und sollte das auch immer bleiben. Von den gravierenden Sicherheitsbedenken ungeschützten Internet Traffic so ins interne LAN zu lassen mal lieber auch gar nicht zu reden ! Eine Frickelei die man sich in einem Administrator Forum sicher nicht als gutes Beispiel für ein Firmennetz nehmen sollte...

Aber egal... Der Erfolg gibt dir Recht und wenn du mit den o.a. Nachteilen leben kannst ist ja gut. Hauptsache die Lösung ist für dich OK und klappt für deine Anwendungen.
Richtig und sicher hätte man es aber mit 2 potenten VPN Routern oder Firewalls in der Peripherie und einem IPsec Tunnel zwischen den Locations gelöst.
Aber unter deinen spezifischen Bedingungen derzeit ist das ein guter Erfolg bei dem du sicher auch VPN technisch viel gelernt hast !

Case closed...

...jaaa, gelernt habe ich einiges. Und das mit den Routern ist nicht aus der Welt - 2 Dinge sprechen allerdings aktuell dagegen:
- ich finde kein Modem, das mit Vodafone ex. Unitymedia 1.000MBit Kabelanschluss funktioniert - die geben nur die Fritte frei (und das VPN mit Digibox ist keine Option)!
- Die TK-Anlge = Digibox (Filiale) kann/soll nicht ersetzt werden, wurde erst gekauft und ist noch nicht abgeschrieben. Parallel die USG´s einzusetzen war ja auch "Mumpitz" und keine sinnvolle Lösung.

So habe ich nun nicht die beste, aber auf jeden Fall funktionierende und dazu noch performante Lösung.

Für Vorschläge bin ich immer offen. Hast Du eine Idee für ein 1.000MBit - Kabelmodem, das mit Vodafone funktioniert? Die geben jedenfalls keines raus und auch keine Info dazu - ich denke, da komme ich nicht weiter...
Die Digibox kann ich auch hinter einen Router klemmen als "nur" TK-Anlage. Dann würde ich dort ein 100MBit Modem und einen vernünftigen (VPN)-Router benötigen. Geht das was? Aber bitte nur einen kompletten Router mit diesen Funktionen, kein Raspi o.ä.

Was wäre denn gut? Könnte ich dann die USGs vernünftig nutzen? Die sind schon da. Oder LANCOM? Oder sonst?