22
IPSec Verbindung zwischen zwei Mikrotik-Routern - 1x Server, einmal hinter NAT
Hallo zusammen,
ich versuche seit Tagen eine funktionierende VPN Verbindung aufzubauen, bin bereits an Wireguard gescheitert und habe es jetzt mit IPSec versucht.
Bei Wireguard musste ich alle paar Tage den Port ändern.
Ich habe mich jetzt etwas mit den Themen beschäftigt, bin aber sicher noch Anfänger, auch wenn ich schon etliche Anleitung durchgelesen und Videos angeschaut habe. Ich hatte auf die Hilfe von ChatGPT gehofft, aber das ist auch mit seinem Latein am Ende
Vielleicht könnt Ihr mir weiterhelfen?
Folgende Situation, ich habe ein Gerät, das eine Netzwerkverbindung nach China benötigt (Staubsaugerroboter) damit es funktioniert.
Dazu habe ich bei Alibabacloud einen ECS-Server gemietet und auf diesem RouterOS installiert.
Der Mikrotik Router hier sitzt hinter einer Fritzbox, die die Verbindung zur Telekom herstellt.
Hier eine Zeichnung wie es aussieht:
Ich habe es versucht nach dieser Anleitung einzurichten, leider funktioniert die Verbindung nicht.
[content:564730]
Folgendes habe ich in der Fritzbox für den Mikrotik Router freigegeben:
Zusätzlich diese Route angelegt:
Das sind die Einstellungen die ich auf dem Mikrotik-Router hinter der Fritzbox getätigt habe:
Und hier noch die Einstellungen des Mikrotik RouterOS auf dem Server, die Ports 4500 und 500 habe ich dort im Server freigegeben.
Openvpn hab ich auch nicht zum laufen bekommen.
Für den Profi ist es vielleicht ganz offensichtlich, was ich falsch mache, aber ich komme nicht weiter.
Hat jemand einen Tipp für mich?
Vielen lieben Dank & ein schönes Wochenende!
ich versuche seit Tagen eine funktionierende VPN Verbindung aufzubauen, bin bereits an Wireguard gescheitert und habe es jetzt mit IPSec versucht.
Bei Wireguard musste ich alle paar Tage den Port ändern.
Ich habe mich jetzt etwas mit den Themen beschäftigt, bin aber sicher noch Anfänger, auch wenn ich schon etliche Anleitung durchgelesen und Videos angeschaut habe. Ich hatte auf die Hilfe von ChatGPT gehofft, aber das ist auch mit seinem Latein am Ende
Vielleicht könnt Ihr mir weiterhelfen?
Folgende Situation, ich habe ein Gerät, das eine Netzwerkverbindung nach China benötigt (Staubsaugerroboter) damit es funktioniert.
Dazu habe ich bei Alibabacloud einen ECS-Server gemietet und auf diesem RouterOS installiert.
Der Mikrotik Router hier sitzt hinter einer Fritzbox, die die Verbindung zur Telekom herstellt.
Hier eine Zeichnung wie es aussieht:
Ich habe es versucht nach dieser Anleitung einzurichten, leider funktioniert die Verbindung nicht.
[content:564730]
Folgendes habe ich in der Fritzbox für den Mikrotik Router freigegeben:
Zusätzlich diese Route angelegt:
Das sind die Einstellungen die ich auf dem Mikrotik-Router hinter der Fritzbox getätigt habe:
Und hier noch die Einstellungen des Mikrotik RouterOS auf dem Server, die Ports 4500 und 500 habe ich dort im Server freigegeben.
Openvpn hab ich auch nicht zum laufen bekommen.
Für den Profi ist es vielleicht ganz offensichtlich, was ich falsch mache, aber ich komme nicht weiter.
Hat jemand einen Tipp für mich?
Vielen lieben Dank & ein schönes Wochenende!
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 670780
Url: https://administrator.de/forum/ipsec-verbindung-zwischen-zwei-mikrotik-routern-1x-server-einmal-hinter-nat-670780.html
Ausgedruckt am: 22.02.2025 um 06:02 Uhr
22 Kommentare
Neuester Kommentar
Gibt es einen triftigen Grund den Mikrotik nicht direkt auf der Fritzbox (links) per IPsec terminieren zu lassen? 🤔
Das wäre doch die ITtechnisch sinnvollste Lösung auf der VPN Responder Seite (oben vermutlich links?) und erspart dir ein Kaskaden Setup und ein eigentlich überflüssiges und stromfressendes Gerät.
Fritz!Box VPN Mikrotik als VPN Client
Oder ist das Szenario oben jetzt falsch verstanden weil du leider nicht gekennzeichnet hast WER VPN Initiator und wer Responder ist.
Zudem ist dein IPsec Port Forwarding an der Fritte die den VPN Responder in Kaskade hat falsch!
Wie man es bei IPsec richtig macht ist HIER im Kaskaden Tutorial beschrieben.
Beachte bei der Fritzbox das diese selber keinerlei IPsec bezogene Konfigs oder auch IPsec User Definition haben darf ansonsten macht sie als aktiver VPN Router KEIN Port Forwarding für IPsec egal ob dies definiert ist.
Wenn, würde es so aussehen:
Bei China solltest du ebenso immer im Hinterkopf haben das alle gängigen VPN Ports ins Ausland bekanntlich durch die große Firewall in der Regel blockiert werden.
Ob dem so ist kannst du mit einem Packet Sniffer wie Wireshark oder dem Mikrotik internen "Torch" selber checken ob von dort (Initiator) überhaupt UDP 500 oder UDP 4500 Pakete auf der VPN Responder Seite ankommen!
Wenn du dennoch eine MT zu MT Kopplung bevorzugst wäre es noch wichtig zu erfahren ob du mit IKEv1 oder mit dem moderneren IKEv2 arbeitest?
Einen grundsätzlichen Überblick über praxisbezogene VPN Setups zeigt dir das Mikrotik Tutorial:
VPNs mit Mikrotik
Auch mit dem Mikrotik als Wireguard Client (Initiator) der auf eine Fritzbox (Wireguard Responder) arbeitet ist ein laufendes Setup im Handumdrehen erledigt wenn man die Fallstricke, bedingt durch die nicht standardkonforme AVM WG Implemention, berücksichtigt:
Mikrotik Wireguard Client auf Fritzbox Server
Sollte es doch andersrum gemeint sein, also rechts (China) der Wireguard Responder (Server) auf dem Mikrotik liegen, bekommt man die Fritte ebenso problemlos angebunden.
Wie das einfach und unkompliziert zu machen ist wird HIER im Detail beschrieben.
So oder so bekommt man es sowohl mit IPsec als auch Wireguard problemlos zum fliegen und das auch immer direkt mit der Fritte.
Das wäre doch die ITtechnisch sinnvollste Lösung auf der VPN Responder Seite (oben vermutlich links?) und erspart dir ein Kaskaden Setup und ein eigentlich überflüssiges und stromfressendes Gerät.
Fritz!Box VPN Mikrotik als VPN Client
Oder ist das Szenario oben jetzt falsch verstanden weil du leider nicht gekennzeichnet hast WER VPN Initiator und wer Responder ist.
Zudem ist dein IPsec Port Forwarding an der Fritte die den VPN Responder in Kaskade hat falsch!
Wie man es bei IPsec richtig macht ist HIER im Kaskaden Tutorial beschrieben.
Beachte bei der Fritzbox das diese selber keinerlei IPsec bezogene Konfigs oder auch IPsec User Definition haben darf ansonsten macht sie als aktiver VPN Router KEIN Port Forwarding für IPsec egal ob dies definiert ist.
die Ports 4500 und 500 habe ich dort im Server freigegeben.
Ist dort im Setup aber nirgends zu sehen sofern der MT mit aktiver Firewall rennt? 🤔Wenn, würde es so aussehen:
Ob dem so ist kannst du mit einem Packet Sniffer wie Wireshark oder dem Mikrotik internen "Torch" selber checken ob von dort (Initiator) überhaupt UDP 500 oder UDP 4500 Pakete auf der VPN Responder Seite ankommen!
Wenn du dennoch eine MT zu MT Kopplung bevorzugst wäre es noch wichtig zu erfahren ob du mit IKEv1 oder mit dem moderneren IKEv2 arbeitest?
Einen grundsätzlichen Überblick über praxisbezogene VPN Setups zeigt dir das Mikrotik Tutorial:
VPNs mit Mikrotik
Auch mit dem Mikrotik als Wireguard Client (Initiator) der auf eine Fritzbox (Wireguard Responder) arbeitet ist ein laufendes Setup im Handumdrehen erledigt wenn man die Fallstricke, bedingt durch die nicht standardkonforme AVM WG Implemention, berücksichtigt:
Mikrotik Wireguard Client auf Fritzbox Server
Sollte es doch andersrum gemeint sein, also rechts (China) der Wireguard Responder (Server) auf dem Mikrotik liegen, bekommt man die Fritte ebenso problemlos angebunden.
Wie das einfach und unkompliziert zu machen ist wird HIER im Detail beschrieben.
So oder so bekommt man es sowohl mit IPsec als auch Wireguard problemlos zum fliegen und das auch immer direkt mit der Fritte.
1
Hier ein IPsec Praxis Setup mit einer Fritzbox als VPN Initiator (Client) mit dynamischer IP und einem Mikrotik als VPN Responder (Server).
Der Einfachheit halber arbeitet der Mikrotik (RouterOS 7.17) mit der Default Konfiguration, also mit einem NAT Firewall Setup an ether1 und den Restports in einer Bridge als lokales LAN (192.168.88.0 /24)
Annahme ist das die Fritzbox benutzerfreundlich über das klassische WebGUI konfiguriert wird und nicht über eine importierte VPN Datei.
Durch diese Vorgabe ohne angepasste VPN Konfig Datei arbeitet die Fritzbox per Default im IPsec Agressive Mode mit einer Phase 1 Lifetime von 1 Stunde und supportet fest ein SHA1 Hashing bzw. DH Group 2 (1024). (Siehe dazu auch hier)
Vorgabe ist das die Fritzbox als VPN Client (Initiator) an einem einfachen Consumer Anschluss mit wechselnden IPs arbeitet oder alternativ auch an einem DS-Lite Anschluss mit CG-NAT IP. Damit muss der Mikrotik als VPN Responder (Server) in der Lage sein ein dynamisches SA Profil anlegen zu können!
Policy Level wegen des dynamischen Profils auf "Unique"
Die Firewall des Mikrotik muss als VPN Responder bei aktiver Firewall eingehende IPsec Pakete (UDP 500, 4500) auf die Input Chain passieren lassen. Ggf. kann man hier auch noch den WAN Port als Input Interface setzen.
Ohne aktive Firewall, z.B. in einer Kaskade, kann diese Regel auch entfallen.
Statt des FQDNs kann hier natürlich auch die feste WAN IP des Mikrotik als Ziel angegeben werden!
Fazit: Works as designed! 😉 👍
Inhaltsverzeichnis
IPsec VPN Setup
Mikrotik VPN Setup als Responder (Server) für Fritzbox
Der Einfachheit halber arbeitet der Mikrotik (RouterOS 7.17) mit der Default Konfiguration, also mit einem NAT Firewall Setup an ether1 und den Restports in einer Bridge als lokales LAN (192.168.88.0 /24)Mikrotik IPsec Phase 1 und Phase 2 Settings
Annahme ist das die Fritzbox benutzerfreundlich über das klassische WebGUI konfiguriert wird und nicht über eine importierte VPN Datei.Durch diese Vorgabe ohne angepasste VPN Konfig Datei arbeitet die Fritzbox per Default im IPsec Agressive Mode mit einer Phase 1 Lifetime von 1 Stunde und supportet fest ein SHA1 Hashing bzw. DH Group 2 (1024). (Siehe dazu auch hier)
Mikrotik Peer und Identity Setup
Vorgabe ist das die Fritzbox als VPN Client (Initiator) an einem einfachen Consumer Anschluss mit wechselnden IPs arbeitet oder alternativ auch an einem DS-Lite Anschluss mit CG-NAT IP. Damit muss der Mikrotik als VPN Responder (Server) in der Lage sein ein dynamisches SA Profil anlegen zu können!Mikrotik Policy Setup
Policy Level wegen des dynamischen Profils auf "Unique"Mikrotik Firewall und Fritzbox Pingcheck
Die Firewall des Mikrotik muss als VPN Responder bei aktiver Firewall eingehende IPsec Pakete (UDP 500, 4500) auf die Input Chain passieren lassen. Ggf. kann man hier auch noch den WAN Port als Input Interface setzen.Ohne aktive Firewall, z.B. in einer Kaskade, kann diese Regel auch entfallen.
Fritzbox VPN Setup über WebGUI
Statt des FQDNs kann hier natürlich auch die feste WAN IP des Mikrotik als Ziel angegeben werden!Fazit: Works as designed! 😉 👍
1
Hallo aqui,
vielen Dank für die ausführliche Antwort und die Links, ich lese es mir durch und versuche damit weiterzukommen.
Ich habe eigentlich an IKEv2 gedacht, wobei auch IKEv1 für meine Anwendung möglich wäre.
Ich dachte an den Mikrotik hier als Initiator und der Mikrotik in China als Responder, müsste aber theoretisch ja auch andersrum möglich sein.
Der Client (Staubsaugerroboter) muss glauben, dass er in China ist, weitere Geräte sollen die VPN Verbindung jedoch nicht nutzen, deshalb dachte ich an das Kaskaden-Setup.
Der Staubsauger soll sich dann mit dem WLAN des Mikrotik verbinden und die Anfragen für seine Clouddienste über die VPN nach China senden, anderenfalls funktioniert der Staubsauger nicht.
Ja, es war wohl nicht die beste Idee das Gerät von China zu importieren, aber jetzt muss ich dafür eine Lösung finden.
Ich teste weiter
Wäre den SSTP eine bessere Alternative für mein Vorhaben?
vielen Dank für die ausführliche Antwort und die Links, ich lese es mir durch und versuche damit weiterzukommen.
Ich habe eigentlich an IKEv2 gedacht, wobei auch IKEv1 für meine Anwendung möglich wäre.
Ich dachte an den Mikrotik hier als Initiator und der Mikrotik in China als Responder, müsste aber theoretisch ja auch andersrum möglich sein.
Der Client (Staubsaugerroboter) muss glauben, dass er in China ist, weitere Geräte sollen die VPN Verbindung jedoch nicht nutzen, deshalb dachte ich an das Kaskaden-Setup.
Der Staubsauger soll sich dann mit dem WLAN des Mikrotik verbinden und die Anfragen für seine Clouddienste über die VPN nach China senden, anderenfalls funktioniert der Staubsauger nicht.
Ja, es war wohl nicht die beste Idee das Gerät von China zu importieren, aber jetzt muss ich dafür eine Lösung finden.
Ich teste weiter
Wäre den SSTP eine bessere Alternative für mein Vorhaben?
Ich habe eigentlich an IKEv2 gedacht, wobei auch IKEv1 für meine Anwendung möglich wäre.
OK, unter den Voraussetzungen ist eine direkte Kopplung mit der Fritte dann nicht mehr möglich weil diese dieses Feature nicht supportet.Ggf. hilft dir dann dieses IKEv2 Tutorial weiter?!
weitere Geräte sollen die VPN Verbindung jedoch nicht nutzen, deshalb dachte ich an das Kaskaden-Setup.
Nein, das wäre nicht nötig bei der Fritte als Client, denn welche Clients sie im Netz in den Tunnel routest bestimmst du mit der ACL. Allerdings ist es dann erforderlich das du eine externe VPN Datei in die Fritte einspielst, denn dieses Finetuning ist so über das eingeschränkte KlickiBunti GUI der Fritte nicht möglich. (Siehe auch HIER zu der Thematik).aber jetzt muss ich dafür eine Lösung finden.
Technisch gesehen ist eine Lösung egal ob mit IPsec oder Wireguard kein Problem. Größter Knackpunkt wird sein ob die große Firewall dort generell deinen VPN Traffic filtert oder nicht.Nebenbei:
Den ganzen überflüssigen Aufwand mit dem Mikrotik hättest du dir mit einem einfachen Jumphost als vServer dort auch sparen können. Siehe HIER. 😉
SSTP ist Windows proprietär. Damit ist so ein Site-to-Site Setup nicht realisierbar.
Vielen Dank für deine Hilfe!
Zumindest habe ich schon einiges gelernt :D
Ich bin nun schon ein Stück weiter, nachdem ich beide auf IKEv2 umgestellt habe, die Firewall Regel ergänzt habe und Send INITIAL_CONTACT beim Mikrotik hinter der Fritzbox aktiviert habe, habe ich jetzt endlich PH2 State established
Jetzt habe ich nur noch folgende Probleme und ich komme nicht weiter, ich denke irgendwo steckt noch ein Fehler.
Wenn ich von Deutschland nach China Pinge kommt es nicht an, andersrum schon.
Hier das Ergebnis von DE nach China und Route:
Hier das Ergebnis von China nach DE und Route:
Und wie stelle ich denn sicher, dass der ganze Traffic dann durch den VPN geht, ich aber dennoch noch lokal Zugriff auf die Config habe?
Zumindest habe ich schon einiges gelernt :D
Ich bin nun schon ein Stück weiter, nachdem ich beide auf IKEv2 umgestellt habe, die Firewall Regel ergänzt habe und Send INITIAL_CONTACT beim Mikrotik hinter der Fritzbox aktiviert habe, habe ich jetzt endlich PH2 State established
Jetzt habe ich nur noch folgende Probleme und ich komme nicht weiter, ich denke irgendwo steckt noch ein Fehler.
Wenn ich von Deutschland nach China Pinge kommt es nicht an, andersrum schon.
Hier das Ergebnis von DE nach China und Route:
Hier das Ergebnis von China nach DE und Route:
Und wie stelle ich denn sicher, dass der ganze Traffic dann durch den VPN geht, ich aber dennoch noch lokal Zugriff auf die Config habe?
habe ich jetzt endlich PH2 State established
Glückwunsch! 👏 👍Send initial Contact sendet, wie die Bezeichnung schon selber sagt, immer der VPN Initiator (Client). Also der, der aktiv den Tunnel aufbaut. Wenn beide Seiten passiv als Responder warten wirds logischerweise nix mit dem Tunnel.
Wenn ich von Deutschland nach China Pinge kommt es nicht an, andersrum schon.
Hier bist du vermutlich Opfer eines (Anfänger) Denkfehlers in der Ping Funktion!Überlege einmal selber!!
In den IPsec Policy Settings hast du ja bestimmt das nur Traffic zwischen deinen lokalen LANs in den Tunnel geroutet wird.
Wenn man jetzt aber wie du etwas laienhaft dahergeht und das Ping Tool ohne entsprechende Settings nutzt die sicherstellen das die Absender (Source) IP aus dem lokalen LAN kommt und die Ziel IP eine Adresse aus dem lokalen LAN von gegenüber ist, dann weiss der MT nicht welche Absender IP er nehmen soll, da er ja mehrere hat. Er nimmt dann also die WAN IP und damit scheitert dann der Ping zum VPN Gegenüber, weil er durch die dann falsche Absender IP die nicht mit der IPsec Policy matched statt in den Tunnel übers Provider Internet geht. Da private RFC1918 IPs im Internet wegen ihrer Unroutebarkeit nicht pingbar sind geht dein Ping also ins IP Nirwana. Genau das Ping Fehlerbild also was du oben bei dir siehst!
Lösung:
Setze im Ping Tool unter "Interface" dein Absender Interface oder klicke den Advanced Reiter im Ping Tool wo du deine Absender IP (Source Address) setzen kannst und setze dort deine LAN Interface IP ein. Damit gibst du die Absender IP vor und alles sollte wie erwartet klappen.
Sieh dir immer die oben zu deiner Hilfe gepostenen Tutorial Screenshots genau an dann passieren solche Fauxpas' auch nicht.
Nebenbei solltest du ausgegraute "Konfig Leichen" wie die nicht mehr existente Default Route auf dein nicht mehr existentes WG Interface usw. immer löschen und so aus der Konfig entfernen! Solche "Relikte" fallen dir irgendwann wieder auf die Füße und dann geht das Troubleshooting wieder von vorn los...
Vielen Dank, oh Mann, vollkommen logisch, aber da wäre ich nicht drauf gekommen.
Ich hab mir jetzt noch die weiteren Seiten angesehen, die IPSEC Verbindung läuft jetzt, Ping geht auch.
Jetzt habe ich versucht, den ganzen Traffic durch den Tunnel zu leiten, dazu habe ich folgende Policies ergänzt
Entsprechend auch die Gegenseite, eth5 in Deutschland habe ich einen anderen Nummernkreis gegeben uns als Serviceport konfiguriert.
Firewall-Regeln habe ich auch nochmal angepasst.
Aber damit komme ich immer noch mit meiner deutschen IP ins Netz, ich denke, ich habe immer noch einen Denkfehler.
DNS /DHCP habe ich in DE so konfiguriert:
In China sieht die weitere Konfiguration so aus:
Ich hab das Gefühl, ich bin kurz vor dem Ziel - nachdem ich zwischenzeitlich auch mal meinen Mikrotik Router hier nur mit Netinstall wieder zum laufen gebracht habe durch falsche Einstellungen :D
Was übersehe ich denn noch?
Ich hab mir jetzt noch die weiteren Seiten angesehen, die IPSEC Verbindung läuft jetzt, Ping geht auch.
Jetzt habe ich versucht, den ganzen Traffic durch den Tunnel zu leiten, dazu habe ich folgende Policies ergänzt
Entsprechend auch die Gegenseite, eth5 in Deutschland habe ich einen anderen Nummernkreis gegeben uns als Serviceport konfiguriert.
Firewall-Regeln habe ich auch nochmal angepasst.
Aber damit komme ich immer noch mit meiner deutschen IP ins Netz, ich denke, ich habe immer noch einen Denkfehler.
DNS /DHCP habe ich in DE so konfiguriert:
In China sieht die weitere Konfiguration so aus:
Ich hab das Gefühl, ich bin kurz vor dem Ziel - nachdem ich zwischenzeitlich auch mal meinen Mikrotik Router hier nur mit Netinstall wieder zum laufen gebracht habe durch falsche Einstellungen :D
Was übersehe ich denn noch?
meinen Mikrotik Router hier nur mit Netinstall wieder zum laufen gebracht habe durch falsche Einstellungen
Auch das ist Unsinn und muss nicht sein wenn man den Rest Knopf richtig bedienen kann! 😉https://help.mikrotik.com/docs/spaces/ROS/pages/24805498/Reset+Button
Du solltest die Policy mit einer entsprechenden Maske erstmal so einstellen das du nur mit 2 oder 4 Adressen aus deinem lokalen LAN in den Tunnel gehst also mit einer /30 oder /29er Maske.
Diese Adressen sollten dann nicht im DHCP Pool stehen sondern fest mit einer Mac Adressierung auf diese dedizierten IP Adressen. Beispiel:
- Netzwerk = 192.168.88.0 /24 (⚠️ .240 bis .247 dürfen nicht im DHCP Pool sein!!)
- Policy Maske = 192.168.88.240 /29
- Lokale Adressen die in den Tunnel geroutet werden = .88.241 bis .88.246
Denk drann das diese Phase 2 Policy auch für die Gegenüber liegende Seite gilt.
Dein grundsätzliches Problem was du vermutlich nicht bedacht hast ist das mit der o.a. Policy NICHT der gesamte Traffic in den Tunnel geht sondern ausschliesslich nur der zwischen den Netzen .88.0 und .1.0 auf der remoten Seite.
Was du aber willst ist das auch der Internet Traffic, also der Traffic an beliebige nicht RFC1918 Zieladressen, dieser spezifischen Geräte über den Tunnel geht, an der remoten Seite ausgekoppelt wird ins Internet und von dort auch wieder zurück über den Tunnel geht. Mit NAT wirst du da innerhalb des Tunnel bei IPsec nichts weil NAT Interface bezogen ist.
Du musst also mit der Policy dafür sorgen das der Traffic dieser spezifischen Geräte insgesamt über den Tunnel zum Ziel geht und dort per NAT ausgekoppelt wird.
Ein entsprechender Thread in der MT Knowledgebase beschreibt so ein Setup mit einer einzelnen /32 IP Adresse (Roboter) nach dem oben geschilderten Prinzip.
https://forum.mikrotik.com/viewtopic.php?t=171863
Vielen lieben Dank, jetzt läuft der Traffic
Jetzt habe ich noch eine letzte Frage, wie schaffe ich es, dass die DNS Anfragen auch in China aufgelöst werden?
Mit folgenden Einstellungen hab ich es versucht.
Deutschland:
China (+Freigabe der Ports in der Firewall):
Oder ist der dhcp-pool 192.168.1.2-192.168.1.126 falsch?
Danke!
Jetzt habe ich noch eine letzte Frage, wie schaffe ich es, dass die DNS Anfragen auch in China aufgelöst werden?
Mit folgenden Einstellungen hab ich es versucht.
Deutschland:
China (+Freigabe der Ports in der Firewall):
Oder ist der dhcp-pool 192.168.1.2-192.168.1.126 falsch?
Danke!
wie schaffe ich es, dass die DNS Anfragen auch in China aufgelöst werden?
DNS Server statisch unter IP --> DNS eintragen! Hier im Testsetup rennt es auch fehlerfrei mit IKEv2.
Der Vorschlag mit der .x.240 /29 in der Policy war übrigens etwas blöd, sorry. 🤦♂️
Blöd deswegen, weil man sich dann von den Router Management Adressen abkappt.
Intelligenter ist natürlich 192.168.x.0 /29 so hat man den Bereich von .1 bis .6 frei für Adressen im /24er Netz die man nach China (oder sonstwohin) tunneln will oder muss. Über die DHCP Reservierung kann man dann einfach bestimmen wen man aus dem Netz über einen Umweg ins Internet bringen will.
Also wenn ich die China DNS in beide Router eingebe, sieht es aber nach DNS Leak aus.
Ich müsste ja die DNS-Abfragen auch durch den Tunnel schicken, oder?
Eins ist mir noch aufgefallen - wenn ich mich über den Tunnel im Router in China über Winbox anmelde, macht er alle 25 Sekunden eine Neuanmeldung, ist das normal?
Danke!
Eins ist mir noch aufgefallen - wenn ich mich über den Tunnel im Router in China über Winbox anmelde, macht er alle 25 Sekunden eine Neuanmeldung, ist das normal?
Danke!
Ich müsste ja die DNS-Abfragen auch durch den Tunnel schicken, oder?
Ja, das ist richtig, zumindestens für die Clients die du in den Tunnel routest!Deshalb ist es sinnvoll nur für diese Clients in der DHCP DNS Einstellung clientspezifisch via statischer Mac Reservierung nur für die einen China DNS zu verwenden. Diese einstellung "überrennt" dann die globale.
Vergiss das also mit dem statischen Eintrag auf den Routern, das war ein Denkfehler, sorry. 🤦♂️
Mach das also immer clientspezifisch.
macht er alle 25 Sekunden eine Neuanmeldung, ist das normal?
Eigentlich nicht... Kann aber ein Inactivity Timeout sein wenn du nix eingibst. Müsste man in der MT Doku zum Management Access einmal checken.
Würde da nicht meine Einstellung von oben passen, mit der ich versucht habe, das auch nach China zu schicken?
Der DNS in DE ist die IP des Router in China, und der DNS in China ist dann der engültige?
Nur klappt das so nicht
Der DNS in DE ist die IP des Router in China, und der DNS in China ist dann der engültige?
Nur klappt das so nicht
Der DNS in DE ist die IP des Router in China, und der DNS in China ist dann der engültige?
Das ist korrekt so wenn diese DNS IP den VPN Clients die den Tunnel nutzen entweder statisch oder im DHCP über die Mac Reservierung zugewiesen werden. So nutzen nur diese VPN Clients spezifisch diesen DNS Server.Alternativ kannst du natürlich diesen dedizierten VPN Clients auch direkt die DNS Server IP in China geben. Beides sollte zum Erfolg führen!
Bedenke das du hier als DNS die LAN Adresse des Mikrotik in China angeben musst so das die übers VPN erreichbar ist!
Diese IP ist dann von den Clients auch übers VPN pingbar. Der Mikrotik arbeitet dann dort wie alle Router auch als lokaler DNS (Cache) Server und reicht alles was er nicht kennt an den Upstream DNS (der "endgültige") weiter der inter ip --> DNS definiert ist oder der dort angezeigt wird sofern er dynamisch gelernt wird.
Klappt hier im Testsetup fehlerlos und kann man mit nslookup oder einem der DNS Tools im Winbos GUI auch testen.
Jetzt funktioniert alles
Vielen vielen Dank für deine Hilfe!
Vielen vielen Dank für deine Hilfe!
Jetzt funktioniert alles
Bingo! Glückwunsch! 👏👍Dann fröhliches Staubsaugen...
Hallo aqui,
nunja, ganz funktioniert es noch nicht, er reagiert nicht auf Eingaben - müsste ich noch Ports freigeben/weiterleiten, die ich im Paket Sniffer sehe?
Wenn ich im identischen Wlan des Staubsaugers bin, zeigt er ihn mir sogar als offline - nur von „außen“ klappt der Sichtzugriff.
Oder denkst du, ich hätte bei Wireguard nicht dieses Problem.
Damals war es nur so, dass der Port nach ein paar Tagen nicht mehr funktionierte - der Handshake ging dann nur nach dem Wechsel auf einen anderen Port - kann ich mir aber auch nicht erklären 🤔
nunja, ganz funktioniert es noch nicht, er reagiert nicht auf Eingaben - müsste ich noch Ports freigeben/weiterleiten, die ich im Paket Sniffer sehe?
Wenn ich im identischen Wlan des Staubsaugers bin, zeigt er ihn mir sogar als offline - nur von „außen“ klappt der Sichtzugriff.
Oder denkst du, ich hätte bei Wireguard nicht dieses Problem.
Damals war es nur so, dass der Port nach ein paar Tagen nicht mehr funktionierte - der Handshake ging dann nur nach dem Wechsel auf einen anderen Port - kann ich mir aber auch nicht erklären 🤔
Wenn ich im identischen Wlan des Staubsaugers bin, zeigt er ihn mir sogar als offline - nur von „außen“ klappt der Sichtzugriff.
Ja, das ist doch auch logisch wenn du ein separates WLAN mit separater IP Adressierung verwendest. Denke einmal selber etwas nach... Mit der 0.0.0.0/0 IPsec Policy wird alles in den Tunnel gesendet. Das inkludiert natürlich auch das LAN/WLAN in dem sich dein Steuerungsclient befindet. Dadurch das RFC1918 IPs nicht geroutet werden gehen also alle Daten der Rückroute des Steuerungsclient ins Nirwana mit dem Fehlerbild was du siehst. Ein Traceroute hätte dir das auch gezeigt.
Es gibt 2 einfache Lösungen
- Den Roboter mit ins gleiche WLAN Segment nehmen wie der Steuerungsclient und mit der IPsec Policy Maske so steuern das nur die ersten 4 oder 8 IP Adressen für den Tunnel verwendet werden. IPs dann mit Mac Reservierung fest zuweisen. Alternativ kannst du dich natürlich mit dem Steuerungsclient auch immer separat ins Roboter WLAN einloggen, das klappt auch weil dann die Connection lokal ist und nicht geroutet wird.
- Wenn du dennoch mit getrennten WLANs (MSSID) arbeiten willst musst du eine 2te Policy generieren mit dem Sauger WLAN IP Netz (Source) und dem Steuerungsclient WLAN IP Netz (Destination) und der Action none. Damit wird das Steuerungsclient IP Netz dann vom Default Routing in den VPN Tunnel ausgenommen.
Hallo,
ich glaub ich hab es falsch erklärt oder falsch verstanden 😅
Meinem Handy hab ich auch per MAC Reservierung in dem IP Kreis des Roboter, das Steuerungssignal läuft über die Cloud drs Herstellers in China - nie lokal. Das Signal muss als einmal durch China, kommt nur nicht zurück zum Router.
Das Handy muss nicht im selben Wlan sein, das war nur ein Test.
ich glaub ich hab es falsch erklärt oder falsch verstanden 😅
Meinem Handy hab ich auch per MAC Reservierung in dem IP Kreis des Roboter, das Steuerungssignal läuft über die Cloud drs Herstellers in China - nie lokal. Das Signal muss als einmal durch China, kommt nur nicht zurück zum Router.
Das Handy muss nicht im selben Wlan sein, das war nur ein Test.
das Steuerungssignal läuft über die Cloud drs Herstellers in China - nie lokal
Uhhhh, das klingt böse der kennt dann dein Zuhause aus dem FF. Aber nundenn...zurück zum Thema.Hast du mal versucht via Mobilfunknetz zuzugreifen also ganz ohne häusliche Infrastruktur?
Erklärbar ist das sonst nicht. Wenn du mit dem Smartphone via WLAN auf www.myexternalip.com gehst müsste da ja die .cn IP Adresse als Absender angezeigt werden. Das NAT auf dem ausgehenden Router hat ja kein Limit was irgendwelche Ports angeht.
Der Sinn und Zweck einer Hersteller Zwangscloud ist ja immer das das Endgerät sich über eine hardgecodete Adresse am Herstellerserver anmeldet und so den Port offenhält über eine Firewall. Der Steuerclient kontaktiert dann von egal wo den Herstellerserver und findet über die Login ID und der zugeordneten Device ID (Mac, Seriennummer etc.) die entsprechende offene Session und nutzt die um aufs Endgerät zugreifen zu können ohne Firewall.
Die übliche Zwangsprozedur damit auch der größte DAU das Gerät einfach steuern kann ohne etwas von Vernetzung und Firewalling kennen zu müssen und für den Hersteller um problemlos an alle Kundendaten zu kommen.
kommt nur nicht zurück zum Router.
Nein, das kann nicht sein und hast du ja oben auch selber vierfiziert! Wenn du mit dem Smartphone auf www.myexternalip.com gehst siehst du als Absender IP ja die des CN Routers. Wenn du ganz sicher gehen willst kannst du dem Smartphone testweise einmal die gleiche IP zuordnen wie dem Roboter um den zu simulieren.Hat der die gleiche Absender IP geht folglich auch der Return Traffic des Servers an die gleiche IP. Wohin sollte er auch sonst gehen?!
Kannst du auch selber sehen wenn du mit der "Torch" Funktion dir den ausgehenden HTTP(S) Traffic ansiehst.
Okay, dann liegt es wahrscheinlich am Staubsaugerroboter selbst - er war mal kurz gesperrt, ist jetzt aber vom Hersteller wieder entsperrt.
Ich kläre mal, ob da vielleicht noch eine Sperre vorhanden ist.
Den Status des Staubsaugers kann ich ja sehen, er reagiert nur nicht auf eingaben.
Wenn ich mal den ISP wechseln würde, würde der Tunnel auch bei CGNAT oder DSlite funktionieren, oder?
Ich kläre mal, ob da vielleicht noch eine Sperre vorhanden ist.
Den Status des Staubsaugers kann ich ja sehen, er reagiert nur nicht auf eingaben.
Wenn ich mal den ISP wechseln würde, würde der Tunnel auch bei CGNAT oder DSlite funktionieren, oder?
Ja, das klappt dann weiter. Ausgehende VPN Verbindungen sind davon nicht betroffen. DS-Lite / CG-NAT Anschlüsse bedeuten nur dann das Aus für IPv4 VPNs (und lokalem Port Forwarding) wenn sie auf der VPN Responder (Server) Seite vorhanden sind.
Also dort, wo von außen (Internet) IPv4 Verbindungen reinkommen auf diesem Anschluss. Diese Verbindungen kann das zentrale NAT Gateway so eines Providers prinzipbedingt NICHT an den jeweiligen Kundenanschluss forwarden. Logisch, denn dann müsste ein kundenspezifisches Port Forwarding dort konfiguriert sein was bei zig tausenden von Kunden die sich so ein Gateway Cluster dynamisch teilen prinzipbedingt technisch unmöglich ist.
Also dort, wo von außen (Internet) IPv4 Verbindungen reinkommen auf diesem Anschluss. Diese Verbindungen kann das zentrale NAT Gateway so eines Providers prinzipbedingt NICHT an den jeweiligen Kundenanschluss forwarden. Logisch, denn dann müsste ein kundenspezifisches Port Forwarding dort konfiguriert sein was bei zig tausenden von Kunden die sich so ein Gateway Cluster dynamisch teilen prinzipbedingt technisch unmöglich ist.
1
