Using NAT for policy-based VPN traffic
NAT configurations only apply to the encrypted packets in the VPN tunnel by default. To translate the addresses of the packets going through the policy-based VPN tunnel, you must specifically enable NAT for the policy-based VPN.
Observe the following guidelines:
- Define Sites (encryption domains) that contain the translated IP addresses that the packets use when they are inside the policy-based VPN tunnel. Set the Sites that contain the
real IP addresses to Private mode in the policy-based VPN.
For example, if you translate IP addresses of traffic going into the policy-based VPN, add a Site that includes the translated IP addresses to your VPN Gateway element. The Sites that contain the internal addresses are set to Private mode.
- If address translation for VPN clients is enabled for the firewall in the Engine Editor, NAT Pool translation is applied before the NAT rules. NAT rules cannot match traffic to which NAT pool translation is applied. NAT Pool is the preferred method for translating VPN client addresses.
- If you want to forward traffic originating from VPN clients to the Internet, you must typically have at least two NAT rules. The first rule is for connections to internal resources to prevent NAT from being applied or to translate to an internal IP address as necessary. The second rule translates internal IP addresses to an external IP address for the Internet connections.
The order of processing for traffic going into a policy-based VPN tunnel is:
- Access Rules
- NAT Rules
- VPN tunnel
The order of processing for traffic coming out of a VPN tunnel is:
- Access Rules
- VPN client NAT Pool
- NAT Rules
- Internal Network
Other than these guidelines, there are no other VPN-specific issues with NAT rules. The first matching NAT rule is applied to those connections that are matched against the NAT rules and the rest of the NAT rules are ignored.