Messages

OPNsense 26.1.3 aarch64 packages and sets released.

AFTR-Adresse bekommst Du z. B. aus dem dhcp6c-Log. Kannst auch einen Packet Capture auf dem WAN-Interface machen und dir die DHCPv6-Pakete direkt anschauen.

GIF-Konfiguration siehe z. B. hier.

Grüße
Maurice

DS-Lite hatte ich mal laufen. Das GIF-Interface muss man manuell konfigurieren, OPNsense verarbeitet den über DHCPv6 zugewiesenen AFTR-Name noch nicht automatisch.

IPv6-only-PPPoE ist soweit ich mich erinnere mittlerweile auch gelöst.

Der Rest ist Standard. VLAN konfigurieren, darauf ein PPPoE-Interface setzen, DHCPv6-Client konfigurieren, LAN-Interfaces bekommen ihr Präfix über Identity Association.

Grüße
Maurice

Gateways are referenced by name in places like static routes and firewall rules. Renaming a gateway could break your configuration.

What you can do: Download a config backup, use search & replace to rename the gateway everywhere, reimport the config.

Cheers
Maurice

Eine FW ist eine FW und sollte das auch bleiben, ohne jeglichen Overhead.

Mit "Overhead" meinst Du Virtualisierung? Sehe ich unproblematisch. OPNsense selbst würde ich nicht als Hypervisor betreiben (machen ja tatsächlich manche mit bhyve), aber OPNsense als Gast unter QEMU/KVM und Hyper-V hat sich bei mir über viele Jahre bewährt.

Even in the current situation (third-party repos can only be added using the console), reports about "OPNsense issues" which turn out to be caused by packages from third-party repos are not uncommon. People report issues they're having with basic stuff like updating OPNsense and don't even mention that they have added a third-party repo (which causes the issue in the first place).

What some users don't seem to realize is that an OPNsense plugin is not some kind of "app". There is no sandboxing, no permission management. A plugin can arbitrarily modify the system and cause issues in other parts of OPNsense. It can even prevent the system from booting.

In my humble opinion, adding a third-party repo is a "not eligible for community support" criteria. It's your system, you can of course do what you want with it, but you really need to be aware of the consequences. If you discover a bug, you need to reproduce it on a system not tainted by a third-party repo before reporting it.
Making it possible to add third-party repos through the GUI would make it even harder to communicate that.

So I'm with Franco here: If adding a third-party repo via the console is too hard for some, that's actually a good thing. It protects them from modifying the system in ways they're not even aware of.

Cheers
Maurice

Für das Heimnetz bin ich persönlich auch ein Freund von Konsolidierung und Virtualisierung. So wenig Hardware wie möglich, nicht zuletzt wegen des Stromverbrauchs.

Mein gesamtes Heimnetz - Switch, GPON-ONT, WLAN-AP, OPNsense, File Server, mehrere RIPE Atlas Probes, LTE-Modem, USV, Freifunk, Smart Home Controller, Hue Bridge, DECT (bestimmt habe ich etwas vergessen) - habe ich mittlerweile auf 32 Watt gedrückt. Und da ist noch Luft nach unten, die nächste Optimierung ist schon geplant. :)

Aber ich stimme Patrick zu, dass man nicht zu viel auf einmal anfangen sollte. Gerade die Konstellation "keine Erfahrung mit OPNsense und keine Erfahrung mit Virtualisierung" sorgt bei vielen schnell für Frust.

Grüße
Maurice

When used in firewall rules, OPNsense itself doesn't expand these _network / _address aliases at all.

Have a look at Firewall: Diagnostics: Statistics: rules. If you selected an _address or _network alias in a firewall rule, it turns into something like vtnet1:2 or vtnet0:network:1 in the resulting pf rules.

Cheers
Maurice

... or if you want to use the additional IPv4 addresses for local services on OPNsense, you can configure additional loopback interfaces with them.
... or if you want to use them for NAT, you can add them to the WAN2 interface using virtual IPs.

So it really depends on your use case.

Cheers
Maurice

@Bode
"Ingressfilter für MAC-Adressen auf den Switches" alleine reichen nicht. An Switch-Ports, an denen kein Telefon angeschlossen ist, darf auch kein VLAN 10-Egress stattfinden. Wie Du das konfigurierst ist herstellerabhängig, da gibt es unterschiedliche Lösungen.

@Cedrik
Korrekt, der Hyper-V vSwitch ist VLAN-aware und macht auch Ingress-Filtering. Bode möchte nach meinem Verständnis aber ganz ohne Client-Konfiguration auskommen, womit das wohl ausscheiden dürfte.

