In a policy-based IPSec VPN, you explicitly configure the subnets behind the NSX Edge on the local site that require secure and encrypted communication with the remote subnets on the peer site.

When the local IPSec VPN site originates traffic from unprotected local subnets to the protected remote subnets on the peer site, the traffic is dropped.

The local subnets behind an NSX Edge must have address ranges that do not overlap with the IP addresses on the peer VPN site. If the local and remote peer across an IPsec VPN tunnel has overlapping IP addresses, traffic forwarding across the tunnel might not be consistent.

You can deploy an NSX Edge agent behind a NAT device. In this deployment, the NAT device translates the VPN address of an NSX Edge instance to a publicly accessible address facing the Internet. Remote VPN sites use this public address to access the NSX Edge instance.

You can place remote VPN sites behind a NAT device as well. You must provide the remote VPN site's public IP address and its ID (either FQDN or IP address) to set up the tunnel. On both ends, static one-to-one NAT is required for the VPN address.

The size of the ESG determines the maximum number of supported tunnels, as shown in the following table.
Table 1. Number of Supported IPSec Tunnels
ESG Size Number of IPSec Tunnels
Compact 512
Large 1600
Quad-Large 4096
X-Large 6000
Restriction: The inherent architecture of policy-based IPSec VPN restricts you from setting up VPN tunnel redundancy.

For a detailed example of configuring a policy-based IPSec tunnel between an NSX Edge and a remote VPN Gateway, see Configure Policy-Based IPSec VPN Site Example.