This is a commonly encountered problem and there a lot of posts out there on the Greater Google on this, including the solution I am about to tell you. Hopefully this post will add to the solution bandwidth of those experiencing the same issue as I did.
We have a UAT server which is allowed to access the live database. The only explanation I can give you for that is that our Test team are somewhat spoilt. They want to see the effects their changes will make on copies of our real live pages and have convinced management that they must have visibility to up to the second live data and so they do.
The above means that the UAT server uses our PROD Web Services. One fine day after one of our Web Services was updated, it lost connection to the live database. Inspection of the relevant configs showed that the UAT server was wired into the UAT Web Service server (as one would expect) so how it ever accessed PROD database previously I don’t know, but it couldn’t now.
The Engineers informed me that the UAT server lived in a Test Domain with the other test servers and that this domain had a Domain Controller with an ‘A’ record that defined our Web Service URL as pointing to the UAT Server i.e. mywebservice.company.net always resolved to the UAT Web Service server. Hence updating the host file with a record that read “prod_server_ip_address” mywebservice.company.net would never work as it was overruled by the domain controller.
So what the Engies did was take the UAT server out of the Test domain and update the Proxy settings for the server to point to our public Internet Server. They then changed the Firewall Rules to allow Port that our Web Service runs on to get through the firewall (they opened the Port). This then allowed our UAT server to contact the Web Service running on the PROD Web Service server.
Open the ports on your Firewall to allow traffic to the Web Service you need.