Messages

JFYI - I noticed some interesting wording in the "Client Device Isolation" help text in UniFi.  It seems the isolation is per-AP only.

Exact wording is "on the same AP [...]"

You cannot view this attachment.

I interpret that as meaning clients on the same WLAN but on different APs can reach each other.

Still fine in @wiggler's use case though.

Are you suggesting to split the network to try to isolate the leak?

Yes, but that's required unless you're using VLANs.   What VLANs bring to the table is that they create virtual L2 domains, which allows you to create networks atop shared physical infrastructure.  Without them (if you're using native networks) then you need separate ports / switches / cabling for each network in order to maintain L2 isolation.

So unless you switch to VLANs, you need to keep those networks physically separate.  It's not a hard requirement as you already know, it's possible to use the same L2 domain, but you'll see the kind of issues that you're seeing.

In that case, would it be best to put switch C, with the access point on the separate port?

Yes

Then that would have the guest subnet, and a sort of secondary lan subnet?

Not sure where you're getting this "secondary" lan from?  There would only be two native networks: the main LAN (router port 1), and Guest (router port 2).

You might be thinking that the AP needs both a native network as well as a tag for Guest?  If so, I think that only applies when you are using the UniFi switch with VLANs.  If you're not using VLANs then there won't be any tagged network- just the native Guest net.

To be fair, I've never set up a UniFi AP this way so I'm speaking a little bit out of my rear end.  I *think* you can use it like this.  Someone should correct me if not :)

You want me to bridge switches A and C through 2 ports on the firewall?

No.  No bridging.

Those are to be separate routed interfaces.  Check the diagram I just added to my last post.

You mentioned earlier that you had switch C connected to switch A.  Did you try separating those as well?  Put Switch A on one of the router ports and put Switch C (with the Windows PC) on the other router port.  Configure them as separate networks in OPNsense.  Make sure those switches don't link to each other.  Also, try disconnecting the Ethernet cable from the PC and plugging it in again in to reset the connection, in case the IPv6 addresses are sticking around.

Could adding a rule blocking lan from reaching the guest network prevent lan devices from getting guest addresses? I'll give it a try.

I don't think so, because IPv6 RAs are part of the ICMPv6 protocol which is enabled by default in OPNsense via system rules.  You can't disable or override those.  However, even if you managed to you would only be masking the issue.  I think that by having those switches all connected together you had a single broadcast domain and that needs to be sorted out, IMHO.

EDIT: attaching a sample diagram with some made-up IPs.

Do you think I would be OK leaving the network configured as is (with an untagged lan network and vlan tagged network) and rely on the managed switch to keep the guest network contained?

In either case, whether you use VLANs or separate native networks, you will still need firewall rules to restrict traffic between the networks.  I'm assuming you know that but you mentioned something about containment here, so just worth mentioning.

Enabling IPv6 can be an eye-opener to existing L2 issues.  It's not clear how you have things wired but it does sound like you need a VLAN-aware managed switch.  Probably the issue was there before but you didn't notice under IPv4 because DHCP is centrally managed and you were only getting one IP.

Right now OPNSense and the AP have no idea that your switch isn't enforcing VLANs.  From the perspective of OPNsense you have two networks (a native LAN and a tagged Guest) so it does what an IPv6 router should do and multicasts RAs on each interface.  Likewise the AP is probably tagging Guest frames as it should, but it's your switch's responsibility to make sure they aren't forwarded out the wrong ports.  Unmanaged switches don't do anything with VLAN tags; they just get passed through.

Depending how you've connected things, the untagged and tagged traffic are sharing wires and switches on the same broadcast domain.  Since the IPv6 RAs are multicast, the ones from the Guest network are also visible to the Windows PC and subject to how that particular client handles tagged frames.

Let us know how you've wired things, but certainly a managed switch should help.

Thank you Ad & team for adding this.  It's been a great help.

The tunable to disable PCID (vm.pmap.pcid_enabled=0) is only needed in some cases, as it's off by default in recent versions of FreeBSD (since 13.2 apparently).  I guess it depends how long ago the system was installed.

OPNsense moved to the FreeBSD 13.2 base in 23.7 (Community) / 23.10 (Business).

The N100 was launched in January 2023, so if this bug is impacting then my guess is it falls into one of these scenarios:

- Early production unit with initial OPNsense install using pre-23.7 image.
- Transplanted OS disk from an earlier installed system, or installed with an earlier downloaded pre-23.7 image.
- Config import explicitly passing along the enabled tunable (vm.pmap.pcid_enabled=1)

That's one possible cause of UFS corruptions.

There are reports of earlier intel microcode causing issues as well and people have had luck with uninstalling the microcode and re-installing it afresh.  I'm not sure what that's about...

I really like this baseline guide and want to try a variation of it on OPNsense 25.7.x.

There is a minor complication now that Dnsmasq is the default DHCP service having replaced ISC on new installs.  For some users now, Dnsmasq is authoritative for local domains rather than Unbound, so the forwarding is Unbound->Dnsmasq rather than Dnsmasq->Unbound (for those of us who use Unbound and not strictly Dnsmasq).  Furthermore, with the OPNsense recommended option "Do not forward to system defined DNS servers [✓]" this means Dnsmasq can't forward upstream so as not to cause DNS loops with Unbound or leak internal structure.

(I also would personally add DoT forwarding and DNS block list filtering on the CLEAR net, but that's just preference.)

Has anyone worked around this for recent OPNsense builds using the new Dnsmasq setup?  I considered adding a 3rd DNS service into the mix, either DNSCrypt-Proxy or AGH, in order to take over the role of upstream forwarder for the CLEAR net.  It would in turn forward to Dnsmasq for local domains just like Unbound does on the VPN net.  This seems a little heavy handed to me and am curious if there's a more elegant way(?)  I'm not familiar enough with BIND9 or views in Unbound to know if those would be helpful here.

Thanks for the effort in publishing the guide @schnerring. I've been studying it for some time since I first found OPNsense and I think I finally now grasp it (and OPNsense) enough to attempt.

It sounds like you both prefer VLAN 1 for management in UniFi, so I think I'll stick with the same since it just works and gives the possibility to recover easily.

@meyergru Are you able to expand the list marked "Native VLAN / Network"?  On mine there is a possibility to select "None" there (it's at the bottom).

Once that is done, I am able to select "Default (1)" to be tagged under "Tagged VLAN Management" using the "Custom" radio button.


@Patrick I am torn on whether or not to keep a native/untagged network in OPNsense at all, as a fallback.  Presently I have LAN dedicated for this purpose on igc0, so I can just put any unmanaged switch there and get access to the 192.168.1.0/24 (example) network regardless of my UniFi network being online or not.  If I instead remove this native network and carry VLAN 1 tagged on the trunk as before, what will happen in case I connect an unmanaged switch to that?  Will VLAN 1 act as native on the "dumb" switch and still give me access to 192.168.1.0/24 and the other tags will be dropped?

EDIT: asking also a different way: is the reason why you tag VLAN 1 in order to save an interface/port or is it because untagged presents a security risk?

@julsssark - If something happens to your switch and it gets factory reset with no ability to restore configs, how will you get it adopted again?  It doesn't know about VLAN90 in its initial state.

@meyergru - I'm already experiencing the pain of accidental lockouts :)  I was hoping I was just doing something wrong, but it sounds like a separate MGMT network is an idea prone to error and disaster in UniFi (at least without one of their gateways).

If the switch isn't finding its controller you can try the set-inform command in SSH: https://lazyadmin.nl/home-network/unifi-set-inform/

This worked for me recently as I had locked myself out while migrating.

As for VLAN1, I was until now using a tags-only trunk in OPNsense with VLAN1 tagged on it and this was working.  Unless I'm mistaken the switch can automatically map VLAN1 tags to its default native network on VLAN ID 1, and this also keeps OPNsense happy as it doesn't see "untagged" frames on the trunk, technically.  It's not good in practice I guess because the switch blindly sends all untagged traffic to this VLAN.

Having said that I also want to stop using VLAN1 and move to a dedicated MGMT VLAN.  I *think* the best way to do this requires at least 3 total router ports.  (Maybe some setups can get away with 2 if they have WAN trunked also, in a router-on-a-stick situation.)

You cannot view this attachment.

In this setup you need a separate, small unmanaged switch like a Netgear GS105 for bootstrapping new or factory reset network devices prior to moving them to the MGMT VLAN.  The bootstrap/provisioning network maps to "LAN" in OPNsense, on the default network, on a dedicated physical port (e.g. igc0).  After provisioning you can move the device to the MGMT VLAN and then disable (or not use) the LAN interface.  It's only needed for device bring-up.

The trick will be that you have to make the UniFi controller always available on the 192.168.1.0/24 network, maybe even multi-homed with the MGMT VLAN.  I don't like the idea of keeping sensitive things on this default "bootstrapping" network so I'm not sure how to solve this from a security standpoint. Somehow it should always be available there in case of a total disaster where the main switch needs to be reset and adopted from scratch.

I need to correct myself here as I just learned something about my ISP gateway.  Until now I had been very confused by all the threads (such as those linked by @patient0) explaining the methods to gain access to the modem UI, because for me it "just works" with a default OPNsense installation.  I don't need any static routes, NAT rules, VIPs or anything.

Well apparently my ISP programs its leased customer gateways specifically to behave like this, even when in bridge mode.  Per ChatGPT:

## ✅ 2. What's Different About Comcast Modems (XB6/XB7/etc.)

Comcast's gateways are **not standard modems**. Even when in bridge mode:

* They still **intercept and respond to traffic** destined for `10.0.0.1`
* They do this **regardless of subnet**
* They don't require ARP entries or routing configuration on your firewall/router

This is **intentional** — it's **Comcast firmware behavior**, likely implemented like this:

### 🔧 Under the hood:

* The modem listens for **all Ethernet traffic** on its WAN interface that is addressed to `10.0.0.1`, even if the source device (your router) is not in the `10.0.0.0/24` subnet
* It does **not rely on standard IP routing**
* It responds directly — effectively creating a **"management side-channel"** on the WAN link

This is **not normal behavior**. It's specific to how Comcast has built their firmware to allow local access to the gateway **even in bridge mode**, to support:

* Xfinity app diagnostics
* Remote management
* User access to signal levels, reboot options, etc.

I apologize for my misinformation earlier.

This thread can use a clean-up so here's my understanding of things:

People with Intel chips have been reporting problems during upgrade to 25.7, though the exact cause is not known.  There are some people who are helped by uninstalling the intel microcode; some not.  One person reported success after changing the tunables recommended here; others not.  There doesn't seem to be a smoking gun and it's not even clear if everyone's issues are the same.  Some people probably just have bad hardware or a corrupt filesystem (could be for various reasons, not necessarily due to this bug) which may be contributing to the reports.

That said-

The intel microcode workaround is discussed in other threads on the board, but as for the tunables in this thread:

Code Select Expand

vm.pmap.pcid_enabled=0

This ^ is the general recommendation for everyone on N-series chips.  It's been shown to cause corruptions when enabled (per the FreeBSD mailing list topic), so keep it off.  It's been defaulted to off in Linux as well.  It may or may not fix anything you are experiencing, but it will at least help prevent potentially severe issues down the line.

Code Select Expand

hw.ibrs_disable: 0
vm.pmap.pti: 1

These ^ two are suggestions from Franco in case you are still having stability issues, but YMMV.  I didn't set these personally because I'm not having any problems with either stability or performance (I just wanted to prevent corruptions) and if you're not seeing any issue either then maybe leave these as they are. 

The one poster so far who reported some success after changing tunables had modified all three, so it's not clear which one made the difference for them.

About 20 years if the trend holds...

Code Select Expand

smartctl 7.5 2025-04-30 r5714 [FreeBSD 14.3-RELEASE-p1 amd64] (local build)
Copyright (C) 2002-25, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF SMART DATA SECTION ===
SMART/Health Information (NVMe Log 0x02, NSID 0xffffffff)
Critical Warning:                   0x00
Temperature:                        42 Celsius
Available Spare:                    100%
Available Spare Threshold:          10%
Percentage Used:                    3%
Data Units Read:                    320,117 [163 GB]
Data Units Written:                 9,553,141 [4.89 TB]
Host Read Commands:                 10,942,867
Host Write Commands:                134,320,113
Controller Busy Time:               977
Power Cycles:                       110
Power On Hours:                     6,224
Unsafe Shutdowns:                   28
Media and Data Integrity Errors:    0
Error Information Log Entries:      1,286
Warning  Comp. Temperature Time:    0
Critical Comp. Temperature Time:    0
Temperature Sensor 2:               52 Celsius

That SSD was newly installed in Nov. 2024, so even rounding up the consumption rate is probably <5% per annum.  This is probably where all the spare capacity helps.

I'm assuming the decay will continue on a linear trajectory but only time will tell.  Knowing my luck I'll have a failed disk by this time next year :)