02.07.2020

18211

Zwei Mobilfunkrouter (TP-Link MR200) per VPN verbinden, ev. per externen VPN-Gateway (VPS-Server)

Hallo in die Runde,

ich habe zwei Mobilfunkrouter (TP-Link MR200), die ich per VPN verbinden möchte, sodass ich von Standart A auf Standort B vollständigen Zugriff habe. Jeder Router hätte ein eigenes Subnetz (192.168.1.0 und 192.168.2.0), das wäre schon mal kein Thema. Jeder Router hat eine eigene SIM-Karte, die in einem Vertrag zusammen gefaßt sind (Multi-SIM) Problem an der Sache ist nur, dass mein Mobilfunkanbieter anscheinend sowas wie CG-NAT verwendet...

Machen wir es mal konkreter:

Normalerweise bekomme ich zb. die IP 10.197.17.81 im Router angezeigt. Auf https://www.wieistmeineip.at wird mir die IP 185.69.244.136 angezeigt. Daher habe ich meinen Anbieter gebeten, dass er mir eine "öffentliche IP" gibt. Dies hat er auch gemacht, dann wird mir die selbe IP im Router, wie auch extern angezeigt. Problem an der Sache ist aber, dass ich trotzdem von einem Router auf den anderen Router keinen erfolgreichen PING erreichen kann.

An der Konfiguration des Routers kann es jedoch nicht liegen, da ich von einem externen Anschluss (DSL-Anschluss bei einem Freund) meine beiden Router problemlos PINGen kann. Auch von meinen beiden Servern konnte ich die beiden Mobilfunkrouter pingen. Nur eben nicht gegenseitig die beiden Router. Anscheinend hat mein Anbieter eine entsprechende Firewall zwischen allen Teilnehmern, was zwar nett ist, aber in dem Fall mir absolut nicht hilft.

Da mein MR200-Router eine IPsec-Verbindung (intergriert im Router) zwischen beiden Standorten aufbauen könnte, wäre das eigentlich mein vorrangiges Ziel, dies auch zu nutzen. Mit zwei Wertkarten hat es komischerweise sogar mal geklappt. Leider sind diese nicht als vollwertiger Internetzugang nutzbar und zu teuer, daher habe ich dies auch nichtmehr. Mit diesen beiden Karten wäre aber bewiesen gewesen, dass eine Verbindung per IPsec problemlos machbar wäre.

Mein Lösungsansatz wäre nun ein externer Gateway-Server (auf einem VPS), der mir die Verbindung der beiden Router herstellt. Idealerweise loggen sich beide Router per IPsec dort ein und ich kann über diesen Server dann die Verbindung aufbauen. IPsec wäre deshalb für mich interessant, da ich kein externes Gerät (zb. Linuxbox) benötigen würde. Wäre das machbar und wie? Aktuell habe ich schon einige Tage damit verbracht, aber ich komme nicht zu dem korrekten Ergebnis. Andere Möglichkeit wäre jeweils ein Raspberry PI, der mir einen OpenVPN-Tunnel zu einem externen VPS aufbaut, aber wie route ich dann die Anfragen über meinen Router?

Sorry, aber aktuell habe ich keinen Plan, wie man dies am idealsten lösen sollte.

Könnt ihr mich mal in die richtige Richtung schubsten, die mich weiter bringt? Ein Wechsel des Internetanbieters (oder Wechsel auf DSL, Kabel, usw.) ist leider nicht möglich.

Herzlichen Dank schon mal!

Lg, Jürgen

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

Content-ID: 583638

Url: https://administrator.de/forum/zwei-mobilfunkrouter-tp-link-mr200-per-vpn-verbinden-ev-per-externen-vpn-gateway-vps-server-583638.html

Ausgedruckt am: 31.12.2024 um 04:12 Uhr

39 Kommentare

Neuester Kommentar

dass mein Mobilfunkanbieter anscheinend sowas wie CG-NAT verwendet...

Wenn beide Seiten CGN verwenden und RFC1918 IP Adressen auf der WAN Seite nutzen bedeutet das das technische AUS für ein VPN. Ist klar, denn beidseitig kann immer einer das CGN Gateway des Providers nicht überwinden und der Tunnelaufbau scheitert dann sofort.
Hier macht es am meisten Sinn wenigsten eine Seite mit einer öffentlichen IP auszustatten. Das ist bei so gut wie allen Providern möglich indem man einen anderen APN im Mobilfunknetz benutzt.
Möglich das das mit einer Kostenänderung (z.B. Business Tarif) einhergeht aber das solltest du mit deinem Mobilfunk Provider klären.
Wenn einer der Router eine öffentliche WAN IP dann ist eine VPN Tunnelverbindung sofort möglich.

Normalerweise bekomme ich zb. die IP 10.197.17.81

Das ist dann sehr schlecht, denn das ist eine Private RFC1918 IP:
https://de.wikipedia.org/wiki/Private_IP-Adresse#Private_Adressbereiche
wieistmeineip kann dir aber so eine RFC 1918 IP niemals anzeigen, denn damit kann man logischerweise niemals ins Internet. RFC1918 IPs werdem in Internet nicht geroutet und sind deshalb unbekannt. Deshalb zeigt meineip dir auch immer deine öffentliche IP des Provider CGN Gateways ! Das ist die 185er IP. Mit dieser IP tauschen deine Netzwerk Pakete im Internet auf.
Alles also genau und richtig wie es sein soll....

zwischen beiden Standorten aufbauen könnte, wäre das eigentlich mein vorrangiges Ziel, dies auch zu nutzen.

Das ist richtig, technisch ist das der allerbeste Weg !

Mit zwei Wertkarten hat es komischerweise sogar mal geklappt.

Die nutzten möglicherweise eine andere APN mit öffentlichen IPs und dann klappt es sofort. Auch wenn nur eine Seite öffentlich ist und die andere CGN. Das ist die Minimalvoraussetzung bei VPN.

Mein Lösungsansatz wäre nun ein externer Gateway-Server

Das wäre eine Option. Eine andere ist deinen Heimrouter zu verwenden.
Wenn du da nicht auch gerade einen DS-Lite Anschluss hast und ggf. noch Besitzer einer FritzBox bist kannst du auch deinen Heimrouter als "Relais" nutzen.

IPsec wäre deshalb für mich interessant, da ich kein externes Gerät (zb. Linuxbox) benötigen würde.

Bahnhof ??
Was soll uns dieser kryptische und wirre Satz sagen ?? Alle Beteilugten müssen logischerweise IPsec können ?!
Unverständlich...

Andere Möglichkeit wäre jeweils ein Raspberry PI, der mir einen OpenVPN-Tunnel zu einem externen VPS aufbaut

Wäre ja Blödsinn wenn deine TP-Link Mobilgurken nur rein IPsec als VPN Protokoll sprechen. Wenn sie bessere Router sind könnten sie auch mehrere VPN Protokolle. Dann wäre natürlich auch SSL (OpenVPN) denkbar. Wenn die Router das aber nicht supporten wär das ja Unsinn, da es dann logischerweise separate Hardware erfordert.

Aktuell habe ich schon einige Tage damit verbracht

Wie ?? Mit Nachdenken ?? Die technischen Fakten sind doch absolut klar und das Ergebnis ist nach 10 Minuten Nachdenken doch dann auch sonnenklar...unverständlich warum dazu mehrere Tage benötigst ?!?

Andere Möglichkeit wäre jeweils ein Raspberry PI, der mir einen OpenVPN-Tunnel zu einem externen VPS aufbaut,

Wie gesagt...sinnfrei wenn deine Router nur IPsec können.

Könnt ihr mich mal in die richtige Richtung schubsten, die mich weiter bringt?

Warum du hast dir die Frage doch schon selber richtig beantwortet ! Du hast 2 Optionen:

Deinen Mobilfunkprovider kontakten und wenigstens eine SIM Karte mit einem anderen APN versehen der öffentliche IPs bekommt.
Einen VPS Server oder deinen Heimrouter (sofern der VPN kann) als "Relais" verwenden um beide Mobilrouter zu koppeln.

Sorry, aber Schuld hast du auch selber hier. Wenn du weisst das du mit den Routern einen VPN Tunnel realisieren willst oder musst dann nutzt man doch keine Billigstverträge mit Provider CGN !!
Das weiss ja nun mittlerweile auch jeder Laie das wenigstens eine Seite eine öffentliche IP haben muss (Business Tarif usw.) wenn VPNs im Spiel sind.

Moin

für solche Fälle gibt es Anbieter wie die Firma MDEX. Die haben die passende Lösung für dein Problem
Das ist aber nicht billig. Für dein VPN benötigst du zusätzlich zu deren Router eine eigenen dahinter.
Ich habe das bei Kunden im Einsatz und das VPN wird vom Lancom-Router terminiert.

Wenn du es privat nutzen möchtest und nicht so viel Geld ausgeben willst, dann hat @aqui ja schon alles richtig und - wie immer - sehr ausführlich erläutert.

Hallo und vielen Dank für die ausführliche Antwort.

Ein Wechsel des Anbieters ist grundsätzlich nicht möglich und angedacht, was offensichtlich auch nicht notwendig sein dürfte, wenn man die entsprechenden Geräte einrichtet. Letztendlich soll das ganze Szenario für keine großen Datenmengen dienen und nur für den Privatgebrauch genutzt werden. Daher kann und will ich auch nicht mehr an Kosten verursachen als notwendig.

Kommen wir zu meinem aktuellen Lösungansatz: Ein OpenVPN-Gateway auf einem VPS-Server

Ziel der Verbindung ist:

Standart A (Subnetz 192.168.1.0) und Standort B (Subnetz 192.168.2.0) miteinander per OpenVPN verbinden. Zum Einsatz kommen sollen zwei Raspberry Pi, die jeweils hinter einem TP-Link MR200 Mobilrouter sich befinden und jeweils eine fixe IP-Adresse haben.

Von Standort A sollen alle Netzwerkgeräte (z.B. 192.168.2.10, 192.168.2.11, usw.) erreichbar sein. Umgekehrt soll von Standort B auch jedes Netzwerkgerät (z.B. 192.168.1.10, 192.168.1.11, usw.) erreichbar sein. Der Datentransfer für das öffentliche Internet soll jeweils über den eigenen Router rausgehen und nicht über den VPN-Tunnel gehen.

Zusätzlich ist eine Verbindung von mobilen Endgeräten (Smartphone, Tablet) ebenso per OpenVPN geplant. Hier sollen dann Geräte aus Standort A und Standort B direkt über den Tunnel erreichbar sein, wenn das Smartphone per OpenVPN verbunden ist. Datentransfer ins Internet soll von dem mobilen Endgerät trotzdem nicht über den Tunnel, sondern direkt geroutet werden.

Eigentlich sollte ich nichts in der Beschreibung vergessen habe, sonst trage ich es nach.

Konfiguration OpenVPN-Server:

port 1194
proto udp
dev tun
user nobody
group nogroup
persist-key
persist-tun
keepalive 10 120
topology subnet
server 10.8.0.0 255.255.255.0
ifconfig-pool-persist ipp.txt
push "dhcp-option DNS 8.8.8.8"  
push "dhcp-option DNS 8.8.4.4"  
push "redirect-gateway def1 bypass-dhcp"  
dh none
ecdh-curve prime256v1
tls-crypt tls-crypt.key 0
crl-verify crl.pem
ca ca.crt
cert server_C6vKTovJpMfnddoe.crt
key server_C6vKTovJpMfnddoe.key
auth SHA256
cipher AES-128-GCM
ncp-ciphers AES-128-GCM
tls-server
tls-version-min 1.2
tls-cipher TLS-ECDHE-ECDSA-WITH-AES-128-GCM-SHA256
client-config-dir /etc/openvpn/ccd
status /var/log/openvpn/status.log
verb 3

Routing-Tabelle OpenVPN-Server:

Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 <IP-Server> 0.0.0.0 UG 0 0 0 eth0
10.8.0.0 0.0.0.0 255.255.255.0 U 0 0 0 tun0
<IP-Server> 0.0.0.0 255.255.255.255 UH 0 0 0 eth0

IP-Forward am OpenVPN-Server:

/proc/sys/net/ipv4/ip_forward = 1

Konfiguration OpenVPN-Clients:

Raspberry Pi auf Standort A (192.168.1.0):

client
proto udp
explicit-exit-notify
remote 51.255.104.136 1194
dev tun
resolv-retry infinite
nobind
persist-key
persist-tun
remote-cert-tls server
verify-x509-name server_C6vKTovJpMfnddoe name
auth SHA256
auth-nocache
cipher AES-128-GCM
tls-client
tls-version-min 1.2
tls-cipher TLS-ECDHE-ECDSA-WITH-AES-128-GCM-SHA256
ignore-unknown-option block-outside-dns
setenv opt block-outside-dns # Prevent Windows 10 DNS leak
verb 3

Darunter kommen dann die Zertifikate, usw.

PING auf 192.168.1.1 (Router Standort A): OK
PING auf 10.8.0.1 (OpenVPN Gateway): OK
PING auf 192.168.2.1 (Router Standort B): Derzeit nicht prüfbar, da noch nicht eingerichtet.

Samsung Tablet (über Mobilfunk):

client
proto udp
explicit-exit-notify
remote 51.255.104.136 1194
dev tun
resolv-retry infinite
nobind
persist-key
persist-tun
remote-cert-tls server
verify-x509-name server_C6vKTovJpMfnddoe name
auth SHA256
auth-nocache
cipher AES-128-GCM
tls-client
tls-version-min 1.2
tls-cipher TLS-ECDHE-ECDSA-WITH-AES-128-GCM-SHA256
ignore-unknown-option block-outside-dns
setenv opt block-outside-dns # Prevent Windows 10 DNS leak
verb 3

Darunter kommen dann die Zertifikate, usw.

PING auf 192.168.1.1 (Router Standort A): Fehlgeschlagen, sollte aber gehen. Was wäre zu tun?
PING auf 10.8.0.1 (OpenVPN Gateway): OK
PING auf 192.168.2.1 (Router Standort B): Derzeit nicht prüfbar, da noch nicht eingerichtet.

Ich hatte in der Konfiguration des Server auch schon folgendes drin:

Route zum Heimnetz auf dem Host-System des OpenVPN-Servers anlegen

route 192.168.1.0 255.255.255.0

Route zum Heimnetz allen Clients mitteilen

push "route 192.168.1.0 255.255.255.0"

Der Raspberry Pi (Standort A, 192.168.1.0) ist dann aber nicht mehr über seine lokale IP erreichbar.

Das Setzen der Routen wäre für mich auch logisch, aber irgendwie sehe ich momentan den Wald vor lautet Bäumen nicht mehr. Letztendlich müssen ja zwei Routen (Standort A: 192.168.1.0 und Standort B: 192.168.2.0) rein. Diese muss ich doch pushen, oder nicht?

Könnt ihr mir mal ein wenig weiterhelfen, damit ich die Denkfehler erkenne?

Dankeschön und liebe Grüße
Jürgen

Ein Wechsel des Anbieters ist grundsätzlich nicht möglich und angedacht

Nein muss man auch nicht. Wenn du richtig gelesen hast dann ging es oben auch einzig nur darum einen anderen APN des gleichen Providers zu verwenden der eben öffentliche IPs vergibt statt CGN RFC 1918 IPs. Das ist ein simpler Mausklick im Setup des Routers.
Jeder Provider supportet unterschiedliche APNs die diese IP Adressvergabe ermöglichen. Ob das ggf. dann mit anderen Gebühren einhergeht ist Provider abhängig und müsstest du klären.

Kommen wir zu meinem aktuellen Lösungansatz: Ein OpenVPN-Gateway auf einem VPS-Server

