Security Policies in vManage

Objective

In this lesson you will configure and verify the security building blocks that an SD‑WAN manager (vManage) relies on for enforcing security policies on a spoke firewall. We will configure the IKEv2 and IPsec profiles, create IPsec Virtual Tunnel Interfaces (VTI), and prepare BGP route learning so that vManage can map security zones and IPS profiles to the proper interfaces. This matters in production because security policies in an SD‑WAN are applied to logical interfaces (VTIs/loopbacks) — if the device-side tunnel and policy anchors are not correct, policy enforcement and route distribution will fail. Real-world scenario: an enterprise spoke must present two redundant VTIs to two hub peers, with IPSec policy and BGP route exchange so that centralized security policies can be applied per-VTI by the SD‑WAN controller.

Topology (quick recap)

The topology used across this lab series remains the same. This lesson does not add new physical devices; it configures the spoke firewall interfaces and IPs used earlier.

ASCII topology (showing exact IPs on every interface)

       Internet (underlay)
            |
            | (outside)
      [Spoke-FW]-----------------------------------------
      | outside: (public IP)                            |
      | Tunnel1 (VTI) IP: 172.16.1.5/31  <-----> 172.16.1.253  [Hub-1]
      | Tunnel2 (VTI2) IP: 172.16.1.7/31 <-----> 172.16.1.254  [Hub-2]
      | Loopback1 (alt) IP: 172.16.1.5/32
      | Loopback2 (alt) IP: 172.16.1.7/32

Device Table

Device	Role	Notes
Spoke-FW	Spoke firewall (ASA/FTD syntax)	Configured with VTIs: Tunnel1/Tunnel2; peers 10.0.0.253 and 10.0.0.254
Hub-1	Hub VPN peer	Peer IP 10.0.0.253 (remote)
Hub-2	Hub VPN peer	Peer IP 10.0.0.254 (remote)

Quick Recap

• Previous lessons ensured underlay connectivity and basic IPsec reachability.
• This lesson uses the same IPs and interface names: Tunnel1 (172.16.1.5/31) to peer 10.0.0.253 and Tunnel2 (172.16.1.7/31) to peer 10.0.0.254.
• We will create IKEv2/IPsec profiles and BGP so route learning and security policy attachment work correctly.

Key Concepts (theory before touching CLI)

• IKEv2: Establishes the cryptographic association for IPsec. When you enable an IKEv2 policy, the device negotiates phase‑1 parameters (encryption, integrity, DH group, PRF). IKEv2 sessions send Exchange messages and maintain state; rekeys occur per policy timers (not shown here but relevant in production).
• IPsec proposal/profile: The IPsec proposal defines ESP algorithms (encryption, integrity) used for tunnel encryption. The ipsecprofile ties the proposal to a tunnel so the kernel applies the ESP transform to traffic.
• VTI (IPsec Virtual Tunnel Interface): A VTI creates a point‑to‑point logical interface that carries encrypted traffic; IP routing (static or dynamic) runs over the VTI. In production SD‑WAN, VTIs are the primary overlay interface and are the anchor for zone-based firewall and IPS policy attachment.
• BGP over VTIs: Running BGP over VTI allows dynamic route learning from hub peers. When BGP neighbors are activated over the VTI IPs (172.16.1.253/.254), routes learned can be redistributed and used for policy decisions. BGP establishes TCP sessions initiated after the DTLS/ESP path exists.
• Think of a VTI like a virtual cable between two routers — the IPsec profile secures the cable, and BGP or static routes decide what traffic travels over that cable.

Tip: In production, central controllers (vManage) reference the VTI/loopback addresses when mapping zone‑based rules and IPS profiles. If the VTI addresses or ipunnumbered mappings are wrong, policies won’t attach correctly.

---

Step-by-step configuration

Step 1: Configure IKEv2 Policy and IPsec Proposal/Profile

What we are doing: Create the cryptographic building blocks for tunnel establishment: an IKEv2 policy for phase‑1 and an IPsec proposal and profile for phase‑2. These are required before configuring VTIs that reference the profile; they ensure both peers can negotiate identical algorithms.

configure terminal
crypto ikev2 policy 10
 encryption aes-256
 integrity sha384
 group 19
 prf sha384
exit
crypto ikev2 enable outside
crypto ipsec ikev2 ipsec-proposal IPSEC_PROP
 protocol esp encryption aes
 protocol esp integrity sha-1
exit
crypto ipsec profile VTI
 set ikev2 ipsec-proposal IPSEC_PROP
exit
end

What just happened:

• crypto ikev2 policy 10 ... created an IKEv2 policy with AES‑256, SHA‑384 integrity and DH group 19; this governs phase‑1 negotiation parameters. The crypto ikev2 enable outside command binds IKEv2 to the outside interface so IKEv2 packets (UDP 500/4500) are accepted on that interface.
• The crypto ipsec ikev2 ipsec-proposal IPSEC_PROP block defined the ESP transforms (AES encryption and SHA‑1 for integrity) used in phase‑2. The crypto ipsec profile VTI associates the IPsec proposal with a named profile (VTI) so tunnel interfaces can reference the profile.

