03.07.2021

20748

Zugriff auf Gerät an LTE Router via VPN

Guten Abend miteinander.

Ich bin gerade dabei, einen Fernzugriff auf die WLAN-Steuerung, eines Whirlpools am Ferienhausstandort, einzurichten. Da die Steuerung an einem LTE-Router hängt, welcher vom Mobilnetzbetreiber keine öffentliche IP zugewiesen bekommt, versuche ich die VPN Verbindung nun in umgekehrter Richtung aufzubauen.

Das ganze sieht jetzt wie folgt aus: Zuhause steht ein Netgear Router, welcher mit fixer, öffentlicher IP 5.149.xxxx am Internet hängt. Dieser dient als VPN Server. Zusätzlich habe ich ein DYNDNS mit "mynetgear" - Domain eingerichtet. Die Pool-Steuerung ist mit dem LTE Router verbunden, auf welchem DD-WRT installiert ist. Der LTE Router dient als VPN Client und baut so eine Verbindung mit dem Router Zuhause auf. So weit so gut. Momentan kann ich den LTE Router vom Heimnetz aus problemlos anpingen. Dies habe ich bisher unter der IP 192.168.2.2 getan, welche ich dem Webinterface des Netgear Routers entnommen habe.

Mein Problem ist nun, dass ich die Geräte, welche am LTE Router hängen, sprich, die Geräte, welche am VPN Client hängen, unter deren IP Adressen nicht anpingen kann. Beispiel: Laptop mit der IP 192.168.3.115 (IP wurde dem Webinterface des LTE Routers entnommen) kann vom Heimnetz aus nicht angepingt werden. Die lokale IP des VPN Clients lautet 192.168.3.1 Leider habe ich im Bereich Routing überhaupt keine Erfahrung, ich hoffe ihr könnt mir da ein wenig auf die Sprünge helfen. Als Gateway habe ich auf dem LTE Router den Standartgateway des Netgear Routers (Zuhause) eingetragen. Grundsätzlich wäre mein Ziel, der Whirlpool-Steuerung "vorzugaukeln", dass sie bei uns Zuhause steht, da diese nur von Geräten bedient werden kann, die mit dem selben Wlan-Netzwerk verbunden sind.

Falls ihr noch weitere Informationen benötigt um mir weiter zu helfen, lasst es mich wissen!
Besten Dank
Silvio

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

Content-ID: 896130848

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

Ausgedruckt am: 04.11.2024 um 22:11 Uhr

63 Kommentare

Neuester Kommentar

Hallo,

Zitat von @tacklearmy:
Der LTE Router dient als VPN Client und baut so eine Verbindung mit dem Router Zuhause auf.

Und wie der Name schon sagt, ein VPN CLIENT. Mit einen Standort zu Standort VPN ist es besser (Site-to-Site).

So weit so gut.

Eher soweit so schlecht

Gruß,
Peter

ähm, welches VPN wird denn eingesetzt? Im Prinzip muss doch nur das Routing vom Client raus konfiguriert werden

Wie man das grundsätzlich löst und die Schritte dazu beschreibt dieser Thread:
Zwei Mobilfunkrouter (TP-Link MR200) per VPN verbinden, ev. per externen VPN-Gateway (VPS-Server)
Ob der VPN Server dabei einer bei einem Hoster ist oder bei dir im Heimnetz lokalisiert ist spielt dabei keinerlei Rolle. Ebenso das verwendete VPN Protokoll. Beim Heimnetz ist nur wichtig das diese Seite eine öffentliche IP Adresse vom Provider bekommt.
Es wäre für eine zielführende Hilfe aber in der Tat hilfreich dein VPN Setup genauer zu kennen. Kollege @Visucius hat Recht was er oben anmerkt. Sollte man als Threadersteller auch eigentlich selber drauf kommen, denn hellsehen können wir hier (noch) nicht.

Vielen Dank für die Anmerkungen.

Sorry, ich habe ganz vergessen zu erwähnen, dass die VPN-Verbindung über OPENVPN im TUN-Modus läuft. (Konfigurationen von Server + Client habe ich als Bilder angehängt)

Additional Config in DDWRT VPN Client:

client
resolv-retry infinite
nobind
persist-key
persist-tun
cipher AES-128-CBC
verb 5
auth-nocache
remote-cert-tls server

Site-To-Site VPN ist mit der original Firmware des Netgear Routers meines Wissens nicht möglich, oder täusche ich mich da?
Der Heimnetzrouter erhält eine öffentliche IP-Adresse.

Gruss Silvio

Konfigurationen von Server + Client habe ich als Bilder angehängt

Man sieht aber nur die Client Konfig ?! Server Konfig fehlt.

Auffällig ist auch das du auf einer Seite den UDP Port 12973 nutzt auf der anderen Seite aber nicht was dann den Default 1194 nutzt. Wäre zumindestens ein möglicher Grund warum der Tunnelaufbau scheitert.
Zudem sollte man wenn man nicht den Default Port nutzt besser keine reservierten IANA Ports verwenden sondern immer die dafür freien Ephemeral Ports von 49152 bis 65535 !
Wichtig ist mal das Server Log zu sehen wenn der Client sich einwählt. Client Log wäre auch hilfreich...

Grundlagen zum OpenVPN Setup , wie immer, HIER.

Die Server Konfig kann ich leider nicht zeigen, da ich selbst keinen Zugriff darauf habe. Die Netgear Firmware lässt mich die Konfig Datei nicht sehen, ich kann nur die Einstellungen vornehmen, welche auf dem obigen Screenshot zu sehen sind. Der UDP Port 12973 soll gemäss Netgear Konfig als Port bei TUN-Modus verwendet werden, deshalb habe ich diesen in der DDWRT VPN Konfig festgelegt. Wo nutze ich den Default 1194? Sehe es gerade nicht.

Den Server Log kann ich leider auch nicht einsehen, die Netgear Firmware ist hier leider nicht sehr hilfreich. Ich sehe lediglich, dass die VPN Verbindung zu stande kommt und dann wieder "gedroppt" wird:

[OpenVPN, connection drop]from remote IP address: 213.55.xxx.xxx Sunday, July 04,2021 13:20:01
[OpenVPN, connection drop]from remote IP address: 213.55.xxx.xxx Sunday, July 04,2021 13:20:01
[OpenVPN, connection drop]from remote IP address: 213.55.xxx.xxx Sunday, July 04,2021 13:18:04
[OpenVPN, connection failed]from remote IP address: 213.55.xxx.xxx Sunday, July 04,2021 13:18:04
[OpenVPN, connection successfully]from remote IP address: client/213.55.xxx.xxx Sunday, July 04,2021 13:17:12

Der LTE Router ist jedoch bei den "angeschlossenen Geräten" im Netgear Webinterface zu sehen, und wenn ich mich mit dem LTE Router verbinde und die IP abfrage, wird mir auch die öffentliche IP des Heimnetzrouters angezeigt. Irgendwas stimmt da noch nicht. Der Client Log sieht so aus:

