Very strange connectivity issue

(tobygroves) #1


We’re having a very strange connectivity issue with our server/client at two customer sites.

The problem is that the client will not connect to the server at all, it’s as if the server wasn’t running. I did some diagnosis onsite at one of the customers and discovered some very strange behaviour.

It turns out that the client won’t even connect to the server when running on the same physical machine. Whether I specify the server by name or by IP address, it still won’t connect. The only thing that works is if I use the loopback address Obviously this only works if the client is on the same machine as the server but it’s the only scenario in which it connects.

Has anyone seen anything like this before? I can find nothing wrong with the general networking configuration of the server. It’s fully “pingable” from anywhere on the network via both its name and IP address, but the client software just won’t connect.

We’re using the SynapseSuperTCPServer channel if that matters. Is it possible there’s some issue with this that’s causing the problem? I’m at a loss where to begin trying to diagnose this issue.

(EvgenyK) #2

If you used IndySuperTCPServer, would it work as expected?

(tobygroves) #3

I did think about producing a build using the Indy sever instead to check. Maybe I’ll do that.

(tobygroves) #4

A month later…

I did try it with a different network library and it showed the same behaviour.

We have managed to track it down to Direct Access, a feature of Server 2012 R2 Essentials. Basically, if this is enabled and configured on the server, then it demonstrates this connectivity issue. I’ve replicated this here on a test virtual machine.

I currently have no idea exactly why this is happening but thought you might like to know in case you want to look into it yourselves. I think it’s a general IP connectivity issue rather than something specific to RO but it might bite you on the backside at some point.

(EvgenyK) #5

synapse uses std winsock library (ws2_32.dll) so seems something may be wrong here because you were able to reproduce this w/o RO

(tobygroves) #6

I’ve found it. If you follow the standard MS instructions to configure Direct Access then it appropriates a large number of ports via this powershell command:

Set-NetNatTransitionConfiguration –IPv4AddressPortPool @(“, 10000-47000”)

We were using a port in this range which was causing the problem. Moving the port we use outside this range or adjusting Direct Access to omit it cured the problem.

Obviously not an RO problem but might prove useful if anyone else comes across the same problem.