IPv6 Internettraffic vom LAN-Interface wird durch ominöse Firewall-Regeln geblockt
-
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...
