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?
Enabling IPsec Inspection on the access policy is necessary for allowing site-to-site IPsec VPN traffic to pass through the Cisco FTD. This feature ensures that the FTD can inspect and permit IPsec traffic, which includes the necessary UDP ports (500, 4500) and ESP protocol.
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
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.
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.
agree. the best practice is to use prefilter rather than ACP for S2S VPN traffic, so it can reduce resource of FTD
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
agree. the best practice is to use prefilter rather than ACP for S2S VPN traffic, so it can reduce resource of FTD
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
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
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.
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
I think it is B