Brksec 3629

Designing IPSec VPNs with
Firepower Threat Defense integration

for Scale and High Availability
Pawel Cecot
Security Technical Leader, CX
BRKSEC-3629
Cisco Webex Teams
Questions?
Use Cisco Webex Teams to chat
with the speaker after the session
How
1 Find this session in the Cisco Events Mobile App
2 Click “Join the Discussion”
3 Install Webex Teams or go directly to the team space
4 Enter messages/questions in the team space
BRKSEC-3629 © 2020 Cisco and/or its affiliates. All rights reserved. Cisco Public 3
Abstract
This session covers the design and deployment aspects of integrating IPSec
VPNs with Firepower Threat Defense (FTD) services. VPN (FlexVPN/DMVPN)
and FTD deployment options will be reviewed with high availability and
scalability in mind. The second part contains a detailed walk through of an
example deployment which will help to understand the configuration and
packet flow between different setup components. Proper understating of
how each of the components of the deployment work is a key for successful
design and operation. This session is aimed at Network Specialists and
Architects involved in designing, managing and troubleshooting security
solutions. This is NOT an introductory session; attendees should have
existing knowledge of FlexVPN/DMVPN and FTD capabilities.
For your reference
• There are slides in your PDF that will not be presented.

• They are valuable, but included only “For your reference”.
About Me Paweł Cecot
pcecot@cisco.com
Technical Leader, CX
• VPN Team Krakow
• 8 years in TAC, 10 in Networking
• Automation
• Network Design
Example Design Requitements
• Large Scale Deployment - 40000 locations
• Hub-and-spoke topology
• Provide security using cryptographically protected tunnels.
• Headend redundancy with 15 seconds convergence
• Mix of ASA and IOS routers on branch locations …
• IPS inspection for the spoke-to-spoke traffic using FTD
Session Objectives
• Large scale IPSec VPN deployments, i.e. deployments exceeding single platform limits.
• VPN Design Selection.
• Understand challenges of inserting a security appliance into a VPN topology (Firewall, IPS)
Agenda
• IPSec VPN Solutions Overview
• IPSec VPN High Availability and Scalability
• Selecting a VPN Design
• FTD Deployment and Interface Modes
• FTD Resiliency and Scalability
• Scalable VPN with FTD Integration Deployment Example
• IPSec VPN Best Practices
• Conclusion
IPSec VPN Solutions Overview
IPSec VPN High Availability and Scalability
Selecting a VPN Design
FTD Deployment and Interface Modes
FTD Resiliency and Scalability
Scalable VPN with FTD Integration Deployment Example
IPSec VPN Best Practices
Conclusion
Underlay & Overlay
Underlay Network
Overlay Network
Underlay & Overlay
VPN
Underlay Network
Overlay Network
IPSec VPNs per platform
Irrelevant to our
Cisco IPSec VPNs
presentation
Overlay IPSec VPNs Tunnel-less Encryption
Site-Site, Any-to-Any
Remote-Access Site-Site
(GETVPN)
GRE over IPSec

Crypto Map EZVPN VTI DMVPN FlexVPN
w/ Crypto Map
All in One
IOS/IOS-XE Yes Yes Yes Yes Yes Yes
ASA Yes No Yes Yes No No**
FTD Yes No Yes Yes* No No**
Not Recommended * On FTD 6.7 roadmap

** Limited integration is possible
What about SD-WAN?
Crypto Map
• Crypto Map was the first implementation of IPSec VPNs used on Cisco devices.
• Aligned to the IPsec protocol, were traffic that is about to be encrypted is defined by
an ACL (crypto ACL).
• Configuration nightmare:
• Mismatched/not mirrored ACL entries.
• ACL must be updated every time new networks are added.
crypto isakmp policy 10 crypto map outside_map 10 ipsec-isakmp

encr aes set peer 172.16.1.1
authentication pre-share set transform-set TS
group 2 match address 110
!
crypto isakmp key cisco123 address 172.16.1.1 interface GigabitEthernet0/0
! ip address 172.17.1.1 255.255.255.0
crypto ipsec transform-set TS esp-aes esp-sha-hmac crypto map outside_map
mode tunnel
!
access-list 110 permit ip 10.20.10.0/24 10.10.10.0/24
Crypto Map - Packet Flow
LAN WAN
Overlay Underlay crypto keyring internet-keyring vrf green
pre-shared-key address 10.1.1.2 key cisco123
!
RIB/FIB RIB/FIB crypto isakmp profile cust1-ike-prof
vrf blue
keyring internet-keyring
No native route match identity address 172.16.1.1 green
leaking !
crypto map outside_map 10 ipsec-isakmp
set peer 172.16.1.1
set transform-set ESP-AES-SHA
match address 110
Eth0/0 Eth0/1
LAN WAN
IP Private L4 Data IP Public ESP IP Private L4 Data
interface Eth0/0 interface Eth0/1 Encrypted

vrf forwarding blue vrf forwarding green
ip address <> ip address <>
ip nat inside ip nat outside Need to know the
crypto map CMAP order of operations
Interface feature (NAT, PBR, QoS, NetFlow, ...)
Dynamic Crypto Map
• Dynamic Crypto Map dynamically accepts remote (initiating) peer’s IP address.
• By default, any proposed traffic selector will be accepted from an authenticate peer.
• By design requires more TCAM space (IOS-XE).
• The DVTI technology replaces dynamic crypto maps as a dynamic hub-and-spoke
method for establishing tunnels.
crypto ipsec transform-set TS esp-aes esp-sha-hmac
mode tunnel
!
crypto dynamic-map dynamic_map 10
set transform-set TS
reverse-route
!
crypto map outside_map 10 ipsec-isakmp dynamic dynamic_map
!
interface GigabitEthernet0/0
ip address 172.17.1.1 255.255.255.0
crypto map outside_map
Crypto Map Summary
• Crypto Map is a legacy VPN solution with many limitations:
• Does not support multicast.
• A crypto map and VTI using the same physical interface is not supported.
• It is not supported on port-channel interface (IOS-XE).
• Multi-VRF limitations; fvrf=vrf1 and ivrf=global not supported.
• Limited HA capabilities (IOS-XE does not support stateful IPSec failover).
• IOS-XE architecture has scaling limitations for dynamic crypto map.
• IOS-XE IKEv2 multi-SA SVTI replaces Static Crypto Map

