FW/IDS am 1900EF macht nicht was sie soll

Forum zum Thema Firewall

Moderator: Lancom-Systems Moderatoren

Antworten
Benutzeravatar
BjörnG
Beiträge: 12
Registriert: 14 Feb 2022, 14:30

FW/IDS am 1900EF macht nicht was sie soll

Beitrag von BjörnG »

Moin zusammen,

obwohl ich FW-Regeln erstellt habe, daß die Netze 2.2.2.2 und 3.3.3.3 komplett offen kommunizieren dürfen, bekomme ich sporadisch folgende FW-Meldungen und es brechen VoIP-Verbindungen ab.

1.1.1.1: Router himself
2.2.2.2: WAN-IP
3.3.3.3: Cloud-VoIP-Server

Netze dürfen vice-versa offen kommunizieren:
ls /Setup/IP-Router/Firewall/Filter-List/

Idx. Prot. Source S-St. S-End Destination D-St. D-End Action Linked Prio Src-Tag Rtg-tag
==========---------------------------------------------------------------------------------------------------------------------------------------------------------
00000020 17 3.3.3.3/32 0 0 1.1.1.0/24 0 0 accept No 0 0 0
00000022 17 1.1.1.0/24 0 0 3.3.3.3/32 0 0 accept No 0 0 0
00000025 0 2.2.2.2/32 0 0 3.3.3.3/32 0 0 accept No 0 0 0
00000026 0 3.3.3.3/32 0 0 2.2.2.2/32 0 0 accept No 0 0 0
Trotzdem werden da UDPs-Abgelehnt...:

Code: Alles auswählen

root@xwiki:/var/log/1.1.1.1# tail -f PACKET_ALERT.log | grep "3.3.3.3"
2022-10-28T08:46:04.149106+02:00 1.1.1.1 PACKET_ALERT: Dst: 2.2.2.2:10044 {1900EF}, Src: 3.3.3.3:41518 (UDP): connection refused
2022-10-28T09:03:49.846814+02:00 1.1.1.1 PACKET_ALERT: Dst: 2.2.2.2:10048 {1900EF}, Src: 3.3.3.3:44148 (UDP): connection refused
2022-10-28T09:07:18.013090+02:00 1.1.1.1 PACKET_ALERT: Dst: 2.2.2.2:10022 {1900EF}, Src: 3.3.3.3:44780 (UDP): connection refused
2022-10-28T09:13:17.805301+02:00 1.1.1.1 PACKET_ALERT: Dst: 2.2.2.2:10024 {1900EF}, Src: 3.3.3.3:45566 (UDP): connection refused
2022-10-28T09:18:10.690228+02:00 1.1.1.1 PACKET_ALERT: Dst: 2.2.2.2:10066 {1900EF}, Src: 3.3.3.3:46540 (UDP): connection refused
2022-10-28T09:20:33.223594+02:00 1.1.1.1 PACKET_ALERT: Dst: 2.2.2.2:10068 {1900EF}, Src: 3.3.3.3:46922 (UDP): connection refused
Hab' aus Verzweiflung auch mal das Client-Binding konfiguriert, in der Hoffnung das NAT zu 'entschärfen':
ls /Setup/IP-Router/Load-Balancer/Client-Binding/Protocols

Name Protocol Port Active
==================------------------------
ANY 0 0 Yes
HTTP 6 80 Yes
HTTPS 6 443 Yes
SF-NTP 6 123 Yes
SF-TCP-1 6 5060 Yes
SF-TCP-2 6 5061 Yes
SF-TCP-XMPP 6 5222 Yes
SF-UDP 17 5060 Yes
Was übersehe ich, und wie zum Henker kann man das IDS mal abschalten, ohne direkt Alles aus zu schalten an der FW?
Oder reicht es hier: https://www.lancom-systems.de/docs/LCOS ... 37412.html nur zu sagen:
IDS - Paket-Aktion -> Übertragen ?

Bin für jede Hilfe dankbar.

Grüße,
Björn
DanLo
Beiträge: 65
Registriert: 08 Jan 2019, 12:44

Re: FW/IDS am 1900EF macht nicht was sie soll

Beitrag von DanLo »

Schlägt da überhaupt die IDS an?

Was sagt denn der Firewall-Trace auf deinem Gerät?
Benutzeravatar
BjörnG
Beiträge: 12
Registriert: 14 Feb 2022, 14:30

Re: FW/IDS am 1900EF macht nicht was sie soll

Beitrag von BjörnG »

DanLo hat geschrieben: 28 Okt 2022, 11:42 Schlägt da überhaupt die IDS an?

