Keine Firewall-Ereignisse

Forum zu aktuellen Geräten der LANCOM Router/Gateway Serie

Moderator: Lancom-Systems Moderatoren

Antworten
blaablupp1893
Beiträge: 3
Registriert: 12 Apr 2022, 11:55

Keine Firewall-Ereignisse

Beitrag von blaablupp1893 »

Hallo zusammen,

mein Problem ist, das bei mir in den Firewall-Ereignissen keine Einträge angezeigt werden. Ich dachte eigentlich, dass ich über die Firewall die geblockten Pakete zwischen den VLANS sehen kann und ggf. freigeben kann. Sorry für den ewig langen Post aber ich dachte ich schreibe hier auf wie ich alles konfiguriert habe. Vielleicht kann mir ja jemand helfen.

Es handelt sich um ein Heimnetz mit einem Lancom 1790EF und es gibt 3 Vlans: Client (100), Server (200) und MGMT (400)
• An LAN1 hängt ein Switch, der per Trunk alle VLANS bekommt, dort sollen auch alle VLANS verfügbar sein.
• An LAN2 ist zusätzlich das CLIENT Netzwerk vorhanden
• An LAN 4 ist zusätzlich das MGMT vorhanden.

Der Switch ist in einem anderen Stockwerk und dort gibt es PCs die auch ins Client VLAN sollen. Dort wo der Router steht, gibt es auch ein paar PCs. Daher ist das Client VLAN am LAN 2 sowie am Switch verfügbar. Das funktioniert auch.

Ich habe das nun folgendermaßen konfiguriert:
Schnittstellen -> LAN -> Ethernet-Ports: Jeweils den Ethernet-Port auf das Interface gemappt. (ETH-1 auf LAN-1, ETH-2 auf LAN2 ….) und Privater Modus eingeschaltet.
Schnittstellen -> LAN -> LAN Bridge -> Port Tabelle: Alle LAN Interfaces der BRG-1 Gruppe zugeordnet.
Schnittstellen -> VLAN -> VLAN Modul aktiviert

Schnittstellen -> VLAN -VLAN-Tabelle: VLANs angelegt.
• Client: VLAN-ID 100, Port: LAN-1, LAN-2
• Server: VLAN-ID 200, Port: LAN-1
• MGMT: VLAN-ID 400, Port: LAN-1

Schnittstellen -> VLAN -> Port Tabelle:
• LAN-1: Trunk; auf diesem Port KEINE Pakete erlauben, die zu anderen VLANs gehören; Port-VLAN-ID 99
• LAN-2: Access; auf diesem Port KEINE Pakete erlauben, die zu anderen VLANs gehören; Port-VLAN-ID 100
• LAN-4: Access; auf diesem Port KEINE Pakete erlauben, die zu anderen VLANs gehören; Port-VLAN-ID 400

IPv4 -> Allgemein -> IP-Netzwerke
• Client, 172.17.1.1/24, VLAN-ID 100, Schnittstellen Zuordnung BRG-1, Schnittstellen-TAG 100
• Client, 172.17.2.1/24, VLAN-ID 200, Schnittstellen Zuordnung BRG-1, Schnittstellen-TAG 200
• Client, 172.17.4.1/24, VLAN-ID 400, Schnittstellen Zuordnung BRG-1, Schnittstellen-TAG 400

Durch den Schnittstellen Tag ist keine Kommunikation zwischen den VLANs möglich. Nun habe ich eine Firewall Regel gesetzt, damit z.B. alle Clients alle Netze erreichen können.

Reiter Allgemein:
• Quell-Tag: 100
• Routing-Tag: 65535
Reiter Stationen:
• Von allen Stationen im Client Netz an alle Stationen

Das Funktioniert so weit auch. Sobald die Regel aktiviert ist, geht die Kommunikation, sobald sie deaktiviert ist, gibt es keine Kommunikation mehr. (Z.B. Ping, SMB) Allerdings zeigt mir die Firewall-Ereignisse keine Ereignisse an. Auch wenn ich nur bestimmte Ports zulasse, kommt keine Meldung das ein anderer Port blockiert wurde. Habe ich das grundsätzlich falsch konfiguriert oder läuft die Kommunikation nicht über die Firewall? Ich habe das Gefühl das ich da ein Verständnisproblem habe.

Danke und freundliche Grüße
Bernd
C/5
Beiträge: 90
Registriert: 18 Jul 2019, 10:55

Re: Keine Firewall-Ereignisse

Beitrag von C/5 »

Hallo Bernd,

was hast Du bei Aktion in der Regel eingestellt?

