Buy or Renew
Buy or Renew
Duo Security forums now LIVE! Get answers to all your Duo Security questions. Learn more
cancel
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Showing results for 
Search instead for 
Did you mean: 
cancel
Start a conversation
1084
Views
10
Helpful
5
Replies

Couldn't migrate VPN - failed on phase 2

Andrew White
Level 2
Level 2

‎09-25-2021 12:22 AM - edited ‎09-25-2021 01:22 AM

Hello,
 
I tried to migrate a VPN we have that originally went from a remote site (not managed by us) to our WAN provider (not managed by us) and instead from this remote site to us direct as we are removing our WAN provider.
 
So I built the VPN using a tunnel interface and phase 1 would establish, but phase 2 would fail with the debugs below. If I changed it to use a crypto map instead it would work. I've had to migrate other VPN and some work and some have similar issues, but using the crypto map method saves the day, why?
 
Configs on my router:
From

interface Tunnel17
ip vrf VR-D_RC
bandwidth 100000
ip address 169.254.0.21 255.255.255.252
ip access-group D-RC-MH-ACL out
ip tcp adjust-mss 1350
tunnel source x.x.48.90
tunnel mode ipsec ipv4
tunnel destination x.x.125.50
tunnel protection ipsec profile D-RC-MH-LQ-IPsecProfile

To

crypto map External 14 ipsec-isakmp
description Mahon
set peer x.x.125.50
set transform-set D-RC-MH-LQ-TransformSet
set pfs group14
set ikev2-profile D-RC-MH-LQ-profile
match address D-RC-MH-ACL
reverse-route static
 
When using a tunnel phase 2 doesn't come up, but using a crypto map it does. 90% of our VPNs are using tunnel mode.
 
Debugs
 
Our Cisco Router
 
Sep 24 15:25:18: IKEv2:(SESSION ID = 10435811,SA ID = 3):Processing any notify-messages in child SA exchange
Sep 24 15:25:18: IKEv2:(SESSION ID = 10435811,SA ID = 3):Validating create child message
Sep 24 15:25:18: IKEv2:(SESSION ID = 10435811,SA ID = 3):Processing CREATE_CHILD_SA exchange
Sep 24 15:25:18: IKEv2:IPSec policy validate request sent for profile 2NL2-2-profile with psh index 3
Sep 24 15:25:18: IKEv2:(SA ID = 3):[IPsec -> IKEv2] Callback received for the validate proposal - PASSED.
Sep 24 15:25:18: IKEv2-ERROR:(SESSION ID = 10435811,SA ID = 3):: Create child exchange failed
Sep 24 15:25:18: IKEv2:(SESSION ID = 10435811,SA ID = 3):IPSec SA create failed
Sep 24 15:25:18: IKEv2-ERROR:Failed to decrement count for outgoing negotiating
Sep 24 15:25:18: IKEv2:(SESSION ID = 10435811,SA ID = 3):Abort exchange
Sep 24 15:25:18: IKEv2:(SESSION ID = 10435811,SA ID = 3):Sending DELETE INFO message for IPsec SA [SPI: 0xEA4709DC]
Sep 24 15:25:18: IKEv2:(SESSION ID = 10435811,SA ID = 3):Building packet for encryption.
Sep 24 15:25:18: IKEv2:(SESSION ID = 10436117,SA ID = 6):Processing ACK to informational exchange
Sep 24 15:25:18: IKEv2:(SESSION ID = 10436117,SA ID = 6):Check for existing IPSEC SA
Sep 24 15:25:18: IKEv2:% Getting preshared key from profile keyring 2NL2-2--keyring
Sep 24 15:25:18: IKEv2:% Matched peer block 'x.x.125.50'
Sep 24 15:25:18: IKEv2:Searching Policy with fvrf 0, local address x.x.48.90
Sep 24 15:25:18: IKEv2:Found Policy 'My-ikev2-2-policy'
Sep 24 15:25:18: IKEv2:(SESSION ID = 10435811,SA ID = 3):Check for IPSEC rekey
Sep 24 15:25:18: IKEv2:(SESSION ID = 10435811,SA ID = 3):Set IPSEC DH group
Sep 24 15:25:18: IKEv2:(SESSION ID = 10435811,SA ID = 3):Checking for PFS configuration
Sep 24 15:25:18: IKEv2:(SESSION ID = 10435811,SA ID = 3):PFS not configured
Sep 24 15:25:18: IKEv2:(SESSION ID = 10435811,SA ID = 3):Generating CREATE_CHILD_SA exchange
Sep 24 15:25:18: IKEv2:(SESSION ID = 10435811,SA ID = 3):ESP Proposal: 1, SPI size: 4 (IPSec negotiation),
Num. transforms: 3
AES-CBC SHA96 Don't use ESN
Sep 24 15:25:18: IKEv2:(SESSION ID = 10435811,SA ID = 3):Building packet for encryption.
Payload contents:
SA N TSi TSr
Sep 24 15:25:18: IKEv2:(SESSION ID = 10435811,SA ID = 3):Checking if request will fit in peer window
Sep 24 15:25:18: IKEv2:(SESSION ID = 10435811,SA ID = 3):Sending Packet [To x.x.125.50:500/From x.x.48.90:500/VRF i0:f0]
Initiator SPI : 1FCA7A0334DD0057 - Responder SPI : 3F955E5719ED26CB Message id: 18
IKEv2 CREATE_CHILD_SA Exchange REQUEST
Payload contents:
ENCR
Sep 24 15:25:18: IKEv2:(SESSION ID = 10435811,SA ID = 3):Received Packet [From x.x.125.50:500/To x.x.48.90:500/VRF i0:f0]
Initiator SPI : 1FCA7A0334DD0057 - Responder SPI : 3F955E5719ED26CB Message id: 18
IKEv2 CREATE_CHILD_SA Exchange RESPONSE
Payload contents:
NOTIFY(ESP_TFC_NO_SUPPORT) SA N TSi TSr
Sep 24 15:25:18: IKEv2:(SESSION ID = 10435811,SA ID = 3):Processing any notify-messages in child SA exchange
Sep 24 15:25:18: IKEv2:(SESSION ID = 10435811,SA ID = 3):Validating create child message
Sep 24 15:25:18: IKEv2:(SESSION ID = 10435811,SA ID = 3):Processing CREATE_CHILD_SA exchange
Sep 24 15:25:18: IKEv2:IPSec policy validate request sent for profile 2NL2-2--profile with psh index 3.
Sep 24 15:25:18: IKEv2:(SA ID = 3):[IPsec -> IKEv2] Callback received for the validate proposal - PASSED.
Sep 24 15:25:18: IKEv2-ERROR:(SESSION ID = 10435811,SA ID = 3):: Create child exchange failed
Sep 24 15:25:18: IKEv2:(SESSION ID = 10435811,SA ID = 3):IPSec SA create failed
Sep 24 15:25:18: IKEv2-ERROR:Failed to decrement count for outgoing negotiating
Sep 24 15:25:18: IKEv2:(SESSION ID = 10435811,SA ID = 3):Abort exchange
Sep 24 15:25:18: IKEv2:(SESSION ID = 10435811,SA ID = 3):Sending DELETE INFO message for IPsec SA [SPI: 0xEA4709DC]
Sep 24 15:25:18: IKEv2:(SESSION ID = 10435811,SA ID = 3):Building packet for encryption.
Payload contents:
DELETE
Sep 24 15:25:18: IKEv2:(SESSION ID = 10435811,SA ID = 3):Checking if request will fit in peer window
 
