MikroTik über LBS steuern | Edomi

[jonofe]

Also ich glaube dass das mit den Netmasks so nicht notwendig ist. Ich habe bei mir auch mehrere Netz 192.168.x.0/24 und die sehen sich auch mit einer Netmask von 255.255.255.0. Ist nur eine Frage des Routings. Hast du mal ein "/ip route print" gemacht? Welche Einträge gibt es denn dort für 192.168.10.0 und 192.168.20.0?

[saegefisch]

Interessant, ich hätte mit der Netzmaske etwas anderes erwartet - habe das Prinzip der Maske wohl dann doch nicht so recht verstanden, denn ich dachte, es wäre genau dafür da (maskieren der anderen IP-Bereiche). Okay, dann ist das wohl nur ein Nebenschauplatz, die /16 tut ja jetzt erst einmal auch nicht weh.
Bleibt die Frage nach dem "zu wenig routing" an einem Switch und "zu wenig routing", wenn an RB und hAP...

Flags: X - disabled, A - active, D - dynamic,
C - connect, S - static, r - rip, b - bgp, o - ospf, m - mme,
B - blackhole, U - unreachable, P - prohibit
 #      DST-ADDRESS        PREF-SRC        GATEWAY            DISTANCE
 0 ADS  0.0.0.0/0                          192.168.1.2               1
 1 ADC  192.168.1.0/24     192.168.1.1     ether06-WAN               0
 2 ADC  192.168.2.0/24     192.168.2.1     bridge                    0
 3 ADC  192.168.10.0/24    192.168.10.1    bridge-vlan010            0
 4 ADC  192.168.20.0/24    192.168.20.1    bridge-vlan020            0
 5 ADC  192.168.30.0/24    192.168.30.1    bridge-vlan030            0
 6 ADC  192.168.80.0/24    192.168.80.1    bridge-vlan080            0
 7 ADC  192.168.100.0/24   192.168.100.1   bridge-vlan100            0

192.168.1.x ist bei mir die DMZ (DHCP der FritzBox. FB ist 192.168.1.2. RB3011 ist 192.168.x.1).
192.168.2.x ist das Managment-VLAN der MikroTiks.

Nachtrag: Wenn man Switch->VLAN die Access-Ports klar differenziert, d.h kein Port liegt in 2 VLAN, dann sehen sich die beiden PC auch nicht mehr, obwohl am selben Switch. Doch obwohl in VLAN010 und VLAN020 switch1-cpu enthalten ist, scheint der Traffic dennoch nicht ins Routing/FW zu kommen. Ich hatte im Switch es immer so verstanden: Wenn im VLAN die CPU enthalten ist, dann wird geroutet - ist aber wohl doch nicht so...

Lesson-Learned: Nein, kein /16-Netzmaske versuchen; dann geht eine ganzer Sack Krams nicht mehr sauber. Die /24, wie im Script ist korrekt.

[saegefisch]

...wieder ein Stück weiter: Habe meine Grundinstallation wieder eingespielt per Script - mit /24-Netzmaske... Jetzt kann (scheint es) reproduzierbar so zu sein, dass wenn im Switch-VLAN die Switch-CPU enthalten ist, der Traffic (doch) in der FW zu sehen ist. Das ist gut; warum auch immer ich oben was etwas anderes zu sehen bekam. Naja, im Zweifel sitzt das Problem vor dem BS...

Danke André für Deinen Hinweis mit der Netzmaske und dass das bei Dir mit /24 geht. Das war mal wieder entscheidend, nicht aufzugeben.

Nun kann ich per Regel 192.168.10.0/24 zu 192.168.20.0/24 sprechen lassen und sehe bei PING oder SMB auch die Pakete in der FW-Regel hochzählen und sehe auch bei Bedarf im Log die Pakete mit korrekten src/dst-IP. Yippie

Frage: Doch kommt nichts zurück. Ist es nicht so, dass man sich bei der FW nie um den Rückkanal kümmern muss, weil der in der "accept established, related" implizit enthalten ist, wenn der Hinweg per Regel erlaubt wurde? In der Regel ist sonst auch keinerlei Einschränkung (kein Port, Protokoll, etc.).
Was könnte der Grund sein, dass die Accepted hochzählt, aber die PCs per SMB oder PING keine Rückmeldung/Connect hin bekommen. Auch dann, wenn dahinter kein Drop/andere Regel mehr kommt...
Stecken beide in 192.168.10.x, geht SMB und PING sofort.

