FW-Regel greift nicht wg. "bad gateway"?

Forum zum Thema Firewall

Moderator: Lancom-Systems Moderatoren

Antworten
dMatschek
Beiträge: 39
Registriert: 24 Apr 2017, 11:44

FW-Regel greift nicht wg. "bad gateway"?

Beitrag von dMatschek »

Hi zusammen,

Ich verstehe die beiden letzten Zeilen nicht, die im Trace begründen, weshalb meine Firewall Regel nicht greift und daher mit der nächsten weiter gemacht wird. Im Forum und im Handbuch finde ich 0 Treffer zu dem Fehlertext.

Code: Alles auswählen

[Firewall] 2023/11/23 11:35:13,421  Devicetime: 2023/11/23 11:35:12,480
Packet matched rule NET-XX-BLOCK2INT
DstIP: 192.168.4.163, SrcIP: 192.168.12.124, Len: 60, DSCP: CS0/BE (0x00), ECT: 0, CE: 0
Prot.: ICMP (1), echo request, id: 0x0001, seq: 0x012e

bad gateway: INTERNET does not match NET-04
test next filter (no matching route for 192.168.4.163@12)
Es sind zwei Netze, die über das gleiche Interface reinkommen, separates VLAN und Tag.
192.168.4.0 = NET-04, VLAN 4, Tag 4
192.168.12.0 = NET-12, VLAN 12, Tag 12

Ich hatte erwartet mit folgender Firewall-Regel das generelle Routing zwischen der 12 und den anderen internen Netzen zu unterbinden:

Code: Alles auswählen

NET-12-BLOCK2INT	ANY	%LNET-12	%L	REJECT	Aus		An	Aus	An	6030	0	0	
Modifiziere ich die Regel und sage nicht als Ziel "alle lokalen Netze" sondern nehme "IP Bereich 192.168.0.1-192.168.255.254" dann funktioniert es wie erwartet.
Wo gerät da was mit der Gateway-Selektion (bad gateway: X does not match Y) durcheinander?
Kontext: 1781VA, Firmware 10.72.0385RU5

VG, Matschek
backslash
Moderator
Moderator
Beiträge: 7016
Registriert: 08 Nov 2004, 21:26
Wohnort: Aachen

Re: FW-Regel greift nicht wg. "bad gateway"?

Beitrag von backslash »

Hi dMatschek

der Trace sagt dir, daß das Paket zwar adreßmäßig auf die Regel NET-XX-BLOCK2INT gematcht hat, die Zielroute aber auf das Interface "INTERNET" zeigt, weshalb die Regel nicht greift die nächste Regel gesucht wird.

192.186.4.163 liegt zwar adreßmässig im Netz NET-04 (weshalb die Regel adreßmäßig matcht), da das Paket aber über NET-12 mit Routing-Tag 12 empfangen wurde, greift auch die Routing-Tabelle für Tag 12. In dieser steht das Netz NET-04 aber gar nicht drin (denn es hat ja das Routing-Tag 4). Also greift in dieser Routing-Tabelle die Default-Route mit Routing-Tag 0 - und die zeigt bei dir auf "INTERNET". Da du in der Regel als Ziel "%L" angegeben hast, sind die Zielnetze auch mit den zugehörigen Zielinterfaces verküpft (bei 192.186.4.163 alos NET-04). Genau deshalb matcht die Regel am Ende nicht und dass soll dir

Code: Alles auswählen

bad gateway: INTERNET does not match NET-04
test next filter (no matching route for 192.168.4.163@12)
auch sagen. Da stehen alle Informationen drin: Die Zielroute des Pakets ist INTERNET, das erwartete Zielinterface der Regel war NET-04, das Paket wurde mit Routing-Tag 12 empfangen
Ich hatte erwartet mit folgender Firewall-Regel das generelle Routing zwischen der 12 und den anderen internen Netzen zu unterbinden:
Die Regel ist überflüssig, weil die Trennung bereits über die Routing-Tags erfolgt (ließ dir dazu sie Sichtbarkeitsregeln für ARF durch).

Viel wichtiger wäre, daß du die Sperr-Routen für private Netze aktivierst, denn sonst geht das Paket zum Internet-Provider und der weiss dann, daß du lokal mindestens das Netz 192.186.4.x hast - und wenn jemand aus NET-04 eine Adresse aus NET-12 anspricht, dann kennt der Provider auch das 192.186.12.x-Netz

Ich war nie ein Freund davon die Sperr-Routen für private Netze zu deaktivieren, aber dem Support war es zu viele Kunden die damit (angeblich) ein Problem hatten. Also wurden Sperr-Routen deaktiviert und nun verthält sich ein LANCOM
im Auslieferungszustand genaugenommen nicht mehr RFC-konform und sendet Pakete mit privaten Zieladressen ins Internet...

Gruß
Backslash
dMatschek
Beiträge: 39
Registriert: 24 Apr 2017, 11:44

Re: FW-Regel greift nicht wg. "bad gateway"?

Beitrag von dMatschek »

Hi Backslash,

das nenn ich sauber zerlegt und dargelegt - herzlichen Dank dafür!

Das Eigentor hab ich mir dazu noch ganz unnötig geschossen. In der Ausgangskonfiguration waren es mal 2 Netze und eine Firewall-Regel zum Unterbinden der Kommunikation. Dann kam ich bei der Erweiterung auf die Idee die Netze sauber mit Tags zu trennen und hab mich unnötig an dieser Deny-Regel hier abgearbeitet statt sie zu löschen. Naja - immerhin was dabei gelernt :-)

Und die Sperr-Routen ergänze ich. Ich bewerte den Informationsabfluss zum Provider über vorhandene Netzsegmente zwar unkritisch (die 256 Varianten des 192.168. Blocks sind doch schneller ausprobiert als abgeschnüffelt?) aber es muss ja nicht sein.

VG,
Matschek
Antworten