Bottom Line: Firewalls perform NAT. NAT and video conferencing standard protocols were initially incompatible. Solutions arose and exist for video conferencing to work through firewalls that perform NAT. Some solutions include advanced firewall capabilities, some involve systems installed in DMZ networks, some include all of the above. As usual in IT and networking technology, implementations of standards across vendors may vary, and feature compatibility and performance impact should be thoroughly analyzed.
As covered in a previous post, RFC 1918 was released even before Network Address Translation was a mature technology. However, the need for entire enterprises with hundreds to thousands of users to share small ranges of globally unique IP addresses made the technology indispensable.
A typical technology evolution process brought about more capabilities and flexibility when implementing NAT through firewalls, starting from simple configurations of translation pools (address ranges or “pools” of numbers), to now managing multiple address ranges on the “inside” and “outside” and DMZ networks, zones, routing capabilities, etc.
“Application aware” firewalls represent the culmination of the evolution, and identify applications like video conferencing, voice over IP, streaming video, etc, and process traffic accordingly. However, the vast majority of installed firewalls are not yet application-aware, and configurations have to be set for features and applications like video conferencing to function. And, even application-aware firewalls will require rule and policy customization depending on installed or planned video conferencing solutions.
Video Conferencing and NAT
NAT primarily works at Layer 3 of the OSI model–the Network Layer. Most notably, NAT changes the source address of the outgoing packet to a “globally unique” IP addresses before forwarding to the Internet.
IP Video conferencing equipment, endpoints and systems primarily use the H.323 protocol, which was established to facilitate multimedia functionalities. H.323 brought several other protocols together that were in use throughout the global telecommunications infrastructure into one specification for video, audio, static image (presentations on a second screen, for example), signalling, security, control and more. The Session Initiation Protocol (SIP) development began at around the same time, originally with an “invitation” (to a conference) focus, is similar, but accomplishes some important functionalities differently. Let’s explore H.323 Firewall traversal first:
Video Conferencing, H.323, and NAT
H.323 was also defined when most corporate communications were conducted on a mix of private network bandwidth and public switched telephone networks. For a myriad of reasons, the International Telecommunications Union (ITU) defined H.323 with its own header separate from the IP header. The H.323 header includes the source IP address of the conferencing endpoint or system. Conferencing worked fine on private networks in which all routers had route entries to all internal destinations. Issues arose when trying to conduct IP video conferences via Internet bandwidth, as firewalls universally performed NAT.
While the IP header changes during a NAT firewall traversal, the H.323 header remains intact, with the original, internal, private source IP address. Remote H.323 endpoints or systems respond according to their audio or video conferencing function to the IP address within the H.323 header. However, the remote networks had no idea how to route to that embedded H.323 source address, since it was a private address within the distant network.
Manufacturers implemented methods to resolve problems caused by NAT. One such example was incorporating the ability to define the public-facing external IP address as their “H.323 address” so the remote network would return traffic across the Internet to the appropriate corporate network firewall. The H.323 source IP had to be manually configured in the conferencing equipment, and network teams had to define static NAT entries in firewalls to ensure videoconferencing packets were always assigned particular globally unique IP addresses.
Conferencing also required firewall administrators to open wide ranges of TCP ports in firewalls, increasing vulnerability to Internet-based attacks. Network and Security teams then had to craft specific permissions, for example, opening the TCP ports for specific host IP addresses, which they subsequently locked down through access-lists.
This worked well when the usage model consisted of one or two conferencing endpoints in an office, but consumes too many of a company’s globally unique IP addresses after modest expansion. IPVersion4 IP addresses are a precious commodity, only available in small ranges from ISPs at this point.
Solutions called “video conferencing gatekeepers” arose that managed the interfaces between several internal conferencing endpoints and one external-facing connection. These shouldn’t be confused with video conferencing “gateways” which provide connections to ISDN and IP networks for conferencing interoperability. This functionality persists as a component of full-featured self-hosted solutions from all vendors.
H.460 NAT Firewall Traversal
The ITU published a “recommendation” which has become a standard for how to handle Real Time Protocol, RTP, and several related protocols, through devices that perform NAT. In fact, the title of the standard is “Traversal of ITU-T H.323 media across network address translators and firewalls.” (You can download the pdf from this ITU website.)
The standard defines how video conferencing data sessions are set up, maintained, and “torn down” through devices that perform NAT. It is important to note that the standard doesn’t define a “black box” of sorts that could do everything for you, nor how to create one. The standard takes the form of defining datagrams, signalling handshakes and flow, and how messages are considered and acted upon by the various components in an end-to-end video conferencing implementation.
In fact, the aforementioned gatekeepers make use of H.460 standards to initiate and keep sessions active through firewalls.
“Application-aware” firewalls can perform H.460 functions. Firewall technology evolution has has brought about their ability to perform “deep packet inspection” and perform NAT on the H.323 and Session Initiation Protocol (SIP) headers within packets. “Deep packet inspection” simply describes the process of analyzing many more bits of a packet to read and process application header information such as the H.323 source IP.
Firewalls can manage multiple h.323 or SIP conferencing sessions simultaneously while minimizing the number of TCP ports that they open, conserving external IP address usage and addressing Security concerns. However, these extra processing tasks prevent firewalls from using rapid forwarding algorithms for video conferencing traffic. Rapid forwarding decision algorithms make many assumptions based on minimal information in the first bits of the IP header.
Having firewalls perform H.460 functions may not be desirable if their processing capacity does not match the extra demand. After all, firewall performance affects everyone’s use of the Internet. You should analyze the impact of enhanced features such as H.460 on overall firewall performance before rolling it out to your network.
The standard allows for legacy “client” systems to communicate through a “client proxy” through a NAT device to other systems that employ H.460 standards. Most high-end self-hosted video conferencing systems include gatekeeper functionality in either software or appliance form. A gatekeeper in the DMZ offloads processing and signalling tasks from the firewall.