For those following this thread and interested in getting better at troubleshooting, this is a perfect example of why people fail to solve their problems.
They start from a server error message and try to understand what happened somewhere in the network.
Since they can't figure out what caused the error, they start changing the configuration in all directions without knowing the source of the problem.
Even, if luckily they change the right component they would still be unable to explain why it fixed the problem.
This is a very common error.
The best way to troubleshoot a network device is to capture a sniffer trace.
Why ?
Because a network device is there to transport traffic (most often tcp/ip)...and usually knowing the details about the application is useless.
In some cases, it is indeed necessary to go deeper in the packet in order to perform a more inteligent routing/switching decision.
For example, when you do http cookie stickyness or radius loadbalancing.
But even in that case, the network device will work on a packet per packet basis and for each of them decide what to do with it.
With the sniffer trace you can first compare successful client-server exchanges compare to failed ones.
You can then see what is different (asymetric path ? traffic misrouted ? traffic blocked ? packet corrupted ? fragmentation ? ...)
All network problems which can lead to many different error messages on the server.
Messages that will be different depending on the application, the hardware, the OS, the vendor, ...
.bmp){kind=link}