Regel: Chain: forward | src: 192.168.10.0/24 | Dst: 192.168.20.0/24 | action: accept

[stonie2oo4]

Also ich kenn mich auch nicht so gut damit aus. Bei mir ist auch das meiste über try & error entstanden.
Vielleicht mal noch ne zweite Regel anderst herum:

Chain: forward | src: 192.168.10.0/24 | Dst: 192.168.20.0/24 | action: accept
Chain: forward | src: 192.168.20.0/24 | Dst: 192.168.10.0/24 | action: accept

Ich mach das bei mir mit den VLANs immer über In.Interface und Out.Interface, also komplett ohne Adressen. Außer ich wills weiter einschränken.
Also in deinem Fall dann In.Interface=VLAN10 und Out.Interface=VLAN20. Geh mal davon aus das das 10er Netz = VLAN10 ist und das 20er = VLAN20 .

Ich vermute jetzt einfach mal das bei SMB bestimmte Ports in beide Richtungen offen sein müssen???

[saegefisch]

danke, stonie2004. Die Regel hatte ich auch schon drin, zählt aber leider nicht hoch. Ich habe dann nachgelesen und kam zu Ergebnis, dass der Rückweg (wohl) über "accepted established, related" läuft, man sich also eigentlich dazu keine Gedanken machen muss. Irgendwie glaube ich fast, es hat auch nichts mit der FW selber zu tun. Daher kam ich ja auch auf die Idee mit der Erweiterung der Netzmaske...

[jonofe]

Wenn du nur von VLAN10 nach VLAN20 erlauben möchtest, dann brauchst du mMn zwei Regeln

1. IN=VLAN10 OUT=VLAN20 => ACCEPT
2. IN=VLAN20 OUT=VLAN10 related,established => ACCEPT

EDIT: Noch eine Frage: Du schriebst oben, dass du VLAN10 und VLAN20 nun miteinander sprechen lassen kannst. Und danach "Es kommt nichts zurück". Das war für mich jetzt etwas widersprüchlich. Aus dem ersten Statement habe ich interpretiert, dass es nun geht. Nach dem zweiten Statement war ich mir nicht mehr so sicher. :-)

EDIT2: Wenn du natürlich ganz oben in der forward chain eine generische related/established Regel hast, dann greift die natürlich und dort werden dann die Paketzähler hochgezählt, wenn Antworten von VLAN20 zurückkommen.

[saegefisch]

Lessons-learned - jetzt geht es:
* Netzmaske keinesfalls auf was anderes als /24 setzen --> gaaaaanz viele, doofe, langwierige Nebeneffekte -> nicht ratsam! :-/
* Eine solche Regel funktioniert hinreichend: Chain: forward | src: 192.168.10.0/24 | Dst: 192.168.20.0/24 | action: accept
* Nein, eine Gegelregel ist NICHT erforderlich, wenn man den Verkehr nicht explizit so auch haben möchte (im Konstrukt von höherwertigen und niederwertigen VLAN eher nicht). also NICHT nötig ist: Chain: forward | src: 192.168.20.0/24 | Dst: 192.168.10.0/24 | action: accept
* JA, es ist erforderlich eine Regel "Chain: forward | related, established | Action: accept". Die Darf mE auch ganz ohne in/out-Zusatz kommen, da ja nur erlaubte und etablierte Regeln damit zurück liefern können und die wirkt als Rückweg für alle erlaubten Regeln und man barucht daher nur eine davon. Denn die obige Regel ist hinreichend, um eine scharkantige Kommunikation aus VLAN 10 in VLAN 20 zu erlauben, nicht aber anders herum. Eine globale "accept releated, established" stellt den Rückweg zu jeder erlaubten Regl sicher.

Zusätzlich zu beachten (DAS war mein Problem der letzen Stunden):
* Die Firewall in den Clients (hier: Windows mit Windows Defender Firewall) verhindert ohne Eingriff wohl die Kommunikation mit IP-Adressen außerhalb der Netzmaske. Daher zeigt die Router-FW sauber die accepted-Pakete. Doch sehe ich faktisch keine Ping-Antwort oder SMB-Antwort auf die (aus Sicht des Routers erfolgreich zugestellten Pakete), weil die Windows-Firewall eine Antwort verhindern. Legt man auf beiden PC eine zusätzliche Regel und erlaubt eingehend/ausgehend 192.168.0.0/16, dann geht SMB und PING wunderbar.

@jonofe: Kannst Du bestätigen, dass Clients außerhalb der /24-Netzmaske ohne manuelle Eingriffe nicht mitteinander reden wollen? Wie konntest Du es verhindern oder hast Du schlicht architektonisch das Thema nicht?

