Security

Hi!

As far as I can tell from the documentation and other various sources we're supposed to install SSL certificates on both Controller and Amigopod when using https for CP authentication. Why is it not enough to install on Amigopod webserver?

I did install a public certificated on Amigopod only, but that triggered a certificate warning for "secure.arubanetworks.com" not valid.

Is there any doc on the procedure to take when you want https on Amigopod CP - including what you will have to do on the Controller? If not - can anyone tell me cause this is causing some headaches :)

Thanks

John

Hi John,

The reason for requiring the secure connection to both the Amigopod and the controller can best be described in the diagram below:

The diagram shows that the actual wireless client is responsible for submitting the user credentials directly to the controller (Automated NAS Login [5]) and this triggers the RADIUS Access-Request transaction to Amigopod.

These steps are discussed in more details on the Amigopod & ArubaOS Integration guide available from the VRD portal on the link below.

http://www.arubanetworks.com/vrd 

Hope this helps

Cam.

Hi (again) Cam,

I've read through the VRD's (Campbus, Integration, Lab,), 6.1 User Guide etc. without really understanding this.

As far as my debugging tells me there is no communication between Controller and Amigopod Radius containing login credentials. Once I enter a correct username/password on the Amigopod portal - it sends an Authenticate success the controller that this client with this mac and ip is authorised or not, which is confusing norwegian on why Controller would need the SSL server cert.

But I guess I don't really have to understand it to be bone.

Tho a quick question - when creating a CSR is the common name the dns name of the controller? It seems vital since the cert warning I get on the client is related to the default domain "secure.arubwnetworks.com".

I'm very new to certificates, and I'm wondering if the common name here have to be reachable from internet when creating certificate through ie. verisign.

John

The Amigopod VRD that I think might help you out is on the following link:

http://www.arubanetworks.com/pdf/technology/Amigopod-AOS-Integration-AppNote.pdf

It describes each of the steps shown in the diagram in my previous post and what you should find is that a RADIUS Access-Request is sent to the Amigopod once the successful HTTP/S POST is received from the wireless client.

In terms of the CSR, the Common Name (CN) in the certificate needs to be DNS resolvable by the wireless client during the redirect process to the Amigopod Web Login page. This can be from an internal DNS server and doesn't necessarily have to be published to a public DNS server.

Let us know how you get on.

Cam.

---

@-cam- wrote:

 

In terms of the CSR, the Common Name (CN) in the certificate needs to be DNS resolvable by the wireless client during the redirect process to the Amigopod Web Login page. This can be from an internal DNS server and doesn't necessarily have to be published to a public DNS server.

 

---

Well - the Amigopod certificate is ok with a public resolvable address. For the csr for the controller it would be the common name of the controller I assume and the certificate will be bound to this address? We're only using public DNS for the guests, as I understand is recommended from the VRD's.

