> ## Content Index > Fetch the complete content index at: https://www.pinglabz.com/llms.txt > Use this file to discover other available public pages before exploring further. # FTD Transparent Mode in FMC: Bridge Group, BVI and Zone Fault - URL: https://www.pinglabz.com/ftd-transparent-mode-fmc/ - Published: 2026-10-20T20:09:42.000Z - Updated: 2026-10-20T20:09:42.000Z - Description: The bridge stayed up and ARP resolved the server, but ping and HTTP failed. In this FMC-managed FTDv home lab, one bridge member in the wrong Switched zone removed the intended deployed permits. Restoring its zone and deploying restored traffic. - Author: Jaime - Tags: Firewall, Security, Troubleshooting, Cisco, Network Security ![FTD transparent mode in FMC with Ethernet0/1 in the wrong zone PL-BR-DMZ: ARP still resolves across bridge group 1 but ping and HTTP hit the default action block](https://storage.ghost.io/c/ff/28/ff28db4a-11e1-4835-b928-158974cf96c1/content/images/2026/10/ftd-transparent-mode-fmc-topology.png) The bridge was up. The client resolved the web server's MAC address through the FTD, and the firewall learned both hosts in its MAC table. Yet ping returned 0/4 and HTTP timed out. I built this in my home lab: FTDv 10.0.0 in transparent mode, managed by FMCv 10.0.1, in Containerlab. The fault was one field: Ethernet0/1 belonged to `PL-BR-DMZ` instead of `PL-BR-OUT`. FMC accepted that change without removing the interface from the bridge group. The access control policy still allowed `PL-BR-IN` to `PL-BR-OUT`, so the traffic now hit its default block. Restoring the member's zone and deploying brought back 4/4 pings and HTTP 200\. No bridge rebuild, address change, or extra allow rule was needed. This is a nested home lab, not a supported production deployment. The observations below belong to FMC 10.0.1 build 1 and FTDv 10.0.0 build 140\. Essentials only was enough for this test; neither allow rule had an intrusion or file policy attached. ## One subnet, two bridge members The data path is client-a → FTD bridge group 1 → web-srv. Both endpoints are in `10.42.50.0/24`: | Endpoint or interface | Address | Connection and zone | | --------------------- | ----------------------- | ------------------------------------------- | | client-a eth1 | 10.42.50.21/24 | Connects to FTD Ethernet0/0 | | FTD Ethernet0/0 | No individual member IP | br-in, PL-BR-IN | | FTD Ethernet0/1 | No individual member IP | br-out, PL-BR-OUT in the working state | | FTD BVI1 | 10.42.50.2/24 | Bridge Virtual Interface for bridge group 1 | | web-srv eth1 | 10.42.50.80/24 | Connects to FTD Ethernet0/1; HTTP on TCP/80 | There is no router in this data path and no NAT policy assigned. Each host uses its connected /24 route to reach the other. The client ARPs for the server itself, rather than a gateway. The server's MAC is `aa:c1:ab:da:d1:8c`; the client's is `aa:c1:ab:c9:27:90`. FMC manages FTD over the separate management tunnel. BVI1 is not the clients' default gateway or the management tunnel endpoint. In this FTD bridge group/BVI configuration, its address belongs to the bridge group; the member interfaces were not given separate IPv4 addresses. That removes the next-hop question from this particular failure. The [FTD static-route lab](https://www.pinglabz.com/ftd-static-route-fmc-next-hop/) follows a routed path with a dead next hop; this path has no such hop to repair. For the ASA version of the bridge-group build, see the [ASA transparent firewall configuration lab](https://www.pinglabz.com/asa-transparent-firewall-configuration/). ## Set FTD transparent mode before adding the device to FMC The FTDv instance was fresh, but the installed image already contained a local-manager setup. There was no first-boot wizard in this run. The first authenticated CLI reported routed mode and local management, so the conversion started by removing the local manager. At the FTD CLISH prompt, I ran `configure manager delete`. The relevant transcript was: ```text > configure manager delete configure manager delete If you enabled any feature licenses, you must disable them in Secure Firewall Device Manager before deleting the local manager. Otherwise, those licenses remain assigned to the device in Cisco Smart Software Manager. Do you want to continue [yes/no]: yes Local Manager successfully deleted. ``` The license warning belongs to the actual command, even on this fresh instance. After the local manager was removed, `configure firewall transparent` produced this exact prompt and response: ```text > configure firewall transparent configure firewall transparent This will destroy the current interface configurations, are you sure that you want to proceed? [y/N] yes The firewall mode was changed successfully. ``` The warning names the current interface configurations. Treat this as a destructive mode change, not an interface checkbox to try on an existing build. The ASA has the same mode choice, and changing it clears the ASA's running configuration; [ASA routed vs transparent mode](https://www.pinglabz.com/cisco-asa-routed-vs-transparent/) compares the two. Here it happened before the bridge and its member configuration were created. The readback confirmed the result: ```text > show firewall show firewall Firewall mode: Transparent ``` I then ran `configure manager add` with the matching private registration values and added the device in FMC; registration completed and both tunnel channels connected. The [FTDv-to-FMC registration lab](https://www.pinglabz.com/register-ftd-to-fmc-containerlab/) covers that pairing step. [FDM cannot manage transparent mode](https://www.cisco.com/c/en/us/td/docs/security/firepower/10-0/fdm/fptd-fdm-config-guide-10-0/fptd-fdm-interfaces.html?ref=pinglabz.com), so this build belongs in FMC. The [local FDM bootstrap lab](https://www.pinglabz.com/ftdv-fdm-containerlab-bootstrap/) is useful background for the prepared image's starting state, but its local-management workflow is not the workflow used for this bridge. ## Build the FTD bridge group interface, BVI and Switched zones In FMC, open **Devices > Device Management**, edit the device, and select **Interfaces > Add Interfaces > Bridge Group Interface**. The editor title in this version is **Add Bridge Group Interface**. On its **Interfaces** tab, set **Bridge Group ID** to `1` and move Ethernet0/0 and Ethernet0/1 into **Selected Interfaces**. Both must be members of the same group for this topology. ![Add Bridge Group Interface with bridge group ID 1 and Ethernet0/0 and Ethernet0/1 selected.](https://storage.ghost.io/c/ff/28/ff28db4a-11e1-4835-b928-158974cf96c1/content/images/2026/10/ftd-transparent-mode-fmc-shot-17-bridge-group-members.png) Add Bridge Group Interface with bridge group ID 1 and Ethernet0/0 and Ethernet0/1 selected. On **IPv4**, select **Use Static IP** and enter `10.42.50.2/24`. FMC creates BVI1\. This transparent-mode build did not require a BVI name or security zone. Cisco's transparent-mode rules match: only member interfaces are named, but the BVI still needs an IP address for traffic to pass ([Cisco](https://www.cisco.com/c/en/us/td/docs/security/secure-firewall/management-center/device-config/100/management-center-device-config-10-0/get-started-tfw.html?ref=pinglabz.com)). ![Bridge Group Interface IPv4 settings with the static BVI1 address 10.42.50.2/24.](https://storage.ghost.io/c/ff/28/ff28db4a-11e1-4835-b928-158974cf96c1/content/images/2026/10/ftd-transparent-mode-fmc-shot-18-bvi1-ipv4.png) Bridge Group Interface IPv4 settings with the static BVI1 address 10.42.50.2/24. Create the member zones under **Objects > Interface > Add > Security Zone**. The popup is called **Security Zones**. FMC requires the **Switched** interface type for bridge group members, and every interface in a zone must be the same type ([Cisco](https://www.cisco.com/c/en/us/td/docs/security/secure-firewall/management-center/device-config/100/management-center-device-config-10-0/interfaces-settings-ifcs-overview.html?ref=pinglabz.com)). I created `PL-BR-IN` and `PL-BR-OUT` with that type. ![Security Zones editor with PL-BR-IN named and Interface Type set to Switched.](https://storage.ghost.io/c/ff/28/ff28db4a-11e1-4835-b928-158974cf96c1/content/images/2026/10/ftd-transparent-mode-fmc-shot-06-new-switched-zone.png) Security Zones editor with PL-BR-IN named and Interface Type set to Switched. Back in the device's Interfaces table, edit each physical member. Enable Ethernet0/0, name it `br-in`, and choose `PL-BR-IN`. Enable Ethernet0/1, name it `br-out`, and choose `PL-BR-OUT`. Save the device configuration. The physical editor also displays **Mode: None**. That field is separate from the security zone's **Switched** type. Cisco documents None as the setting to choose for regular firewall interfaces and says the mode changes automatically with later configuration ([Cisco](https://www.cisco.com/c/en/us/td/docs/security/secure-firewall/management-center/device-config/100/management-center-device-config-10-0/interfaces-settings-ifcs-overview.html?ref=pinglabz.com)); in this run the FMC API readback still showed mode NONE for both bridge members. Likewise, the numeric security levels shown by `show nameif` were 0 on both members; those numbers do not tell you which FMC security zones the interfaces occupy. The two assignments worth writing down are therefore bridge membership and security-zone membership. Ethernet0/1 can remain a member of bridge group 1 while its zone changes. That is exactly what the fault will exploit. ## Make the ACP match the member zones I created a new `PL-Bridge-ACP` under **Policies > Security policies > Access Control > Create Policy**, with **Block All Traffic** as the default. The existing `PL-Edge-ACP` was untouched. The policy had two enabled rules: | Rule | Action | Source zone | Destination zone | Destination and service | | ----------------- | ----------------- | ----------------- | ----------------- | ----------------------------------- | | Allow-Bridge-Web | Allow | PL-BR-IN | PL-BR-OUT | 10.42.50.80, HTTP TCP/80 | | Allow-Bridge-ICMP | Allow | PL-BR-IN | PL-BR-OUT | Any destination, ICMP any type/code | | Default Action | Block All Traffic | Unmatched traffic | Unmatched traffic | Log at beginning to FMC | For both allow rules, I enabled logging at the end of the connection to Firewall Management Center. The default block logged at the beginning; FMC disabled end logging for that default action. Those settings provide an event for the completed web request and an event when the faulted connection is denied. ![Retained PL-Bridge-ACP rule table, viewed after cleanup: two zone-based Allow rules and default Block All Traffic; the rules were unchanged across all three states.](https://storage.ghost.io/c/ff/28/ff28db4a-11e1-4835-b928-158974cf96c1/content/images/2026/10/ftd-transparent-mode-fmc-shot-13-bridge-acp-rules.png) Retained PL-Bridge-ACP rule table, viewed after cleanup: two zone-based Allow rules and default Block All Traffic; the rules were unchanged across all three states. The screenshot shows the retained policy after cleanup, hence the zero assigned devices. The recorded configuration comparisons confirmed that these rules stayed identical through baseline, fault, and fix. The [FDM access-control lab](https://www.pinglabz.com/ftd-access-control-policy-fdm-packet-tracer/) breaks traffic by changing rule order. Here the rule order stayed put. The Default Prefilter Policy also remained assigned; the separate [FMC prefilter Fastpath lab](https://www.pinglabz.com/fmc-prefilter-policy-fastpath/) covers a different reason traffic may avoid the expected ACP decision. Save the policy and deploy the device changes through **Deploy > Advanced Deploy**. Wait for **Completed** before testing. A saved zone assignment in FMC and the assignment currently deployed on FTD are separate things. ## Prove the baseline with real traffic From client-a, the test flushed the neighbor entry on eth1, ran `ping -c 4 -W 1 10.42.50.80`, and requested the server with curl using a six-second maximum. The baseline result was: ```text --- 10.42.50.80 ping statistics --- 4 packets transmitted, 4 packets received, 0% packet loss round-trip min/avg/max = 1.909/4.985/11.828 ms ping_exit=0 10.42.50.80 dev eth1 lladdr aa:c1:ab:da:d1:8c ref 1 used 0/0/0 probes 4 REACHABLE PL-bridge-ok HTTP=200 total=0.028514 local=10.42.50.21:36522 curl_exit=0 ``` The neighbor entry contains the server's MAC, and the response body identifies the expected service. A successful ping alone would not establish that the web rule was working. At FTD's diagnostic CLI, `show firewall` still reported transparent mode. The relevant `show bridge-group` excerpt was: ```text Bridge Group: 1 Interfaces: Ethernet0/0 Ethernet0/1 Management System IP Address: 10.42.50.2 255.255.255.0 Management Current IP Address: 10.42.50.2 255.255.255.0 ``` The baseline `show mac-address-table` learned the server on br-out and client on br-in: ```text br-out aac1.abda.d18c dynamic 5 1 ... br-in aac1.abc9.2790 dynamic 5 1 ``` In **Events & Logs > Analysis > Unified Events**, I opened the actual HTTP connection with client source port `36522`. It was **Allow**, matched **Allow-Bridge-Web** in **PL-Bridge-ACP**, and showed ingress `PL-BR-IN`, egress `PL-BR-OUT`, and HTTP response code 200. ![Baseline HTTP event Networking details: PL-BR-IN to PL-BR-OUT, response code 200, and br-in/br-out interfaces.](https://storage.ghost.io/c/ff/28/ff28db4a-11e1-4835-b928-158974cf96c1/content/images/2026/10/ftd-transparent-mode-fmc-shot-52-baseline-event-zones.png) Baseline HTTP event Networking details: PL-BR-IN to PL-BR-OUT, response code 200, and br-in/br-out interfaces. The selected event is the earlier baseline row; the later rows visible above it came from subsequent tests. Unified Events displayed UTC-4 in this run, while the collected traffic transcripts used UTC. Correlate the addresses and source port as well as the clock. The baseline packet capture started late. It contains six ICMP packets and the HTTP exchange, but misses initial ARP and the first ping pair. The 4/4 result comes from the client transcript, not a claim that the capture recorded all four pairs. ## Change only Ethernet0/1's security zone For the fault, I created another **Switched** zone named `PL-BR-DMZ`. In the device Interfaces table, I edited Ethernet0/1 and changed only **Security Zone** from `PL-BR-OUT` to `PL-BR-DMZ`. ![Faulted Ethernet0/1 editor: br-out remains enabled, with Security Zone set to PL-BR-DMZ.](https://storage.ghost.io/c/ff/28/ff28db4a-11e1-4835-b928-158974cf96c1/content/images/2026/10/ftd-transparent-mode-fmc-shot-32-wrong-member-zone.png) Faulted Ethernet0/1 editor: br-out remains enabled, with Security Zone set to PL-BR-DMZ. FMC accepted the change, saved it, and deployed it. Ethernet0/1 stayed in bridge group 1\. Its logical name remained br-out, and BVI1 kept `10.42.50.2/24`. The ACP rules still referred to `PL-BR-OUT`. After the fault deployment completed, the same client tests returned: ```text --- 10.42.50.80 ping statistics --- 4 packets transmitted, 0 packets received, 100% packet loss ping_exit=1 10.42.50.80 dev eth1 lladdr aa:c1:ab:da:d1:8c ref 1 used 0/0/0 probes 4 REACHABLE HTTP=000 total=6.001743 local=:-1 curl: (28) Connection timed out after 6001 milliseconds curl_exit=28 ``` The client had flushed its old neighbor entry before that test. It then learned the same server MAC and marked it REACHABLE, even while all four pings failed and curl exited 28\. The failed curl summary did not report a usable local port; the real connection's source port comes from FMC's event, not from guessing at that summary. FTD's interface readback still showed the members up, and the fault MAC table contained both endpoints: ```text br-out aac1.abda.d18c dynamic 5 1 br-in aac1.abc9.2790 dynamic 5 1 ``` There was no missing member to re-add. Recreating BVI1 would change something the evidence already showed was intact. ### The fault capture proves ARP, with a collection limit The first fault capture, `37-fault.pcap`, contained zero packets. It cannot prove ARP crossed the firewall. The dedicated ARP-only capture, `44-fault-arp.pcap`, provides that evidence: ```text 19:37:04.635487 aa:c1:ab:c9:27:90 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 10.42.50.80 tell 10.42.50.21, length 28 19:37:04.635528 aa:c1:ab:da:d1:8c > aa:c1:ab:c9:27:90, ethertype ARP (0x0806), length 42: Reply 10.42.50.80 is-at aa:c1:ab:da:d1:8c, length 28 ``` The request asks for `10.42.50.80`, and the reply advertises the server's actual MAC. Together with the client's refreshed REACHABLE entry, this establishes ARP across the bridge during the fault. The capture has two ARP packets and no IP packets; it is not a recording of the failed TCP conversation. The cause of the earlier capture limitation was not independently established. ### Unified Events identifies the wrong zone pair The real failed HTTP connection used source port `38824`. Its Event Details showed **Block**, **Default Action**, and **PL-Bridge-ACP**. Under Networking, the zone pair had become `PL-BR-IN` → `PL-BR-DMZ`. The logical interfaces were still br-in → br-out. ![Fault HTTP event Networking details: PL-BR-IN to PL-BR-DMZ, while the egress interface remains br-out.](https://storage.ghost.io/c/ff/28/ff28db4a-11e1-4835-b928-158974cf96c1/content/images/2026/10/ftd-transparent-mode-fmc-shot-51-fault-event-zones.png) Fault HTTP event Networking details: PL-BR-IN to PL-BR-DMZ, while the egress interface remains br-out. That difference explains why inspecting the interface name alone can mislead you. The web allow rule required the destination zone `PL-BR-OUT`. The packet left through the same bridge member, but that member no longer belonged to the zone named in the rule. ## Compare the deployed ACL and trace the drop The saved rules did not disappear from FMC. Their deployed Allow-Bridge lines disappeared from FTD's ACL during the fault. In the baseline, `show access-list` included: ```text access-list CSM_FW_ACL_ line 9 remark rule-id 268434447: L7 RULE: Allow-Bridge-Web access-list CSM_FW_ACL_ line 10 advanced permit tcp ifc br-in any ifc br-out host 10.42.50.80 object-group HTTP rule-id 268434447 (hitcnt=1) (Last Hit=19:32:29 UTC Oct 20 2026) access-list CSM_FW_ACL_ line 10 advanced permit tcp ifc br-in any4(0xf0050000) ifc br-out host 10.42.50.80(0xa2a3250) eq www rule-id 268434447 (hitcnt=1) (Last Hit=19:32:29 UTC Oct 20 2026) ``` The fault ACL retained the prefilter permits, then went straight to the default deny. Its ending was: ```text access-list CSM_FW_ACL_ line 8 remark rule-id 268434446: ACCESS POLICY: PL-Bridge-ACP - Default access-list CSM_FW_ACL_ line 9 remark rule-id 268434446: L4 RULE: DEFAULT ACTION RULE access-list CSM_FW_ACL_ line 10 advanced deny ip any any rule-id 268434446 event-log flow-start (hitcnt=11) (Last Hit=19:35:41 UTC Oct 20 2026) ``` There were no Allow-Bridge-Web or Allow-Bridge-ICMP entries anywhere in that fault ACL. This ties the zone assignment to the deployed policy rather than relying solely on a rule editor that still looks correct. At the FTD diagnostic CLI, the tested transparent-mode trace included the server MAC **before** the destination IP: ```text > packet-tracer input br-in tcp 10.42.50.21 43003 aac1.abda.d18c 10.42.50.80 80 detailed ``` The earlier attempt without a destination MAC failed parsing. This corrected command resolved br-out at the destination-MAC lookup, then dropped at ACCESS-LIST: ```text Phase: 1 Type: L2-EGRESS-IFC-LOOKUP Subtype: Destination MAC L2 Lookup Result: ALLOW Elapsed time: 71708 ns Config: Additional Information: Destination MAC lookup resulted in egress ifc br-out ... Phase: 3 Type: ACCESS-LIST Subtype: Result: DROP Elapsed time: 492 ns Config: access-group CSM_FW_ACL_ global access-list CSM_FW_ACL_ advanced deny ip any any rule-id 268434446 event-log flow-start access-list CSM_FW_ACL_ remark rule-id 268434446: ACCESS POLICY: PL-Bridge-ACP - Default access-list CSM_FW_ACL_ remark rule-id 268434446: L4 RULE: DEFAULT ACTION RULE ``` The final result was: ```text Result: input-interface: br-in(vrfid:0) input-status: up input-line-status: up output-interface: br-out(vrfid:0) output-status: up output-line-status: up Action: drop Time Taken: 129724 ns Drop-reason: (acl-drop) Flow is denied by configured rule, Drop-location: frame snp_classify_table_lookup:6167 flow (NA)/NA ``` For the GUI equivalent, open **Troubleshooting > Tools > Packet Tracer**. Select the transparent device, TCP, ingress br-in, source `10.42.50.21`, destination `10.42.50.80`, and destination port 80\. For this untagged bridge-member trace, **Destination MAC Address** became required. I used `aac1.abda.d18c`, left VLAN and inline tag blank, and left bypass, decrypted-packet, and simulated-transmit options unchecked. ![Fault GUI Packet Tracer with the server destination MAC supplied: MAC lookup passes and ACCESS-LIST drops on PL-Bridge-ACP's Default Action.](https://storage.ghost.io/c/ff/28/ff28db4a-11e1-4835-b928-158974cf96c1/content/images/2026/10/ftd-transparent-mode-fmc-shot-37-fault-packet-tracer-drop.png) Fault GUI Packet Tracer with the server destination MAC supplied: MAC lookup passes and ACCESS-LIST drops on PL-Bridge-ACP's Default Action. The [ASA packet-tracer guide](https://www.pinglabz.com/cisco-asa-packet-tracer/) gives background on reading phases. Here the useful sequence is particularly clear: FTD can select the bridge egress and still deny the IP packet at the next policy decision. Keep those simulations separate from the curl evidence. The fault CLI tracer used source port `43003`, and the GUI used `43004`; neither was the real HTTP attempt on `38824`. The [FMC packet-tracer and capture lab](https://www.pinglabz.com/ftd-packet-tracer-capture-fmc/) explores why a simulated verdict still needs a real traffic check. ## Restore the zone, deploy, and verify recovery I returned to Ethernet0/1's physical interface editor, restored **Security Zone** to `PL-BR-OUT`, saved, and deployed. No ACP rule edits were required. ![FTD transparent mode in FMC fixed: Ethernet0/1 back in PL-BR-OUT, Allow-Bridge-Web matches and ping and HTTP 200 pass across the bridge](https://storage.ghost.io/c/ff/28/ff28db4a-11e1-4835-b928-158974cf96c1/content/images/2026/10/ftd-transparent-mode-fmc-fig2.png) Wait for the fix deployment to complete before calling a retest a recovery check. One fault repeat in this run happened while that deployment was still in progress and remained blocked. It is not evidence of a failure after the completed fix. The [FMC deployment-history rollback lab](https://www.pinglabz.com/fmc-deployment-history-rollback/) covers the history view in more depth. After completion, client-a returned: ```text --- 10.42.50.80 ping statistics --- 4 packets transmitted, 4 packets received, 0% packet loss round-trip min/avg/max = 2.282/4.679/10.906 ms ping_exit=0 10.42.50.80 dev eth1 lladdr aa:c1:ab:da:d1:8c ref 1 used 0/0/0 probes 4 REACHABLE PL-bridge-ok HTTP=200 total=0.011219 local=10.42.50.21:52672 curl_exit=0 ``` The fixed real HTTP connection used source port `52672`. Unified Events returned to **Allow / Allow-Bridge-Web**, with `PL-BR-IN` → `PL-BR-OUT` and HTTP response code 200. ![Fixed real HTTP event on source port 52672: Allow, Allow-Bridge-Web, and PL-Bridge-ACP.](https://storage.ghost.io/c/ff/28/ff28db4a-11e1-4835-b928-158974cf96c1/content/images/2026/10/ftd-transparent-mode-fmc-shot-49-fixed-allow-detail.png) Fixed real HTTP event on source port 52672: Allow, Allow-Bridge-Web, and PL-Bridge-ACP. Both Allow-Bridge entries returned to the deployed ACL. CLI and GUI tracers allowed the flow again. The fixed capture recorded 20 packets: two ARP, eight ICMP, and ten TCP, with the HTTP 200 exchange and response marker present. Unlike the late baseline capture, it included all four ping request/reply pairs. The configuration comparison confirmed that the only physical-interface semantic change was Ethernet0/1's security zone. The BVI/member list and ACP rules stayed unchanged; the fixed interface state matched the baseline. That confines the repair to the field that caused the failure. ## Why ARP passing does not prove the ACP allows traffic The ARP result answered a narrow question: could the client discover the server's MAC across this bridge? It did not test the zone-based TCP or ICMP rules in PL-Bridge-ACP. That split is documented behavior: Cisco states that unicast IPv4 needs an access rule to cross a bridge group, while ARPs are allowed in both directions without one (ARP inspection is the control for ARP) ([FTD transparent mode in the FMC 10.x guide](https://www.cisco.com/c/en/us/td/docs/security/secure-firewall/management-center/device-config/100/management-center-device-config-10-0/get-started-tfw.html?ref=pinglabz.com)). The fault supplied both answers at once. ARP reached the server and its reply reached the client. Meanwhile, FMC recorded the IP connection under the wrong destination zone, and packet-tracer showed a default-action ACL drop after a successful MAC lookup. A learned MAC and an up BVI were compatible with a working bridge path and a denied web connection. For this symptom, compare three things before changing addressing: the actual egress member, that member's deployed security zone, and the destination zone required by the intended ACP rule. Here br-out was correct throughout; its zone was the field that differed. ## FTD transparent mode limitations: Cisco's list and this lab Cisco lists the platform limits separately. Bridge groups in transparent mode don't support DHCP relay, dynamic routing protocols, multicast IP routing, QoS or VPN termination for through traffic, although access rules can pass DHCP, routing-protocol and multicast traffic through the bridge. Transparent mode is also not supported for FTDv on AWS, Azure, GCP or OCI ([Cisco](https://www.cisco.com/c/en/us/td/docs/security/secure-firewall/management-center/device-config/100/management-center-device-config-10-0/get-started-tfw.html?ref=pinglabz.com)). This FTD transparent mode configuration used one untagged subnet, one bridge group, two members, and basic ICMP/HTTP rules. It did not test VLAN trunks, multiple bridge groups, high availability, routing features, or performance. The home-lab result does not establish support for those designs on a production platform. The practical constraints encountered here were specific: conversion warned that it would destroy interface configurations; FDM was not the transparent-mode manager; FMC required Switched security zones; and the bridge-member tracer needed a destination MAC. FMC also allowed a member-zone change that left bridge membership valid but made the intended zone-based rules inapplicable. No NAT was configured, and the final NAT readback was empty. That is a boundary of this test, not a claim that every transparent deployment forbids translation. The [FMC NAT rule-order lab](https://www.pinglabz.com/ftd-nat-fmc-rule-order/) and [FTD twice-NAT lab](https://www.pinglabz.com/ftd-twice-nat-fmc/) cover separate translation faults. Neither translation nor IPS tuning was part of this repair. 💡 **Running ASA instead of FTD? Bridge groups and BVIs work there too, with interfaces and ACLs instead of FMC zones.** The free [Cisco ASA Field Reference PDF](https://www.pinglabz.com/cisco-asa-cheat-sheet/#pdf-asa-field-reference) puts the packet pipeline, NAT order, capture commands and a troubleshooting decision tree on nine printable pages. [PingLabz Pro](https://www.pinglabz.com/membership/?plz%5Fplacement=pricing:ftd-transparent-mode-fmc:mid:v1) unlocks all 68 browser labs, 500 CCNA practice questions and two timed mock exams for $59/year or $7.99/month. Coming soon · planned price $19 ASA Firewall Field Kit A troubleshooting runbook for packet flow, packet-tracer, captures, asp-drop, NAT, failover and IPsec, plus the ASAv Containerlab topologies from the PingLabz ASA labs. It isn't built yet. [See what's planned and join the waitlist](https://www.pinglabz.com/cisco-asa-field-kit/) ## Verification checklist - Confirm transparent mode with `show firewall`; do not infer it from the presence of a bridge object in FMC. - Check bridge group 1 contains both intended members and BVI1 has the expected address. Confirm the member links are up. - Check endpoint MAC learning on br-in and br-out. Treat it as bridge evidence, not permission to pass IP traffic. - In FMC, compare each member's Switched security zone with the source and destination zones in the intended ACP rule. - Deploy and wait for Completed. Keep tests taken during deployment separate from tests after completion. - Flush the client's data-interface neighbor entry, then test both ping and the real HTTP service. Check the response body as well as status 200. - In Unified Events, identify the real connection by its tuple and inspect action, rule, zones, and interfaces. Account for the display clock. - Compare deployed ACL entries and run a transparent trace with the server's destination MAC. After repair, require fresh successful traffic and the expected Allow event. ## Related firewall labs - [Register FTDv to FMC](https://www.pinglabz.com/register-ftd-to-fmc-containerlab/) — Pair the device and manager, including the registration-key mismatch fault. - [FTD packet-tracer and captures in FMC](https://www.pinglabz.com/ftd-packet-tracer-capture-fmc/) — Compare a simulated allow with evidence from real traffic. - [FMC deployment history and rollback](https://www.pinglabz.com/fmc-deployment-history-rollback/) — Check deployments and restore an earlier policy state. - [FTD access control with local FDM](https://www.pinglabz.com/ftd-access-control-policy-fdm-packet-tracer/) — Follow a separate fault caused by access-rule order. - [ASA transparent firewall configuration](https://www.pinglabz.com/asa-transparent-firewall-configuration/) — Compare the ASA bridge-group and BVI lab. - [ASA routed vs transparent mode](https://www.pinglabz.com/cisco-asa-routed-vs-transparent/) — When a bridge group fits better than a routed hop. ## FAQ ### Why does ARP work while ping and HTTP fail through transparent FTD? In this lab, ARP still crossed the bridge after Ethernet0/1 moved to PL-BR-DMZ. The ACP's IP allow rules required PL-BR-OUT, so ping and HTTP hit Default Action. ARP reachability did not establish an ACP permit. Cisco documents this: ARP crosses a bridge group without an access rule, but unicast IPv4 needs one ([Cisco](https://www.cisco.com/c/en/us/td/docs/security/secure-firewall/management-center/device-config/100/management-center-device-config-10-0/get-started-tfw.html?ref=pinglabz.com)). ### What is an FMC Switched security zone used for here? It is the security-zone type FMC 10.0.1 required for these transparent bridge members. The ACP matched PL-BR-IN to PL-BR-OUT. The physical member editor's Mode: None field was separate from that Switched zone type. ### Does BVI1 route between the client and server? No. Both hosts used 10.42.50.0/24 and reached each other through bridge group 1\. BVI1 held 10.42.50.2/24; there was no router or NAT in the tested data path. FMC management used the separate tunnel. ### Why did FMC Packet Tracer need a destination MAC? For the untagged bridge-member trace used here, the GUI required Destination MAC Address. Supplying the server MAC let FTD select br-out, after which the faulted trace exposed the default ACL drop. The corrected CLI command also placed that MAC before the destination IP. Inside a bridge group, Cisco documents a destination-MAC lookup instead of a route lookup to choose the egress interface ([Cisco](https://www.cisco.com/c/en/us/td/docs/security/secure-firewall/management-center/device-config/100/management-center-device-config-10-0/get-started-tfw.html?ref=pinglabz.com)).