Every Secure Firewall Threat Defense deployment starts with one foundational decision covered directly in the SNCF blueprint: does the firewall act as a routed Layer 3 hop, or as an invisible Layer 2 bridge? Get this wrong at design time and the fix means reinitializing the device.
Routed Mode
Routed mode is the default and most common deployment: Threat Defense operates as a genuine Layer 3 hop between networks, with each interface assigned an IP address on a different subnet. The firewall participates fully in the network topology -- it performs Network Address Translation, can run dynamic routing (OSPF, EIGRP, BGP), and appears in traceroutes as a router hop. Because it terminates and re-originates Layer 3 traffic, routed mode supports the full range of NAT use cases: static NAT for published servers, dynamic PAT for outbound internet access, and policy-based NAT for split scenarios. Most greenfield deployments and any design requiring the firewall to route between subnets use routed mode.
Transparent Mode
Transparent mode turns Threat Defense into a Layer 2 bridge -- a "bump in the wire" that inspects and enforces policy on traffic without appearing as a router hop at all. Interfaces in a bridge group share the same IP subnet, and the bridge group itself gets a single management IP via a Bridge Virtual Interface (BVI). Because the firewall isn't a routing hop, it requires no re-addressing of the existing network to insert -- this is the single biggest reason architects choose transparent mode: dropping a firewall into an existing flat segment (in front of a legacy application, inside a data center pod, or between two zones that can't be re-IP'd) without touching any host's default gateway. The trade-off is that transparent mode does not participate in dynamic routing and offers only limited NAT support, and by default it does not pass non-IP traffic like BPDUs -- in a redundant switched topology this can create a bridging loop unless BPDU pass-through is explicitly enabled.
Choosing Between Them and Operational Impact
The choice isn't just architectural preference -- it's largely permanent for the life of that deployment. Firewall mode is set during initial device setup, and changing it later requires reinitializing the device configuration, not a live toggle. This is why the SNCF blueprint tests mode selection as a deployment-time decision: a scenario describing "insert a firewall into an existing segment without changing any IP addressing" points to transparent mode every time, while a scenario needing NAT, dynamic routing, or the firewall to act as a default gateway points to routed mode.
Key Mechanics
- Routed mode: firewall is a Layer 3 hop, full NAT support, participates in dynamic routing, interfaces on different subnets.
- Transparent mode: firewall is a Layer 2 bridge, one IP per bridge group via a BVI, interfaces share a subnet, no dynamic routing participation, limited NAT.
- Transparent mode drops BPDUs by default -- redundant L2 topologies need BPDU pass-through explicitly enabled to avoid a bridging loop.
- Firewall mode is chosen at initial setup; switching modes later requires reinitializing the device, not a live configuration change.
Exam Tip: "Deploy a firewall into an existing network segment without changing any host IP addresses or default gateways" is the signature phrase for transparent mode.
Exam Tip: If a scenario requires the firewall to perform NAT or participate in OSPF/EIGRP/BGP, that rules out transparent mode -- those capabilities require routed mode.
Exam Tip: Don't treat firewall mode as something reconfigured on the fly during a maintenance window -- changing it is a reinitialization, which is why the decision belongs at design time, not as an afterthought.
Worked example: A data center team must insert a Secure Firewall in front of a legacy application segment to enforce intrusion prevention, but the application's servers have hardcoded default gateways that cannot be changed without a lengthy change-control process, and there's no appetite for a re-IP project. The design deploys Threat Defense in transparent mode with a single bridge group spanning the inside and outside interfaces on the existing subnet, inserting inspection transparently with zero changes to server configuration -- while a separate new greenfield segment elsewhere in the same data center, which needs NAT and OSPF peering with the core, uses a second Threat Defense device in routed mode.