• IOS-XE IKEv2 multi-SA DVTI replaces Dynamic Crypto Map
• VTI on ASA 9.7.1+
• VTI on FTD – on 6.6 roadmap
Tunnel Interface
Tunnel Interface
Overlay Underlay
TUNNEL
INTERFACE
• Tunnel Interface interconnects underlay and overlay network.

• Supports various encapsulation types – GRE IPv4/IPv6, Native IPSec IPv4/IPv6
• Main building block for IOS IPSec VPNs – mGRE (DMVPN), Static/Dynamic (FlexVPN)
IPSec Virtual Tunnel Interface
IPSec VTI
• IPsec Virtual Tunnel Interface (VTI) provides a virtual routable interface for
terminating IPsec tunnels and an easy way to define protection between sites to
form an overlay network.
• Simplifies the configuration of IPsec for protection of remote links, support multicast,
and simplify network management and load balancing.
• The VTI tunnel is always up.
IOS Tunnel Interface – Packet Flow
LAN WAN
Overlay Underlay interface Tunnel <>
vrf forwarding blue Overlay VRF (IVRF)
RIB/FIB RIB/FIB
ip address <> Overlay IP address
tunnel mode gre ipv6 Tunnel encap type
tunnel source <> Underlay src IP address
tunnel vrf green Underlay VRF (FVRF)
tunnel destination <> Underlay dst IP address
Eth0/0 Tunnel1 Eth0/1
IP Private L4 Data IP Public GRE IP Private L4 Data
interface Eth0/0 interface Eth0/1

LAN WAN vrf forwarding green
vrf forwarding blue
IOS Tunnel Interface – Packet Flow
LAN WAN
Overlay Underlay interface Tunnel <>
Pre-encapsulation
vrf forwarding blue
Tunnel encapsulation Overlay VRF (IVRF)
interface output features RIB/FIB RIB/FIB
(apply to cleartext packet) & optional protection
ip address <> Overlay IP address
tunnel mode gre ipv6 Tunnel encap type
tunnel source <> Underlay IP address
tunnel vrf green Underlay VRF (FVRF)
tunnel destination <>
Post-encapsulation Underlay dst IP address
Interface input features
Eth0/0 Eth0/1
Tunnel1 interface output features
(apply to cleartext packet)
(apply to encrypted packet)
IP Private L4 Data IP Public GRE IP Private L4 Data
interface Eth0/0 interface Eth0/1

LAN WAN vrf forwarding green
vrf forwarding blue
Virtual Interface Types
GRE over IPSec IPsec Native CLI
Dynamic Virtual-Template Virtual-Template interface Tunnel <>

Virtual-Access Virtual-Access
Dynamic GRE/IPSec DVTI
DVTI Multi-SA
Static Tunnel interface Tunnel Interface interface Virtual-Template <>
Static GRE/IPSec SVTI
SVTI Multi-SA
IPSec Tunnel Interface Types - Static
Static Tunnel Interface

interface Tunnel1
ip unnumbered Loopback1
Tu0 Tu0 tunnel source GigabitEthernet2
10.0.0.1 10.0.0.2 tunnel mode gre ipv4
tunnel destination 10.0.0.2
tunnel protection ipsec profile default
Tu Static Tunnel
VT
IPSec Tunnel Interface Types - Dynamic
interface Virtual-Template1 type tunnel

Dynamic Tunnel Interface ip unnumbered Loopback1
VT1 tunnel source GigabitEthernet2

Tu0 VA1
Tu0
Spoke 10.0.0.1 10.0.0.2 Hub
interface Virtual-Access1
tunnel source GigabitEthernet2
no tunnel protection ipsec initiate
Tu Static Tunnel VT Virtual Template VA Virtual Access
IOS Tunnel interface types – with GRE
Tunnel
Encapsulation Configuration Use Cases
Type
• p2p GRE
interface Tunnel <id>
Static tunnel mode gre {ip | ipv6}
• p2p GRE over IPSec
GRE/IPSec* tunnel protection ipsec profile default • FlexVPN Spoke w/
shortcuts
interface Virtual-Template <id> type tunnel • FlexVPN Hub
Dynamic IP IPsec GRE IP L4 Data tunnel mode gre {ip | ipv6} • FlexVPN Spoke w/
GRE/IPSec Encrypted tunnel protection ipsec profile default shortcuts
FlexVPN
mGRE over tunnel mode gre multipoint [ipv6] • DMVPN
IPSec* tunnel protection ipsec profile default DMVPN
• Enables tunneling of non-IP protocols (e.g. MPLS, NHRP)