20210704 13:17:09 W NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
20210704 13:17:09 Re-using SSL/TLS context
20210704 13:17:09 LZO compression initializing
20210704 13:17:09 Control Channel MTU parms [ L:1622 D:1212 EF:38 EB:0 ET:0 EL:3 ]
20210704 13:17:12 Data Channel MTU parms [ L:1622 D:1450 EF:122 EB:406 ET:0 EL:3 ]
20210704 13:17:12 Local Options String (VER=V4): 'V4 dev-type tun link-mtu 1558 tun-mtu 1500 proto UDPv4 comp-lzo cipher AES-128-CBC auth SHA1 keysize 128 key-method 2 tls-client'
20210704 13:17:12 Expected Remote Options String (VER=V4): 'V4 dev-type tun link-mtu 1558 tun-mtu 1500 proto UDPv4 comp-lzo cipher AES-128-CBC auth SHA1 keysize 128 key-method 2 tls-server'
20210704 13:17:12 I TCP/UDP: Preserving recently used remote address: [AF_INET]5.149.xx.xx:12973
20210704 13:17:12 Socket Buffers: R=[172032->172032] S=[172032->172032]
20210704 13:17:12 I UDPv4 link local: (not bound)
20210704 13:17:12 I UDPv4 link remote: [AF_INET]5.149.xx.xx:12973
20210704 13:17:12 TLS: Initial packet from [AF_INET]5.149.xx.xx:12973 sid=dc9010cd d1d71c06
20210704 13:17:12 VERIFY KU OK
20210704 13:17:12 Validating certificate extended key usage
20210704 13:17:12 NOTE: --mute triggered...
20210704 13:17:13 4 variation(s) on previous 3 message(s) suppressed by --mute
20210704 13:17:13 I [server] Peer Connection Initiated with [AF_INET]5.149.xx.xx:12973
20210704 13:17:14 SENT CONTROL [server]: 'PUSH_REQUEST' (status=1)
20210704 13:17:14 PUSH: Received control message: 'PUSH_REPLY redirect-gateway def1 bypass-dhcp route 192.168.1.0 255.255.255.0 route-gateway 192.168.2.1 topology subnet ping 10 ping-restart 120 ifconfig 192.168.2.4 255.255.255.0'
20210704 13:17:14 OPTIONS IMPORT: timers and/or timeouts modified
20210704 13:17:14 NOTE: --mute triggered...
20210704 13:17:14 3 variation(s) on previous 3 message(s) suppressed by --mute
20210704 13:17:14 Using peer cipher 'AES-128-CBC'
20210704 13:17:14 Outgoing Data Channel: Cipher 'AES-128-CBC' initialized with 128 bit key
20210704 13:17:14 Outgoing Data Channel: Using 160 bit message hash 'SHA1' for HMAC authentication
20210704 13:17:14 NOTE: --mute triggered...
20210704 13:17:14 2 variation(s) on previous 3 message(s) suppressed by --mute
20210704 13:17:14 net_route_v4_best_gw query: dst 0.0.0.0
20210704 13:17:14 net_route_v4_best_gw result: via 192.168.137.1 dev eth1
20210704 13:17:14 I TUN/TAP device tun1 opened
20210704 13:17:14 do_ifconfig ipv4=1 ipv6=0
20210704 13:17:14 I net_iface_mtu_set: mtu 1500 for tun1
20210704 13:17:14 I net_iface_up: set tun1 up
20210704 13:17:14 I net_addr_v4_add: 192.168.2.4/24 dev tun1
20210704 13:17:14 net_route_v4_add: 5.149.xx.xx/32 via 192.168.137.1 dev [NULL] table 0 metric -1
20210704 13:17:14 net_route_v4_add: 0.0.0.0/1 via 192.168.2.1 dev [NULL] table 0 metric -1
20210704 13:17:14 net_route_v4_add: 128.0.0.0/1 via 192.168.2.1 dev [NULL] table 0 metric -1
20210704 13:17:14 net_route_v4_add: 192.168.1.0/24 via 192.168.2.1 dev [NULL] table 0 metric -1
20210704 13:17:14 I Initialization Sequence Completed
20210704 13:25:04 MANAGEMENT: Client connected from [AF_INET]127.0.0.1:16
20210704 13:25:04 D MANAGEMENT: CMD 'state'
20210704 13:25:04 MANAGEMENT: Client disconnected
20210704 13:25:04 MANAGEMENT: Client connected from [AF_INET]127.0.0.1:16
20210704 13:25:04 D MANAGEMENT: CMD 'state'
20210704 13:25:04 MANAGEMENT: Client disconnected
20210704 13:25:04 MANAGEMENT: Client connected from [AF_INET]127.0.0.1:16
20210704 13:25:04 D MANAGEMENT: CMD 'state'
20210704 13:25:04 MANAGEMENT: Client disconnected
20210704 13:25:04 MANAGEMENT: Client connected from [AF_INET]127.0.0.1:16
20210704 13:25:04 D MANAGEMENT: CMD 'status 2'
20210704 13:25:04 MANAGEMENT: Client disconnected
20210704 13:25:04 MANAGEMENT: Client connected from [AF_INET]127.0.0.1:16
20210704 13:25:04 D MANAGEMENT: CMD 'log 500'
19700101 01:00:00

(Ich habe meine genaue, öffentliche IP im Log mit "xx" zensiert, im Log ist die IP logischerweise nicht so vermerkt)

Wo genau soll ich nun die Ports auf die freien Ephemeral Ports ändern?

Vielen Dank ;)

Die Server Konfig kann ich leider nicht zeigen, da ich selbst keinen Zugriff darauf habe.

Das ist per se erstmal schlecht.

Steht der VPN Server in einem internen Netzwerk ?? Wenn ja, dann stelle dort absolut sicher das der dortige Internet Router 2 statische Routen definiert hat.
Eine auf das interne OVPN Netzwerk und eine auf das remote LAN jeweils mit der lokalen VPN Server IP als Gateway Adresse (der OVPN Server ist ja Router).
Andernfalls passiert das was du oben schilderst das du keinen Zugriff auf die im remoten LAN liegenden Endgeräte hast, was ja dann durch das Fehlen der IP Routen auch zu erwarten ist. Statt via Server in den OVPN Tunnel routet der Router diese IP Netze dann Richtung Provider auf Nimmerwiedersehen ins IP Nirwana.
Arbeitet der OVPN Server direkt auf dem Internet Router selber ist das NICHT erforderlich.
Siehe dazu auch die Bilder und Screenshots im "OpenVPN Merkzettel" ! Bzw. auch HIER.

Die Meldung "Initialization Sequence Completed" zeigt aber das die OpenVPN Verbindung an sich sauber klappt und zumindestens deren Config wohl richtig und OK ist. Um das wasserdicht sagen zu können müsste man das auch im Server einsehen können aber wenn du vom Client die lokale Server IP pingen kannst und auch lokale Endgeräte im Server Netzwerk und andersrum vom Server die lokale Client IP dann sieht das alles aus reiner OVPN Sicht gut und korrekt aus !
Vermutlich sind es dann nur die fehlenden statischen IP Routen die eine Connectivity verhindern sofern der OVPN Server in einem internen LAN platziert ist.

Alles Klar. Ich habe das ganze noch einmal versucht aufzuzeichnen. Ich habe vergessen zu erwähnen, dass der LTE Router nicht selbst der VPN-Client ist, sondern ein zweiter Router (Der DDWRT Router) an diesem hängt, da der LTE Router von TP Link kein DD WRT unterstützt. Das sollte aber an der Ausgangslage nichts ändern.

Ziel ist, den Pool mit dem Handy über die dafür vorgesehene App zu steuern. Dies klappt aber nur, wenn sich der Pool im selben Netzwerk befindet wie das Smartphone.

Das sollte aber an der Ausgangslage nichts ändern.

Das ist richtig, das ist unerheblich ob das in einer Kaskade betrieben wird oder nicht.

Dies klappt aber nur, wenn sich der Pool im selben Netzwerk befindet wie das Smartphone.

Sollte auch in einem gerouteten IP Netz völlig problemlos funktionieren.

Mich irritiert der OVPN Client Log noch etwas. So wie ich das sehe, bricht die VPN Verbindung im Sekundentakt ab, wird dann aber gleich wieder hergestellt. Ist das normal so? Würde auch auf die "Connection Drop" Meldung im Netgear Router passen

Hi tacklearmy,
Du bist Dir ganz sicher, das Dein Netgear R6800 überhaupt als OpenVPN-Server agieren kann?
Was im GUI so zu sehen ist, betrifft den OpenVPN-Client und dieser ist ja wohl auf dem LTE-Router terminiert.
Leider ist dieser Router auch nicht von DD-WRT unterstützt, so das notfalls nur ein OpenWRT in Frage käme, welches natürlich nicht ganz so trivial in der Anwendung ist.
R6800
Allemal aber eine bessere Lösung wie die Firmware von Netgear.
Gruß orcape

Abend orcape

Jep, der Netgear Router funktioniert als VPN Server. Kann mich vom Handy aus auch problemlos in das VPN Netzwerk Per ovpn Konfigurationsdatei einloggen. Die .ovpn Datei ist aber mit "TAP" Protokoll konfiguriert. Den TAP Modus habe ich auf DDWRT jedoch nkcht zum laufen gebracht.

Kann mich vom Handy aus auch problemlos in das VPN Netzwerk Per ovpn Konfigurationsdatei einloggen

Kannst du denn vom Handy auch alle Endgeräte in dem VLAN pingen ? Das wäre noch wichtig zu wissen.
Gutes Ping und Troubleshooting Tool für sowas sind z.B. die HE.net Tools:
https://apps.apple.com/de/app/he-net-network-tools/id858241710
https://play.google.com/store/apps/details?id=net.he.networktools&hl ...

Danke für die Tool-Empfehlung!

Die Situation ist wie folgt:

Ich kann vom Handy aus alle Geräte im VLAN, sowie Geräte im Heimnetzwerk pingen! Vom Heimnetzwerk kann alle Geräte im VLAN über deren Remote IP pingen. Vom Laptop klappt es über Mobile Hotspot und VPN Client ebenfalls.

Beide Geräte nutzen folgendes Konfigurations-File:

client
dev tun
proto udp
dev-node NETGEAR-VPN
remote xxx.mynetgear.com 12973
resolv-retry infinite
nobind
persist-key
persist-tun
ca ca.crt
cert client.crt
key client.key
cipher AES-128-CBC
comp-lzo
verb 5

Weiterhin kann ich die Geräte, welche am VPN DDWRT Router hängen und von diesem IPs im Format 192.168.3.xxx erhalten weder vom Handy im VLAN, noch vom Heimnetzwerk aus pingen.

weder vom Handy im VLAN, noch vom Heimnetzwerk aus pingen.

Dafür ist auch deine Konfig falsch, denn es fehlt dafür ja der Routing Eintrag des lokalen DD-WRT Netzes.
Hilfreich wäre hier natürlich auch die OVPN Konfig des DD-WRT mal zu sehen.
Du machst ja eine Site-to-Site OVPN Kopplung zwischen NetGear und DD-WRT und dafür ist deine o.a. Konfig dann fehlerhaft bzw. die Setup Kommandos für das Site-to-Site fehlen komplett.
Dieser Thread zeigt dir wie die Konfigs richtig auszusehen haben:
OpenVPN - Erreiche Netzwerk hinter Client nicht
Passe das entsprechend an, dann kommt das auch sofort zum Fliegen.
Wichtig:
Beachte das du das NAT auf dem Tunnel Interface bei OpenWRT deaktivieren musst:
Problem mit site 2 site VPN

Dafür muss ich auch die OVPN Konfiguration des Netgear Routers (Server) ändern oder? Dann müsste entsprechend OpenWRT auf den Router flashen, da es kein DD WRT für den Netgear gibt....

Dafür muss ich auch die OVPN Konfiguration des Netgear Routers (Server) ändern oder?

Das ist ja so bei einer Site-to-Site Konfig !

OpenWRT auf den Router flashen

