6
Mikrotik als VPN Client
Hallo Zusammen
ich versuche vergens eine VPN Verbindung zwischen einer Mikrotik und einer Ubiquiti USG herzustellen. Die Idee ist dass die Mikrotik als Client fungiert. Habe eine L2TP mit IPSec Verbindung eingerichet.
Diese verbindet sich auch mit der USG. Mit der Mikrotik kann ich auch das Netzwerk auf der gegenseite anpingen. Aber leider kann ich dies mit dem PC nicht der im Netzwerk der Mikrotik liegt. In der Firewall Einstellung habe ich alles zugelassen, da die Mikrotik nicht direkt am Öffentlichen Netz hängt.
Site to Site VPN Verbindungen zwischen Mikrotiks habe ich schon öfters hinbekommen, als eine Einwahl VPN mit der Mikrotik habe ich noch nie gemacht.
ich versuche vergens eine VPN Verbindung zwischen einer Mikrotik und einer Ubiquiti USG herzustellen. Die Idee ist dass die Mikrotik als Client fungiert. Habe eine L2TP mit IPSec Verbindung eingerichet.
Diese verbindet sich auch mit der USG. Mit der Mikrotik kann ich auch das Netzwerk auf der gegenseite anpingen. Aber leider kann ich dies mit dem PC nicht der im Netzwerk der Mikrotik liegt. In der Firewall Einstellung habe ich alles zugelassen, da die Mikrotik nicht direkt am Öffentlichen Netz hängt.
Site to Site VPN Verbindungen zwischen Mikrotiks habe ich schon öfters hinbekommen, als eine Einwahl VPN mit der Mikrotik habe ich noch nie gemacht.
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: 451186
Url: https://administrator.de/forum/mikrotik-als-vpn-client-451186.html
Ausgedruckt am: 23.12.2024 um 00:12 Uhr
6 Kommentare
Neuester Kommentar
Aber leider kann ich dies mit dem PC nicht der im Netzwerk der Mikrotik liegt
Ist der Mikrotik der einzige Router im Netzwerk, sprich also ist das Internet direkt am Mikrotik oder betreibst du den in einer Router Kaskade mit doppeltem NAT ?Wenn du von den Routern deren jeweiliges LAN Interface pingen kannst ist das erstmal ein gutes zeichen, denn das besagt ja das der VPN Tunnel sauber aufgebaut wurde und funktioniert.
Dann kann es lediglich nur ein Problem der Endgeräte sein, das hier eine Router fehlt oder die Einstellungen der lokalen Firewalls auf den Endgeräten nicht angepasst wurden.
Letzteres solltest du besonders bei Winblows beachten, denn die Firewall lässt weder Pings (ICMP) noch IP Pakete mit nicht lokalen Absender Adressen durch. Das ist hier der häufigste Anfragegrund im Forum weil der Zugriff auf remote Windows Rechner nicht klappt obwohl der VPN Tunnel aktiv ist.
Grundlagen zu den Settings findest du auch hier:
IPsec VPN Praxis mit Standort Vernetzung Cisco, Mikrotik, pfSense, FritzBox u.a
Cisco, Mikrotik, pfSense VPN Standort Vernetzung mit dynamischem Routing
Kennst du ja aber als MT Spezl vermutlich alles schon
Hallo aqui
Es ist nicht der einzige Router im Netz aber nach aussen her sollte es keine Blockierungen geben. Wie du ja selber sagst funktioniert der Ping von der Mikrotik aus. Ich hatte auch schon übers Web versucht einen Webserver aufzurufen, der auf der VPN seite steht aber das funktioniert leider nicht.
Ich lese mir die Links mal durch vielleicht habe ich einen kleinen Denkfehler gemacht. Mit dem PC direkt eine VPN verbindung auf die Ubiquiti USG zu machen funktioniert ohne Probleme.
Es ist nicht der einzige Router im Netz aber nach aussen her sollte es keine Blockierungen geben. Wie du ja selber sagst funktioniert der Ping von der Mikrotik aus. Ich hatte auch schon übers Web versucht einen Webserver aufzurufen, der auf der VPN seite steht aber das funktioniert leider nicht.
Ich lese mir die Links mal durch vielleicht habe ich einen kleinen Denkfehler gemacht. Mit dem PC direkt eine VPN verbindung auf die Ubiquiti USG zu machen funktioniert ohne Probleme.
einen Webserver aufzurufen, der auf der VPN seite steht aber das funktioniert leider nicht.
Wie gesagt das kann die lokale Firewall dieser Geräte sein. Besonders wenn es sich um Winblows Systeme handelt, denn die dortige lokale Firewall blockt alle IP Adressen die nicht aus dem lokalen LAN kommen per Default. Hier muss man also immer zwingend die lokale Firewall anpassen.Sinnvoll ost es deshalb das Web GUI eines evtl. vorhandenen Druckers usw. zu verwenden denn in der Regel haben die keine Firewalls. Das gleiche gilt für ICMP Pakete (Ping und Traceroute) die die Winblows Firewall ach per Default komplett filtert. Hier muss man bei Windows also aufpassen.
Ein sicheres Indiz ist immer die Pingbarkeit der jeweiligen LAN Interfaces der VPN Router. Sind die Pingbar, kann man davon ausgehen das der Fehler zu 98% in den Endgeräten auf der jeweiligen remoten Seite liegt.
Eine Wireshark Sniffer ist dann, wie immer, hier oft eine wertvolle Hilfe !
Eventuell hast du auch keine Rückroute, dann kennt die USG nur die IP, die sie der Mikrotik zugeteilt hat, aber nicht die IP des Netzwerks in dem der Windows PC hängt. Hört sich für mich an als ob du Client VPN statt LAN-zu-LAN aktiviert hättest, dann könnte auch nur die Mikrotik pingen.
Eventuell hast du auch keine Rückroute
Wäre auch hier die erste Vermutung !Traceroute (tracert Winblows) ist wie immer dein bester Freund das rauszubekommen.
Hallo roeggi,
Meiner Meinung nach gibt es hier mehrere mögliche Probleme und mehrere Lösungsmöglichkeiten, ich fang mal mit den möglichen Problemen an:
1.) Wie die Kollegen bereits geschrieben haben fehlen den Routern die entsprechenden Routen. Solltest du mit Routing noch nicht viel am Hut haben, dann merke dir folgende zwei Faustregeln:
a. Ohne zusätzliche Angaben kennt ein Router ausschließlich die anliegenden Netze.
b. Routen müssen immer bidirektional angegeben werden.
Der Tik hat über die Einwahl alle Informationen bekommen, die notwendig sind um im/ins USG Netz Daten zu transferieren. Die USG jedoch hat nur die Information erhalten, dass ein zusätzlicher (IP-)Teilnehmer im Netzwerk L2TP-Einwahl vorhanden ist. Das bedeutet die USG weiß gar nicht, dass hinter dem neuen Teilnehmer noch ein, zwei, viele Netz(e) zu finden sind. Dies muss mittels einer statischen Route erstmal definiert werden.
2.) Selbst wenn das Routing bereits funktionieren würde, ich würde davon ausgehen, dass das Tik-Netz auf der USG trotz allem ein Fremdnetz ist und deswegen von der Firewall dropped würde.
3.) Es gibt keine Route vom Endgerät im Tik-Netz (PC), die dem Endgerät mitteilt, wie er das über VPN erreichbare Netz finden kann. Ist ein wunderbares Problem über das ich beim Consulting bei einem bestimmten Kunden immer wieder mal drübergestolpert bin...
Lösungsvorschläge:
1.) Lösung zu Problem #3:
a. Temporär, lokal (meine Präferenz für Bugfixing): Öffne am PC mit Admin-Rechten eine Konsole und gib "route add DESTINATIONSNETZ GATEWAY" ein. Wenn das USG-Netz, dass du erreichen willst z.B. 10.0.0.0/24 und dein Tik-Router 192.168.201.5 ist dann würde der Befehl
lauten
b. Permanent, lokal (macht Sinn wenn du wirklich nur ein einziges Gerät routen willst: Selbes Prozedere wie in Punkt a., es kommt nur noch ein Switch dazu:
Selbstverständlich kannst du das Destinationsnetz auch klassifiziert angeben, würde ich heute aber nicht mehr machen. Das würde dann so aussehen:
c. permanent, ganzes Netzwerk (die eigentlich richtige Implementation): Richte die statische Route über eine der verfügbaren Möglichkeiten auf deinem Standardgateway ein. Wenn nicht allzuviel Traffic zu erwarten ist oder die Hardware des StandardGWs entsprechende Power hat: Trag eine statische Route ein, die auf den Tik als Gateway verweist.
Wenn das Gerät eher schwachbrüstig ist und du mit DHCP arbeitest könntest du den Leases noch eine DHCP-Option mitgeben. Ich werde hierzu kein Beispiel geben, da dies von System zu System unterschiedlich (kompliziert) implementiert sein kann.
2.) Wenn die Teilnehmer aus dem Tik-Netz für Teilnehmer aus dem USG-Netz nicht direkt erreichbar sein müssen, schalt am TIK ein Masquerading ein, gültig für alle Anfragen aus dem lokalen Netz mit Ziel USG-Netz(e).
Der Befehl in der Shell lautet dafür:
10.0.0.0/24 ist das Netzwerk, das ich als Beispiel für das USG-Netz gewählt habe.
Mit Masquerading werden alle über den Tik an das USG-Netz gesendeten Pakete so umgeschrieben, sodass es für die USG aussieht als würde der ursprüngliche Request vom Tik kommen.
Vorschlag 2.) ist in meinen Augen nur ein Workaround, würde ich eigentlich nur als Proof-Of-Concept verwenden, dass es tatsächlich möglich ist Clients im USG-Netz zu erreichen.
3.) Wie bereits von den Kollegen erläutert ist es sicherlich klug die Routen von der USG ins Tik-Netz sowie die Firewall Regeln auf der USG zu überprüfen. Speziell wenn mein Vorschlag 2.) funktioniert, dann hast du das Problem bei der USG.
lG
Areanod
Meiner Meinung nach gibt es hier mehrere mögliche Probleme und mehrere Lösungsmöglichkeiten, ich fang mal mit den möglichen Problemen an:
1.) Wie die Kollegen bereits geschrieben haben fehlen den Routern die entsprechenden Routen. Solltest du mit Routing noch nicht viel am Hut haben, dann merke dir folgende zwei Faustregeln:
a. Ohne zusätzliche Angaben kennt ein Router ausschließlich die anliegenden Netze.
b. Routen müssen immer bidirektional angegeben werden.
Der Tik hat über die Einwahl alle Informationen bekommen, die notwendig sind um im/ins USG Netz Daten zu transferieren. Die USG jedoch hat nur die Information erhalten, dass ein zusätzlicher (IP-)Teilnehmer im Netzwerk L2TP-Einwahl vorhanden ist. Das bedeutet die USG weiß gar nicht, dass hinter dem neuen Teilnehmer noch ein, zwei, viele Netz(e) zu finden sind. Dies muss mittels einer statischen Route erstmal definiert werden.
2.) Selbst wenn das Routing bereits funktionieren würde, ich würde davon ausgehen, dass das Tik-Netz auf der USG trotz allem ein Fremdnetz ist und deswegen von der Firewall dropped würde.
3.) Es gibt keine Route vom Endgerät im Tik-Netz (PC), die dem Endgerät mitteilt, wie er das über VPN erreichbare Netz finden kann. Ist ein wunderbares Problem über das ich beim Consulting bei einem bestimmten Kunden immer wieder mal drübergestolpert bin...
Lösungsvorschläge:
1.) Lösung zu Problem #3:
a. Temporär, lokal (meine Präferenz für Bugfixing): Öffne am PC mit Admin-Rechten eine Konsole und gib "route add DESTINATIONSNETZ GATEWAY" ein. Wenn das USG-Netz, dass du erreichen willst z.B. 10.0.0.0/24 und dein Tik-Router 192.168.201.5 ist dann würde der Befehl
route add 10.0.0.0/24 192.168.201.5b. Permanent, lokal (macht Sinn wenn du wirklich nur ein einziges Gerät routen willst: Selbes Prozedere wie in Punkt a., es kommt nur noch ein Switch dazu:
route add 10.0.0.0/24 192.168.201.5 -proute add 10.0.0.0 MASK 255.255.255.0 192.168.201.5 -pc. permanent, ganzes Netzwerk (die eigentlich richtige Implementation): Richte die statische Route über eine der verfügbaren Möglichkeiten auf deinem Standardgateway ein. Wenn nicht allzuviel Traffic zu erwarten ist oder die Hardware des StandardGWs entsprechende Power hat: Trag eine statische Route ein, die auf den Tik als Gateway verweist.
Wenn das Gerät eher schwachbrüstig ist und du mit DHCP arbeitest könntest du den Leases noch eine DHCP-Option mitgeben. Ich werde hierzu kein Beispiel geben, da dies von System zu System unterschiedlich (kompliziert) implementiert sein kann.
2.) Wenn die Teilnehmer aus dem Tik-Netz für Teilnehmer aus dem USG-Netz nicht direkt erreichbar sein müssen, schalt am TIK ein Masquerading ein, gültig für alle Anfragen aus dem lokalen Netz mit Ziel USG-Netz(e).
Der Befehl in der Shell lautet dafür:
/ip firewall nat add action=masquerade chain=srcnat dst-address=10.0.0.0/24Mit Masquerading werden alle über den Tik an das USG-Netz gesendeten Pakete so umgeschrieben, sodass es für die USG aussieht als würde der ursprüngliche Request vom Tik kommen.
Vorschlag 2.) ist in meinen Augen nur ein Workaround, würde ich eigentlich nur als Proof-Of-Concept verwenden, dass es tatsächlich möglich ist Clients im USG-Netz zu erreichen.
3.) Wie bereits von den Kollegen erläutert ist es sicherlich klug die Routen von der USG ins Tik-Netz sowie die Firewall Regeln auf der USG zu überprüfen. Speziell wenn mein Vorschlag 2.) funktioniert, dann hast du das Problem bei der USG.
lG
Areanod
