[Problem] instabile AVM-Firewall auf 7270

So, hier kommt mein Testergebnis, ich hab's nicht systematisch gemacht, sondern ganz einfach für eine praktisch brauchbare Konfiguration ohne Pseudoregeln die Reihenfolge verändert, so daß nie mehr als drei „gleichartige IP-Regeln“ hintereinander stehen. In der Praxis sind's dann eher Zweiergrüppchen geworden, weil ich logisch zusammengehörige nicht auseinanderreißen wollte:

/*lowinput*/
Code:
deny ip any host 255.255.255.255 /*Broadcast*/
deny ip host 255.255.255.255 any /*Broadcast*/
reject ip any 172.16.0.0 255.240.0.0 /*lokal B*/
reject ip 172.16.0.0 255.240.0.0 any /*lokal B*/
deny ip any 242.0.0.0 255.255.255.0 /*lokales Multicast*/
deny ip 242.0.0.0 255.255.255.0 any /*lokales Multicast*/
reject ip any 169.254.0.0 255.255.0.0 /*Zeroconf*/
reject ip 169.254.0.0 255.255.0.0 any /*Zeroconf*/
deny ip any 239.255.0.0 255.255.0.0 /*lokales Multicast*/
deny ip 239.255.0.0 255.255.0.0 any /*lokales Multicast*/
reject ip any 192.168.0.0 255.255.0.0 /*lokal C*/
reject ip 192.168.0.0 255.255.0.0 any /*lokal C*/
deny ip any 239.192.0.0 255.252.0.0 /*lokales Multicast*/
deny ip 239.192.0.0 255.252.0.0 any /*lokales Multicast*/
reject ip any 10.0.0.0 255.0.0.0 /*lokal A*/
reject ip 10.0.0.0 255.0.0.0 any /*lokal A*/
reject udp any any range 137 138 /*Netbios*/
reject tcp any any eq 139 /*Netbios*/
reject tcp any any eq 445 /*CIFS*/
reject tcp any any eq 901 /*SWAT*/
reject ip any 198.18.0.0 255.254.0.0 /*Test*/
reject ip 198.18.0.0 255.254.0.0 any /*Test*/
reject udp any any range 161 162 /*SNMP*/
reject udp any any eq 514 /*Syslog*/
reject ip any 192.0.2.0 255.255.0.0 /*Doku 1*/
reject ip 192.0.2.0 255.255.0.0 any /*Doku 1*/
reject udp any any eq 111 /*RPC*/
reject udp any any eq 2049 /*NFS*/
reject tcp any any eq 2049 /*NFS*/
reject udp any any eq 135 /*DCE-RPC*/
reject tcp any any eq 135 /*DCE-RPC*/
reject ip any 198.51.100.0 255.255.0.0 /*Doku 2*/
reject ip 198.51.100.0 255.255.0.0 any /*Doku 2*/
reject tcp any any eq 515 /*LPD*/
reject udp any any eq 631 /*CUPS*/
reject tcp any any eq 631 /*CUPS*/
reject tcp any any eq 9100 /*Drucker*/
reject ip any 203.0.113.0 255.255.0.0 /*Doku 3*/
reject ip 203.0.113.0 255.255.0.0 any /*Doku 3*/
/*highoutput*/
Code:
deny ip any host 255.255.255.255 /*Broadcast*/
deny ip host 255.255.255.255 any /*Broadcast*/
reject ip any 172.16.0.0 255.240.0.0 /*lokal B*/
deny ip any 242.0.0.0 255.255.255.0 /*lokales Multicast*/
deny ip 242.0.0.0 255.255.255.0 any /*lokales Multicast*/
reject ip any 169.254.0.0 255.255.0.0 /*Zeroconf*/
deny ip any 239.255.0.0 255.255.0.0 /*lokales Multicast*/
deny ip 239.255.0.0 255.255.0.0 any /*lokales Multicast*/
permit ip any 192.168.180.1 255.255.255.255 /*AVM-DNS*/
permit ip any 192.168.180.2 255.255.255.255 /*AVM-DNS*/
reject ip any 192.168.0.0 255.255.0.0 /*lokal C*/
deny ip any 239.192.0.0 255.252.0.0 /*lokales Multicast*/
deny ip 239.192.0.0 255.252.0.0 any /*lokales Multicast*/
reject ip any 10.0.0.0 255.0.0.0 /*lokal A*/
reject udp any any range 137 138 /*Netbios*/
reject tcp any any eq 139 /*Netbios*/
reject tcp any any eq 445 /*CIFS*/
reject tcp any any eq 901 /*SWAT*/
reject ip any 198.18.0.0 255.254.0.0 /*Test*/
reject udp any any range 161 162 /*SNMP*/
reject udp any any eq 514 /*Syslog*/
reject ip any 192.0.2.0 255.255.0.0 /*Doku 1*/
reject ip 192.0.2.0 255.255.0.0 any /*Doku 1*/
reject udp any any eq 111 /*RPC*/
reject udp any any eq 2049 /*NFS*/
reject tcp any any eq 2049 /*NFS*/
reject udp any any eq 135 /*DCE-RPC*/
reject tcp any any eq 135 /*DCE-RPC*/
reject ip any 198.51.100.0 255.255.0.0 /*Doku 2*/
reject ip 198.51.100.0 255.255.0.0 any /*Doku 2*/
reject tcp any any eq 515 /*LPD*/
reject udp any any eq 631 /*CUPS*/
reject tcp any any eq 631 /*CUPS*/
reject tcp any any eq 9100 /*Drucker*/
reject ip any 203.0.113.0 255.255.0.0 /*Doku 3*/
reject ip 203.0.113.0 255.255.0.0 any /*Doku 3*/