Nöö, das wäre ein unsinniger Schluß. OpenVPN bzw. dessen Konfig ist doch überall gleich, egal ob Winblows, Linux, MacOS, OpenWRT, DD-WRT oder was auch immer. Genau DAS macht OpenVPN ja aus das die Tunnelkonfig überall gleich ist egal auf welchem Unterbau OpenVPN rennt.
Fazit: Passe lediglich die Konfig Dateien mit den erforderlichen route, push route und iroute Kommandos an und dann rennt das auch sofort wie es soll !

Letztendlich bleibt mir wohl aber keine andere Wahl, denn ich kann die Server Konfig des Netgear-Openvpn Servers nicht bearbeiten. Möglich ist nur den VPN Service auf dem Router zu aktivieren, oder halt nicht zu aktivieren ^^ .

Die Konfig Dateien erstellt er selbst. Ich kann höchstens die Client Konfigs umschreiben, aber das reicht vermutlich nicht aus, oder verstehe ich dich jetzt komplett falsch?

denn ich kann die Server Konfig des Netgear-Openvpn Servers nicht bearbeiten

Sowas ist generell immer schlecht. Hat der ggf. einen SSH Zugang da sman mit PuTTY usw. drauf zugreifen kann (Shell).
Ansonsten wird es sinnvoller sein den OVPN Dienst dort zu deaktivieren und einen kleinen Raspberry Pi 4 oder einen 20 Euro Mikrotik Router wie den hier beschrieben) Damit bist du dann frei von jeglichen Fesseln und kannst alles so customizen wie du willst.

Nö, SSH ist leider aus "Sicherheitsrisiken" deaktiviert, hab den Zugriff per SSH und Putty bereits erfolglos probiert.

Ich denke am günstigsten geht es, wenn ich einen gebrauchten Router auf Ebay für unter 10 Euro kaufe, auf den ich DD-WRT flashen kann. Ansonsten wäre der von dir genannte Router eine relativ einfache Lösung für mich!

Ich denke am günstigsten geht es, wenn ich einen gebrauchten Router auf Ebay für unter 10 Euro kaufe, auf den ich DD-WRT flashen kann.

Bevor Du 10 € investierst, probier doch einfach mal die Lösung mit OpenWRT auf dem R6800.
R6800 OpenWRT
Auch wenn da nur ein Snapshot läuft, so ist es einen Versuch wert.
Du solltest nur an alle nötigen Futures denken, die Du bei der Installation benötigst. Beim Nachinstallieren gibt es oft Probleme mit der Kompatibilität der Version.

Soo... Habe nun einen frischen DD WRT geflashten Router als VPN Server eingerichtet. OpenWrt auf dem Heimnetzrouter war mir zu heiss, da ich mich mit dieser Firmware überhaupt nicht auskenne... Der Server läuft soweit und die Clients können sich einwählen.
Nun bin ich wieder bei meinem Routing-Problem angelangt.

Wie aktiviere ich das IPv4 Forwarding auf der DDWRT Firmware? Habe das von Aqui gepostete "Tutorial" soweit verfolgt und bestmöglich nachgemacht, Pings auf den Client sind aber, aus dem Heimnetz, immernoch nicht möglich.

Anbei Screenshots von allem was ich so konfiguriert habe ;)

Sind wohl viele Fehler drin. Kenne mich leider nicht extrem gut mit Netzerkgeschichten aus...

Das Erstellen der Zertifikate mit OpenSSL hat mich schon fast zum kochen gebracht, da OpenSSL, Nasm usw auf meinem Rechner noch nicht installiert waren...

Server Log:

Serverlog:
20210715 12:47:30 I net_iface_up: set tun2 up
20210715 12:47:30 I net_addr_v4_add: 172.18.18.1/24 dev tun2
20210715 12:47:30 Socket Buffers: R=[172032->172032] S=[172032->172032]
20210715 12:47:30 I UDPv4 link local (bound): [AF_INET][undef]:1194
20210715 12:47:30 I UDPv4 link remote: [AF_UNSPEC]
20210715 12:47:30 MULTI: multi_init called r=256 v=256
20210715 12:47:30 IFCONFIG POOL IPv4: base=172.18.18.2 size=252
20210715 12:47:30 I Initialization Sequence Completed
20210715 12:52:40 W xx:22165 WARNING: normally if you use --mssfix and/or --fragment you should also set --tun-mtu 1500 (currently it is 1400)
20210715 12:52:40 xx:22165 TLS: Initial packet from [AF_INET]xx:22165 sid=451218c4 4edcf61e
20210715 12:52:41 xx:22165 VERIFY OK: depth=1 C=CH ST=BE L=xxO=SilvioVPN OU=Ploder CN=Zertifikat name=Zertifikat2 emailAddress=xx.xx@xx.ch
20210715 12:52:41 xx:22165 VERIFY OK: depth=0 C=CH ST=BE L=xxO=OpenVPN OU=changeme CN=Ploderchischte name=Zertifikat4 emailAddress=xx.xxx@xx.ch
20210715 12:52:41 I xx:22165 peer info: IV_VER=3.git:released:662eae9a:Release
20210715 12:52:41 I xx:22165 peer info: IV_PLAT=android
20210715 12:52:41 I xx:22165 peer info: IV_NCP=2
20210715 12:52:41 I xx:22165 peer info: IV_TCPNL=1
20210715 12:52:41 I xx:22165 peer info: IV_PROTO=2
20210715 12:52:41 I xx:22165 peer info: IV_LZO_STUB=1
20210715 12:52:41 I xx:22165 peer info: IV_COMP_STUB=1
20210715 12:52:41 I xx:22165 peer info: IV_COMP_STUBv2=1
20210715 12:52:41 I xx:22165 peer info: IV_AUTO_SESS=1
20210715 12:52:41 I xx:22165 peer info: IV_GUI_VER=net.openvpn.connect.android_3.2.4-5891
20210715 12:52:41 I xx:22165 peer info: IV_SSO=openurl
20210715 12:52:41 W xx:22165 WARNING: 'link-mtu' is used inconsistently local='link-mtu 1458' remote='link-mtu 1522'
20210715 12:52:41 W xx:22165 WARNING: 'tun-mtu' is used inconsistently local='tun-mtu 1400' remote='tun-mtu 1500'
20210715 12:52:41 W xx:22165 WARNING: 'auth' is used inconsistently local='auth SHA1' remote='auth [null-digest]'
20210715 12:52:41 W xx:22165 WARNING: 'keysize' is used inconsistently local='keysize 128' remote='keysize 256'
20210715 12:52:41 xx:22165 Control Channel: TLSv1.3 cipher TLSv1.3 TLS_AES_256_GCM_SHA384 peer certificate: 4096 bit RSA signature: RSA-SHA1
20210715 12:52:41 I xx:22165 [Ploderchischte] Peer Connection Initiated with [AF_INET]xx:22165
20210715 12:52:41 I Ploderchischte/xx:22165 MULTI_sva: pool returned IPv4=172.18.18.2 IPv6=(Not enabled)
20210715 12:52:41 Ploderchischte/xx:22165 OPTIONS IMPORT: reading client specific options from: /tmp/openvpn_cc_6fb544d50265b067.tmp
20210715 12:52:41 Ploderchischte/xx.241:22165 MULTI: Learn: 172.18.18.2 -> Ploderchischte/xx.241:22165
20210715 12:52:41 Ploderchischte/xx:22165 MULTI: primary virtual IP for Ploderchischte/xx:22165: 172.18.18.2
20210715 12:52:41 Ploderchischte/xx:22165 Data Channel: using negotiated cipher 'AES-256-GCM'
20210715 12:52:41 Ploderchischte/xx:22165 Outgoing Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
20210715 12:52:41 Ploderchischte/xx:22165 Incoming Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
20210715 12:52:41 Ploderchischte/xx:22165 PUSH: Received control message: 'PUSH_REQUEST'
20210715 12:52:41 Ploderchischte/xx:22165 SENT CONTROL [Ploderchischte]: 'PUSH_REPLY redirect-gateway def1 route-gateway 172.18.18.1 topology subnet ping 10 ping-restart 120 ifconfig 172.18.18.2 255.255.255.0 peer-id 0 cipher AES-256-GCM' (status=1)
20210715 12:52:56 MANAGEMENT: Client connected from [AF_INET]127.0.0.1:14
20210715 12:52:56 D MANAGEMENT: CMD 'state'
20210715 12:52:56 MANAGEMENT: Client disconnected
20210715 12:52:56 MANAGEMENT: Client connected from [AF_INET]127.0.0.1:14
20210715 12:52:56 D MANAGEMENT: CMD 'state'
20210715 12:52:56 MANAGEMENT: Client disconnected
20210715 12:52:56 MANAGEMENT: Client connected from [AF_INET]127.0.0.1:14
20210715 12:52:56 D MANAGEMENT: CMD 'state'
20210715 12:52:56 MANAGEMENT: Client disconnected
20210715 12:52:56 MANAGEMENT: Client connected from [AF_INET]127.0.0.1:14
20210715 12:52:56 MANAGEMENT: Client disconnected
20210715 12:52:56 NOTE: --mute triggered...
20210715 12:52:56 1 variation(s) on previous 3 message(s) suppressed by --mute
20210715 12:52:56 D MANAGEMENT: CMD 'status 2'
20210715 12:52:56 MANAGEMENT: Client disconnected
20210715 12:52:56 MANAGEMENT: Client connected from [AF_INET]127.0.0.1:14
20210715 12:52:56 D MANAGEMENT: CMD 'status 2'
20210715 12:52:56 MANAGEMENT: Client disconnected
20210715 12:52:56 MANAGEMENT: Client connected from [AF_INET]127.0.0.1:14
20210715 12:52:56 D MANAGEMENT: CMD 'log 500'
20210715 12:52:56 MANAGEMENT: Client disconnected
20210715 12:57:17 MANAGEMENT: Client connected from [AF_INET]127.0.0.1:14
20210715 12:57:17 D MANAGEMENT: CMD 'state'
20210715 12:57:17 MANAGEMENT: Client disconnected
20210715 12:57:17 MANAGEMENT: Client connected from [AF_INET]127.0.0.1:14
20210715 12:57:17 D MANAGEMENT: CMD 'state'
20210715 12:57:17 MANAGEMENT: Client disconnected
20210715 12:57:17 MANAGEMENT: Client connected from [AF_INET]127.0.0.1:14
20210715 12:57:17 D MANAGEMENT: CMD 'state'
20210715 12:57:17 MANAGEMENT: Client disconnected
20210715 12:57:17 MANAGEMENT: Client connected from [AF_INET]127.0.0.1:14
20210715 12:57:17 MANAGEMENT: Client disconnected
20210715 12:57:17 NOTE: --mute triggered...
20210715 12:57:17 1 variation(s) on previous 3 message(s) suppressed by --mute
20210715 12:57:17 D MANAGEMENT: CMD 'status 2'
20210715 12:57:17 MANAGEMENT: Client disconnected
20210715 12:57:18 MANAGEMENT: Client connected from [AF_INET]127.0.0.1:14
20210715 12:57:18 D MANAGEMENT: CMD 'status 2'
20210715 12:57:18 MANAGEMENT: Client disconnected
20210715 12:57:18 MANAGEMENT: Client connected from [AF_INET]127.0.0.1:14
20210715 12:57:18 D MANAGEMENT: CMD 'log 500'
20210715 12:57:18 MANAGEMENT: Client disconnected
20210715 13:03:59 MANAGEMENT: Client connected from [AF_INET]127.0.0.1:14
20210715 13:03:59 D MANAGEMENT: CMD 'state'
20210715 13:03:59 MANAGEMENT: Client disconnected
20210715 13:03:59 MANAGEMENT: Client connected from [AF_INET]127.0.0.1:14
20210715 13:03:59 D MANAGEMENT: CMD 'state'
20210715 13:03:59 MANAGEMENT: Client disconnected
20210715 13:03:59 MANAGEMENT: Client connected from [AF_INET]127.0.0.1:14
20210715 13:03:59 D MANAGEMENT: CMD 'state'
20210715 13:03:59 MANAGEMENT: Client disconnected
20210715 13:03:59 MANAGEMENT: Client connected from [AF_INET]127.0.0.1:14
20210715 13:03:59 MANAGEMENT: Client disconnected
20210715 13:03:59 NOTE: --mute triggered...
20210715 13:03:59 1 variation(s) on previous 3 message(s) suppressed by --mute
20210715 13:03:59 D MANAGEMENT: CMD 'status 2'
20210715 13:03:59 MANAGEMENT: Client disconnected
20210715 13:03:59 MANAGEMENT: Client connected from [AF_INET]127.0.0.1:14
20210715 13:03:59 D MANAGEMENT: CMD 'status 2'
20210715 13:03:59 MANAGEMENT: Client disconnected
20210715 13:03:59 MANAGEMENT: Client connected from [AF_INET]127.0.0.1:14
20210715 13:03:59 D MANAGEMENT: CMD 'log 500'
19700101 01:00:00

