Skip navigation
McAfee Secure sites help keep you safe from identity theft, credit card fraud, spyware, spam, viruses and online scams
712 Views 2 Replies Latest reply: Jan 6, 2013 11:19 PM by aussiewan RSS
aussiewan Newcomer 20 posts since
Mar 26, 2012
Currently Being Moderated

Jan 1, 2013 9:24 PM

Captive Portal issues - SSL breaks and non-javascript POST login

Hi all,


We have MWG set up in transparent proxy mode and have configured a captive portal (based on the built in template for IP auth) to authenticate users, but have a couple of issues.


First of all - SSL pages do not redirect to the logon page, the client gets an SSL error. If the user is already logged in, the pages work fine. It appears that the SSL tunnel can't be intercepted properly to inject the HTTP 302 to redirect to the logon page. I looked into the possibility of enabling the SSL Scanner, but from what I can gather I need to use a certificate on the MWG boxes which is always trusted by the end users. However this is for a guest network, and we don't have any managment over the end user devices, so we can not install the certificate on them. Is this a problem we are just going to have to live with? It still works, it's just inconvenient.


The other issue is that the login page (POST) from the templates uses javascript and xmlhttprequest to generate a custom HTTP POST with the username and password sent in headers. This works fine for a lot of devices... however it doesn't in the mini webbrowser on iOS (iPad/iPhone) devices which comes up when they detect a captive portal. The page refuses to render at all because it can't handle the javascript, and when the page is cancelled it disconnects from that wireless network. If I allow unauthenticated access to the apple website, then it can access the test file it wants and thinks that there is no captive portal, so it doesn't pop up with that box, however users then have to load up a web browser to a non-SSL site so they get redirected to the login page. I have tried creating a new page that uses standard POST to submit the username and password, however the MWG rules only appear to let you see the body.text content for the response, not the request, so I can't grab the user credentials out of the POST. Changing it to a GET request would work, but naturally we don't want user credentials stored in the URL which can be more easily accessed both on end devices and in MWG.


To make this process as painless as possible, we would like to resolve either one of these problems - we don't need both, just one, however I wouldn't mind working out both if possible.


Any advice is welcome. I can provide the rule-set we are using if you like, but as I said it's basically the built in template with a few tweaks to the login page format and set to authenticate against AD



More Like This

  • Retrieving data ...

Bookmarked By (0)


  • Correct Answers - 5 points
  • Helpful Answers - 3 points