NAT and ipsec vpn of link Balancing Devices

 

When implementing a new link Load Balancing Project, users often use firewalls as their egress devices. If the user's organizational structure is distributed, it is often necessary to build a security tunnel to communicate with the headquarters or branches over the internet through ipsec vpn. In this case, the firewall is responsible for the maintenance of the ipsec vpn tunnel in addition to serving as the egress device. If we need to launch the link load device at this time, we will inevitably encounter customer requirements to ensure the availability and Stability of the ipsec vpn. In this case, we generally ask the customer to move the firewall from the egress to the Intranet, and then map the vpn application of the firewall on the Link balancing device. However, this method has limitations. In most cases, NAT processing is completely transparent to users. However, when you want to use the IPSec Technology to build a VPN Network, NAT brings a lot of trouble. The main goal of the IPSec protocol is to protect the integrity of IP data packets, which means that IPSec will prohibit any modification to the data packets. However, during the NAT process, you must modify the IP address header data of the IP data packet, transfer the Layer Report header data, or even transfer the data content such as the FTP application. Therefore, once an IP packet processed by IPSec passes through the NAT device, the packet content is changed by the NAT device. After the modified packet arrives at the destination host, the decryption or integrity authentication process will fail, therefore, this message is discarded as illegal data. This is the most common issue of "coordination between IPSec and NAT" when establishing a VPN gateway. So when will we encounter this problem? If our VPN device is behind the NAT device, if we need to access the Intranet through the VPN Client outside the country, if we do not have a legal public network address, we can only access the Internet through the service provider, etc, this problem occurs.
Ipsec usually works in transmission mode and tunnel mode, while the common protocols are AH and ESP. From the principle, we can see that, in the end, NAT may only work with ESP in tunnel mode. Let's take a look at the work of site to site vpn used by users in traditional units: 1. tunnel mode requires that local-address and des-address be specified manually on each site, therefore, when establishing a tunnel between the site and the site, it is the source and destination addresses that need to authenticate each other. This method is also the most common method we encounter. 2. In the aggressive mode, you usually only need to configure the Host Name of the vpn server at the headquarters in the branch office. In this case, you do not need to configure the host name to access the vpn server. Therefore, this mode has the best compatibility. However, this mode is relatively less secure than the first one. Now let's take a look at the situation in the first mode, namely the tunnel mode. In my scenario, the user is a branch-based structure. Therefore, by setting up a vpn server at the headquarters, the vpn devices of each branch are connected by site to site, ipsec vpn is connected in tunnel mode.

650) this. width = 650; "border =" 0 "alt =" "src =" http://www.bkjia.com/uploads/allimg/131227/0P2144356-0.jpg "/>

Now, after adding a link balancing device, the structure is changed:

650) this. width = 650; "border =" 0 "alt =" "src =" http://www.bkjia.com/uploads/allimg/131227/0P21424A-1.jpg "/>

After the device goes online, it finds that the VPN device of the branch cannot connect to the vpn server of the Headquarters. After inspection, it finds that, you can use the local-address and des-address methods to establish a tunnel on the vpn devices of the headquarters and branches. Therefore, a one-to-one ing is established for the Headquarters vpn server on the Link balancing device to directly map the public IP address of the previous Headquarters vpn server to the current private IP address, at the same time, modify the local-address of the tunnel on the Headquarters vpn server and change the previous public address to the current private address. However, it is found that the vpn device of the Branch has been trying to establish a tunnel, but it never succeeds. After analysis, the ipsec vpn package sent from the vpn device of the branch office cannot pass the verification of the Headquarters vpn device after the one-to-one ing is modified. At this time, the user suggested that, because there are too many branches and they do not want to modify the local-address of the vpn server at the headquarters and the tunnels of each branch, they should: the vpn configuration on the Headquarters vpn server cannot be modified, and the vpn must work properly. Therefore, you need to modify the configuration of the link Balancing Device for the following purposes: 1. You cannot modify the ipsec-related data packets. Otherwise, vpn negotiation may fail. 2. In addition to changing the previous public IP address to the current private IP address, the vpn server at the Headquarters cannot be changed. It is found that using the DSR can perfectly solve this problem: step 1: The firewall network port must be directly connected to the network port vlan of The Link balancing device, and an IP address of the network segment of the network port of The Link balancing device must be set, at the same time, the firewall's default gateway points to the network port interface address of the link balancing device. Step 2: create a virtual-server on the Link balancing device. Its VIP address is the public network address of the vpn server. The associated service-group has only one server, the private address of the vpn server. Enable DSR for the virtual-server. Step 3: Create a loopback address on the firewall, which is the public ip address of the previous vpn server. After the above three steps, the ipsec vpn packet sent from the vpn device of the branch office will be directly forwarded to the private IP address of the firewall through the link balancing device without any modification, the firewall sees that the request packet is the loopback address of the request, so the request is accepted and processed. In this way, the vpn can work normally without modifying any vpn configuration. Some may say, isn't this actually a routing action? Can I add a host route entry about the private IP address of the vpn server to the link balancing device? This is a good question. The above three steps are actually a router routing action, but the problem is that the gateway device of the isp will not add a host route for us, instead, it will only assign us a public network segment. If no ing is added to the egress device, the egress device does not respond to the arp query on the public ip address of the vpn server of the isp gateway device, and the request does not reach the interface address of the egress device, the Host Routing of the egress device cannot be used.

T. d.

This article is from the "ADC technology blog" blog, please be sure to keep this source http://virtualadc.blog.51cto.com/3027116/696941