Real-world note: Use strong algorithms consistent with your enterprise policy. In some networks, SHA‑384 and AES‑256 are mandatory for hub‑to‑spoke tunnels.

Verify:

show crypto ikev2 policy
Policy: 10
  Encryption: AES-256, Integrity: SHA384, PRF: SHA384, DH Group: 19

---

Step 2: Configure IPsec Tunnel‑Group Entries for Hub Peers

What we are doing: Define the two remote hub peers (10.0.0.253 and 10.0.0.254) as IPsec tunnel‑group entries with pre‑shared keys. This ties peer IPs to authentication material used during IKEv2 negotiation.

configure terminal
tunnel-group 10.0.0.253 type ipsec-l2l
tunnel-group 10.0.0.253 ipsec-attributes
 ikev2 remote-authentication pre-shared-key cisco
 ikev2 local-authentication pre-shared-key cisco
 ikev2 route set interface
exit
tunnel-group 10.0.0.254 type ipsec-l2l
tunnel-group 10.0.0.254 ipsec-attributes
 ikev2 remote-authentication pre-shared-key cisco
 ikev2 local-authentication pre-shared-key cisco
 ikev2 route set interface
exit
end

What just happened:

• Each tunnel-group <peer> type ipsec-l2l block registers a static peer for a LAN‑to‑LAN IPsec VPN.
• ikev2 remote-authentication pre-shared-key cisco and ikev2 local-authentication pre-shared-key cisco set the pre‑shared key for mutual authentication; the shared key is “cisco” per the reference material.
• ikev2 route set interface tells the device to set routing attributes or accept routes learned via IKEv2 (used in some implementations for IKE route learning).

Real-world note: Pre‑shared keys should be changed from defaults and centrally managed (e.g., with PSK vaults). For SD‑WAN, controller-managed keying is preferred.

Verify:

show running-config tunnel-group
tunnel-group 10.0.0.253 type ipsec-l2l
tunnel-group 10.0.0.253 ipsec-attributes
 ikev2 remote-authentication pre-shared-key cisco
 ikev2 local-authentication pre-shared-key cisco
 ikev2 route set interface
tunnel-group 10.0.0.254 type ipsec-l2l
tunnel-group 10.0.0.254 ipsec-attributes
 ikev2 remote-authentication pre-shared-key cisco
 ikev2 local-authentication pre-shared-key cisco
 ikev2 route set interface

---

Step 3: Create Tunnel Interfaces (VTIs) and Protect with the IPsec Profile

What we are doing: Configure two tunnel interfaces — Tunnel1 and Tunnel2 — with the VTI IPs shown in the topology, point them to each hub peer, and attach the ipsec profile. These interfaces are where SD‑WAN/vManage will map zone and IPS policies.

configure terminal
interface Tunnel1
 nameif VTI
 ip address 172.16.1.5 255.255.255.254
 tunnel source interface outside
 tunnel destination 10.0.0.253
 tunnel mode ipsec ipv4
 tunnel protection ipsec profile VTI
exit
interface Tunnel2
 nameif VTI2
 ip address 172.16.1.7 255.255.255.254
 tunnel source interface outside
 tunnel destination 10.0.0.254
 tunnel mode ipsec ipv4
 tunnel protection ipsec profile VTI
exit
end

What just happened:

• interface Tunnel1 and interface Tunnel2 created two logical VTI interfaces.
• nameif assigns a logical name used by policy frameworks. vManage and ASA/FTD reference these nameif values when attaching zone‑based firewall or IPS rules.
• The ip address commands give each VTI its overlay IP. The /31 mask (255.255.255.254) creates a point‑to‑point address between spoke and hub addresses (172.16.1.5 ↔ 172.16.1.253 and 172.16.1.7 ↔ 172.16.1.254).
• tunnel protection ipsec profile VTI binds the IPsec profile created earlier; once IKEv2 completes, traffic on the interface will be encrypted with that profile.

Real-world note: Some deployments prefer ipunnumbered on the tunnel and loopback /32 anchors. Both methods are supported — loopback/ipunnumbered simplifies policy mapping when VTIs are transient.

Verify:

show interface Tunnel1
Interface Tunnel1 "VTI", is up, line protocol is up
  Internet address is 172.16.1.5/31
  Tunnel source: outside, Tunnel destination: 10.0.0.253
  Tunnel mode: ipsec ipv4
  IPSEC profile: VTI

show interface Tunnel2
Interface Tunnel2 "VTI2", is up, line protocol is up
  Internet address is 172.16.1.7/31
  Tunnel source: outside, Tunnel destination: 10.0.0.254
  Tunnel mode: ipsec ipv4
  IPSEC profile: VTI

---

Step 4: Add VTI Static Routes (if not using IKEv2 route learning)