Was sagt denn der Firewall-Trace auf deinem Gerät?
Den kann ich nicht nutzen im Moment. Wenn ich den Trace starte crashed das Routing des Routes.
Genauer, die WAN-Route wird nicht mehr bedient.
Man kann auf der CLI des Routers ins Internet pingen, und auch ins LAN, aber vom LAN kommt man nicht mehr raus.
Die default WAN-Route stellt die Funktion ein.

Man muss per Assistent die WAN löschen und neu anlegen, dann routet er erst wieder. Ein Neustart des Routers behebt den Fehler nicht.

Support-Case deswegen hab ich bei LANCOM schon eröffnet.
tstimper
Beiträge: 956
Registriert: 04 Jun 2021, 15:23
Wohnort: Chemnitz
Kontaktdaten:

Re: FW/IDS am 1900EF macht nicht was sie soll

Beitrag von tstimper »

BjörnG hat geschrieben: 28 Okt 2022, 11:57
Man muss per Assistent die WAN löschen und neu anlegen, dann routet er erst wieder. Ein Neustart des Routers behebt den Fehler nicht.

Support-Case deswegen hab ich bei LANCOM schon eröffnet.
Welche Firmware hast Du auf dem 1900EF?
Ich habe vier 1900EF, die hatten auch so ein Problem.
Firmware 10.50.0953-RU8

Ich musste unter Communication > Remote Sites > "Establish remote site even without route (keepalive without route)"
ankaken, damit die interfaces online gingen und dann das Routing funktionierte.

Und das obwohl gültige Routen da waren.

Der Assistent setzt diesen Haken.

Sehr merkwürdig.

Viele Grüße

ts
TakeControl: Config Backup für LANCOM Router, ALC, APs und Switche...
https://www.linkedin.com/posts/activity ... 04032-DNQ5
https://www.nmedv.de
Benutzeravatar
BjörnG
Beiträge: 12
Registriert: 14 Feb 2022, 14:30

Re: FW/IDS am 1900EF macht nicht was sie soll

Beitrag von BjörnG »

tstimper hat geschrieben: 01 Nov 2022, 10:49
Ich musste unter Communication > Remote Sites > "Establish remote site even without route (keepalive without route)"
ankaken, damit die interfaces online gingen und dann das Routing funktionierte.

Und das obwohl gültige Routen da waren.

Der Assistent setzt diesen Haken.

Sehr merkwürdig.

Viele Grüße

ts
Moin ts,

wah, geiler Hinweis. Danke!!!
Ich dokumentiere das mal in unserer KEDB. ;)

Bei uns läuft noch die 10.50.0819RU7

Grüße,
Björn

Nachtrag: Den Haken hat der Assistent bei uns beim Neuanlegen nicht gesetzt... Setze den Haken dann jetzt mal manuell.
backslash
Moderator
Moderator
Beiträge: 7010
Registriert: 08 Nov 2004, 21:26
Wohnort: Aachen

Re: FW/IDS am 1900EF macht nicht was sie soll

Beitrag von backslash »

Hi BjörnG
obwohl ich FW-Regeln erstellt habe, daß die Netze 2.2.2.2 und 3.3.3.3 komplett offen kommunizieren dürfen, bekomme ich sporadisch folgende FW-Meldungen und es brechen VoIP-Verbindungen ab.

1.1.1.1: Router himself
2.2.2.2: WAN-IP
3.3.3.3: Cloud-VoIP-Server

Code: Alles auswählen

root@xwiki:/var/log/1.1.1.1# tail -f PACKET_ALERT.log | grep "3.3.3.3"
2022-10-28T08:46:04.149106+02:00 1.1.1.1 PACKET_ALERT: Dst: 2.2.2.2:10044 {1900EF}, Src: 3.3.3.3:41518 (UDP): connection refused
das hat erstmal nichts mit der Firewall zu tun, sondern eher mit dem NAT bzw. mit einer herausgealterten Session...
"connection refused" kommt immer dann, wenn das Paket an dei IP des Geräts (hier also die WAN-IP 2.2.2.2) gerichtet ist, es aber keinen Listener für das Paket gibt - bzw keine NAT-Session mehr
Den kann ich nicht nutzen im Moment. Wenn ich den Trace starte crashed das Routing des Routes.
Genauer, die WAN-Route wird nicht mehr bedient.
Man kann auf der CLI des Routers ins Internet pingen, und auch ins LAN, aber vom LAN kommt man nicht mehr raus.
Die default WAN-Route stellt die Funktion ein.

