Topics

[not]

Question: if a more specific policy (by source address) matches a query in Unbound, and that query is not blocked by any filter on that policy, does the filtering end there?  Or does it cascade through each of the less specific matching policies until it's either blocked or resolved by the final (i.e. 'default') policy?

I couldn't find the answer in the relevant section of the docs, but it says this:

The algorithm selects the most specific subnet when domains overlap across subnet sizes.

... which I might have interpreted as it stops on the first matched policy, going from most to least specific.

I set up a test like so:

You cannot view this attachment.

(Note: the original 'default' policy is disabled and replaced with the 'clients-all' default policy.)

The idea was that local queries from OPNsense itself (source 127.0.0.1 or ::1) would resolve unimpeded so that firewall Host aliases wouldn't break.  All other traffic, including dynamic IPv6 sources for which I can't statically enter into the policy, would go to the one with the block lists.

The localhost matchers both work fine.  Since requests and replies are both local, ::1 works here (unlike in F/W and DNAT rules).

The "issue" is that localhost queries are still falling through to the 'clients-all' policy and getting filtered, so I think it's designed to cascade but am not certain.

(I know, I can solve this with IPv4-only addressing for DNS and specific policies per IPv4 net.  Just messing around to learn.  I also want localhost requests forwarded externally via DoT through Unbound, same as the others.)

If they are meant to cascade, is there a way to make the policies work like pf 'quick' rules, on first match?  Alternatively, can anyone think of a creative hack to make this scheme work as intended and still support dynamic prefixes? :)

I'm a bit ignorant still on advanced DNS topics.  Please be patient :)

This thread is in response to the discussion on page 1, specifically posts #5-8, here: https://forum.opnsense.org/index.php?topic=50857.0

I didn't want to further derail the IPFire topic so am posting separately to better understand this.

---

I feel that some of the DNS hosts lists that we use in Unbound are not specifically written for it and result in incomplete blocking because Unbound uses exact matching, whereas other engines may treat them as zones and automatically block subdomains.

For reference here are the built-in DNSBLs in OPNsense for Unbound.

