[gelöst] Line-Polling VS. Firewall

[dMatschek]

Hi zusammen.

Ich habe hier einen 1790VA, FW 10.50.0530RU4, bei dem ich das Verhalten der automatischen Firewall/Intruder Detection im Kontext des Line-Pollings nicht verstehe. Mit dem Polling überwache ich eine Kabel-und eine DSL-Verbindung, die jeweils über eine FritzBox bereitgestellt wird.
Bei der Kabel-Verbinndung sah es im Polling so aus als ob es keine ICMP Replys gibt, in der Folge wird die Verbindung alle 60s getrennt und versucht neu aufzubauen. Im Trace:

Code: Alles auswählen

[Line-Polling] 2022/05/10 10:55:10,312  Devicetime: 2022/05/10 10:55:11,574 IPv4 Line Polling [failed] on interface GS-CABLE: Sent ping to 1.1.1.1
[Line-Polling] 2022/05/10 10:55:10,312  Devicetime: 2022/05/10 10:55:11,574 IPv4 Line Polling [failed] on interface GS-CABLE: Sent ping to 1.0.0.1
[Line-Polling] 2022/05/10 10:55:11,312  Devicetime: 2022/05/10 10:55:12,574 IPv4 Line Polling [failed] on interface GS-CABLE: No ping reply received. Remaining retries: 17
[Line-Polling] 2022/05/10 10:55:11,312  Devicetime: 2022/05/10 10:55:12,574 IPv4 Line Polling [failed] on interface GS-CABLE: Sent ping to 1.1.1.1
[Line-Polling] 2022/05/10 10:55:11,312  Devicetime: 2022/05/10 10:55:12,574 IPv4 Line Polling [failed] on interface GS-CABLE: Sent ping to 1.0.0.1

[Line-Polling] 2022/05/10 10:55:11,504  Devicetime: 2022/05/10 10:55:12,756 IPv4 Line Polling [forced] on interface GS-VDSL: Ping reply received during last poll period. Next check in 20s
[Line-Polling] 2022/05/10 10:55:11,504  Devicetime: 2022/05/10 10:55:12,756 IPv4 Line Polling [forced] on interface GS-VDSL: Sent ping to 8.8.8.8
[Line-Polling] 2022/05/10 10:55:11,504  Devicetime: 2022/05/10 10:55:12,756 IPv4 Line Polling [forced] on interface GS-VDSL: Sent ping to 8.8.4.4

Wenn ich gleichzeitig einen Wireshark Mitschnitt am entsprechenden DSL-Port mache, sehe ich jedoch erfolgreiche ICMPs, incl. Reply:

Code: Alles auswählen

26	7.070240	109.90.xx.xx	1.1.1.1	ICMP	98	Echo (ping) request  id=0x578e, seq=4/1024, ttl=64 (reply in 28)
27	7.070254	109.90.xx.xx	1.0.0.1	ICMP	98	Echo (ping) request  id=0x578e, seq=4/1024, ttl=64 (reply in 29)
28	7.079686	1.1.1.1	109.90.xx.xx	ICMP	98	Echo (ping) reply    id=0x578e, seq=4/1024, ttl=56 (request in 26)
29	7.079699	1.0.0.1	109.90.xx.xx	ICMP	98	Echo (ping) reply    id=0x578e, seq=4/1024, ttl=56 (request in 27)

Dann hab ich die Firwall Einträge mit in den Trace genommen, und siehe da: Das Lancom IDS killt die Antwort seines eigenen ICMP Requests

Code: Alles auswählen

[Firewall] 2022/05/10 11:21:50,725  Devicetime: 2022/05/10 11:21:52,063
Packet matched rule intruder detection
DstIP: 109.90.xx.xx, SrcIP: 1.1.1.1, Len: 84, DSCP: CS0/BE (0x00), ECT: 0, CE: 0
Prot.: ICMP (1), echo reply, id: 0x5912, seq: 0x0001

Filter info: packet received from invalid interface GS-CABLE
send SNMP trap
packet dropped

Wie kann das denn sein, bzw: Was kann ich dagegen tun?

VG,
Matschek

[backslash]

Hi dMatschek

kann es sein, daß du keine Default-Route hast, die auf das Interface GS-CABLE zeigt? Was sagt ein "show ipv4-fib" im CLI?
Wenn du ein z.B. Backup über administrative Distanzen realisiert hast, dann brauchst du für jede Leitung eine eigene Route mit verschiedenen Routing-Tags - selbst wenn du sie nicht explizit nutzen willst, müssen sie vorhanden sein, damit das IDS nicht anschlägt

Gruß
Backslah

[dMatschek]

Hi Backslash,

Volltreffer. Ich hatte für diese Gegenstelle keine Default-Route. Sobald ich sie angelegt hab, verwirft das IDS die Replys Pakete nicht mehr und die Leitung bleibt stabil stehen. Danke!!
Das Backup über administrative Distanzen ist später auch geplant. Ich werde zwar hier Tags einsetzen, aber um deinen Hinweis richtig zu verstehen: Wenn ich keine Tags einsetzen würde, und beide Default-Routen untereinander schreiben würde, nur mit unterschiedlichen administrativen Distanzen - das wäre ein Problem?

VG,
Matschek

[backslash]

Hi dMatschek

Wenn ich keine Tags einsetzen würde, und beide Default-Routen untereinander schreiben würde, nur mit unterschiedlichen administrativen Distanzen - das wäre ein Problem?

jain...

Um das Backup zu realisieren mußt du die Routen mit gleichem Tag (also z.B. auch 0) aber unterschiedlichen administrativen Distanzen eintragen.
In dem Fall schlägt das IDS zu, wenn Pakete auf der "Backup-Route" empfangen werden (z.B. die Antworten auf die Poll-Pings), denn in der FIB (Forwarding Information Base = effektive Routing-Tabelle) steht nur die Route mit der gerade niedrigsten administrativen Distanz.

Um das IDS ruhig zu stellen muß du also für jede Gegenstelle die gleiche Route nochmal eintragen, nur diesmal mit unterschiedlichen Routing-Tags (die administrative Distanz ist dabei dann egal)... Dadurch werden für diese Tags weitere Routing-Tabellen angelegt - und das IDS findet dann jeweils eine Route zur Quell-Adresse der Ping-Antworten über das jeweilige Interface und ist glücklich...

Gruß
Backslash

[dMatschek]

Dann mal ein erneutes Danke für die Erklärung. Nicht wirklich intuitiv, und auch auf den zweiten Blick muss ich die Stirn runzeln, dass ich selbst die Brücke bauen muss zwischen zwei integrierten Features.. Aber, jetzt weiß ich ja wie

VG,
Matschek

[backslash]

Hi dMatschek,

daß das "unschön" ist hat sich auch schon herumgesprochen und es wird für die 10.70 an einer Lösung gearbeitet, die die zusätzlichen Routen überflüssig machen soll

Gruß
Backslash