Was die einfachste Lösung ist wenn man CGN Opfer ist...

Datentransfer ins Internet soll von dem mobilen Endgerät trotzdem nicht über den Tunnel, sondern direkt geroutet werden.

Dann ist aber deine Server Konfig komplett FALSCH, denn damit machst du einen Gateway Redirect !
(Kommando: push "redirect-gateway def1 bypass-dhcp") Damit ist dann ein Split Tunneling Betrieb wie du ihn dir selber vorgibst technisch unmöglich ! Hier musst du mit push route... die dedizierten IP Netze in den Tunnel routen.
Bitte lies da hiesige OpenVPN_Tutorial ! Dort ist das im Kapitel Server Konfig explizit erklärt !

Es fehlen auch die statischen Routen der OVPN Netze auf den jeweiligen Mobilfunk Routern ! In deiner ansonsten guten Dokumentation erwähnst du das mit keinem einzigen Wort.
Zusätzlich fehlen auch alle Kernel Routen und auch die Client Netzrouten in deiner Server Konfig !
So kann das also nicht wirklich was werden. Die musst du also noch entsprechend hinzufügen damit du eine LAN zu LAN VPN Verbindung realisieren kannst !
Ping und Traceroute sind hier wie immer deine besten Freunde !

Hier wird ganz genau dein RasPi Design mit bunten Bildern erklärt:
OpenVPN - Erreiche Netzwerk hinter Client nicht
Lesen und verstehen...dann klappt das auch sofort mit den RasPis !

Wenn du richtig gelesen hast dann ging es oben auch einzig nur darum einen anderen APN des gleichen Providers zu verwenden der eben öffentliche IPs vergibt statt CGN RFC 1918 IPs. Das ist ein simpler Mausklick im Setup des Routers.

Das haben wir leider schon alles durch, egal mit dynamischer öffentlicher IP (kostenlos) oder mit fixer öffentlicher IP. In beiden Fällen war eine Verbindung zwischen den beiden Routern nicht möglich, da scheinbar intern beim Provider eine Firewall jegliche Verbindung geblockt hat. Kein VPN, kein PING, gar nichts. Von einem anderen Anbieter (oder einem Server) aus war ein PING kein Problem.

Eine Nachfrage, ob an der Firewall etwas gemacht werden kann und auf einen direkten Hinweis auf die Umstände hat man mir nur mitgeteilt, dass die Techniker keine andere Möglichkeit haben und wir somit alle Mittel ausgeschöpft haben. Weitere Anfragen blieben dann leider unbeantwortet, da wohl der Support schon etwas genervt war.

Was die einfachste Lösung ist wenn man CGN Opfer ist...

Ich würde ja einen anderen Anbieter oder sogar eine Festanbindung (DSL, Kabel, usw.) nehmen, wenn die Kosten nicht ein entscheidender Faktor wären. Bei dieser VPN-Verbindung geht es nur um ein paar Steuerfunktionen und die Übertragung von Messwerten. Darum ist auch die Performance von dem VPN-Tunnel nicht das entscheidende Kriterium.

Dann ist aber deine Server Konfig komplett FALSCH, denn damit machst du einen Gateway Redirect !

Okay, den Rest muss ich erstmal durcharbeiten - ggf. melde ich mich wieder, ich wollte nur mal den ersten Teil kommentieren.

Hier wird ganz genau dein RasPi Design mit bunten Bildern erklärt:
OpenVPN - Erreiche Netzwerk hinter Client nicht

Also diese Anleitung ist der Hammer, damit kann man auch als Einsteiger in OpenVPN wirklich was anfangen. ;) WOWWW!

Was ich allerdings nicht verstehe ist, wieso die Router 1 und Router 2 eine IP-Adresse aus dem Adressbereich 10.x.x.x haben? Ich dachte, man kann mit einer privaten IP-Adresse (was ja auch bei CGN der Fall ist) keine Verbindung aufbauen? Hier steht es aber offiziell in der Anleitung und die Verbindung scheint mit einem einfach Port-Forward funktionieren?

Ähm, bei mir baut sich gerade ein Knoten im Kopf auf....

egal mit dynamischer öffentlicher IP (kostenlos) oder mit fixer öffentlicher IP. In beiden Fällen war eine Verbindung zwischen den beiden Routern nicht möglich,

Sorry, aber das kann man dir nicht wirklich glauben. Das schafft man auch mit jedem Baumarkt Router der VPN kann. Zumal du auch noch 2gleiche Modelle hast.
Das ist in einem Administrator Forum nicht wirklich glaubhaft, aber egal. Leider hast du es ja auch nicht einmal geschafft dein Setup zu posten oder einmal genau zu spezifizieren WAS beim VPN Ausbau gescheitert ist ?! Aber auch egal...

dass die Techniker keine andere Möglichkeit haben und wir somit alle Mittel ausgeschöpft haben.

Was bei einem first Level Support auch klar ist. Ausser Reset und Router Tausch haben die bekanntlich keinerlei weitere Fachkenntnisse...was hast du also erwartet ?

wieso die Router 1 und Router 2 eine IP-Adresse aus dem Adressbereich 10.x.x.x haben?

Einfach mal lesen...

Es ist eine Labor Simulation ! Klar hast du recht man hätte jetzt auch 85.1.1.1 und 85.1.1.2 als IPs nehmen können. Dann wären sie öffentlich.
Das ist aber Wumpe...es ist ein Labor Setup und das sind dann natürlich die Provider WAN Port IPs !

Es ist KEIN Live Setup ! Ich hatte angenommen das Wort "Simulation" sei da eindeutig und mich wohl getäuscht.
Das sollte aber hoffentlich deinen Knoten lösen...?!

Sorry, aber das kann man dir nicht wirklich glauben. Das schafft man auch mit jedem Baumarkt Router der VPN kann. Zumal du auch noch 2gleiche Modelle hast.

Man kann es wirklich nicht glauben, aber es ist so. Ich hatte vom Anbieter (übrigens Spusu in Österreich):

1. Router (Öffentliche IP)
2. Router (Öffentliche IP)

Ein PING von 1. Router auf 2. Router war nicht möglich, umgekehrt ebenso nicht.
Hingegeben war ein PING von einem anderen Anschluss und von einem Server an 1. Router und 2. Router möglich.

Das spricht doch dafür, dass der Anbieter die Datenpakete filtert und eine Kommunikation zwischen zwei Anschlüssen trotz öffentlicher IP nicht zulässt. Anscheinend dürfte das Problem auch sehr selten sein.

Hat man hier Erfahrung mit dem Anbieter? Nachdem es ein deutsches Forum ist, fürchte ich ja eher nicht.

Einfach mal lesen... Es ist eine Labor Simulation ! Klar hast du recht man hätte jetzt auch 85.1.1.1 und 85.1.1.2 als IPs nehmen können.

Ja, das verstehe ich schon, aber in meinem Fall ging es ja um eine andere Aufgabenstellung:

1. Private IP-Adresse(n) am WAN beider Router
2. Zwei Raspi (als OpenVPN-Client) im LAN
3. Ein VPS als Gateway (als OpenVPN Server)
4. Diverse mobile Clients (Smartphones, Tablets)

In der Laborsimulation findet ja eigentlich eine Verbindung zwischen zwei Netzwerken statt (mittels Raspi) aber ohne Einsatz eines Gateways, das eine öffentliche IP hat. Das wäre mein Ziel und in meinem Fall anscheinend die einzige Lösung *seufz*.

Anscheinend dürfte das Problem auch sehr selten sein.

In der Tat sehr selten und eher wohl außergewöhnlich.
Das nicht einmal sowas wie ein Ping funktioniert lässt aber doch mehr als erheblichen Zeifel am Wahrheitsgehalt aufkommen. Das Provider ICMP Echo Pakete (Ping) filtern grenzt eher an ein Märchen aber kann man nicht ausschliessen das in A sowas möglich ist. Üblich ist es eigentlich nirgendwo auf der Welt, denn Ping ist ein essentiellen Test Tool für Verbindungen was normal kein Einziger Provider filtert. Schon aus Eigeninteresse wäre das Unsinn, denn bedenke mal wieviel Support Calls die sonst diesbezüglich am Tag bekommen würden...??!!
Sorry, aber das klingt wirklich wenig glaubhaft.

1. Private IP-Adresse(n) am WAN beider Router

""Beider Router" ist dann der sofortige Todesstoß für VPNs, denn das bedeutet 2mal Provider CGN an beiden Anschlüssen. Das dann ein VPN technisch vollkommen ausgeschlossen ist wurde oben schon hinreichend geklärt. Wie willst du das NAT Gateway des Providers überwinden ??? Unmöglich....!!
So eine VPN Konstellation kann dann logischerweise nur mit einem Vermittlungshost laufen. Sprich du mietest dir für 3-5 Euro einen billigen vServer bei einem Hoster deiner Wahl, installierst dort OpenVPN. Der vServer hat immer eine öffentliche IP.
Diese öffentliche IP connecten dann die beiden CGN Clients (RasPis) per OpenVPN und der öffentliche vServer verbindet dann diese beiden RasPi OVPN Tunnel. Nur so kannst du einfach die beidseitige CGN Problematik überwinden und niemals anders.
Ist ja auch irgendwie logisch, denn du hast keinerlei technische Chance das Provider NAT Gateway zu überwinden, da du ja niemals dort ein zwingend erfoderliches Port Forwarding für VPN eintragen kannst !
Das macht eine VPN Verbindung mit beidseitigem CGN unmöglich. Jedenfalls ohne vServer.
Ohne den Vermittlungsserver dazwischen MUSS mindestens eine Seite eine öffentliche IP haben (Responder) !

In der Laborsimulation findet ja eigentlich eine Verbindung zwischen zwei Netzwerken statt (mittels Raspi) aber ohne Einsatz eines Gateways

Auch das ist schlicht falsch und zeigt das du dir entweder das Schaubild zum Setup oder den Thread nicht wirklich durchgelesen hast.

Ein WAN Port hat die 10.99.1.99 /24 und der andere 10.1.1.189 /24 !!
Zwei völlig unterschiedliche IP Netzwerke also die OHNE einen Router dazwischen logischerweise niemals überwunden werden können ! Das weisst auch du selber.
Fazit:
Die "Internet Wolke" der Zeichnung besteht aus 2 Cisco 2600er Routern die Back to Back mit 10 Mbit und BGP Routing verbunden sind. Eine bessere und realistischere "Internet Simulation" kann es also gar nicht geben !
Für die Darstellung der VPN Funktion an sich ist dieser Fakt aber vollkommen unerheblich solange es eine IP Verbindung zwischen den beiden IP netzen 10.99.1.99 /24 und 10.1.1.189 /24 gibt. Wie auch immer die realisiert ist. Es könnte natürlich genausogut 85.99.1.99 /24 und 85.1.1.189 /24 sein was der VPN Funktion natürlich keinen Abbruch tut. Weisst du auch alles selber...?!

Das nicht einmal sowas wie ein Ping funktioniert lässt aber doch mehr als erheblichen Zeifel am Wahrheitsgehalt aufkommen.
Sorry, aber das klingt wirklich wenig glaubhaft.

Es ist aber leider so, wie ich es beschrieben haben.

Ich habe diesbezüglich SPUSU (Österreichischer Anbieter im Netz von "Drei") schon ziemlich verflucht, aber aufgrund der Tarifstruktur und Möglichkeit zur Multi-SIM ist es eben die einzige Möglichkeit. Vielleicht kommt euch mal was von SPUSU unter diesbezüglich...

So eine VPN Konstellation kann dann logischerweise nur mit einem Vermittlungshost laufen. Sprich du mietest dir für 3-5 Euro einen billigen vServer bei einem Hoster deiner Wahl, installierst dort OpenVPN. Der vServer hat immer eine öffentliche IP.

Ja, ist ist mir auch klar und habe ich schon im 1. Posting geschrieben. Momentan scheitert es noch ein wenig an der Umsetzung und bestimmt auch am Verständnis für das Thema. Hier mal meine bisherigen Configs:

Was ich bisher habe:

vServer mit öffentlicher IP.
IP-Forwarding (net.ipv4.ip_forward = 1) ist gesetzt.
OpenVPN per Paketmanager installiert.

/etc/openvpn/server.conf

dev tun
proto udp4
port 1194
ca /etc/openvpn/server/ca.crt
cert /etc/openvpn/server/server.crt
key /etc/openvpn/server/server.key
dh /etc/openvpn/server/dh2048.pem
cipher AES-256-CBC
auth SHA256
user nobody
group nogroup
server 172.18.18.0 255.255.255.0
topology subnet
push "topology subnet"  
persist-key
persist-tun
status /etc/openvpn/openvpn-status.log
push "route 192.168.1.0 255.255.255.0"  
route 192.168.1.0 255.255.255.0
keepalive 10 120
explicit-exit-notify 1
client-config-dir /etc/openvpn/client 

/etc/openvpn/client/raspi1:

ifconfig-push 172.18.18.3 255.255.255.0
iroute 192.168.1.0 255.255.255.0

/etc/openvpn/client/tablet:

ifconfig-push 172.18.18.2 255.255.255.0
iroute 192.168.1.0 255.255.255.0

Raspberry PI am Standort A (IP: 192.168.1.107)

IP-Forwarding (net.ipv4.ip_forward = 1) ist gesetzt.

/etc/openvpn/client.conf:

dev tun
proto udp4
client
remote <IP des vServers>
ca /etc/openvpn/client/ca.crt
cert /etc/openvpn/client/raspi1.crt
key /etc/openvpn/client/raspi1.key
cipher AES-256-CBC
auth SHA256
auth-nocache
tls-client
remote-cert-tls server
user nobody
group nogroup
persist-tun
persist-key
mute-replay-warnings
pull

Android Tablet (per Mobilfunk 4G/LTE):

client.conf:

dev tun
proto udp4
client
remote <IP des vServers>
ca ca.crt
cert tablet.crt
key tablet.key
cipher AES-256-CBC
auth SHA256
auth-nocache
tls-client
remote-cert-tls server
user nobody
group nogroup
persist-tun
persist-key
mute-replay-warnings
pull

Was ich bisher getestet habe:

OpenVPN-Verbindung von Client (raspi1) auf vServer: OK
OpenVPN-Verbindung von Client (tablet) auf vServer: OK

Ping vom Client (raspi1) auf vServer über VPN-Tunnel:

ping 172.18.18.1
PING 172.18.18.1 (172.18.18.1) 56(84) bytes of data.
64 bytes from 172.18.18.1: icmp_seq=1 ttl=64 time=77.9 ms
64 bytes from 172.18.18.1: icmp_seq=2 ttl=64 time=82.8 ms
64 bytes from 172.18.18.1: icmp_seq=3 ttl=64 time=77.3 ms

route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         192.168.1.1     0.0.0.0         UG    303    0        0 wlan0
172.18.18.0     0.0.0.0         255.255.255.0   U     0      0        0 tun0
192.168.1.0     0.0.0.0         255.255.255.0   U     303    0        0 wlan0

Ping vom Client (tablet) auf vServer über VPN-Tunnel:

Ping (172.18.18.1) ist möglich.
Routing Tabelle kann ich auf dem Android Gerät nicht ausgeben.

Ping vom Client (tablet) auf LAN-Router über VPN-Tunnel:

Ping (192.168.1.1) auf LAN-Router funktioniert nicht.
Ping (192.168.1.107) auf Raspberry Pi im LAN funktioniert nicht.
Selbstverständlich auch kein Ping auf andere Geräte im LAN möglich.

Router (TP-Link, MR200, Mobilrouter) im LAN:

