I've got a working WCF service and a working Delphi client. On a normal PC, they work nicely. On a VM that's "Bridged" they work nicely if I log onto the domain (but not if I logon locally to the VM as administrator). If the VM is NATed, the connection attempt times out.
I would love to hear people's thoughts on what could be making such a difference to whether the client can successfully connect to the WCF service. Bear in mind I'm connecting with basicHttpBinding with no security.
The service is setup to use System Account (interact with desktop is NOT checked), and it starts automatically. The service URI doesn't change, the port is open, and can be telnet'd to in all scenarios.
Any ideas or pointers?
Within the VM, open Internet Explorer and verify that you can view the WSDL of the WCF service. If you can't, then your issue is connectivity and has nothing to do with your Delphi code.
Group Policies and Enterprise Security solutions that swap certificates or require certificates to be registered (we're using a UTM called CyberRoam) make a difference.
Also when Virtual Machines join a domain, their ComputerNames are added to a list maintained by the Domain Controller. When the same Virtual Machine is "moved" or "copied", its ComputerName should be changed to avoid DNS resolution issues.
I'm not claiming this as the definitive answer, however it does explain the issues I noticed in this instance.
Related
I have created a service (WCF) that acts as a backend for a DB. For now it does basic operations such as INSERT, SELECT etc. I have run it locally and now it is time to expose her to the internet and enter 'production'. Is there a best practice to doing so? Bear in mind this service will be hosted on a PC as a Windows Service (not IIS). This is the first time I am putting a Windows Service into production so I am hazy on the details but I think this is the main idea:
On the service: Check for 'rookie' errors such as SQL Injection. Set maximum message sizes to ones marginally higher than the largest message that should be transmitted by my service. Also upgrade self signed X.509 certificate to one issued by a CA. (Where does one store this certificate? Locally on the PC?)
On the PC: Fully patched software (OS etc) and windows firewall with a specific set of rules that allows traffic only on the ports being used (I suppose the safest way to do this is to use the windows tool Allow a program or feature through Windows Firewall ?). Furthermore an updated antivirus running.
On the Network: For the network router, port forward the respective ports being used (the base address is declared as http://localhost:8080 so I guess port 80 for HTTP and 443 for HTTPS? I am using message level Security.)
General precautions: Full message logging on the service to analyze traffic and potential attackers. Also run a Network intrusion detection system such as Snort so that I can sleep a bit better at night.
Am I missing anything obvious? Also should I be hosting in IIS, on security exchange someone said that I would be vulnerable to HTTP attacks if I did not put the code behind a web server. However I have not read this anywhere else
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.
I built a WCF service that exposes itself for a web application, it accepts an object and prints the data on the clients machine. Works fine on my development machine, and the service is up and running on any machine i install it on. I can enter ip address in clients machine web browser and see it is running. Problem is when i send the object to the clients machine it returns an error, that sounds like it could be because of the clients windows firewall. Where would i start at to deal with this problem ?
There was no endpoint listening at http://192.168.1.168:2202/PrintLabel that could accept the message. This is often caused by an incorrect address or SOAP action. See InnerException, if present, for more details.
And the InnerException: Unable to connect to the remote server
With further research and discussion with people in the community i came to understand that as was mentioned at the bottom of this article.
"Self-hosted HTTP addressing for WCF is not integrated into the Windows firewall. An exception must be added to the firewall configuration to allow inbound connections using a particular URL.
But this SO question led me to a page with how to control Windows Firewall through code to enable my WCF self hosted service to accept an object.
This the link below.
http://www.shafqatahmed.com/2008/01/controlling-win.html
That link was towards the direction i needed, but based on user comments it seemed to have some bugs. A colleague found this link and i believe this technique will be the best solution for this scenario.
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