Remote access VPN clients connect to a Cisco Secure Firewall (FTD) and inside servers see the traffic, but replies never reach the clients. A packet trace shows the servers' replies to the VPN pool being translated to the outside interface address. What is the fix?
Select an answer to reveal the explanation.
Short Explanation
Here's the trap: a broad PAT rule grabs the servers' replies and rewrites them as if they were headed to the internet, so they never go back into the tunnel. A NAT exemption tells the firewall leave these addresses alone. Fix the NAT and you'll see the replies find their way home.
Full Explanation
FTD processes NAT before VPN encryption decisions are applied to return traffic. If a broad dynamic NAT or PAT rule matches traffic from inside networks to any destination, replies destined for the VPN address pool are translated to the outside interface address, so they no longer match the VPN's protected traffic and are sent out unencrypted or dropped. A NAT exemption, implemented as an identity NAT rule from the inside networks to the VPN pool and placed so it matches before the broad translation, keeps addresses unchanged and lets replies enter the tunnel. Adding a PAT rule for the pool creates more translation, the opposite of what is needed, and the clients expect replies from real server addresses. Decryption policy concerns inspection of TLS sessions and does not perform address translation, so disabling it cannot stop the rewrite. Split tunneling governs which destinations the client sends into the tunnel; corporate servers would still be tunneled, and it has no influence on how the firewall translates server replies. Exam caveat: identity NAT for VPN traffic usually needs a route lookup on the egress interface so the firewall forwards correctly; review that setting rather than ignoring it. Operational check: add the exemption above the broad rule, run packet tracing from a server to a client address, and confirm the trace shows no translation and an encrypt step.