Ipsec policy invalidated proposal with error 256

проще и надёжнее.
гибче и секурнее.
но не всегда можно 🙂

Источник

zeeshannetwork

When investigating phase 2’s issues,looking at IPSEC debug on RESPONDER is a lot more helpful than looking at DEBUG ISAKMP output. For example, if there is mismatch issue with encryption,hashing, tunnel mode, Proxy ID,single ISAKMP NOTIFICATION MESSAGE WITH CODE”PROPOSAL NOT CHOSEN 3″ is sent. By looking at this message, we can not tell what caused this: Is it PROXY ID? ENCRYPTION TYPE? So it is a lot better to look at DEBUG CRYPTO IPSEC on RESPONDER when investigating PHASE2 ‘s issue.

For a successful phase2 ‘s negotiation following must be true:

1. Matching encryption, hashing, DH
2. Matching tunnel mode
3. Proxy ID ( ACL) on RESPONDER/INITIATOR SHOULD MIRROR EACH OTHER( It is possible to have successful PHASE2 negotiation even when PROXY ID does not mirror , but it will cause intermittent connectivity issue for production traffic, we will demonstrate using an example towards the end of this post under ” MORE ON PROXY ID”, but for optimum design, PROXY ID must mirror)

We will introduce issues and see what debug looks like on RESPONDER. This way we can train ourselves to identify the issue by just looking at debug.

PROXY IDS DO NOT MIRROR:

DEBUG ISAKMP ON R1 ( INITIATOR)

*Dec 2 11:41:04.503: ISAKMP:(1059): processing NOTIFY PROPOSAL_NOT_CHOSEN protocol 3

DEBUG ISAKMP ON R2( RESPONDER)

ISAKMP:(1059): phase 2 SA policy not acceptable! (local 12.12.12.2 remote 12.12.12.1)
*Dec 2 11:41:34.587: ISAKMP: set new node 2135090770 to QM_IDLE
*Dec 2 11:41:34.587: ISAKMP:(1059):Sending NOTIFY PROPOSAL_NOT_CHOSEN protocol

Not enough info to pinpoint if PROXY IS is the cause, however if we see DEBUG CRYPTO IPSEC ON RESPONDER, we can easily pinpoint:

Dec 2 11:44:18.367: IPSEC(validate_proposal_request): proposal part #1,
(key eng. msg.) INBOUND local= 12.12.12.2:0, remote= 12.12.12.1:0,
local_proxy= 2.2.2.2/255.255.255.255/256/0,
remote_proxy= 1.1.1.1/255.255.255.255/256/0,
protocol= ESP, transform= NONE (Tunnel),
lifedur= 0s and 0kb,
spi= 0x0(0), conn_id= 0, keysize= 0, flags= 0x0
*Dec 2 11:44:18.367: Crypto mapdb : proxy_match
src addr : 2.2.2.2
dst addr : 1.1.1.1
protocol : 0
src port : 0
dst port : 0
R2#
*Dec 2 11:44:18.367: Crypto mapdb : proxy_match
src addr : 2.2.2.2
dst addr : 1.1.1.1
protocol : 0
src port : 0
dst port : 0
*Dec 2 11:44:18.367: map_db_find_best did not find matching map
*Dec 2 11:44:18.367: IPSEC(ipsec_process_proposal): proxy identities not supported

ENCRYPTION DOES NOT MATCH:

We have normalized the set up and just introduced mismatch encryption:

Debug crypto isakmp on R1/R2

Agin not enough info to pinpoint mismatch encryption is the cause but debug crypto ipsec does pinpoint it:

DEBUG CRYPTO IPSEC ON R2( RESPONDER)

MISMATCH HASHING:

We have normalized the set up, introduced only hashing mismatch:

DEBUG CRYPTO ISAKMP ON R2 (RESPONDER)

MORE ON PROXY ID ISSUE:

We have normalized the set up and made following changes on R2:

Above we are using 1.1.1.0/24 instead of 1.1.1.1/32 on R2

R1 ‘s ACL (shown below) and R2’s ACL above do not mirror:

R1’s ACL 101:
access-list 101 permit ip host 1.1.1.1 host 2.2.2.2

Let initiate the INTERESTING TRAFFIC from 1.1.1.1 to 2.2.2.2, R1 is INITIATOR and R2 is the RESPONDER:

HOST#ping 2.2.2.2 source 1.1.1.1 repeat 2
Type escape sequence to abort.
Sending 2, 100-byte ICMP Echos to 2.2.2.2, timeout is 2 seconds:
Packet sent with a source address of 1.1.1.1

We see no issue, ping is successful, even though PROXY ID does not mirror:

PHASE2 is established on R1/R2:

R2’s PHASE2:

( following is created because PROXY ID on R2 does not match with the PROXY ID of R1)

local ident (addr/mask/prot/port): (2.2.2.2/255.255.255.255/0/0)
remote ident (addr/mask/prot/port): (1.1.1.0/255.255.255.0/0/0)

#pkts encaps: 0, #pkts encrypt: 0, #pkts digest: 0
#pkts decaps: 0, #pkts decrypt: 0, #pkts verify: 0
#pkts compressed: 0, #pkts decompressed: 0
#pkts not compressed: 0, #pkts compr. failed: 0
#pkts not decompressed: 0, #pkts decompress failed: 0
#send errors 0, #recv errors 0

local crypto endpt.: 12.12.12.2, remote crypto endpt.: 12.12.12.1
path mtu 1500, ip mtu 1500, ip mtu idb FastEthernet0/0
current outbound spi: 0x0(0)
PFS (Y/N): N, DH group: none

inbound esp sas:

inbound pcp sas:

outbound esp sas:

So we do see some memory waste on R2 when proxy ID does not match but we do see ” INTERESTING TRAFFIC ” flows without any problem.

How about if R2 is initiator and R1 is a responder ? will ping from 2.2.2.2 to 1.1.1.1 be successful? Let’s see:

I have cleared the IPSEC SA on R1/R2 using : clear crypto sa

So we see pings fail when R2 is the INITIATOR and R1 is the RESPONDER

Phase2 on R1/R2 fail:

local crypto endpt.: 12.12.12.2, remote crypto endpt.: 12.12.12.1
path mtu 1500, ip mtu 1500, ip mtu idb FastEthernet0/0
current outbound spi: 0x0(0)
PFS (Y/N): N, DH group: none

inbound esp sas:

inbound pcp sas:

outbound esp sas:

outbound ah sas:

outbound pcp sas:

PHASE2 FAILS!!

So in nutshell, If R1 is the initiator and R2 is the responder we see no issue, but if the situation is reversed, we see issue. Why?

This is what happening:

When R1 is INITIATOR and R2 is the RESPONDER

We know R1 ‘s PROXY ID is :

access-list 101 permit ip host 1.1.1.1 host 2.2.2.2 which tells R1:

Encrypt traffic form 1.1.1.1 to 2.2.2.2 only when sending traffic

Allow only encrypted traffic sourced from 2.2.2.2 to 1.1.1.1 only.

ALLOW RETURN ENCRYPTED TRAFFIC FROM 2.2.2.2 to 1.1.1.1 only

access-list 101 permit ip host 2.2.2.2 1.1.1.0 0.0.0.255 , which tells R2:

Encrypt traffic from 2.2.2.2 to 1.1.1.0/24 only when sending traffic.

ALLOW ENCRYPTED TRAFFIC FROM 1.1.1.0/24 to 2.2.2.2 only

Being INITIATOR, R1 sends 1st phase2 message carrying PROXY ID( 1.1.1.1/32, 2.2.2.2/32), telling R2, it will be sending ENCRYPTED TRAFFIC FROM SRC IP 1.1.1.1 to 2.2.2.2

R2 checks its own PROXY ID to see if the such traffic is allowed.

Based on R2’s PROXY ID, R2 only allow encrypted traffic from 1.1.1.0/24 to 2.2.2.2/32 , based on this R2 sees traffic from 2.2.2. to 1.1.1.1 is allowed.So phase2 negotiation is successful.

When R2 is initiator and R1 is the responder:

We saw phase2 communication fails, here is why:

Again, let see R1’s PROXY ID:

Encrypt traffic form 1.1.1.1 to 2.2.2.2 only when sending traffic

ALLOW ENCRYPTED TRAFFIC FROM 2.2.2.2 to 1.1.1.1 only

Since R2 is initiator, so R2 sends the 1st message in phase2 to R1, carrying its PROXY ID ( 2.2.2.2/32 1.1.1.0/24), telling R1 it will be sending ENCRYPTED TRAFFIC SOURCED from 2.2.2.2 to any IP with in 1.1.1.0/24 subnet.

R1 receives it and checks if the such traffic is allowed.

R1 only allows return traffic from 2.2.2.2/32 to 1.1.1.1/32 .Based on this , R1 rejects PHASE2 negotiation’s attempts from R2. Basically R2 is saying it can send encrypted traffic with SRC IP 2.2.2.2 to any DES IP within 1.1.1.0/24 subnet, so it could be 1.1.1.1, 1.1.1.2, 1.1.1.3 so on. But R1 allows encrypted traffic to 1.1.1.1 not any other IP within 1.1.1.0/24 subnet so R1 rejects PHASE2 negotiation’s attempt from R2.

So in such case we will see intermittent connectivity ( if IPSEC SA expires, and R2 becomes initiator, communication fails, but when R1 becomes initiator, communication will restore, communication will continue until IPSEC SA expires and R1 is no longer the initiator).

LAST NOTE:

Number of PROXY ID does not need to be same on both IPSEC ENDPOINTS for phase2 to be successful.

R1 has following PROXY IDS:

access-list 101 permit ip host 1.1.1.1 host 2.2.2.2

access-list 101 permit ip host 3.3.3.3 host 4.4.4.4 ( not needed but configured)

R2 haw one PROXY ID:

access-list 101 permit ip host 1.1.1.1 host 2.2.2.2

Below ( in BOLD) memory/CPU resources is wasted to retain PROXY ID not used on R1 (access-list 101 permit ip host 3.3.3.3 host 4.4.4.4)

R1#show crypto ipsec sa

interface: FastEthernet0/0
Crypto map tag: ZEE, local addr 12.12.12.1

protected vrf: (none)
local ident (addr/mask/prot/port): (3.3.3.3/255.255.255.255/0/0)
remote ident (addr/mask/prot/port): (4.4.4.4/255.255.255.255/0/0)
current_peer 12.12.12.2 port 500
PERMIT, flags=
#pkts encaps: 0, #pkts encrypt: 0, #pkts digest: 0
#pkts decaps: 0, #pkts decrypt: 0, #pkts verify: 0
#pkts compressed: 0, #pkts decompressed: 0
#pkts not compressed: 0, #pkts compr. failed: 0
#pkts not decompressed: 0, #pkts decompress failed: 0
#send errors 0, #recv errors 0

Adblock
detector

When investigating phase 2’s  issues,looking at IPSEC debug on RESPONDER is a lot more helpful than looking at DEBUG ISAKMP output. For example, if there is mismatch issue with encryption,hashing, tunnel mode, Proxy ID,single ISAKMP NOTIFICATION MESSAGE WITH CODE”PROPOSAL NOT CHOSEN 3″ is sent. By looking at this message, we can not tell what caused this: Is it PROXY ID? ENCRYPTION TYPE? So it is a lot better to look at DEBUG CRYPTO IPSEC on RESPONDER when investigating PHASE2 ‘s issue.

For a successful phase2 ‘s negotiation following must be true:

1. Matching encryption, hashing, DH
2. Matching tunnel mode
3. Proxy ID ( ACL) on RESPONDER/INITIATOR SHOULD MIRROR EACH OTHER  ( It is possible to have successful PHASE2 negotiation even when PROXY ID does not mirror , but it will cause intermittent connectivity  issue for production traffic, we  will demonstrate using an example towards the end of this post  under ” MORE ON PROXY ID”, but for optimum design, PROXY ID must mirror)

We will introduce issues and see what debug looks like on RESPONDER. This  way we can train ourselves to identify the issue by just looking at debug.

PROXY IDS DO NOT MIRROR:

R1:

crypto isakmp policy 1
 encr 3des
 hash md5
 authentication pre-share
 lifetime 120
crypto isakmp key ZEE address 12.12.12.2
crypto ipsec transform-set ZEE esp-3des esp-md5-hmac
 mode tunnel
crypto map ZEE 1 ipsec-isakmp
 set peer 12.12.12.2
 set transform-set ZEE
 match address 101

access-list 101 permit ip host 1.1.1.1 host 2.2.2.2

R2:

crypto isakmp policy 1
 encr 3des
 hash md5
 authentication pre-share
 lifetime 120
crypto isakmp key ZEE address 12.12.12.1


crypto ipsec transform-set ZEE esp-3des esp-md5-hmac
 mode tunnel
crypto map ZEE 1 ipsec-isakmp
 set peer 12.12.12.1
 set transform-set ZEE
 match address 101


access-list 101 permit ip host 2.2.2.2 host 3.3.3.3 

DEBUG  ISAKMP ON R1 ( INITIATOR)

*Dec 2 11:41:04.503: ISAKMP:(1059): processing NOTIFY PROPOSAL_NOT_CHOSEN   protocol 3

DEBUG ISAKMP ON R2( RESPONDER)

ISAKMP:(1059): phase 2 SA policy not acceptable! (local 12.12.12.2 remote 12.12.12.1)
*Dec 2 11:41:34.587: ISAKMP: set new node 2135090770 to QM_IDLE
*Dec 2 11:41:34.587: ISAKMP:(1059):Sending NOTIFY PROPOSAL_NOT_CHOSEN protocol 

Not enough info to pinpoint if PROXY IS is the cause, however if we see DEBUG CRYPTO IPSEC ON RESPONDER,  we can easily pinpoint:

Dec 2 11:44:18.367: IPSEC(validate_proposal_request): proposal part #1,
(key eng. msg.) INBOUND local= 12.12.12.2:0, remote= 12.12.12.1:0,
local_proxy= 2.2.2.2/255.255.255.255/256/0,
remote_proxy= 1.1.1.1/255.255.255.255/256/0,
protocol= ESP, transform= NONE (Tunnel),
lifedur= 0s and 0kb,
spi= 0x0(0), conn_id= 0, keysize= 0, flags= 0x0
*Dec 2 11:44:18.367: Crypto mapdb : proxy_match
src addr : 2.2.2.2
dst addr : 1.1.1.1
protocol : 0
src port : 0
dst port : 0
R2#
*Dec 2 11:44:18.367: Crypto mapdb : proxy_match
src addr : 2.2.2.2
dst addr : 1.1.1.1
protocol : 0
src port : 0
dst port : 0
*Dec 2 11:44:18.367: map_db_find_best did not find matching map
*Dec 2 11:44:18.367: IPSEC(ipsec_process_proposal): proxy identities not supported

ENCRYPTION DOES NOT MATCH:

We have normalized the set up and just introduced mismatch encryption:

Debug crypto isakmp on R1/R2

NOTIFY PROPOSAL_NOT_CHOSEN protocol

R1:

crypto ipsec transform-set ZEE esp-aes esp-md5-hmac

R2:

crypto ipsec transform-set ZEE esp-3des esp-md5-hmac

debug crypto isakmp on R1 ( INITIATOR):

*Dec 2 11:49:55.351: ISAKMP:(1061): processing NOTIFY PROPOSAL_NOT_CHOSEN protocol 3

debug  crypto isakmp on R2 ( RESPONDER)

Dec 2 11:50:25.411: ISAKMP:(1061): IPSec policy invalidated proposal with error 256
*Dec 2 11:50:25.411: ISAKMP:(1061): phase 2 SA policy not acceptable! (local 12.12.12.2 remote 12.12.12.1)
*Dec 2 11:50:25.411: ISAKMP:
R2#set new node -760315767 to QM_IDLE
*Dec 2 11:50:25.411: ISAKMP:(1061):Sending NOTIFY PROPOSAL_NOT_CHOSEN protocol 3

Agin not enough info to pinpoint mismatch encryption is the cause but debug crypto ipsec does pinpoint it:

DEBUG CRYPTO IPSEC ON R2( RESPONDER)

*Dec 2 11:52:36.227: IPSEC(validate_proposal_request): proposal part #1,
 (key eng. msg.) INBOUND local= 12.12.12.2:0, remote= 12.12.12.1:0,
 local_proxy= 2.2.2.2/255.255.255.255/256/0,
 remote_proxy= 1.1.1.1/255.255.255.255/256/0,
 protocol= ESP, transform= NONE (Tunnel),
 lifedur= 0s and 0kb,
 spi= 0x0(0), conn_id= 0, keysize= 128, flags= 0x0
*Dec 2 11:52:36.235: Crypto mapdb : proxy_match
 src addr : 2.2.2.2
 dst addr : 1.1.1.1
 protocol : 0
 src port : 0
 dst port : 0
