Top-Themen

Aktuelle Themen (A bis Z)

Administrator.de FeedbackApache ServerAppleAssemblerAudioAusbildungAuslandBackupBasicBatch & ShellBenchmarksBibliotheken & ToolkitsBlogsCloud-DiensteClusterCMSCPU, RAM, MainboardsCSSC und C++DatenbankenDatenschutzDebianDigitiales FernsehenDNSDrucker und ScannerDSL, VDSLE-BooksE-BusinessE-MailEntwicklungErkennung und -AbwehrExchange ServerFestplatten, SSD, RaidFirewallFlatratesGoogle AndroidGrafikGrafikkarten & MonitoreGroupwareHardwareHosting & HousingHTMLHumor (lol)Hyper-VIconsIDE & EditorenInformationsdiensteInstallationInstant MessagingInternetInternet DomäneniOSISDN & AnaloganschlüsseiTunesJavaJavaScriptKiXtartKVMLAN, WAN, WirelessLinuxLinux DesktopLinux NetzwerkLinux ToolsLinux UserverwaltungLizenzierungMac OS XMicrosoftMicrosoft OfficeMikroTik RouterOSMonitoringMultimediaMultimedia & ZubehörNetzwerkeNetzwerkgrundlagenNetzwerkmanagementNetzwerkprotokolleNotebook & ZubehörNovell NetwareOff TopicOpenOffice, LibreOfficeOutlook & MailPapierkorbPascal und DelphiPeripheriegerätePerlPHPPythonRechtliche FragenRedHat, CentOS, FedoraRouter & RoutingSambaSAN, NAS, DASSchriftartenSchulung & TrainingSEOServerServer-HardwareSicherheitSicherheits-ToolsSicherheitsgrundlagenSolarisSonstige SystemeSoziale NetzwerkeSpeicherkartenStudentenjobs & PraktikumSuche ProjektpartnerSuseSwitche und HubsTipps & TricksTK-Netze & GeräteUbuntuUMTS, EDGE & GPRSUtilitiesVB for ApplicationsVerschlüsselung & ZertifikateVideo & StreamingViren und TrojanerVirtualisierungVisual StudioVmwareVoice over IPWünsch Dir wasWebbrowserWebentwicklungWeiterbildungWindows 7Windows 8Windows 10Windows InstallationWindows MobileWindows NetzwerkWindows ServerWindows SystemdateienWindows ToolsWindows UpdateWindows UserverwaltungWindows VistaWindows XPXenserverXMLZusammenarbeit

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

Mitglied: soundy

soundy (Level 1) - Jetzt verbinden

02.07.2020 um 02:01 Uhr, 687 Aufrufe, 37 Kommentare

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
37 Antworten
Mitglied: aqui
02.07.2020, aktualisiert um 09:25 Uhr
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.
Bitte warten ..
Mitglied: goscho
02.07.2020 um 10:15 Uhr
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.
Bitte warten ..
Mitglied: soundy
04.07.2020 um 21:48 Uhr
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:

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):

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):

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:

  1. Route zum Heimnetz auf dem Host-System des OpenVPN-Servers anlegen
route 192.168.1.0 255.255.255.0

  1. 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
Bitte warten ..
Mitglied: aqui
05.07.2020, aktualisiert um 16:35 Uhr
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:
https://administrator.de/content/detail.php?id=530283&token=984#comm ...
Lesen und verstehen...dann klappt das auch sofort mit den RasPis !
Bitte warten ..
Mitglied: soundy
09.07.2020, aktualisiert um 02:02 Uhr
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:
https://administrator.de/content/detail.php?id=530283&token=984#comm ...

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....
Bitte warten ..
Mitglied: aqui
09.07.2020 um 14:31 Uhr
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...?!
Bitte warten ..
Mitglied: soundy
09.07.2020 um 23:08 Uhr
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*.
Bitte warten ..
Mitglied: aqui
10.07.2020, aktualisiert um 10:34 Uhr
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...?!
Bitte warten ..
Mitglied: soundy
11.07.2020, aktualisiert um 02:13 Uhr
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

/etc/openvpn/client/raspi1:

/etc/openvpn/client/tablet:



Raspberry PI am Standort A (IP: 192.168.1.107)

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

/etc/openvpn/client.conf:



Android Tablet (per Mobilfunk 4G/LTE):

client.conf:



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 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:



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!
Bitte warten ..
Mitglied: aqui
11.07.2020, aktualisiert 16.07.2020
Und hier kommt die richtige Lösung, wasserdicht getestet.

ovpnvsrv - Klicke auf das Bild, um es zu vergrößern

Konfig vServer (OpenVPN Server):

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:

Konfig RasPi(OpenVPN Client):

Tunnel Interface und Routing Tabelle:

Konfig mobiler Client (Windows Laptop mit 4G Stick):

Routing Tabelle mobiler Client:

Finaler Ping Check:

vServer auf FritzBox LAN Interface:
RasPi Client auf vServer Tunnel Interface:
Mobiler Client auf FritzBox LAN Interface:

Fazit:

Works as designed !!!

So, nun bist du wieder dran !
Bitte warten ..
Mitglied: soundy
16.07.2020, aktualisiert um 02:08 Uhr
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):


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:

client.conf:

ccd-datei:


Mobile Clients (als Beispiel):

client.conf:

ccd-datei:



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*
Bitte warten ..
Mitglied: aqui
16.07.2020, aktualisiert um 10:15 Uhr
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 !
henet - Klicke auf das Bild, um es zu vergrößern

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 !
Bitte warten ..
Mitglied: soundy
16.07.2020 um 14:24 Uhr
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:

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):

screenshot_20200716-134842_network tools - Klicke auf das Bild, um es zu vergrößern
Bitte warten ..
Mitglied: aqui
16.07.2020, aktualisiert um 20:19 Uhr
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 !
Bitte warten ..
Mitglied: soundy
17.07.2020 um 01:34 Uhr
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.

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

(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




NOTEBOOK PER USB-TETHERING



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.



LOGFILE DER VERBINDUNG AM NOTEBOOK PER USB-TETHERING



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.
Bitte warten ..
Mitglied: aqui
17.07.2020, aktualisiert um 08:54 Uhr
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:
img_0180 - Klicke auf das Bild, um es zu vergrößern
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 !
Bitte warten ..
Mitglied: soundy
18.07.2020, aktualisiert um 02:41 Uhr
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:

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*
Bitte warten ..
Mitglied: aqui
18.07.2020, aktualisiert um 12:22 Uhr
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...!
Bitte warten ..
Mitglied: soundy
18.07.2020, aktualisiert um 20:13 Uhr
Also nach deiner Beschreibung scheint so einiges (alles?) richtig zu sein:

Die statische Route im Router (192.168.1.1):

static_route - Klicke auf das Bild, um es zu vergrößern



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):

Und noch ein Traceroute:



IP-Forwarding auf dem RasPi:

IP-Forwarding auf dem vServer:



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



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



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



Ping vom vServer (Gateway) auf das Schaltmodul:

Keine Ausgabe, gar nichts... Auch kein Zugriff auf das Webinterface, eh klar.
Bitte warten ..
Mitglied: aqui
18.07.2020, aktualisiert um 20:10 Uhr
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:
https://administrator.de/wissen/merkzettel-vpn-installation-openvpn-5610 ...
Bitte warten ..
Mitglied: soundy
18.07.2020, aktualisiert um 21:00 Uhr
Sorry, Bild hab ich bereinigt.

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

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

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



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:

screenshot_20200718-205147_pingtools - Klicke auf das Bild, um es zu vergrößern

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

screenshot_20200718-205424_pingtools - Klicke auf das Bild, um es zu vergrößern

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.
Bitte warten ..
Mitglied: aqui
18.07.2020 um 21:03 Uhr
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 !
icmp-firewall - Klicke auf das Bild, um es zu vergrößern
Bitte warten ..
Mitglied: soundy
18.07.2020, aktualisiert um 21:10 Uhr
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.
Bitte warten ..
Mitglied: aqui
18.07.2020, aktualisiert um 21:11 Uhr
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 !
Bitte warten ..
Mitglied: soundy
18.07.2020, aktualisiert um 21:19 Uhr
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:

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


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?
Bitte warten ..
Mitglied: aqui
19.07.2020, aktualisiert um 13:33 Uhr
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...
Bitte warten ..
Mitglied: soundy
19.07.2020 um 23:46 Uhr
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/Trace an den RasPI an Standort A:

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

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


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:

Am Gateway Server:

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?
Bitte warten ..
Mitglied: aqui
20.07.2020, aktualisiert um 10:03 Uhr
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 !
Bitte warten ..
Mitglied: soundy
21.07.2020 um 00:19 Uhr
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.
Bitte warten ..
Mitglied: aqui
21.07.2020, aktualisiert um 09:15 Uhr
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 !
Bitte warten ..
Mitglied: soundy
21.07.2020 um 17:14 Uhr
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.
Bitte warten ..
Mitglied: aqui
22.07.2020 um 09:57 Uhr
Ich arbeite schon immer mit 192.168.1.x und 255.255.255.0 zuhause.
Keine wirklich intelligente Wahl wenn man mit VPNs arbeitet...
https://administrator.de/wissen/vpns-einrichten-pptp-117700.html#toc-7
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:
https://administrator.de/content/detail.php?id=359367&token=695#comm ...
da dies wohl eher Profigeräte sind.
Nein, das ist nicht richtig. Auch mit Basis Kenntnissen kommt man mit den Teilen sehr gut klar:
https://administrator.de/wissen/mikrotik-vlan-konfiguration-routeros-ver ...
https://administrator.de/content/detail.php?id=562927&token=111#comm ...
https://administrator.de/wissen/ipsec-ikev2-standort-vpn-vernetzung-cisc ...
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.
Bitte warten ..
Mitglied: soundy
22.07.2020 um 22:36 Uhr
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.
Bitte warten ..
Mitglied: aqui
22.07.2020 um 22:43 Uhr
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 !
Bitte warten ..
Mitglied: soundy
30.07.2020, aktualisiert 31.07.2020
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:

