Packet matched rule (null)

Forum zum Thema Firewall

Moderator: Lancom-Systems Moderatoren

Antworten
Benutzeravatar
gm
Beiträge: 300
Registriert: 21 Okt 2006, 12:21
Wohnort: Großkonreuth
Kontaktdaten:

Packet matched rule (null)

Beitrag von gm »

Hallo,

habe eben mal einen FW-Trace mitlaufen lassen und bin dabei auf folgende komische Einträge gestoßen:

Code: Alles auswählen

[Firewall] 2008/04/06 03:27:54,800
Packet matched rule (null)
DstIP: 68.142.72.250, SrcIP: 84.147.71.228, Len: 29, DSCP: unknown (4), ECT: 0, CE: 0
Prot.: UDP (17), DstPort: 27010, SrcPort: 27015
fragment packets on T-ONLINE to 256
Was ist die Regel "null"? Meine letzte Regel ist eine DENY-ALL-Regel und jede Regel hat bei mir einen Namen :?:

Ferner ist mir im Lanconfig aufgefallen, wenn man unter Firewall/QOS->Regeln bei einer Regel im Reiter Trigger/Aktion-Set das Kreuz bei "Markieren mit DiffServ-CP:" setzt, dass dann der Eintrag in der Aktionsliste plötzlich Sonderzeichen enthält. Dies Tritt seit dem Lanconfig 7.52 auf.


Mein eigentliches Problem ist aber folgendes:
Ich betreibe gewisse Dienste in einer DMZ hinter NAT. Die relevanten Ports sind per Portforwarding vom LANCOM zu den Servern weitergeleitet (1x IPSec und 1x UDP 27015). Das klappt ganz gut. Ich würde jetzt gerne Mindesbandbreiten für die Verbindungen mit den Servern festelegen bzw. Paketfragmentierung einschalten (beides nur für den Upload der Server ins Internet). Es soll aber erst eine Reservierung vorgenommen werden, wenn pro Verbindung ca. 50 Pakete übertragen wurden, da sonst jede einfache Kurzanfrage zu einer Bandbreitenreservierung führen würde. Für normale ausgehende Verbindungen aus dem LAN (z.B. Mailversand) habe ich die Reservierung ohne Probleme hinbekommen, aber diesem speziellen Fall will es absolut nicht klappen.

Meine Regel für 49 KBit Mindestbandbreite je Verbindung vom lokalen UDP-Port 27015 ins Internet plus Fragmentierung des Resttraffic auf 257 Byte sieht so aus (Die krummen Zahlen sind damit ich es besser im LANMONITOR kontrollieren kann):

Code: Alles auswählen

Prot.	Quelle	Ziel	Aktion	verknuepft	Prio	Aktiv	VPN-Regel	Stateful	Rtg-Tag	Kommentar
UDP	%S27015 %A10.0.3.11	ANYHOST	%Lcp50 %A %N %Ft257 @i %Qctds49 @i	nein	2	ja	nein	ja	0	QOS: 49 KBit pro Verb., ab 50 Pkt., 10.0.3.11:27015
- Wieso zieht die Regel oben nicht wenn Traffic läuft?
- Muss man eigentlich den Router neu starten, nach dem man neue FW-Regeln eingespielt hat oder ziehen die sofort?
- Ist die Verbindungsquelle bzw. -ziel bei einer FW-Regel aus Sicht eines Paketfilters zu sehen oder spielt dabei eine Rolle wer die Verbindung aufgebaut hat?
- Kann für UDP oder IPSec eine Mindestbandbreite hinterlegt werden (Server jeweils hinter dem LANCOM, per Portforwarding)?
- Was zeigt der LANMONITOR bei "TX bevorzugt" an? Ist das die korrekte Summe aller Reservierungen?
- Wird "TX bevorzugt" sofort für jede Verbindung mit Mindestbandbreite hochgezählt oder erst später, wenn z.B. die Bandbreite knapp wird?
- Wenn ich in der FW-Regel eine SNMP-Info hinterlege kommt die dann pro Paket, das verarbeitet wird, oder pro Verbindung nur 1x?
- Ich habe das Gefühl, dass nicht alle sonstigen Pakete in die normalerweise in der DENY-All-Regel landen müssten, z.B. Portscanns, zuvor ausgefiltert werden und dabei keine Meldung im LANMONITOR (SNMP) erfolgt.
- Gibt es die Möglichkeit genau in Erfahrung zu bringen für welche Verbindungen welche Mindestbandbreite aktuell zugeteilt ist (quasi die Detailansicht von "TX bevorzugt"im LANMONITOR)?


