When I recently put a bunch of Microsoft Web Service Enhancements (WSE 2.0) services to the test across an Internet based connection I was in for a surprise…
I hadn’t counted on the problem of trying to configure WSE to work behind our “Gateway to the Internet”, the Network Address Translation (NAT) router!
Our office LAN sits behind a router/firewall which ‘protects’ it from the 2Mbit broadband Internet pipe. All but the necessary TCP/IP ports are blocked and all workstation machines are running Windows XP Service Pack 2 with the firewall enabled.
The preliminaries to getting it all running include the usual:
1) Opening up the relevant TCP/IP port on the firewall. (The default port for the soap.tcp transport is 8081)
2) NAT mapping of the router port 8081 to the test server or workstation’s port 8081.
3) If using Windows XP SP2 as a test machine, then add the service host application to the list program exceptions for incoming network connections in Windows Firewall.
And this is where it gets a little tricky…
A problem arises from the fact that the external IP address belongs to the router and not the machine which is hosting the service. This machine hosting the service has its own internal IP address which is not visible from the outside.
But WSE doesn’t allow binding a SoapService to an IP address that is not local to the machine. i.e. you cannot bind to the router’s IP address, you can only bind to a address such as localhost.
If you try, you get the following error: WSE813: The following transport address could not be mapped to a local network interface: soap.tcp://<RouterIPAddress>.
Furthermore if you bind your SoapService to localhost then all incoming network connections that originate from the local network are received by WSE and are served correctly. Incoming connections that originate from outside the firewall however are addressed to the router. Since the router (using NAT) is configured to map these incoming connections to the internal machine which is hosting the service, the message is indeed routed to the correct host application…
But upon receiving these external messages WSE rejects the request and reports “Destination Unreachable” back to the client. The reason for this is simple, WSE uses WS-Addressing and the wsa:To address is not referencing this machine, its referencing an endpoint on the router.
After some investigation, trial and error and finally common sense, the answer was quite simple, employ the use of WS-Addressing’s wsa:Via as follows.
Register the SoapService using a logical name such as “MyService” and a Via: specifying the IP address of the machine hosting the service:
MyService service = new MyService();
Uri logical = new Uri("urn:MyService");
Uri via = new Uri("soap.tcp://<ServiceHostIPAddress>");
EndpointReference epr = new EndpointReference(logical, via);
SoapReceivers.Add(epr, service);
On the client you do something similar except specify the router’s IP address:
public class MyClient : SoapClient {
public MyClient() : base(
new EndpointReference(
new Uri("urn:MyService"),
new Uri("soap.tcp://<RouterIPAddress>")) {}
}
Easy as that!