FMC Site to Site VPNs - Network Direction (2024)

Last Updated: [last-modified] (UTC)

Firewalls running Threat Defence support site to site (AKA LAN-to-LAN) VPNs. They’re slightly different though, as the VPN is configured in FMC, not on the device itself.

In this article, we’ll look at how to configure a site-to-site VPN through FMC.

Please note, this applies to FMC managing devices that run FTD. Regular ASA with Firepower Services do not have their VPN’s configured in FMC.

Topologies

The first thing to be aware of is the topologies that are supported. There are three topology types to choose from:

• Point to Point– This is a simple topology between two endpoints. In FMC, A and B nodes need to be defined
• Hub and Spoke– A group of spoke sites creating tunnels to a hub site
• Full Mesh– A group of multipoint tunnels, where any device can connect to any other

Each device in any of these topologies is called anendpoint. At least one endpoint will be a device managed in FMC.

Any device in your VPN topology that’s not FMC managed is called anExtranetdevice. This includes devices in your network that don’t run threat defence, devices outside of your network (such as a router in a partner network), and Threat Defence devices managed by a different FMC server.

We can use FMC to push VPN config to remove FTD devices. This is possible for devices managed in our FMC, or devices managed with another FMC server (such as a remote office managed by a different team).

Each endpoint has aprotected networkassociated with it. This is, as the name suggests, the network that’s behind the VPN device. The ultimate goal of the VPN is for the protected networks to communicate with each other.

No special licensing is required for the VPN, as long asexport-controlled featuresis enabled.

Configuration

IKE Policies and IPSecProposals

Each endpoint can be authenticated using either certificates or preshared keys. Preshared keys may be automatic if FMC manages all the endpoints.

There are some predefined IKE policies that you can use, or you can create your own:

1. Go to theObjectstab
2. Browse toVPN, then eitherIKEv1orIKEv2

As shown below, you can select the algorithms that you want to use. The same applies to IPSec proposals.

Topology

We’ll now create a point-to-point VPN that connects to a third-party device.

1. Browse toDevices->VPN->Site To Site
2. ClickAdd VPN->Firepower Threat Defence Device
3. Enter a name for the topology
4. Select a topology type (point to pointin our case)
5. Select the versionof IKE to use (IKEv2 is recommended)

Now we need to define our first endpoint (Node A).

1. Make sure you’re on theEndpointstab
2. Next toNode A, click the green Add button
3. Select a Threat Defence device that your FMC manages from the list
4. Select an interface that the VPN will be established on
5. If there is more than one IP address on this interface, select the one to use
6. If this is a private IP address (non-routable over the internet), tick theThis IP is Privatecheckbox, and enter the corresponding public IP
7. Select theConnection Type
   • Bidirectional– Either node can negotiate the VPN
   • Answer-Only– The local node will respond when the remote node negotiates the VPN
   • Originate-Only– The local node will negotiate the VPN, but will not respond if the remote tries to negotiate
8. Click the green Add button next toProtected Networks
   • Add one or more networks behind this device, that will be accessible over the VPN
   • From FMC 6.2.3, you have the option of using a subnet/IP address object, or an extended access list

Now, configure the remote endpoint (not managed by us):

1. Next toNode B, click the green Add button
2. SelectExtranetas the device
3. Enter a friendly Device Name
4. Enter the IP address of the device
5. For version 6.2.3 and newer, there will be an option to add acertificate map(we don’t need it, as we’re using preshared keys)
6. As before, add a protected network

Next, we configure IKE (the phase-1 tunnel). The settings available to us are determined by the version of IKE that we’re using.

1. Go to theIKEtab
2. Select a suitable policy (we’re usingthe predefinedAES-SHA-SHApolicy)
3. Select the authentication type
   • A preshared manual key is entered at both ends manually
   • A preshared automatic key is managed by FMC. This requires FMC to manage both ends
   • A certificate can be used, but it requires a trustpoint to be configured

And now we configure IPSec (phase-2 tunnel):

