Restrictions for VRF-Aware IPsec
-
Tunnel F-VRF encrypts an IPSec packet and this packet is transferred to the destination through WAN VRF which is attached to a WAN interface. But when the destination sends one IPSec packet back to the source WAN VRF, the router drops the packet as the IPSec packet is not decrypted. This is due to no context matching for it on the WAN VRF. The context which can decrypt the packet is built at the Tunnel F-VRF, which is why the F-VRF of the tunnel must be the same as the VRF of WAN interface so that the IPSec packet can be decrypted.
-
If you are configuring the VRF-Aware IPsec feature using a crypto map configuration and the Inside VRF (IVRF) is not the same as the Front Door VRF (FVRF), this feature is not interoperable with unicast reverse path forwarding (uRPF) if uRPF is enabled on the crypto map interface. If your network requires uRPF, it is recommended that you use Virtual Tunnel Interface (VTI) for IPsec instead of crypto maps.
-
The VRF-Aware IPsec feature does not allow IPsec tunnel mapping between VRFs. For example, it does not allow IPsec tunnel mapping from VRF vpn1 to VRF vpn2.
-
When the VRF-Aware IPsec feature is used with a crypto map, this crypto map cannot use the global VRF as the IVRF and a non-global VRF as the FVRF. However, configurations based on virtual tunnel interfaces do not have that limitation. When VTIs or Dynamic VTIs (DVTIs) are used, the global VRF can be used as the IVRF together with a non-global VRF used as the FVRF.
-
You must include the VRF in the local-address command when using the local address with VRF in the ISAKMP profile and keyring.
-
When configuring IPsec with tunnel protection for VTI, GRE/IPsec, or DMVPN, define the IVRF under the tunnel interface and not under ISAKMP or IKEv2 profile for the peer device. Defining an IVRF under the ISAKMP or IKEv2 profile can lead to IPsec negotiation failures.