Security

Hi Guys,

We are using Aruba AP 105 which is associated to Aruba controller 3600 Version 6.2.1.3. Internal office wireless network is working fine but clients are not able to see the guest login page. After connecting to guest SSID they try to browse the internet and should normally get a captive portal where they enter their guest credentials. However, when they browse the internet, they get to securelogin.arubanetworks.com but the name resolution from this url to the controller's IP address is not happening. I tried to make a host entry in the guest laptop for this url to my controller's IP address and then it works fine so I am assuming this has something to do with DNS. All they can see in the browser is this and the page times out:

No, I am not.

Couple of questions:

• Did this ever work?
• Does the controller have an IP on the VLAN that the user is on?
• What is the output of show ip cp-redirect-address; does this look correct for your configuration?

No, this is for a new branch office that we are setting up. The exact same setup for another branch office works perfectly fine.

No, the controller is on different vlan and ip subnet than the guest user.

#show ip cp-redirect-address

Captive Portal IPv4 redirect Address ... X.X.X.X
Captive Portal IPv6 redirect Address ... ::1

Here, X.X.X.X is the controller ip address, so this looks correct.

We have a site to site tunnel between branch office and central office and all IP traffic is allowed so nothing is blocking in between. Also, it works fine by putting a dns host entry for securelogin.arubanetworks.com.

---

@Onkar Jog wrote:

No, the controller is on different vlan and ip subnet than the guest user.

---

The controller needs an IP on every VLAN that will do captive portal redirects.

Sorry, i thought you were asking about the controller management IP address which is on a different vlan than the user. Anyway, yes, the controller does have an IP address in the same vlan as that of the user. Like I mentioned before, it is working fine for 5 different branch offices with exactly same setup but doesn't seem to work for this new office.

I read this in a document which looks relevant to my issue:

The actual DNS server responds that it cannot resolve 
<https://securelogin.arubanetworks.com>, but the controller intercepts that reply and changes the packet to say that securelogin.arubanetworks.com is at the IP address of the controller itself. Remember that it is critical that the DNS server sends back a reply to the query.  It is only then that the controller can spoof the reply back from the DNS server.  Sending a DNS request without receiving a reply is not sufficient, since without a reply the controller will never help the client resolve securelogin.arubanetworks.com.

However, if that is the case then I dont understand how it is working fine for all other offices and doesn't work only for this office.

Also, you say this is for a new branch office.  Is the controller local to the branch?  What forwarding mode is the virtual AP in?

show wlan virtual-ap <nameofVAP>

Then check the role the client is in:

show user | include x.x.x.x

Then check the permissions of the role:

show rights <rolename>

no the controller is not local to the branch. its at central location. the VAP is in tunneled mode. the client is in "portal-logon" mode. here's the output:

#show rights portal-logon

Derived Role = 'portal-logon'
Up BW:No Limit Down BW:No Limit
L2TP Pool = default-l2tp-pool
PPTP Pool = default-pptp-pool
Periodic reauthentication: Disabled
ACL Number = 49/0
Max Sessions = 65535

Captive Portal profile = captive-guest

access-list List
----------------
Position Name Type Location
-------- ---- ---- --------
1 captive-guest_list_operations session
2 logon-control session
3 captiveportal session

captive-guest_list_operations
-----------------------------
Priority Source Destination Service Action TimeRange Log Expired Queue TOS 8021P Blacklist Mirror DisScan ClassifyMedia IPv4/6
-------- ------ ----------- ------- ------ --------- --- ------- ----- --- ----- --------- ------ ------- ------------- ------
1 user ocsp.usertrust.com svc-http permit Low 4
2 user ocsp.usertrust.com svc-https permit Low 4
logon-control
-------------
Priority Source Destination Service Action TimeRange Log Expired Queue TOS 8021P Blacklist Mirror DisScan ClassifyMedia IPv4/6
-------- ------ ----------- ------- ------ --------- --- ------- ----- --- ----- --------- ------ ------- ------------- ------
1 user any udp 68 deny Low 4
2 any any svc-icmp permit Low 4
3 any any svc-dns permit Low 4
4 any any svc-dhcp permit Low 4
captiveportal
-------------
Priority Source Destination Service Action TimeRange Log Expired Queue TOS 8021P Blacklist Mirror DisScan ClassifyMedia IPv4/6
-------- ------ ----------- ------- ------ --------- --- ------- ----- --- ----- --------- ------ ------- ------------- ------
1 user controller svc-https dst-nat 8081 Low 4
2 user any svc-http dst-nat 8080 Low 4
3 user any svc-https dst-nat 8081 Low 4
4 user any svc-http-proxy1 dst-nat 8088 Low 4
5 user any svc-http-proxy2 dst-nat 8088 Low 4
6 user any svc-http-proxy3 dst-nat 8088 Low 4

Expired Policies (due to time constraints) = 0

the nslookup to www.arubanetworks.com does give 2 ip addresses but https://1.1.1.1 doesnot work.

To ensure it is not DNS:

- On the client, run nslookup www.arubanetworks.com (do you get an IP back?)

- On the client, browse to http://1.1.1.1 (this removes DNS from the picture)

If you are still not able to connect then it is likely not a DNS issue.; let's start there.