Diese Regeln laufen hier absturzfrei, die Kommentare stehen auch so drin, stören also wie erwartet auch nicht, wenn sie mal was länger sind. Eingehende und ausgehende Regeln sind leicht asymmetrisch, weil ich - in der Annahme, erst kommt die AVM-Firewall, dann das AVM-NAT, dann das Internet - ausgehend die Privatadressen als „Absender“ durchlasse, als Ziele dann logischerweise auch diese seltsamen DNS-Weiterleitungen. Sollte die Reihenfolge andersherum sein, müßte man das nochmals überdenken.

Wenn man die obigen „Lowinput“-Regeln zum „Highoutput“ kopiert, sollte man's merken, wenn man dann nicht mehr ins Internet kommt, habe ich richtig geraten, aber das mache ich jetzt nicht mehr, vielleicht später mal, wenn ich Zeit habe. Eigentlich müßte man's wissen, um sinnvolle Regeln ohne Ballast zu erstellen, der gar nicht wirkt, aber Rechenzeit frißt.
 
Hallo MaxMuster,

da die nach Deinem Ergebnis in der Reihenfolge abgeänderten Regeln hier seit der ersten Einstellung stabil laufen, denke ich, es ist an der Zeit, davon AVM in Kenntnis zu setzen und das zu dokumentieren, bis die ihr Programm behoben haben. Ich kann das Ergebnis gerne ins Freetz–Wiki einbauen, da bin ich ja jetzt ohnehin angemeldet. Wenn ich mich recht erinnere, hattest Du das lange vor der „Maximal–drei–gleichartige–Erkenntnis“ schonmal an AVM geschickt, da würde es sich empfehlen, wenn Du als Entdecker nun nochmal „nachlegst“, zumal Du von der Konsole so schöne Logs mitsenden könntest.

Viele Grüße, Christoph
 
@all:

Da habt Ihr ja eine klasse Analyse hingelegt, vielleicht solltet Ihr AVM kaufen, weil Ihr es besser drauf habt... ;-) Also auf jeden Fall mal ein großes Lob und vielen lieben Dank!

Aber leicht offtopic: Hat jemand die Abhilfe aus der Reboot-Schleife durch Trennung des DSL-Kabels auch auf einer 7390 verifiziert? Bei mir ist das Umflashen immer eine Riesensache, weil ich an den Router nicht direkt ran komme und immer meinen halben Schrank im Flur umbauen muß.

Hawedieehre.
Fant.
 
Deine Frage passt nicht ganz zum Topic!?

Gruß
Oliver
 
Ja, weil es ja eigentlich um die 7270 und nicht um die 7390 geht...

Trotzdem ist das eine intessante Frage...
 