Die Warnungen im Serverlog werde ich noch beheben die Config ist noch nicht ganz fertig.

Ich bin jetzt auf "Hilfe für Dummies" angewiesen: Wo muss ich welche Routen eintragen? Habe ich irgendwo eine IP falsch eingetragen? Was ist sonst alles noch falsch / fehlend?

Die Anleitung von Aqui bringt mich hier gerade nicht weiter, weil das Verständnis etwas fehlt / die Server Konfig für Linux geschrieben ist, und ich nicht weiss, wo ich die Dinge auf dem DD WRT Webinterface eintragen soll.

Ich hoffe, ihr könnt mir da etwas weiterhelfen.

Vielen herzlichen Dank
Gruss Silvio

Wie aktiviere ich das IPv4 Forwarding auf der DDWRT Firmware?

IPv4 Forwarding ist bei Router Firmware generell immer aktiviert. Logisch, denn ansonsten könnte ein Router ja gar nicht routen !

Die Frage wie und wo du statische Routen eintragen musst kann man dir leider so erstmal nicht beantworten, da aus deinem sonst guten Topologie Diagram nicht ersichtlich ist WIE die OpenWRT VPN Router genau angeschlossen sind im Heimnetz und Feriennetz.
Es gibt dafür ja generell 2 Optionen:

In einer Router Kaskade mit den jeweiligen Internet Routern
Als normale Endgeräte in den jeweils lokalen LANs. Quasi als sog. "one armed" Router.

Davon hängt ab wie und wo das Routing richtig einzurichten ist.

Gedacht wäre es so:

VPN Server = WAN Eingang (Ethernet) <--> Lan Ausgang Hauptrouter

VPN Client = WAN Eingang (Ethernet) <--> Lan Ausgang LTE Router

Die DDWRT Geräte bekommen ihr Netzwekkabel also quasi so, wie sie es auch tun würden, wenn sie direkt an einem Modem hängen würden. Ist das so nicht richtig überlegt?

Gedacht wäre es so:

OK, eine klassische Router Kaskade also. Das klappt problemlos und damit sind keinerlei zusätzliche Routen irgendwo erforderlich. Das einfache Setup sähe dann so aus:

Du musst nur 2 Dinge beachten:

Port Forwarding am Zuhause Router zum WAN Port OpenVPN Router für UDP 1194 aktivieren
NAT im OpenVPN Tunnelinterface auf den OpenWRT Router deaktivieren

Das OpenVPN Setup für Client und Server kannst du im Site to Site Tutorial HIER abschreiben, das ist bei dir identisch.
Damit kommt dieses einfache Standard Setup sofort zum Fliegen !

Alles Klar, werde ich gleich versuchen.

Folgende Fragen noch: Welchen Gateway soll ich beim Grundsetup des VPN Servers eintragen? Den Standardgateway des Heimnetzrouters?

Spielt es eine Rolle, welche IP Adressen die Clients des VPN Client Routers erhalten? Können z.B. Adressen im Format 192.168.3.1xx auch mit den Geräten mit Adressen im Format 192.168.1.1xx Kommunizieren?

Folgende Fragen noch: Welchen Gateway soll ich beim Grundsetup des VPN Servers eintragen?

Das kommt ganz drauf an WIE du die WAN Port Adressierung des OpenWRT Zuhause Routers gelöst hast. (Basis Beispiel von oben)

Statische WAN Port Adressierung = Dann trägst du als Gateway und DNS auf dem OpenWRT statisch die 192.168.2.1 ein
Dynamische Adressierung (WAN Port ist DHCP Client) = OpenWRT bekommt Gateway und DNS dynamisch via DHCP vom Zuhause Router. Du musst nix konfigurieren
Dynamische Adressierung (WAN Port ist DHCP Client) mit Mac Adress Reservierung im Zuhause Router = Auf Basis der WAN Port Mac Adresse des OpenWRT Routers trägst du die 192.168.2.254 in die DHCP Reservierung ein. Gateway und DNS (192.168.2.1) kommen dann wieder dynamisch per DHCP.

Letztere Option ist natürlich die Eleganteste.

Spielt es eine Rolle, welche IP Adressen die Clients des VPN Client Routers erhalten?

Nein, da bist du frei in der Auswahl und kannst alles nehmen was dir die privaten_RFC_1918 IP Bereiche bieten. Das Einzige was zählt ist

Das IP Netze nicht doppelt vorkommen dürfen !
Dynamische DHCP Adresspools dürfen sich nicht mit statischen Adressen überschneiden !

Können z.B. Adressen im Format 192.168.3.1xx auch...

Du routest ja ganze IP Netze über den VPN Tunnel und keine einzelnen Hostadressen. Einzelne Hostadressen sind fürs VPN irrelevant solange der jeweilige Netzwerk Prefix mit der VPN Site-to-Site Konfig korrespondiert. Es wird dann alles geroutet was zum IP Netz der jeweils gegenüberliegenden Seite passt. (Siehe OpenVPN Tutorial).

Hmm... Clients verbinden mit dem Server wie gewünscht, die Warnungen sind alle weg! Wenn ich mich mit dem Handy als Client verbinde, kann ich den DD WRT Client problemlos unter seiner "virtuellen IP" pingen, aber die Geräte in seinem Lan Netz nicht. Ich vermute, dass es am fehlenden "iroute-Command" liegt.

Ich kann die Konfigs aus dem oben genannten OpenVPN Tutorial leider nicht 1:1 übernehmen, da ich die Einrichtung über das DDWRT GUI vornehme. Die Einstellungsmöglichkeiten sind auf einem der Screenshots in meinem Post vom 15.07. 13:42 ersichtlich.

Ich habe einen Screenshot der Routing Tabelle des VPN Server Routers sowie einen des VPN Client Routers angehängt, muss ich da allenfalls was eintragen? NAT habe ich in der VPN Client Konfig ausgeschaltet. (Die, mit den schlecht zensierten IP Adressen, ist die Routing Tabelle des VPN Clients.) ;)

Die beiden verbundenen VPN Clients auf dem 2. Screenshot, haben den selben Namen, da sie noch das selbe Zertifikat verwenden ( Wird noch geändert!)

