Back
Lesson 3 of 7

FTD Deployment Modes

Objective

In this lesson you will learn the practical differences between routed and transparent FTD deployment modes, how to think about inline (in-path) versus passive (monitor/tap) deployments, and the concept of multi-instance on chassis/platforms. You will perform CLI examples that demonstrate the mode switch and the basic interface and routing changes required for an FTD device to operate as a routed firewall or as a transparent bridge. This matters in production because the deployment mode determines how traffic is forwarded, how addressing and routing are handled, and which inspection/features are available — for example, routed mode is required when the firewall needs to be a default gateway for a LAN, while transparent mode is useful for inserting inspection without re-addressing an existing network.

Real-world scenario: A branch is being protected by an FTD 1200 series box. The network team must choose whether to re-IP and put the device as the branch default gateway (routed mode) or insert the device inline between the router and the LAN without changing existing IPs (transparent mode). Meanwhile, corporate has an N+1 Firepower chassis that can host multiple logical FTD instances; you must understand how multi-instance affects management and resource allocation.

Quick Recap

Refer to the topology used in Lesson 1. No additional devices are added for this lesson; we will reuse the same FTD device and edge router. For clarity, this lesson uses the following device addressing and interfaces (these are the IPs/interfaces we will use in the CLI examples below).

Device table

DeviceModelInterfaceIP address
FTDSecure Firewall 1230 (lab instance)Ethernet1/1 (outside)203.0.113.2/30
FTDSecure Firewall 1230 (lab instance)Ethernet1/2 (inside)10.0.0.2/24
FTD Management—Management0/0192.0.2.10/24
Internet RouterEdge RouterGig0/0203.0.113.1/30
LAN Gateway (if not using FTD)Switch/RouterGig0/110.0.0.1/24

ASCII topology (interfaces show exact IPs used in examples)

Router (Internet) 203.0.113.1/30 | | Gig0/0 | FTD Ethernet1/1 203.0.113.2/30 FTD Ethernet1/2 10.0.0.2/24 | | (to LAN switch) | LAN 10.0.0.0/24 (example host 10.0.0.100)

Tip: The addresses above use RFC 5737 / RFC 3330 ranges for lab/example use. In production use, substitute your assigned addresses and name management hosts like lab.nhprep.com for DNS where needed.

Key Concepts

Before we touch the CLI, understand these core ideas. Each point explains the theory and real-world implication.

  • Routed mode (Layer 3 firewall): The firewall participates in IP routing. Interfaces are IP-addressed and the FTD can be the gateway for attached subnets. Packet flow: packets arrive on an ingress interface, routing table lookup determines egress interface, firewall policies and NAT are applied. In production, use routed mode when the firewall must be a routing hop or default gateway for a zone.

  • Transparent mode (Layer 2 firewall / bridge): The firewall forwards frames at Layer 2 between bridge-group member interfaces; IP addressing for transit hosts remains unchanged. The device itself typically needs a management IP for access. Packet flow: frames are switched across the bridge with inspection applied, but the firewall does not participate in routing for transit traffic. This is useful to insert security into an existing network without renumbering.

  • Inline vs Passive deployment:

    • Inline (in-path): the device actively forwards traffic and enforces policy; failure may impact traffic unless high-availability or bypass is used. Use when you need full enforcement (IPS, URL filtering, DLP).
    • Passive (monitor/tap): the device receives a copy of traffic (SPAN/mirror) and inspects it without affecting production flow. Use for intrusion detection, monitoring, and when you cannot tolerate in-path failures.

  • Multi-instance / chassis considerations: High-end platforms may host multiple logical firewall instances (multi-instance). Think of each instance as a virtual FTD with its own policies and management context. In production data centers this allows segmentation of duties or hosting of customer-specific security instances on a shared chassis. Resource scheduling and interfaces must be planned to avoid contention.

  • Protocol and behavior details: When you configure a routed FTD interface with an IP, the device will send ARP for hosts in the subnet and respond to management/neighbor protocols on that interface. In transparent mode, ARP behavior is different: the FTD will forward ARP requests/answers across the bridge group (it may also proxy where configured). If you enable dynamic routing (BGP/OSPF) on a routed interface, the router will send Hello packets according to the routing protocol defaults (e.g., OSPF Hello every 10s on broadcast networks) and build adjacencies on the routed interfaces.

Step-by-step configuration

Each step below includes the exact commands, an explanation of what they do, why they matter, and verification output you should expect.

Step 1: Configure the FTD for Routed Mode (basic interface and default route)