• Required for dynamic mesh scenarios
• "tunnel mode gre ip" is the default on static and dynamic tunnel interfaces
* IPSec protection is optional
IOS Tunnel interface types – without GRE
Tunnel
Encapsulation Configuration Use Cases
Type
• p2p IPSec
Native IPsec tunnel mode ipsec {ipv4 | ipv6}
• FlexVPN Spoke w/o
(SVTI) tunnel protection ipsec profile default shortcuts
• FlexVPN inter-Hub
interface Virtual-Template <id> type tunnel
Native IPsec tunnel mode ipsec {ipv4 | ipv6}
• FlexVPN Hub w/o
(DVTI) IP IPsec IP L4 Data tunnel protection ipsec profile default shortcuts
FlexVPN
Encrypted interface tunnel <id>
Native IPsec • Static Crypto Map
tunnel mode ipsec <ipv4|ipv6>
Multi-SA tunnel protection ipsec profile default replacement for 3rd party
SVTI 16.12.1 tunnel protection ipsec policy ipv4 ACL peers
Native IPsec interface Virtual-Template <id> type tunnel • Dynamic Crypto Map
Multi-SA tunnel mode ipsec {ipv4 | ipv6} replacement for 3rd party
DVTI 15.2(1)T+ tunnel protection ipsec profile default peers
FlexVPN
• Less overhead – no GRE Crypto Map
• Multi-SA support compatibility
• Mixed Mode – IPv4 over IPv6 (tunnel mode ipsec ipv4 v6-overlay) or vice versa
Traffic Permitted by Protection Type
IPv4 & IPv6

IPv4 only IPv6 only IP Multicast Non-IP
(Dual Stack)
Crypto Map Yes Yes No No No
Native IPsec
IPv4 Tunnel Yes Yes No Yes No
(SVTI/DVTI)
Native IPsec
IPv6 Tunnel Yes Yes No Yes No
(SVTI/DVTI)
GRE over IPSec* Yes Yes Yes Yes Yes
Recommended
* With Static and Dynamic Tunnel
FlexVPN - Mode Auto to Rule Them All
• Automatic transport and encapsulation
protocol detection
• Virtual-Access interface dynamically
interface tunnel 1
adjusted to transport/encapsulation type tunnel mode gre ip
IPv4 interface tunnel 1

tunnel mode ipsec ipv4
FlexVPN Hub
IPv6
crypto ikev2 profile ALL-SPOKES interface tunnel 1
tunnel mode gre ipv6
virtual-template 1 mode auto
!
interface virtual-template 1 type tunnel interface tunnel 1
tunnel mode ipsec ipv6
tunnel mode gre ip
FlexVPN Configuration Example
Tu1: 192.168.1.1/32 Tu1: 192.168.1.2/32
10.0.1.0/24 10.0.2.0/24
Router1 Router2
Gi2: 172.16.12.1/24 Gi2: 172.16.23.2/24
Smart
Router1 Defaults IKEv2 Routing – pushing a static
crypto ikev2 authorization policy default
route to a remote peer
route set remote ipv4 10.0.1.0 255.255.255.0
!
crypto ikev2 profile default IKEv2 Profile - repository of
match identity remote address 172.16.23.2 nonnegotiable parameters of
authentication remote pre-share key cisco the IKE SA
authentication local pre-share key cisco
aaa authorization group psk list flex default local Tunnel Interface defining tunnel
!
endpoints, encapsulation and
interface Tunnel1
IPSec protection
tunnel destination 172.16.23.2 BRKSEC-3054 - IOS FlexVPN Remote
tunnel protection ipsec profile default Access, IoT and Site-to-Site advanced Crypto
VPN Designs
Thursday, January 30 | 11:00 AM - 01:00 PM
IKEv2 Dynamic VTI – Configuration
Va1: 192.168.1.1/32 Tu1: 192.168.1.2/32
10.0.1.0/24 10.0.2.0/24
Hub Spoke
Gi2: 10.0.12.1/24 Gi2: 10.0.23.2/24
Hub Spoke
crypto ikev2 authorization policy default crypto ikev2 authorization policy default
route set remote ipv4 10.0.0.0 255.0.0.0 route set remote ipv4 10.0.2.0 255.255.255.0
! !
crypto ikev2 profile default crypto ikev2 profile default
match identity remote any match identity remote address 10.0.12.1
authentication remote pre-share key cisco authentication remote pre-share key cisco
authentication local pre-share key cisco authentication local pre-share key cisco
aaa authorization group psk list flex default aaa authorization group psk list flex default
local local
virtual-template 1 !
! interface Tunnel1
interface Virtual-Template1 type tunnel ip address 192.168.1.2 255.255.255.255
ip unnumbered Loopback1 tunnel source GigabitEthernet2
ip ospf 1 area 1 tunnel mode ipsec ipv4
tunnel source GigabitEthernet2 tunnel destination 10.0.12.1
tunnel mode ipsec ipv4 tunnel protection ipsec profile default
tunnel protection ipsec profile default !
interface GigabitEthernet2
ip address 10.0.23.2 255.255.255.0
IKEv2 Multi-SA Static VTI
IOS XE 16.12.1
• By default, the traffic selector for an SVTI is set to ‘any any’.

