Describe the issue
When trying to connect to IKEv2 VPN I get a policy match error as pictured below.
To Reproduce
Steps to reproduce the behavior:
- Create new IKEv2 client config
- Import P12 Certificate using
certutil - Create VPN profile using PowerShell commands
- Try to connect the the newly made VPN config
Expected behavior
The VPN connects successfully
Logs
Starting Pluto (Libreswan Version 4.5 IKEv2 IKEv1 XFRM XFRMI esp-hw-offload FORK PTHREAD_SETSCHEDPRIO NSS (IPsec profile) (native-PRF) SYSTEMD_WATCHDOG LIBCAP_NG AUTH_PAM NETWORKMANAGER CURL(non-NSS)) pid:2443
core dump dir: /run/pluto
secrets file: /etc/ipsec.secrets
leak-detective enabled
NSS crypto [enabled]
XAUTH PAM support [enabled]
initializing libevent in pthreads mode: headers: 2.1.12-stable (2010c00); library: 2.1.12-stable (2010c00)
NAT-Traversal support [enabled]
Encryption algorithms:
AES_CCM_16 {256,192,*128} IKEv1: ESP IKEv2: ESP FIPS aes_ccm, aes_ccm_c
AES_CCM_12 {256,192,*128} IKEv1: ESP IKEv2: ESP FIPS aes_ccm_b
AES_CCM_8 {256,192,*128} IKEv1: ESP IKEv2: ESP FIPS aes_ccm_a
3DES_CBC [*192] IKEv1: IKE ESP IKEv2: IKE ESP FIPS NSS(CBC) 3des
CAMELLIA_CTR {256,192,*128} IKEv1: ESP IKEv2: ESP
CAMELLIA_CBC {256,192,*128} IKEv1: IKE ESP IKEv2: IKE ESP NSS(CBC) camellia
AES_GCM_16 {256,192,*128} IKEv1: ESP IKEv2: IKE ESP FIPS NSS(GCM) aes_gcm, aes_gcm_c
AES_GCM_12 {256,192,*128} IKEv1: ESP IKEv2: IKE ESP FIPS NSS(GCM) aes_gcm_b
AES_GCM_8 {256,192,*128} IKEv1: ESP IKEv2: IKE ESP FIPS NSS(GCM) aes_gcm_a
AES_CTR {256,192,*128} IKEv1: IKE ESP IKEv2: IKE ESP FIPS NSS(CTR) aesctr
AES_CBC {256,192,*128} IKEv1: IKE ESP IKEv2: IKE ESP FIPS NSS(CBC) aes
NULL_AUTH_AES_GMAC {256,192,*128} IKEv1: ESP IKEv2: ESP FIPS aes_gmac
NULL [] IKEv1: ESP IKEv2: ESP
CHACHA20_POLY1305 [*256] IKEv1: IKEv2: IKE ESP NSS(AEAD) chacha20poly1305
Hash algorithms:
MD5 IKEv1: IKE IKEv2: NSS
SHA1 IKEv1: IKE IKEv2: IKE FIPS NSS sha
SHA2_256 IKEv1: IKE IKEv2: IKE FIPS NSS sha2, sha256
SHA2_384 IKEv1: IKE IKEv2: IKE FIPS NSS sha384
SHA2_512 IKEv1: IKE IKEv2: IKE FIPS NSS sha512
PRF algorithms:
HMAC_MD5 IKEv1: IKE IKEv2: IKE native(HMAC) md5
HMAC_SHA1 IKEv1: IKE IKEv2: IKE FIPS NSS sha, sha1
HMAC_SHA2_256 IKEv1: IKE IKEv2: IKE FIPS NSS sha2, sha256, sha2_256
HMAC_SHA2_384 IKEv1: IKE IKEv2: IKE FIPS NSS sha384, sha2_384
HMAC_SHA2_512 IKEv1: IKE IKEv2: IKE FIPS NSS sha512, sha2_512
AES_XCBC IKEv1: IKEv2: IKE native(XCBC) aes128_xcbc
Integrity algorithms:
HMAC_MD5_96 IKEv1: IKE ESP AH IKEv2: IKE ESP AH native(HMAC) md5, hmac_md5
HMAC_SHA1_96 IKEv1: IKE ESP AH IKEv2: IKE ESP AH FIPS NSS sha, sha1, sha1_96, hmac_sha1
HMAC_SHA2_512_256 IKEv1: IKE ESP AH IKEv2: IKE ESP AH FIPS NSS sha512, sha2_512, sha2_512_256, hmac_sha2_512
HMAC_SHA2_384_192 IKEv1: IKE ESP AH IKEv2: IKE ESP AH FIPS NSS sha384, sha2_384, sha2_384_192, hmac_sha2_384
HMAC_SHA2_256_128 IKEv1: IKE ESP AH IKEv2: IKE ESP AH FIPS NSS sha2, sha256, sha2_256, sha2_256_128, hmac_sha2_256
HMAC_SHA2_256_TRUNCBUG IKEv1: ESP AH IKEv2: AH
AES_XCBC_96 IKEv1: ESP AH IKEv2: IKE ESP AH native(XCBC) aes_xcbc, aes128_xcbc, aes128_xcbc_96
AES_CMAC_96 IKEv1: ESP AH IKEv2: ESP AH FIPS aes_cmac
NONE IKEv1: ESP IKEv2: IKE ESP FIPS null
DH algorithms:
NONE IKEv1: IKEv2: IKE ESP AH FIPS NSS(MODP) null, dh0
MODP1024 IKEv1: IKE ESP AH IKEv2: IKE ESP AH NSS(MODP) dh2
MODP1536 IKEv1: IKE ESP AH IKEv2: IKE ESP AH NSS(MODP) dh5
MODP2048 IKEv1: IKE ESP AH IKEv2: IKE ESP AH FIPS NSS(MODP) dh14
MODP3072 IKEv1: IKE ESP AH IKEv2: IKE ESP AH FIPS NSS(MODP) dh15
MODP4096 IKEv1: IKE ESP AH IKEv2: IKE ESP AH FIPS NSS(MODP) dh16
MODP6144 IKEv1: IKE ESP AH IKEv2: IKE ESP AH FIPS NSS(MODP) dh17
MODP8192 IKEv1: IKE ESP AH IKEv2: IKE ESP AH FIPS NSS(MODP) dh18
DH19 IKEv1: IKE IKEv2: IKE ESP AH FIPS NSS(ECP) ecp_256, ecp256
DH20 IKEv1: IKE IKEv2: IKE ESP AH FIPS NSS(ECP) ecp_384, ecp384
DH21 IKEv1: IKE IKEv2: IKE ESP AH FIPS NSS(ECP) ecp_521, ecp521
DH31 IKEv1: IKE IKEv2: IKE ESP AH NSS(ECP) curve25519
testing CAMELLIA_CBC:
Camellia: 16 bytes with 128-bit key
Camellia: 16 bytes with 128-bit key
Camellia: 16 bytes with 256-bit key
Camellia: 16 bytes with 256-bit key
testing AES_GCM_16:
empty string
one block
two blocks
two blocks with associated data
testing AES_CTR:
Encrypting 16 octets using AES-CTR with 128-bit key
Encrypting 32 octets using AES-CTR with 128-bit key
Encrypting 36 octets using AES-CTR with 128-bit key
Encrypting 16 octets using AES-CTR with 192-bit key
Encrypting 32 octets using AES-CTR with 192-bit key
Encrypting 36 octets using AES-CTR with 192-bit key
Encrypting 16 octets using AES-CTR with 256-bit key
Encrypting 32 octets using AES-CTR with 256-bit key
Encrypting 36 octets using AES-CTR with 256-bit key
testing AES_CBC:
Encrypting 16 bytes (1 block) using AES-CBC with 128-bit key
Encrypting 32 bytes (2 blocks) using AES-CBC with 128-bit key
Encrypting 48 bytes (3 blocks) using AES-CBC with 128-bit key
Encrypting 64 bytes (4 blocks) using AES-CBC with 128-bit key
testing AES_XCBC:
RFC 3566 Test Case 1: AES-XCBC-MAC-96 with 0-byte input
RFC 3566 Test Case 2: AES-XCBC-MAC-96 with 3-byte input
RFC 3566 Test Case 3: AES-XCBC-MAC-96 with 16-byte input
RFC 3566 Test Case 4: AES-XCBC-MAC-96 with 20-byte input
RFC 3566 Test Case 5: AES-XCBC-MAC-96 with 32-byte input
RFC 3566 Test Case 6: AES-XCBC-MAC-96 with 34-byte input
RFC 3566 Test Case 7: AES-XCBC-MAC-96 with 1000-byte input
RFC 4434 Test Case AES-XCBC-PRF-128 with 20-byte input (key length 16)
RFC 4434 Test Case AES-XCBC-PRF-128 with 20-byte input (key length 10)
RFC 4434 Test Case AES-XCBC-PRF-128 with 20-byte input (key length 18)
testing HMAC_MD5:
RFC 2104: MD5_HMAC test 1
RFC 2104: MD5_HMAC test 2
RFC 2104: MD5_HMAC test 3
1 CPU cores online
starting up 1 helper threads
started thread for helper 0
using Linux xfrm kernel support code on #1 SMP Debian 5.10.70-1 (2021-09-30)
systemd watchdog for ipsec service configured with timeout of 200000000 usecs
watchdog: sending probes every 100 secs
seccomp security for helper not supported
seccomp security not supported
"l2tp-psk": added IKEv1 connection
"xauth-psk": added IKEv1 connection
"ikev2-cp": loaded private key matching left certificate 'dkay.xyz'
"ikev2-cp": added IKEv2 connection
listening for IKE messages
Kernel supports NIC esp-hw-offload
adding UDP interface ens0 x.x.x.x:500
adding UDP interface ens0 x.x.x.x:4500
adding UDP interface lo 127.0.0.1:500
adding UDP interface lo 127.0.0.1:4500
forgetting secrets
loading secrets from "/etc/ipsec.secrets"
packet from x.x.x.x:500: ISAKMP_v2_IKE_SA_INIT message received on x.x.x.x:500 but no suitable connection found with IKEv2 policy
packet from x.x.x.x:500: responding to IKE_SA_INIT (34) message (Message ID 0) with unencrypted notification NO_PROPOSAL_CHOSEN
Server
- OS: Debian 11
Client
- Device: Dell XPS 15
- OS: Windows 11 Pro
- VPN mode: IKEv2
Windows Server 2008 R2 Enterprise Windows Server 2008 R2 Standard Windows Server 2008 R2 Datacenter Windows Server 2008 R2 for Itanium-Based Systems Windows Server 2008 R2 Foundation Windows Server 2008 R2 Web Edition Windows 7 Home Basic Windows 7 Home Premium Windows 7 Professional Windows 7 Starter Windows 7 Ultimate Windows 7 Enterprise Windows 7 Service Pack 1 Windows Server 2008 R2 Service Pack 1 More…Less
Symptoms
Consider the following scenario:
-
You have two computers that are running Windows 7 or Windows Server 2008 R2.
-
Each computer is behind a separate Network Address Translation (NAT) firewall.
-
You connect the computers by using an Internet Protocol Security (IPsec) connection that uses Internet Key Exchange version 2 (IKEv2) tunnel mode.
-
You install the update that is described in Microsoft Knowledge Base (KB) article 2248145 on one of the computers.
In this scenario, the IPsec connection fails. More specifically, no data packets are routed through the IPsec connection, and the IPsec connection is negotiated repeatedly.
Resolution
Hotfix information
A supported hotfix is available from Microsoft. However, this hotfix is intended to correct only the problem that is described in this article. Apply this hotfix only to systems that are experiencing the problem described in this article. This hotfix might receive additional testing. Therefore, if you are not severely affected by this problem, we recommend that you wait for the next software update that contains this hotfix.
If the hotfix is available for download, there is a «Hotfix download available» section at the top of this Knowledge Base article. If this section does not appear, contact Microsoft Customer Service and Support to obtain the hotfix.
Note If additional issues occur or if any troubleshooting is required, you might have to create a separate service request. The usual support costs will apply to additional support questions and issues that do not qualify for this specific hotfix. For a complete list of Microsoft Customer Service and Support telephone numbers or to create a separate service request, visit the following Microsoft website:
http://support.microsoft.com/contactus/?ws=supportNote The «Hotfix download available» form displays the languages for which the hotfix is available. If you do not see your language, it is because a hotfix is not available for that language.
Prerequisites
To apply this hotfix, you must be running one of the following operating systems:
-
Windows 7
-
Windows 7 Service Pack 1 (SP1)
-
Windows Server 2008 R2
-
Windows Server 2008 R2 Service Pack 1 (SP1)
For more information about how to obtain a Windows 7 or Windows Server 2008 R2 service pack, click the following article number to view the article in the Microsoft Knowledge Base:
976932 Information about Service Pack 1 for Windows 7 and for Windows Server 2008 R2
Registry information
To use the hotfix in this package, you do not have to make any changes to the registry.
Restart requirement
You must restart the computer after you apply this hotfix.
Hotfix replacement information
This hotfix does not replace a previously released hotfix.
File information
The global version of this hotfix installs files that have the attributes that are listed in the following tables. The dates and the times for these files are listed in Coordinated Universal Time (UTC). The dates and the times for these files on your local computer are displayed in your local time together with your current daylight saving time (DST) bias. Additionally, the dates and the times may change when you perform certain operations on the files.
Windows 7 and Windows Server 2008 R2 file information notes
Important Windows 7 hotfixes and Windows Server 2008 R2 hotfixes are included in the same packages. However, hotfixes on the Hotfix Request page are listed under both operating systems. To request the hotfix package that applies to one or both operating systems, select the hotfix that is listed under «Windows 7/Windows Server 2008 R2» on the page. Always refer to the «Applies To» section in articles to determine the actual operating system that each hotfix applies to.
-
The files that apply to a specific product, milestone (RTM, SPn), and service branch (LDR, GDR) can be identified by examining the file version numbers as shown in the following table:
Version
Product
Milestone
Service branch
6.1.760
1.17xxxWindows 7 and Windows Server 2008 R2
SP1
GDR
6.1.760
1.21xxxWindows 7 and Windows Server 2008 R2
SP1
LDR
-
GDR service branches contain only those fixes that are widely released to address widespread, critical issues. LDR service branches contain hotfixes in addition to widely released fixes.
-
The MANIFEST files (.manifest) and the MUM files (.mum) that are installed for each environment are listed separately in the «Additional file information for Windows 7 and for Windows Server 2008 R2» section. MUM and MANIFEST files, and the associated security catalog (.cat) files, are critical to maintaining the state of the updated component. The security catalog files, for which the attributes are not listed, are signed with a Microsoft digital signature.
For all supported x86-based versions of Windows 7
|
File name |
File version |
File size |
Date |
Time |
|---|---|---|---|---|
|
Bfe.dll |
6.1.7601.21939 |
496,128 |
09-Mar-2012 |
13:49 |
|
Fwpuclnt.dll |
6.1.7601.17514 |
216,576 |
20-Nov-2010 |
12:19 |
|
Ikeext.dll |
6.1.7601.21939 |
675,328 |
09-Mar-2012 |
13:50 |
|
Networksecurity-ppdlic.xrm-ms |
Not applicable |
3,028 |
09-Mar-2012 |
14:11 |
|
Nshwfp.dll |
6.1.7601.21939 |
657,920 |
09-Mar-2012 |
13:51 |
|
Wfp.mof |
Not applicable |
822 |
10-Jun-2009 |
21:32 |
For all supported x64-based versions of Windows 7 and of Windows Server 2008 R2
|
File name |
File version |
File size |
Date |
Time |
Platform |
|---|---|---|---|---|---|
|
Bfe.dll |
6.1.7601.21939 |
706,560 |
09-Mar-2012 |
15:35 |
x64 |
|
Fwpuclnt.dll |
6.1.7601.21939 |
324,096 |
09-Mar-2012 |
15:36 |
x64 |
|
Ikeext.dll |
6.1.7601.21939 |
854,528 |
09-Mar-2012 |
15:36 |
x64 |
|
Networksecurity-ppdlic.xrm-ms |
Not applicable |
3,028 |
09-Mar-2012 |
15:52 |
Not applicable |
|
Nshwfp.dll |
6.1.7601.21939 |
832,000 |
09-Mar-2012 |
15:36 |
x64 |
|
Wfp.mof |
Not applicable |
822 |
10-Jun-2009 |
20:51 |
Not applicable |
|
Fwpuclnt.dll |
6.1.7601.21939 |
216,576 |
09-Mar-2012 |
13:50 |
x86 |
|
Nshwfp.dll |
6.1.7601.21939 |
657,920 |
09-Mar-2012 |
13:51 |
x86 |
|
Wfp.mof |
Not applicable |
822 |
12-Nov-2010 |
23:57 |
Not applicable |
For all supported IA-64-based versions of Windows Server 2008 R2
|
File name |
File version |
File size |
Date |
Time |
Platform |
|---|---|---|---|---|---|
|
Bfe.dll |
6.1.7601.21939 |
1,074,176 |
09-Mar-2012 |
13:54 |
IA-64 |
|
Fwpuclnt.dll |
6.1.7601.21939 |
566,272 |
09-Mar-2012 |
13:55 |
IA-64 |
|
Ikeext.dll |
6.1.7601.21939 |
1,486,848 |
09-Mar-2012 |
13:55 |
IA-64 |
|
Networksecurity-ppdlic.xrm-ms |
Not applicable |
3,028 |
09-Mar-2012 |
14:11 |
Not applicable |
|
Nshwfp.dll |
6.1.7601.21939 |
1,114,112 |
09-Mar-2012 |
13:56 |
IA-64 |
|
Wfp.mof |
Not applicable |
822 |
10-Jun-2009 |
20:57 |
Not applicable |
|
Fwpuclnt.dll |
6.1.7601.21939 |
216,576 |
09-Mar-2012 |
13:50 |
x86 |
|
Nshwfp.dll |
6.1.7601.21939 |
657,920 |
09-Mar-2012 |
13:51 |
x86 |
|
Wfp.mof |
Not applicable |
822 |
12-Nov-2010 |
23:57 |
Not applicable |
Status
Microsoft has confirmed that this is a problem in the Microsoft products that are listed in the «Applies to» section.
More Information
For more information about software update terminology, click the following article number to view the article in the Microsoft Knowledge Base:
824684 Description of the standard terminology that is used to describe Microsoft software updates
Additional file information
Additional file information for Windows 7 and for Windows Server 2008 R2
Additional files for all supported x86-based versions of Windows 7
|
File name |
X86_20a86d6c24debb129b9d8d613177c98a_31bf3856ad364e35_6.1.7601.21939_none_a2ead1087e612eaa.manifest |
|
File version |
Not applicable |
|
File size |
704 |
|
Date (UTC) |
09-Mar-2012 |
|
Time (UTC) |
20:01 |
|
File name |
X86_microsoft-windows-network-security_31bf3856ad364e35_6.1.7601.21939_none_cfa4ddeba1f63ee8.manifest |
|
File version |
Not applicable |
|
File size |
158,847 |
|
Date (UTC) |
09-Mar-2012 |
|
Time (UTC) |
20:04 |
Additional files for all supported x64-based versions of Windows 7 and of Windows Server 2008 R2
|
File name |
Amd64_2666cccee9d44abbc79608dede64f461_31bf3856ad364e35_6.1.7601.21939_none_a6a3ac1846156ab1.manifest |
|
File version |
Not applicable |
|
File size |
708 |
|
Date (UTC) |
09-Mar-2012 |
|
Time (UTC) |
20:01 |
|
File name |
Amd64_76381ea7c449c9436085d7436ac4248d_31bf3856ad364e35_6.1.7601.21939_none_7a53aac6e6dc7c6a.manifest |
|
File version |
Not applicable |
|
File size |
1,058 |
|
Date (UTC) |
09-Mar-2012 |
|
Time (UTC) |
20:01 |
|
File name |
Amd64_microsoft-windows-network-security_31bf3856ad364e35_6.1.7601.21939_none_2bc3796f5a53b01e.manifest |
|
File version |
Not applicable |
|
File size |
154,831 |
|
Date (UTC) |
09-Mar-2012 |
|
Time (UTC) |
16:01 |
|
File name |
Wow64_microsoft-windows-network-security_31bf3856ad364e35_6.1.7601.21939_none_361823c18eb47219.manifest |
|
File version |
Not applicable |
|
File size |
94,348 |
|
Date (UTC) |
09-Mar-2012 |
|
Time (UTC) |
14:10 |
Additional files for all supported IA-64-based versions of Windows Server 2008 R2
|
File name |
Ia64_c760f426708a313f66a559039845bf37_31bf3856ad364e35_6.1.7601.21939_none_e4fa1dc3814c9d44.manifest |
|
File version |
Not applicable |
|
File size |
1,056 |
|
Date (UTC) |
09-Mar-2012 |
|
Time (UTC) |
20:01 |
|
File name |
Ia64_microsoft-windows-network-security_31bf3856ad364e35_6.1.7601.21939_none_cfa681e1a1f447e4.manifest |
|
File version |
Not applicable |
|
File size |
154,828 |
|
Date (UTC) |
09-Mar-2012 |
|
Time (UTC) |
15:15 |
|
File name |
Wow64_microsoft-windows-network-security_31bf3856ad364e35_6.1.7601.21939_none_361823c18eb47219.manifest |
|
File version |
Not applicable |
|
File size |
94,348 |
|
Date (UTC) |
09-Mar-2012 |
|
Time (UTC) |
14:10 |
Need more help?
Want more options?
Explore subscription benefits, browse training courses, learn how to secure your device, and more.
Communities help you ask and answer questions, give feedback, and hear from experts with rich knowledge.
/ip ipsec mode-config
add name=ike2-rw responder=no
/ip ipsec policy group
add name=ike2-rw
/ip ipsec profile
add name=ike2-rw
/ip ipsec peer
add address=1.62.251.118/32 exchange-mode=ike2 name=ike2-rw-client profile=ike2-rw
/ip ipsec proposal
add name=ike2-rw pfs-group=none
/ip ipsec identity
add auth-method=digital-signature certificate=cert_export_rw-client1.p12_0 generate-policy=\
port-strict mode-config=ike2-rw peer=ike2-rw-client policy-template-group=ike2-rw
/ip ipsec policy
add group=ike2-rw proposal=ike2-rw template=yes19:31:45 ipsec,error can't get private key
19:31:45 ipsec adding notify: AUTHENTICATION_FAILED
19:31:45 ipsec,debug => (size 0x8)
19:31:45 ipsec,debug 00000008 00000018
19:31:45 ipsec <- ike2 request, exchange: AUTH:1 1.62.251.118[4500] 84ceebc655ab6287:ec4dabcf5c648235
19:31:45 ipsec,debug ===== sending 220 bytes from 192.168.31.82[4500] to 1.62.251.118[4500]
19:31:45 ipsec,debug 1 times of 224 bytes message will be sent to 1.62.251.118[4500]
19:31:45 ipsec,info killing ike2 SA: ike2-rw-client 192.168.31.82[4500]-1.62.251.118[4500] spi:84ceebc655ab6287:ec4dabcf5c648235
19:31:45 ipsec KA remove: 192.168.31.82[4500]->1.62.251.118[4500]
19:31:45 ipsec,debug KA tree dump: 192.168.31.82[4500]->1.62.251.118[4500] (in_use=1)
19:31:45 ipsec,debug KA removing this one...
19:31:46 ipsec ike2 starting for: 1.62.251.118
19:31:47 ipsec adding notify: IKEV2_FRAGMENTATION_SUPPORTED
19:31:47 ipsec,debug => (size 0x8)
19:31:47 ipsec,debug 00000008 0000402e
19:31:47 ipsec adding notify: NAT_DETECTION_DESTINATION_IP
19:31:47 ipsec,debug => (size 0x1c)
19:31:47 ipsec,debug 0000001c 00004005 d1a8174f 274c82ec 57ffb917 762ca478 33b9a69c
19:31:47 ipsec adding notify: NAT_DETECTION_SOURCE_IP
19:31:47 ipsec,debug => (size 0x1c)
19:31:47 ipsec,debug 0000001c 00004004 40aa98ca 8901c4d3 531464b0 fb8cf1c0 3f8f30bb
19:31:47 ipsec adding payload: NONCE
19:31:47 ipsec,debug => (size 0x1c)
19:31:47 ipsec,debug 0000001c 622faac4 002343d4 ea463c45 ccaf0cf5 ad074150 3806e7c8
19:31:47 ipsec adding payload: KE
19:31:47 ipsec,debug => (first 0x100 of 0x108)
19:31:47 ipsec,debug 00000108 000e0000 ca10fd42 c5bd2690 59d142be 2d4f20cb e7af85f3 625e4c6c
19:31:47 ipsec,debug 49677473 19c4980b 771b03d9 62ead805 9ca25eab 310829d2 86dac253 b4f03c90
19:31:47 ipsec,debug 7391f601 f5a6540c 733be228 227dd1f4 e9b8079b 7fc04279 a436d0c5 fcb56743
19:31:47 ipsec,debug d614473a 968a10e7 ccfbec76 fc2cd374 85bbbe67 dfd3d523 bb2c9667 095a8855
19:31:47 ipsec,debug 8199204a a82003b5 c646b762 5be4ecbd 2c52de2c 6ef05ced 6158a915 fe1c3360
19:31:47 ipsec,debug 19bec5bc 82275cff 0338494a c909f8ea 714950aa be66d5bf 71beff8c 1404156e
19:31:47 ipsec,debug b9412a13 8621dd03 27a30e95 997503af 312aaf05 f51a7003 729d3dd2 21e3b2ba
19:31:47 ipsec,debug 4af56445 835ce943 e0288bce eeaa33a7 73fa2523 1f3475d8 00a8ffb0 70efd53b
19:31:47 ipsec adding payload: SA
19:31:47 ipsec,debug => (size 0x40)
19:31:47 ipsec,debug 00000040 0000003c 01010006 0300000c 0100000c 800e0080 03000008 01000003
19:31:47 ipsec,debug 03000008 02000002 03000008 03000002 03000008 0400000e 00000008 04000002
19:31:47 ipsec <- ike2 request, exchange: SA_INIT:0 1.62.251.118[4500] afe46a55add8e618:0000000000000000
19:31:47 ipsec,debug ===== sending 448 bytes from 192.168.31.82[4500] to 1.62.251.118[4500]
19:31:47 ipsec,debug 1 times of 452 bytes message will be sent to 1.62.251.118[4500]
19:31:47 ipsec,debug ===== received 429 bytes from 1.62.251.118[4500] to 192.168.31.82[4500]
19:31:47 ipsec -> ike2 reply, exchange: SA_INIT:0 1.62.251.118[4500] afe46a55add8e618:bc9d21157c465ff3
19:31:47 ipsec ike2 initialize recv
19:31:47 ipsec payload seen: SA (48 bytes)
19:31:47 ipsec payload seen: KE (264 bytes)
19:31:47 ipsec payload seen: NONCE (28 bytes)
19:31:47 ipsec payload seen: NOTIFY (28 bytes)
19:31:47 ipsec payload seen: NOTIFY (28 bytes)
19:31:47 ipsec payload seen: CERTREQ (5 bytes)
19:31:47 ipsec processing payload: NONCE
19:31:47 ipsec processing payload: SA
19:31:47 ipsec IKE Protocol: IKE
19:31:47 ipsec proposal #1
19:31:47 ipsec enc: aes128-cbc
19:31:47 ipsec prf: hmac-sha1
19:31:47 ipsec auth: sha1
19:31:47 ipsec dh: modp2048
19:31:47 ipsec matched proposal:
19:31:47 ipsec proposal #1
19:31:47 ipsec enc: aes128-cbc
19:31:47 ipsec prf: hmac-sha1
19:31:47 ipsec auth: sha1
19:31:47 ipsec dh: modp2048
19:31:47 ipsec processing payload: KE
19:31:47 ipsec,debug => shared secret (size 0x100)
19:31:47 ipsec,debug b8ed85c4 ce9233ec 101c6228 f51e8a75 1999693b 8d45c786 9e860166 24a575b5
19:31:47 ipsec,debug 0913115b 28c71df1 4b47f2ee 6d7f8dc7 78082a5d 6049da0f 4adbaf9e 5f3362b0
19:31:47 ipsec,debug f4598ea9 b56bd362 0ee15050 f4cd6799 43816c75 09fde846 1ff85fb3 6a572f6e
19:31:47 ipsec,debug 7d866e61 3c984fb0 9a5c2e92 e92f8a8e a7ca8db1 d7973feb a516f36e cb2756e8
19:31:47 ipsec,debug a2d9357c f18adba5 091f39d9 d00d3778 e25c2d57 34e3defe bd450de0 6875f1d6
19:31:47 ipsec,debug 0775ab05 0f0e73cd cfc4a0ba 5ca3be65 940d9d0d 4910573f a58d5dec 38dcb268
19:31:47 ipsec,debug ec18e78b 4a531363 71da68ea 62d7fb64 479317ff 39671af5 9b7bc785 2935eb17
19:31:47 ipsec,debug d3436283 b95485e7 008925f6 9d165c5d 3a3061e7 bdd6bf3a 1b39bab6 1d481d78
19:31:47 ipsec,debug => skeyseed (size 0x14)
19:31:47 ipsec,debug 8e3a2465 a0e0e70e 2e4b2591 fa42d0ac b816f8fa
19:31:47 ipsec,debug => keymat (size 0x14)
19:31:47 ipsec,debug 75ff304a 5c6449c2 fdeef599 891b2630 5404b339
19:31:47 ipsec,debug => SK_ai (size 0x14)
19:31:47 ipsec,debug 3049085e 8779a4c5 b5eaf9ed ea602bc8 92d44154
19:31:47 ipsec,debug => SK_ar (size 0x14)
19:31:47 ipsec,debug 6252e811 ed035dad 6c019671 2a7f24aa d9e952fd
19:31:47 ipsec,debug => SK_ei (size 0x10)
19:31:47 ipsec,debug 76bb2cb0 73bb695f 8e342b61 e68988f3
19:31:47 ipsec,debug => SK_er (size 0x10)
19:31:47 ipsec,debug 7fe115a0 46fc410b b3cb9c71 d3a957e4
19:31:47 ipsec,debug => SK_pi (size 0x14)
19:31:47 ipsec,debug 341d660a c608e75d cc7a85b9 5edd6709 2f42dc65
19:31:47 ipsec,debug => SK_pr (size 0x14)
19:31:47 ipsec,debug 54972b6e dea4d248 24bc41fc 84f0f40f b5ef3c4e
19:31:47 ipsec,info new ike2 SA (I): ike2-rw-client 192.168.31.82[4500]-1.62.251.118[4500] spi:afe46a55add8e618:bc9d21157c465ff3
19:31:47 ipsec processing payloads: NOTIFY
19:31:47 ipsec notify: NAT_DETECTION_SOURCE_IP
19:31:47 ipsec notify: NAT_DETECTION_DESTINATION_IP
19:31:47 ipsec (NAT-T) LOCAL
19:31:47 ipsec KA list add: 192.168.31.82[4500]->1.62.251.118[4500]
19:31:47 ipsec init child continue
19:31:47 ipsec offering proto: 3
19:31:47 ipsec proposal #1
19:31:47 ipsec enc: aes256-cbc
19:31:47 ipsec enc: aes192-cbc
19:31:47 ipsec enc: aes128-cbc
19:31:47 ipsec auth: sha1
19:31:47 ipsec my ID (DER DN): rw-client1
19:31:47 ipsec adding payload: ID_I
19:31:47 ipsec,debug => (size 0x1f)
19:31:47 ipsec,debug 0000001f 09000000 30153113 30110603 5504030c 0a72772d 636c6965 6e7431
19:31:47 ipsec,error can't get private key
19:31:47 ipsec adding notify: AUTHENTICATION_FAILED
19:31:47 ipsec,debug => (size 0x8)
19:31:47 ipsec,debug 00000008 00000018
19:31:47 ipsec <- ike2 request, exchange: AUTH:1 1.62.251.118[4500] afe46a55add8e618:bc9d21157c465ff3
19:31:47 ipsec,debug ===== sending 268 bytes from 192.168.31.82[4500] to 1.62.251.118[4500]
19:31:47 ipsec,debug 1 times of 272 bytes message will be sent to 1.62.251.118[4500]
19:31:47 ipsec,info killing ike2 SA: ike2-rw-client 192.168.31.82[4500]-1.62.251.118[4500] spi:afe46a55add8e618:bc9d21157c465ff3
19:31:47 ipsec KA remove: 192.168.31.82[4500]->1.62.251.118[4500]
19:31:47 ipsec,debug KA tree dump: 192.168.31.82[4500]->1.62.251.118[4500] (in_use=1)
19:31:47 ipsec,debug KA removing this one...
In CLI is also possible to display the current logs/debug information for the path specified.
monitor start /var/log/messages
Tips to Start the Troubleshoot Process for IPsec Issues
It is possible to separate three different IPsec scenarios. It is a good point of reference to identify the symptom to have a better approach to know how to start.
- IPsec tunnel does not establish.
- IPsec tunnel went down and it re-established on its own. (Flapped)
- IPsec tunnel went down and it stays on a downstate.
For the IPsec tunnel does not establish symptoms, it is needed to debug in real-time to verify what is the current behavior on the IKE negotiation.
For IPsec tunnel went down and it re-established on its own symptoms, most commonly known as tunnel Flapped and the root cause analysis (RCA) is needed. It is indispensable to know the timestamp when the tunnel went down or have an estimated time to look at the debugs.
For IPsec tunnel went down and it stays on downstate symptoms, it means the tunnel worked before but for any reason, it came down and we need to know the teardown reason and the current behavior that prevents the tunnel to be successfully established again.
Identify the points before the troubleshoot starts:
- IPsec tunnel (Number) with issues and configuration.
- The timestamp when the tunnel went down (if applicable).
- IPsec peer IP address (Tunnel destination).
All the debugs and logs are saved on /var/log/messages files, for the current logs, they are saved on messages file but for this specific symptom the flap could be identified hours/days after the issue, most probably debugs related would be on messages1,2,3..etc. It is important to know the timestamp to look at the right message file and analyze the debugs (charon) for the IKE negotiation of the IPsec Tunnel related.
Most of the debugs do not print the number of the IPsec tunnel. The most frequent way to identify the negotiation and packets is with the IP address of the remote peer and the IP address where the tunnel is sourced on the vedge. Some examples of IKE debugs printed:
Jun 18 00:31:22 vedge01 charon: 09[CFG] vici initiate 'child_IPsec2_1'
Jun 18 00:31:22 vedge01 charon: 16[IKE] initiating IKE_SA ipsec2_1[223798] to 10.10.10.1
Jun 18 00:31:22 vedge01 charon: 16[IKE] initiating IKE_SA ipsec2_1[223798] to 10.10.10.1
The debugs for the IKE INIT negotiation show the IPsec Tunnel number, However, the subsequent information for packet exchange only uses the IPsec tunnel IP addresses.
Jun 18 00:31:22 vedge01 charon: 09[CFG] vici initiate 'child_ipsec2_1'
Jun 18 00:31:22 vedge01 charon: 16[IKE] initiating IKE_SA ipsec2_1[223798] to 10.10.10.1
Jun 18 00:31:22 vedge01 charon: 16[IKE] initiating IKE_SA ipsec2_1[223798] to 10.10.10.1
Jun 18 00:31:22 vedge01 charon: 16[ENC] generating IKE_SA_INIT request 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) N(FRAG_SUP) N(HASH_ALG) N(REDIR_SUP) ]
Jun 18 00:31:22 vedge01 charon: 16[NET] sending packet: from 10.132.3.92[500] to 10.10.10.1[500] (464 bytes)
Jun 18 00:31:22 vedge01 charon: 12[NET] received packet: from 10.10.10.1[500] to 10.132.3.92[500] (468 bytes)
Jun 18 00:31:22 vedge01 charon: 12[ENC] parsed IKE_SA_INIT response 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) N(HTTP_CERT_LOOK) N(FRAG_SUP) V ]
Jun 18 00:31:22 vedge01 charon: 12[ENC] received unknown vendor ID: 4f:85:58:17:1d:21:a0:8d:69:cb:5f:60:9b:3c:06:00
Jun 18 00:31:22 vedge01 charon: 12[IKE] local host is behind NAT, sending keep alives
IPsec tunnel configuration:
interface ipsec2
ip address 192.168.1.9/30
tunnel-source 10.132.3.92
tunnel-destination 10.10.10.1
dead-peer-detection interval 30
ike
version 2
rekey 86400
cipher-suite aes256-cbc-sha1
group 14
authentication-type
pre-shared-key
pre-shared-secret $8$wgrs/Cw6tX0na34yF4Fga0B62mGBpHFdOzFaRmoYfnBioWVO3s3efFPBbkaZqvoN
!
!
!
ipsec
rekey 3600
replay-window 512
cipher-suite aes256-gcm
perfect-forward-secrecy group-14
!Symptom 1. IPsec Tunnel Does Not Get Established
As the issue can be the first implementation for the tunnel, it has not been up and the IKE debugs are the best option.
Symptom 2. IPsec Tunnel Went Down and It Was Re-established on Its Own
As previously mentioned, usually this symptom is addressed to know the root cause of why the tunnel went down. With the root cause analysis known, sometimes, the network’s admin prevents further issues.
Identify the points before the troubleshoot starts:
- IPsec tunnel (Number) with issues and configuration.
- The timestamp when the tunnel went down.
- IPsec peer IP address (Tunnel destination)
DPD Retransmissions
In this example, the tunnel went down on Jun 18 at 00:31:17.
Jun 18 00:31:17 vedge01 FTMD[1472]: %Viptela-vedge01-FTMD-6-INFO-1000001: VPN 1 Interface ipsec2 DOWN
Jun 18 00:31:17 vedge01 FTMD[1472]: %Viptela-vedge01-ftmd-6-INFO-1400002: Notification: interface-state-change severity-level:major host-name:"vedge01" system-ip:4.0.5.1 vpn-id:1 if-name:"ipsec2" new-state:down
Note: The logs for IPsec tunnel down are not part of iked debugs, they are FTMD logs. Therefore, neither charon nor IKE would be printed.
Note: The related logs are not usually together printed, there be more information between them not related to the same process.
Step 1. After the timestamp is identified and the time and the logs are correlated, start to review the logs from bottom to top.
Jun 18 00:31:17 vedge01 charon: 11[IKE] giving up after 3 retransmits
Jun 18 00:28:22 vedge01 charon: 08[IKE] retransmit 3 of request with message ID 543 (tries=3, timeout=30, exchange=37, state=2)
Jun 18 00:28:22 vedge01 charon: 08[NET] sending packet: from 10.132.3.92[4500] to 10.10.10.1[4500] (76 bytes)
Jun 18 00:26:45 vedge01 charon: 06[IKE] retransmit 2 of request with message ID 543 (tries=3, timeout=30, exchange=37, state=2)
Jun 18 00:26:45 vedge01 charon: 06[NET] sending packet: from 10.132.3.92[4500] to 10.10.10.1[4500] (76 bytes)
Jun 18 00:25:21 vedge01 charon: 08[IKE] sending DPD request
Jun 18 00:25:21 vedge01 charon: 08[ENC] generating INFORMATIONAL request 543 [ ]
Jun 18 00:25:21 vedge01 charon: 08[NET] sending packet: from 10.132.3.92[4500] to 10.10.10.1[4500] (76 bytes)
Jun 18 00:25:51 vedge01 charon: 05[IKE] retransmit 1 of request with message ID 543 (tries=3, timeout=30, exchange=37, state=2)
Jun 18 00:25:51 vedge01 charon: 05[NET] sending packet: from 10.132.3.92[4500] to 10.10.10.1[4500] (76 bytes)
The last successful DPD packet exchange is described as request # 542.
Jun 18 00:24:08 vedge01 charon: 11[ENC] generating INFORMATIONAL request 542 [ ]
Jun 18 00:24:08 vedge01 charon: 11[NET] sending packet: from 10.132.3.92[4500] to 10.10.10.1[4500] (76 bytes)
Jun 18 00:24:08 vedge01 charon: 07[NET] received packet: from 13.51.17.190[4500] to 10.10.10.1[4500] (76 bytes)
Jun 18 00:24:08 vedge01 charon: 07[ENC] parsed INFORMATIONAL response 542 [ ]
Step 2. Put all the information together in the right order:
Jun 18 00:24:08 vedge01 charon: 11[ENC] generating INFORMATIONAL request 542 [ ]
Jun 18 00:24:08 vedge01 charon: 11[NET] sending packet: from 10.132.3.92[4500] to 10.10.10.1[4500] (76 bytes)
Jun 18 00:24:08 vedge01 charon: 07[NET] received packet: from 10.10.10.1[4500] to 10.132.3.92[4500] (76 bytes)
Jun 18 00:24:08 vedge01 charon: 07[ENC] parsed INFORMATIONAL response 542 [ ]Jun 18 00:25:21 vedge01 charon: 08[IKE] sending DPD request
Jun 18 00:25:21 vedge01 charon: 08[ENC] generating INFORMATIONAL request 543 [ ]
Jun 18 00:25:21 vedge01 charon: 08[NET] sending packet: from 10.132.3.92[4500] to 10.10.10.1[4500] (76 bytes)
Jun 18 00:25:51 vedge01 charon: 05[IKE] retransmit 1 of request with message ID 543 (tries=3, timeout=30, exchange=37, state=2)
Jun 18 00:25:51 vedge01 charon: 05[NET] sending packet: from 10.132.3.92[4500] to 10.10.10.1[4500] (76 bytes)Jun 18 00:26:45 vedge01 charon: 06[IKE] retransmit 2 of request with message ID 543 (tries=3, timeout=30, exchange=37, state=2)
Jun 18 00:26:45 vedge01 charon: 06[NET] sending packet: from 10.132.3.92[4500] to 10.10.10.1[4500] (76 bytes)Jun 18 00:28:22 vedge01 charon: 08[IKE] retransmit 3 of request with message ID 543 (tries=3, timeout=30, exchange=37, state=2)
Jun 18 00:28:22 Lvedge01 charon: 08[NET] sending packet: from 10.132.3.92[4500] to 10.10.10.1[4500] (76 bytes)Jun 18 00:31:17 vedge01 charon: 11[IKE] giving up after 3 retransmits
Jun 18 00:31:17 vedge01 FTMD[1472]: %Viptela-LONDSR01-FTMD-6-INFO-1000001: VPN 1 Interface ipsec2 DOWN
Jun 18 00:31:17 vedge01 FTMD[1472]: %Viptela-LONDSR01-ftmd-6-INFO-1400002: Notification: interface-state-change severity-level:major host-name:"LONDSR01" system-ip:4.0.5.1 vpn-id:1 if-name:"ipsec2" new-state:down
For the example described, the tunnel goes down due to vEdge01 does not receive the DPD packets from 10.10.10.1. It is expected after 3 DPD retransmissions the IPsec peer is set as «lost» and the tunnel goes down. There are multiple reasons for this behavior, usually, it is related to the ISP where the packets are lost or dropped in the path. If the issue occurs once, there is no way to track the traffic lost, however, if the issue persists, the packet can be tracked with the use of captures on vEdge, remote IPSec peer, and the ISP.
Symptom 3. IPsec Tunnel Went Down and It Stays on a Downstate
As previously mentioned in this symptom, the tunnel previously worked fine but for any reason, it came down and the tunnel has not been able to successfully established again. In this scenario, there is an affectation to the network.
identify the points before the troubleshoot starts:
- IPsec tunnel (Number) with issues and configuration.
- The timestamp when the tunnel went down.
- IPsec peer IP address (Tunnel destination)
PFS Mismatch
In this example, the troubleshoot does not start with the timestamp when the tunnel goes down. As the issue persists, the IKE debugs are the best option.
interface ipsec1
description VWAN_VPN
ip address 192.168.0.101/30
tunnel-source-interface ge0/0
tunnel-destination 10.10.10.1
ike
version 2
rekey 28800
cipher-suite aes256-cbc-sha1
group 2
authentication-type
pre-shared-key
pre-shared-secret "$8$njK2pLLjgKWNQu0KecNtY3+fo3hbTs0/7iJy6unNtersmCGjGB38kIPjsoqqXZdVmtizLu79\naQdjt2POM242Yw=="
!
!
!
ipsec
rekey 3600
replay-window 512
cipher-suite aes256-cbc-sha1
perfect-forward-secrecy group-16
!
mtu 1400
no shutdownThe debug iked is enabled and negotiation is displayed.
daemon.info: Apr 27 05:12:56 vedge01 charon: 16[NET] received packet: from 10.10.10.1[4500] to 172.28.0.36[4500] (508 bytes)
daemon.info: Apr 27 05:12:56 vedge01 charon: 16[ENC] parsed CREATE_CHILD_SA request 557 [ SA No TSi TSr ]
daemon.info: Apr 27 05:12:56 vedge01 charon: 16[CFG] received proposals: ESP:AES_GCM_16_256/NO_EXT_SEQ, ESP:AES_CBC_256/HMAC_SHA1_96/NO_EXT_SEQ, ESP:3DES_CBC/HMAC_SHA1_96/NO_EXT_SEQ, ESP:AES_CBC_256/HMAC_SHA2_256_128/NO_EXT_SEQ, ESP:AES_CBC_128/HMAC_SHA1_96/NO_EXT_SEQ, ESP:3DES_CBC/HMAC_SHA2_256_128/NO_EXT_SEQ
daemon.info: Apr 27 05:12:56 vedge01 charon: 16[CFG] configured proposals: ESP:AES_CBC_256/HMAC_SHA1_96/MODP_4096/NO_EXT_SEQ
daemon.info: Apr 27 05:12:56 vedge01 charon: 16[IKE] no acceptable proposal found
daemon.info: Apr 27 05:12:56 vedge01 charon: 16[IKE] failed to establish CHILD_SA, keeping IKE_SA
daemon.info: Apr 27 05:12:56 vedge01 charon: 16[ENC] generating CREATE_CHILD_SA response 557 [ N(NO_PROP) ]
daemon.info: Apr 27 05:12:56 vedge01 charon: 16[NET] sending packet: from 172.28.0.36[4500] to 10.10.10.1[4500] (76 bytes)daemon.info: Apr 27 05:12:57 vedge01 charon: 08[NET] received packet: from 10.10.10.1[4500] to 172.28.0.36[4500] (76 bytes)
daemon.info: Apr 27 05:12:57 vedge01 charon: 08[ENC] parsed INFORMATIONAL request 558 [ ]
daemon.info: Apr 27 05:12:57 vedge01 charon: 08[ENC] generating INFORMATIONAL response 558 [ ]
daemon.info: Apr 27 05:12:57 vedge01 charon: 08[NET] sending packet: from 172.28.0.36[4500] to 10.10.10.1[4500] (76 bytes)
daemon.info: Apr 27 05:12:58 vedge01 charon: 07[NET] received packet: from 10.10.10.1[4500] to 172.28.0.36[4500] (396 bytes)
daemon.info: Apr 27 05:12:58 vedge01 charon: 07[ENC] parsed CREATE_CHILD_SA request 559 [ SA No TSi TSr ]
daemon.info: Apr 27 05:12:58 vedge01 charon: 07[CFG] received proposals: ESP:AES_GCM_16_256/NO_EXT_SEQ, ESP:AES_CBC_256/HMAC_SHA1_96/NO_EXT_SEQ, ESP:3DES_CBC/HMAC_SHA1_96/NO_EXT_SEQ, ESP:AES_CBC_256/HMAC_SHA2_256_128/NO_EXT_SEQ, ESP:AES_CBC_128/HMAC_SHA1_96/NO_EXT_SEQ, ESP:3DES_CBC/HMAC_SHA2_256_128/NO_EXT_SEQ
daemon.info: Apr 27 05:12:58 vedge01 charon: 07[CFG] configured proposals: ESP:AES_CBC_256/HMAC_SHA1_96/MODP_4096/NO_EXT_SEQ
daemon.info: Apr 27 05:12:58 Avedge01 charon: 07[IKE] no acceptable proposal found
daemon.info: Apr 27 05:12:58 vedge01 charon: 07[IKE] failed to establish CHILD_SA, keeping IKE_SA
Note: CREATE_CHILD_SA packets are exchanged for every rekey or new SA. For more references, navigate to Understanding IKEv2 Packet Exchange
IKE debugs show the same behavior and it is constantly repeated, so it is possible to take a part of the information and analyze it:
CREATE_CHILD_SA means a rekey, with the purpose for the new SPIS to be generated and exchanged between the IPsec endpoints.
- The vedge receives the CREATE_CHILD_SA request packet from 10.10.10.1.
- The vedge processes the request and verifies the proposals (SA) sent by peer 10.10.10.1
- The vedge compares the received proposal sent by the peer against its configured proposals.
- The CREATE_CHILD_SA exchanged fails with » no acceptable proposals found».
At this point, the question is: Why is there a configuration mismatch if the tunnel worked previously and no changes were done?
Analyze in deep, there is an extra field on the configured proposals that the peer is not sending.
configured proposals: ESP:AES_CBC_256/HMAC_SHA1_96/MODP_4096/NO_EXT_SEQ
Received proposals:
ESP:AES_GCM_16_256/NO_EXT_SEQ,
ESP:AES_CBC_256/HMAC_SHA1_96/NO_EXT_SEQ,
ESP:3DES_CBC/HMAC_SHA1_96/NO_EXT_SEQ,
ESP:AES_CBC_256/HMAC_SHA2_256_128/NO_EXT_SEQ,
ESP:AES_CBC_128/HMAC_SHA1_96/NO_EXT_SEQ,
ESP:3DES_CBC/HMAC_SHA2_256_128/NO_EXT_SEQ
MODP_4096 is DH group 16, which vedges has configured for PFS (perfect-forward-secrecy) on phase 2 (IPsec section).
PFS is the only mismatch configuration in which the tunnel can be successfully established or not according to who is the initiator or responder in the IKE negotiation. However, when the rekey starts the tunnel is not be able to continue and this symptom can be presented or related to.
vEdge IPSec/Ikev2 Tunnel Not Getting Re-initiated After Being Torn Down Due to a DELETE Event
See Cisco bug ID CSCvx86427 for more information about this behavior.
As the issue perseveres, the IKE debugs are the best options. However, for this particular bug if debugs are enabled no information is displayed neither the terminal nor the message file.
To narrow down this issue and verify if vEdge hits the Cisco bug ID CSCvx86427, it is needed to find the moment when the tunnel goes down.
identify the points before the troubleshoot starts:
- IPsec tunnel (Number) with issues and configuration.
- The timestamp when the tunnel went down.
- IPsec peer IP address (Tunnel destination)
After the timestamp is identified, and the time and logs are correlated, review the logs just before when the tunnel goes down.
Apr 13 22:05:21 vedge01 charon: 12[IKE] received DELETE for IKE_SA ipsec1_1[217]
Apr 13 22:05:21 vedge01 charon: 12[IKE] deleting IKE_SA ipsec1_1[217] between 10.16.0.5[10.16.0.5]...10.10.10.1[10.10.10.1]
Apr 13 22:05:21 vedge01 charon: 12[IKE] deleting IKE_SA ipsec1_1[217] between 10.16.0.5[10.16.0.5]...10.10.10.1[10.10.10.1]
Apr 13 22:05:21 vedge01 charon: 12[IKE] IKE_SA deleted
Apr 13 22:05:21 vedge01 charon: 12[IKE] IKE_SA deleted
Apr 13 22:05:21 vedge01 charon: 12[ENC] generating INFORMATIONAL response 4586 [ ]
Apr 13 22:05:21 vedge01 charon: 12[NET] sending packet: from 10.16.0.5[4500] to 10.10.10.1[4500] (80 bytes)
Apr 13 22:05:21 vedge01 charon: 12[KNL] Deleting SAD entry with SPI 00000e77
Apr 13 22:05:21 vedge01 FTMD[1269]: %Viptela-AZGDSR01-FTMD-6-INFO-1000001: VPN 1 Interface ipsec1 DOWN
Apr 13 22:05:21 vedge01 FTMD[1269]: %Viptela-AZGDSR01-ftmd-6-INFO-1400002: Notification: interface-state-change severity-level:major host-name:"vedge01" system-ip:4.1.0.1 vpn-id:1 if-name:"ipsec1" new-state:down
Note: There are multiples DELETES packets on an IPsec negotiation, and the DELETE for CHILD_SA is an expected DELETE for a REKEY process, this issue is seen when a pure IKE_SA DELETE packet is received without any particular IPsec negotiation. That DELETE removes all the IPsec/IKE tunnel.
Related Information
- KEv2 Packet Exchange and Protocol Level Debugging
- The Internet Key Exchange (IKE) — RFC 2409
- IKEv2 — RFC 7296
- Site-to-Site LAN to LAN IPSec Between vEdge and Cisco IOS
- Technical Support & Documentation — Cisco Systems
This article describes how to troubleshoot IPsec VPN connection with IKEv2 on Aviatrix gateway.
Workflow¶
Check Site2Cloud Connection Status¶
- Login Aviatrix Controller
- Go to SITE2CLOUD -> Setup
- Find the Site2Cloud Connection
- Check the tunnel status
- if the Status displays “Down”, please follow the next step
Perform the Diagnostics Action “Run analysis”¶
- Go to SITE2CLOUD -> Diagnostics
- Select the related information for VPC ID/VNet Name, Connection, and Gateway
- Select the option “Run analysis” under Action and click the button “OK”
- View the suggestion on the prompt panel to troubleshoot Site2Cloud tunnel down issue
- Follow the next step to view logs if needed
Troubleshoot the keyword in the Diagnostics Action “Show logs”¶
- Go to SITE2CLOUD -> Diagnostics
- Select the related information for VPC ID/VNet Name, Connection, and Gateway
- Select the option “Show logs” under Action and click the button “OK”
- Review the logs on the prompt panel
- Compare your logs with the successful example logs as below
- Attempt to locate the keyword or failure message during IKEv2/IPsec negotiation. Here are some examples of negotiation failure and hint to fix or troubleshoot it further:
- Keyword: “Error: Failed to deliver message to gateway”
- Keyword: “establishing IKE_SA failed, peer not responding”
- Keyword: “NO_PROPOSAL_CHOSEN”
- Keyword: “AUTHENTICATION_FAILED”
- Keyword: “no shared key found”
- Keyword: “failed to establish CHILD_SA, keeping IKE_SA”
Keyword: “establishing IKE_SA failed, peer not responding”¶
Probable Causes:
- Peer IP address is mismatched, or peer IP address is not reachable
- UDP Port 500/4500 is not accessible
Suggestions:
- Troubleshoot connectivity between Aviatrix gateway and peer VPN router
Keyword: “NO_PROPOSAL_CHOSEN”¶
Probable Causes:
- Peer IP address is mismatched, or peer IP address is not reachable
- IKE version is mismatched (one VPN gateway uses IKEv1 and another one uses IKEv2)
- IKEv2 algorithm is mismatched
- IPsec algorithm is mismatched
Suggestions:
- Troubleshoot connectivity between Aviatrix gateway and peer VPN router
- Verify that both VPN settings use the same IKEv2 version
- Verify that all IKEv2/IPsec algorithm parameters (i.e., Authentication/DH Groups/Encryption) match on both VPN configuration
Keyword: “AUTHENTICATION_FAILED”¶
Probable Causes:
- IKE version is mismatched (one VPN gateway uses IKEv1 and another one uses IKEv2)
- pre-shared key is mismatched
- Identifier configuration is mismatched
Suggestions:
- Verify that both VPN settings use the same IKEv2 version
- Verify that pre-shared key match on both VPN configuration
- Verify that Identifier match
- By default, Aviatrix utilizes gateway’s public IP as Local Identifier.
Keyword: “failed to establish CHILD_SA, keeping IKE_SA”¶
Probable Causes:
- IPsec algorithm is mismatched
Suggestions:
- Verify that all IPsec algorithm parameters (i.e., Authentication/DH Groups/Encryption) match on both VPN configuration