Ich möchte nicht an dem Layer2 Problem herumdoktern.

Du hast eine grundsätzliche Layer 2-Fehlkonfiguration, die es zu beheben gilt. "Herumdoktern" wäre, dies zu ignorieren und stattdessen an anderen Stellen zu basteln.

Habe ewig gesucht woran es liegen könnte.

Die PCs müssen entweder an Access-Ports (nur VLAN 1 untagged) angeschlossen oder so konfiguriert werden, dass sie selbst VLAN-Ingress-Filtering machen. Beides ist bei dir nicht gegeben, weshalb die PCs alle Multi- und Broadcasts aus beiden VLANs verarbeiten. Probleme aller Art sind da garantiert, RAs aus dem falschen VLAN ist nur eines davon.

Ich möchte eine Lösung, womit die PC's ohne Konfiguration in ihr vlan kommen, unabhängig ob ein Telefon davor ist oder nicht, den Telefonen ihr vlan zugewiesen wird und die PC's mobil mit ihrer Netzwerkkarte benutzt werden können.

Konfiguriere die Telefone wie von Cedrik beschrieben, dann sehen die PCs nur VLAN 1 untagged, wenn sie an ein Telefon angeschlossen werden.
Falls Du wirklich die Konstellation hast, dass am selben Switch-Port abwechselnd mal ein PC und mal ein Telefon (+ ggfs. PC am zweiten Telefon-Port) hängt, dann musst Du den Switch in der Tat so konfigurieren, dass er seine Port-Konfiguration dynamisch anpasst (z. B. default Access-Port für VLAN 1 und nur, wenn die MAC-Adresse eines Telefons erkannt wird, zusätzlich VLAN 10 tagged).

An den Link-Local-Adressen von OPNsense herumzubasteln bringt wirklich nichts. Dann empfangen die PCs eben RAs von zwei unterschiedlichen Source-Adressen, aber dadurch ist doch nichts gewonnen. Sie empfangen immer noch RAs aus beiden VLANs. Und es gib sicher auch anderen Multi- / Broadcast-Traffic im VoIP-VLAN, den die PCs abbekommen.

Vielleicht lassen sich die IP-Telefone so konfigurieren, dass sie das VoIP-VLAN nicht an ihren zweiten Port (an dem der PC hängt) durchreichen? Wäre ein naheliegendes Feature, denn genau für deinen Use Case haben diese ja den zweiten Port.

Du solltest jedenfalls nicht versuchen, für ein Layer 2-Problem (nicht sauber getrennte VLANs) einen Workaround auf höheren Layern (z. B. Router Advertisements) zu basteln.

@Patrick Je nach NIC / Treiber / Konfiguration wird das VLAN-Tag ggfs. ignoriert und Windows akzeptiert dann alle Frames. So kommt es zur Vermischung von VLANs. Habe ich auch schon gesehen.

Das hört sich nach einer inkorrekten VLAN-Konfiguration des PCs an. Dort muss die NIC so konfiguriert werden, dass das VoIP-VLAN ignoriert wird.

Das ist ggfs. einfacher, wenn Du auf dem Switch-Port beide VLANs taggst und auf dem PC explizit das gewünschte VLAN (tagged) konfigurierst.

Mit IPv6 und OPNsense hat das alles relativ wenig zu tun - Du hast ein Layer 2-Problem zwischen Switch und Client-PC.

Grüße
Maurice

In the flyer they promise 20m of free (as in unpaid) fiber installation inside the building.

Let me quote myself:

If you want it elsewhere in the house, you can prepare a conduit yourself and they will use it to run up to 20 meters of fiber inside the house (also for free).

You can also find all of this information on their website, it's pretty well documented.

So if I wan't to have multiple VLANs with different assigned prefixes, I need Kea.

No. Dynamically assigning a /64 prefix to an interface is done by dhcp6c (via the Track Interface / Identity Association feature) and unrelated to downstream prefix delegation.

Or basically my current setting can be replaced by switching from track interface to Identity Association and from switching from ICE to Kea?

You can switch to Identity Association, but will then have to manually configure Router Advertisements and DHCPv6.
Kea requires a static prefix, so if you have a dynamic prefix and need stateful DHCPv6, you'll have to switch to Dnsmasq or stick with ISC (which imho is the best option for the time being).

I switched from Track Interface to Identity Association and from ISC DHCPv4 to Kea DHCPv4, but keep using radvd and ISC DHCPv6.