"
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
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
