Pix 501 loses VPN tunnel overnight

I have a few stores that have lateley been losing their VPN connections overnight which requires me to restart my Sonicwall 3060 pro at corporate and their DSL modems and Pix 501's in the remote locations to re-sync those tunnels. Over the weekend I created a command prompt on my machine at corporate that sent out infinite ping requests and then that store retained it's connection. I turned that off yesterday and we lost the connection by morning.

Is there something that I can do that forces these connections to stay open?

Here is my config for the pix.
interface ethernet0 auto
interface ethernet1 100full
nameif ethernet0 outside security0
nameif ethernet1 inside security100
enable password xxxxxxxxxxxxxxx encrypted
passwd xxxxxxxxxxxxxxxxx encrypted
hostname pixfirewall16
domain-name domain.com
fixup protocol dns maximum-length 512
fixup protocol ftp 21
fixup protocol h323 h225 1720
fixup protocol h323 ras 1718-1719
fixup protocol http 80
fixup protocol rsh 514
fixup protocol rtsp 554
fixup protocol sip 5060
fixup protocol sip udp 5060
fixup protocol skinny 2000
fixup protocol smtp 25
fixup protocol sqlnet 1521
fixup protocol tftp 69
access-list pixtosnwl permit ip
access-list NONAT permit ip
access-list outside_access_in permit tcp any interface outside eq 5900
access-list outside_access_in permit tcp any any eq 5900
access-list outside_access_in permit icmp any any
no pager
logging on
mtu outside 1500
mtu inside 1500
ip address outside aa.bb.cc.dd
ip address inside
ip audit info action alarm
ip audit attack action alarm
pdm logging informational 100
pdm history enable
arp timeout 14400
global (outside) 1 interface
nat (inside) 0 access-list NONAT
nat (inside) 1 0 0
static (inside,outside) tcp interface 5900 5900 netmask 0 0
access-group outside_access_in in interface outside
route outside aa.bb.cc.ee 255
timeout xlate 0:05:00
timeout conn 1:00:00 half-closed 0:10:00 udp 0:02:00 rpc 0:10:00 h225 1:00:00
timeout h323 0:05:00 mgcp 0:05:00 sip 0:30:00 sip_media 0:02:00
timeout sip-disconnect 0:02:00 sip-invite 0:03:00
timeout uauth 0:05:00 absolute
aaa-server TACACS+ protocol tacacs+
aaa-server TACACS+ max-failed-attempts 3
aaa-server TACACS+ deadtime 10
aaa-server RADIUS protocol radius
aaa-server RADIUS max-failed-attempts 3
aaa-server RADIUS deadtime 10
aaa-server LOCAL protocol local
http server enable
http inside
no snmp-server location
no snmp-server contact
snmp-server community public
no snmp-server enable traps
tftp-server inside /configs
floodguard enable
crypto ipsec transform-set strong esp-3des esp-sha-hmac
crypto ipsec security-association lifetime seconds 86400
crypto map tosnwl 20 ipsec-isakmp
crypto map tosnwl 20 match address pixtosnwl
crypto map tosnwl 20 set peer aa.bb.cc.ff
crypto map tosnwl 20 set transform-set strong
crypto map tosnwl interface outside
isakmp enable outside
isakmp key xxxxxx address aa.bb.cc.ff netmask no-xauth no-config-mode
isakmp identity address
isakmp policy 20 authentication pre-share
isakmp policy 20 encryption 3des
isakmp policy 20 hash sha
isakmp policy 20 group 2
isakmp policy 20 lifetime 86400
telnet inside
telnet timeout 60
ssh aa.bb.cc.ff outside
ssh outside
ssh aa.bb.cc.ff inside
ssh timeout 60
management-access inside
console timeout 0
terminal width 80

Open in new window

Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

The odd thing in this is that you have to go through all of this work to bring them back up. The general idea of a VPN is that it comes up (usually in less than 1 ping) and is there when it is needed and disconnect when it is not. It sounds like you are loosing half the connection as I have seen a simular problem when the IKE piece become out of sync or drops but the IPSEC portion stays up. Do you know what lifetime values you have set up in your Sonicwall?

You might want to do some show commands and look at the output proior to resetting things next time.

Also i don't normally mess with the ipsec lifetime I usually just leave it at default and you have it set to one day.
crypto ipsec security-association lifetime seconds 86400

It may seem odd but I have had better luck shortening the lifetimes in these situation instead of lengthening them. As the longer they got the more trouble I seemed to run into.




Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
RidcoDoITAuthor Commented:
I will try and shorten them to 1 hr and see if that makes any difference. I only put that ipsec lifetime command because I was grasping for straws to figure out what will hold these things open.
Let me know if you have any other questions.

an hour might bit a bit on ths short side would allow you to test it. If it is better then push it out like 4-12hours.

Good Luck,

It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today

From novice to tech pro — start learning today.