1. Go to theIPSectab
2. Select a suitable IPSec proposal (If you’re not sure, leave the defaults in place)
3. Enable Reverse Route Injection to add protected networks into the local routing table
4. Optionally, enable Perfect Forward Secrecy. If you’re not sure, leave it enabled

Additional Configuration

There are a few final things that you may want to consider for your environment.

NAT Exemption– If you use NAT, you will need to create an exemption for the traffic going over the VPN.

Dynamic Routing– Reverse Route Injection gets the route into the local routing table, but it doesn’t go any further. If you want to advertise this route, you need to redistribute it into your IGP.

Policy Deployment– Remember that your changes will not take effect until you deploy them to your devices.

Verification andMonitoring

The simplest place to check the status of your VPN is in FMC.

Browse toSystem->Health->Events. Then click onVPN Status.

The remaining verification takes place on the FTD CLI. When you are at the CLI, runsystem support diagnostic-clito get the Classic-ASA style console.

From here, run packet-tracer to simulate traffic between the protected networks.

NOTE: I’ve used some fake IP’s here, so I don’t share any real network information.

Simulate Traffic with Packet-Tracer

firepower# packet-tracer in inside icmp 10.6.26.201 8 0 10.8.1.1Phase: 1Type: UN-NATSubtype: staticResult: ALLOWConfig:nat (Inside,Outside) source static Network-Test Network-Test destination static Network-Remote Network-Remote description VPN ExemptionAdditional Information:NAT divert to egress interface OutsideUntranslate 10.8.1.1/0 to 10.8.1.1/0Phase: 2Type: ACCESS-LISTSubtype: logResult: ALLOWConfig:access-group CSM_FW_ACL_ globalaccess-list CSM_FW_ACL_ advanced trust icmp any any rule-id 268436517 event-log flow-endaccess-list CSM_FW_ACL_ remark rule-id 268436517: PREFILTER POLICY: Site Prefilteraccess-list CSM_FW_ACL_ remark rule-id 268436517: RULE: ICMPAdditional Information:Phase: 3Type: CONN-SETTINGSSubtype:Result: ALLOWConfig:class-map class-default match anypolicy-map global_policy class class-default set connection advanced-options UM_STATIC_TCP_MAP set connection decrement-ttlservice-policy global_policy globalAdditional Information:Phase: 4Type: NATSubtype:Result: ALLOWConfig:nat (Inside,Outside) source static Network-Test Network-Test destination static Network-Remote Network-Remote description VPN ExemptionAdditional Information:Static translate 10.6.26.201/0 to 10.6.26.201/0Phase: 5Type: NATSubtype: per-sessionResult: ALLOWConfig:Additional Information:Phase: 6Type: IP-OPTIONSSubtype:Result: ALLOWConfig:Additional Information:Phase: 7Type: INSPECTSubtype: np-inspectResult: ALLOWConfig:Additional Information:Phase: 8Type: VPNSubtype: encryptResult: ALLOWConfig:Additional Information:Phase: 9Type: NATSubtype: rpf-checkResult: ALLOWConfig:nat (Inside,Outside) source static Network-Test Network-Test destination static Network-Remote Network-Remote description VPN ExemptionAdditional Information:Phase: 10Type: FLOW-CREATIONSubtype:Result: ALLOWConfig:Additional Information:New flow created with id 41815442, packet dispatched to next modulePhase: 11Type: ROUTE-LOOKUPSubtype: Resolve Egress InterfaceResult: ALLOWConfig:Additional Information:found next-hop 10.222.254.22 using egress ifc OutsidePhase: 12Type: FLOW-LOOKUPSubtype:Result: ALLOWConfig:Additional Information:Found flow with id 41634632, using existing flowPhase: 13Type: CAPTURESubtype:Result: ALLOWConfig:Additional Information:MAC Access listResult:input-interface: Outsideinput-status: upinput-line-status: upoutput-interface: Outsideoutput-status: upoutput-line-status: upAction: allow

Now, let’s confirm phase-1 (IKE). You may find that the commands below do not return any data initially.