Ich habe deine treffende Darstellung meines Netzwerks noch etwas angepasst, so sollte sie in etwa stimmen.

DDWRT Server Lan Netz = 192.168.2.x
DDWRT Client Lan Netz = 192.168.3.x
Heim-Lan Netz = 192.168.1.x

aber die Geräte in seinem Lan Netz nicht. Ich vermute, dass es am fehlenden "iroute-Command" liegt.

Nein. Mit push route... in der Server Konfig distribuierst du ja immer das gesamte Netzwerk an den VPN Client. Der weiss also das er das remote LAN über sein VPN Tunnel Interface erreicht !
Kannst du übrigens auch immer selber sehen wenn du dir die Route Table des Clients bei aktivem VPN Client einmal ansiehst. route print (Winblows) bzw. ip route show oder netstat -r -n bei unixoiden Clients.
Bei Smartphones helfen wie immer die kostenlosen HE.NET Tools:
https://apps.apple.com/de/app/he-net-network-tools/id858241710
https://play.google.com/store/apps/details?id=net.he.networktools&hl ...
Sind die remoten Clients Winblows Rechner ?
Wenn ja ist es da immer die lokale Windows Firewall. Diese blockt generell ALLES was aus fremden IP Netzen wie deinem VPN Netz kommt und muss entsprechend angepasst werden wie z.B. für ICMP Pakete (Ping): https://www.windowspro.de/wolfgang-sommergut/ping-windows-10-erlauben-gu ...
Das iroute Kommando benötigst du aber zwingend für die Site-to-Site Konfig !

da ich die Einrichtung über das DDWRT GUI vornehme

Hilfreich wäre aber schon mal die originale Konfig Datei zu sehen. Das geht z.B. problemlos mit einem Shell Zugriff per SSH via PuTTY. Ansonsten ist es immer schwer zu beurteilen was OpenVPN da genau macht.

Routing Tabelle des VPN Server Routers sowie einen des VPN Client Routers

Sieht perfekt und richtig aus !
Was ist mit NAT auf dem OpenVPN Tunnelinterface ? Ist das deaktiviert ?

Oben steht "Statische Reservierung auf Hauptrouter" und dort ist eine Reservierung mit einer IP 192.168.1.5 angegeben was aber technischer Unsinn ist, denn der Hauptrouter (damit ist wohl der NICHT OpenWRT Router gemeint ?!?) kann niemals Reservierungen für das .1.0er Netz machen da es gar nicht an ihm angeschlossen ist ! Ist das ein freudscher Tippfehler oder was soll das bedeuten ?
Ebenso auf der anderen Seite lokale IP... Wo denn auf welchem Router und dort auf welchem Interface.
Auch "treffende Darstellung meines Netzwerks noch etwas angepasst" dein "Server" und "Client" ist ja IMMER ein Router mit zumidestens 3 Interfaces. Was bedeutet also nur die Angabe eines ??
Etwas wirr und unklar das alles von der Dokumentation. Sowas ist dann immer ein Nährboden für Fehler und Missverständnisse.

Kannst du mir vielleicht gerade sagen, welchen Command ich im SSH Terminal eingeben muss, damit ich die Server Konfig sehen kann? Finde nichts dazu im Inet.

Nevermind, habs gefunden ;)

Hier die Konfig:

root@DD-WRT:/tmp/openvpn# cat openvpn.conf
dh /tmp/openvpn/dh.pem
ca /tmp/openvpn/ca.crt
cert /tmp/openvpn/cert.pem
key /tmp/openvpn/key.pem
keepalive 10 120
verb 3
mute 3
syslog
writepid /var/run/openvpnd.pid
management 127.0.0.1 14
management-log-cache 100
topology subnet
script-security 2
port 1194
proto udp4
auth sha1
cipher AES-128-CBC
data-ciphers AES-256-GCM:AES-128-GCM:AES-128-CBC
client-connect /tmp/openvpn/clcon.sh
client-disconnect /tmp/openvpn/cldiscon.sh
client-config-dir /tmp/openvpn/ccd
comp-lzo yes
tls-server
duplicate-cn
client-to-client
push "redirect-gateway def1"
fast-io
tun-mtu 1500
mtu-disc yes
server 192.168.5.0 255.255.255.0
dev tun2
route-up /tmp/openvpn/route-up.sh
route-pre-down /tmp/openvpn/route-down.sh
persist-key
persist-tun

Oben steht "Statische Reservierung auf Hauptrouter" und dort ist eine Reservierung mit einer IP 192.168.1.5 angegeben was aber technischer Unsinn ist, denn der Hauptrouter (damit ist wohl der NICHT OpenWRT Router gemeint ?!?) kann niemals Reservierungen für das .1.0er Netz machen da es gar nicht an ihm angeschlossen ist !

Der Hauptrouter ist der von dir als "Zuhause-Router" beschriebene Router. Er hat die IP 192.168.1.1 und vergibt Adressen im Format 192.168.1.x So auch an den DD WRT Router, der als VPN Server taugt und die Wan IP 192.168.1.5 vom Zuhause-Router erhält. Der DDWRT-Router ist an seinem WAN Eingang, per Lan-Kabel, direkt an einem der Lan Ausgänge des Zuhause-Routers verbunden.

Kannst du mir vielleicht gerade sagen, welchen Command ich im SSH Terminal eingeben muss, damit ich die Server Konfig sehen kann?

Ja, das ist kinderleicht. Das geht mit dem Kommando cat oder auch less. Damit kann man alle Text Dateien ansehen. Ein cat /etc/openvpn/server.conf zeigt dir dann z.B. die Datei.
Wenn du dir über die OpenWRT Packetverwaltung noch den nano Editor dazu installierst kannst du diese Dateien auch einfach und schnell bearbeiten statt mit dem gruseligen vi.

Deinen Konfig hat einen Fehler. Zumindestens für die Site to Site Konfig. "push "redirect-gateway def1" macht einen Gateway Redirect. Das ist bei einem Client tolerabel (sendet bei aktivem Client sämtlichen Traffic, auch Internet Traffic) in den Tunnel. Bei einem Site to Site geht das aber nicht weil sonst dein gesamer lokaler Traffic in den Tunnel geht. Bei teurem LTE sicher NICHT gewollt.
Hier solltest du besser immer Split Tunneling nutzen mit push route... !! Siehe dazu auf die entsprechende Passage im Tutorial:
Merkzettel: VPN Installation mit OpenVPN

So auch an den DD WRT Router, der als VPN Server taugt und die Wan IP 192.168.1.5 vom Zuhause-Router erhält.

Sorry, das ist völliger Quatsch und kann so niemals sein ! Sieh dir bitte einmal genau die o.a. Zeichnung an !! Oder...du hast eine komplett andere IP Adressierung als in deiner korrigierten Zeichnung oben. Dann drehen wir uns natürlich alle sinnfrei im Kreis hier.

Der OpenWRT Router "Zuhause" ist mit dem WAN/Internet Port mit dem Zuhause Internet Router an einem der LAN Ports verbunden. Hier hat der Zuhause Router eine Netzwerk IP 192.168.2.0 !
der WAN Port des OpenWRT Routers der hier drinsteckt kann doch folglich dann nie und nimmer nicht eine .1.0er IP an dem Port haben ! Das MUSS immer eine .2.0er IP sein ! Das Setup sieht doch so aus:

PC---(lokales LAN .1.0)---LAN-Port_(WRT)_WAN-Port---(Koppel LAN .2.0)---LAN_Port(InternetRouter)

An seinem LAN Port (OpenWRT) ist dann logischerweise das .1.0er Netz !
Hast du da jetzt grundsätzlich was falsch gemacht und das Ding doch als "one armed" angeschlossen ?
Nur das dir nochmal klar ist was eine Router Kaskade ist:
IPsec IKEv2 VPN für mobile Benutzer auf der pfSense oder OPNsense Firewall einrichten
Nicht das wir uns hier sinnlos im Kreis drehen weil du einen völlig andere Konfig nutzt..

Bedenke auch das im .2.0er Koppelnetz keinerlei andere Endgeräte mehr sein dürfen !! Die müssen allesamt im LAN Netz am OpenWRT Router sein !!! Das ist eine reine Punkt zu Punkt Verbindung ausschliesslich der beiden Router.
Gleiches gilt für die Ferien Seite !!

Bis auf den Redirect Fehler und das komplett das iroute Kommando für die Site to Site Kopplung fehlt ist die Server Konfig zwar mit überflüssigen Kommandos überfrachtet aber korrekt.
Mit einem Mobilclient solltest du damit zumindestens auf alle Komponenten im lokalen LAN zugreifen können.

Vermutlich habe ich einen Fehler gemacht, und den Router als von dir beschriebenen "one armed" angeschlossen. Ich habe nochmals versucht ein Schema von der Situation zu erstellen, vielleicht bringt das etwas Licht ins Dunkle. Ausserdem läuft auf den 2 Routern DD-WRT, nicht OpenWrt, wie du sagst, spielt aber nicht so eine grosse Rolle.

Die Datenmengen, welche durch den Tunnel gerouted werden sind erstmal nebensächlich, der LTE Router ist sowieso mit einer FlatRate-Sim ausgestattet, da spielt das Datenvolumen keine Rolle. Wenn ich meinen Traffic nicht durch den Tunnel senden möchte, kann ich mich ja weiterhin direkt mit dem LTE Router verbinden, dann geht nichts durch die VPN Verbindung. Gerouted werden soll ja nur der Traffic der Geräte, welche am VPN Client Router hängen.

