Path check
Confirmed the guest tag traversed the access point and managed switching path to the firewall interface.
05 / Network support / firewall
Repairing a guest network from client to firewall
A guest SSID connected but skipped the captive portal. I followed the path through VLAN tagging, DHCP, DNS, OPNsense sessions, and firewall policy until the wrong interface binding surfaced.
Starting point
Where it started
Guest clients could join the wireless network, but the expected portal flow did not appear consistently. The SSID label alone could not show whether the client VLAN, resolver path, portal zone, session state, and firewall rules agreed.
What I did
What I worked on
- Verified the guest SSID tag across the access point, managed switching path, and OPNsense interface.
- Checked the client lease and DNS path separately from captive-portal enforcement.
- Found the portal zone bound to a network-services interface instead of the actual guest interface and corrected the binding.
- Cleared stale bypass sessions, aligned lease and portal timeouts, and repeated the test with a fresh mobile connection.
Evidence
What I checked and recorded
Root cause
The captive-portal zone referenced the wrong logical interface even though the visible guest-network labels looked plausible.
Validation
Retested with a fresh phone, confirmed a guest lease and portal session, then checked that internal network roles remained unreachable.
Result
What changed
A fresh client received the expected guest lease, entered the portal flow, established a guest session, reached the internet, and remained isolated from internal network roles.
What I learned
What I took from it
- Interface labels are not enough; verify the live handle and generated service state.
- Stale sessions can make a correct fix look broken or a broken configuration look correct.
- Client behavior, DHCP, DNS, portal state, and firewall policy all need to agree before the issue is closed.
Next case study / 06