NAT, or network address translation, is a function embedded in even the simplest of SOHO routers. Simply put, NAT hides your device’s “real” address from the network by translating this address to a different address for network communications, thereby supplying a measure of security.
The good: NAT is relatively effective as a first line of defense against hackers who might invade your system. While it’s not perfect, it’s pretty darn effective.
The bad: Doing any Web-based functions that require passing the IP address in the body of the message can have problems working through NAT.
The ugly: Applications that depend on H.323 and Session Initiation Protocol often have problems for this exact reason. In our recent testing of various messaging programs, we found varying levels of success when connecting through routers with integrated firewalls. This proved to be especially problematic with MSN Messenger.
Whenever we tried to initiate either application-sharing or whiteboarding with MSN Messenger while connected through our routers with NAT, we received error messages indicating that we were unable to connect due to a SIP error. The genesis of this “error” is that the NAT function was changing the IP address on the packet headers so that we were able to communicate for basic functions. However, the SIP messages (and H.323 messages) also contain references to the IP address within the body of the message. The NAT function does not change the addresses contained within the body of the message.
We were able to make these functions work by bypassing the router, confirming that the NAT function was root of the problem. But then we lost all of the NAT protection. One can also poke holes in the NAT firewall, but this opens the computer to other exploits.
On the corporate level, “session border control” products are quickly emerging to address this problem. But on the SOHO level, we are still looking for an appropriate solution.