A site-to-site tunnel on a Cisco Secure Firewall (FTD) shows IKE and IPsec SAs up, yet remote hosts cannot reach local servers. A packet trace of traffic arriving from the tunnel shows it dropped by the access control policy default action. What should be changed?

On FTD, decrypted VPN traffic is subject to the access control policy unless the option to bypass the policy for decrypted traffic is enabled. With the security associations up, the tunnel is working cryptographically; the packet trace showing a drop by the default action means no rule permits the remote protected network to reach the servers. The fix is to add an access control rule that allows that traffic, ideally with inspection, or to enable the bypass setting and use VPN filters for control. Replacing the preshared key addresses authentication, which already succeeded, since the security associations are established; key strength has no influence on post-decryption policy. A stronger Diffie-Hellman group changes key exchange parameters but does not grant permission through the access control policy, and changing it would only renegotiate the same tunnel. NAT traversal is relevant when a NAT device sits between the peers; it changes how encrypted packets are encapsulated, not whether decrypted packets are permitted by policy. Exam caveat: bypassing the access control policy also bypasses inspection, so many designs prefer explicit allow rules with intrusion policies for VPN traffic. A missing NAT exemption is the other common cause of up-but-no-traffic and shows a translation in the trace. Operational check: rerun the packet trace after deploying and confirm it now matches the new rule and is allowed.