Ich hoffe das Schema verwirrt nicht nur noch mehr

Hallo,

Zitat von @tacklearmy:
Die Datenmengen, welche durch den Tunnel gerouted werden sind erstmal nebensächlich

Sicher?

der LTE Router ist sowieso mit einer FlatRate-Sim ausgestattet, da spielt das Datenvolumen keine Rolle.

Sicher? Wenn es keine echte Flatrate ist, wird irgendwann gedrosselt und nennt sich immer noch Flatrate. https://www.lte-anbieter.info/flat/lte-flatrate.php

Ausserdem läuft auf den 2 Routern DD-WRT, nicht OpenWrt, wie du sagst, spielt aber nicht so eine grosse Rolle.
und den Router als von dir beschriebenen "one armed" angeschlossen.

Nur zur verdeutlichung. DD-WRT und OpenWrt sind nicht das gleiche, aber ähnlich. Du bist nicht mein Kumpel, auch wenn du den gleichen Vornamen haben solltest. Sollte DD-WRT und OpenWrt wie du schreibst schon irgendwo und irgendwie gleich sein, dann hätten sie den gleichen namen. Und "one armed" sagt man wenn dein router nur mit einen Port für 2 oder mehr netze betrieben wird (was geht aber oft mehr fehlerquellen bietet und daher eher vermieden werden sollte)

Auch das dein Modem eine IP nutzt/hat ist sinnfrei/falsch/nicht möglich usw. Modem steht für Modulator und Demodulator und kann nur von z.B. Ethernet nach DSL/PPoE usw. die Signale Wandeln. Da ist kein Platz und keine Elektronik drin welche ein IP Versteht oder damit umgehen kann. https://de.wikipedia.org/wiki/Modem

Gruß,
Peter

Vermutlich habe ich einen Fehler gemacht,

Ja, das hast du !

und den Router als von dir beschriebenen "one armed" angeschlossen.

Nein das hast du nicht, der ist richtig in einer Kaskade angeschlossen ! Kannst du ja auch selber sehen oben !
Leider fehlt in deiner Zeichnung die IP Adressierung im Koppelnetz zw. LTE Router und OpenWRT ! Was hast du da benutzt ?

Dein Fehler ist das du am Zuhause Hauptrouter LAN Endgeräte angeschlossen hast. Oben wurde mehrfach darauf hingewiesen das das NICHT funktioniert !!!
Nur nochmal wiederholt damit du das verstehst:
Bedenke auch das im .2.0er Koppelnetz keinerlei andere Endgeräte mehr sein dürfen !! Die müssen allesamt im LAN Netz am OpenWRT Router sein !!! Die Verbindung NetGear zu OpenWRT ist eine reine Punkt zu Punkt Verbindung ausschliesslich der beiden Router.
Gleiches gilt für die Ferien Seite !!
Ist doch auch klar, denke doch einmal selber etwas nach !! Am OpenWRT machst du NAT (IP Adress Translation) am WAN Port. Die .1.0er IP Geräte am LAN Port des NetGear können durch die NAT Firewall am OpenWRT WAN Port...

a.) Niemals Geräte im OpenWRT LAN erreichen
b.) Niemals Geräte im oder via VPN erreichen

Einzig und allein der o.a. WLAN Client 192.168.2.10 kann damit kommunizieren. Nichts anderes.
Wenn das OK ist kannst du das natürlich alles so lassen. Oder...

Du hast am DD-WRT den Router Mode am WAN aktiviert statt des Gateway Modes ! Das ginge auch, denn damit deaktiviert man das NAT am DD-WRT (und nur am DD-WRT) !
Das Deaktivieren von NAT am DD-WRT löst dann das Problem, erfordert dann aber wieder zwingend zwei statische Route am NetGear !!
Leider machst du ja oben keinerlei Aussagen WIE der DD-WRT eingestellt ist ob Router oder Gateway Mode. (Siehe dazu auch hier).
Mit dem DD-WRT als normalem Router (WAN Port = Router Mode) sähe das so aus:

Danke für die Rückmeldungen!

Die Flatrate ist eine echte Flatrate! Bei mir in der Schweiz gibts sowas schon für relativ wenig Geld, ich weiss nicht, wie das in Deutschland aussieht.

Mit der Adressierung der "Modem IP" wollte ich nicht sagen, dass das Modem diese IP hat, sondern, dass diese vom Netzbetreiber, über das Modem, an den Router weitergeleitet wird.

Welche Einstellung verändert denn mein Koppelnetz? Kann ich das Koppelnetz im VPN Server Router frei wählen?

Im Prinzip wäre es schon OK, wenn nur die Clients des VPN Server mit den Geräten im VPN kommunizieren könnte, denn ich kann mich ja jederzeit per Mobile Client ins VPN einloggen und so meinen Pool Fernsteuern. Schöner wäre aber, wenn das auch klappen würde, wenn mein Handy mit dem Zuhause-Wlan verbunden wäre.

Der VPN Server läuft im Gateway Modus! Ich habe bereits versucht das Gerät im "Router-Modus" zu betreiben, hatte danach aber keine Internet Verbindung über Wlan am Gerät mehr, was vermutlich auf die fehlenden statischen Routen zurückzuführen ist.

Gruss Silvio

Welche Einstellung verändert denn mein Koppelnetz? Kann ich das Koppelnetz im VPN Server Router frei wählen?

Kannst du. Siehe Zeichnung oben.

Schöner wäre aber, wenn das auch klappen würde, wenn mein Handy mit dem Zuhause-Wlan verbunden wäre.

Wenn du DD-WRT nutzt geht das auch. Wichtig ist hier dann nur das du den WAN Port in den Router Mode versetzt und die statischen Routen am Internet Router einträgst !! (Siehe Zeichnung oben)

Der VPN Server läuft im Gateway Modus!

Das ist FALSCH, denn damit ist das NAT am WAN Port aktiv und du kannst aus dem Hauptnetz NICHT ins DD-WRT LAN und das VPN zugreifen, das ist dann technisch unmöglich.
Ändere das also unbedingt in den Router Mode !

hatte danach aber keine Internet Verbindung über Wlan am Gerät mehr

Vermutlich hast du dann, wie leider so oft, vergessen am WAN Port dann das Default Gateway und DNS auf den NetGear einzutragen und auf dem NetGear die statischen Routen in die DD-WRT Netze einzurichten.

Ohne das kann der DD-WRT logischerweise nix ins Internet routen ! Nachdenken...!!

Sorry, die Zeichnung oben habe ich nicht gesehen, als ich den letzten Kommentar geschrieben habe. Die Zeichnung sollte so exakt stimmen! Ich habe die Einstellungen nun so wie in der Zeichnung übernommen, habe aber via DD WRT Router immernoch keine Internetverbindung. Die Statischen Routen habe ich ebenfalls so wie aufgezeichnet eingetragen. (Metrik 2, evtl ist das falsch?)

Gateway IP am lokalen Interface ist falsch ! Die musst du leer lassen, denn du hast das Default Gateway ja schon am WAN Port definiert !!
Zeigt dir DD-WRT am WAN Port die korrekte IP an ?

Ist vom DD-WRT Ping Menü der .1.1er IP und eine Internet IP wie z.B. 8.8.8.8 pingbar ?

Ansonsten ist alles richtig !

Pings klappen! Habe den Gateway aus dem lokalen Interface rausgenommen.
Wan IP wird als 192.168.1.5 angezeigt (siehe Screenshots)

Internetverbindung habe ich weiterhin keine.

Internetverbindung habe ich weiterhin keine.

Das ist ja dann gelogen wenn du die 8.8.8.8 pingen kannst !! Diese IP ist ja nun zweifelsohne eine öffentliche Internet IP also hast du dann ja wohl eine Internet Vetbindung oder führst du uns hier alle hinters Licht ?

Pinge diese IP auch einmal von den .2.0er Clients aus !
Was dann bei deinen Clients vermutlich nicht geht ist die DNS Namensauflösung !
Welchen DNS Server hast du denn da im DD-WRT DHCP Setup eingestellt ? Da sollte die NetGear Gurke als DNS stehen mit der 192.168.1.1. Das solltest du an den Clients einmal mit ipconfig -all (Winblows) checken. Bzw. auch nslookup mit den o.a. HE.NET Tools.

Ich kann einfach von den Clients keine Websiten / Internet erreichen. Dass der Router eine Internetverbindung hat, stimmt. IP Config gibt 192.168.1.1 als DNS aus, wie es sein sollte oder?

IP Config gibt 192.168.1.1 als DNS aus, wie es sein sollte oder?

Stelle das im DHCP Server testweise mal um auf die .2.5 so das der DD-WRT dann DNS Proxy spielt. Testweise statisch am Client auf die .2.5 setzen geht natürlich auch.

Möglich auch das du einen Konfig Fehler am WAN Port gemacht hast ??!
Du teilst die WAN IP ja dynamisch zu per DHCP, richtig ?
Dann darfst du KEINE zusätzliche statische Route eingeben !! Klar, denn diese bekommt die DD-WRT Kiste ja schon per DHCP und das korrumpiert die Routing Table !
Ein kurzer Testsetup bestätigte das hier das das Routing dann nicht mehr klappt.

Fazit: KEINE statische IP Adresse am WAN Port und KEIN Gateway eintragen wenn der WAN Port Mode auf DHCP Client gesetzt ist. (DHCP vom NG)
(Screenshots mit IPs aus einem Testenetz, kannst du ignorieren bzw. auf deine interpretieren !)