Ist es ferner normal, dass die Allow-Regel für das Weiterleiten von IPSec so komisch aussieht? Bei Prot. in der 1. Spalte steht was ganz anderes als bei den anderen Regeln (aus Webconfig kopiert). Die Regel wurde mit LANCONFIG erzeugt....

Code: Alles auswählen

Prot.	Quelle	Ziel	Aktion	verknuepft	Prio	Aktiv	VPN-Regel	Stateful	Rtg-Tag	Kommentar
FW_ALLOW_0	ANYHOST	%S500,4500 %A10.0.3.1	%Lcrds0 %A	nein	1	ja	nein	ja	0	default route -> 10.0.3.1 (IPSec)
Für Eure Tips möchte ich mich schon mal bedanken. :-)

Viele Grüße
gm

PS: Firmware ist mittlerweile die 7.30, hatte vorher die 7.28


Edit:
Kann es sein, dass es am Portforwarding liegt, dass die QoS-Regeln einfach nicht greifen wollen?
backslash
Moderator
Moderator
Beiträge: 7129
Registriert: 08 Nov 2004, 21:26
Wohnort: Aachen

Beitrag von backslash »

Hi gm,
Wieso zieht die Regel oben nicht wenn Traffic läuft?
Wenn ich dich richtig verstanden habe, dann ist das ein Server, der von aussen angesprochen wird, d.h. er bietet einen Dienst auf UDP-Port 27015 an.

In diesem Fall mußt du die Regel umdrehen, d.h. die Quelle muß ANYHOST und das Ziel mup "%S27015 %A10.0.3.11" lauten, da die Regeln sich immer auf die Richtung des ersten Pakets einer Session beziehen.
- Muss man eigentlich den Router neu starten, nach dem man neue FW-Regeln eingespielt hat oder ziehen die sofort?
Sie greifen sofort - natürllich nur für neue Sessions. Für bereits bestehende Sessions bleiben die Regeln aktiv, die zum Zeitpunkt des ersten Pakets des Session aktiv waren.
- Ist die Verbindungsquelle bzw. -ziel bei einer FW-Regel aus Sicht eines Paketfilters zu sehen oder spielt dabei eine Rolle wer die Verbindung aufgebaut hat?
Siehe Antwort auf die erste Frage: Die Richtung des Verbindungsaufbaus ist maßgeblich
- Was zeigt der LANMONITOR bei "TX bevorzugt" an? Ist das die korrekte Summe aller Reservierungen?
Das ist die Summe aller Reservierungen aus Regeln, in denen das Häkchen bei "erzwungen" nicht gesetzt ist.
Wenn ich in der FW-Regel eine SNMP-Info hinterlege kommt die dann pro Paket, das verarbeitet wird, oder pro Verbindung nur 1x?
Die Meldung kommt natürlich nur einmal pro Session...
- Ich habe das Gefühl, dass nicht alle sonstigen Pakete in die normalerweise in der DENY-All-Regel landen müssten, z.B. Portscanns, zuvor ausgefiltert werden und dabei keine Meldung im LANMONITOR (SNMP) erfolgt.

Wenn ein Portscan erkannt wird, dann gibt es dafür natürlich eine Meldung. Ab dann werden für die weiteren Pakete keine Meldungen mehr erzeugt. Hinzu kommt, daß "gleiche" Meldungen nur maximal einmal pro Minute kommen (um des Log nicht zu überfluten)
- Gibt es die Möglichkeit genau in Erfahrung zu bringen für welche Verbindungen welche Mindestbandbreite aktuell zugeteilt ist (quasi die Detailansicht von "TX bevorzugt"im LANMONITOR)?
Nein, es gibt nur sie Summenansicht. Du kannst dir aber für jede Verbindung anschauen, aufgrund welcher Regel sie angelegt wurde (unter /status/ip-router/connection-list). Da du ja weisst, welche Regel, welche Reservierungen generiert, kannst du daraus selbst errechnen, wleche Bandbreiten vergeben wurden...
Ist es ferner normal, dass die Allow-Regel für das Weiterleiten von IPSec so komisch aussieht? Bei Prot. in der 1. Spalte steht was ganz anderes als bei den anderen Regeln (aus Webconfig kopiert). Die Regel wurde mit LANCONFIG erzeugt....
FW_ALLOW_0 ist ein Verweis in die Objekt-Tabelle in dem die Protokolle UDP, ESP und AH zusammengefaßt werden. Die Ports 500 und 4500 dienen dazu, sowohl reines IPSec als auch IPSec über NAT-T mit der Regel zu erfassen