Stellt sich die Frage: Wie kann man den lokalen Firewalls - ohne an jedem Geräte lokale Regeln anlegen zu müssen - im LAN klar machen, dass man 192.168.0.0/16 vertraut und der Router sich um die Sicherheit kümmert?

Werde diese Erkenntnisse die Tage wieder in ein MikroTik-Script kippen für einen möglichen Firewall-Ansatz mit VLAN. Dann liefern die Scripte ein rundes und kommentiertes Bild für ein lauffähige Lösung, die sich jeder nach Bedarf anpassen kann. Version 6.41 ist übrigens mittlerweile stable/current, nicht mehr RC.

[saegefisch]

...was bin ich froh, wenn der MT endlich final geht und ich endlich wieder edomi machen kann...

...eine (hoffentlich letzte) Frage dazu noch: Der MT hängt hinter einer Fritzbox (192.168.1.x = DMZ). Ziel ist, dass ich aus den MT-Netzen, z.B. 192.168.10.x auf die FB zugreifen kann (für Config). FW-Regeln passen bereits, aber nehmen wir mal vereinfachend an, alle FW-Regeln sind aus (NAT bleibt aktiv)

• A) Ping aus dem MT-Terminal zur FB geht -> OK
• B) Ping von einem PC hinter dem MT: keine Ping-Antwort (Grund unbekannt) -> nicht OK

--> Was muss man tun, damit ein Client hinter dem MT auf die FB in der DMZ zugreifen kann? NAT? Aber eigentlich ist der Ping ja schon mit der korrekten IP versehen? Route? Ist bei mir alles dynamisch.
--> Wie kann man die Ursache ermitteln? Tools?

[jonofe]

@jonofe: Kannst Du bestätigen, dass Clients außerhalb der /24-Netzmaske ohne manuelle Eingriffe nicht mitteinander reden wollen? Wie konntest Du es verhindern oder hast Du schlicht architektonisch das Thema nicht?

Wenn die Netzmaske korrekt auf /24 (255.255.255.0) definiert ist, sind es vollständig getrennte Netze.

Bsp.: Du hast an einem physischen Switch 2 Geräte:

Gerät A mit IP 192.168.10.x
Gerät B mit IP 192.168.20.x.

A und B sehen sich somit nicht und auch der Switch löst dieses Problem nicht, denn er routet nicht zwischen Netzen. A und B haben aber jeweils eine Defaultroute, welche auf das Gateway des entsprechendes Netzes eingestellt ist, d.h.

Gateway A: 192.168.10.1
Gateway B: 192.168.20.1

Sendet A nun ein Ping zu B, dann geht dieser Traffic erst via Switch zum Router (Mikrotik oder Fritzbox oder whatever). Dort ist nun eine Route notwendig, damit die beiden Netze miteinander sprechen können. Ist diese Route nicht da, dann versucht der Router die Pakete gemäß seiner Defaultroute in Internet zu routen, wo sie natürlich aufgrund der internen IPs am ersten Router des Internetproviders verworfen werden.

In Kurzform: Ich würde nicht sagen, dass "manuelle Eingriffe" notwendig sind, aber zumindest eine korrekte Konfiguration.

Stellt sich die Frage: Wie kann man den lokalen Firewalls - ohne an jedem Geräte lokale Regeln anlegen zu müssen - im LAN klar machen, dass man 192.168.0.0/16 vertraut und der Router sich um die Sicherheit kümmert?

Die Frage ist ja: Benötigt man lokale Firewalls? Bei uns auf der Arbeit haben wir ca. 320.000 Desktops und 50.000 Server. Da gibts keine lokalen Firewalls. Wenn die Netze gut gemanaged sind, dann sollte das auch nicht notwendig sein. Und support-technisch wäre das echt aufwändig. Daher habe ich auch bei mir keine lokalen Firewalls.

Anders siehts natürlich mit Virenscanner u.ä. aus.

[jonofe]

B) Ping von einem PC hinter dem MT: keine Ping-Antwort (Grund unbekannt) -> nicht OK

Ha, das ist genau das was ich im letzten Post geschrieben habe.

Bsp:
Die Fritzbox hat IP 192.168.1.2 und du pingst von einem 192.168.10.x.
Dein MT weiss, wie er die FB erreicht, also kommt das Paket dort an.
Jetzt will die FB die Antwort senden. Sie kennt aber nur zwei Regeln:

