Site-to-Site and Remote Access VPN on FTD, and Troubleshooting

What it is

FTD can terminate both site-to-site VPNs and remote access VPNs, and it is configured from the Firewall Management Center.

A site to site VPN joins two networks through an IPsec tunnel between two gateways. A remote access VPN lets a user connect from anywhere using Cisco Secure Client. Both need matching security parameters at both ends, and a path for the traffic.

How it works

First get the tunnel to form, then make sure the right traffic uses it.

Site-to-site VPN

In FMC you create a site to site VPN topology, and the topology type sets the shape.

For each endpoint you choose the device, the interface that terminates the tunnel, and the protected networks. You choose IKEv1 or IKEv2, and IKEv2 is preferred because it is more efficient and more secure. You then set the IKE policy, the IPsec proposal and the authentication, which is a pre-shared key or a certificate.

Both peers need the same IKE settings: encryption, integrity, Diffie-Hellman group and authentication method. The protected network definitions must mirror each other. One side's local network is the other side's remote network.

Traffic handling for site-to-site

Traffic that goes into the tunnel should not be translated by NAT. Create a NAT exemption, often called identity NAT, for the protected networks. The firewall also needs routes that point the remote network out of the VPN interface, and an access control rule or the VPN bypass option to permit the decrypted traffic.

Remote access VPN

The remote access policy wizard asks for the main parts.

• Connection profile: names the tunnel group and how users authenticate.
• Authentication: usually a RADIUS server such as ISE, or LDAP, or a certificate.
• Address pool: the IP addresses given to connected clients.
• Group policy: attributes such as DNS, split tunnelling and banners.
• Secure Client package: the client software that the gateway can push to users.
• Access interface and certificate: the outside interface and the identity certificate that the gateway presents.

Clients connect by SSL, using TLS or DTLS, or by IPsec with IKEv2. Split tunnelling sends only listed networks through the VPN. Without it, all user traffic goes through the firewall.

As with site to site, you need NAT exemption for the client pool, and policy that permits the client traffic. An identity certificate that clients trust avoids security warnings.

Troubleshooting tunnel establishment

IKE first builds a secure channel, then IPsec builds the data tunnel. Check each stage in order, and note where it stops.

> system support diagnostic-cli
firepower> enable
firepower# show crypto ikev2 sa
firepower# show crypto ipsec sa
firepower# show vpn-sessiondb anyconnect
firepower# debug crypto ikev2 platform 255
firepower# debug crypto ikev2 protocol 255

The system support diagnostic-cli command opens the diagnostic CLI on the Threat Defense device, where these ASA style commands run.

The first two show the IKE and IPsec security associations. The third lists remote access sessions. Debugs show the negotiation, and you should disable them after use.

The protected network mismatch is a classic case. The peers agree on IKE, but they refuse the IPsec negotiation, because the proxy identities do not mirror each other.

Useful extra checks

Use a packet capture on the outside interface to see whether IKE packets arrive. Use packet-tracer to test whether the firewall policy and NAT allow a flow. The FMC health and event views also show VPN status.