Gruß
Backslash
Benutzeravatar
gm
Beiträge: 300
Registriert: 21 Okt 2006, 12:21
Wohnort: Großkonreuth
Kontaktdaten:

Beitrag von gm »

Hi backslash,

wow, vielen vielen Dank für Deine Antworten. Funktioniert jetzt auf anhieb! Deine Auskünfte haben mich weiter gebracht als über 800 Seiten Handbuch. Danke Danke Danke. :M backslash

Eine Frage brennt mir aber noch auf den Nägeln: Wie bekomme ich es hin, dass das QoS erst ab dem 50. Paket pro Verbindung zieht? Wenn ich die Accept-Aktion der Regel mit dem Trigger "50 Pakete absolut" versehe scheint dies irgendwie nicht zu wirken und trotzdem für alle anderen auch eine Reservierung vorzunehmen.
Mein Problem ist, dass auf dem Port 27015 pro Sekunde ca. 3 bis 10 Verbindungen eingehen, die nur den Status des Servers abfragen und dann wieder beendet werden. Das Statusabfragen ist normalerweise nach 3 bis 10 Paketen vorbei, daher der Trigger auf 50, so dass nur die wirklichen Verbindungen ein QoS bekommen. Kann man dies irgendwie lösen?

Viele Grüße
gm

Edit: 19:20 Uhr
Ich glaub ich bin selber draufgekommen was zu tun ist damit die QoS Regel erst ab dem 50 Paket zieht geht:
Scheinbar brauche ich dafür 2 Regeln:
- Die erste Regel setzt ein bestimmtes QoS-Flag z.B. EF ab dem 50 Paket und beachtet nachgelagerte Regeln
- Die zweite Regel macht QoS nur für die Pakete mit EF
Beiden Regeln sind die Prüfungen für die Ports und Adressen gemein.
backslash
Moderator
Moderator
Beiträge: 7129
Registriert: 08 Nov 2004, 21:26
Wohnort: Aachen

Beitrag von backslash »

Hi gm
Eine Frage brennt mir aber noch auf den Nägeln: Wie bekomme ich es hin, dass das QoS erst ab dem 50. Paket pro Verbindung zieht? Wenn ich die Accept-Aktion der Regel mit dem Trigger "50 Pakete absolut" versehe scheint dies irgendwie nicht zu wirken und trotzdem für alle anderen auch eine Reservierung vorzunehmen.
Ein Aufschalten einer Mindestbandbreite über einen Trigger ist leider nicht vorgesehen - die QoS-Parameter greifen sofort.
Mein Problem ist, dass auf dem Port 27015 pro Sekunde ca. 3 bis 10 Verbindungen eingehen, die nur den Status des Servers abfragen und dann wieder beendet werden. Das Statusabfragen ist normalerweise nach 3 bis 10 Paketen vorbei, daher der Trigger auf 50, so dass nur die wirklichen Verbindungen ein QoS bekommen. Kann man dies irgendwie lösen?
Wenn du den Sourcecode des Servers zur Verfügung hast, könntest du dir mit DiffServ-Tags helfen, in dem der Server

- reine Statusanfragen mit BE getaggten Paketen beantwortet
- wirkliche Daten z.B. mit EF getaggten Paketen überträgt

Dann könntest du die Mindestbandbreiten nur dann reservieren, wenn der Server EF getaggte Pakete aussendet...

Etwas anderes fällt mir da z.Zt auch nicht ein.

Gruß
Backslasdh
Benutzeravatar
gm
Beiträge: 300
Registriert: 21 Okt 2006, 12:21
Wohnort: Großkonreuth
Kontaktdaten:

Beitrag von gm »

Hi backslash,

das Reservieren der Mindestbandbreite geht auch mit dem LANCOM-Gerät selbst, ohne dass ich am Server oder per Netfilter eingreifen muss:
Man braucht dafür 2 Regeln:
- Die erste Regel setzt ein bestimmtes QoS-Flag z.B. EF ab dem 50 Paket, beinhaltet kein QoS und beachtet nachgelagerte Regeln, die Prio der Regel muss höher sein als die der Zweiten
- Die zweite Regel macht QoS nur für die Pakete mit EF
Bei beiden Regeln habe ich die Prüfungen auf die Ports und Adressen gleich eingetragen.

Funktioniert astrein. :D

Einzig die CPU-Last klettert ganz schön hoch. wenn ca. 0,5 MBit in Senderichtung laufen liegt die Last bei ca. 25 bis 30 %, aber das ist für mich i.O.

Gruß
gm
Antworten