Client not receiving IP Address from Windows DHCP/NPS intermittently

  • 2
  • Question
  • Updated 8 months ago
  • (Edited)

I have a Windows Server 2012r2 with DHCP/DNS/NPS (NAP is not enabled) and Aerohive wifi gear

DHCP is a /21 on the network with usually about 70% of IPs used.

2 SSID: 
SSID with PSK. IP is provided by Windows Server 
SSID with 802.1x Radius NPS. IP is provided by Windows Server

We have about 600 users on wifi daily. Every week or so, we have about 5-10 users that stop by and cannot get on the SSID with Radius auth. They authenticate correctly because I see the Network Policy and Access Services log in event viewer. But, they never receive an IP from the server. I packet captured a couple of clients and they were sending out a DHCP Discover request, but it doesn't seem to get answered.

This happens with Mac clients and PC clients. It does not seem to happen with iOS or Android devices.

When I take that same client and go on the SSID with PSK, it immediately gets an IP address. Then, I click back to the SSID with Radius and it works perfectly, obviously using the same IP it got when it was on the SSID with PSK.

I looked at the DHCP C:\Windows\system32\dhcp audit log files and the client that keeps trying to get an IP after it authenticates with the SSID with 802.1x, does not seem to be there. However, once I switch to the SSID with PSK, that client appears in the DHCP log.

I am unsure of what log to look at and what issue this can be.

Thanks for your help
Photo of Maxim Lapushin

Maxim Lapushin

  • 3 Posts
  • 0 Reply Likes

Posted 8 months ago

  • 2
Photo of MST

MST

  • 152 Posts
  • 3 Reply Likes
I had similar problem when use client classification. Similar situation. 
Photo of Dianne Dunlap

Dianne Dunlap

  • 75 Posts
  • 15 Reply Likes
When you say "DHCP Discover request, but it doesn't seem to get answered" you're seeing that on the wired side?  If that's the case, it would be a Microsoft dhcp problem.  If there's an access-accept from the server and the AP says it's forwarding the dhcp request to the wired side but it's not, it would be an Aerohive problem.  I am kind of puzzled as to why you'd be 'segmenting' traffic by having 802.1x and wpa-psk users on the same vlan.  Have you tried increasing the lease time?
Photo of Maxim Lapushin

Maxim Lapushin

  • 3 Posts
  • 0 Reply Likes
Right, I am seeing the wireless client request an IP and I am seeing it not get answered. So, I am not sure it is an Aerohive problem, but, regardless, I have no clue how to troubleshoot it if its an Aerohive problem.  The lease time is set to 8 hours and that is probably fine as far as I can tell. I have a PSK and Radius since some older clients and IoT only support PSK. 

Re: MST with client classification. What was the solution?
Photo of MST

MST

  • 152 Posts
  • 3 Reply Likes
Maxim,

Make sure you have enabled http and option 55. If you use client classification and are properly authorized by Radius, but client is not recognised its landing in "nowhere land" obtaining 169.x.x.x from dhcp. What clients are not recognised by Aerohive? Windows | MAC | Android ? One of the option is make a default user profile with valid DHCP - if client is not recognised by classification then it would be assigned to the default vlan (top profile). 

Client classification is not the safest method, but it is what it is. I would send you instruction how to use wireshark and aerohive access point to find out option 55 in DHCP request - having right option 55 you create OS object and use Supplemental CLI. The easiest would be update application signature as well as change default vlan with valid DHCP. Let me know anyway, -MST 
Photo of Tony Schaps

Tony Schaps

  • 28 Posts
  • 8 Reply Likes
I have not run into this with Aerohive, but I have with other systems over the years. To me, this seems related to the Broadcast vs. Unicast nature of the DHCP process, and it sounds to me like broadcasts (or some broadcasts) aren't going from wireless->wired or vice-versa. For example: DHCP Discover from the client is broadcast, a DHCP offer from the server is broadcast, but DHCP renew requests and responses (Acks) are unicast, if I am not mistaken. So I see a scenario where a device cannot get an IP address lease on the PSK SSID, but gets one on the 802.1x network, and when it switches back to the PSK, it only does a DHCP renew, not a Discover all over again.
This doesn't work out perfectly in my head, and I don't know how you have things configured, but under the PSK SSID settings, set IP Multicast conversion to Unicast to "always" if it's set to Auto, and see what that does. This may not be the exact problem, but I'd bet it's something to do with broadcasts getting blocked somewhere along the way. 
You wrote "I am seeing the wireless client request an IP and I am seeing it not get answered." 
You need to be sniffing these interactions in multiple places, ideally one wireless, at least one wired. 

Good luck.
Photo of Rob Pritchard

Rob Pritchard

  • 86 Posts
  • 8 Reply Likes
Just 8.1 or any revision of 8.1?  We're running on 8.1r2a.
Photo of MST

MST

  • 152 Posts
  • 3 Reply Likes
We have 230' so we use HiveOS 6.5r8b.179369  firmware on the HM Classic 8.1.r2 
Photo of Rob Pritchard

Rob Pritchard

  • 86 Posts
  • 8 Reply Likes
I get that, but you said "don't use 8.1 as that firmware has some issue with Bonjure and DHCP too."  I'm asking if the Bonjure and DHCP problem is with any revision of 8.1 (anything from 8.1r1 to 8.1r2a) or did you just see those problems on just 8.1r1?  What happened when you contacted Aerohive support about the problems you found on 8.1r1?
(Edited)
Photo of MST

MST

  • 152 Posts
  • 3 Reply Likes
Rob, I was refering to access point firmware as 8.1r2 with bonjure and dhcp issues in our case, reverting the firmware to 6.5.r8b fix all of them. DHCP had really long delay, bonjure shows only few apple tvs, etc.....  Aerohive support confirmed that issues in 8.r2 and advised to revert firmware on all access point to golden release which is 6.5r8b

HM appliance is using Software Version:8.1r2Build -MST
Photo of Rob Pritchard

Rob Pritchard

  • 86 Posts
  • 8 Reply Likes
Understood.  So you haven't tried HiveOS 8.1r2a yet?
Photo of Maxim Lapushin

Maxim Lapushin

  • 3 Posts
  • 0 Reply Likes
We aren't using client classification. The only thing we are using is Attribute 81 Tunnel-Pvt-Group-ID to direct clients to the correct vlan. We are using AP 230s with HiveOS 6.5r8b.

Also, the clients do not work on the SSID with Radius. They do immediately work with the SSID with PSK and then we switch them back to the Radius SSID and since it already has an IP address, it works fine. 

Ya, I am hesitant to push out the 8.x HiveOS since a while ago the hive support said we should remain on HiveOS 6.x 
Photo of Tony Schaps

Tony Schaps

  • 28 Posts
  • 8 Reply Likes
I misread and got the what works and what doesn't reversed, but I'd still try adjusting the "multicast to unicast" setting on the Radius SSID.