Microsoft updates getting blocked by Firewall

[JiaXiang]

I have follow below link to allow these URL in my security policy but today I perform Windows update still very slow and from the log I still able to see some aged-out in my log for update. Any configuration change can help me to solve this issue ? 

https://docs.microsoft.com/en-us/windows-server/administration/windows-server-update-services/deploy...

URL 

http://windowsupdate.microsoft.com
http://*.windowsupdate.microsoft.com
https://*.windowsupdate.microsoft.com
http://*.update.microsoft.com
https://*.update.microsoft.com
http://*.windowsupdate.com
http://download.windowsupdate.com
https://download.microsoft.com
http://*.download.windowsupdate.com
http://wustat.windows.com
http://ntservicepack.microsoft.com
http://go.microsoft.com
http://dl.delivery.mp.microsoft.com
https://dl.delivery.mp.microsoft.com

officeapps.live.com/
cd.office.net/
office.com/
officecdn.microsoft.com/
officecdn.microsoft.com.edgesuite.net/
microsoft.com/
*data.microsoft.com/
*.delivery.mp.microsoft.com/
*.metaservices.microsoft.com/

[kiwi]

Hi @JiaXiang ,

It's not very clear how you've configured your policy.

For Windows Updates specifically, do you have a security policy in place for the application 'ms-update' ?

How is the traffic identified/blocked exactly ? Is the traffic blocked from a security profile perspective ?

Cheers,

-Kiwi.

[JiaXiang]

Hi Kiwi,

In the security policy I have allow above FQDN any service and any application but the log result is showing aged-out. When using outlook in office the outlook will have  (!)  mark.

[JiaXiang]

User who is using Global protect or I try to test using mobile network to perform Windows update is fine. I think the problem is not in Windows firewall.

[JiaXiang · Accepted solution]

After raise to PANW TAC checking and the issue is actually ISP BGP routing issue. PANW TAC perform a packet capture and notice there is no drop packet in firewall then PANW TAC confirm that the issue is from ISP. Due to ISP BGP route the traffic to some ip that is not firewall resolve to. After ISP fix the routing issue then the issue is resolve. 

[bhelman]

This issue is a year old.  How were you dealing with wildcard FQDN's?  It's my understanding you cannot use them.  I'm trying to solve this very issue.

[Adrian_Jensen]

You can not use wildcard FQDNs (because an address object must be resolvable to a specific IP(s)), however above JiaXiang was using a URL filter which can be wildcarded as it matches a portion of a string within a HTTP-like request. URL filters only apply to URL requests (HTTP/HTTPS/various APIs on non-standard ports), FQDNs apply to any communication to an IP.

[bhelman]

Ah, so my testing methodology was faulty (using ping to test).  Do you know if Microsoft Updates are URL requests?  I can easily re-create the test and simply web instead of ping.

[Adrian_Jensen]

Microsoft update does a HTTP request (port 80 to something like updates.microsoft.com) followed by multiple HTTPS requests (port 443) to various Microsoft domains and CDNs to download the actual patches. There may also be ping tests for reachability, I don't recall exactly.