Hallo zusammen,
vorab schon mal besten Dank für euren Support!
Ausgangssituation:OPNsense 26.7.1_1-amd64
FreeBSD 15.1-RELEASE-p1
OpenSSL 3.5.7
WAN / Internet
:
: Telekom VDSL
:
.-----+-----.
| Gateway | Vigor 167
'-----+-----'
|
WAN | IP or Protocol
|
.-----+------.
| OPNsense |
'-----+------'
|
LAN ; VLAN10 192.168.10.0 ; VLAN20 192.168.20.0 ; VLAN30 192.168.30.0
|
.-----+------.
| LAN-Switch | OpenWRT
'-----+------'
|
...-----+------... VLAN10 192.168.10.11 (client1)
|
...-----+------... VLAN10 192.168.10.12 (client2)
|
...-----+------... VLAN10 192.168.10.13 (client3)
|
...-----+------... VLAN20 192.168.20.21 (client4)
...
Erstellung und Nutzung von firewall rules ist bekannt. Internetzugriff via VLANs hat funktioniert, Wireguard VPN hat funktioniert. Das setup funktioniert generell sehr gut.
Ich möchte lediglich Sicherheitsbedenken ausräumen:- Jetzt frage ich mich, ob ich kritische Einstellungen gesetzt haben könnte, die mich gegenüber dem "Auslieferungszustand" von OPNsense angreifbar machen? Lieber nochmal alles auf null?
- Oder spielen sich sämtliche "gefährliche" Einstellungen bei Firewall>Rules ab, weil ausschließlich hier zB inbound traffic aufs WAN gesetzt wird?
- Kann man sich mit "falschen" IPv6 configs angreifbar machen – außerhalb Firewall>Rules? Oder müssten hierfür auch immer inbound traffic Regeln auf WAN eingestellt sein?
- Die VLANs sollen untereinander getrennt sein – bis auf Regeln natürlich, etwa dass client4 in VLAN20 nach client1 in VLAN10 ruft.
- Viele empfehlen hierfür einen RFC1918 alias zu erstellen für die privaten IP ranges und den dann mit destination invert zu versehen. Sprich, allow traffic überall hin außer local networks.
- Ist das denn best practice? Oder lieber block rule? Wie kann ich beim selbstgeschriebenen Alias sichergehen, dass ich auch alle IPv6 erwische? IPv4 ist ja recht einfach, aber bei dynamischen IPv6 Adressen (Telekom VDSL consumer Vertrag) müsste ich doch bei jeder neuen IPv6 Adresse den alias neu anpassen, oder nicht?
Meine Ziele:
1) VLANs sollen nicht auf LAN zugreifen dürfen
2) VLANs sollen getrennt voneinander sein (bis auf rules)
3) VLANs sollen Internetzugriff haben
4) Mein setup soll sicher und nicht von außen angreifbar sein
Herzlichen Dank!! Ich weiß euren Support sehr zu schätzen :)
Mit der geringen Info, die Du geliefert hast, sind nur prinzipielle Antworten möglich, nichts konkretes:
1. Natürlich kannst Du das getan haben, das meiste spielt sich allerdings im Firewall-Bereich ab.
2. Jein. Es sind nicht nur WAN-Regeln, sondern z.B. auch NAT.
3. Ja, absolut und ja. Da IPv6 kein NAT benötigt, reicht ein falsches "Allow Any" in den WAN- (oder Floating-) Regeln aus.
4. Ja, sollten sie, sonst brauchst Du ja keine VLANs. Und genau da spielt ggf. auch IPv6 rein, denn jetzt müssen die Pakete eben nicht mehr über das WAN reinkommen.
5. Richtig. Das gilt für die übliche "Allow Any"-Regeln bei IPv4.
6. Ob man das mit einer Regel und invertiertem Ziel oder mit zwei Regeln (eine mit Block RFC1918 und eine mit Allow Any) macht, ist Geschmackssache. Über VLAN-Abschottung auf Ebene IPv6 habe ich noch nicht nachgedacht, denn der Bereich ist zu groß, um ihn zu scannen. Das bedeutet: Das schlimmste, was Dir passieren könnte, ist, dass ein Client in einem VLAN einen anderen in einem anderen VLAN erreichen kann - nur: wie soll er ihn finden?
P.S.: Du kannst in der Ziel-Adresse auch "INTERFACE net" angeben. Und wenn Du alle lokalen Interfaces zu einer Firewall-Gruppe zusammenfasst, gibt es auch "LOCAL_VLANS net". Dann kannst Du als Ziel !LOCAL_VLANS net nutzen für die Allow-Regel. Tatsächlich habe ich das sogar genau so gemacht und zwar sowohl für Version "any", also für IPv4 und IPv6 - ich nutze !RFC1918 gar nicht.
Ob destination invert oder Blockregeln ist reine Geschmackssache.
Wenn du keine eingehenden Allowregeln auf WAN oder Floating hast, bist du so sicher wie im Auslieferzustand oder mit jedem Consumergerät auch.
Gib Gedöns, dem du nicht vertraust, wie IoT-Kram evtl. nur IPv4 in dem entsprechenden VLAN, dann geht das mit dem Blocken in Richtung der anderen VLANs einfacher. Es sei denn, du hast ein statisches IPv6-Prefix.
HTH,
Patrick
Vielen Dank euch beiden für die schnelle Rückmeldung! Sehr detailliert, echt klasse.
Sofern ihr euch die Zeit nehmen und über meine config schauen würdet (tausend Dank im Voraus): wäre es am einfachsten, wenn ich auf Werkseinstellungen zurücksetze, von Werkseinstellungen ausgehend von jeder Änderung einen Screenshot mache und ihn hier poste? Viel wird das nicht sein: Telekom VDSL setup, interfaces, assignments, DNS/DHCP, VLAN-Regeln, ggfs. Wireguard.
Wegen
Quote2. Jein. Es sind nicht nur WAN-Regeln, sondern z.B. auch NAT.
3. Ja, absolut und ja. Da IPv6 kein NAT benötigt, reicht ein falsches "Allow Any" in den WAN- (oder Floating-) Regeln aus.
und
QuoteWenn du keine eingehenden Allowregeln auf WAN oder Floating hast, bist du so sicher wie im Auslieferzustand oder mit jedem Consumergerät auch.
tendiere ich nämlich zu nochmal zurücksetzen. Habe für wireguard natürlich NAT und weitere Einstellungen vorgenommen, mich am neuen DNS probiert etc.
Wahrscheinlich am schnellsten für alle, wenn ich neu beginne und konkret mein delta zum Werkszustand poste.
QuoteMit der geringen Info, die Du geliefert hast, sind nur prinzipielle Antworten möglich, nichts konkretes:
Dann kann ich auch konkreter werden. Euer thumbs up zu meinen Einstellungen würde mir massiv helfen: alleine IPv6 kommt mit so vielen Fallstricken und neuen Konzepten daher.
Vielen Dank im Voraus!
QuoteP.S.: Du kannst in der Ziel-Adresse auch "INTERFACE net" angeben. Und wenn Du alle lokalen Interfaces zu einer Firewall-Gruppe zusammenfasst, gibt es auch "LOCAL_VLANS net". Dann kannst Du als Ziel !LOCAL_VLANS net nutzen für die Allow-Regel. Tatsächlich habe ich das sogar genau so gemacht und zwar sowohl für Version "any", also für IPv4 und IPv6 - ich nutze !RFC1918 gar nicht.
klasse, das probiere ich mal aus :)
Edit: 2 Fragen zu hardware:
1. Aktuell ist im OPNsense Rechner eine 4x 1 Gb Intel Netzwerkkarte verbaut. Ich gehe über 1x trunk port von OPNsense zu einem OpenWRT router, den ich als switch und access point nutze. Die anderen 3 ports der OPNsense über ne bridge, LAGG oder so zu verbinden, fand ich zu fummelig.
OpenWRT habe ich als switch eingestellt (kein DHCP etc.). Ich gehe davon aus, dass sämtlicher traffic einmal durch die OPNsense muss. Daher müsste eine Netzwerkkarte mit 2x 10 Gbit (zB Intel X550-T2) durchaus helfen, oder?
2. Welche managed switches sind zu empfehlen? Ich bin Fan von OpenWRT und würde am liebsten einen großen switch flashen. Jedoch ist das Angebot an einfach flashbaren switches nicht groß. Falls ich mich mal auf nicht-OpenWRT fähige hardware einlasse: was empfehlt ihr so ab 24 ports fürs 19" rack?
So, ich habe nochmal meine Einstellungen auf Werkseinstellungen zurückgesetzt und neu begonnen.
Zunächst mal bis hier hin meine Basiskonfiguration. Internet auf LAN funktioniert. Das sollte für Telekom VDSL so passen - ansonsten lasst es mich bitte wissen.
QuoteEinstellungen nach Anleitung "IPv6 for generic DSL dialup" https://docs.opnsense.org/manual/how-tos/ipv6_dsl.html
- System > General > System: Domain = home.arpa
- Interfaces > LAN > Static IPv4 address = 192.168.1.2/24
- Interfaces > WAN > Generic configuration: IPv6 Configuration Type = DHCPv6
- Interfaces > WAN > DHCPv6 client configuration: Request prefix only = check
- Interfaces > WAN > DHCPv6 client configuration: Send prefix hint = check
- Interfaces > WAN > DHCPv6 client configuration: Prefix delegation size = 56
- Interfaces > LAN > Generic configuration: IPv4 Configuration Type = Static IPv4
- Interfaces > LAN > Generic configuration: IPv6 Configuration Type = Track interface (legacy)
- Interfaces > LAN > DHCPv6 client configuration: Request prefix only = check
- Interfaces > LAN > Track IPv6 Interface: Parent interface = WAN
- Interfaces > LAN > Track IPv6 Interface: Assign prefix ID = 0
Einstellungen nach Anleitung "PPPoE ISP Setup" https://docs.opnsense.org/manual/how-tos/pppoe_isp_setup.html
Interfaces > WAN > Generic configuration: IPv4 Configuration Type = DHCP- Interfaces > WAN > Generic configuration: IPv4 Configuration Type = None
Interfaces > WAN > Generic configuration: IPv6 Configuration Type = DHCPv6- Interfaces > WAN > Generic configuration: IPv6 Configuration Type = None
- Interfaces > Devices > VLAN > add:
- Device = vlan0.1.7
- Parent = igb0 (ab:12:...) [WAN]
- VLAN tag = 7
- Description = vlan0.1.7
- Interfaces > Devices > Point-to-Point > add:
- Link Type = PPPoE
- Link interface(s) = vlan0.1.7
- Description = igb0_vlan_PPPoE
- Username = abc
- Password = 123
- Interfaces > Assignments: assign Device = pppoe0 (vlan0.1.7)-igb0...
- Interfaces > igb0_vlan7_PPPoE: Enable = check
- Interfaces > igb0_vlan7_PPPoE: IPv4 Configuration Type = PPPoE
Ansonsten noch kleinere settings wie beep, theme, ...
Zu
- Interfaces > WAN > Generic configuration: IPv4 Configuration Type =
DHCP None - Interfaces > WAN > Generic configuration: IPv6 Configuration Type =
DHCPv6 None
In letzterer Anleitung "PPPoE ISP Setup" (https://docs.opnsense.org/manual/how-tos/pppoe_isp_setup.html) sollte man sowohl IPv4 als auch IPv6 config type als None setzen - entgegen der ersten Anleitung "IPv6 for generic DSL dialup" (https://docs.opnsense.org/manual/how-tos/ipv6_dsl.html).
Passt das so?
Die Tage mache ich mich ans Eingemachte wie Firewall, DNS, DHCP etc. und poste dann nochmal ein update. Besten Dank euch schon mal!
Die Verantwortung für deine Konfiguration liegt bei dir. Du wirst hier keine "semi-offizielle" Abnahme bekommen. Nicht in einem Community-Forum und kostenlos. Ich mache sowas gerne gewerblich über meine Firma.
Just saying.
Quote from: name89214 on August 09, 2026, 10:15:48 PM- Interfaces > LAN > Static IPv4 address = 192.168.1.2/24
Also ich finde subjektiv ja, wer dem Gateway/Router nicht .1 oder .254 gibt, der hat psychotische Tendenzen :P aber das kann ja jeder halten wie er mag. Ich find sowas unsauber und intransparent beim Debuggen.
Wie du dein VDSL/PPPoE herstellst, das hängt vom Anbieter und nicht von irgendeinem Howto ab. Auch Telekom macht stellenweise schon Setups ohne VLAN7 (weil VLAN6/Multicast stirbt und wegfällt). Also kann sein dass es bei dir so passt.
Ob man mit dem dynamischen IPv6 Kram glücklich wird, hängt wahrscheinlich eher von den Disconnect-Timeouts ab, also wann es ne Trennung gibt. TDSL sollte ja theoretisch nur noch so grob alle 3-6 Monate eine machen - da kann das dann gut funktionieren. Wie oft sie das v6 Prefix ändern, weiß ich nicht, da gibt es auch Anbieter, die da Hardcore alle 24h nen neuen Prefix announcen und dann macht v6 wenig Spaß :/
Cheers
Quote from: JeGr on August 11, 2026, 05:47:55 PMOb man mit dem dynamischen IPv6 Kram glücklich wird, hängt wahrscheinlich eher von den Disconnect-Timeouts ab, also wann es ne Trennung gibt. TDSL sollte ja theoretisch nur noch so grob alle 3-6 Monate eine machen - da kann das dann gut funktionieren. Wie oft sie das v6 Prefix ändern, weiß ich nicht, da gibt es auch Anbieter, die da Hardcore alle 24h nen neuen Prefix announcen und dann macht v6 wenig Spaß :/
Naja, das kann man ja über DDNS übergehen, das läuft ja selbst für Lite-Anschlüsse mitlerweile brauchbar.
Ist doch für die Finger auch angnehmer DNS zu nutzen als eine v6-Adresse ;)
Quote from: trixter on August 21, 2026, 09:07:45 AMNaja, das kann man ja über DDNS übergehen, das läuft ja selbst für Lite-Anschlüsse mitlerweile brauchbar.
Wenn du bei IPv6 mit DDNS anfängst, kannst dus auch gleich sein lassen. Der effektive Sinn des Ganzen war gerade das NAT-Gemurkse und Co NICHT mehr zu brauchen.
Zudem hilft dir DDNS rein gar nichts, wenn sich dein Prefix ständig ändert (bei jeder Neueinwahl als mit Glück alle 24h...) und du dann Geräte hast, die entsprechend lange brauchen ein neues Prefix, das announced wurde auch zu übernehmen. Heißt das ist nicht mehr nur mal so kurz 15s bei der Neueinwahl wie bei IPv4, sondern kann sich im Dümmsten Fall auch mal ne Stunde hin ziehen, bis alle Geräte mal ihren Hintern hoch bekommen haben und die IP durchrotieren. Und das ist ausgehend, da reden wir noch nicht von Erreichbarkeit von außen zwecks DDNS und Co.
Das ist einfach eine scheiß Seuche, Prefixe zu rotieren und das auch noch im dümmsten Fall alle 24h. Das läuft inzwischen schlicht unter "defekt" bei uns weil du nichts ordentlich damit anfangen kannst. Und da hilft dir weder irgendein DNS/DDNS noch sonstwas dagegen. Leider.
Cheers
Dynamische Präfixe sind natürlich Murks. Es kommt aber drauf an, wie der ISP es implementiert. Ich hatte mal einen ISP, der das neue Präfix zugewiesen hat und gleichzeitig das Routing des Alten gestoppt hat. Das ist richtig Gaga. Irgendwann haben die umgestellt und das alte Präfix noch bis zum Ablauf seiner Gültigkeit weitergeroutet. Dann hat man die Umstellung gar nicht mehr bemerkt. Man muss natürlich aufpassen, dass DDNS immer nur Adressen mit dem neuesten Präfix bekannt macht.