Security

Hello,

 

Aruba design guide recommends  to use external DNS when possible for captiveportal based  guest access.

If external DNS  is in play, does the controller  management IP participate in any  DNS (send/receive) at all during guest  redirection/handover process? ( Note.we are sourcing packets from mangment not loopback)

Put it differently, does the controller require DNS  connectivity in guest implmentation?

With  Trapeze implmentations,I had to allow DNS to be sourced from the controller but  thought of getting  some  thoughts from the forum.If there is a document/link to this info that would be great.

Thanks,

nerd

 

 

The client needs to be able to resolve DNS.  Absolutely.

 

Please see the "Guest Access with ArubaOS" design guide on this page for guest access details:  http://www.arubanetworks.com/technology/reference-design-guides/

 

Thanks Joseph.

I have no doubts on the clients and DNS connectivity. The question was about the controller  and DNS.

 

The guest role should have "permit" for DNS traffic on the controller i.e. the controller will just pass through the DNS requests from the client.

guest role is allowing DNS  traffic.

 

let me explain with an example..

suppose we throw a firewall between the controller and internet, controller IP is 192.168.10.50/29 and the guest client subnet is 172.16.20.0/24.

I have allowed  DNS/http/https  on the firewall for 172.16.10.0/24 only.do i need to punch a hole for  192.168.10.50/29 ?

I don't know if you made a mistake, but you need to allow DNS from the guest subnet of 172.16.20.0/24 for this to work.

Thanks Joseph.

 

This is what we have configured:

 

netdestination P-DNS
  host a.b.c.d
  host  e.f.g.h

 

ip access-list session guest-logon-access
  user any udp 68  deny
  any any svc-dhcp  permit time-range w-hours
  user   alias P-DNS svc-dns  permit time-range w-hours

one more thing folks.

 there is  dst-nat 8081 on the  controller ACL .So I think  I need to open port 8081 on the upstream firewall as well.

 

No, you don't.

 

The only thing you need is for the clients (not the controller) to be able to resolve DNS.  The controller's role is only to pass the client's traffic.  It does not directly resolve DNS and does not source DNS packets.

 

Thanks  for the reply Joseph,

 

Looking at the steps involved in guest authentication, it seems that it breaks from Step 14 onwards.

 

Investigations continues...

 

Do you have a "welcome page" configured in your Captive Portal authenticaton profile?

 

After step 14, can the client then open a different browser and do anything?

 

No we don't have a welcome page.

 

Please below for the captiveportal related configuration.

 

ip access-list session captiveportal
 user   alias controller svc-https  dst-nat 8081
  user any svc-http  dst-nat 8080
  user any svc-https  dst-nat 8081

 

 

user-role guest-logon
captive-portal "guestnetwork"
access-list session captiveportal
access-list session guest-logon-access
access-list session logon-control

 

aaa authentication captive-portal "guestnetwork"
   default-role "auth-guest"
   server-group "Internal"
   protocol-http
   white-list "ocsp.usertrust.com"

 

user-role auth-guest                              
access-list session cplogout
access-list session guest-logon-access
access-list session block-internal-access
access-list session auth-guest-access
access-list session drop-and-log
!

Strange thing is that once authenticated, DNS breaks on the client device.

 

Have not tried a different broweser but will do so shortly.

 

Thanks,

You should consider creating your guest network from the WLAN/LAN wizard and take it from there.  That is the simplest way to make it work.

I did not use a wizard but will keep it as my last resort.

Interesting observation, prior to authentication I can see DNS query/reply but post authentication in only see queries no reply from DNS server.

I'm going to run some debugs on the controller.

Hi ,

Have been away last few days. The cause of the DNS malfunction was due to the fact that NTP was off and this resulted the time based ACLs to play havoc.

 

Thanks