I have a wcf service (with net.tcp binding) hosted at windows service and a wpf client. when I run the service in a server outside the company's domain it works excellent, the problem is when I host the service in a server inside the company's domain, and try to run the wpf app in a client outside of the company domain.
I'm getting the same error, "The Socket connection was aborted..."
I try with Security Mode None, Transport and the same result.
My question is, what is the correct way to do that? I mean host the wcf net TCP service in a domain server and call it from a client outside of domain?
Thanks a lot!
I change the binding from net.tcp to wshttp and the service works fine!
Server with the corporate domain and client without corporate domain
The thing is I need the make this work with net.tcp
Neither a Windows Domain nor DNS have anything to do with WCF/TCP if you don't explicitly make it so.
Assuming the address you gave actually leads to the PC you host your service on (so no local IP addresses) and nothing in between (like a firewall) blocks the connection, it should work.
The correct way is to make sure client and server can talk to each other. If it's different networks, you will need NAT and if one is a corporate network I'd be very surprised to see no firewall that you need to configure.
As a first step, try to ping your target machine from your client machine.
Related
I'm planning on using a wsDualHttpBinding for a WCF service with callbacks. The clients will be a windows form application communicating to the service over the internet. Obviously I have no control over the firewall on the client side, so I'm wondering what is the proper way to set the ClientBaseAddress on the client side?
Right now in my intiial testing I'm running the service and client on the same pc and i am setting the binding as follows
Dim binding As System.ServiceModel.WSDualHttpBinding = Struct.Endpoint.Binding
binding.ClientBaseAddress = New Uri("http://localhost:6667")
But I have a feeling this won't work when deploying over the internet because "localhost" won't translate to the machine address (much less worrying about NAT translation) and that port might be blocked by the clients firewall.
What is the proper way to handle the base address for callbacks to a remote client?
some one tell me if i do not specify ClientBaseAddress then WCF infratructure creates a default client base address at port 80 which is used for the incoming connections from the service. Since port 80 is usually open to firewalls, things should just work.
so just tell me when win form wcf client apps will run then how can i open my custom port like "6667" and also guide me what library or what approach i should use as a result response should come from client side router
to pc and firewall will not block anything. please discuss this issue with real life scenario how people handle this kind of situation in real life. thanks
The proper way is to use TCP transport instead of HTTP transport. Duplex communication over HTTP requires two HTTP connections - one opened from client to server (that's OK) and second opened from server to client. This can work only in scenarios where you have full control over both ends. There is simply too many complications which cannot be avoided just by guessing what address to use like:
Local Windows or third party firewall has to be configured
Permission for application to run - listening on HTTP is not allowed by default unless UAC is turned off or application is running as admin. You must allow listening on the port through netsh or httpcfg (windows XP and 2003) - that again requires admin permissions.
Port can be already used by another application. In case of 80 it can be used by any local web server - for example IIS.
Private networks and network devices - if your client machine is behind the NAT the port forwarding must be configured but what if you have two machines running your application on the same private network? You cannot forward from the same incoming port to two machines.
All these issues can be avoided mostly only when you have control over whole infrastructure. That is the reason why HTTP duplex communication is useful mostly for intranet scenarios and why for example Silverlight offers another implementation where the second connection is not created and Silverlight client instead polls server continuously to check if there is any callback available.
TCP transport requires only single connection from client to server because TCP protocol is natively duplex so the server can call back the client through the same connection. When you deploy a public service you usually have control over infrastructure on the server side so you can make necessary changes in configuration to make it work.
I think this also answers your previous question.
I've a WCF service running just on my laptop. The laptop is connected to the web, IP is static.
What's involved in getting that service consumable by a web user (say I'm in Cyprus and my clients are other in the US), can I restrict users by their IP address?
Please not, I'm aware of WCF support for P2P, but that's not what I'm looking for. The service will be migrated to a proper hosting environment after a while.
I'd let IIS do the heavy work and restrict IPs.
Restrict IP addresses in IIS
Just host the WCF inside a web project and use a dynamic DNS service to pass through to your laptop.
HTH
This is probably a basic networking issue, but I am new to this stuff and just do not know the answer.
I have written a wcf service and client. I can use one of the http bindings and get the service to work correctly when I put my machine's network IP address as the endpoint address and run the client and server from the same machine. Now, I want to be able to connect to this service from a different machine over the internet. Clearly it does not work when I use my network IP address in this scenario, but simply putting in my router's broadband IP address does not seem to be doing the trick, either. Am I just missing a firewall port that I need to open up, or am I trying to do something that should not be possible?
If you want users from the internet to be able to connect to your service, you'll have to consider a few points:
binding: the lowest common denominator is the basicHttpBinding which is SOAP 1.1 with basically no additional features available - just like ASMX webservices. Just about anyone can connect to that. For more advanced clients, you might also want to expose a wsHttpBinding endpoint on your service
security: how (if at all) do you want to secure access to your web service? Do you have username/password credentials that callers must supply? Check out the WCF Security Guidance for a whole slew of information bits on the various security scenarios
authenticating your service: typically, you should strive to make your service authenticate itself to the rest of the world - this requires a server certificate and enables secured communication (messages signed + encrypted) on the wire
make sure your service endpoint(s) is reachable from the internet, through all firewalls and proxies and everything :-)
Hope that helps a bit!
You need to set up port forwarding on your router. Perhaps someone on ServerFault or SuperUser would be able to help you. Or even a google search now that you know what it's called. The instructions will be different depending on the router. The port you need to forward will be the port you've picked in the WCF config file.
I host WCF services through IIS, but it took me ages to work out how. At the moment I put the files on the webserver and enable websharing on the root folder. Then you can assign them to an appropriate Application Pool in IIS, and add a service reference to any client projects using the URL of the wsdl.
I'm not sure if this is the best way to do it but its the only way I've worked out so far.
Here's the simple solution.
I am assuming that you have made a working WCF application and hosted over the IIS.
The next thing to do is to browse the application from the IIS. It will give you url in the address bar something like:
http://localhost/myservice/service.svc
Next go to www.whatismyip.com. this will give you your system's WAN IP (say, 45.34.56.200).
Replace the URL you got in step 2 with: http://45.34.56.200/myservice/service.svc
Now you can use this URL any where in this world to consume your service.
I found a good Article and it is working fine for me, on the following the Main steps:
1-First you should create WCF Service.
2-add application on IIS and give alias for your virtual directory and set path from your local drive.
3-Make sure your default app pool set to .NET CLR V4.0.
4-test your WCF service is running successfully on localhost.
5-To access the same via LAN (Local Area Network) you must disable Firewall for you Private network.
6- try to use ngrok.com, you will get Temp URL to use via internet to access your LocalHost anywhere.
Then Everything will be fine.
For More Information Check the following Link:
https://www.codeproject.com/Tips/813650/Host-WCF-on-LocalHost-and-access-via-Internet
We have created a WCF using net.tcp with an anticipation that the service can work in a firewall that would accept only HTTP port. The client behind firewall can also access it.
Do we need to host the service on a static, public IP so that any client from any network can conect to it?
Ideally, we would like to host the service on a node behind a firewall (say on 192.168.0.199) so that a client on some other network could connect to it.
Please suggest.
Well, either you need to make the service publicly visible somehow - using a public IP, or by routing a publicly visible IP on your corporate firewall to your internal server. But yes - it needs to be publicly visible one way or another.
The other option would be to connect it to the Windows Azure Service Bus - in that case, you could keep it behind the firewall, and just establish a publicly visible IP "in the cloud" that will then route the traffic to your web server.
Marc
I may be off on this but WCF client should have no issues communicating with a WCF server behind a firewall. Even application - level firewalls are OK in this scenario, as long as you configure them to not inspect past layer 4. Do not authenticate or do anything with your traffic at the firewall - simply NAT it to an inside IP address and you should be ok.
Couple of notes: transport security might be a little better to this observer but both transport and message level security in WCF should work without problems through firewalls. If you need message streaming though, then you are stuck with transport level security.
If your firewall (or one of your firewalls) happens to be Microsoft ISA or TMG type device, you may find this helpful: http://www.run-corp.com/how-to-configure-wcf-application-on-microsoft-isa-tmg-firewall/.
I am struggling with a WCF issue relating to name resolution-or something like so. When I consume a wcf service (netTcpBinding) on an application server via a web application on the web server it doesn't work. Ok it doesn't work in most situations. If you access the web application from the web server itself using localhost or 127.0.0.1 it works. However accessing it through the web server via another client machine or accessing the web application locally on the web server using the host name or IP address does not work. In both instances you get a socket connection aborted error.
What makes it more interesting is that switching all the security to 'none' as opposed to 'transport' resolves the issue.
My question is, is it possible to access wcf services using your web server and still use transport security? Or is this a bug/designed behaviour?
Many thanks for any insight,
Steve
The default NetTcpBinding security option is Kerberos / Windows Authentication. If your client and service are not on the same domain it will not work. You may need to look at certificate based authentication.
If you your service is running under a domain account, try changing it to LocalService or NetworkService to see if it resolves the issue.
Transport security typically only works point-to-point - when the client connects directly to the server.
If you have clients that come in from the internet, you have no control over how many intermediary hops they go through - so Transport security, even if you get it to work, will most likely not work at all, e.g. your message might be protected from the client to the first hop, and from the last hop to your server - but not in between hops.
For an internet scenario, typically, Transport security is not a valid option - use Message Security for those cases.
I'm not 100% sure why the connection wouldn't work at all - but in any case, if you're not behind a corporate firewall, I wouldn't be using netTcp with transport security in such a scenario.
Could you please add your server side config (anything inside <system.serviceModel>) to your question to see how you set up Transport security?