Eine statische Route habe ich wie folgt gesetzt:

Destination		Subnet Mask		Gateway
172.18.18.0		255.255.255.0	192.168.1.107

Ziel ist aktuell von mir:

Vom Mobilgerät (Tablet) per 4G/LTE die 192.168.1.1 erfolgreich zu pingen und auf Geräte im LAN 192.168.1.0 zugreifen zu kommen. Dies soll später dann auch von einem zweiten Mobilgerät (Smartphone) möglich sein. Das wäre aber letztendlich nur ein zweiter Client und eigentlich die selbe Konfiguration, außer der IP im VPN-Tunnel.

Ebenso soll es für den zweiten Standort (LAN 192.168.2.0) gleichfalls funktionieren, da fehlt mir aber noch der Raspi, den ich mir erst zulegen möchte, wenn das mal soweit läuft.

Das bedeutet weiters, dass ich auch von Standort A (192.168.1.0) auf Standort B (192.168.2.0) auf alle Geräte (und IP-Adressen) zugreifen können möchte, was ja über den VPN->Tunnel möglich sein muss.

Für mich stellt sich hier nun die Frage: Wo hab ich den Verständnis- oder Denkfehler?

Ich vermute etwas mit einer Route, die ich falsch habe oder noch fehlt. Aber wie gesagt: Das Verständnis.