What we are doing: Place the FTD in routed mode by assigning IP addresses to the outside and inside interfaces and configuring a default static route pointing toward the internet router. This is the minimum to make the FTD act as a Layer 3 firewall and permit policy-based inspection between zones.

configure terminal
interface Ethernet1/1
 nameif outside
 security-level 0
 ip address 203.0.113.2 255.255.255.252
 no shutdown
 exit
interface Ethernet1/2
 nameif inside
 security-level 100
 ip address 10.0.0.2 255.255.255.0
 no shutdown
 exit
route outside 0.0.0.0 0.0.0.0 203.0.113.1 1
write memory
end

What just happened:

  • interface Ethernet1/1 and interface Ethernet1/2 put the two physical ports into configuration mode. nameif assigns logical zone names used by policies, security-level sets the default firewall trust level (higher is more trusted), and ip address configures the Layer 3 addressing. no shutdown ensures the interfaces are administratively up.
  • route outside 0.0.0.0 0.0.0.0 203.0.113.1 1 installs a default route for traffic to reach the Internet via the edge router.
  • write memory persists the configuration across reboots.

Real-world note: Routed mode requires you to plan addressing and routing across your network. In production, this is commonly used when the firewall must be the customer edge or a layer-3 segmentation boundary.

Verify:

show running-config interface Ethernet1/1
interface Ethernet1/1
 nameif outside
 security-level 0
 ip address 203.0.113.2 255.255.255.252
 no shutdown
exit

show running-config interface Ethernet1/2
interface Ethernet1/2
 nameif inside
 security-level 100
 ip address 10.0.0.2 255.255.255.0
 no shutdown
exit

show route
Codes: C - connected, S - static, R - RIP, B - BGP, O - OSPF
S*    0.0.0.0/0 [1/0] via 203.0.113.1, outside
C     203.0.113.0/30 is directly connected, Ethernet1/1
C     10.0.0.0/24 is directly connected, Ethernet1/2

Step 2: Switch the FTD to Transparent Mode (bridge two interfaces)

What we are doing: Convert the firewall to transparent mode so it acts as a Layer 2 bridge between Ethernet1/1 and Ethernet1/2. We will assign a management IP so the administrator can reach the box while it bridges traffic transparently.

configure terminal
no route outside 0.0.0.0 0.0.0.0 203.0.113.1 1
firewall transparent
interface Ethernet1/1
 bridge-group 1
 no ip address
 no nameif
 no security-level
 no shutdown
 exit
interface Ethernet1/2
 bridge-group 1
 no ip address
 no nameif
 no security-level
 no shutdown
 exit
management interface Management0/0
 ip address 192.0.2.10 255.255.255.0
 exit
write memory
end

What just happened:

  • no route ... removes the default route because the device in transparent mode will not perform routing for transit.
  • firewall transparent configures the device to operate at Layer 2. Interfaces placed into a bridge-group are switched together; they no longer require IP addresses for transit.
  • A management interface IP (Management0/0) is set to allow administrative access (SSH/HTTPS) to the device even though it is not a routing hop for traffic in the bridged network.

Real-world note: Transparent mode is ideal when you must insert security into an existing IP design without readdressing hosts. However, some features (certain NAT types, some routing-dependent controls) are unavailable — check feature compatibility before choosing this mode.

Verify:

show firewall
Firewall Mode: TRANSPARENT
Bridge groups:
  Bridge-group 1
    Interfaces: Ethernet1/1, Ethernet1/2
Management:
  Management0/0    IP address: 192.0.2.10/24
show running-config
firewall transparent
interface Ethernet1/1
 bridge-group 1
!
interface Ethernet1/2
 bridge-group 1
!
management interface Management0/0
 ip address 192.0.2.10 255.255.255.0
!

Step 3: Demonstrate Inline vs Passive (concept + simple monitoring capture)

What we are doing: Explain how to deploy inline (in-path) versus passive (monitor) inspection, and create a traffic capture as a passive mechanism to validate traffic flows without changing forwarding. This step does not change forwarding state — it demonstrates a safe passive verification method.

configure terminal
capture LAN-HTTP interface Ethernet1/2 match tcp any any eq 80
exit

What just happened:

  • The capture command creates a packet capture on interface Ethernet1/2 that passively copies matching TCP port 80 traffic into a capture buffer for inspection. This does not force the firewall to become in-path or change its forwarding behavior; it simply mirrors traffic matching the filter into an internal capture for troubleshooting.

Real-world note: Passive captures and SPAN ports are commonly used during migrations to understand traffic patterns before committing to an inline deployment. Passive mode prevents outages if the security device fails.

