- Advisory services
- Consultations
- Network and technology policies
- Network and technology service docs
- Using Jisc community
- Network and technology service docs
- Domain name registration
- How to sign up
- Janet Support Manual
- Janet CSIRT
- Back-up services
- eduroam
- Backup Web Hosting
- Certificate Service
- Connection timeline
- Eligibility
- Janet 3G Buyer's Guide
- Janet 3G eduroam interoperablity authentication methods
- Janet Mail Services
- Janet Network Charges
- Janet Reach
- Janet Videoconferencing Feedback results
- Primary connections
- Supporting Business Continuity
- Business and Community Engagement (BCE) using Janet
- Cost
- Interconnect connections
- Connecting student accommodation
- Customer-owned routing equipment
- Obtaining a Janet IP Address Range
- Terms for the Provision of the Janet Service
- Upgrading your existing bandwidth and Janet router
- Fault reporting
- IP address assignment
- Janet Aurora
- Janet Netsight
- Janet txt
- Routers
- Network set-up
- Guest access
- Network time service
- Training
- Contact
- Primary Nameserver Service
- Secondary Nameserver Service
- Vscene
- Vscene
- Vscene updates and revisions
- Login Options
- Jisc and Ajenta partnership FAQ
- Learn more about Vscene
- Vscene Help and user guides
- Videoconferencing service policies
- ISDN
- Content providers
- Technical documentation
- Technical details
- Technical details
- Ports, IP addresses and Firewall information for Vscene
- Products
- Videoconferencing standards
- Data Sharing within Videoconferencing
- IP Videoconferencing
- Gatekeepers
- Videoconferencing equipment
- Security
- Videoconferencing safety
- Products
- H.323
- Desktop videoconferencing
- IOCOM Visimeet
- Recording
- H.323
- Guide to reliable H.323 campus networks
- H323 Border Traversal
- Live videoconferencing streaming
- H323 Border Traversal
- The H.323 protocol
- Firewalls and ports
- Network Address Translation (NAT)
- Solutions
- References
Network Address Translation (NAT)

NAT should be familiar to network managers – it is widely deployed in large private networks. NAT is described fully in RFC1918 “Address Allocation for Private Internets”. NAT was introduced partly as a means of conserving real or public (also sometimes called 'routable') IP addresses. The deployment of NAT allows large organisations to give every computer a unique Internet address without diminishing the available pool of public IP addresses. It does this by defining a set of addresses that should not be used on the public Internet and should only be used within the private network. Thus these addresses are 'unroutable'. Using NAT in a network also has the potential to add a layer of security – if the addresses within an organisation are not routable from the Internet it may be harder to 'attack' them. By definition, there must be some kind of translation machine between the inner and outer network. Whether this actually helps security is open to debate, but the practice of deploying NAT'd private networks has certainly helped conserve Internet addresses.
NAT is usually overcome by deploying a NAT server at the network boundary, which maintains mappings between private (NAT) addresses and public IP addresses. These mappings may be static (i.e. permanent) or dynamic (i.e. ad hoc and temporary). The problem that NAT presents to a deployment of H.323 is due to the fact that both H.225 messages and H.245 call setup messages bury their network (IP) address deep in the data payload of the IP packet. This payload is examined by the equipment at the other end and the source address within is used as the return address. If the return address is one that is behind a NAT boundary then the packet will never reach its destination, as NAT addresses are unroutable in the public Internet and the call will eventually time-out and fail. A 'naïve' NAT server will only change the addresses in the UDP or IP datagram header and footer, and not alter anything deeper in the protocol stack or in the data payload itself. This explains why H.323 works perfectly well when the two endpoints are within the same network, even when that network is using private (NAT) addresses. As long as the two endpoints have a route to each other then the call will succeed, as the packets exchanged never go beyond their particular NAT domain and so no translation is effected on the IP addresses used.