Firepower SDWAN

on

 Firepower SDWAN

FMC 7.6 +


FMC 7.7 SDWAN Lab



  •  Add Hub and Branch1 to SDWAN topology

1. Device > VPN > Site to Site > Add a new topology



2. Add Hub FTD

Tunnel interface IP is borrowed from loopback interface

VPN tunnel interface subnet is 169.254.77.0/24. Hub DVTI is 169.254.77.1, branch SVI is from a created pool.











Create a new SDWAN zone and lookback interface








Once Hub is added:



3. Add a Branch1 FTD

Click Next to add Spoke



Local Tunnel (IKE) Identity is useful if branch has dynamic public IP




After added Branch1



4. Authentication settings

Leave default settings in this lab




5. SD-WAN settings

enable BGP to redistribute connected LAN subnet.







After added SDWAN settings




After deployment





6. Add overlay ACP rules

Branch:


Hub:



  • Add Branch2 to SDWAN topology



After deployment:



No any Hub changes is required, no ACP change is required as all branches are sharing the same ACP.



  • Add the 2nd SDWAN topology on ISP2





Branch1:

looks mBGP is only on the branches.




Multipath BGP allows a router or firewall to install and use multiple equal‑cost BGP paths to the same destination prefix at the same time.

Without multipath:

  • BGP selects one best path
  • All traffic follows that single next‑hop

With multipath enabled:

  • Multiple paths remain active in the routing table
  • Traffic can be load‑shared across them

So in SD‑WAN mode:

Multipath BGP = route visibility
SD‑WAN = forwarding decision

Multipath BGP lets the device learn multiple equal routes, but whether traffic actually load‑balances depends on the platform, ECMP support, and SD‑WAN policy behavior.


Operational Caveats (Very Important)

🔸 Asymmetric Routing

Multipath can cause:

  • Return traffic on a different path
  • Broken stateful inspection

Most firewalls:

  • Use session stickiness
  • Or recommend single preferred egress per flow


Key Takeaways

  • Multipath BGP = multiple equal BGP routes installed
  • ECMP = multiple next‑hops used by forwarding plane
  • In Firepower SD‑WAN, routing ≠ forwarding
  • SD‑WAN policy usually overrides BGP multipath

What SD‑WAN Actually Is in Firepower 7.7

Think of Firepower SD‑WAN as:

Policy‑controlled path selection among already‑routed overlays

The flow is:

  1. Routing (BGP / static / connected) decides:

    • Which destinations are reachable
    • Over which SD‑WAN VPN tunnels

  2. SD‑WAN policy then decides:

    • Which tunnel to use
    • Based on SLA and policy intent

  3. Forwarding happens over the selected VTI

Routing is never bypassed.


No App‑based path steering in Firepower 7.7 release

In FMC 7.7, SD‑WAN does not have a dedicated policy menu. SD‑WAN behavior is controlled through VPN topology design and routing decisions. Traffic steering is limited to preferred path and failover; application‑based SD‑WAN policies are not supported in this release.

Although PBR technically can steering traffic when there is no SDWAN policy available, but it is not recommended

Why this is a bad idea with Firepower SD‑WAN (Important)

🔴 1. PBR Bypasses Routing and SD‑WAN Logic

PBR executes:

  • Before SD‑WAN path logic
  • Before routing preference and SLA checks

Meaning:

  • Tunnel health is ignored
  • Failover logic is ignored
  • You can blackhole traffic if the forced path goes down

SD‑WAN is conditional path selection
PBR is absolute path forcing

🔴 2. High Risk of Asymmetric Routing (Firewall killer)

With:

  • Dual ISPs
  • BGP over VPN
  • Hub‑and‑spoke design

PBR can easily cause:

  • Forward path via ISP‑2
  • Return path via ISP‑1

Result:

  • Session drops
  • TCP resets
  • “Random” application failures

Even with:

  • same-security-traffic permit intra-interface
  • Stateful inspection

🔔 ASA/FTD is not tolerant of forced asymmetry.

🔴 3. PBR Is NOT Overlay‑Aware

PBR works on:

  • Physical interfaces
  • Next‑hop IPs

It does not understand:

  • SD‑WAN VPN topology
  • VTI selection
  • Overlay reachability

So you cannot say:

“Use SD‑WAN tunnel ISP‑2 if SLA is good”

You can only say:

“Always send traffic out interface X”

🔴 4. Troubleshooting Becomes Brutal

Once PBR is mixed with:

  • SD‑WAN
  • BGP
  • Route‑based VPN

You will see:

  • Routes exist but traffic ignores them
  • SD‑WAN failover appears “broken”
  • TAC immediately asks you to remove PBR
















Comments

Post a Comment