Avaya 3.7 Setting up VPN with overlapping private addresses

Setting up the network
90 Avaya VPNmanager Configuration Guide Release 3.7
In the example shown in Figure 28, when client 10.1.2.101 initially sends a packet to a host on
the public network, the security gateway dynamically maps the client’s private address
10.1.2.101 to a public address selected from the N1.N2.N3.0/24 address pool. Since the packet
is going out the public interface, the security gateway changes the packet’s source address
10.1.2.101 to its assigned public address N1.N2.N3.X.
When the public host receives the packet, it sends a reply to N1.N2.N3.X. The reply packet is
routed into the security gateway through the public interface, the security gateway changes the
packet’s destination address back to the client’s private address 10.1.2.101 before sending the
packet back to the client.
The public address assigned to the client’s private address remains in effect until the client
traffic is idle for a user-defined period of time. When this idle period is reached, the mapped
address is returned to the pool of available addresses. When all public addresses have been
assigned, no other private clients can initiate a connection to the public network until a public
address becomes available.
One limitation for dynamic mapping is that communication with remote hosts on the public
network can only be initiated from clients on the private network. If communicat ion ini tiated fr om
either the public or private side is required, static address mapping must be used. Static
address mapping permanently maps private addresses to their corresponding public
addresses, thereby allowing communication between clients and hosts to be initiated from
either the private or public network.
Setting up VPN with overlapping private addresses
Figure 29 shows an example of using NAT to set up VPNs between two site s t hat use t he same
private network addresses while still allowing private network connections to the In ternet. Thr ee
NAT rules are applied to each security gateway: one on the private interface, one on the public
interface, and one on the VPN tunnel. A DNS entry is also required for each host that can be
reached through the tunnel.
The tunnel-mode VPN, named Sales_VPN, provides a secure connection between the
SF_Sales_Group and LA_Sales_Group over the public network. Since both sites are using the
same private network addresses, NAT mapping must be performed on packets entering and
leaving the Sales_VPN tunnel. This is required to ensure that unique host addresses are used
on each side of the tunnel.
Communication between a member of the SF_Sales_Group and the server in LA_Sales_Group
starts with a DNS lookup of the LA_Sales_Group server address which in this example returns
a destination address of 10.0.88.20. The SF_VSU proxy ARPs for 10.0.88.20 by sending its
own MAC address in response to an ARP request.
When the packet sent from 10.1.1.17 to 10.0.88.20 enters SF_VSU
through the private interface, its destination address is changed from 10.0.8 8.20 to 1 72.16.1. 20
by applying the NAT rule assigned to the security gateway’s private interface.
The SF_VSU performs a VPN lookup and determines that the packet
needs to be tunneled to the LA_VSU. Since the packet is leaving the SF_VSU through the
Sales_VPN tunnel, the SF_VSU applies the tunnel NAT rule to the packet’s source address