INTERNATIONAL TELECOMMUNICATION UNION
ITU-T
Technical Paper
TELECOMMUNICATION
STANDARDIZATION SECTOR
OF ITU
(24 November 2006)
SERIES H: AUDIOVISUAL AND MULTIMEDIA SYSTEMS
Infrastructure of audiovisual services – Transmission
multiplexing and synchronization
HSTP-FNTP
Firewall and NAT Traversal Problems in H.323
Systems
Summary
This technical paper analyzes the problem scenarios created for H.323 systems by the existence of
Firewall (FW) and Network Address Translator (NAT) devices in IP networks.
This document studies the scenarios which are defined in the Technical Paper “Requirements for
Network Address Translator and Firewall Traversal of H.323 Multimedia Systems” and studied in
ITU-T Study Group 16. The Technical Paper attempts to identify the FW/NAT traversal problems
associated with each of these scenarios.
Change Log
This document contains Version 2 of the ITU-T Technical Paper on “Firewall and NAT Traversal
Problems in H.323 Systems” approved at the ITU-T Study Group 16 meeting held in Geneva, 14-24
November 2006.
Version 1 was approved at the ITU-T Study Group 16 meeting held in Geneva, 26 July – 5 August
2005
Editor:
Sasha Ruditsky
RADVISION
New Jersey, USA
Tel: +1 (201) 689 – 6343
Fax: +1 (201) 689 – 6301
Email: sasha@radvision.com
HSTP-FNTP (2006-11) i
Contents
Page
1
SCOPE ..................................................................................................................................................................... 1
2
REFERENCES ........................................................................................................................................................ 1
3
ABBREVIATIONS ................................................................................................................................................. 1
4
STRUCTURE OF THE DOCUMENT.................................................................................................................. 2
5
TYPES OF NAT DEVICES AND THE NESTING OF NAT DEVICES ........................................................... 2
6
FIREWALL DEVICES AND THE NESTING OF FIREWALL DEVICES ..................................................... 3
6.1
7
THE TYPES OF THE IP COMMUNICATION IN H.323 MULTIMEDIA SYSTEMS .................................. 3
7.1
7.2
7.3
8
MAXIMAL CASE ................................................................................................................................................ 4
MINIMAL CASE ................................................................................................................................................. 5
TYPICAL CASE .................................................................................................................................................. 5
PROBLEMS CAUSED BY FW/NAT DEVICES IN H.323 SYSTEMS ............................................................. 6
8.1
8.2
9
APPLICATION LEVEL GATEWAYS (ALGS) ........................................................................................................ 3
GENERIC PROBLEMS ......................................................................................................................................... 6
PROBLEMS SPECIFIC TO FW/NAT TOPOLOGY .................................................................................................. 7
SCENARIOS IN H.323 MULTIMEDIA SYSTEMS ........................................................................................... 9
9.1
9.2
SCENARIOS IN THE SERVICE PROVIDER CONFIGURATION ................................................................................. 9
SCENARIOS IN THE ENTERPRISE CONFIGURATION .......................................................................................... 10
HSTP-FNTP (2006-11) ii
ITU-T Technical Paper HSTP-FNTP
ITU-T Technical Paper
Firewall and NAT Traversal Problems in H.323 Systems
Summary
This Technical Paper analyzes the problem scenarios created for H.323 systems by the existence of
firewall (FW) and Network Address Translator (NAT) devices in IP networks and attempts to
identify the FW/NAT traversal problems associated with each of these scenarios.
1
Scope
This Technical Paper analyzes the problem scenarios created for H.323 systems by the existence of
firewall (FW) and Network Address Translator (NAT) devices in IP networks and attempts to
identify the FW/NAT traversal problems associated with each of these scenarios.
This document studies the scenarios which are defined in the ITU-T Technical Paper
“Requirements for Network Address Translator and Firewall Traversal of H.323 Multimedia
Systems” and studied in SG16. The Technical Paper attempts to identify the FW/NAT traversal
problems associated with various scenarios.
2
References
[1]
ITU-T Recommendation H.323 (2006-06), Packet-based multimedia communications systems
[2]
ITU-T Recommendation H.225.0 (2006-05), Call signalling protocols and media stream
packetization for packet-based multimedia communication systems
[3]
ITU-T Recommendation H.460.17 (2005-09), Using H.225.0 call signalling connection as
transport for H.323 RAS messages
[4]
IETF RFC 3489 (1999), STUN - Simple Traversal of User Datagram Protocol (UDP)
through Network Address Translators (NATs)
[5]
ITU-T Technical Paper HSTP-RNAT (2005-08), Requirements for Network Address
Translator and Firewall Traversal of H.323 Systems
3
Abbreviations
ALG
Application Level Gateway
EP
Endpoint
FW
Firewall
GK
Gatekeeper
IP
Internet Protocol
NAT
Network Address Translator
PER
ASN.1 Packed Encoding Rules
SCTP
Stream Control Transmission Protocol
TCP
Transmission Control Protocol
UDP
User Datagram Protocol
HSTP-FNTP (2006-11) 1
4
Structure of the document
The FW/NAT traversal problems existing in H.323 networks are the result of the way H.323 uses
the TCP/IP protocol and the way the FW and NAT devices are implemented.
This document starts from the description of the types of existing FW and NAT devices and the
barriers created by connecting several NAT and/or FW devices together.
This document then continues with the analysis of the TCP/UDP/IP operations required for the
H.323 protocol functionality. Several H.323 operating modes are analyzed.
The document then discuses the problems related to the specific IP operations used by H.323
systems in the different FW/NAT topologies.
The final section lists the scenarios described in “The Requirements Document” and provides a
mapping of each scenario to the FW/NAT topologies described in the current document.
This document analyzes the H.323 usage of UDP and TCP; the usage of SCTP is for further study.
5
Types of NAT devices and the nesting of NAT devices
Network Address Translators (NAT) devices are network elements which modify the source or
destination IP addresses of the IP packets passing between internal and external networks. The main
purpose of NAT devices is to reduce the number of IP addresses needed to represent an internal
network in the address space of the external network. NAT devices are also used as topology hiding
devices to achieve a particular level of security.
According to RFC 3489, NAT devices can be classified as follows:

Full Cone: A full cone NAT is one where all requests from the same internal IP address and port
are mapped to the same external IP address and port. Furthermore, any external host can send a
packet to the internal host by sending a packet to the mapped external address.

Restricted Cone: A restricted cone NAT is one where all requests from the same internal IP
address and port are mapped to the same external IP address and port. Unlike a full cone NAT,
an external host can send a packet to the internal host only if the internal host had previously
sent a packet to the IP address of the external host.

Port Restricted Cone: A port restricted cone NAT is like a restricted cone NAT, but the
restriction includes port numbers. Specifically, an external host can send a packet, with source
IP address X and source port P, to the internal host only if the internal host had previously sent a
packet to IP address X and port P.

Symmetric: A symmetric NAT is one where all requests from the same internal IP address and
port to a specific destination IP address and port are mapped to the same external IP address and
port. If the same host sends a packet with the same source address and port, but to a different
destination, a different mapping is used. Furthermore, only the external host that receives a
packet can send a UDP packet back to the internal host.
Some networks are separated by several NAT devices. If these NAT devices are connected in such
a way that the external network of one device represents the internal network of the other and if all
the communicating devices are located in the innermost internal network and in the outermost
external one, then the entire chain of NAT devices can be seen as one NAT device belonging to one
of the aforementioned types. Figure 1 illustrates the behaviour of two nested NAT devices; by
induction, it can be shown that a sequence of any number of NAT devices also behaves as a single
NAT device.
HSTP-FNTP (2006-11) 2
Internal
External
Internal
External
Inner
Outer
Outer
Inner
Full Cone
Restricted Cone
Port Rest. Cone
Symmetric
Full Cone
Full Cone
Restricted Cone
Port Rest. Cone
Symmetric
Restricted Cone
Restricted Cone
Restricted Cone
Port Rest. Cone
Symmetric
Port Rest. Cone
Port Rest. Cone
Port Rest. Cone
Port Rest. Cone
Symmetric
Symmetric
Symmetric
Symmetric
Symmetric
Symmetric
Figure 1: The nesting of two NAT devices and their composite behaviour
6
Firewall devices and the nesting of firewall devices
One of the functions of firewall devices is to act as packet filters. The firewall examines each
packet and then:

passes the packet unmodified to the other side;

drops the packet entirely; or