What we are doing: Add next‑hop routes for the hub VTI addresses so the local routing table knows how to reach the hub VTI addresses. In some deployments, static VTI routes are required unless route learning via IKEv2/BGP is configured.

configure terminal
route VTI 172.16.1.253 255.255.255.255 172.16.1.253 1
route VTI2 172.16.1.254 255.255.255.255 172.16.1.254 1
end

What just happened:

• The route commands create host routes toward each hub VTI address with the outgoing interface tied to the corresponding VTI context (VTI or VTI2). This ensures the device has a route to the hub overlay IP so IKE/BGP can form.

Real-world note: If IKEv2 route learning is enabled on both ends, these static routes may not be necessary and can be omitted to reduce static configuration needs.

Verify:

show route
S*  172.16.1.253/32 is directly connected, Tunnel1
S*  172.16.1.254/32 is directly connected, Tunnel2

---

Step 5: Configure BGP for Route Exchange over VTIs

What we are doing: Configure BGP with neighbors on the VTI IPs so the spoke can dynamically learn overlay routes from the hub peers for centralized policy enforcement.

configure terminal
router bgp 65000
 timers bgp 5 15 0
 address-family ipv4 unicast
  neighbor 172.16.1.253 remote-as 65000
  neighbor 172.16.1.253 activate
  neighbor 172.16.1.254 remote-as 65000
  neighbor 172.16.1.254 activate
 exit-address-family
 redistribute connected
end

What just happened:

• router bgp 65000 enters the BGP process with AS 65000 used on the spoke.
• timers bgp 5 15 0 adjusts the keepalive/hold/other timers to faster values (useful for lab/test environments; production networks should consider timer choices carefully).
• neighbor ... remote-as 65000 registers the hub neighbors by their overlay IPs (the peer IPs are the VTI destinations). The activate under the IPv4 unicast address family allows route exchange.
• redistribute connected advertises connected networks (for example, on the spoke) into BGP so the hub can learn spoke prefixes.

Real-world note: BGP over IPsec is common in SD‑WAN for scalable route distribution. Ensure route filtering and prefix-lists are used in production to avoid leaking internal prefixes.

Verify:

show bgp ipv4 unicast summary
BGP router identifier 172.16.1.5, local AS number 65000
Neighbor        V    AS MsgRcv MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
172.16.1.253    4 65000     120     121        0    0    0 00:05:12       8
172.16.1.254    4 65000     118     119        0    0    0 00:04:58       7

---

Verification Checklist

• Check 1: IKEv2 SA is established — verify with show crypto ikev2 sa and confirm entries for peers 10.0.0.253 and 10.0.0.254 in state READY or ESTABLISHED.
• Check 2: IPsec SA is up and data packets are being encrypted — verify with show crypto ipsec sa and confirm bytes/packets counters increasing for both tunnels.
• Check 3: BGP neighbors are established and routes learned — verify with show bgp ipv4 unicast summary and show bgp ipv4 unicast (ensure routes from hub are present).

Common Mistakes

Symptom	Cause	Fix
IKEv2 negotiation fails	Pre-shared key mismatch between spoke and hub	Ensure ikev2 remote-authentication pre-shared-key cisco and hub keys match; change keys from default in production
Tunnel interface shows down / no IP	Incorrect tunnel destination or no route to peer's underlay IP	Verify tunnel destination matches hub public IP (10.0.0.253 / 10.0.0.254) and underlay connectivity exists to that peer
BGP neighbor stuck in Active	IP route to neighbor’s overlay address missing or IPsec not established	Verify route entries or enable IKEv2 route learning; confirm IPsec SA is UP
Policies in SD‑WAN not applied to VTI	nameif or VTI IPs do not match controller mapping	Use the exact nameif and overlay IPs (172.16.1.5 / 172.16.1.7) that the controller expects; consider using loopback + ipunnumbered if controller expects /32 anchors

Key Takeaways

• VTIs are the primary overlay interfaces in SD‑WAN security; they are the anchors for zone‑based firewall and IPS profile attachment.
• IKEv2 (phase‑1) and IPsec proposals/profiles (phase‑2) must match on both sides for tunnels to establish — algorithm choice directly affects negotiations and rekeying.
• BGP over VTIs enables dynamic route learning so the SD‑WAN controller can make policy decisions based on real overlay routes.
• In production, avoid default pre‑shared keys, use centralized key management, enforce route filtering, and map policies to stable anchors (loopbacks/ipunnumbered) when possible.

Warning: Always coordinate tunnel algorithm choices and BGP filters with hub teams before applying changes; misconfigured policies can create connectivity or security gaps.

This completes Lesson 5: you have prepared the spoke firewall with the correct cryptographic, VTI, routing, and neighbor constructs that an SD‑WAN manager will map to zone‑based firewall and IPS profiles. In the next lesson we will show how the controller applies security policies to these interface anchors and demonstrate traffic enforcement.