ASA-to-FTD Migration: Guest Inspection Bypass, Partner VPN, and Hairpin NAT
You are migrating a pair of ASA 5525-X firewalls to two FTD 2130 appliances managed by an FMC, using the Secure Firewall migration tool to import the configuration. The source configuration contains 1,900 access control entries, 210 NAT rules and 14 prefilter-style rules, including nine site-to-site VPNs with business partners. Three business requirements are causing debate. First, guest Wi-Fi users must remain blocked from the PCI subnet but must not be inspected for intrusion, because the guest network's traffic volume saturates the appliance and generates meaningless IDS events. Second, one partner VPN carries a legacy application that breaks when inspected, while the other eight must stay fully inspected. Third, internal users must reach three public web servers through the public hostname that resolves to the internet-facing address, even though they are inside the network. The imported policy currently permits everything between inside and DMZ because the migration tool could not resolve every object, and the go-live window is two weeks away.
1. How do you satisfy the guest requirement and the legacy-partner requirement on FTD, and why is the apparently simpler prefilter answer wrong for the guest network?
Read the worked answer
These two requirements look identical but are not, and conflating them is where migrations fail.
The tempting answer for guest Wi-Fi is a prefilter rule with a fastpath action: bypass inspection, done. But prefilter is evaluated before the access control policy and fastpath bypasses the access control policy entirely, not just intrusion inspection. A guest flow fastpathed to the PCI subnet would be permitted, because nothing downstream evaluates it. That directly violates the guest-must-be-blocked requirement. The correct design is an access control rule that targets the guest zone/source and PCI destination with a Block action placed above the general guest rule, plus a general guest-to-outside rule with intrusion inspection disabled (or a variable set that does no inspection). Ordering gives you the block; the rule's inspection settings give you the no-IDS behaviour without removing access control.
The partner VPN is the opposite case: the traffic is already authenticated and encrypted, and the requirement is that a specific partner's flows skip inspection while the rest of the VPN traffic is inspected. Build a VPN-scoped access control rule for that partner's address set with intrusion inspection disabled, ordered above the general VPN rule that has inspection enabled. Again this keeps logging and access control, which is what you want for an externally sourced flow.
Reserve prefilter for genuine cases: blocking known-bad source ranges before the policy engine, and fastpath where you accept that no access control exists for that traffic.
2. Design the hairpin NAT solution for internal users reaching the public web server hostname, and explain how you would prove it works before go-live.
Read the worked answer
The problem is that the internal client resolves a public address, sends traffic to the internet-facing VIP, and the return path from the server goes to an inside address - so the session is asymmetric and the client never sees the reply.
The design is a pair of NAT rules with the interface NAT rule positioned correctly. On the inbound rule (outside-facing VIP to real server address on port range), enable the option that also applies the translation to traffic that arrives on the inside interface from internal clients - that reflexive/U-turn behaviour is what makes an internal client's hit on the public address get translated to the real server, so both client and server stay on the same side. Then the server's replies are source-translated so the client sees the VIP as the source, which keeps the client's TCP state valid. Practically, you need one rule matching inside-originated traffic destined for the VIP and one handling the server-to-client direction, plus the access control rule permitting the inside client to the real server address and the existing outside ACL for real external clients.
Do not do this by guessing. Prove it in three steps: use packet-tracer on the FTD diagnostic CLI with an inside source, the VIP as destination and the service port, and check both the ACP and NAT stages in the output; verify the NAT rule hit counters with the NAT table on the device after a real test from an internal client; and test from an external client at the same time to ensure the change did not break the normal path. Also confirm the source NAT address pool does not conflict with the real server subnet - a hairpin failure is frequently a routing or ARP problem on the translated address rather than a NAT rule problem.
3. The imported policy currently has a broad inside-to-DMZ permit and the go-live window is two weeks out. What is your migration validation plan?
Read the worked answer
Two weeks is enough to validate if you turn the problem around: you do not need to reproduce 1,900 ACEs perfectly, you need to prove which traffic exists and which rules are load-bearing.
First, fix the import mechanically: resolve the unresolved object groups by mapping them to named objects, and reject any imported rule that became 'any' through a failed resolution. An 'any'-to-'any' permit in an imported policy is a finding, not a placeholder - treat it as an open risk item with an owner.
Second, use the source device. Pull hit counts from the ASA before cutover and rank rules by usage. Rules with zero hits over a representative period are candidates for retirement, not migration; rules with heavy hits must be individually verified. This typically shrinks the rulebase dramatically and is the only defensible way to justify what you drop.
Third, exploit FTD's ability to log without blocking. Convert the broad inside-to-DMZ permit into a permissive rule with connection logging for the first week of production, then analyse the logs against the intended narrower rules to find what the broad rule was actually carrying. Where you are unsure, keep the traffic permitted but logged.
Fourth, validate the security-critical paths explicitly: the guest-to-PCI block, both VPN inspection policies, hairpin access, and any rule protecting the DMZ from inside. Test each with real traffic, not just packet-tracer. Finally, agree the cutover rollback: keep the ASA configuration and the return path ready until the FTD pair has run a full business cycle, including month-end.