Security

Good Morning All-

I'm having a specific issue with Captive Portal redirection...in that it isn't happening. The customer had an HTML welcome page designed for them and when applied to their Captive Portal configuration, the welcome page fails to load and the guests are unable to browse out to the internet.

For the sake of everyone's sanity:
* the guest VLAN does have an L3 address

* guest logon is enabled in the captive portal settings

* when I use the internal (Aruba provided) captive portal pages, everything works like it should

* when I tried a basic default captive portal HTML file (provided by someone here in the community - thanks!), it also worked without issue

What this tells me is that:

1) the controller config is good

2) the custom HTML isn't

However, I'm not an HTML expert...not even an HTML beginniner. I'm hoping that someone out here is. I do have a TAC case open, but I don't know when they will get back to me. If anyone has experienced this before and can provide some insight into a resolution, please let me know. If you'd like to take a look at the HTML file, please PM me and I'll be more than happy to send it your way.

Thanks!

Shane

did you check on clearpass manual?

you speak about clearpass captive portal or controller captive portal?

Update:

This is a captive portal configuration that is defined on the controller, not through clearpass. 

I have two user roles defined, a guest-logon and auth-guest in split tunnel configuration. The auth-guest role works fine - all traffic is src-nat out to the internet the way it should be. When I change the AAA policy to guest-logon, the captive portal page loads, user gets an IP address in the correct VLAN, I can ping the gateway...all looks right. However, when I click on the submit for free wifi, I am returned to the captive portal page with this: 

....html?errmsg=Access%20denied

This is a custom HTML page. There is no place for the user to input a valid email or password, this is all done behind the scenes in the HTML itself, where it is passing a generic username and password when the user clicks on submit. I created a Internal db entry with the username and password and set it to the auth-guest role - it doesn't appear that this helps, as I'm not even sure that the credentials are being passed. I ran a show datapath session table | include <ip address> and found that ports 53 and 443 are being used by the test device, but I don't specifically see the controller IP in any of those conversations - the 443 is traffic outbound to load the CSS that is required for the captive portal page and DNS. I'm at a loss at this point...can anyone shed some light on this? 

Thanks!

Shane

First try to use a non-custom Captive Portal to verify that it's not the custom that is messing things up. To me it definately looks like it. Make sure the action on the form is "/auth/index.html/u" and that the form contains the fields username and password.

All the info you need is in Chapter 18 of the AOS UserGuide 6.3.

Once you're sure the two roles involved (guest-logon and guest-auth) work using the default built-in Captive Portal, then return to troubleshooting the custom pages.

Please note:

- The default server-group picks up the role from the guest account. This means that if you created an internal account, and that is assigned Guest role - that will override the role (guest-auth) that you have as default role in the Captive Portal profile. That doesn't seem to be the case here thought, but thought I'd mention it.

- guest-logon role traffic should be normal permit. The default settings for policy logon-control and captiveportal should be untouched for this scenario

John-

Thanks for the reply.

I had tested with the non-custom Captive Portal page a while back and had determined that something in the custom HTML was making life hard. I made some changes to the config based on your suggestions and I was finally able to get things working properly.

I've attached a document to this posting that I also used from TAC. This document helped me rewrite some of the HTML so that the original purpose of this page (which was to allow guests to connect without having to enter a valid email or password) remained. If there is anyone out there that is looking to do the same, please use this for HTML reference only...the ACL's seem a bit out of date.

Attachment(s)

Custom Captive Portal Web Guest Access.pdf   368 KB 1 version

Great to hear that my little nudge sendt you in the right direction :)