What issues/considerations/workarounds exist when trying to implement H.323 gatekeepers and/or gateways when Network Address Translation is used and calls must be made between endpoints/gateways/gatekeepers in different NAT'd subnets? My understanding is that the IP addresses in the "phone books" inside the gatekeepers/gateways are at a higher layer in the protocols and therefore will not be properly NAT'd. What is being done to address this and what is the workaround at this time?

    Requires Free Membership to View

    Login

Your understanding about NAT related difficulties is partially correct: the issue really arises from the fact that H.323 is an umbrella that supports numerous protocols and transports. If a transport, such as HTTP or RTSP, embeds IP addresses in the payload portion of IP traffic (rather than just in the header), when those packets get segmented or fragmented, that data becomes difficult to track and use.

Your best solution is to contact your gatekeeper or gateway vendor and ask them about the most secure set of protocols to use for H.323 sessions between NAT'd subnets. Unfortunately, such solutions are very much vendor-specific; since I don't want to write a book on the subject I can only give you an injunction to research the matter with your vendor or vendors.

Other possible solutions include:
  • setting up VPN links and punching specific ports through your firewalls
  • working with robust NAT implementations that permit some addresses to be handled (obviously, public addresses are essential) without translation
  • using a dual-homed gateway or gatekeeper and passing traffic through the public (untranslated) address side of the box
  • situating a video-teleconferencing box in your DMZ or on the public side of your Internet interfaces and tunnelling traffic between that box and the private site of your network
  • selecting alternate H.323 compatible transports that don't embed address data in streaming video payloads

Alas, except for the last suggestion, all of these approaches do involve potential security risks, so select any of these with extreme caution and make sure you monitor related ports and services for potential signs of abuse or attack.

One last note: if you're using Port Address Translation (PAT) rather than NAT in any of your applications, you're basically out of luck in this area. Proposed solutions and workarounds for that technology are neither well- understood nor widely implemented because of terrible security risks involved (like opening up large ranges of UDP and TCP ports). Reasonable workarounds or solutions for PAT are beyond me, at any rate.

--Ed--

This was first published in November 2001

Join the conversationComment

Share
Comments

    Results

    Contribute to the conversation

    All fields are required. Comments will appear at the bottom of the article.
    Back to top