R2#
*Dec 2 11:52:36.235: IPSEC(ipsec_process_proposal): transform proposal
 not supported for identity:
 {esp-aes esp-md5-hmac }

MISMATCH HASHING:

We have normalized the set up, introduced only hashing mismatch:

R1(config)#crypto ipsec transform-set ZEE esp-3des esp-sha512-hmac

R2(config)#crypto ipsec transform-set ZEE esp-3des esp-md5-hmac

DEBUG CRYPTO ISAKMP ON R1( INITIATOR):
*Dec 2 11:59:35.351: ISAKMP (1063): received packet from 12.12.12.2 dp
R1#ort 500 sport 500 Global (I) QM_IDLE
*Dec 2 11:59:35.351: ISAKMP: set new node -241107808 to QM_IDLE
*Dec 2 11:59:35.351: ISAKMP:(1063): processing HASH payload. message ID = 4053859488
*Dec 2 11:59:35.351: ISAKMP:(1063): processing NOTIFY PROPOSAL_NOT_CHOSEN protocol 3

DEBUG CRYPTO ISAKMP ON R2 (RESPONDER)

*Dec 2 12:00:05.391: ISAKMP:(1063): IPSec policy invalidated proposal with error 256
*Dec 2 12:00:05.395: ISAKMP:(1063): phase 2 SA policy not acceptable! (local 12.12.12.2 remote 12.12.12.1)
*Dec 2 12:00:05.395: ISAKMP: set new node -1199250418 to QM_IDLE
*D
R2#ec 2 12:00:05.399: ISAKMP:(1063):Sending NOTIFY PROPOSAL_NOT_CHOSEN protocol 3

DEBUG CRYPTO IPSEC ON R2 ( RESPONDER):

Dec 2 12:00:05.379: IPSEC(validate_proposal_request): proposal part #1,
 (key eng. msg.) INBOUND local= 12.12.12.2:0, remote= 12.12.12.1:0,
 local_proxy= 2.2.2.2/255.255.255.255/256/0,
 remote_proxy= 1.1.1.1/255.255.255.255/256/0,
 protocol= ESP, transform= NONE (Tunnel),
 lifedur= 0s and 0kb,
 spi= 0x0(0), conn_id= 0, keysize= 0, flags= 0x0
*Dec 2 12:00:05.387: Crypto mapdb : proxy_match
 src addr : 2.2.2.2
 dst addr : 1.1.1.1
 protocol : 0
 src port : 0
 dst port : 0
*Dec 2 12:00:05.391: IPSEC(ipsec_process_proposal): transform proposal 
not supported for identity:
 {esp-3des esp-sha512-hmac }

MORE ON PROXY ID ISSUE:

We have normalized the set up and made following changes on R2:

R2(config)#no access-list 101 permit ip host 2.2.2.2 host 1.1.1.1

R2(config)#access-list 101 permit ip host 2.2.2.2 1.1.1.0 0.0.0.255

Above we are using 1.1.1.0/24 instead of 1.1.1.1/32 on R2

R1 ‘s ACL (shown below) and R2’s ACL above do not mirror:

R1’s ACL 101:
access-list 101 permit ip host 1.1.1.1 host 2.2.2.2

Let initiate the INTERESTING TRAFFIC from 1.1.1.1 to 2.2.2.2, R1 is INITIATOR and R2 is the RESPONDER:

HOST#ping 2.2.2.2 source 1.1.1.1 repeat 2
Type escape sequence to abort.
Sending 2, 100-byte ICMP Echos to 2.2.2.2, timeout is 2 seconds:
Packet sent with a source address of 1.1.1.1

.!

We see no issue, ping is successful, even though PROXY ID does not mirror:

PHASE2 is established on R1/R2:

R1#show crypto ipsec sa

interface: FastEthernet0/0
 Crypto map tag: ZEE, local addr 12.12.12.1

protected vrf: (none)
 local ident (addr/mask/prot/port): (1.1.1.1/255.255.255.255/0/0)
 remote ident (addr/mask/prot/port): (2.2.2.2/255.255.255.255/0/0)
 current_peer 12.12.12.2 port 500
 PERMIT, flags={origin_is_acl,}
 #pkts encaps: 1, #pkts encrypt: 1, #pkts digest: 1
 #pkts decaps: 1, #pkts decrypt: 1, #pkts verify: 1


SNIP!!!!

inbound esp sas:
 spi: 0x772F9817(1999607831)


 outbound esp sas:
 spi: 0x2206BE0C(570867212)
 transform: esp-3des esp-md5-hmac

R2’s PHASE2:

R2#show crypto ipsec sa

interface: FastEthernet0/0
 Crypto map tag: ZEE, local addr 12.12.12.2

protected vrf: (none)
 local ident (addr/mask/prot/port): (2.2.2.2/255.255.255.255/0/0)
 remote ident (addr/mask/prot/port): (1.1.1.1/255.255.255.255/0/0)
 current_peer 12.12.12.1 port 500
 PERMIT, flags={origin_is_acl,}
 #pkts encaps: 3, #pkts encrypt: 3, #pkts digest: 3
 #pkts decaps: 3, #pkts decrypt: 3, #pkts verify: 3


SNIP!!

inbound esp sas:
 spi: 0xA2AB9FF3(2729156595)
 transform: esp-3des esp-md5-hmac 

outbound esp sas:
 spi: 0xAC381769(2889357161)
 transform: esp-3des esp-md5-hmac

( following is created because PROXY ID on R2 does not match with the PROXY ID of R1)

local ident (addr/mask/prot/port): (2.2.2.2/255.255.255.255/0/0)
remote ident (addr/mask/prot/port): (1.1.1.0/255.255.255.0/0/0)

#pkts encaps: 0, #pkts encrypt: 0, #pkts digest: 0
#pkts decaps: 0, #pkts decrypt: 0, #pkts verify: 0
#pkts compressed: 0, #pkts decompressed: 0
#pkts not compressed: 0, #pkts compr. failed: 0
#pkts not decompressed: 0, #pkts decompress failed: 0
#send errors 0, #recv errors 0

local crypto endpt.: 12.12.12.2, remote crypto endpt.: 12.12.12.1
path mtu 1500, ip mtu 1500, ip mtu idb FastEthernet0/0
current outbound spi: 0x0(0)
PFS (Y/N): N, DH group: none

inbound esp sas:

inbound ah sas:

inbound pcp sas:

outbound esp sas:

So we do see some memory waste on R2 when proxy ID does not match  but we do see ” INTERESTING TRAFFIC ” flows without any problem.

How about if R2 is initiator and R1 is a responder ? will ping  from 2.2.2.2 to 1.1.1.1 be successful? Let’s  see:

I have cleared the IPSEC SA on R1/R2 using : clear crypto  sa

SERVER#ping 1.1.1.1 source 2.2.2.2 repeat 2
Type escape sequence to abort.
Sending 2, 100-byte ICMP Echos to 1.1.1.1, timeout is 2 seconds:
Packet sent with a source address of 2.2.2.2
..

So we see pings fail  when R2 is the INITIATOR and R1 is the RESPONDER

Phase2 on R1/R2 fail:

R2#show crypto ipsec sa

interface: FastEthernet0/0
 Crypto map tag: ZEE, local addr 12.12.12.2

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

local crypto endpt.: 12.12.12.2, remote crypto endpt.: 12.12.12.1
path mtu 1500, ip mtu 1500, ip mtu idb FastEthernet0/0
current outbound spi: 0x0(0)
PFS (Y/N): N, DH group: none

inbound esp sas:

inbound ah sas:

inbound pcp sas:

outbound esp sas:

outbound ah sas:

outbound pcp sas:

PHASE2 FAILS!!

So in nutshell, If R1 is the initiator and R2 is the responder we see no issue, but if the situation is reversed, we see issue. Why?

This is what happening:

When R1 is INITIATOR and R2 is the RESPONDER

We know R1 ‘s PROXY ID is :

access-list 101 permit ip host 1.1.1.1 host 2.2.2.2 which tells R1:

Encrypt traffic form 1.1.1.1 to 2.2.2.2 only when sending traffic

Allow only encrypted traffic sourced from 2.2.2.2 to 1.1.1.1 only.

ALLOW RETURN ENCRYPTED TRAFFIC FROM 2.2.2.2 to 1.1.1.1 only

R2 ‘s PROXY ID:

access-list 101 permit ip host 2.2.2.2 1.1.1.0 0.0.0.255 , which tells R2:

Encrypt traffic from 2.2.2.2 to 1.1.1.0/24 only when sending traffic.

ALLOW ENCRYPTED TRAFFIC FROM 1.1.1.0/24 to 2.2.2.2 only

Being INITIATOR, R1 sends 1st phase2 message carrying PROXY ID( 1.1.1.1/32, 2.2.2.2/32), telling R2, it will be sending ENCRYPTED TRAFFIC FROM SRC IP 1.1.1.1 to 2.2.2.2

R2 checks its own PROXY ID to see if the such traffic is allowed.

Based on R2’s  PROXY ID,  R2 only allow  encrypted traffic from 1.1.1.0/24 to 2.2.2.2/32 , based on this R2 sees  traffic from 2.2.2. to 1.1.1.1 is allowed.So phase2 negotiation is successful.

When R2 is initiator and R1 is the responder:

We saw phase2 communication fails, here is why:

Again, let see R1’s PROXY ID:

Encrypt traffic form 1.1.1.1 to 2.2.2.2 only when sending traffic

ALLOW  ENCRYPTED TRAFFIC FROM 2.2.2.2 to 1.1.1.1 only

Since R2 is initiator, so R2 sends  the 1st message in phase2 to R1, carrying its PROXY ID ( 2.2.2.2/32 1.1.1.0/24), telling R1 it will be sending ENCRYPTED TRAFFIC SOURCED from 2.2.2.2 to any IP with in 1.1.1.0/24 subnet.

R1 receives it and checks if the such traffic is allowed.

R1 only allows return traffic from 2.2.2.2/32 to 1.1.1.1/32 .Based on this , R1 rejects PHASE2 negotiation’s attempts from R2. Basically R2 is saying it can send encrypted traffic with SRC IP 2.2.2.2 to any DES IP within 1.1.1.0/24 subnet, so it could be 1.1.1.1, 1.1.1.2, 1.1.1.3 so on. But R1 allows  encrypted  traffic to 1.1.1.1 not any other IP within 1.1.1.0/24 subnet so R1 rejects PHASE2 negotiation’s attempt from R2.

So in such case we will see intermittent connectivity  ( if IPSEC SA expires, and R2 becomes initiator, communication fails, but when R1 becomes initiator, communication will restore, communication will continue until IPSEC SA expires and R1 is no longer the initiator).

LAST NOTE:

Number of PROXY ID does not need to be same on both IPSEC ENDPOINTS for phase2 to be successful.

For e.g:

R1 has following  PROXY IDS:

access-list 101 permit ip host 1.1.1.1 host 2.2.2.2

access-list 101 permit ip host 3.3.3.3 host 4.4.4.4 ( not needed but configured)

R2 haw one PROXY ID:

access-list 101 permit ip host 1.1.1.1 host 2.2.2.2

Below ( in BOLD) memory/CPU resources is wasted to retain PROXY ID not used on R1 (access-list 101 permit ip host 3.3.3.3 host 4.4.4.4) 

R1#show crypto ipsec sa

interface: FastEthernet0/0
Crypto map tag: ZEE, local addr 12.12.12.1

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

local crypto endpt.: 12.12.12.1, remote crypto endpt.: 12.12.12.2
path mtu 1500, ip mtu 1500, ip mtu idb FastEthernet0/0
current outbound spi: 0x0(0)
PFS (Y/N): N, DH group: none

inbound esp sas:

inbound ah sas:

inbound pcp sas:

outbound esp sas:

outbound ah sas:

outbound pcp sas:

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

local crypto endpt.: 12.12.12.1, remote crypto endpt.: 12.12.12.2
path mtu 1500, ip mtu 1500, ip mtu idb FastEthernet0/0
current outbound spi: 0xFC55F1C(264593180)
PFS (Y/N): N, DH group: none

inbound esp sas:
spi: 0xA1100165(2702180709)
transform: esp-3des esp-md5-hmac ,
in use settings ={Tunnel, }
conn id: 199, flow_id: 199, sibling_flags 80004040, crypto map: ZEE
sa timing: remaining key lifetime (k/sec): (4220620/3532)
IV size: 8 bytes
replay detection support: Y
Status: ACTIVE(ACTIVE)

inbound ah sas:

inbound pcp sas:

outbound esp sas:
spi: 0xFC55F1C(264593180)
transform: esp-3des esp-md5-hmac ,
in use settings ={Tunnel, }
conn id: 200, flow_id: 200, sibling_flags 80004040, crypto map: ZEE
sa timing: remaining key lifetime (k/sec): (4220620/3532)
IV size: 8 bytes
replay detection support: Y
Status: ACTIVE(ACTIVE)

outbound ah sas:

outbound pcp sas:

Always use PROXY ID frugally with crypto map. If a PROXY ID is not needed, avoid using it to save memory and CPU resources.In later post, we will see PROXY ID does not scale well when using CRYPTO MAP

The HUB is managed at a data center with external IP 200.200.200.200.
There are 10 remote offices.

Office 9                                    HUB
10.1.9.0 - 100.100.100.100 ->>  VPN   <<- 200.200.200.200 - 10.1.1.0

In office 9 only,
after upgrading from ADSL to EFM and replaced Cisco 887 with Cisco 1812 (both running IOS 12.4).
Copied the config, replaced internet connection details.

Not sure if relevant, but there is also a router in bridge mode the EFM provider installed the 1812 connects through.

Now the ISAKMP is connected

MYCISCO#show crypto isakmp sa
IPv4 Crypto ISAKMP SA
dst              src              state          conn-id slot status
100.100.100.100  200.200.200.200  MM_NO_STATE       2262    0 ACTIVE (deleted)

But Phase 2 IPSEC SA will not come up. the logs produce errors:

• transform proposal not supported for identity
• IPSec policy invalidated proposal with error 256
• phase 2 SA policy not acceptable!

From show log:

*Apr  2 21:44:09.198: ISAKMP:(2125):Old State = IKE_QM_READY  New State = IKE_QM_READY
*Apr  2 21:44:12.246: ISAKMP (0:2125): received packet from 200.200.200.200 dport 500 sport 500 Global (I) QM_IDLE
*Apr  2 21:44:12.246: ISAKMP: set new node -505694825 to QM_IDLE
*Apr  2 21:44:12.246: crypto_engine: Decrypt IKE packet
*Apr  2 21:44:12.246: crypto_engine: Generate IKE hash
*Apr  2 21:44:12.246: ISAKMP:(2125): processing HASH payload. message ID = -505694825
*Apr  2 21:44:12.246: ISAKMP:(2125): processing SA payload. message ID = -505694825
*Apr  2 21:44:12.246: ISAKMP:(2125):Checking IPSec proposal 0
*Apr  2 21:44:12.246: ISAKMP: transform 0, ESP_AES
*Apr  2 21:44:12.246: ISAKMP:   attributes in transform:
*Apr  2 21:44:12.246: ISAKMP:      group is 5
*Apr  2 21:44:12.246: ISAKMP:      encaps is 1 (Tunnel)
*Apr  2 21:44:12.246: ISAKMP:      SA life type in seconds
*Apr  2 21:44:12.246: ISAKMP:      SA life duration (basic) of 28800
*Apr  2 21:44:12.246: ISAKMP:      authenticator is HMAC-SHA
*Apr  2 21:44:12.246: ISAKMP:      key length is 128
*Apr  2 21:44:12.246: CryptoEngine0: validate proposal
*Apr  2 21:44:12.246: ISAKMP:(2125):atts are acceptable.
*Apr  2 21:44:12.246: IPSEC(validate_proposal_request): proposal part #1
*Apr  2 21:44:12.246: IPSEC(validate_proposal_request): proposal part #1,
  (key eng. msg.) INBOUND local= 100.100.100.100, remote= 200.200.200.200,
    local_proxy= 10.1.9.0/255.255.255.0/0/0 (type=4),
    remote_proxy= 10.1.1.0/255.255.255.0/0/0 (type=4),
    protocol= ESP, transform= esp-aes esp-sha-hmac  (Tunnel),
    lifedur= 0s and 0kb,
    spi= 0x0(0), conn_id= 0, keysize= 128, flags= 0x0
*Apr  2 21:44:12.246: Crypto mapdb : proxy_match
        src addr     : 10.1.9.0
        dst addr     : 10.1.1.0
        protocol     : 0
        src port     : 0
        dst port     : 0
*Apr  2 21:44:12.246: IPSEC(crypto_ipsec_process_proposal): transform proposal not supported for identity:
    {esp-aes esp-sha-hmac }
*Apr  2 21:44:12.246: ISAKMP:(2125): IPSec policy invalidated proposal with error 256
*Apr  2 21:44:12.246: ISAKMP:(2125): phase 2 SA policy not acceptable! (local 100.100.100.100 remote 200.200.200.200)

