Bigfix agent connectivity issue

We are facing a peculiar issue in on our environment. We have installed bigfix agent and it is able to register to the relay for the first time. But it fails to communicate further. It will get first error when posting result. After few posting result failures, when it tries to register again, it will be failing and it will never get registered. We have reinstalled it few times - but it follows the same pattern. We have another client on the same segment, from that client also we are getting the same error. The clients are in Azure network. We have a VPN connectivity and NAT ip to reach bigfix relay. Telnet on port 52311 works fine to relay server.

No error found on relay logs. You can find the client log attached.

-------Pasting the error for reference------

At 08:02:53 -0400 -
Error posting report to: ‘http://169.53.35.215:52311/cgi-bin/bfenterprise/PostResults.exe’ (General transport failure.
socket timeout error)
At 08:09:42 -0400 -
Error posting report to: ‘http://169.53.35.215:52311/cgi-bin/bfenterprise/PostResults.exe’ (General transport failure.
socket timeout error)
At 08:20:34 -0400 -
Error posting report to: ‘http://169.53.35.215:52311/cgi-bin/bfenterprise/PostResults.exe’ (General transport failure.
socket timeout error)
Beginning Relay Select
RegisterOnce: Attempting secure registration with 'https://169.53.35.215:52311/cgi-bin/bfenterprise/clientregister.exe?RequestType=RegisterMe60&ClientVersion=9.5.7.90&Body=151104&SequenceNumber=1&MinRelayVersion=7.1.1.0&CanHandleMVPings=1&Root=http://%3a52311&AdapterInfo=00-0d-3a-1c-23-b1_172.21.5.160%2f27_172.21.5.166_0&AdapterIpv6=00-0d-3a-1c-23-b1%5efe80%3a%3a20d%3a3aff%3afe1c%3a23b1%2f64_0’
At 08:21:35 -0400 -
RegisterOnce: GetURL failed - General transport failure. - ‘http://169.53.35.215:52311/cgi-bin/bfenterprise/clientregister.exe?RequestType=RegisterMe60&ClientVersion=9.5.7.90&Body=151104&SequenceNumber=1&MinRelayVersion=7.1.1.0&CanHandleMVPings=1&Root=http://%3a52311&AdapterInfo=00-0d-3a-1c-23-b1_172.21.5.160%2f27_172.21.5.166_0&AdapterIpv6=00-0d-3a-1c-23-b1%5efe80%3a%3a20d%3a3aff%3afe1c%3a23b1%2f64_0’ http failure code 0 - registration url - http://169.53.35.215:52311/cgi-bin/bfenterprise/clientregister.exe?RequestType=RegisterMe60&ClientVersion=9.5.7.90&Body=151104&SequenceNumber=1&MinRelayVersion=7.1.1.0&CanHandleMVPings=1&Root=http://%3a52311&AdapterInfo=00-0d-3a-1c-23-b1_172.21.5.160%2f27_172.21.5.166_0&AdapterIpv6=00-0d-3a-1c-23-b1%5efe80%3a%3a20d%3a3aff%3afe1c%3a23b1%2f64_0

Did you find a solution to this issue? I just encountered the same issue, also in Azure.

Yeah… it was a network issue… there were many packet loss in VPN connectivity between Azure and Softlayer…
We were able to solve the network issue, by reducing MTU size on the server to 1300 from 1500…

1300 seems a bit small. 1400 would probably work as well. The key is to reduce your MTU to match the path you are traveling (the VPN encapsulation adds overhead to the packets, causing them to exceed the Path MTU and get fragmented).

Details and how to use ping to determine optimal MTU is at https://www.google.com/amp/s/www.networkworld.com/article/2224654/cisco-subnet/mtu-size-issues.amp.html

1 Like

the network team had done some trial and error on another server and ended up at 1350. Trying that first. Thanks for adding in the ping command testing link, I’ll give that a look as well.

The MTU size corrected my connection issues as well. Thanks so much for the assistance on this issue.

Happy to hear that… We lost almost 4 weeks to find this solution after so many troubleshooting / argument sessions with many teams including PMR team :wink:
Just to add to it - We can not lower MTU size for azure Linux server below 1500. So we changed our relay from Linux to windows.

Interesting, I just lowered the MTU size for a Linux server in Azure. Wonder what your limitation was? I don’t want any future surprises.