Das ACCEPT-Objekt muss halt mit der Option SNMP z. B. laufen, damit im Lanmonitor etwas ankommt.
Ich lege mir deshalb immer auch ein neues ACCEPT-Objekt mit aktiviertem SNMP an. Dito für das REJECT-Objekt. So kann man für eine Regel schnell mal wechseln und später wieder zurück, ohne dass gleich alle Regeln mit dem betreffenden Aktions-Objekt anfangen zu melden. Das wäre dann ein bissl viel im Monitor.

Syslog wäre auch möglich, vermute ich, nutze selbst aber nur SNMP.

CU
C/5
backslash
Moderator
Moderator
Beiträge: 7010
Registriert: 08 Nov 2004, 21:26
Wohnort: Aachen

Re: Keine Firewall-Ereignisse

Beitrag von backslash »

Hi blaablupp1893,

für Pakete, die aufgrund der ARF-Sichtbarkeiten (bzw. Unsichtbarkeiten) geblockt werden, erzeugt die Firewall keine Events...
ARF-Sichtbarkeiten äußern sich in getrennten Routing-Tabellen für die jeweilige Routing-Tags - und somit ein ein Verwerfen aufgrund des falschen Tags kein Firewallereignis, sondern einfach nur ein "fehlgeschlagenes" Routing...

Durch Umtaggen mit einer Firewallregel änderst du am Ende nur den Routen-Lookup...

Gruß
Backslash
blaablupp1893
Beiträge: 3
Registriert: 12 Apr 2022, 11:55

Re: Keine Firewall-Ereignisse

Beitrag von blaablupp1893 »

Hallo, vielen Dank für die schnellen Antworten.

Jetzt werden aber die Ereignisse angezeigt. Ich hatte bei den ACCEPT-Objekten die SNMP Option nicht aktiviert. Jetzt werden für die vorhandenen Regeln auch die Ereignisse angezeigt.

Nur nochmal zu meinem Verständnis.
Wenn ich mehrere Netze in einer Bridge habe, dann können diese untereinander kommunizieren, wenn sie den gleichen Schnittstellen TAG haben. (Gleiche Routingtabelle)

Bei unterschiedlichen Schnittstellen Tags können sie nicht kommunizieren da es verschiedene Routingtabellen gibt.

Dann könnte ich eine Routingeintrag zwischen Clientnetz und Servernetz setzten, dann könnten sie wieder kommunizieren.

Oder ich setze eine Firewall Regel mit dem Routing Tag 65535 (Route 0 = alle Routen zu allen Tabellen sind vorhanden). In der Regel kann ich dann z.B. erlauben das alle Client PCs mit dem Server Netz kommunizieren dürfen.

Der Quell Tag ist eine weitere Bedingung das die Regel bei einem bestimmten Netz mit Schnittstellen Tag Anwendung findet. Nur wenn beides stimmt, wird die Regel angewendet? Beim Quell-Tag 0 gilt die Regel für alle Schnittstellen (Voraussetzung das das Routing-Tag stimmt)

Gruß Bernd
backslash
Moderator
Moderator
Beiträge: 7010
Registriert: 08 Nov 2004, 21:26
Wohnort: Aachen

Re: Keine Firewall-Ereignisse

Beitrag von backslash »

Hi blaablupp1893
Wenn ich mehrere Netze in einer Bridge habe, dann können diese untereinander kommunizieren, wenn sie den gleichen Schnittstellen TAG haben. (Gleiche Routingtabelle)
ja, aber mit der Bridge solltest vorsichtig sein... Denn eine Bridge ist eine Layer-2 Verbindung wie ein Switch...Und an einem Switch können alle zumindest über ihre MAC-Adressen miteinander kommunizieren.
OK, über VLANs kannst du da noch eine Trennung erzielen
Bei unterschiedlichen Schnittstellen Tags können sie nicht kommunizieren da es verschiedene Routingtabellen gibt.
richtig, die Schnittstellen-Tags (oder auch Routing-Tags) trennen die Netze auf Layer-3 Ebene auf und es gelten die ARF-Sichtbarkeitsregeln beim öffnen einer session. Diese Regelm besagen recht simpel, daß sich nur Netze mit gleichem Routing-Tag sehen können, mit zwei Ausnahmen:
- Netze mit Tag 0 können alle Netze sehen
- Netze vom Typ DMZ werden von allen anderen Netzen gesehen
Dann könnte ich eine Routingeintrag zwischen Clientnetz und Servernetz setzten, dann könnten sie wieder kommunizieren.
nein, denn du kannst in der Routing-Tabelle ja nur angeben für welches Tag eine Route gelten soll. Du willst aber das Tag wechseln - und das geht nur über eine Firewall-Regel.
Oder ich setze eine Firewall Regel mit dem Routing Tag 65535 (Route 0 = alle Routen zu allen Tabellen sind vorhanden).
Also wenn du so "hart" alles aufmachst, dann kannst du dir die Tags auch gleich sparen...
Man macht die Trennung eingentlich weil die Netze wirklich separat bleiben sollen. Und wenn dann tatsächlich doch eine Kommunikation zwischen den Netzen erlaubt werden soll, dann gibt man sie gezielt frei, sprich für eine handvoll von IP-Adressen und Ports und natürlich auch mit dem gezielten Routing-Tag
Der Quell Tag ist eine weitere Bedingung das die Regel bei einem bestimmten Netz mit Schnittstellen Tag Anwendung findet. Nur wenn beides stimmt, wird die Regel angewendet?
ja, aber wenn du schon sagst "alle stationen im Client-Netz", dann kannst du dir das Qeull-Tag auch sparen, denn das wäre "doppelt gemoppelt"... Es gibt nur ganz wenige Spezielfälle, an denen die Angabe des Quell-Tags überhaupt Sinn macht
Beim Quell-Tag 0 gilt die Regel für alle Schnittstellen (Voraussetzung das das Routing-Tag stimmt)
jein, Quell-Tag 0 bedeutet einfach, daß das Tag ignoriert wird - und damit gilt es natürlich für alle Schnisttellen...
Das Routing-Tag hingegen ist für das Ziel zuständig, also erstmal nicht Bedingung der Regel - es sei denn man würde beim Ziel ein bestimmtes Interface mit angeben und der Routen-Lookup würde aufgrund des Tags ein anders Interface finden...

