> ## 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. # Register FTD to FMC: Fix a Registration Key Mismatch - URL: https://www.pinglabz.com/register-ftd-to-fmc-containerlab/ - Published: 2026-10-19T09:01:17.000Z - Updated: 2026-10-19T22:18:33.000Z - Description: A deliberate registration key mismatch produces FMC’s generic timeout. Follow the FTD tunnel evidence, clean registration, failed first deployment and successful retry, then build and test the FMC-managed forwarding baseline. - Author: Jaime - Tags: Firewall, Security, Network Security, Troubleshooting, Cisco ![FMC and FTDv topology in Containerlab: mismatched registration keys leave pl-ftd-edge Pending while TCP/8305 connects](https://storage.ghost.io/c/ff/28/ff28db4a-11e1-4835-b928-158974cf96c1/content/images/2026/10/fmc-ftd-register-topology.png) FMC’s failed registration task ended with this message: > pl-ftd-edge: Registration timed out. Please check connectivity and registration id The task stopped after 2m09s. FTD still showed Pending, and there were no management tunnel peers. Yet a TCP connection from the FTD guest to FMC on port 8305 succeeded. The fault was deliberate: FTD and FMC had different registration keys. Matching those keys and adding the device again completed registration over the same network path. The timeout did not name the mismatch; the surrounding evidence made the diagnosis. ![FMC Tasks shows registration failed after 2m9s with the connectivity and registration ID timeout message.](https://storage.ghost.io/c/ff/28/ff28db4a-11e1-4835-b928-158974cf96c1/content/images/2026/10/fmc-ftd-register-shot-09-key-mismatch-registration-failure.png) FMC Tasks shows registration failed after 2m9s with the connectivity and registration ID timeout message. This is the first lab in the FMC-managed FTD series, built in my home lab. The recorded run used FMCv 10.0.1 build 1, FTDv 10.0.0 build 140, and an IOL router in Containerlab. It is a home-lab result, not a supported production deployment. Registration worked, the first automatic deployment failed, and a normal deployment retry succeeded. ## Topology and addressing The traffic path is client-a/client-b → sw-in → FTD inside → FTD outside → r-core → server. FMC manages FTD over a separate management tunnel; it does not sit in the client-to-server forwarding path. | Node or interface | Address | Purpose | | ------------------------- | -------------------------- | -------------------------------------------------------- | | client-a eth1 | 10.42.10.21/24 | Inside client; server route through 10.42.10.1 | | client-b eth1 | 10.42.10.22/24 | Second inside client; same server route | | sw-in | Layer 2 only | Bridge joining both clients to FTD inside | | FTD Ethernet0/0 | 10.42.10.1/24 | inside; security zone PL-INSIDE | | FTD Ethernet0/1 | 10.42.20.1/29 | outside; security zone PL-OUTSIDE | | r-core Ethernet0/1 | 10.42.20.2/29 | Transit link toward FTD | | r-core Ethernet0/2 | 10.42.30.1/24 | Server LAN gateway | | server eth1 | 10.42.30.80/24 | Separate HTTP listeners on TCP/80 and TCP/8080 | | FTD guest management eth0 | 10.0.0.15/24 | FMC control and event tunnel through virtual NAT | | FMCv | Management tunnel endpoint | Central configuration, deployment, and connection events | The FTD server route points to 10.42.20.2\. The IOL router has a return route for 10.42.10.0/24 through 10.42.20.1, and the server routes back through 10.42.30.1\. There is no data-plane NAT policy in this baseline. If you need the earlier local-management setup, [FTDv in Containerlab with FDM](https://www.pinglabz.com/ftdv-fdm-containerlab-bootstrap/) covers that separate lab. This one starts with FMC registration and builds a new forwarding baseline. ### How the management tunnel crosses virtual NAT The appliance guests sit behind their VM launchers' virtual NAT. FMC and FTD have reachable container-side management endpoints, with TCP/8305 forwarded into the guests. For FTD, the external 8305 listener reaches virtual-machine host port 28305, then guest 10.0.0.15:8305\. FMC's listener forwards 8305 into its guest too. FMC's Add Device Host field used the reachable FTD container-side endpoint, rather than the guest's 10.0.0.15 address. FTD's manager configuration pointed at FMC's reachable endpoint. The completed tunnel reported the FTD guest-side NAT peer as 10.0.0.2. The FTD NAT ID matters here because the registration needs a shared identifier across that translated management path. The same NAT ID was supplied in FTD's manager command and FMC's Add Device form. The registration key also had to match. These are separate fields: keeping the NAT ID consistent did not compensate for using different keys. This run used a reachable Host value plus a matching NAT ID. It did not test NAT-ID-only registration or require DONTRESOLVE. The management translation also has nothing to do with translating the inside clients' traffic. ## The fault: different registration keys On the FTD CLI, `configure manager add` configured the remote manager with one registration key and the shared NAT ID. In FMC, Devices → Device Management → Add Device used a different key on purpose. The GUI registration selected display name `pl-ftd-edge`, access policy `PL-Edge-ACP`, Virtual device, FTDv50, and Essentials. The policy initially used Block All Traffic as its default action. The host, key, and NAT ID values are omitted here. After the failed task, `show managers` on FTD still showed this state. This is a redacted excerpt from the recorded CLI: ```text > show managers show managers Type : Manager Host : Display name : Identifier : Registration : Pending ``` On the same FTD CLI, `sftunnel-status` had no peer to inspect: ```text > sftunnel-status sftunnel-status SFTUNNEL Start Time: Mon Oct 19 06:43:00 2026 Both IPv4 and IPv6 connectivity is supported Broadcast count = 0 Reserved SSL connections: 0 Management Interfaces: 2 eth0 (control events) 10.0.0.15, tap_nlp (control events) 169.254.1.2,fd00:0:0:1::2 *********************** No peers to check ``` Pending means the manager was configured locally but registration had not completed. The successful manager-add message by itself was not proof that FMC had accepted the device. ## Diagnose the timeout before changing the network FMC's “Registration timed out. Please check connectivity and registration id” message was generic in this run. It did not say “registration key mismatch.” The task readback reported FAILED and REGISTRATION\_FAILED, while FTD remained Pending. A connection test from the FTD guest's expert shell to FMC TCP/8305 returned: ```text Guest-to-FMC TCP/8305 connection succeeded ``` That proves the tested TCP connection could be established. It does not prove successful registration, authentication, or both tunnel channels. It does make a blanket “port 8305 is unreachable” explanation a poor fit for this evidence. For this symptom, check the management path first, then compare both registration inputs: the key and the NAT ID. Check the Host value in FMC as well; a guest address behind virtual NAT is not automatically the endpoint FMC can reach. Read `show managers` and `sftunnel-status` alongside the FMC task rather than treating the GUI timeout as a diagnosis. Here, the known key difference, reachable TCP/8305, Pending state, and absent peers all pointed in the same direction. Correcting only the registration setup on that path then produced a working tunnel. No host networking changes or appliance restarts were needed. ![Fixed state: matching key and NAT ID, registration completed, and traffic flowing through PL-Edge-ACP](https://storage.ghost.io/c/ff/28/ff28db4a-11e1-4835-b928-158974cf96c1/content/images/2026/10/fmc-ftd-register-fig2.png) ## Fix: delete the pending manager and add it again For this fresh lab device, the repair was to remove the pending manager on FTD and add it with the same key used in FMC. The NAT ID stayed the same. The following is the recorded FTD CLI sequence; the angle-bracket fields are existing redactions, not literal values to enter: ```text > configure manager delete configure manager delete Manager successfully deleted. > configure manager add configure manager add Manager successfully configured. Please make note of reg_key as this will be required while adding Device in FMC. ``` Back in FMC, Add Device was submitted again with the reachable Host endpoint, `pl-ftd-edge`, matching key and NAT ID, and the same initial policy and license selections. This was a new registration attempt after the failed one. The recorded sequence on October 19, 2026 used UTC timestamps: | Stage | Recorded observation | | ------------------------------ | ---------------------------------------------------------------------- | | Wrong-key Add Device submit | 06:43:26.995; task failed after 2m09s | | Matching-key Add Device submit | 06:48:01.915 | | Tunnel connection start | 06:48:13, as later reported by FTD | | FMC secure-connection readback | 06:48:40.939; about 39 seconds after submit | | Discovery-success readback | 06:50:23.684; about 2m22s after submit; initial deployment in progress | | FTD completed-state readback | 06:51:41 | Those readback times are observations, not exact completion times or registration targets for another VM. At the completed-state check, `show managers` included: ```text Registration : Completed Management type : Configuration and analytics ``` The tunnel output also showed both channels connected: ```text Cipher used = TLS_AES_256_GCM_SHA384 (strength:256 bits) ChannelA Connected: Yes, Interface eth0 Cipher used = TLS_AES_256_GCM_SHA384 (strength:256 bits) ChannelB Connected: Yes, Interface eth0 ``` FMC Device Management now showed Normal health, Routed mode, version 10.0.0, and Essentials. Initial deployment was still pending in this view: ![Device Management lists pl-ftd-edge as Normal on version 10.0.0 with Essentials, while Deployment Pending remains 1.](https://storage.ghost.io/c/ff/28/ff28db4a-11e1-4835-b928-158974cf96c1/content/images/2026/10/fmc-ftd-register-shot-13-device-normal-health.png) Device Management lists pl-ftd-edge as Normal on version 10.0.0 with Essentials, while Deployment Pending remains 1. ## Registration succeeded; the first deployment failed The automatic deployment following registration failed after 1m06s. FMC's troubleshooting details showed a database/retrieved LINA checksum mismatch: ```text DB Path/Connection Failure while validating lina checksum : Checksum from DB '5e1c6988dd637b3f3d3d609f18a864bb' does not match retrieved checksum '85b90be6 4295812e f2f914b4 b50bb2ec ' ``` ![The initial automatic deployment troubleshooting dialog reports a LINA checksum mismatch.](https://storage.ghost.io/c/ff/28/ff28db4a-11e1-4835-b928-158974cf96c1/content/images/2026/10/fmc-ftd-register-shot-15-initial-deployment-checksum-failure.png) The initial automatic deployment troubleshooting dialog reports a LINA checksum mismatch. A normal scoped deployment retry through the FMC GUI succeeded in 1m51s. No checksum files, database contents, or appliance settings were manually repaired. That retry establishes recovery in this run; it does not establish the underlying cause of the checksum mismatch. ![FMC Deployments reports Deployment to device successful after the initial deployment retry, with a duration of 1m51s.](https://storage.ghost.io/c/ff/28/ff28db4a-11e1-4835-b928-158974cf96c1/content/images/2026/10/fmc-ftd-register-shot-18-initial-redeploy-success.png) FMC Deployments reports Deployment to device successful after the initial deployment retry, with a duration of 1m51s. Deployment History retained the failed automatic job and the successful retry. The later forwarding-baseline deployment also succeeded, in 1m10s. The series returns to those records in [FMC deployment history and rollback](https://www.pinglabz.com/fmc-deployment-history-rollback/). ## Build the shared forwarding baseline in FMC Registration gives FMC a managed device. The clients still need interface addresses, routing, and an access control policy before this becomes a useful traffic lab. All FMC configuration changes in this run were made through the GUI; API reads were used to check the saved state. ### Interfaces, zones, and the server route In the device's Interfaces page, Ethernet0/0 was named inside, assigned 10.42.10.1/24, and placed in PL-INSIDE. Ethernet0/1 became outside, with 10.42.20.1/29 in PL-OUTSIDE. ![The Interfaces page shows inside 10.42.10.1/24 in PL-INSIDE and outside 10.42.20.1/29 in PL-OUTSIDE.](https://storage.ghost.io/c/ff/28/ff28db4a-11e1-4835-b928-158974cf96c1/content/images/2026/10/fmc-ftd-register-shot-20-interfaces-configured.png) The Interfaces page shows inside 10.42.10.1/24 in PL-INSIDE and outside 10.42.20.1/29 in PL-OUTSIDE. The Disabled entries in that screenshot belong to Path Monitoring. They do not show administratively disabled data interfaces. After deployment, `show interface ip brief` confirmed both data interfaces up/up: ```text Interface IP-Address OK? Method Status Protocol Ethernet0/0 10.42.10.1 YES manual up up Ethernet0/1 10.42.20.1 YES manual up up ``` Under Routing → Static Route, `PL-SERVER-NET` represented 10.42.30.0/24\. Its route used outside, gateway 10.42.20.2, and metric 1. ![The static route dialog selects PL-SERVER-NET on outside through gateway 10.42.20.2 with metric 1.](https://storage.ghost.io/c/ff/28/ff28db4a-11e1-4835-b928-158974cf96c1/content/images/2026/10/fmc-ftd-register-shot-21-static-route-dialog.png) The static route dialog selects PL-SERVER-NET on outside through gateway 10.42.20.2 with metric 1. The deployed `show route` excerpt confirmed the connected networks and server route: ```text C 10.42.10.0 255.255.255.0 is directly connected, inside L 10.42.10.1 255.255.255.255 is directly connected, inside C 10.42.20.0 255.255.255.248 is directly connected, outside L 10.42.20.1 255.255.255.255 is directly connected, outside S 10.42.30.0 255.255.255.0 [1/0] via 10.42.20.2, outside ``` That next hop is part of the fixture. [FTD static route to a dead next hop](https://www.pinglabz.com/ftd-static-route-fmc-next-hop/) changes it in the next lab so the routing failure has a known working comparison. ### Access rules and logging `PL-Edge-ACP` used these rules in order: | Order | Rule | Match and action | Connection logging | | ------- | ----------------- | ------------------------------------------------------- | ------------------------- | | 1 | Allow-ICMP | PL-INSIDE → PL-OUTSIDE; ICMP any type/code; Allow | Disabled | | 2 | Allow-Web | Same zones; destination 10.42.30.80; HTTP TCP/80; Allow | At end, sent to FMC | | Default | Block All Traffic | Remaining traffic; Block | At beginning, sent to FMC | ![PL-Edge-ACP lists Allow-ICMP first, Allow-Web for 10.42.30.80 and HTTP second, and Block All Traffic as the default action.](https://storage.ghost.io/c/ff/28/ff28db4a-11e1-4835-b928-158974cf96c1/content/images/2026/10/fmc-ftd-register-shot-25-access-policy-rules.png) PL-Edge-ACP lists Allow-ICMP first, Allow-Web for 10.42.30.80 and HTTP second, and Block All Traffic as the default action. FMC 10.0.1 disabled end-of-connection logging for the default Block action in the GUI. Beginning logging was enabled instead. Allow-Web did use end logging. This matters when looking for the permitted web connection in Unified Events after the test finishes. The system Default Prefilter Policy remained assigned. No custom prefilter or data-plane NAT policy was added, and `show nat` returned no entries. [Prefilter Fastpath skips the ACP](https://www.pinglabz.com/fmc-prefilter-policy-fastpath/) starts from this baseline and changes the prefilter behavior. For a local-FDM comparison of access rule order, see [FTD access control policy and packet-tracer](https://www.pinglabz.com/ftd-access-control-policy-fdm-packet-tracer/). ## First traffic test and Unified Events After the baseline deployment succeeded, both clients tested 10.42.30.80 through eth1\. Each received four ping replies with no loss, HTTP 200 on TCP/80, and a timeout on TCP/8080. Client-a's ping output was: ```text PING 10.42.30.80 (10.42.30.80): 56 data bytes 64 bytes from 10.42.30.80: seq=0 ttl=63 time=15.705 ms 64 bytes from 10.42.30.80: seq=1 ttl=63 time=3.977 ms 64 bytes from 10.42.30.80: seq=2 ttl=63 time=3.152 ms 64 bytes from 10.42.30.80: seq=3 ttl=63 time=2.794 ms --- 10.42.30.80 ping statistics --- 4 packets transmitted, 4 packets received, 0% packet loss round-trip min/avg/max = 2.794/6.407/15.705 ms ``` Its TCP/80 response was: ```text HTTP/1.1 200 OK Content-Type: text/plain Connection: close PL-server-port-80 ``` The TCP/8080 attempt returned: ```text curl: (28) Connection timed out after 5002 milliseconds Exit: 28 ``` | Client | Ping | TCP/80 | TCP/8080 | | --------------------- | -------------------- | --------------------------- | --------------------- | | client-a, 10.42.10.21 | 4/4 replies; 0% loss | HTTP 200; PL-server-port-80 | Timeout; curl exit 28 | | client-b, 10.42.10.22 | 4/4 replies; 0% loss | HTTP 200; PL-server-port-80 | Timeout; curl exit 28 | Both server listeners also returned HTTP 200 when tested locally. The blocked port test therefore had a listening service behind it. In Events & Logs → Analysis → Unified Events, Last 1 hour showed four connection events: Allow to TCP/80 and Block to TCP/8080 for each client. Narrowing the columns made source IP, destination IP, action, and destination port visible together. ![Unified Events with Last 1 hour selected shows both clients allowed to 10.42.30.80 TCP/80 and blocked to TCP/8080.](https://storage.ghost.io/c/ff/28/ff28db4a-11e1-4835-b928-158974cf96c1/content/images/2026/10/fmc-ftd-register-shot-30-unified-events-both-clients-ports.png) Unified Events with Last 1 hour selected shows both clients allowed to 10.42.30.80 TCP/80 and blocked to TCP/8080. The GUI displayed these events four hours behind the UTC CLI timestamps in this run. The screenshot preserves that display; its times have not been rewritten to make the views agree. For deeper forwarding checks, [FTD packet-tracer allows but capture shows no SYN-ACK](https://www.pinglabz.com/ftd-packet-tracer-capture-fmc/) uses this same fixture. The [ASA packet-tracer guide](https://www.pinglabz.com/cisco-asa-packet-tracer/) is useful background for reading simulated flow decisions alongside real traffic evidence. At the final recorded check, FTD was registered, connected, and deployed. Device Management showed Normal (1), `PL-Edge-ACP`, and Deployment Pending (0). ![Final Device Management shows pl-ftd-edge Normal, assigned PL-Edge-ACP, with Deployment Pending at 0.](https://storage.ghost.io/c/ff/28/ff28db4a-11e1-4835-b928-158974cf96c1/content/images/2026/10/fmc-ftd-register-shot-31-final-device-normal-deployed.png) Final Device Management shows pl-ftd-edge Normal, assigned PL-Edge-ACP, with Deployment Pending at 0. FMC itself still had Talos and security-feed retrieval health alerts. Those were retained. Green FTD health and passing fixture traffic tests do not mean every FMC health check was green. 💡 **Coming from ASA to FTD?** 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:register-ftd-to-fmc-containerlab: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 - Check FMC's registration task and FTD's `show managers` together. This repair ended at Completed, not Pending. - Confirm TCP/8305 reachability on the management path, then compare the registration key and NAT ID at both ends. - Use `sftunnel-status` to confirm connected control and event channels. - Check deployment separately from registration. In this run, the first automatic deployment failed and its normal retry succeeded. - Confirm inside/outside addresses, security zones, the route through 10.42.20.2, and the deployed ACP. - Test both clients: ping and HTTP on TCP/80 should pass in this baseline; TCP/8080 should time out and produce Block events. - Check Unified Events for both source addresses and both destination ports, then verify no deployment remains pending. ## Related firewall labs - [FTDv in Containerlab with local FDM](https://www.pinglabz.com/ftdv-fdm-containerlab-bootstrap/) — Start with the earlier local-management lab. - [FTD access control policy and packet-tracer](https://www.pinglabz.com/ftd-access-control-policy-fdm-packet-tracer/) — Follow a rule-order failure under FDM. - [FTD static route to a dead next hop](https://www.pinglabz.com/ftd-static-route-fmc-next-hop/) — Break the working server route from this fixture. - [FMC prefilter Fastpath skips the ACP](https://www.pinglabz.com/fmc-prefilter-policy-fastpath/) — Change the prefilter behavior against the same baseline. - [FTD packet-tracer and capture with FMC](https://www.pinglabz.com/ftd-packet-tracer-capture-fmc/) — Compare an allow verdict with missing return traffic. - [FMC deployment history and rollback](https://www.pinglabz.com/fmc-deployment-history-rollback/) — Use deployment records to investigate and reverse changes. - [FTD NAT in FMC: Auto NAT vs Manual NAT](https://www.pinglabz.com/ftd-nat-fmc-rule-order/) — A broad PAT rule in NAT Rules Before changes a static-NAT server's outbound source. - [Cisco FTD twice NAT in FMC](https://www.pinglabz.com/ftd-twice-nat-fmc/) — Swapped Original and Translated Destination objects break both the old and new partner addresses. ## FAQ ### How do I register FTD to FMC from the CLI? On FTD, use `configure manager add` with FMC's reachable address, a registration key, and the NAT ID used by this lab. Then add the device in FMC with the corresponding values and policy selection. The recorded repair sequence above shows the command with redacted placeholders. A locally configured manager is only the first step; verify Completed and the tunnel channels afterward. ### Does the FMC registration timeout prove the key is wrong? No. FMC used that generic timeout for the deliberate key mismatch here. The diagnosis also depended on successful TCP/8305 reachability, FTD remaining Pending with no peers, the known unequal keys, and successful registration after correcting them. ### Is the FTD NAT ID a data-plane NAT rule? No. In this run it was the shared registration identifier supplied on FTD and in FMC across the translated management path. The forwarding baseline had no NAT policy or NAT entries. A matching NAT ID did not make mismatched registration keys work. ### Does successful registration mean the first policy deployment succeeded? No. This device registered successfully, then its automatic first deployment failed with a LINA checksum mismatch. A normal GUI deployment retry succeeded in 1m51s, followed by a successful baseline deployment and traffic tests.