Remote Cisco ASA device debug
 
Sep 24 17:51:21 charon 12621 14[CFG] <con2000|5305> selected peer config 'con2000'
Sep 24 17:51:21 charon 12621 14[CFG] <5305> looking for peer configs matching x.x.125.50[%any]...x.x.48.90[x.x.48.90]
Sep 24 17:51:21 charon 12621 14[ENC] <5305> parsed IKE_AUTH request 1 [ V IDi AUTH CPRQ(DNS DNS NBNS NBNS SUBNET DNS6 SUBNET6 VER U_SPLITDNS U_BANNER (28692) U_BKPSRV U_DEFDOM) SA TSi TSr N(SET_WINSIZE) N(ESP_TFC_PAD_N) N(NON_FIRST_FRAG) ]
Sep 24 17:51:21 charon 12621 14[ENC] <5305> unknown attribute type (28692)
Sep 24 17:51:21 charon 12621 14[NET] <5305> received packet: from x.x.48.90[500] to x.x.125.50[500] (556 bytes)
Sep 24 17:51:21 charon 12621 14[NET] <5305> sending packet: from x.x.125.50[500] to x.x.48.90[500] (448 bytes)
Sep 24 17:51:21 charon 12621 14[ENC] <5305> generating IKE_SA_INIT response 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) N(CHDLESS_SUP) N(MULT_AUTH) ]
Sep 24 17:51:21 charon 12621 14[CFG] <5305> selected proposal: IKE:AES_CBC_256/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_2048
Sep 24 17:51:21 charon 12621 14[IKE] <5305> x.x.48.90 is initiating an IKE_SA
Sep 24 17:51:21 charon 12621 14[IKE] <5305> received Cisco FlexVPN Supported vendor ID
Sep 24 17:51:21 charon 12621 14[ENC] <5305> received unknown vendor ID: 43:49:53:43:4f:56:50:4e:2d:52:45:56:2d:30:32
Sep 24 17:51:21 charon 12621 14[IKE] <5305> received Cisco Delete Reason vendor ID
Sep 24 17:51:21 charon 12621 14[ENC] <5305> parsed IKE_SA_INIT request 0 [ SA KE No V V V N(NATD_S_IP) N(NATD_D_IP) ]
Sep 24 17:51:21 charon 12621 14[NET] <5305> received packet: from x.x.48.90[500] to x.x.125.50[500] (1155 bytes)
Sep 24 17:51:21 charon 12621 14[NET] <5304> sending packet: from x.x.125.50[500] to x.x.48.90[500] (38 bytes)
Sep 24 17:51:21 charon 12621 14[ENC] <5304> generating IKE_SA_INIT response 0 [ N(INVAL_KE) ]
Sep 24 17:51:21 charon 12621 14[IKE] <5304> DH group MODP_2048_256 unacceptable, requesting MODP_2048
 
