Please disregard my last post regarding ip address outside and route outside, I just realized what this was. I don't understand how changing the IP address would make my VPN unfunctional now. Our SNM changed from 255.255.255.248 to 255.255.255.240
Do you get authentication errors or nothing at all when clients try to connect?? Have you looked at any logs or run any debugs on the PIX to see if there is any action??
I hate all Uppercase... I don't want my groups to seem angry at me all the time! =)
- ColdFlame (vbscript forum)
Cisco Systems VPN Client Version 5.0.00.0340
Copyright (C) 1998-2006 Cisco Systems, Inc. All Rights Reserved.
Client Type(s): Windows, WinNT
Running on: 5.1.2600 Service Pack 3
Config file directory: C:\Program Files\Cisco Systems\VPN Client
1 09:33:28.828 11/10/09 Sev=Info/4 CM/0x63100002
Begin connection process
15 09:33:29.125 11/10/09 Sev=Info/6 IKE/0x63000001
IOS Vendor ID Contruction successful
16 09:33:29.125 11/10/09 Sev=Info/4 IKE/0x63000013
SENDING >>> ISAKMP OAK AG *(HASH, NOTIFY:STATUS_INITIAL_CONTACT, NAT-D, NAT-D, VID(?), VID(Unity)) to 67.78.141.82
17 09:33:29.125 11/10/09 Sev=Info/6 IKE/0x63000055
Sent a keepalive on the IPSec SA
18 09:33:29.125 11/10/09 Sev=Info/4 IKE/0x63000083
IKE Port in use - Local Port = 0x0989, Remote Port = 0x1194
19 09:33:29.125 11/10/09 Sev=Info/5 IKE/0x63000072
Automatic NAT Detection Status:
Remote end is NOT behind a NAT device
This end IS behind a NAT device
20 09:33:29.125 11/10/09 Sev=Info/4 CM/0x6310000E
Established Phase 1 SA. 1 Crypto Active IKE SA, 0 User Authenticated IKE SA in the system
46 09:33:34.468 11/10/09 Sev=Info/5 IKE/0x6300000D
MODE_CFG_REPLY: Attribute = Received and using NAT-T port number , value = 0x00001194
47 09:33:34.468 11/10/09 Sev=Info/4 CM/0x63100019
Mode Config data received
48 09:33:34.484 11/10/09 Sev=Info/4 IKE/0x63000056
Received a key request from Driver: Local IP = 10.252.1.100, GW IP = 67.78.141.82, Remote IP = 0.0.0.0
49 09:33:34.484 11/10/09 Sev=Info/4 IKE/0x63000013
SENDING >>> ISAKMP OAK QM *(HASH, SA, NON, ID, ID) to 67.78.141.82
68 09:33:54.890 11/10/09 Sev=Info/4 IKE/0x63000014
RECEIVING <<< ISAKMP OAK INFO *(HASH, NOTIFYPD_ACK) from 67.78.141.82
69 09:33:54.890 11/10/09 Sev=Info/5 IKE/0x63000040
Received DPD ACK from 67.78.141.82, seq# received = 3319899588, seq# expected = 3319899588
70 09:33:59.375 11/10/09 Sev=Info/6 IKE/0x63000055
Sent a keepalive on the IPSec SA
71 09:34:09.375 11/10/09 Sev=Info/6 IKE/0x63000055
Sent a keepalive on the IPSec SA
72 09:34:19.375 11/10/09 Sev=Info/6 IKE/0x63000055
Sent a keepalive on the IPSec SA
73 09:34:24.875 11/10/09 Sev=Info/4 IKE/0x63000017
Marking IKE SA for deletion (I_Cookie=0168A263A30D7835 R_Cookie=B76953D02B94AC58) reason = DEL_REASON_PEER_NOT_RESPONDING
74 09:34:24.875 11/10/09 Sev=Info/4 IKE/0x63000013
SENDING >>> ISAKMP OAK INFO *(HASH, DEL) to 67.78.141.82
75 09:34:25.375 11/10/09 Sev=Info/4 IKE/0x6300004B
Discarding IKE SA negotiation (I_Cookie=0168A263A30D7835 R_Cookie=B76953D02B94AC58) reason = DEL_REASON_PEER_NOT_RESPONDING
76 09:34:25.375 11/10/09 Sev=Info/4 CM/0x63100012
Phase 1 SA deleted before first Phase 2 SA is up cause by "DEL_REASON_PEER_NOT_RESPONDING". 0 Crypto Active IKE SA, 0 User Authenticated IKE SA in the system
This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
By continuing to use this site, you are consenting to our use of cookies.