ForcedRefresh UDP problem

[TimRice]

I have a server that is not acknowledging the UDP messages sent to it by it’s Relay. Client and Relay are both v10.0.5.

We used WireShark on the Relay to verify that the Relay is SENDING the UDP message, and WireShark installed on the Target Endpoint shows the UDP message from the Relay is being received by the Windows system, but BES Client never acknowledges the UDP message in it’s logs nor does it respond to the Relay as expected.

When I say UDP messages, I’m including both a New Targeted Custom Action, and a Forced Refresh attempt from the Console as a Master Operator.

Other machines in the same subnet seem to be working fine, acknowledging their New Actions and the Forced Refreshes.

Anyone have any suggestions on where I can/should look next? GPO is controlling the local Firewall, and there is currently a rule to allow the BES Client traffic inbound on UDP…

[JasonWalker]

I’d double-check the Windows Firewall rule. The easiest place is in Task Manager -> Performance -> Resource Monitor. Hit the Network tab, open the “Listening Ports”.pane, and find the BigFix UDP port. The Firewall Status on it should be “Allowed, Not Restricted”. I’m afraid I don’t know how to check this via command line or script though.

Where I sometimes see problems there is that the Windows Firewall Profile is not switching between Public/Private/Domain as expected, so GPO-applied rules might not be set as expected.

If that looks clear, may need to check for a third-party firewall from your antivirus or endpoint protection.

[ageorgiev]

If you have ruled out firewall as suggested by Jason, look into which app is actually listening on UDP 52311 (or whichever it is in your environment if you’ve chosen to change it). There are certain apps that automatically listen on random UDP ports and are known to “take over” the BigFix port (start listening on it BEFORE BigFix agent is able to) and essentially “intercept” the BigFix UDP messages. One known one that impacts us is DNS server from Microsoft. You can run something like netstat -nab > netstat.txt and just check the app (should give you the .exe).

If it is in fact the case, depending on what the app is you may seek to “reserve” the port somehow depending on how the app works. Microsoft do support excluding ports via netsh:

netsh int <ipv4|ipv6> Add excludedportrange [protocol=]tcp|udp [startport=] [numberofports=] [[store=]active|persistent]

[itsmpro92]

DNS servers are candidates for this type of problem. There are a couple of Tasks available in BES support to change the ephemeral port range used by DNS to exclude the port used by BigFix (default 52311).

[TimRice]

We found the problem!

The admin for these servers had configured to rule to apply to PUBLIC network traffic, rather than DOMAIN traffic.

And they only did this on a few of the servers. The rest they configured properly.

Once we switched the rules to DOMAIN, BES Traffic was flowing properly. Now I just need to create a Task that will track down all the misconfigured Windows firewall rules on our servers.

[JasonWalker]

I can’t speak to the rest of the firewall rules you have in place, but I have some canned things to check the BES ports if that helps. I’m pretty sure they’re on BigFix.me but I can check - but it may be an hour or two