Messages

Looks like one command just boots instantly (and can take options or specific kernels) while the other boots the current kernel after some delay.  Shouldn't make any practical difference for this, I think, since you're just setting some variables.

https://docs.freebsd.org/en/books/handbook/boot/

(Intel microcode issue aside...)

The "gotcha" is that OPNsense installers are only released twice yearly.  There was 25.1 and I think the next installer image will be 25.7.  So at time of writing there is no 25.x installer image that has this mitigated.

If you have an affected device and you are installing OPNsense freshly from the 25.1 image, then you need to "prime" the installer with the tunables so you don't get stuck.  You can do this from the FreeBSD boot menu by pressing '3' ("Escape to loader prompt").  From there you can enter tunables with the 'set' command, followed by 'boot'.  Example:

Code Select Expand

set hint.uart.0.at="isa"
boot

Once installed, you can then update OPNsense to the latest release.  Alternatively, you can persist the tunable(s) by adding them in System->Settings->Tunables if you will not be updating to at least 25.1.6 for whatever reason.

Apologies for the generic boot screenshot: this is from a vanilla FreeBSD VM.  I don't have the OPNsense installer handy at the moment, but the boot loader screen is the same/similar except for the logos.

I don't know what specific tunables might be needed for other devices (there are older threads you can search for) but at least for Protectli V1410 (N5105) and the older VP2410 (J4125) I only needed this one tunable to get them working at the time.

Nice!  Serial console is working again here after deleting the tunable.

Bonus: I'm able to authenticate again in PuTTY by copy/pasting my login password.  That had stopped working with the tunable and I was having to manually type the password in.  No clue why that makes a difference in PuTTY but it was irritating :)

Hmm, I thought FQDN would resolve all of the IPs but it looks like it doesn't pick up IPv6 auto-generated addresses, at least in my current setup with Kea+Unbound.

MAC aliases seem reliable, though.

If I want to change a device's IP address, I should not have to update all of its firewall rules or alias assignments manually.

You don't need to use IP addresses in firewall aliases.  You can also use FQDN in the "Host" alias type, or the MAC address in the "MAC" alias type.  Either of those will track the current IP address(es) of the client, including any auto-configured IPs such as from IPv6 SLAAC (in my experience, at least).  I think there may just be a short delay between IP changes for the alias to update, but I'm not sure how long.  I haven't noticed an issue in practice.

EDIT: I found a setting in Firewall->Settings->Advanced that seems to control the update interval.  Default is 300s.

You cannot view this attachment.

It also affects some current production Protectli units which are running coreboot.  I was told by a rep that they are working with their coreboot vendor on a fix but in the meantime "hint.uart.0.at=isa" is needed in system tunables.

I observed for several days without making significant changes in OPNsense and I can confirm that when the network is undisturbed there is no issue; the temporary IPs are generating once daily as expected in both Windows and Debian, at least for a time.  Inevitably something happens to break them, because...

...I also learned that what qualifies as a 'disturbance' has been expanded to include not only radvd service shutdown or restarts due to configuration changes or router reboots, but also WAN DHCP renew / rebind events as per https://github.com/opnsense/core/issues/6522.  There's a similarly themed upstream thread at https://github.com/radvd-project/radvd/issues/85. 

In my case the IPv6 prefix rarely changes, but my ISP likes to reboot my modem at least weekly.  It happened once while I was capturing and I noticed that when the modem came back online there was indeed a prefix deprecation RA in Wireshark.  So this a bug; actually a non-stater for anyone using privacy extensions** with radvd because, based on my understanding of the linked GitHub issues, the DeprecatePrefix=on setting is required by OPNsense for reliable prefix propagation.  It was explicitly coded to restart radvd and send this RA message on DHCP events since OPNsense 23.1.9.

It would seem then that disabling the setting is also not an option, for the sake of IPv6 functioning in OPNsense.

So this leaves me with two questions:

1) How is this handled by OPNsense when Dnsmasq is used for RAs instead of radvd?  Is there a similar RA type as the radvd one that deprecates the current prefix?  If not, then is the original issue in https://github.com/opnsense/core/issues/6522 again present under Dnsmasq?

2) What current viable option do OPNsense users have for IPv6 privacy extensions?



** unless the client network link is re-established often, which masks the issue, or prefixes change frequently.

