Windows Firewall preventing UDP

We have been seeing a problem with Endpoints able to report to the IEM Server, but they would not acknowledge the UDP messages telling them to check for new Actions and Forced Refreshes.

The Windows Firewall tasks are not showing as relevant, at least for the test machine I got my hands on.

When I manually added a Firewall Rule for UDP/52311 Any/Any, it started to work just fine.

When I was looking at the Firewall Rules, there were 25 other rules that all dealt with UDP traffic. I don’t know enough about the Windows Firewall rule behavior to know why one of those 25 was blocking the traffic and the Windows Firewall tasks were not detecting it.

Unless someone has a better suggestion, I’m planning to use the “Windows Firewall is Blocking BES Traffic” action as a skeleton to build a new task to target any Windows Endpoint with an operating firewall that doesn’t already have the Named rules.

1 Like

I don’t remember what it should look like.

It could be that the firewall is set to block all inbound traffic not specifically allowed through, and that the BES Client entry if it exists isn’t correct or doesn’t include 52311 UDP.

It could also be that another program is using 52311 UDP.


Auditing Firewall settings should be added to:

http://bigfix.me/analysis/details/2994765

or

http://bigfix.me/analysis/details/88 (out of date and overlapping the above)

If I recall correctly, the built-in “Windows Firewall is Blocking BES Traffic” may have a bad relevance detection to determine whether the Windows Firewall is turned on. As usual, you should start by running each of the relevance statements through the debugger & see which one is giving you a ‘false’.

I don’t recall what the detection logic failure is, but it had to do with whether Windows Firewall was turned on by a local setting or by a Group Policy. Ping back on this tomorrow if that doesn’t point you in the right direction and I should be able to retrieve the “better” logic from some of my postings on bigfix.me.

1 Like

I split Fixlet ID #518 out in the Fixlet Debugger yesterday afternoon. The Relevance seems to be detecting the Firewall just fine (Relevance #6).

Once I delete the 3 BES Client rules I manually added to my problematic laptop, Relevance Clauses #8 & #10 are both returning “False”.

As a short term fix I simply created a Fixlet that becomes relevant when the Firewall is active and any of the three BES Client Rules is missing. I copied in the Action script from Fixlet #518 and it seems to work, I just have to wait for all the misconfigured systems to perform their daily check for Content/Actions and I can start resolving this facet of the problem from a practical standpoint.

1 Like

I would also recommend enabling command polling on all clients. You could start with something like once every 12 hours for all clients, and maybe more aggressive for problematic clients.