Secure Firewall Integration, Troubleshooting, and Operations
This domain tests how Secure Workload and Secure Firewall fit with the rest of the estate, and how you diagnose a flow that should work but does not.
Integration points
- Secure Workload ↔ FMC/FTD: Secure Workload publishes segmentation intent to the firewall manager so policy can be enforced where no agent runs; the FMC is registered as an enforcement appliance and workloads map to firewall objects/scopes.
- Secure Workload ↔ ISE/pxGrid: user and device identity plus security group tags, usable both in Secure Workload policy and in FTD identity rules and inline tagging.
- Secure Workload ↔ cloud connectors and ACI: tag- and EPG-based inventory and network-level enforcement.
- FMC ↔ SIEM: eStreamer for structured connection and intrusion events, syslog for alerting. Syslog over UDP is lossy; use TCP/TLS where the events are audit-relevant.
- NTP, DNS, and certificate trust are integration prerequisites - most "integration broken" tickets are clock or name-resolution issues.
Troubleshooting method
FMC side: check deployment status first (Health Monitor, policies showing out of date), then the task queue for failed deployments, then packet tracer, then captures on ingress and egress. FTD CLI: show managers (registration state), show interface and show route, show nat, show version, and show conn from the diagnostic CLI reached with system support diagnostic-cli; use the expert shell for Linux-level logs. A device reporting no manager explains why nothing you deploy takes effect.
Worked example
A newly added permit rule has no effect. Order of checks: (1) was the policy deployed successfully? (2) does the prefilter fastpath the flow? (3) does an earlier ACP rule match, since first match wins? (4) is NAT translating to an address the rule never sees? (5) run packet tracer to see the actual matching rule, then capture to prove the packet arrives at all. Each step eliminates one layer instead of re-reading the rule.
Operations
Schedule FMC backups to a remote host, back up devices through FMC, and test restores. FMC HA protects management; FTD HA protects the data plane - they are separate designs and each FTD still registers individually. Plan image upgrades in change windows because the data plane reboots, and treat log retention and clock accuracy as compliance requirements.
Traps
- Editing policy and never deploying it; the device silently keeps the old policy.
- Assuming an FTD HA pair appears as one device in FMC.
- Using syslog where eStreamer is needed for connection-level forensics.
- Forgetting prefilter when a rule appears never to match.