cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
3070
Views
85
Helpful
6
Replies

Issues establishing VPN Tunnel between FTD managed by FMC and IOS RT

I am currently having issues establishing an S2S VPN Tunnel between to end devices in my Lab environment. (Cisco FTD to Cisco IOS). Currently, the IKEv2 SA Status says: IN-NEG : Please See Configurations Below:

Network Topology:

 

CarsonDavis56998_0-1645707877498.png

 

Cisco FTD (FMC Screenshots)

Interesting Traffic ACL

CarsonDavis56998_1-1645707877503.png

 

 

CarsonDavis56998_2-1645707877507.png

 

 

IKEv2 Policy (PHASE 1)

Integrity: MD5

Encryption: DES

PRF: MD5

DH Group: 2

 

IPSec Policy (PHASE 2)

ESP HASH: MD5

ESP Encryption: DES

 

VPN S2S Configuration

CarsonDavis56998_3-1645707877511.png

 

CarsonDavis56998_4-1645707877515.png

 

 

CarsonDavis56998_5-1645707877520.png

 

CarsonDavis56998_6-1645707877524.png

 

 

CarsonDavis56998_7-1645707877529.png

 

 

CISCO IOS

 

crypto ikev2 proposal QTS_VPN

 encryption des

 integrity md5

 group 2

crypto ikev2 policy QTS_VPN

 proposal QTS_VPN

crypto ikev2 keyring QTS_VPN

 peer QTS_FTD

  address 172.29.129.20

  pre-shared-key cisco123

 !

crypto ikev2 profile QTS_VPN

 match identity remote address 172.29.129.20 255.255.255.255

 authentication remote pre-share

 authentication local pre-share

 keyring local QTS_VPN

crypto ipsec transform-set QTS_VPN esp-des esp-md5-hmac

 mode tunnel

crypto map QTS_VPN 10 ipsec-isakmp

 set peer 172.29.129.20

 set transform-set QTS_VPN

 set ikev2-profile QTS_VPN

 match address QTS_VPN

 crypto map QTS_VPN

Interface Configuration

interface GigabitEthernet0/0

 ip address 172.29.129.200 255.255.255.0

 duplex auto

 speed auto

 media-type rj45

 crypto map QTS_VPN

interface GigabitEthernet0/1

 ip address 192.168.200.1 255.255.255.0

 duplex auto

 speed auto

 media-type rj45

Routing table

S*    0.0.0.0/0 [1/0] via 172.29.129.254

 

Access-lists:

Extended IP access list QTS_VPN

    10 permit ip 192.168.200.0 0.0.0.255 192.168.100.0 0.0.0.255 (10 matches)

    20 permit ip 192.168.100.0 0.0.0.255 192.168.200.0 0.0.0.255

 

 
 
 

 

 

 

 

 

1 Accepted Solution

Accepted Solutions

@CarsonDavis56998 what is the configuration of your IKEv2 and IPSec proposals on the FTD, cannot tell from the screenshot. I assume they are exactly the same?

 

Turn on IKEv2 debugs on both ends, generate traffic and provide the output for review.

View solution in original post

6 Replies 6

@CarsonDavis56998 can you provide the output of "show crypto ipsec sa" and "show crypto ikev2 sa" from both devices please?

 

I can't say I've ever used an extended ACL to define the protected networks, I rather just define the network object to represent the networks.

 

Here is an example of an FTD to ASA VPN that might be of help.

Please note that interesting traffic was generated from both local networks when capturing this data.

 

FTD:
There are no ipsec sas
> show crypto ikev2 sa

There are no IKEv2 SAs
> show crypto ipsec sa

There are no ipsec sas

CISCO IOS:

Router#show crypto ipsec sa

interface: GigabitEthernet0/0
Crypto map tag: QTS_VPN, local addr 172.29.129.200

protected vrf: (none)
local ident (addr/mask/prot/port): (192.168.100.0/255.255.255.0/0/0)
remote ident (addr/mask/prot/port): (192.168.200.0/255.255.255.0/0/0)
current_peer 172.29.129.20 port 500
PERMIT, flags={origin_is_acl,}
#pkts encaps: 0, #pkts encrypt: 0, #pkts digest: 0
#pkts decaps: 0, #pkts decrypt: 0, #pkts verify: 0
#pkts compressed: 0, #pkts decompressed: 0
#pkts not compressed: 0, #pkts compr. failed: 0
#pkts not decompressed: 0, #pkts decompress failed: 0
#send errors 0, #recv errors 0

local crypto endpt.: 172.29.129.200, remote crypto endpt.: 172.29.129.20
plaintext mtu 1500, path mtu 1500, ip mtu 1500, ip mtu idb GigabitEthernet0/0
current outbound spi: 0x0(0)
PFS (Y/N): N, DH group: none

inbound esp sas:

inbound ah sas:

inbound pcp sas:

outbound esp sas:

outbound ah sas:

outbound pcp sas:

protected vrf: (none)
local ident (addr/mask/prot/port): (192.168.200.0/255.255.255.0/0/0)
remote ident (addr/mask/prot/port): (192.168.100.0/255.255.255.0/0/0)
current_peer 172.29.129.20 port 500
PERMIT, flags={origin_is_acl,}
#pkts encaps: 0, #pkts encrypt: 0, #pkts digest: 0
#pkts decaps: 0, #pkts decrypt: 0, #pkts verify: 0
#pkts compressed: 0, #pkts decompressed: 0
#pkts not compressed: 0, #pkts compr. failed: 0
#pkts not decompressed: 0, #pkts decompress failed: 0
#send errors 10, #recv errors 0

local crypto endpt.: 172.29.129.200, remote crypto endpt.: 172.29.129.20
plaintext mtu 1500, path mtu 1500, ip mtu 1500, ip mtu idb GigabitEthernet0/0
current outbound spi: 0x0(0)
PFS (Y/N): N, DH group: none

inbound esp sas:

inbound ah sas:

inbound pcp sas:

outbound esp sas:

outbound ah sas:

 

Router#show crypto ikev2 sa
IPv4 Crypto IKEv2 SA

Tunnel-id Local Remote fvrf/ivrf Status
1 172.29.129.200/500 172.29.129.20/500 none/none IN-NEG
Encr: Unknown - 0, PRF: Unknown - 0, Hash: None, DH Grp:0, Auth sign: Unknown - 0, Auth verify: Unknown - 0
Life/Active Time: 86400/0 sec

IPv6 Crypto IKEv2 SA

 

 

@CarsonDavis56998 what is the configuration of your IKEv2 and IPSec proposals on the FTD, cannot tell from the screenshot. I assume they are exactly the same?

 

Turn on IKEv2 debugs on both ends, generate traffic and provide the output for review.

Hello Rob, thank you so much for the link to the documentation. I was able to confirm that my NAT Policy was misconfigured on the FTD and that traffic flows as it should from end to end. Thanks again, sir!!

 

 

@CarsonDavis56998 NAT exemption rule missing?

Normally I'd expect to see the IPSec SAs established (which in your case they were not) but only one way traffic.

Either way, glad it's working.

I had reconfigured 2 items and deployed them at the same time. These two items were 1. (NAT) which were changed based on the documentation you referred me to, and 2. (Protected Network Config) which was changed from Extended ACL to Subnet/IP Address. As both of these changes were deployed at the same time it is possible that perhaps the Protected Network change perhaps fixed the connection instead.

Review Cisco Networking for a $25 gift card