Wireless Access

After upgrading from ArubaOS version 6.1.2.3 to 6.1.3.10 our external DHCP stopped assigning IP addresses to clients. This deployment has been functional for over a year and I cannot discover what has suddenly caused the issue. As a band-aid, I was able to create the required DHCP scopes locally on the controller and enable that service. I have gone through the config side by side, line by line and see nothing which would prevent the required traffic. I verified that the DHCP server is still functioning. I verified all the VLAN memberships remain. I verified the Helper addresses are still in place. I verified that I can still ping the DHCP server. I went through the ACLs in user roles. I verified my initial roles. I have been through the release notes and see nothing interesting or useful. It really seems like this was not a big OS jump and I truly am puzzled but the sudden malfunction. I have rebooted the controller as well, just as a sanity check and that made no difference. Thoughts on what I am missing? What I can look for in the logs?

Thanks.

That is odd.

Here is an additional troubleshooting step.

What are the results if you were to spin up a temp/test SSID (new one) on the controller, using the same DHCP server, same VLANs etc.   Does it also fail ?   If you use the WLAN wizard you should be able to set one up in a matter of a few mins.

The goal of the test?  To see if something was messed up in the conversion or if all SSIDs (new and existing) are affected (at which time we start looking at VLAN/IP parameters and performance, or lack thereof)

JF

---

@jfernyc wrote:

That is odd.

 

Here is an additional troubleshooting step.

 

What are the results if you were to spin up a temp/test SSID (new one) on the controller, using the same DHCP server, same VLANs etc.   Does it also fail ?   If you use the WLAN wizard you should be able to set one up in a matter of a few mins.

 

The goal of the test?  To see if something was messed up in the conversion or if all SSIDs (new and existing) are affected (at which time we start looking at VLAN/IP parameters and performance, or lack thereof)

 

JF

---

Will definitely try this and report back, but it will have to be after hours. I don't want to break what is now working from the internal DHCP server.

Any updates on this potential issue?

I'll be upgrading from 6.1.3.8 shortly and need to figure out which version is the most stable.   6.1.3.10 is the latest, but I'm in similar situation where my corp users are on vlan1 and captive portal users on different vlan.

See if your user role has an "any any service dhcp permit" ACL, or if it has an "allow all" ACL

I had a very similar issue when I upgraded to that version, but instead the guest users were getting ips from the corporate vlan.  More specifically, it was all Apple devices with a small amount of others.

Corp users were on vlan 1 (bad idea I know, but I didn't set it up that way) and I can only think it was something to do with that and native vlan etc.

TAC couldn't work out why it was happening either.  In the end I created new vlan, subnet and scope on controller with "ip nat inside" and then it was working as it should.

Thats the same road I was going down MC.

Worth a shot, doesn't provide root cause, but fix is a fix sometimes ;)

JF

So with regard to roles, am I most concerned with the initial role or the authenticated role? It seems to me that authentication is working fine. I have three impacted SSIDs - Corporate (802.1X), iPad (MAC) and Guest (Captive Portal). In all three SSIDs, if I enter a static IP in the correct subnet, I can connect as expected. Further, the issue has been "corrected' by using the controller's DHCP server which would indicate to me that the authentication is working and we should be moving out of the initial role.

So working with my Corporate SSID

initial role = logon

802.1X Authentication Default Role = authenticated

user-role logon
access-list session logon-control
access-list session captiveportal
access-list session vpnlogon
access-list session v6-logon-control
access-list session captiveportal6

!

user-role authenticated
access-list session allowall
access-list session v6-allowall

!
ip access-list session allowall
any any any permit
ipv6 any any any permit

!

ip access-list session v6-allowall
ipv6 any any any permit

!

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

!

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

!

ip access-list session vpnlogon
user any svc-ike permit
user any svc-esp permit
any any svc-l2tp permit
any any svc-pptp permit
any any svc-gre permit
any any udp 4500 permit

!

ip access-list session v6-logon-control
ipv6 user any udp 68 deny
ipv6 any any svc-v6-icmp permit
ipv6 any any svc-v6-dhcp permit
ipv6 any any svc-dns permit

!

ip access-list session captiveportal6
ipv6 user alias controller6 svc-https captive
ipv6 user any svc-http captive
ipv6 user any svc-https captive
ipv6 user any svc-http-proxy1 captive
ipv6 user any svc-http-proxy2 captive
ipv6 user any svc-http-proxy3 captive