Verify:

show capture LAN-HTTP
Capture LAN-HTTP:
Index  Time        Source IP        Dest IP          Proto Len
1      00:00:10    10.0.0.100       93.184.216.34    TCP   66
2      00:00:12    93.184.216.34    10.0.0.100       TCP   54

show capture LAN-HTTP buffer
0000  00 11 22 33 44 55 66 77 88 99 aa bb cc dd ee ff  ................
... (hex dump of captured packets)

Step 4: Notes on Multi-instance on Chassis (concept + minimal CLI show)

What we are doing: Review how multiple logical instances are presented on chassis and use a read-only verification command to show the instance list. No per-instance creation commands are performed here (multi-instance creation is typically done via platform management tools), but we show how to confirm instances.

show system virtual-instances
Virtual Instance 1
 Name: FTD-Instance-1
 Status: active
 Interfaces: Ethernet1/1, Ethernet1/2
Virtual Instance 2
 Name: FTD-Instance-2
 Status: suspended
 Interfaces: Ethernet1/3, Ethernet1/4

What just happened:

  • The show system virtual-instances output lists logical instances on the chassis, their status, and assigned interfaces. This gives the operator visibility into how the chassis partitions resources. Each instance behaves like a separate FTD from a management/policy perspective.

Real-world note: In production chassis-based deployments, plan interface to instance mapping and resource (CPU/memory) reservations. Multi-instance simplifies multi-tenancy and provides isolation for complex environments.

Verify:

show system virtual-instances
Virtual Instance 1
 Name: FTD-Instance-1
 Status: active
 Interfaces: Ethernet1/1, Ethernet1/2
Virtual Instance 2
 Name: FTD-Instance-2
 Status: suspended
 Interfaces: Ethernet1/3, Ethernet1/4

Verification Checklist

  • Check 1: Routed mode active — verify interfaces have IPs and default route exists.

    • How: show running-config interface Ethernet1/1, show route
    • Expected: Interface shows IP and S* 0.0.0.0/0 via 203.0.113.1

  • Check 2: Transparent mode active — verify firewall shows TRANSPARENT mode and bridge-group members.

    • How: show firewall, show running-config
    • Expected: Firewall Mode: TRANSPARENT and Bridge-group 1 lists Ethernet1/1 and Ethernet1/2.

  • Check 3: Passive capture working — verify capture buffer contains packets.

    • How: show capture LAN-HTTP
    • Expected: Entries showing captured packets with source/destination IPs and protocol.

  • Check 4: Multi-instance visibility — verify instance list.

    • How: show system virtual-instances
    • Expected: Listing of Virtual Instance 1 (active) and any other instances.

Common Mistakes

SymptomCauseFix
No traffic passes when switched to routed modeInterfaces administratively down or missing default routeshow interface and show route; use no shutdown on interfaces and route <if> 0.0.0.0 0.0.0.0 <next-hop>
Transparent mode configured but management unreachableManagement interface not configured or wrong VLAN/route on admin networkConfigure management interface Management0/0 ip address <addr> and ensure admin network has L2/L3 reachability to that IP (DNS lab.nhprep.com entry if used)
Passive captures show no packetsCapture filter mismatch or capture on wrong interface (not the one carrying mirrored traffic)Verify SPAN/mirror configuration on upstream switch and ensure capture filter matches traffic; check show capture on intended interface
Misunderstanding feature availabilityTrying to use routing-dependent features while in transparent modeChoose routed mode for NAT/dynamic routing; check feature compatibility before changing modes

Key Takeaways

  • Routed mode makes the FTD a Layer 3 participant (IP addresses on interfaces, routing table, NAT available). Use it when the firewall must be a gateway or route traffic.
  • Transparent mode bridges at Layer 2, letting you insert security without renumbering; management access requires a separate management IP.
  • Inline (in-path) deployments provide enforcement but introduce potential failure domains; passive (monitor) deployments let you inspect traffic without affecting production forwarding.
  • Chassis-based multi-instance capability provides logical separation of firewall instances; plan interface mapping and resource allocation carefully.
  • Always verify mode-specific behaviors (ARP, routing, management reachability) with the show commands immediately after making changes to avoid lockout or traffic disruption.

Final real-world note: In production migrations, begin with passive monitoring to understand traffic and dependencies, then move to an inline routed deployment only after you have validated connectivity and planned IP addressing and routing. Use management hostnames such as lab.nhprep.com and standard credentials (example: Lab@123 for lab accounts) only in lab environments.

Practice with Hands-On Labs

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