WK,(((,QWHUQDWLRQDO&RQIHUHQFHRQ&RPPXQLFDWLRQ7HFKQRORJ\3URFHHGLQJV

A Method for Accessing Web Services Behind

Network Address Translators (NATs)

Wenhao Lu, Xi Zhou*, Yingxiao Xu, Yinsheng Li, Weiwei Sun

School of Computer Science
Fudan University
Shanghai, P.R.China 200433
{062053036, zhouxi, xuyx, liys, wwsun}@fudan.edu.cn

Abstract—Due to some reasons, quite a lot of Web Services are

running inside private networks behind Network Address
Translators (NATs), which makes it difficult for consumers to
directly access the services. In this article we propose an indirect
method for accessing web services behind NATs.
Keywords-Web Services; NAT traversal;
I. INTRODUCTION
A Web Service is a software system designed to support
interoperable machine-to-machine interaction over a network
[1]. As the need for interoperability and application-to-
application communication grows, the use of web services is
expanding rapidly in recent years.
In the mid-1990’s Network Address Translation (NAT)
became a popular tool for alleviating the IPv4 address shortage.
The illusion of anonymity (private IP addresses) and
inaccessibility of the internal hosts behind a NAT device is not
a problem for application such as web browser, which only
need to initiate outgoing connections. This illusion of
anonymity and inaccessibility is sometimes perceived as a
privacy benefit. Nevertheless, hosts behind NAT-enabled
routers do not have end-to-end connectivity and cannot
participate in some Internet protocols. Services that require the
initiation of TCP connections from the outside network, or
stateless protocols such as those using UDP, can be disrupted.
Unless the NAT router makes a specific effort to support such
protocols, incoming packets cannot reach their destination.
Most Web Services running on publicly addressable hosts
can be easily consumed. However, serious lack of IPv4 address
space results in Network Address Translators (NATs). The
present-day Internet has seen ubiquitous deployment of NATs
and quite some Web Services are running inside private
networks behind NATs. Without publicly routable IP addresses,
these services cannot be accessed directly.
There are a variety of NAT devices and a variety of
network topologies utilizing NAT devices in deployments.
According to different situations and application scenarios,
different solutions are adopted to traverse NATs. Many
techniques exist for NAT traversal, but no technique works in
every situation since NAT behavior is not standardized.
II. CURRENT NAT TRAVERSAL APPROACHES
A. NAT Traversal Protocols and Techniques Based on NAT
Behavior
x Simple Traversal of UDP over NATs (STUN) [2]: A
standards-based IP protocol used as in applications of
real-time voice, video, messaging and other interactive
IP communications. The protocol requires assistance
from a 3rd-party network server.
x Traversal Using Relay NAT (TURN) [3]: A protocol
that allows for an element behind a NAT or firewall to
receive incoming data over TCP/UDP connections. It
is most useful for elements behind symmetric NATs [2]
or firewalls that wish to be on the receiving end of a
connection to a single peer.
x UDP hole punching [4]: A method for establishing
bidirectional UDP connections between Internet hosts
in private networks using NAT. The technique is
widely used in P2P software and VoIP [5] telephony. It
is one of the methods used in Skype [6] to bypass
firewalls and NAT devices. It can also be used to
establish VPNs [7].
x TCP hole punching [4]: Extended from UDP hole
punching, albeit with much less success.
B. NAT Traversal Based on NAT Control
x NAT Port Mapping Protocol (NAT PMP) [8]: An
Internet Engineering Task Force (IETF) Internet Draft.
It allows a computer in a private network (behind a
NAT router) to automatically configure the router to
allow parties outside the private network to contact
itself.
x Universal Plug and Play (UPnP) [9]: A set of protocols
aims to allow devices to connect seamlessly and to
simplify the implementation of networks in the home
and corporate environments.
x Application Layer Gateway (ALG) [10]: consists of a
security component that augments a firewall or NAT

This research is supported by the National High-Tech Research and

Development Plan of China under Grant 2006AA01Z234
üüüüüüüüüüüüüüüüüü
978-1-4244-2251-7/08/$25.00 ©2008 I E E E


 WK,(((,QWHUQDWLRQDO&RQIHUHQFHRQ&RPPXQLFDWLRQ7HFKQRORJ\3URFHHGLQJV
Main Internet
NAT NAT
(202.120.224.18) (222.72.255.192)
Private Private
Network Network
Web Service Consumer Web Service Provider
(10.132.142.8) (10.68.5.28)
Figure 1. A common case scenario.
employed in a computer network. It allows customized
NAT traversal filters to be plugged into the gateway to
support address and port translation for certain
application layer protocols.
C. NAT Traversal Combining Several Techniques
x Interactive Connectivity Establishment (ICE) [11]:
Provides a mechanism for NAT traversal using various
techniques.
Most of the above techniques cannot meet our need for
accessing Web Services behind NATs because none of them
are born to do it. Consider the scenario in Fig. 1. Service
consumer and service provider both have private IP addresses
and lie behind different NAT devices. Hole punching technique
doesn’t work here because usually we can’t expect a consumer
to initiate a connection with a rendezvous server and the
technique requires the NATs to be EIM-NATs [4]. Also UPnP
is not a good choice either since some operating systems don’t
support UPnP or in many cases, the UPnP function is turned
off by network administrators. For accessing Web Services
behind NATs, we here present a new method as follows.
III. OUR APPROACH
Our Approach is somewhat like TURN. In this approach,
we introduce a public addressable Host S as a broker that will
help the consumer access the service. See Fig. 2 (We don’t care
whether the consumer is behind a NAT). In Fig. 2 the
consumer from Host A wants to access the Web Service
running on Host B (Service B). Host S runs a broker service
(also a Web Service – Service S) that consumes Service B for
the consumer.
A. Connect the Service Provider with a Broker
Host B initiates a connection to Host S. (This step can be
omitted if Server S happens to be the gateway of the private
network where Server B lies.) It’s a client/server connection.
Service S will consume Service B on behalf of the consumer
on Host A through this connection. The connection can only be
initiated by Host B.
B. Create and Register the Service
Create Service B (with Host S’ information in its
description) on host B and Register it in a UDDI registry.
Without a publicly addressable IP address, something must
be added to the description (WSDL file [12]) of Service B. We
add Service S’ WSDL file’s URI to the “documentation”
element of Service B’s WSDL file. So the “documentation”
element of B’s WSDL file should look like this:
<documentation>
<![CDATA[
Service S’ WSDL file’s URI
]]>
</documentation>
C. Service Discovery
The consumer from Host A may look up a service it needs
from a certain UDDI [1]. It gets the description of Service B.
Service B’s WSDL file is parsed by a program on Host A.
The program first checks the “documentation” element. If there
is a CDATA section inside the element, Host A will know that
Service B is behind a NAT and the program will get Service S’
WSDL file according to the URI. Then the program generates
a SOAP message [13] based on Service S’ WSDL file and
input parameters from Host A. When SOAP connection is
created between Host A and Host S, Service S can be
consumed.
D. Call the Broker
The consumer notices that Service B is behind a NAT
device and it can be accessed through a broker service –
Service S on Host S. So the consumer calls the broker.
Service S has two input parameters. One is the URI of
Service B’s WSDL file, the other is a set of input parameters
from Host A. Service S returns what Service B returns. Service
S gets the SOAP message from Host A. After receiving this
message, it’s Service S’ job to send a SOAP message to Host B.
This SOAP connection may not work if the NAT of Host B is a
non-EIM-NAT [4]. We can run a program on S to capture that
SOAP message heading toward Host B and send this message
as a raw XML file through the connection established between
Host B and Host S earlier. Later, Host B will resend this
message through its local SOAP connection to Service B.
E. Consume the Service behind NAT
Through the connection already established, Service S
consumes Service B and gets Service B’s return value(s) as its
own return values.
F. Return Value(s) to the Original Consumer
The consumer on Host A gets the return value(s) from
Service S.

 WK,(((,QWHUQDWLRQDO&RQIHUHQFHRQ&RPPXQLFDWLRQ7HFKQRORJ\3URFHHGLQJV
Figure 2. Architechture of our approach.
IV. EXPERIMENTS
In fact, Service B is part of a service composition, which is
maintained by School of Computer Science, Fudan University
in Shanghai. Like service B, many services of this service
composition are behind NATs. And for some reasons, we have
to access all the services of the service composition from
Beijing. And that’s why we’re working on NAT traversal for
Web Services in the first place. We did two experiments.
First we use three hosts interconnected by a LAN switch to
do the experiment. One of the hosts is installed with a Virtual
Machine and the Web Service is running on this virtual
machine. Two of the hosts are Windows 2000 and another one
is Fedora 5 Linux. We use Java Web Services Developer Pack
2.0 to parse WSDL files and to send SOAP messages. Our
approach worked. We successfully consumed Service B behind
NAT.
Then we put our method into practice to meet our real
needs. We used two different NAT devices. A consumer in
Beijing successfully called a Web Service behind NAT in
Shanghai. We did more tests. Most services of the service
composition must be consumed in turn. Services deployed on

publicly addressable hosts are accessed without broker server
automatically. The average response time for consuming
services behind NATs is below 3 seconds and the worst case is
5.573 seconds.
V. CONLUSION AND FUTRUE WORK
We provide a new method to access Web Services behind
NATs. This method works for almost all type of NAT devices.
Services need broker servers to make them available on main
Internet. This method can be adopted when NAT traversal
based on NAT control cannot work.
The broker server in our method is doing the relaying job.
One disadvantage of the method is that it consumes the broker
servers’ processing power and network bandwidth. There is a
number limitation of broker services that can be deployed on
broker server. The tradeoff must be balanced.
In some situations a service behind NAT may be consumed
continuously by a single consumer. It would be better if a
direct connection between the consumer and the service can be
established with the help of a broker server. We will try to
improve this method to make it work more efficiently.
REFERENCES
[1] W3C Web Services Architecture, http://www.w3.org/TR/ws-arch/
[2] Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy, “STUN –
Simple Traversal of User Datagram Protocol (UDP) Through Network
Address Translators (NATs)”, RFC3489, March 2003.
[3] Rosenberg, J., Mahy, R., and P. Matthews, "Traversal Using Relays
around NAT (TURN): Relay Extensions to Session Traversal Utilities
for NAT (STUN)", Work in Progress, January 2008.
[4] P. Srisuresh, B. Ford, D. Kegel, “State of Peer-to-Peer (P2P)
Communication across Network Address Translators (NATs)”,
RFC5128, March 2008.
[5] D. Collins, Carrier Grade Voice Over IP (second edition). McGraw-Hill
Professional, 2002.
[6] http://www.skype.com.
[7] B. Gleeson, A. Lin, J. Heinanen, T. Finland, G.Armitage, A. Malis, “A
Framework for IP Based Virtual Private Networks”, RFC2764, February
2000.
[8] Cheshire, S., Krochmal, M., and K. Sekar, “NAT Port Mapping Protocol
(NAT-PMP)”, Work in Progress, October 2006.
[9] UPnP Forum, “Internet Gateway Device (IGD) Standardized Device
Control Protocol V 1.0”, November 2001,
http://www.upnp.org/standardizeddcps/igd.asp
[10] P. Srisuresh, M. Holdrege, “IP Network Address Translator (NAT)
Terminology and Considerations” (refer section 2.9), RFC2663, August
1999
[11] Rosenberg, J., “Interactive Connectivity Establishment (ICE): A
Methodology for Network Address Translator (NAT) Traversal for
Offer/Answer Protocols”, Work in Progress, October 2007.
[12] W3C Web Service Description Language (WSDL) Version 2.0 Part 0:
Primer, http://www.w3.org/TR/2007/REC-wsdl20-primer-2007062
[13] W3C SOAP Version 1.2 Part 0: Primer (Second Edition),
http://www.w3.org/TR/2007/REC-soap12-part0-20070427/