Connection refused - nettcp WCF Service from work - client connecting over VPN

Question

Here's the scenario: A client machine has connected to the 'Work network' via VPN (Cisco VPN Client). The work network hosts a machine that has a WCF service with nettcp binding. The client tries to connect to this service and gets an exception as follows:

Could not connect to net.tcp://workMachine:2010/SomeService. The connection attempt lasted for a time span of 00:00:01.3180754. TCP error code 10061: No connection could be made because the target machine actively refused it workMachine:2010.

Things I tried:

1. Changed the Workgroup of the client machine to the work network workgroup
2. Added domain/username/password for the Windows Networking Password vault, so that it can be used to connect
3. Changed the wcf service path with an IP address instead of the workMachine name
4. Checked client machine firewalls and added to allow the wcf client through it

All above failed and didn't work. Has anyone encountered similar issues?

The client machine is on Windows 7

SecurityMode of the WCF service is set to NONE - so that shouldn't be an issue.

Any insights will be helpful

Answer 1

You may need to supply client credentials explicitly through your proxy object.

Assume that the proxy object in the code below implements one of the ClientBase interfaces.

proxy.ClientCredentials.Windows.ClientCredential.UserName = "clientaccount";
proxy.ClientCredentials.Windows.ClientCredential.Password = "S3cr3t1337Pwd";

Answer 2

Could you - just for testing purposes - expose the same service on the same machine using a HTTP endpoint, and try to connect to that one from your VPN client?

NetTcp is an excellent choice behind the corporate firewall - just don't know how the Cisco VPN client might cause troubles here, that might not show up when using an http-based protocol. Just a wild guess for now, but if you have nothing else to go on, give it a try!

Marc

Answer 3

Just another thought to assist with debugging of these kind of issues, using CMD execute "netstat -a" (you can append the -o switch and find the related process id also) and see if the port in question is currently open, if it isn't you may have an issue with the SMSvcHost.exe (this is the Windows process for managing an IIS hosted TCP Service).

I've had this issue before and rectified it by restarting the following services (obviously you'll need to carefully consider this if you are dealing with a live production system):

NetTcpActivator (Net. Tcp Listening Adapter) NetTcpPortSharing (Net. Tcp Port Sharing Service)

and possibly if relevant:

NetMsmqActivator (Net. Pipe Listener Adapter) NetPipeActivator (Net. Pipe Listener Adapter)

Hope this helps someone!

J.