|
|
![]() ![]() Network Address Translation: Hiding in Plain Sight |
|
Using PAT on a public network, TCP and UDP traffic appears to come from a single address. The advantage is clear for SOHO (small office/home office) setups and remote medium-sized offices that are connecting to the Internet via an ISP: If you're using a remote-access device that supports PAT, a single IP address is all that you need for your entire network. In fact, many SOHO remote-access devices support dynamic IP address assignment via PPP. Your ISP need not support your NAT and in fact will be unaware of it. If you ever switch to a different ISP, you won't have to change your IP networking. Obviously, there is a trade-off when you have multiple users sharing a modem or ISDN BRI link, but the savings in both ISP charges and management are well worth it.
With NAT-based load-balancing, the router or NAT device charged with load-balancing relates multiple private-destination IP addresses to a single public IP address (see "NAT-Based Load-Balancing," below). Each subsequent TCP connection request is sent to the next private IP address in the NAT. NAT simplifies load-balancing by eliminating the need to change DNS tables. In addition, the cached DNS requests on client machines won't alter the load-balancing, unlike DNS round-robin. But of course, NAT load-balancing will only work with NAT, not PAT. Security Issues Whenever you alter IP addressing, you need to think carefully about the impact on any security scheme you have in place. For example, firewalls use IP addresses, along with TCP port numbers, destination addresses and sometimes other information in the IP header, to decide whether or not to block network traffic. Depending on where you place your NAT device, you may have to alter your firewall rules, because NAT changes the source or destination addresses, depending on direction. If a NAT device, such as an internal router, is placed on the protected side of the firewall, you will have to change any firewall rules that govern traffic flow to and from the private network behind the NAT device. In many setups, NAT is implemented on the firewall, providing control of both access to the network and address translation. You should not place the NAT outside your firewall unless you can tightly restrict which network connections are translated. Any mischievous hackers who can fool the NAT into thinking they have a legitimate connection will be able to access your network as if they were authorized users. If your enterprise is stepping out to the edge of networking technology and implementing a virtual private network (VPN) using IPSec (IP Security), misplacement of the NAT will break your VPN. Essentially, you need to place your NAT device on the protected sides of the VPN, not in the middle, because NAT changes the IP address field of the IP packet, one of the untouchable fields in the IPSec header. IPSec secures the entire packet so you know which station sent the original packet. If the IP address is changed, security will be defeated because the original address has been altered. The packet then could be falsified. Although NAT offers a variety of benefits, such as removing the need to renumber your network, reducing the costs of ISP accounts and providing better load-balancing, NAT's potential threat to some management and security functions demands that you always use caution when rolling it out. Send your comments on this article to Mike Fratto at mfratto@nwc.com. |
|
|
SID Stalking: Cloning Windows NT By Jonathan Feldman Print This Page E-mail this URL |



Up to this point, we have talked about using NAT and PAT to make registered addresses available for use by workstations with unregistered addresses. Another interesting use of NAT is as an alternative to DNS round-robin for load-balancing busy servers. DNS round-robin resolves multiple IP addresses to a single DNS name. The DNS server will step through the IP address entries when it replies to DNS name requests. The effect is to have many IP addresses resolvable by the same name. For example, an HTTP server farm can be load-balanced with DNS round-robin. However, IP clients cache the DNS/IP address resolution locally, so each subsequent request goes to the same IP addresses, thwarting DNS round-robin.












