DHCP Server Does Not Lease Reserved IP Address from 2nd Time

[takumi1469]

Hi, I'm currently doing DHCP server migration from Windows server's DHCP server function to Palo Alto PA-3200 series, with PAN-OS 9.1 series. I copied over all the configurations from Windows server to Palo Alto including the IP address reservation. After migration, what happened was that, for an IP scope that corresponds to a VLAN with 802.1X dynamic VLAN allocation configured, the workstations whose MAC address is mapped to reserved IP address on Palo Alto could be allocated the reserved IP address for the first time, BUT, after signing out and signing in to the machine, the machines could not be allocated any IP address, therefore the users could not log in to the workstations. In the same VLAN, other workstations with no IP address reserved could be assigned an IP address properly from the pool; first sign in to the machine will assign an available IP address from the pool, and, if the user signs out  and signs in again, the same IP address gets assigned to the machine as the first sign in. 

Has anyone else experienced an issue like this? I can't imagine there is an issue with the configuration of DHCP server. This issue persisted with or without "Ping before allocating new IP address" setting, we made sure the reserved IP addresses are not used by anything else, and we also tried changing the IP pool range to not include the reserved IP addresses. We deleted the IP reservation for one machine, then the user could log in to that machine and an IP address was assigned, so we're convinced that the issue is with the Palo Alto's behavior when IP address is reserved for the machine. I'll appreciate any information. Thanks!

NGFW 

[pdwilson]

Just to add to this thread, I performed some troubleshooting with Mr. Saito, and we discovered what appears to be the behavior.  If a computer moves from one VLAN to another (via 802.1x authentication), and the computer has a DHCP reservation in the new VLAN, the computer attempts to request the same IP address it had in the first VLAN and the Palo Alto does not respond to the PC.  The Palo Alto seems to recognize that the IP being requested is not what "should" be requested per the DHCP reservation in the "new" VLAN, but it does not send back a DHCP NAK, so the computer doesn't know to send a DHCP DISCOVER broadcast.  

Here is are some example processes to illustrate the issue:

This is the normal process using Microsoft DHCP:
1) Windows PC starts on VLAN 10 with IP 192.168.10.2
2) User initiates 802.1x and the network switchport the PC is connected to is assigned to VLAN 20
3) The Windows PC sends a DHCP REQUEST message with IP 192.168.10.2
4) The Microsoft DHCP server recieves the DHCP REQUEST and recogninzes the requested IP (192.168.10.2) does not match the IP reservation for the VLAN 20, then sends DHCP NAK message to Windows PC
5) The Windows PC receives the DHCP NAK message and the PC sends a DHCP DISCOVER message
6) The Microsoft DHCP server responds to the DHCP DISCOVER message with the reservation IP for the VLAN 20 interface (192.168.20.2)

This is the non-working process using the Palo Alto as a DHCP server:
1) Windows PC starts on VLAN 10 with IP 192.168.10.2
2) User initiates 802.1x and the network switchport the PC is connected to is assigned to VLAN 20
3) The Windows PC sends a DHCP REQUEST message with IP 192.168.10.2
4) The Palo Alto recieves the DHCP REQUEST and recogninzes the requested IP (192.168.10.2) does not match the IP reservation for the VLAN 20, but no response is sent from the Palo Alto (the PA does not send DHCP NAK message to Windows PC)

5) Steps 3 & 4 repeat four times until the Windows PC stops trying and 802.1x eventually reverts to VLAN 10

edited for clarity

[BPry]

@takumi1469,

Personally with your setup, I wouldn't recommend switching over to the built-in DHCP server on the firewall. The DHCP capabilities of the firewall directly are pretty limited and are meant for very basic setups, if you already have a Windows DHCP server setup I'm not sure your reasoning for wanting to migrate away from it. 

[pdwilson]

@BPry 

Thanks for taking the time to reply.  The reason for migrating off of using Microsoft DHCP simply comes down to a server consolidation effort.  Besides the difficulty experienced with the DHCP reservations, the PA is performing the rest of the DHCP functions suitably for the setup.

[takumi1469]

Thank you for your reply. Maybe the hint was there when I felt that it was inconvenient that you cannot add a comment on DHCP server on each interface, and on each reservation for that matter for hostname for examlple.  Are you aware of specific limitations of the builtin DHCP server function of Palo Alto firewall? 

[pdwilson]

We performed some packet captures on the Palo Alto and they illustrate the problem, as follows:

No MAC reservation - works as expected

① User performed 802.1x auth and PC is moved into VLAN 2, then PC attempts to renew it's (VLAN 1) IP address
② Palo Alto rejects DHCP request since the requested (VLAN 1) IP is outside of the VLAN 2 DHCP pool

③ The PC responds to DHCP NAK from Palo Alto with DHCP Discover

④ The Palo Alto responds to PC's DHCP Discover with DHCP Offer (VLAN 2 IP 192.168.0.42)

⑤ The PC Requests VLAN 2 IP (192.168.0.42) offered by Palo Alto

⑥ The Palo Alto Acknowledges PC's Request

MAC reservation - Palo Alto does not send NAK

① User performed 802.1x auth and PC is moved into VLAN 2, then PC attempts to renew it's (VLAN 1) IP address
     Palo Alto never responds; the PC repeats the DHCP Request of the VLAN 1 IP several times...no NAK from Palo Alto
② At this point the PC has reverted back to VLAN 1 since user login ultimately failed; the PC sends a DHCP Discover

③ The Palo Alto responds to PC's DHCP Discover with DHCP Offer (VLAN 1 IP 192.168.0.34)

④ The PC Requests VLAN 1 IP (192.168.0.34) offered by Palo Alto

⑤ The Palo Alto Acknowledges PC

To summarize the problem:

●　If the PC moves from one VLAN to another, and the DHCP pool serving the new VLAN does not have a MAC reservation, the Palo Alto responds with a DHCP NAK which causes the PC to perform DHCP DISCOVER and get a proper IP for the VLAN.

●　If the PC moves from one VLAN to another, and the DHCP pool serving the new VLAN does have a MAC reservation, the Palo Alto never responds with a DHCP NAK.

[takumi1469]

Thank you very much, Paul-san, for your reply elegantly illustrating the issue we are faced with. I hope this post will gather more attention and eventually lead to a fix!