mr200_1 - Klicke auf das Bild, um es zu vergrößern

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.
Bitte warten ..
Mitglied: soundy
31.07.2020, aktualisiert um 00:01 Uhr
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:

mr200_2 - Klicke auf das Bild, um es zu vergrößern

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!
Bitte warten ..
Mitglied: aqui
31.07.2020 um 09:50 Uhr
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 !
Bitte warten ..
Ähnliche Inhalte
Netzwerkgrundlagen

VPN Tunnel zum VPS für RDP und VPS über VPN

Frage von BlackMatrixNetzwerkgrundlagen21 Kommentare

Hallo, zugegeben ich bin noch nicht die Leuchte was Netzwerktechnik angeht, aber ich würde gerne meinen Windows-Server (VPS) besser ...

Router & Routing

TP-Link Router VPN Verbindung Router Oberfläche nicht erreichbar

Frage von D46505PlRouter & Routing6 Kommentare

Hallo Zusammen, ich habe 2x TP Link VR200 vDSL Router an 2 verschiedenen Standorten. Beide Netzwerke sind über ein ...

Netzwerke

TP-Link zwei VLANs auf ein Port

gelöst Frage von matze2090Netzwerke8 Kommentare

Hallo, ich bin gerade noch in der Ausbildung und möchte zu Hause zum testen und für Gäaste ein VLAN ...

Router & Routing

VPN mit alternativem Gateway

Frage von niLuxxRouter & Routing5 Kommentare

Hallo zusammen, Ich möchte euch kurz eine Frage zum Thema VPN stellen. Ist es möglich bei bestehendem VPN den ...

Neue Wissensbeiträge
Humor (lol)

Wie verhindere ich, dass Websitebesucher die Werbecookies abschalten?

Information von DerWoWusste vor 1 TagHumor (lol)6 Kommentare

Ich habe gerade auf die Antwort gefunden: ich täusche einen langwierigen Änderungsprozess vor und biete nebenbei einen Cancelbutton, den ...

Sicherheit

Windows Setup erlaubt elevation of privilege plus DC Updates

Information von DerWoWusste vor 1 TagSicherheit3 Kommentare

Eine interessante neue Sicherheitslücke. Details gibt es wenig, aber die klare Empfehlung: If you are using WSUS or MEM ...

Exchange Server

Exchange Server 2016 and the End of Mainstream Support

Information von Dani vor 2 TagenExchange Server

As hopefully many of you already know Exchange Server 2016 enters the Extended Support phase of its product lifecycle ...

Viren und Trojaner

Schwachstelle in Teamviewer oder aufgeflogene Backdoor?

Information von magicteddy vor 2 TagenViren und Trojaner1 Kommentar

Moin, die Interpretation überlasse ich jedem selber, ich habe eine deutliche Abneigung dagegen. Wer es nutzen muss sollte schleunigst ...

Heiß diskutierte Inhalte
Windows Server
Windows Server "mit" oder "ohne" Antivirensoftware
gelöst Frage von Dr.MabuseWindows Server23 Kommentare

Antiviren-Software: Fluch oder Segen? Die Frage der Sinnhaftigkeit von Antiviren-Software ist nicht neu Die Software kostet Performance, sorgt oft ...

Windows Server
Patchday August Server 2019 - zerstört Hyper V Dienste
Frage von ichkriegediekrieseWindows Server19 Kommentare

Guten Morgen alle zusammen Gestern habe ich, wie oft die Sicherheitsupdates vom Patchday eingespielt da ja doch einige Sicherheitsupdates ...

Hardware
Azubi Projekt - Serverhardware
Frage von nachgefragtHardware19 Kommentare

Hallo Administratoren, für ein Azubi-Projekt benötige ich euren Rat, um ihr das Thema Serverhardware näher zu bringen: Server zusammenbauen ...

iOS
Facetime Nummer
gelöst Frage von ral9004iOS15 Kommentare

Hallo Ein Kollege bat mich, ihm für den Videochat meine Facetime Nummer zu mailen. Meine Facetime App läuft auf ...

Administrator Magazin
08 | 2020 Cloud-First-Strategien sind inzwischen die Regel und nicht mehr die Ausnahme und Workloads verlagern sich damit in die Cloud – auch Datenbanken. Dort geht es aber nicht nur um die Frage, wie die Datenbestände in die Wolke zu migrieren sind, sondern auch darum, welche Datenbank ...