• From Cisco IOS XE 16.12.1 we can define and associate an ACL with an SVTI.
• IPSec SAs are created for each non-any-any traffic selector, and thus, multiple SAs
are attached to an SVTI.
IKEv2 Multi-SA SVTI - Configuration
Tu1: 192.168.1.1/32 Tu1: 192.168.1.2/32
172.16.1.0/24 172.30.3.0/24
172.30.4.0/24
172.16.2.0/24
Router1 Router2
Gi2: 10.0.12.1/24 Gi2: 10.0.23.2/24
Router1 Router2
match identity remote 10.0.23.2 match identity remote 10.0.12.1
aaa authorization group psk list flex default local aaa authorization group psk list flex default local
! !
crypto ipsec profile default crypto ipsec profile default
reverse-route reverse-route
! !
ip access-list extended SVTI_ACL ip access-list extended SVTI_ACL
permit ip 172.16.1.0 0.0.0.255 172.30.3.0 0.0.0.255 permit ip 172.30.3.0 0.0.0.255 172.16.1.0 0.0.0.255
permit ip 172.16.2.0 0.0.0.255 172.30.4.0 0.0.0.255 permit ip 172.30.4.0 0.0.0.255 172.16.2.0 0.0.0.255
! !
interface Tunnel1 interface Tunnel1
ip address 192.168.1.1 255.255.255.252 ip address 192.168.1.2 255.255.255.252
tunnel source GigabitEthernet2 tunnel source GigabitEthernet2
tunnel mode ipsec ipv4 tunnel mode ipsec ipv4
tunnel destination 10.0.23.2 tunnel destination 10.0.12.1
tunnel protection ipsec policy ipv4 SVTI_ACL tunnel protection ipsec policy ipv4 SVTI_ACL
tunnel protection ipsec profile default tunnel protection ipsec profile default
IKEv2 Multi-SA Dynamic VTI
15.2(1)T+
• IKEv2 DVTI supports multiple IPsec SAs proposed by the initiator – Multi-SA DVTI
• Multi-SA DVTI is interoperable with third-party devices that implement only crypto
maps.
• DVTI allow per peer features to be applied on a dedicated interface.
Multi-SA DVTI - security-policy limit
Hub# show crypto session detail
IPSEC FLOW: permit ip 172.16.254.0/255.255.255.0 172.16.4.0/255.255.255.0
Active SAs: 2, origin: crypto map
Inbound: #pkts dec'ed 4 drop 0 life (KB/Sec) 4607999/3353
Outbound: #pkts enc'ed 4 drop 0 life (KB/Sec) 4607999/3353
IPSEC FLOW: permit ip 172.16.254.0/255.255.255.0 172.16.3.0/255.255.255.0
Active SAs: 2, origin: crypto map
Inbound: #pkts dec'ed 4 drop 0 life (KB/Sec) 4607999/3342
Outbound: #pkts enc'ed 4 drop 0 life (KB/Sec) 4607999/3342
crypto ipsec profile default

set security-policy limit 2
set ikev2-profile default 172.16.4.0/24
172.16.3.0/24
172.16.254.0/24
Hub Spoke 172.16.2.0/24
Router# debug crypto ipsec

(…)
*Nov 28 12:12:40.609: IPSEC(vti_multi_sa): Maximum SA limit has reached. Dropping the connection
IKEv2 Multi-SA DVTI - Configuration
Hub – IKEv2 Multi-SA DVTI Spoke – IKEv2 Crypto Map

match identity remote any match identity remote any
aaa authorization group psk list default default aaa authorization group psk list default default
virtual-template 1 !
! access-list 100 permit ip 10.0.12.0/24 10.0.0.0/16
interface Virtual-Template1 type tunnel access-list 100 permit ip 10.0.13.0/24 10.0.0.0/16
ip unnumbered Loopback1 access-list 100 permit ip 10.0.14.0/24 10.0.0.0/16
tunnel source GigabitEthernet2 !
tunnel mode ipsec ipv4 crypto map CMAP 10 ipsec-isakmp
tunnel protection ipsec profile default set peer 10.0.0.1
set ikev2-profile default
match address 100
!
interface GigabitEthernet2
ip address 172.16.1.1 255.255.255.0
crypto map CMAP
FlexVPN and DMVPN comparison
FlexVPN DMVPN
DVTI mGRE
mGRE
SVTI
• DMVPN uses mGRE interface while FlexVPN is using p2p tunnels – SVTI or DVTI.
• In DMVPN crypto is optional, FlexVPN is tied to crypto configuration and requires IKEv2.
• If direct spoke-to-spoke is not needed, GRE encapsulation can be omitted for FlexVPN.
FlexVPN and DMVPN comparison
Compatibility with any IKEv2-based third-party VPN vendors
IKEv2 routing – very light solution fit for IoT
Point-to-point tunnel interfaces instead of mGRE
Granular per tunnel configuration of QoS, ZBF, VRF, etc. (AAA server)
Simplified use of NHRP – no NHS registration
One way of configuring NHRP compared to 3 phases in DMVPN
Demo – FlexVPN
Conclusion
Designing Fault-Tolerant IPSec VPNs
• The design depends on what faults the VPN needs to be able to withstand.
• From the fault-tolerance perspective, the design can be broken down into:
• Transport Network – connectivity between IPSec Gateways
• Access Link – link/device that connects the IPSec gateway to the Transport Network
• IPSec Gateway
VPN VPN
Router Router
Branch Location Design
• Single-Router, Single-Link • Single-Router, Dual-Link
• Dual-Router, Dual-Link
FlexVPN Hub Redundancy – active-active
Hub1 Hub2 Routing Based Resiliency
Dynamic Routing
(BGP, EIGRP, OSPF, RIP…)
IKEv2 Routing
FlexVPN FlexVPN
Spoke Only
interface Tunnel1
(…) In case of link/hub failure, dynamic routing
tunnel destination <hub1-nbma-ip> protocol timers or IKEv2 DPD timers determine
interface Tunnel2 the convergence time
(…)
tunnel destination <hub2-nbma-ip>
Tunnel Origin/Destination Dynamic Modification
FlexVPN crypto ikev2 client flexvpn <name>
Tunnel Only client connect tunnel 1
Origin/Destination peer 1 <address> track 10 up
peer 2 <address> track 10 down
source 1 <primary interface> track 100
source 2 <cellular interface> track 200
Tunnel Peer Selection Tunnel Source Selection !
interface Tunnel1
(…)
Backup Peer List Tunnel Pivoting tunnel source dynamic
tunnel destination dynamic
Static or Downloadable
Peer State Tracking

ISP1
GigE0/0 Hub2
Peer re-activation
Backup Groups Client Hub1

FastE2/0 ISP2
Load-Balancing
DMVPN Hub Redundancy
DMVPN DMVPN
Dual hub – Single Cloud Dual hub – Dual Cloud
interface Tunnel1 interface Tunnel1