@all:

Okay, ich kann meine Frage jetzt selbst beantworten. Ich mußte es (unfreiwillig) testen wollen!!! Wenn man das DSL-Kabel abzieht, kann man auch die Fritz!Box 7390 wieder erreichen und die "strittigen" Firewall-Regeln entfernen.

Ich habe entsprechend den obigen Ausführungen im Freetz-AVM-Firewall Frontend die Standart-Einstellungen geladen und dann meine Einstellungen dazu gemacht. Dabei habe ich drauf geachtet, daß keine drei any-any-ip-Regeln direkt hintereinander stehen.

Wenn ich aber folgende Einstellungen eintrage:
/*highoutput/*
Code:
permit udp 192.168.2.0 255.255.255.0 any eq 1194
permit tcp 192.168.2.0 255.255.255.0 host 134.60.1.26 eq 587
permit tcp 192.168.2.0 255.255.255.0 any eq 22
permit tcp 192.168.2.0 255.255.255.0 host 134.60.1.11 eq 587
permit ip host 192.168.2.29 any
permit tcp 192.168.2.0 255.255.255.0 host 134.60.1.111 eq 993
reject ip 192.168.2.0 255.255.255.0 any
reject ip any 242.0.0.0 255.0.0.0 /*AVM*/
reject udp any any eq 135
reject tcp any any eq 135
deny ip any host 255.255.255.255 /*AVM*/
reject udp any any range 137 139
reject tcp any any range 137 139
reject ip any 169.254.0.0 255.255.0.0 /*AVM*/
reject udp any any range 161 162
reject udp any any eq 520
reject udp any any eq 111
reject udp any any eq 22289
reject udp any any eq 1710
reject udp any any eq 1048
reject udp any any eq 158
reject udp any any eq 515
reject icmp any 149.1.1.0 255.255.255.0

dann landet meine 7390 in einer Dauerreset-Schleife. Alle Regeln mit 192.168.2.X sind von mir. Der Rest ist aus der Standart-Einstellung, die ich nicht geändert habe. Warum geht das nicht?!!?? Was mache ich falsch?

Hawedieehre.
Fant.
 
