MikroTik über LBS steuern | Edomi

[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.

[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?

[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.

[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]

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...

[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]

...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

[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.

[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]

Hey André,

vielen Dank für Deine Gedanken - ich wünschte, ich hätte auch nur einen kleinen Teil Deines gesunden Halbwissens...

• Die DHCP-Server liefern bereits für jedes VLAN nach meinem Verständnis korrekte GW-Daten an die Clients und hAP. Ich komme aus allen VLAN korrekt ins WWW inkl. DNS auf Port 53. Und per FW kann ich das auch für jedes VLAN oder einzelne IP unterbinden/erlauben --> sollte sauber funktionieren.
• Grundsätzlich möchte ich von den höherwertigen VLAN in die niederwertigen VLAN zugreifen können, nicht aber anders herum. Z.B: vom "inneren Zirkel" auf meine Kodi-Clientes, die aber nicht auf meinen inneren Zirkel.
• Die VLANs resultieren durch die DHCP-Server letztlich in IP-Adressebereichen - nicht zuletzt an den Access-Ports - daher auch die Netzmasken-Relevanz (nach meinem Verständnis): VLAN010 -> 192.168.10.1/24 | VLAN020 -> 192.168.20.1/24 | ...
• Zur FW: Nach meinem Verständnis ist erst einmal alles erlaubt im RB. Wenn ich alle FW-Regeln deaktiviere, müsste ich von VLAN zu VLAN kommunizieren können (wenn die Netzmaske der Clients groß genug ist). Da ich in der FW am Ende jeder Chain immer einen Drop vorsehe ist hingegen nur genau das erlaubt, was ich zuvor als Regel erlaube. Aber zu meinen 2. und 3. Spiegelstrich: die FW scheint ja gar nicht gefragt zu werden.
• Zur Netzmaske: Nach meinem Verständnis muss z.B. ein Windows-PC 192.168.10.10 eine /16-Netzmaske haben, damit er einen anderen PC 192.168.20.11 sehen kann. Die übliche /24 würde das sonst verhindern, selbst wenn der Router die beiden erfolgreich routen würde. Damit sich die beiden sehen können, muss beides erfüllt sein: Der Router routet und die Netzmaske der Clients unterbindet nicht das gegenseitige Sehen, oder? Und weiter denke ich nicht, dass das etwas mit dem Switch oder der Switch HW zu tun hat (die machen ja eigentlich Layer 2). Und darum bin ich ja so überrascht, dass der Inter-VLAN-Traffic im Switch zu laufen scheint, den VLAN ist doch Layer 3 - dachte ich.
• Im 2. Punkt vermute ich genauso wie Du: Läuft über Switch HW. Aber wie kann ich erreichen, dass nur VLAN-intern über Switch HW läuft, aber inter-VLAN zwangsweise geroutet wird und damit die FW auch erreicht?
• Zum 3. Punkt: Wie gesagt, ins WWW wird korrekt aus jedem VLAN geroutet, egal ob der Client am RB oder einem hAP (LAN oder WLAN) angebunden ist. Daher nahm ich an, dass es nicht an fehlenden Routen liegen kann, die ja offensichtlich durch den Trunk-Port vom hAP zum RB funktionieren. Fakt ist aber, dass die beiden Clients ins WWW können, sich eben nicht sehen, wenn einer am RB und einer am hAP angebunden ist.

[jonofe]

Ist zwar schwierig sich in eine komplett unterschiedliche Konfiguration reinzudenken, aber hier mal das was mir beim Lesen deiner Punkte durch den Kopf ging:

• Den ersten Punkt habe ich nicht verstanden. Warum ist die netmask wichtig dafür, dass sich die VLANs sehen? Ich vermute dies ist nur nötig, weil die Kommunikation direkt über den Switch HW Chip läuft, richtig? Denn ansonsten würde das Routing ja sicherstellen, dass sie sich sehen. Oder?
• Das du in Torch nichts siehst liegt ggf. daran, dass die Kommunikation über den Switch HW Chip läuft und nicht über den Router und der Router die Pakete dann gar nicht sieht.
• Beim dritten Punkt könnte es am fehlenden Routing im RB liegen. Wenn dort ein Paket von VLAN10 (hAP) zu VLAN20 (RB) ankommt, muss der Router natürlich wissen, wohin er es Routen soll. Eigentlich sollte diese Routes ja dynamisch angelegt werden. Das könntest Du in /ip route prüfen. Außerdem ist wichtig, dass das default Gateway für die VLAN korrekt ist, d.h. 192.168.10.1 für VLAN10 und und 192.168.20.1 für VLAN 20. Weiterhin muss in der forward chain der traffic von VLAN10 zu VLAN20 und umgekehrt erlaubt sein, aber das ist ja der Fall, wenn ich dich richtig verstanden habe.

Wie gesagt, sind nur Vermutungen auf Basis meines gesunden Halbwissens.

In diesem Sinne: Frohes Neues

[saegefisch]

...aber auf der anderen Seite dachte ich, dass man mit "Torch" und Fleiß das Thema Firewall für die VLAN lösen kann - denn ohne ergibt VLAN ja überhaupt keinen Sinn. Doch nun zerschelle ich an der Firewall:

• Die Netzmasken für die DHCP-Server der VLAN habe ich von /24 auf /16 geändert, da sich die Geräte sonst nicht sehen. Richtig? Gedanke wäre: Das muss sein, damit sich die Geräte VLAN-übergreifend technisch sehen können. Alles andere soll in der FW alles gedropped werden, außer aktiv erlaubter Verkehr z.B. von VLAN010 nach VLAN020, aber nicht von VLAN020 nach VLAN010.
• Wenn ich z.B. ein 192.168.10.10 (VLAN010) und ein 192.168.20.11 (VLAN020) an einem Switch habe, dann sehe ich in Torch nicht einmal den Traffic, obwohl die beiden sich sehen (Ping, SMB). Es ist ja gewünscht, dass der VLAN-interne Traffic auf Switch-HW läuft. Aber wie stelle ich sicher, dass VLAN-übergreifender Traffic auch über die FORWARD-Regeln der FW laufen und nicht daran vorbei. Oder habe ich falsch geschaut?
• Wenn die die beiden Geräte z.B. am RB und am hAP anschließe, dann sehen sich die beiden nicht gar nicht (weder Ping, noch SMB) und sehe schon wieder kein Traffic in Torch am Trunk-Port zwischen hAP und RB. Ich nahm an, der Verkehr würde über den Trunk vom hAP an den RB gehen und würde dort über die FW laufen. Und wenn man ihn nicht aktiv dropped, dann sollten sich beide Geräte an Ihren VLAN010 und VLAN020-Access-Ports auch sehen können. Oder habe ich falsch geschaut?

Bin für einen Tipp dankbar, wo mein Gedankenfehler liegt...

[saegefisch]

Nachtrag zu meinen Scripten: Bei meinem 1. Wurf habe ich das Aufräumen irgendiwe völlig (unsinnig) überkonstruiert. Habe meine Scripte jetzt vereinfacht; jeder kann sich die Scripte für sich und die anderen Scripte auch anpassen. Am Beispiel von "31 - RB3011 Firewall.rsc" sieht das bei mir jetzt so (viel schlanker) aus:

#### erst aufräumen...
{:log info "Remove IP FIREWALL ADDRESS-LIST before creation - Script Start"
:foreach obj in=[/ip firewall address-list find] do={
                 /ip firewall address-list remove $obj }
:delay 3
}
#### aufgeräumt!
#### erst aufräumen...
{:log info "Remove IP FIREWALL FILTER before creation - Script Start"
:foreach obj in=[/ip firewall filter find action!=passthrough] do={
                 /ip firewall filter remove $obj }
:delay 3
}
#### aufgeräumt!

[stonie2oo4]

Habt ihr eigentlich nen eigenen Benutzer für den LBS angelegt?
Wäre ja denk ich mal sicherer als den Admin-Benutzer zu nehmen.
Wenn ja, was für "Policies" würde dieser benötigen. Reicht "api" hier aus?

Unter Services hatte ich alles außer Winbox und ssh deaktiviert. Jetzt gibts da "api" und "api-ssl".
Funktioniert mit dem LBS beides? Ist es dann besser "api-ssl" zu verwenden oder ist es egal, da es ja vom eigenen Lan aus kommt?

Gruß und frohe Weihnachten

[saegefisch]

Nein, das wird es nicht, weil es bis 6.40 das Konzept der Master-Ports gibt. Der RC und die kommende Version 6.41 haben diese Option nicht mehr, sondern nutzen eine Funktion, sie sich HW-offload nennt. Es dient dazu, recht einfach und vom Router im wesentlichen selbst erkannt den möglichen Switch-Verkehr (der nicht geroutet werden muss auf Layer 3 = IP) über die Switch-Chips auf Layer 2 laufen zu lassen. Das ist schneller und sparsamer und braucht die Master-Paramete nicht mehr. Man kann das im wesentlichen durch eine geschickte Wahl der Ports unterstützen.
Der Weg von Mikrotik scheint darüber hinaus im Ausblick in Richtung der VLAN an den Bridges zu gehen, was die EInrichtung vereinfachen würde - aber das ist wohl noch Zukuntfsmusik.

Kurz: Nein, für 6.40 können die Scripte als Ideengeber dienen, aber schon im 10er-Script fehlen wesentliche Parameter für die Master-Ports in 6.40. Du kannst Sie aber auf 6.40 leicht anpassen - dazu gibt es viele Beispiele im WWW (z.B. die beiden Links in meinem Beitrag oben). Die Videos im Router-Forum von Mod "CapFloor" z.B. beziehen sich derzeit noch auf 6.40.

Und: Ich konnte meine login-Probleme nun auch woanders verorten - daher sehe ich nun kein Problem mehr, neben den Packages auch die Firmware anzuheben. Am Ende gilt dazu aber immer: JEDER ist dafür selbst verantwortlich, was er tut. Ich kann dazu weder raten, noch abraten. Ich kann nur von meinen Erfahrungen berichten. Erfahrungen machen muss letztlich jeder selber. Und: IMMER Backup vorher. Und bei produktiven Systemen ggf. warten, bis 6.41 im stable bereit steht.