Windows Server in DMZ dosn't fetch Windows Updates

maybe the application control is blocking this (Zip Download)?

Do you have Web Filtering enabled on the rule beeing hit?

Hello LHerzog,

at first thank you for the fast reply !
The application control is not enabled, so I don't have entrys in this log.
On the rule,which is responsible for outbound traffic of the DMZ, Web Filtering is not enabled.

Best Regards
ranX

You will need Web Filtering enabled so the exceptions you created apply.

Be sure, the Server has the Proxy certificate installed.

When I do so, will it be OK, to choose the "deny all" policy ?
To my understanding an exception from this should work anyway.

When DPI engine is enabled, do I still need the certificate, when the proxy is not in use  ?

yes, you will need the proxy / DPI ReEncryption cert on the client.

if you exclude policy checks in Web Exceptions, this should work with the Deny All Policy.

be sure to also enable WebProxy on the DMZ zone. in Administration > Device Access

I will give this a try and report back tomorrow

great. and post some lines of the logviewer if it does not work.

Well, still no luck.  To trigger update traffic on the windows host, I always do "net stop wuauserv" and "net start wuauserv".
To be sure, the update service does a full refresh, I even delete the "SoftwareDistribution" folder.  
On the machine the refresh of available update always works, but when it gets to the point, to download them, it's stuck at the state "download pending".

At that time there is nothing to see on the Web Filter Log.
On the Firewall log I see this, when I set the filter for entries of the respective Windows machine as can be seen in the upper corner.  
I assume, these external IPs, the host tries to connect, are the microsoft update servers.
But I got no idea, how to allow access, as I don't know their URLs and a reverse lookup only tells, these are Microsoft servers.

Here the firewall log

the reason is invalid packet. also the traffic is not hit by any firewall rule (N/A).

please create one rule with a NAT rule applying to the traffic and try again. in NAT select Masq

Also please check the Web filter log - you'll see the URL path there (I hope).

Well, the funny thing is:
I have a firewall rule and I have a NAT rule.

When I don't filter for denied traffic, I see most of the outbound traffic from the DMZ going out and in as expected.
If this were not the case, I wouldn't even see a refresh of the available updates on the Windows host.

But for some strange reason, the routing of the packets seen on the screenshot goes wrong.
As you see, they have no "out" Interface entry.
I assume, this is, why they do not get masked and no rule is applied.
As long as they are missing this attribute simply no rule will match.

Well, the funny thing is:
I have a firewall rule and I have a NAT rule.

When I don't filter for denied traffic, I see most of the outbound traffic from the DMZ going out and in as expected.
If this were not the case, I wouldn't even see a refresh of the available updates on the Windows host.

But for some strange reason, the routing of the packets seen on the screenshot goes wrong.
As you see, they have no "out" Interface entry.
I assume, this is, why they do not get masked and no rule is applied.
As long as they are missing this attribute simply no rule will match.

Anybody with an idea, why some comunication to MS update servers works and other fails, as described above ?
Any help is appreciated.

please show us your DMZ host object and according firewall rule. also show us the zone in which the server is.