Site-to site setup on FTD2100 runninng ASA COntext mode

[dm84dm]

I have an FTD 2100 which has been downgraded to ASA to be able to run ASA context mode Image. I am trying to establish a S2S but the Phase one is not coming up. When I do sh Crypto IKEV2 SA, it does not show anything or the tunnel trying to negotiate, and nothing is showing on the logs either. I tried to Debug but I was not getting any output.

Attached is the running configuration of the ASA Context.

[balaji.bandi]

what is other side device ? is the external IP reachable ? (and required ports open if the device behind NAT)

run debug :

#debug crypto ikev1 1

post below out put :

show version
 show crypto isa sa

[dm84dm]

I am running IKEv2. I can ping the peer public IP and Viz versa

DC2-ASA/act/XXXX# sh ver

Cisco Adaptive Security Appliance Software Version 9.14(4) <context>
SSP Operating System Version 2.8(1.172)
Device Manager Version 7.14(1)

Compiled on Tue 01-Feb-22 18:39 GMT by builders

DC2-ASA up 198 days 19 hours
failover cluster up 1 year 16 days

Hardware: FPR-2110

License mode: Smart Licensing

Licensed features for this user context:
Failover : Active/Active
Encryption-DES : Enabled
Encryption-3DES-AES : Enabled
Carrier : Disabled
AnyConnect Premium Peers : 0
Other VPN Peers : 200
AnyConnect for Mobile : Enabled
AnyConnect for Cisco VPN Phone : Enabled
Advanced Endpoint Assessment : Enabled
Cluster : Disabled

Failover cluster licensed features for this user context:
Failover : Active/Active
Encryption-DES : Enabled
Encryption-3DES-AES : Enabled
Carrier : Disabled
AnyConnect Premium Peers : 0
Other VPN Peers : 200
AnyConnect for Mobile : Enabled
AnyConnect for Cisco VPN Phone : Enabled
Advanced Endpoint Assessment : Enabled
Cluster : Disabled

Configuration last modified by enable_15 at 14:32:11.274 UTC Mon Sep 25 2023
DC2-ASA/act/XXXX#

[Marvin Rhoads]

Is your ASA establishing BGP neighborship and learning the route to the 192.168.13.1 host?

[dm84dm]

Yes. the ASA is doing BGP with my internal ASA where the IP is originating from

[Rob Ingram]

@dm84dm a policy based VPN will not automatically establish. Are you attempting to generate interesting traffic from the correct source IP address - 192.168.13.1 to the destination IP address - 10.185.220.37?

[dm84dm]

Yes I am

[Milos_Jovanovic]

Hi @dm84dm,

Have you enabled VPN for this context, by assigning appropriate class from system context? If I remember correctly, by default, VPNs are not allowed for multi-context ASA.

Kind regards,

Milos

[Marvin Rhoads]

They are supported:

"Guidelines for IPsec VPNs

Context Mode Guidelines

Supported in single or multiple context mode"

Reference: https://www.cisco.com/c/en/us/td/docs/security/asa/asa914/configuration/vpn/asa-914-vpn-config/vpn-ike.html

[Milos_Jovanovic]

Not sure how it is now, but, until certain version, they were not supported by default. Instead, you had to create class that allows VPN, and then to assign that class to specific context. Something like:

class vpn
limit-resource ASDM 5
limit-resource Telnet 5
limit-resource Mac-addresses 65535
limit-resource SSH 5
limit-resource VPN Other 100
limit-resource VPN AnyConnect 100

!

context vpn
member vpn
allocate-interface Port-channel1.117
allocate-interface Port-channel1.300
config-url disk0:/vpn.cfg

Without this, context would drop all VPN connections, which would be visible from "show resource usage" command. Here is the document describing what I was referring to.

Perhaps this has change in between. I haven't really configured blank post v9.12 ASA (mostly they are HW upgrades).

Kind regards,

Milos

[johnlloyd_13]

hi,

did you configure a VPN resource class and assign it to a context?

can you post 'show license summary' and 'show run class' from the 'system' context?

[dm84dm]

here is the error I see on the sh log asdm
Deny TCP reverse path check from 192.168.13.1 to 10.185.220.37 on interface outside
Alos here is the packet-tracer output when sourcing from 192.168.13.1

Phase: 1
Type: CAPTURE
Subtype:
Result: ALLOW
Config:
Additional Information:
MAC Access list

Phase: 2
Type: ACCESS-LIST
Subtype:
Result: ALLOW
Config:
Implicit Rule
Additional Information:
MAC Access list

Phase: 3
Type: INPUT-ROUTE-LOOKUP
Subtype: Resolve Egress Interface
Result: ALLOW
Config:
Additional Information:
Found next-hop 185.65.102.113 using egress ifc outside

Phase: 4
Type: SUBOPTIMAL-LOOKUP
Subtype: suboptimal next-hop
Result: ALLOW
Config:
Additional Information:
Input route lookup returned ifc S2S_VRF is not same as existing ifc outside

Phase: 5
Type: ECMP load balancing
Subtype:
Result: ALLOW
Config:
Additional Information:
ECMP load balancing
Found next-hop 185.65.102.113 using egress ifc outside

Result:
input-interface: outside
input-status: up
input-line-status: up
output-interface: outside
output-status: up
output-line-status: up
Action: drop
Drop-reason: (rpf-violated) Reverse-path verify failed, Drop-location: frame 0x000000aabb65c34c flow (NA)/NA

The traffic is not getting to the tunnel

[Rob Ingram]

@dm84dm why is the input interface outside for 192.168.13.0/24?

input-interface: outside
input-status: up
input-line-status: up
output-interface: outside

Did you specify the incorrect source interface when running packet-tracer?

Is there a BGP route in the ASA routing table for 192.168.13.0/24?