(…) (…)
ip nhrp nhs <hub-tunnel> nbma <hub1-nbma-ip> multicast ip nhrp nhs <hub-tunnel> nbma <hub1-nbma-ip> multicast
ip nhrp nhs <hub-tunnel> nbma <hub2-nbma-ip> multicast
interface Tunnel2
(…)
ip nhrp nhs <hub-tunnel> nbma <hub2-nbma-ip> multicast
Scaling beyond the limits of one hub router
Static assignment active/standby cluster
• Multiple clusters for scale
• 1+1 redundancy
Cluster1
Inter-DC Link Cluster2
Hub1 Hub2 Hub3 Hub4
Spoke Spoke Spoke Spoke
Static assignment active/standby cluster
• Multiple clusters for scale
• 1+1 redundancy
Cluster1
Inter-DC Link Cluster2
Hub1 Hub2 Hub3 Hub4
Primary Tunnel
Backup Tunnel
IKEv2 Load Balancer
• IKEv2 Load Balancer Components:
• Cluster Load Balancing (CLB)
3. CLB Master sends a redirect
• Hot Standby Router Protocol (HSRP) to client to Hub 3
2. CLB Master selects the LLG (Hub3)
• IKEv2 Redirect
• N+1 redundancy (N<5) HSRP Standby HSRP Active HSRP Standby
CLB Master
• Easy to configure and cost-effective CLB Slave CLB Slave
Hub1 Hub1 Hub2 Hub3
1. Client sends IKE SA_INIT with

REDIRECT_SUPPORTED to VIP
4. Client establishes IKEv2

session with LLG Hub (Hub 3)
Spoke
Server Load Balancing
• SLB (Server Load Balancing) Hub1 Hub2 Hub3
• N+1 redundancy with N >> 5

• SLB options:
• Nexus (Intelligent Traffic Director) SLB
• F5 SLB
• A10 Thunder SLB
• Today, we have designs in 100K+ (250K

known), tested with 1M.
Spoke
Bringing it all together – Geo LB + SLB
America Europe
Hub1 Hub1
SLB SLB
Hub2 Hub2
Hub3 Hub3
Spoke Spoke
Primary Tunnel
Backup Tunnel
• Large or small number of branch offices?
• Small Scale -> Static Tunnels
• Large Scale -> Dynamic Tunnels on Hub + Clustering, DNS Balancing, IKEv2 Load Balancer, SLB
• What level of high availability is required?

• Is direct spoke-to-spoke required?
• What protocols will be transported?
• Non-IP –> GRE required
• Dual stack -> GRE required
• 3rd party support?

• Crypto Map -> FlexVPN (Multi-SA SVTI/DVTI)
• DMVPN or FlexVPN?
Conclusion
Firewall - Asymmetric Traffic Challenge
• Symmetric flow example:
inside outside
SYN inside
SYN/ACK
SYN
SYN/ACK same-security-traffic is not applicable on FTD.
Traffic is allowed for both inter- and intra-interface
• Asymmetric flow examples: SYN

outside1
inside outside inside
outside2
With IPS-Only asymmetry
SYN is not a problem. We just
SYN/ACK
SYN/ACK need to reassemble the
packet.
FTD Interface Mode FTD Deployment Mode Description Real traffic can be
(inherited from ASA) FW + IPS dropped?
Routed Routed Full ASA and Snort Yes
checks
ASA
Switched Routed or Transparent Full ASA and Snort Yes

checks
Inline Set Routed or Transparent Partial ASA and full Snort Yes
checks
Inline Set with Tap Routed or Transparent Partial ASA and full Snort No
FirePower
checks
Passive Routed or Transparent Partial ASA and full Snort No
checks
Passive (ERSPAN) Routed Partial ASA and full Snort No
checks
IPS-only
Symmetric VPN flow – Spoke to DC
FTD in Transparent
SYN
SYN ACK DC
outside
inside
2.
Hub1 Hub2
VPN
Spoke1
Spoke3
Spoke2
Asymmetric VPN traffic flow example?
FTD in Transparent mode
SYN
SYN ACK
DC
outside
inside
2.
inside outside
Hub1 Hub2
SYN
SYN/ACK
VPN
Spoke1
Spoke3
Spoke2
FTD on a stick
FTD in Routed mode
DC
outside
inside
2.
Hub1 Hub2
VPN
Spoke1
Spoke3
Spoke2
Protecting direct spoke-spoke traffic
Option 1 – spoke being an FTD/ASA
Option 2 – spoke being an IOS router:

• IOS Firewall
• ZBF
• Application Aware ZBF (XE16.9.1) Hub1
• Snort IPS*
• URL Filtering*
• Cisco Umbrella
Spoke1 Spoke2
• ETA (Encrypted Traffic Analytics)
* Available only on selected platforms BRKSEC-3629 © 2020 Cisco and/or its affiliates. All rights reserved. Cisco Public 59
Conclusion
High Availability for Firepower Threat Defense
• FTD High Availability (failover), requires:

• two identical FTD devices HA Link
• dedicated failover link and, optionally, a state link
FTD FTD
• FTD supports Active/Standby stateful failover
Active Standby
• Supports all NGFW/NGIPS interface modes
• Provides redundancy but not scalability
Clustering for the Firepower Threat Defense
• Grouping of multiple FTD units together as a single logical device.

• Supported only on the Firepower 9300 and the Firepower 4100 series.
• Provides increased throughput and redundancy of multiple devices.
• All packets for a flow are redirected to connection Owner.
Cluster Control Link
Firepower NGFW Clustering Deep Dive - BRKSEC-3032

Friday, January 31 | 11:30 AM - 01:30 PM
FTD FTD FTD

