You are viewing a plain text version of this content. The canonical link for it is here.
Posted to muse-dev@ws.apache.org by Eitan Plotnik <ep...@cisco.com> on 2008/08/13 15:17:05 UTC

RE: Web Services server behind a NAT router


Hi Chris,

We had an idea to copy the original IP address (from wsa:To in the request)
to the IP Address part in the wsa:Address of the returned EPR. 
This means that the returned address is always accessible - since the client
is the one that sent it in the first place.
This will allow both clients inside and outside the private nat network to
call the web-service. 
For inside clients the private IP address will be returned, and for outside
clients the global IP address will be returned (see implementation below).

Would appreciate any comments for this fix to make sure I'm not missing
anything.

Thanks,
Eitan.


To implement this I've extended SimpleResourceManager and overriden
createResource(String contextPath) method as follows:

public Resource createResource(String contextPath) throws SoapFault {
		Resource resource = super.createResource(contextPath);
		
		
		StringBuffer buffer = new StringBuffer();
		
		// get original wsa:To IP address
		// Mini-platform way to retrieve custom header properties.
		//EndpointReference toEpr =
resource.getEnvironment().getAddressingContext().getToAddress();
		//String originalDestination = toEpr.getAddress().toString();
		
		// Axis2 way to retrieve custom header properties.
        SOAPHeader axiom =
MessageContext.getCurrentMessageContext().getEnvelope().getHeader();
        Element xml =
((AxisEnvironment)resource.getEnvironment()).convertToDOM(axiom);
        xml = XmlUtils.getElement(xml, new
QName("http://www.w3.org/2005/08/addressing", "To", "wsa"));

		
		String originalDestination = xml.getTextContent();
		int originalSlash = originalDestination.lastIndexOf('/');
		
		buffer.append(originalDestination.substring(0, originalSlash));
		
        //
        // substitute the resource type's context path for the one 
        // that was on there originally
        //
        String resourceContextPath = resource.getContextPath();
        
        if (resourceContextPath.charAt(0) != '/')
            buffer.append('/');
        
        buffer.append(resourceContextPath);
        
        //
        // re-set EPR address
        //
        URI addressWithProperEndpoint = URI.create(buffer.toString());        
       
resource.getEndpointReference().setAddress(addressWithProperEndpoint);
		
		
		
		return resource;
	}








Chris.Twiner wrote:
> 
> Hiya,
> 
> I assume that it has an externally resolvable dns address though?  Is
> there a reason you can't use the dns name for it?  Whats used isn't
> resolved (by the server), its just put in the from etc.
> 
> If not and the ip address is the only way to contact it then you're stuck. 
> AFAIK there isn't a solution to that problem, without using a central
> publicly available server, even then I'm not sure Muse would play nicely
> with it (or most ip software for that matter, JXTA excluded).
> 
> cheers,
> Chris
> 
> -----Original Message-----
> From: Eitan Plotnik [mailto:eplotnik@cisco.com]
> Sent: Thursday, July 10, 2008 1:40 PM
> To: muse-dev@ws.apache.org
> Subject: RE: Web Services server behind a NAT router
> 
> 
> 
> 
> Hi Chris,
> 
> Thanks for the prompt reply.
> The issue is that it's dynamic NAT. The server doesn't know the router's
> public IP address.
> The only option we could think of is to get the address from the wsa:TO
> attribute from the client's request, but that seemed wrong.
> 
> Thanks again,
> Eitan.
> 
> 
> 
> 
> Chris.Twiner wrote:
>>
>> Hi Eitan,
>>
>> yes there is a solution, but it requires some coding.  There are
>> functions in AbstractEnvironment :
>>
>>  getDefaultURI() and setDefaultURI()
>>
>> the getter is in turn called by
>>
>>   getDeploymentEPR()
>>
>> which you can override with any uri you want.
>>
>> Of course this means you coding an extra environment.
>>
>> cheers,
>> Chris
>>
>> -----Original Message-----
>> From: Eitan Plotnik [mailto:eplotnik@cisco.com]
>> Sent: Thursday, July 10, 2008 1:29 PM
>> To: muse-dev@ws.apache.org
>> Subject: Web Services server behind a NAT router
>>
>>
>>
>> When a web services server is located behind a NAT router, it returns
>> a private (e.g. non-globally-routable) IP address in the
>> EndpointReference.
>> When the client tries to send a request to the received epr, it fails
>> with destination unreachable.
>>
>> Is there a solution in Apache Muse for such a set-up?
>> --
>> View this message in context:
>> http://www.nabble.com/Web-Services-server-behind-a-NAT-router-tp183808
>> 38p18380838.html Sent from the Muse - Dev mailing list archive at
>> Nabble.com.
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: muse-dev-unsubscribe@ws.apache.org
>> For additional commands, e-mail: muse-dev-help@ws.apache.org
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: muse-dev-unsubscribe@ws.apache.org
>> For additional commands, e-mail: muse-dev-help@ws.apache.org
>>
>>
>>
> 
> --
> View this message in context:
> http://www.nabble.com/Web-Services-server-behind-a-NAT-router-tp18380838p18381040.html
> Sent from the Muse - Dev mailing list archive at Nabble.com.
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: muse-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: muse-dev-help@ws.apache.org
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: muse-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: muse-dev-help@ws.apache.org
> 
> 
> 

