IPv6 Internettraffic vom LAN-Interface wird durch ominöse Firewall-Regeln geblockt
-
@Trunex said in IPv6 Internettraffic vom LAN-Interface wird durch ominöse Firewall-Regeln geblockt:
Nach etwas forschen im Log habe ich eine Firewall-Regel entdeckt, die teilweise IPv6-Verkehr blockiert. Dies gilt für alle Interfaces, die IPv6 aktiviert hatten (Ausnahme: WAN).
Dann sieh doch in den Regeln nach WO die Regeln stehen und was sie angelegt hat?
Und wenn sie nirgends stehen - schau im Log Viewer was als Description angegeben ist, deshalb gibt es die ja. Normalerweise steht bei allem was automatisch generiert wird nen Standard Text bei. Gibts keinen Text wäre das seltsam dann muss die Regel irgendwo definiert sein. Bei allem was Benutzer angelegt haben steht norml. USER RULE mit bei. -
Besten Dank erstmal für die Rückmeldung @JeGr!
Tatsächlich habe ich die Beschreibungen der Regeln etwas stiefmütterlich behandelt, was mir natürlich jetzt auf die Füße fällt. Unabhängig davon habe ich die Rule-ID mit jeder einzelnen Regel händisch verglichen (ein typischer Fall von selber Schuld). Allerdings passte die ID zu keiner Regel, die unter Firewall angelegt wurde.
Lediglich in der CLI konnte ich die Regel finden. Der Inhalt dieser Regel passt jedoch zu keiner, die ich selbst angelegt habe. Da mein Regelwerk sehr übersichtlich ist, kann ich das mit Sicherheit so sagen (vielleicht ca. 10 Regeln). Im Log stand User Rule meines Wissens nach nicht bei.
Deshalb ist deine Frage die Richtige: Wo stehen die Regeln und wie wurden sie angelegt? Für mich macht das alles keinen Sinn.
Ich werde im Laufe der Woche meine Regeln korrekt benennen und IPv6 nochmal testen. Vermutlich wird dies keinen Mehrwert bringen, aber dann können wir dies schon mal ausschließen.
Wenn jemand noch eine Idee hat - gerne her damit! :-)
-
Schau in die Firewall Logs und schalte ggd vorher noch ein, dass die Regelbeschreibung als Spalte angezeigt wird. Dann kannst du lesen WER oder WAS die Regel macht oder gemacht hat :)
-
So ich konnte nun nochmal testen. Erstmal besten Dank @JeGr für den offensichtlichen Hinweis mit den Firewall-Descriptions. Das hat mehr geholfen, als ich vorher vermutet habe. Manchmal muss man das einfach nochmal vorgehalten bekommen.
Mir sind bei meinem Test zwei Dinge aufgefallen:
- Ein Traceroute zu google.com über IPv6 funktioniert über das WAN-Interface problemlos. Über das LAN-Interface kommt der Traceroute nicht über die Fritzbox hinaus. Vielleicht deutet das auf ein Problem mit den deligierten IPv6 Subnetzen und der Firewall der Fritzbox hin. Hat da noch jemand eine Idee? Die Fritzbox ist ja leider etwas intransparent...
Für die Theorie spricht auch noch, dass der Standard-IPv6-Verkehr rausgeht, wie besipielsweise ICMPv6 Pakete von Clients. Allerdings kommt kein ICMPv6 Paket zurück (auch nicht geblockt).
- Es wird diverser Verkehr von Local-IPv6-Adressen zu Multicast Adressen geblockt. Die Regel sieht wie folgt aus:
@7(1000107685) block drop in log inet6 all label "Default deny rule IPv6"
Mir sagt die Regel gar nichts und ich habe keine solche Regel beschrieben. Hat jemand eine Idee, wo die her kommen könnte?
Ich bin für jeden weiteren Tipp dankbar :-)
-
@Trunex Laut AVM kann die Fritzbox nur ein /62 an nachgelagerte Router weitergeben. Also max. 4 Subnetze.
https://avm.de/service/fritzbox/fritzbox-7590/wissensdatenbank/publication/show/1239_IPv6-Subnetz-in-FRITZ-Box-einrichten/ -
@privateer
Besten Dank für den Hinweis! Ich hatte auf dem WAN Interface vorher /57 Netz angefordert und über DHCP /64 Adressen verteilt.Nach deinem Hinweis hatte das WAN Interface auf /62 und auf DHCP /64 und später auf dem WAN Interface /57 und auf DHCP /62. nach jeder Änderung habe ich einen Reboot durchgeführt. Leider hat dies auch nichts gebracht :(
Hat jemand noch eine Idee? Ich habe echt keine Ahnung mehr, wo ich ansetzen soll.
-
Achja IPv6 habe ich aktuell nur für ein Interface aktiv (LAN), somit wird auch nur ein subnetz weiter verteilt.
-
@Trunex said in IPv6 Internettraffic vom LAN-Interface wird durch ominöse Firewall-Regeln geblockt:
Ich bin für jeden weiteren Tipp dankbar :-)
BTW: es gibt im gleichen Menü der Fritte wo auch exposed host für IPv4 eingestellt werden kann so etwas ähnliches für IPv6. Dann wird ICMPv6 etc. nicht mehr geblockt, das war leider lange das Problem bei den doofen Fritten, dass sie zwar das Subnetz delegiert, aber dann trotzdem firewall'd haben von extern. Sehr nervig. Das geht aber mit dem Schalter freizuschalten.
-
Danke für den Hinweis @JeGr !
Ich hatte die Einstellung zwar schon an der Fritzbox vorgenommen, ich habe vorsichtshalber die Freigabe gelöscht und neu angelegt und die PFSENSE neu gestartet. Leider bleiben die Symptome und das Problem wie gehabt.
Generell habe ich auch das Gefühl, dass die Problematik von einer Fehlfunktion der Fritte ausgeht. Was ich allerdings noch nicht verstehe, die in dem Post vor 13 Tagen genannte Regel (@7(1000107685) block drop in log inet6 all label "Default deny rule IPv6") immer noch ausgehenden IPv6 Verkehr vom LAN blockiert. Ich verstehe nicht, warum die existiert.
Hat da jemand noch eine Idee?
-
Warum wird wohl ein "DEFAULT DENY" existieren? Das ist das Default BLOCK ANY der Firewall selbst. Es wird immer alles geblockt was nicht explizit erlaubt ist. Verstehe deshalb die Frage nicht ganz? Wenn natürlich kein Traffic erlaubt ist, dann wird auch nichts rausgelassen und durch den Default Block weggehauen. Das ist doch normales - dokumentiertes - Verhalten?
-
@JeGr stimmt, es wäre ein normales Verhalten, wenn dieser Traffic nicht erlaubt wäre. Bei mir ist der IPv6 Verkehr auf den LAN Interface explizit erlaubt.
-
Regelwerk WAN Interface
Regelwerk LAN Interface (mit den deaktivierten Regeln oben, hatte ich mal etwas ausprobiert)
-
@Trunex In deiner Regel ist aber das Gateway vorgegeben, lass da doch mal Sternchen drin und konfiguriere unter Routing das Gateway. Oder Multicast muss vielleicht geblockt werden an Netzgrenzen. Also das dürfte alles so sein, wie es soll.
-
Da steht "LAN net". Bei IPv6 also der Prefix, der auf dem LAN anliegt. Das schließt aber NICHT Multicast Prefixe, DDE Adressen oder auch local unicast Adressen mit FD oder FE Prefix ein.
Zumal ich jetzt das Log nicht sehe, welches geblocktes IPv6 mit default deny hat - daher ist es nur mit Glaskugel schwer zu raten, aber ich gehe davon aus, dass alles was jetzt noch geblockt ist - logischerweise - nicht auf die Regel am LAN passt und das auch mit Absicht dann geblockt ist. Hat dann aber auch nichts mit dem Problem zu tun, denn Multicast soll eh nicht geroutet werden und FExx:-Traffic außer default-GW fe80::1 Geblubber ebenfalls nicht. Somit eigentlich korrekt.
-
So da bin ich wieder. Sorry für die später Rückmeldung, wollte es vernünftig durchtesten und bin vorher nicht dazu gekommen...
@Bob-Dig : Besten Dank für den Tipp. Habe ich getestet, hat aber nichts gebracht. Ggf. könnte es tatsächlich am Routing liegen, dazu gleich mehr.
@JeGr : Du hattest mit deiner Vermutung Recht. Der Block über die Rule 7 passiert tatsächlich, wenn Kommunikation von einer Link-Local Adresse (fe80) nach draußen geschehen soll. Das kann natürlich nicht funktionieren. Von daher passt das. Sorry, dann hatte ich das wohl übersehen... Laut Firewall-Log sollte alles okay sein. Lediglich kommt hin und wieder über eine Globale IPv-6-Adresse (vermutlich Fritzbox) auf den Port 80 der WAN Schnittstelle. Diese Kommunikation wurde erst von meiner Deny IPv6 Rule auf der WAN-Schnittstelle geblockt. Nachdem ich diese deaktiviert hatte, wurde sie über die genannte Rule 7 geblockt. Inwieweit das mit unserem Problem zu tun hat, kann ich noch nicht überblicken.
So wie es für mich derzeit aussieht, ist es tatsächlich ein Routing-Problem. Als Default-Gateway hatte ich "dynamic" aktiviert. Das Gateway ist somit aktuell Deckungsgleich mit dem Standard-Gateway des WAN-Interfaces. Dieses Gateway ist allerdings die Link-Local-Adresse (fe80) der Fritzbox. Kann das überhaupt funktionieren?
Ich hatte die Adresse über verschiedene Schnittstellen angepingt und keine Rückmeldung erhalten. Über die Link-Local-Adressen funktionierte es einwandfrei. Klingt für mich logisch, dass ich über die Global-Adressen der Schnittstellen keine Link-Local-Adresse erreichen kann.
Aber ist dies dann nicht das Grundproblem? Können die Schnittstellen deshalb nicht vernünftig mit der Fritzbox kommunizieren? Oder stehe ich, mal wieder, auf dem Schlauch?
Ich hatte testehalber versucht, dass Gateway entsprechend anzupassen (Global-Adressen der Fritzbox). Diese liegen aber außerhalb des erreichbaren Adressbereiches, deshalb nicht möglich.
Was sagt ihr zu dem Sachverhalt?
-
Kann ich jezt ohne mehr Details nicht pauschal was dazu sagen. Es ist aber nicht unüblich, dass autodiscover/SLAAC routing via fe80::1 macht, was das definierte default GW im Netz ist. Auf dem WAN ist das auch völlig OK. Wenn man intern das mit DHCP6 oder der pfSense macht, ist es doof, weil dann ansonsten mit LAN_net dann natürlich kein fe80 erlaubt ist. Muss man selbst steuern/konfigurieren, dass man da dann die FW IP6 als Gateway pusht/propagiert.
Aber auf dem WAN ist das legitim. Kann man auch manuell als gateway eintragen und anpingen, wenn die Gegenstelle was taugt und ping6 antwortet. Sehe ich kein Problem drin.
-
Ich habe die gleiche Konfiguration pfSense hinter fritz Box
56er Prefix Anforderung bei Vf
57er Prefix Anforderung durch die pfSense64er Prefix Verteilung im Lan und VLan
Die pfSense habe ich als Exposed Host freigegeben.
Läuft alles einwandfrei.
Vorgegangen bin ich hiernach als Hilfe.
https://blog.veloc1ty.de/2019/05/26/pfsense-opnsense-ipv6-delegation-fritzbox/
-
@Mickman99 Die Seite hatte ich in meinen vorherigen Besuchen ebenfalls gesehen. Sie führte bei mir jedoch auch nicht zum Erfolg :(
-
Deine FritzBox hat IPv6 und stellt dir einen Prefix zur Verfügung?
Also einen Prefix aus dem deines Providers und der kommt an der PfSense an oder ist das der Prefix den Du manuell in der FritzBox eingestellt hast?
-
@mickman99 Sorry mal wieder die späte Rückmeldung. Habe jetzt Urlaub und kann mich dem Thema wieder expliziter widmen.
Tatsächlich wird der Präfix einwandfrei auf die Interfaces verteilt und stimmen auch mit dem Präfix mit dem der FRITZ!Box überein. Laut Log der FRITZ!Box wird das verteilte Netz an das LAN Interface auch erkannt und als Exposed Host freigegeben.
Ich vertraue allerdings der Firewall der FRITZ!Box nicht so ganz. Ich richte parallel bei einem Nachbar einen OpenVPN Server über IPv6 ein. Auch dort wird der eingehender Verkehr trotz Exposed Host (natürlich nur zum Test so freigegeben) rejected. Sinn macht das nicht.
Zusätzlich ist bei meiner pfsense das Problem aufgetreten, wenn viele Daten auf einmal verarbeitet werden müssen, dass der interne DNS Server abschmiert. Da habe ich auch die Vermutung, dass es an der FRITZ!Box liegt. Der Log der Fritte verrät da allerdings nicht so viel...
