Buy or Renew
Buy or Renew
cancel
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Showing results for 
Search instead for 
Did you mean: 
cancel
Start a conversation
765
Views
0
Helpful
4
Replies

VPN Client to PIX - Client Disconnects after 2-5 Min.

kerrow
Level 1
Level 1

‎08-18-2004 01:02 PM

My VPN Client connects to a PIX 515 with 6.2 OS on it. I have IP connectivity for about 2 to 5 minutes and then it stops and I get the pop up that states the connection has been terminated because the peer is not responding. Below is the log on the client, entry 119 seems to be where this starts going south. Any advice would be appreciated and I know this PIX needs on OS upgrade, that will me my next step, however hopefully I can figure this out with the current codd

112 15:08:50.470 08/18/04 Sev=Info/4 IKE/0x63000013

SENDING >>> ISAKMP OAK INFO *(HASH, NOTIFY:DPD_REQUEST) to 199.x.x.x

113 15:08:55.477 08/18/04 Sev=Info/6 IKE/0x6300003D

Sending DPD request to 199.x.x.x, seq# = 133241582

114 15:08:55.477 08/18/04 Sev=Info/4 IKE/0x63000013

SENDING >>> ISAKMP OAK INFO *(HASH, NOTIFY:DPD_REQUEST) to 199.x.x.x

115 15:09:00.484 08/18/04 Sev=Info/6 IKE/0x6300003D

Sending DPD request to 199.x.x.x, seq# = 133241583

116 15:09:00.484 08/18/04 Sev=Info/4 IKE/0x63000013

SENDING >>> ISAKMP OAK INFO *(HASH, NOTIFY:DPD_REQUEST) to 199.x.x.x

117 15:09:05.501 08/18/04 Sev=Info/6 IKE/0x6300003D

Sending DPD request to 199.x.x.x, seq# = 133241584

118 15:09:05.501 08/18/04 Sev=Info/4 IKE/0x63000013

SENDING >>> ISAKMP OAK INFO *(HASH, NOTIFY:DPD_REQUEST) to 199.x.x.x

119 15:09:10.999 08/18/04 Sev=Info/4 IKE/0x63000013

SENDING >>> ISAKMP OAK INFO *(HASH, DEL) to 199.x.x.x

120 15:09:10.999 08/18/04 Sev=Info/5 IKE/0x63000018

Deleting IPsec SA: (OUTBOUND SPI = 7EEA98AA INBOUND SPI = B59C2181)

121 15:09:10.999 08/18/04 Sev=Info/4 IKE/0x63000048

Discarding IPsec SA negotiation, MsgID=1D773F1F

122 15:09:10.999 08/18/04 Sev=Info/4 IKE/0x63000017

Marking IKE SA for deletion (I_Cookie=641BEE2F4E734B4D R_Cookie=CEEB106902E21C62) reason = DEL_REASON_PEER_NOT_RESPONDING

123 15:09:11.009 08/18/04 Sev=Info/4 IKE/0x63000013

SENDING >>> ISAKMP OAK INFO *(HASH, DEL) to 199.x.x.x

124 15:09:11.130 08/18/04 Sev=Info/4 IPSEC/0x63700013

Delete internal key with SPI=0x81219cb5

125 15:09:11.130 08/18/04 Sev=Info/4 IPSEC/0x6370000C

Key deleted by SPI 0x81219cb5

126 15:09:11.130 08/18/04 Sev=Info/4 IPSEC/0x63700013

Delete internal key with SPI=0xaa98ea7e

127 15:09:11.130 08/18/04 Sev=Info/4 IPSEC/0x6370000C

Key deleted by SPI 0xaa98ea7e

Labels:
0 Helpful
4 Replies 4

steven.wilson
Level 1
Level 1

‎08-19-2004 03:28 AM

It may be that the PIX is timing-out the vpn client.

Try the following command on the PIX.

timeout uauth 0:30:00 absolute

timeout uauth 0:15:00 inactivity

Also check the isakmp policy lifetime.

Cheers,

Steve

0 Helpful

mostiguy
Level 6
Level 6

‎08-19-2004 06:28 AM

While it is connected, are you able to get any data across the connection? If not, that is likely the reason the tunnel times out. Reasons that data cannot cross it can include incorrect nat 0 statements and other configuration hijinx

0 Helpful

kerrow
Level 1
Level 1
In response to mostiguy

‎08-19-2004 07:38 AM

While it is connected, I CAN get data across.

If you look at the Client log I am not recieving the (HASH, NOTIFY:DPD_ACK). Below is a log from a good vpn connection to another client. Notice that when there is a (HASH, NOTIFY:DPD_REQUEST), an isakmp packet is recieved and there is a (HASH, NOTIFY:DPD_ACK):

91 09:09:06.846 08/19/04 Sev=Info/6 IKE/0x6300003D

Sending DPD request to 12.x.x.x, seq# = 1873801401

92 09:09:06.846 08/19/04 Sev=Info/4 IKE/0x63000013

SENDING >>> ISAKMP OAK INFO *(HASH, NOTIFY:DPD_REQUEST) to 12.x.x.x

93 09:09:06.996 08/19/04 Sev=Info/5 IKE/0x6300002F

Received ISAKMP packet: peer = 12.x.x.x

94 09:09:06.996 08/19/04 Sev=Info/4 IKE/0x63000014

RECEIVING <<< ISAKMP OAK INFO *(HASH, NOTIFY:DPD_ACK) from 12.x.x.x

95 09:09:06.996 08/19/04 Sev=Info/5 IKE/0x6300003F

Received DPD ACK from 12.x.x.x, seq# received = 1873801402, seq# expected = 1873801402

96 09:09:17.361 08/19/04 Sev=Info/6 IKE/0x6300003D

Sending DPD request to 12.x.x.x, seq# = 1873801402

97 09:09:17.361 08/19/04 Sev=Info/4 IKE/0x63000013

SENDING >>> ISAKMP OAK INFO *(HASH, NOTIFY:DPD_REQUEST) to 12.x.x.x

98 09:09:17.521 08/19/04 Sev=Info/5 IKE/0x6300002F

Received ISAKMP packet: peer = 12.x.x.x

99 09:09:17.521 08/19/04 Sev=Info/4 IKE/0x63000014

RECEIVING <<< ISAKMP OAK INFO *(HASH, NOTIFY:DPD_ACK) from 12.x.x.x

What could be causing this, maybe an ACL or implied Deny any at the end of an ACL? Mismatched lifetime or idle timers? This PIX is a firewall that I have inherited, it needs a lot of clean up work, however that is not in the current budget, thus I need to figure this out without upgrading or reconfiguring the PIX if at all possible. Any additional help will be appreciated

0 Helpful

kerrow
Level 1
Level 1
In response to kerrow

‎08-19-2004 09:55 AM

Problem seems to have been with the nonat acl, which was also being used for split tunnel, I made a acl just for split tunnelling, omitting all the unneededs in my nonat acl, i.e., DMZ access and various other things that I did not want to remove and it worked great.

0 Helpful
Customers Also Viewed These Support Documents