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
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/contentid/583638
Ausgedruckt am: 21.11.2024 um 13:11 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.
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.
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.
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 !
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...?!
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...?!
Und hier kommt die richtige Lösung, wasserdicht getestet.
RasPi hat den COMMON Name: "client02" deshalb Konfig Datei in /etc/openvpn/server/clientconf
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:
Tunnel Interface und Routing Tabelle:
Routing Tabelle mobiler Client:
RasPi Client auf vServer Tunnel Interface:
Mobiler Client auf FritzBox LAN Interface:
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
Inhaltsverzeichnis
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
ifconfig-push 172.18.18.254 255.255.255.0
iroute 192.168.188.0 255.255.255.0
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
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
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
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
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
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 !
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 !
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 !
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 !
Das Fazit ist ja eindeutig:
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 !
- 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 !
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.
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...!
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...
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
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
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 !
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 !
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.
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)
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...
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 !
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 !
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.
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 !
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 !
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:
openvpn-status.log:
client config garten.ovpn (Der ASUS Router) - Ich habe die certs stark eingekürzt:
Systemprotokoll aus dem ASUS Router ( --> garten.ovpn):
Soweit so "gut"
Sobald ich jetzt aber im OpenVPN-Server die drei Zeilen:
hinterlege:
Bekomme ich einen IP-Konflikt:
Client Systemprotokoll aus dem ASUS-Router (garten.ovpn):
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
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 ?
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 !
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 !