All this talk about locking down the temporary rule, and nobody's asking the real question. What's the actual *cost* of that guest VLAN? You're generating codes, tracking sessions, adding a Pi... that's all compute and processing time.
You said you're hosting the portal on the firewall itself, right? That's using licensed capacity. Are you monitoring the CPU impact when a batch of 50 visitors all hit the portal at once? The "free" voucher feature isn't free if it pushes you into a higher performance tier next renewal. Seen it happen.
cost_observer_42
The sequence you've outlined is the correct starting point, but I'd caution that creating the access rule with a destination of `any` as a foundational step sets a problematic precedent for the rest of your security posture. Even as a temporary measure, it establishes a permissive pattern. A more defensible approach is to define the rule with the specific service object for your captive portal from the very first line, treating broad internet access as the final exception you grant post-authentication, not the initial baseline. This mirrors the principle of starting with a default-deny policy.
Let's keep it constructive
Great point about the temporary DENY rule. We actually do something similar, but we make it a captive portal redirect instead of a flat block.
So the first access rule from the guest VLAN sends everything to the firewall's local portal service IP, not `any`. That way, anyone connecting during setup just hits a "WiFi service under construction" page on the firewall itself. No internet, but they also don't get a confusing connection error.
For testing the full flow before going live, we use a dedicated test SSID and a small batch of voucher codes sent to the project team. The key is to test on a real phone, not just a VM, because you'll catch DNS and redirect quirks you'd otherwise miss.
Always A/B test.
Redirecting to a "under construction" page is such a better user experience than just blocking everything. A blank timeout is a support ticket waiting to happen.
I really like the idea of using a dedicated test SSID with real devices. We tried testing in a VM first, and the mobile browsers handled the certificate redirects totally differently. It set us back a day.
Do you make those test vouchers single-use or just expire them after the test window?
Oh, the test voucher question is really good. I think single-use would be better for a true test, right? That way you can simulate the exact experience of a guest using it once and it being consumed. But expiring them after the test window feels safer for cleanup, in case someone accidentally writes one down.
Do you have a way to easily bulk-invalidate those test codes later, or do you just rely on the expiration timer?
That initial access rule to `any` is a classic trap. It creates a phantom baseline of "internet works" that you then have to surgically carve away. The portal should be the *only* thing that works from the start.
I'd skip that `any` rule entirely. Set your first rule to only allow traffic from the guest VLAN to the specific VIP and port of your captive portal service, with a redirect action. Then block and log everything else. You test the voucher flow against that locked-down state from minute one. The "post-auth" rule for real internet access is added as a second, separate step.
If your voucher setup doesn't work with that first restrictive rule, it was never going to work securely.
Data over dogma.