It appears the hagezi lists, for example, are wildcarded but many of the others (e.g. AdGuard) are not and those could (depending how they're written) be less reliable in Unbound.

Is that a fair assessment and is there RPZ support in the roadmap for the Unbound UI?  Would that solve this, and is there even a gap or am I off with this assessment?

Thanks.  This has long been one of my nagging unresolved questions.

I'm not sure if this was discussed already (apologies in advance) but In Firewall->Rules [new], are we able to search through the global ruleset?  For example I want to quickly find any 'FireHOL' related rule, but it seems I can't do that.  I need to already know where the rule is (Floating, Group, or Interface name) and have that selected in the left drop down in order for the search to match.

Related to this, is there a way to view the entire ruleset at once?

I'm wondering if there could be an "All" option added to the ruleset selector above Floating?

You cannot view this attachment.

I'd say over the last 1-2 days I'm experiencing a high number of connection issues on the forum.  Server overloaded?

You cannot view this attachment.

You cannot view this attachment.

I've been reviewing older comments (thread below) about Floating & NAT interactions and anticipating to try out the new Firewall->Automation GUI in upcoming 26.1.  Reviewed the documentation as well so I'm clear on the rule processing order between the old and new UIs:

https://forum.opnsense.org/index.php?topic=49053.0
https://docs.opnsense.org/manual/firewall_automation.html

As I understand it, there will mostly be feature parity between Firewall->Automation->Filter and Firewall->Rules in the new release and at some undisclosed future date the old UI will be replaced.  In the linked topic, @Monviech also mentioned that there isn't likely to be a mechanism to clone rules to the new UI.

Question: if I want to migrate my rules to the new UI as an early adopter (and I'm not interested in using APIs), is the recommended approach to just start over with a fresh install?

If it doesn't already exist, can I propose a global option to disable processing on the Automation rules?  That way I can take my time to add new rules there without affecting anything or having negative interactions with the existing rules.  I can raise a GH request if this makes any sense.

Looking forward to trying the Automation GUI :)

Some weeks ago my ISP did some infrastructure upgrades in the area and since then I'm seeing constant IGMP membership queries on WAN to the all-members multicast address (224.0.0.1).  I understand this traffic to be link-local and likely is from the ISP's CMTS for all cable subscribers on the segment.

Should I be allowing these to pass, or is it better to keep dropping?  AFAIK these shouldn't impact our services as we don't subscribe for IPTV.

You cannot view this attachment.

Hello all, I'm wrestling with a first TrueNAS deployment and this issue is beyond my skillset.  Asking here because I think it's relevant to pf/OPNsense and maybe my particular rules causing the issue.

The NAS has two integrated NICs, an Intel I226-V (top) and an Aquantia AQC113 (bottom):

Code Select Expand

truenas_admin@truenas[~]$ ethtool -i enp6s0
driver: igc
version: 6.12.33-production+truenas
firmware-version: 2014:8877
expansion-rom-version:
bus-info: 0000:06:00.0
supports-statistics: yes
supports-test: yes
supports-eeprom-access: yes
supports-register-dump: yes
supports-priv-flags: yes


Code Select Expand

truenas_admin@truenas[~]$ ethtool -i enp3s0
driver: atlantic
version: 6.12.33-production+truenas
firmware-version: 1.3.31
expansion-rom-version:
bus-info: 0000:03:00.0
supports-statistics: yes
supports-test: no
supports-eeprom-access: no
supports-register-dump: no

At first I configured the management interface on enp6s0 with a static IP address, as per TrueNAS guidelines.  This interface has IP 192.168.1.118 on LAN.  It has the default gateway 192.168.1.1, DNS also 192.168.1.1, and the web UI is bound to this IP only.

Up to this point everything is working with a stable connection.  I'm able to access the web UI from a client on VLAN 30 ("CLEAR net") using a Floating rule with direction IN on the CLEAR interface that allows the client to "any" on LAN.

The problem comes when I configure the second interface.  I assign it a static IP 172.21.30.118 which is from the CLEAR subnet as this will be my data interface for SMB shares (the SMB service will bind to it).  I don't assign any additional gateway or DNS, and no static routes.  Just the IP on the interface.  IPv6 auto-config is still disabled in TrueNAS.

After this step, my TrueNAS web UI becomes unstable.  I'm still able to log in, but after some seconds I'm kicked off.  This process repeats itself ad-infinitum and I'm not able to stay in the UI long enough to get work done.  This dialog appears in between when I'm kicked off and the login prompt follows it.

You cannot view this attachment.

If I remove the IP on the second interface, then everything becomes stable again.

Checking the firewall logs while this happens I can see the initial request is allowed as it's matching the Floating rule, and it gets a response.  I don't know why the DNS lookups in between are logged at all as those are within the same subnet (this is a group rule).  Finally another interface group rule is matching instead which is rejecting and causing me to get kicked off.

You cannot view this attachment.

This happens in a loop as mentioned above.  I can see that the source ports changed in between the login and the rejected packets.  This also repeats and is reflected in the state table with new states being generated each cycle.

Also, there is a group 'pass' rule which is supposed to be overriding this 'reject' rule in any case, but that's not happening.

Floating:
You cannot view this attachment.

Group rules (from the CLEAR interface's view):
You cannot view this attachment.

The "PORTS_OUT_LAN" alias already has port 443 included.

Did I set up some kind of asymmetric routing condition when I configured the second NIC?  Is this a TrueNAS quirk? 

I do have Proxmox management on the same LAN network and with a separate VM bridge, but no problems at all there.  That's been stable for a while now.

TrueNAS ip/route info:

Code Select Expand

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host noprefixroute
       valid_lft forever preferred_lft forever
2: enp6s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether 6c:xx:xx:xx:41:0a brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.118/24 brd 192.168.1.255 scope global enp6s0
       valid_lft forever preferred_lft forever
    inet6 fe80::xxxx:xxxx:xxxx:410a/64 scope link proto kernel_ll
       valid_lft forever preferred_lft forever
3: enp3s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether 6c:xx:xx:xx:41:09 brd ff:ff:ff:ff:ff:ff
    inet 172.21.30.118/24 brd 172.21.30.255 scope global enp3s0
       valid_lft forever preferred_lft forever
    inet6 fe80::xxxx:xxxx:xxxx:4109/64 scope link proto kernel_ll
       valid_lft forever preferred_lft forever


Code Select Expand

truenas_admin@truenas[~]$ route  
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         firewall        0.0.0.0         UG    0      0        0 enp6s0
172.21.30.0     0.0.0.0         255.255.255.0   U     0      0        0 enp3s0
192.168.1.0     0.0.0.0         255.255.255.0   U     0      0        0 enp6s0


I don't know exactly when it started, but I think in the last few updates (currently I'm on 25.7.9) I'm seeing that the load on two VPN gateways is not being equally distributed anymore.

I have two Wireguard devices (wg0, wg1) and respective interfaces (WAN_VPN0, WAN_VPN1).  The interfaces are enabled but not configured.  I have a corresponding IPv4 and IPv6 gateway for each interface.

I then created two LB groups: one has the IPv4 members on a common tier, and the other has the IPv6 members on a common tier.  I have a VLAN interface with policy routing to send non-local traffic out the respective IPv4 or IPv6 gateway.  Within the gateway settings, all of them have the default weight (1).  Both gateways are monitored and healthy.

There is a client VM connected to this VLAN. I started a few streams and am seeing that there is a very strong preference for one WG interface.  In the past I would see the traffic more evenly split and both interfaces would show activity.

My expectation is that the client will choose either IPv4 or IPv6 and within the respective gateway group it should balance fairly between the two upstream devices.  Is that a fair assumption or have I misunderstood?  Also, I am curious what the selection criteria is for load balancing- does it distribute by 5-tuple?

Edit: although the screenshot shows "Round Robin with Sticky Address", I wasn't using that previously.  Just changed it for testing.

For those with coreboot firmware, particularly Protectli units that have the optional UEFI, I'm curious if you have control over power management (e.g. ASPM and PowerD/SpeedStep) at the OS level?

The coreboot/Dasharo menu itself doesn't have options for those, so I'm not sure if that means the functions are locked at whatever the manufacturer set them to.  I have disabled PowerD in OPNsense and also set the tunable 'hw.pci.enable_aspm=0,' but this is what I see on reboot:

Code Select Expand

root@firewall:~ # sysctl hw.pci.enable_aspm
hw.pci.enable_aspm: 0


Code Select Expand

root@firewall:~ # pciconf -lcv igc2
igc2@pci0:4:0:0: class=0x020000 rev=0x04 hdr=0x00 vendor=0x8086 device=0x125c subvendor=0x8086 subdevice=0x0000
    vendor     = 'Intel Corporation'
    device     = 'Ethernet Controller I226-V'
    class      = network
    subclass   = ethernet
    cap 01[40] = powerspec 3  supports D0 D3  current D0
    cap 05[50] = MSI supports 1 message, 64 bit, vector masks
    cap 11[70] = MSI-X supports 5 messages, enabled
                 Table in map 0x1c[0x0], PBA in map 0x1c[0x2000]
    cap 10[a0] = PCI-Express 2 endpoint max data 256(512) FLR RO NS
                 max read 512
                 link x1(x1) speed 5.0(5.0) ASPM L1(L1)
    ecap 0001[100] = AER 2 0 fatal 0 non-fatal 0 corrected
    ecap 0003[140] = Serial 1 <redacted>
    ecap 0018[1c0] = LTR 1
    ecap 001f[1f0] = Precision Time Measurement 1
    ecap 001e[1e0] = L1 PM Substates 1


Code Select Expand

root@firewall:~ # sysctl dev.cpu.0
dev.cpu.0.temperature: 34.0C
dev.cpu.0.coretemp.throttle_log: 0
dev.cpu.0.coretemp.tjmax: 105.0C
dev.cpu.0.coretemp.resolution: 1
dev.cpu.0.coretemp.delta: 71
dev.cpu.0.cx_method: C1/mwait/hwc C2/mwait/hwc C3/mwait/hwc
dev.cpu.0.cx_usage_counters: 347858 0 0
dev.cpu.0.cx_usage: 100.00% 0.00% 0.00% last 322us
dev.cpu.0.cx_lowest: C1
dev.cpu.0.cx_supported: C1/1/1 C2/2/127 C3/3/253
dev.cpu.0.freq_levels: 2001/10000 2000/10000 1800/8793 1600/7632 1400/6524 1200/5466 1000/4445 800/3472
dev.cpu.0.freq: 2001
dev.cpu.0.%iommu:
dev.cpu.0.%parent: acpi0
dev.cpu.0.%pnpinfo: _HID=ACPI0007 _UID=0 _CID=none
dev.cpu.0.%location: handle=\_SB_.CP00
dev.cpu.0.%driver: cpu
dev.cpu.0.%desc: ACPI CPU

If I'm interpreting correctly, the settings had no effect and power management is still fully active.  Is that correct/expected?

https://investors.micron.com/news-releases/news-release-details/micron-announces-exit-crucial-consumer-business

It looks like the RAM "shortage" for consumers could be a little more than temporary.  Gamers Nexus on YT just did an interesting piece with their take on this (won't get into it here).

Maybe don't wait to buy that router or RAM kit you've been thinking about... :(

Update from 25.7.8 -> 25.7.9 went without error and I was not prompted for a reboot, but the web UI became unresponsive afterward.  Internet connectivity was not affected.

A reboot command from serial console brought everything back.  Looks stable now :)

I tried the new configuration cleanup tool under System->Configuration->Defaults->Components.  It worked beautifully to remove the stale configs of several plugins that I'd uninstalled.  It even helpfully highlighted which ones were not installed to guide the selection for cleanup :)  Nice touch.

The only minor inconsistency is that the XML element start/end tags sometimes get removed and sometimes don't.  I had limited configs to play with, but it might be the case that when there is no plugin version in the start tag then those get left intact, but the versioned ones get removed.

I'm not sure if this is expected or warrants a bug, but in either case the end result is that the configs are removed and the plugin would revert to its defaults when re-installed (so not really an issue).

Adding a couple diff snippets here to illustrate.

1. The 'bind' plugin did not have a version listed.  The element start tag was <bind> and the end tag was </bind>.  Everything between the tags was removed:

Code Select Expand

6186,6234c6088,6089
<       <record version="1.0.1">
<         <records/>
<       </record>
<       <acl version="1.0.0">
<         <acls/>
<       </acl>
<       <general version="1.0.12">
<         <enabled>0</enabled>
<         <disablev6>0</disablev6>
<         <enablerpz>1</enablerpz>
<         <listenv4>0.0.0.0</listenv4>
<         <listenv6>::</listenv6>
<         <querysource/>
<         <querysourcev6/>
<         <transfersource/>
<         <transfersourcev6/>
<         <port>53530</port>
<         <forwarders/>
<         <filteraaaav4>0</filteraaaav4>
<         <filteraaaav6>0</filteraaaav6>
<         <filteraaaaacl/>
<         <logsize>5</logsize>
<         <general_log_level>info</general_log_level>
<         <maxcachesize>80</maxcachesize>
<         <recursion/>
<         <allowtransfer/>
<         <allowquery/>
<         <dnssecvalidation>no</dnssecvalidation>
<         <hidehostname>0</hidehostname>
<         <hideversion>0</hideversion>
<         <disableprefetch>0</disableprefetch>
<         <enableratelimiting>0</enableratelimiting>
<         <ratelimitcount/>
<         <ratelimitexcept>0.0.0.0,::</ratelimitexcept>
<         <rndcalgo>hmac-sha256</rndcalgo>
<         <rndcsecret>VxtIzJevSQXqnr7h2qerrcwjnZlMWSGGFBndKeNIDfw=</rndcsecret>
<       </general>
<       <domain version="1.1.1">
<         <domains/>
<       </domain>
<       <dnsbl version="1.0.5">
<         <enabled>0</enabled>
<         <type/>
<         <whitelists/>
<         <forcesafegoogle>0</forcesafegoogle>
<         <forcesafeduckduckgo>0</forcesafeduckduckgo>
<         <forcesafeyoutube>0</forcesafeyoutube>
<         <forcestrictbing>0</forcestrictbing>
<       </dnsbl>
---

2. The 'stunnel' plugin had a version in the <start> tag and in that case everything including the tags was removed:

Code Select Expand

6236,6243d6090
<     <Stunnel version="1.0.4" persisted_at="1756512408.00">
<       <general>
<         <enabled>0</enabled>
<         <chroot>0</chroot>
<         <enable_ident_server>0</enable_ident_server>
<       </general>
<       <services/>
<     </Stunnel>

Thanks again for your work on this tool!

I migrated my desktop PC to Linux and also migrated some VirtualBox VMs there.  My goal is to expose two VLANs from OPNsense to the Linux host, on two separate linux bridges, so that the host and guest VMs can attach to either VLAN as needed and also maintain traffic isolation between them (no host routing).  I want OPNsense to handle the inter-VLAN routing and enforce its policies.

The host has a 2.5GbE Intel i226-v NIC that is connected via a trunk switch port configured as native=30(CLEAR) and tagged=20(VPN).  The host is to use 'br0' which carries the untagged traffic.  Guest VMs can attach to either 'br0' (for clear internet) or 'br20' (for VPN gateway).  OPNsense policies allow clients on VLAN 20 to reach local services on VLAN 30.

After some experimentation and failures, the best working setup I came up with is this:

Code Select Expand

$ ip a
...
3: enp10s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq master br0 state UP group default qlen 1000
    link/ether 24:xx:xx:xx:xx:cd brd ff:ff:ff:ff:ff:ff
4: enp10s0.20@enp10s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br20 state UP group default qlen 1000
    link/ether 24:xx:xx:xx:xx:cd brd ff:ff:ff:ff:ff:ff
5: br0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 24:xx:xx:xx:xx:cd brd ff:ff:ff:ff:ff:ff
    inet 172.21.30.100/24 brd 172.21.30.255 scope global dynamic noprefixroute br0
       valid_lft 86118sec preferred_lft 86118sec
    inet6 2601:xx:xxxx:6db3:e7f7:39a6:1d2d:bed4/64 scope global temporary dynamic
       valid_lft 86371sec preferred_lft 85760sec
    inet6 2601:xx:xxxx:6db3:xxxx:xxxx:xxxx:9dca/64 scope global dynamic mngtmpaddr noprefixroute
       valid_lft 86371sec preferred_lft 86371sec
    inet6 fe80::xxxx:xxxx:xxxx:fb89/64 scope link noprefixroute
       valid_lft forever preferred_lft forever
6: br20: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether a2:xx:xx:xx:xx:5a brd ff:ff:ff:ff:ff:ff
7: virbr0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default qlen 1000
    link/ether 52:xx:xx:xx:xx:76 brd ff:ff:ff:ff:ff:ff
    inet 192.168.122.1/24 brd 192.168.122.255 scope global virbr0
       valid_lft forever preferred_lft forever

(virbr0 is created by VirtualBox for its NAT networking- I don't manage it.)

Using NetworkManager / nmcli, I created br0 which has the NIC (enp10s0) as a slave port.  br0 also has IP addresses for the host itself to access VLAN 30.

I then created a VLAN sub-interface (enp10s0.20) to handle tagging on VLAN 20 and made this a slave port on br20.  I left br20 unconfigured because the host doesn't use it and any guest VMs attached to it can configure themselves with DHCP / SLAAC.  This bridge should hopefully make tagging transparent to the VMs and they can just pass untagged frames internally.

I also disabled IP forwarding globally via sysctl config:

Code Select Expand

$ cat /etc/sysctl.d/999-disable-ip-forwarding.conf
net.ipv4.ip_forward = 0
net.ipv6.conf.all.forwarding = 0

... and confirmed that no host route exists for VLAN 20:

Code Select Expand

$ ip r
default via 172.21.30.1 dev br0 proto dhcp src 172.21.30.100 metric 425
172.21.30.0/24 dev br0 proto kernel scope link src 172.21.30.100 metric 425
192.168.122.0/24 dev virbr0 proto kernel scope link src 192.168.122.1 linkdown

$ ip -6 r
2601:xx:xxxx:6db3::/64 dev br0 proto ra metric 425 pref medium
fe80::/64 dev br0 proto kernel metric 1024 pref medium
default via fe80::xxxx:xxxx:xxxx:39a0 dev br0 proto ra metric 425 pref medium

So far so good and everything "works" as expected.  I have a guest VM in VirtualBox that is acting as a NAS on VLAN 30 and another guest VM that is acting as an SMB client on VLAN 20.  The client's internet is going through the VPN gateway and online speedtest results look great- full speed achieved with an 'A' score on the bufferbloat Waveform test.  From OPNsense logs I can see the inter-VLAN routing is taking place when I transfer a file from NAS->client:

You cannot view this attachment.

I observe a couple issues, however.

The first is not serious and I can live with it.  It's that the host bridge br0 takes some time after system boot to get its IP address.  When I was using the physical interface directly, DHCP would already be done by the time the desktop booted up.  With the bridge it takes an additional half a minute after logging on to get the IPs configured.  I expect SLAAC to have some delay because of RA intervals, but DHCP delay seems odd.

The second issue is that I am seeing high retransmit counts and small TCP congestion windows in iperf3 between the two VMs.  They are sharing a physical link up to the switch, but it should be full-duplex.  This is the iperf3 result from client to server VM:

Code Select Expand

$ iperf3 -c 172.21.30.108
Connecting to host 172.21.30.108, port 5201
[  5] local 172.21.20.130 port 40986 connected to 172.21.30.108 port 5201
[ ID] Interval           Transfer     Bitrate         Retr  Cwnd
[  5]   0.00-1.00   sec   199 MBytes  1.67 Gbits/sec  436    277 KBytes       
[  5]   1.00-2.00   sec   211 MBytes  1.77 Gbits/sec   74    339 KBytes       
[  5]   2.00-3.00   sec   252 MBytes  2.12 Gbits/sec  174    349 KBytes       
[  5]   3.00-4.00   sec   236 MBytes  1.98 Gbits/sec  116    419 KBytes       
[  5]   4.00-5.00   sec   218 MBytes  1.82 Gbits/sec  131    290 KBytes       
[  5]   5.00-6.00   sec   206 MBytes  1.73 Gbits/sec   56    363 KBytes       
[  5]   6.00-7.00   sec   230 MBytes  1.93 Gbits/sec  161    356 KBytes       
[  5]   7.00-8.00   sec   199 MBytes  1.67 Gbits/sec   70    370 KBytes       
[  5]   8.00-9.00   sec   199 MBytes  1.67 Gbits/sec   51    358 KBytes       
[  5]   9.00-10.00  sec   188 MBytes  1.57 Gbits/sec   99    338 KBytes       
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bitrate         Retr
[  5]   0.00-10.00  sec  2.09 GBytes  1.79 Gbits/sec  1368             sender
[  5]   0.00-10.00  sec  2.08 GBytes  1.79 Gbits/sec                  receiver

It's a similar story in the opposite direction.

I can accept this for my needs, but I am curious what's causing it and if I misconfigured something.  I suspect fragmentation, maybe due to the VLAN tag overhead (?) but I'm not sure how to confirm.  All interfaces are using 1500 MTU as confirmed in linux.

My second question is regarding the architecture itself: is there anything that I overlooked which might come back to bite me?  Did I open myself to VPN leaks from the br20 clients?

TIA!

My interfaces are set to WAN tracking for IPv6 which works fine with Dnsmasq using the 'ra-stateless' mode.  Clients get the dynamic /64 prefix in the RA and auto-configure their GUAs with SLAAC.

I want to additionally configure ULA ranges with DHCPv6 for internal networking and firewalling purposes.  The desire is that hosts with ULA addresses should communicate that way and only use their GUAs for internet, if this is possible.

The first thing I did was to add ULA virtual IPs (Interfaces->Virtual IPs) for each interface.  For example, on the LAN interface I added an IP alias like fd00:db8:1001::1/64.

The problem now is that Dnsmasq is picking up the ULA prefix on the interface in addition to the GUA dynamic prefix and advertising both in the RAs.  Therefore hosts are auto-configuring IPs in both ULA and GUA subnets, including privacy addresses for each.

Is there a way to prevent Dnsmasq from including the ULA prefix in the stateless RA?  I would like to manually specify a DHCPv6 range for those like fd00:db8:1001::1000 - fd00:db8:1001::ffff and for them to be excluded from host auto-configuration and privacy extensions.  Ideally, I'd like to specify the ranges as partial IPs in Dnsmasq like ::1000 - ::ffff using the interface Constructor, so that Dnsmasq will auto-register hosts in DNS.

I tried to set the 'slaac' mode in addition to the 'ra-stateless' mode as suggested in the OPNsense docs but I can't get the desired result.

I'd like to keep "pure" VLAN interfaces with the parent interface (e.g. igc2) disabled and unassigned, as it's my understanding that that is best practice for tags-only interfaces where there should not be untagged traffic.  It also prevents potential routing issues if a parent gets an IP for some reason.

I'd also like to change the MAC on all internal parent interfaces as a security measure against applications leaking firewall OUI / manufacturer info to the outside.

Unless I'm mistaken this is currently not possible, because parent interfaces must be assigned in Interfaces->Assignments and Enabled in order to set a MAC address.  The only way around it is to set a per-VLAN (child interface) MAC and then must use promiscuous mode.

I tried setting the MAC and then disabling the parent, but the MAC change did not persist for the VLAN interfaces in that case.

Does this support already exist?  Could it become a feature, if I were to raise a GitHub issue tracker?

My DDNS subdomains on DuckDNS have been failing to resolve for the last 1-2 weeks, only very occasionally succeeding.  In most instances I get SERVFAIL in DNS logs.  Their service dashboard loads sometimes but has also been flaky (failed to resolve when I tried earlier), though it provides no useful information about service health.

https://dnschecker.org/ shows propagation issues- most regions show red "x" marks.

Anyone know what's going on with them?

I came across this mailing list thread while searching online about FreeBSD instabilities with N100, as many have been reporting upgrade issues.  I'm not sure if this is related to the problematic microcode updates.

https://lists.freebsd.org/archives/freebsd-current/2025-January/006984.html

ChatGPT (for what it's worth) describes the issues like this:

2. PCID / Cache Corruption Bug

    The N100 has a known CPU erratum: INVLPG instruction with PCID enabled fails to flush TLB entries, causing data corruption on UFS file systems (sometimes panics or inode mangling) [ref]

    The workaround: add

    vm.pmap.pcid_enabled=0 

    to loader.conf, ideally tested in production. Users report stability regained after disabling PCID [ref]

3. UFS Filesystem Instability

    Severe issues such as inode corruption, filesystem panics, or UFS failure have been seen repeatedly when PCID remains enabled and UFS is used [ref]

    ZFS appears to avoid these issues entirely.

⚠️ Why Might You Want to Disable It?

Some CPUs (including Intel N100/Alder Lake-N) exhibit hardware bugs when PCID is used. Specifically:

    A known CPU erratum causes INVLPG (used to invalidate specific TLB entries) to fail when PCID is active.

    This can result in stale or corrupted memory mappings, leading to:

        Filesystem corruption (especially UFS)

        Kernel panics

        Data loss

        Subtle stability problems

Disabling PCID (vm.pmap.pcid_enabled=0) avoids using the broken logic path.
🧪 Who Should Set It?

If you're using:

    Intel N100 or other Alder Lake-N CPUs

    UFS as a filesystem

    FreeBSD 13.x or 14.x

👉 You should absolutely set vm.pmap.pcid_enabled=0 to ensure stability.

Seemed a little concerning and I thought I'd bring it up here for more technical insight.

I'm not affected personally as I don't have an N100 at this time.

Using the 25.7 installer on a test VM, I used console option 2 to set the LAN interface IP and a custom DHCP range of 192.168.160.100 - 192.168.160.199.  I then launched the installer and installed to disk.  This was a fresh install over an existing one (ZFS pool overwrite, no config import).

After logging in to the GUI and completing the initial setup wizard, Dnsmasq was enabled but the DHCP range was set to 192.168.160.41 - 192.168.160.245.

(No argument from me that .41-.245 is not a better default since in Dnsmasq the static reservations should be within the pool range, unlike in ISC.)

Just reporting it for consideration in the 26.1 installers :)  Maybe someone else can also verify if they saw this since I was kind of in a hurry.

[Specs:]

I don't know if this issue affects more units than just mine, or if this is maybe on my end (defective PC motherboard?), but I wanted to document the recovery steps.  I did forward my observations to Protectli as well.

Specs:
Vault V1410 (Intel N5105, 8GB) with Protectli coreboot version 0.9.3.  The coreboot detail is important because there's no option to set the RTC that I'm aware of, so will need to be done through the OS.

I don't know if this affects units with the stock AMI UEFI.

The issue:
Following an extended power loss event where the Vault remains disconnected from mains power or battery backup for some time (>1hr in my case), the USB COM port becomes inoperable and fails to list in Windows Device Manager or in the Linux /dev filesystem.  The firewall remains accessible only via GUI and SSH. The issue persists across power cycles.

(EDIT: I haven't tried the vga console as mine runs headless.)

Evidence:
You can observe that the device is not being recognized on your PC that is connected with the USB COM cable.  For example, in Linux 'dmesg' output there will not be any reference to the expected device (/dev/ttyUSB0) that is typically there.  Also there will be no such character device on the /dev on the filesystem:

Code Select Expand

$ sudo dmesg | grep tty
[    0.152646] printk: legacy console [tty0] enabled
[    0.791432] serial8250: ttyS0 at I/O 0x3f8 (irq = 4, base_baud = 115200) is a 16550A


Code Select Expand

$ ls -l /dev/ttyUSB*
ls: cannot access '/dev/ttyUSB*': No such file or directory

On Windows there will be an error indicator in Device Manager.  The COM port will have become an unrecognized device that fails to initialize.

The fix:
1) Open the device and perform a CMOS reset by shorting two pins.  https://kb.protectli.com/kb/cmos-reset/

This will restore the serial port, but will also wipe out the system time.

2) DNS resolution may be blocked due to the time error and the NTP service in OPNsense will be unable to sync.  Manually set the date to the current wall clock time to within 1-2 minutes.  On the OPNsense console (as root):

$ date yymmddhhMM

For example, enter "2507301300" for "Jul 30 2025 at 1pm"

This will get NTP and other services unstuck, but may take a few minutes to sync.

Validation:

Code Select Expand

$ sudo dmesg | grep tty
[    0.152646] printk: legacy console [tty0] enabled
[    0.791432] serial8250: ttyS0 at I/O 0x3f8 (irq = 4, base_baud = 115200) is a 16550A
[ 8856.625541] usb 1-1: FTDI USB Serial Device converter now attached to ttyUSB0     <--- this reappears


Code Select Expand

$ ls -l /dev/ttyUSB*
crw-rw---- 1 root dialout 188, 0 Jul 30 00:37 /dev/ttyUSB0

If on Windows, you should again see the COM0 port in Device Manager.


-----

I did see this issue multiple times already as we have been having more frequent power outages in our region, and also I've seen it on two separate V1410s.  I had gotten a replacement for my original one due to a different issue, but that one exhibited this problem as well. 

On the most recent occurrence I did happen to have a serial terminal session open when the power went out, so it could be a factor.  I don't recall if I was able to close the session cleanly and I don't remember if that was always the case the other times it happened.  If you own this device and depend on the USB COM then maybe consider keeping around a small screwdriver.

The 25.7 release announcement references this change:

o system: allow experimental feature to run web GUI privilege separated as "wwwonly" user

I don't see any option to enable this in the web GUI settings, unless I missed it.  How do we try this?