Messages

Funny, it was tortoise at first, but I thought that turtle is a more common term.

Leon would agree, but we know how that ended...

Why not just keep the existing logic of sequentially numbering the IAIDs as the default / automatic behavior (for IA_NA and IA_PD)?
In case of manual configuration, preventing duplicate IAIDs is under the control of the user. What we definitely mustn't have are duplicate IAIDs as the default.

An additional setting for manually specifying the IAID for IA_NA might be nice to have. Or we could just use the same for IA_PD and IA_NA. I currently can't think of a use case where these would have to be distinct, but I'm sure someone will come up with one. :)

And please use the keyword "IAID" in the GUI. It took me embarrassingly long to figure out that this is what's meant by the new setting.

Multiple DUIDs as a workaround for duplicate IAIDs seems overkill to me. But if there is actual demand for multiple DUIDs for special use cases, sure, why not.

Cheers
Maurice

I applied the patch to 26.1.3. Unfortunately, it doesn't work for me. dhcp6c fails to acquire an address (IA_NA) on the secondary WAN, and sometimes fails completely (no address on both WANs and no prefix delegation on WAN 1).

One thing I noticed in packet captures is that the IAID is now set to 0 for both WAN interfaces. That's not supposed to happen, each interface must have a distinct IAID. Not sure whether this is the root cause, but it's plausible because in my case, both WAN interfaces are served by the same upstream DHCPv6 server.

Without the patch, dhcp6c uses a distinct IAID for each interface. Had to roll back the patch. Happy to test again when unique IAIDs are back.

Config WAN 1:

Code Select Expand

<if>vtnet0</if>
<descr>WAN_GPON</descr>
<enable>1</enable>
<lock>1</lock>
<blockpriv>1</blockpriv>
<blockbogons>1</blockbogons>
<mtu>1492</mtu>
<ipaddrv6>dhcp6</ipaddrv6>
<dhcp6-ia-pd-len>8</dhcp6-ia-pd-len>

Config WAN 2:

Code Select Expand

<if>vtnet1</if>
<descr>WAN_LTE</descr>
<enable>1</enable>
<lock>1</lock>
<blockpriv>1</blockpriv>
<blockbogons>1</blockbogons>
<ipaddrv6>dhcp6</ipaddrv6>
<dhcp6-ia-pd-len>none</dhcp6-ia-pd-len>

Cheers
Maurice

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.