This document provides a configuration example for Site to Site VPN on Firepower Threat Defense (FTD) managed by FMC.
Cisco recommends that you have knowledge of these topics:
Basic understanding of VPN
Experience with Firepower Management Center
Experience with ASA command line
The information in this document is based on these software and hardware versions:
Cisco FTD 6.5
The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, ensure that you understand the potential impact of any command.
Start with the configuration on FTD with FirePower Management Center.
Step 1. Define the VPN Topology.
1. Navigate to Devices > VPN > Site To Site. Under Add VPN, click Firepower Threat Defense Device, as shown in this image.
2. Create New VPN Topology box appears. Give VPN a name that is easily identifiable.
Network Topology: Point to Point
IKE Version: IKEv2
In this example when you select endpoints, Node A is the FTD, and Node B is the ASA. Click on the green plus button to add devices to the topology, as shown in this image.
3. Add the FTD as the first endpoint.
Choose the interface that a crypto map is placed on. The IP address should auto-populate from the device configuration.
Click the green plus under Protected Networks, as shown in this image, to select what subnets should be encrypted in this VPN.
4. Click on green plus and a Network Object is created here.
5. Add all the subnets local to the FTD that needs to be encrypted. Click Add to move them to the Selected Networks. Now click OK, as shown in this image.
FTDSubnet = 10.10.113.0/24
Node A: (FTD) endpoint is complete. Click the green plus for Node B, as shown in the image.
Node B is an ASA. Devices that are not managed by the FMC are considered Extranet.
6. Add a device name and IP address. Click on the green plus to add protected networks, as shown in the image.
7. As shown in this image, select the ASA subnets that need to be encrypted and add them to the selected networks.
ASASubnet = 10.10.110.0/24
Step 2. Configure IKE Parameters.
Now both endpoints are in place go through the IKE/IPSEC configuration.
1. Under the IKE tab, specify the parameters that are used for the IKEv2 initial exchange. Click the green plus to create a new IKE policy, as shown in the image.
2. In the new IKE policy, specify a priority number as well as the lifetime of phase 1 of the connection. This document uses these parameters for the initial exchange: Integrity (SHA256), Encryption (AES-256), PRF (SHA256), and Diffie-Hellman Group (Group 14)
Note: All IKE policies on the device are sent to the remote peer regardless of what is in the selected policy section. The first IKE Policy matched by the remote peer will be selected for the VPN connection. Choose which policy is sent first using the priority field. Priority 1 will be sent first.
3. Once the parameters are added, select this policy, and choose the Authentication Type.
4. Choose pre-shared-key manual. For this document, the PSK cisco123 is used.
Step 3. Configure IPsec Parameters.
1. Under IPsec, click on the pencil to edit the transform set and create a new IPsec Proposal, as shown in this image.
2. In order to create a new IKEv2 IPsec Proposal, click the green plus and input the phase 2 parameters.
Select ESP Encryption >AES-GCM-256. When the GCM algorithm is used for encryption, a Hash algorithm is not needed. With GCM the hash function is built-in.
3. Once the new IPsec proposal has been created add it to the selected transform sets.
The newly selected IPsec proposal is now listed under the IKEv2 IPsec Proposals.
If needed, the phase 2 lifetime and PFS can be edited here. For this example, the lifetime will be set as default and PFS disabled.
Optional- You must complete either complete the option to Bypass Access Control or Create an Access Control Policy.
Step 4. Bypass Access Control.
Optionally, sysopt permit-vpn can be enabled under the Advanced > Tunnel.
This removes the possibility to use the Access Control Policy to inspect traffic coming from the users. VPN filters or downloadable ACLs can still be used to filter user traffic. This is a global command and will apply to all VPNs if this checkbox is enabled.
If sysopt permit-vpn is not enabled then an access control policy must be created to allow the VPN traffic through the FTD device. If sysopt permit-vpn is enabled skip creating an access control policy.
Step 5. Create an Access Control Policy.
Under Access Control Policies, navigate to Policies > Access Control > Access Control and select the Policy that targets the FTD device. In order to add a Rule, click Add Rule, as shown in the image here.
Traffic must be allowed from the internal network out to the external network and from the external network into the internal network. Create one rule to do both or create two rules to keep them separate. In this example, one rule is created to do both.
Step 6. Configure NAT Exemption.
Configure a NAT Exemption statement for the VPN traffic. NAT exemption must be in place to keep VPN traffic from hitting another NAT statement and incorrectly translating VPN traffic.
1. Navigate to Devices > NAT, select the NAT policy that targets the FTD. Create a new rule as you click the Add Rule button.
2. Create a new Static Manual NAT Rule. Reference the inside and outside interfaces.
3. Under the Translation tab and select the source and destination subnets. As this is a NAT exemption rule, make the original source/destination and the translated source/destination the same, as shown in this image:
4. Lastly, move to the Advanced tab and enabled no-proxy-arp and route-lookup.
5. Save this rule and look at the final results in the NAT list.
6. Once the configuration is completed, save and deploy the configuration to the FTD.
Step 7. Configure the ASA.
Enable IKEv2 on the outside interface of the ASA:
Crypto ikev2 enable outside
2. Create the IKEv2 Policy that defines the same parameters configured on the FTD:
Note: At this time there is no way to review VPN tunnel status from the FMC. There is an enhancement request for this capability CSCvh77603.
Attempt to initiate traffic through the VPN tunnel. With access to the command line of the ASA or FTD, this can be done with the packet tracer command. When using the packet-tracer command to bring up the VPN tunnel it must be run twice to verify the tunnel comes up. The first time the command is issued the VPN tunnel is down so the packet-tracer command will fail with VPN encrypt DROP. Do not use the inside IP address of the firewall as the source IP address in the packet-tracer as this will always fail.
When building a VPN there are two sides negotiating the tunnel. Therefore, it is best to get both sides of the conversation when you troubleshoot any type of tunnel failure. A detailed guide on how to debug IKEv2 tunnels can be found here: How to debug IKEv2 VPNs
The most common cause of tunnel failures is a connectivity issue. The best way to determine this is to take packet captures on the device. Use this command to take packet captures on the device:
Capture capout interface outside match ip host 172.16.100.20 host 192.168.200.10
Once the capture is in place, try to send traffic over the VPN and check for bi-directional traffic in the packet capture.