Zuletzt bearbeitet:
@fant:
Habe das auf einer 7390 nicht weiter getestet, eventuell besteht dort das Problem weiterhin (wie in dem oben mal genannten Thread mit der 7270, wo es nicht um "ip" Regeln ging. Vielleicht ist es hier auch noch mit der Summe anderer Regeln, oder "tcp", "udp" und "ip"-Regeln zählen zusammen oder ...

Versuche doch erstmal, immer nach zwei (eigenen) Regeln eine Regel zur "Abgrenzung" einzufügen, sowas wie hier (ab "reject ip any 242.0.0.0 255.0.0.0" war es ja Original, oder??):

Code:
permit udp 192.168.2.0 255.255.255.0 any eq 1194
permit tcp 192.168.2.0 255.255.255.0 host 134.60.1.26 eq 587
[B]deny ip any host 255.255.255.255 /*AVM*/[/B]
permit tcp 192.168.2.0 255.255.255.0 any eq 22
permit tcp 192.168.2.0 255.255.255.0 host 134.60.1.11 eq 587
[B]deny ip any host 255.255.255.255 /*AVM*/[/B]
permit ip host 192.168.2.29 any
permit tcp 192.168.2.0 255.255.255.0 host 134.60.1.111 eq 993
[B]deny ip any host 255.255.255.255 /*AVM*/[/B]
reject ip 192.168.2.0 255.255.255.0 any
reject ip any 242.0.0.0 255.0.0.0 /*AVM*/
reject udp any any eq 135
reject tcp any any eq 135
deny ip any host 255.255.255.255 /*AVM*/
reject udp any any range 137 139
reject tcp any any range 137 139
reject ip any 169.254.0.0 255.255.0.0 /*AVM*/
reject udp any any range 161 162
reject udp any any eq 520
reject udp any any eq 111
reject udp any any eq 22289
reject udp any any eq 1710
reject udp any any eq 1048
reject udp any any eq 158
reject udp any any eq 515
reject icmp any 149.1.1.0 255.255.255.0

Ansonsten bleibt nur, "ranpirschen", also immer eine Regel hinzufügen, speichern und übernehmen, und beobachten, ab wann es "knallt".

@Christoph_F:
Ich suche die AVM-Mail "von damals" wieder raus und melde das. Habe momentan aber keinen Zugriff, weil ich unterwegs bin.

Jörg
 
@fant:
Die ADSL-Abklemm-Methode sollte immer dann funktionieren, wenn die Kiste als ADSL-Router läuft; wenn die nur Ethernet routet, geht es nicht (von MaxMuster getestet); wenn die Modem-Funktion ausgeschaltet ist, also ein externes ADSL-Modem dranklemmt, geht es auch über die Ethernet-Switch-Buchsen nach draußen (halt nicht mit IP wie im Ethernet-Router-Fall, sondern PPPoE oder ausländisch auch PPTP), jedoch ist auch da eine „Einwahl“ erforderlich wie im ADSL-Router-Fall, diese Variation hat wohl noch niemand getestet.

Was die Regeln betrifft, leuchtet mir die eine oder andere inhaltlich nicht ein (was ist 149.1.1.0/24 und warum soll dahin kein ICMP gehen?), aber die MaxMuster-Methode hat bei Dir anscheinend versagt, es muß noch mehr dahinterstecken oder was anderes; vielleicht ist das Problem bei der 7390 ja auch von AVM verschlimmert worden.

Meine Arbeitshypothese geht dahin, daß auch zwischen jeweils drei "reject udp" irgendwas anderes sollte, damit nochmal testen, ansonsten „ranpirschen“ wie bereits vorgeschlagen.

@MaxMuster:
Fein, ich wollte gerade das Freetz-Wiki in Angriff nehmen und Dich da lobend erwähnen, aber…

@olistudent:
… die Anmeldung auf Freetz.org ist anscheinend abgeklemmt? Die ganze „Kopfzeile“ scheint auf den Trac–Seiten zu fehlen.
 
Ach so, falls Du nicht weiterkommst, sag' mal Bescheid und nenne uns mal unverändert alle Regeln (eingehend, ausgehend und Port–Weiterleitungen) dann lade ich die bei mir in die 7270 und schaue, ob sie dort gehen oder ebenso versagen.
 
Ich habe nur die Regeln dazu gemacht, die was mit 12.168.2.X enthalten. Die anderen sind von der Funktion: "Standard" im AVM-Firewall-Frontend eingetragen. Ich habe diese mal drin gelassen, weil ich sicher gehen wollte, daß irgendwas mal drin steht. Wenn ich nur diese Regeln setze, dann geht es komischerweise...obwohl da sich auch ähnliche Regeln knubbeln...

Hawedieehre.
Ingo.
 
@Christoph_F:
Ich suche die AVM-Mail "von damals" wieder raus und melde das. Habe momentan aber keinen Zugriff, weil ich unterwegs bin.
Antwort von AVM (ist schon vor einer Woche gekommen):

Hallo Herr ****,

vielen Dank für den Hinweis. Wir haben den Punkt identifizieren können und er wird im nächsten Labornachleger behoben sein.

Viele Grüße und ein schönes Wochenende!

#####
 
Die Anmeldung ging wieder, als ich jetzt nochmal reingeschaut habe, das Freetz-Trac-Wiki enthält also nun die hier gesammelten Erkenntnisse. Gibt es was neues von der 7390?
 

Zurzeit aktive Besucher

Keine Mitglieder online.

Statistik des Forums

Themen
246,219
Beiträge
2,248,328
Mitglieder
373,792
Neuestes Mitglied
gilbertsamson563
Holen Sie sich 3CX - völlig kostenlos!
Verbinden Sie Ihr Team und Ihre Kunden Telefonie Livechat Videokonferenzen

Gehostet oder selbst-verwaltet. Für bis zu 10 Nutzer dauerhaft kostenlos. Keine Kreditkartendetails erforderlich. Ohne Risiko testen.

3CX
Für diese E-Mail-Adresse besteht bereits ein 3CX-Konto. Sie werden zum Kundenportal weitergeleitet, wo Sie sich anmelden oder Ihr Passwort zurücksetzen können, falls Sie dieses vergessen haben.