Back
Lesson 1 of 6

Security Architecture in SD-WAN

Objective

Understand how security integrates with SD‑WAN in three deployment models: on‑box inspection, service chaining to cloud security, and cloud (Secure Access) integration. You will configure IPSec-based branch connectivity to a Secure Access cloud point, learn why tunnel addressing and static routing matter, and verify routing and BGP behavior as seen on a firewall spoke.

In production, this matters because branches must securely reach corporate and cloud applications while retaining local inspection, redirecting traffic to cloud security services, or combining both for layered defense. Example: a retail branch uses on‑box firewalling for segmentation, sends web traffic to a cloud SWG (secure web gateway) for DLP/sandboxing, and uses a Secure Access tunnel for private application access.

Topology & Device Table

ASCII topology — exact IP addresses and interface names are used as shown in the reference material.

Note: "outside" is the firewall WAN interface. Two static IPSec VTIs are shown as logical VPN-connected interfaces: outside_static_vti_1 and outside_static_vti_2.

Network Topology Diagram

Device table

DeviceInterfaceIP AddressSubnet MaskRole
BranchFTDoutside64.x.14.188255.255.255.0*WAN interface to ISP
BranchFTDoutside_static_vti_11.0.1.1255.255.255.255VPN logical interface (advertised)
BranchFTDoutside_static_vti_21.0.2.1255.255.255.255Secondary VPN logical interface (advertised)
BranchFTDtunnel (primary)169.254.0.6255.255.255.252VTI address (primary IPSec tunnel)
SecureAccesspublic endpoint (primary)35.171.x.188255.255.255.255Secure Access VPN endpoint (public)
SecureAccesspublic endpoint (sec)217.195.x.188255.255.255.255Backup Secure Access VPN endpoint (public)
SecureAccesstunnel peer IPs169.254.0.5 / .9255.255.255.252Tunnel addresses for BGP/overlay

*Subnet mask for outside shown as /24 as an example matching the show route context. Use the actual mask from your ISP when deploying.

Key Concepts (theory + behavior)

  • On‑box firewalling (FTD): The firewall appliance inspects and enforces security policies locally. Think of it as the branch's gatekeeper — it blocks or allows traffic before anything is tunneled. In production, on‑box inspection is used for segmentation, north‑south filtering, and local security controls.

  • Service chaining to cloud security (SWG/DLP/CASB): Instead of (or in addition to) inspecting everything locally, selected traffic (e.g., web) is redirected to cloud security services. Packet flow: client → branch firewall (policy redirect) → internet → cloud security PoP → destination. This is used when you need advanced cloud protection (DLP, sandbox, tenant controls).

  • Secure Access tunnels and overlay routing: Branches establish IPSec tunnels to Secure Access PoPs. Use hub‑and‑spoke VTI topology for simplicity. The overlay advertises RAVPN subnets and application routes; the cloud can optionally advertise a default route to branch firewalls. BGP is commonly used over those VTIs; when enabled, you will see BGP peers (169.254.0.5 and 169.254.0.9) and learned routes such as 0.0.0.0/0.

  • Tunnel addressing best practices: Use the dedicated link‑local ranges shown (169.254.0.6/30 primary, 169.254.0.10/30 secondary). These addresses are only for tunnel endpoints — they simplify routing and avoid the need for loopbacks. In a live network this reduces complexity when configuring many spokes.

  • Routing and static routes to endpoints: Create static routes to the cloud public endpoints (35.171.x.188 and 217.195.x.188) pointed to your ISP gateway to prevent route flapping and ensure stable IP reachability for tunnel establishment. The branch may also receive default or application routes from Secure Access.

Step-by-step configuration

Each step contains the commands, explanation, why it matters, and verification.

Step 1: Configure ISAKMP (IKE) policy and pre‑shared key

What we are doing: Establish an IKE policy and shared key that will be used to form IPSec SAs with the Secure Access public endpoint. This sets the foundational authentication and transform parameters for IPSec.

crypto isakmp policy 10
 encr aes
 authentication pre-share
 group 2
!
crypto isakmp key Lab@123 address 35.171.x.188

What just happened: The crypto isakmp policy 10 block defines an IKE Phase 1 policy (encryption AES, pre‑shared key, DH group 2). The crypto isakmp key command assigns the pre‑shared secret (Lab@123) for the peer at 35.171.x.188; during IKE negotiation the device authenticates the remote endpoint using this shared key.