Master Slave Slave
Conclusion
Example Design Requirements and Assumptions
• Large Scale Deployment - 40000 locations
• Hub-and-spoke topology
• Provide security using cryptographically protected tunnels.
• Headend redundancy with 15 seconds convergence
• Mix of ASA and IOS routers on branch locations
• IPS inspection for the spoke-to-spoke traffic using FTD …
Proposed Solution
• FlexVPN Hub-and-Spoke topology
• HA and scalability using active/standby clusters with BGP
• PBR to redirect spoke-spoke traffic to FTD on a stick
High Level Design – Topology
Hub-and-spoke + Large Scale
Cluster 1
….. Cluster 4
HA or
FTD1 FTD2
Cluster
Hub1 Hub2 Hub4

Hub3
Spoke1 ….. Spoke10000

Spoke1
Spoke10000
Spoke2 Spoke2
BGP routing considerations
Headend redundancy with 15 seconds convergence
• Two tunnels primary and secondary.

S 172.16.1.1 is directly connected, Virtual-Access1
B 192.168.102.0/24 [200/0] -> 172.16.1.7
• Decrease BGP timers for fast convergence.
• For the BGP neighborship we need IKEv2 Virtual-Access1
172.16.1.253/32 Hub1
routing to exchange the addresses that will be 10.0.0.254
used for peering. iBGP
• BGP listen range on Hub. 10.0.0.1
Tunnel1
172.16.1.1/32 Spoke1
• Route reflector between Hubs.
S 172.16.1.253/32 -> Tunnel1
• Summary advertised to spokes. B 192.168.0.0/16 [200/0] -> 172.16.1.254
FTD Routed mode on a stick
IPS inspection for the spoke-to-spoke traffic using FTD
Cluster 1
FTD
interface Virtual-Access2
ip policy route-map FW
tunnel mode ipsec ipv4 2
tunnel destination 10.0.0.1 inside / 172.16.254.254/24
no tunnel protection ipsec initiate
3 2.
172.16.254.1/24
B 192.168.102.0/24 [200/0] ->Hub2172.16.1.7
Hub1 S 172.16.1.7 is directly connected, Virtual-Access1
172.16.1.254/32 172.16.1.253/32
1 4
B 192.168.0.0/16 [200/0] -> 172.16.1.254

S 172.16.1.254/32 -> Tunnel1
S 172.16.1.253/32 -> Tunnel2
Spoke1
192.168.101.0/24 Spoke2
192.168.102.0/24
Spoke router configuration – IOS Example
crypto ikev2 profile default
match identity remote fqdn domain hub
identity local fqdn Spoke1.router FTD
authentication local pre-share key <PSK>
authentication remote pre-share key <PSK>
aaa authorization group psk list FlexVPN default local
! inside / 172.16.1.1/24
interface Tunnel101
tunnel destination 10.0.0.253 172.16.1.253/24 172.16.1.254/24
tunnel protection ipsec profile default Primary Tunnel
! Hub2
Hub1
interface Tunnel102
tunnel source GigabitEthernet2 10.0.0.253
tunnel destination 10.0.0.254 10.0.0.254
tunnel protection ipsec profile default Secondary Tunnel
10.0.0.1
!
router bgp 65000
timers bgp 5 15 Reduced BGP 10.0.0.2
neighbor 172.16.1.253 remote-as 65000 timers for faster
neighbor 172.16.1.254 remote-as 65000 Spoke1 (Router)
convergence Spoke3
! 192.168.101.0/24
address-family ipv4 192.168.103.0/24
Spoke2 (ASA)
network 192.168.101.0 mask 255.255.255.0
(…) 192.168.102.0/24
Spoke router configuration – ASA Example
hostname Spoke2 interface Tunnel1
domain-name Spoke2 nameif VTI Primary Tunnel
! IKE Identity ip address 172.16.1.5 255.255.255.254
crypto isakmp identity hostname tunnel source interface outside
! tunnel destination 10.0.0.253
crypto ikev2 policy 10 tunnel mode ipsec ipv4
encryption aes-256 tunnel protection ipsec profile VTI
integrity sha384 IKEv2 and IPSec !
group 19 algorithms interface Tunnel2
prf sha384 nameif VTI2 Secondary Tunnel
crypto ikev2 enable outside ip address 172.16.1.7 255.255.255.254
! tunnel source interface outside
crypto ipsec ikev2 ipsec-proposal IPSEC_PROP tunnel destination 10.0.0.254
protocol esp encryption aes tunnel mode ipsec ipv4
protocol esp integrity sha-1 tunnel protection ipsec profile VTI
! pre-shared-keys !
crypto ipsec profile VTI route VTI 172.16.1.253 255.255.255.255 172.16.1.253 1
set ikev2 ipsec-proposal IPSEC_PROP route VTI2 172.16.1.254 255.255.255.255 172.16.1.254 1
! !
tunnel-group 10.0.0.253 type ipsec-l2l router bgp 65000 Instead of IKEv2
tunnel-group 10.0.0.253 ipsec-attributes timers bgp 5 15 0 routing
ikev2 remote-authentication pre-shared-key cisco address-family ipv4 unicast
ikev2 local-authentication pre-shared-key cisco neighbor 172.16.1.253 remote-as 65000
! neighbor 172.16.1.253 activate
tunnel-group 10.0.0.254 type ipsec-l2l neighbor 172.16.1.254 remote-as 65000
tunnel-group 10.0.0.254 ipsec-attributes neighbor 172.16.1.254 activate
ikev2 remote-authentication pre-shared-key cisco redistribute connected
ikev2 local-authentication pre-shared-key cisco
Hub’s IKEv2 profile selection
crypto ikev2 name-mangler extract-domain
crypto ikev2 profile router fqdn domain
match identity remote fqdn domain router
authentication remote pre-share key cisco
crypto ikev2 authorization policy router
route set interface
aaa authorization group psk list FlexVPN name-mangler extract-domain
crypto ikev2 name-mangler extract-host
crypto ikev2 profile firewall
fqdn hostname
match identity remote fqdn domain firewall
authentication local pre-share key cisco crypto ikev2 authorization policy Spoke2
aaa authorization group psk list FlexVPN name-mangler extract-host route set local ipv4 172.16.1.5
virtual-template 1 mode auto 255.255.255.255
no config-exchange request
Store it on
Hub1 an external
AAA server
Required only if we want to terminate

