The BigFix Relay to which a BigFix client reports sends a UDP packet to the client on port 52311, which is the signal for the client to gather something.
Does the BigFix client listen on UDP port 52311? I ask because when I run a ping UDP port utility (https://technet.microsoft.com/en-us/sysinternals/jj729731.aspx) on a properly working client, I get messages that the connection was refused … but when I run the same command on a properly working Relay, I see that the Relay is listening.
If the Relay is sending the UDP packet to the client, shouldn’t it be the client that listens?
Thanks, Aram … I did look at that network traffic guide. I wonder why the Windows psping utility returns “the remote computer refused the network connection” when I run that against a client (running only the BES Client) even with Windows firewall off.
I see these entries on the client with netstat -an | find "52311"
UDP 0.0.0.0:52311 :
UDP [::]:52311 :
On the relay, I see more entries than just these two …
netstat -an | find "52311"
TCP 0.0.0.0:52311 0.0.0.0:0 LISTENING
TCP [::]:52311 [::]:0 LISTENING
UDP 0.0.0.0:52311 :
UDP [::]:52311 :
I know the entries for TCP are for server / relay to relay notifications, gathering & reporting. Both computers have the same two entries for the UDP listing, so I still don’t get why one computer doesn’t accept the UDP connection with psping but the other does.
(I’m trying to help someone solve an issue where the UDP signal is not getting to the client, which tells me UDP 52311 is blocked somewhere.)
You can enable command polling on clients that are not getting UDP to help mitigate the issue.
I actually recommend enabling command polling on all clients at something like once every 6 hours, but enable command polling on clients that don’t get the UDP notifications once an hour.
Part of the reason I recommend command polling for all clients is that UDP notifications will be missed on any client that is sleeping or temporarily disconnected from the network. I will catch anything it missed when it polls for commands.
The primary impact of command polling is slightly more load on the relays, but the impact on the root server is minimal, unless many clients are using the root as it’s relay, and even then it may not be significant.
Hi James … thank you … I am aware of command polling, and while I may eventually set that up, I still want to diagnose the apparent issue of the UDP signal not reaching the DMZ clients. Some work, some don’t, so I am sure it’s something on the network, but I figured I’d attempt to perform UDP pings to see if I get answers; hence my question about the BigFix client listening on UDP and not responding to the psping utility.
The client actually does perform a “command poll” every time it does a relay selection which is controlled by _BESClient_RelaySelect_IntervalSeconds which by default is 6 hours.
I did this for the exact reason you mention, and the client performs the same thing when it starts up as well.
I haven’t tried a network sniff, but it’s entirely possible that the client simply does not reply when it receives a packet on UDP 52311. Unlike TCP, there is no requirement for a two-way handshake (SYN/ACK/SYN-ACK) when using UDP.
So, it could be that normal BES Client operation is one-way only on the UDP (client receives a UDP message from the relay, and simply performs a new gather without replying to UDP at all); or it may be that the BES Client does some kind of validation on the UDP packet before replying, and recognizes that psping is “not the packet you’re looking for”.
Using psping or nmap would give better results querying a TCP port, because barring firewall or port filtering the server must complete a TCP handshake before sending any real data or authenticating the client.
Hi all … thank you for your comments - it makes sense that the UDP listener on the client doesn’t ACK a request.
Also, the overall issue with the UDP packet not being received was resolved … despite multiple assurances from the network team, UDP traffic was still being blocked. Once the firewall issue was resolved, everything began working as designed.
The fixlet I linked ( https://bigfix.me/fixlet/details/3798 ) uses the last command time inspector to determine if a client has not received any UDP notifications for a period of time and then automatically enables command polling based upon this.