GUI : Transparent proxies (both http/https) make GIU unreachable

[lezidev]

Hello everyone

In my training project, I need to set up a captive portal connected to a wireless access point. The last one distributes DHCP on the LAN interface. I have two network cards not three as suggested in documentation tutorial ; it's not possible so I tried on two cards configuration.

I have an issue on the captive portal, more precisely on the web GUI. Actually I tried to add http and https transparent proxies on it which is on the LAN network card.
However when I did this, it was on the LAN interface (web GUI and guestnetwork are on this interface) and now I can't get access on the GUI. It makes sense, this is what the transparent proxies should do.

Of course I'm stuck now.. I tried to undo the LAN interface on my server but it appears the configuration is still the same.
N.B. The captive portal still work on the LAN interface

LAN is : 10.100.70.0
WAN is : 10.100.71.0
and the Web GUI is on 10.100.70.254

EDIT: I tried this on account of HTTPS certificate issue when clients need to log on but the browser shows certificate error.

[lezidev]

To make the connection with dev reply on Github :

easiest steps to reconfigure your box, with a factory reset is to flush all firewall related configurations, go to the gui and then reapply settings when done.

Code Select Expand

ipfw flush
pfctl -d

Then configure your firewall, next your captive portal....

[northbyte]

It sounds like the main issue is that the transparent HTTP/HTTPS proxy rules are now intercepting traffic destined for the captive portal's own management interface. Since the Web GUI and guest network are both on the LAN interface, adding transparent proxying there can prevent access to 10.100.70.254.

I would first try to restore GUI access by connecting from the LAN and temporarily disabling the transparent proxy rules from the server's local console or configuration files. Once access is restored, make sure the management IP (10.100.70.254) and any required captive-portal authentication traffic are excluded from the interception rules.

For the HTTPS certificate problem, I would avoid using transparent HTTPS interception simply to solve certificate warnings. Modern browsers validate certificates strictly, and a captive portal should normally use a properly configured certificate and an appropriate authentication/redirect workflow. Testing the portal from a clean client while checking DNS, routing, firewall rules, and certificate-chain errors can help identify where the failure occurs.

If you're building this as a security-training environment, it can also be useful to perform a separate Wi-Fi/network security assessment after the portal is working. Paranoid Security provides information about Wi-Fi security audits and network testing here: Paranoid Security