Why does site-to-site IPsec VPN fail behind Cisco FTD with allowed ports?

Configure security policies such as access control, DNS, identity, and network analysis policy in Secure Firewall Management Center

Answer Correct answer: C — Change the matching access control rule action from Allow to Trust so site-to-site IPsec traffic bypasses Snort inspection and the tunnel can establish.

A network administrator is configuring a site-to-site IPsec VPN to a router sitting behind a Cisco FTD. The administrator has configured an access policy to allow traffic to this device on UDP 500, 4500, and ESP. VPN traffic is not working. Which action resolves this issue?

Change the access policy to allow all ports.
Enable IPsec Inspection on the access policy.
Set the allow action in the access policy to trust. Correct Answer
Modify the NAT policy to use the interface PAT.

Community Insight

Tested: FTD access control rule actions for VPN pass-through; trap: assuming that simply permitting the required ports is enough, when the Allow action still subjects IPsec traffic to Snort inspection.

This question tests why site-to-site IPsec VPN traffic through a Cisco FTD still fails when the access policy allows UDP 500, UDP 4500, and ESP. The page establishes that changing the rule action to Trust is the correct fix, because Allow sends the traffic through Snort inspection, which can drop IKE and ESP.

Many learners choose B (Enable IPsec Inspection) because ASA-style IPsec pass-through inspection sounds necessary, but FTD access control policies do not have that option; the real fix is to use Trust to bypass Snort.

Community Discussion (11 comments)

donciga 👍 1 Selected: C

The correct answer is C. The ACP already permits UDP/500, UDP/4500, and ESP, so the traffic is not being denied by a block rule. When the action is Allow, the flow is still sent to Snort. Snort inspection commonly breaks IKE/ESP (reassembly, normalization, or file/app inspection). Changing the matching rule to Trust (or a prefilter Fastpath) forwards IPsec without Snort and lets the tunnel to the router behind the FTD establish.

TECH3K3 👍 1 Selected: D

The only reason I think it could be D, because this is the setup I have in my house. I have a Cisco ASA5508X behind a Cisco ISR 1100 router and I have a policy pointing to the PAT. interface.

OskarNorman 👍 1

I think it is B

gwb 👍 1

I agree. the rule was in the place (said allowed), it means additional inspection is not required because it is already blocked. we need to trust IPsec rather than another inspection

gwb 👍 1

agree. the best practice is to use prefilter rather than ACP for S2S VPN traffic, so it can reduce resource of FTD

spambox730 👍 6 Selected: C

A - necessary ports (and ESP protocol) are allowed already B - 'inspect ipsec-pass-thru' can be configured in policy-map so it is not part of access policy C - Ensures there are no further inspections just in case SNORT dropped the traffic. D - NAT detection during VPN negotiation will detect NAT anyway. It does not matter if 1:1 or PAT

Gabranch 👍 2 Selected: D

Try as I might, I can't find any information about doing IPSEC inspection on an ACP for FTD. A is not correct That leaves C/D. Bypassing inspection (trust instead of allow) - It would be a troubleshooting step for me but I'm not confident that it would solve it. With D, there's an assumption that the NAT configuration is such that the inside VPN destination does not have a 1:1 and is instead just catching a ride on the global outbound NAT. In that case, we would need a PAT for inbound connections to be directed toward the VPN endpoint.

Initial14 👍 1 Selected: B

The trick here is "to this device" meaning from the outside. But the thing is, if you have device behind NAT, you must enable IPSEC ( protocol 50 and UPD 4500 NAT-T) for device to initiate connection. In this case connection was opened from the outside to the inside, and in this case it will not work because of NAT... To put it simply, just reverse the rules regarding source/destination

Joe_Blue 👍 3 Selected: B

The correct answer is B. To allow site-to-site IPsec VPN traffic through a Cisco FTD, the IPsec Inspection feature must be enabled on the access policy. IPsec Inspection is a feature that allows the FTD to inspect and permit IPsec traffic. It is required to allow site-to-site IPsec VPN traffic to pass through the FTD. By enabling IPsec Inspection on the access policy, the FTD will permit the necessary UDP ports (500, 4500) and ESP traffic.

Silexis 👍 1

IPSEC Inspection in fact is allowing the ports ant proto already configured. You can't do a real inspection on an IPSEC flow but if you enable IPSEC Inspection with Allow, it will push the flow to SNORT and the IPSEC will be broke...... C is the right answer here

z6st2a1jv 👍 2

Yes ISP inspection is there to allow the traffic related to IKE, without the need to manually configure the rules in the ACP. But in the question, they say that those rules are already in place. So I think C is the better choice.

Comments & Corrections

No comments yet — spotted an error or have a note? Share it below.

Expert Analysis

Why the Answer Is Correct

The access policy already permits UDP 500, UDP 4500, and ESP, so the failure is not a simple port-blocking issue. In Cisco FTD, an Allow action in an access control rule sends matching traffic to Snort for inspection, and Snort's normalization or application-layer processing can interfere with IKE and ESP, preventing the tunnel from coming up. Changing the matching rule to Trust bypasses Snort entirely and forwards the IPsec packets, which is the recommended way to pass site-to-site VPN traffic through FTD. This is why option C directly resolves the problem, as noted by community member donciga who explained that "Allow" still runs Snort inspection and "Trust" forwards IPsec without Snort.

Why the Other Options Are Wrong

Option A is overly permissive and would not fix the underlying inspection problem, since the needed ports are already allowed. Option B references an "IPsec Inspection" setting that does not exist as an access-policy option in FTD; IPsec pass-through is not a checkbox in ACP, and if needed it is handled via FlexConfig or NAT behavior. Option D suggests interface PAT, but PAT cannot forward ESP (IP protocol 50) because ESP has no TCP/UDP ports; NAT-T only helps UDP 4500, and changing to interface PAT would likely break the ESP path rather than fix it. Therefore none of these address the Snort-inspection drop that Trust resolves.

Community Comment Notes

spambox730 pointed out that the necessary ports are already allowed and that "inspect ipsec-pass-thru" is configured in a policy-map, not the access policy, which steers toward C. donciga and gwb both argued that an Allow rule still sends IKE/ESP to Snort and that Trust (or a prefilter fastpath) is needed, with gwb calling prefilter the best practice for site-to-site VPN traffic. While Joe_Blue and OskarNorman voted for B, their reasoning relies on an IPsec inspection feature not present in the FTD access control policy. Gabranch and TECH3K3 leaned toward D but admitted uncertainty, and the NAT concern they raised does not override the inspection issue described in the question.

Exam Strategy

When an FTD access policy already permits the required VPN ports but the tunnel still fails, suspect Snort inspection interfering with IKE or ESP rather than a missing access rule. Look for an action change to Trust or a prefilter fastpath, because Allow always sends traffic to Snort.

Frequently Asked Questions

Why does the Allow action still drop IPsec VPN traffic in Cisco FTD?

Allow sends matching traffic to Snort inspection, which can interfere with IKE and ESP. Switching to Trust bypasses Snort so the tunnel can establish.

Can interface PAT forward ESP for a site-to-site VPN behind FTD?

No, ESP uses IP protocol 50 and has no ports, so PAT cannot translate or forward it. You need static NAT or direct routing for the VPN peer.

More 300-710 FAQ →

Related Analysis

← Back to 300-710 Study Guide