- Access exclusive content
- Connect with peers
- Share your expertise
- Find support resources
Enhanced Security Measures in Place: To ensure a safer experience, we’ve implemented additional, temporary security measures for all users.
10-31-2023 06:31 AM
I've never had the opportunity to use or need to use an FQDN in a security policy before but my first attempt to do so does not seem to be working. I'm trying to use an FQDN to restrict IPSEC/IKE traffic from a Virtual Network Gateway (VNG) in Azure. The public IP has to be dynamically assigned and we tear down the VNG and put it back in place periodically and each time it is created it gets a NEW public IP address.
I can point to the FQDN for this public IP address and it appears to resolve properly both in the GUI and from the CLI. In fact, showing the VPN gateways shows it pointing to the proper public IP in azure using the FQDN. However, the security policy keeps missing the traffic for some reason and it falls through to the clean up deny rule. I don't understand why and I'm not certain how to troubleshoot this as the DNS lookups and other items seem to be using the proper IP for the FQDN defined.
FYI - the security policy is simply two objects - destination FQDN and outside IP of the firewall allowing IKE/IPSEC. Statically defining the IP for the object in the rule works fine. Switching to an FQDN object is where it fails.
Any ideas?
11-01-2023 10:57 AM
Hi @TonyDeHart ,
That seems odd. Could you share a screenshot of the traffic as well as the policy created? Can you try creating removing IKE/IPSEC in the app and set it to an allow any for testing purposes to see if traffic hits the policy?
11-01-2023 11:12 AM
I can't this afternoon but can probably give it a shot sometime tomorrow when I can put the rules back.
Even if I can't use it I'd like to understand why it does or does not work and how it works. Interestingly at the CLI when I show the security policy where the FQDN goes I see 0.0.0.0 in its place in the source/destination. Is that normal?
11-01-2023 11:34 AM - edited 11-01-2023 11:38 AM
In Windows command prompt run
nslookup -debug example.com
Change example.com to domain you are using as FQDN.
Look up what TTL this domain has.
I sometimes see as crazy as 5 second TTLs around.
If domain has short TTL then Palo might time out.
How to Change the FQDN Refresh Timers
https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA10g000000ClKbCAK
FAST-DNS Resolution Issues
https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA10g000000boQJCAY
11-01-2023 11:48 AM
Admittedly it is very short at 1 minute but I don't control it as its assigned by Azure.
(default TTL = 60 (1 min))
The fqdn resolves properly in the CLI and more importantly, the IPSEC tunnel uses it when defined there. It is just the object itself fails in the security policy.
11-01-2023 11:54 AM
Check what value is in FQDN cache.
https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA10g000000ClHJCA0
11-01-2023 01:50 PM - edited 11-01-2023 01:51 PM
The FQDN showed up correctly after executing the show dns-proxy fqdn all command. I added an FQDN object for it again to the same rule and it showed up as 0.0.0.0 still.
But, when I added another rule with that FQDN object it showed up with the IP and then thereafter even modifying the original rule it showed up with an IP when running "show running security-policy" so now I'm not sure what happened or why it works now.
Previously, all I ever got was 0.0.0.0 in the policy.
I'll leave it and see if this persists as usable for the time being. It would be great if it does.
Thanks for everyone's help.
P.S I'm still on 10.0.6 on this FW - is it possible this is a bug? I'll be updating to 10.2.5 soon.
11-02-2023 05:35 AM
So I ran an "experiment" of sorts this morning to see if this FQDN policy really sticks and works and found an interesting anomaly which I can only chalk up to bug or some sort of CLI issue.
When I spun up the VGN in Azure which of course assigned a new IP address to my FQDN, the endpoint immediately showed up properly using the "show dns-proxy fqdn all". However, using the "show running security-policy" command continues to show the OLD IP address in the policy information. Despite this, the IPSEC tunnel comes up and the GUI shows a match on the FQDN rule. The IPSEC Tunnel activation however took a short bit of time so it wasn't immediate but it doesn't appear the "show running security-policy" is a reliable indicator of what IP address is actually being used.
Either way, I'm happy! It works and I can avoid changing the rules/objects every time we tear this down and turn it back up again.
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!