My Configuration:

!
version 12.4
no service pad
service timestamps debug datetime msec
service timestamps log datetime msec
no service password-encryption
!
hostname MYCISCO
!
boot-start-marker
boot-end-marker
!
logging buffered 4096 debugging
no logging console
enable secret 5 XXXXXXXXXXXXXXXXXXXXXXXXXX
!
aaa new-model
!
!
aaa authentication login userauthen local
aaa authorization network groupauthor local
!
aaa session-id common
!
resource policy
!
clock timezone AEST 10
clock summer-time BST recurring last Sun Mar 2:00 last Sun Oct 3:00
no ip source-route
no ip gratuitous-arps
!
!
ip cef
no ip dhcp use vrf connected
ip dhcp excluded-address 10.1.9.1 10.1.9.99
!
ip dhcp pool VLAN1
   import all
   network 10.1.9.0 255.255.255.0
   default-router 10.1.9.254
   domain-name MYDOMAIN.COM
   dns-server 8.8.8.8
!
!
ip tcp path-mtu-discovery
no ip bootp server
no ip domain lookup
ip domain name MYDOMAIN.COM
ip name-server 8.8.8.8
!
password encryption aes
crypto pki token default removal timeout 0
!
!
!
no spanning-tree vlan 1
no spanning-tree vlan 2
username ADMINUSERNAME password 0 ADMINPASSWORD
archive
 log config
  hidekeys
!
!
!
crypto isakmp policy 3
 encr aes
 authentication pre-share
 group 5
 lifetime 3600
crypto isakmp key PRESHAREDKEY address 200.200.200.200 no-xauth
!
!
crypto ipsec transform-set myset esp-des esp-md5-hmac
crypto ipsec transform-set myset1 esp-des esp-md5-hmac
crypto ipsec transform-set myset2 esp-3des esp-md5-hmac
crypto ipsec transform-set myset3 esp-aes 256
crypto ipsec transform-set myset4 esp-aes 256 esp-md5-hmac
crypto ipsec transform-set myset5 esp-3des esp-sha-hmac
mode transport
!
crypto dynamic-map dynmap 10
 set transform-set myset
 reverse-route
!
!
crypto map clientmap client authentication list userauthen
crypto map clientmap isakmp authorization list groupauthor
crypto map clientmap client configuration address respond
crypto map clientmap 1 ipsec-isakmp
 set peer 200.200.200.200
 set security-association lifetime seconds 28800
 set transform-set myset myset1 myset2 myset3 myset4 myset5
 match address 110
crypto map clientmap 10 ipsec-isakmp dynamic dynmap
!
bridge irb
!
!
!
interface FastEthernet0
 no ip address
 duplex auto
 speed auto
 pppoe enable group global
 pppoe-client dial-pool-number 1
 no shutdown
!
interface FastEthernet1
 no ip address
 shutdown
 duplex auto
 speed auto
!
interface BRI0
 no ip address
 encapsulation hdlc
 shutdown
!
interface FastEthernet2
!
interface FastEthernet3
!
interface FastEthernet4
!
interface FastEthernet5
!
interface FastEthernet6
!
interface FastEthernet7
!
interface FastEthernet8
!
interface FastEthernet9
!
interface Vlan1
 description Internal Network
 ip address 10.1.9.254 255.255.255.0
 ip verify unicast reverse-path
 no ip redirects
 no ip proxy-arp
 ip nat inside
 ip virtual-reassembly
 load-interval 30
!

 no ip redirects
 no ip unreachables
 no ip proxy-arp
 ip mtu 1492
 ip flow ingress
 ip nat outside
 ip virtual-reassembly in

interface Dialer0
no ip redirects
no ip unreachables
no ip proxy-arp

 ip address negotiated
 ip mtu 1492
 ip nat outside
 ip virtual-reassembly
 encapsulation ppp
 ip tcp adjust-mss 1452
 dialer pool 1
 ppp chap hostname CHAP@HOST.COM
 ppp chap password 0 CHAPPASSWORD
 ppp pap sent-username PAP@HOST.COM password 0 PAPPASSWORD
 ppp ipcp dns request accept
 crypto map clientmap
!

!
!
no ip http server
no ip http secure-server
ip nat inside source list 102 interface Dialer0 overload
ip route 0.0.0.0 0.0.0.0 Dialer0
!
access-list 1 remark IP Addresses Permitted to login via ssh and telnet
access-list 1 permit 200.200.200.200
access-list 1 permit 10.1.9.0 0.0.0.255
access-list 1 permit 10.1.1.0 0.0.0.255
access-list 1 deny   any
access-list 3 remark NTP Server addresses
access-list 3 permit X.X.X.X
access-list 4 remark Deny All
access-list 4 deny   any
access-list 102 remark NAT
access-list 102 deny   ip 10.1.9.0 0.0.0.255 10.1.1.0 0.0.0.255
access-list 102 permit ip 10.1.9.0 0.0.0.255 any

access-list 110 remark VPN 
access-list 110 permit ip 10.1.9.0 0.0.0.255 10.1.1.0 0.0.0.255
dialer-list 1 protocol ip permit
no cdp run
!
!
!
control-plane
!
!
line con 0
 password CONPASSWORD
line aux 0
 access-class 4 in
line vty 0 4
 access-class 1 in
 exec-timeout 500 0
 privilege level 3
 password VTYPASSWORD
 transport input telnet ssh
!
scheduler max-task-time 5000
scheduler interval 500
ntp access-group peer 3
ntp access-group serve 4
ntp master
ntp server X.X.X.X
!
webvpn context Default_context
 ssl authenticate verify all
 !
 no inservice
!
end

I’m suspecting the Access List settings, but again this is identical to 9 other offices, and the network support team who are providing the HUB end have taken a look and the settings are all correct.

Thanks for your comments!

Время прочтения
82 мин

Просмотры 177K

Коллеги, здравствуйте. Меня зовут Семенов Вадим и я хочу представить статью, посвященную вопросу масштабируемости VPN-ов, причем тех VPN-ов, которые доступны для настройки в обычной корпоративной сети предприятия, а не со стороны провайдера. Надеюсь, данная статья станет справочным материалом, который может потребоваться при дизайне сети, либо при её апгрейде, либо для того, чтобы освежить в памяти принцип работы того или иного VPN-на. 

В начале статьи описаны основные моменты стека протоколов IPSec, так как использование данного стандарта далее будет весьма часто встречаться. В конце параграфа об IPSec были включены самые частые причины неработоспособности IPSec канала, а также основные шаги по их устранению.

Типы VPN соединений

Ниже систематизированы VPN-ы, которые доступны для настройки в корпоративной сети. Технологии распределены по уровню предоставляемых клиенту каналов по модели OSI (рис 1):

 
Как раз VPN-ы для корпоративных сетей будут рассмотрены в данной статье.

Схема VPN-ов относительно возможности пропуска мультикаста и работы протоколов маршрутизации (рис. 2):

 

Дополнительно приводится структурированная схема VPN-ов (рис.3), которые могут предоставляться провайдером, но в данной статье подробно они не рассматриваются:

 
Итогом работы по систематизации VPN-ов и исследованию их масштабируемости послужила итоговая таблица, в которую заносилась общая информация по типу протокола VPN-а, его особенности, и самое важное, что необходимо сделать, если к существующим VPN-ам подключить еще один.
В таблице представлены результаты настроек, исследование полученного формата пакета, настройка протокола маршрутизации (OSPF) через VPN-ы, а также рассмотрены вопросы масштабируемости протокола.

Таблица VPN

Установление IPSec, сообщения, режимы работы.

В процессе установления соединения через IPSec двум участникам защищенного канала необходимо согласовать значительный ряд параметров: по необходимости они должны аутентифицировать друг друга, сгенерировать и обменяться общими ключами (причем через недоверенную среду), установить какой трафик шифровать (от какого отправителя и к какому получателю), а также договориться с помощью каких протоколов шифровать, а с помощью каких — аутентифицировать. Служебной информации предполагается обменяться много, не правда ли? По этой причине IPSec и состоит из стека протоколов, обязанность которых обеспечить установление, работу и управление защищенным соединением. Процесс установления соединения состоит из 2 фаз: первая фаза устанавливается для того, чтобы обеспечить безопасный обмен ISAKMP сообщений во второй фазе. А ISAKMP (Internet Security Association and Key Management Protocol) служит для согласования политик безопасности (SA) между участниками VPN соединения, в который как раз и определяются с помощью какого протокола шифровать (AES, 3DES, DES), и с помощью чего аутентифицировать (HMAC SHA, MD5).

Режим работы IKE (Internet Key Exchange):

IKE Фаза 1

• (опционально) аутентификация пиров
• Согласование IKE SA между пирами

Main Mode (6 сообщений)

• [First exchange] Начало согласований начинаются с отправки пиром друг другу предложений о поддерживаемом шифровании, протоколов аутентификации самих сообщений IKE, времени жизни ассоциаций безопасности. Пир выбирает предложенный SA и отправляет их предложившему пиру. Эти настройки определяются в ISAKMP Policy
• [Second exchange] Генерация общих разделяемых ключей через обмен открытыми ключами по Diffie-Hellman. Дальнейший обмен сообщениями происходит уже зашифрованными сообщениями.
• [Third exchange] Обмен сообщениями для аутентификации ISAKMP сессии (IKE_I_MM4)

После установки IKE SA (то есть установления 1-ой фазы), происходит согласование IPSEC в quick mode (QM). Сообщения режима Main Mode (MM):
—        IKE_READY New State = IKE_I_MM1
—        IKE_I_MM1 New State = IKE_I_MM2
—        IKE_I_MM2 New State = IKE_I_MM3
—        IKE_I_MM3 New State = IKE_I_MM4
—        IKE_I_MM4 New State = IKE_I_MM5
—        IKE_I_MM5 New State = IKE_I_MM6
Aggressive Mode (3 сообщения)
Инициатором в первое сообщение помещается предложение о шифровании, протоколе аутентификации самих сообщений IKE, времени жизни ключей, сообщения об обмене ключами Диффи-Хеллмана (DH), идентификатор сессии, её аутентификация.
Команда для диагностики данной фазы на оборудовании Cisco **show crypto isakmp sa

IKE Фаза 1.5

Не используется в стандартном peer-to-peer VPN соединении, применяется при организации удаленных подключений.
Имеет два режима:
Xauth (User Authentication)

• Дополнительная аутентификация пользователей в пределах IKE протокола. Для этого используется протокол Extended Authentication.

Mode config (Push Config)

• Передается дополнительная информация клиенту о IP адресе, маске, DNS-серверах и т.д.

IKE Фаза 2

IPsec SAs/SPIs
На этом этапе ISAKMP ответственен за обмен сессионными ключами и согласование политик безопасности (SA) для обеспечения конфиденциальности и целостности пользовательского трафика. В настройке (в Cisco IOS) за это отвечает transform-set.
Quick mode
QM делает все то, что и IPSec SAs/SPIs за меньшее количество служебных сообщений. По аналогии с Aggressive Mode.
Рассмотрим пример обмена служебными сообщениями во время установления IPSec туннеля. Работающий вариант.

ISAKMP:(1007):Old State = IKE_I_MM6  New State = IKE_I_MM6
*Sep  3 08:59:27.539: ISAKMP:(1007):Input = IKE_MESG_INTERNAL, IKE_PROCESS_COMPLETE
*Sep  3 08:59:27.543: ISAKMP:(1007):Old State = IKE_I_MM6  New State = IKE_P1_COMPLETE

ФАЗА 2

А теперь я предлагаю рассмотреть пару примеров неработоспособности IPSec.

Case1

“Old State = IKE_I_MM1  New State = IKE_I_MM1”
Причина №1
Не договорились по IKE proposal (предложенным IKE) в Фазе 1. На одной стороне указан 3des, на другом aes.

Error while processing SA request: Failed to initialize SA
*Sep  3 08:36:38.239: ISAKMP: Error while processing KMI message 0, error 2.
*Sep  3 08:36:38.287: ISAKMP:(0): retransmitting phase 1 MM_NO_STATE…
*Sep  3 08:40:38.307: ISAKMP (0): incrementing error counter on sa, attempt 3 of 5: retransmit phase 1
*Sep  3 08:40:38.307: ISAKMP:(0): retransmitting phase 1 MM_NO_STATE
*Sep  3 08:37:08.339: ISAKMP:(0):deleting SA reason «Death by retransmission P1» state (I) MM_NO_STATE (peer 192.168.0.2)
*Sep  3 08:41:08.359: ISAKMP:(0):Input = IKE_MESG_INTERNAL, IKE_PHASE1_DEL
*Sep  3 08:41:08.359: ISAKMP:(0):Old State = IKE_I_MM1  New State = IKE_DEST_SA

На маршрутизаторе отображается следующее состояние:

R7#sh crypto isakmp sa
IPv4 Crypto ISAKMP SA
       dst                     src                       state             conn-id status
192.168.0.2     192.168.0.1           MM_NO_STATE          0    ACTIVE

Причина №2
ACL на физическом интерфейсе блокируется трафик ISAKMP.

Case2

Если transform set на одном роутере один

R7#sh run | i transform
crypto ipsec transform-set TRANSFORM esp-aes esp-md5-hmac

…а на другом роутере другой

R10#sh run | i transform
crypto ipsec transform-set TRANSFORM esp-aes esp-sha-hmac

