ScreenOS Firewalls (NOT SRX)
Highlighted
ScreenOS Firewalls (NOT SRX)

VPN Dropping Connection Frequently

‎07-08-2014 07:45 AM

So I have a route based VPN setup between me an on offsite host. Everything is working and traffic is getting to and from fine but the VPN drops connection pretty frequently and I cannot figure out the reason. The information they gave me for the setup:

 

Peer IP address:

72.xxx.xx.xxx (Kansas)

 

Device Make:

Cisco

 

Device Model:

ASA 5540

 

Firmware Version:

8.4(2)

 

 

Phase I Proposal

AES-256 – SHA1

 

Phase I Lifetime (sec)

86400

 

Diffe-Hellman Group

5

 

PFS (Yes/No)

No

 

Mode (Main/Aggressive)

Main

 

 

Phase II Proposal

AES-256 – SHA1

 

Phase II Lifetime (sec)

28800

 

 

I can provide the config file if necessary. One thing did stick out to me though in the config file is a line that reads "set ike ikev2 ike-sa-soft-lifetime 60". I know the host said they used IKEv1 when they set it up and in the WebOS GUI the gateway is specified to use IKEv1 but, when you go to the gateway it just says AutoIKE and the config file has that line specfying IKEv2 which makes me thing this might be the problem with the mismatch?

2 REPLIES 2
Highlighted
ScreenOS Firewalls (NOT SRX)

Re: VPN Dropping Connection Frequently

‎07-08-2014 09:34 AM

Do you see any messages in the logs?  Does the VPN go down around the same time each day or after x number of minutes/hours?

Highlighted
ScreenOS Firewalls (NOT SRX)
Solution
Accepted by topic author will@compudyne.it
‎08-26-2015 01:27 AM

Re: VPN Dropping Connection Frequently

‎07-08-2014 12:50 PM

I believe I have figured it out. It would negotiate the VPN and everything would be fine and then about 10 minutes later the logs would show up and down up and down continuously. Basically it all had to do with the VPN monitor. I found some troubleshooting steps per: http://kb.juniper.net/InfoCenter/index?page=content&id=KB9488.

Turning off the VPN monitor seemed to stabalize the connection. It hasn't dropped yet. I think the host was blocking ICMP requests.

 

Feedback