OPNsense Forum
International Forums => German - Deutsch => Topic started by: direx on March 25, 2019, 06:44:08 pm
-
Hallo,
ich betreibe OPNsense 19.1.4 an einem DualStack-Anschluss der Telekom. Mein IPv6-Präfix ändert sich leider regelmäßig. Damit habe ich nun folgendes Problem bei den Firewall-Regeln.
Ich besitze derzeit folgende Interfaces mit 5 Subnetzen:
- LAN mit 192.168.1.0/24 und IPv6 Prefix-Tracking
- SRV mit 192.168.2.0/24 und IPv6 Prefix-Tracking
- MMT mit 192.168.3.0/24 und IPv6 Prefix-Tracking
- IOT mit IPv4-only 192.168.4.0/24
- GST mit 192.168.5.0/24 und IPv6 Prefix-Tracking
- ... und WAN
Die Netze sollen sich untereinander erstmal nicht erreichen (nur per Ausnahme). Mir geht es jetzt um Regeln der Art:
"Erlaube Internetzugang aus dem LAN-Netz"
Für IPv4 ist das einfach, da ist das pro Interface diese Regel:
ALLOW destination !192.168.0.0/16
Wie mache ich das für IPv6 sauber? Durch den dynamischen Präfix kann ich ja nicht einfach sagen "erlaube alles, außer destination $PREFIX/48".
Die einzige Möglichkeit, die ich gefunden habe, sind pro Interface erstmal 3 DENY-Regeln mit allen lokalen v6-Netzen (SRV-Net, MMT-Net, ...) als Ziel und darunter dann eine ALLOW-All-Regel. Das ist aber zum einem sehr umständlich und zum anderen ist die ALLOW-All-Regel recht fehleranfällig. Kommt mal ein neues Netz hinzu, dürfen alle erstmal in das Netz. Man muss dann immer noch an eine neue DENY-Regel für jeweils jedes v6-Interface denken.
Irgendwas mache ich doch bestimmt falsch, oder? Ich bin doch sicher nicht der erste, der IPv6 mit OPNsense nutzen will.
Danke und Grüße
direx
-
Leider gibt es keine Platzhalter für das aktuelle IPv6 Präfix in den Firewallregeln.
Du kannst versuchen einen IPv6 DynDNS Dienst zu verwenden, auf diese DynDNS Domain einen Hostname Alias zu setzen und diesen Hostname Alias dann in der Firewall zu verwenden.
Das sollte theoretisch dafür sorgen, dass alle paar Minuten der Alias in seine Adresse aufgelöst wird und diese dann von der Firewall verwendet wird.
Ob Aliases mittlerweile mit ne v6 Host funktionieren weiß ich aber nicht. Hatte da immer Probleme.
-
Hallo,
vielen Dank für die Antwort. Leider löst das aber mein Problem nicht, denn:
- Kann ich per DynDNS nur einzelne Hosts registrieren, nicht aber einen kompletten v6-Präfix
- Ich möchte nicht, dass die Sicherheit im lokalen Netz von einem externen Dienst abhängt
- Ist bei einem Präfix-Wechsel kurzzeitig meine Firewall so lange offen, bis mal ein Alias-Refresh stattfindet.
Das kann es doch nicht sein, oder?
Ich formuliere meine Frage mal anders:
Wie sieht eine "Erlaube Internetzugang"-Regel für IPv6 aus?
Danke und viele Grüße
direx
-
> Das kann es doch nicht sein, oder?
Das ist das Problem bei dieser unsäglich "tollen" Technik mit rotierenden Prefixen. Damit lassen sich dann eben leider keine Prefix Aliase definieren, weil du leider vorher nicht weißt, welches du hast. Außer mit den <interface>_net Aliasen zu arbeiten wird dir leider nichts anderes übrig bleiben. :(
Mit ein Grund warum ich schlußendlich mit einem statischen Tunnel arbeite und nicht mit dem Provider Prefix (außer für Gästenetze). Trotzdem extrem unbefriedigend und unnötig.
-
Also kann man die Aussage wagen: Sobald mehrere Subnetze im Einsatz sind, dann ist "richtiges" IPv6 Pflicht? (Ausser man will basteln oder nur IPv4 verwenden.)
Man sollte die ISPs verpflichten, dass zumindest auf Anfrage ein statisches Präfix zur Verfügung gestellt werden muss. Und das kostenlos und nicht nur bei "Business-Anschlüssen". Hätte man gleich in den Standard mit einbauen sollen und bei Zuwiderhandlung muss der Laden schliessen oder so. :)
-
Ich bin durchaus mit dynamischem Präfix zufrieden am Privatanschluss. Das "Problem" liegt eher daran, dass viele Funktionen einfach nicht prefix change aware sind.
-
Hallo,
also das mit dem dynamischen Präfix finde ich aus Privatsphäre-Sicht eigentlich auch ganz okay. Das ist glaube ich auch Gang und Gäbe bei so ziemlich allen ISPs. Immerhin bekomme ich ein /56er-Präfix von der Drosselkom, damit kann man recht gut arbeiten. Durch das Prefix-Tracking kommt OPNsense ja auch grundsätzlich damit klar.
Also kann man die Aussage wagen: Sobald mehrere Subnetze im Einsatz sind, dann ist "richtiges" IPv6 Pflicht? (Ausser man will basteln oder nur IPv4 verwenden.)
Also "richtiges" IPv6 ist es ja schon. Die spannende Frage ist halt, wie sich das die OPNsense-Entwickler gedacht haben - auf der einen Seite gibt es Prefix-Tracking an den Interfaces (für genau solche Umgebungen mit dynamische Prefixen) und auf der anderen Seite kommt die Firewall damit offenbar nicht klar. Das verwirrt mich halt.
Ich kann auch nochmal im englischsprachigen Forum fragen, vielleicht ließt ja dort ein Entwickler mit und kann Auskunft geben, wie das jetzt konkret gedacht ist.
Viele Grüße
direx
-
Ich weiss nicht ob ich IPv6 als "richtig" bezeichnen will, wenn es NUR mit dynamischen Präfixen ausgeliefert wird. Das sieht mir eher nach von ISP-Marketingabteilungen kaputt gemacht aus. Aber um das soll sich die Diskussion hier nicht drehen.
Ist auf franco’s "long-term TODO list":
https://forum.opnsense.org/index.php?topic=9773.msg44620#msg44620
Wie sieht das eigentlich bei der Konkurrenz aus? Gibt es gut funktionierende Lösungen für diesen Anwendungsfall?
-
> Wie sieht das eigentlich bei der Konkurrenz aus? Gibt es gut funktionierende Lösungen für diesen Anwendungsfall?
Nein, weil im IPv6 RFC so ein Bullshit ursprünglich gar nicht vorgesehen ist.
> also das mit dem dynamischen Präfix finde ich aus Privatsphäre-Sicht eigentlich auch ganz okay.
Es bringt für die Privatsphäre genauso wenig wie bei IPv4. Gar nichts. Wenn jemand die IP gerichtlich o.ä. erfragt bekommt er genauso Antwort bei v6 wie v4. Und Mechanismen zum eindeutigen Erkennen von Benutzern brauchen heute lange keine IP mehr.
> Das ist glaube ich auch Gang und Gäbe bei so ziemlich allen ISPs
Weil es alle anderen so idiotisch nachgemacht haben, ist es nicht "OK". Nur die Marketing Schiene, dass es ja "was positives" für den Kunden ist und man ja um seine Privatsphäre besorgt ist ... was ein BS. Da ging es historisch nur um Faulheit, interne Prozesse umzustellen auf die Moderne (PPP -> PPPoE Abrechnung) und später hat man damit eine tolle Ausrede gehabt, warum man das als "Feature" bei Business Anschlüssen teuer verkaufen kann, obwohl es der gleiche Anschluß und Technik ist. Einfach kompletter Nonsense.
> Also "richtiges" IPv6 ist es ja schon.
Nicht wirklich, denn IPv6 - z.B. im Servereinsatz etc. - sieht absolut auch statische IP6 Vergabe vor. Wie will ich aber statische IP6 vergeben wenn sich alle paar Tage/Wochen der Prefix ändert?
Man sieht es BTW an lokalen oder kleineren Anbietern, die sich mit alten Zöpfen nicht herumschlagen müssen, dass dort statische IPs oder Prefixe oft gar kein Problem sind. Heute bei hinterhergeworfenen VPN-Anbietern noch von "Privacy Feature" im Marketing zu faseln ist schon frech ;)
-
Ist auf franco’s "long-term TODO list":
https://forum.opnsense.org/index.php?topic=9773.msg44620#msg44620
Das ist schonmal eine gute Nachricht, danke für den Link. :) Ist zwar schon etwas älter und ins 19.1er-Release hat es das offenbar nicht geschafft, aber vielleicht klappt es mit dem 19.7er.
> Wie sieht das eigentlich bei der Konkurrenz aus? Gibt es gut funktionierende Lösungen für diesen Anwendungsfall?
Nein, weil im IPv6 RFC so ein Bullshit ursprünglich gar nicht vorgesehen ist.
Naja, im ursprünglichen RFC2460 fehlt ja so einiges. Viele Dinge kommen halt erst später dazu, das war schon immer so. DHCPv6 mit "long-lived prefixes" kam halt "erst" 2003 im RFC3633. Aber wie genau "long-lived" zu interpretieren ist, lässt der RFC (wohl bewusst) außen vor. Diese Diskussion führt also zu nix.
Und weil die Frage bezüglich der "Konkurrenz" aufkam, dort gibt es das Problem gar nicht. In IPFire kann man z.B. Regeln definieren der Art "ALLOW -in LAN -out WAN", komplett auf Interface-Ebene und damit entkoppelt von irgendwelchen v4 oder v6-Adressen. Dynamische Präfixe sind demnach dort gar kein Problem.
Und bei Unifi von Ubiquiti geht das auch per Management-Shell. Übrigens sind sogar inbound-Regeln für v6 bei diesen beiden "Konkurrenten" problemlos möglich (bei statisch gesetzten IPv6-Tokens), indem einfach nur die letzten Bits der Adresse gematcht werden (inverted mask match).
Aber wie gesagt, ich wollte hier gar keine Diskussion dieser Art lostreten, weil das zu nix führt. Nur die Behauptung, dass das sowieso alles Bullshit ist und die Konkurrenz auch keine funktionierenden Lösungen hat, wollte ich so nicht stehenlassen. Ich denke wir bleiben trotzdem alle bei OPNsense ;)
> Das ist glaube ich auch Gang und Gäbe bei so ziemlich allen ISPs
Weil es alle anderen so idiotisch nachgemacht haben, ist es nicht "OK". Nur die Marketing Schiene, dass es ja "was positives" für den Kunden ist und man ja um seine Privatsphäre besorgt ist ...
Mir persönlich wäre ein statischer Präfix für meinen Anwendungsfall natürlich auch lieber. Allerdings ist deine grundsätzlich ablehnende Haltung hier auch wieder nicht zielführend in der Diskussion. Jeder hat andere Anforderungen und ich würde das Privatsphäre-Argument tatsächlich gelten lassen (auch wenn das vielleicht aus einer Marketing-Abteilung kommt). Privacy-Extensions sind relativ witzlos, weil man dich über den Prefix trotzdem tracken kann. Und klar, natürlich kann man dich auch trotz dynamischen Präfix mit verschiedenen Techniken tracken, aber es ist halt etwas aufwändiger. Die IPv6-Adresse als Tracking-Merkmal servierst du halt auf dem Silbertablett.
Und klar ist das eine miese Nummer, dass die Drosselkom statische Präfixe als "Business" verkauft, obwohl der Mehraufwand dafür quasi Null ist. Wir müssen aber halt auch irgendwie mit dem klarkommen, was aktuell (leider) am Markt üblich ist. Es kann sich halt nicht jeder immer seinen ISP aussuchen.
Man sieht es BTW an lokalen oder kleineren Anbietern, die sich mit alten Zöpfen nicht herumschlagen müssen, dass dort statische IPs oder Prefixe oft gar kein Problem sind.
Die kleinen Anbieter sind häufig die bessere Wahl. Besonders die Telekom ist ja bekannt dafür, überall so viel Geld zu erpressen, wie nur irgend möglich - siehe die Wegelagerei mit dem Peering/Double-Paid-Traffic. Aber das driftet schon wieder aber, sorry.
Man muss halt einfach mal der Realität ins Auge sehen. Und die sieht eben so aus, dass die großen ISPs DHCPv6 mit sich ändernden Prefixen fahren. Ich glaube mein Prefix ändert sich auch nur bei der PPPoE-Neueinwahl (also bei jedem Firewall-Reboot) und ist damit tatsächlich quasi "long-lived". In Firewall-Regeln kann ich ihn deswegen aber trotzdem nicht benutzen und da hoffte ich eben auf irgendeine sinnvolle Lösung.
Falls doch noch jemand was zur eigentlichen Problemlösung beitragen kann, wäre ich natürlich dankbar. Aktuell bleibt halt wirklich nur als Workaround auf jedem Interface eine DENY-Regel für jeweils alle anderen v6-Netze. Und danach dann eine ALLOW-any-Regel.
Viele Grüße
direx
-
"ALLOW -in LAN -out WAN -proto IPv6" geht doch auch in opnsense? Hier kann ich die Adressen zumindest offen lassen... von iptables auf debian kenne ich das auch so.
Dann .. wenn man eine feste IP beauftragt... so ist's zumindest bei Netcologne, bekommt man doch neben einer festen ipv4 auch ein festen ipv6 präfix. Da verschiebt sich nichts mehr.
Das sich der Präfix mit jedem dialin bei einer variablen IPv6 im Rahmen der v6 Range bewegt, die der Provider selbst für diese Zwecke zugeteilt bekommen hat ist normal, deine Fritzbox bzw dein dhcpv6 client auf dem WAN sollte den aktuell gültigen präfix auch kennen... sonst könnte er daraus keine gültige IPv6 basteln. Windows Clients basteln ja auch mit Hilfe der Prefix Info und der Privacy Extension am laufenden Band neue tempräre IP Adressen im Adressraum der zugewiesenen Prefix - dabei geht es aber nicht um obfuscation des Subnetzes, sondern lediglich der Verbindung/Host im Subnetz. In wie weit das privacy ist, mag jeder selbst beurteilen, in *nix Betriebssystemen ist die Privacy Extension heute noch per default abgeschaltet und den Staatsanwalt interessiert im Zweifel nur das zugewiesene Subnet/Prefix.
Ausserdem hab ich in der GUI Regelerstellung bei Quelle und Ziel neben "jeglich" und "Host" auch "LAN Netzwerk" und "LAN Adresse" zur Auswahl. Ich habs nicht probiert aber "LAN Adresse" müsste die grade gültige volle IP meines LAN Adapters sein und "LAN Netzwerk" mein Prefix? Respektive das gleiche für WAN?
Ob der FW-Regelsatz neu geladen wird wenn sich die IP wegen abgelaufener Lease/Zwangstrennung ändert, weis ich nicht aber gehe stark davon aus... der dhcp6 client auf wan sollte das veranlassen wenn er IP bzw. besser gesagt Präfixwechsel erkennt.
Aus verschiedenen Gründen sehe ich das Präfix Problem also nicht... allerdings bin ich auch kein BSD Spezi und hab mich auch noch nicht mit dem speziellen Opnsense Routing/Bridging en Detail beschäftigt.
-
"ALLOW -in LAN -out WAN -proto IPv6" geht doch auch in opnsense?
Eben nicht, sonst wäre es ja ganz einfach. Zumindest wüsste ich nicht, wo man das einstellt. Wo willst du das denn einstellen? Du kannst meiner Meinung nach als Destination nur sagen "WAN address" oder "WAN net", aber beides ist nicht gleich "WAN interface". Oder übersehe ich da jetzt was?
Danke und viele Grüße
direx
-
die "ALLOW -in LAN -out WAN -proto IPv6" sieht in der GUI so aus, und ist auf das LAN gebunden...
"IPv6 * * * * * * testrule "
So wird sie in der shell angezeigt. em0 ist mein lan, nfe0 wan.
root@drexbox:~ # pfctl -a '*' -sr | grep test
pfctl: DIOCGETRULES: Invalid argument
pass in quick on em0 inet6 all flags S/SA keep state label "USER_RULE: testrule"
root@drexbox:~ #
Wobei das genau genommen eine "ALLOW -in LAN -out any -proto IPv6" ist.. eine -out wan mit prefix sieht so aus:
pfctl: DIOCGETRULES: Invalid argument
pass in quick on em0 inet6 from any to (nfe0:network) flags S/SA keep state label "USER_RULE: testrule"
root@drexbox:~ #Ansicht in der GUI ist dann:
"IPv6 * * * WAN Netzwerk * * testrule "
wie gesagt.. unter iptabels ist das quasi baugleich auch so.... in der englischen GUI steht da vermutlich halt WAN Network bei Ziel/Target.. bin ich jetzt zu faul das auszuprobieren. Wobei die Rule so wenig Sinn macht... oben oder die bzw. "to (em0:network)" wäre zweckmässiger wenn man sein LAN präfix als Target referenzieren will .. also wenn em0 dem LAN entspricht.... egal es geht jedenfalls!
Ein "wan interface" als target gibts in der GUI so wie du sagst erst mal nicht...korrekt, aber wie das Paket es über die Mauer schafft ist doch ansich egal... eine "pass all ipv6 in,out" Regel wie im ersten Beispiel würde gehen, eine "pass all ipv6 in, out prefixnet" wie der Threadstarter es anfragt im 2. Beispiel auch.
eine selbst gefrickelte
pass in quick on em0 inet6 from any to nfe0 flags S/SA keep state"
... also ohne das network... via shell Befehl oder script würde vermutlich auch gehen, auch wenn die GUI das nicht anbietet.
probier ich jetzt aber nicht aus... 2 Alternativen reichen erst mal :)
-
Moin,
ich glaube wir reden aneinander vorbei :)
Wobei das genau genommen eine "ALLOW -in LAN -out any -proto IPv6" ist..
Genau das ist das Problem. Das "-out any" würde dann auch sämtlichen IPv6-Traffic in andere lokale Subnetze durchlassen, was ich genau nicht möchte. Normalerweise müsste die Regel nach OPNsense-Philosophie IMHO so aussehen:
ALLOW -in LAN -out !IPv6_Prefix -proto IPv6
Also erlaube sämtlichen IPv6-Traffic, der nicht wieder zum eigenen Prefix (und damit potentiell in andere lokale Subnetze) geht. Dazu müsste ich aber den aktuellen v6-Prefix referenzieren können.
Eine -out wan mit prefix sieht so aus:
pfctl: DIOCGETRULES: Invalid argument
pass in quick on em0 inet6 from any to (nfe0:network) flags S/SA keep state label "USER_RULE: testrule"
root@drexbox:~ #Ansicht in der GUI ist dann:
"IPv6 * * * WAN Netzwerk * * testrule "
Dann geht der Traffic aber nicht ins Internet, sondern nur in das Netzwerk, was direkt am WAN-Interface anliegt (also das Provider-Netz). Bringt also leider auch nix.
eine selbst gefrickelte
pass in quick on em0 inet6 from any to nfe0 flags S/SA keep state"
... also ohne das network... via shell Befehl oder script würde vermutlich auch gehen, auch wenn die GUI das nicht anbietet.
Das ist die einzige sinnvolle Möglichkeit. Wie du sagtest bietet das die UI aber nicht an und selber wollte ich hier eigentlich keine Regeln dazuscripten.
Bleibt also die Erkenntnis, dass IPv6 mit OPNsense in dieser Konstellation so noch nicht vorgesehen ist. Zwei (jeweils unschöne) Workarounds wären also:
- Auf der Shell: Selbst gefrickelte Regel ("sicherer" bzw. robuster, allerdings mit Scripterei verbunden -> unschön und kann bei Updates kaputt gehen)
- Alternativ in der UI: Erst selektiv IPv6-Traffic in alle Netze verbieten (bei mir 5 DENY-Regeln je Interface) und danach dann ein IPv6 ALLOW any. (Das ist die klickbare Variante, die ich aber für sehr fragil halte -> ebenfalls unschön)
Eine saubere Lösung wäre also zumindest eins der folgenden beiden Features offiziell in OPNsense bereitzustellen:
- Möglichkeit zur Referenzierung des aktuellen IPv6-Prefix (für DynPrefix-Opfer wie mich)
- Als Destination direkt ein Interface angeben (das ist eigentlich generell praktisch)
Liest hier evtl. auch ein Entwickler mit, der dazu was sagen könnte? Ansonsten kann ich auch mal einen Feature-Request aufmachen.
-
hm.. ich bin für Feature-Request.
Allerdings ist BSD/pf für mich recht neu... bin halt iptables-geschädigt. :o
-
Zur Info:
- Feature-Request bzgl. Regeln für dynamisches IPv6 Prefix (war schon da): https://github.com/opnsense/core/issues/2544
- Feature-Request für Interface in Regeln: https://github.com/opnsense/core/issues/3380
Drückt die Daumen, dass mindestens eins der beiden Features in 19.7 landet ;) Zumindest der Dyn-v6-Prefix-Support steht schon als Milestone drin, das klingt ja vielversprechend. Dann könnten endlich großflächig OPNsense IPv6-Deployments erfolgen.
- direx
-
@rolfd: Das mit dem Interface in der Regel geht wohl auch nicht. Das Interface in der Regel wird in die Interface-IP-Adresse aufgelöst.
Man hat also derzeit wirklich keine Chance auf eine sinnvolle Lösung. Drückt weiter die Daumen für bessere IPv6-Unterstützung in 19.7 ;)