NAT and Security Issues

In single-site deployments, CUCM servers and IP Phones usually use private IP addresses because there is no need to communicate with the outside IP world. NAT is not configured for the phone subnets, and attacks from the outside are impossible. In multisite deployments, however, IP Security (IPsec) virtual private network (VPN) tunnels can be used between sites. The VPN tunnels allow only intersite communication; access to the protected internal networks is not possible from the outside—only from the other site through the tunnel. Therefore, attacks from the outside are blocked at the gateway. To configure IPsec VPNs, the VPN tunnel must be configured to terminate on the two gateways in the different sites. Sometimes this is not possible; for instance, the two sites may be under different administration, or perhaps security policies do not allow the configuration of IPsec VPNs. In such a case, or when connecting to a public service such as an ITSP, NAT has to be configured for CUCM servers and IP Phones. Cisco calls this Hosted NAT Traversal for Session Border Controllers. In Figure 1-7, Company A and Company B both use IP network 10.0.0.0/8 internally. To communicate over the Internet, the private addresses are translated into public IP addresses. Company A uses public IP network A, and Company B uses public IP network B. All CUCM servers and IP Phones can be reached from the Internet and communicate with each other. As soon as CUCM servers and IP Phones can be reached with public IP addresses, they are subject to attacks from the outside world, introducing potential security issues.
A groan grasps the peanut near the offending anthology.