Sorry, I don't know why I thought you were asking about setting up Quad9. I misread that you are already using Cloudflare.

split-brain DNS

Ah, you are asking about split-horizon DNS.  Not in my current skillset so I'll back out here.

To forward to Quad9 via DoT in Unbound just add an entry for each upstream IP you want to forward to in the "DNS over TLS" tab.  Keep the value "dns.quad9.net" constant for the "Verify CN" field.  You can confirm it's working with this link: https://on.quad9.net/

Unless you take additional active measures to restrict DNS on your network, clients are free to ignore your Unbound instance.  There's nothing preventing web browsers and IoT devices, for example, from using whatever DoT or DoH provider they want.

You can easily redirect plain DNS requests to your Unbound instance via port forwarding, and you can simply block DoT/DoQ requests that don't originate from Unbound by filtering TCP & UDP on ports 853 and 8853.  There are some edge cases to consider as well since DNS providers may use alternate custom ports like 9953 (Quad9).

You cannot easily cope with DoH though, at least not with a simple firewall setup.  The closest solution I've found for that so far is to use IP lists for public DNS providers and block any HTTPS requests to those IPs, but this is a blunt tool.  It tends to break CDNs because many DNS lists also include CDN IPs, or they use shared IP blocks with DNS services.  I've broken GitHub and Cloudflare sites this way, so am too still looking for a better solution short of proxying HTTPS traffic and engaging in man-in-the-middle antics.

Yes, you can individually configure network clients (via OS settings) or applications to force your DNS service.  I think this gets a little messy though and you can never rest trusting that nothing on the device won't go around your settings.

In that context, it would be interesting to check on other OSes

This was affecting my linux clients as well (one Raspberry Pi OS - wired, one Debian 12 - WiFi), so I will test the theory there also.  I think my discussion with ChatGPT was focused only on Windows due to the prompts, so it was giving client-specific advice, but this is probably a wider issue due to the RFC.

If I can successfully reproduce I may raise an issue with RADVD to at least get their thoughts on it, although they might also just recommend to disable it.

Just posting the 24-hour result since the RA with PreferredLifetime=0 was received.

The temporaries remained active for the duration of their valid lifetime and then became deprecated.  No new ones were generated.

Code Select Expand

Addr Type  DAD State   Valid Life Pref. Life Address
---------  ----------- ---------- ---------- ------------------------
Public     Preferred     23h58m3s    3h58m3s 2601:<redacted>:f69
Temporary  Deprecated    23h58m3s         0s 2601:<redacted>:a322
Public     Preferred     23h58m3s    3h58m3s fdf8:<redacted>:3a21
Temporary  Deprecated    23h58m3s         0s fdf8:<redacted>:a322
Other      Preferred     infinite   infinite fe80::<redacted>

The theory is holding up so far.  The next part of the test should confirm it.

Using a default allow rule with a "!RFC1918" condition has some limitations, most obviously with dynamic IPv6 as described.  With such a rule you may need to also then place explicit allow rules before it for access to DNS and other network services (except DHCP which is handled automatically by OPNsense) because those are in many cases in the RFC1918 range.

There's a way to do it differently which I found works for IPv6 inter-VLAN filtering as well:

You can continue to use a default allow rule with a "!" condition, but instead of RFC1918 ranges you would use an alias containing the network(s) you want to block access to.  These can be CIDR IP blocks.  Alternatively you can use explicit block rules for OPNsense interfaces (e.g. LAN net, IOT net, etc.)

You cannot view this attachment.

or

You cannot view this attachment.

This approach may be a little too wide open for you, depending on your concerns.  It's also difficult to manage for large numbers of interfaces or if you are frequently adding/removing interfaces. 

For a simple home network with just a few VLANs, this can work well IMO.

No need to apologize; the topic is essentially about AT&T.

https://www.reddit.com/r/opnsense/comments/17mw7ys/att_ipv6_and_multilan_oh_my/
https://github.com/lilchancep/att-pfsense-ipv6
https://forum.netgate.com/topic/153288/multiple-ipv6-prefix-delegation-over-at-t-residential-gateway-for-pfsense-2-4-5/11
https://www.perplexity.ai/search/cedf07dc-1fe2-44e3-b896-b61a13122db1 (Aggregated a ton of articles/posts)