I was thinking this was a common setup which could have an easy explanation in one document or section. As it is I have to go through several docs (which don't describe the whole process of certificate setup) and do this in lab to see how it really works. It's a decent enough process of learning, but we're still re-inventing the wheel :)

John

Hi Jsolb - I'm going through this exact scenario right now and I went ahead and put Verisign certs on the Amigopod and my guest controllers.  If you don't, as you saw, you'll get the cert errors.  I actually saw Firefox puke on itself when the Amigopod redirects the client back to the controller when I had a self-signed cert on there.  That's what made me go with Verisign...that and it looks more professional if you aren't causing cert errors on your guest's browsers.

That all said, I too wondered why the Amigopod has to redirect the client back to the Aruba controller after a successful auth.  The controller is the NAS, Amigopod is the RADIUS server.  One would think all Amigopod needs to do is send the auth accept (or appropriate RADIUS message) back to the controller so it can place the user in the guest role.  The diagram and documentation that I read just says what it does, but not why it's necessary.  I certainly could have missed that part though as the documentation is over 400 pages.  Interestingly enough, if you switch the authentication to HTTP and sniff the traffic between the Amigopod and the controller, you see the Amigopod send the user's username and password back to the controller.  Why the controller needs all that info, I don't know.

What I do know though is that it's the controller's CP configuration that sets what the welcome page is for the guests.  Maybe that's why Amigopod needs to do that redirect.

Hi Mike!

Thanks for the added info. We don't want that cert warning either and are going for SSL certs. Just a bit confusing the setup since there are no docs that takes this from A to B with reason of C...

In Radius debug on Amigopod there is no such information sent to the controller. In http the username/pw will be in the Post to the Amigopod web-page and as such you can sniff it, but really no reason why it should communicate that to the controller directly. The redirect back to the controller for the welcome page could very well be in http tho right?

But ok - thats how it is currently, so I just have to get the certificate for the controller ordered.

When you created the CSR for the Controller - was this with an external resolvable cn? Do you use internal or external DNS for your guests? Isn't it a requirement when ordering SSL certs that the cn has to be resolvable, or is it only the domain part of cn that has to be valid?

John

The CN of the controller cert does NOT need to be resolvable as the controller will intercept client DNS requests for the name configured in the CN and return the IP address of the controller.  You can choose which IP address is returned by configuring the ip cp-redirect-address on the controller.  You will need a PEF license to issue that command and you MAY need to reboot the controller for it go into effect (I did).

For example, if the CN for your controller is guestportal.company.com, set the "Address" in your web login to be guestportal.company.com and you're done.  After successful auth, the Amigopod will redirect the guest to that URL and when he does a lookup, the controller will intercept and return its CP address.

FYI, if you have more than one guest controller, use the same CN for all of them. 

EDIT - FYI, the CN of the Amigopod DOES have to be resolvable though.  Either internally or externally, depending on what DNS servers you give your guests via DHCP.

---

@jsolb wrote:

Hi Mike!

 

Thanks for the added info. We don't want that cert warning either and are going for SSL certs. Just a bit confusing the setup since there are no docs that takes this from A to B with reason of C...

 

In Radius debug on Amigopod there is no such information sent to the controller. In http the username/pw will be in the Post to the Amigopod web-page and as such you can sniff it, but really no reason why it should communicate that to the controller directly. The redirect back to the controller for the welcome page could very well be in http tho right?

 

But ok - thats how it is currently, so I just have to get the certificate for the controller ordered.

 

When you created the CSR for the Controller - was this with an external resolvable cn? Do you use internal or external DNS for your guests? Isn't it a requirement when ordering SSL certs that the cn has to be resolvable, or is it only the domain part of cn that has to be valid?

 

John

---

Let me try to clarify how the workflow is structured between the controller and Amigopod.

• controller redirects unauthenticated session to Amigopod web login page
• The guest user completes the login form and clicks submit.
• submit goes to Amigopod initially to allow any pre-authentication checks to be performed
• the client browser is then instructed to HTTP/S POST the form credentials to the controller (typically securelogin.arubanetworks.com based on the CN of the default certificate)
• controller receives the HTTP/S POST transaction and crafts a RADIUS Access-Request and sends to the RADIUS server defined in your aaa-profile (typically Amigopod but doesn't have to be)
• Amigopod receives the Access-Request and processes it based on local database or proxy lookup to external server
• RADIUS returned attributes are sent based on the definition in the User Roles on Amigopod
• Controller potentially performs role derivation based on returned attributes (ie. Aruba-User-Role) and defines session length by parsing the Session-Timeout / Idle-Timeout values returned from Amigopod.
• If controller Captive Portal Profile has a welcome page defined, the controller will then redirect the guest web session to this defined page.

So if you run the Amigopod RADIUS debugger you should see the first RADIUS request sent directly after you see your guest session attempt to connect and POST the form credentials to the controller address or FQDN.

Just out of interest, this is eaxctly how the controller performs web authentication when a locally hosted Captive Portal page is used and the only difference being that Amigopod is hosting the page - the packet flow is exactly the same.

Hope this helps

Cam.

Hey all, a little late to the party here. I'm running into this issue as well in my current guest wlan captive portal setup. Read though all your comments and here is where I'm at.

- I am using captive portal and guest self registration with amigopod, controller as NAS, local radius server on amigopod

- guest role allows only Internet access (and necessary services for amigopod/controller/etc), including public DNS (not internal DNS)

- Amigoipod self registration portal should not be publicly accessible, however the hostname of amigopod registration portal needs to be resolveable.

My question: Without using internal DNS servers, for a portal page that should only be accessible by users on guest wifi (not over the Internet), how in the world do we resolve a private IP address using a public record? It sounds like the majority of you are making the amigopod registration page public. I just need to make the DNS entry public, but using a private IP address. I'm stumped. Is the controller capable of acting as an authoritative source for DNS lookups for specific hosts?

-GR

If you need the Amigopod's hostname to be resolvable, you need DNS to return that for you. There's no way around that. If you dont have DNS handling this function (internally or externally), then you will not be able to do what you want. The controller only has the ability to spoof DNS for it own name and not for Amigopod.

GR,

You could consider using a DNS proxy in your environment. The proxy could be configured to point to the public DNS server accessible to the guest users but also include a couple of local DNS entries for the Amigopod server(s). For example there are a couple of commands you could run on a perimeter Cisco IOS router that will allow it to perform this DNS proxy function for you.

The following link has some discussion around how this can be configured on a Cisco IOS router Cisco IOS DNS Services Configuration

Hope this helps

Cam.

To calrify around the cp-redirect setting on the controller, does it matter that it is the CP Guest supplying the redirect to <URL>/cgi-bin/login?

This is my last stumbling block before we move to using an internal DNS proxy, as even though setting the cp-redirect to the correct controller, it will still not resolve the controller CN/URL?

Good call cam, we do have websense in our environment which can proxy dns requests, we just don't have that functionality configured right now. We are researching that and the possibility of using a cisco device to do the same.

Can I assume that most everyone else is either publishing their registration page publically or just allowing internal DNS access for guests?

-GR