FQDN security policy

[P.Gandla]

Our internal servers connects to a server on internet . There are existing FQDN based security policies. The destination FQDN resolves into multiple ip addresses . I am seeing few allows and denies for that particular destination URL on paloalto traffic logs . Users facing intermittent issues . It seems like firewall is querying for that destination and selecting a different ip addresses and therefore blocks internal server request to that destination . Any recommendations  ? Does configuring ip based policies can fix this issue ? 

[Adrian_Jensen]

First, are you seeing blocks based on IP or based on URL? There are many factors on which traffic can be filtered in a single PaloAlto Security Policy. The first of which is IP source and destination (an IP address, an IP block, or a FQDN that resolves to one or more IP addresses). Another is the URL which can match a URL Category. Other factors may include Security Zones, Services (TCP/UDP port), detected Applications, etc. An IP is not a URL and a URL is not an IP, as a URL may resolve to multiple IPs, and a single IP may host many very different URLs. One or both factors may be used in any given Security Policy.

I suspect the problem you are seeing is actually an IP problem stemming from fast-flux DNS. Fast-flux DNS is, unfortunately, commonly used these days with CDNs and diverse hosting. The DNS for a given FQDN returns one or more IP answers with a very short TTL (often less than 30 seconds) and may return a completely different set of IPs when queried a few seconds later. The PaloAlto, like many endpoints, has a minimum 30 second DNS caching time (so it doesn't flail with very short TTLs/bad responses).

From a client standpoint, this short TTL doesn't matter as the browser will pick one of the DNS responses, open a connection to that IP, and transfer data for multiple minutes+. The client won't connect to a different IP until it needs to open a new connection and does a lookup again. From the PaloAlto perspective, this is a problem as the PA will get one set of IPs from the DNS response to filter on and a few seconds later the client will get a different set of IPs to connect to. So the IP the Paloalto is filtering on will mismatch the IP the client is connecting to, for the same FQDN. See this for a previous discussion:

https://live.paloaltonetworks.com/t5/panorama-discussions/frequently-changing-ip-for-a-fqdn/td-p/547...

You can view the IPs a FQDN is currently resolved to in the PaloAlto by clicking the "Resolve" link next to the FQDN in the Address Object configuration. There are basically 2 ways to work around a fast-flux DNS problem. The first is to try to discover all the IPs associated with a FQDN and create and Address Group (though this is likely to require constant maintenance). The second option is to create a custom URL Category for your destination URL (the FQDN portion of the URL) and use that instead of an IP source/destination.

I.e.:

Objects-> Address:

Name = Website_Acme.com

Type = FQDN

Address = acme.com

Policies-> Security:

Name = Allow acme.com by IP

SrcZone = Trust

DstZone = Untrust

DstAddress = Website_Acme.com

Application = web-browsing,SSL

Action = Allow

vs.

Objects-> Custom Objects->URL Category:

Name = Allow_Acme

Type = URL List

Sites - acme.com/, *.acme.com/

Policies-> Security:

Name = Allow acme.com by URL

SrcZone = Trust

DstZone = Untrust

Application = web-browsing,SSL

URLCategory = Allow_Acme

Action = Allow

The URL filtering has advantages and disadvantages. The biggest advantage is that you use a wildcard to match all subdomains within URL (as you can not have a wildcard DNS lookup) and apply that rule regardless of where the URL is hosted. The biggest disadvantage is that the rule will initially match all traffic as a URL can not be determined until after a TCP connection has established and the URL request exchanged (if the URL doesn't match then the PaloAlto with re-evaluate Security Policies to find the next appropriate policy match).