Thanks- this was enlightening.

So apparently AT&T responds to a request for a /60 but they don't actually delegate the full range.  They only hand out 8 prefixes, requiring users to manually override DHCP settings with custom config files.

(It seems that also AT&T gateways can't be put into bridge mode, leading users to bypass them with special SFP modules that emulate an ONT)

This sounds like a difficult ISP to deal with :-/

I don't understand what the issue with regard to the AT&T prefix delegation is after reading this thread and the one you linked in your OP.  What do you mean by this?

The problem isn't that they delegate a /60 prefix, but rather the fragile and unorthodox way they expect their gateway to request it

Thanks, and sorry to divert the topic.  It just want to be sure I understand because AT&T is one of the ISPs I would consider moving to eventually.

My current ISP also delegates a /60 though I don't see any issue.

Minor update:

I reproduced the RA with PreferredLifetime=0 on a config change, but specific to the RA system.  I made a small adjustment to include the VLAN-specific internal domain in the DNS search list and then when I clicked 'Save' it sent the problematic RA first before finally sending the updated RA.

You cannot view this attachment.

Code Select Expand

Frame 630998: 198 bytes on wire (1584 bits), 198 bytes captured (1584 bits) on interface \Device\NPF_{42A788CA-BA2E-4C03-8301-C6DB59536A38}, id 0
Ethernet II, Src: Protectli_f:xx:xx (<redacted>), Dst: IPv6mcast_01 (33:33:00:00:00:01)
Internet Protocol Version 6, Src: fe80::<redacted>, Dst: ff02::1
Internet Control Message Protocol v6
    Type: Router Advertisement (134)
    Code: 0
    Checksum: 0x5c90 [correct]
    [Checksum Status: Good]
    Cur hop limit: 64
    Flags: 0x00, Prf (Default Router Preference): Medium
    Router lifetime (s): 0
    Reachable time (ms): 0
    Retrans timer (ms): 0
    ICMPv6 Option (Prefix information : 2601:<redacted>::/64)
        Type: Prefix information (3)
        Length: 4 (32 bytes)
        Prefix Length: 64
        Flag: 0xc0, On-link flag(L), Autonomous address-configuration flag(A)
        Valid Lifetime: 7200 (2 hours)
        Preferred Lifetime: 0 (0 seconds)
        Reserved
        Prefix: 2601:45:4000:6db3::
    ICMPv6 Option (Prefix information : fdf8:<redacted>::/64)
        Type: Prefix information (3)
        Length: 4 (32 bytes)
        Prefix Length: 64
        Flag: 0xc0, On-link flag(L), Autonomous address-configuration flag(A)
        Valid Lifetime: 7200 (2 hours)
        Preferred Lifetime: 0 (0 seconds)
        Reserved
        Prefix: fdf8:fb25:3a87:1030::
    ICMPv6 Option (Recursive DNS Server 2601:<redacted>)
        Type: Recursive DNS Server (25)
        Length: 3 (24 bytes)
        Reserved
        Lifetime: RDNSS address MUST no longer be used (0) (0 seconds)
        Recursive DNS Servers: 2601:<redacted>
    ICMPv6 Option (DNS Search List Option h1.home.arpa)
        Type: DNS Search List Option (31)
        Length: 3 (24 bytes)
        Reserved
        Lifetime: DNSSL domain name MUST no longer be used (0) (0 seconds)
        Domain Names: h1.home.arpa
        Padding
    ICMPv6 Option (MTU : 1500)
        Type: MTU (5)
        Length: 1 (8 bytes)
        Reserved
        MTU: 1500
    ICMPv6 Option (Source link-layer address : <redacted>)
        Type: Source link-layer address (1)
        Length: 1 (8 bytes)
        Link-layer address: Protectli_f:xx:xx (<redacted>)

(it invalidated not only the active prefixes but also the RDNSS and DNSSL options in this scenario.)

I can do two things:

1. Since my PC was recently rebooted before receiving this RA, I can now check it after 24 hours to confirm that the privacy address will not be generated.  The theory is it will not since the active prefix was invalidated but not actually changed.

2. (Longer term test) I can reset the network connection and set 'AdvDeprecatedPrefix=off', then I can:
- confirm that the PreferredLifetime=0 is no longer being sent
- observe for several days to confirm temporary address generation working correctly