-- 
View this message in context: http://www.nabble.com/Web-Services-server-behind-a-NAT-router-tp18380838p18962848.html
Sent from the Muse - Dev mailing list archive at Nabble.com.


---------------------------------------------------------------------
To unsubscribe, e-mail: muse-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: muse-dev-help@ws.apache.org


RE: Web Services server behind a NAT router

Posted by Ch...@swisscom.com.
Hi Eitan,

Sorry for the delay, I think its probably an approach thats tied to your environment.  I've found systems that use dns records to point to servers and a tunneled address through the router are often required for such things.

Often there is no way around dns entries (also for nats usually reverse entries are essential for decent lookup), one for external and one for internal usage.  This also then allows loadbalancing approaches (stonebeat, arrowpoint etc) within the dmz (or nat address in your case).  Where I work you can't ping more than two hops without hitting yet another firewall (or firewalling router).

But given who you work for this is just for others on the list :-)

Because its an environmental thing its difficult to get a generic addressing scheme to work, without resorting to virtual addresses and hole punching techniques like Juxta uses.

Having said that, if this scheme works, I'd stick with it as its simple and therefore probably very effective.

cheers,
Chris

-----Original Message-----
From: Eitan Plotnik [mailto:eplotnik@cisco.com]
Sent: Wednesday, August 13, 2008 3:17 PM
To: muse-dev@ws.apache.org
Subject: RE: Web Services server behind a NAT router



Hi Chris,

We had an idea to copy the original IP address (from wsa:To in the request) to the IP Address part in the wsa:Address of the returned EPR.
This means that the returned address is always accessible - since the client is the one that sent it in the first place.
This will allow both clients inside and outside the private nat network to call the web-service.
For inside clients the private IP address will be returned, and for outside clients the global IP address will be returned (see implementation below).

Would appreciate any comments for this fix to make sure I'm not missing anything.

Thanks,
Eitan.


To implement this I've extended SimpleResourceManager and overriden createResource(String contextPath) method as follows:

