- Access exclusive content
- Connect with peers
- Share your expertise
- Find support resources
03-08-2025 08:59 AM - edited 03-08-2025 09:30 AM
Environment: panos 11.2.4 h5, GP 6.3.2-525, New customer/configuration
We are running into an issue where a GP user that logs in from their home, gets a DHCP/dns record tied to the GP MacAddress via our internal DHCP/dns Server in the expected subnet.
That all works. If they come into the office and connect to the internal network they get a new DHCP tied to their physical MacAddress but because the old lease is still out there in the GP Subnet, reverse DNS cant be updated. They still get the IP and can browse out through the network but nothing can connect back to them via dns name until the other lease runs out and the physical MacAddress lease reattempts to record itself.
The issue can happen in reverse as well. User has their physical MacAddress registered internally then goes home and logs in via GP and dns cant register the GP MacAddress because the machine is tied to another lease already under a different Mac.
As we are new to palo and new to GP i'm not sure if i'm missing something in the config or if this is just how it works and i'd need to have the leases set really low or work something else out.
03-08-2025 10:29 PM
This doesn't really have anything to do with the GlobalProtect configuration itself, but instead the DNS server that you are using. There's a number of things on the DNS server that can help out with this like integration with Active Directory, dynamic updates being properly enabled, and ensuring that you have aging and scavenging setup properly. When GlobalProtect connects the DHCP client service should be sending an update about the change of address infromation, but you can also change how often a client is setup to update its registration through the DefaultRegistrationRefreshInterval registry.
As long as the DHCP server has dynamic updates enabled you really shouldn't be seeing any issue here on a regular basis. Even when everything is setup properly there's still instances where you'll see stale entries, but it should be an infrequent occurrence where it sounds like you're running into this on a regular basis. If you're not the one managing the DHCP and DNS infrastructure, I would recommend engaging that individual/team and really have them validating their side of things. With a proper configuration, clients can update their DNS information themselves even if you were using an internal IP pool for GlobalProtect instead of routing them through to your DHCP server(s).
03-09-2025 07:22 AM
The clients updating their DNS Information themselves via their Kerberos ticket is something that's come up as a possible solution. Meant to have this in my original post but we are using IPControl for our DNS/DHCP server which is a bind server. I don't personally administer that side of the world but apparently it's not the easier application to deal with.
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!