Setup WAN Port DHCP:

Advanced Routing Setup:

++Routing Tabelle:

Ping Check auf DD-WRT Konsole:

Verändert leider nix an der Situation. DNS Server in ipConfig am Client ist nun 192.168.2.5, 8.8.8.8 -Ping vom Client geht weiterhin nicht.

Die Wan IP wird Statisch zugeteilt, siehe Screenshot letzter Post. Habe das gestern so eingestellt, da ich ohnehin eine Reservierung für 192.168.1.5 auf dem Netgear eingerichtet habe. Screenshot ebenfalls hier noch einmal angehängt.

Die Clients verlieren ihren Internetzugriff, sobald ich den Router Modus aktiviere. Im Gateway Modus klappt der 8.8.8.8 Ping!

Das Problem liegt vielleicht eher bei den statischen Routen im Netgear Router. Ich verstehe nicht ganz, was die Route auf die 10.0.8.0 bewirken soll?

Denn weder im Router, noch im Gateway Modus ist ein Ping vom Client 192.168.1.7 auf den Client 192.168.2.134 möglich. Umgekehrt aber schon.

-Ping vom Client geht weiterhin nicht.

Nur nochmal doof nachgefragt: Die statische Route am NetGear Router
Zielnetz: 192.168.2.0, Maske: 255.255.255.0, Gateway: 192.168.1.5
Hast du konfiguriert ???
Ohne diese statische Route kann es im Router Mode NICHT funktionieren und dieser Screenshot fehlte beharrlich in allen deinen Dokus oben !

Nur nochmals zur Erinnerung das Layer 3 "Zuhause" Setup mit Router Mode und mit diesen dafür zwingend notwendigen beiden statischen Routen auf dem NetGear Router !

Zum IP Connectivity Check folgende ToDos:

Per PuTTY und SSH auf dem DD-WRT einloggen. (user: root und Admin Passwort)
Output von ip a und ip route show posten
Ping Check ping 192.168.1.1 und ping 8.8.8.8 ausführen. Ergebnis ?
Ping Check mit LAN Absender IP ausführen ping -I br0 192.168.1.1 und ping -I br0 8.8.8.8. Ergebnis ? (- (groß I) setzt als Absender IP das Interface "br0" was das lokale LAN .2.0 ist, dessen IP Adressierung du auch durch das Kommando "ip a" sehen kannst !)

Die Statische Route ist konfiguriert. Hatte ich am 17.07.2021 um 12:13:06 Uhr bereits einmal als Screenshot gepostet. (Zweit letztes Bild) neuer Screenshot in diesem Post

Folgender Output im PuTTY Inferface:

root@DD-WRT VPN Server:~# ip a
1: lo: <LOOPBACK,MULTICAST,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 brd 127.255.255.255 scope host lo
valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel master br0 state UP qlen 1000
link/ether a0:21:b7:ac:b4:e5 brd ff:ff:ff:ff:ff:ff
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP qlen 1000
link/ether a0:21:b7:ac:b4:e6 brd ff:ff:ff:ff:ff:ff
inet 192.168.1.5/24 brd 192.168.1.255 scope global eth1
valid_lft forever preferred_lft forever
6: br0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP
link/ether a0:21:b7:ac:b4:e5 brd ff:ff:ff:ff:ff:ff
inet 192.168.2.5/24 brd 192.168.2.255 scope global br0
valid_lft forever preferred_lft forever
7: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br0 state UP
link/ether a0:21:b7:ac:b4:e5 brd ff:ff:ff:ff:ff:ff
9: tun2: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UNKNOWN qlen 500
link/[65534]
inet 192.168.5.1/24 scope global tun2
valid_lft forever preferred_lft forever

root@DD-WRT VPN Server:~# ip route show

default via 192.168.1.1 dev eth1
127.0.0.0/8 dev lo scope link
192.168.1.0/24 dev eth1 scope link src 192.168.1.5
192.168.2.0/24 dev br0 scope link src 192.168.2.5
192.168.5.0/24 dev tun2 scope link src 192.168.5.1

root@DD-WRT VPN Server:~# ping 192.168.1.1
PING 192.168.1.1 (192.168.1.1): 56 data bytes
64 bytes from 192.168.1.1: seq=0 ttl=64 time=3.912 ms
64 bytes from 192.168.1.1: seq=1 ttl=64 time=3.681 ms
64 bytes from 192.168.1.1: seq=2 ttl=64 time=3.729 ms
64 bytes from 192.168.1.1: seq=3 ttl=64 time=3.708 ms
^C
--- 192.168.1.1 ping statistics ---
107 packets transmitted, 107 packets received, 0% packet loss
round-trip min/avg/max = 3.539/3.951/12.703 ms

root@DD-WRT VPN Server:~# ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8): 56 data bytes
64 bytes from 8.8.8.8: seq=0 ttl=118 time=15.258 ms
64 bytes from 8.8.8.8: seq=1 ttl=118 time=13.921 ms
64 bytes from 8.8.8.8: seq=2 ttl=118 time=13.220 ms
64 bytes from 8.8.8.8: seq=3 ttl=118 time=13.399 ms
^C
--- 8.8.8.8 ping statistics ---
4 packets transmitted, 4 packets received, 0% packet loss
round-trip min/avg/max = 13.220/13.949/15.258 ms

root@DD-WRT VPN Server:~# ping -I br0 192.168.1.1
PING 192.168.1.1 (192.168.1.1): 56 data bytes

^C
--- 192.168.1.1 ping statistics ---
34 packets transmitted, 0 packets received, 100% packet loss

root@DD-WRT VPN Server:~# ping -I br0 8.8.8.8
PING 8.8.8.8 (8.8.8.8): 56 data bytes
^C
--- 8.8.8.8 ping statistics ---
13 packets transmitted, 0 packets received, 100% packet loss
root@DD-WRT VPN Server:~#

root@DD-WRT VPN Server:~# ip route show

OK, da ist alles richtig wie es sein soll.

Du kannst ja sehen das der Internet Zugriff mit der eth1 Absender IP fehlerfrei funktioniert. Nicht aber mit der "br0" Absender IP (192.168.2.5) !
Daraus folgert ganz klar das der NetGear Router ein Problem hat, denn er führt die statische Rückroute nicht aus ! Warum auch immer...?
Der Gateway Mode bestätigt diesen Verdacht, denn .2.0er Absender IPs tauchen mit dem dann am DD-WRT aktiven NAT (IP Adress Translation) am NetGear nicht auf. Der "sieht" durch das NAT nur das alles hinter dem DD-WRT mit der .1.5er Absender IP ankommt und "denkt" somit das alles aus seinem lokalen Netz kommt.
Ein sicheres Indiz das mit dem DD-WRT Router Mode die dann erforderliche statische Route am NetGear nicht greift ! Der ist also der böse Buhmann...

Das mag daran liegen das deine dortige statische Route eine falsche Metrik hat. Die sollte nicht 2 sondern 1 lauten. Siehe dazu auch hier HIER Seite 160.
Testweise kannst du auch mal "Privat" anhaken denn diese Route muss nicht dynamisch mit RIP propagiert werden ! RIP nutzt du eh nicht.
Der Rest im DD-WRT ist sauber und korrekt konfiguriert wie du ja an den o.a. Outputs selber sehen kannst.

eth1 = WAN Port
br0 = LAN Port (bridge0)
tun = OpenVPN Server Tunnel Interface
Default Route auf .1.1
Pings mit WAN Port Absender in Internet OK

Alles also wie es sein soll !
Der Fehler ist die nicht funktionierende statische Route im NetGear ins .2.0er IP Netz so das die Rückroute im Router Mode tot ist !

Hast du auf dem NetGear die derzeit aktuellste_Firmware_1.2.0.76 geflasht ??

Alles Klar! Neuste Firmware ist drauf, der Router will mir eine Metrik von 1 aber nicht erlauben... Habe die Route testweise auf Privat gesetzt, verändert nix.

Test deines Designs mit einer FritzBox

FritzBox, Setup DHCP Clients:

FritzBox, Statische Route:

(192.168.100.0 /24 ist das lokale LAN am DD-WRT Router)

DD-WRT, WAN Port:

Ping Check mit (Windows) Client aus DD-WRT LAN:

(Client DNS ist hier der DD-WRT, 192.168.100.1)

Fazit: Works as designed !! 😉

Mehr kann man an Troubleshooting über einen Forensupport fast nicht mehr machen um zu zeigen das es bei DD-WRT auch mit klassischem Routing ohne NAT fehlerfrei klappt. Fakt ist das die NetGear Kiste der böse Buhmann ist. Der FritzBox Check oben zeigt das ja eindeutig !
Wenn die mit so einer einfachen Konfig nicht umgehen kann musst du dann zwangsweise den Gateway Mode belassen (Routen kannst du dann wieder entfernen).
Was dann aber bedeutet:
KEINE Endgeräte im .1.0er Koppelnetzwerk ! Bzw. nur solche die mit dem VPN und Clients im .2.0er Netz NICHT kommunizieren müssen. Das können sie durch das dann aktive NAT am DD-WRT WAN Port nicht. Nur ausschliesslich die Clients im lokalen LAN am DD-WRT können das wenn der DD-WRT im Gateway Mode (NAT aktiv) ist !

Scheint wohl wieder so ein Netgear "Kompatibilitäts" Thema zu sein, andere User im Netz haben das selbe Problem. Nun gut, dann lasse ich das Ding halt im Gateway Modus ist kein Weltuntergang. Ich kann ja trotzdem übers Handy entweder via WLAN des DD WRT Servers oder halt direkt als VPN Client mit den anderen Clients Kommunizieren.

