MikroTik über LBS steuern | Edomi

[saegefisch]

Mit edomi am MT bin ich gerade völlig ratlos - alles kurios:
* RB3011/1.hAP: edomi hat Ping, WebZugang geht per LAN/WLAN im wesentlichen (man muss gelegentlich die Seite neu aufrufen), ssh per (putty oder MT): OK
* 2. hAP (an dem mein Arbeits-PC hängt): edomi hat schlechten Ping/traceroute, Kein WebZugang erreichbar, ssh per putty geht nicht. Jetzt kommt es aber: ssh per hAP (RouterOS->Tools) geht problemlos! Wie kann ssh per putty (hinter dem hAP) nicht gehen, aber vom hAP selber geht es. FW im hAP habe ich schon komlett abgeschaltet. am PC kann es nicht liegen (AV und FW testweise auch mal abgeschaltet; andern etherxx getetet, LAN-Kabel getauscht). Und auch kurios: ssh per 2.hAP geht, aber im CAP-WLAN des selben hAP dennoch kein WebZugang zu edomi; wohl aber im anderen CAP-WLAN des 1. hAP geht es, wenn man im Haus in den Bereich des 1.hAP kommt
--> vielleicht ist der IP-Umzug edomi (3 Stellen: ifcfg-eth0, httpd.conf, edomi.ini; dann mehrfach schon reboot) nicht gut bekommen. Werde edomi wohl mal neu installieren und dann schauen - falls hier nicht jemand eine gute Idee hat, was ich noch machen kann.

Und auch noch mal die Frage für diverse Daten für edomi: Multicast (siehe oben #187) aus einem Subnetz in ein anderes mit dem MT: Wie geht'n das?

[coliflower]

Was C genau meint weiß ich auch nicht (bin nie soweit gekommen - sorry) ... Hier vielleicht ein wenig hilfreich: https://forum.mikrotik.com/viewtopic...108196#p537120
https://forum.mikrotik.com/viewtopic...108196#p537229

[saegefisch]

...das war der Tool-Tip... aber was meint es technisch, bzw. wie löse ich es?

Und gleich noch eine zusätzliche, ganz andere Frage: Wie bekomme ich einen Multicast (SMA Energymeter: 239.12.255.254:9522) aus einem Subnetz 192.168.20.0/24 in ein anders 192.168.30.0/24? Habe für edomi gerade keine Verbrauchsdaten mehr...

[coliflower]

D = Dynamic
C = Complete

[saegefisch]

So, nach einer gänzlich schlaflosen Nacht ist nun alles soweit umgezogen hinter den MT. Es ist dann doch heftig, wieviele Abhängigkeiten es gibt mit TVH, Kodi, Edomi, 1Wire, mehrere NAS mit Backup-Strategien+SQL,syslog,..., DALI,...

Frage:
* edomi (192.168.20.20) ist von RB3011 Terminal per ping/traceroute erreichbar: OK + WebZugriff per Client: OK
* vom einen hAP Terminal ebenso: OK
* ABER vom 2. hAP (192.168.20.244) hingegen selten Ping; traceroute liegt mit 3-7 hops bei einem Loss von 50-90%. Alle andere Server im selben und anderen Subnetzen, surfen, Zugriff NAS,...scheinen tadellos zu gehen

Beide hAP per Trunk am RB3011. Edomi und hAP reboot gemacht. Alle Firewalls aus. Was kann die Ursache sein für einen loss von 50-70% bei nur einem Server? gibt es edomi-spezifische Fallstricke? Es wird wohl kein Kabel-Problem sein, weil der 2. hAP 2 Etagen weg (CAT5e) ist.... Ist bestimmt irgend etwas sau-dummes wegen Schlafentzug...<schämvorab>

Nachtrag: in der ARP-Liste des funktionierenden hAP steht die IP/MAC von edomi mit "DC", in der ARP-Liste des nicht sauber funktionierenden hAP nur mit "D". Was meint das fehlende "C = complete"?

[Janncsi]

Also meine allgemeine Firewall nach aussen funktioniert genau nach dem Prinzip sehr wirksam und wird seit langem eingesetzt!

Momentan habe ich eine Kommunikation zwischen den Vlans versucht über die Routing-Tabelle mit statischen Routen abzubilden und das funktioniert teilweise auch. Internet habe ich noch mit allen Vlans, was aber einfach mit einer Firewall-Regel abzustellen wäre.
Was ich noch realisieren möchte ist, dass das Routing dynamisch funktioniert und ich den Verkehr rein über die Firewall steuere....mein CRS125 ist sicherlich irgendwann an der Grenze, doch noch dümpel ich bei durchschnittlich 10% rum...

[jonofe]

Ja genau. Und die Definition der Default Policy der drei Chains INPUT/FORWARD/OUTPUT wurde von Mikrotik entfernt, d.h. statisch auf ACCEPT gestellt. User definierte Chains haben die Default Policy RETURN, d.h. wenn kein Match statfindet machen sie nach der aufrufenden Regel weiter.

D.h. wenn alle Regeln stimmig sind, sollte man am Ende der Input und Forward Queue ein DROP haben. Bei der OUTPUT Queue ist das eher unkritisch.

[saegefisch]

So habe ich es auch verstanden (MT-Wiki, diverse Router-Foren, Blogs,...) und kann ich empirisch bestätigen: Am Ende immer allgemeiner DROP jeweils für Chain Input und Forward, damit alles, was nicht zuvor explizit erlaubt wurde, gedropped. Ohne den Drop am Ende werden die Pakete mE. verarbeitet/gehen durch. Merkt man, wenn man z.B. alle Regeln inaktiv setzt: Dann geht alles durch.

[jonofe]

Mikrotik verwendet iptables und hier bestimmt die Default Policy der Chain was passiert wenn ein Paket durch die Chain läuft und keine Regel matched. M.W. ist die Default Einstellung der 3 Standard Chains (INPUT, FORWARD, OUTPUT) auf ACCEPT eingestellt. Daher muss man entweder am Ende einer Chain ein DROP all Regel einfügen, oder die Standard Policy der Chain auf DROP ändern. Ich mach aus Transparenz Gründen am Ende die DROP Regeln, dann ist es in der FW Sicht auf einen Blick erkennbar.

[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

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

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

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

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

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