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

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Announcements
Please sign in to see details of an important advisory in our Customer Advisories area.

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

L1 Bithead

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 

Solid, and resilient.
6 REPLIES 6

L1 Bithead

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

Cyber Elite
Cyber Elite

@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. 

@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.

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? 

Solid, and resilient.

L1 Bithead

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

No MAC reservation - works as expected
01.png
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

02.png

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.

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!

 

20210309-4249320_s

 

Solid, and resilient.
  • 5154 Views
  • 6 replies
  • 1 Likes
Like what you see?

Show your appreciation!

Click Like if a post is helpful to you or if you just want to show your support.

Click Accept as Solution to acknowledge that the answer to your question has been provided.

The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!

These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the LIVEcommunity as a whole!

The LIVEcommunity thanks you for your participation!