Real-world note: Using a strong pre-shared key and consistent IKE settings across all spokes and the cloud endpoint prevents mismatched negotiation parameters which is a common connection failure.

Verify:

show crypto isakmp policy

Expected output (example):

Policy: 10
 encr: aes
 hash: none
 authentication: pre-share
 group: 2
 lifetime: 86400 seconds

Step 2: Define IPsec transform set and traffic selectors (crypto ACL)

What we are doing: Create an IPsec transform set and an ACL that identifies the "interesting" traffic selectors (what to encrypt). This ACL controls which traffic is placed into the IPSec tunnel.

crypto ipsec transform-set TS esp-aes esp-sha-hmac mode tunnel
!
access-list 110 permit ip 10.20.10.0 0.0.0.255 10.10.10.0 0.0.0.255
access-list 110 permit ip 10.20.10.0 0.0.0.255 10.10.20.0 0.0.0.255
access-list 110 permit ip 10.20.10.0 0.0.0.255 10.10.30.0 0.0.0.255

What just happened: The transform set TS specifies ESP with AES for encryption and SHA HMAC for integrity in tunnel mode — this defines the Phase 2 cryptographic policy. The access-list 110 entries define the traffic selectors (which source/destination networks are encrypted). Only flows matching this ACL will be considered for the crypto map.

Real-world note: Misconfigured crypto ACLs are a frequent cause of failed tunnels — the branch and cloud must define matching selectors.

Verify:

show access-lists 110

Expected output:

Extended IP access list 110
 permit ip 10.20.10.0/24 10.10.10.0/24
 permit ip 10.20.10.0/24 10.10.20.0/24
 permit ip 10.20.10.0/24 10.10.30.0/24

Step 3: Create the crypto map and bind the transform set and peer

What we are doing: Build a crypto map that ties together the peer IP, transform set, and ACL (traffic selectors). This crypto map will later be applied to the WAN interface so traffic can be encrypted toward the Secure Access endpoint.

crypto map outside_map 10 ipsec-isakmp
 set peer 35.171.x.188
 set transform-set TS
 match address 110

What just happened: The crypto map entry outside_map 10 defines an IPSec SA profile referencing the peer at 35.171.x.188, using the transform set TS, and the traffic selector ACL 110. When applied to the outside interface, traffic matching ACL 110 and destined to the peer will trigger tunnel creation and SA negotiation.

Real-world note: For hub‑and‑spoke topologies you may create multiple map entries (primary/secondary peers). If the cloud uses a single pre-shared key for all spokes, keep the key consistent.

Verify:

show crypto map

Expected output (representative excerpt):

Crypto Map outside_map 10
 peer: 35.171.x.188
 transform-set: TS
 match address: 110
 status: available

Step 4: Assign the crypto map to the WAN interface

What we are doing: Apply the crypto map to the outside interface and configure the interface IP. This ties the crypto policy to the physical interface so IKE/IPSec traffic flows to the internet.

interface GigabitEthernet0/0
 ip address 64.x.14.188 255.255.255.0
 crypto map outside_map
!

What just happened: The outside interface is given the public IP (64.x.14.188) and has the outside_map crypto map applied. When interesting traffic is generated, the device will initiate IKE negotiation to 35.171.x.188 and establish an IPsec tunnel if the peer responds and parameters match.

Real-world note: Always ensure your ISP/edge ACLs and NAT rules allow IKE (UDP 500/4500) and ESP traffic to the cloud endpoints.

Verify:

show interface GigabitEthernet0/0

Expected output (representative):

GigabitEthernet0/0 is up, line protocol is up
  Internet address is 64.x.14.188/24
  MTU 1500 bytes, BW 1000000 Kbit/sec, DLY 10 usec
  Encapsulation ARPA
  crypto map applied: outside_map

Step 5: Ensure stable IP reachability to cloud endpoints (static host routes)

What we are doing: Add static host routes for the Secure Access public endpoint(s) via the ISP gateway so the firewall never routes those IPs into the tunnel itself or into alternate paths, preventing tunnel flapping.

ip route 35.171.x.188 255.255.255.255 64.x.14.254
ip route 217.195.x.188 255.255.255.255 64.x.14.254