This is because FTD will not attempt to bring the tunnel up until it sees some traffic trying to pass over it. A ping or packet-trace can help with this. Configuring IP SLA somewhere else in the network may be useful to keep the tunnel up.

Confirm Phase-1

! IKEv1 or v2 can be usedfirepower# show crypto ikev1 saIKEv1 SAs: Active SA: 1 Rekey SA: 0 (A tunnel will report 1 Active and 1 Rekey SA during rekey)Total IKE SA: 11 IKE Peer: 258.6.18.25 Type : L2L Role : initiator Rekey : no State : MM_ACTIVE

Now, havea look at phase-2 (IPSec). In particular, look forencapsanddecaps.

Encaps are packets that we encapsulate and send over the VPN. Decaps are packets that are sent over the VPN to us, that we need to decapsulate.

Confirm Phase-2

firepower# sh crypto ip sainterface: Outside Crypto map tag: CSM_Outside_map, seq num: 2, local addr: 10.222.254.2 access-list CSM_IPSEC_ACL_1 extended permit ip 10.6.26.0 255.255.255.0 10.8.0.0 255.255.0.0 local ident (addr/mask/prot/port): (10.6.26.0/255.255.255.0/0/0) remote ident (addr/mask/prot/port): (10.8.0.0/255.255.0.0/0/0) current_peer: 258.6.18.25 #pkts encaps: 43, #pkts encrypt: 43, #pkts digest: 43 ! We are encapsulating traffic and sending #pkts decaps: 0, #pkts decrypt: 0, #pkts verify: 0 ! We are not getting return traffic to decapsulate #pkts compressed: 0, #pkts decompressed: 0 #pkts not compressed: 43, #pkts comp failed: 0, #pkts decomp failed: 0 #pre-frag successes: 0, #pre-frag failures: 0, #fragments created: 0 #PMTUs sent: 0, #PMTUs rcvd: 0, #decapsulated frgs needing reassembly: 0 #TFC rcvd: 0, #TFC sent: 0 #Valid ICMP Errors rcvd: 0, #Invalid ICMP Errors rcvd: 0 #send errors: 0, #recv errors: 0 local crypto endpt.: 10.222.254.2/4500, remote crypto endpt.: 258.6.18.25/4500 path mtu 1500, ipsec overhead 82(52), media mtu 1500 PMTU time remaining (sec): 0, DF policy: copy-df ICMP error validation: disabled, TFC packets: disabled current outbound spi: 6EAB4C07 current inbound spi : B53ECF25 inbound esp sas: spi: 0xB53ECF25 (3040792357) transform: esp-aes-256 esp-sha-hmac no compression in use settings ={L2L, Tunnel, NAT-T-Encaps, PFS Group 2, IKEv1, } slot: 0, conn_id: 12288, crypto-map: CSM_Outside_map sa timing: remaining key lifetime (kB/sec): (3915000/26892) IV size: 16 bytes replay detection support: Y Anti replay bitmap: 0x00000000 0x00000001 outbound esp sas: spi: 0x6EAB4C07 (1856719879) transform: esp-aes-256 esp-sha-hmac no compression in use settings ={L2L, Tunnel, NAT-T-Encaps, PFS Group 2, IKEv1, } slot: 0, conn_id: 12288, crypto-map: CSM_Outside_map sa timing: remaining key lifetime (kB/sec): (3914997/26892) IV size: 16 bytes replay detection support: Y Anti replay bitmap: 0x00000000 0x00000001

If you’re using Reverse Route Injection, then you should check that the route is in the routing table.

Start by checking if the route is in FTD, as shown below. Then check that it’s being redistributed into your IGP successfully.

Check Static VPN route

firepower# show route static! ---Output removed for brevity---Gateway of last resort is 10.225.254.54 to network 0.0.0.0S* 0.0.0.0 0.0.0.0 [1/0] via 10.222.254.2, OutsideV 10.8.0.0 255.255.0.0 connected by VPN (advertised), Outside

References

Cisco –Firepower Threat Defense Site-to-site VPNs