Thanks
Labels:
0 Helpful
5 Replies 5

Rob Ingram
VIP
VIP

‎09-25-2021 12:33 AM - edited ‎09-25-2021 12:40 AM

HI @Andrew White 

The Tunnel interface is a Route Based VPN which uses the traffic selector of 0.0.0.0/0.0.0.0 to establish the IPSec SA, static/dynamic routing routes traffic over the tunnel.

 

The crypto map is a Policy Based VPN which uses the traffic selector as defined in the crypto ACL, in your example whatever networks defined in "D-RC-MH-ACL".

 

The peer devices need to either mirror the traffic selectors as defined in the ACL if using Policy Based VPN or both use Route Based VPN.

 

If you only changed one side to use a tunnel interface and the peer is using a crypto map, then the traffic selectors will be mismatched and that might explain why the tunnel fails to establish.

 

Andrew White
Level 2
Level 2
In response to Rob Ingram

‎09-25-2021 01:18 AM

Thanks I did just notice when using the Tunnel mode I had this and wondered if that is why phase 2 failed.

I saw a: 

% Network not in table

 

I had:

ip route 192.168.1.0 255.255.255.0 Tunnel20
ip route 192.168.2.0 255.255.255.0 Tunnel20
ip route 192.168.3.0 255.255.255.0 Tunnel20
ip route 192.168.4.0 255.255.255.0 Tunnel20
ip route 192.168.5.0 255.255.255.0 Tunnel20
ip route 192.168.6.0 255.255.255.0 Tunnel20
ip route 192.168.7.0 255.255.255.0 Tunnel20
ip route 10.253.8.0 255.255.255.0 Tunnel20
ip route 10.253.9.0 255.255.255.0 Tunnel20

 

Should of been:

 

ip route vrf VR-D_RCC 192.168.1.0 255.255.255.0 Tunnel20
ip route vrf VR-D_RCC 192.168.2.0 255.255.255.0 Tunnel20
ip route vrf VR-D_RCC 192.168.3.0 255.255.255.0 Tunnel20
ip route vrf VR-D_RCC 192.168.4.0 255.255.255.0 Tunnel20
ip route vrf VR-D_RCC 192.168.5.0 255.255.255.0 Tunnel20
ip route vrf VR-D_RCC 192.168.6.0 255.255.255.0 Tunnel20
ip route vrf VR-D_RCC 192.168.7.0 255.255.255.0 Tunnel20
ip route vrf VR-D_RCC 10.253.8.0 255.255.255.0 Tunnel20
ip route vrf VR-D_RCC 10.253.9.0 255.255.255.0 Tunnel20

 

0 Helpful

Rob Ingram
VIP
VIP
In response to Andrew White

‎09-25-2021 02:55 AM - edited ‎09-25-2021 02:56 AM

@Andrew White incorrect static routes would explain if no traffic was encrypted and sent over a tunnel, not why Phase 2 failed to establish in the first place.

0 Helpful

Andrew White
Level 2
Level 2
In response to Rob Ingram

‎09-25-2021 03:04 AM - edited ‎09-25-2021 03:06 AM

Thanks so it comes down to a mismatch in SAs where they might of had 5 subnets configured and we had say 6 if mode were using tunnel mode?

0 Helpful

Rob Ingram
VIP
VIP
In response to Andrew White

‎09-25-2021 03:24 AM - edited ‎09-25-2021 12:59 PM

@Andrew White Yes it's a problem with SAs, if using a tunnel you are sending 0.0.0.0/0.0.0.0 and the peer is sending and expecting what is defined in their ACL. You need to reconfigure the peer device to use Route Based VPN with a tunnel interface or carry on using the policy based VPN.

 

In you example the first 5 SAs would be established, but because one of the peers hasn't configured the 6th network, no SA pair will be established for that. For each line in the crypto ACL there will be a pair of SAs (inbound and outbound) assuming traffic is sent to bring up the tunnel.

 

When using a tunnel interface there will only be a pair of IPSec SAs, because the SA is established using 0.0.0.0/0.0.0.0 not the more specific networks as defined in a crypto map ACL.

Customers Also Viewed These Support Documents