public Resource createResource(String contextPath) throws SoapFault {
                Resource resource = super.createResource(contextPath);


                StringBuffer buffer = new StringBuffer();

                // get original wsa:To IP address
                // Mini-platform way to retrieve custom header properties.
                //EndpointReference toEpr = resource.getEnvironment().getAddressingContext().getToAddress();
                //String originalDestination = toEpr.getAddress().toString();

                // Axis2 way to retrieve custom header properties.
        SOAPHeader axiom =
MessageContext.getCurrentMessageContext().getEnvelope().getHeader();
        Element xml =
((AxisEnvironment)resource.getEnvironment()).convertToDOM(axiom);
        xml = XmlUtils.getElement(xml, new QName("http://www.w3.org/2005/08/addressing", "To", "wsa"));


                String originalDestination = xml.getTextContent();
                int originalSlash = originalDestination.lastIndexOf('/');

                buffer.append(originalDestination.substring(0, originalSlash));

        //
        // substitute the resource type's context path for the one
        // that was on there originally
        //
        String resourceContextPath = resource.getContextPath();

        if (resourceContextPath.charAt(0) != '/')
            buffer.append('/');

        buffer.append(resourceContextPath);

        //
        // re-set EPR address
        //
        URI addressWithProperEndpoint = URI.create(buffer.toString());

resource.getEndpointReference().setAddress(addressWithProperEndpoint);



                return resource;
        }








Chris.Twiner wrote:
>
> Hiya,
>
> I assume that it has an externally resolvable dns address though?  Is
> there a reason you can't use the dns name for it?  Whats used isn't
> resolved (by the server), its just put in the from etc.
>
> If not and the ip address is the only way to contact it then you're stuck.
> AFAIK there isn't a solution to that problem, without using a central
> publicly available server, even then I'm not sure Muse would play
> nicely with it (or most ip software for that matter, JXTA excluded).
>
> cheers,
> Chris
>
> -----Original Message-----
> From: Eitan Plotnik [mailto:eplotnik@cisco.com]
> Sent: Thursday, July 10, 2008 1:40 PM
> To: muse-dev@ws.apache.org
> Subject: RE: Web Services server behind a NAT router
>
>
>
>
> Hi Chris,
>
> Thanks for the prompt reply.
> The issue is that it's dynamic NAT. The server doesn't know the
> router's public IP address.
> The only option we could think of is to get the address from the
> wsa:TO attribute from the client's request, but that seemed wrong.
>
> Thanks again,
> Eitan.
>
>
>
>
> Chris.Twiner wrote:
>>
>> Hi Eitan,
>>
>> yes there is a solution, but it requires some coding.  There are
>> functions in AbstractEnvironment :
>>
>>  getDefaultURI() and setDefaultURI()
>>
>> the getter is in turn called by
>>
>>   getDeploymentEPR()
>>
>> which you can override with any uri you want.
>>
>> Of course this means you coding an extra environment.
>>
>> cheers,
>> Chris
>>
>> -----Original Message-----
>> From: Eitan Plotnik [mailto:eplotnik@cisco.com]
>> Sent: Thursday, July 10, 2008 1:29 PM
>> To: muse-dev@ws.apache.org
>> Subject: Web Services server behind a NAT router
>>
>>
>>
>> When a web services server is located behind a NAT router, it returns
>> a private (e.g. non-globally-routable) IP address in the
>> EndpointReference.
>> When the client tries to send a request to the received epr, it fails
>> with destination unreachable.
>>
>> Is there a solution in Apache Muse for such a set-up?
>> --
>> View this message in context:
>> http://www.nabble.com/Web-Services-server-behind-a-NAT-router-tp18380
>> 8 38p18380838.html Sent from the Muse - Dev mailing list archive at
>> Nabble.com.
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: muse-dev-unsubscribe@ws.apache.org
>> For additional commands, e-mail: muse-dev-help@ws.apache.org
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: muse-dev-unsubscribe@ws.apache.org
>> For additional commands, e-mail: muse-dev-help@ws.apache.org
>>
>>
>>
>
> --
> View this message in context:
> http://www.nabble.com/Web-Services-server-behind-a-NAT-router-tp183808
> 38p18381040.html Sent from the Muse - Dev mailing list archive at
> Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: muse-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: muse-dev-help@ws.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: muse-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: muse-dev-help@ws.apache.org
>
>
>

--
View this message in context: http://www.nabble.com/Web-Services-server-behind-a-NAT-router-tp18380838p18962848.html
Sent from the Muse - Dev mailing list archive at Nabble.com.


---------------------------------------------------------------------
To unsubscribe, e-mail: muse-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: muse-dev-help@ws.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: muse-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: muse-dev-help@ws.apache.org