4
Mikrotik Routing,Firewall und IPSec hinter Fritzbox
Hallo Zusammen,
nachdem ich eigentlich stiller Leser bin ist nun der Punkt gekommen an dem ich mal etwas Hilfe benötige.
Ich habe mein Heimnetz wie auf dem Bild zu sehen aufgebaut bzw. ich befürchte genau diesen großen Mit verzapft:
Ursprünglich hat der Cisco auch das L3-Routing übernommen, das war mir aber zu unflexibel.
Daher hat nun ein MT RB5009 (ROS v7.1.1) seinen Dienst aufgenommen.
Die Verbindung von der FBox geht auf den Switch (VLAN 99 untagged als Koppelnetz) und von dort dann via Trunk auf den MT.
Dort ist der SFP-Port mit den anderen Ports (sind aber nicht angeschlossen) in einer Bridge. Das habe ich so gemacht damit ich das VLAN99 auch durch einen weiteren Trunk an meinen Virtualisierungsserver durchreichen kann.
Soweit so gut, es funktioniert ja auch grundlegend.
Mir kommen nun eigentlich 3 Fragen auf:
1. Die Bridge am MT steht im VLAN1, sollte ich das ändern? Ich nutze das VLAN1 nicht aktiv. Der MT sieht den Cisco aber auch darüber (CDP?)?
Mein Management-VLAN ist eigentlich das VLAN 10.
2. Ich habe eine IPSec-Verbindung (S2S) die ich nur aus dem VLAN70 benötige. Eigentlich sollen Geräte im VLAN70 nur mit der Remote-Site sprechen, ich muss allerdings aus dem VLAN30 auf ein Gerät ins VLAN70 via RDP zugreifen. Wie kann ich den Tunnel quasi erzwingen bzw. macht das überhaupt Sinn wenn ich noch intern darauf zugreifen muss?
Hier die Policy:
3. In Verbindung zu Punkt 2 werde ich mir mit der Firewall nicht ganz klar. Eingerichtet habe ich diese nach MT Advanced Firewall
Meine internen Netze sind (inkl. VLAN99) in einer Interface-Liste, das VLAN70 in einer eigenen Interface-Liste.
Zudem habe ich für die Firewall noch Adresslisten angelegt, diese sind aufgeteilt in "intern" (inkl. VLAN70) und das Remote-Netz 192.168.1.0/24.
Ich habe nun in der RAW-Table folgende Einträge:
Speziell die Zeilen 15-18 machen mir Kopfschmerzen ob das so überhaupt richtig ist.
Vor allem 15/16... muss ich Incoming auf das VLAN70 setzen weil das die Antworten auf die RDP-Anfragen von VLAN30 sind und die RAW-Table keine Verbindungsstati verarbeitet? Ich komme aus "internal" und möchte die Antworten via VLAN70 wieder zurückschicken, korrekt? Oder lese ich das falsch?
Die Zeilen 17/18 kann man dann aber besser absichern oder? Ich möchte diese ja nur in das eine Remote-Netz freigeben, aber ich kann in der RAW-Table kein Zielnetz angeben. Wie könnte man das lösen?
Hintergrund: Ich möchte in das Remotenetz mit meinem Client in VLAN70 (hängt dort in der Domäne) kommen.
Da soll aber nichts auf meine Systeme zugreifen können, daher auch das eigene VLAN. Ich muss nur von meinem Client-Netz VLAN30 via RDP in das VLAN70 greifen können.
Für meinen Frieden und zum Verständnis: Wäre das eigentlich einfacher wenn ein IPSec-Tunnel ein eigenes Interface hätte wie bei Wireguard?
Vielen Dank schonmal im Voraus für Hilfe und Geduld!
nachdem ich eigentlich stiller Leser bin ist nun der Punkt gekommen an dem ich mal etwas Hilfe benötige.
Ich habe mein Heimnetz wie auf dem Bild zu sehen aufgebaut bzw. ich befürchte genau diesen großen Mit verzapft:
Ursprünglich hat der Cisco auch das L3-Routing übernommen, das war mir aber zu unflexibel.
Daher hat nun ein MT RB5009 (ROS v7.1.1) seinen Dienst aufgenommen.
Die Verbindung von der FBox geht auf den Switch (VLAN 99 untagged als Koppelnetz) und von dort dann via Trunk auf den MT.
Dort ist der SFP-Port mit den anderen Ports (sind aber nicht angeschlossen) in einer Bridge. Das habe ich so gemacht damit ich das VLAN99 auch durch einen weiteren Trunk an meinen Virtualisierungsserver durchreichen kann.
Soweit so gut, es funktioniert ja auch grundlegend.
Mir kommen nun eigentlich 3 Fragen auf:
1. Die Bridge am MT steht im VLAN1, sollte ich das ändern? Ich nutze das VLAN1 nicht aktiv. Der MT sieht den Cisco aber auch darüber (CDP?)?
Mein Management-VLAN ist eigentlich das VLAN 10.
2. Ich habe eine IPSec-Verbindung (S2S) die ich nur aus dem VLAN70 benötige. Eigentlich sollen Geräte im VLAN70 nur mit der Remote-Site sprechen, ich muss allerdings aus dem VLAN30 auf ein Gerät ins VLAN70 via RDP zugreifen. Wie kann ich den Tunnel quasi erzwingen bzw. macht das überhaupt Sinn wenn ich noch intern darauf zugreifen muss?
Hier die Policy:
/ip ipsec policy
add action=encrypt disabled=no dst-address=192.168.1.0/24 dst-port=any ipsec-protocols=esp level=require peer=rem01 proposal=FBox protocol=all sa-dst-address=1.2.3.4 sa-src-address=192.168.178.251 src-address=10.83.70.0/24 src-port=\
any tunnel=yes3. In Verbindung zu Punkt 2 werde ich mir mit der Firewall nicht ganz klar. Eingerichtet habe ich diese nach MT Advanced Firewall
Meine internen Netze sind (inkl. VLAN99) in einer Interface-Liste, das VLAN70 in einer eigenen Interface-Liste.
Zudem habe ich für die Firewall noch Adresslisten angelegt, diese sind aufgeteilt in "intern" (inkl. VLAN70) und das Remote-Netz 192.168.1.0/24.
Ich habe nun in der RAW-Table folgende Einträge:
/ip firewall raw
add action=accept chain=prerouting comment="defconf: enable for transparent firewall" disabled=yes
add action=accept chain=prerouting comment="defconf: accept DHCP discover" dst-address=255.255.255.255 dst-port=67 in-interface-list=LAN protocol=udp src-address=0.0.0.0 src-port=68
add action=drop chain=prerouting comment="defconf: drop bogon IP's" src-address-list=bad_ipv4
add action=drop chain=prerouting comment="defconf: drop bogon IP's" dst-address-list=bad_ipv4
add action=drop chain=prerouting comment="defconf: drop bogon IP's" src-address-list=bad_src_ipv4
add action=drop chain=prerouting comment="defconf: drop bogon IP's" dst-address-list=bad_dst_ipv4
add action=drop chain=prerouting comment="defconf: drop non global from WAN" in-interface-list=WAN src-address-list=not_global_ipv4
add action=drop chain=prerouting comment="defconf: drop forward to local lan from WAN" dst-address-list=internal in-interface-list=WAN
add action=drop chain=prerouting comment="defconf: drop local if not from default IP range" disabled=yes in-interface-list=LAN log-prefix=drp_nondef src-address-list=!internal
add action=drop chain=prerouting comment="defconf: drop bad UDP" port=0 protocol=udp
add action=jump chain=prerouting comment="defconf: jump to ICMP chain" jump-target=icmp4 protocol=icmp
add action=jump chain=prerouting comment="defconf: jump to TCP chain" jump-target=bad_tcp protocol=tcp
add action=accept chain=prerouting comment="defconf: accept everything else from LAN" in-interface-list=LAN
add action=accept chain=prerouting comment="accept RDP answers from rem01 VLAN70" dst-port="" in-interface-list=rem01_VL70 protocol=tcp src-address-list=internal src-port=3389
add action=accept chain=prerouting comment="accept RDP answers from rem01 VLAN70" dst-port="" in-interface-list=rem01_VL70 protocol=udp src-address-list=internal src-port=3389
add action=accept chain=prerouting comment="allow udp services to rem01" dst-port=53,88,389,123 in-interface-list=rem01_VL70 protocol=udp src-address-list="" src-port=""
add action=accept chain=prerouting comment="allow tcp services to rem01" dst-port=135,389,636,3268,3269,53,88,445,3389,1024-65535,80,443 in-interface-list=rem01_VL70 protocol=tcp src-address-list="" src-port=""
add action=accept chain=prerouting comment="defconf: accept everything else from WAN" in-interface-list=WAN
add action=drop chain=prerouting comment="defconf: drop the rest" log-prefix=raw_16
add action=drop chain=bad_tcp comment="defconf: TCP flag filter" protocol=tcp tcp-flags=!fin,!syn,!rst,!ack
add action=drop chain=bad_tcp comment=defconf protocol=tcp tcp-flags=fin,syn
add action=drop chain=bad_tcp comment=defconf protocol=tcp tcp-flags=fin,rst
add action=drop chain=bad_tcp comment=defconf protocol=tcp tcp-flags=fin,!ack
add action=drop chain=bad_tcp comment=defconf protocol=tcp tcp-flags=fin,urg
add action=drop chain=bad_tcp comment=defconf protocol=tcp tcp-flags=syn,rst
add action=drop chain=bad_tcp comment=defconf protocol=tcp tcp-flags=rst,urg
add action=drop chain=bad_tcp comment="defconf: TCP port 0 drop" port=0 protocol=tcp
add action=accept chain=icmp4 comment="defconf: echo reply" icmp-options=0:0 limit=5,10:packet protocol=icmp
add action=accept chain=icmp4 comment="defconf: net unreachable" icmp-options=3:0 protocol=icmp
add action=accept chain=icmp4 comment="defconf: host unreachable" icmp-options=3:1 protocol=icmp
add action=accept chain=icmp4 comment="defconf: protocol unreachable" icmp-options=3:2 protocol=icmp
add action=accept chain=icmp4 comment="defconf: port unreachable" icmp-options=3:3 protocol=icmp
add action=accept chain=icmp4 comment="defconf: fragmentation needed" icmp-options=3:4 protocol=icmp
add action=accept chain=icmp4 comment="defconf: echo" icmp-options=8:0 limit=5,10:packet protocol=icmp
add action=accept chain=icmp4 comment="defconf: time exceeded " icmp-options=11:0-255 protocol=icmp
add action=drop chain=icmp4 comment="defconf: drop other icmp" protocol=icmp
add action=drop chain=prerouting dst-address-list=ddos-target src-address-list=ddos-attackersSpeziell die Zeilen 15-18 machen mir Kopfschmerzen ob das so überhaupt richtig ist.
Vor allem 15/16... muss ich Incoming auf das VLAN70 setzen weil das die Antworten auf die RDP-Anfragen von VLAN30 sind und die RAW-Table keine Verbindungsstati verarbeitet? Ich komme aus "internal" und möchte die Antworten via VLAN70 wieder zurückschicken, korrekt? Oder lese ich das falsch?
Die Zeilen 17/18 kann man dann aber besser absichern oder? Ich möchte diese ja nur in das eine Remote-Netz freigeben, aber ich kann in der RAW-Table kein Zielnetz angeben. Wie könnte man das lösen?
Hintergrund: Ich möchte in das Remotenetz mit meinem Client in VLAN70 (hängt dort in der Domäne) kommen.
Da soll aber nichts auf meine Systeme zugreifen können, daher auch das eigene VLAN. Ich muss nur von meinem Client-Netz VLAN30 via RDP in das VLAN70 greifen können.
Für meinen Frieden und zum Verständnis: Wäre das eigentlich einfacher wenn ein IPSec-Tunnel ein eigenes Interface hätte wie bei Wireguard?
Vielen Dank schonmal im Voraus für Hilfe und Geduld!
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 1662411393
Url: https://administrator.de/contentid/1662411393
Printed on: April 24, 2024 at 15:04 o'clock
4 Comments
Latest comment
Vom Design her wäre es dann in der Tat besser den RB5009 in Kaskade mit der FB laufen zu lassen und das Layer 3 Switching auf dem CBS dann im Setup zu deaktivieren und den rein nur als einfachen Layer 2 Switch laufen zu lassen.
Dieses Basis Design beschreibt das hiesige MT VLAN Tutorial.
Den IPsec Tunnel beschreiben dann diverse andere Threads hier im Forum:
Fritz!Box VPN Mikrotik als VPN Client
Hilfe bei OpenVPN Standortvernetzung zwischen pfSense (Server) und Mikrotik (Client)
VPN Performance durch Mikrotik erhöhen
IPsec-Site2Site-Tunnel zwischen zwei MikroTik-Routern, beide MikroTik-Router hinter NAT
Mit dynamischen IP Adressen:
Hilfe bei OpenVPN Standortvernetzung zwischen pfSense (Server) und Mikrotik (Client)
Mit IKEv2
IPsec IKEv2 Standort VPN Vernetzung mit Cisco, pfSense OPNsense und Mikrotik
Oder als L2TP Client Dialin mit IPsec
Scheitern am IPsec VPN mit MikroTik
Denke bei Kaskaden Betreib daran das du die IPsec Protokollkomponenten auf der FritzBox dann per Port Forwarding auf den MT weiterleitest wie es HIER genau beschrieben ist !
Dieses Basis Design beschreibt das hiesige MT VLAN Tutorial.
Den IPsec Tunnel beschreiben dann diverse andere Threads hier im Forum:
Fritz!Box VPN Mikrotik als VPN Client
Hilfe bei OpenVPN Standortvernetzung zwischen pfSense (Server) und Mikrotik (Client)
VPN Performance durch Mikrotik erhöhen
IPsec-Site2Site-Tunnel zwischen zwei MikroTik-Routern, beide MikroTik-Router hinter NAT
Mit dynamischen IP Adressen:
Hilfe bei OpenVPN Standortvernetzung zwischen pfSense (Server) und Mikrotik (Client)
Mit IKEv2
IPsec IKEv2 Standort VPN Vernetzung mit Cisco, pfSense OPNsense und Mikrotik
Oder als L2TP Client Dialin mit IPsec
Scheitern am IPsec VPN mit MikroTik
Denke bei Kaskaden Betreib daran das du die IPsec Protokollkomponenten auf der FritzBox dann per Port Forwarding auf den MT weiterleitest wie es HIER genau beschrieben ist !
Hallo aqui,
das L3-Switching ist auf dem CBS schon aus, ich habe mich auch brav an deine Anleitung gehalten.
Die Weiterleitungen habe ich auf der FBox schon eingerichtet, der Tunnel steht schon.
Im Endeffekt habe ich den MT mit ins Setup genommen weil der CBS keine Prefix-Delegation im IPv6-Umfeld kann.
Daher ist er als Router ausgeschieden. Ohne diese Anforderung wäre er es geblieben.
Ich hatte den Tunnel vorher über eine *sense realisiert, aber da der MT das auch kann soll er das tun ;)
Mir geht es eben konkret um die 3 Punkte meines Posts:
1. Welches VLAN für die Bridge oder egal? - Nachtrag: Das ist eigentlich nur das VLAN in welches untagged-Traffic kommt der an der Bridge ankommt. So habe ich zumindest verstanden. Der sollte natürlich nicht ins MGMT-VLAN.
2. Erzwingung des Tunnels (evtl. auch unsinnig?), quasi ein langes LAN-Kabel vom Remote-Standort zu mir, aber ich eben noch per RDP auf die Maschine komme.
-> Stichwort Policy, die Dst.Address ist hier ausschlaggebend soweit ich das verstanden habe. Wenn ich die auf 0.0.0.0/0 setze dann funktioniert es ja wie gewollt, allerdings komme ich dann vom internen Netz nicht mehr an die Maschine da ja die Antwort über den Tunnel geschickt wird (vermute ich).
3. Habe ich einen Denkfehler in den FW-Regeln bzw. eben etwas vergessen für die Abschottung meines Netzes ggü. dem Remote-Netz?
Bzgl. IPSec schau ich mir gleich mal die Links an, habe zwar schon etwas gekramt aber evtl. finde ich ja mehr heraus.
Vielen Dank erstmal für deine Antwort und Hilfe!
das L3-Switching ist auf dem CBS schon aus, ich habe mich auch brav an deine Anleitung gehalten.
Die Weiterleitungen habe ich auf der FBox schon eingerichtet, der Tunnel steht schon.
Im Endeffekt habe ich den MT mit ins Setup genommen weil der CBS keine Prefix-Delegation im IPv6-Umfeld kann.
Daher ist er als Router ausgeschieden. Ohne diese Anforderung wäre er es geblieben.
Ich hatte den Tunnel vorher über eine *sense realisiert, aber da der MT das auch kann soll er das tun ;)
Mir geht es eben konkret um die 3 Punkte meines Posts:
1. Welches VLAN für die Bridge oder egal? - Nachtrag: Das ist eigentlich nur das VLAN in welches untagged-Traffic kommt der an der Bridge ankommt. So habe ich zumindest verstanden. Der sollte natürlich nicht ins MGMT-VLAN.
2. Erzwingung des Tunnels (evtl. auch unsinnig?), quasi ein langes LAN-Kabel vom Remote-Standort zu mir, aber ich eben noch per RDP auf die Maschine komme.
-> Stichwort Policy, die Dst.Address ist hier ausschlaggebend soweit ich das verstanden habe. Wenn ich die auf 0.0.0.0/0 setze dann funktioniert es ja wie gewollt, allerdings komme ich dann vom internen Netz nicht mehr an die Maschine da ja die Antwort über den Tunnel geschickt wird (vermute ich).
3. Habe ich einen Denkfehler in den FW-Regeln bzw. eben etwas vergessen für die Abschottung meines Netzes ggü. dem Remote-Netz?
Bzgl. IPSec schau ich mir gleich mal die Links an, habe zwar schon etwas gekramt aber evtl. finde ich ja mehr heraus.
Vielen Dank erstmal für deine Antwort und Hilfe!
1.)
Versteht man es richtig geht es dir hier rein nur um die Default PVID auf UNtagged Ports. Also das VLAN in das per Default UNtagged Traffif geforwardet werden soll, richtig ?
Das ist dann eher eine kosmetische denn eine technische Frage. Ist egal und kannst du dir frei aussuchen.
2.)
Ist leider recht unklar was du hier genau meinst ?? Willst du den Tunnelaufbau erzwingen ?? oder willst du Traffic durch den Tunnel erzwingen ?? Etwas wirr...sorry.
Mit der IPsec Phase 2 bestimmst du immer WELCHER Traffic durch den Tunnel geht (Source Netz und Remote Netz). Der wird dann immer geroutet.
Musst du ggf. nochmal erklären was genau du hier meinst.
3.)
Sieht soweit OK aus. Was du allerdings persönlich mit "Abschottung" genau meinst ist ja leider von dir nicht explizit definiert. Folglich kann dir diese Frage deshalb niemand final beantworten.
Versteht man es richtig geht es dir hier rein nur um die Default PVID auf UNtagged Ports. Also das VLAN in das per Default UNtagged Traffif geforwardet werden soll, richtig ?
Das ist dann eher eine kosmetische denn eine technische Frage. Ist egal und kannst du dir frei aussuchen.
2.)
Ist leider recht unklar was du hier genau meinst ?? Willst du den Tunnelaufbau erzwingen ?? oder willst du Traffic durch den Tunnel erzwingen ?? Etwas wirr...sorry.
Mit der IPsec Phase 2 bestimmst du immer WELCHER Traffic durch den Tunnel geht (Source Netz und Remote Netz). Der wird dann immer geroutet.
Musst du ggf. nochmal erklären was genau du hier meinst.
3.)
Sieht soweit OK aus. Was du allerdings persönlich mit "Abschottung" genau meinst ist ja leider von dir nicht explizit definiert. Folglich kann dir diese Frage deshalb niemand final beantworten.
Hallo aqui,
1) Habe ich mir nochmal angesehen, habe die Bridge umgestellt in das Gast-VLAN und die Filterung auf "admit only VLAN tagged". Auf der Bridge kam vorher auch nichts untagged an. Es funktioniert zumindest alles wie es soll.
2) Die Links von dir haben mich auf die richtige Spur gebracht:
- Policy (Phase 2) auf Dst 0.0.0.0/0 und zusätzlich eine "höhere" Policy mit meinem Client-VLAN als Dst ohne Tunnel und Action. Damit werden die Antworten auf Anfragen vom Client-VLAN auch wieder korrekt zurückgeroutet. -> Haken dran
Das hatte ich nur nicht geschnallt bzw. war da etwas zu engstirnig mit der Policy und Src/Dst.
3) Hier war der Hund begraben. Ich hatte den Netzverkehr vom IPSec in der Raw-Table auf "no track" gesetzt. Damit haben meine normalen Filter nicht mehr gegriffen. Ich habe mich auch schon gewundert warum da nichts mehr ankommt. Hatte für die Verbindung ja eben die Rules 15-18 drin. Die haben zwar gegriffen aber ich kam vom Remote-Netz auf mein lokales Netz. Na klar, s. Regel 14, von daher haben die das "no track" wieder deaktiviert und nun greifen auch die normalen Filter sauber und blocken die Verbindung von Remote ab, der Weg von mir zu Remote geht aber wie es soll (established/related eben auch).
Es ist ja zum Glück nichts produktives was lebenswichtig wäre
Aber hier nochmals vielen Dank für den Schubs und deine hervorragende Arbeit für die Community!
Ich verfolge deine Beiträge immer gespannt, auch wenn ich nicht zu 100% durchsteige ;)
1) Habe ich mir nochmal angesehen, habe die Bridge umgestellt in das Gast-VLAN und die Filterung auf "admit only VLAN tagged". Auf der Bridge kam vorher auch nichts untagged an. Es funktioniert zumindest alles wie es soll.
2) Die Links von dir haben mich auf die richtige Spur gebracht:
- Policy (Phase 2) auf Dst 0.0.0.0/0 und zusätzlich eine "höhere" Policy mit meinem Client-VLAN als Dst ohne Tunnel und Action. Damit werden die Antworten auf Anfragen vom Client-VLAN auch wieder korrekt zurückgeroutet. -> Haken dran
Das hatte ich nur nicht geschnallt bzw. war da etwas zu engstirnig mit der Policy und Src/Dst.
3) Hier war der Hund begraben. Ich hatte den Netzverkehr vom IPSec in der Raw-Table auf "no track" gesetzt. Damit haben meine normalen Filter nicht mehr gegriffen. Ich habe mich auch schon gewundert warum da nichts mehr ankommt. Hatte für die Verbindung ja eben die Rules 15-18 drin. Die haben zwar gegriffen aber ich kam vom Remote-Netz auf mein lokales Netz. Na klar, s. Regel 14, von daher haben die das "no track" wieder deaktiviert und nun greifen auch die normalen Filter sauber und blocken die Verbindung von Remote ab, der Weg von mir zu Remote geht aber wie es soll (established/related eben auch).
Es ist ja zum Glück nichts produktives was lebenswichtig wäre
Aber hier nochmals vielen Dank für den Schubs und deine hervorragende Arbeit für die Community!
Ich verfolge deine Beiträge immer gespannt, auch wenn ich nicht zu 100% durchsteige ;)
