EzVPN client loses connection and doesn't attempt to reconnect
I have a Cisco 871 router configured as an EzVPN client connecting to a PIX. The router is running latest IOS (c870-advsecurityk9-mz.124-15.T1.bin) and the PIX is running 6.3(5) code.
Every so often, the remote 871 router will drop its VPN connection to the PIX and will not re-attempt to establish it.
I've configured "crypto isakmp keepalive 30 20 periodic" on the 871 and the ezvpn client is configured for "connect auto".
I can connect to the 871's global IP address, so it has Internet connectivity. When I display the crypto ipsec client ezvpn, it tells me that IPSEC is active, yet there are no crypto isakmp sa's or crypto ipsec sa's displayed.
I also have a "debug crypto ipsec client ezvpn" and "debug crypto isakmp" running on the 871, and I see no debugs.
I've tried forcing traffic by pinging from an internal host to the main site, but it doesn't attempt to re-establish the VPN.
I guess what bothers me the most is that the ezvpn client is displaying the "IPSEC_ACTIVE" state, when it really isn't.
Am I missing something here?
I've attached a text file with the 871's configuration. It also has a show version, and the sho crypto commands that I've mentioned.
Thanks in advance for any help.
(P.S. -- Also, if I reboot the router, it automatically re-connects, or I can force it by manually connecting. I just can't seem to have the router itself re-connect on its own.)
Re: EzVPN client loses connection and doesn't attempt to reconne
The reason your ezvpn client is displaying the "IPSEC_ACTIVE" state is because the connection is not properly terminated from remote end (i.e PIX). Make sure you have configured "isakmp keepalive 30 20" on PIX also. By configuring keepalives on both sides, when the tunnel goes down the IPSEC peer will be aware of the tunnel loss and flush all the isakmp and ipsec SA that it has for the previous connection. With this mechanism, when traffic tries to go over the tunnel, both sides will try to rebuild the tunnel and cases of invalid SPI will be avoided.
We have configured the outside and inside Interface with official ipv6 adresses, set a default route on outside Interface to our router, we also have definied a rule , which also gets hits, to permit tcp from inside Interface to any6.
In Syslog I also se...