One way tunnel establishment

[stephan.l.martin1]

I am working on establishing a site-to-site VPN connection with an XE router. I am only able to establish the tunnel when sourcing traffic from the router's end. After clearing the SA and initiating traffic from the inside interface (utilizing an IP that matches the crypto map), the SA is unable to establish as it is being dropped by the VPN engine. 

As this is a replacement system, we are establishing a test environment to isolate traffic/subnets. The FTD itself is barebones in terms of policy configurations at this point as we work through the bidirectional establishment issues.

My first question is: Is manual NAT REQUIRED even if NAT is not taking place? When establishing the S2S topology, NAT exemptions are added to the device NAT configuration. Do we still need to configure a manual NAT policy?

FTD Version: 7.4.2

FMC Version: 7.4.2.1

I will post requested information in the morning once I am at my system. Thank you in advance for any clarity you can offer!

[balaji.bandi]

You need to validated the configuration, make sure you have routing and ACL correct in place, and do you have PFS configured ?

If they are not overlapped subnet, you do not need NAT (if that is requirement)

Debug :

https://community.cisco.com/t5/vpn/debug-vpn-on-ftd/td-p/4702003

[stephan.l.martin1]

Thank you for your input. I will look into this and get back. I have verified that the crypto map, IKEv2 policy, and IPsec policy works. It’s definitely an FTD side issue as we aren’t seeing UDP 500 on the XE router when clearing the SA and generating interesting traffic. 

[balaji.bandi]

As per the information you mentioned when the traffic initiated from XE router all works, but when the tunnel tear down, and try to initiate from FTD not working.

as suggested run debug and see any where where the traffic dropping and post the logs as per the debug

[stephan.l.martin1]

Good morning. I am working through this now. Will post once I have some logs to share. 

[stephan.l.martin1]

Debug output attached. Please note IP's have been sanitized (first 2 octets)

[Rob Ingram]

@stephan.l.martin1 you only need a NAT exemption rule if there is NAT configured that may unintentially translate the VPN traffic, so potentially in this instance you do not need a NAT exemption rule.

Is the IPSec SA established? Check the output of "show crypto ipsec sa" on both peers and determine if the encap|decap counters are increasing.

On the FTD you need to explictly permit the VPN traffic in the Access Control Policy, otherwise traffic is dropped.

You could run packet-tracer from the FTD to provide more information as to the problem.

[stephan.l.martin1]

Good morning! The ASP is wide open at the moment given that we are in the initial testing/configuration phase. Packet tracer succeeds when the SA is established by the XE side of the VPN (interesting traffic establishes the tunnel coming towards the FTD). Upon clearing the SA and attempting to reestablish with traffic being sourced from the inside interface the SA fails to establish and packet tracer fails on the VPN engine. 

[Rob Ingram]

@stephan.l.martin1 as previously suggested, check PFS. If the initiator does not have PFS configured or is configured using a smaller group than the responder, the connection will fail. If the initiator has a PFS group configured but the responder does not, or the responder has a smaller group configured, then the PFS-group of the initiator is used.

When you said "Upon clearing the SA and attempting to reestablish with traffic being sourced from the inside interface the SA fails to establish and packet tracer fails on the VPN engine." - if you turn on IKE debugs, is the tunnel even attempted to establish?

Can you provide the output of packet-tracer please?

[stephan.l.martin1]

Packet tracer screenshots attached. We did annotate that PFS was mismatched on the XE vs FTD side (FTD DH20, XE DH14) upon correcting we are still seeing the same issue. 

[Rob Ingram]

@stephan.l.martin1 the output of the logs will provide a clue.

Other things to check, what is the connection type? The FTD could be configured for "answer-only" there would not attempt to establish a tunnel. https://www.cisco.com/c/en/us/td/docs/security/secure-firewall/management-center/device-config/740/management-center-device-config-74/vpn-s2s.html

Also, as alluded to by @Aref Alsouqi is the remote peer (responder) behind a dynamic NAT? if so that would not work.

[stephan.l.martin1]

Connection type is set as bidirectional. We've cycled from bidi to originate only with the same results. Please note I have attached debug logs above to a response to @balaji.bandi 

[Rob Ingram]

@stephan.l.martin1 can you turn on IKEv2 debugs "debug crypto ikev2 platform" and "debug crypto ikev2 protocol" for more debug information.

https://www.cisco.com/c/en/us/td/docs/security/firepower/621/configuration/guide/fpmc-config-guide-v621/firepower_threat_defense_vpn_troubleshooting.pdf

[stephan.l.martin1]

@Rob Ingram please see attached. 

[Rob Ingram · Accepted solution]

@stephan.l.martin1 you will need to go to system support diagnostic-cli on the FTD CLI and set debug commands (as above). The debug logs will appear once you create interesting traffic to attempt to establish the tunnel.

If required, set the Platform settings to enable logging, this will get the debug output to appear on your ssh session. https://community.cisco.com/t5/network-security/ftd-cli-ssh-debugging/td-p/3711562