Wireless Access

hi,

where can one find detailed programming documentation for externally hosted captive portal using aruba controller and APs. (not IAP). Also, not using clearpass.

This can clearly be done as Purple wifi supports it:

http://support.purplewifi.net/support/articles/1000143426-aruba-controller-based-

For example , in this documentation for another brand of controller and externally hosted captive portal, we can clearly see the HTTP messages passed from/to the portal page, and the controller. (I guess you can call them controller here, as they are cloud hosted.)

http://blog.tanaza.com/blog/bid/249584/Captive-portal-splash-pages-and-externally-hosted-RADIUS-Server

We wish to obtain the same documnetation so we can integrate our own captive portal solution with external hosted login pages and RADIUS to aruba controller. (we can already see quite a bit from Purple's documentation, we just need to know how does the portal page trigger the controller to perform a RADIUS lookup for the client MAC trying to associated with guest WIFI)

thanks

hi apoapoapoapo

the controller doesnt trigger it, the client triggers it. Flow is as follows:

1. client connects, gets a role that has captive portal ACLs in it

2. client tries to open http://place.com

3. controller spoofs the src ip of place.com and the client establishes an HTTP connection and gets the index page

4. controller responds with http 302 redirect to the "login-page" as configured in the captive portal, say http://captiveportalserver.com

5. client dns resolves and then attempts to connect to captiveportalserver.com - there must be an allow rule in the captive portal access list for this host, placed above all the dst-nat rules, for example:

netdestination external_cp      << or you can put the IP directly into the ACL

   host 1.2.3.4

!

ip access-list session captiveportal

  user    alias external_cp    svc-http   permit             <<

  user    alias external_cp    svc-https   permit          <<

  user   alias controller svc-https  dst-nat 8081
  user any svc-http  dst-nat 8080
  user any svc-https  dst-nat 8081
!

6. client receives the external CP webpage which contains a form with username and password fields, and the form action is the controllers authentication interface

7. client adds username/password or whatever else is used to authenticate (might just be a "press ok to continue" where the username and password are embedded in the form as hidden data etc.)

8. client presses "ok/login" and the client submits the form to the controller, the controller then performs radius auth and if the result is OK it changes the role to the captive portal guest auth role (i.e. removes the captive portal).

you can refer to this link for some of the common methods

https://arubanetworkskb.secure.force.com/pkb/articles/HowTo/R-1649

regards

-jeff

Thanks for your reply, the sequence of events makes sense. What I was getting at is a detailed documentation regarding your step 8)

"and the client submits the form to the controller,"

If the portal page is externally hosted, the KB page you gave will need some adjustment.

For example, the KB page says for username/password login, the form HTTP POST back to

"/auth/index.html/u" on the controller, with username, and password form parameters.

Since now the portal page is externally hosted, does it post to <controller IP or controller host name>/auth/index.html/u  ?

how does the controller know which client it is, does it look at request MAC address at some lower level hidden from us ,  is there any more parameters we must supply ?

thanks

---

 If the portal page is externally hosted, the KB page you gave will need some adjustment.

For example, the KB page says for username/password login, the form HTTP POST back to

"/auth/index.html/u" on the controller, with username, and password form parameters.

 

Since now the portal page is externally hosted, does it post to <controller IP>/auth/index.html/u  ? 

---

The external CP doesn't need to know the IP or FQDN of the controller in the basic use cases of captive portal.

"/auth/index.html/u"  or   "http://controller.internal.place.com/auth/index.html/u"  as form actions, do the same thing here. Note that the FQDN example doesnt have to exist as a DNS entry (although it probably should for completeness), but it does require a new captive portal SSL cert (with matching CN) to be uploaded to the controller. Ignore that for now, get it working with the Aruba default cert first (standard disclaimer about not using the Aruba certs in real deployments goes here).

for example, the external cp can return

<form action="/auth/index.html/u">

or this (using the Aruba factory SSL cert)

<form action="https://securelogin.arubanetworks.com/auth/index.html/u">

or

<form action="https://controller.internal.place.com/auth/index.html/u">

where the final example requires that the captive portal SSL cert has the CN="controller.internal.place.com", the controller will hijack the DNS requests from the client and will return the switch IP of the controller.

Note that if the clients who are hitting the captive portal are in some vlan X, and if that vlan X is not the mgmt vlan (i.e the switch IP of the controller is not in that vlan), then the clients must be able to access the switch IP via their default gateway, or, you need to change the source IP being used for the captive portal from the mgmt vlan (default) to vlan X  (refer to CLI guide for command "ip cp-redirect-address a.b.c.d"

---

 

how does the controller know which client it is,

 

---

 

The controller will determine the user from the source IP of the http POST that comes in

 

 

---

 

 is there any more parameters we must supply ?

 

---

 nope.