ASA/FTD* because they do not
support IKEv2 config exhange
Spoke1.router Spoke2.firewall
* VTI for FTD on 6.7 roadmap BRKSEC-3629 © 2020 Cisco and/or its affiliates. All rights reserved. Cisco Public 70
Hub router configuration - with PBR
aaa new-model interface Virtual-Template1 type tunnel
aaa authorization network FlexVPN local ip unnumbered Loopback1
! ip policy route-map FW
access-list 123 permit ip 192.168.0.0 0.0.255.255 any tunnel protection ipsec profile default
! !
route-map FW permit 10 router bgp 65000
match ip address 123 bgp listen range 172.16.1.0/24 peer-group Flex
set ip next-hop 172.16.254.254 PBR bgp listen limit 10000
! timers bgp 5 15
crypto ikev2 profile router neighbor Flex peer-group
match identity remote fqdn domain router neighbor Flex remote-as 65000
authentication remote pre-share key cisco !
authentication local pre-share key cisco address-family ipv4
aaa authorization group psk list FlexVPN name-mangler redistribute connected
extract-domain neighbor Flex activate
virtual-template 1 mode auto neighbor Flex route-reflector-client
! neighbor Flex next-hop-self all
crypto ikev2 profile firewall exit-address-family
match identity remote fqdn domain firewall
aaa authorization group psk list FlexVPN name-mangler
Separate IKEv2 profiles
extract-domain
for routers and firewalls iBGP with listen range
no config-exchange request
Interface and routing verification
Hub1# show derived-config interface Virtual-Access 1
Building configuration...
Derived configuration : 197 bytes

!
interface Virtual-Access1 Derived from the Virtual-Access1
ip unnumbered Loopback1 Virtual-Template 172.16.1.253/32 Hub1
ip policy route-map FW 10.0.0.254
tunnel protection ipsec profile default 10.0.0.1
no tunnel protection ipsec initiate Tunnel1
172.16.1.1/32 Spoke1
Hub1# show ip route

S 172.16.1.1/32 is directly connected, Virtual-Access1 192.168.101.0/24
B 192.168.101.0/24 [200/0] via 172.16.1.1, 00:25:06
Spoke1# show ip route

S 172.16.1.254/32 is directly connected, Tunnel1
S 172.16.1.253/32 is directly connected, Tunnel2
B 192.168.0.0/16 [200/0] via 172.16.1.254, 00:07:27
FTD Deployment Modes Overview
Conclusion
IPSec Security Association Lifetime
• The IPSec SA rekey can be triggered from two angles:

• From a time-based perspective (lifetime in seconds of the SAs). Default value – 3600s.
• From a traffic volume perspective (lifetime in kilobytes of data processed by the SAs). Default value ~ 4GB.
• Block Ciphers become unsafe with more than 2n/2 blocks of message encrypted.
• 3DES is broken
• With AES encryption algorithms, the volume-based re-key is justified only if more
than 264 blocks of 16 bytes are encrypted = 256 exabytes of data.
crypto ipsec profile IPsec-Profile

set security-association lifetime kilobytes disable
Recommended
IPSec Anti-Replay Window Size Tuning
• When QoS is used, packets from different traffic classes can be queued and
delivered out of order by a large number, bigger than anti-replay window size.
• There are a couple of possibilities to address this issue:
• Increase the IPsec anti-replay window size (default is 64 packets).
crypto ipsec security-association replay window-size 1024
• Disable the anti-replay protection mechanism.

crypto ipsec security-association replay disable
• IPSec Anti-Replay Checking with Multiple Sequence Number Spaces
IPSec Anti-Replay Checking with Multiple
Sequence Number Spaces CSR 16.6.1
ISR4k 16.7.1
ASR1k 16.8.1
• IPSec Anti-Replay multi-SNS is enabled with:
crypto ipsec security-association multi-sn
• The feature must be configured on both ends.

• The tunnel interface needs to be flapped.
• First 4 bits from SPI number are used to map DSCP to SNS
• Different SPI values even though this is the same SA.

0xb80acc20
0x180acc20
Call Admission Control for IKE
• For IKEv1 the default number of in-negotiation IKE connections is unlimited.
Router(config)# crypto call admission limit ike in-negotiation-sa 40
• For IKEv2 the default setting is 40.
Router(config)# crypto ikev2 limit max-in-negotiation-sa 40
• For large scale consider starting at 100 at reduce/increase based on results.
IPsec & Fragmentation
• The goal is to avoid post-encrypt fragmentation by controlling pre-encrypt

fragmentation
• Incorrect MTU/MSS settings lead to problems with performance and packet drop.
• Proper MTU/MSS tuning helps achieve best performance and to avoid
fragmentation.
• IPSec Overhead Calculator Tool https://cway.cisco.com/tools/ipsec-overhead-calc/
interface Tunnel1
ip mtu 1400
tcp adjust-mss 1360 Recommended
settings covering
majority of scenarios
IPSec Overhead Calculator Tool
IPsec & Fragmentation - Crypto Map
Fragmentation with Crypto maps
(Crypto pre-fragmentation)
WAN interface with

crypto map applied
LAN WAN
INTF RIB/FIB
INTF
Crypto • Crypto pre-fragmentation based on SA-MTU