, то не сойдется SA IPSEC (не будет увеличиваться количество зашифрованных и расшифрованных пакетов

*Sep  3 08:56:08.551: ISAKMP:(1006): IPSec policy invalidated proposal with error 256
*Sep  3 08:56:08.559: ISAKMP:(1006): phase 2 SA policy not acceptable! (local 192.168.0.1 remote 192.168.0.2)
*Sep  3 08:56:08.563: ISAKMP: set new node -1456368678 to QM_IDLE
*Sep  3 08:56:08.567: ISAKMP:(1006):Sending NOTIFY PROPOSAL_NOT_CHOSEN protocol 3
        spi 1785687224, message ID = 2838598618
*Sep  3 08:56:08.575: ISAKMP:(1006): sending packet to 192.168.0.2 my_port 500 peer_port 500 (I) QM_IDLE
*Sep  3 08:56:08.579: ISAKMP:(1006):Sending an IKE IPv4 Packet.
*Sep  3 08:56:08.583: ISAKMP:(1006):purging node -1456368678
*Sep  3 08:56:08.587: ISAKMP:(1006):deleting node 1350414148 error TRUE reason «QM rejected«
*Sep  3 08:56:08.591: ISAKMP:(1006):Node 1350414148, Input = IKE_MESG_FROM_PEER, IKE_QM_EXCH
*Sep  3 08:56:08.595: ISAKMP:(1006):Old State = IKE_QM_READY  New State = IKE_QM_READY

Case3

Если неправильно указали preshared key на IPSec пирах:

R7#sh run | i isakmp key
crypto isakmp key cisco123 address 172.16.1.2

R10#sh run | i isakmp key
crypto isakmp key cisco address 0.0.0.0 0.0.0.0

Тогда будет ошибка retransmitting phase 1 MM_KEY_EXCH

*Sep  3 09:14:30.659: ISAKMP:(1010): retransmitting phase 1 MM_KEY_EXCH…
*Sep  3 09:14:30.663: ISAKMP (1010): incrementing error counter on sa, attempt 3 of 5: retransmit phase 1
*Sep  3 09:14:30.663: ISAKMP:(1010): retransmitting phase 1 MM_KEY_EXCH
*Sep  3 09:14:30.663: ISAKMP:(1010): sending packet to 192.168.0.2 my_port 500 peer_port 500 (I) MM_KEY_EXCH
*Sep  3 09:14:30.663: ISAKMP:(1010):Sending an IKE IPv4 Packet.
*Sep  3 09:14:30.711: ISAKMP (1010): received packet from 192.168.0.2 dport 500 sport 500 Global (I) MM_KEY_EXCH
*Sep  3 09:14:30.715: ISAKMP:(1010): phase 1 packet is a duplicate of a previous packet.
*Sep  3 09:14:50.883: ISAKMP:(1011): retransmitting due to retransmit phase 1
*Sep  3 09:14:51.383: ISAKMP:(1011): retransmitting phase 1 MM_KEY_EXCH…
*Sep  3 09:14:51.387: ISAKMP:(1011):peer does not do paranoid keepalives.
*Sep  3 09:14:51.387: ISAKMP:(1011):deleting SA reason «Death by retransmission P1» state ® MM_KEY_EXCH (peer 192.168.0.2)
*Sep  3 09:14:51.395: ISAKMP:(1011):Input = IKE_MESG_INTERNAL, IKE_PHASE1_DEL

Regular IPSec

Настройка через Crypto map

Конфигурация устройств:

 
Проверка работоспособности

SPI передается в IPSec пакете для того, чтобы при получении его пир-ом, в данном случае HUB-ом,  HUB знал какой SA (security association) использовать, то есть какой протокол шифрования, какой протокол аутентификации и т.д. используется и как пакет расшифровывать. На HUB-е есть точно такая же SA с таким же SPI.
Успешное прохождение трафика через VPN на HUB-e

 
Теперь добавим еще один Spoke, посмотрим, какие изменения нам потребуется внести

 
Проверка работы VPN

 
Отсутствие связности до Spoke2 неудивительно — необходимо включать внутренние сети нового удаленного офиса в Crypto ACL, в итоге для обеспечения связности между Spokе-ми через HUB требуется добавление в Crypto ACL N сетей на N spoke-ах.

Альтернатива. Множественные Crypto map.

Пример конфигурации IPSec множественных VPN-ов с удаленными офисами с динамическими или статическими ip адресами, когда каждый офис получает доступ через интернет канал VPN-HUBа, но при этом все удаленные сети находятся в таблице маршрутизации и до них организована связь без использования NAT-а.

В данной схеме и в данной конфигурации на удаленных офисах выставлено в Crypto ACL в качестве сети назначения – ip any, т.е. трафик к любому хосту будет заворачиваться в туннель, и при подключении нового удаленного офиса нет необходимости в изменении во всех остальных Crypto ACL в N удаленных офисах.
Независимо от метода подключения: Regular IPSec или (забегая немного вперед, IPSec  dynamic IP)  в том и другом случае мы сталкиваемся с задачей обеспечения доступности между удаленными площадками. В рамках подключения типа Regular IPSec и IPSec  dynamic IP нужно вручную определять сети в crypto ACL, поэтому для уменьшения конфигурации на оконечных устройствах после подключения очередного удаленного офиса, возможно пойти двумя путями:

1. Отойти от crypto map к VTI и настроить динамическую маршрутизацию.
2. Для настройки динамического протокола маршрутизации (OSPF) перейдем от использования метода crypto  map к такой же настройке, но только через VTI интерфейс (поддерживает unicast, multicast).

Настройка через Virtual Tunnel Interface + профайлы.

Virtual Tunnel Interface обеспечивают маршрутизирующий интерфейс для терминирования IPSec туннелей и более простой способ обеспечения безопасного соединения удаленных корпоративных сетей. VTI поддерживает передачу через туннель только юникаста и мультикаста, что позволяет обеспечить работу динамических протоколов маршрутизации без дополнительной необходимости в инкапсулировании пакета в GRE (дополнительные 4-байта). Существуют два типа виртуальных туннельных интерфейса:
Static virtual interface – представляет собой point-to-point туннель
Dуnamic virtual interface – позволяет масштабировать решение по VPN-ам путем терминирования множественных туннелей на себя с удаленных Spoke-ов, которые могут иметь динамический IP адрес. Единственный недостаток – только удаленные spoke маршрутизаторы могут инициировать установление туннеля (т.к. только у них указан tunnel destination HUB_ip).
При настройке DVTI на HUB маршрутизаторе создается шаблон настроек virtual-template, при успешном обмене ключами с удаленным spoke-м и установлении с ним туннеля — из «шаблона» на HUBе создается virtual-access интерфейс, который является как SVTI туннельный интерфейс  для данного туннеля.
Особенности VTI:

• Traffic selector (т.е. тот трафик, который будет завернут в туннель) у Static VTI всегда ip any any;
• Traffic selector у Dynamic VTI тоже по умолчанию ip any any и поддерживает только одну IPSec SA, но может принимать тот traffic selector, который предлагает ему инициатор;
• Не поддерживается Stateful Failover;
• Режим работы transform-set только в туннельном режиме.

 
Проверка установления соседства через OSPF over Static VTI

Traffic Selector для Static VTI ip any any, т.е. все, что мы направим в туннель через статический маршрут либо через протокол маршрутизации, то и будет шифроваться/дешифроваться.

 
interface Tunnel0
ip address 10.1.1.254 255.255.255.0
ip ospf mtu-ignore

 
OSPF Neighbor осуществляет проверку на использование одинакового значения MTU на интерфейсе. Если neighbor получит размер MTU в DBD пакете бОльший, чем MTU своего входящего интерфейса, то соседство не установится.
При подключении второго Spoke2 настраивается второй Tunnel (HUB-Spoke2), на которого выделяется своя отдельная подсеть.

IPSec with Dynamic IP, Dynamic VTI

 
Рассмотрим на нашем примере схему с использованием Dynamic VTI на HUBе, Static VTI на spoke-ах.  К Dynamic VTI могут подключаться также и с настроенными crypto map-ами.

Проверим установленные туннели при двух подключенных Spoke-ах:

 
Работа OSPF через туннели:

 
Восстановление канала при падении линка
Выключим Tunnel интерфейс на Spoke, очистим ipsec сессии и обмененными ключами. После этого включим интерфейс обратно:

Spoke1(config-if)#no shutdown
*Aug  6 10:02:27.669: %CRYPTO-6-ISAKMP_ON_OFF: ISAKMP is ON
*Aug  6 10:02:27.702: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel0, changed state to up
*Aug  6 10:02:27.713: %OSPF-5-ADJCHG: Process 1, Nbr 10.0.0.1 on Tunnel0 from LOADING to FULL, Loading Done

Восстановление туннеля прошло автоматически.

EASY VPN

Идея технологии Easy VPN заключается в облегчении установления VPN-подключения региональным маршрутизаторам засчет того, что часть настроек касательно IPSec сообщается VPN-клиенту самим VPN HUB-ом. Для этого в протокол согласования ассоциаций безопасности (ISAKMP) была внесена дополнительная фаза 1.5. Через эту фазу vpn-клиент может запросить информацию о IP-адресе, DNS-ы, ACL для split tunnel. Чаще всего эта технология используется в организации удаленного подключения через Cisco VPN Client.
Три режима работы Easy VPN Remote[1]:

• клиентский режим. В этом случае на VPN-клиенте(маршрутизаторе) вся локальная сеть удаленного офиса подвергается NAT/PAT-трансляции в адрес, который выдан сервером из заданного пула
• режим сетевого расширения. В этом случае, все сетевые устройства, которые находятся за VPN-клиентом (маршрутизатором), получают IP-адреса и являются полноценными участниками IP-маршрутизации. В этом случае PAT не используется, что позволяет конечным рабочим станциям работать друг с другом напрямую.
• режим сетевого расширения «плюс». Аналогичен режиму простого сетевого расширения, но с дополнением в виде возможности запроса IP-адреса в процессе установления защищенного канала связи и его автоматической установки на доступный Loopback-интерфейс. Ассоциации безопасности IPsec для этого IP-адреса автоматически создаются Easy VPN Remote’ом. Этот IP чаще всего используется для устранения неисправностей (ping, telnet, ssh и т.д.).

Есть и особенности в настройках:
Cisco Easy VPN Remote не поддерживает transform set с установленной безопасностью без аутентификации (ESP-DES and ESP-3DES) или transform-set, обеспечивающий аутентификацию без шифрования (ESP-NULL ESP-SHA-HMAC and ESP-NULL ESP-MD5-HMAC)
Если на VPN-клиенте (маршрутизаторе) настроен NAT/PAT до настройки Cisco Easy VPN Remote, то в первую очередь необходимо удалить NAT-правила (в последствии они создадутся автоматически)

Настройка Easy VPN в client mode

На VPN-клиенте (маршрутизаторе) вся локальная сеть удаленного офиса подвергается NAT/PAT-трансляции в адрес, который выдан сервером из заданного пула

Автоматически прописывается ip outside nat (ip nat inside мы должны прописать) и добавляются ACL!
Проверим, что NAT настроился автоматически, прописался исходящий интерфейс и добавились списки контроля доступа ACL интересующего нас трафика

VPN_Client#sh ip nat statistics
Total active translations: 0 (0 static, 0 dynamic; 0 extended)
Peak translations: 0
Outside interfaces:
  Ethernet0/0
Inside interfaces:
  Ethernet0/2
Hits: 0  Misses: 0
CEF Translated packets: 0, CEF Punted packets: 0
Expired translations: 0
Dynamic mappings:
— Inside Source
[Id: 106] access-list EZVPN-CLIENT_internet-list interface Ethernet0/0 refcount 0
[Id: 105] access-list EZVPN-CLIENT_enterprise-list pool EZVPN-CLIENT refcount 0
 pool EZVPN-CLIENT: netmask 255.255.255.0
        start 172.16.40.49 end 172.16.40.49
        type generic, total addresses 1, allocated 0 (0%), misses 0

Видно, что добавились автоматически два списка доступа. Посмотрим, какой тип трафика они определяют

VPN_Client#sh access-lists EZVPN-CLIENT_internet-list (не локальные сети пускать в инет)
Extended IP access list EZVPN-CLIENT_internet-list
    10 deny ip 192.168.2.0 0.0.0.255 192.168.1.0 0.0.0.255
    20 deny ip 192.168.2.0 0.0.0.255 2.2.2.0 0.0.0.255
    30 permit ip 192.168.2.0 0.0.0.255 any
!
VPN_Client#sh access-lists EZVPN-CLIENT_enterprise-list (локальные сети натить в назначенный IP)
Extended IP access list EZVPN-CLIENT_enterprise-list
    10 permit ip 192.168.2.0 0.0.0.255 192.168.1.0 0.0.0.255
    20 permit ip 192.168.2.0 0.0.0.255 2.2.2.0 0.0.0.255

GRE tunnel. OSPF over GRE

Gre представляет собой транспорт для многих типов остальных протоколов, будь то сигнальные сообщения динамических протоколов маршрутизации (OSPF, EIGRP) либо IPv6 пакеты. Данные пакеты инкапсулируются в еще один IP пакет (тип 47) с GRE заголовком. GRE прост в настройке, хотя и разработан первоначально Cisco, сейчас представляет собой открытый стандарт RFC 2784.
GRE туннель создает point-to-point линк со всеми вытекающими из этого проблемами масштабирования. В реальной сети это выливается в создании каждого туннеля для каждого удаленного офиса (маршрутизатора) с выделением отдельной подсети.

 
Проверка работы OSPF

 
Формат пакета:

GRE over IPSec

 
Проверка работы GRE over IPSec

Формат пакета:

Работа OSPF over GRE over IPSec
OSPF работает в стандартной конфигурации (как в случае network type broadcast)

DMVPN

DMVPN реализует multipoint GRE архитектуру, позволяя использовать, во-первых, одно адресное пространство для всех vpn удаленных офисов, во-вторых, пропускать через туннель большой список сторонних протоколов, а также мультикаст, и в-третьих, устанавливать динамически туннели между региональными удаленными площадками в случае возникновения трафика между ними. Однако есть одно но, данная технология реализуема только на моновендорной сети на Cisco.

 
Настройка маршрутизатора HQ как DMVPN HUB, Spoke 1 как DMVPN Client

Проверка работы DMVPN
Проверяем установился ли туннель до DMVPN HUBa.
Обращаем внимание, что NBMA address – реальный адрес HUBa.

 
Создание динамического GRE туннеля от удаленного офиса Spoke1 к Spoke2
Вначале загрузки у  Spoke 1 был только 1 туннель до HUBа. При генерировании трафика (пинга) до Spoke2, сразу же создался туннель до Spoke2

 
На данный момент схема сети (рис.13) будет уже выглядеть так:

Динамические протоколы маршрутизации через DMVPN

Настройка OSPF

Сделав настройки по DMVPN и включив общую сеть для VPN-а 10.5.5.0 в процесс OSPF – мы будем наблюдать как OSPF на HUBе будет устанавливать смежные отношения сначала со Spoke1 до того момента, как не получит hello пакет со Spoke2, после этого отношения рушатся с ошибкой Neighbor Down: Adjacency forced to reset, так как по умолчанию interface Tunnel выставлен как point-to-point интерфейс. Для корректной работы OSPF необходимо выставить network type как broadcast. Если выставить broadcast только на HUBe, то соседства установятся, но маршрутов через OSPF на Spok-aх не будет, поэтому необходимо выставить broadcast и на HUB, и на Spoke-ах.
Ниже приведены таблицы поведения OSPF в зависимости от выбранного значения network type.

DMVPN c EIGRP

Выключаем на HUBe split-horizon

Избавимся от HUB-а как промежуточного устройства в связности Spoke1 <-> Spoke2

PPTP

PPTP стал совместной разработкой консорциумов Microsoft, 3Com, Ascend Communication. Хорошо масштабируемый протокол. Может использоваться для соединения офисов по типу точка-точка, но, больше всего подходит для организации удаленного подключения по архитектуре клиент-сервер. Достаточно настроить центральный PPTP VPN HUB, а удаленные пользователи подключаются через PPTP клиент, который внедрен во всех OC Windows, в том числе MacOS и Linux-дистрибутивах.
Существуют криптографические проблемы в протоколе аутентификации MSCHAPv2 [https://technet.microsoft.com/ru-ru/library/security/2743314.aspx], поэтому в большинстве случаев рекомендовано использование даже на той же самой OC Windows протокола L2TP over IPSec вместо PPTP.
В качестве средств шифрования используется только

один протокол

шифрования Microsoft Point-to-Point Encryption (128битный ключ), в качестве аутентификации – MSCHAPv2, PEAP (рекомендовано).
PPTP в процессе своей работы устанавливает 2 сессии: PPP сессию с использованием GRE протокола и TCP соединение по порту 1723 для обслуживания PPTP сессии.
Установление TCP сессии перед установлением PPP соединения

 
Формат PPP пакета (рис.15)

PPTP_HUB #
Username cisco2 password cisco2
!
interface Loopback1
 ip address 192.168.2.2 255.255.255.0
!
vpdn enable
!
vpdn-group 1
 ! Default PPTP VPDN group
 accept-dialin
  protocol pptp
  virtual-template 1
!
interface Virtual-Template1
 ip unnumbered Loopback1
 ip mtu 1400
 ip tcp adjust-mss 1360
 peer default ip address pool PPTP-Pool
 ppp encrypt mppe auto
 ppp authentication ms-chap-v2 chap callin
!
ip local pool PPTP-Pool 192.168.2.5 192.168.2.50
!

Проверка установленных PPTP соединений.
Пользователь cisco2 авторизован и сессия установлена.

PPTP_HUB #sho vpdn session
%No active L2TP tunnels
PPTP Session Information Total tunnels 1 sessions 1
LocID RemID TunID Intf    Username      State   Last Chg Uniq ID
55592     0     17168 Vi3        cisco2        estabd  00:04:13      6       

Пользователю выдан ip адрес из DHCP Pool-а и создан virtual-access

PPTP_HUB#sh ip int br
   Interface                IP-Address   OK? Method            Status               Protocol
 Ethernet0/0              unassigned    YES NVRAM     administratively down down
GigabitEthernet0/0  192.168.1.3   YES NVRAM              up                       up
GigabitEthernet1/0      77.1.1.3     YES NVRAM              up                       up
 Loopback0                3.3.3.3      YES NVRAM                up                       up
 Loopback1            192.168.2.2  YES NVRAM                 up                       up
Virtual-Access1        unassigned   YES   unset                down                 down
Virtual-Access2        unassigned   YES   unset                  up                       up
Virtual-Access3      192.168.2.5  YES   unset                   up                       up
Virtual-Template1   192.168.2.5  YES   unset                down                   down

В случае если возникает задача конкретному PPTP клиенту выдавать принадлежащий только ему IP адрес, то тогда можно прибегнуть к созданию TXT файла с перечислением всех PPTP клиентов.
Настройка на маршрутизаторе:

ip dhcp pool STATIC
   import all
   origin file flash:/static2.txt
   default-router 192.168.2.2
   dns-server 8.8.8.8 8.8.4.4
   domain-name lab.local
   lease 3
!
interface Virtual-Template1
 ip unnumbered Loopback1
 ip mtu 1400
 ip tcp adjust-mss 1360
 peer default ip address pool STATIC (PPTP-Pool нам уже не нужен)
 ppp encrypt mppe auto
 ppp authentication ms-chap-v2 chap callin

 
Сам TXT файлик static2.txt.

*time* Mar 01 2002 12:23 AM
*version* 2
    !IP address       Type    Hardware address   Lease expiration   VRF
192.168.2.77 /25             1000c.2984.4f84           Infinite
192.168.2.17 /25             1000c.2946.1575          Infinite
192.168.2.18 /25             10000.0000.1111          Infinite

L2TP

L2TP – это стандарт IETF, который вобрал в себя лучшее от протокола L2F от Cisco и PPTP от Microsoft. Не предлагает средств по защите данных, поэтому часто используется с IPSec.

L2TP – один из немногих представителей VPN протоколов (к тому же доступный для внедрения в корпоративной сети), который может предложить технологию pseudowire – проброс native vlan-а через L3 сеть. Технологию pseudowire поддерживает только L2TP version 3. Кроме этого L2TPv3 поддерживает следующие L2-протоколы, данные (payloads) которых могут прозрачно передаваться через псевдо-туннель L2TPv3:

• Ethernet
• Ethernet VLAN (802.1q)
• HDLC
• PPP
• MPLS

Главное отличие L2TPv3 перед L2TPv2 это то, что L2TPv3 может туннелировать различный тип трафика (см. выше), в то время как v2 только PPP.

L2TPv3 использует два типа сообщений:

• Сигнальные (Control Connection)
• Для данных (Session data)

L2TPv3 сигнальные сообщения так и сообщения с данными могут быть перенесены через IP (protocol ID 115), т.е. L2TPv3 использует меньший overhead

 L2TPv2 инкапсулирует данные в IP/UDP (UDP порт 1701).

L2TPv3 Pseudowire

В архитектуре L2TP, равно как и в архитектуре PPTP, используются следующие понятия:

Модель работы протоколов для L2TPv3 LNS – LNS, а для L2TPv2 LAC – LNS  (подробнее см.ниже).
Создадим pseudowire между R5 в Центральном офисе и в R9 в региональном офисе, тем самым расширим сеть 192.168.1.x/24 в региональный офис.

 
Проверка установления сессии:

 
R7 теперь доступен без протоколов маршрутизации:

R10#ping 192.168.1.7 repeat 10
Type escape sequence to abort.
Sending 10, 100-byte ICMP Echos to 192.168.1.7, timeout is 2 seconds:
!!!!!!!!!!
Success rate is 100 percent (10/10), round-trip min/avg/max = 128/142/180 ms

Работа OSPF через L2TP

Соседство установилось по умолчанию, включив сеть 192.168.1.0 на R7 и R10

 
Недостатки:
Если L2TP создается на маршрутизаторе как в нашем примере, то через pseudowire соединения не пройдут следующие L2 PDU: CDP, STP, VTP, LLDP. Для туннелирования таких протоколов необходимо создавать L2TPv3 туннель на L3 коммутаторе.
Большой минус – мы должны удалить ip адрес на интерфейсе маршрутизатора, который служит маршрутом по умолчанию для всех остальных станций. В итоге у нас ПК остаются без связи с другими сетями.
L2 VPN работает в двух режимах:

• обязательный туннельный режим
• добровольный (опциональный) туннельный режим.

Обязательный туннельный режим относится к провайдер-определяемым (provider provisioning) и в таком режиме работают протоколы L2F, PPTP, L2TP. В обязательном туннельном режиме через L2TP удаленные пользователи подключаются к LAC по обычному PPP соединению, LAC их терминирует на себя и туннелирует PPP сессии к LNS. Причем удаленный пользователь даже не подозревает об L2TP.

 
В добровольном /клиентском инициированном туннеле удаленный хост действует как LAC, то есть он согласует и устанавливает L2TP сессию непосредственно с LNS.

 
В нашем примере Cisco R9 (44.1.1.9) будет действовать как LAC и устанавливать L2TP соединение с Cisco R5 в ЦОДе (55.1.1.1), которая будет выступать в роли LNS.

*Oct 20 19:52:55.861: L2X  tnl   08287:________: Create logical tunnel
*Oct 20 19:52:55.865: L2TP tnl   08287:________: Create tunnel
*Oct 20 19:52:55.869: L2TP tnl   08287:________:     version set to V2 (протокол L2TPv2)
*Oct 20 19:52:55.873: L2TP tnl   08287:________:     remote ip set to 44.1.1.9
*Oct 20 19:52:55.873: L2TP tnl   08287:________:     local ip set to 55.1.1.1
*Oct 20 19:52:55.877: L2TP tnl   08287:00003073: FSM-CC ev Rx-SCCRQ
(Start—Control—Connection—Request) LNS проверяет валидность отправителя и наличие собственных ресурсов, также на этом этапе согласуется список поддерживаемых типов pseudowire (Ethernet, Frame Relay)
*Oct 20 19:52:55.877: L2TP tnl   08287:00003073: FSM-CC    Idle->Proc-SCCRQ
*Oct 20 19:52:55.877: L2TP tnl   08287:00003073: FSM-CC do Rx-SCCRQ
*Oct 20 19:52:55.881: L2X        _____:________: Tunnel author started for LAC
*Oct 20 19:52:55.901: L2X        _____:________: Tunnel author found
*Oct 20 19:52:55.905: L2TP tnl   08287:00003073: Author reply, data source: «VPDN-L2TP»
*Oct 20 19:52:55.909: L2X        _____:________: class [AAA author, group «VPDN-L2TP»]
*Oct 20 19:52:55.913: L2X        _____:________:   created
*Oct 20 19:52:55.917: L2TP tnl   08287:00003073: FSM-CC ev SCCRQ-OK
*Oct 20 19:52:55.917: L2TP tnl   08287:00003073: FSM-CC    Proc-SCCRQ->Wt-SCCCN
Start-Control-Connection-Connected (SCCCN) ожидаем состояния Connected
*Oct 20 19:52:55.917: L2TP tnl   08287:00003073: FSM-CC do Tx-SCCRP
Start-Control-Connection-Reply (SCCRP) отправили ответное сообщение
*Oct 20 19:52:55.917: L2X        _____:________: l2x_open_socket: is called
*Oct 20 19:52:55.921: L2TP tnl   08287:00003073: Open sock 55.1.1.1:1701->44.1.1.9:1701
Используется UDP с портом 1701 для служебных сообщений
*Oct 20 19:52:55.925: L2TP tnl   08287:00003073: FSM-CC ev Sock-Ready
*Oct 20 19:52:55.929: L2TP tnl   08287:00003073: FSM-CC    in Wt-SCCCN
*Oct 20 19:52:55.929: L2TP tnl   08287:00003073: FSM-CC do Ignore-Sock-Up
*Oct 20 19:52:55.941: L2X        _____:________: Disabled security for VPDN
*Oct 20 19:52:56.053: L2TP tnl   08287:00003073: FSM-CC ev Rx-SCCCN
*Oct 20 19:52:56.053: L2TP tnl   08287:00003073: FSM-CC    Wt-SCCCN->Proc-SCCCN
*Oct 20 19:52:56.053: L2TP tnl   08287:00003073: FSM-CC do Rx-SCCCN
*Oct 20 19:52:56.053: L2TP tnl   08287:00003073: Got a response in SCCCN from LAC
*Oct 20 19:52:56.057: L2TP tnl   08287:00003073: Tunnel Authentication success
*Oct 20 19:52:56.061: L2TP tnl   08287:00003073: FSM-CC ev SCCCN-OK
*Oct 20 19:52:56.065: L2TP tnl   08287:00003073: FSM-CC    Proc-SCCCN->established
*Oct 20 19:52:56.069: L2TP tnl   08287:00003073: FSM-CC do Established
*Oct 20 19:52:56.073: L2TP tnl   08287:00003073: Control channel up
*Oct 20 19:52:56.077: L2TP tnl   08287:00003073:   55.1.1.1<->44.1.1.9

 
Служебный канал установился, теперь устанавливается канал для данных (PPP фреймов).
Стоит отметить, что по одному установившемуся туннелю может проходить множество клиентских сессий.

 

Для установки сессии для данных LAC отправляет ICRQ (Call-Request), если на LNS достаточно ресурсов, то LNS отвечает сообщением ICRP (Call-Reply). Для завершения установления сессии – LAC отправляет ICCN Incoming-Call-Connected.

*Oct 20 19:52:56.117: L2X  _____:_____:________: Create logical session
*Oct 20 19:52:56.121: L2TP _____:_____:________: Create session
*Oct 20 19:52:56.121: L2TP _____:_____:________:   Using ICRQ FSM
Incoming-Call-Request (ICRQ) Здесь передается требуемый pseudowire тип, требуемый для уровня L2
*Oct 20 19:52:56.125: L2TP _____:_____:________:     remote ip set to 44.1.1.9
*Oct 20 19:52:56.125: L2TP _____:_____:________:     local ip set to 55.1.1.1
*Oct 20 19:52:56.129: L2TP tnl   08287:00003073: FSM-CC ev Session-Conn
*Oct 20 19:52:56.129: L2TP tnl   08287:00003073: FSM-CC    in established
*Oct 20 19:52:56.129: L2TP tnl   08287:00003073: FSM-CC do Session-Conn-Est
*Oct 20 19:52:56.129: L2TP tnl   08287:00003073:   Session count now 1
*Oct 20 19:52:56.129: L2TP _____:08287:0000754C: Session attached
*Oct 20 19:52:56.129: L2TP _____:08287:0000754C: FSM-Sn ev Rx-ICRQ
*Oct 20 19:52:56.129: L2TP _____:08287:0000754C: FSM-Sn    Idle->Proc-ICRQ
*Oct 20 19:52:56.129: L2TP _____:08287:0000754C: FSM-Sn do Rx-ICRQ
*Oct 20 19:52:56.129: L2TP _____:08287:0000754C:   Chose application VPDN
*Oct 20 19:52:56.133: L2TP _____:08287:0000754C:   App type set to VPDN
*Oct 20 19:52:56.133: L2TP tnl   08287:00003073:   VPDN Session count now 1
*Oct 20 19:52:56.189: L2TP 00005:08287:0000754C: FSM-Sn ev ICRQ-OK
*Oct 20 19:52:56.193: L2TP 00005:08287:0000754C: FSM-Sn    Proc-ICRQ->Wt-Tx-ICRP
*Oct 20 19:52:56.193: L2TP 00005:08287:0000754C: FSM-Sn do Tx-ICRP-Local-Check
*Oct 20 19:52:56.193: L2TP 00005:08287:0000754C: FSM-Sn ev Local-Cont
*Oct 20 19:52:56.193: L2TP 00005:08287:0000754C: FSM-Sn    Wt-Tx-ICRP->Wt-Rx-ICCN
*Oct 20 19:52:56.193: L2TP 00005:08287:0000754C: FSM-Sn do Tx-ICRP
Incoming-Call-Reply (ICRP)
*Oct 20 19:52:56.197: L2TP 00005:08287:0000754C: Open sock 55.1.1.1:1701->44.1.1.9:1701
*Oct 20 19:52:56.197: L2TP 00005:08287:0000754C: FSM-Sn    in Wt-Rx-ICCN    (ожидаем ICCN)
*Oct 20 19:52:56.397: L2TP 00005:08287:0000754C: FSM-Sn ev Rx-ICCN             (ICCN получили)
*Oct 20 19:52:56.401: L2TP 00005:08287:0000754C: FSM-Sn    Wt-Rx-ICCN->Proc-ICCN
*Oct 20 19:52:56.405: L2TP 00005:08287:0000754C: FSM-Sn do Rx-ICCN
*Oct 20 19:52:56.437: L2TP 00005:08287:0000754C: FSM-Sn ev ICCN-OK
*Oct 20 19:52:56.441: L2TP 00005:08287:0000754C: FSM-Sn    Proc-ICCN->established
*Oct 20 19:52:56.445: L2TP 00005:08287:0000754C: FSM-Sn do Established
*Oct 20 19:52:56.449: L2TP 00005:08287:0000754C: Session up      (Ceccия для данных установилась)
*Oct 20 19:52:58.197: L2TP 00005:08287:0000754C: FSM-Sn    in established
*Oct 20 19:52:58.241: %LINEPROTO-5-UPDOWN: Line protocol on Interface Virtual-Access3, changed state to up
*Oct 20 19:52:58.273: %LINK-3-UPDOWN: Interface Virtual-Access3, changed state to up

 
В нашем примере сформировался один туннель между LAS и LNS и одна пользовательская сессия.

Настройка L2TP в добровольном туннельном режиме очень похожа в настройке с обязательным туннельным режимом. Различие в настройке VPDN группы следующее:

• Команда terminate-from не нужна
• Аутентификация L2TP туннеля выключена командой no l2tp tunnel authentication

Настройка L2TPv2

На некоторых типах маршрутизаторов нельзя создать interface virtual-ppp, поэтому привожу в качестве альтернативны другую рабочую конфигурацию через создание interface Dialer. Конфигурация предоставляется «AS IS».

 
Конфигурация L2TPv2 через interface virtual-ppp

Проверка установления туннеля и заодно проверяем работу сессии через пинг с внутренней сети удаленного клиента (LAC) и просмотра статистики сессионных пакетов на L2TP HUBe (LNS)

 
Формат пакета L2TPv2

Overhead UDP (8байт) + L2TPv2 (8байт) + PPP (4 байта) +IPv4 (20 байт) = 40байт

Работа OSPF через L2TPv2

 
LSA протокола OSPF через L2TPv2
Обратите, пожалуйста, внимание на получившийся overhead.

 

Overhead UDP (8байт) + L2TPv2 (8байт) + PPP (4 байта) +IPv4 (20 байт) = 40байт
Проверка установленного соседства

Настройка для L2TPv3

 

Настройка L2TPv3 практически ничем не отличается на удаленных клиентах, в то время как настройка на VPN HUB-е отличается очень разительно.

 
Проверка установленной L2TPv3 сессии на LNS

 
Проверка установленной L2TPv3 сессии на LAC

 
Формат пакета L2TPv3

Overhead L2TPv3 (4байта) + HDLC (4байта) = 8 байт

Проверяем работу сессии через пинг с внутренней сети удаленного клиента (LAC) и просмотра статистики сессионных пакетов на L2TP HUBe (LNS)

L2TPv2 over IPSec

Протокол L2TP не обеспечивает защищенность передаваемых по нему данных, поэтому для обеспечения целостности и конфиденциальности данных используем набор протоколов IPSec. Из средств безопасности L2TP может предложить аутентификацию хоста, инициализирующего туннель, а также PPP аутентификацию. Так как в нашем примере использован протокол L2TPv2, который использует IP/UDP инкапсуляцию, то достаточно в крипто ACL определить лишь UDP трафик по порту 1701. В настройке IPSec используется транспортный режим, а не туннельный, чтобы шифровать трафик от оконечного клиента оконечному (в транспортном режиме), нежели создавать дополнительные IP туннельные интерфейсы и шифровать трафик только между ними (в туннельном режиме).

 
Схема сети:

 
Проверяем работу сессии через пинг с внутренней сети удаленного клиента (LAC) и просмотра статистики сессионных пакетов на L2TP HUBe (LNS)

 
Формат пакета L2TPv2 over IPSec

Формат пакета IP | ESP header | UDP | L2TP | PPP | ESP trailer | Auth trailer
Overhead ESP_header (8байт) + UDP (8байт) + L2TPv2 (8байт) + PPP (4 байта) + ESP_trailer (min 2байта) + SHA_auth (160бит =  20 байт) =

50 бaйт

Работа OSPF over L2TPv2 over IPSec

Соседство через OSPF не было потеряно, hello пакеты по-прежнему приходят через каждый 10 сек. Маршруты анонсируются через удаленный OSPF соседний маршрутизатор.

Масштабирование. Подключение нового удаленного офиса через L2TPv2

Настройка для LNS, т.е. для L2TPv2 HUBа минимальная – необходимо лишь добавить пользователя для PPP CHAP авторизации. Если этого не сделать, то будет следующая ошибка:

*Nov  9 10:31:35.178: VPDN uid:123 disconnect (AAA) IETF: 17/user-error Ascend: 26/PPP CHAP Fail
*Nov  9 10:31:35.178: VPDN uid:123 vpdn shutdown session, result=2, error=6, vendor_err=0, syslog_error_code=8, syslog_key_type=1

 
Добавляем второго LAC

 
После этого на LNS уже 2 туннеля

 
Работа OSPF в L2TPv2
В случае подключение удаленных офисов через L2TPv2 – нет ограничений в использовании динамических протоколов маршрутизации. Для включения OSPF заведем на каждом удаленном маршрутизаторе по сети на loopback-е:

 
Проверяем OSPF соседство и настроенные маршруты

 
В случае не использования OSPF, каждое добавление нового регионального офиса требует статического добавления маршрутов на каждом существующем маршрутизаторе (и региональном и L2TP HUBe) с адресом достижения – ip адрес ppp интерфейса.
В случае хорошего дизайна распределения IP адресов мы можем ограничиться тем, что на региональных маршрутизаторах 1 раз добавили суммарный маршрут до всей внутренних региональных сетей, например 192.168.25.0/24 на interface virtual-ppp VPN HUBa, тогда при подключении новой подсети а-ля 192.168.25.16/29 нам не нужно будет ничего добавлять на региональных маршрутизаторах, останется только лишь на VPN HUBе указать за каким vitual-ppp интерфейсом нового регионального маршрутизатора находится эта сеть:
HUB(conf)#ip route 192.168.25.16 255.255.255.248 16.16.16.16 (<- где 16.16.16.16 это virtual-ppp интерфейс нового регионального маршрутизатора, и который в таблице маршрутизации VPN HUBa будет выглядеть как непосредственно подключенный:

C        16.16.16.16 is directly connected, Virtual-Access4)

Спасибо самым стойким и усидчивым читателям, дошедшим до конца данной статьи, за ваше внимание и терпение. Как я уже отмечал в начале статьи, мне бы хотелось, чтобы данный обзор стал небольшим сборником и справочным материалом, который необязательно помнить наизусть, но к которому можно всегда обратиться. Надеюсь, что это реально поможет моим коллегам по «цеху» учесть нюансы в построении качественного, красивого и грамотного сетевого дизайна, избежать подводных камней и в целом сделать свою работу на высшем уровне! С вами был Семенов Вадим.

P.S.
Ну и на десерт: для любопытных и пытливых умов, желающих ознакомиться поглубже в способе инкапсуляции того или иного типа VPN-а, поглубже разобраться в формате различных заголовков — возможно скачать дампы пакетов, собранных при обзоре указанных выше VPN-ов здесь.

С радостью отвечу на возникшие вопросы по статье.

Black-Dragon

Dmitry[kiev]

Izobretatel

Dmitry[kiev]

Black-Dragon

Dmitry[kiev]

gvur

Hi all, I have problem with L2TP/IPSec configuration in Cisco Router 2911 . I cannot connect via Windows 7,8.1,10 build in vpn client.

Here is my config :

aaa new-model 
aaa authentication ppp L2TP-LOGIN local     
username l2tpuser password cisco     
! 
vpdn enable     
vpdn-group L2TP-GR     
description L2TP over IPSec    
accept-dialin     
protocol l2tp     
virtual-template 2    
exit 

no l2tp tunnel authentication     
session-limit 20 

exit 
! 
ip local pool L2TP-POOL 172.16.23.100 172.16.23.200     
interface Virtual-Template2     
description L2TP over IPSec Template     
ip unnumbered FastEthernet0/1     
peer default ip address pool L2TP-POOL     
no keepalive     
ppp authentication ms-chap-v2 L2TP-LOGIN     
ppp mtu adaptive     
exit 
! 
crypto isakmp enable     
crypto logging session     
crypto isakmp invalid-spi-recovery    
! 
crypto isakmp policy 20     
encr 3des     
authentication pre-share     
group 2     
hash md5    
exit 
! 
crypto keyring L2TP-KEY     
pre-shared-key address 0.0.0.0 0.0.0.0 key cisco123cisco     
exit 
! 
crypto isakmp profile L2TP-PROF     
keyring L2TP-KEY     
match identity address 0.0.0.0     
exit 
! 
crypto ipsec transform-set L2TP-TRSET esp-3des esp-md5-hmac     
mode transport     
exit 
! 
crypto dynamic-map DYN-L2TP-MAP 10     
set isakmp-profile L2TP-PROF     
set transform-set L2TP-TRSET     
set nat demux     
exit     
! 
crypto map L2TP-MAP 65535 ipsec-isakmp dynamic DYN-L2TP-MAP     
! 
interface gi0/0    
description WAN    
crypto map L2TP-MAP     
exit 
! 

What’s the problem? Where am I wrong?

Updated

.Apr  3 08:16:16.610: ISAKMP (1070): received packet from 192.168.7.92 dport 
500 sport 500 Global (R) QM_IDLE
.Apr  3 08:16:16.610: ISAKMP: set new node -1169728138 to QM_IDLE
.Apr  3 08:16:16.610: crypto_engine: Decrypt IKE packet
.Apr  3 08:16:16.610: crypto_engine: Generate IKE hash
.Apr  3 08:16:16.610: ISAKMP:(1070): processing HASH payload. message ID = 
3125239158
.Apr  3 08:16:16.610: ISAKMP:(1070): processing DELETE payload. message ID = 
3125239158
.Apr  3 08:16:16.610: ISAKMP:(1070):peer does not do paranoid keepalives.

.Apr  3 08:16:16.610: ISAKMP:(1070):deleting node -1169728138 error FALSE 
reason "Informational (in) state 1"
.Apr  3 08:16:16.610: ISAKMP (1070): received packet from 192.168.7.92 dport 
500 sport 500 Global (R) QM_IDLE
.Apr  3 08:16:16.610: ISAKMP: set new node -1213364179 to QM_IDLE
.Apr  3 08:16:16.610: crypto_engine: Decrypt IKE packet
.Apr  3 08:16:16.610: crypto_engine: Generate IKE hash
.Apr  3 08:16:16.610: ISAKMP:(1070): processing HASH payload. message ID = 
3081603117
.Apr  3 08:16:16.614: ISAKMP:(1070): processing DELETE payload. message ID = 
3081603117
.Apr  3 08:16:16.614: ISAKMP:(1070):peer does not do paranoid keepalives.

.Apr  3 08:16:16.614: ISAKMP:(1070):deleting SA reason "No reason" state (R) 
QM_IDLE       (peer 192.168.7.92)
.Apr  3 08:16:16.614: ISAKMP:(1070):deleting node -1213364179 error FALSE 
reason "Informational (in) state 1"
.Apr  3 08:16:16.618: IPSEC(key_engine): got a queue event with 1 KMI 
message(s)
.Apr  3 08:16:16.618: IPSEC(key_engine_delete_sas): rec'd delete notify from 
ISAKMP
.Apr  3 08:16:16.618: IPSEC(key_engine_delete_sas): delete SA with spi 
0x3D3ED559 proto 50 for 192.168.7.92
.Apr  3 08:16:16.618: crypto_engine: Pull flow statistics
.Apr  3 08:16:16.618: crypto_engine_ipsec_flow_pull_statistics: calling 
driver
.Apr  3 08:16:16.618: ISAKMP: set new node -1561337744 to QM_IDLE
.Apr  3 08:16:16.618: crypto_engine: Generate IKE hash
.Apr  3 08:16:16.618: crypto_engine: Encrypt IKE packet
.Apr  3 08:16:16.618: ISAKMP:(1070): sending packet to 192.168.7.92 my_port 
500 peer_port 500 (R) QM_IDLE
.Apr  3 08:16:16.618: ISAKMP:(1070):Sending an IKE IPv4 Packet.
.Apr  3 08:16:16.618: ISAKMP:(1070):purging node -1561337744
.Apr  3 08:16:16.618: ISAKMP:(1070):Input = IKE_MESG_INTERNAL, 
IKE_PHASE1_DEL
.Apr  3 08:16:16.618: ISAKMP:(1070):Old State = IKE_P1_COMPLETE  New State = 
IKE_DEST_SA

.Apr  3 08:16:16.618: ISAKMP:(1070):deleting SA reason "No reason" state (R) 
QM_IDLE       (peer 192.168.7.92)
.Apr  3 08:16:16.618: ISAKMP: Unlocking peer struct 0x3DB5A12C for 
isadb_mark_sa_deleted(), count 0
.Apr  3 08:16:16.622: crypto engine: deleting IKE SA SW:70
.Apr  3 08:16:16.622: crypto_engine: Delete IKE SA
.Apr  3 08:16:16.622: IKE HA: Removing one interface using VIP 0.0.0.0
.Apr  3 08:16:16.622: IKE HA: No database for VIP 0.0.0.0.  Cannot delete
.Apr  3 08:16:16.622: IPSec HA: Removing one interface using VIP 0.0.0.0
.Apr  3 08:16:16.622: IPSec HA: No database for VIP 0.0.0.0.  Cannot delete
.Apr  3 08:16:16.622: ISAKMP:(1070):Input = IKE_MESG_FROM_PEER, IKE_MM_EXCH
.Apr  3 08:16:16.622: ISAKMP:(1070):Old State = IKE_DEST_SA  New State = 
IKE_DEST_SA

.Apr  3 08:16:16.622: crypto_engine: Pull sadb-ivrf statistics
.Apr  3 08:16:16.622: crypto_engine_ipsec_sadb_ivrf_pull_statistics: call 
driver
.Apr  3 08:16:16.622: crypto_engine: Pull sadb-ivrf statistics, got error 
unsupported operation
.Apr  3 08:16:16.622:  ISAKMP: Failed to find peer index node to update 
peer_info_list
.Apr  3 08:16:16.622: IPSEC(update_current_outbound_sa): updated peer 
192.168.7.92 current outbound sa to SPI 3D3ED559
.Apr  3 08:16:16.622: IPSEC(delete_sa): deleting SA,
(sa) sa_dest= XX, sa_proto= 50,
sa_spi= 0x6D6766BE(1835493054),
sa_trans= esp-3des esp-sha-hmac , sa_conn_id= 2109
sa_lifetime(k/sec)= (250000/3600),
(identity) local= XX:0, remote= 192.168.7.92:0,
local_proxy= XX/ 255.255.255.255/17/1701,
remote_proxy= 192.168.7.92/255.255.255.255/17/1701
.Apr  3 08:16:16.622: IPSEC(update_current_outbound_sa): updated peer 
192.168.7.92 current outbound sa to SPI 3D3ED559
.Apr  3 08:16:16.622: IPSEC(delete_sa): deleting SA,
(sa) sa_dest= 192.168.7.92, sa_proto= 50,
sa_spi= 0x3D3ED559(1027528025),
sa_trans= esp-3des esp-sha-hmac , sa_conn_id= 2110
sa_lifetime(k/sec)= (250000/3600),

(identity) local= XX:0, remote= 192.168.7.92:0,
local_proxy= XX/255.255.255.255/17/1701,
remote_proxy= 192.168.7.92/255.255.255.255/17/1701
.Apr 3 08:16:16.622: crypto engine: deleting IPSec SA Onboard VPN:109
.Apr 3 08:16:16.626: crypto_engine: Delete IPSec SA
.Apr 3 08:16:16.626: crypto engine: deleting IPSec SA Onboard VPN:110
.Apr 3 08:16:16.630: crypto_engine: Delete IPSec SA
.Apr 3 08:16:16.634: %CRYPTO-5-SESSION_STATUS: Crypto tunnel is DOWN. Peer
192.168.7.92:500 Id: 192.168.7.92
ATVRouter#
.Apr 3 08:16:16.634: ISAKMP: Deleting peer node by peer_reap for
192.168.7.92: 3DB5A12C
.Apr 3 08:16:16.634: IPSEC(key_engine): got a queue event with 1 KMI
message(s)
ATVRouter#
.Apr 3 08:16:20.082: ISAKMP (0): received packet from 192.168.7.92 dport 500
sport 500 Global (N) NEW SA
.Apr 3 08:16:20.082: ISAKMP: Created a peer struct for 192.168.7.92, peer
port 500
.Apr 3 08:16:20.082: ISAKMP: New peer created peer = 0x23781594 peer_handle
= 0x80000065
.Apr 3 08:16:20.082: ISAKMP: Locking peer struct 0x23781594, refcount 1 for
crypto_isakmp_process_block
.Apr 3 08:16:20.082: ISAKMP: local port 500, remote port 500
.Apr 3 08:16:20.082: ISAKMP: Find a dup sa in the avl tree during calling
isadb_insert sa = 3DA06FE8
.Apr 3 08:16:20.082: ISAKMP:(0):Input = IKE_MESG_FROM_PEER, IKE_MM_EXCH
.Apr 3 08:16:20.082: ISAKMP:(0):Old State = IKE_READY New State = IKE_R_MM1

.Apr 3 08:16:20.082: ISAKMP:(0): processing SA payload. message ID = 0
.Apr 3 08:16:20.082: ISAKMP:(0): processing vendor id payload
.Apr 3 08:16:20.082: ISAKMP:(0): processing IKE frag vendor id payload
.Apr 3 08:16:20.082: ISAKMP:(0):Support for IKE Fragmentation not enabled
.Apr 3 08:16:20.082: ISAKMP:(0): processing vendor id payload
.Apr 3 08:16:20.086: ISAKMP:(0): vendor ID seems Unity/DPD but major 69
mismatch
.Apr 3 08:16:20.086: ISAKMP (0): vendor ID is NAT-T RFC 3947
.Apr 3 08:16:20.086: ISAKMP:(0): processing vendor id payload
.Apr 3 08:16:20.086: ISAKMP:(0): vendor ID seems Unity/DPD but major 123
mismatch
.Apr 3 08:16:20.086: ISAKMP:(0): vendor ID is NAT-T v2
.Apr 3 08:16:20.086: ISAKMP:(0): processing vendor id payload
.Apr 3 08:16:20.086: ISAKMP:(0): vendor ID seems Unity/DPD but major 194
mismatch
.Apr 3 08:16:20.086: ISAKMP:(0): processing vendor id payload
.Apr 3 08:16:20.086: ISAKMP:(0): vendor ID seems Unity/DPD but major 241
mismatch
.Apr 3 08:16:20.086: ISAKMP:(0): processing vendor id payload
.Apr 3 08:16:20.086: ISAKMP:(0): vendor ID seems Unity/DPD but major 184
mismatch
.Apr 3 08:16:20.086: ISAKMP:(0): processing vendor id payload
.Apr 3 08:16:20.086: ISAKMP:(0): vendor ID seems Unity/DPD but major 134
mismatch
.Apr 3 08:16:20.086: ISAKMP:(0):found peer pre-shared key matching
192.168.7.92
.Apr 3 08:16:20.086: ISAKMP:(0): local preshared key found
.Apr 3 08:16:20.086: ISAKMP : Scanning profiles for xauth …
.Apr 3 08:16:20.086: ISAKMP:(0):Checking ISAKMP transform 1 against priority
1 policy
.Apr 3 08:16:20.086: ISAKMP: encryption AES-CBC
.Apr 3 08:16:20.086: ISAKMP: keylength of 256
.Apr 3 08:16:20.086: ISAKMP: hash SHA
.Apr 3 08:16:20.086: ISAKMP: default group 20
.Apr 3 08:16:20.086: ISAKMP: auth pre-share
.Apr 3 08:16:20.086: ISAKMP: life type in seconds
.Apr 3 08:16:20.086: ISAKMP: life duration (VPI) of 0x0 0x0 0x70 0x80
.Apr 3 08:16:20.086: ISAKMP:(0):Encryption algorithm offered does not match
policy!
.Apr 3 08:16:20.086: ISAKMP:(0):atts are not acceptable. Next payload is 3
.Apr 3 08:16:20.086: ISAKMP:(0):Checking ISAKMP transform 2 against priority
1 policy
.Apr 3 08:16:20.086: ISAKMP: encryption AES-CBC
.Apr 3 08:16:20.086: ISAKMP: keylength of 128
.Apr 3 08:16:20.086: ISAKMP: hash SHA
.Apr 3 08:16:20.086: ISAKMP: default group 19
.Apr 3 08:16:20.086: ISAKMP: auth pre-share
.Apr 3 08:16:20.086: ISAKMP: life type in seconds
.Apr 3 08:16:20.086: ISAKMP: life duration (VPI) of 0x0 0x0 0x70 0x80
.Apr 3 08:16:20.086: ISAKMP:(0):Encryption algorithm offered does not match
policy!
.Apr 3 08:16:20.086: ISAKMP:(0):atts are not acceptable. Next payload is 3
.Apr 3 08:16:20.086: ISAKMP:(0):Checking ISAKMP transform 3 against priority
1 policy
.Apr 3 08:16:20.086: ISAKMP: encryption AES-CBC
.Apr 3 08:16:20.086: ISAKMP: keylength of 256
.Apr 3 08:16:20.086: ISAKMP: hash SHA
.Apr 3 08:16:20.086: ISAKMP: default group 14
.Apr 3 08:16:20.086: ISAKMP: auth pre-share
.Apr 3 08:16:20.086: ISAKMP: life type in seconds
.Apr 3 08:16:20.086: ISAKMP: life duration (VPI) of 0x0 0x0 0x70 0x80
.Apr 3 08:16:20.090: ISAKMP:(0):Encryption algorithm offered does not match
policy!
.Apr 3 08:16:20.090: ISAKMP:(0):atts are not acceptable. Next payload is 3
.Apr 3 08:16:20.090: ISAKMP:(0):Checking ISAKMP transform 4 against priority
1 policy
.Apr 3 08:16:20.090: ISAKMP: encryption 3DES-CBC
.Apr 3 08:16:20.090: ISAKMP: hash SHA
.Apr 3 08:16:20.090: ISAKMP: default group 14
.Apr 3 08:16:20.090: ISAKMP: auth pre-share
.Apr 3 08:16:20.090: ISAKMP: life type in seconds

.Apr 3 08:16:20.090: ISAKMP: life duration (VPI) of 0x0 0x0 0x70 0x80

.Apr 3 08:16:20.090: ISAKMP:(0):Diffie-Hellman group offered does not match

policy!
.Apr 3 08:16:20.090: ISAKMP:(0):atts are not acceptable. Next payload is 3

.Apr 3 08:16:20.090: ISAKMP:(0):Checking ISAKMP transform 5 against priority 1

policy
.Apr 3 08:16:20.090: ISAKMP: encryption 3DES-CBC

.Apr 3 08:16:20.090: ISAKMP: hash SHA

.Apr 3 08:16:20.090: ISAKMP: default group 2

.Apr 3 08:16:20.090: ISAKMP: auth pre-share

.Apr 3 08:16:20.090: ISAKMP: life type in seconds

.Apr 3 08:16:20.090: ISAKMP: life duration (VPI) of 0x0 0x0 0x70 0x80

.Apr 3 08:16:20.090: ISAKMP:(0):atts are acceptable. Next payload is 0

.Apr 3 08:16:20.090: ISAKMP:(0):Acceptable atts:actual life: 0

.Apr 3 08:16:20.090: ISAKMP:(0):Acceptable atts:life: 0

.Apr 3 08:16:20.090: ISAKMP:(0):Fill atts in sa vpi_length:4

.Apr 3 08:16:20.090: ISAKMP:(0):Fill atts in sa life_in_seconds:28800

.Apr 3 08:16:20.090: ISAKMP:(0):Returning Actual lifetime: 28800

.Apr 3 08:16:20.090: ISAKMP:(0)::Started lifetime timer: 28800.

.Apr 3 08:16:20.090: ISAKMP:(0): processing vendor id payload

.Apr 3 08:16:20.090: ISAKMP:(0): processing IKE frag vendor id payload

.Apr 3 08:16:20.090: ISAKMP:(0):Support for IKE Fragmentation not enabled

.Apr 3 08:16:20.090: ISAKMP:(0): processing vendor id payload

.Apr 3 08:16:20.094: ISAKMP:(0): vendor ID seems Unity/DPD but major 69

mismatch

.Apr 3 08:16:20.094: ISAKMP (0): vendor ID is NAT-T RFC 3947

.Apr 3 08:16:20.094: ISAKMP:(0): processing vendor id payload

.Apr 3 08:16:20.094: ISAKMP:(0): vendor ID seems Unity/DPD but major 123

mismatch

.Apr 3 08:16:20.094: ISAKMP:(0): vendor ID is NAT-T v2

.Apr 3 08:16:20.094: ISAKMP:(0): processing vendor id payload

.Apr 3 08:16:20.094: ISAKMP:(0): vendor ID seems Unity/DPD but major 194

mismatch

.Apr 3 08:16:20.094: ISAKMP:(0): processing vendor id payload

.Apr 3 08:16:20.094: ISAKMP:(0): vendor ID seems Unity/DPD but major 241

mismatch

.Apr 3 08:16:20.094: ISAKMP:(0): processing vendor id payload

.Apr 3 08:16:20.094: ISAKMP:(0): vendor ID seems Unity/DPD but major 184

mismatch

.Apr 3 08:16:20.094: ISAKMP:(0): processing vendor id payload

.Apr 3 08:16:20.094: ISAKMP:(0): vendor ID seems Unity/DPD but major 134

mismatch

.Apr 3 08:16:20.094: ISAKMP:(0):Input = IKE_MESG_INTERNAL,

IKE_PROCESS_MAIN_MODE

.Apr 3 08:16:20.094: ISAKMP:(0):Old State = IKE_R_MM1 New State = IKE_R_MM1

.Apr 3 08:16:20.094: ISAKMP:(0): constructed NAT-T vendor-rfc3947 ID

.Apr 3 08:16:20.094: ISAKMP:(0): sending packet to 192.168.7.92 my_port 500
peer_port 500 (R) MM_SA_SETUP

.Apr 3 08:16:20.094: ISAKMP:(0):Sending an IKE IPv4 Packet.

.Apr 3 08:16:20.098: ISAKMP:(0):Input = IKE_MESG_INTERNAL, IKE_PROCESS_COMPLETE

.Apr 3 08:16:20.098: ISAKMP:(0):Old State = IKE_R_MM1 New State = IKE_R_MM2

.Apr 3 08:16:20.106: ISAKMP (0): received packet from 192.168.7.92 dport 500

sport 500 Global (R) MM_SA_SETUP

.Apr 3 08:16:20.106: ISAKMP:(0):Input = IKE_MESG_FROM_PEER, IKE_MM_EXCH

.Apr 3 08:16:20.106: ISAKMP:(0):Old State = IKE_R_MM2 New State = IKE_R_MM3

.Apr 3 08:16:20.106: ISAKMP:(0): processing KE payload. message ID = 0

.Apr 3 08:16:20.106: crypto_engine: Create DH shared secret

.Apr 3 08:16:20.162: ISAKMP:(0): processing NONCE payload. message ID = 0

.Apr 3 08:16:20.162: ISAKMP:(0):found peer pre-shared key matching 192.168.7.92

.Apr 3 08:16:20.162: crypto_engine: Create IKE SA

.Apr 3 08:16:20.162: crypto engine: deleting DH phase 2 SW:75

.Apr 3 08:16:20.162: crypto_engine: Delete DH shared secret

.Apr 3 08:16:20.162: ISAKMP:received payload type 20

.Apr 3 08:16:20.162: ISAKMP (1071): His hash no match — this node outside NAT

.Apr 3 08:16:20.162: ISAKMP:received payload type 20

.Apr 3 08:16:20.162: ISAKMP (1071): No NAT Found for self or peer

.Apr 3 08:16:20.162: ISAKMP:(1071):Input = IKE_MESG_INTERNAL,

IKE_PROCESS_MAIN_MODE

.Apr 3 08:16:20.162: ISAKMP:(1071):Old State = IKE_R_MM3 New State = IKE_R_MM3

.Apr 3 08:16:20.162: ISAKMP:(1071): sending packet to 192.168.7.92 my_port 500

peer_port 500 (R) MM_KEY_EXCH

.Apr 3 08:16:20.162: ISAKMP:(1071):Sending an IKE IPv4 Packet.

.Apr 3 08:16:20.166: ISAKMP:(1071):Input = IKE_MESG_INTERNAL,

IKE_PROCESS_COMPLETE

.Apr 3 08:16:20.166: ISAKMP:(1071):Old State = IKE_R_MM3 New State = IKE_R_MM4

.Apr 3 08:16:20.166: ISAKMP (1071): received packet from 192.168.7.92 dport 500

sport 500 Global (R) MM_KEY_EXCH

.Apr 3 08:16:20.166: crypto_engine: Decrypt IKE packet

.Apr 3 08:16:20.166: ISAKMP:(1071):Input = IKE_MESG_FROM_PEER, IKE_MM_EXCH

.Apr 3 08:16:20.166: ISAKMP:(1071):Old State = IKE_R_MM4 New State = IKE_R_MM5

.Apr 3 08:16:20.170: ISAKMP:(1071): processing ID payload. message ID = 0

.Apr 3 08:16:20.170: ISAKMP (1071): ID payload

    next-payload : 8

    type         : 1

    address      : 192.168.7.92

    protocol     : 0

    port         : 0

    length       : 12

.Apr 3 08:16:20.170: ISAKMP:(0):: peer matches none of the profiles

.Apr 3 08:16:20.170: ISAKMP:(1071): processing HASH payload. message ID = 0

.Apr 3 08:16:20.170: crypto_engine: Generate IKE hash

.Apr 3 08:16:20.170: ISAKMP:(1071):SA authentication status:

    authenticated

.Apr 3 08:16:20.170: ISAKMP:(1071):SA has been authenticated with 192.168.7.92

.Apr 3 08:16:20.170: ISAKMP: Trying to insert a peer

XX/192.168.7.92/500/, and inserted successfully 23781594.

.Apr 3 08:16:20.170: ISAKMP:(1071):Input = IKE_MESG_INTERNAL,
IKE_PROCESS_MAIN_MODE
.Apr 3 08:16:20.170: ISAKMP:(1071):Old State = IKE_R_MM5 New State = IKE_R_MM5

.Apr 3 08:16:20.170: ISAKMP:(1071):SA is doing pre-shared key authentication using id type ID_IPV4_ADDR
.Apr 3 08:16:20.170: ISAKMP (1071): ID payload
next-payload : 8
type : 1
address : XX
protocol : 17
port : 500
length : 12
.Apr 3 08:16:20.170: ISAKMP:(1071):Total payload length: 12
.Apr 3 08:16:20.170: crypto_engine: Generate IKE hash
.Apr 3 08:16:20.170: crypto_engine: Encrypt IKE packet
.Apr 3 08:16:20.170: ISAKMP:(1071): sending packet to 192.168.7.92 my_port 500 peer_port 500 (R) MM_KEY_EXCH
.Apr 3 08:16:20.170: ISAKMP:(1071):Sending an IKE IPv4 Packet.
.Apr 3 08:16:20.170: ISAKMP:(1071):Input = IKE_MESG_INTERNAL, IKE_PROCESS_COMPLETE
.Apr 3 08:16:20.170: ISAKMP:(1071):Old State = IKE_R_MM5 New State = IKE_P1_COMPLETE

.Apr 3 08:16:20.170: ISAKMP:(1071):Input = IKE_MESG_INTERNAL, IKE_PHASE1_COMPLETE
.Apr 3 08:16:20.170: ISAKMP:(1071):Old State = IKE_P1_COMPLETE New State = IKE_P1_COMPLETE

.Apr 3 08:16:20.170: ISAKMP (1071): received packet from 192.168.7.92 dport 500 sport 500 Global (R) QM_IDLE
.Apr 3 08:16:20.170: ISAKMP: set new node 1 to QM_IDLE
.Apr 3 08:16:20.170: crypto_engine: Decrypt IKE packet
.Apr 3 08:16:20.174: crypto_engine: Generate IKE hash
.Apr 3 08:16:20.174: ISAKMP:(1071): processing HASH payload. message ID = 1
.Apr 3 08:16:20.174: ISAKMP:(1071): processing SA payload. message ID = 1
.Apr 3 08:16:20.174: ISAKMP:(1071):Checking IPSec proposal 1
.Apr 3 08:16:20.174: ISAKMP: transform 1, ESP_AES
.Apr 3 08:16:20.174: ISAKMP: attributes in transform:
.Apr 3 08:16:20.174: ISAKMP: encaps is 2 (Transport)
.Apr 3 08:16:20.174: ISAKMP: key length is 128
.Apr 3 08:16:20.174: ISAKMP: authenticator is HMAC-SHA
.Apr 3 08:16:20.174: ISAKMP: SA life type in seconds
.Apr 3 08:16:20.174: ISAKMP: SA life duration (VPI) of 0x0 0x0 0xE 0x10
.Apr 3 08:16:20.174: ISAKMP: SA life type in kilobytes
.Apr 3 08:16:20.174: ISAKMP: SA life duration (VPI) of 0x0 0x3 0xD0 0x90
.Apr 3 08:16:20.174: ISAKMP:(1071):atts are acceptable.
.Apr 3 08:16:20.174: IPSEC(validate_proposal_request): proposal part #1
.Apr 3 08:16:20.174: IPSEC(validate_proposal_request): proposal part #1,
(key eng. msg.) INBOUND local= XX:0, remote= 192.168.7.92:0,
local_proxy= XX/255.255.255.255/17/1701,
remote_proxy= 192.168.7.92/255.255.255.255/17/1701,
protocol= ESP, transform= NONE (Transport),
lifedur= 0s and 0kb,
spi= 0x0(0), conn_id= 0, keysize= 128, flags= 0x0
.Apr 3 08:16:20.174: IPSEC(ipsec_process_proposal): transform proposal not supported for identity:
{esp-aes esp-sha-hmac }
.Apr 3 08:16:20.174: ISAKMP:(1071): IPSec policy invalidated proposal with error 256
.Apr 3 08:16:20.174: ISAKMP:(1071):Checking IPSec proposal 2
.Apr 3 08:16:20.174: ISAKMP: transform 1, ESP_3DES
.Apr 3 08:16:20.174: ISAKMP: attributes in transform:
.Apr 3 08:16:20.174: ISAKMP: encaps is 2 (Transport)
.Apr 3 08:16:20.174: ISAKMP: authenticator is HMAC-SHA
.Apr 3 08:16:20.174: ISAKMP: SA life type in seconds
.Apr 3 08:16:20.174: ISAKMP: SA life duration (VPI) of 0x0 0x0 0xE 0x10
.Apr 3 08:16:20.174: ISAKMP: SA life type in kilobytes
.Apr 3 08:16:20.174: ISAKMP: SA life duration (VPI) of 0x0 0x3 0xD0 0x90
.Apr 3 08:16:20.174: ISAKMP:(1071):atts are acceptable.
.Apr 3 08:16:20.174: IPSEC(validate_proposal_request): proposal part #1
.Apr 3 08:16:20.174: IPSEC(validate_proposal_request): proposal part #1,
(key eng. msg.) INBOUND local= XX:0, remote= 192.168.7.92:0,
local_proxy= XX/255.255.255.255/17/1701,
remote_proxy= 192.168.7.92/255.255.255.255/17/1701,
protocol= ESP, transform= NONE (Transport),
lifedur= 0s and 0kb,
spi= 0x0(0), conn_id= 0, keysize= 0, flags= 0x0
.Apr 3 08:16:20.174: ISAKMP:(1071): processing NONCE payload. message ID = 1
.Apr 3 08:16:20.174: ISAKMP:(1071): processing ID payload. message ID = 1
.Apr 3 08:16:20.174: ISAKMP:(1071): processing ID payload. message ID = 1
.Apr 3 08:16:20.174: ISAKMP:(1071):QM Responder gets spi
.Apr 3 08:16:20.174: ISAKMP:(1071):Node 1, Input = IKE_MESG_FROM_PEER, IKE_QM_EXCH
.Apr 3 08:16:20.174: ISAKMP:(1071):Old State = IKE_QM_READY New State = IKE_QM_SPI_STARVE
.Apr 3 08:16:20.174: crypto_engine: Generate IKE hash
.Apr 3 08:16:20.174: ISAKMP:(1071):Node 1, Input = IKE_MESG_INTERNAL, IKE_GOT_SPI
.Apr 3 08:16:20.174: ISAKMP:(1071):Old State = IKE_QM_SPI_STARVE New State = IKE_QM_IPSEC_INSTALL_AWAIT
.Apr 3 08:16:20.174: IPSEC(key_engine): got a queue event with 1 KMI message(s)
.Apr 3 08:16:20.174: IPSEC(crypto_ipsec_create_ipsec_sas): Map found dyn-map
.Apr 3 08:16:20.174: crypto_engine: Generate IKE QM keys
.Apr 3 08:16:20.174: crypto_engine: Create IPSec SA (by keys)
.Apr 3 08:16:20.174: crypto_engine: Generate IKE QM keys
.Apr 3 08:16:20.174: crypto_engine: Create IPSec SA (by keys)
.Apr 3 08:16:20.178: IPSEC(create_sa): sa created,
(sa) sa_dest= XX, sa_proto= 50,
sa_spi= 0x7315891C(1930791196),
sa_trans= esp-3des esp-sha-hmac , sa_conn_id= 2111
sa_lifetime(k/sec)= (250000/3600)
.Apr 3 08:16:20.178: IPSEC(create_sa): sa created,
(sa) sa_dest= 192.168.7.92, sa_proto= 50,
sa_spi= 0x8F7085B8(2406516152),
sa_trans= esp-3des esp-sha-hmac , sa_conn_id= 2112
sa_lifetime(k/sec)= (250000/3600)
.Apr 3 08:16:20.178: ISAKMP: Failed to find peer index node to update peer_info_list
.Apr 3 08:16:20.178: ISAKMP:(1071):Received IPSec Install callback… proceeding with the negotiation
.Apr 3 08:16:20.178: %CRYPTO-5-SESSION_STATUS: Crypto tunnel is UP . Peer 192.168.7.92:500 Id: 192.168.7.92
ATVRouter#
.Apr 3 08:16:20.178: crypto_engine: Encrypt IKE packet
.Apr 3 08:16:20.178: ISAKMP:(1071): sending packet to 192.168.7.92 my_port 500 peer_port 500 (R) QM_IDLE
.Apr 3 08:16:20.178: ISAKMP:(1071):Sending an IKE IPv4 Packet.
.Apr 3 08:16:20.178: ISAKMP:(1071):Node 1, Input = IKE_MESG_FROM_IPSEC, IPSEC_INSTALL_DONE
.Apr 3 08:16:20.178: ISAKMP:(1071):Old State = IKE_QM_IPSEC_INSTALL_AWAIT New State = IKE_QM_R_QM2
.Apr 3 08:16:20.902: Before decryption:
0E9A1710: 4500 00B02F21 E..0/!
0E9A1720: 00007F32 8DA7C0A8 075C5584 60CB7315 …2.’@(.U.Ks.
0E9A1730: 891C0000 0001EFA6 247AF2C7 3279C1E2 ......o&$zrG2yAb
0E9A1740: A511DBA4 AC053704 024C %.[$,.7..L ...
.Apr 3 08:16:20.902: After decryption:
0E9A1720: 4500 00912F21 E.../!
0E9A1730: 00007F11 8DE7C0A8 075C5584 60CB06A5 .....g@(.U.K.%
0E9A1740: 06A5007D 3DAEC802 00750000 00000000 .%.}=.H..u……
0E9A1750: 00008008 00000000 0001 ………. …
.Apr 3 08:16:21.034: ISAKMP (1071): received packet from 192.168.7.92 dport 500 sport 500 Global (R) QM_IDLE
.Apr 3 08:16:21.034: crypto_engine: Decrypt IKE packet
.Apr 3 08:16:21.034: crypto_engine: Generate IKE hash
.Apr 3 08:16:21.034: ISAKMP:(1071):deleting node 1 error FALSE reason «QM done (await)»
.Apr 3 08:16:21.034: ISAKMP:(1071):Node 1, Input = IKE_MESG_FROM_PEER, IKE_QM_EXCH
.Apr 3 08:16:21.034: ISAKMP:(1071):Old State = IKE_QM_R_QM2 New State = IKE_QM_PHASE2_COMPLETE
.Apr 3 08:16:21.034: IPSEC(key_engine): got a queue event with 1 KMI message(s)
.Apr 3 08:16:21.034: IPSEC(key_engine_enable_outbound): rec’d enable notify from ISAKMP
.Apr 3 08:16:21.034: crypto engine: updating MTU size of IPSec SA Onboard VPN:112
.Apr 3 08:16:21.034: crypto_engine: Set IPSec MTU
.Apr 3 08:16:21.034: IPSEC: Expand action denied, notify RP
.Apr 3 08:16:21.370: Before decryption:
ATVRouter#
0E77EF10: 4500 00B02F36 E..0/6
0E77EF20: 00007F32 8D92C0A8 075C5584 60CB7315 …2..@(.U.Ks.
0E77EF30: 891C0000 00024D72 BFA1217C F028FDAC ......Mr?!!|p(},
0E77EF40: 126D1317 154D99D9 FE1D .m...M.Y~. ...
.Apr 3 08:16:21.370: After decryption:
0E77EF20: 4500 00912F36 E.../6
0E77EF30: 00007F11 8DD2C0A8 075C5584 60CB06A5 .....R@(.U.K.%
0E77EF40: 06A5007D 3DAEC802 00750000 00000000 .%.}=.H..u……
0E77EF50: 00008008 00000000 0001 ………. …
ATVRouter#
.Apr 3 08:16:23.182: Before decryption:
0E872A90: 4500 00B02F46 E..0/F
0E872AA0: 00007F32 8D82C0A8 075C5584 60CB7315 …2..@(.U.Ks.
0E872AB0: 891C0000 000388AF CB251180 AD8DF624 ......./K%..-.v$
0E872AC0: 3E41D021 E42A3957 AB10 >AP!d*9W+. ...
.Apr 3 08:16:23.182: After decryption:
0E872AA0: 4500 00912F46 E.../F
0E872AB0: 00007F11 8DC2C0A8 075C5584 60CB06A5 .....B@(.U.K.%
0E872AC0: 06A5007D 3DAEC802 00750000 00000000 .%.}=.H..u……
0E872AD0: 00008008 00000000 0001 ………. …
ATVRouter#
.Apr 3 08:16:27.181: Before decryption:
0E85BE90: 4500 00B02F4D E..0/M
0E85BEA0: 00007F32 8D7BC0A8 075C5584 60CB7315 …2.{@(.U.Ks.
0E85BEB0: 891C0000 00048C24 1EF1EE86 85AD43A7 .......$.qn..-C'
0E85BEC0: ACE56CC9 A3603B72 C3B7 ,elI#;rC7 …
.Apr 3 08:16:27.181: After decryption:
0E85BEA0: 4500 00912F4D E…/M
0E85BEB0: 00007F11 8DBBC0A8 075C5584 60CB06A5 …..;@(.U.K.%
0E85BEC0: 06A5007D 3DAEC802 00750000 00000000 .%.}=.H..u......
0E85BED0: 00008008 00000000 0001 .......... ...
ATVRouter#
.Apr 3 08:16:35.181: Before decryption:
0E87C490: 4500 00B02F55 E..0/U
0E87C4A0: 00007F32 8D73C0A8 075C5584 60CB7315 ...2.s@(.U.Ks.
0E87C4B0: 891C0000 000506C7 E739688F C70DF4DB …….Gg9h.G.t[
0E87C4C0: 94F2096C 79CE037A B69C .r.lyN.z6. …
.Apr 3 08:16:35.181: After decryption:
0E87C4A0: 4500 00912F55 E…/U
0E87C4B0: 00007F11 8DB3C0A8 075C5584 60CB06A5 …..3@(.U.`K.%
0E87C4C0: 06A5007D 3DAEC802 00750000 00000000 .%.}=.H..u……
0E87C4D0: 00008008 00000000 0001 ………. …

Debug shows that 2 phases of IPSec is success, but I still cannot connect via Windows built-in vpn client.

I am having a problem with a site to site VPN setup.  I am recieving the following errors on the hub router:

000221: *Feb 26 16:38:49.341 EST: ISAKMP:(2031): IPSec policy invalidated proposal with error 256
000222: *Feb 26 16:38:49.341 EST: ISAKMP:(2031): phase 2 SA policy not acceptable! (local 216.222.165.72 remote 216.222.162.155)
000223: *Feb 26 16:38:49.341 EST: ISAKMP:(2031):deleting node -1773415254 error TRUE reason «QM rejected»

I recieve the following error on the remote router:

ISAKMP:(2002):deleting node -1382141815 error TRUE reason «Delete Larval»

Here is the config for the main site:

Building configuration…

Current configuration : 9226 bytes
!
version 12.4
no service pad
service tcp-keepalives-in
service tcp-keepalives-out
service timestamps debug datetime msec localtime show-timezone
service timestamps log datetime msec localtime show-timezone
service password-encryption
service sequence-numbers
!
hostname xxxxx
!
boot-start-marker
boot-end-marker
!
security authentication failure rate 3 log
security passwords min-length 6
logging buffered 51200 debugging
logging console critical
enable secret 5 xxxxxx
!
aaa new-model
!
!
aaa authentication login local_authen local
aaa authentication login clientauth local
aaa authentication ppp default local
aaa authorization exec local_author local
aaa authorization network groupauthor local
!
aaa session-id common
!
resource policy
!
clock timezone EST -5
clock summer-time EDT recurring
no ip source-route
!
!
ip cef
no ip dhcp use vrf connected
ip dhcp excluded-address 192.168.1.1 192.168.1.99
ip dhcp excluded-address 192.168.1.201 192.168.1.254
!
ip dhcp pool POOL_LAN_DHCP
   import all
   network 192.168.1.0 255.255.255.0
   default-router 192.168.1.1
   dns-server 64.33.128.10 209.143.0.10
!
!
ip tcp synwait-time 10
ip tftp source-interface Vlan1
no ip bootp server
no ip domain lookup
ip domain name local
ip name-server 64.33.128.10
ip name-server 209.143.0.10
ip ssh time-out 60
ip ssh authentication-retries 2
ip inspect name CBACinspect cuseeme
ip inspect name CBACinspect ftp
ip inspect name CBACinspect h323
ip inspect name CBACinspect icmp
ip inspect name CBACinspect netshow
ip inspect name CBACinspect rcmd
ip inspect name CBACinspect realaudio
ip inspect name CBACinspect rtsp
ip inspect name CBACinspect esmtp
ip inspect name CBACinspect sqlnet
ip inspect name CBACinspect streamworks
ip inspect name CBACinspect tftp
ip inspect name CBACinspect tcp
ip inspect name CBACinspect udp
ip inspect name CBACinspect vdolive
vpdn enable
!
!
!
!

!
!
crypto keyring L2L
  pre-shared-key address x.x.x.155 key xxxxxxx
!
crypto isakmp policy 10
 encr 3des
 authentication pre-share
 group 2
!
crypto isakmp client configuration group RemoteAccessVPN
 key xxxxxxxxx
 pool Pool_RemoteAccessVPN
 acl ACL_VPN_RemoteAccess
!
crypto isakmp client configuration group watertower
 key xxxxxx
 pool watertower
 acl VPN_watertower
crypto isakmp profile VPNClient
   description VPN clients with access LAN
   match identity group RemoteAccessVPN
   client authentication list clientauth
   isakmp authorization list groupauthor
   client configuration address respond
crypto isakmp profile L2L
   keyring L2L
 match identity address x.x.x.155 255.255.255.255
crypto isakmp profile watertower
   match identity group watertower
   client authentication list local
   isakmp authorization list groupauthor
   client configuration address respond
!
!
crypto ipsec transform-set ESP-AES256-SHA esp-aes 256 esp-sha-hmac
crypto ipsec transform-set ESP-AES128-SHA esp-aes esp-sha-hmac
crypto ipsec transform-set ESP-3DES-SHA esp-3des esp-sha-hmac
crypto ipsec transform-set ESP-AES-SHA esp-aes esp-sha-hmac
crypto ipsec transform-set newset esp-3des esp-sha-hmac
!
crypto dynamic-map dynmap 5
 set transform-set ESP-AES256-SHA
 set isakmp-profile VPNClient
crypto dynamic-map dynmap 10
 set transform-set ESP-AES256-SHA
crypto dynamic-map dynmap 15
 set transform-set newset
!
!
crypto map VPNmap 30 ipsec-isakmp dynamic dynmap
crypto map VPNmap 40 ipsec-isakmp
 set peer x.x.x.155
 set transform-set newset
 match address ACL_L2L_watertower
!
!
!
!
interface Null0
 no ip unreachables
!
interface Loopback0
 description Lo0 used for outbound traffic not subject to NAT
 ip address 10.20.30.40 255.255.255.0
!
interface FastEthernet0
 description External — Internet — to DSL modem
 no ip address
 ip verify unicast reverse-path
 no ip redirects
 no ip unreachables
 no ip proxy-arp
 ip virtual-reassembly
 ip route-cache flow
 duplex auto
 speed auto
 pppoe enable group global
 pppoe-client dial-pool-number 1
 no cdp enable
!
interface FastEthernet1
 no ip address
 shutdown
 duplex auto
 speed auto
!
interface FastEthernet2
!
interface FastEthernet3
!
interface FastEthernet4
!
interface FastEthernet5
!
interface FastEthernet6
!
interface FastEthernet7
!
interface FastEthernet8
!
interface FastEthernet9
 switchport access vlan 12
!
interface Vlan1
 description Internal LAN
 ip address 192.168.1.1 255.255.255.0
 no ip redirects
 no ip unreachables
 no ip proxy-arp
 ip nat inside
 ip virtual-reassembly
 ip route-cache flow
 ip policy route-map RMAP_NO_STATIC_NAT
!
interface Vlan12
 no ip address
 ip nat inside
 ip virtual-reassembly
!
interface Async1
 no ip address
 encapsulation slip
!
interface Dialer1
 ip address negotiated
 ip access-group ACL_outside_in in
 ip nat outside
 ip inspect CBACinspect out
 ip virtual-reassembly
 encapsulation ppp
 ip tcp adjust-mss 1452
 dialer pool 1
 dialer-group 1
 ppp authentication pap callin
 ppp pap sent-username xxxx password 7 xxxxx
 ppp ipcp dns request
 ppp ipcp address accept
 crypto map VPNmap
!
ip local pool Pool_RemoteAccessVPN 192.168.100.100 192.168.100.150
ip local pool watertower 192.168.9.50 192.168.9.60
ip route 0.0.0.0 0.0.0.0 Dialer1
!
!
no ip http server
ip http authentication local
no ip http secure-server
ip http timeout-policy idle 5 life 86400 requests 10000
ip nat inside source static tcp 192.168.1.41 23 interface Dialer1 1000
ip nat inside source route-map NAT_RMAP interface Dialer1 overload
!
ip access-list extended ACL_L2L_watertower
permit ip 192.168.1.0 0.0.0.255 192.168.13.0 0.0.0.255
ip access-list extended ACL_NAT_RMAP
 deny   ip 192.168.1.0 0.0.0.255 192.168.100.0 0.0.0.255
 deny   ip 192.168.1.0 0.0.0.255 192.168.9.0 0.0.0.255
 deny   ip 192.168.1.0 0.0.0.255 192.168.13.0 0.0.0.255
 permit ip 192.168.1.0 0.0.0.255 any
ip access-list extended ACL_RMAP_NO_STATIC
 permit ip 192.168.1.0 0.0.0.255 192.168.13.0 0.0.0.255
 permit ip 192.168.1.0 0.0.0.255 192.168.100.0 0.0.0.255
 permit ip 192.168.1.0 0.0.0.255 192.168.9.0 0.0.0.255
 deny   ip 192.168.1.0 0.0.0.255 any
ip access-list extended ACL_VPN_RemoteAccess
 permit ip 192.168.1.0 0.0.0.255 192.168.100.0 0.0.0.255
ip access-list extended ACL_outside_in
 permit udp any eq bootps any eq bootpc
 permit icmp any host x.x.x.72 echo-reply
 permit icmp any host x.x.x.72 time-exceeded
 permit icmp any host x.x.x.72 unreachable
 permit udp any host x.x.x.72 eq non500-isakmp
 permit udp any host x.x.x.72 eq isakmp
 permit esp any host x.x.x.72
 permit ahp any host x.x.x.72
 permit gre any host x.x.x.72
 permit tcp any host x.x.x.72 eq 22
 permit tcp any host x.x.x.72 eq telnet
 permit tcp any host x.x.x.72 eq 1000
 deny   tcp any host x.x.x.72 eq cmd
 deny   udp any host x.x.x.72 eq snmp
 permit ip x.x.x.x x.x.x.72 any
 permit ip x.x.x.x x.x.x.72 any
ip access-list extended ACL_vty_access_in
 remark VTY Access-class list
 permit ip 192.168.100.0 0.0.0.255 any
 permit ip 192.168.1.0 0.0.0.255 any
 remark VTY Access-class list
 deny   ip any any
ip access-list extended VPN_watertower
 permit ip 192.168.1.0 0.0.0.255 192.168.9.0 0.0.0.255
 permit ip 192.168.13.0 0.0.0.255 192.168.9.0 0.0.0.255
!
logging trap debugging
dialer-list 1 protocol ip permit
no cdp run
!
!
!
route-map NAT_RMAP permit 1
 match ip address ACL_NAT_RMAP
!

route-map RMAP_NO_STATIC_NAT permit 1
 match ip address ACL_RMAP_NO_STATIC
 set ip next-hop 10.20.30.41
!
!
!
!
control-plane
!

This is the config for the remote site:

Building configuration…

Current configuration : 3863 bytes
!
version 12.4
no service pad
service timestamps debug datetime msec
service timestamps log datetime msec
service password-encryption

dot11 syslog
!
!
ip cef
no ip domain lookup
!
!
!

!
crypto isakmp policy 10
 encr 3des
 authentication pre-share
crypto isakmp key xxxxxx address x.x.x.72
!
!
crypto ipsec transform-set newest esp-3des esp-sha-hmac
!
crypto map newmap 10 ipsec-isakmp
 set peer x.x.x.72
 set transform-set newest
 match address 110
!
archive
 log config
  hidekeys
!
!
ip tcp mss 1452
!
bridge irb
!
!
interface ATM0
 no ip address
 no ip route-cache cef
 no ip route-cache
 load-interval 30
 no atm ilmi-keepalive
 pvc 0/35
  encapsulation aal5snap
  pppoe-client dial-pool-number 1
 !
 dsl operating-mode auto
!
interface FastEthernet0
!
interface FastEthernet1
!
interface FastEthernet2
!
interface FastEthernet3
!
interface Vlan1
 description $ETH-SW-LAUNCH$$INTF-INFO-HWIC 4ESW$
 ip address 192.168.13.1 255.255.255.0
 ip nat inside
 ip virtual-reassembly
 ip tcp adjust-mss 1452
 no autostate
!
interface Dialer1
 mtu 1492
 ip address negotiated
 ip nat outside
 ip virtual-reassembly
 encapsulation ppp
 ip tcp adjust-mss 1452
 dialer pool 1
 dialer-group 1
 no cdp enable
 ppp authentication pap callin
 ppp pap sent-username xxxxx password 7 xxxxxx
 ppp ipcp dns request
 ppp ipcp address accept
 crypto map newmap
!
ip forward-protocol nd
ip route 0.0.0.0 0.0.0.0 Dialer1
!
no ip http server
ip http access-class 23
ip http authentication local
no ip http secure-server
ip http timeout-policy idle 60 life 86400 requests 10000
!
access-list 23 permit 10.10.10.0 0.0.0.7
access-list 110 permit ip 192.168.13.0 0.0.0.255 192.168.1.0 0.0.0.255
dialer-list 1 protocol ip permit
no cdp run
!
control-plane
!

Any help would be greatly appreciated.  Thanks!