((

Wäre toll, wenn man mich in die richtige Richtung schubst. Dann kann ich es verstehen und weiter aufbauen, was ich vorhabe.

Herzlichen Dank und schönes Weekend noch!

Und hier kommt die richtige Lösung, wasserdicht getestet.

Inhaltsverzeichnis

Konfig vServer (OpenVPN Server)

Konfig RasPi(OpenVPN Client)

Konfig mobiler Client (Windows Laptop mit 4G Stick)

Finaler Ping Check

Fazit

Konfig vServer (OpenVPN Server)

dev tun
proto udp4
port 1194
ca /etc/openvpn/server/ca.crt
cert /etc/openvpn/server/vserver.crt
key /etc/openvpn/server/vserver.key
dh /etc/openvpn/server/dh.pem
user nobody
group nogroup
server 172.18.18.0 255.255.255.0
topology subnet
push "topology subnet"
persist-key
persist-tun
status /etc/openvpn/openvpn-status.log
status-version 3
push "route 192.168.188.0 255.255.255.0"
route 192.168.188.0 255.255.255.0
keepalive 10 120
explicit-exit-notify 1
client-config-dir /etc/openvpn/server/clientconf 

RasPi hat den COMMON Name: "client02" deshalb Konfig Datei in /etc/openvpn/server/clientconf

ifconfig-push 172.18.18.254 255.255.255.0
iroute 192.168.188.0 255.255.255.0 

ACHTUNG: Bei der statischen RasPi Client IP von "oben" mit der IP Adressvergabe anfangen, da der Server automatisch von "unten" aufsteigend vergibt. Ansonsten kommt es zu Adress Chaos mit den mobilen Clients !

Interfaces und Routing Tabelle:

root@vserver:/etc/# ip route show
default via 85.12.34.254 dev eth0  metric 202
85.12.34.56/24 dev eth0  metric 202
172.18.18.0/24 dev tun0 proto kernel scope link src 172.18.18.1
192.168.188.0/24 via 172.18.18.2 dev tun0

root@vserver:/etc/# ip interface show
tun0: flags=4305<UP,POINTOPOINT,RUNNING,NOARP,MULTICAST>  mtu 1500
        inet 172.18.18.1  netmask 255.255.255.0  destination 172.18.18.1
        inet6 fe80::3f68:74e8:9525:b48  prefixlen 64  scopeid 0x20<link>
        unspec 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  txqueuelen 100  (UNSPEC)
        RX packets 6  bytes 504 (504.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 12  bytes 792 (792.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0 

Konfig RasPi(OpenVPN Client)

dev tun
proto udp4
client
remote 85.12.34.56 1194
ca /etc/openvpn/client/ca.crt
cert /etc/openvpn/client/client02.crt
key /etc/openvpn/client/client02.key
auth-nocache
tls-client
remote-cert-tls server
user nobody
group nogroup
persist-tun
persist-key
mute-replay-warnings
pull 

Tunnel Interface und Routing Tabelle:

 tun0: flags=4305<UP,POINTOPOINT,RUNNING,NOARP,MULTICAST>  mtu 1500
        inet 172.18.18.254  netmask 255.255.255.0  destination 172.18.18.254
        inet6 fe80::112:40cc:c30c:444b  prefixlen 64  scopeid 0x20<link>
        unspec 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  txqueuelen 100  (UNSPEC)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 2  bytes 96 (96.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

root@raspiclient:/etc/# ip route show
default via 192.168.188.1 dev eth0 metric 100
172.18.18.0/24 dev tun0 proto kernel scope link src 172.18.18.254
192.168.188.0/24 dev eth0 proto kernel scope link src 192.168.188.22 metric 100 

Konfig mobiler Client (Windows Laptop mit 4G Stick)

dev tun
proto udp4
remote 85.12.34.56 1194
ca   ca.crt
cert client01.crt
key  client01.key
auth-nocache
tls-client
remote-cert-tls server
# ping 15
# ping-restart 45
# ping-timer-rem
persist-tun
persist-key
mute-replay-warnings
pull 

Routing Tabelle mobiler Client:

IPv4-Routentabelle
===========================================================================
Aktive Routen:
     Netzwerkziel    Netzwerkmaske          Gateway    Schnittstelle Metrik
          0.0.0.0          0.0.0.0       212.x.y.z       212.x.y.z     35
         212.x.y.z    255.255.255.0   Auf Verbindung        212.x.y.z    291
         127.0.0.0        255.0.0.0   Auf Verbindung         127.0.0.1    331
        127.0.0.1  255.255.255.255   Auf Verbindung         127.0.0.1    331
  127.255.255.255  255.255.255.255   Auf Verbindung         127.0.0.1    331
      172.18.18.0    255.255.255.0   Auf Verbindung       172.18.18.2    291
      172.18.18.2  255.255.255.255   Auf Verbindung       172.18.18.2    291
    172.18.18.255  255.255.255.255   Auf Verbindung       172.18.18.2    291
    192.168.188.0    255.255.255.0      172.18.18.1      172.18.18.2    29
===========================================================================
Ständige Routen:
  Keine 

Finaler Ping Check

vServer auf FritzBox LAN Interface:

root@vserver:/etc/# ping 192.168.188.1 -c 3
PING 192.168.188.1 (192.168.188.1) 56(84) bytes of data.
64 bytes from 192.168.188.1: icmp_seq=1 ttl=63 time=2.40 ms
64 bytes from 192.168.188.1: icmp_seq=2 ttl=63 time=1.87 ms
64 bytes from 192.168.188.1: icmp_seq=3 ttl=63 time=1.82 ms 

RasPi Client auf vServer Tunnel Interface:

root@raspiclient:/etc/# ping 172.18.18.1 -c 3
PING 172.18.18.1 (172.18.18.1) 56(84) bytes of data.
64 bytes from 172.18.18.1: icmp_seq=1 ttl=64 time=1.59 ms
64 bytes from 172.18.18.1: icmp_seq=2 ttl=64 time=1.43 ms
64 bytes from 172.18.18.1: icmp_seq=3 ttl=64 time=1.24 ms 

Mobiler Client auf FritzBox LAN Interface:

C:\Users\admin>ping 192.168.188.1

Ping wird ausgeführt für 192.168.188.1 mit 32 Bytes Daten:
Antwort von 192.168.188.1: Bytes=32 Zeit=3ms TTL=62
Antwort von 192.168.188.1: Bytes=32 Zeit=3ms TTL=62
Antwort von 192.168.188.1: Bytes=32 Zeit=3ms TTL=62
Antwort von 192.168.188.1: Bytes=32 Zeit=3ms TTL=62

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

Fazit

Works as designed !!! 😉

So, nun bist du wieder dran !

P.S.: Eine anderes Tutorial was so etwas beschreibt ist hier zu lesen:
Feste IPs zuhause in pfsense via GRE Tunnel

Hallo und vielen Dank für die grossartige Hilfe.

Ich habe nun einen großen Fortschritt gemacht und möchte dies auch hier mal dokumentieren. Leider habe ich auch ein paar Fehler gemacht, die mich viel Zeit in der Fehlersuche gekostet haben. z.B. habe ich lange den Befehl "iroute" im Client-Config-Dir bei ALLEN Clients drinnen, was wohl ein grober Fehler war. Jetzt ist der nurmehr beim Raspi1 drinnen.

Also fangen wir mal an, denn irgendwas passt da noch nicht. Dazu unten mehr:

vServer Config (OpenVPN Gateway):

dev tun
proto udp4
port 1194
ca /etc/openvpn/server/ca.crt
cert /etc/openvpn/server/server.crt
key /etc/openvpn/server/server.key
dh /etc/openvpn/server/dh2048.pem
user nobody
group nogroup
server 172.18.18.0 255.255.255.0
topology subnet
push "topology subnet"  
persist-key
persist-tun
status /etc/openvpn/openvpn-status.log
status-version 3
push "route 192.168.1.0 255.255.255.0"  
route 192.168.1.0 255.255.255.0
keepalive 10 120
explicit-exit-notify 1
client-config-dir /etc/openvpn/client

Raspi1 Config (Standort A):

Raspberry Pi: 192.168.1.107 / 255.255.255.0
Router: TP-Link MR200 192.168.1.1 / 255.255.255.0

Statische Route im Router gesetzt:

Network Destination: 172.18.18.0
Subnet Mask: 255.255.255.0
Gateway: 192.168.1.107

client.conf:

dev tun
proto udp4
client
remote 51.255.104.136
ca /etc/openvpn/client/ca.crt
cert /etc/openvpn/client/raspi1.crt
key /etc/openvpn/client/raspi1.key
auth-nocache
tls-client
remote-cert-tls server
user nobody
group nogroup
persist-tun
persist-key
mute-replay-warnings
pull

ccd-datei:

ifconfig-push 172.18.18.254 255.255.255.0
iroute 192.168.1.0 255.255.255.0

Mobile Clients (als Beispiel):

client.conf:

dev tun
proto udp4
client
remote 51.255.104.136
ca ca.crt
cert dell.crt
key dell.key
auth-nocache
tls-client
remote-cert-tls server
persist-tun
persist-key
mute-replay-warnings
pull

ccd-datei:

ifconfig-push 172.18.18.200 255.255.255.0

TEST ERGEBNISSE:

Verbindungsaufbau von Router und mobilen Geräten: OK

vServer auf Router (Standort A) LAN Interface:
ping 192.168.1.1: OK

RasPi Client auf vServer Tunnel Interface:
ping 172.18.18.1: OK

Mobiler Client auf Router (Standort A) LAN Interface:
ping 192.168.1.1: OK

Mobiler Client auf Raspi1 (Standort A):
ping 192.168.1.107: OK

ABER:

Mobiler Client auf anderes Gerät (Standort A):
ping 192.168.1.108: Zeitüberschreitung bei Verbindung

Selbes gilt auch für alle anderen Geräte am Standort A.

Für mich stellt sich nun die Frage nach dem wieso?

- IP-Forwarding ist am vServer Gateway aktiviert.
- IP-Forwarding ist am Raspi1 (Standort A) aktiviert.
- Statische Route ist am Router (Standort A) aktiviert.

Wo habe ich da noch einen Fehler? Was habe ich übersehen, ich komme einfach nicht drauf *grrrr*

Eine ccd Datei für den mobilen Client ist NICHT erforderlich und auch kontraproduktiv. Diese brauchen entgegen dem RasPi Client der ja routet keine feste Tunnel IP !
Diese ccd solltest du also in jedem Falle weglassen ! Sie muss rein nur für den RasPi konfiguriert sein und nicht für die mob. Clients.

Leider fehlt ein route print oder der Output der Routing Tabelle des mobilen Clients !

So kann man nicht checken ob das 192.168.1.0er Netzwerk richtig in seiner Routing Tabelle steht bei aktivem OVPN Client. Hier helfen wie immer die HE.NET Tools:
https://play.google.com/store/apps/details?id=net.he.networktools&hl ...
https://apps.apple.com/de/app/he-net-network-tools/id858241710
Diese zeigen immer die lokalen Routing Tabellen bei Mobilgeräten !
Ein Screenshot wäre hier sehr hilfreich !

Worst Case wäre wenn das ein Android ist der kein Pushen von Routes in die Routing Tabelk supportet weil der OVPN Client nicht mit Root Rechten arbeitet.
Das müsste man mal checken indem man testweise eine Windows oder Linux oder macOS Client als mobilen Client testet.
Wenn die die richtigen Routen in ihrer Routing Tabelle haben, dann liegt es am Android Client selber.
Apple iOS kann übernimmt z.B. diese Routen mit dem offiziellen OVPN Client aus dem App Store fehlerlos !

Okay, ich hab die ccd-Dateien für die mobilen Clients mal entfernt.

Die HE-Tools dürften nur auf Apple die Routing Table anzeigen, aber nicht auf Android. Ich habe einen Screenshot beigefügt. Im Google Playstore ist auch nichts von der Routing Table bei Android angegeben, eventuell funktioniert das bei Android gar nicht.

SAMSUNG TABLET:

Ich habe es mal mit der adb-Shell (über USB-Debugging) auf Android versucht, mit Erfolg:

cat /proc/net/route
Iface   Destination     Gateway         Flags   RefCnt  Use     Metric  Mask            MTU     Window  IRTT            
rmnet_data0     E031C10A        00000000        0001    0       0       0       F8FFFFFF        0       0       0       
tun0    001212AC        00000000        0001    0       0       0       00FFFFFF        0       0       0

C:\adb>adb shell
gts3llte:/ $ netstat -nr
Kernel IP routing table
Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
10.193.49.224   0.0.0.0         255.255.255.248 U         0 0          0 rmnet_data0
172.18.18.0     0.0.0.0         255.255.255.0   U         0 0          0 tun0

Erste Ausgabe nicht recht praktikabel, nach ein wenig Google-Suche habe ich die Info zum zweiten Befehl gefunden.

NOTEBOOK (per USB-Tethering angeschlossen am Smartphone):

route print -4
IPv4-Routentabelle
===========================================================================
Aktive Routen:
     Netzwerkziel    Netzwerkmaske          Gateway    Schnittstelle Metrik
          0.0.0.0          0.0.0.0   192.168.42.129   192.168.42.165     75
        127.0.0.0        255.0.0.0   Auf Verbindung         127.0.0.1    331
        127.0.0.1  255.255.255.255   Auf Verbindung         127.0.0.1    331
  127.255.255.255  255.255.255.255   Auf Verbindung         127.0.0.1    331
     192.168.42.0    255.255.255.0   Auf Verbindung    192.168.42.165    331
   192.168.42.165  255.255.255.255   Auf Verbindung    192.168.42.165    331
   192.168.42.255  255.255.255.255   Auf Verbindung    192.168.42.165    331
        224.0.0.0        240.0.0.0   Auf Verbindung         127.0.0.1    331
        224.0.0.0        240.0.0.0   Auf Verbindung    192.168.42.165    331
  255.255.255.255  255.255.255.255   Auf Verbindung         127.0.0.1    331
  255.255.255.255  255.255.255.255   Auf Verbindung    192.168.42.165    331
===========================================================================
Ständige Routen:
  Keine

screenshot_20200716-134842_network tools

Beim Tablet fehlt die 192.168.1.0er Router komplett ! Das push "route 192.168.1.0 255.255.255.0" wird also gar nicht ausgeführt am Client.
Beim Notebook ist nicht einmal die Internet OVPN Route/Schnittstelle zu sehen ! Bis du dir sicher das dort der OVPN Client wirklich aktiv ist und am vServer angemeldet ?!
Sehr wahrscheinlich ist das nicht der Fall. Dort fehlt ja komplett alles ! Sogar das Interface.
Siehst du natürlich auch selber das diese Routen da fehlen !

Jepp, die fehlende Route ist mir auch aufgefallen, daher...

Zwei Sachen:

1. Ja, ich hab beim Notebook (per USB-Tethering) einen Fehler gemacht, ich war nicht verbunden mit dem VPN.
2. E gibt auch anscheinend ein Problem mit dem "netstat -nr" auf dem Android, siehe folgende Infos.

C:\adb>adb shell
gts3llte:/ $ netstat -nr
Kernel IP routing table
Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
10.193.49.224   0.0.0.0         255.255.255.248 U         0 0          0 rmnet_data0
172.18.18.0     0.0.0.0         255.255.255.0   U         0 0          0 tun0

Was ich heraus gefunden habe, gibt es irgendwelche "unsichtbaren Routen", die hier nicht aufscheinen. Dabei bin ich auf folgenden Befehl aufmerksam geworden, der mir auch entsprechende Einträge liefert, wenn ich mit dem Tablet per VPN verbunden bin:

ANDROID TABLET

/system/bin/ip route show table 0
default dev dummy0 table 1002 proto static scope link
172.18.18.0/24 dev tun0 table 1259 proto static scope link
**192.168.1.0/24 dev tun0 table 1259 proto static scope link**
default via 10.193.49.229 dev rmnet_data0 table 1009 proto static
10.193.49.224/29 dev rmnet_data0 table 1009 proto static scope link
10.193.49.224/29 dev rmnet_data0 proto kernel scope link src 10.193.49.228
172.18.18.0/24 dev tun0 proto kernel scope link src 172.18.18.2
broadcast 10.193.49.224 dev rmnet_data0 table local proto kernel scope link src 10.193.49.228
local 10.193.49.228 dev rmnet_data0 table local proto kernel scope host src 10.193.49.228
broadcast 10.193.49.231 dev rmnet_data0 table local proto kernel scope link src 10.193.49.228
broadcast 127.0.0.0 dev lo table local proto kernel scope link src 127.0.0.1
local 127.0.0.0/8 dev lo table local proto kernel scope host src 127.0.0.1
local 127.0.0.1 dev lo table local proto kernel scope host src 127.0.0.1
broadcast 127.255.255.255 dev lo table local proto kernel scope link src 127.0.0.1
broadcast 172.18.18.0 dev tun0 table local proto kernel scope link src 172.18.18.2
local 172.18.18.2 dev tun0 table local proto kernel scope host src 172.18.18.2
broadcast 172.18.18.255 dev tun0 table local proto kernel scope link src 172.18.18.2
unreachable default dev lo table 1025 proto static metric 1024 error -101
unreachable default dev lo proto kernel metric 4294967295 error -101
unreachable default dev lo proto kernel metric 4294967295 error -101
unreachable default dev lo proto kernel metric 4294967295 error -101
unreachable default dev lo proto kernel metric 4294967295 error -101
unreachable default dev lo proto kernel metric 4294967295 error -101
unreachable default dev lo proto kernel metric 4294967295 error -101
unreachable default dev lo proto kernel metric 4294967295 error -101
unreachable default dev lo proto kernel metric 4294967295 error -101
unreachable default dev lo proto kernel metric 4294967295 error -101
unreachable default dev lo proto kernel metric 4294967295 error -101
unreachable default dev lo proto kernel metric 4294967295 error -101
unreachable default dev lo proto kernel metric 4294967295 error -101
unreachable default dev lo proto kernel metric 4294967295 error -101
unreachable default dev lo proto kernel metric 4294967295 error -101
unreachable default dev lo proto kernel metric 4294967295 error -101
unreachable default dev lo proto kernel metric 4294967295 error -101
unreachable default dev lo proto kernel metric 4294967295 error -101
unreachable default dev lo proto kernel metric 4294967295 error -101
unreachable default dev lo proto kernel metric 4294967295 error -101
unreachable default dev lo proto kernel metric 4294967295 error -101
unreachable default dev lo proto kernel metric 4294967295 error -101
unreachable default dev lo proto kernel metric 4294967295 error -101
unreachable default dev lo proto kernel metric 4294967295 error -101
unreachable default dev lo proto kernel metric 4294967295 error -101
unreachable default dev lo proto kernel metric 4294967295 error -101
unreachable default dev lo proto kernel metric 4294967295 error -101
unreachable default dev lo proto kernel metric 4294967295 error -101
unreachable default dev lo proto kernel metric 4294967295 error -101
unreachable default dev lo proto kernel metric 4294967295 error -101
unreachable default dev lo proto kernel metric 4294967295 error -101
unreachable default dev lo proto kernel metric 4294967295 error -101
unreachable default dev lo proto kernel metric 4294967295 error -101
unreachable default dev lo proto kernel metric 4294967295 error -101
unreachable default dev lo proto kernel metric 4294967295 error -101
unreachable default dev lo proto kernel metric 4294967295 error -101
unreachable default dev lo proto kernel metric 4294967295 error -101
unreachable default dev lo proto kernel metric 4294967295 error -101
unreachable default dev lo proto kernel metric 4294967295 error -101
unreachable default dev lo proto kernel metric 4294967295 error -101
unreachable default dev lo proto kernel metric 4294967295 error -101
unreachable default dev lo proto kernel metric 4294967295 error -101
unreachable default dev lo proto kernel metric 4294967295 error -101
unreachable default dev lo proto kernel metric 4294967295 error -101
unreachable default dev lo proto kernel metric 4294967295 error -101
unreachable default dev lo proto kernel metric 4294967295 error -101
unreachable default dev lo proto kernel metric 4294967295 error -101
unreachable default dev lo proto kernel metric 4294967295 error -101
unreachable default dev lo proto kernel metric 4294967295 error -101
unreachable default dev lo proto kernel metric 4294967295 error -101
unreachable default dev lo proto kernel metric 4294967295 error -101
unreachable default dev lo proto kernel metric 4294967295 error -101
unreachable default dev lo proto kernel metric 4294967295 error -101
unreachable default dev lo proto kernel metric 4294967295 error -101
unreachable default dev lo proto kernel metric 4294967295 error -101
unreachable default dev lo proto kernel metric 4294967295 error -101
unreachable default dev lo proto kernel metric 4294967295 error -101
unreachable default dev lo proto kernel metric 4294967295 error -101
unreachable default dev lo proto kernel metric 4294967295 error -101
unreachable default dev lo proto kernel metric 4294967295 error -101
unreachable default dev lo proto kernel metric 4294967295 error -101
unreachable default dev lo proto kernel metric 4294967295 error -101
unreachable default dev lo proto kernel metric 4294967295 error -101
unreachable default dev lo proto kernel metric 4294967295 error -101
unreachable default dev lo proto kernel metric 4294967295 error -101
unreachable default dev lo proto kernel metric 4294967295 error -101
unreachable default dev lo proto kernel metric 4294967295 error -101
unreachable default dev lo proto kernel metric 4294967295 error -101
unreachable default dev lo proto kernel metric 4294967295 error -101
unreachable default dev lo proto kernel metric 4294967295 error -101
unreachable default dev lo proto kernel metric 4294967295 error -101
unreachable default dev lo proto kernel metric 4294967295 error -101
unreachable default dev lo proto kernel metric 4294967295 error -101
unreachable default dev lo proto kernel metric 4294967295 error -101
unreachable default dev lo proto kernel metric 4294967295 error -101
unreachable default dev lo proto kernel metric 4294967295 error -101
unreachable default dev lo proto kernel metric 4294967295 error -101
unreachable default dev lo proto kernel metric 4294967295 error -101
unreachable default dev lo proto kernel metric 4294967295 error -101
unreachable default dev lo proto kernel metric 4294967295 error -101
unreachable default dev lo proto kernel metric 4294967295 error -101
unreachable default dev lo proto kernel metric 4294967295 error -101
unreachable default dev lo proto kernel metric 4294967295 error -101
unreachable default dev lo proto kernel metric 4294967295 error -101
unreachable default dev lo proto kernel metric 4294967295 error -101
unreachable default dev lo proto kernel metric 4294967295 error -101
unreachable default dev lo proto kernel metric 4294967295 error -101
unreachable default dev lo table 1127 proto static metric 1024 error -101
unreachable default dev lo proto kernel metric 4294967295 error -101
unreachable default dev lo proto kernel metric 4294967295 error -101
unreachable default dev lo proto kernel metric 4294967295 error -101
unreachable default dev lo proto kernel metric 4294967295 error -101
unreachable default dev lo proto kernel metric 4294967295 error -101
unreachable default dev lo proto kernel metric 4294967295 error -101
unreachable default dev lo proto kernel metric 4294967295 error -101
unreachable default dev lo proto kernel metric 4294967295 error -101
unreachable default dev lo proto kernel metric 4294967295 error -101
unreachable default dev lo proto kernel metric 4294967295 error -101
unreachable default dev lo proto kernel metric 4294967295 error -101
unreachable default dev lo proto kernel metric 4294967295 error -101
unreachable default dev lo proto kernel metric 4294967295 error -101
unreachable default dev lo proto kernel metric 4294967295 error -101
unreachable default dev lo proto kernel metric 4294967295 error -101
unreachable default dev lo proto kernel metric 4294967295 error -101
unreachable default dev lo proto kernel metric 4294967295 error -101
unreachable default dev lo proto kernel metric 4294967295 error -101
unreachable default dev lo proto kernel metric 4294967295 error -101
unreachable default dev lo proto kernel metric 4294967295 error -101
unreachable default dev lo proto kernel metric 4294967295 error -101
unreachable default dev lo proto kernel metric 4294967295 error -101
unreachable default dev lo proto kernel metric 4294967295 error -101
unreachable default dev lo table 1157 proto static metric 1024 error -101
unreachable default dev lo proto kernel metric 4294967295 error -101
unreachable default dev lo proto kernel metric 4294967295 error -101
unreachable default dev lo proto kernel metric 4294967295 error -101
unreachable default dev lo proto kernel metric 4294967295 error -101
unreachable default dev lo proto kernel metric 4294967295 error -101
unreachable default dev lo proto kernel metric 4294967295 error -101
unreachable default dev lo proto kernel metric 4294967295 error -101
unreachable default dev lo proto kernel metric 4294967295 error -101
unreachable default dev lo proto kernel metric 4294967295 error -101
unreachable default dev lo proto kernel metric 4294967295 error -101
unreachable default dev lo proto kernel metric 4294967295 error -101
unreachable default dev lo proto kernel metric 4294967295 error -101
unreachable default dev lo proto kernel metric 4294967295 error -101
unreachable default dev lo proto kernel metric 4294967295 error -101
unreachable default dev lo proto kernel metric 4294967295 error -101
unreachable default dev lo proto kernel metric 4294967295 error -101
unreachable default dev lo proto kernel metric 4294967295 error -101
unreachable default dev lo proto kernel metric 4294967295 error -101
unreachable default dev lo proto kernel metric 4294967295 error -101
unreachable default dev lo proto kernel metric 4294967295 error -101
unreachable default dev lo proto kernel metric 4294967295 error -101
unreachable default dev lo proto kernel metric 4294967295 error -101
unreachable default dev lo proto kernel metric 4294967295 error -101
unreachable default dev lo proto kernel metric 4294967295 error -101
unreachable default dev lo proto kernel metric 4294967295 error -101
unreachable default dev lo proto kernel metric 4294967295 error -101
unreachable default dev lo proto kernel metric 4294967295 error -101
unreachable default dev lo proto kernel metric 4294967295 error -101
unreachable default dev lo proto kernel metric 4294967295 error -101
unreachable default dev lo proto kernel metric 4294967295 error -101
unreachable default dev lo proto kernel metric 4294967295 error -101
unreachable default dev lo proto kernel metric 4294967295 error -101
unreachable default dev lo proto kernel metric 4294967295 error -101
unreachable default dev lo proto kernel metric 4294967295 error -101
unreachable default dev lo proto kernel metric 4294967295 error -101
unreachable default dev lo proto kernel metric 4294967295 error -101
unreachable default dev lo proto kernel metric 4294967295 error -101
unreachable default dev lo proto kernel metric 4294967295 error -101
unreachable default dev lo proto kernel metric 4294967295 error -101
unreachable default dev lo proto kernel metric 4294967295 error -101
unreachable default dev lo proto kernel metric 4294967295 error -101
unreachable default dev lo proto kernel metric 4294967295 error -101
unreachable default dev lo proto kernel metric 4294967295 error -101
unreachable default dev lo proto kernel metric 4294967295 error -101
unreachable default dev lo proto kernel metric 4294967295 error -101
unreachable default dev lo proto kernel metric 4294967295 error -101
unreachable default dev lo proto kernel metric 4294967295 error -101
unreachable default dev lo proto kernel metric 4294967295 error -101
unreachable default dev lo proto kernel metric 4294967295 error -101
unreachable default dev lo proto kernel metric 4294967295 error -101
unreachable default dev lo proto kernel metric 4294967295 error -101
unreachable default dev lo proto kernel metric 4294967295 error -101
unreachable default dev lo proto kernel metric 4294967295 error -101
unreachable default dev lo proto kernel metric 4294967295 error -101
unreachable default dev lo proto kernel metric 4294967295 error -101
unreachable default dev lo proto kernel metric 4294967295 error -101
unreachable default dev lo proto kernel metric 4294967295 error -101
unreachable default dev lo proto kernel metric 4294967295 error -101
unreachable default dev lo proto kernel metric 4294967295 error -101
unreachable default dev lo proto kernel metric 4294967295 error -101
unreachable default dev lo proto kernel metric 4294967295 error -101
unreachable default dev lo proto kernel metric 4294967295 error -101
unreachable default dev lo proto kernel metric 4294967295 error -101
unreachable default dev lo proto kernel metric 4294967295 error -101
unreachable default dev lo proto kernel metric 4294967295 error -101
unreachable default dev lo proto kernel metric 4294967295 error -101
unreachable default dev lo proto kernel metric 4294967295 error -101
unreachable default dev lo proto kernel metric 4294967295 error -101
unreachable default dev lo proto kernel metric 4294967295 error -101
unreachable default dev lo proto kernel metric 4294967295 error -101
unreachable default dev lo proto kernel metric 4294967295 error -101
unreachable default dev lo proto kernel metric 4294967295 error -101
unreachable default dev lo proto kernel metric 4294967295 error -101
unreachable default dev lo proto kernel metric 4294967295 error -101
unreachable default dev lo proto kernel metric 4294967295 error -101
unreachable default dev lo proto kernel metric 4294967295 error -101
unreachable default dev lo proto kernel metric 4294967295 error -101
unreachable default dev lo proto kernel metric 4294967295 error -101
unreachable default dev lo proto kernel metric 4294967295 error -101
unreachable default dev lo proto kernel metric 4294967295 error -101
unreachable default dev lo proto kernel metric 4294967295 error -101
unreachable default dev lo proto kernel metric 4294967295 error -101
unreachable default dev lo proto kernel metric 4294967295 error -101
unreachable default dev lo proto kernel metric 4294967295 error -101
unreachable default dev lo proto kernel metric 4294967295 error -101
fe80::/64 dev dummy0 table 1002 proto kernel metric 256
default dev dummy0 table 1002 proto static metric 1024
unreachable default dev lo proto kernel metric 4294967295 error -101
unreachable default dev lo table 1259 proto static metric 1024 error -101
unreachable default dev lo proto kernel metric 4294967295 error -101
unreachable default dev lo proto kernel metric 4294967295 error -101
unreachable default dev lo proto kernel metric 4294967295 error -101
unreachable default dev lo proto kernel metric 4294967295 error -101
unreachable default dev lo proto kernel metric 4294967295 error -101
unreachable default dev lo proto kernel metric 4294967295 error -101
local ::1 dev lo table local proto unspec metric 0
local fe80::b4a0:dbff:fe2d:a2f6 dev lo table local proto unspec metric 0
ff00::/8 dev dummy0 table local metric 256
unreachable default dev lo proto kernel metric 4294967295 error -101

(Anmerkung: Woher die vielen "unreachable" beim Tablet kommen, weiß ich nicht. Soll mich jetzt mal nicht stören, aber kommt mir halt komisch vor. Da aber direkt vom Android System, wird man hier wohl auch nicht eingreifen können.)

ANDROID SMARTPHONE

/system/bin/ip route show table 0
172.18.18.0/24 dev tun0 table 1042 proto static scope link
**192.168.1.0/24 dev tun0 table 1042 proto static scope link**
default via 10.74.16.1 dev rmnet4 table 1008 proto static
10.74.16.0/24 dev rmnet4 table 1008 proto static scope link
10.74.16.0/24 dev rmnet4 proto kernel scope link src 10.74.16.37
172.18.18.0/24 dev tun0 proto kernel scope link src 172.18.18.3
broadcast 10.74.16.0 dev rmnet4 table local proto kernel scope link src 10.74.16.37
local 10.74.16.37 dev rmnet4 table local proto kernel scope host src 10.74.16.37
broadcast 10.74.16.255 dev rmnet4 table local proto kernel scope link src 10.74.16.37
broadcast 127.0.0.0 dev lo table local proto kernel scope link src 127.0.0.1
local 127.0.0.0/8 dev lo table local proto kernel scope host src 127.0.0.1
local 127.0.0.1 dev lo table local proto kernel scope host src 127.0.0.1
broadcast 127.255.255.255 dev lo table local proto kernel scope link src 127.0.0.1
broadcast 172.18.18.0 dev tun0 table local proto kernel scope link src 172.18.18.3
local 172.18.18.3 dev tun0 table local proto kernel scope host src 172.18.18.3
broadcast 172.18.18.255 dev tun0 table local proto kernel scope link src 172.18.18.3
fe80::/64 dev tun0 table 1042 proto kernel metric 256 pref medium
unreachable default dev lo table 1042 proto static metric 1024 error -113 pref medium
local ::1 dev lo table local proto kernel metric 0 pref medium
local fe80::5ed0:dc68:5fd8:54f6 dev tun0 table local proto kernel metric 0 pref medium
ff00::/8 dev tun0 table local metric 256 pref medium

NOTEBOOK PER USB-TETHERING

IPv4-Routentabelle
===========================================================================
Aktive Routen:
     Netzwerkziel    Netzwerkmaske          Gateway    Schnittstelle Metrik
          0.0.0.0          0.0.0.0   192.168.42.129   192.168.42.165     75
        127.0.0.0        255.0.0.0   Auf Verbindung         127.0.0.1    331
        127.0.0.1  255.255.255.255   Auf Verbindung         127.0.0.1    331
  127.255.255.255  255.255.255.255   Auf Verbindung         127.0.0.1    331
      172.18.18.0    255.255.255.0   Auf Verbindung       172.18.18.4    281
      172.18.18.4  255.255.255.255   Auf Verbindung       172.18.18.4    281
    172.18.18.255  255.255.255.255   Auf Verbindung       172.18.18.4    281
**      192.168.1.0    255.255.255.0      172.18.18.1      172.18.18.4     25**
     192.168.42.0    255.255.255.0   Auf Verbindung    192.168.42.165    331
   192.168.42.165  255.255.255.255   Auf Verbindung    192.168.42.165    331
   192.168.42.255  255.255.255.255   Auf Verbindung    192.168.42.165    331
        224.0.0.0        240.0.0.0   Auf Verbindung         127.0.0.1    331
        224.0.0.0        240.0.0.0   Auf Verbindung       172.18.18.4    281
        224.0.0.0        240.0.0.0   Auf Verbindung    192.168.42.165    331
  255.255.255.255  255.255.255.255   Auf Verbindung         127.0.0.1    331
  255.255.255.255  255.255.255.255   Auf Verbindung       172.18.18.4    281
  255.255.255.255  255.255.255.255   Auf Verbindung    192.168.42.165    331
===========================================================================
Ständige Routen:
  Keine

LOGFILE DER VERBINDUNG AM ANDROID TABLET

Sieht doch auch alles normal aus, oder übersehe ich da etwas? Am Smartphone sieht es genauso aus, das möchte ich jetzt nicht auch noch reinkopieren, da es doch einiges an Code ist.

21:58.572 -- ----- OpenVPN Start -----

21:58.573 -- EVENT: CORE_THREAD_ACTIVE

21:58.578 -- OpenVPN core 3.git:released:3e56f9a6:Release android arm64 64-bit PT_PROXY

21:58.578 -- Frame=512/2048/512 mssfix-ctrl=1250

21:58.579 -- UNUSED OPTIONS
[auth-nocache] 
[tls-client] 
[user] [nobody] 
[group] [nogroup] 
[persist-tun] 
[persist-key] 
[mute-replay-warnings] 
[pull] 

21:58.579 -- EVENT: RESOLVE

21:58.589 -- Contacting <Öffentliche-IP-des-vServers>:1194 via UDP

21:58.589 -- EVENT: WAIT

21:58.602 -- Connecting to [Öffentliche-IP-des-vServers]:1194 (Öffentliche-IP-des-vServers) via UDPv4

21:58.979 -- EVENT: CONNECTING

21:58.984 -- Tunnel Options:V4,dev-type tun,link-mtu 1541,tun-mtu 1500,proto UDPv4,cipher BF-CBC,auth SHA1,keysize 128,key-method 2,tls-client

21:58.985 -- Creds: UsernameEmpty/PasswordEmpty

21:58.986 -- Peer Info:
IV_VER=3.git:released:3e56f9a6:Release
IV_PLAT=android
IV_NCP=2
IV_TCPNL=1
IV_PROTO=2
IV_AUTO_SESS=1
IV_GUI_VER=net.openvpn.connect.android_3.2.2-5027
IV_SSO=openurl
IV_BS64DL=1


21:59.037 -- VERIFY OK: depth=1,
Hier sind Infos zum Server Zertifikat

21:59.038 -- VERIFY OK: depth=0,
Hier sind Infos zum Server Zertifikat

21:59.158 -- SSL Handshake: CN=server, TLSv1.2, cipher TLSv1.2 ECDHE-RSA-AES256-GCM-SHA384, 2048 bit RSA

21:59.167 -- Session is ACTIVE

21:59.168 -- EVENT: GET_CONFIG

21:59.171 -- Sending PUSH_REQUEST to server...

21:59.222 -- OPTIONS:
[topology] [subnet] 
[route] [192.168.1.0] [255.255.255.0] 
[route-gateway] [172.18.18.1] 
[topology] [subnet] 
[ping] [10] 
[ping-restart] [120] 
[ifconfig] [172.18.18.2] [255.255.255.0] 
[peer-id]  
[cipher] [AES-256-GCM] 


21:59.223 -- PROTOCOL OPTIONS:
  cipher: AES-256-GCM
  digest: NONE
  compress: NONE
  peer ID: 0

21:59.224 -- EVENT: ASSIGN_IP

21:59.271 -- Connected via tun

21:59.272 -- EVENT: CONNECTED info='<Öffentliche-IP-des-vServers>:1194 (<Öffentliche-IP-des-vServers>) via /UDPv4 on tun/172.18.18.2/ gw=[172.18.18.1/]'  

LOGFILE DER VERBINDUNG AM NOTEBOOK PER USB-TETHERING

Fri Jul 17 01:25:50 2020 OpenVPN 2.4.9 x86_64-w64-mingw32 [SSL (OpenSSL)] [LZO] [LZ4] [PKCS11] [AEAD] built on Apr 16 2020
Fri Jul 17 01:25:50 2020 Windows version 6.2 (Windows 8 or greater) 64bit
Fri Jul 17 01:25:50 2020 library versions: OpenSSL 1.1.1f  31 Mar 2020, LZO 2.10
Fri Jul 17 01:25:51 2020 TCP/UDP: Preserving recently used remote address: [AF_INET]<Öffentliche-IP-des-vServers>:1194
Fri Jul 17 01:25:51 2020 UDPv4 link local (bound): [AF_INET][undef]:1194
Fri Jul 17 01:25:51 2020 UDPv4 link remote: [AF_INET]<Öffentliche-IP-des-vServers>:1194
Fri Jul 17 01:25:52 2020 [server] Peer Connection Initiated with [AF_INET]<Öffentliche-IP-des-vServers>:1194
Fri Jul 17 01:25:53 2020 open_tun
Fri Jul 17 01:25:53 2020 TAP-WIN32 device [LAN-Verbindung] opened: \\.\Global\{CAEBAE24-8FB7-4173-B7D7-550A1FCC97FE}.tap
Fri Jul 17 01:25:53 2020 Set TAP-Windows TUN subnet mode network/local/netmask = 172.18.18.0/172.18.18.4/255.255.255.0 [SUCCEEDED]
Fri Jul 17 01:25:53 2020 Notified TAP-Windows driver to set a DHCP IP/netmask of 172.18.18.4/255.255.255.0 on interface {CAEBAE24-8FB7-4173-B7D7-550A1FCC97FE} [DHCP-serv: 172.18.18.254, lease-time: 31536000]
Fri Jul 17 01:25:53 2020 Successful ARP Flush on interface [17] {CAEBAE24-8FB7-4173-B7D7-550A1FCC97FE}
Fri Jul 17 01:25:58 2020 Initialization Sequence Completed

Ehrlich, ich bin mittlerweile ratlos, aber es ist extrem toll etwas zu lernen.

Und ich habe schon viel dabei gelernt, wenn man sich damit beschäftigt.

Das Fazit ist ja eindeutig:

Deine OpenVPN Konfig funktioniert fehlerlos ! Siehe Notebook
Das Tablet supportet keine injizierten Routen !

Wie bereits oben gesagt wurde das oben gepostete Test Setup mit einem iPhone und iPad mit OVPN Client getestet und das funktioniert fehlerfrei. Die HE.Tools Routing Tabelle zeigt auch klar die per OpenVPN injizierten Routen an:

Das ist also alles korrekt und so ist es auch bei dir, da deine Konfig bis auf die lokalen IP Netze ja absolut identisch ist.
Die Route im mobilen Notebook beweist das ja das du aktuell vom VPN Setaup an sich alles richtig gemacht hast.
Ein Test mit einem Xiaomi Redme 4a funktionierte hier übrigens mit dem o.a. Testsetup ebenso problemlos unter Android. Das akzeptiert also injizierte Routen in seiner Android Version ebenso wie dein Smartphone oben was die 192.168.1.0er Route ja auch anstandslos übernommen hat und damit ja sicher auch funkltioniert.

Fazit:
Du hast ein Software Problem auf dem spezifischen Tablet. Als Workaround könnte man für die mobilen Clients ggf. einen Gateway Redirect versuchen (push "redirect-gateway def1 bypass-dhcp"). Allso alles in den Tunnel zu routen. Es steht aber zu befürchten das dieses Tablet auch nichtmal das kann, da es wieder einen Eingriff in die Routing Tabelle erfordert was bei der spezifischen Tablet Android Version wohl nur mit Root Rechten klappt. Wenn dort der OVPN Client ohne Root Rechte arbeitet ist das auch aussichtslos.
Normal würde da dann eine statische Route helfen und das Problem lösen aber auch hier ohne Root Rechte wird das wohl eher schwierig....
Fazit aus dem Fazit: Auf IPsec (Strongswan) wechseln oder Apple iPads verwenden !

Das akzeptiert also injizierte Routen in seiner Android Version ebenso wie dein Smartphone oben was die 192.168.1.0er Route ja auch anstandslos übernommen hat und damit ja sicher auch funkltioniert.

Tja, wenn das so wäre, wäre ich glücklich.

Auch vom Smartphone und vom Notebook (über USB-Tethering) kann ich nur den Router (192.168.1.1) und den VPN-Client Raspberry Pi 1 (192.168.1.107) anpingen. Alle andere Ziele im Netzwerk sind nicht erreichbar, z.B. Rechner, Drucker, NAS, schaltbare Steckdosen, usw.

Wenn es nur auf dem Tablet nicht funktionieren würde, dann wäre die Sachlage ja klar. Aber so sieht es doch ganz anderes aus, aber wo ist dann der Fehler?

Bezüglich IPsec (Strongswan) hab ich schon mal kurz im Überblick was gelesen, aber dies dürfte ja erheblich schwieriger sein als OpenVPN. Habe mich allerdings nicht genau damit beschäftigt. Welcher Vorteil hätte oder soll ich damit haben gegenüber OpenVPN?

WAS MIR AUFGEFALLEN IST:

Am OpenVPN-Gateway-Server:

route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         149.202.82.254  0.0.0.0         UG    0      0        0 eth0
149.202.82.254  0.0.0.0         255.255.255.255 UH    0      0        0 eth0
172.18.18.0     0.0.0.0         255.255.255.0   U     0      0        0 tun0
192.168.1.0     172.18.18.2     255.255.255.0   UG    0      0        0 tun0

dev tun
proto udp4
port 1194
ca /etc/openvpn/server/ca.crt
cert /etc/openvpn/server/server.crt
key /etc/openvpn/server/server.key
dh /etc/openvpn/server/dh2048.pem
user nobody
group nogroup
server 172.18.18.0 255.255.255.0
topology subnet
push "topology subnet"  
persist-key
persist-tun
status /etc/openvpn/openvpn-status.log
status-version 3
route 192.168.1.0 255.255.255.0
push "route 192.168.1.0 255.255.255.0"  
keepalive 10 120
explicit-exit-notify 1
client-config-dir /etc/openvpn/client
verb 3

Warum habe ich als Gateway zu 192.168.1.0 eigentlich die 172.18.18.2 drinnen?

Sollte das nicht eigentlich die 172.18.18.254 (IP des Raspi 1) oder die 172.18.18.0 (IP des Gateway-Servers) sein?

Die 172.18.18.2 erhalte ich ja (bei der weiter oben genannten Konfiguration) als private IP am Tablet.

Verwirrung pur macht sich breit. *konfuzius*

Alle andere Ziele im Netzwerk sind nicht erreichbar, z.B. Rechner, Drucker, NAS, schaltbare Steckdosen, usw.

OK. Wenn dem wirklich so ist dann liegt der Fehler aber ganz klar im lokalen LAN des RasPi.
Rechner, Drucker, NAS, und schaltbare Steckdosen haben dort ja immer den lokalen Internet Router als Default Gateway.
Das es dann vom RasPi nicht weiter geht kann dann nur 2 Gründe haben:

Statische Default Route auf den Internet Router ins VPN IP Netz fehlt oder ist falsch konfiguriert ! Dort (auf dem Internet Router) muss eine statische Route ala: Zielnetz: 172.18.18.0, Maske: 255.255.255.0 Gateway: 192.168.1.<raspi_host_ip> definiert sein.
Rechner wenn sie Winblows OS haben muss die lokale Windows Firewall angepasst werden, da man ja mit einer fremden 172.18.18er IP drauf zugreift.

Besser ist es dann immer Drucker, NAS, oder schaltbare Steckdosen zu pingen, da die keine Firewall haben.

Du kannst das ganz einfach testen....
Pinge von einem Client aus dem lokalen 192.168.1.0er Netz die virtuelle OVPN IP des Servers 172.18.18.1 !
Das muss immer klappen wenn das Routing im lokalen .1.0er Netz sauber ist.
Auch ein Ping aus .1.0 auf die OVPN IP des RasPis 172.18.18.254 muss immer klappen !
Sieht so aus als ob du ein Routing oder Forwarding Problem dort im lokalen LAN oder dem RasPi hast.
Mache zur Sicherheit auf dem RasPi nochmal ein # cat /proc/sys/net/ipv4/ip_forward
Dort muss als Ergebnis eine 1 rauskommen !

Alle Routen werden ja sauber auf die Clients propagiert...jedenfalls beim Laptop ganz sicher. Daran liegt es also nicht. Ein Traceroute (tracert) auf einen Drucker oder NAS wird dann auch sicher bis zum RasPi kommen, oder ?
Zeigt dann das dort der Fehler ist.
Noch wasserdichteres Testen bekommst du mit dem Wireshark hin den du auf einem Zielrechner im .1.0er Netzwerk rennen lässt und checkst ob dort eingehden ICMP Echo Requests (Ping) vom externen Client ankommen !
Immer strategisch vorgehen...!

Also nach deiner Beschreibung scheint so einiges (alles?) richtig zu sein:

Die statische Route im Router (192.168.1.1):

Ping vom Client (Win10-Rechner) im lokalen Netz (192.168.1.0) auf die virtuelle OVPN-IP auf den ich verbinde (172.18.18.254):

C:\Users\juerg>ping 172.18.18.254

Ping wird ausgeführt für 172.18.18.254 mit 32 Bytes Daten:
Antwort von 172.18.18.254: Bytes=32 Zeit=3ms TTL=64
Antwort von 172.18.18.254: Bytes=32 Zeit=3ms TTL=64
Antwort von 172.18.18.254: Bytes=32 Zeit=4ms TTL=64
Antwort von 172.18.18.254: Bytes=32 Zeit=4ms TTL=64

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

Und noch ein Traceroute:

C:\Users\juerg>tracert 172.18.18.254

Routenverfolgung zu 172.18.18.254 über maximal 30 Hops

  1     2 ms     1 ms     1 ms  192.168.1.1
  2     5 ms     3 ms     3 ms  172.18.18.254

Ablaufverfolgung beendet.

IP-Forwarding auf dem RasPi:

pi@raspberrypi:~ $ cat /proc/sys/net/ipv4/ip_forward
1

IP-Forwarding auf dem vServer:

root@tunnel:~# cat /proc/sys/net/ipv4/ip_forward
1

Traceroute auf ein Schaltmodul mit Webinterface (Shelly 2.5) vom Win10-Client aus:

C:\Users\juerg>tracert 192.168.1.108

Routenverfolgung zu 192.168.1.108 über maximal 30 Hops

  1     5 ms     2 ms     7 ms  192.168.1.108

Ablaufverfolgung beendet.

Traceroute auf ein Schaltmodul mit Webinterface (Shelly 2.5) vom RasPi-Client (im LAN) aus:

pi@raspberrypi:~ $ traceroute 192.168.1.108
traceroute to 192.168.1.108 (192.168.1.108), 30 hops max, 60 byte packets
 1  192.168.1.108 (192.168.1.108)  4.359 ms  4.809 ms  5.165 ms

Traceroute auf ein Schaltmodul mit Webinterface (Shelly 2.5) vom vServer (über OVPN-Tunnel) aus:

root@tunnel:~# traceroute 192.168.1.108
traceroute to 192.168.1.108 (192.168.1.108), 30 hops max, 60 byte packets
 1  172.18.18.254 (172.18.18.254)  50.041 ms  50.793 ms  57.063 ms
 2  192.168.1.108 (192.168.1.108)  57.065 ms  57.178 ms  64.148 ms

Ping vom vServer (Gateway) auf das Schaltmodul:

root@tunnel:~# ping 192.168.1.108
PING 192.168.1.108 (192.168.1.108) 56(84) bytes of data.

Keine Ausgabe, gar nichts... Auch kein Zugriff auf das Webinterface, eh klar.

Wenn du bei im Text eingebetteten Bilder auch mal die "+" Taste an der richtigen Stelle klicken würdest, dann würden die Bilder auch hier im richtigen Kontext erscheinen und nicht wirr am Ende des Threads. Das würde allen zur Übersichtlichkeit helfen.
FAQs lesen und verstehen hilft wirklich !

(Kann man übrigens nachträglich immer über den "Bearbeiten" Knopf rechts unter "Mehr" korrigieren !)
Zurück zum Thread...

Ping vom Client (Win10-Rechner) im lokalen Netz (192.168.1.0) auf die virtuelle OVPN-IP auf den ich verbinde (172.18.18.254):

OK, das ist ja die OVPN IP des RasPi die ihm fest zugewiesen wird. Zeigt das dieser routet.
Noch sinnvoller wäre aber ein Ping des Rechners auf die 172.18.18.1 gewesen, sprich die OVPN IP des vServers !
Perfekt wäre zusätzlich ein Ping auf eine Pool OVPN Client IP gewesen wie z.B. die deines Tethering Notebooks 172.18.18.4. (Achte darauf das ICMP dort in der Windows Firewall erlaubt ist !! https://www.windowspro.de/wolfgang-sommergut/ping-windows-10-erlauben-gu ... )
Aber letztendlich ist es das nicht...

Ein Problem wurde im Eifer des Gefechts hier leider übersehen.
Der routende RasPi ist ja auch ein Client wie alle mobilen Clients auch. Die direkte Kommunikation von einem Client mit einem anderen Client ist aber im OpenVPN per Default deaktiviert so das aller Traffic immer zentral zum Server gesendet wird.
Das ist zu 99% der Grund warum der RasPi dann Traffic von den mobilen Clients über sich blockiert.
Das ist aber einfach und schnell zu fixen.
Füge der vServer OpenVPN Konfig das Kommando client-to-client hinzu und restarte den OpenVPN Prozess mit dem systemctl restart openvpn-server@server Kommando !!
Das sollte das Problem dann final fixen !

Ist hier auch auskommentiert zu sehen:
Merkzettel: VPN Installation mit OpenVPN

Sorry, Bild hab ich bereinigt.

Ping vom Notebook (192.168.1.104) im WLAN, ohne VPN-Verbindung:

C:\Users\juerg>ping 172.18.18.1

Ping wird ausgeführt für 172.18.18.1 mit 32 Bytes Daten:
Antwort von 172.18.18.1: Bytes=32 Zeit=84ms TTL=63
Antwort von 172.18.18.1: Bytes=32 Zeit=82ms TTL=63
Antwort von 172.18.18.1: Bytes=32 Zeit=94ms TTL=63
Antwort von 172.18.18.1: Bytes=32 Zeit=88ms TTL=63

Ping vom Notebook (192.168.1.104) im WLAN, ohne VPN-Verbindung ans Smartphone (per VPN verbunden):

C:\Users\juerg>ping 172.18.18.3

Ping wird ausgeführt für 172.18.18.3 mit 32 Bytes Daten:
Antwort von 172.18.18.3: Bytes=32 Zeit=216ms TTL=62
Antwort von 172.18.18.3: Bytes=32 Zeit=140ms TTL=62
Antwort von 172.18.18.3: Bytes=32 Zeit=199ms TTL=62
Antwort von 172.18.18.3: Bytes=32 Zeit=119ms TTL=62

Ping vom Notebook (192.168.1.104) im WLAN, ohne VPN-Verbindung ans Tablet (per VPN verbunden):

C:\Users\juerg>ping 172.18.18.2

Ping wird ausgeführt für 172.18.18.2 mit 32 Bytes Daten:
Antwort von 172.18.18.2: Bytes=32 Zeit=192ms TTL=62
Antwort von 172.18.18.2: Bytes=32 Zeit=173ms TTL=62
Antwort von 172.18.18.2: Bytes=32 Zeit=119ms TTL=62
Antwort von 172.18.18.2: Bytes=32 Zeit=647ms TTL=62

Das Kommando "client-to-client" habe ich drinnen und neu gestartet.

Es ändert aber an der Situation überhaupt nichts. Vom eingeloggten VPN-Client (über Mobilnetz) komme ich an meine lokalen Geräte nicht ran, außer die 192.168.1.1 (Router) und die 192.168.1.107 (RasPi im LAN). Am Windows 10 Client (192.168.1.104) habe ich die Pings durch die Firewall erlaubt, hat nichts geändert. Auch das deaktivieren der Firewall hat nichts gebracht, unveränderte Situation.

Allerdings etwas ist mir aufgefallen:

Wenn die Windows-Firewall AUSGESCHALTET ist, dann kann ich vom mobilen Client (Mobilfunk) einen Traceroute machen:

Wenn die Windows-Firewall EINGESCHALTET ist, dann kann ich vom mobilen Client (Mobilfunk) KEINEN Traceroute machen:

Die maximalen Hops hab ich auf 5 gekürzt, da es bei 30 (Standart in der App) sonst nicht auf den Screenshot gepaßt hätte.

Wenn die Windows-Firewall AUSGESCHALTET ist, dann kann ich vom mobilen Client (Mobilfunk) einen Traceroute machen:

Haben wir aber immer und immer wieder hier gepredigt das du die Winblows Firewall anpassen musst !!
Jeder Laie weiss doch mittlerweile das die alles was NICHT aus dem lokalen Netzwerk kommt blockiert.
ICMP Protokoll (Ping) ist generell immer blockiert !
Passe das an: https://www.windowspro.de/wolfgang-sommergut/ping-windows-10-erlauben-gu ...
und setze auch die Source und destination IPs auf Beliebig !

Genauso hab ich es auch gemacht, gem. https://www.windowspro.de/wolfgang-sommergut/ping-windows-10-erlauben-gu ...

Letztendlich ist aber (temporär) ausschalten genauso wirkungsvoll.

Es hakt irgendwo anders.

hackt ??
Das macht man doch eigentlich nur im Garten:
https://de.wikipedia.org/wiki/Hacke_(Werkzeug)
Oder meintest du es hakt irgendwo ?
https://www.duden.de/suchen/dudenonline/haken
Spaß beiseite....

Das zeigt dann aber doch ganz klar das deine Firewall nicht richtig customized ist !

Ja, aber selbst bei ausgeschalteter Firewall klappt es nicht.

Ganz zu schweigen von den anderen Netzwerkgeräten, bevorzugt meine Schaltmodule.

Bei einem "Sonoff Switch" und einem "Shelly 2.5" keine Reaktion auf einen PING, genauso wie der Win-Rechner.

Vom vServer (Gateway) aus getestet:

Wenn am Router die statische Route (172.18.18.0 / 255.255.255.0 / 192.168.1.107) AKTIVIERT ist:

root@tunnel:~# traceroute 192.168.1.111
traceroute to 192.168.1.111 (192.168.1.111), 30 hops max, 60 byte packets
 1  172.18.18.254 (172.18.18.254)  59.045 ms  60.815 ms  60.913 ms
 2  192.168.1.111 (192.168.1.111)  110.210 ms  117.479 ms  117.498 ms

Wenn am Router die statische Route (172.18.18.0 / 255.255.255.0 / 192.168.1.107) DEAKTIVIERTist:

root@tunnel:~# traceroute 192.168.1.111
traceroute to 192.168.1.111 (192.168.1.111), 30 hops max, 60 byte packets
172.18.18.254 (172.18.18.254)  64.720 ms  65.551 ms  65.576 ms
* * *
* * *
* * *
* * *
* * *
* * *
* * *
* * *
* * *
* * *
* * *
* * *
* * *
* * *
* * *
* * *
* * *
* * *
* * *
* * *
* * *
* * *
* * *
* * *
* * *
* * *
* * *
* * *
* * *

PING in keinem Fall möglich!

Das bedeutet doch für mein Verständnis:

Die statische Route funktioniert, aber könnte da nicht der Router schuld sein, dass er die VPN-Pakete einfach verwirft? Leider habe ich keinen anderen Router bei der Hand, mit dem ich das testen könnte. Welche Testmethoden hätte ich denn, WO das Problem liegt?

Ja, aber selbst bei ausgeschalteter Firewall klappt es nicht.

Dann widersprichst du dich jetzt aber selber und es wird etwas wirr: (Zitat):
"Wenn die Windows-Firewall AUSGESCHALTET ist, dann kann ich vom mobilen Client (Mobilfunk) einen Traceroute machen"
Ja was denn nun ? Mal geht es mal wieder nicht ?!

Wenn am Router die statische Route DEAKTIVIERTist:

Sorry aber den Blödsinn kannst du dir und uns doch ersparen. Denk mal selber etwas nach ! WIE sollte denn ohne diese statische Route die Ping Rückantwort von .1.111 dann funktionieren ?? .1.111 hat doch ganz sicher den Internet Router als Default Gateway und wenn du die .1.111 anpingst dann muss der Router doch wissen das er zum 172.18.18er Netz über die lokale Gateway IP 192.168.1.107 (RasPi) in das Netz gelangt.
Der Ping aus dem OVPN Netz wird vom Client (Laptop) mit einer 172.18.18er Absender IP gesendet. Der .4 wenns dein Laptop ist.
Das Paket was bei .1.111 ankommt hat also eine Absender IP 172.18.18.4 und eine Destination IP 192.168.1.111.
Das Ping Reply Paket von .1.111 hat dann als Absender folglich die 192.168.1.111 und als Destination die 172.18.18.4.
Der .1.111 Client sendet es aber, da es ein Fremdnetz ist, an den Internet Router, denn dort zeigt ja (hoffentlich ?!) sein Default Gateway hin...logisch.
Der Internet Router sieht dann in seine Routing Tabelle wo steht:

172.18.18.0 /24 Traffic an die 192.168.1.107 senden (statische OVPN Route)
Alles was er NICHT kennt an den Internet Provider senden (Default Route)

Wenn du ihm nun die erste Route löschst, dann sendet er das 172.18.18er Antwort Paket zum Provider und damit ins Nirwana.
Was sollte also das unsinnige Löschen dieser Route dann bringen ? Macht alles doch nur schlimmer...

Es wäre auch völlig unverständlich wenn ein Traceroute klappt ein Ping aber nicht, denn beide Tools nutzen immer ICMP.
Ausnahme du hast einen Apple Mac, denn der nutzt für Traceroute TCP statt ICMP.

Wie gesagt. Das Testsetup funktioniert hier mit exakt den gleichen Settings wie bei dir vollkommen fehlerlos ! Irgendwo muss also be dir der Wurm drin sein ?!

Nur mal dumm nachgefragt: Kann es sein das du irgendwelche unsinnigen iptable Firewall Regeln auf dem RasPi definiert hast ?
Was sagt ein iptables -S oder sudo iptables -S wenn du kein Root User bist ?
Oder ist das ein jungfräuliches Raspbian ?
Ansonsten bin ich mit meinem IP und OVPN Latein am Ende...

Es wäre auch völlig unverständlich wenn ein Traceroute klappt ein Ping aber nicht, denn beide Tools nutzen immer ICMP.

Ja, das denke ich mir auch und wundert mich auch etwas. Hier nochmal die Zusammenfassung:

VOM GATEWAY SERVER AUS:

Ping/Trace an den Router an Standort A:

ping 192.168.1.1 -c 3
PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data.
64 bytes from 192.168.1.1: icmp_seq=1 ttl=63 time=54.2 ms
64 bytes from 192.168.1.1: icmp_seq=2 ttl=63 time=307 ms
64 bytes from 192.168.1.1: icmp_seq=3 ttl=63 time=105 ms

traceroute 192.168.1.1
traceroute to 192.168.1.1 (192.168.1.1), 30 hops max, 60 byte packets
 1  172.18.18.254 (172.18.18.254)  50.431 ms  68.601 ms  70.479 ms
 2  192.168.1.1 (192.168.1.1)  70.526 ms  70.555 ms  70.545 ms

Ping/Trace an den RasPI an Standort A:

ping 192.168.1.107 -c 3
PING 192.168.1.107 (192.168.1.107) 56(84) bytes of data.
64 bytes from 192.168.1.107: icmp_seq=1 ttl=64 time=48.7 ms
64 bytes from 192.168.1.107: icmp_seq=2 ttl=64 time=87.0 ms
64 bytes from 192.168.1.107: icmp_seq=3 ttl=64 time=51.4 ms

traceroute 192.168.1.107
traceroute to 192.168.1.107 (192.168.1.107), 30 hops max, 60 byte packets
 1  192.168.1.107 (192.168.1.107)  49.667 ms  51.559 ms  56.693 ms

Ping/Trace an das Schaltmodul "Shelly 2.5" an Standort A:

 ping 192.168.1.108 -c 3
PING 192.168.1.108 (192.168.1.108) 56(84) bytes of data.

--- 192.168.1.108 ping statistics ---
3 packets transmitted, 0 received, 100% packet loss, time 1999ms

 traceroute 192.168.1.108
traceroute to 192.168.1.108 (192.168.1.108), 30 hops max, 60 byte packets
 1  172.18.18.254 (172.18.18.254)  133.909 ms  135.577 ms  135.591 ms
 2  192.168.1.108 (192.168.1.108)  135.597 ms  140.768 ms  140.774 ms

Ping/Trace an das Schaltmodul "Sonoff R2" an Standort A:

ping 192.168.1.111 -c 3
PING 192.168.1.111 (192.168.1.111) 56(84) bytes of data.

--- 192.168.1.111 ping statistics ---
3 packets transmitted, 0 received, 100% packet loss, time 2014ms

traceroute 192.168.1.111
traceroute to 192.168.1.111 (192.168.1.111), 30 hops max, 60 byte packets
 1  172.18.18.254 (172.18.18.254)  58.897 ms  60.806 ms  60.835 ms
 2  192.168.1.111 (192.168.1.111)  60.834 ms  60.866 ms  60.866 ms

VOM MOBILEN CLIENT (ANDROID SMARTPHONE per Mobilfunk) AUS:

Gleiches Verhalten wie vom vServer aus, was zu erwarten war.
Die Ausgabe poste ich nicht, damit es nicht unübersichtlich wird.

VOM MOBILEN CLIENT (ANDROID TABLET per Mobilfunk) AUS:

Gleiches Verhalten wie vom vServer aus, was zu erwarten war.
Die Ausgabe poste ich nicht, damit es nicht unübersichtlich wird.

MEINE VERMUTUNG: Der Router schmeißt mir die Datenpakete weg. Ich habe aber schon alles mögliche durchgeschaut in der Konfiguration (z.B. AP Client Isolation disabled, ICMP Block disabled, Router Firewall disabled, usw.). Ich werde jetzt dann noch ein wenig nachforschen, ob es hier eventuell einen Bug gibt, oder ich sonst wie Infos finde zu dem Thema - hat jemand ggf. noch Stichworte für eine professionelle Suche?

Ausnahme du hast einen Apple Mac, denn der nutzt für Traceroute TCP statt ICMP.

Nein, nie einen Mac oder sonst was von Apple besessen oder benutzt.

Was sagt ein iptables -S oder sudo iptables -S wenn du kein Root User bist ?

Am Raspi Client:

pi@raspberrypi:~ $ sudo iptables -S
-P INPUT ACCEPT
-P FORWARD ACCEPT
-P OUTPUT ACCEPT

Am Gateway Server:

root@tunnel:~# iptables -S
-P INPUT ACCEPT
-P FORWARD ACCEPT
-P OUTPUT ACCEPT

Wenn ich nicht ganz schief liefe, eigentlich alles OK...?

Oder ist das ein jungfräuliches Raspbian ?

Jein, es läuft ioBroker (Smart Home System) drauf. Aber es wurde sonst nicht viel dran verändert.

Ansonsten bin ich mit meinem IP und OVPN Latein am Ende...

Seufz... trotzdem ein riesengroßes Danke für deine Bemühungen.

Eventuell fällt dir ja noch was dazu ein? Oder jemand anderen?

Ping/Trace an das Schaltmodul "Shelly 2.5" an Standort A:

Da ein Ping an alle anderen Geräte im .1.1er Netz ja fehlerfrei funktioniert, nicht aber an diese Schaltdosen liegt der große verdacht nahe das diese scheinbar entweder kein Gateway konfiguriert haben oder kein Routing können.
Es ist ja offensichtlich das es immer nur diese Geräte sind. Mit allen anderen klappt es ja fehlerlos wenn man deine Ping und Traceroute Statistiken richtig interpretiert.
Mit anderen Worten: Alles rennt bis auf diese ominösen Schaltsteckdosen. Ggf. solltest du da also mal etwas genauer hinsehen.

Ich habe daraufhin das o.a. OVPN Testsetup nochmal etwas realistischer getestet mit umgeflashten Gosund SP1 und SP111 Dosen:
https://www.bastelbunker.de/gosund-sp1-mit-tasmota/
https://www.bastelbunker.de/gosund-sp111-mit-tasmota/
auf denen sich die aktuelle Tasmota Firmware befindet ud die im Zielnetz per WLAN angebunden sind. Also identisches Setup wie deins oben nur mit anderer IP Adressierung und andere Schaltdosen HW und Firmware.
Das Pingen, Tracerouten und auch der HTTP Browser Zugriff von mobilen OVPN Clients (iPad, MacBook und Windows Laptop) funktioniert mit ALLEN diesen Enderäten auf diese Gosund/Tasmota Schaltdosen völlig ohne irgendwelche Probleme.
Ich glaube ein Shelly-1 fliegt hier irgendwo auch noch in der Bastelkiste rum. Wenn ich den finde hänge ich den auch nochmal rein um ganz sicher zu gehen.
Fazit:
Das OVPN Design und Konfig von oben ist wasserdicht und fehlerfrei !

Ich fasse mal kurz zusammen:

Nicht nur diese Schaltmodule lassen sich nicht pingen, sondern GAR KEIN Gerät, außer 192.168.1.1 (Router) und 192.168.1.107 (Raspi Client). Genau das ist es, was mir mehr als komisch vor kommt. Notebook, Tablet, Smartphone, Schaltmodule, Drucker, usw. KEIN PING, aber TRACE erfolgreich.

So wie es aussieht, gebe ich erstmal auf und überlege mir eine andere Lösung. Eventuell besorge ich mir noch einen anderen Router, da ich dem TP-Link irgendwie nicht so recht über den Weg traue - eine Google Recherche brachte dazu jedoch keine Ergebnisse, ob es hier Probleme gibt oder nicht.

Genau das ist es, was mir mehr als komisch vor kommt. Notebook, Tablet, Smartphone, Schaltmodule, Drucker, usw. KEIN PING, aber TRACE erfolgreich.

Da stimmt irgendwas in dem lokalen .1.0er Netz grundsätzlich nicht ! Hört sich irgendwie nach falscher Subnetzmaske usw. an.
Da ist irgendwas oberfaul was NICHTS mit deinem OpenVPN Umfeld zu tun hat !
Das es auch hier mit den Tasmota Dosen sauber funktioniert spricht dafür das es im lokalen .1.0er Netz ein ganz anderes Problem gibt.
(Übrigens die Shelly-1 rennt hier auch fehlerlos mit OVPN von Remote !)

So wie es aussieht, gebe ich erstmal auf

Solltest du aber was den Fehler im .1.0er Netz anbetrifft nicht machen ! Das wird dich immer und immer wieder dann einholen !

Eventuell besorge ich mir noch einen anderen Router

Mikrotik ?!
Viel Erfolg weiderhin !

Da stimmt irgendwas in dem lokalen .1.0er Netz grundsätzlich nicht ! Hört sich irgendwie nach falscher Subnetzmaske usw. an.

Hmmm, ja nur bin ich mir keines Fehlers bewußt und intern läuft ja alles.
Ich arbeite schon immer mit 192.168.1.x und 255.255.255.0 zuhause.
Am zweiten Standort halt dann mit 192.168.2.x und 255.255.255.0, da ich OVPN schon im Kopf hatte.

(Übrigens die Shelly-1 rennt hier auch fehlerlos mit OVPN von Remote !)

Das freut mich zu lesen, dann habe ich ja noch Hoffnung.

Mikrotik ?!

Hatte ich mal, aber ob ich mich da drüber trauen soll. Hatte vor vielen Jahren im Büro mal einen Mikrotik und riesige Probleme damit, da dies wohl eher Profigeräte sind.

Hättest du eine persönliche Empfehlung für einen Mikrotik mit integriertem 4G/LTE-Modul (Cat 4 reicht mir), wenn es sowas gibt? Dual WLAN (2.4/5 GHz) ist ebenso nbedingt erforderlich, da ich 2.4 GHz Geräte auch im Betrieb habe.

Ich arbeite schon immer mit 192.168.1.x und 255.255.255.0 zuhause.

Keine wirklich intelligente Wahl wenn man mit VPNs arbeitet...

VPNs einrichten mit PPTP

Hatte ich mal, aber ob ich mich da drüber trauen soll.

Warum nicht ? Ein OpenVPN Server oder Client ist damit in 10 Minuten aufgesetzt ! Guckst du hier:
Clientverbindung OpenVPN Mikrotik

da dies wohl eher Profigeräte sind.

Nein, das ist nicht richtig. Auch mit Basis Kenntnissen kommt man mit den Teilen sehr gut klar:
Mikrotik VLAN Konfiguration ab RouterOS Version 6.41
Scheitern am IPsec VPN mit MikroTik
IPsec IKEv2 Standort VPN Vernetzung mit Cisco, pfSense OPNsense und Mikrotik
usw. usw.

für einen Mikrotik mit integriertem 4G/LTE-Modul (Cat 4 reicht mir),

Guckst du hier:
https://mikrotik.com/products/group/lte-products
SXT R oder wAP LTE ist die Hardware der Wahl.

https://mikrotik.com/products/group/lte-products
SXT R oder wAP LTE ist die Hardware der Wahl.

Ich schau mal, ob MikroTik doch was für mich ist, danke für die Tips.

Was hälst du von diesem Produkt?
https://www.gl-inet.com/products/gl-x750/

OpenWRT habe ich auch früher schon mal getestet.

Ich kenne den hier:
https://www.amazon.de/GL-iNet-GL-MT300N-V2-Repeater-Performance-Compatib ...
Das ist schon erstaunlich was die leisten. Aber OK, da werkelt OpenWRT im Hintergrund, der universale Tausendsassa der alles kann was das Netzwerker Herz begehrt !

So, ich habe den Provider (erfolgreich!) gewechselt und habe folgendes zu berichten. Eventuell hilft es ja jemanden, wenn er mit einer ähnlichen Situation zu kämpfen hat, denn "Spusu" ist als Anbieter echt eigenartig. Also:

Ich bin von "Spusu" (Anbieter in Österreich im Netz von Drei) zu "Yesss" (Anbieter in Österreich im Netz von A1) gewechselt. Nun habe ich zwei SIM-Karten, wo mir sofort jeweils eine "Public IP" geschaltet wurde.

Ohne etwas an den Router (TP-Link MR200) zu ändern habe ich eine VPN-Verbindung per IPsec zwischen meinen beiden Routern herstellen können. Dazu habe ich unter "VPN -> IPsec VPN" folgendes eingestellt:

Bei "Remote IPsec Gateway Gateway" habe ich meinen "DynDNS-Hostnamen" eingegeben.
Bei "Tunnel access from local IP addresses" die lokale IP des Routers.
Bei "Tunnel access from remote IP addresses" die IP des entfernten Routers.

Die beiden IP-Adressen beim anderen Router natürlich umdrehen und den DynDNS-Hostnamen auch entsprechend anpassen.

Fertig! Und schon kann ich von den Geräten im Netzwerk A auf die Geräte im Netzwerk B zugreifen bzw. auch umgekehrt. Da es hierbei nur um wenig Bandbreite geht (Messdaten bzw. Steuersignale) brauche ich auch nichts besonderes und ich finde diese Lösung durchaus für meinen Zweck ideal.

Mir ist klar, dass es eine einfache Lösung ist - aber für mich reicht es eigentlich, was spricht also dagegen.

Nachtrag noch zur mobilen Einwahl in meine Netzwerke:

Der "TP-Link MR200" hat auch OpenVPN an Board, natürlich sehr einfach gehalten. Das sieht dann so aus:

Somit kann ich mich mit meinen mobilen Geräten einloggen (geht eigentlich nur um mein eigenes Smartphone und ein Tablet). Andere Personen werden nie Zugriff haben, also reicht auch diese Lösung. Weiters geht es hier auch nicht um Geschwindigkeit oder Bandbreite, sondern auch hier wieder nur um Steuersignale und Messdaten.

FAZIT:

Für mich reicht die Lösung, ist einfach und sollte auch längerfristig laufen. Kein Herumgefummel, kein externer VPS, kein Gateway, usw. Für Profis mag es primitiv anmuten, das verstehe ich. Aber ich muss letztendlich zwischen Aufwand und Nutzen entscheiden.

Die richtige Entscheidung war: PROVIDERWECHSEL (siehe Beginn des vorigen Betrages!)

DANKE auf jeden Fall für die kompetente Hilfe und die Geduld mit mir!

Die richtige Entscheidung war: PROVIDERWECHSEL

Danke für das Feedback. Bestätigt die Empfehlung die wir hier ja in fast allen diesen (hartnäckigen) Fällen auch immer geben, da man nie weiss was diese Billig Wiederverkäufer ohne eigenens Netz so alles Treiben mit den Kundenrestriktionen. Leider ignorieren 95% aller Thread Ersteller das aber.
Klasse wenns nun alles ohne Frickelei rennt wie es soll !

Case closed !

Hallo @aqui,

erst einmal großes Lob an dich, dass du hier so tolle und umfangreiche Unterstützung leistest, echt klasse.

Ich habe einen ähnlichen Fall wie soundy.
Ich möchte mich von Zuhause aus (I-Tüppfelchen wäre auch von mobilen Clients) aus mit dem Netzwerk in meinem Garten verbinden und alle Netzwerkgeräte im Garten-Netzwerk ansprechen können.

Ich habe mir für den Garten daher einen LTE-Router (ASUS 4G-AC53U) beschafft der direkt als VPN-Client eine Verbindung aufbauen kann. Dieser sitzt ebenfalls hinter einem CG-NAT von o2, sodass ich mir auch einen VPS angemietet habe, um dies zu "umgehen".

Der OpenVPN-Server läuft auf dem VPS und die Clients können sich soweit auch mit ihm Verbinden, das geht soweit
(Ich nutze openvpn-install, um mir die Clients anzulegen).

server.conf:

local 173.212.xxx.xxx
port 1194
proto udp
dev tun
ca ca.crt
cert server.crt
key server.key
dh dh.pem
auth SHA512
tls-crypt tc.key
topology subnet
server 172.18.18.0 255.255.255.0
push "redirect-gateway def1 bypass-dhcp"  
ifconfig-pool-persist ipp.txt
push "dhcp-option DNS 213.136.95.10"  
push "dhcp-option DNS 213.136.95.11"  
keepalive 10 120
cipher AES-256-CBC
user nobody
group nogroup
persist-key
persist-tun
verb 3
crl-verify crl.pem
explicit-exit-notify
status /etc/openvpn/openvpn-status.log
status-version 3

openvpn-status.log:

TITLE   OpenVPN 2.5.1 x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] built on Apr 27 2021
TIME    2021-11-14 11:59:54     1636887594
HEADER  CLIENT_LIST     Common Name     Real Address    Virtual Address Virtual IPv6 Address    Bytes Received  Bytes Sent      Connected Since Connected Since (time_t)        Username        Client ID       Peer ID Data Channel Cipher
CLIENT_LIST     garten  46.114.38.222:37378     172.18.18.2             58042   5995    2021-11-14 11:48:35     1636886915      UNDEF   1       1       AES-256-GCM
CLIENT_LIST     STE_home        94.134.59.249:61808     172.18.18.3             43425   3916    2021-11-14 11:58:19     1636887499      UNDEF   2       0       AES-256-GCM
HEADER  ROUTING_TABLE   Virtual Address Common Name     Real Address    Last Ref        Last Ref (time_t)
ROUTING_TABLE   172.18.18.3     STE_home        94.134.59.249:61808     2021-11-14 11:59:52     1636887592
ROUTING_TABLE   172.18.18.2     garten  46.114.38.222:37378     2021-11-14 11:59:49     1636887589
GLOBAL_STATS    Max bcast/mcast queue length    0
END

client config garten.ovpn (Der ASUS Router) - Ich habe die certs stark eingekürzt:

client
dev tun
proto udp
remote 173.212.xxx.xxx 1194
resolv-retry infinite
nobind
persist-key
persist-tun
remote-cert-tls server
auth SHA512
cipher AES-256-CBC
ignore-unknown-option block-outside-dns
block-outside-dns
verb 3
<ca>
-----BEGIN CERTIFICATE-----
MIIDQjtefe
-----END CERTIFICATE-----
</ca>
<cert>
-----BEGIN CERTIFICATE-----
MIIDTfeef
-----END CERTIFICATE-----
</cert>
<key>
-----BEGIN PRIVATE KEY-----
MIrbrIEvg
-----END PRIVATE KEY-----
</key>
<tls-crypt>
-----BEGIN OpenVPN Static key V1-----
7brhrfb6f6
-----END OpenVPN Static key V1-----
</tls-crypt>

Systemprotokoll aus dem ASUS Router ( --> garten.ovpn):

Nov 14 11:48:33 kernel: _nvram_free: 541(httpds) nvram_idx(0 / 1)
Nov 14 11:48:33 rc_service: httpds 541:notify_rc restart_vpncall
Nov 14 11:48:35 vpnclient5[23068]: Unrecognized option or missing or extra parameter(s) in config.ovpn:44: block-outside-dns (2.4.7)
Nov 14 11:48:35 vpnclient5[23068]: OpenVPN 2.4.7 arm-unknown-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [MH/PKTINFO] [AEAD] built on Jul 29 2020
Nov 14 11:48:35 vpnclient5[23068]: library versions: OpenSSL 1.0.2u  20 Dec 2019, LZO 2.03
Nov 14 11:48:35 vpnclient5[23069]: NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
Nov 14 11:48:35 vpnclient5[23069]: Outgoing Control Channel Encryption: Cipher 'AES-256-CTR' initialized with 256 bit key  
Nov 14 11:48:35 vpnclient5[23069]: Outgoing Control Channel Encryption: Using 256 bit message hash 'SHA256' for HMAC authentication  
Nov 14 11:48:35 vpnclient5[23069]: Incoming Control Channel Encryption: Cipher 'AES-256-CTR' initialized with 256 bit key  
Nov 14 11:48:35 vpnclient5[23069]: Incoming Control Channel Encryption: Using 256 bit message hash 'SHA256' for HMAC authentication  
Nov 14 11:48:35 vpnclient5[23069]: TCP/UDP: Preserving recently used remote address: [AF_INET]173.212.xxx.xxx:1194
Nov 14 11:48:35 vpnclient5[23069]: Socket Buffers: R=[180224->180224] S=[180224->180224]
Nov 14 11:48:35 vpnclient5[23069]: UDP link local: (not bound)
Nov 14 11:48:35 vpnclient5[23069]: UDP link remote: [AF_INET]173.212.xxx.xxx:1194
Nov 14 11:48:35 vpnclient5[23069]: TLS: Initial packet from [AF_INET]173.212.xxx.xxx:1194, sid=05a735f4 243c9479
Nov 14 11:48:35 vpnclient5[23069]: VERIFY OK: depth=1, CN=ChangeMe
Nov 14 11:48:35 vpnclient5[23069]: VERIFY KU OK
Nov 14 11:48:35 vpnclient5[23069]: Validating certificate extended key usage
Nov 14 11:48:35 vpnclient5[23069]: ++ Certificate has EKU (str) TLS Web Server Authentication, expects TLS Web Server Authentication
Nov 14 11:48:35 vpnclient5[23069]: VERIFY EKU OK
Nov 14 11:48:35 vpnclient5[23069]: VERIFY OK: depth=0, CN=server
Nov 14 11:48:36 vpnclient5[23069]: Control Channel: TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 2048 bit RSA
Nov 14 11:48:36 vpnclient5[23069]: [server] Peer Connection Initiated with [AF_INET]173.212.xxx.xxx:1194
Nov 14 11:48:37 vpnclient5[23069]: SENT CONTROL [server]: 'PUSH_REQUEST' (status=1)  
Nov 14 11:48:37 vpnclient5[23069]: PUSH: Received control message: 'PUSH_REPLY,redirect-gateway def1 bypass-dhcp,dhcp-option DNS 213.136.95.10,dhcp-option DNS 213.136.95.11,route-gateway 172.18.18.1,topology subnet,ping 10,ping-restart 120,ifconfig 172.18.18.2 255.255.255.0,peer-id 1,cipher AES-256-GCM'  
Nov 14 11:48:37 vpnclient5[23069]: OPTIONS IMPORT: timers and/or timeouts modified
Nov 14 11:48:37 vpnclient5[23069]: OPTIONS IMPORT: --ifconfig/up options modified
Nov 14 11:48:37 vpnclient5[23069]: OPTIONS IMPORT: route options modified
Nov 14 11:48:37 vpnclient5[23069]: OPTIONS IMPORT: route-related options modified
Nov 14 11:48:37 vpnclient5[23069]: OPTIONS IMPORT: --ip-win32 and/or --dhcp-option options modified
Nov 14 11:48:37 vpnclient5[23069]: OPTIONS IMPORT: peer-id set
Nov 14 11:48:37 vpnclient5[23069]: OPTIONS IMPORT: adjusting link_mtu to 1624
Nov 14 11:48:37 vpnclient5[23069]: OPTIONS IMPORT: data channel crypto options modified
Nov 14 11:48:37 vpnclient5[23069]: Data Channel: using negotiated cipher 'AES-256-GCM'  
Nov 14 11:48:37 vpnclient5[23069]: Outgoing Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key  
Nov 14 11:48:37 vpnclient5[23069]: Incoming Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key  
Nov 14 11:48:37 vpnclient5[23069]: TUN/TAP device tun15 opened
Nov 14 11:48:37 vpnclient5[23069]: TUN/TAP TX queue length set to 100
Nov 14 11:48:37 vpnclient5[23069]: /sbin/ifconfig tun15 172.18.18.2 netmask 255.255.255.0 mtu 1500 broadcast 172.18.18.255
Nov 14 11:48:37 vpnclient5[23069]: /etc/openvpn/ovpn-up tun15 1500 1552 172.18.18.2 255.255.255.0 init
Nov 14 11:48:38 vpnclient5[23069]: WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this
Nov 14 11:48:38 vpnclient5[23069]: Initialization Sequence Completed

Soweit so "gut"

Sobald ich jetzt aber im OpenVPN-Server die drei Zeilen:

client-to-client
push "route 192.168.111.0 255.255.255.0"  
route 192.168.111.0 255.255.255.0

hinterlege:

local 173.212.xxx.xxx
port 1194
proto udp
dev tun
ca ca.crt
cert server.crt
key server.key
dh dh.pem
auth SHA512
tls-crypt tc.key
topology subnet
server 172.18.18.0 255.255.255.0
push "redirect-gateway def1 bypass-dhcp"  
ifconfig-pool-persist ipp.txt
push "dhcp-option DNS 213.136.95.10"  
push "dhcp-option DNS 213.136.95.11"  
keepalive 10 120
cipher AES-256-CBC
user nobody
group nogroup
persist-key
persist-tun
verb 3
crl-verify crl.pem
explicit-exit-notify
status /etc/openvpn/openvpn-status.log
status-version 3
client-to-client
push "route 192.168.111.0 255.255.255.0"  
route 192.168.111.0 255.255.255.0

Bekomme ich einen IP-Konflikt:

Client Systemprotokoll aus dem ASUS-Router (garten.ovpn):

Nov 14 12:20:02 kernel: _nvram_free: 541(httpds) nvram_idx(0 / 1)
Nov 14 12:20:02 rc_service: httpds 541:notify_rc restart_vpncall
Nov 14 12:20:04 vpnclient5[7758]: Unrecognized option or missing or extra parameter(s) in config.ovpn:44: block-outside-dns (2.4.7)
Nov 14 12:20:04 vpnclient5[7758]: OpenVPN 2.4.7 arm-unknown-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [MH/PKTINFO] [AEAD] built on Jul 29 2020
Nov 14 12:20:04 vpnclient5[7758]: library versions: OpenSSL 1.0.2u  20 Dec 2019, LZO 2.03
Nov 14 12:20:04 vpnclient5[7759]: NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
Nov 14 12:20:04 vpnclient5[7759]: Outgoing Control Channel Encryption: Cipher 'AES-256-CTR' initialized with 256 bit key  
Nov 14 12:20:04 vpnclient5[7759]: Outgoing Control Channel Encryption: Using 256 bit message hash 'SHA256' for HMAC authentication  
Nov 14 12:20:04 vpnclient5[7759]: Incoming Control Channel Encryption: Cipher 'AES-256-CTR' initialized with 256 bit key  
Nov 14 12:20:04 vpnclient5[7759]: Incoming Control Channel Encryption: Using 256 bit message hash 'SHA256' for HMAC authentication  
Nov 14 12:20:04 vpnclient5[7759]: TCP/UDP: Preserving recently used remote address: [AF_INET]173.212.xxx.xxx:1194
Nov 14 12:20:04 vpnclient5[7759]: Socket Buffers: R=[180224->180224] S=[180224->180224]
Nov 14 12:20:04 vpnclient5[7759]: UDP link local: (not bound)
Nov 14 12:20:04 vpnclient5[7759]: UDP link remote: [AF_INET]173.212.xxx.xxx:1194
Nov 14 12:20:05 vpnclient5[7759]: TLS: Initial packet from [AF_INET]173.212.xxx.xxx:1194, sid=ae66f026 8bd0689e
Nov 14 12:20:05 vpnclient5[7759]: VERIFY OK: depth=1, CN=ChangeMe
Nov 14 12:20:05 vpnclient5[7759]: VERIFY KU OK
Nov 14 12:20:05 vpnclient5[7759]: Validating certificate extended key usage
Nov 14 12:20:05 vpnclient5[7759]: ++ Certificate has EKU (str) TLS Web Server Authentication, expects TLS Web Server Authentication
Nov 14 12:20:05 vpnclient5[7759]: VERIFY EKU OK
Nov 14 12:20:05 vpnclient5[7759]: VERIFY OK: depth=0, CN=server
Nov 14 12:20:05 vpnclient5[7759]: Control Channel: TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 2048 bit RSA
Nov 14 12:20:05 vpnclient5[7759]: [server] Peer Connection Initiated with [AF_INET]173.212.xxx.xxx:1194
Nov 14 12:20:06 vpnclient5[7759]: SENT CONTROL [server]: 'PUSH_REQUEST' (status=1)  
Nov 14 12:20:06 vpnclient5[7759]: PUSH: Received control message: 'PUSH_REPLY,redirect-gateway def1 bypass-dhcp,dhcp-option DNS 213.136.95.10,dhcp-option DNS 213.136.95.11,route 192.168.111.0 255.255.255.0,route-gateway 172.18.18.1,topology subnet,ping 10,ping-restart 120,ifconfig 172.18.18.2 255.255.255.0,peer-id 1,cipher AES-256-GCM'  
Nov 14 12:20:06 vpnclient5[7759]: OPTIONS IMPORT: timers and/or timeouts modified
Nov 14 12:20:06 vpnclient5[7759]: OPTIONS IMPORT: --ifconfig/up options modified
Nov 14 12:20:06 vpnclient5[7759]: OPTIONS IMPORT: route options modified
Nov 14 12:20:06 vpnclient5[7759]: OPTIONS IMPORT: route-related options modified
Nov 14 12:20:06 vpnclient5[7759]: OPTIONS IMPORT: --ip-win32 and/or --dhcp-option options modified
Nov 14 12:20:06 vpnclient5[7759]: OPTIONS IMPORT: peer-id set
Nov 14 12:20:06 vpnclient5[7759]: OPTIONS IMPORT: adjusting link_mtu to 1624
Nov 14 12:20:06 vpnclient5[7759]: OPTIONS IMPORT: data channel crypto options modified
Nov 14 12:20:06 vpnclient5[7759]: Data Channel: using negotiated cipher 'AES-256-GCM'  
Nov 14 12:20:06 vpnclient5[7759]: Outgoing Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key  
Nov 14 12:20:06 vpnclient5[7759]: Incoming Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key  
Nov 14 12:20:06 vpnclient5[7759]: TUN/TAP device tun15 opened
Nov 14 12:20:06 vpnclient5[7759]: TUN/TAP TX queue length set to 100
Nov 14 12:20:06 vpnclient5[7759]: /sbin/ifconfig tun15 172.18.18.2 netmask 255.255.255.0 mtu 1500 broadcast 172.18.18.255
Nov 14 12:20:06 vpnclient5[7759]: /etc/openvpn/ovpn-up tun15 1500 1552 172.18.18.2 255.255.255.0 init
Nov 14 12:20:07 vpnclient5: WARNING: Ignore conflicted routing rule: 192.168.111.0 255.255.255.0 gw 172.18.18.1
Nov 14 12:20:07 vpnclient5[7759]: WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this
Nov 14 12:20:07 vpnclient5[7759]: Initialization Sequence Completed

Achtung: Ich habe bisher noch keine statische Route im ASUS Router hinterlegt, da ich mir an dieser Stelle nicht sicher bin wie die auszusehen hat, da ich statt einem Raspi hinter dem Router direkt den Router als VPN-Client nutze. Hierzu könnte ich deine Unterstützung gebrauchen. Bitte reiß mir nicht den Kopf ab, bin kein Profi

.

Was mache ich sonst noch falsch?

Grüße,
canjuma

Einen entsprechenden Thread der so ein Jumphost Setup genau beschreibt und auch die Fussfallen die es zu vermeiden geht ist dieser:
Wie Portforwarding über 2 miteinander verbundenen pfSense realisieren

Hast du das alles gelesen und entsprechend beachtet in deinem Setup ?

Sobald ich jetzt aber im OpenVPN-Server die drei Zeilen:

Das geht so logischerweise nicht mit diesen beiden Kommandos zumal es sich um das gleiche Netz handelt, was falsch ist !
Bei einem Site to Site Setup gilt das hier:
OpenVPN - Erreiche Netzwerk hinter Client nicht
Dort steht auch wie diese Routing Kommandos richtig anzuwenden sind bei Server und Client !

gelöst Frage Netzwerke LAN, WAN, Wireless

Heiß diskutiert