1. Netz 192.168.1.0/24 zurück an MT
2. Alles andere per Default Route ins Internet.

Also geht die Antwort auf dein Ping ins Internet und wird am ersten Router verworfen.

Lösung:
Statische Routen in der FB für alle internen Netze (bzw. für die, aus denen eine Kommunikation zur FB möglich sein soll) anlegen mit Gateway 192.168.1.1 (MT). Danach sollte es funktionieren.

[saegefisch]

Danke, André!
Zum Thema lokale FW: Nachvollziehbar. Denk' ich mal drüber nach. Erledigt.
Zum Thema Route: Ach, das hört sich immer so logisch an, aber im Detail ist's manchmal nicht leicht, wenn es nicht das tägliche Brot ist... aber ich bin nah dran...

Du meinst eine Route in der FB, damit die FB eine 3 Lösung kennt? An eine Einstellung in der FB hatt ich gar nicht gedacht... kaum trägt man eine statische IPv4-Route dort ein (192.168.10.0 | 255.255.255.0 | 192.168.1.1), geht der Ping und auch der Web-Zugang aus dem MT auf die FB. Wow! Dann darf ich bald wieder edomi machen...

"Isch habb' da druff gedrücktt... und der GEHT!!!"
"Hat der alte Hexenmeister sich doch einmal weg begeben, nun sollen seine Geister..."

[Janncsi]

@saegefisch
Wollte dir nur sagen, dass ich sehr aufmerksam mitlese, was du schreibst. Bei mir laufen zwar mittlerweile die Vlans, aber genau das Trennen und Erlauben mittels Firewall funktioniert bei mir noch nicht sauber. Ich habe es aktuell über die statischen Routen gelöst, die aber in einem Fall trotzdem keine Verbindung erlauben. Dein Weg ist, meiner Meinung nach, deutlich sauberer...

Werde ihn, wenn ich mit meiner Visu n Stück weiter bin, gerne mal aufgreifen, auch mit Hilfe deiner Skripte. Vielen Dank dafür!!!!

[jonofe]

Wow! Dann darf ich bald wieder edomi machen...

Na das ist doch das eigentlich Ziel

"Isch habb' da druff gedrücktt... und der GEHT!!!"

sehr cool !!!

[saegefisch]

Janncsi : Gerne! Und danke für Deine Rückmeldung; schön zu sehen, dass es anderen hilft, seine Lernkurve weiter zu geben. Kommentiertes Script für FW kommt auf jeden Fall auch. Habe auch die meisten Fälle aus dem MT-Wiki durchgearbeitet und dort notiert (zum Teil aber inaktiv, da für mich nicht relevant); da kann sich dann jeder selbst nach Bedarf bedienen.

jonofe : Aber erst mal müssen die kommenden Tage rund 45 Geräte jetzt umziehen...dann darf ich edomi machen. Aber so nah dran war ich schon lange nicht mehr...

Nachtrag: Statt der statischen Route in der FB kann man auch einen 2. NAT-Regel dafür anlegen, um z.B. VLAN010 <-> DMZ zu "natten". Geht auch wunderbar.

[coliflower]

Bei mir laufen zwar mittlerweile die Vlans, aber genau das Trennen und Erlauben mittels Firewall funktioniert bei mir noch nicht sauber.

Grundsätzlich, wenn die Firewall eine stateful-FW ist, dann ist per Design der Verkehr "in" die FW über einen Port aus WAN ins LAN/VLAN oder aus LAN (VLAN) in WAN oder ein anderes VLAN, immer blockiert. Eine extra Blockade der Daten ist nicht notwendig.

Dh., wenn du einem Client/User in einem bestimmten VLAN ins WAN (Internet) oder in ein anderes VLAN erlauben möchtest, dann muss du eine Regel in dem VLAN aus dem du auf ein anderes Netz (WAN/VLAN) zugreifen möchtest, erstellen.

Ist zwar nicht MT (sondern pfSense) aber hier ein Beispiel um zB aus VLAN50 auf bestimmte Internetseiten auf bestimmten Kontinenten zugreifen zu können, danach um auf bestimmte Dienste ... Derzeit habe ich noch am Ende eine Regel um auf alles zugreifen zu können ... Du siehst, bei einer stateful Firewall braucht man nichts extra blocken, sondern nur erlauben - wichtig, die Reihenfolge der Regeln.

Bildschirmfoto 2018-01-04 um 11.16.59.png

Hier noch ein Beispiel für den WAN-Port:

Bildschirmfoto 2018-01-04 um 11.32.04.png