Messages

Thanks for the fixes, Franco. ISC DHCPv6 menu is indeed back in RC2.

Cheers
Maurice

Hm... The current situation is: LAN interface is set to "Track Interface" with "Allow manual adjustment of DHCPv6 and Router Advertisements" enabled. ISC DHCPv6 is enabled and manually configured.

When I switch the interface to "Identity association", it vanishes from the ISC DHCPv6 menu. Entering the URL directly (/services_dhcpv6.php?if=lan) doesn't work either. But according to System: Diagnostics: Services, ISC DHCPv6 is still running.

Cheers
Maurice

Identity Association and ISC DHCPv6 are mutually exclusive, correct? ISC depends on Track Interface (legacy)?

(I'm stuck with ISC since neither Dnsmasq nor Kea support prefix delegation with dynamic prefixes.)

Cheers
Maurice

@franco That would be weird, since the automatic blackhole route and the static routes have different prefix lengths. Adding a /48 blackhole route should not remove existing routes for /60 subnets. But this should be easy to test by creating static routes for prefixes which aren't subnets of the delegated prefix.

@matt335672, what's your WAN configuration, static or DHCPv6?

And I reconsidered what I said about having observed this before. What I have indeed observed is some static routes sometimes not getting added to the routing table after a reboot. But I think these were static IPv4 routes on ptp interfaces, so probably a different issue.

Cheers
Maurice

Just a quick report that I upgraded from the 25.7.11 development version to 26.1.r1, so far without issues.

Switching back to Community doesn't replace the automatically installed os-isc-dhcp-devel plugin with the non-devel version, but I think that's expected. It's an additional manual step which might be worth mentioning in the upgrade instructions.

I keep hostwatch disabled for the time being, so no statement about that.

Cheers
Maurice

Nothing wrong with your configuration, it's most likely a bug. I've seen this behaviour before under hard to reproduce circumstances - some static IPv6 routes sometimes don't get added to the routing table after a reboot. Haven't been able to pinpoint it and mostly worked around it with Monit.

If it's reproducible in your setup, creating an issue on GitHub with as many details as possible (logs) might be the best way forward.

Cheers
Maurice

Haven't looked into the details, but a quick search on GitHub reveals quite a few vtnet related cherry picks from upstream into stable/25.7, like this one: https://github.com/opnsense/src/commit/52cbb08

I've now set hw.vtnet.csum_disable=0 on two OPNsense instances with vtnet interfaces (one amd64, one aarch64).
Will report back with anecdotal observations (remind me if I forget because everything works).

Code Select Expand

options=ec07bb<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,TSO4,TSO6,LRO,VLAN_HWTSO,LINKSTATE,RXCSUM_IPV6,TXCSUM_IPV6,HWSTATS>

No side effects observed in the last 6+ weeks.

Zu beachten ist noch, dass die Interfaces neu zugewiesen werden müssen, falls die neue Hardware einen anderen Ethernet-Treiber verwendet. Das kann man auch schon vorab im Backup der config.xml machen, dann passt es nach dem Import direkt wieder.

Der ACME-Client generiert beim nächsten Renew neue private Keys. Das ist ggfs. zu beachten, falls Du die Zertifikate auch auf anderen Geräten verwendest oder DANE TLSA Records verwendest.

Grüße
Maurice

Thanks a lot for your detailed explanation, apalrd!

I've now used the OPNsense Tayga plugin with 'udp-cksum-mode fwd' for about a week and didn't notice any side effects. Before creating a pull request, it would be great if we could get a few more testers. @bestboy, it would be particularly interesting if this fixes VoWiFi for you.

Code Select Expand

opnsense-patch -c plugins 3be934f
You have to re-apply the Tayga config (Services: Tayga: Apply) or reboot OPNsense after applying the patch. Restarting Tayga isn't sufficient.

Cheers
Maurice

So the file you create with the touch command has the special name that triggers the expansion ?

Correct. The rc script checks whether this file exists. If it does, the partition and file systems modifications are executed and the file is deleted, so this happens only once:

Code Select Expand

GROWFS_MARKER=/.probe.for.growfs
[...]
if [ -f ${GROWFS_MARKER} ]; then
    if [ -n "${ROOT_IS_UFS}" ]; then
        grow_partition ${ROOT_IS_UFS}
        growfs -y "/"
    elif [ -n "${ROOT_IS_ZFS}" ]; then
        zpool list -Hv ${ROOT_IS_ZFS} | while read NAME MORE; do
            if [ "${NAME}" != "${ROOT_IS_ZFS}" ]; then
                grow_partition ${NAME}
                zpool online -e ${ROOT_IS_ZFS} ${NAME}
            fi
        done
    fi
fi
[...]
rm -f ${GROWFS_MARKER}

/.probe.for.growfs exists on nano, vm and arm images so they fill all available disk space on first boot. But you can create this file any time on any OPNsense installation.

Cheers
Maurice

@del13r Good point. If uptime is critical, the manual approach might be worth it.

Cheers
Maurice

As upstream routers for testing, I mostly use OPNsense VMs (radvd, ISC DHCPv6 etc.) as well as MikroTik RouterOS VMs (they have free VM images for testing and offer some features which OPNsense doesn't have, like a PPPoE server).

Cheers
Maurice

OPNsense does the partition and file system adjustments automatically, for both UFS and ZFS. You trigger this by creating a "magic file":

• touch /.probe.for.growfs
• Shutdown OPNsense and expand the disk image (qemu-img resize / Resize-VHD / qm resize / ...)
• There is no step 3. When OPNsense boots, the rc script performs its magic.

Cheers
Maurice

@franco If you need a DHCPv6 server which offers this option for testing, you can simply use OPNsense's ISC DHCPv6 server with a custom config:

Code Select Expand

echo "option dhcp6.aftr-name test.aftr.example.com;" > /usr/local/etc/dhcpd6.opnsense.d/aftr.conf
I've done this before and it works just fine.

Cheers
Maurice