Re: two sa for a VPN connection? (Cisco VPN client 3.6.3 <--->IO

tricaricog · ‎04-01-2003

Hi

I open a VPN connection using CiscoVPN client 3.6.3 (behind a NAT) to a Cisco 3620 router, all works well, but when I use "sh crypto isakmp sa" command on the router, I see two couple of SA each associated with the same remote client! During the connection only one of the two association exchange data..What happens???

Follows a log of CISCO VPN client 3.6.3

79 12:22:50.777 03/30/03 Sev=Info/6 IKE/0x6300003B

Attempting to establish a connection with 10.0.0.1.

80 12:22:50.817 03/30/03 Sev=Info/4 IKE/0x63000013

SENDING >>> ISAKMP OAK AG (SA, KE, NON, ID, VID, VID, VID, VID, VID) to 10.0.0.1

81 12:22:50.817 03/30/03 Sev=Info/4 IPSEC/0x63700014

Deleted all keys

82 12:22:51.188 03/30/03 Sev=Info/5 IKE/0x6300002F

Received ISAKMP packet: peer = 10.0.0.1

83 12:22:51.188 03/30/03 Sev=Info/4 IKE/0x63000014

RECEIVING <<< ISAKMP OAK AG (SA, VID, VID, VID, VID, VID, KE, ID, NON, HASH, NAT-D, NAT-D) from 10.0.0.1

84 12:22:51.188 03/30/03 Sev=Info/5 IKE/0x63000059

Vendor ID payload = 12F5F28C457168A9702D9FE274CC0100

85 12:22:51.188 03/30/03 Sev=Info/5 IKE/0x63000001

Peer is a Cisco-Unity compliant peer

86 12:22:51.188 03/30/03 Sev=Info/5 IKE/0x63000059

Vendor ID payload = AFCAD71368A1F1C96B8696FC77570100

87 12:22:51.188 03/30/03 Sev=Info/5 IKE/0x63000001

Peer supports DPD

88 12:22:51.188 03/30/03 Sev=Info/5 IKE/0x63000059

Vendor ID payload = B2BE6C300BEB39F6C45E0BE6E52E9FA7

89 12:22:51.188 03/30/03 Sev=Info/5 IKE/0x63000059

Vendor ID payload = 09002689DFD6B712

90 12:22:51.188 03/30/03 Sev=Info/5 IKE/0x63000001

Peer supports XAUTH

91 12:22:51.188 03/30/03 Sev=Info/5 IKE/0x63000059

Vendor ID payload = 90CB80913EBB696E086381B5EC427B1F

92 12:22:51.188 03/30/03 Sev=Info/5 IKE/0x63000001

Peer supports NAT-T

93 12:22:51.218 03/30/03 Sev=Info/4 IKE/0x63000013

SENDING >>> ISAKMP OAK AG *(HASH, NOTIFY:STATUS_INITIAL_CONTACT, NAT-D, NAT-D) to 10.0.0.1

94 12:22:51.218 03/30/03 Sev=Info/5 IKE/0x63000071

Automatic NAT Detection Status:

Remote end is NOT behind a NAT device

This end IS behind a NAT device

95 12:22:51.238 03/30/03 Sev=Info/5 IKE/0x6300005D

Client sending a firewall request to concentrator

96 12:22:51.238 03/30/03 Sev=Info/5 IKE/0x6300005C

Firewall Policy: Product=Cisco Integrated Client, Capability= (Centralized Protection Policy).

97 12:22:51.238 03/30/03 Sev=Info/4 IKE/0x63000013

SENDING >>> ISAKMP OAK TRANS *(HASH, ATTR) to 10.0.0.1

98 12:22:51.238 03/30/03 Sev=Info/5 IKE/0x6300002F

Received ISAKMP packet: peer = 10.0.0.1

99 12:22:51.238 03/30/03 Sev=Info/4 IKE/0x63000014

RECEIVING <<< ISAKMP OAK INFO *(HASH, NOTIFY:STATUS_RESP_LIFETIME) from 10.0.0.1

100 12:22:51.238 03/30/03 Sev=Info/5 IKE/0x63000044

RESPONDER-LIFETIME notify has value of 86400 seconds

101 12:22:51.238 03/30/03 Sev=Info/5 IKE/0x63000046

This SA has already been alive for 1 seconds, setting expiry to 86399 seconds from now

102 12:22:51.258 03/30/03 Sev=Info/5 IKE/0x6300005D

Client sending a firewall request to concentrator

103 12:22:51.258 03/30/03 Sev=Info/5 IKE/0x6300005C

Firewall Policy: Product=Cisco Integrated Client, Capability= (Centralized Protection Policy).

104 12:22:51.258 03/30/03 Sev=Info/4 IKE/0x63000013

SENDING >>> ISAKMP OAK TRANS *(HASH, ATTR) to 10.0.0.1

105 12:22:51.258 03/30/03 Sev=Info/5 IKE/0x6300002F

Received ISAKMP packet: peer = 10.0.0.1

106 12:22:51.258 03/30/03 Sev=Info/4 IKE/0x63000014

RECEIVING <<< ISAKMP OAK TRANS *(HASH, ATTR) from 10.0.0.1

107 12:22:51.258 03/30/03 Sev=Info/5 IKE/0x63000010

MODE_CFG_REPLY: Attribute = INTERNAL_IPV4_ADDRESS: , value = 10.0.0.138

108 12:22:51.258 03/30/03 Sev=Warning/3 IKE/0xE3000084

The length, 5338268, of the Mode Config option, , is invalid

109 12:22:51.258 03/30/03 Sev=Info/5 IKE/0xA3000016

MODE_CFG_REPLY: The received (32767) attribute and value (65280) is not supported

110 12:22:51.258 03/30/03 Sev=Info/5 IKE/0xA3000017

MODE_CFG_REPLY: The received (INTERNAL_ADDRESS_EXPIRY) attribute and value (86399) is not supported

111 12:22:51.258 03/30/03 Sev=Info/5 IKE/0x6300000E

MODE_CFG_REPLY: Attribute = APPLICATION_VERSION, value = Cisco Internetwork Operating System Software

IOS (tm) 3600 Software (C3620-IK9O3S7-M), Version 12.2(15)T, RELEASE SOFTWARE (fc1)

TAC Support: http://www.cisco.com/tac

Compiled Mon 10-Mar-03 16:47 by ccai

112 12:22:51.258 03/30/03 Sev=Info/4 IKE/0xA3000015

MODE_CFG_REPLY: Received MODECFG_UNITY_SPLIT_INCLUDE attribute with no data

113 12:22:51.258 03/30/03 Sev=Info/5 IKE/0x6300000D

MODE_CFG_REPLY: Attribute = Recieved and using NAT-T port number , value = 0x00001194

114 12:22:51.268 03/30/03 Sev=Info/5 IKE/0x63000055

Received a key request from Driver for IP address 10.0.0.1, GW IP = 10.0.0.1

115 12:22:51.268 03/30/03 Sev=Info/4 IKE/0x63000013

SENDING >>> ISAKMP OAK QM *(HASH, SA, NON, ID, ID) to 10.0.0.1

116 12:22:51.268 03/30/03 Sev=Info/5 IKE/0x63000055

Received a key request from Driver for IP address 10.10.10.255, GW IP = 10.0.0.1

117 12:22:51.268 03/30/03 Sev=Info/4 IKE/0x63000013

SENDING >>> ISAKMP OAK QM *(HASH, SA, NON, ID, ID) to 10.0.0.1

118 12:22:51.278 03/30/03 Sev=Info/5 IKE/0x6300002F

Received ISAKMP packet: peer = 10.0.0.1

119 12:22:51.278 03/30/03 Sev=Info/4 IKE/0x63000014

RECEIVING <<< ISAKMP OAK TRANS *(HASH, ) from 10.0.0.1

120 12:22:51.278 03/30/03 Sev=Warning/3 IKE/0xA3000058

Received malformed message or negotiation no longer active (message id: 0x07676201)

121 12:22:51.568 03/30/03 Sev=Info/5 IKE/0x6300002F

Received ISAKMP packet: peer = 10.0.0.1

122 12:22:51.568 03/30/03 Sev=Info/4 IKE/0x63000014

RECEIVING <<< ISAKMP OAK QM *(HASH, SA, NON, ID, ID, NOTIFY:STATUS_RESP_LIFETIME) from 10.0.0.1

123 12:22:51.568 03/30/03 Sev=Info/5 IKE/0x63000044

RESPONDER-LIFETIME notify has value of 3600 seconds

124 12:22:51.568 03/30/03 Sev=Info/5 IKE/0x63000045

RESPONDER-LIFETIME notify has value of 4608000 kb

125 12:22:51.568 03/30/03 Sev=Info/4 IKE/0x63000013

SENDING >>> ISAKMP OAK QM *(HASH) to 10.0.0.1

126 12:22:51.568 03/30/03 Sev=Info/5 IKE/0x63000058

Loading IPsec SA (Message ID = 0x03C59714 OUTBOUND SPI = 0x2EF5A47A INBOUND SPI = 0x28D9CD3E)

127 12:22:51.568 03/30/03 Sev=Info/5 IKE/0x63000025

Loaded OUTBOUND ESP SPI: 0x2EF5A47A

128 12:22:51.568 03/30/03 Sev=Info/5 IKE/0x63000026

Loaded INBOUND ESP SPI: 0x28D9CD3E

129 12:22:51.788 03/30/03 Sev=Info/5 IKE/0x6300002F

Received ISAKMP packet: peer = 10.0.0.1

130 12:22:51.788 03/30/03 Sev=Info/4 IKE/0x63000014

RECEIVING <<< ISAKMP OAK QM *(HASH, SA, NON, ID, ID, NOTIFY:STATUS_RESP_LIFETIME) from 10.0.0.1

131 12:22:51.788 03/30/03 Sev=Info/5 IKE/0x63000044

RESPONDER-LIFETIME notify has value of 3600 seconds

132 12:22:51.788 03/30/03 Sev=Info/5 IKE/0x63000045

RESPONDER-LIFETIME notify has value of 4608000 kb

133 12:22:51.788 03/30/03 Sev=Info/4 IKE/0x63000013

SENDING >>> ISAKMP OAK QM *(HASH) to 10.0.0.1

134 12:22:51.788 03/30/03 Sev=Info/5 IKE/0x63000058

Loading IPsec SA (Message ID = 0xA8B5AF91 OUTBOUND SPI = 0x13F0BE84 INBOUND SPI = 0xBB1FAC80)

135 12:22:51.788 03/30/03 Sev=Info/5 IKE/0x63000025

Loaded OUTBOUND ESP SPI: 0x13F0BE84

136 12:22:51.788 03/30/03 Sev=Info/5 IKE/0x63000026

Loaded INBOUND ESP SPI: 0xBB1FAC80

137 12:22:52.139 03/30/03 Sev=Info/4 IPSEC/0x63700014

Deleted all keys

138 12:22:52.139 03/30/03 Sev=Info/4 IPSEC/0x63700010

Created a new key structure

139 12:22:52.139 03/30/03 Sev=Info/4 IPSEC/0x6370000F

Added key with SPI=0x7aa4f52e into key list

140 12:22:52.139 03/30/03 Sev=Info/4 IPSEC/0x63700010

Created a new key structure

141 12:22:52.139 03/30/03 Sev=Info/4 IPSEC/0x6370000F

Added key with SPI=0x3ecdd928 into key list

142 12:22:52.139 03/30/03 Sev=Info/4 IPSEC/0x63700010

Created a new key structure

143 12:22:52.139 03/30/03 Sev=Info/4 IPSEC/0x6370000F

Added key with SPI=0x84bef013 into key list

144 12:22:52.139 03/30/03 Sev=Info/4 IPSEC/0x63700010

Created a new key structure

145 12:22:52.139 03/30/03 Sev=Info/4 IPSEC/0x6370000F

Added key with SPI=0x80ac1fbb into key list

afakhan · ‎04-01-2003

Hi,

There should be one IKE SA(sh cry isa sa), and two pairs of IPSec SAs(sh cry ips sa) per client.

Router side debugs would help in finding out the cause of it, and it could be a cosmetic issue if eveything is working ok.

Thanks

Afaq

tricaricog · ‎04-01-2003

Yes everything work ok, but when I issue the command "sh crypto ipsec sa" i see two sa related to the same identity with different SPI !

During data exchange only the first sa indicate a data exchange..

gmiiller · ‎04-03-2003

Having multiple SA's between peers is common, so is having traffic counters against one of them.

The most common cause of multiple SA's are discontiguous address ranges or specific ports only covered in the crypto ACL's. It also occurs often in RAS and when using GRE/IPSec.

THe IPSec RFC is based around contiguous address ranges in the crypto ACL. So multiple SA's will be formed for SA's involving discontiguous hosts at each end.

Similarly, port/protocol based crypto ACL's, GRE/IPsec and, frequently RAS, will create multiple SA's although when you view the sa's only one of them has incrementing traffic counters.

The main thing is to take this into consideration when working out the maximum number of tunnels (or SA's) you want a device to terminate.

two sa for a VPN connection? (Cisco VPN client 3.6.3 <--->IOS)