Layer
• SA MTU = (Crypto map interface IP MTU –
Encryption Overhead)
Crypto • SA MTU displayed in ‘show crypto ipsec sa’
Engine
IPsec & Fragmentation – Tunnel Protection
Fragmentation with Tunnel protection
LAN Tunnel WAN

INTF Interface INTF
• Pre-encap fragmentation based on Tunnel IP MTU

• Tunnel IP MTU interface Tunnel <>
• Configured using ‘ip mtu <>’ on tunnel interface ip address <>
ip mtu <>
• If not configured,
(Tunnel egress interface IP MTU –
Tunnel encap overhead - Encryption Overhead)
• Tunnel IP MTU displayed in ‘show ip interface tunnel <>’
• Crypto pre-fragmentation & SA MTU are not relevant for tunnel protection
QoS Considerations – VPN Hub
• Implementing quality of service (QoS) on the FlexVPN Hub is often necessary, because
Spoke’s inbound physical bandwidth can become congested.
• The Hub has a much faster connection that does not become congested as fast as the
Spoke connection (that is, the Hub can overrun the Spoke).
10Gbps shaper
10Gbps 500Mbps
Hub Spoke
Step 1 – configure shaping policy on physical interface

Step 2 – configure per-spoke QoS policies which will get applied to virtual-access
interfaces
QoS Considerations – VPN Spoke
• QoS on FlexVPN Spoke is setup to shape/police outbound traffic to ensure that the spoke
doesn't overrun its own outbound bandwidth.
• This is an aggregate (across all tunnels) policy that is applied to the outbound physical
interface on the spoke.
10Gbps shaper
10Gbps 500Mbps
Hub Spoke
Step 1 – configure physical interface QoS policy on FlexVPN Spoke
FTD Deployment Modes Overview
Conclusion
Conclusion
• Many VPN Solutions; asses the design requirements before selecting the best
option.
• Evaluate failure scenarios and acceptable convergence time.
• Understand the packet flow to properly insert a security appliance (Firewall, IPS).
• Keep it simple.
• Follow the IPSec VPN best practices to achieve best performance and avoid
problems.
Complete your
online session
survey • Please complete your session survey
after each session. Your feedback
is very important.
• Complete a minimum of 4 session
surveys and the Overall Conference
survey (starting on Thursday) to
receive your Cisco Live t-shirt.
• All surveys can be taken in the Cisco Events
Mobile App or by logging in to the Content
Catalog on ciscolive.com/emea.
Cisco Live sessions will be available for viewing on

demand after the event at ciscolive.com.
Continue your education
Demos in the
Walk-In Labs
Cisco Showcase
Meet the Engineer

Related sessions
1:1 meetings
Thank you

Brksec 3629

Uploaded by

Copyright:

Available Formats

Brksec 3629

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Brksec 3629

Uploaded by

Copyright:

Available Formats

Designing IPSec VPNs with

Firepower Threat Defense integration

• There are slides in your PDF that will not be presented.

Overlay IPSec VPNs Tunnel-less Encryption

GRE over IPSec

ASA Yes No Yes Yes No No**

FTD Yes No Yes Yes* No No**

Not Recommended * On FTD 6.7 roadmap

crypto isakmp policy 10 crypto map outside_map 10 ipsec-isakmp

IP Private L4 Data IP Public ESP IP Private L4 Data

interface Eth0/0 interface Eth0/1 Encrypted

• IOS-XE IKEv2 multi-SA SVTI replaces Static Crypto Map

• Tunnel Interface interconnects underlay and overlay network.

IP Private L4 Data IP Public GRE IP Private L4 Data

interface Eth0/0 interface Eth0/1

Interface feature (NAT, PBR, QoS, NetFlow, ...)

IP Private L4 Data IP Public GRE IP Private L4 Data

interface Eth0/0 interface Eth0/1

Interface feature (NAT, PBR, QoS, NetFlow, ...)

GRE over IPSec IPsec Native CLI

Dynamic Virtual-Template Virtual-Template interface Tunnel <>

Static Tunnel Interface

interface Virtual-Template1 type tunnel

VT1 tunnel source GigabitEthernet2

Tu Static Tunnel VT Virtual Template VA Virtual Access

• Enables tunneling of non-IP protocols (e.g. MPLS, NHRP)

* IPSec protection is optional

IPv4 & IPv6

Crypto Map Yes Yes No No No

GRE over IPSec* Yes Yes Yes Yes Yes

IPv4 interface tunnel 1

• By default, the traffic selector for an SVTI is set to ‘any any’.

crypto ipsec profile default

Router# debug crypto ipsec

Hub – IKEv2 Multi-SA DVTI Spoke – IKEv2 Crypto Map

Compatibility with any IKEv2-based third-party VPN vendors

IKEv2 routing – very light solution fit for IoT

Point-to-point tunnel interfaces instead of mGRE

Simplified use of NHRP – no NHS registration

One way of configuring NHRP compared to 3 phases in DMVPN

• Single-Router, Single-Link • Single-Router, Dual-Link

Hub1 Hub2 Routing Based Resiliency

Peer State Tracking

Backup Groups Client Hub1

Dual hub – Single Cloud Dual hub – Dual Cloud

interface Tunnel1 interface Tunnel1

Hub1 Hub2 Hub3 Hub4

Spoke Spoke Spoke Spoke

Spoke Spoke Spoke Spoke

Hub1 Hub2 Hub3 Hub4

Hub1 Hub1 Hub2 Hub3

1. Client sends IKE SA_INIT with

4. Client establishes IKEv2

• SLB (Server Load Balancing) Hub1 Hub2 Hub3

• N+1 redundancy with N >> 5

• Today, we have designs in 100K+ (250K

• What level of high availability is required?

• 3rd party support?

• Asymmetric flow examples: SYN