20
VPN mit Mikrotik Hex, Mikrotik CR326 und FritzBox?
Hallo zusammen,
ich spanne derzeit über einen Mikrotik Hex für den Privathaushalt einige VLANs auf (Bewohner, Gäste, Server, IoT-Kram etc.). Der Hex hängt hinter einer FritzBox6590 an einem Kabelanschluss, bei dem ich mir mal 1000 MBit gegönnt habe (langsamere Optionen wären gar nicht so viel günstiger gewesen).
Ursprünglich wollte ich hinter den Hex einen Cisco SG250 mit PoE hängen, um die VLANs zu verteilen, aber faktisch gibt es derzeit nur drei kabelgebundene Clients und einen Accesspoint, der wundersamerweise die ganze Wohnung sehr gut versorgt (Unifi AC LR). Daher steht der (recht laute) Cisco derzeit still - der Unifi ist das einzige PoE-versorgte Gerät und dafür verwende ich dessen mitgelieferten Einspeiser.
Sollte ich doch mal mehr Ports benötigen, liebäugele ich mit der Anschaffung des CR326 (und Verkauf des SG250) - unterm Strich spare ich damit Geld und vermeide Lärm.
Jetzt denke ich über die Einrichtung eines VPNs nach, mit dem ich von mehreren Clients von unterwegs aus auf den heimischen Server zugreifen kann. Ich habe mich mit diversen Anleitungen mal an der Einrichtung innerhalb des Hex versucht, bin aber letztendlich doch jedesmal gescheitert, und könnte nicht bei allen Schritten jemandem erklären, was ich da eigentlich gemacht habe.
Was aber recht trivial war, war die Einrichtung eines VPNs über die Fritzbox. Da hat AVM schon einiges sehr erleichtert.
Was denkt Ihr, ist folgendes Setup funktional?
- Hex als Router hinter einer Fritzbox, an Port 4 derselben, wo ein "Fritz-Gästenetz" aufgespannt wird. Hex bezieht als "Gast" an der Fritzbox eine IP und spielt aus deren Sicht Client. So funktioniert es ja heute schon.
- VPN-Zugang von außen zum "normalen" Fritzbox-Netz einrichten, welches an den Ports 1-3 derselben verfügbar wäre.
- Die Fritzbox für ihr "normales" Netz nicht DHCP-Server spielen lassen, sondern eine IP-Adresse fest zuweisen
- Auf dem Hex ein weiteres VLAN "VPN-Besucher" aufspannen mit einem Adressbereich, der die Fritzbox umfasst
- Port 1 der Fritzbox mit einem Port des Hex verbinden, an welchem dieses "VPN-Besucher"-VLAN anliegt.
Vorteile, falls das klappen würde, wären:
- VPN wäre recht leicht auf der Fritzbox einzurichten
- evtl. könnte ich die Aufgaben des Hex mittelfristig auch auf den CR326 verschieben, der ja auch RouterOS anbietet. Das würde dann nur noch von der Client-Zahl und den Firewall-Regeln abhängen, aber keinen Einfluss mehr auf die VPN-Performance haben.
Freue mich auf Euren Input!
Viele Grüße
- michacgn
ich spanne derzeit über einen Mikrotik Hex für den Privathaushalt einige VLANs auf (Bewohner, Gäste, Server, IoT-Kram etc.). Der Hex hängt hinter einer FritzBox6590 an einem Kabelanschluss, bei dem ich mir mal 1000 MBit gegönnt habe (langsamere Optionen wären gar nicht so viel günstiger gewesen).
Ursprünglich wollte ich hinter den Hex einen Cisco SG250 mit PoE hängen, um die VLANs zu verteilen, aber faktisch gibt es derzeit nur drei kabelgebundene Clients und einen Accesspoint, der wundersamerweise die ganze Wohnung sehr gut versorgt (Unifi AC LR). Daher steht der (recht laute) Cisco derzeit still - der Unifi ist das einzige PoE-versorgte Gerät und dafür verwende ich dessen mitgelieferten Einspeiser.
Sollte ich doch mal mehr Ports benötigen, liebäugele ich mit der Anschaffung des CR326 (und Verkauf des SG250) - unterm Strich spare ich damit Geld und vermeide Lärm.
Jetzt denke ich über die Einrichtung eines VPNs nach, mit dem ich von mehreren Clients von unterwegs aus auf den heimischen Server zugreifen kann. Ich habe mich mit diversen Anleitungen mal an der Einrichtung innerhalb des Hex versucht, bin aber letztendlich doch jedesmal gescheitert, und könnte nicht bei allen Schritten jemandem erklären, was ich da eigentlich gemacht habe.
Was aber recht trivial war, war die Einrichtung eines VPNs über die Fritzbox. Da hat AVM schon einiges sehr erleichtert.
Was denkt Ihr, ist folgendes Setup funktional?
- Hex als Router hinter einer Fritzbox, an Port 4 derselben, wo ein "Fritz-Gästenetz" aufgespannt wird. Hex bezieht als "Gast" an der Fritzbox eine IP und spielt aus deren Sicht Client. So funktioniert es ja heute schon.
- VPN-Zugang von außen zum "normalen" Fritzbox-Netz einrichten, welches an den Ports 1-3 derselben verfügbar wäre.
- Die Fritzbox für ihr "normales" Netz nicht DHCP-Server spielen lassen, sondern eine IP-Adresse fest zuweisen
- Auf dem Hex ein weiteres VLAN "VPN-Besucher" aufspannen mit einem Adressbereich, der die Fritzbox umfasst
- Port 1 der Fritzbox mit einem Port des Hex verbinden, an welchem dieses "VPN-Besucher"-VLAN anliegt.
Vorteile, falls das klappen würde, wären:
- VPN wäre recht leicht auf der Fritzbox einzurichten
- evtl. könnte ich die Aufgaben des Hex mittelfristig auch auf den CR326 verschieben, der ja auch RouterOS anbietet. Das würde dann nur noch von der Client-Zahl und den Firewall-Regeln abhängen, aber keinen Einfluss mehr auf die VPN-Performance haben.
Freue mich auf Euren Input!
Viele Grüße
- michacgn
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: 624692
Url: https://administrator.de/contentid/624692
Ausgedruckt am: 17.11.2024 um 15:11 Uhr
20 Kommentare
Neuester Kommentar
Es könnte sein, dass es für Port 4 der FB Einschränkungen gibt.
Dieses abtippfertige Tutorial beschreibt dir die einfache und kinderleichte Einrichtung eines L2TP VPNs auf dem Mikrotik. Damit kannst du von allen Betriebssystemen und Smartphones, Tablets etc. immer ganz einfach den onboard VPN Client benutzen:
Scheitern am IPsec VPN mit MikroTik
Scheitern am IPsec VPN mit MikroTik
1
Hallo aqui,
wie so oft fabrizierst Du fabelhafte Anleitungen. Die ist auch sehr übersichtlich - bei bisherigen Tutorials habe ich wohl IPSEC probiert, mit deutlich mehr für mich rätselhaften Schritten.
Magst Du mir bitte noch erklären, was die Bedeutung des Proxy-ARP ist, der ja hier eine sehr entscheidende Rolle zu spielen scheint?
Bei mir sind Interfaces wie folgt definiert (Ausschnitt, aber die anderen VLANs sind analog):
/interface bridge vlan
add bridge=bridge1 tagged=bridge1 untagged=VLAN1 vlan-ids=1
add bridge=bridge1 tagged=bridge1,ether3,ether2 untagged=VLAN10 vlan-ids=10
/interface list member
add interface=ether1 list=WAN
add interface=bridge1 list=LAN
add interface=VLAN10 list=LAN
add interface=VLAN1 list=LAN
Wo müsste ich denn den Proxy-ARP definieren?
Übrigens, sowas wie dieses Unwissen hinsichtlich des Proxy-ARP meine ich, wenn ich sage: ich will nicht blind Tutorials folgen, sondern schon eine Ahnung haben, was ich da gerade warum aktiviere. Und wenn ich es komplett für mich nicht nachvollzogen kriege, dann muss ich es halt doch über die Fritzbox probieren.
Danke aber auf jeden Fall schonmal!
wie so oft fabrizierst Du fabelhafte Anleitungen. Die ist auch sehr übersichtlich - bei bisherigen Tutorials habe ich wohl IPSEC probiert, mit deutlich mehr für mich rätselhaften Schritten.
Magst Du mir bitte noch erklären, was die Bedeutung des Proxy-ARP ist, der ja hier eine sehr entscheidende Rolle zu spielen scheint?
Bei mir sind Interfaces wie folgt definiert (Ausschnitt, aber die anderen VLANs sind analog):
/interface bridge vlan
add bridge=bridge1 tagged=bridge1 untagged=VLAN1 vlan-ids=1
add bridge=bridge1 tagged=bridge1,ether3,ether2 untagged=VLAN10 vlan-ids=10
/interface list member
add interface=ether1 list=WAN
add interface=bridge1 list=LAN
add interface=VLAN10 list=LAN
add interface=VLAN1 list=LAN
Wo müsste ich denn den Proxy-ARP definieren?
Übrigens, sowas wie dieses Unwissen hinsichtlich des Proxy-ARP meine ich, wenn ich sage: ich will nicht blind Tutorials folgen, sondern schon eine Ahnung haben, was ich da gerade warum aktiviere. Und wenn ich es komplett für mich nicht nachvollzogen kriege, dann muss ich es halt doch über die Fritzbox probieren.
Danke aber auf jeden Fall schonmal!
was die Bedeutung des Proxy-ARP ist, der ja hier eine sehr entscheidende Rolle zu spielen scheint?
Immer gerne aber die Wikipedia kann das besser:https://en.wikipedia.org/wiki/Proxy_ARP
Ohne das Proxy ARP bei L2TP beantwortet der VPN Router die ARP Requests der VPN Clients nicht.
Bei mir sind Interfaces wie folgt definiert
Das ist nicht ganz richtig was die VLAN Interfaces angeht. Guckst du auch hier:Router Mikrotik 750GL einbinden
Wo müsste ich denn den Proxy-ARP definieren?
Du definierst ihn auf allen VLAN IP Interfaces die du via VPN erreichen willst.sondern schon eine Ahnung haben, was ich da gerade warum aktiviere.
Sehr löbliche Einstellung !! 
dann muss ich es halt doch über die Fritzbox probieren.
Nicht zwingend, du hättest noch OpenVPN als Option ! 
Clientverbindung OpenVPN Mikrotik
Die L2TP Konfig funktioniert aber wasserdicht und das ganz sicher auch bei dir !
Guten Abend!
Nach langer Zeit habe ich endlich mal etwas Ruhe gefunden, mit den Einstellungen für das VPN zu spielen.
Zunächst: lieber @aqui, Deine Tutorial lief einwandfrei. DANKE!
Ich habe das VPN jetzt ausprobiert, indem ich das Handy mit dem WLAN der Fritzbox verbunden habe (die vor dem Mikrotik als "teures Modem" hängt). Als nächstes würde ich versuchen, dort ein Portmapping anzulegen für die Kommunikation von außen. Und als übernächstes steht vielleicht an, den Mikrotik Hex durch einen CRS326 zu ersetzen, damit ich mehr Ports habe. Mal sehen, was das an Performance hier im Heimnetz kosten könnte.
Eine Frage bleibt beim VPN aber noch: wofür benötige ich das Proxy-ARP?
Mir ist klar, was technisch passiert: ohne Proxy-ARP geht auf L2 keine Verbindung durch, da das Remote-Device ja nicht mit eigener MAC im lokalen Netz vertreten ist. Verstehe ich richtig: das kann mir egal sein, wenn ich keine L2-basierten Protokolle nutzen möchte, sondern bspw. nur http-Verbindungen zulassen will, die ja mit TCP/IP auf L3 basieren?
Router Mikrotik 750GL einbinden
Mir fällt auf Anhieb nur ein Unterschied auf: ich habe auch die bridge als tagged zu jedem Interface hinzugefügt. Wenn ich Deine Anleitung richtig gesehen habe, machst Du das nicht. Wolltest Du darauf hinaus, oder übersehe ich etwas? Ich traue mich nicht, meine lauffähige Einrichtung jetzt zu resetten, um Deine Anleitung (die ich sicher schonmal befolgt habe) nochmal durchzuspielen und danach die Unterschiede im Coding zu vergleichen. Vermutlich habe ich danach Einstellungen verändert, um bestimmte Dinge auszuprobieren.
Oder was ist Deiner Ansicht nach nicht ganz richtig?
Danke auf jeden Fall!
Viele Grüße
- michacgn
Nach langer Zeit habe ich endlich mal etwas Ruhe gefunden, mit den Einstellungen für das VPN zu spielen.
Zunächst: lieber @aqui, Deine Tutorial lief einwandfrei. DANKE!
Ich habe das VPN jetzt ausprobiert, indem ich das Handy mit dem WLAN der Fritzbox verbunden habe (die vor dem Mikrotik als "teures Modem" hängt). Als nächstes würde ich versuchen, dort ein Portmapping anzulegen für die Kommunikation von außen. Und als übernächstes steht vielleicht an, den Mikrotik Hex durch einen CRS326 zu ersetzen, damit ich mehr Ports habe. Mal sehen, was das an Performance hier im Heimnetz kosten könnte.
Eine Frage bleibt beim VPN aber noch: wofür benötige ich das Proxy-ARP?
Ohne das Proxy ARP bei L2TP beantwortet der VPN Router die ARP Requests der VPN Clients nicht.
Mir ist klar, was technisch passiert: ohne Proxy-ARP geht auf L2 keine Verbindung durch, da das Remote-Device ja nicht mit eigener MAC im lokalen Netz vertreten ist. Verstehe ich richtig: das kann mir egal sein, wenn ich keine L2-basierten Protokolle nutzen möchte, sondern bspw. nur http-Verbindungen zulassen will, die ja mit TCP/IP auf L3 basieren?
Bei mir sind Interfaces wie folgt definiert
Das ist nicht ganz richtig was die VLAN Interfaces angeht. Guckst du auch hier:Router Mikrotik 750GL einbinden
Mir fällt auf Anhieb nur ein Unterschied auf: ich habe auch die bridge als tagged zu jedem Interface hinzugefügt. Wenn ich Deine Anleitung richtig gesehen habe, machst Du das nicht. Wolltest Du darauf hinaus, oder übersehe ich etwas? Ich traue mich nicht, meine lauffähige Einrichtung jetzt zu resetten, um Deine Anleitung (die ich sicher schonmal befolgt habe) nochmal durchzuspielen und danach die Unterschiede im Coding zu vergleichen. Vermutlich habe ich danach Einstellungen verändert, um bestimmte Dinge auszuprobieren.
Oder was ist Deiner Ansicht nach nicht ganz richtig?
Danke auf jeden Fall!
Viele Grüße
- michacgn
ich habe auch die bridge als tagged zu jedem Interface hinzugefügt.
Das ist falsch wenn du damit die Member Ports der Bridge meinst.Es ist richtig wenn du damit die VLAN Zuweisung in der Bridge meinst und rein nur die Ports die Tagged sind. Alle einfachen Access Ports dürfen NICHT so konfiguriert sein.
Deine Beschreibung ist etwas verwirrend und unklar weil nicht klar ist WELCHE Einstellung du genau damit meinst. Ein Screenshot würde sicher helfen genau zu verstehen was du meinst mit der Port Einstellung.
Thema Proxy ARP.
L2TP nutzt ein unnumbered Interface für die Client Anbindung und muss deshalb auf ARP Requests antworten für VPN Clients was es ohne Proxy ARP nicht machen würde.
https://de.wikipedia.org/wiki/Address_Resolution_Protocol#Proxy_ARP
https://en.wikipedia.org/wiki/Proxy_ARP
Hallo!
Danke nochmal. Ich habe meinen Denkfehler beim Proxy-ARP gefunden: ich habe die VPN-Clients in ein eigenes VLAN gesperrt. Alle Heimserver stecken damit natürlich in einem anderen VLAN, was in jedem Fall ein L3-Routing erfordert hat. Daher war das Vorhandensein des Proxy-ARPs bei mir irrelevant. Stecke ich die VPN-Clients in dasselbe VLAN wie die Server, gibt es keinen Grund für ein L3-Routing, und dann scheitert ohne Proxy-ARP nachvollziehbarerweise auch die Kommunikation auf L2.
Jetzt kann ich etwas beruhigter schlafen - ich weiß halt gerne, warum ich bestimmte (von den Defaults abweichende) Settings mache.
Nochmal zur VLAN-Konfiguration. Das hier war ja der relevante Teil, auf den Du dich bezogen hast:
Folgende Zeile hatte ich nicht gezeigt:
Aus meiner Sicht bedeutet das:
- auf den Interfaces bridge1, ether2 und ether3 reisen die Pakete "mit VLAN-Markierung", während sie auf den virtuellen Interfaces VLAN10 etc. untagged sind, ebenso auf Interface ether4 - dort gibt es nur Pakete aus VLAN20.
Was ich nicht erwähnt hatte:
- ether2 ist mein Virtualisierungshost, dessen VMs in unterschiedlichen VLANs liegen. Daher bekommt er "alle" VLANs und muss selber das ganze aufdröseln.
- ether3 ist der MSSID-fähige AP, der die VLANs in verschiedenen SSIDs präsentiert und daher auch alle VLANs bekommt.
- lediglich ether4 und ether5 sind dumme Endgeräte, die entsprechend nur das jeweilige VLAN untagged präsentiert bekommen.
Klingt das jetzt vernünftig, oder hättest Du dennoch etwas anders eingestellt?
Danke nochmal. Ich habe meinen Denkfehler beim Proxy-ARP gefunden: ich habe die VPN-Clients in ein eigenes VLAN gesperrt. Alle Heimserver stecken damit natürlich in einem anderen VLAN, was in jedem Fall ein L3-Routing erfordert hat. Daher war das Vorhandensein des Proxy-ARPs bei mir irrelevant. Stecke ich die VPN-Clients in dasselbe VLAN wie die Server, gibt es keinen Grund für ein L3-Routing, und dann scheitert ohne Proxy-ARP nachvollziehbarerweise auch die Kommunikation auf L2.
Jetzt kann ich etwas beruhigter schlafen
- ich weiß halt gerne, warum ich bestimmte (von den Defaults abweichende) Settings mache.Nochmal zur VLAN-Konfiguration. Das hier war ja der relevante Teil, auf den Du dich bezogen hast:
/interface bridge vlan
add bridge=bridge1 tagged=bridge1 untagged=VLAN1 vlan-ids=1
add bridge=bridge1 tagged=bridge1,ether3,ether2 untagged=VLAN10 vlan-ids=10
/interface list member
add interface=ether1 list=WAN
add interface=bridge1 list=LAN
add interface=VLAN10 list=LAN
add interface=VLAN1 list=LANFolgende Zeile hatte ich nicht gezeigt:
add bridge=bridge1 tagged=bridge1,ether3,ether2 untagged=VLAN20,ether4 vlan-ids=20Aus meiner Sicht bedeutet das:
- auf den Interfaces bridge1, ether2 und ether3 reisen die Pakete "mit VLAN-Markierung", während sie auf den virtuellen Interfaces VLAN10 etc. untagged sind, ebenso auf Interface ether4 - dort gibt es nur Pakete aus VLAN20.
Was ich nicht erwähnt hatte:
- ether2 ist mein Virtualisierungshost, dessen VMs in unterschiedlichen VLANs liegen. Daher bekommt er "alle" VLANs und muss selber das ganze aufdröseln.
- ether3 ist der MSSID-fähige AP, der die VLANs in verschiedenen SSIDs präsentiert und daher auch alle VLANs bekommt.
- lediglich ether4 und ether5 sind dumme Endgeräte, die entsprechend nur das jeweilige VLAN untagged präsentiert bekommen.
Klingt das jetzt vernünftig, oder hättest Du dennoch etwas anders eingestellt?
Das hier war ja der relevante Teil, auf den Du dich bezogen hast:
Ahhh...OK.Gut, das "untagged VLANx" Interface ist da der Fehler. Das gehört da nicht rein. In der Bridge VLAN Konfig stehen einzig und allein NUR die tagged Ports und die Bridge selber. (Siehe Tutorial und Screenshots dort !)
Die VLAN Interfaces werden lediglich nur in den Bridge Member Ports aufgeführt.
Untagged Endgeräte Ports werden nur mit ihrem PVID Setting im Member Port Setup definiert.
Das solltest du in jedem Falle in deinem Setup korrigieren. Gilt bei dir für die VLAN IDs 1, 10 und 20 !
Aus meiner Sicht bedeutet das:....
Alles richtig mit, wie bereits gesagt, den VLAN Interfaces selber. Wäre ja auch technischer Quatsch die da UNtagged einzutragen, da sie ja in der Interface Definition selber unten immer Tagged definiert sind. Das ist also de facto falsch und bedarf der Korrektur. (Entfernen der vlan Interfaces dort)oder hättest Du dennoch etwas anders eingestellt?
Ja, siehe oben...
Hallo @aqui,
nach langer Pause (andere Dinge standen im Vordergrund) komme ich endlich mal wieder dazu, hier weiterzuspielen.
Wie an anderer Stelle geschrieben ist es jetzt doch ein RB3011 geworden, der sich um VLANs kümmert und auch den VPN bereitstellen soll, hinter der Fritzbox, die in Standard-Vodafone-Konfiguration betrieben wird und somit schon eine erste Firewall und ein erstes NATting bereitstellt (sowas macht die Diskussion mit VF einfacher: wenn an keinem der Ports Internet zu finden ist, ist es wohl deren Problem, sonst meines).
Einmal zu den VLANs:
Im Tutorial schreibst Du:
Ist es nicht letztendlich sogar egal, ob ich die VLAN-Ports tagged oder untagged heranführe? Idealerweise hat ein VLAN-Port ja genau ein VLAN ;)
Beim L2TP-VPN stelle ich mir auch noch eine Frage: hier wird ja zur Verschlüsselung IPSec verwendet, mit PSK. Sehe ich richtig, dass mir ein zertifikatsbasiertes Verfahren (statt PSK) nur zwei Vorteile bringen würde:
- nur definierte Endgeräte (auf denen das Zertifikat installiert ist) können sich einwählen
- ich kann durch Key Revocation theoretisch einzelne Geräte dauerhaft ausschließen.
Wobei das zweite ja auch durch einen Austausch des PSK auf allen verbliebenen Devices möglich wäre.
Oder gäbe es noch weitere Vorteile?
Frohe Ostern und viele Grüße
- michacgn
nach langer Pause (andere Dinge standen im Vordergrund) komme ich endlich mal wieder dazu, hier weiterzuspielen.
Wie an anderer Stelle geschrieben ist es jetzt doch ein RB3011 geworden, der sich um VLANs kümmert und auch den VPN bereitstellen soll, hinter der Fritzbox, die in Standard-Vodafone-Konfiguration betrieben wird und somit schon eine erste Firewall und ein erstes NATting bereitstellt (sowas macht die Diskussion mit VF einfacher: wenn an keinem der Ports Internet zu finden ist, ist es wohl deren Problem, sonst meines).
Einmal zu den VLANs:
Zitat von @aqui:
Gut, das "untagged VLANx" Interface ist da der Fehler. Das gehört da nicht rein. In der Bridge VLAN Konfig stehen einzig und allein NUR die tagged Ports und die Bridge selber. (Siehe Tutorial und Screenshots dort !)
Die VLAN Interfaces werden lediglich nur in den Bridge Member Ports aufgeführt.
Gut, das "untagged VLANx" Interface ist da der Fehler. Das gehört da nicht rein. In der Bridge VLAN Konfig stehen einzig und allein NUR die tagged Ports und die Bridge selber. (Siehe Tutorial und Screenshots dort !)
Die VLAN Interfaces werden lediglich nur in den Bridge Member Ports aufgeführt.
Im Tutorial schreibst Du:
VLAN Ports müssen NICHT zwingend als Member Ports der Bridge eingetragen werden ! Siehe dazu auch HIER.
Dabei verlinkst Du auf ein PDF, in welchem es heißt (Folie 6):/interface bridge vlan
add bridge=bridge1 tagged=bridge1,ether2,ether3,VLAN10 untagged=ether4 vlan-ids=10
add bridge=bridge1 tagged=bridge1,ether2,ether3,VLAN11 vlan-ids=11
add bridge=bridge1 tagged=bridge1,ether2,ether3,VLAN12 vlan-ids=12Ist es nicht letztendlich sogar egal, ob ich die VLAN-Ports tagged oder untagged heranführe? Idealerweise hat ein VLAN-Port ja genau ein VLAN ;)
Beim L2TP-VPN stelle ich mir auch noch eine Frage: hier wird ja zur Verschlüsselung IPSec verwendet, mit PSK. Sehe ich richtig, dass mir ein zertifikatsbasiertes Verfahren (statt PSK) nur zwei Vorteile bringen würde:
- nur definierte Endgeräte (auf denen das Zertifikat installiert ist) können sich einwählen
- ich kann durch Key Revocation theoretisch einzelne Geräte dauerhaft ausschließen.
Wobei das zweite ja auch durch einen Austausch des PSK auf allen verbliebenen Devices möglich wäre.
Oder gäbe es noch weitere Vorteile?
Frohe Ostern und viele Grüße
- michacgn
Ist es nicht letztendlich sogar egal, ob ich die VLAN-Ports tagged oder untagged heranführe?
Das ist richtig wenn man es unten im Setup immer dem richtigen VLAN zuweist !dass mir ein zertifikatsbasiertes Verfahren (statt PSK) nur zwei Vorteile bringen würde:
Den wichtigstens Vorteil hast du vergessen. Der VPN Server weist sich mit einem Zertifikat aus. Damit ist dann sichergestellt das sich alle Clients nur mit DEINEM eigenen VPN Server verbinden. Ohne ein Zertifikat kann jeder deinen Clients einen Fake VPN Server unterjubeln der die Clients dann per VPN an irgendwas Böses entführt. Sprich dein VPN Server ist kaperbar ohne das du es merkst.Wenn du aber damit leben kannst spricht nichts gegen L2TP.
Den wichtigstens Vorteil hast du vergessen. Der VPN Server weist sich mit einem Zertifikat aus. Damit ist dann sichergestellt das sich alle Clients nur mit DEINEM eigenen VPN Server verbinden. Ohne ein Zertifikat kann jeder deinen Clients einen Fake VPN Server unterjubeln der die Clients dann per VPN an irgendwas Böses entführt. Sprich dein VPN Server ist kaperbar ohne das du es merkst.
Wenn du aber damit leben kannst spricht nichts gegen L2TP.
Wenn du aber damit leben kannst spricht nichts gegen L2TP.
Danke, das stimmt natürlich!
Jetzt bin ich nochmal über L2TP gestolpert:
- ich habe den Proxy-ARP auf ein virtuelles VLAN-Interface gesetzt. Naiv hätte ich gedacht, dass damit auch der Traffic über dieses Interface fließt. Tut er aber nicht, er kommt aus einem dynamisch erzeugten Interface <l2tp-...>. Sehe ich richtig: Firewall-Regeln auf Interface-Basis kann ich nicht machen, ich muss über andere Kriterien filtern?
- Ich habe in der Firewall die von @aqui vorgeschlagenen Freigaben hinzugefügt (1701, 500, 4500 sowie ESP), ebenso diese Ports 1:1 in der vorgeschalteten Fritzbox an den Mikrotik geforwardet. Interessanterweise gibt es aber nur dann Traffic auf dieser Regel, wenn der "Road Warrior" mit der Fritzbox direkt verbunden ist. Ist er hingegen im Internet und kommt "von außen" an die Fritzbox, die dann Port-Forwarding macht, passiert auf dieser Regel nichts.
/ip firewall filter
add action=accept chain=input protocol=ipsec-espWie kommt es dazu? Aus Sicht des Mikrotik kommt der Traffic doch in beiden Fällen "aus der Fritzbox", einmal dort geroutet, einmal dort geswitcht?
Interessanterweise gibt es aber nur dann Traffic auf dieser Regel, wenn der "Road Warrior" mit der Fritzbox direkt verbunden ist.
Zeigt klar das deine FritzBox falsch konfiguriert ist !Die FritzBox ist ja selber aktiver IPsec VPN Router. Deaktiviert man nicht vollständig auf der FritzBox die VPN Funktion und VPN User usw., dann "denkt" sie weiterhin die eingehenden IPsec Pakete UDP 500, 4500 und ESP sind für sie selber bestimmt und forwardet sie NICHT weiter auch wenn ein gültiges Port Forwarding aktiviert ist dafür. Ihre eigene VPN Funktion hat immer Priorität !
Wichtig ist auch das die FB VPN Funktion NICHT für die FB Ports reglementiert ist was im Setup ja möglich ist.
Darauf wird in den zahlosen VPN Tutorials hier und im Netz immer und immer wieder hingewiesen.
Fazit:
Customize deine FritzBox richtig, dann forwardet sie auch korrekt die IPsec Frames und L2TP dahinter kommt sofort zum Fliegen !
doch in beiden Fällen "aus der Fritzbox", einmal dort geroutet, einmal dort geswitcht?
Nein. Geswitcht schonmal gar nicht weil die FB ja bekanntermaßen ein Router ist" und KEIN Switch.Knackpunkt ist wie oben bereits gesagt die FB. Hat die Reste einer VPN Konfig drauf leitet sie schlicht und einfach den IPsec Traffic trotz Port Forwarding NICHT weiter.
Kannst du auch wunderbar selber sehen wenn du dir temporär mal einen Wireshark Sniffer mit gleicher IP wie den MT an die FB klemmst und den von der FB eingehenden VPN Traffic ansiehst.
Forwardet sie siehst du eingehenden IPsec Traffic vom Client
Blockiert sie siehst du nix
Hallo aqui,
das klingt plausibel - passt aber nicht. Was ich nicht deutlich erwähnt habe: die Verbindung funktioniert ja, und sie wird definitiv erst auf dem Mikrotik aufgelöst:
- Ich habe auf der FB niemals ein VPN eingerichtet, nie Nutzer angelegt und nie PSK definiert. Ich hätte auch keinen Schalter es abzustellen - außer halt die Benutzerliste zu leeren, die aber schon leer ist.
- Ändere ich den für IPSec verwendeten PSK im Mikrotik, funktioniert der Zugang nicht mehr. Das heißt, der PSK wird definitiv zwischen Client (hier: Handy) und Mikrotik verwendet, nicht in der Fritzbox.
Ich wundere mich halt nur, warum Protocol 50 nicht verwendet wird, wenn das Handy auch als Client an der FB angemeldet ist. Vielleicht, weil Handy und Mikrotik (beide als Clients an der FB) per L2-Switching verbunden sind?
das klingt plausibel - passt aber nicht. Was ich nicht deutlich erwähnt habe: die Verbindung funktioniert ja, und sie wird definitiv erst auf dem Mikrotik aufgelöst:
- Ich habe auf der FB niemals ein VPN eingerichtet, nie Nutzer angelegt und nie PSK definiert. Ich hätte auch keinen Schalter es abzustellen - außer halt die Benutzerliste zu leeren, die aber schon leer ist.
- Ändere ich den für IPSec verwendeten PSK im Mikrotik, funktioniert der Zugang nicht mehr. Das heißt, der PSK wird definitiv zwischen Client (hier: Handy) und Mikrotik verwendet, nicht in der Fritzbox.
Ich wundere mich halt nur, warum Protocol 50 nicht verwendet wird, wenn das Handy auch als Client an der FB angemeldet ist. Vielleicht, weil Handy und Mikrotik (beide als Clients an der FB) per L2-Switching verbunden sind?
Kann das sein das du Protocol 50 mit UDP oder TCP Port 50 verwechselst ? Bei laien passiert das gerne mal. IP Protocoll 50 ist aber das ESP Protokoll ein eigenstäntiges IP Protokoll. Möglich das du da was verwechelst ?!
Auch ist unklar was du genau mit "...als Client an der FB angemeldet ist" genau meinst ??
Als was für ein Client denn ?? WLAN, VPN, WEBclient ??
Als VPN Client ist das Mobiltelefon niemals an der FB "angemeldet" ! Folglich kannst du also niemals irgendwelchen ESP Traffic dort sehen. Unklar was du damit meinst.
Der ESP Tunnel transportiert die VPN Live Daten. Würde der nicht "verwendet" werden würde das gesamte VPN logischerweise niemals funktionieren.
Das ist so als wenn du einen leeren Tank beim Auto hast. Würdest du dir den VPN Traffic zw. Client und MT mit einem Wireshark Sniffer einmal ansehen siehst du dort immer ESP (Prot. 50) Traffic. Unverständlich wie du darauf kommst das es "nicht verwendet" wird ?!
Auch ist unklar was du genau mit "...als Client an der FB angemeldet ist" genau meinst ??
Als was für ein Client denn ?? WLAN, VPN, WEBclient ??
Als VPN Client ist das Mobiltelefon niemals an der FB "angemeldet" ! Folglich kannst du also niemals irgendwelchen ESP Traffic dort sehen. Unklar was du damit meinst.
Der ESP Tunnel transportiert die VPN Live Daten. Würde der nicht "verwendet" werden würde das gesamte VPN logischerweise niemals funktionieren.
Das ist so als wenn du einen leeren Tank beim Auto hast. Würdest du dir den VPN Traffic zw. Client und MT mit einem Wireshark Sniffer einmal ansehen siehst du dort immer ESP (Prot. 50) Traffic. Unverständlich wie du darauf kommst das es "nicht verwendet" wird ?!
Hallo aqui,
nein, ich meine wirklich Protocol 50.
Szenario 1:
- das Handy ist mit dem (für diesen Test aktivierten) WLAN der Fritzbox verbunden. Es ist ein direkter Client der Fritzbox, typischerweise mit IP-Adresse 192.168.178.xx3. Kein VPN involviert.
- der Mikrotik ist per Kabel mit derselben FB verbunden. IP dynamisch per DHCP bezogen: 192.168.178.xx2.
- L2TP ist auf dem Mikrotik eingerichtet, auf dessen Mikrotik-interner Adresse 192.168.1.1
- vier Regel stehen am Anfang der IP-Firewall des Mikrotik:
- Die VPN-Daten sind auf dem Mikrotik definiert (L2TP, PSK, Secrets) und auf dem Handy hinterlegt (IP=192.168.178.xx2, also die auf der Fritzbox vergebene IP für den Mikrotik).
- Die FB kennt kein VPN, war dort nie genutzt.
Schalte ich das VPN ein, funktioniert alles. Ich sehe, wie bei den Firewall-Regeln der Paketzähler mit den Zugriffen auf dem Handy hochgeht.
Szenario 2:
- das Handy ist per LTE im Netz der Telekom eingebucht.
- der Mikrotik ist per Kabel mit derselben FB verbunden. Per DHCP IP 192.168.178.xx2.
- auf der FB werden die Ports 500, 1701 und 4500 auf den Mikrotik geforwardet.
- Ebenso wird ESP auf den Mikrotik geforwardet:
(bitte nicht von der 0 verwirren lassen: bei Wahl des Protokolls ESP ist der Port nicht eingebbar)
- L2TP ist auf dem Mikrotik eingerichtet, auf dessen Mikrotik-interner Adresse 192.168.1.1
- dieselben vier Regel wie oben stehen am Anfang der IP-Firewall des Mikrotik.
- Die VPN-Daten sind auf dem Mikrotik definiert (L2TP, PSK, Secrets) und auf dem Handy hinterlegt (externe IP der Fritzbox).
- Die FB kennt kein VPN, war dort nie genutzt.
Schalte ich das VPN ein, funktioniert alles. Ich sehe, wie bei den Firewall-Regeln der Paketzähler mit den Zugriffen auf dem Handy hochgeht - ABER nicht bei der Regel für ESP. Da diese Regel aber ausschließlich auf das Protokoll eingeschränkt ist (kein Interface, keine Ports, nichts, siehe oben), heißt das: der Traffic kommt hier nicht vorbei.
nein, ich meine wirklich Protocol 50.
Szenario 1:
- das Handy ist mit dem (für diesen Test aktivierten) WLAN der Fritzbox verbunden. Es ist ein direkter Client der Fritzbox, typischerweise mit IP-Adresse 192.168.178.xx3. Kein VPN involviert.
- der Mikrotik ist per Kabel mit derselben FB verbunden. IP dynamisch per DHCP bezogen: 192.168.178.xx2.
- L2TP ist auf dem Mikrotik eingerichtet, auf dessen Mikrotik-interner Adresse 192.168.1.1
- vier Regel stehen am Anfang der IP-Firewall des Mikrotik:
/ip firewall filter add action=accept chain=input protocol=ipsec-esp
/ip firewall filter add action=accept chain=input dst-port=500 in-interface-list=WAN protocol=udp
/ip firewall filter add action=accept chain=input dst-port=1701 in-interface-list=WAN protocol=udp
/ip firewall filter add action=accept chain=input dst-port=4500 in-interface-list=WAN protocol=udp- Die FB kennt kein VPN, war dort nie genutzt.
Schalte ich das VPN ein, funktioniert alles. Ich sehe, wie bei den Firewall-Regeln der Paketzähler mit den Zugriffen auf dem Handy hochgeht.
Szenario 2:
- das Handy ist per LTE im Netz der Telekom eingebucht.
- der Mikrotik ist per Kabel mit derselben FB verbunden. Per DHCP IP 192.168.178.xx2.
- auf der FB werden die Ports 500, 1701 und 4500 auf den Mikrotik geforwardet.
- Ebenso wird ESP auf den Mikrotik geforwardet:
Geöffnete Ports -- Verwendete Protokolle -- Gerät
0 -- ESP, IPv4 -- MikroTik
500 -- UDP, IPv4 -- MikroTik
1701 -- UDP, IPv4 -- MikroTik
4500 -- UDP, IPv4 -- MikroTik- L2TP ist auf dem Mikrotik eingerichtet, auf dessen Mikrotik-interner Adresse 192.168.1.1
- dieselben vier Regel wie oben stehen am Anfang der IP-Firewall des Mikrotik.
- Die VPN-Daten sind auf dem Mikrotik definiert (L2TP, PSK, Secrets) und auf dem Handy hinterlegt (externe IP der Fritzbox).
- Die FB kennt kein VPN, war dort nie genutzt.
Schalte ich das VPN ein, funktioniert alles. Ich sehe, wie bei den Firewall-Regeln der Paketzähler mit den Zugriffen auf dem Handy hochgeht - ABER nicht bei der Regel für ESP. Da diese Regel aber ausschließlich auf das Protokoll eingeschränkt ist (kein Interface, keine Ports, nichts, siehe oben), heißt das: der Traffic kommt hier nicht vorbei.
OK, jetzt versteht man dein verwirrendes Szenario endlich...
OK, bei Szenario 1 bist du ja über das WLAN direkt am MT Port. Der VPN Client hat als VPN Server IP dann direkt die MT Adresse konfiguriert. Klar, dann ist die FB komplett außen vor und alles klappt direkt zwischen Client und MT. Da hast du recht.
Szenario 2 geht ja dnan über die FB. Als VPN Server IP im Client ist jetzt natürlich NICHT die MT IP (die ist aus dem Internet ja gar nicht erreichbar !) sondern die FB WAN IP drin.
Dann forwardet die FB quasi als "Durchlauferhitzer" zum MT.
Sorry, aber da war etwas Sand im Verständigungs "Getriebe".
Das die Counter nicht hochgehen bei ESP liegt am NAT Traversal. Beim VPN Traffic über die FB "merkt" der VPN Server das im Gegensatz zum Szenario 1 NAT (IP Adress Translation) dazwischen ist und nutzt automatisch alles über NAT Traversal = UDP 4500. Das ESP Paket ist also in ein UDP 4500 Paket verpackt und für den ESP Counter so nicht mehr sichtbar. Da hast du dich vermutlich dann in jugendlicher Unkentniss des IPsec Protokollhandlings verwirren lassen, kann das sein ?!
OK, bei Szenario 1 bist du ja über das WLAN direkt am MT Port. Der VPN Client hat als VPN Server IP dann direkt die MT Adresse konfiguriert. Klar, dann ist die FB komplett außen vor und alles klappt direkt zwischen Client und MT. Da hast du recht.
Szenario 2 geht ja dnan über die FB. Als VPN Server IP im Client ist jetzt natürlich NICHT die MT IP (die ist aus dem Internet ja gar nicht erreichbar !) sondern die FB WAN IP drin.
Dann forwardet die FB quasi als "Durchlauferhitzer" zum MT.
Sorry, aber da war etwas Sand im Verständigungs "Getriebe".
Das die Counter nicht hochgehen bei ESP liegt am NAT Traversal. Beim VPN Traffic über die FB "merkt" der VPN Server das im Gegensatz zum Szenario 1 NAT (IP Adress Translation) dazwischen ist und nutzt automatisch alles über NAT Traversal = UDP 4500. Das ESP Paket ist also in ein UDP 4500 Paket verpackt und für den ESP Counter so nicht mehr sichtbar. Da hast du dich vermutlich dann in jugendlicher Unkentniss des IPsec Protokollhandlings verwirren lassen, kann das sein ?!
Hallo @aqui,
danke! "NAT Traversal = UDP 4500" war, was ich brauchte, um einen Abend durch Google zu reisen. Die RouterOs-Doku ist ja an manchen Stellen super, an anderen aber leider gar nicht.
Exakt! Und da mich sowas stört, habe ich halt heute versucht, das nachzuvollziehen. Ich will doch wissen, was ich hier bastele und nutze.
Eigentlich ist es halbwegs simpel:
UDP 500: hierüber wird die IPSec-Vorgehensweise ausgehandelt und die NAT-Detection gemacht.
Wenn kein NAT, wird IP-Protokoll 50 verwendet, was keinen Port braucht.
Wenn NAT, dann wird Protokoll UDP mit Port 4500 verwendet, was dadurch NAT-able wird, da ja ein Port vorhanden ist.
In jedem Fall landen die Pakete damit am IPSec-Server, der sie entschlüsselt, und an Port 1701 weitergibt.
UDP 1701: hier lauscht der L2TP-Server und schiebt die Pakete ins lokale Netz.
So, damit bleibt nur noch eine Frage: der L2TP-Server läuft mit eigener IP-Adresse, die ich bspw. im Secret oder im Profil zuweise. Aber es scheint ziemlich gleich zu sein, ob ich hier eine IP-Adresse des Routers (also bspw. 192.168.1.1), eine IP-Adresse aus seinem Netz (192.168.1.5) oder einen Pool zuweise. Nur leer lassen darf ich sie nicht. Welche Funktion hat sie? Was kann ich damit aktiv beeinflussen?
Schönen Abend!
- michacgn
danke! "NAT Traversal = UDP 4500" war, was ich brauchte, um einen Abend durch Google zu reisen. Die RouterOs-Doku ist ja an manchen Stellen super, an anderen aber leider gar nicht.
Zitat von @aqui:
Da hast du dich vermutlich dann in jugendlicher Unkentniss des IPsec Protokollhandlings verwirren lassen, kann das sein ?!
Da hast du dich vermutlich dann in jugendlicher Unkentniss des IPsec Protokollhandlings verwirren lassen, kann das sein ?!
Exakt! Und da mich sowas stört, habe ich halt heute versucht, das nachzuvollziehen. Ich will doch wissen, was ich hier bastele und nutze.
Eigentlich ist es halbwegs simpel:
UDP 500: hierüber wird die IPSec-Vorgehensweise ausgehandelt und die NAT-Detection gemacht.
Wenn kein NAT, wird IP-Protokoll 50 verwendet, was keinen Port braucht.
Wenn NAT, dann wird Protokoll UDP mit Port 4500 verwendet, was dadurch NAT-able wird, da ja ein Port vorhanden ist.
In jedem Fall landen die Pakete damit am IPSec-Server, der sie entschlüsselt, und an Port 1701 weitergibt.
UDP 1701: hier lauscht der L2TP-Server und schiebt die Pakete ins lokale Netz.
So, damit bleibt nur noch eine Frage: der L2TP-Server läuft mit eigener IP-Adresse, die ich bspw. im Secret oder im Profil zuweise. Aber es scheint ziemlich gleich zu sein, ob ich hier eine IP-Adresse des Routers (also bspw. 192.168.1.1), eine IP-Adresse aus seinem Netz (192.168.1.5) oder einen Pool zuweise. Nur leer lassen darf ich sie nicht. Welche Funktion hat sie? Was kann ich damit aktiv beeinflussen?
Schönen Abend!
- michacgn
Ich will doch wissen, was ich hier bastele und nutze.
Warum nutzt du dann nicht viel aktiver mal den Wireshark ??? Ist doch immer dein allerbester Freund bei sowas !Welche Funktion hat sie? Was kann ich damit aktiv beeinflussen?
Stelle dir das VPN wie eine virtuelles IP Interface eines Routers vor, was es ja quasi auch ist. Interfaces müssen immer in eigenen IP Netzen arbeiten oder man nutzt unnumbered Interfaces.
@aqui, ich danke Dir herzlich!
Immer gerne ! 🙂
