Using IPSec VPN to Implement Secure Interconnection Between LANs
The headquarters and branches of an enterprise are interconnected in various ways.
Site-to-Site VPN — IPSec
A site-to-site VPN, also called a LAN-to-LAN VPN or a gateway-to-gateway VPN, is used to set up an IPSec tunnel between two gateways, implementing secure access of LANs. Figure 1 shows a typical site-to-site IPSec VPN network.
This network requires that two gateways on both ends of the tunnel have fixed IP addresses or fixed domain names, and both parties be able to initiate a connection.
A site-to-site VPN is applicable to IPv4 networks, IPv6 networks, and networks that run both IPv4 and IPv6.
- Firewalls acting as IPSec gateways can be deployed on Layer 2 or Layer 3. When gateways are deployed on Layer 2, the site-to-site IPSec VPN is called transparent IPSec VPN.
A FW can serve as both an IPSec gateway and a NAT gateway.
When a NAT device exists between two IPSec gateways, FWs support IPSec NAT traversal.
Site-to-Site VPN — L2TP over IPSec
L2TP over IPSec encapsulates packets using L2TP before transmitting them using IPSec. L2TP and IPSec are used together to allow branches to securely access VPNs by dialing the LAC. Branches use L2TP to dial the LAC and obtain private IP addresses on the headquarters network. IPSec is used to ensure communication security during this process.
Figure 2 shows a network for the branch to access the headquarters through an L2TP over IPSec tunnel. The outbound interfaces of the LAC (FW_A) and L2TP network server (LNS) (FW_B) have fixed IP addresses. A user in the branch dials FW_A through PPPoE. FW_A then initiates a tunnel setup request to FW_B over the Internet. An L2TP over IPSec is set up between FW_A and FW_B. Then FW_A authenticates the user, and FW_B can also authenticate the user again after the user is successfully authenticated by FW_A. After the user is successfully authenticated by FW_B, FW_B assigns a private IP address to the user.
Site-to-Site VPN — GRE over IPSec
Generic Routing Encapsulation (GRE) is a generic tunneling protocol that encapsulates multicast, broadcast, and non-IP packets. GRE, however, provides only simple password authentication but not data encryption, and therefore cannot ensure data transmission security. IPSec provides high data transmission security but cannot encapsulate multicast, broadcast, or non-IP packets. Leveraging advantages of GRE and IPSec, GRE over IPSec encapsulates multicast, broadcast, and non-IP packets into common IP packets. For example, to hold a video conference between a branch and the headquarters, use GRE over IPSec to transmit service traffic on an IPSec VPN.
Figure 3 shows a typical GRE over IPSec VPN network.
GRE over IPSec supports the transport and tunnel encapsulation modes. Compared to the transport mode, the tunnel mode adds an extra IPSec header, which makes the packet longer and more likely to be fragmented. Therefore, GRE over IPSec in transport mode is recommended.
Site-to-Multisite (Hub-Spoke VPN)
In most cases, the headquarters of an enterprise are connected to multiple branches through IPSec VPN tunnels. Figure 4 shows a typical hub-spoke IPSec VPN network.
Branches do not need to communicate with each other.
Deploy IPSec VPN between the headquarters and branches.
Branches need to communicate with each other.
If branches access the Internet using dynamic public IP addresses, traditional IPSec VPN will cause branches to fail to directly communicate with each other. Communication data between branches has to be forwarded through the headquarters. This consumes the CPU and memory resources of the hub (FW_C). In addition, the headquarters must encapsulate and decapsulate traffic between branches, causing additional network delay.