Und auch beim Routuing-Tag gilt in der Fierwall-Regel: Ein Tag 0 wird ignoriert und der Routen-Looku wird mit dem Tag des Interfaces gemacht, über daß das Paket empfangen wurde. Tag 65535 erzwingt die Nutzung des Tags 0 beim Routen-Lookup


BTW: wenn das komplette Client-Netz das komplette Server-Netz sehen, kannst du das Server-Netz aich als DMZ markierehn bzw. wenn das Client-Netz ale Netze sehen soll, dann gib dem Client Netz einfach das Tag 0

Gruß
Backslash
blaablupp1893
Beiträge: 3
Registriert: 12 Apr 2022, 11:55

Re: Keine Firewall-Ereignisse

Beitrag von blaablupp1893 »

Hallo Backslash,

vielen Dank für die ausführlichen Erklärungen.
OK, über VLANs kannst du da noch eine Trennung erzielen
Ja das habe ich gemacht.
nein, denn du kannst in der Routing-Tabelle ja nur angeben für welches Tag eine Route gelten soll. Du willst aber das Tag wechseln - und das geht nur über eine Firewall-Regel.
Das habe ich kurz nach meinem Post noch angeschaut und ausprobiert. Das habe ich jetzt verstanden.
Also wenn du so "hart" alles aufmachst, dann kannst du dir die Tags auch gleich sparen...
Man macht die Trennung eingentlich weil die Netze wirklich separat bleiben sollen. Und wenn dann tatsächlich doch eine Kommunikation zwischen den Netzen erlaubt werden soll, dann gibt man sie gezielt frei, sprich für eine handvoll von IP-Adressen und Ports und natürlich auch mit dem gezielten Routing-Tag
ja ich weiß, da macht die ganze Konfiguration davor keinen Sinn. Das habe ich nur exemplarisch so geschrieben. Das Ziel ist tatsächlich die Netze zu trennen und nur bestimmte IPs und Ports zu erlauben.

ja, aber wenn du schon sagst "alle stationen im Client-Netz", dann kannst du dir das Qeull-Tag auch sparen, denn das wäre "doppelt gemoppelt"... Es gibt nur ganz wenige Spezielfälle, an denen die Angabe des Quell-Tags überhaupt Sinn macht
Sehr gut dann habe ich das kapiert. Das des dann in dem Fall überflüssig ist habe ich mir schon gedacht (gehofft), habe es aber nicht dazugeschrieben.
Und auch beim Routuing-Tag gilt in der Fierwall-Regel: Ein Tag 0 wird ignoriert und der Routen-Looku wird mit dem Tag des Interfaces gemacht, über daß das Paket empfangen wurde.
Ok das ist interessant. Aber dann ist ja 65535 bei mir die richtige Einstellung, da sonst die Netze untereinander nicht kommunzieren könnten und ich sonst keine Routen mit anderen Tags außer 0 habe.

Ich denke ich muss noch einiges recherchieren aber ein paar Grundlagen habe ich auf jeden Fall verstanden. Sollte ich noch Fragen haben melde ich mich nochmal
Danke nochmal und schöne Ostern
Gruß Bernd
Antworten