handles the packet in some other way
Firewalls typically base their decisions on the packet’s five-tuple: the protocol value, the source and
destination IP addresses, and the source and destination port numbers.
Connecting several firewalls sequentially creates a new device, which (from the point of view of the
devices communicating through the entire chain of FWs) behaves as a FW with the combined set of
decision rules.
6.1
Application Level Gateways (ALGs)
Some firewalls implement the logic of a particular protocol. They filter and modify the packets
according to the rules of that protocol. Specifically, an H.323 ALG parses H.323 packets and
modifies the firewall rules according to the information gathered from H.323 packets. The firewall
devices implementing a NAT function and acting as an H.323 ALG can also modify addresses in
H.323 packets (inside the PER structures) from their internal values to the external ones.
While solving some of the FW/NAT traversal problems for the cases where different FW/NAT
traversal solutions are not used, an H.323 ALG is used in concert with other types of FW traversal
solutions may actually produce additional problems.
7
The types of the IP Communication in H.323 Multimedia systems
For the purpose of the analysis performed in this section it is assumed that H.323 systems consist of
two H.323 EPs and one or two GKs. If only one GK is used, it serves both EPs. If two GKs are used,
each EP is served by its own GK. A similar assumption is made in [5].
H.323 can use several different modes of operation, i.e. tunnelled vs. separate H.245, H.225.0 over
TCP versus Annex E, direct-routed versus GK-routed signalling, etc. The different modes of
operation have different FW/NAT traversal problems.
HSTP-FNTP (2006-11) 3
This clause lists the various types of communication (IP operations) used by H.323 systems. Three
different cases are presented:

Maximal case: all H.323 modes are supported

Minimal case: only the most FW/NAT friendly mode is supported (i.e. H.460.17’s RAS over a
persistent TCP connection and the GK-routed call signalling with tunnelled H.245).

Typical case: the mode which is believed to be widely deployed mode is RAS over UDP, and
GK-routed H.225.0 over TCP with separate H.245.
7.1
Maximal case
The H.323 standard requires the following types of communication between H.323 entities:

EP to its GK

EP to the peer’s GK

GK to GK

EP to EP
Depending on the placement of the GKs and the EPs relative to the FW/NATs in the network, one
or more types of communication may be problematic.
7.1.1
Communication between the endpoint and its gatekeeper
The following basic TCP/IP operations are normally performed by the H.323 entities and may be
subject to FW/NAT traversal problems (in the following list “well-known” means defined by IANA
and known to FW devices, known a priori means known by some external means to the device
which is going to use it, but not necessarily known to the FW device):

Sending a multicast UDP datagram from the EP to the GK to the well-known address

Sending a unicast UDP datagram from the EP to the GK to the address known a priori

Sending a unicast UDP datagram from the EP to the GK to the address provided by the GK

Sending a unicast UDP datagram from the GK to the EP to the address provided by the EP

Establishing a TCP connection from the EP to the GK to the address provided by the GK

Establishing a TCP connection from the GK to the EP to the address provided by the EP
7.1.2
Communication between the endpoint and the peer’s gatekeeper
The following basic TCP/IP operations are performed by the H.323 entities and may be subject to
FW/NAT traversal problems:

Establishing a TCP connection from the EP to the peer’s GK to the address provided by the
EP’s GK

Establishing a TCP connection from the GK to the EP to the address provided by the EP
7.1.3
Communication between the gatekeepers
The following basic TCP/IP operations are performed by H.323 entities and may be subject to
FW/NAT traversal problems:

Sending a multicast UDP datagram to the well-known address

Sending a unicast UDP datagram to the address known a priori

Establishing of a TCP connection to the address provided by the GK accepting the connection
HSTP-FNTP (2006-11) 4
7.1.4
Communication between the endpoints
The following basic TCP/IP operations are performed by H.323 entities and may be subject to
FW/NAT traversal problems:

Sending a unicast UDP datagram to the address provided by the receiving EP

Establishing a TCP connection to the address provided by the accepting EP
7.2
Minimal case
The previous section defines the communication types required to implement all the possible H.323
operation modes. In the environment where all entities support the most FW/NAT friendly H.323
mode (as defined before) the smaller set of IP operations is required. This clause defines such a
minimum set.
The H.323 standard requires at least the following types of communication between H.323 entities:

EP to its GK

GK to GK

EP to EP
7.2.1
Communication between the endpoint and its gatekeeper
The following basic TCP/IP operations are performed by H.323 entities and may be subject to
FW/NAT traversal problems:

Establishing a TCP connection from the EP to the GK to the address provided by the GK
7.2.2
Communication between the gatekeepers
The following basic TCP/IP operations are performed by H.323 entities and may be subject to
FW/NAT traversal problems:

Establishing a TCP connection to the address provided by the GK accepting the connection
7.2.3
Communication between the endpoints
The following basic TCP/IP operations are performed by H.323 entities and may be subject to
FW/NAT traversal problems:

