This one took months to track down. For those that have come to this site looking for reasons why Windows Firewall is blocking an application of communication through a port, I would first rule out two things.
- Ensure there is not a blocking rule for the same application or port. Windows processes firewall rules in a specific order, and a block rule takes precedence. Order of Windows Firewall with Advanced Security Rules Evaluation
- Double check that the path is correct. I often receive requests to allow an executable through where someone gave me the wrong path or had a typo. I always encourage them to send me a screen shot with the details expanded so I can visually see the prompt and path. They can also copy and past the path from the expanded details.
Alright, assuming the more obvious is out of the way, let me describe the scenario I had setup. I am using Group Policy to apply the firewall rules. However, I am using this through AppSense which utilizes GPO ADMX files and applies the settings on computer startup. This has worked great for years. As part of the process, I first look to see if the file exist, then I lay down the rule. On a reboot, I am wiping all the rules back to defaults and re-applying them at computer startup.
The reason for this was that many admins were adding firewall rules to the systems and failing to go through the correct process. By putting them in AppSense EM Policy, we consider these to be ‘approved, managed and documented’. The second reason was that if by some chance a rouge application or user put rules in place, we wanted to have it cleaned up on a reboot. Lastly, if an application was uninstalled and the files no longer existed, we closed up the holes by wiping those rules, which are not re-written since the file exist condition was no longer valid.
Years later, we started seeing sporadic devices that would show the Windows Firewall Prompt for credentials. None of our users have administrative rights, so they could not allow the communication through the firewall. The Windows Firewall and registry showed that the policy settings to allow were in place. No previous block rule existed, and when logging was turned on, you could clearly see the Windows Firewall blocking the communication.
What was identified is that when the Windows firewall service started up the rules were evaluated, but there seemed to be a race condition with how we were applying them locally in AppSense. If the rules were written in time, they were enforced, those written after the service was fully initialized were not enforced. This caused a lot of confusion because looking at the firewall settings the rules were all there.
The solution was to run GPUPDATE /Force.
Since we did not want to change our clean up and re-write process, as we felt this was more secure, we used LANDESK to distribute a custom task scheduler item to occur at user logon. The task simply runs the GPUPDATE /force and all of the firewall problems went away. The reason we did this at user logon, was that we assumed other GPOs written based upon conditions could face a similar enforcement issue. Doing this about a minute after any user logon has since cleared up our calls into the help desk relating to sporadic firewall blockage of allowed rules.
