Keeping a 501-501 VPN tunnel up when idle

Answered Question

Below is the config for the remote PIX 501.  I have read the article which discusses "Enable or Disable ISAKMP Keepalives".  I have configured isakmp keepalives on both PIX 501's.  When there is no traffic, the VPN usually drops, sometimes within a few hours, sometimes within a couple of days.  It always comes right back up when the remote initiates traffic.

But my questions are: can I configure it to always remain up?  Is a missed keepalive causing the tunnel to get dropped?  Is that just how it is with 501's?

Thanks for all comments.


don-pix# sh conf
: Saved
: Written by enable_15 at 11:42:11.280 UTC Sat Jan 2 1993
PIX Version 6.3(5)
interface ethernet0 auto
interface ethernet1 100full
nameif ethernet0 outside security0
nameif ethernet1 inside security100
enable password  encrypted
passwd encrypted
hostname don-pix
domain-name
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
names
name xxx.xxx.xxx.xxx ocean-pix-outside
access-list internet-traffic permit ip 192.168.1.0 255.255.255.0 any
access-list ping-permit permit icmp any any
access-list toOcean-nat permit ip 192.168.1.0 255.255.255.0 192.168.27.0 255.255
.255.0
access-list don-to-ocean-vpn permit ip 10.10.3.0 255.255.255.0 192.168.27.0 255.
255.255.0
pager lines 24
icmp deny any outside
mtu outside 1500
mtu inside 1500
ip address outside dhcp setroute
ip address inside 192.168.1.1 255.255.255.0
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) 1 access-list internet-traffic 0 0
static (inside,outside) 10.10.3.0 access-list toOcean-nat 0 0
access-group ping-permit in interface outside
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
no snmp-server location
no snmp-server contact
snmp-server community public
no snmp-server enable traps
floodguard enable
sysopt connection permit-ipsec
crypto ipsec transform-set ocean esp-des esp-md5-hmac
crypto map toOcean 20 ipsec-isakmp
crypto map toOcean 20 match address don-to-ocean-vpn
crypto map toOcean 20 set peer ocean-pix-outside
crypto map toOcean 20 set transform-set ocean
crypto map toOcean interface outside
isakmp enable outside
isakmp key ******** address ocean-pix-outside netmask 255.255.255.255
isakmp keepalive 60
isakmp policy 9 authentication pre-share
isakmp policy 9 encryption des
isakmp policy 9 hash md5
isakmp policy 9 group 2
isakmp policy 9 lifetime 86400
telnet 192.168.1.0 255.255.255.0 inside
telnet 192.168.27.0 255.255.255.0 inside
telnet timeout 30
ssh 0.0.0.0 0.0.0.0 inside
ssh timeout 5
management-access inside
console timeout 0
dhcpd address 192.168.1.2-192.168.1.33 inside
dhcpd lease 3600
dhcpd ping_timeout 750
dhcpd auto_config outside
dhcpd enable inside
terminal width 80
Cryptochecksum:
don-pix#

I have this problem too.
0 votes
Correct Answer by Marcin Latosiewicz about 6 years 5 months ago

Chris,

I might not be entirely on the money here.

But I belive that DPDs are not sent unless there is no return traffic for a period of time.


Normally you'd need to have 1 keepalive missed followed by 5 aggressive tries. So with your settings there should be a connection outage of some 1:10 + variance

Normally no idle timeout should apply to a L2L tunnels.

If you want to see a reason for tunnel being dropped I'm afraid we'd need to get debugs at the time of disconnect.

Marcin

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (1 ratings)
Loading.
Correct Answer
Marcin Latosiewicz Thu, 06/24/2010 - 10:04

Chris,

I might not be entirely on the money here.

But I belive that DPDs are not sent unless there is no return traffic for a period of time.


Normally you'd need to have 1 keepalive missed followed by 5 aggressive tries. So with your settings there should be a connection outage of some 1:10 + variance

Normally no idle timeout should apply to a L2L tunnels.

If you want to see a reason for tunnel being dropped I'm afraid we'd need to get debugs at the time of disconnect.

Marcin

Actions

This Discussion