Sending a unicast UDP datagram to the address provided by the receiving EP
7.3
Typical case
The most widely deployed H.323 networks use the following types of communication between the
entities:

EP to its GK

GK to GK

EP to EP
7.3.1
Communication between the endpoint and its gatekeeper
The following basic TCP/IP operations are performed by H.323 entities and may be subject to
FW/NAT traversal problems:

Sending a unicast UDP datagram from the EP to the GK to the address known a priori

Sending a unicast UDP datagram from the EP to the GK to the address provided by the GK
HSTP-FNTP (2006-11) 5

Sending a unicast UDP datagram from the GK to the EP to the address provided by the EP

Establishing a TCP connection from the EP to the GK to the address provided by the GK

Establishing a TCP connection from the GK to the EP to the address provided by the EP
7.3.2
Communication between the gatekeepers
The following basic TCP/IP operations are performed by H.323 entities and may be subject to
FW/NAT traversal problems:

Establishing a TCP connection to the address provided by the GK accepting the connection
7.3.3
Communication between endpoints
The following basic TCP/IP operations are normally performed by H.323 entities and may be
subject to FW/NAT traversal problems:

Sending a unicast UDP datagram to the address provided by the receiving EP

Establishing a TCP connection to the address provided by the accepting EP
8
Problems caused by FW/NAT devices in H.323 systems
8.1
Generic problems
8.1.1
Discovery of the topology
As described in this document there are several possible FW/NAT topologies between two
communicating entities. Different topologies represent different problems and, as a result, the
topology discovery mechanism may be needed. The solutions for the FW/NAT traversal problem
should provide a means to discover the FW/NAT topology between the communicating entities.
The results of such a discovery should contain information about the:

presence in the communication path of the NAT devices and their type

presence in the communication path of the FW devices

presence in the communication path of the H.323 ALG(s)
8.1.2
Dynamic port allocation
The main role of the firewalls is to restrict the network traffic by allowing only legitimate traffic.
The H.323 protocol uses dynamic port allocation for several of its functions, and any one of the
65535 available UDP and TCP ports may be used by an H.323 device. This makes it impossible to
define the set of rules for filtering the H.323 packets by an H.323-unaware FW device. The
FW/NAT traversal solution should allow the configuration of the FW to enable or disable the H.323
traffic, while not affecting the filtering of the other protocols’ packets by an H.323-unaware FW.
8.1.3
Problems with usage of intermediary devices
The FW/NAT traversal solutions regularly involve the usage of intermediary H.323 devices. While
solving one particular problem, such solutions often create others. This clause discusses these
problems.
8.1.3.1 H.323 ALG related problems
The H.323 ALG is an entity which is not defined by the H.323 standard. This means that its
behaviour in certain situations is not known and/or predictable.
HSTP-FNTP (2006-11) 6
For example, let’s assume that an H.323 entity located behind the H.323 ALG equipped firewall
discovers the H.323 entity’s external address (using for instance the STUN protocol) and uses it in
the H.323 messages. The ALG receiving such messages normally translates internal addresses into
external ones. It is not defined what the ALG behaviour should be when it receives an external
address.
8.1.3.2 Security related problems
Intermediary devices may be required to modify the transport addresses located in the H.323
messages. This may create problems if the communicating H.323 entities use the H.235 integrity
protection mechanisms. In this case, every intermediary device shall be able to digitally sign the
message after it has been modified (which in other words means that every intermediary shall be a
trusted entity).
8.1.3.3 QoS related problems
Every intermediary entity in the media communication path creates an additional media delay, jitter
and increases probability of packet loss. The suboptimal selection of intermediary devices can
create situations where the media packets travel half-way over the globe just to be routed back to
the room next door.
8.2
Problems specific to FW/NAT topology
The following three FW/NAT topologies are possible between two communicating H.323 entities:

Direct connection: there is no FW/NAT device between the two H.323 entities

FW/NAT device: one or more FW/NAT devices with the same orientation (external network of
the previous device is connected to the internal network of the next) are present in the path
between the two H.323 entities

