How to Configure Security Policies to Allow IPsec VPN
Site-to-Site IPsec VPN
In a typical IPsec VPN application scenario, the VPN gateways (Firewall_A and Firewall_B) negotiate the security association (SA) through the Internet Key Exchange (IKE) protocol, and then use the negotiated Authentication Header (AH) or Encapsulating Security Payload (ESP) protocol to provide authentication or encrypted transmission, as shown in Figure 9-1. ISAKMP messages are used for IKE negotiation and encapsulated in UDP packets. The UDP port number is 500. ESP provides the authentication and encryption functions, whereas AH provides only the authentication function. Therefore, ESP is usually used.
Generally, the subnet devices at both ends of the site-to-site VPN tunnel may initiate service access. Therefore, both Firewall_A and Firewall_B may initiate IKE negotiation. Table 9-1 lists the typical security policy configuration. The source and destination IP address in the security policies on Firewall_A are the destination and source IP addresses in the security policies on Firewall_B. The source and destination security zones in the security policies on Firewall_A are the destination and source security zones in the security policies on Firewall_B.
No. |
Name |
Source Security Zone |
Destination Security Zone |
Source Address/Region |
Destination Address/Region |
Service |
Action |
---|---|---|---|---|---|---|---|
Firewall_A |
|||||||
101 |
Allow ISAKMP message to peer |
Local |
Untrust |
192.0.2.1/32 |
203.0.113.1/32 |
isakmp (UDP: 500) |
permit |
102 |
Allow ISAKMP message from peer |
Untrust |
Local |
203.0.113.1/32 |
192.0.2.1/32 |
isakmp (UDP: 500) |
permit |
103 |
Allow IPSec from peer |
Untrust |
Local |
203.0.113.1/32 |
192.0.2.1/32 |
esp (50) ah (51) |
permit |
104 |
Allow intranet from peer |
Untrust |
Trust |
10.1.2.0/24 |
10.1.1.0/24 |
any |
permit |
105 |
Allow intranet to peer |
Trust |
Untrust |
10.1.1.0/24 |
10.1.2.0/24 |
any |
permit |
Firewall_B |
|||||||
101 |
Allow ISAKMP message to peer |
Local |
Untrust |
203.0.113.1/32 |
192.0.2.1/32 |
isakmp (UDP: 500) |
permit |
102 |
Allow ISAKMP message from peer |
Untrust |
Local |
192.0.2.1/32 |
203.0.113.1/32 |
isakmp (UDP: 500) |
permit |
103 |
Allow IPSec from peer |
Untrust |
Local |
192.0.2.1/32 |
203.0.113.1/32 |
esp (50) ah (51) |
permit |
104 |
Allow intranet from peer |
Untrust |
Trust |
10.1.1.0/24 |
10.1.2.0/24 |
any |
permit |
105 |
Allow intranet to peer |
Trust |
Untrust |
10.1.2.0/24 |
10.1.1.0/24 |
any |
permit |
Pay attention to the following points:
- Configure security policy 103 for a firewall to receive IPsec-encrypted packets from the peer firewall. No security policy needs to be configured for IPsec-encrypted packets sent from the firewall.
- If IPsec VPN is configured manually, the firewalls do not use ISAKMP messages to negotiate SAs. Therefore, you do not need to configure security policy 101 or 102.
- In security policy 105 for the traffic to be encrypted entering the IPsec tunnel, the source security zone is the security zone (Trust) to which the packet sender belongs, and the destination security zone is the security zone to which the interface that establishes the IPsec tunnel belongs. The interface refers to the interface to which the IPsec policy group is applied or the virtual tunnel interface to which the IPsec profile is applied. For example, Firewall_A initiates a service access request. Figure 9-2 shows the source and destination security zones. When a tunnel interface is used to establish an IPsec tunnel, ensure that the security zones are correctly configured.
Site-to-Multisite IPsec VPN
In a site-to-multisite IPsec VPN scenario, a branch site usually initiates access to the hub site. Table 9-2 lists the security policies for the branch site and hub site.
No. |
Name |
Source Security Zone |
Destination Security Zone |
Source Address/Region |
Destination Address/Region |
Service |
Action |
---|---|---|---|---|---|---|---|
Firewall_A, which is a branch site that initiates access requests |
|||||||
101 |
Allow ISAKMP message to peer |
Local |
Untrust |
192.0.2.1/32 |
203.0.113.1/32 |
isakmp (UDP: 500) |
permit |
102 |
Allow IPSec from peer |
Untrust |
Local |
203.0.113.1/32 |
192.0.2.1/32 |
esp (50) ah (51) |
permit |
103 |
Allow intranet to peer |
Trust |
Untrust |
10.1.1.0/24 |
10.1.2.0/24 |
any |
permit |
Firewall_B, which is the hub site that receives access requests from the peer end |
|||||||
201 |
Allow ISAKMP message from peer |
Untrust |
Local |
192.0.2.1/32 |
203.0.113.1/32 |
isakmp (UDP: 500) |
permit |
202 |
Allow IPSec from peer |
Untrust |
Local |
192.0.2.1/32 |
203.0.113.1/32 |
esp (50) ah (51) |
permit |
203 |
Allow intranet from peer |
Untrust |
Trust |
10.1.1.0/24 |
10.1.2.0/24 |
any |
permit |
If the hub site needs to initiate access to branch sites, the security policy configuration in the site-to-multisite scenario is the same as that in the site-to-site scenario. For details, see Table 9-1.
IPsec VPN with NAT Traversal
NAT translates the IP address and port number of a packet. IPsec VPN ensures data security and prevents data from being intercepted or tampered with. If a NAT gateway exists between VPN gateways, the NAT gateway will attempt to change IP addresses and port numbers of packets, but VPN gateways will prevent the IP addresses and port number from being changed, which causes a conflict. To ensure that an IPsec tunnel can be established and packets can pass through the NAT device, NAT traversal function must be enabled on the VPN gateways.
To implement NAT traversal, a VPN gateway needs to check whether the peer end supports NAT traversal in the IKE negotiation phase. If the peer end supports NAT traversal, the VPN gateway checks whether a NAT gateway exists between the local end and the peer end. These checks are performed using ISAKMP messages.
If a NAT gateway exists, the VPN gateway uses the UDP header to encapsulate ISAKMP messages and ESP packets to implement NAT traversal. In transport mode, the VPN gateway inserts a standard UDP header between the original IP header and an ESP header. In tunnel mode, the VPN gateway inserts a standard UDP header between the new IP header and an ESP header. The default port number in the UDP header is 4500. When receiving ESP packets, the NAT gateway translates the IP addresses and port numbers in the external IP header and UDP header. Figure 9-3 shows a typical NAT traversal scenario. Firewall_A is located on the enterprise private network. The IPsec VPN packets sent from Firewall_A to Firewall_B must pass through the NAT gateway.
Table 9-3 describes the configuration for security policies.
No. |
Name |
Source Security Zone |
Destination Security Zone |
Source Address/Region |
Destination Address/Region |
Service |
Action |
---|---|---|---|---|---|---|---|
Firewall_A, which is a branch site that initiates access |
|||||||
101 |
Allow ISAKMP message to peer |
Local |
Untrust |
10.10.1.1/32 |
203.0.113.1/32 |
isakmp (UDP: 500) UDP: 4500 |
permit |
102 |
Allow IPSec from peer |
Untrust |
Local |
203.0.113.1/32 |
10.10.1.1/32 |
UDP: 4500 |
permit |
103 |
Allow intranet to peer |
Trust |
Untrust |
10.1.1.0/24 |
10.1.2.0/24 |
any |
permit |
Firewall_B, which is the hub site that receives access requests from the peer end |
|||||||
201 |
Allow ISAKMP message from peer |
Untrust |
Local |
192.0.2.1/32 |
203.0.113.1/32 |
isakmp (UDP: 500) UDP: 4500 |
permit |
202 |
Allow IPSec from peer |
Untrust |
Local |
192.0.2.1/32 |
203.0.113.1/32 |
UDP: 4500 |
permit |
203 |
Allow intranet from peer |
Untrust |
Trust |
10.1.1.0/24 |
10.1.2.0/24 |
any |
permit |