What just happened: These static host routes force traffic destined for the Secure Access public endpoints to be forwarded to the ISP gateway (64.x.14.254). This prevents the device from trying to send control plane traffic into an unstable path or the VPN overlay and protects tunnel stability.

Real-world note: In production, static routes to control-plane endpoints are a simple and reliable way to prevent route feedback or recursion which can break tunnel establishment.

Verify:

show route

Expected output (representative; full lines shown):

B*    0.0.0.0/0 [20/0] via 169.254.0.5
B     100.73.x.0 255.255.240.0 [20/0] via 169.254.0.5
S     35.171.x.188 255.255.255.255 [1/0] via 64.x.14.254, outside
S     217.195.x.188 255.255.255.255 [1/0] via 64.x.14.254, outside
V     1.0.1.1 255.255.255.255 connected by VPN (advertised), outside_static_vti_1
V     1.0.2.1 255.255.255.255 connected by VPN (advertised), outside_static_vti_2

Tip: The B* 0.0.0.0/0 line shows the branch receiving a default route from the cloud via BGP over the tunnel (169.254.0.5) — this is optional and controlled by Secure Access policy.

Verification: BGP default route entry (cloud-provided)

What we are doing: Confirm BGP has learned and selected the default route from Secure Access peers.

show bgp0.0.0.0

Expected output (representative):

BGP routing table entry for 0.0.0.0/0, version 530
Paths: (2 available, best #2, table default)
Advertised to update-groups:
64512 64512 169.254.0.9 from 169.254.0.9 (169.254.0.9)
  Origin IGP, localpref 100, valid, external
64512 169.254.0.5 from 169.254.0.5 (169.254.0.5)
  Origin IGP, localpref 100, valid, external, best

What just happened: The branch has two BGP paths for the default route (from 169.254.0.9 and 169.254.0.5). The second path (via 169.254.0.5) is selected as best and installed into the routing table. This is how the cloud can steer default or specific routes to spokes.

Real-world note: When using a hub‑and‑spoke overlay, multiple cloud peers provide redundancy. BGP attributes (localpref, AS path, MED) determine the active path.

Verification Checklist

  • Check 1: IKE policy and pre‑shared key present — verify with show crypto isakmp policy and confirm the policy parameters.
  • Check 2: Crypto map applied and transform set configured — verify with show crypto map and show access-lists 110.
  • Check 3: Static host routes to cloud endpoints exist — verify show route shows S 35.171.x.188 and S 217.195.x.188 via 64.x.14.254.
  • Check 4: BGP default route learned from cloud — verify with show bgp0.0.0.0 and show route for the installed default.

Common Mistakes

SymptomCauseFix
Tunnel never establishesCrypto ACLs do not match between branch and cloudEnsure ACL traffic selectors match exactly on both sides (source/dest/netmask)
IKE negotiation failsPre-shared key or IKE policy mismatchVerify crypto isakmp policy settings and crypto isakmp key values (Lab@123)
Tunnel flaps or dropsCloud public endpoint reachable via tunnel due to missing static routeAdd static host routes to cloud endpoints via ISP gateway (e.g., 35.171.x.188 via 64.x.14.254)
Default route not installedBGP session not established or BGP attributes prefer other pathCheck BGP neighbors and attributes; ensure tunnel and VTIs are up and peering IPs (169.254.0.5/.9) are reachable

Key Takeaways

  • Use dedicated tunnel addressing (169.254.0.6/30 primary, 169.254.0.10/30 secondary) to simplify overlay routing — think of these like private link IPs between the branch and Secure Access PoP.
  • Secure Access integration typically uses hub‑and‑spoke VTIs and may advertise defaults and application routes to spokes via BGP; ensure static routes to public endpoints to avoid recursion.
  • Crypto map-based IPSec requires three matching pieces: IKE policy/key, transform-set, and traffic-selector ACL. Misalignment in any one of them prevents tunnel formation.
  • In production, choose where inspection happens: on‑box for local control, service chaining for advanced cloud services, or both. Each model has operational trade-offs for latency, visibility, and policy enforcement.

Warning: Always validate control‑plane reachability (static routes to cloud endpoints) before relying on overlay paths for tunnel establishment; this simple step prevents many connectivity issues in large deployments.

Practice with Hands-On Labs

30 step-by-step labs for CCNA, CCNP Enterprise & Security