Kahn10
@dis-corp.com
| [Config] Client VPN problems on Cisco 1720
I've been working on this for several days now and feel I'm not any closer to a solution. I have a site which has been running a client VPN for years without trouble suddenly can no longer function. They hadn't tried it in a while, but soon before they reported it we did add a new NAT overload and they had been upgraded to IOS 12.4 19 (they since have been brought back down again.
Any help would be appreciated. Here is the config (edited for IPs keys and passwords), the version, and the log (edited for IPs)
Please let me know if there is anything else that might assist in your assistance.
Thank you,
Conn |
|
ndegwa
join:2007-06-14
kenya
| Looks like you have several VPN tunnels. Which one in particular are you trying to connect to ?
There seems to be a ISAKMP policy mismatch between the VPN server and client based on the logs.
I would verify the ACCESS-LIST on each ISAKMP policy to make sure no NAT is happenin within the VPN tunnel.
Does each peer still have the same initial OUTSIDE IP ? |
|
Kahn10
@dis-corp.com
| reply to Kahn10
The other tunnels are Cisco to Cisco connections, those all work. The PC we are using to test the tunnel is behind a NAT, but it is able to form a VPN client tunnel to several other sites.
It does seem like the logs indicate a mismatch, but strangely this is the same setup for all of our sites:
crypto isakmp policy 3
encr 3des
authentication pre-share
group 2
Thanks,
Conn |
|
zno
join:2002-01-08
Atlanta, GA
| i'm purely speculating here since i don't know your entire setup...
how about adding "hash md5" to the crypto policy 3? just to be consistent with your transform sets.
also from the debug, line 816 seems to indicate that you have mismatching hash.
if this still doesn't fix your prob, check ACLs and see if you have any matching traffic while a client is trying to connect.
--
got anti-virus and firewall? |
|
Kahn10
@dis-corp.com
| reply to Kahn10
I tried setting policy three to use md5 hash with no luck. I think this one uses the standard SHA because it is a VPN Client rather than a store to store VPN between routers like all the others.
Here is the pertinent state change in a router nearly identical to the one I am having a problem with.
On this one the policy three is identical to the problem router. Here is the same section from the log on the bad router:
I think this is mhere is it supposed to match, but no luck. Like I said, these routers are nearly identical, right down to the fact that they both have miltiple remotes and are attached to T1 lines. I just can't figure out what the difference is. I can post the other if anyone cares to look.
As to the ACL, it is not currently enabled on the Serial0.1 interface, maybe I'm misunderstanding what you are saying. Please let me know if there is something I am missing. |
|
ndegwa
join:2007-06-14
kenya | please post the following
1. show crypto isakmp sa
2. show crypto ipsec sa
this will help narrow down on where the mismatch is occuring |
|
zno
join:2002-01-08
Atlanta, GA | reply to Kahn10
ACLs 103-107 & 111 are being applied to VPN tunnels. it doesn't matter whether you apply these to the serial interface or not. these ACLs control what gets in and out of your VPN tunnels. check your VPN ACLs if you haven't already done so. |
|
Kahn10
@dis-corp.com
| This is the pertinent line in sh crypto isakmp sa:
The ACLs for the VPN I think are correct. The ACL match addresses you are referring to are all for the store to store VPNs, which don't have a problem. We have ACL 199 for crypto isakmp client:
|
|
Kahn10
@dis-corp.com | reply to Kahn10
There didn't end up being any related data about this connection in sh crypto ipsec sa |
|
ndegwa
join:2007-06-14
kenya | reply to Kahn10
It looks as though the first phase (ISAKMP) of the security association isn't even coming up
Can you ping from the client to the remote side then ran the command again ? |
|
Kahn10
@dis-corp.com | reply to Kahn10
I'm confused about what you are asking. Are you wondering if I can ping the outside of the router from the client? I can do that. There isn't really any way to ping in the other direction because the computer is on the inside of a network. |
|
Kahn10
@dis-corp.com
| reply to Kahn10
So after this was reviewed by everyone in our company who know even a smidge about Cisco's we decided to test from a different network. This time it worked without issue.
I'm not sure why this isn't working from our DSL test lab; we have other connections that work without trouble from there. If anyone has any theories I would love to know. I am no longer seeking a solution at this point though.
Thank you all for your assistance. |
|
Kahn10
@dis-corp.com
| reply to Kahn10
Scratch that, it is only working from one network, not from any others. From tho customer PC we get:
[code]
###.###.###.81 ###.###.###.144 AG_INIT_EXCH 1 0
...
So different, but still not connecting.
Back to square one. |
|
ndegwa
join:2007-06-14
kenya
| Based on the link below, you might try and confirm the pre-shared keys on both sides.
»www.cisco.com/en/US/tech/tk583/t···25.shtml |
|
ndegwa
join:2007-06-14
kenya |
Am not sure if it's picking from
1. crypto map cm-cryptomap isakmp authorization list groupauthor
or
2. crypto isakmp client configuration group VPNclient
key folco123 |
|
kamikatze
join:2007-11-02
| reply to Kahn10
Make sure the dynamic crypto map has the lowest priority of all.
Something like this
crypto map map-static-1 1139 ipsec-isakmp
crypto map map-static-1 1140 ipsec-isakmp
crypto map map-static-1 1144 ipsec-isakmp
crypto map map-vpnclient-1 3000 ipsec-isakmp dynamic vpn_client |
|
