FQDN Object in Policy - not working but FQDN seems to resolve properly

[TonyDeHart]

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?

[JayGolf]

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?

[TonyDeHart]

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?

[Raido_Rattameister]

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

[TonyDeHart]

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.

[Raido_Rattameister]

Check what value is in FQDN cache.

• PAN-OS 8.1 and below: > request system fqdn show
• PAN-OS 9.1 and above: > show dns-proxy fqdn all

https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA10g000000ClHJCA0

[TonyDeHart]

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.

[TonyDeHart]

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.