Man muss per Assistent die WAN löschen und neu anlegen, dann routet er erst wieder. Ein Neustart des Routers behebt den Fehler nicht.
das wage ich ehrlich gesagt zu bezweifeln, denn
a) was soll der Trace mit dem Routing zu tun haben
b) warum sollte ein Reboot nicht wieder in den vorherigen Zustand zurückkehren?
Ich musste unter Communication > Remote Sites > "Establish remote site even without route (keepalive without route)"
ankaken, damit die interfaces online gingen und dann das Routing funktionierte.
Das bringt aber nur etwas, wenn es gar keine statische Route auf das Interface gibt. Dann muß das Gerät über ein Routing-Protokoll wie RIP oder BGP seine Routne zugewiesen bekommen (oder auch per DHCP)

Gruß
Backslash
tstimper
Beiträge: 956
Registriert: 04 Jun 2021, 15:23
Wohnort: Chemnitz
Kontaktdaten:

Re: FW/IDS am 1900EF macht nicht was sie soll

Beitrag von tstimper »

backslash hat geschrieben: 02 Nov 2022, 11:00
Das bringt aber nur etwas, wenn es gar keine statische Route auf das Interface gibt. Dann muß das Gerät über ein Routing-Protokoll wie RIP oder BGP seine Routne zugewiesen bekommen (oder auch per DHCP)

Gruß
Backslash
So habe ich das auch verstanden, nur funktioniert es in meinem Fall auch bei vorhandenen statischen Routen nur mit Haken.
Ohne Haken bleiben die Interfaces auch mit statischen Routen down, wenn man manuell konfiguriert.

Gefühlt dreimal geändert und mit Lanconfig geschrieben führt dazu, das es eine Weile geht.

Das Verhalte ist nicht reproduzierbar.

Siehe LCSUP-125737 "Der Parameter "keepalive ohne Route” scheint nur zufällig mal zu funktionieren."

Viele Grüße

ts
TakeControl: Config Backup für LANCOM Router, ALC, APs und Switche...
https://www.linkedin.com/posts/activity ... 04032-DNQ5
https://www.nmedv.de
Benutzeravatar
BjörnG
Beiträge: 12
Registriert: 14 Feb 2022, 14:30

Re: FW/IDS am 1900EF macht nicht was sie soll

Beitrag von BjörnG »

Moin backlash,
backslash hat geschrieben: 02 Nov 2022, 11:00 Hi BjörnG

Code: Alles auswählen

root@xwiki:/var/log/1.1.1.1# tail -f PACKET_ALERT.log | grep "3.3.3.3"
2022-10-28T08:46:04.149106+02:00 1.1.1.1 PACKET_ALERT: Dst: 2.2.2.2:10044 {1900EF}, Src: 3.3.3.3:41518 (UDP): connection refused
backslash hat geschrieben:das hat erstmal nichts mit der Firewall zu tun, sondern eher mit dem NAT bzw. mit einer herausgealterten Session...
"connection refused" kommt immer dann, wenn das Paket an dei IP des Geräts (hier also die WAN-IP 2.2.2.2) gerichtet ist, es aber keinen Listener für das Paket gibt - bzw keine NAT-Session mehr
Danke für den Hinweis. Damit hast bestätigt was sich immer deutlicher zeigt, das NAT des Routers torpediert unsere VoIP-Sessions/Verbindungen...
Den kann ich nicht nutzen im Moment. Wenn ich den Trace starte crashed das Routing des Routes.
Genauer, die WAN-Route wird nicht mehr bedient.
Man kann auf der CLI des Routers ins Internet pingen, und auch ins LAN, aber vom LAN kommt man nicht mehr raus.
Die default WAN-Route stellt die Funktion ein.

Man muss per Assistent die WAN löschen und neu anlegen, dann routet er erst wieder. Ein Neustart des Routers behebt den Fehler nicht.
backslash hat geschrieben: das wage ich ehrlich gesagt zu bezweifeln, denn
a) was soll der Trace mit dem Routing zu tun haben
b) warum sollte ein Reboot nicht wieder in den vorherigen Zustand zurückkehren?

Gruß
Backslash
Klingt komisch? Ist aber leider so.
Deshalb hat es mich auch über 30Min. gekostet beim ersten Auftreten wieder online zu kommen. War kurz davor nen Werksreset zu machen und eine gesicherte Konfig einzuspielen. Hab dann aus der Verzweiflung mal die Route gelöscht und neu angelegt. WAN-Route funktionierte wieder...
Das ist mir dann später bei einem IP-Scan im LAN durch ein Inventarisierungstool auch noch mal passiert.
Deshalb ein Support-Case bei LANCOM eröffnet. LCSUP-130885 Mal schauen ob und was sie dazu sagen werden.

Grüße,
Björn
Antworten