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?
Related
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.
Enviroment
Consider the following production environment setup for a web application:
End user --Internet--> web server in DMZ --Firewall--> WCF hosted on app server --> DB Server
Constraint:
Also consider that we cannot change anything from the infrastructure point of view. For example, open ports, change any firewall setting etc.
Problem:
We want to expose the WCF, which is hosted on the app server, to external clients. We are trying to solve this as follows:
End user --Internet--> Router WCF in DMZ --Firewall--> WCF hosted on app server --> DB Server
Please note that we cannot establish a db connection from the DMZ environment where the WCF needs to be hosted so that the external clients can consume it. We have developed a "Router WCF" which passes through all messages to the internal WCF and vice-versa.
This solution adds an unnecessary overhead of serializing and de-serializing data. There must a better and proper way of doing this. We are looking forward to the community for guidance. Thank you.
In DMZ the bibliography tells you: always create an intermediate layer. This means another machine on the internet will be the point of connection and it will proxy the connection back to WCF.
The machine is the web server you seem to mention, that is stupid, has no data, and (to be a proper DMZ) has a firewall between it and all the machines (WCF and the others) it serves that permits only IP:PORTS used on such machines.
In this scenario, usually Apache on the public web server with a URL-rewrite rule (i.e if it is /x/y send it to servera.internal.com:9900 - if it is /x/z send it to serverb.internal.com:9901 etc...) is enough, but there are plenty of solutions of course.
It seems you are doing exactly this, why do you say it is not the proper solution?
DMZs could seem a bit dated as protection mechanism (I agree) but you have to think when servers like your WCF machine had dozens of ports opened, and you wanted to lower the risk of random ports on web-facing machines, a giant attack surface. Nowadays everything can work with couple of ports opened, so it can seem "silly" to do all of this just to forward a TCP port. But it is still valuable as (for example) if servers behind the web server in DMZ do not have internet access, even when WCF is compromised, the attacker cannot use its own reverse shell to deploy what it is nowadays called an APT (yesterday backdoor). The attacker "won't see" his own machine from WCF as the DMZ provides the connection to the external world.
Summary:
Does anybody know if there are known issues or configuration gotchas with an IIS service connecting to an Azure based service?
Scenario:
I currently have a scenario that requires me to host two web-services, one in Azure, and one on a server running IIS. The IIS hosted service (a WCF service) connects to the Azure hosted service (actually the Azure storage API) in order to fetch certain information. This information is manipulated and returned to the client.
Client -> IIS Service -> Azure Storage Service
Issue:
I'm running into issues with the IIS service connecting to the Azure Service. The hostname cannot be resolved. I'm using the Azure Storage client from my code, but have actually tried this using the azure API calls, and they also do not work from IIS. I captured the requests using Fiddler (on a different machine), they match the azure REST API calls, as expected. These requests, when made outside of IIS on the host machine execute properly. It is only when they are issued by the IIS service that they fail.
In my research other people have been running into this issue when there's a firewall problem, but since I can hit the service properly from the machine, that doesn't seem to fit the bill. My hunch is that there's a configuration issue I need to sort out in IIS, but I've failed to find anything useful with my searches.
Does anyone have any information on why this might be occuring (known bugs, gotchas etc)? Any workarounds? From a SOA perspective, this seems fairly critical to understand.
Any assitance anyone has would be helpful. Thank you.
Sounds like a proxy configuration issue. Check how your IIS server connected to Internet. If you are using some sort of proxy to get to Internet, that connection has to be configured correctly.
Specifically, if your proxy servers are Microsoft ISA server, or Microsoft Forefront TMG, then you need to check two things:
ISA server client or Forefront TMG client software is installed on the server
The account used by IIS application pool is domain user. ISA Server/TMG are designed to work only with user account, not service account. Alternative workaround for this limitation is using "defaultProxy" configuration in web.config, however it only wokrs for HTTP/HTTPS.
If you use different proxy server, then other issues might be involved, for example proxy might require authentication.
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/.