HTTPS splash pages on Peplink AP AC mini

Hello
I have a Peplink AP AC mini, and im having problems with adding https sites as default splash pages, they just don’t work, the captive portal just opens blank pages, do you know if theres something that must be changed in the configuration of the AP AC Mini for https to work?
Thanks

I have never tried. Do you see any SSL errors in the browser? Does the page you want to use have any frame sets? Does the https page contain data from more than one server? (Does it contain artifacts from many domains - Adsense, Facebook, amazon, etc). Since the router is intercepting traffic and routing it to the destination of your splash page, I imagine the client is limited to resources in that specific web domain (i.e. All traffic is going to or coming from Facebook.com)

My advice would be to find a very simple https page and try with it to see if the issue is with SSL or specific to the page you are wanting to use.

I also beleive that the Peplink is expecting specific values to and from the portal page if you are doing authentication. That might be causing some grief. What happens if you do open authentication?

How it works is that actually our spashpage is let’s say http://somesite.com/splash.php this php is the one that handles login and authentication and it works fine. But it also has an iframe inside that shows different sites depending on the client, sometimes our clients wants to show their Facebook fan page, sometimes they want to show their website homepage, etc. When our clients sites are plain http they work fine. But when it’s an https, either a normal site or a Facebook page (https), it doesn’t work. Android devices show sometimes certificate warnings depending on the whitelist elements added on the configuration of the peplink, but we can’t get to make them work for everyone.

Someone may pop in with their experiences with the splash page and https, but you may find quicker resolution be entering a support ticket.

https://contact.peplink.com/secure/create-support-ticket.html

This may be an issue of needing to add certificate authority domain names in the allowed networks field so the users browser can run its revocation/validation checks. I would imagine a browser would just spin waiting for it. As a test, you could load your ssl splash page in your browser, then immediately change to a captive portal enabled network and see if the cached SSL information enables the client to load the splash page.

If that is the issue, you can find the list of default trusted CAs for each popular OS and just add their domain names.

Just a thought and I hope it helps you.

1 Like

Hello @cervantoso
Not sure if this may be your situation though our team had a recent issue with a roll out resulting in similar issues. We had the Captive Portal setup through InControl2 and assigned to both the required SSID and also a dedicated VLAN (giving Layer 2 Network isolation), this was resulting in the Captive portal attempting to double authenticate, the solution was to remove the captive portal from the VLAN and it all came good.
Happy to Help,
Marcus :slight_smile: