A local Snort 3 rule set to Block fired an FMC intrusion event for the exact URI, and the client still got HTTP 200. The policy was in Detection Inspection Mode. Switching it to Prevention blocked the marker request while normal HTTP kept working.
One FTD twice NAT rule did source PAT and destination translation from a partner's old address to its new one. Swapping the destination objects in FMC broke the old and the new address for different reasons. Counters and captures showed why.
A broad PAT rule in NAT Rules Before changed a server's outbound source from 10.42.20.5 to 10.42.20.1, and the partner reset the connection. Inbound HTTP and packet-tracer looked fine. NAT counters and a capture found it; NAT Rules After fixed it.
A deploy that disabled Allow-Web completed successfully and broke HTTP. FMC Deployment History rolled the FTD back and restored HTTP 200, but FMC still held the bad policy, so the next deploy would have broken it again.
FMC Packet Tracer said ALLOW and Unified Events recorded Allow, but curl timed out. FMC captures with Trace showed SYNs reaching the server and no SYN-ACK returning: the server had lost its return route. One route fixed it.
A broad FMC prefilter Fastpath rule let client-b bypass an explicit ACP block and opened port 8080 for both clients. Real HTTP tests, packet-tracer and Unified Events show why changing the rule to Analyze restored access control.
FMC deployed the route successfully and Unified Events said Allow, but HTTP timed out. Follow the FTD routing table, unanswered ARP and a packet-tracer no-v4-adjacency drop to an unused next hop, then verify the fix through the real router.
A deliberate registration key mismatch produced only a generic FMC timeout while TCP/8305 was reachable. Follow the FTD tunnel evidence, clean re-registration, a failed first deployment and a successful retry, then test the forwarding baseline.
A broad subnet block placed above Allow-Web in FDM caught HTTP first. Follow FTD packet-tracer, system support trace and the acl-drop to the rule ID, then move Allow-Web back to the top and verify both services.
FDM would not load while pings and HTTP still crossed the FTDv. The management address and gateway had moved off the management network. Bootstrap FDM through the REST API, break management, and restore it from the serial console.
One static route sent client SYNs around the ASA while SYN-ACKs crossed it, so the ASA dropped them as tcp-not-syn with syslog 106015. Restoring routing fixed it; a scoped TCP state bypass also worked once the outside ACL allowed the return.
Both ASAv data interfaces were up, the ACL permitted the traffic and PAT was configured, yet the first pings failed. ASP drop counters showed no-route to a target beyond the outside subnet. One default route fixed ping and HTTP.