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!

[stephan.l.martin1]

@Rob Ingram Sorry for the slow response. In an effort to not duplicate efforts I will be holding short on pushing updated debug/files. We currently have TAC looking at the debug output and show tech output. We spent about a little over an hour reviewing all of the configurations on the FTD and RTR side. Once I have an update on whether this is a bug or if there was a missing configuration I will be sure to submit to this threat for the benefit of anyone else having this issue. 

[Aref Alsouqi]

As suggested by @Rob Ingram please try to run packet tracer twice on the FTD right after you cleared the tunnel and share the output for review. Also, is this FTD sitting behind a NAT device?

[stephan.l.martin1]

Attempted per your request with the same results (fail) no change from attachment in response to @Rob Ingram 

[stephan.l.martin1]

@Rob Ingram The issue was hiding in plain sight but obscured. As part of our deployment, we attempted to establish multiple VPNs distributed between separate VRFs. The result was that the 8300 router was selecting the inappropriate IKEv2 and IPSec profiles resulting in failed negotiations (the configs were the same but it was sourcing the response from a different VPN responder)

I believe there may have been multiple issues associated as we worked through various configuration options- but this is ultimately the issue that appears to have caused the bulk of our headache.

I would like to thank you, @Aref Alsouqi and @balaji.bandi for your assistance!

Log output:

011024: *Oct 22 15:37:02.359 MDT: IKEv2:(SESSION ID = 19631,SA ID = 1):parsing NOTIFY payload NOTIFY(NON_FIRST_FRAGS)

011025: *Oct 22 15:37:02.359 MDT: IKEv2:(SESSION ID = 19631,SA ID = 1):Stopping timer to wait for auth message
011026: *Oct 22 15:37:02.359 MDT: IKEv2:(SESSION ID = 19631,SA ID = 1):Checking NAT discovery
011027: *Oct 22 15:37:02.359 MDT: IKEv2:(SESSION ID = 19631,SA ID = 1):NAT not found
011028: *Oct 22 15:37:02.359 MDT: IKEv2:(SESSION ID = 19631,SA ID = 1):Searching policy based on peer's identity 'X.X.248.100' of type 'IPv4 address'
011029: *Oct 22 15:37:02.359 MDT: IKEv2:% Getting preshared key from profile keyring DB-2 ##########WRONG PROFILE####
011030: *Oct 22 15:37:02.359 MDT: IKEv2:% Matched peer block 'DBIDS'
011031: *Oct 22 15:37:02.359 MDT: IKEv2:(SESSION ID = 19631,SA ID = 1):Searching Policy with fvrf 5, local address X.X.118.
011050: *Oct 22 15:37:02.362 MDT: IKEv2-ERROR:(SESSION ID = 19631,SA ID = 1):: There was no IPSEC policy found for received TS
011051: *Oct 22 15:37:02.362 MDT: IKEv2:(SESSION ID = 19631,SA ID = 1):Sending TS unacceptable notify
011052: *Oct 22 15:37:02.362 MDT: IKEv2:(SESSION ID = 19631,SA ID = 1):Get my authentication method
011053: *Oct 22 15:37:02.362 MDT: IKEv2:(SESSION ID = 19631,SA ID = 1):My authentication method is 'PSK'
011054: *Oct 22 15:37:02.362 MDT: IKEv2:(SESSION ID = 19631,SA ID = 1):Get peer's preshared key for X.X.248.100
011055: *Oct 22 15:37:02.362 MDT: IKEv2:(SESSION ID = 19631,SA ID = 1):Generate my authentication data
011056: *Oct 22 15:37:02.362 MDT: IKEv2:(SESSION ID = 19631,SA ID = 1):Use preshared key for id X.X.198.2, key len 16
011057: *Oct 22 15:37:02.362 MDT: IKEv2:(SESSION ID = 19631,SA
N15-TEST-8300-U-R#ID = 1):[IKEv2 -> Crypto Engine] Generate IKEv2 authentication data
011058: *Oct 22 15:37:02.362 MDT: IKEv2:(SESSION ID = 19631,SA ID = 1):[Crypto Engine -> IKEv2] IKEv2 authentication data generation PASSED
011059: *Oct 22 15:37:02.362 MDT: IKEv2:(SESSION ID = 19631,SA ID = 1):Get my authentication method
011060: *Oct 22 15:37:02.362 MDT: IKEv2:(SESSION ID = 19631,SA ID = 1):My authentication method is 'PSK'
011061: *Oct 22 15:37:02.362 MDT: IKEv2:(SESSION ID = 19631,SA ID = 1):Generating IKE_AUTH message
011062: *Oct 22 15:37:02.363 MDT: IKEv2:(SESSION ID = 19631,SA ID = 1):Constructing IDr payload: 'X.X.198.2' of type 'IPv4 address'
011063: *Oct 22 15:37:02.363 MDT: IKEv2:(SESSION ID = 19631,SA ID = 1):Building packet for encryption.
Payload contents:
VID IDr AUTH NOTIFY(TS_UNACCEPTABLE)

[Rob Ingram]

@stephan.l.martin1 thanks for updating, yes the debugs are clear on the cause of the problem. Glad it is now resolved.

[Aref Alsouqi]

You are very welcome @stephan.l.martin1, glad you could get to the bottom of this issue and fix it.

[stephan.l.martin1]

Specifically narrowed down the misconfiguration- we did not specify the fvrf in the profile configuration in which both profiles were configured with match fvrf any. We suspect that the profile reverts to highest local identity address for selection as that is the only difference aside from the name. Upon properly segregating the profiles to the appropriate fvrf the traffic becomes bidirectional for IPsec tunnel establishment.