Head to head FW/NAT: each one of the two H.323 entities is located behind one or more
FW/NAT devices. These FW/NAT devices are connected to the same external network
Direct connection, by definition, does not create any FW/NAT traversal problems (not counting the
problem of discovery of the direct connection).
The following clauses describe the problems associated with the two other topologies involving
FW/NAT devices. Each topology contains a description of the problems with performing a
particular IP operation in such a topology. Only the IP operations which are required for the
“typical H.323 case” (as defined above) are discussed.
8.2.1
FW/NAT device between the two H.323 communicating entities
8.2.1.1 Sending a unicast UDP datagram to the external address known a priori
This operation does not create any known problems associated with NAT traversal.
For FW traversal, the operation requires the communication with the specified destination address
to be allowed. Taking into account that such an address is known a priori, this should not create any
particular problems.
8.2.1.2 Sending a unicast UDP datagram to the address provided by the external peer
This operation does not create any known problems associated with NAT traversal.
For FW traversal, the operation requires the communication with the specified destination address
to be allowed. Taking into account that such an address is dynamically allocated by the peer and
that there are no standard defined rules restricting the values which the address can take, this type of
communication creates FW traversal problems.
HSTP-FNTP (2006-11) 7
8.2.1.3 TCP connection established to the dynamic address provided by an external entity
The establishment of TCP connections to the external entity does not create known problems with
NAT devices. Maintaining such connections require some kind of network activity over the
connection happening more frequently then the binding expiration time defined by the NAT device.
Use of the TCP keep-alive mechanism solves this problem, but nothing in the H.323
Recommendation mandates or recommends the use of this mechanism.
For FW traversal, the operation creates the same type of problems as any operation involving
dynamic addresses as described before.
8.2.1.4 Sending a unicast UDP datagram to the internal address known a priori
Only Full Cone NAT devices and the NAT devices allowing static address mapping allow this type
of operation. The rest of the NAT devices require a UDP datagram to be sent in the opposite
direction before this operation.
For FW traversal, the operation requires the communication with the specified internal destination
address to be allowed. Taking into account that such address is known a priori, this should not
create any additional problems.
8.2.1.5 Sending a unicast UDP datagram to the internal address provided by the peer
The NAT devices require UDP datagrams to be sent from the internal to the external address (which
depends on the type of NAT device used) before this operation. In most of the cases which use this
type of operation in H.323 (i.e. RAS messages, RTP/RTCP messages, etc), such a prior message
can be identified. Unfortunately, H.323 forbids usage of the UDP/IP level address from which
message has arrived and instead mandates usage of the corresponding H.323 level field. H.323 also
allows using different addresses for sending and receiving RAS and RTP/RTCP packets, which
adds complexity to this problem.
To allow for the sending of UDP datagrams to the internal address for an extended period of time,
the UDP datagrams from this internal address should be sent periodically to the external address.
For FW traversal, the operation creates the same type of problems as any operation involving
dynamic addresses as described before.
8.2.1.6 Establishing a TCP connection to the dynamic address provided by the internal entity
This operation is normally disabled by NAT devices.
For FW traversal, the operation creates the same type of problems as any operation involving
dynamic addresses as described before.
8.2.2
Head-to-head FW/NAT devices between the two H.323 communicating entities
8.2.2.1 Sending a unicast UDP datagram to the address known a priori
This operation involves sending UDP datagrams to the external network of the first NAT device
and then to the internal network of the second NAT device. As described before, such an operation
is only allowed if the second NAT device is a Full Cone NAT device, or if it allows static address
mapping.
The traversal of both FWs is a question of configuration and of taking into account that the address
is known a priori; hence this configuration should not create additional problems.
HSTP-FNTP (2006-11) 8
8.2.2.2 Sending a unicast UDP datagram to the address provided by the peer
This operation involves sending UDP datagrams to the external network of the first NAT device
and then to the internal network of the second NAT device. Sending UDP datagrams to a dynamic
internal address creates problems, as discussed in clause 8.2.1.5.
In the cases where the second NAT device (the NAT device traversed in the direction from the
external to the internal network) is not a Full Cone NAT device, the direct UDP communication
through head to head NAT devices is impossible. The only known way to enable UDP
communication in this case is through the usage of an intermediary entity placed on the external
network.
For FW traversal, the operation creates the same type of problems as any operation involving
dynamic addresses as described before.
8.2.2.3 Establishing a TCP connection between entities
This operation is normally disabled by the NAT devices in the direction from the external to the
internal network.
For FW traversal the operation creates the same type of problems as any operation involving
dynamic addresses as described before.
9
Scenarios in H.323 Multimedia Systems
The following clause is based on the list of scenarios provided in [5]. For each scenario the section
specifies which FW/NAT traversal topologies defined in clause 8.2 are applied to the
communication between a particular pair of H.323 entities.
9.1
9.1.1
Scenarios in the Service Provider Configuration
Scenario 1 – The endpoints are in the same domain with private addresses
EP to GK – FW/NAT EP – internal, GK – external
EP to EP – direct connection
9.1.2
Scenario 2 – The endpoints are in the different domains with private addresses
EP to GK – FW/NAT EP – internal, GK – external
EP to EP – two FW/NAT head to head
9.1.3
Scenario 3 – One endpoint has public address and another has private address
EP1 to GK – FW/NAT EP – internal, GK – external
EP2 to GK – direct connection
EP to EP – FW/NAT
9.1.4
Scenario 4 – The endpoints are in the same multi-level realm with private addresses
EP to GK – FW/NAT EP – internal, GK – public
EP to EP – direct connection
9.1.5
Scenario 5 – The endpoints are in the different multi-level realms with private
addresses
EP to GK – FW/NAT EP – internal, GK – external
EP to EP – FW/NAT
HSTP-FNTP (2006-11) 9
9.1.6
Scenario 6 – One endpoint is in a multi-level realm with private addresses, another
endpoint is in a realm with private addresses
EP to GK – FW/NAT EP – internal, GK – external
EP to EP – two FW/NAT head to head
9.1.7
Scenario 7 - One endpoint is in a multi-level realm with private addresses, another
endpoint is in a realm with public addresses
EP1 to GK – FW/NAT EP – internal, GK – external
EP2 to GK – direct connection
EP to EP – FW/NAT
9.2
9.2.1
Scenarios in the Enterprise Configuration
Scenario 1 – The endpoints and the gatekeeper are in a realm with private addresses
EP to GK – direct connection
EP to EP – direct connection
9.2.2
Scenario 2 - One endpoint and the gatekeeper are in the same realm with private
addresses, another endpoint is in another realm with private addresses
EP1 to GK – head to head FW/NAT
EP2 to GK – direct connection
EP to EP – head to head FW/NAT
9.2.3
Scenario 3 - One endpoint and its GK are in the same realm with private addresses,
another endpoint and its GK are in another realm with private addresses
EP to GK – direct connection
GK to GK – head to head FW/NAT
EP to EP – head to head FW/NAT
9.2.4
Scenario 4 - One endpoint and its GK are in the same realm with private addresses,
another endpoint and its GK are in the realm with public addresses
EP1 to GK1 – direct connection
EP2 to GK2 – direct connection
GK to GK – FW/NAT
EP to EP – FW/NAT
9.2.5
Scenario 5 - One endpoint and its GK are in different realms with private addresses,
another endpoint and its GK are in a realm with globally unique registered addresses
EP1 to GK1 – head to head FW/NAT
EP2 to GK2 – direct connection
GK to GK – FW/NAT
EP to EP – FW/NAT
HSTP-FNTP (2006-11) 10
9.2.6
Scenario 6 - One endpoint and its GK are in a multi-level realm with private addresses,
another endpoint and its GK are in a realm with globally unique registered addresses
EP1 to GK1 – direct connection
EP2 to GK2 – direct connection
GK to GK – FW/NAT
EP to EP – FW/NAT
9.2.7
Scenario 7 - One endpoint and its GK are in different multi-level realms with private
addresses, another endpoint and its GK are in a realm with globally unique registered
addresses
EP1 to GK1 – FW/NAT EP – internal, GK – external
EP2 to GK2 – direct connection
GK to GK – FW/NAT
EP to EP – FW/NAT
9.2.8
Scenario 8 - One endpoint and the GK are in a realm with private addresses, another
endpoint is in a different multi-level realm
EP1 to GK – FW/NAT EP – internal, GK – external
EP2 to GK – direct connection
EP to EP – FW/NAT
9.2.9
Scenario 9 - One endpoint and its GK are in a realm with private addresses, another
endpoint and its GK are in a different multi-level realm
EP1 to GK1 – direct connection
EP2 to GK2 – direct connection
GK to GK – head to head FW/NAT
EP to EP – head to head FW/NAT
9.2.10 Scenario 10 - One endpoint and its GK are in a realm with private addresses, another
endpoint is roaming outside of the enterprise realm
EP1 to GK – direct connection
EP2 to GK – FW/NAT GK – internal, EP – external
EP to EP – FW/NAT
9.2.11 Scenario 11 - One endpoint is roaming outside of the enterprise realm, its GK is in a
realm with private addresses; another endpoint and its GK are in a realm with
globally unique registered addresses
EP1 to GK1 – direct connection
EP2 to GK2 – FW/NAT GK – internal, EP – external
GK to GK – FW/NAT
EP to EP – direct connection
___________________
HSTP-FNTP (2006-11) 11