Was jetzt noch fehlt ist das iRoute Kommando in der Openvpn Server Konfig. Wie kann ich das über Putty ausführen? Welcher Command wäre in meinem Fall nötig?
Danke dir für die ausführliche Hilfe und das Troubleshooting

Wenn du nur ein einziges Site to Site Ziel hast wie bei dir reichen diese 3 Server Kommandos:
push "route 192.168.1.0 255.255.255.0"
route 192.168.3.0 255.255.255.0
iroute 192.168.3.0 255.255.255.0
Das geht jetzt davon aus das 192.168.3.0 das lokale LAN am xWRT Router der "Ferien" Seite ist.
Die "Ferien" OVPN Client Seite hat eine einfache normale Client Konfig.

Ich habe die Config Datei mit Vi über Putty angepasst und gespeichert, nach dem Neustart des Routers sind die Änderungen aber wieder weg. Kann ich die Kommands auch über die Server GUI Konsole eingeben? Vgl. Screenshot

Das OpenVPN Konfig Verzeichnis in DD-WRT ist sehr wahrscheinlich falsch. M.E. ist es unter /etc/config oder /tmp/openvpn/openvpn.conf. Musst du aber mal checken bzw. mal die DD-WRT Doku durchforsten:
https://wiki.dd-wrt.com/wiki/index.php/OpenVPN#Customizable_Parameters
http://coertvonk.com/sw/networking/dd-wrt-and-openvpn-5591

Kann ich die Kommands auch über die Server GUI Konsole eingeben?

Nein. Dort kannst du, wie der Name es schon selber sagt, nur Kommandos eingeben die die Linux Command Shell direkt ausführt. Die 3 Kommandos oben sind keine Linux Shell Kommandos sonder Konfig Kommandos in einer Text Datei.
Es gibt aber im OpenVPN GUI ein Textfeld wo man OVPN Kommandos eingeben kann.

Gibt es einen speziellen SSH Command um die Einstellungen zu speichern? Nach Restart wird das openvpn.conf file zurückgesetzt..

Habs geschafft. DD WRT gibt jedoch bei dieser Konfig folgenden Fehler aus:

Konfig:

dh /tmp/openvpn/dh.pem
ca /tmp/openvpn/ca.crt
cert /tmp/openvpn/cert.pem
key /tmp/openvpn/key.pem
keepalive 10 120
verb 3
mute 3
syslog
writepid /var/run/openvpnd.pid
management 127.0.0.1 14
management-log-cache 100
topology subnet
script-security 2
port 1194
proto udp4
auth sha1
cipher AES-128-CBC
data-ciphers AES-256-GCM:AES-128-GCM:AES-128-CBC
client-connect /tmp/openvpn/clcon.sh
client-disconnect /tmp/openvpn/cldiscon.sh
client-config-dir /tmp/openvpn/ccd
comp-lzo yes
tls-server
duplicate-cn
client-to-client
push "redirect-gateway def1"
fast-io
tun-mtu 1500
mtu-disc yes
server 192.168.5.0 255.255.255.0
dev tun2
route-up /tmp/openvpn/route-up.sh
route-pre-down /tmp/openvpn/route-down.sh
persist-key
persist-tun
push "route 192.168.1.0 255.255.255.0"
route 192.168.3.0 255.255.255.0
iroute 192.168.3.0 255.255.255.0

Fehler:

Jan 1 01:00:18 DD-WRT VPN Server daemon.err openvpn[876]: Options error: option 'iroute' cannot be used in this context (/tmp/openvpn/openvpn.conf)

Ist ja auch kein Wunder !!! Bitte einmal das OpenVPN Tutorial lesen !!!
Merkzettel: VPN Installation mit OpenVPN
Was steht dort fett und ohne das man das übersehen kann ???

push "redirect-gateway def1 bypass-dhcp" = Schickt statt nur den Traffic des lokalen LANs den gesamten Client Traffic in den VPN Tunnel !
Wenn dies aktiviert wird muss man dann zwingend den Eintrag push "route 192.168.188.0 255.255.255.0" mit "#" einkommentieren oder löschen !
Niemals dürfen beide Push Optionen zusammen in der Konfig stehen !! Ein Fehler der oft gemacht wird. Es geht entweder nur Split Tunnel oder nur Gateway Redirect.

Muss man denn immer alles doppelt und 3fach wiederholen ?! 🧐 Korrigiere den Unsinn, dann klappt das auch.

push "redirect-gateway def1 bypass-dhcp" = Schickt statt nur den Traffic des lokalen LANs den gesamten Client Traffic in den VPN Tunnel !
Wenn dies aktiviert wird muss man dann zwingend den Eintrag push "route 192.168.188.0 255.255.255.0" mit "#" einkommentieren oder löschen !
Niemals dürfen beide Push Optionen zusammen in der Konfig stehen !! Ein Fehler der oft gemacht wird. Es geht entweder nur Split Tunnel oder nur Gateway Redirect.

Wenn nur das korrigiert werden sollte, dann sollte der Server ja jetzt laufen. Im Tutorial steht einiges in FETT, weiss nicht auf was du hinaus wolltest. Der Context Fehler ist immernoch da.

Sorry wenn ich die Dinge nicht direkt auf Anhieb kapiere, bin ziemlicher Anfänger und dankbar für deine ausführliche Hilfe.

und dankbar für deine ausführliche Hilfe.

Kein Problem...immer cool bleiben !

https://openvpn.net/faq/overriding-a-pushed-route-in-the-clients-config- ...
https://community.openvpn.net/openvpn/wiki/OverridingAPushedRouteInTheCl ...

Ich habe das schon richtig verstanden oder: Das iroute Kommando muss in die Server Konfig?

Bei mir kommt kein fehler zum Route Kommando, sondern zum "iroute". Habe versucht einfach "pull-filter ignore "iroute" zu benutzen, klappt leider nicht.

Das iroute Kommando muss in die Server Konfig?

Jepp, ganz genau !
Wenn es bei dir partout so nicht klappen sollte dann musst du das doch Site-to-Site clientweise in eine separate Datei splitten.
In der Server Konfig steht dann sowas:
client-config-dir /etc/openvpn/csconf
Das zeigt dann auf das Verzeichnis wo die Client spezifischen Dateien liegen. Bei deinem DD-WRT solltest du dann tunlichst eins nehmen was nicht nach einem Reboot gelöscht wird. Also z.B. auch das wo schon die zentrale Server Konfig Datei steht.
Es mag auch daran liegen das deine Server Konfig noch kleine Fehler aufweist. Wenn du die Subnet Adress Topology nutzt musst du auch ein push "topology subnet" in die Server Konfig einführen. Das fehlt oben !
Eine einfache Server Konfig sähe so aus bei dir:
dev tun
proto udp4
port 1194
dh /tmp/openvpn/dh.pem
ca /tmp/openvpn/ca.crt
cert /tmp/openvpn/cert.pem
key /tmp/openvpn/key.pem
cipher AES-256-CBC
auth SHA256
duplicate-cn
client-to-client
fast-io
user nobody
group nogroup
server 172.168.5.0 255.255.255.0
topology subnet
push "topology subnet"
persist-key
persist-tun
push "route 192.168.2.0 255.255.255.0"
route 192.168.3.0 255.255.255.0
keepalive 10 120

Die Compression sollte zwingend deaktiviert werden. Grund ist ein Security_Bug (VORACLE) !
Die Client spezifischen Routing Konfig Kommandos auf dem Server liegen in den Client spezifischen Dateien unter (hier im Beispiel) /etc/openvpn/csconf/ auf dem Server. Der Konfig Dateiname entspricht dann dem Common Name des Clients wie er im Client Zertifikat angegeben wurde.
Z.B. "client01" ist hier im Beispiel der Common Name im Zertifikat des ersten Clients und entsprechend heisst auch die Client 1 spezifische Datei dann client01.
Wichtig und entscheident ist hier welche Common Names in den Client Zertifikaten pro Client definiert wurden !
(Wenn es nur einen einzigen Routing Client bei LAN zu LAN gibt ist das irrelevant und kann dann natürlich entfallen. Es reicht dann die Route in der Server Konfig.)
In dieser Datei steht dann:
ifconfig-push 172.168.5.2 255.255.255.0
iroute iroute 192.168.3.0 255.255.255.0
Wie bereits gesagt: Wenn du nur eine einzige Sit-to-Site Verbindung hast lass das iroute Kommando einfach weg und probier es mal so. Mit nur einer Verbindung sollte es auch ohne Client spezifische Konfig klappen.
Wenn der Site-to-Site Tunnel steht führe einfach mal ein ip route show oder netstat -r -n aus und sieh dir die Routing Tabelle von Server und Site Client an, dann kannst du sehen ob die jeweiligen Ziel IP Netze richtig in den Tunnel geroutet werden.

Soo... Nach langem Rumprobieren habe ich mich dazu entschlossen den LTE-Internet Provider zu wechseln.

Und siehe da; Die Cloud Applikation des Steuerungsherstellers funktioniert auf Anhieb. Der vorherige Anbieter muss die Verbindung irgendwie nicht zugelassen haben. Nun ist auch keine VPN Verbindung mehr notwendig. Sollte diese Lösung auf Dauer nicht funktionieren, kann ich beim Provider auch eine öffentliche IP lösen und den VPN Server direkt auf dem LTE Router laufen lassen.

Danke für eure Hilfe!
Over and out.

gelöst Frage Netzwerke Router, Routing

Heiß diskutiert