Daniel sent us this one — he's describing a setup a lot of home lab types will recognize immediately. You've got fiber coming in, an OPNsense box doing the routing and firewalling, and a UniFi access point handling your wireless. You're already broadcasting an IoT network and a main network. Now you want to add a guest network with a captive portal. The question is: where do you actually create the VLAN? In the firewall, in the UniFi controller, or both? And what are your options beyond the built-in captive portal if you want something more custom?
This is the exact moment where a home network stops being a router-in-a-box situation and starts looking like a miniature enterprise. And the thing is, that's not overkill anymore. When your thermostat, your printer, your doorbell, and your guest's malware-riddled laptop all share the same broadcast domain, you've got a problem that a single password can't solve.
Right — and the guest network without segmentation is just a polite fiction. You hand someone the Wi-Fi password and they're on the same subnet as your NAS. That's not hospitality, that's negligence.
Negligence with a splash page.
The splash page makes it feel secure. That's the trap. Daniel's asking the right question here because most people stop at "I checked the guest network box in UniFi" and call it done. They don't realize that checkbox does not create a VLAN — it just turns on client isolation and a basic captive portal. Your guest's device still gets an IP on your main subnet unless you've defined the VLAN upstream.
That's the misconception we need to kill right at the start. UniFi's guest network checkbox is not a segmentation tool. It's a convenience feature. It says "don't let these devices talk to each other" — which is fine for a coffee shop — but it does not say "don't let these devices talk to the rest of my network." For that, you need a VLAN defined in the firewall.
We're going to walk through this properly. First, the VLAN architecture — where does the subnet actually live, and how does the traffic get tagged between OPNsense and the AP? Second, the captive portal — do you use UniFi's built-in splash page, OPNsense's Captive Portal plugin, or something third-party like PacketFence? Third, the integration gotchas that turn a Saturday project into a Sunday debugging session.
I want to be clear about who this is for. If you're running OPNsense and UniFi, you're already past the point of plugging in whatever the ISP gave you. You've probably flashed an SSD with OPNsense, you've adopted an AP in the UniFi controller, you've maybe even set up VLANs for IoT. But the guest network with a captive portal — that's the feature most people skip because it seems like a lot of work for something that doesn't benefit you directly.
Until your nephew torrents something on your IP address and you get the letter from your ISP.
The captive portal isn't just about authentication — it's about liability. A terms-of-service click-through may not hold up in court, but it at least establishes that the person using your network acknowledged some ground rules. And if you're running an Airbnb or you have frequent guests, that's not trivial.
Let's get into the actual topology. Daniel's describing fiber to a bridge — probably an ONT in bridge mode — feeding an OPNsense mini PC, which then connects to a single UniFi AP. No managed switch in the middle. That's important because it simplifies the VLAN discussion. You don't need a managed switch to do VLANs if your AP connects directly to the firewall.
That's misconception number two, by the way. People think VLANs require a managed switch. They don't, not if your AP can tag traffic and your router can understand tagged frames. The AP's uplink port becomes the trunk. UniFi APs handle this natively — you create a network in the controller, set it to VLAN Only mode with a VLAN ID, and the AP tags every frame from that SSID with that ID before sending it upstream.
The real question Daniel's asking is: do I create the VLAN in OPNsense first, or can I do it entirely within UniFi? And the answer is, you can do a wireless-only subnet in UniFi using the Network Isolation feature — which does create a separate subnet that lives on the AP — but that subnet has no firewall rules, no traffic shaping, and no integration with anything upstream. It's a walled garden that only exists on that AP.
Which might be fine if you have exactly one AP and you never want your guest network to touch anything else. But the moment you add a second AP, or you want guests to reach a printer on a different VLAN, or you want to rate-limit guest traffic — you're stuck. The OPNsense-first approach gives you a proper firewall interface for the guest subnet, and you can write rules that are actually enforceable.
Our recommendation is option A: create the VLAN and subnet in OPNsense, then map the UniFi SSID to that VLAN ID. OPNsense handles routing, DHCP, firewall rules, and the captive portal redirect. UniFi handles the SSID broadcast and VLAN tagging. That's the cleanest separation of concerns.
The gotcha — there's always a gotcha — is that if you create a VLAN interface in OPNsense but forget to allow that VLAN ID on the AP's uplink port, the traffic gets dropped silently. The guest connects, gets an IP from DHCP, and then nothing loads. You'll spend an hour checking firewall rules before you realize the frames never reached the firewall in the first place.
The other gotcha is the reverse: you create the network in UniFi with VLAN ID ten, map the SSID, and it works — but only because the traffic is falling through to your default LAN. The AP is tagging it, OPNsense doesn't have a VLAN ten interface, so it treats the frames as untagged and dumps them onto the LAN interface. Congratulations, your guest network is your main network with extra steps.
I've seen this in forum posts at least a dozen times. Someone sets up a guest SSID, checks the guest box, sets the VLAN to ten, and thinks they're segmented. Then they run a network scan from the guest device and discover they can still reach the printer, the NAS, the baby monitor. The VLAN ID in UniFi doesn't create the VLAN — it just says "if this VLAN exists upstream, tag the traffic with this ID." If it doesn't exist upstream, the tag is ignored.
The order of operations matters. VLAN in OPNsense first, then the UniFi network definition, then the SSID mapping. Not the other way around.
That's the architecture piece. Once the VLAN is in place and traffic is actually segmented, then we can talk about what happens when a guest connects and hits that splash page. UniFi's built-in portal is fine for a simple password or a click-through, but if you want RADIUS authentication, voucher-based access, or a custom branded page, you're going to need something more.
Which we'll dig into. But for now, the core takeaway is: the VLAN lives in the firewall. UniFi is just the radio — it broadcasts the SSID and tags the frames. The actual network segmentation happens upstream.
Let's zoom out and define the stack Daniel's describing, because the topology itself dictates where the VLAN has to live. You've got fiber coming into an ONT running in bridge mode. Bridge mode means the ONT is just converting light to Ethernet, no routing, no NAT, no DHCP. It hands a public IP straight to whatever's plugged into it.
Which in this case is a mini PC running OPNsense. Probably something like a Protectli or a Fitlet, maybe a repurposed thin client. That box is your router, your firewall, your DHCP server, your DNS resolver — it's the brains of the operation. And then it feeds a single UniFi access point, which is the radio.
That's the canonical prosumer stack. And the reason it matters for this conversation is that there's exactly one device in this topology that can create subnets and enforce firewall rules between them — and that's the OPNsense box. The UniFi AP is not a router. It can't do inter-VLAN routing, it can't do stateful firewalling, it can't do NAT. It's an access point.
Which brings us to the core question Daniel's really asking: where does the VLAN live? And what does "best practice" actually mean when you're not running a data center — you're just a person with a homelab who wants guests to have internet without access to your stuff?
Best practice in this topology is unambiguous. The VLAN lives in OPNsense. You create the VLAN interface there, you assign it a subnet, you set up DHCP, you write firewall rules that block traffic to your LAN and IoT subnets but allow DNS and internet access. Then you trunk that VLAN to the UniFi AP, and the AP tags the guest SSID traffic with that VLAN ID.
Here's where it gets interesting — because UniFi does offer a halfway option that a lot of people gravitate toward. It's called Network Isolation, and it lets you create a wireless-only subnet directly on the AP without touching OPNsense at all. The AP runs its own little DHCP server and hands out IPs in a separate range.
For exactly one specific use case, that works. If you have a single AP, you never plan to add a second one, and you want a guest network that is completely walled off from everything — including the ability to print, access a media server, or do anything except browse the web — Network Isolation is fine. It's the "I don't want to think about VLANs" option.
The tradeoff is that you lose all visibility and control at the firewall level. You can't rate-limit guest traffic, you can't run intrusion detection on that subnet, you can't log DNS queries, and you can't set up a captive portal redirect that points to anything except UniFi's built-in splash page. The subnet exists in a black box on the AP.
The moment you add a second AP, the whole thing falls apart. Network Isolation doesn't coordinate subnets across APs. Each AP would hand out its own IP range, and a guest roaming from the living room to the bedroom would get a different IP and lose their session. At that point you're not running a network, you're running two networks that happen to have the same SSID.
The decision tree Daniel needs is really three branches. First, the VLAN architecture — do you go OPNsense-only, UniFi-only with Network Isolation, or the hybrid where OPNsense handles routing and UniFi handles SSID-to-VLAN mapping? Second, the captive portal — do you use UniFi's built-in click-through page, OPNsense's Captive Portal plugin with RADIUS and vouchers, or something third-party like PacketFence? And third, the integration gotchas — the things that break silently and send you down a rabbit hole of packet captures at two in the morning.
What I like about this episode is that it's not a debate. There's a clear right answer for this topology, and we're going to give it. But we're also going to explain why the other options exist and when they make sense, because the person listening might have a slightly different setup — maybe a managed switch in the middle, maybe multiple APs, maybe a separate controller running on a Raspberry Pi.
The principles translate. VLANs belong on the device that routes. Captive portals belong wherever your authentication logic lives. And the guest network should never, ever share a broadcast domain with anything you care about. If you walk away with nothing else, that's the one thing.
The other thing — which we'll hammer throughout — is that the order of operations is not negotiable. VLAN in the firewall first, then the UniFi network definition, then the SSID mapping. Reverse it and you're either dropping traffic or leaking it onto your LAN. There is no third outcome.
The decision tree. Option A — create the VLAN and subnet entirely in OPNsense, trunk it to the UniFi AP. Option B — use UniFi's Network Isolation to spin up a wireless-only subnet on the AP itself. Option C — a hybrid where OPNsense does the routing and firewalling, and UniFi handles the SSID-to-VLAN mapping.
I want to be precise about what option C actually means, because it's the one most people end up with even if they don't realize it. You create the VLAN interface in OPNsense — that's where the subnet lives, that's where DHCP runs, that's where the firewall rules are enforced. Then in UniFi, you create a network of type VLAN Only with the matching VLAN ID, and you map your guest SSID to that network. The AP tags the frames, OPNsense receives them on the VLAN interface, and everything works.
That's the recommended approach for this topology. Option A and option C are functionally the same thing when you only have one AP — the distinction only matters if you've got a managed switch between the firewall and the AP. In Daniel's case, the AP plugs directly into the OPNsense box, so the uplink port on the firewall is the trunk.
Let's walk through the actual steps for the recommended approach, because the menu paths matter and getting them wrong is where people get stuck. In OPNsense, you go to Interfaces, then Other Types, then VLAN. You select your parent interface — that's the physical port the AP is plugged into — set the VLAN tag to ten, give it a description like "Guest VLAN," and save.
Then you go to Interfaces, Assignments, and you'll see that new VLAN interface in the list of available network ports. You hit the plus button to assign it, and now it shows up as a new interface — probably called OPT something. Click into it, enable it, give it a static IP — say, one ninety two dot one sixty eight dot ten dot one slash twenty four — and save. That IP becomes the gateway for your guest subnet.
Services, DHCP Server, and you'll see a tab for your new guest interface. Enable the DHCP server on that interface, define your pool — ten dot two through ten dot two fifty four, for example — and set the DNS servers. You can point guests to OPNsense itself for DNS, or hand out something external like one dot one dot one dot one if you want to keep guest DNS queries off your resolver entirely.
Then the firewall rules. This is where the segmentation actually happens. Firewall, Rules, select your guest interface tab, and you need at least two rules. First, a block rule for destination RFC nineteen eighteen — that's your ten dot, one seventy two dot sixteen through thirty one, and one ninety two dot one sixty eight address spaces. That blocks guest traffic from reaching your LAN, your IoT network, and any other private subnets.
You need a carve-out for the captive portal. If you're running the portal on OPNsense itself, you need an allow rule above that block rule that permits traffic to the firewall's guest interface IP on port eighty and port four forty three. Otherwise guests can't reach the splash page to authenticate.
Second, an allow rule for DNS — UDP port fifty three — to wherever your guests are resolving. Then a final allow rule for destination any on ports eighty and four forty three, which lets authenticated guests browse the web. Everything else gets dropped by the default deny. That's your basic guest firewall policy.
Now the UniFi side. In the controller, go to Settings, Networks, and create a new network. The type is critical here — you want VLAN Only, not Corporate and not Guest. VLAN Only means the AP will tag traffic with the specified VLAN ID but won't try to create a subnet or run DHCP. Set the VLAN ID to ten, matching what you created in OPNsense.
Then go to Wi-Fi, create your guest SSID, and under Network, select the VLAN Only network you just created. That's the mapping. The AP now knows that any device connecting to this SSID gets its traffic tagged with VLAN ten and sent upstream to OPNsense. The AP doesn't do any routing, doesn't hand out IPs, doesn't enforce any firewall rules — it just tags and forwards.
This is where the gotcha we mentioned earlier bites people. If you create the UniFi network with VLAN ID ten but you never created VLAN ten in OPNsense, the AP is still tagging the frames — but OPNsense has no interface listening for that tag. The frames hit the physical interface, OPNsense doesn't know what to do with tagged traffic on an untagged interface, and it either drops them or interprets them as belonging to the native VLAN — which is your LAN.
The result is that guests can't reach the internet, or worse, they can reach the internet but they're actually on your LAN subnet getting IPs from your main DHCP pool. You test it from a guest device, the web page loads, and you think everything is working — but you've got zero segmentation. The guest device can still ping your printer, your NAS, everything.
The reverse gotcha is equally common. You create VLAN ten in OPNsense, set up DHCP, write your firewall rules — everything looks correct on the firewall side. But you never configured the UniFi AP's uplink port to accept tagged traffic on VLAN ten. If the AP plugs directly into OPNsense, the parent interface on OPNsense needs to have the VLAN interface assigned — which we already did in the steps above. If you skip that, the AP is sending tagged frames upstream, but something in the path is dropping them. The guest connects, tries to get a DHCP lease, and never hears back.
The other thing that trips people up is the native VLAN. On a trunk port, untagged traffic belongs to the native VLAN — typically VLAN one, which is usually your LAN. If your AP's management traffic is untagged and you've set the switch port to trunk mode with a native VLAN of one, that's fine. But if you accidentally change the native VLAN on that port to something else, the AP itself loses connectivity to the controller, and suddenly you can't adopt or manage the AP anymore. I've done this. It's humbling.
The AP ghosting you because you changed one VLAN setting you didn't fully understand — that's a rite of passage in homelab networking.
That covers the VLAN architecture. But a guest network without a captive portal is just an open Wi-Fi network with extra steps. Let's fix that.
The captive portal is where things get interesting, because this is where the use case really dictates the tool. UniFi's built-in portal is dead simple — you check a box in the controller, pick a password or a click-through splash page, and you're done in five minutes. But it's a walled garden. No RADIUS, no custom branding beyond a logo upload, no terms-of-service checkbox that actually logs acceptance, no voucher system.
For a lot of people, that's plenty. If you just want guests to see a page that says "Welcome to the Smith household, password is taco tuesday," UniFi's portal does that. The limitation is that you can't tie authentication to anything external. You can't say "only people with a Google account can get on," or "here's a twelve-hour voucher code that expires after use.
Which is where OPNsense's Captive Portal plugin comes in. It lives under Services, Captive Portal, and it's been part of OPNsense since the early days — the current version supports RADIUS authentication, voucher-based access with time-limited tickets, and fully custom HTML and CSS splash pages. You can brand it, you can add an "Accept Terms" button, you can even embed analytics.
The tradeoff is that you're now running the portal on the firewall itself. That means every guest HTTP request gets intercepted by OPNsense before the device is authenticated, redirected to the splash page, and only then allowed through. It's a single point of failure — if OPNsense goes down, the portal goes down, and guests can't authenticate. But in a home setup with one firewall, that's already your single point of failure for everything, so it's not really a new risk.
The voucher system is where OPNsense's portal really shines for certain use cases. Say you run an Airbnb. You can generate a batch of time-limited voucher codes — each one valid for the duration of a guest's stay — and print them out or email them. The guest enters the code on the splash page, and they're online. When the time expires, the voucher is dead. No password sharing, no residual access.
That's the kind of thing that sounds like overkill until you actually need it. And the Airbnb example is perfect because you're not just being a good host — you're creating a paper trail. If a guest does something illegal on your connection, you can show the ISP that the traffic came from a voucher-authenticated session tied to a specific stay. It's not bulletproof legally, but it's better than "I gave them the Wi-Fi password on a sticky note.
Now, if you want to go beyond what OPNsense offers natively, there's a whole ecosystem of third-party captive portal solutions. PacketFence is the big one in the open-source world — it's a full network access control system. Device registration, MAC authentication, integration with Active Directory or LDAP, even the ability to run vulnerability scans before granting access. It's what universities and large enterprises use.
It's absolutely overkill for a home guest network. PacketFence wants its own server or container, it has a database back end, it expects you to configure switch ports and SNMP — it's a whole infrastructure project. But it demonstrates what's possible. You can run it in a Docker container on the OPNsense box itself, integrate it with UniFi via RADIUS, and create a splash page that requires Google login or SMS verification. Someone in the homelab community has definitely done this and written a forty-page blog post about it.
There are also cloud-managed options like Purple WiFi or Cloud4Wi, which offload the portal hosting to a cloud service. Those are more common in retail and hospitality — they give you analytics, social login, email capture — but they require your guest traffic to hit an external server for authentication, which adds latency and a dependency on someone else's uptime.
For the prosumer use case Daniel's describing, OPNsense's captive portal is the sweet spot. It's free, it runs locally, it supports vouchers and RADIUS, and it doesn't require a separate server. The thirty minutes you spend configuring it gets you a system that's genuinely useful, not just a checkbox you ticked.
The architecture decision here mirrors the VLAN decision we already made. If you use UniFi's captive portal, the splash page is served by the UniFi controller. The AP intercepts the guest's web request and redirects it to the controller. Traffic still routes through OPNsense, but the authentication logic lives on the UniFi side.
If you use OPNsense's portal, the splash page is served by the firewall itself. The advantage is that all guest traffic — pre-authentication and post-authentication — passes through OPNsense, which means you can enforce bandwidth limits, content filtering, and logging in one place. No split brain between what the AP knows and what the firewall knows.
There's also a hybrid approach that doesn't get enough attention. You can run a separate web server — say, Nginx in a Docker container on the OPNsense box or on a Raspberry Pi — that hosts a fully custom captive portal page with whatever branding, terms of service, and authentication logic you want. Then you point OPNsense's captive portal configuration to that external URL. The firewall still handles the redirect and the access control, but the user experience is entirely yours to design.
That's the route you go when you want the splash page to look like it belongs to you, not to OPNsense or UniFi. Custom HTML, custom CSS, your own logo, maybe a little animation. It's a flex, honestly. Your guests connect to the Wi-Fi and see a beautifully designed landing page instead of a generic login box, and they know they're dealing with someone who takes their home network seriously.
Or someone who has too much time on their hands. But either way, the capability is there. And the integration with RADIUS is what ties it all together if you want to get fancy. You can run a FreeRADIUS server — again, in a container — and have it handle authentication for both the captive portal and the UniFi controller. That way you've got a single authentication back end for everything.
Let's pull this together into something you can actually act on. If you pause the episode right now and want to start configuring, here's the decision framework in thirty seconds.
Tier one — you just want a simple click-through page, maybe a password. Use UniFi's built-in guest portal plus the VLAN we already set up in OPNsense. You get the splash page from UniFi, the segmentation from OPNsense. Done in an afternoon.
Tier two — you need actual authentication. RADIUS, voucher codes for an Airbnb, custom branding on the splash page. That's OPNsense's Captive Portal plugin. It runs on the firewall, it's free, and the voucher system alone is worth the thirty-minute setup if you have rotating guests.
Tier three — you want enterprise-grade network access control. Device registration, MAC authentication, Active Directory integration, vulnerability scanning before access is granted. That's PacketFence territory. And I want to be honest here: this is a weekend project that turns into a month-long obsession. It's powerful, but it's not a casual setup.
The one thing that is non-negotiable across all three tiers: create the VLAN in OPNsense first. Do not rely on UniFi's guest network checkbox for segmentation. That checkbox is a client isolation toggle, not a VLAN. If you remember nothing else from this episode, remember that.
The reason this keeps tripping people up is that UniFi's interface makes it feel like you're doing segmentation. You check the box, you set a VLAN ID, it looks authoritative. But the VLAN ID field in UniFi is just a label — it says "tag this traffic with this number." It does not say "create a subnet with this number and enforce firewall rules on it." That part is your job, and it happens in OPNsense.
Here's the quick-start checklist. Write this down, or don't — we'll say it slow. Step one: in OPNsense, Interfaces, Other Types, VLAN. Create the VLAN interface on the parent port. Step two: Interfaces, Assignments, add it, give it a static IP. Step three: Services, DHCP Server, enable it on that interface, set your pool.
Step four: firewall rules on the guest interface. Block RFC nineteen eighteen, allow DNS, allow HTTP and HTTPS to the captive portal IP, then allow web traffic out. Step five: in UniFi, create a network of type VLAN Only with the matching VLAN ID. Step six: map your guest SSID to that network. Step seven: enable the captive portal — UniFi's or OPNsense's, depending on your tier.
Step eight: test it with an actual guest device. Not your phone that's already trusted on the LAN — grab a tablet, a spare laptop, something that has never touched your network. Connect to the guest SSID, verify the splash page appears, authenticate, and then run a network scan. Try to ping your printer. Try to reach your NAS admin page. If you can't, you did it right.
If you can, go back to step four — the firewall rules are where segmentation actually gets enforced. The VLAN separates the traffic at layer two, but the firewall rules are what say "this subnet cannot talk to that subnet." Without both layers, you've got the illusion of segmentation without the reality.
The other thing to test: disconnect and reconnect. Make sure the captive portal comes back. Make sure DHCP gives you a fresh lease. Make sure your voucher still works if you're using one. The number of setups that work exactly once and then break on reconnect is not zero.
That's the captive portal session timeout biting you. Both OPNsense and UniFi have idle timeout settings — if a guest disconnects and the session hasn't expired, they might bypass the portal on reconnect. That's usually fine for a home setup, but if you want the portal to reappear every time, you need to set the timeout aggressively.
One thing we haven't touched on — and I think it's worth flagging before we close — is where captive portals are headed as the broader internet shifts underneath them. Most portal redirects still assume the client has a public IPv4 address. The portal intercepts the first HTTP request, spoofs the response, and sends the user to the splash page. That whole dance depends on the client thinking it's talking to the open internet.
If your ISP has you behind carrier-grade NAT, or worse, they've gone IPv6-only with some transition mechanism like four six four XLAT, the redirect logic can get confused. The client's browser makes assumptions about what a valid internet connection looks like, and a portal intercept that doesn't handle IPv6 correctly can leave the guest staring at a blank page wondering if the Wi-Fi is broken.
It's an edge case today, but it's growing. More ISPs — especially in Europe and parts of Asia — are deploying IPv6-only access networks. The captive portal standards are slowly catching up. RFC eight nine five two defines how portals should handle IPv6, but not every implementation follows it yet. OPNsense's portal handles it better than most; UniFi's is still catching up.
Then there's Wi-Fi seven and multi-link operation, which is going to change how SSIDs map to physical radios. MLO lets a single device connect across multiple frequency bands simultaneously — two point four, five, and six gigahertz — all under one association. The question of which VLAN that traffic belongs to gets murky when the traffic is striped across bands.
The standards bodies are working on it, but the practical implication for a home user is: don't over-engineer your VLAN setup today assuming it'll map cleanly to Wi-Fi seven tomorrow. Build what you need now, and be ready to revisit when the hardware catches up.
On the IoT side, Matter and Thread are slowly making the dedicated IoT VLAN less critical — at least for devices that support those protocols. They handle their own encryption and segmentation at the application layer. But guest networks are different. Guests bring random devices running random software, and no protocol is going to fix that. The guest VLAN will always matter, because liability doesn't go away just because the threat model changes.
Which brings us to the thing that actually matters here. A guest network with a captive portal isn't just a security project. It's hospitality done right. You're saying "I want you to have internet, I want it to be easy, and I also want to protect my own stuff — and yours, honestly, because my network is cleaner than most public Wi-Fi you'll use today.
Give your friends internet without giving them access to your printer. That's the whole thing.
Now: Hilbert's daily fun fact.
Hilbert: In the early fifteen hundreds, a lighthouse keeper on the Faroe Islands was legally required to maintain a flock of exactly six sheep — one for each week of his scheduled rotation — because the remote posting meant he'd otherwise starve before the next supply boat arrived.
...right.
Something to think about next time you're configuring DHCP reservations. This has been My Weird Prompts. If you enjoyed this episode, tell someone who's still handing out their main Wi-Fi password on a sticky note. We're at my weird prompts dot com. For Herman Poppleberry, I'm Corn.
