in LCOS 9.10.0530 kommt es bei der Anwendung verketteter Firewallregeln für IPv4 zu "Auffälligkeiten" bei der Behandlung von UDP-Strömen.
(Beobachtetet für ein Interface vom Typ "DMZ", vielleicht auch für Typ "INTRANET")
FW-Regelwerk
Es werden in einem ersten Schritt DSCP-Tags global für diverse Protokolle gesetzt, damit eine flexible QoS-Anpassung von und zum LAN erreicht werden kann. Nachfolgende Regeln bestimmen für Quelle/Ziel und Anwendung, was durchgelassen wird.
Beispiel:
Netz: 10.1.254.0/24 ist DMZ
Prio 1: Setze DSCP AF21 für bestimmte Protokolle (z. B. DNS udp/53)
und erwartete verkettete Folgeregel
Prio 0: erlaube DNS nach extern aus DMZ
Wenn ein Server eine DNS-Anfrage startet,
Code: Alles auswählen
# dig @8.8.8.8 test.de
Code: Alles auswählen
> trace # firewall ip-router
[Firewall] 2015/12/19 02:29:32,304
Packet matched rule DSCP-AF21
DstIP: 8.8.8.8, SrcIP: 10.1.254.130, Len: 64, DSCP: CS0/BE (0x00), ECT: 0, CE: 0
Prot.: UDP (17), DstPort: 53, SrcPort: 49390
test next filter (linked rules)
[Firewall] 2015/12/19 02:29:32,305
Packet matched rule 0-DMZ-DNS-X
DstIP: 8.8.8.8, SrcIP: 10.1.254.130, Len: 64, DSCP: CS0/BE (0x00), ECT: 0, CE: 0
Prot.: UDP (17), DstPort: 53, SrcPort: 49390
packet accepted
[IP-Router] 2015/12/19 02:29:32,304
IP-Router Rx (LAN-1, DMZ, RtgTag: 3):
DstIP: 8.8.8.8, SrcIP: 10.1.254.130, Len: 64, DSCP: CS0/BE (0x00), ECT: 0, CE: 0
Prot.: UDP (17), DstPort: 53, SrcPort: 49390
no channel available => discard frame
Code: Alles auswählen
[IP-Router] 2015/12/19 02:29:37,305
IP-Router Rx (LAN-1, DMZ, RtgTag: 3):
DstIP: 8.8.8.8, SrcIP: 10.1.254.130, Len: 64, DSCP: AF21 (0x12), ECT: 0, CE: 0
Prot.: UDP (17), DstPort: 53, SrcPort: 49390
Route: WAN Tx (ISP-GW-1)
[IP-Router] 2015/12/19 02:29:37,326
IP-Router Rx (ISP-GW-1, RtgTag: 3):
DstIP: 10.1.254.130, SrcIP: 8.8.8.8, Len: 80, DSCP: AF21 (0x12), ECT: 0, CE: 0
Prot.: UDP (17), DstPort: 49390, SrcPort: 53
Route: LAN-1 Tx (DMZ):
Resultat
Code: Alles auswählen
# dig @8.8.8.8 test.de
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 62580
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;test.de. IN A
;; ANSWER SECTION:
test.de. 383 IN A 104.45.6.189
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Sat Dec 19 03:07:30 CET 2015
In der Verbindungstabelle taucht als maßgebliche Regel für den Verbindungsaufbau die erste Regel auf, nicht diejenige, die letztlich den Transport freigegeben hat.
Code: Alles auswählen
> ls /Status/IP-Router/conn
Src-Address Dst-Address Prot. Src-Port Dst-Port Rtg-tag Timeout Flags Filter-Rule Src-Route Dest-Route
----------------------------------------------------------------------------------------------------------------------------------------------------------------
10.1.254.130 8.8.8.8 17 49390 53 3 27 10020000 DSCP-AF21 ISP-GW-1
Im Ergebnis kommt es zu 5 Sekunden langen Hängern oder Abbrüchen quer durch die Bank von UDP-Anwendungen:
- ntp (udp/123)
- dns (udp/53)
- und ich denke, auch bei Verbindungsaufbau über LANCOM dynVPN (udp/87) das Problem gesehen zu haben.
usw.!
Sobald die Verkettungsregel (Setze DSCP) abgeschaltet wird, greift die abschließende Regel sofort, die Anwendung funktioniert ohne Hänger,
und die Verbindungstabelle zeigt die richtige Regel:
Code: Alles auswählen
> ls /Status/IP-Router/conn
Src-Address Dst-Address Prot. Src-Port Dst-Port Rtg-tag Timeout Flags Filter-Rule Src-Route Dest-Route
----------------------------------------------------------------------------------------------------------------------------------------------------------------
10.1.254.130 216.239.32.10 17 8223 53 3 13 80020000 0-DMZ-DNS-X ISP-GW-1
Die Verkettung funktioniert bei TCP korrekt, bei UDP nicht.
Gruß,
rougu
NB:
Dieses (Fehl-)Verhalten hat massiv Arbeit verursacht, weil ich die Verkettung von Firewallregeln ausbauen musste, um die aktuelle Release-Version (mit all ihren unbestrittenen Vorteilen) produktiv einsetzen zu können.
