Содержание
- ASA IKEv2/IPSec VTI to IOS-XE Router
- ASA Configuration
- Specify an IKEv2 Policy; define the encryption/integrity/PRF algorithms, DH group and SA lifetime
- Enable IKEv2 on the outside interface
- Create an IPSec Transform Set, define the encryption and integrity (hashing) algorithms
- Create an IPSec Profile, reference the previously created IPSec Transform Set
- Create a Group Policy and ensure IKEv2 is selected an allowed protocol (IKEv2)
- Create a Tunnel Group
- Create a Tunnel Interface
- Create static routes to the destination LAN
- IOS Router
- Create an IKEv2 Policy
- Create an IKEv2 Policy and reference the IKEv2 Proposal
- Define a IKEv2 Keyring and define the pre-shared key
- Create an IKEv2 Profile
- Create an IPSec Transform Set
- Create an IPSec Profile
- Create a Tunnel Interface
- Create a static route to a remote network over the tunnel interface
- Verification
- Rate this:
- Share this:
- Like this:
- Related
- Published by integratingit
- 6 thoughts on “ ASA IKEv2/IPSec VTI to IOS-XE Router ”
- Ikev2 negotiation aborted due to error create child exchange failed
ASA IKEv2/IPSec VTI to IOS-XE Router
Cisco introduced VTI to ASA Firewalls in version 9.7.1 as an alternative to policy based crypto maps. Cisco IOS routers have long supported VTI (sVTI, DVTI, DMVPN, FlexVPN etc). This post will describe the steps on how to configure a VTI between a Cisco ASA Firewall and a Cisco IOS Router.
Hardware/Software used:
Cisco ASAv (v9.9.1)
Cisco CSR1000v (v16.3.3)
ASA Configuration
Specify an IKEv2 Policy; define the encryption/integrity/PRF algorithms, DH group and SA lifetime
Enable IKEv2 on the outside interface
Create an IPSec Transform Set, define the encryption and integrity (hashing) algorithms
Create an IPSec Profile, reference the previously created IPSec Transform Set
Create a Group Policy and ensure IKEv2 is selected an allowed protocol (IKEv2)
Create a Tunnel Group
Ensure the Tunnel Group matches the IP address of the Peer device, reference the Group Policy previously created and specify the IKEv2 pre-shared keys (local and remote).
Create a Tunnel Interface
Ensure this is named appropriately. It is important to ensure you specify the tunnel mode ipsec ipv4, there is no default value unlike on an IOS router which defaults to GRE for encapsulation (ASA’s do not support GRE). Specify the tunnel source, destination, ip address and reference the ipsec profile previously created.
Create static routes to the destination LAN
IOS Router
Create an IKEv2 Policy
Define the encryption/integrity/PRF algorithms, DH group and SA lifetime. This must obviously match the IKEv2 policy defined on the ASA.
Create an IKEv2 Policy and reference the IKEv2 Proposal
Define a IKEv2 Keyring and define the pre-shared key
Create an IKEv2 Profile
Specify the remote identity (IP address) of the ASA, the local identity that will be sent to the ASA (local router’s public IP address), define authentication method and reference the pre-defined IKEv2 Keyring.
Create an IPSec Transform Set
Define the encryption and integrity (hashing) algorithms. This must obviously match the algorithms defined in the Transform Set on the ASA.
Create an IPSec Profile
Reference the previously created IPSec Transform Set and IKEv2 Profile
Create a Tunnel Interface
Specify a tunnel IP address, source interface, tunnel mode (must be ipsec ipv4), tunnel destination (ip address of the ASA) and tunnel protection (previously defined ipsec profile).
Create a static route to a remote network over the tunnel interface
Verification
On the ASA, run the command show interface tunnel 0 will display configuration details of the tunnel interface. You can confirm the source interface, source ip address, destination ip address and the tunnel mode. The tunnel mode has to be set to ipsec ipv4, if not the output would display invalid! and the VPN will not work.
show crypto ipsec sa details will as usual confirm 2 IPSec SA’s and confirm encaps/decaps of traffic communicating over the tunnel interface.
On the ASA you can also run the command show vpn-sessiondb detail l2l to obtain more information about the session, such as endpoint IP address, algorithms, duration, bytes tx/rx etc.
Running a ping from a loopback on the router to a subnet behind the ASA with debug icmp trace enable on the ASA will confirm traffic is source over the VTI.
On the router, similar commands exist as the ASA. Running the command show interface tunnel 1 will reveal the tunnel IP address, tunnel source interface/ip address, destination IP address, tunnel protocol, transport and transport protection (ipsec profile) etc.
show crypto ipsec sa will provide the same output as the command run on the ASA (peer ip address, encaps/decaps etc).
Rate this:
Like this:
Published by integratingit
6 thoughts on “ ASA IKEv2/IPSec VTI to IOS-XE Router ”
Thank you so much for this guide!
I have managed to configure an IKEv2/IPSec VTI tunnel between a Cisco ASA 5506-X [ 9.9(2) ] and Cisco 887VW [ 15.4(3)M6a ].
Not sure if it was due to IOS version of the 887, but I ran into the following strange errors, when using the “show crypto ikev2 diagnose error” on 887:
Error(1): We requested a certificate, but the peer supplied none
Error(1): Failed to retrieve issuer public key hash list
Error(8): Failed to find a matching policy
And on those on ASA:
All configured IKE versions failed to establish the tunnel. Map Tag= __vti-crypto-map-7-0-0. Map Sequence Number = xxxxx.
IKEv2 Failed to process Configuration Payload request for attribute 0x123. Error: Platform errors
IKEv2 Negotiation aborted due to ERROR: Auth exchange failed
I made it work by changing the following at 887:
router(config-ikev2-profile)#no match identity remote address x.x.x.x 255.255.255.255
router(config-ikev2-profile)#match identity remote any
Not sure though about the security impact of this change; both sites have static public IP addresses, so I am already limiting the VPN connections with ACLs.
Hi,
I assume if you removed the remote identity of the IP address and replaced with “any” that the remote ASA was not identifying it self as the IP address you defined. Now that it’s working, if you run “show crypto ikev2 sa detailed” what does it say the “remote id:” is?
Are you using certificates? Normally I’d use a certificate map to identify remote peers and “identity local dn” to identify the router. Then you wouldn’t need the “match identity remote any” command and you would know that only an ASA/router with your certificates can authenticate a VPN tunnel.
Hey,
I’ve ran the “show crypto ikev2 sa detailed” at the 887 and Remote id: shows the internal ip address of the outside interface of the ASA (ex. 192.168.176.2); note that ASA is behind an ISP router with all the traffic NATed to it and therefore the 887:”NAT-T is detected outside” & ASA:”NAT-T is detected inside”.
So it seems that 887 was expecting the public IP address configured at the ikev2 profiles but ASA was “injecting” its inside IP address because… that was what it knew to do?
I now tested changing the 887 config to the following:
router(config-ikev2-profile)#match identity remote address 192.168.176.2
…and it still works!
No, I am not using certificates yet; I read it requires a server or route to ran as a CA and I do not want to invest time to that yet, just to replace my old DMVPN l2l tunnel between the 887 and 877 (*877 replaced with the ASA).
Next step to replace the 887 with an ASA 5510 to achieve something more 5MB throughput and less than 100% usage with every file copy that currently the 887 struggle with.
But do you still mark as “security risk” the current setup without certificates?
(now it has the “match identity remote address”, plus ACLs between x2 static public IPs, plus a loooong PSK)
Hi,
Good to hear it’s working, I expected that to be the issue.
You should be fine. I’d recommend using IKEv2 with the latest recommended IKEv2 algorithms (checkout a post I made a couple of months ago) and a long PSK should be ok (note, with IKEv2 you can have asymmetric PSK, 1 for local and 1 for remote peer).
Источник
Ikev2 negotiation aborted due to error create child exchange failed
Just setting up my first 2.2 install, trying to tunnel to our Cisco ASA. The tunnel seems to drop partially at times – I’m not well versed in this stuff by any means, so forgive me for not knowing the terminology.
Under Status/IPSec, if the tunnel is working, there is an option to «Show child SA entries.» When I come in in the mornings, that option is not there and I can’t reach anything on the other side of the tunnel, though it shows as being up. Disconnecting and reconnecting manually brings everything back up.
P1: IKE v2, mutual PSK, AES 256, SHA512, DH 14
P2: tunnel, ESP, AES 256, SHA512, PFS group 14
No logs yet, as the IPSec logging seems very verbose. Will get logging sent to a remote syslog server if it will help…
This is what the log file looks like when the tunnel times out and tries to restart automatically:
Dec 8 03:17:21 charon: 03[KNL] creating acquire job for policy 1.2.3.4/32|/0 === 9.8.7.6/32|/0 with reqid <1>
Dec 8 03:17:21 charon: 05[IKE] establishing CHILD_SA con1<1>
Dec 8 03:17:21 charon: 05[IKE] establishing CHILD_SA con1<1>
Dec 8 03:17:21 charon: 05[ENC] generating CREATE_CHILD_SA request 482 [ N(ESP_TFC_PAD_N) SA No TSi TSr ]
Dec 8 03:17:21 charon: 05[NET] sending packet: from 1.2.3.4[4500] to 9.8.7.6[4500] (240 bytes)
Dec 8 03:17:21 charon: 05[NET] received packet: from 9.8.7.6[4500] to 1.2.3.4[4500] (80 bytes)
Dec 8 03:17:21 charon: 05[ENC] parsed CREATE_CHILD_SA response 482 [ N(NO_PROP) ]
Dec 8 03:17:21 charon: 05[IKE] received NO_PROPOSAL_CHOSEN notify, no CHILD_SA built
Dec 8 03:17:21 charon: 05[IKE] received NO_PROPOSAL_CHOSEN notify, no CHILD_SA built
Dec 8 03:17:21 charon: 05[IKE] failed to establish CHILD_SA, keeping IKE_SA
Dec 8 03:17:21 charon: 05[IKE] failed to establish CHILD_SA, keeping IKE_SA
And for a manual start of the tunnel:
Dec 8 09:14:49 charon: 16[CFG] received stroke: initiate ‘con1’
Dec 8 09:14:49 charon: 10[IKE] initiating IKE_SA con1[177] to 9.8.7.6
Dec 8 09:14:49 charon: 10[IKE] initiating IKE_SA con1[177] to 9.8.7.6
Dec 8 09:14:49 charon: 10[ENC] generating IKE_SA_INIT request 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) N(FRAG_SUP) ]
Dec 8 09:14:49 charon: 10[NET] sending packet: from 1.2.3.4[500] to 9.8.7.6[500] (376 bytes)
Dec 8 09:14:49 charon: 10[NET] received packet: from 9.8.7.6[500] to 1.2.3.4[500] (521 bytes)
Dec 8 09:14:49 charon: 10[ENC] parsed IKE_SA_INIT response 0 [ SA KE No V V V N(NATD_S_IP) N(NATD_D_IP) V ]
Dec 8 09:14:49 charon: 10[IKE] received Cisco Delete Reason vendor ID
Dec 8 09:14:49 charon: 10[IKE] received Cisco Delete Reason vendor ID
Dec 8 09:14:49 charon: 10[IKE] received Cisco Copyright 
2009 vendor ID
Dec 8 09:14:49 charon: 10[IKE] received Cisco Copyright 2009 vendor ID
Dec 8 09:14:49 charon: 10[ENC] received unknown vendor ID: 43:49:53:43:4f:2d:47:52:45:2d:4d:4f:44:45:02
Dec 8 09:14:49 charon: 10[IKE] received FRAGMENTATION vendor ID
Dec 8 09:14:49 charon: 10[IKE] received FRAGMENTATION vendor ID
Dec 8 09:14:49 charon: 10[IKE] authentication of ‘1.2.3.4’ (myself) with pre-shared key
Dec 8 09:14:49 charon: 10[IKE] authentication of ‘1.2.3.4’ (myself) with pre-shared key
Dec 8 09:14:49 charon: 10[IKE] establishing CHILD_SA con1
Dec 8 09:14:49 charon: 10[IKE] establishing CHILD_SA con1
Dec 8 09:14:49 charon: 10[ENC] generating IKE_AUTH request 1 [ IDi N(INIT_CONTACT) IDr AUTH N(ESP_TFC_PAD_N) SA TSi TSr N(MOBIKE_SUP) N(ADD_4_ADDR) N(EAP_ONLY) ]
Dec 8 09:14:49 charon: 10[NET] sending packet: from 1.2.3.4[4500] to 9.8.7.6[4500] (272 bytes)
Dec 8 09:14:49 charon: 10[NET] received packet: from 9.8.7.6[4500] to 1.2.3.4[4500] (256 bytes)
Dec 8 09:14:49 charon: 10[ENC] parsed IKE_AUTH response 1 [ V IDr AUTH SA TSi TSr N(ESP_TFC_PAD_N) N(NON_FIRST_FRAG) ]
Dec 8 09:14:49 charon: 10[IKE] authentication of ‘9.8.7.6’ with pre-shared key successful
Dec 8 09:14:49 charon: 10[IKE] authentication of ‘9.8.7.6’ with pre-shared key successful
Dec 8 09:14:49 charon: 10[IKE] IKE_SA con1[177] established between 1.2.3.4[1.2.3.4]…9.8.7.6[9.8.7.6]
Dec 8 09:14:49 charon: 10[IKE] IKE_SA con1[177] established between 1.2.3.4[1.2.3.4]…9.8.7.6[9.8.7.6]
Dec 8 09:14:49 charon: 10[IKE] scheduling reauthentication in 27966s
Dec 8 09:14:49 charon: 10[IKE] scheduling reauthentication in 27966s
Dec 8 09:14:49 charon: 10[IKE] maximum IKE_SA lifetime 28506s
Dec 8 09:14:49 charon: 10[IKE] maximum IKE_SA lifetime 28506s
Dec 8 09:14:49 charon: 10[IKE] received ESP_TFC_PADDING_NOT_SUPPORTED, not using ESPv3 TFC padding
Dec 8 09:14:49 charon: 10[IKE] received ESP_TFC_PADDING_NOT_SUPPORTED, not using ESPv3 TFC padding
Dec 8 09:14:49 charon: 10[IKE] CHILD_SA con1 <1>established with SPIs cbbb4fef_i 2dec761d_o and TS 192.168.244.0/24|/0 === 192.168.242.0/24|/0
Dec 8 09:14:49 charon: 10[IKE] CHILD_SA con1 <1>established with SPIs cbbb4fef_i 2dec761d_o and TS 192.168.244.0/24|/0 === 192.168.242.0/24|/0
The ASA logs would be more telling, it’s sending back a «no proposal chosen» which means it’s claiming the proposal doesn’t match anything it has configured, the question is why. ASAs are easy to configure in such a way that they’ll use diff settings as initiator than responder, which is usually what causes issues along those lines.
Syslog would only say this:
Dec 8 16:19:01 192.168.242.1 %ASA-3-751022: Local:9.8.7.6:4500 Remote:1.2.3.4:4500 Username:1.2.3.4 IKEv2 Tunnel rejected: Crypto Map Policy not found for remote traffic selector 192.168.244.0/192.168.244.255/0/65535/0 local traffic selector 192.168.242.0/192.168.242.255/0/65535/0!
Dec 8 16:19:01 192.168.242.1 %ASA-4-750003: Local:9.8.7.6:4500 Remote:1.2.3.4:4500 Username:1.2.3.4 IKEv2 Negotiation aborted due to ERROR: Failed to find a matching policy
But debug from the console says:
IKEv2-PROTO-1: (48): Failed to find a matching policy
IKEv2-PROTO-1: (48): Received Policies:
ESP: Proposal 1: AES-CBC-256 SHA512 DH_GROUP_2048_MODP/Group 14 Don’t use ESN
ESP: Proposal 2: AES-GCM-256 DH_GROUP_2048_MODP/Group 14 Don’t use ESN
IKEv2-PROTO-1: (48): Failed to find a matching policy
IKEv2-PROTO-1: (48): Expected Policies:
IKEv2-PROTO-1: (48): Failed to find a matching policy
IKEv2-PROTO-1: (48):
IKEv2-PROTO-1: (48): Create child exchange failed
IKEv2-PROTO-1: (48):
I guess the lack of anything listed after «expected policies» suggests it must be a configuration issue on my Cisco, and not a pfSense problem. No idea what it could be though.
ASAs are easy to configure in such a way that they’ll use diff settings as initiator than responder
I’d be curious to have you expand on that. BTW debug from the Cisco is here: http://pastebin.com/egAZmYFu
Cisco config looks like this:
You need to show the logs from pfSense side.
Источник
I have a site to site connection from the ASA to an Azure subscription.
The site to site session starts up fine, but after a few minutes (from 3 to 25) the connection fails. If on ASDM I open Monitoring > VPN > VPN Statistics > Sessions, the session is still there, but no communication (e.g. ICMP, RDP, ..) can be performed. If I logout the session, the communication is reestablished, until the next failure a few minutes later.
Every time the connection fails, I observe this warning on the syslog:
4 Sep 18 2018 17:40:58 750003 Local:80.x.y.z:500
Remote:51.a.b.c:500 Username:51.a.b.c IKEv2 Negotiation aborted
due to ERROR: Detected unsupported failover version
This is the configuration I have used to setup the site to site connection on the router:
object network HQ-LAN
subnet 10.0.0.0 255.0.0.0
description The HQ local network address space on premise
object network Azure-UKSouth-LAN
subnet 172.16.0.0 255.255.0.0
description Azure virtual network address space on UKSouth Azure
object-group network AzureLabNet-network
description Azure AzureLabNet Virtual Network
network-object object AzureLabNet-LAN
object-group network HQ-network
description HQ on-premises Network
network-object object HQ-LAN
object-group network HQ-UKSouth-network
description The HQ Azure UK South network
network-object object HQ-UKSouth-LAN
access-list uksouth-s2s-acl extended permit ip object-group HQ-network object-group HQ-UKSouth-network
nat (LAN,INTERNET) source static HQ-network HQ-network destination static HQ-UKSouth-network HQ-UKSouth-network no-proxy-arp route-lookup
!
crypto ipsec ikev2 ipsec-proposal UKSouth
protocol esp encryption aes-gcm
protocol esp integrity null
crypto ipsec security-association lifetime seconds 3600
crypto ipsec security-association lifetime kilobytes 102400000
crypto ipsec security-association pmtu-aging infinite
crypto ipsec inner-routing-lookup
crypto map CRYPTO-MAP 2 match address uksouth-s2s-acl
crypto map CRYPTO-MAP 2 set peer 51.a.b.c
crypto map CRYPTO-MAP 2 set ikev2 ipsec-proposal UKSouth
crypto map CRYPTO-MAP 2 set ikev2 pre-shared-key *****
crypto map CRYPTO-MAP 2 set security-association lifetime seconds 3600
crypto map CRYPTO-MAP 2 set nat-t-disable
crypto map CRYPTO-MAP interface INTERNET
crypto ca trustpool policy
crypto ikev2 policy 2
encryption aes
integrity sha256
group 19
prf sha256
lifetime seconds 28800
crypto ikev2 enable INTERNET
group-policy AzureGroupPolicy-UKSouth internal
group-policy AzureGroupPolicy-UKSouth attributes
vpn-tunnel-protocol ikev2
dynamic-access-policy-record DfltAccessPolicy
tunnel-group 51.a.b.c type ipsec-l2l
tunnel-group 51.a.b.c general-attributes
default-group-policy AzureGroupPolicy-UKSouth
tunnel-group 51.a.b.c ipsec-attributes
ikev2 remote-authentication pre-shared-key *****
ikev2 local-authentication pre-shared-key *****
no tunnel-group-map enable peer-ip
tunnel-group-map default-group 51.a.b.c
sysopt connection tcpmss 1350
sysopt connection preserve-vpn-flows
From the Azure side,
$RG = "RG"
$ConnectionName = "UKSouth-HQ-S2S"
$connection = Get-AzureRmVirtualNetworkGatewayConnection -Name $ConnectionName -ResourceGroupName $RG
$ipsecpolicy = New-AzureRmIpsecPolicy -IkeEncryption AES128 -IkeIntegrity SHA256 -DhGroup ECP256 -IpsecEncryption GCMAES128 -IpsecIntegrity GCMAES128 -PfsGroup ECP256 -SALifeTimeSeconds 3600 -SADataSizeKilobytes 2048
Set-AzureRmVirtualNetworkGatewayConnection -VirtualNetworkGatewayConnection $connection -UsePolicyBasedTrafficSelectors $True -IpsecPolicies $ipsecpolicy
Any suggestion on how to prevent this communication failure?
UPDATE
I am not sure if this is meaningful, but after the connection fails, but the session is still up, «pkts decaps» doesn’t increase anymore, but «pkts encaps» keeps increasing:
gateway# show crypto ipsec sa
interface: INTERNET
Crypto map tag: CRYPTO-MAP, seq num: 1, local addr: 80.x.y.z
access-list uksouth-s2s-acl extended permit ip 10.0.0.0 255.0.0.0 172.16.0.0 255.255.0.0
local ident (addr/mask/prot/port): (10.0.0.0/255.0.0.0/0/0)
remote ident (addr/mask/prot/port): (172.16.0.0/255.255.0.0/0/0)
current_peer: 51.a.b.c
#pkts encaps: 4549, #pkts encrypt: 4549, #pkts digest: 4549
#pkts decaps: 4953, #pkts decrypt: 4953, #pkts verify: 4953
#pkts compressed: 0, #pkts decompressed: 0
#pkts not compressed: 4549, #pkts comp failed: 0, #pkts decomp failed: 0
#pre-frag successes: 0, #pre-frag failures: 0, #fragments created: 0
#PMTUs sent: 0, #PMTUs rcvd: 0, #decapsulated frgs needing reassembly: 0
#TFC rcvd: 0, #TFC sent: 0
#Valid ICMP Errors rcvd: 0, #Invalid ICMP Errors rcvd: 0
#send errors: 0, #recv errors: 0
local crypto endpt.: 80.x.y.z/500, remote crypto endpt.: 51.a.b.c/500
path mtu 1494, ipsec overhead 55(36), media mtu 1500
PMTU time remaining (sec): 0, DF policy: copy-df
ICMP error validation: disabled, TFC packets: disabled
current outbound spi: 73EF6FC2
current inbound spi : 766AF315
inbound esp sas:
spi: 0x766AF315 (1986720533)
SA State: active
transform: esp-aes-gcm esp-null-hmac no compression
in use settings ={L2L, Tunnel, IKEv2, }
slot: 0, conn_id: 29892608, crypto-map: CRYPTO-MAP
sa timing: remaining key lifetime (kB/sec): (92159057/2555)
IV size: 8 bytes
replay detection support: Y
Anti replay bitmap:
0xFFFFFFFF 0xFFFFFFFF
outbound esp sas:
spi: 0x73EF6FC2 (1945071554)
SA State: active
transform: esp-aes-gcm esp-null-hmac no compression
in use settings ={L2L, Tunnel, IKEv2, }
slot: 0, conn_id: 29892608, crypto-map: CRYPTO-MAP
sa timing: remaining key lifetime (kB/sec): (93181492/2555)
IV size: 8 bytes
replay detection support: Y
Anti replay bitmap:
0x00000000 0x00000001
UPDATE #2
While debugging, I have noticed that once the first IKE negotiations completes successfully, the last line on the debug is referring to a peer message ID: 0x1:
debug crypto ipsec 255
debug crypto isakmp 255
debug crypto ikev2 protocol 255
debug crypto ikev2 platform 255
..
IKEv2-PROTO-5: (59): Deleting negotiation context for peer message ID: 0x1
The debug output goes silent afterwards, until the connection fails.
At that point, I observe a number of sequential peer message IDs (0x2, 0x3, 0x4, ..) and their deletion until I don’t force the session to logout.
I am not sure if those peer message IDs are the cause (perhaps Azure or the ASA only support a single peer message IDs per security association?) or an effect of the issue.
The peer message ID 0x2 looks like this:
Sep 19 17:35:29 [IKEv1]IKE Receiver: Packet received on 80.x.y.z:500 from 51.a.b.c:500
IKEv2 Recv RAW packet dump
..
IKEv2-PLAT-3: RECV PKT [CREATE_CHILD_SA] [51.a.b.c]:500->[80.x.y.z]:500 InitSPI=0x145521242b6265d7 RespSPI=0x0c25d68e92bfcdc2 MID=00000002
IKEv2-PROTO-5: (59): Request has mess_id 2; expected 2 through 2
(59):
IKEv2-PROTO-2: (59): Received Packet [From 51.a.b.c:500/To 80.x.y.z:500/VRF i0:f0]
(59): Initiator SPI : 145521242B6265D7 - Responder SPI : 0C25D68E92BFCDC2 Message id: 2
(59): IKEv2 CREATE_CHILD_SA Exchange REQUESTIKEv2-PROTO-3: (59): Next payload: ENCR, version: 2.0 (59): Exchange type: CREATE_CHILD_SA, flags: INITIATOR (59): Message id: 2, length: 304(59):
Payload contents:
IKEv2-PROTO-1: decrypt queued(59):
(59): Decrypted packet:(59): Data: 304 bytes
IKEv2-PROTO-1: Asynchronous request queued
IKEv2-PROTO-1:
IKEv2-PLAT-2: (59): Decrypt success status returned via ipc 1
(59): REAL Decrypted packet:(59): Data: 228 bytes
IKEv2-PROTO-5: Parse Notify Payload: REKEY_SA NOTIFY(REKEY_SA) Next payload: SA, reserved: 0x0, length: 12
Security protocol id: ESP, spi size: 4, type: REKEY_SA
SA Next payload: N, reserved: 0x0, length: 44
last proposal: 0x0, reserved: 0x0, length: 40
Proposal: 1, Protocol id: ESP, SPI size: 4, #trans: 3 last transform: 0x3, reserved: 0x0: length: 12
type: 1, reserved: 0x0, id: AES-GCM
last transform: 0x3, reserved: 0x0: length: 8
type: 4, reserved: 0x0, id: DH_GROUP_256_ECP/Group 19
last transform: 0x0, reserved: 0x0: length: 8
type: 5, reserved: 0x0, id: Don't use ESN
N Next payload: TSi, reserved: 0x0, length: 52
f6 b6 68 e9 13 e6 a5 8e 04 c4 73 d1 6e 74 c8 35
2c e9 fd 92 a0 b2 07 6a 33 ce 35 d0 88 b8 4f 42
85 1b 4a 69 cd 1c 0f cd 9d 52 1c c3 77 f2 a0 57
TSi Next payload: TSr, reserved: 0x0, length: 24
Num of TSs: 1, reserved 0x0, reserved 0x0
TS type: TS_IPV4_ADDR_RANGE, proto id: 0, length: 16
start port: 0, end port: 65535
start addr: 172.16.0.0, end addr: 172.16.255.255
TSr Next payload: KE, reserved: 0x0, length: 24
Num of TSs: 1, reserved 0x0, reserved 0x0
TS type: TS_IPV4_ADDR_RANGE, proto id: 0, length: 16
start port: 0, end port: 65535
start addr: 10.0.0.0, end addr: 10.255.255.255
KE Next payload: NONE, reserved: 0x0, length: 72
DH group: 19, Reserved: 0x0
f9 63 b6 54 8e bd d7 92 b5 76 7e 5a 7d 3d ab 7c
22 14 05 76 da 72 a1 ef 9e be b0 30 06 1e dc cb
9e bc a4 c5 49 c4 05 0d db 0a 09 3e 95 6e c8 b8
ee 3e 22 25 12 13 72 0f d9 13 b4 8d 65 06 a0 70
IKEv2-PROTO-5: (59): SM Trace-> SA: I_SPI=145521242B6265D7 R_SPI=0C25D68E92BFCDC2 (R) MsgID = 00000002 CurState: READY Event: EV_RECV_CREATE_CHILD
IKEv2-PROTO-5: (59): Action: Action_Null
IKEv2-PROTO-5: (59): SM Trace-> SA: I_SPI=145521242B6265D7 R_SPI=0C25D68E92BFCDC2 (R) MsgID = 00000002 CurState: CHILD_R_INIT Event: EV_RECV_CREATE_CHILD
IKEv2-PROTO-5: (59): Action: Action_Null
IKEv2-PROTO-5: (59): SM Trace-> SA: I_SPI=145521242B6265D7 R_SPI=0C25D68E92BFCDC2 (R) MsgID = 00000002 CurState: CHILD_R_INIT Event: EV_VERIFY_MSG
IKEv2-PROTO-2: (59): Validating create child message
IKEv2-PROTO-5: (59): SM Trace-> SA: I_SPI=145521242B6265D7 R_SPI=0C25D68E92BFCDC2 (R) MsgID = 00000002 CurState: CHILD_R_INIT Event: EV_CHK_CC_TYPE
IKEv2-PROTO-2: (59): Check for create child response message type
IKEv2-PROTO-5: (59): SM Trace-> SA: I_SPI=145521242B6265D7 R_SPI=0C25D68E92BFCDC2 (R) MsgID = 00000002 CurState: CHILD_R_IPSEC Event: EV_REKEY_IPSECSA
IKEv2-PROTO-2: (59): Beginning IPSec Rekey as Responder
IKEv2-PROTO-5: (59): SM Trace-> SA: I_SPI=145521242B6265D7 R_SPI=0C25D68E92BFCDC2 (R) MsgID = 00000002 CurState: CHILD_R_IPSEC Event: EV_PROC_MSG
IKEv2-PROTO-2: (59): Processing CREATE_CHILD_SA exchange
IKEv2-PLAT-2: Selector received from peer is accepted
IKEv2-PLAT-2: (59): PROXY MATCH on crypto map CRYPTO-MAP seq 1
IKEv2-PROTO-2: (59):
IKEv2-PROTO-5: (59): SM Trace-> SA: I_SPI=145521242B6265D7 R_SPI=0C25D68E92BFCDC2 (R) MsgID = 00000002 CurState: CHILD_R_IPSEC Event: EV_NO_EVENT
IPSEC: Received a PFKey message from IKE
IPSEC: Parsing PFKey GETSPI message
IPSEC: Creating IPsec SA
IPSEC: Getting the inbound SPI
IPSEC DEBUG: Inbound SA (SPI 0x00000000) state change from inactive to embryonic
IPSEC: New embryonic SA created @ 0x00007f5357431640,
SCB: 0x55A268C0,
Direction: inbound
SPI : 0xE3E2B0FD
Session ID: 0x09DAD000
VPIF num : 0x00000007
Tunnel type: l2l
Protocol : esp
Lifetime : 240 seconds
IKEv2-PLAT-2: Received PFKEY SPI callback for SPI 0xE3E2B0FD, error FALSE
IKEv2-PLAT-2:
IKEv2 received all requested SPIs from CTM to respond to a tunnel request.
IKEv2-PROTO-5: (59): SM Trace-> SA: I_SPI=145521242B6265D7 R_SPI=0C25D68E92BFCDC2 (R) MsgID = 00000002 CurState: CHILD_R_IPSEC Event: EV_OK_RECD_IPSEC_RESP
IKEv2-PROTO-5: (59): Action: Action_Null
IKEv2-PROTO-5: (59): SM Trace-> SA: I_SPI=145521242B6265D7 R_SPI=0C25D68E92BFCDC2 (R) MsgID = 00000002 CurState: CHILD_R_IPSEC Event: EV_PROC_MSG
IKEv2-PROTO-2: (59): Processing CREATE_CHILD_SA exchange
IKEv2-PROTO-1: (59): The peer's KE payload contained the wrong DH group
IKEv2-PROTO-1: (59):
IKEv2-PROTO-5: (59): SM Trace-> SA: I_SPI=145521242B6265D7 R_SPI=0C25D68E92BFCDC2 (R) MsgID = 00000002 CurState: CHILD_R_IPSEC Event: EV_INV_KE
IKEv2-PROTO-2: (59): Sending invalid ke notification, peer sent group 19, local policy prefers group 0
IKEv2-PROTO-5: Construct Notify Payload: INVALID_KE_PAYLOADIKEv2-PROTO-2: (59): Building packet for encryption.
(59):
Payload contents:
(59): NOTIFY(INVALID_KE_PAYLOAD)(59): Next payload: NONE, reserved: 0x0, length: 10
(59): Security protocol id: ESP, spi size: 0, type: INVALID_KE_PAYLOAD
(59):
(59): 00 00
IKEv2-PROTO-5: (59): SM Trace-> SA: I_SPI=145521242B6265D7 R_SPI=0C25D68E92BFCDC2 (R) MsgID = 00000002 CurState: CHILD_R_IPSEC Event: EV_ENCRYPT_MSG
IKEv2-PROTO-2: (59):
IKEv2-PROTO-5: (59): SM Trace-> SA: I_SPI=145521242B6265D7 R_SPI=0C25D68E92BFCDC2 (R) MsgID = 00000002 CurState: CHILD_R_IPSEC Event: EV_NO_EVENT
IKEv2-PLAT-2: (59): Encrypt success status returned via ipc 1
IKEv2-PROTO-5: (59): SM Trace-> SA: I_SPI=145521242B6265D7 R_SPI=0C25D68E92BFCDC2 (R) MsgID = 00000002 CurState: CHILD_R_IPSEC Event: EV_OK_ENCRYPT_RESP
IKEv2-PROTO-5: (59): Action: Action_Null
IKEv2-PROTO-5: (59): SM Trace-> SA: I_SPI=145521242B6265D7 R_SPI=0C25D68E92BFCDC2 (R) MsgID = 00000002 CurState: CHILD_R_IPSEC Event: EV_TRYSEND
(59):
IKEv2-PROTO-2: (59): Sending Packet [To 51.a.b.c:500/From 80.x.y.z:500/VRF i0:f0]
(59): Initiator SPI : 145521242B6265D7 - Responder SPI : 0C25D68E92BFCDC2 Message id: 2
(59): IKEv2 CREATE_CHILD_SA Exchange RESPONSEIKEv2-PROTO-3: (59): Next payload: ENCR, version: 2.0 (59): Exchange type: CREATE_CHILD_SA, flags: RESPONDER MSG-RESPONSE (59): Message id: 2, length: 80(59):
Payload contents:
(59): ENCR(59): Next payload: NOTIFY, reserved: 0x0, length: 52
(59): Encrypted data: 48 bytes
(59):
IKEv2-PLAT-3: (59): SENT PKT [CREATE_CHILD_SA] [80.x.y.z]:500->[51.a.b.c]:500 InitSPI=0x145521242b6265d7 RespSPI=0x0c25d68e92bfcdc2 MID=00000002
IKEv2-PROTO-5: (59): SM Trace-> SA: I_SPI=145521242B6265D7 R_SPI=0C25D68E92BFCDC2 (R) MsgID = 00000002 CurState: CHILD_R_DONE Event: EV_FAIL
IKEv2-PROTO-1: (59): Create child exchange failed
IKEv2-PROTO-1: (59):
IKEv2-PROTO-2: (59): IPSec SA create failed
IKEv2-PROTO-5: (59): SM Trace-> SA: I_SPI=145521242B6265D7 R_SPI=0C25D68E92BFCDC2 (R) MsgID = 00000002 CurState: EXIT Event: EV_ABORT
IKEv2-PROTO-5: (59): Sent response with message id 2, Requests can be accepted from range 3 to 3
IKEv2-PROTO-5: (59): SM Trace-> SA: I_SPI=145521242B6265D7 R_SPI=0C25D68E92BFCDC2 (R) MsgID = 00000002 CurState: EXIT Event: EV_CHK_PENDING_ABORT
IKEv2-PROTO-5: (59): SM Trace-> SA: I_SPI=145521242B6265D7 R_SPI=0C25D68E92BFCDC2 (R) MsgID = 00000002 CurState: EXIT Event: EV_UPDATE_CAC_STATS
IKEv2-PROTO-2: (59): Abort exchange
IKEv2-PLAT-1: (59): Child SA rekey failure reported for SPI 0x918F75A6.
IKEv2-PROTO-5: (59): Deleting negotiation context for peer message ID: 0x2
IPSEC: Received a PFKey message from IKE
IPSEC DEBUG: Received a DELETE PFKey message from IKE for an inbound SA (SPI 0xE3E2B0FD)
IKEv2-PLAT-1: Failed to remove peer correlation entry from cikePeerCorrTable. Local Type = 0. Local Address = 0.0.0.0. Remote Type = 0. Remote Address = 0.0.0.0. Correlation Peer Index = 0. IPSEC Tunnel Index = 0.
IPSEC DEBUG: Migrated SA is deleted, Deleting the Backup SPI entry 0xE3E2B0FD
IPSEC DEBUG: Inbound SA (SPI 0xE3E2B0FD) destroy started, state embryonic
IPSEC: Destroy current inbound SPI: 0xE3E2B0FD
IPSEC DEBUG: Inbound SA (SPI 0xE3E2B0FD) free started, state embryonic
IPSEC DEBUG: Inbound SA (SPI 0xE3E2B0FD) state change from embryonic to dead
IPSEC DEBUG: Inbound SA (SPI 0xE3E2B0FD) free completed
IPSEC DEBUG: Inbound SA (SPI 0xE3E2B0FD) destroy completed
IKEv2-PLAT-2: Received PFKEY delete SA for SPI 0xE3E2B0FD error FALSE
This is followed by seemingly another peer message ID 0x2:
Sep 19 17:42:26 [IKEv1]IKE Receiver: Packet received on 80.x.y.z:500 from 51.a.b.c:500
IKEv2 Recv RAW packet dump 21 ff 04 38 c0 41 06 57 ec 3f e5 f2 88 36 75 4c | !..8.A.W.?...6uL 2e 20 25 08 00 00 00 03 00 00 00 50 00 00 00 34 | . %........P...4 a6 07 1e 88 af d6 97 c0 d4 3c 29 ee 29 c6 79 fa | .........<).).y. 93 0f bb c4 07 42 04 d4 74 dc 03 1c be 85 11 a1 | .....B..t....... b4 79 55 6c 68 9b 00 82 78 a6 14 b9 0b cd ea eb | .yUlh...x....... IKEv2-PLAT-3: RECV PKT [INFORMATIONAL] [51.a.b.c]:500->[80.x.y.z]:500 InitSPI=0x21ff0438c0410657 RespSPI=0xec3fe5f28836754c MID=00000003 IKEv2-PROTO-5: (99): Request has mess_id 3; expected 3 through 3
(99): IKEv2-PROTO-2: (99): Received Packet [From 51.a.b.c:500/To
80.x.y.z:500/VRF i0:f0] (99): Initiator SPI : 21FF0438C0410657 - Responder SPI : EC3FE5F28836754C Message id: 3 (99): IKEv2 INFORMATIONAL Exchange REQUESTIKEv2-PROTO-3: (99): Next payload: ENCR, version: 2.0 (99): Exchange type: INFORMATIONAL, flags: INITIATOR (99): Message id: 3, length: 80(99): Payload contents: IKEv2-PROTO-1: decrypt queued(99): (99): Decrypted packet:(99): Data: 80 bytes IKEv2-PROTO-1: Asynchronous request queued IKEv2-PROTO-1: IKEv2-PLAT-2: (99): Decrypt success status returned via ipc 1 (99): REAL Decrypted packet:(99): Data: 0 bytes
IKEv2-PROTO-5: (99): SM Trace-> SA: I_SPI=21FF0438C0410657 R_SPI=EC3FE5F28836754C (R) MsgID = 00000003 CurState: READY Event: EV_RECV_INFO_REQ IKEv2-PROTO-5: (99): Action: Action_Null IKEv2-PROTO-5: (99): SM Trace-> SA: I_SPI=21FF0438C0410657 R_SPI=EC3FE5F28836754C (R) MsgID = 00000003 CurState: INFO_R Event: EV_RECV_INFO_REQ IKEv2-PROTO-2: (99): Received DPD/liveness query IKEv2-PROTO-2: (99): Building packet for encryption. IKEv2-PROTO-2: (99): Sending ACK to informational exchange IKEv2-PROTO-5: (99): SM Trace-> SA: I_SPI=21FF0438C0410657 R_SPI=EC3FE5F28836754C (R) MsgID = 00000003 CurState: INFO_R Event: EV_ENCRYPT_MSG IKEv2-PROTO-2: (99): IKEv2-PROTO-5: (99): SM Trace-> SA: I_SPI=21FF0438C0410657 R_SPI=EC3FE5F28836754C (R) MsgID = 00000003 CurState: INFO_R Event: EV_NO_EVENT IKEv2-PROTO-5: (99): Locked SA.Event EV_FREE_NEG queued in the state EXIT IKEv2-PLAT-2: (99): Encrypt success status returned via ipc 1 IKEv2-PROTO-5: (99): SM Trace-> SA: I_SPI=21FF0438C0410657 R_SPI=EC3FE5F28836754C (R) MsgID = 00000003 CurState: INFO_R Event: EV_OK_ENCRYPT_RESP IKEv2-PROTO-5: (99): Action: Action_Null IKEv2-PROTO-5: (99): SM Trace-> SA: I_SPI=21FF0438C0410657 R_SPI=EC3FE5F28836754C (R) MsgID = 00000003 CurState: INFO_R Event: EV_TRYSEND (99): IKEv2-PROTO-2: (99): Sending Packet [To
51.a.b.c:500/From 80.x.y.z:500/VRF i0:f0] (99): Initiator SPI : 21FF0438C0410657 - Responder SPI : EC3FE5F28836754C Message id: 3 (99): IKEv2 INFORMATIONAL Exchange RESPONSEIKEv2-PROTO-3: (99): Next payload: ENCR, version: 2.0 (99): Exchange type: INFORMATIONAL, flags: RESPONDER MSG-RESPONSE (99): Message id: 3, length: 80(99): Payload contents: (99): ENCR(99): Next payload: NONE, reserved: 0x0, length: 52 (99): Encrypted data: 48 bytes (99): IKEv2-PLAT-3: (99): SENT PKT [INFORMATIONAL] [80.x.y.z]:500->[51.a.b.c]:500 InitSPI=0x21ff0438c0410657 RespSPI=0xec3fe5f28836754c MID=00000003 IKEv2-PROTO-5: (99): SM Trace-> SA: I_SPI=21FF0438C0410657 R_SPI=EC3FE5F28836754C (R) MsgID = 00000003 CurState: INFO_R Event: EV_CHK_INFO_TYPE IKEv2-PROTO-5: (99): SM Trace-> SA: I_SPI=21FF0438C0410657 R_SPI=EC3FE5F28836754C (R) MsgID = 00000003 CurState: INFO_R Event: EV_START_DEL_NEG_TMR IKEv2-PROTO-5: (99): Action: Action_Null IKEv2-PROTO-5: (99): SM Trace-> SA: I_SPI=21FF0438C0410657 R_SPI=EC3FE5F28836754C (R) MsgID = 00000003 CurState: EXIT Event: EV_CHK_PENDING IKEv2-PROTO-5: (99): Sent response with message id 3, Requests can be accepted from range 4 to 4 IKEv2-PROTO-5: (99): SM Trace-> SA: I_SPI=21FF0438C0410657 R_SPI=EC3FE5F28836754C (R) MsgID = 00000003 CurState: EXIT Event: EV_NO_EVENT IKEv2-PROTO-5: (99): SM Trace-> SA: I_SPI=21FF0438C0410657 R_SPI=EC3FE5F28836754C (R) MsgID = 00000002 CurState: EXIT Event: EV_FREE_NEG IKEv2-PROTO-5: (99): Deleting negotiation context for peer message ID: 0x2
Afterwards, the following peer message IDs are all similar:
Sep 19 17:42:28 [IKEv1]IKE Receiver: Packet received on 80.x.y.z:500 from 51.a.b.c:500
IKEv2 Recv RAW packet dump
21 ff 04 38 c0 41 06 57 ec 3f e5 f2 88 36 75 4c | !..8.A.W.?...6uL
2e 20 25 08 00 00 00 04 00 00 00 50 00 00 00 34 | . %........P...4
09 7a 1a df 16 98 ed 80 68 8c eb 6f d3 13 a4 2c | .z......h..o...,
16 60 0d 69 0d c6 56 a8 2a 0c 53 a0 eb 7a 86 d8 | .`.i..V.*.S..z..
38 ea 11 7a 3c 57 4c d9 98 8a 96 e2 be b0 c5 db | 8..z<WL.........
IKEv2-PLAT-3: RECV PKT [INFORMATIONAL] [51.a.b.c]:500->[80.x.y.z]:500 InitSPI=0x21ff0438c0410657 RespSPI=0xec3fe5f28836754c MID=00000004
IKEv2-PROTO-5: (99): Request has mess_id 4; expected 4 through 4
(99):
IKEv2-PROTO-2: (99): Received Packet [From 51.a.b.c:500/To 80.x.y.z:500/VRF i0:f0]
(99): Initiator SPI : 21FF0438C0410657 - Responder SPI : EC3FE5F28836754C Message id: 4
(99): IKEv2 INFORMATIONAL Exchange REQUESTIKEv2-PROTO-3: (99): Next payload: ENCR, version: 2.0 (99): Exchange type: INFORMATIONAL, flags: INITIATOR (99): Message id: 4, length: 80(99):
Payload contents:
IKEv2-PROTO-1: decrypt queued(99):
(99): Decrypted packet:(99): Data: 80 bytes
IKEv2-PROTO-1: Asynchronous request queued
IKEv2-PROTO-1:
IKEv2-PLAT-2: (99): Decrypt success status returned via ipc 1
(99): REAL Decrypted packet:(99): Data: 0 bytes
IKEv2-PROTO-5: (99): SM Trace-> SA: I_SPI=21FF0438C0410657 R_SPI=EC3FE5F28836754C (R) MsgID = 00000004 CurState: READY Event: EV_RECV_INFO_REQ
IKEv2-PROTO-5: (99): Action: Action_Null
IKEv2-PROTO-5: (99): SM Trace-> SA: I_SPI=21FF0438C0410657 R_SPI=EC3FE5F28836754C (R) MsgID = 00000004 CurState: INFO_R Event: EV_RECV_INFO_REQ
IKEv2-PROTO-2: (99): Received DPD/liveness query
IKEv2-PROTO-2: (99): Building packet for encryption.
IKEv2-PROTO-2: (99): Sending ACK to informational exchange
IKEv2-PROTO-5: (99): SM Trace-> SA: I_SPI=21FF0438C0410657 R_SPI=EC3FE5F28836754C (R) MsgID = 00000004 CurState: INFO_R Event: EV_ENCRYPT_MSG
IKEv2-PROTO-2: (99):
IKEv2-PROTO-5: (99): SM Trace-> SA: I_SPI=21FF0438C0410657 R_SPI=EC3FE5F28836754C (R) MsgID = 00000004 CurState: INFO_R Event: EV_NO_EVENT
IKEv2-PROTO-5: (99): Locked SA.Event EV_FREE_NEG queued in the state EXIT
IKEv2-PLAT-2: (99): Encrypt success status returned via ipc 1
IKEv2-PROTO-5: (99): SM Trace-> SA: I_SPI=21FF0438C0410657 R_SPI=EC3FE5F28836754C (R) MsgID = 00000004 CurState: INFO_R Event: EV_OK_ENCRYPT_RESP
IKEv2-PROTO-5: (99): Action: Action_Null
IKEv2-PROTO-5: (99): SM Trace-> SA: I_SPI=21FF0438C0410657 R_SPI=EC3FE5F28836754C (R) MsgID = 00000004 CurState: INFO_R Event: EV_TRYSEND
(99):
IKEv2-PROTO-2: (99): Sending Packet [To 51.a.b.c:500/From 80.x.y.z:500/VRF i0:f0]
(99): Initiator SPI : 21FF0438C0410657 - Responder SPI : EC3FE5F28836754C Message id: 4
(99): IKEv2 INFORMATIONAL Exchange RESPONSEIKEv2-PROTO-3: (99): Next payload: ENCR, version: 2.0 (99): Exchange type: INFORMATIONAL, flags: RESPONDER MSG-RESPONSE (99): Message id: 4, length: 80(99):
Payload contents:
(99): ENCR(99): Next payload: NONE, reserved: 0x0, length: 52
(99): Encrypted data: 48 bytes
(99):
IKEv2-PLAT-3: (99): SENT PKT [INFORMATIONAL] [80.x.y.z]:500->[51.a.b.c]:500 InitSPI=0x21ff0438c0410657 RespSPI=0xec3fe5f28836754c MID=00000004
IKEv2-PROTO-5: (99): SM Trace-> SA: I_SPI=21FF0438C0410657 R_SPI=EC3FE5F28836754C (R) MsgID = 00000004 CurState: INFO_R Event: EV_CHK_INFO_TYPE
IKEv2-PROTO-5: (99): SM Trace-> SA: I_SPI=21FF0438C0410657 R_SPI=EC3FE5F28836754C (R) MsgID = 00000004 CurState: INFO_R Event: EV_START_DEL_NEG_TMR
IKEv2-PROTO-5: (99): Action: Action_Null
IKEv2-PROTO-5: (99): SM Trace-> SA: I_SPI=21FF0438C0410657 R_SPI=EC3FE5F28836754C (R) MsgID = 00000004 CurState: EXIT Event: EV_CHK_PENDING
IKEv2-PROTO-5: (99): Sent response with message id 4, Requests can be accepted from range 5 to 5
IKEv2-PROTO-5: (99): SM Trace-> SA: I_SPI=21FF0438C0410657 R_SPI=EC3FE5F28836754C (R) MsgID = 00000004 CurState: EXIT Event: EV_NO_EVENT
IKEv2-PROTO-5: (99): SM Trace-> SA: I_SPI=21FF0438C0410657 R_SPI=EC3FE5F28836754C (R) MsgID = 00000003 CurState: EXIT Event: EV_FREE_NEG
IKEv2-PROTO-5: (99): Deleting negotiation context for peer message ID: 0x3
I think this is an issue with the pfSense…
Here’s a partial debug trace of the pfSense trying to initiate a connection. The tunnel is down, and I try to ping a host in the remote subnet. This brings up phase 1 of the tunnel but not phase 2 (or whatever the IKEv2 terms are.)
IKEv2-PROTO-2: (153): Received Packet [From 1.2.3.4:4500/To 9.8.7.6:500/VRF i0:f0]
(153): Initiator SPI : 8CE2615A4BA17050 - Responder SPI : 3A1657181A5F8FB2 Message id: 1
(153): IKEv2 IKE_AUTH Exchange REQUESTIKEv2-PROTO-3: (153): Next payload: ENCR, version: 2.0 (153): Exchange type: IKE_AUTH, flags: INITIATOR (153): Message id: 1, length: 464(153):
Payload contents:
(153): REAL Decrypted packet:(153): Data: 376 bytes
(153): IDi(153): Next payload: NOTIFY, reserved: 0x0, length: 12
(153): Id type: IPv4 address, Reserved: 0x0 0x0
(153):
(153): b8 45 a9 a2
(153): NOTIFY(INITIAL_CONTACT)(153): Next payload: IDr, reserved: 0x0, length: 8
(153): Security protocol id: Unknown - 0, spi size: 0, type: INITIAL_CONTACT
(153): IDr(153): Next payload: AUTH, reserved: 0x0, length: 12
(153): Id type: IPv4 address, Reserved: 0x0 0x0
(153):
(153): a2 d4 ca 7e
(153): AUTH(153): Next payload: NOTIFY, reserved: 0x0, length: 72
(153): Auth method PSK, reserved: 0x0, reserved 0x0
(153): Auth data: 64 bytes
(153): NOTIFY(ESP_TFC_NO_SUPPORT)(153): Next payload: SA, reserved: 0x0, length: 8
(153): Security protocol id: Unknown - 0, spi size: 0, type: ESP_TFC_NO_SUPPORT
(153): SA(153): Next payload: TSi, reserved: 0x0, length: 156
(153): last proposal: 0x2, reserved: 0x0, length: 40
Proposal: 1, Protocol id: ESP, SPI size: 4, #trans: 3(153): last transform: 0x3, reserved: 0x0: length: 12
type: 1, reserved: 0x0, id: AES-CBC
(153): last transform: 0x3, reserved: 0x0: length: 8
type: 3, reserved: 0x0, id: SHA96
(153): last transform: 0x0, reserved: 0x0: length: 8
type: 5, reserved: 0x0, id: Don't use ESN
(153): last proposal: 0x2, reserved: 0x0, length: 40
Proposal: 2, Protocol id: ESP, SPI size: 4, #trans: 3(153): last transform: 0x3, reserved: 0x0: length: 12
type: 1, reserved: 0x0, id: AES-CBC
(153): last transform: 0x3, reserved: 0x0: length: 8
type: 3, reserved: 0x0, id: SHA512
(153): last transform: 0x0, reserved: 0x0: length: 8
type: 5, reserved: 0x0, id: Don't use ESN
(153): last proposal: 0x2, reserved: 0x0, length: 36
Proposal: 3, Protocol id: ESP, SPI size: 4, #trans: 3(153): last transform: 0x3, reserved: 0x0: length: 8
type: 1, reserved: 0x0, id: 3DES
(153): last transform: 0x3, reserved: 0x0: length: 8
type: 3, reserved: 0x0, id: SHA96
(153): last transform: 0x0, reserved: 0x0: length: 8
type: 5, reserved: 0x0, id: Don't use ESN
(153): last proposal: 0x0, reserved: 0x0, length: 36
Proposal: 4, Protocol id: ESP, SPI size: 4, #trans: 3(153): last transform: 0x3, reserved: 0x0: length: 8
type: 1, reserved: 0x0, id: 3DES
(153): last transform: 0x3, reserved: 0x0: length: 8
type: 3, reserved: 0x0, id: SHA512
(153): last transform: 0x0, reserved: 0x0: length: 8
type: 5, reserved: 0x0, id: Don't use ESN
(153): TSi(153): Next payload: TSr, reserved: 0x0, length: 40
(153): Num of TSs: 2, reserved 0x0, reserved 0x0
(153): TS type: TS_IPV4_ADDR_RANGE, proto id: 0, length: 16
(153): start port: 0, end port: 65535
(153): start addr: 1.2.3.4, end addr: 1.2.3.4
(153): TS type: TS_IPV4_ADDR_RANGE, proto id: 0, length: 16
(153): start port: 0, end port: 65535
(153): start addr: 192.168.244.0, end addr: 192.168.244.255
(153): TSr(153): Next payload: NOTIFY, reserved: 0x0, length: 40
(153): Num of TSs: 2, reserved 0x0, reserved 0x0
(153): TS type: TS_IPV4_ADDR_RANGE, proto id: 0, length: 16
(153): start port: 0, end port: 65535
(153): start addr: 9.8.7.6, end addr: 9.8.7.6
(153): TS type: TS_IPV4_ADDR_RANGE, proto id: 0, length: 16
(153): start port: 0, end port: 65535
(153): start addr: 192.168.242.0, end addr: 192.168.242.255
(153): NOTIFY(Unknown - 16396)(153): Next payload: NOTIFY, reserved: 0x0, length: 8
(153): Security protocol id: Unknown - 0, spi size: 0, type: Unknown - 0
(153): NOTIFY(Unknown - 16397)(153): Next payload: NOTIFY, reserved: 0x0, length: 12
(153): Security protocol id: Unknown - 0, spi size: 0, type: Unknown - 0
(153):
(153): c0 a8 f4 01
(153): NOTIFY(Unknown - 16417)(153): Next payload: NONE, reserved: 0x0, length: 8
(153): Security protocol id: Unknown - 0, spi size: 0, type: Unknown - 0
(153):
(153): Decrypted packet:(153): Data: 464 bytes
Note the public IP addresses are included in the ‘TS_IPV4_ADDR_RANGE’ section. The resulting failure looks like this:
IKEv2-PROTO-1: (153): Failed to find a matching policy
IKEv2-PROTO-1: (153): Received Policies:
IKEv2-PROTO-1: (153): Failed to find a matching policy
IKEv2-PROTO-1: (153): Expected Policies:
IKEv2-PROTO-5: (153): Failed to verify the proposed policies
IKEv2-PROTO-1: (153): Failed to find a matching policy
Here is what happens, moments later, when I manually start the tunnel from the IPSec status page:
IKEv2-PROTO-2: (154): Received Packet [From 1.2.3.4:4500/To 9.8.7.6:500/VRF i0:f0]
(154): Initiator SPI : A1D8249CBDC4008D - Responder SPI : 8E4623ACA44823B8 Message id: 1
(154): IKEv2 IKE_AUTH Exchange REQUESTIKEv2-PROTO-3: (154): Next payload: ENCR, version: 2.0 (154): Exchange type: IKE_AUTH, flags: INITIATOR (154): Message id: 1, length: 432(154):
Payload contents:
(154): REAL Decrypted packet:(154): Data: 344 bytes
(154): IDi(154): Next payload: NOTIFY, reserved: 0x0, length: 12
(154): Id type: IPv4 address, Reserved: 0x0 0x0
(154):
(154): b8 45 a9 a2
(154): NOTIFY(INITIAL_CONTACT)(154): Next payload: IDr, reserved: 0x0, length: 8
(154): Security protocol id: Unknown - 0, spi size: 0, type: INITIAL_CONTACT
(154): IDr(154): Next payload: AUTH, reserved: 0x0, length: 12
(154): Id type: IPv4 address, Reserved: 0x0 0x0
(154):
(154): a2 d4 ca 7e
(154): AUTH(154): Next payload: NOTIFY, reserved: 0x0, length: 72
(154): Auth method PSK, reserved: 0x0, reserved 0x0
(154): Auth data: 64 bytes
(154): NOTIFY(ESP_TFC_NO_SUPPORT)(154): Next payload: SA, reserved: 0x0, length: 8
(154): Security protocol id: Unknown - 0, spi size: 0, type: ESP_TFC_NO_SUPPORT
(154): SA(154): Next payload: TSi, reserved: 0x0, length: 156
(154): last proposal: 0x2, reserved: 0x0, length: 40
Proposal: 1, Protocol id: ESP, SPI size: 4, #trans: 3(154): last transform: 0x3, reserved: 0x0: length: 12
type: 1, reserved: 0x0, id: AES-CBC
(154): last transform: 0x3, reserved: 0x0: length: 8
type: 3, reserved: 0x0, id: SHA96
(154): last transform: 0x0, reserved: 0x0: length: 8
type: 5, reserved: 0x0, id: Don't use ESN
(154): last proposal: 0x2, reserved: 0x0, length: 40
Proposal: 2, Protocol id: ESP, SPI size: 4, #trans: 3(154): last transform: 0x3, reserved: 0x0: length: 12
type: 1, reserved: 0x0, id: AES-CBC
(154): last transform: 0x3, reserved: 0x0: length: 8
type: 3, reserved: 0x0, id: SHA512
(154): last transform: 0x0, reserved: 0x0: length: 8
type: 5, reserved: 0x0, id: Don't use ESN
(154): last proposal: 0x2, reserved: 0x0, length: 36
Proposal: 3, Protocol id: ESP, SPI size: 4, #trans: 3(154): last transform: 0x3, reserved: 0x0: length: 8
type: 1, reserved: 0x0, id: 3DES
(154): last transform: 0x3, reserved: 0x0: length: 8
type: 3, reserved: 0x0, id: SHA96
(154): last transform: 0x0, reserved: 0x0: length: 8
type: 5, reserved: 0x0, id: Don't use ESN
(154): last proposal: 0x0, reserved: 0x0, length: 36
Proposal: 4, Protocol id: ESP, SPI size: 4, #trans: 3(154): last transform: 0x3, reserved: 0x0: length: 8
type: 1, reserved: 0x0, id: 3DES
(154): last transform: 0x3, reserved: 0x0: length: 8
type: 3, reserved: 0x0, id: SHA512
(154): last transform: 0x0, reserved: 0x0: length: 8
type: 5, reserved: 0x0, id: Don't use ESN
(154): TSi(154): Next payload: TSr, reserved: 0x0, length: 24
(154): Num of TSs: 1, reserved 0x0, reserved 0x0
(154): TS type: TS_IPV4_ADDR_RANGE, proto id: 0, length: 16
(154): start port: 0, end port: 65535
(154): start addr: 192.168.244.0, end addr: 192.168.244.255
(154): TSr(154): Next payload: NOTIFY, reserved: 0x0, length: 24
(154): Num of TSs: 1, reserved 0x0, reserved 0x0
(154): TS type: TS_IPV4_ADDR_RANGE, proto id: 0, length: 16
(154): start port: 0, end port: 65535
(154): start addr: 192.168.242.0, end addr: 192.168.242.255
(154): NOTIFY(Unknown - 16396)(154): Next payload: NOTIFY, reserved: 0x0, length: 8
(154): Security protocol id: Unknown - 0, spi size: 0, type: Unknown - 0
(154): NOTIFY(Unknown - 16397)(154): Next payload: NOTIFY, reserved: 0x0, length: 12
(154): Security protocol id: Unknown - 0, spi size: 0, type: Unknown - 0
(154):
(154): c0 a8 f4 01
(154): NOTIFY(Unknown - 16417)(154): Next payload: NONE, reserved: 0x0, length: 8
(154): Security protocol id: Unknown - 0, spi size: 0, type: Unknown - 0
(154):
(154): Decrypted packet:(154): Data: 432 bytes
No public IP addresses included, and this connection succeeds. Thoughts?
EDIT: Here are pfSense logs for these two connection attempts. Aside from the different size of the packets sent, note the line ‘establishing CHILD_SA con1{1}’ in the failed attemps, versus ‘establishing CHILD_SA con1’ in the successful attempt. Does this indicate anything useful?
Dec 18 09:38:59 pf-victoria charon: 16[KNL] creating acquire job for policy 1.2.3.4/32|/0 === 9.8.7.6/32|/0 with reqid {1}
Dec 18 09:38:59 pf-victoria charon: 06[IKE] <con1|28>initiating IKE_SA con1[28] to 9.8.7.6
Dec 18 09:38:59 pf-victoria charon: 06[IKE] initiating IKE_SA con1[28] to 9.8.7.6
Dec 18 09:38:59 pf-victoria charon: 06[ENC] generating IKE_SA_INIT request 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) N(FRAG_SUP) ]
Dec 18 09:38:59 pf-victoria charon: 06[NET] sending packet: from 1.2.3.4[500] to 9.8.7.6[500] (440 bytes)
Dec 18 09:38:59 pf-victoria charon: 06[NET] received packet: from 9.8.7.6[500] to 1.2.3.4[500] (585 bytes)
Dec 18 09:38:59 pf-victoria charon: 06[ENC] parsed IKE_SA_INIT response 0 [ SA KE No V V V N(NATD_S_IP) N(NATD_D_IP) V ]
Dec 18 09:38:59 pf-victoria charon: 06[IKE] <con1|28>received Cisco Delete Reason vendor ID
Dec 18 09:38:59 pf-victoria charon: 06[IKE] received Cisco Delete Reason vendor ID
Dec 18 09:38:59 pf-victoria charon: 06[IKE] <con1|28>received Cisco Copyright (c) 2009 vendor ID
Dec 18 09:38:59 pf-victoria charon: 06[IKE] received Cisco Copyright (c) 2009 vendor ID
Dec 18 09:38:59 pf-victoria charon: 06[ENC] received unknown vendor ID: 43:49:53:43:4f:2d:47:52:45:2d:4d:4f:44:45:02
Dec 18 09:38:59 pf-victoria charon: 06[IKE] <con1|28>received FRAGMENTATION vendor ID
Dec 18 09:38:59 pf-victoria charon: 06[IKE] received FRAGMENTATION vendor ID
Dec 18 09:38:59 pf-victoria charon: 06[IKE] <con1|28>authentication of '1.2.3.4' (myself) with pre-shared key
Dec 18 09:38:59 pf-victoria charon: 06[IKE] authentication of '1.2.3.4' (myself) with pre-shared key
Dec 18 09:38:59 pf-victoria charon: 06[IKE] <con1|28>establishing CHILD_SA con1{1}
Dec 18 09:38:59 pf-victoria charon: 06[IKE] establishing CHILD_SA con1{1}
Dec 18 09:38:59 pf-victoria charon: 06[ENC] generating IKE_AUTH request 1 [ IDi N(INIT_CONTACT) IDr AUTH N(ESP_TFC_PAD_N) SA TSi TSr N(MOBIKE_SUP) N(ADD_4_ADDR) N(EAP_ONLY) ]
Dec 18 09:38:59 pf-victoria charon: 06[NET] sending packet: from 1.2.3.4[4500] to 9.8.7.6[4500] (464 bytes)
Dec 18 09:38:59 pf-victoria charon: 06[NET] received packet: from 9.8.7.6[4500] to 1.2.3.4[4500] (208 bytes)
Dec 18 09:38:59 pf-victoria charon: 06[ENC] parsed IKE_AUTH response 1 [ V IDr AUTH N(NO_PROP) ]
Dec 18 09:38:59 pf-victoria charon: 06[IKE] <con1|28>authentication of '9.8.7.6' with pre-shared key successful
Dec 18 09:38:59 pf-victoria charon: 06[IKE] authentication of '9.8.7.6' with pre-shared key successful
Dec 18 09:38:59 pf-victoria charon: 06[IKE] <con1|28>IKE_SA con1[28] established between 1.2.3.4[1.2.3.4]...9.8.7.6[9.8.7.6]
Dec 18 09:38:59 pf-victoria charon: 06[IKE] IKE_SA con1[28] established between 1.2.3.4[1.2.3.4]...9.8.7.6[9.8.7.6]
Dec 18 09:38:59 pf-victoria charon: 06[IKE] <con1|28>scheduling reauthentication in 27865s
Dec 18 09:38:59 pf-victoria charon: 06[IKE] scheduling reauthentication in 27865s
Dec 18 09:38:59 pf-victoria charon: 06[IKE] <con1|28>maximum IKE_SA lifetime 28405s
Dec 18 09:38:59 pf-victoria charon: 06[IKE] maximum IKE_SA lifetime 28405s
Dec 18 09:38:59 pf-victoria charon: 06[IKE] <con1|28>received NO_PROPOSAL_CHOSEN notify, no CHILD_SA built
Dec 18 09:38:59 pf-victoria charon: 06[IKE] received NO_PROPOSAL_CHOSEN notify, no CHILD_SA built
Dec 18 09:38:59 pf-victoria charon: 06[IKE] <con1|28>failed to establish CHILD_SA, keeping IKE_SA
Dec 18 09:38:59 pf-victoria charon: 06[IKE] failed to establish CHILD_SA, keeping IKE_SA
Dec 18 09:39:34 pf-victoria charon: 16[CFG] received stroke: initiate 'con1'
Dec 18 09:39:34 pf-victoria charon: 09[IKE] <con1|29>initiating IKE_SA con1[29] to 9.8.7.6
Dec 18 09:39:34 pf-victoria charon: 09[IKE] initiating IKE_SA con1[29] to 9.8.7.6
Dec 18 09:39:34 pf-victoria charon: 09[ENC] generating IKE_SA_INIT request 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) N(FRAG_SUP) ]
Dec 18 09:39:34 pf-victoria charon: 09[NET] sending packet: from 1.2.3.4[500] to 9.8.7.6[500] (440 bytes)
Dec 18 09:39:34 pf-victoria charon: 09[NET] received packet: from 9.8.7.6[500] to 1.2.3.4[500] (585 bytes)
Dec 18 09:39:34 pf-victoria charon: 09[ENC] parsed IKE_SA_INIT response 0 [ SA KE No V V V N(NATD_S_IP) N(NATD_D_IP) V ]
Dec 18 09:39:34 pf-victoria charon: 09[IKE] <con1|29>received Cisco Delete Reason vendor ID
Dec 18 09:39:34 pf-victoria charon: 09[IKE] received Cisco Delete Reason vendor ID
Dec 18 09:39:34 pf-victoria charon: 09[IKE] <con1|29>received Cisco Copyright (c) 2009 vendor ID
Dec 18 09:39:34 pf-victoria charon: 09[IKE] received Cisco Copyright (c) 2009 vendor ID
Dec 18 09:39:34 pf-victoria charon: 09[ENC] received unknown vendor ID: 43:49:53:43:4f:2d:47:52:45:2d:4d:4f:44:45:02
Dec 18 09:39:34 pf-victoria charon: 09[IKE] <con1|29>received FRAGMENTATION vendor ID
Dec 18 09:39:34 pf-victoria charon: 09[IKE] received FRAGMENTATION vendor ID
Dec 18 09:39:34 pf-victoria charon: 09[IKE] <con1|29>authentication of '1.2.3.4' (myself) with pre-shared key
Dec 18 09:39:34 pf-victoria charon: 09[IKE] authentication of '1.2.3.4' (myself) with pre-shared key
Dec 18 09:39:34 pf-victoria charon: 09[IKE] <con1|29>establishing CHILD_SA con1
Dec 18 09:39:34 pf-victoria charon: 09[IKE] establishing CHILD_SA con1
Dec 18 09:39:34 pf-victoria charon: 09[ENC] generating IKE_AUTH request 1 [ IDi N(INIT_CONTACT) IDr AUTH N(ESP_TFC_PAD_N) SA TSi TSr N(MOBIKE_SUP) N(ADD_4_ADDR) N(EAP_ONLY) ]
Dec 18 09:39:34 pf-victoria charon: 09[NET] sending packet: from 1.2.3.4[4500] to 9.8.7.6[4500] (432 bytes)
Dec 18 09:39:34 pf-victoria charon: 09[NET] received packet: from 9.8.7.6[4500] to 1.2.3.4[4500] (304 bytes)
Dec 18 09:39:34 pf-victoria charon: 09[ENC] parsed IKE_AUTH response 1 [ V IDr AUTH SA TSi TSr N(ESP_TFC_PAD_N) N(NON_FIRST_FRAG) ]
Dec 18 09:39:34 pf-victoria charon: 09[IKE] <con1|29>authentication of '9.8.7.6' with pre-shared key successful
Dec 18 09:39:34 pf-victoria charon: 09[IKE] authentication of '9.8.7.6' with pre-shared key successful
Dec 18 09:39:34 pf-victoria charon: 09[IKE] <con1|29>IKE_SA con1[29] established between 1.2.3.4[1.2.3.4]...9.8.7.6[9.8.7.6]
Dec 18 09:39:34 pf-victoria charon: 09[IKE] IKE_SA con1[29] established between 1.2.3.4[1.2.3.4]...9.8.7.6[9.8.7.6]
Dec 18 09:39:34 pf-victoria charon: 09[IKE] <con1|29>scheduling reauthentication in 28245s
Dec 18 09:39:34 pf-victoria charon: 09[IKE] scheduling reauthentication in 28245s
Dec 18 09:39:34 pf-victoria charon: 09[IKE] <con1|29>maximum IKE_SA lifetime 28785s
Dec 18 09:39:34 pf-victoria charon: 09[IKE] maximum IKE_SA lifetime 28785s
Dec 18 09:39:34 pf-victoria charon: 09[IKE] <con1|29>received ESP_TFC_PADDING_NOT_SUPPORTED, not using ESPv3 TFC padding
Dec 18 09:39:34 pf-victoria charon: 09[IKE] received ESP_TFC_PADDING_NOT_SUPPORTED, not using ESPv3 TFC padding
Dec 18 09:39:34 pf-victoria charon: 09[IKE] <con1|29>CHILD_SA con1{1} established with SPIs c02da961_i c6c0ab47_o and TS 192.168.244.0/24|/0 === 192.168.242.0/24|/0
Dec 18 09:39:34 pf-victoria charon: 09[IKE] CHILD_SA con1{1} established with SPIs c02da961_i c6c0ab47_o and TS 192.168.244.0/24|/0 === 192.168.242.0/24|/0</con1|29></con1|29></con1|29></con1|29></con1|29></con1|29></con1|29></con1|29></con1|29></con1|29></con1|29></con1|29></con1|28></con1|28></con1|28></con1|28></con1|28></con1|28></con1|28></con1|28></con1|28></con1|28></con1|28></con1|28>
Sometimes while I install the site-to-site IPsec between VPN boxes, I’m getting some error that everyone generally come upon. I wanna write these errors. I hope this post is useful for new beginners.
I will examine the error messages according to the topology below.
ERROR-1:
Routing failed to locate next hop for udp from NP Identity Ifc:188.18.17.1/62465 to mpls:3.3.3.1/62465
IKEv1 was unsuccessful at setting up a tunnel. Map Tag = mpls_map. Map Sequence Number = 2
ERROR-2:
Tunnel Manager has failed to establish an L2L SA. All configured IKE versions failed to establish the tunnel. Map Tag= mpls_map. Map Sequence Number = 2.
IKEv1 was unsuccessful at setting up a tunnel. Map Tag = mpls_map. Map Sequence Number = 2.
THE SOLUTION OF ERROR-1,2:
These errors say that there is a big wrong in our configuration. This is a reachability problem between VPN boxes. if we have two exits points. Related routes might not be written to the correct point in our VPN boxes. Sometimes we are typing the wrong subnet mask. For my example; Now I’m writing route to the correct point. If the route is not written to the correct point, the IPsec tunnel will be tried to install over the internet interface because of the default route. For this is not to happen, we have to write the route to Mpls interface on both devices so they can access each other.
Add the IP address of the Fortinet to ASA’s routing table.
Or add the IP address of the ASA to Fortinet’s routing table.
Here is the result;
Group = 3.3.3.1, IP = 3.3.3.1, PHASE 1 COMPLETED
Tunnel Manager dispatching a KEY_ACQUIRE message to IKEv1. Map Tag = mpls_map. Map Sequence Number = 2.
Group = 3.3.3.1, IP = 3.3.3.1, IKE Initiator: New Phase 2, Intf mpls, IKE Peer 3.3.3.1 local Proxy Address 20.20.20.0, remote Proxy Address 192.168.60.0, Crypto map (mpls_map)
Group = 3.3.3.1, IP = 3.3.3.1, Security negotiation complete for LAN-to-LAN Group (3.3.3.1) Responder, Inbound SPI = 0xaa2c7b53, Outbound SPI = 0x67ee5d0a
IPSEC: An outbound LAN-to-LAN SA (SPI= 0x67EE5D0A) between 188.18.17.1 and 3.3.3.1 (user= 3.3.3.1) has been created.
IPSEC: An inbound LAN-to-LAN SA (SPI= 0xAA2C7B53) between 188.18.17.1 and 3.3.3.1 (user= 3.3.3.1) has been created.
Group = 3.3.3.1, IP = 3.3.3.1, PHASE 2 COMPLETED (msgid=22e90ccb)
IKEv1 was successful at setting up a tunnel. Map Tag = mpls_map. Map Sequence Number = 2.
ERROR-3:
Phase 1 failure: Mismatched attribute types for class Group Description: Rcv'd: Group 5 Cfg'd: Group 2
Group = 3.3.3.1, IP = 3.3.3.1, Duplicate Phase 1 packet detected. Retransmitting last packet.
IKEv1 was unsuccessful at setting up a tunnel. Map Tag = mpls_map. Map Sequence Number = 2.
THE SOLUTION OF ERROR-3:
İf you are getting the error that is a mismatched attribute in PHASE 1. You first have to check the ike pre-share key. The pre-shared key may not be matched on both sides.
ERROR-4;
IP = 3.3.3.1, Error processing payload: Payload ID: 1
IKEv1 was unsuccessful at setting up a tunnel. Map Tag = mpls_map. Map Sequence Number = 2.
THE SOLUTION OF ERROR-4:
A packet has been received with a payload that cannot be processed. Generally, This error comes up when the IKE policy does not match on both peers. So this is related to PHASE-1. We must fix policies on both sides.
Cisco ASA side;
Fortigate Fw side;
ERROR-5:
Group = 3.3.3.1, IP = 3.3.3.1, IKE Initiator: New Phase 2, Intf mpls, IKE Peer 3.3.3.1 local Proxy Address 20.20.20.0, remote Proxy Address 192.168.60.0, Crypto map (mpls_map)
Group = 3.3.3.1, IP = 3.3.3.1, Received non-routine Notify message: No proposal chosen (14)
Group = 3.3.3.1, IP = 3.3.3.1, QM FSM error (P2 struct &0x00007fffce4c3170, mess id 0x92bb8655)!
IKEv1 was unsuccessful at setting up a tunnel. Map Tag = mpls_map. Map Sequence Number = 2.
Group = 3.3.3.1, IP = 3.3.3.1, PHASE 1 COMPLETED
THE SOLUTION OF ERROR-5;
The keywords are for us; Received non-routine Notify message: No proposal chosen. The error says where is wrong in our configuration. This error is in phase-2 because phase-1 is completed. The meaning of No proposal may be related IPSEC encryption list.
Cisco ASA side;
Fortinet FW side;
If you set the proper encryption algorithm in both VPN boxes. The problem will be solved.
ERROR-6:
Group = 3.3.3.1, IP = 3.3.3.1, Received non-routine Notify message: No proposal chosen (14)
Group = 3.3.3.1, IP = 3.3.3.1, QM FSM error (P2 struct &0x00007fffce4d4ac0, mess id 0xf37ec058)!
Group = 3.3.3.1, IP = 3.3.3.1, PHASE 1 COMPLETED
THE SOLUTION OF ERROR-6;
This error is almost the same as Error-5. Phase-1 is completed but Phase-2 is not completed. The PFS is enabled on Fortinet Fw but is disabled on Cisco ASA. I have to change as to enable on Cisco.
ERROR-7:
Group = 3.3.3.1, IP = 3.3.3.1, QM FSM error (P2 struct &0x00007fffcda24c00, mess id 0x3be33942)!
Group = 3.3.3.1, IP = 3.3.3.1, Removing peer from correlator table failed, no match!
IKEv1 was unsuccessful at setting up a tunnel. Map Tag = mpls_map. Map Sequence Number = 2.
Group = 3.3.3.1, IP = 3.3.3.1, PHASE 1 COMPLETED
THE SOLUTION OF ERROR-7;
There is no proposal like in error-5,6. This error is related to phase-2. You have to check the ISAKMP and crypto map configuration on both peers. My problem is the wrong local subnet on Fortinet Fw In my configuration.
ERROR-8:
Local:188.18.17.1:500 Remote:3.3.3.1:500 Username:Unknown IKEv2 Received a IKE_INIT_SA request
Local:188.18.17.1:500 Remote:3.3.3.1:500 Username:Unknown IKEv2 Negotiation aborted due to ERROR: Failed to find a matching policy
THE SOLUTION OF ERROR-8:
If we get this error. There is a conflict in IKE versions. We have to set the same IKE version.
ERROR-9:
3Jun 30 202109:03:39713061Group = 3.3.3.1, IP = 3.3.3.1, Rejecting IPSec tunnel: no matching crypto map entry for remote proxy 192.168.60.0/255.255.255.0/0/0 local proxy 0.0.0.0/0.0.0.0/0/0 on interface mpls
THE SOLUTION OF ERROR-9:
You know, the policies should be the same on both sides. When I look at the Fortigate side, I see that the remote network is marked as all. The only required network should be marked on both sides.
Fortinet;
The remote address should be changed with 20.20.20.0/24
Asa;
I hope that will be useful.
Thanks for Reading
Cisco introduced VTI to ASA Firewalls in version 9.7.1 as an alternative to policy based crypto maps. Cisco IOS routers have long supported VTI (sVTI, DVTI, DMVPN, FlexVPN etc). This post will describe the steps on how to configure a VTI between a Cisco ASA Firewall and a Cisco IOS Router.
Hardware/Software used:
Cisco ASAv (v9.9.1)
Cisco CSR1000v (v16.3.3)
ASA Configuration
Specify an IKEv2 Policy; define the encryption/integrity/PRF algorithms, DH group and SA lifetime
crypto ikev2 policy 5
encryption aes-256
integrity sha512 sha384
group 19 14
prf sha512 sha384
lifetime seconds 86400
Enable IKEv2 on the outside interface
crypto ikev2 enable OUTSIDE
Create an IPSec Transform Set, define the encryption and integrity (hashing) algorithms
crypto ipsec ikev2 ipsec-proposal TSET
protocol esp encryption aes-256 aes-192
protocol esp integrity sha-512 sha-384 sha-256
Create an IPSec Profile, reference the previously created IPSec Transform Set
crypto ipsec profile IPSEC_PROFILE
set ikev2 ipsec-proposal TSET
Create a Group Policy and ensure IKEv2 is selected an allowed protocol (IKEv2)
group-policy 2.2.2.1 internal
group-policy 2.2.2.1 attributes
vpn-tunnel-protocol ikev2
Create a Tunnel Group
Ensure the Tunnel Group matches the IP address of the Peer device, reference the Group Policy previously created and specify the IKEv2 pre-shared keys (local and remote).
tunnel-group 2.2.2.1 type ipsec-l2l
tunnel-group 2.2.2.1 general-attributes
default-group-policy 2.2.2.1
tunnel-group 2.2.2.1 ipsec-attributes
ikev2 remote-authentication pre-shared-key Cisco1234
ikev2 local-authentication pre-shared-key Cisco1234
Create a Tunnel Interface
Ensure this is named appropriately. It is important to ensure you specify the tunnel mode ipsec ipv4, there is no default value unlike on an IOS router which defaults to GRE for encapsulation (ASA’s do not support GRE). Specify the tunnel source, destination, ip address and reference the ipsec profile previously created.
interface Tunnel0
nameif BRANCH1_VTI
ip address 172.16.2.1 255.255.255.0
tunnel source interface OUTSIDE
tunnel destination 2.2.2.1
tunnel mode ipsec ipv4
tunnel protection ipsec profile IPSEC_PROFILE
Create static routes to the destination LAN
route BRANCH1_VTI 10.10.0.0 255.255.0.0 172.16.2.3
IOS Router
Create an IKEv2 Policy
Define the encryption/integrity/PRF algorithms, DH group and SA lifetime. This must obviously match the IKEv2 policy defined on the ASA.
crypto ikev2 proposal PROP-1
encryption aes-cbc-256
integrity sha512 sha384
group 19 14
Create an IKEv2 Policy and reference the IKEv2 Proposal
crypto ikev2 policy IKEV2_POLICY
proposal PROP-1
Define a IKEv2 Keyring and define the pre-shared key
crypto ikev2 keyring KEYRING
peer ALL
address 0.0.0.0 0.0.0.0
pre-shared-key local Cisco1234
pre-shared-key remote Cisco1234
Create an IKEv2 Profile
Specify the remote identity (IP address) of the ASA, the local identity that will be sent to the ASA (local router’s public IP address), define authentication method and reference the pre-defined IKEv2 Keyring.
crypto ikev2 profile ASA_VTI_PROFILE
match identity remote address 1.1.1.1
identity local address 2.2.2.1
authentication local pre-share
authentication remote pre-share
keyring local KEYRING
dpd 10 2 on-demand
Create an IPSec Transform Set
Define the encryption and integrity (hashing) algorithms. This must obviously match the algorithms defined in the Transform Set on the ASA.
crypto ipsec transform-set TSET esp-aes 256 esp-sha512-hmac
Create an IPSec Profile
Reference the previously created IPSec Transform Set and IKEv2 Profile
crypto ipsec profile IPSEC_PROFILE
set transform-set TSET
set ikev2-profile ASA_VTI_PROFILE
Create a Tunnel Interface
Specify a tunnel IP address, source interface, tunnel mode (must be ipsec ipv4), tunnel destination (ip address of the ASA) and tunnel protection (previously defined ipsec profile).
interface Tunnel1
ip address 172.16.2.3 255.255.255.0
tunnel source GigabitEthernet1
tunnel mode ipsec ipv4
tunnel destination 1.1.1.1
tunnel protection ipsec profile IPSEC_PROFILE
Create a static route to a remote network over the tunnel interface
ip route 192.168.0.0 255.255.0.0 172.16.2.1
Verification
On the ASA, run the command show interface tunnel 0 will display configuration details of the tunnel interface. You can confirm the source interface, source ip address, destination ip address and the tunnel mode. The tunnel mode has to be set to ipsec ipv4, if not the output would display invalid! and the VPN will not work.
show crypto ipsec sa details will as usual confirm 2 IPSec SA’s and confirm encaps/decaps of traffic communicating over the tunnel interface.
On the ASA you can also run the command show vpn-sessiondb detail l2l to obtain more information about the session, such as endpoint IP address, algorithms, duration, bytes tx/rx etc.
Running a ping from a loopback on the router to a subnet behind the ASA with debug icmp trace enable on the ASA will confirm traffic is source over the VTI.
On the router, similar commands exist as the ASA. Running the command show interface tunnel 1 will reveal the tunnel IP address, tunnel source interface/ip address, destination IP address, tunnel protocol, transport and transport protection (ipsec profile) etc.
show crypto ipsec sa will provide the same output as the command run on the ASA (peer ip address, encaps/decaps etc).
|
Страница 1 из 1 | [ Сообщений: 20 ] |
VPN Site2Site в связке cisco ASA 5512 -> Cloud
| Автор | Сообщение |
|---|---|
|
Зарегистрирован: 15 май 2015, 11:52 |
Всем привет! Непонятки в том, нужна ли на циске фаза ikev1 в таком случае? Вложения: Комментарий к файлу: Конфиг myASA
Последний раз редактировалось Krot 15 май 2015, 17:17, всего редактировалось 1 раз. |
| 15 май 2015, 17:02 |
|
|
|
|
crash Зарегистрирован: 10 окт 2012, 09:51 |
и не будет схемы? Какой интерфейс устанавливает соединение? какая именно крипто мапа используется? Считаете здесь телепаты? |
| 15 май 2015, 17:09 |
|
|
|
|
crash Зарегистрирован: 10 окт 2012, 09:51 |
Код: access-list L2LAccessList extended permit ip object 51-network object 50-network хотелось бы узнать 51-network и что это за обжект? Если верить вашему конфигу, то его не существует. |
| 15 май 2015, 17:12 |
|
|
|
|
Krot Зарегистрирован: 15 май 2015, 11:52 |
обжект 51-network есть в наличии, соединение устанавливает «outsidetoISP» криптомапа под названием «myset» |
| 15 май 2015, 17:29 |
|
|
|
|
crash Зарегистрирован: 10 окт 2012, 09:51 |
это что NETWORK_OBJ_192.168.X.0_24? Ну ладно белые закрываете айпи, но серые чего скрывать то? Цитата: nat (51,outsidetoISP) source dynamic any interface можно было бы переписать по другому и правильней было бы. |
| 15 май 2015, 17:36 |
|
|
|
|
crash Зарегистрирован: 10 окт 2012, 09:51 |
вообще интересно, повырезали пол конфига и смотрите, разбирайтесь. |
| 15 май 2015, 17:40 |
|
|
|
|
Krot Зарегистрирован: 15 май 2015, 11:52 |
ASAQuarta/ASAQuarta# $p 192.168.51.222 0 192.168.50.3 det Phase: 1 Phase: 2 Phase: 3 Phase: 4 Phase: 5 Phase: 6 Phase: 7 Phase: 8 Result: ASAQuarta/ASAQuarta# |
| 15 май 2015, 18:08 |
|
|
|
|
crash Зарегистрирован: 10 окт 2012, 09:51 |
с обратной стороны вы уверены, что все настроено правильно? |
| 15 май 2015, 18:13 |
|
|
|
|
aliotru Зарегистрирован: 01 янв 1970, 03:00 |
Зачем гадать, что да как — давайте сюда дебаг подключения вашего туннеля. |
| 15 май 2015, 18:45 |
|
|
|
|
crash Зарегистрирован: 10 окт 2012, 09:51 |
и для полной картины, packet-tracer надо пару раз запустить |
| 15 май 2015, 19:13 |
|
|
|
|
Krot Зарегистрирован: 15 май 2015, 11:52 |
уважаемый Aliatru, уважаемый Crash, PS. |
| 15 май 2015, 22:25 |
|
|
|
|
crash Зарегистрирован: 10 окт 2012, 09:51 |
что именно конкретней? Код: packet-tracer input 51 tcp 192.168.51.222 10000 192.168.50.22 80 и показываете. Можете ее запустить два раза, даже лучше |
| 16 май 2015, 05:18 |
|
|
|
|
Krot Зарегистрирован: 15 май 2015, 11:52 |
дал команду packet-tracer input 51 tcp 192.168.51.222 10000 192.168.50.22 80 detailed. Вложения:
|
| 16 май 2015, 17:08 |
|
|
|
|
Nikolay_ Зарегистрирован: 01 янв 1970, 03:00 |
Возможно, это — Ваша проблема: http://tkurek.blogspot.com/2013/10/type … -drop.html |
| 16 май 2015, 23:09 |
|
|
|
|
Krot Зарегистрирован: 15 май 2015, 11:52 |
Была бы моя если бы ASA по обе стороны канала стояли. http://blogs.technet.com/b/networking/a … 12-r2.aspx Вот еще… 3 May 22 2015 14:42:24 751022 4 May 22 2015 14:52:49 750003 |
| 22 май 2015, 15:17 |
|
|
|
|
aliotru Зарегистрирован: 01 янв 1970, 03:00 |
Вот оно вам в лог и пишет — Krot писал(а): Crypto Map Policy not found for remote traffic Krot писал(а): Соединение по VPN, как видно на ASDM-консоли, поднято, но биты в канале в нуле. С чего вы взяли что туннель поднялся как нужно? что получаете в ответ от команды — sh vpn-sessiondb detail l2l ? Krot писал(а): криптомапа под названием «myset» В вашем конфиге не обнаружено такой криптомапы. а дебаг имелся ввиду debug crypto ipsec, debug ikev1/2 |
| 22 май 2015, 16:11 |
|
|
|
|
Krot Зарегистрирован: 15 май 2015, 11:52 |
ASAQuarta/ASAQuarta# sh vpn-sessiondb detail l2l Session Type: LAN-to-LAN Detailed Connection : 37.230.xxx.xxx IKEv2 Tunnels: 1 IKEv2: ASAQuarta/ASAQuarta# |
| 22 май 2015, 16:22 |
|
|
|
|
CrAlex Зарегистрирован: 27 мар 2012, 21:37 |
Krot писал(а): ASAQuarta/ASAQuarta# sh vpn-sessiondb detail l2l Session Type: LAN-to-LAN Detailed Connection : 37.230.xxx.xxx IKEv2 Tunnels: 1 IKEv2: ASAQuarta/ASAQuarta# Ну первая фаза прошла все хорошо, а вот со второй фазой беда бедовая |
| 22 май 2015, 16:37 |
|
|
|
|
aliotru Зарегистрирован: 01 янв 1970, 03:00 |
Судя по всему мапа используется вот эта — Код: crypto map mymap 10 match address L2LAccessList К ней прицеплен вот этот АКЛ Код: access-list L2LAccessList extended permit ip object 51-network object 50-network и все это сдобрено вот этим nonat Код: nat (51,outsidetoISP) source static NETWORK_OBJ_192.168.X.0_24 NETWORK_OBJ_192.168.X.0_24 destination static NETWORK_OBJ_192.168.X.0_24 NETWORK_OBJ_192.168.X.0_24 no-proxy-arp route-lookup Вы бы хоть рассказали что у вас за объекты такие, что за этими названиями прячется. |
| 22 май 2015, 17:44 |
|
|
|
|
degree Зарегистрирован: 23 янв 2018, 13:19 |
Извините за некропост, но вдруг еще кто-нибудь нагуглит эту тему. У серии ASA проблемы с поднятием туннеля с майкрософтовским VPN, который используется в облаках на основе Hyper-V. В поддержке облака мне так и сказали, что серия ASA не подходит для работы с их VPN site-to-site. Подробности: https://blogs.technet.microsoft.com/net … r-2012-r2/ |
| 23 янв 2018, 13:29 |
|
| Показать сообщения за: Поле сортировки |
VPN Site2Site в связке cisco ASA 5512 -> Cloud
обычно такое бывает когда не совпадают параметры (по крайней мере у меня с разными филиалами несовпадение ACL это самая распространенная ошибка)|
|
Страница 1 из 1 | [ Сообщений: 20 ] |
Кто сейчас на конференции |
|
Сейчас этот форум просматривают: Google [Bot] и гости: 1 |
| Вы не можете начинать темы Вы не можете отвечать на сообщения Вы не можете редактировать свои сообщения Вы не можете удалять свои сообщения Вы не можете добавлять вложения |
