04-27-2016 03:10 PM
I think I have nailed this down to a AAA profile or user role issue. After finding this thread:
User davidaVzB has the exact same issue I am facing. My captive portal SSID constantly disconnects users when they roam (sometimes even when they are idle), and they are unable to reconnect. We do have some slight differences, such as:
1. Band steering is enabled.
2. User Idle Timeout does not match DHCP lease (lease is 86400, idle timeout is 43200).
3. I have a 3400 controller, not 3600.
4. I am running 126.96.36.199 code, not 188.8.131.52
Every other point davidaVzB makes I have seen/configured as well. Today I began investigating his solution, which was to change his logoncontrol ACL to reference "user any udp 68 deny" instead of "any any udp 68 deny". My logoncontrol ACL already states "user any udp 68 deny", so his solution does not work for me.
I then tried to adjust my AAA profile for this SSID, first by changing the following to options that work on our guest SSID that does not have issues:
1. MAC Authentication Default Role changed from "cp_guest" to "guest".
2. 802.1X Authentication Default Role cahnged from "cp_guest" to "guest".
This did not do anything, as I still see the captive portal and disconnect while roaming. I then tried modifying:
3. Initial role changed from "cp_guest_logon" to "authenticated".
I now bypass the captive portal page and can roam without issue. So the problem seems to be within the Initial Role defined in the AAA profile I am using. Here are the ACL's in use on the initial role:
rol/,captiveportal/ --- ip access-list session global-sacl --- ip access-list session apprf-cp-guest-logon-sacl --- ip access-list session logon-control user any udp 68 deny any any svc-icmp permit any any svc-dns permit any any svc-dhcp permit any any svc-natt permit any network 169.254.0.0 255.255.0.0 any deny any network 240.0.0.0 240.0.0.0 any deny --- 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 any svc-http-proxy1 dst-nat 8088 user any svc-http-proxy2 dst-nat 8088 user any svc-http-proxy3 dst-nat 8088 ---
I finally tried creating a test ACL called "test-logon-control" which had all lines except for "user any udp 68 deny". This also caused me to disconnect while roaming. As far as I can tell, "svc-dhcp" includes udp 67-68, so I should be allowing all DHCP traffic now.
At this point I am stumped. Is there anything else I can try, or something I am missing above?
Solved! Go to Solution.
04-28-2016 12:39 AM
What role does the user get AFTER authenticating with the Captive Portal? That is the role that you need to look at.
Aruba Customer Engineering
Looking for an Answer? Search the Community Knowledge Base Here: Community Knowledge Base
Validated Reference Design Guides : http://community.arubanetworks.com/t5/Validated-Reference-Design/tkb-p/Aruba-VRDs
04-28-2016 08:36 AM - edited 04-28-2016 08:50 AM
Thank you, Colin. I took a look at our guest profile and noticed the following:
user-role cp_guest access-list session global-sacl access-list session apprf-cp_guest-sacl access-list session deny-all-internal access-list session allowall
The first two ACL's have no permit/deny statements in them, followed by a deny of all RFC1918 space, then a permit all. Since we use a 10.x.x.x network for this CP SSID, and it was being denied access to that network, via ACL deny-all-internal, it was being dropped. I updated the role to include a new "permit-services" ACL as follows and bumped it up in priority above the deny statement:
ip access-list session permit-services any any svc-dhcp permit any any svc-dns permit any any svc-natt permit any any svc-icmp permit
This allowed me to roam throughout the building without being dropped. I will continue to test today, but I think that solved the problem.