7
Mikrotik IPSec Firewall Rules Interface
Guten Morgen 
Wie ich weiß, gibt es hier ja auch einige Mikrotik Freaks. Ich bin vor kurzem bei einem IPSEC Site2Site Tunnel nachdenklich geworden, was die Firewall Rules für IPSec angeht.
Man kennt es ja von anderen Systemen wie PFSENSE etc., dass IPSEC Interfaces seperat behandelt werden bzw. es ein Interface im System gibt. Wie bei OpenVPN z.B. auch. Bei Mikrotik ist dieses ja nicht so.
Ich habe einen MT am WAN mit eth1, eth1 hält quasi die öffentliche IP.
Nun zum eigentlichen "Problem" mit den FW Rules:
Auf eth1 habe ich alles für IPSEC notwendige Freigegeben, passend auf source IP der Gegenseite etc. #1(input chain)
Dann gibt es eine weitere Regeln welche IPSEC Traffic in die dahinter liegend Netzte entsprechen erlaubt. #2(forward chain)
Noch eine Regel für established, related #3(forward chain)
Am Ende stehen die Block Regeln für Input,Forward,Output Chain.
Soweit alles gut, nun brauchte ich noch zwei weitere Regeln. Zum einen für Winbox und zum anderen für SNMP monitoring. Diese habe ich auf eth1 als input accept angelgt, gefiltert auf den source Bereich des Management Netzes. Klappt auch alles.
Kann man das besser lösen? Bin ich auf dem Holzweg ? Oder geht es bei MT nicht anders?
Danke für eure Antworten
Wie ich weiß, gibt es hier ja auch einige Mikrotik Freaks. Ich bin vor kurzem bei einem IPSEC Site2Site Tunnel nachdenklich geworden, was die Firewall Rules für IPSec angeht.
Man kennt es ja von anderen Systemen wie PFSENSE etc., dass IPSEC Interfaces seperat behandelt werden bzw. es ein Interface im System gibt. Wie bei OpenVPN z.B. auch. Bei Mikrotik ist dieses ja nicht so.
Ich habe einen MT am WAN mit eth1, eth1 hält quasi die öffentliche IP.
Nun zum eigentlichen "Problem" mit den FW Rules:
Auf eth1 habe ich alles für IPSEC notwendige Freigegeben, passend auf source IP der Gegenseite etc. #1(input chain)
Dann gibt es eine weitere Regeln welche IPSEC Traffic in die dahinter liegend Netzte entsprechen erlaubt. #2(forward chain)
Noch eine Regel für established, related #3(forward chain)
Am Ende stehen die Block Regeln für Input,Forward,Output Chain.
Soweit alles gut, nun brauchte ich noch zwei weitere Regeln. Zum einen für Winbox und zum anderen für SNMP monitoring. Diese habe ich auf eth1 als input accept angelgt, gefiltert auf den source Bereich des Management Netzes. Klappt auch alles.
Kann man das besser lösen? Bin ich auf dem Holzweg ? Oder geht es bei MT nicht anders?
Danke für eure Antworten
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: 586180
Url: https://administrator.de/contentid/586180
Ausgedruckt am: 19.11.2024 um 23:11 Uhr
7 Kommentare
Neuester Kommentar
Würde ich dir mal ans Herz legen
https://help.mikrotik.com/docs/display/ROS/Building+Advanced+Firewall
https://help.mikrotik.com/docs/display/ROS/Building+Advanced+Firewall
am WAN mit eth1, eth1 hält quasi die öffentliche IP.
Zum einen für Winbox und zum anderen für SNMP monitoring. Diese habe ich auf eth1 als input accept angelgt,
Winbox und SNMP auf dem WAN-Port??Zum einen für Winbox und zum anderen für SNMP monitoring. Diese habe ich auf eth1 als input accept angelgt,
Zitat von @144705:
Würde ich dir mal ans Herz legen
https://help.mikrotik.com/docs/display/ROS/Building+Advanced+Firewall
Würde ich dir mal ans Herz legen
https://help.mikrotik.com/docs/display/ROS/Building+Advanced+Firewall
am WAN mit eth1, eth1 hält quasi die öffentliche IP.
Zum einen für Winbox und zum anderen für SNMP monitoring. Diese habe ich auf eth1 als input accept angelgt,
Winbox und SNMP auf dem WAN-Port??Zum einen für Winbox und zum anderen für SNMP monitoring. Diese habe ich auf eth1 als input accept angelgt,
Die Betonung liegt hier bei: gefiltert auf die entsprechenden source Netze. Ich mache doch nicht snmp und winbox aufm WAN interface offen. Vielleicht samstags Nacht's nach einer Flasche Vodka, aber sonst nicht.
Schon klar aber warum überhaupt auf die WAN IP gebunden, das ist doch Verquer...?!
Ich mache doch nicht snmp und winbox aufm WAN interface offen. Vielleicht samstags Nacht's nach einer Flasche Vodka, aber sonst nicht.
Besser dafür eine dedizierte IP LAN intern verwenden und nicht die IP des WAN-Ports. Das fliegt dir sonst bei einem Flüchtigkeitsfehler schnell mal um die Ohren.
Vielleicht samstags Nacht's nach einer Flasche Vodka, aber sonst nicht.
Dann hast du auch eh vergessen wer oder was Mikrotik ist... 
Bei Mikrotik ist dieses ja nicht so.
Richtig, weil es Regeln auf iptables Basis verwendet. Ist aber nur ein rein kosmetischer Unterschied. Auf eth1 habe ich alles für IPSEC notwendige Freigegeben
Das ist vollkommen unnötig wenn man intelligenterweise die Firewall Einstellungen der Default Konfig übernimmt. Dort gibt es entsprechende Regelwerke für IPsec.Wichtig ist nur das man den Tunnel Traffic IMMER aus dem NAT ausnimmt, was man in der Firewall unter NAT einstellt. Das hat aber mit den eigentlichen Firewall Regelwerken nichts zu tun:
IPsec IKEv2 Standort VPN Vernetzung mit Cisco, pfSense OPNsense und Mikrotik
Am Ende stehen die Block Regeln für Input,Forward,Output Chain.
Zum einen für Winbox und zum anderen für SNMP monitoring.
WinBox ist UDP 8291 und SNMP UDP 161 (bzw. zusätzlich UDP 162 wenn du Traps versendest). Das musst du in die Forwarding Regel übernehmen und gut iss... Bin ich auf dem Holzweg ?
Nein, alles richtig gemacht ! Ist auf einem Router ja auch der übliche Weg. Einzig die WinBox Services könnte man auch über die Interface Lists regeln wo die Interfaces definiert werden die Zugriff auf die Konfiguration Services haben sollen. Das geht dann aber nur global und nicht IP oder Netz spezifisch. In sofern also alles OK.
Danke für eure Antworten zunächst.
@aqui: ich habe die defconf leider entfernt
aber ich poste einmal ein screenshot von meinem Regelwerk. Ist es wirklich so, dass die deny rules nicht notwendig sind? Irgendwie schaltet die Kiste auf Durchzug, wenn ich die deaktiviere.
Ich war nur echt ein wenig verwundert, kenne sonst PFSENSE gut. Da ist es ja ein eigenes IF.
Wenn man sich da mal einen Bock schießt bei der Config, hat man ja ratzefatz nach außen ungewollt ports offen Obacht :-O
@144705: Du meinstest eben in deinem Post sicher, die Regeln auf destination IP anzuwenden oder? Das hatte ich natürlich schon getan. Vielleicht etwas blöd beschrieben von mir.
@aqui: ich habe die defconf leider entfernt
aber ich poste einmal ein screenshot von meinem Regelwerk. Ist es wirklich so, dass die deny rules nicht notwendig sind? Irgendwie schaltet die Kiste auf Durchzug, wenn ich die deaktiviere.Ich war nur echt ein wenig verwundert, kenne sonst PFSENSE gut. Da ist es ja ein eigenes IF.
Wenn man sich da mal einen Bock schießt bei der Config, hat man ja ratzefatz nach außen ungewollt ports offen
Obacht :-O@144705: Du meinstest eben in deinem Post sicher, die Regeln auf destination IP anzuwenden oder? Das hatte ich natürlich schon getan. Vielleicht etwas blöd beschrieben von mir.
Ist es wirklich so, dass die deny rules nicht notwendig sind?
Doch, die abschließenden DROP Regeln sind beim Mikrotik nötig! Denn der Default ist beim Mikrotik ohne Rules ACCEPT.Einfach das oben verlinkte Advanced Firewall Tut durcharbeiten dann siehst du was du noch verbessern kannst oder fehlt.
Nur als TIPP, arbeite in der Firewall mit Interface-Listen und zusätzlichen Chains für die Zonen, das macht das Anpassen der Config hinterher wesentlich einfacher wenn sich Dinge ändern. Dann muss man nur noch die Interface-Listen anpassen statt alle Regeln anpassen zu müssen.
ich habe die defconf leider entfernt
Keine Gute Idee, denn die aktiviert auch das Fast Switching...Denn der Default ist beim Mikrotik ohne Rules ACCEPT.
OK, sorry ich dachte das wäre identisch zu Linux, da ist es genau andersrum. Man kann es in den iptables Settings ja da auch einstellen ob man Default Accept oder Deny haben will. Sorry für die verwirrung.
