Cisco RV082 to ASA 5510 tunnel freezes after 8 hours.

james.blish · ‎04-19-2012

I have a RV082 that has an issue keeping an IPSEC Gateway to Gateway VPN running from itself to our ASA 5510.

At 8 hours of connectivity (I can almost set a clock to it) the Tunnel will say it is connected on the RV082 but on the ASA 5510 the tunnel is not up.

If I click on disconnect on the RV082 under the VPN Summary page things will come back up. from the ASA 5510 side there is nothing I can do to get things back (ping inside "vpn network" or even trying to make a connection to a networked VPN machine).

To make things more complicated I have another VPN on the RV082 to a PIX 506e that works with no issues. I also have another RV082 at another location with the same settings that keeps its tunnel with the ASA 5510 with out any issue.

Some things I have tried to try and fix the issue are:

I upgrade the firmware on the Rv082 V3 from 4.0.0.7-tm (what it was shipped with) to 4.1.1.01-sp) - This seemed to have no effect.

on the RV082 I have changed the MTU from automatic to 1428 and 1452 - all this does is make the connection to the PIX 506e unstable like it is for the ASA 5510 I have changed this back to automatic.

since the time of stability seems to be 8 hours I have changed the "Phase 1 SA life time" and "Phase 2 SA life time" to 28800 both at the same time and individually - This seemed to have no effect.

The current configuration on the RV082 are:

Local security gateway type: IP Only

IP address: (local ISP provided static IP address)

Local security group type: subnet

IP address: 192.168.30.0

subnetmask: 255.255.255.0

Remote security gateway type: IP only

IP address: Remote address provided by ISP

Remote Security type: Subnet

IP address: 192.168.26.0

subnet mask: 255.255.255.0

Keying mode: IKE with Preshared key

Phase 1 DH Group: Group 2 - 1024 bit

Phase 1 Encryption: 3DES

Phase 1 Authorentication: MD5

PHase 1 SA Life Time: 86400

Perfect forward secrecy: is not checked.

Phase 2 DH Group: Group 2 - 1024 bit

Phase 2 Encryption: 3DES

phase 2 Authentication: MD5

Phase 2 SA Life Time: 86400

Preshared key: <shared-key>

Minimum Preshared Key Complexity: is checked

Preshared Key Strength meter: goes to 2 green boxes.

advanced setting nothing is set up.

ASA IPSEC related settings for this VPN:

crypto ipsec transform-set ESP-AES-256-MD5 esp-aes-256 esp-md5-hmac

crypto ipsec transform-set ESP-DES-SHA esp-des esp-sha-hmac

crypto ipsec transform-set ESP-3DES-SHA esp-3des esp-sha-hmac

crypto ipsec transform-set ESP-DES-MD5 esp-des esp-md5-hmac

crypto ipsec transform-set ESP-AES-192-MD5 esp-aes-192 esp-md5-hmac

crypto ipsec transform-set ESP-AES-256-SHA esp-aes-256 esp-sha-hmac

crypto ipsec transform-set ESP-AES-128-SHA esp-aes esp-sha-hmac

crypto ipsec transform-set ESP-AES-192-SHA esp-aes-192 esp-sha-hmac

crypto ipsec transform-set ESP-AES-128-MD5 esp-aes esp-md5-hmac

crypto ipsec transform-set TRANS_ESP_3DES_SHA esp-3des esp-sha-hmac

crypto ipsec transform-set TRANS_ESP_3DES_SHA mode transport

crypto ipsec transform-set ESP-3DES-MD5 esp-3des esp-md5-hmac

crypto ipsec transform-set ESP-AES-SHA esp-aes esp-sha-hmac

crypto ipsec security-association lifetime seconds 28800

crypto ipsec security-association lifetime kilobytes 4608000

crypto ipsec df-bit clear-df inside

crypto dynamic-map SYSTEM_DEFAULT_CRYPTO_MAP 65535 set pfs group1

crypto dynamic-map SYSTEM_DEFAULT_CRYPTO_MAP 65535 set transform-set ESP-AES-128-SHA ESP-AES-128-MD5 ESP-AES-192-SHA ESP-AES-192-MD5 ESP-AES-256-SHA ESP-AES-256-MD5 ESP-3DES-SHA ESP-3DES-MD5 ESP-DES-SHA ESP-DES-MD5

crypto map internet_map 7 match address internet_cryptomap_7

crypto map internet_map 7 set peer (Static_IP_ADDRESS)

crypto map internet_map 7 set transform-set ESP-3DES-MD5

crypto map internet_map 7 set reverse-route

crypto isakmp enable internet

crypto isakmp policy 4

authentication pre-share

encryption aes

hash sha

group 2

lifetime 86400

crypto isakmp policy 5

authentication pre-share

encryption 3des

hash sha

group 2

lifetime 86400

crypto isakmp policy 10

authentication pre-share

encryption des

hash sha

group 2

lifetime 86400

crypto isakmp policy 30

authentication pre-share

encryption 3des

hash md5

group 2

lifetime 86400

tunnel-group (Static_IP_ADDRESS) type ipsec-l2l

tunnel-group (Static_IP_ADDRESS) ipsec-attributes

pre-shared-key <shared-key>

thanks in advance.

rocater · ‎04-20-2012

Hello Jim,

Given the time problem I would say it is the lifetime that is causing the issue. I know you mentioned changing the lifetime settings as well, but there is still this line-

"crypto ipsec security-association lifetime seconds 28800"

I wish there was more I could do for you but my ASA knowledge is limited.

rmanthey · ‎04-20-2012

Jim,

What is the Crypto map that is assigned to the outside (internet) interface? Verify the ASA dosn't have PFS turned on, because it is on by default.

hope this helps

Cisco Small Business Support Center

Randy Manthey

CCNA, CCNA - Security

james.blish · ‎04-20-2012

Thank you Robert,

The problem is that I don't want to change the ASA it has 4 working VPN's on it already and if i make a change on the ASA i could be ruining those stable VPN's you wouldn't by any chance know if the:

crypto ipsec security-association lifetime seconds 28800

corrilates with Phase 1 or Phase 2 as defined by the RV082 (I have been assuming that it is phase 1 but my brain has become broken on this issue)

Hello Randy,

for the default crypto map I believe this is it:

crypto dynamic-map SYSTEM_DEFAULT_CRYPTO_MAP 65535 set pfs group1

I see that PFS is turned on I will try adjusting that this evening/weekend on the RV082 (again don't want to make sweeping changes on the ASA as it is the more important and stable piece in this) and let you know how things go.

james.blish · ‎04-20-2012

i've changed the phase 1 to 28800 again we will see if this makes it.

james.blish · ‎04-21-2012

after the change the colapse happened at 6 hours instead of 8. change phase 1 back to 86400 and phase 2 to 28800. also tried pfs with 86400 on both phases and still no connection can be made.

when pfs is checked the error I see that I believe is the issue for connectivity is

#171: Sending encrypted notification NO_PROPOSAL_CHOSEN to (STATIC_IP_ADDRESS):500

Deleteing connection

any other ideas?

will notify again when tunnel colapses again or if it is stable with phase 2 at 28800

james.blish · ‎04-22-2012

had crash with 28800 for phase 2 and put it for both phases on the RV082 still 8 hour drops. I changed the advanced to "agressive mode" the tunnel stayed up for 18 hours with that but after colapse could not connect again until agressive mode was turned off.

Any other ideas?

rmanthey · ‎04-23-2012

Jim,

Is PFS on for Phase 2 on the ASA? how about the RV? What DH group on both? it looks like group1 on the ASA.

Does phase 2 ever rekey correctly?

What is the lifetime for phase 1?

Does Phase 1 stay connected?

what happens if you run a constant ping through the tunnel, does it stay up longer than the 8 hours?

Are the Date and times correct on both devices?

Can you provide the settings of the RV?

Cisco Small Business Support Center

Randy Manthey

CCNA, CCNA - Security

james.blish · ‎04-23-2012

Hello Randy,

For PFS on the ASA I believe it is on phase 1:

crypto dynamic-map SYSTEM_DEFAULT_CRYPTO_MAP 65535 set pfs group1

on the RV it isn't turned on at all when it is checked the VPN tunnel never connects.

I have no idea if the phase 2 is ever rekeyed if you tell me how I can check that I will look.

Lifetime for phase 1 is 28800 if I am reading correctly:

crypto ipsec security-association lifetime seconds 28800

on the RV if I set this uptime seems to drop to 5 hours so currently it is set at 86400

phase 1 seems to stay connected on both devices I am not sure how to check this as well.

If I do a constant ping from the asa to RV (and the other way around) the tunnel still drops at 8 hours. In fact the tunnel will go down in the middle of the day if I do not premtively drop it and bring it up while people are using the connection.

the dates on both systems are the same and use NTP to stay in check. the RV082 has the daylight savings pieces put in.

Is there a way to scrub the RV's export and I will post it but with a straight export it is semi encoded and I would rather not have my passwords and ip addresses posted to the internet if I could avoid it.

rmanthey · ‎04-23-2012

Jim,

I would recommend you call into the 1866-606-1866 and create a case so your configuration can remain confidential.

On the ASA CLI you could run:

Show crypto isakmp sa - phase 1

show crypto ipsec sa - phase 2

Just the logs on the RV is the only place to see if it is attempting to re-key.

Cisco Small Business Support Center

Randy Manthey

CCNA, CCNA - Security

james.blish · ‎04-23-2012

Hello Randy,

from the ASA:

Show crypto isakmp sa

4   IKE Peer: (IP address)
    Type    : user            Role    : initiator
    Rekey   : no              State   : MM_WAIT_MSG2

Show crypto ipsec sa

from the RV there is nothing that happens before the crash for 4 hours (crash happened at 20:55)

Apr 23 17:40:21 2012 VPN Log (g2gips0) #2099: ignoring Vendor ID payload [XAUTH]
Apr 23 17:40:21 2012 VPN Log (g2gips0) #2099: ignoring Vendor ID payload [XAUTH]
Apr 23 17:40:21 2012 VPN Log (g2gips0) #2099: received Vendor ID payload [Dead Peer Detection]
Apr 23 17:40:21 2012 VPN Log (g2gips0) #2099: received Vendor ID payload [Dead Peer Detection]
Apr 23 17:40:21 2012 VPN Log (g2gips0) #2099: ignoring Vendor ID payload [Cisco-Unity]
Apr 23 17:40:21 2012 VPN Log (g2gips0) #2099: ignoring Vendor ID payload [Cisco-Unity]
Apr 23 17:40:21 2012 VPN Log (g2gips0) #2099: ignoring Vendor ID payload [e3c2cddc6781d12ba5d08759c31a6d90]
Apr 23 17:40:21 2012 VPN Log (g2gips0) #2099: ignoring Vendor ID payload [e3c2cddc6781d12ba5d08759c31a6d90]
Apr 23 17:40:21 2012 VPN Log (g2gips0) #2099: [Tunnel Negotiation Info] <<< Initiator Received Main Mode 4th packet
Apr 23 17:40:21 2012 VPN Log (g2gips0) #2099: [Tunnel Negotiation Info] <<< Initiator Received Main Mode 4th packet
Apr 23 17:40:21 2012 VPN Log (g2gips0) #2099: [Tunnel Negotiation Info] >>> Initiator Send Main Mode 5th packet
Apr 23 17:40:21 2012 VPN Log (g2gips0) #2099: [Tunnel Negotiation Info] >>> Initiator Send Main Mode 5th packet
Apr 23 17:40:21 2012 VPN Log (g2gips0) #2099: [Tunnel Negotiation Info] >>> Initiator Receive Main Mode 6th packet
Apr 23 17:40:21 2012 VPN Log (g2gips0) #2099: [Tunnel Negotiation Info] >>> Initiator Receive Main Mode 6th packet
Apr 23 17:40:21 2012 VPN Log (g2gips0) #2099: Peer ID is ID_IPV4_ADDR: ipaddress
Apr 23 17:40:21 2012 VPN Log (g2gips0) #2099: [Tunnel Negotiation Info] Main Mode Phase 1 SA Established
Apr 23 17:40:21 2012 VPN Log (g2gips0) #2099: [Tunnel Negotiation Info] Main Mode Phase 1 SA Established
Apr 23 17:40:21 2012 VPN Log (g2gips0) #2099: ISAKMP SA established
Apr 23 17:41:11 2012 VPN Log (g2gips0) #2088: received Delete SA payload: deleting ISAKMP State #2088
Apr 23 17:41:11 2012 VPN Log (g2gips0) #2088: received Delete SA payload: deleting ISAKMP State #2088
Apr 23 21:07:49 2012 System Log HTTP Basic authentication success for user: admin

rmanthey · ‎04-24-2012

Hello Jim,

It looks like Phase 1 keeps rekeying. Does the RV082 have a public or private IP address on the WAN? Do you have NAT-T setup on the VPN?

If you are using a public IP is it static or DHCP?

RV?

ASA?

Can you set the Vendor-ID on the ASA to its outside IP address?

If all that is fine or can be done. I would recommend trying to turn off PFS on phase 1.

Cisco Small Business Support Center

Randy Manthey

CCNA, CCNA - Security

james.blish · ‎04-24-2012

Hello Randy,

The RV has a static public IP address. (as does the ASA)

only the ASA has NAT-T working on it the RV is strictly NAT outgoing only.

I'm not sure what you mean by set the Vendor-ID on the ASA to its outside IP address.

I will try turning off the PFS on the ASA with a: "no crypto dynamic-map SYSTEM_DEFAULT_CRYPTO_MAP 65535 set pfs group1" this evening

james.blish · ‎04-25-2012

Thank you Randy,

The removal of PFS seems to have worked the tunnel has now been up for 12 hours. after 48 hours if things are still good I will say everything is good.

rmanthey · ‎04-25-2012

Most likely some thing in the shared secret DH values are not matching when hashed.

Cisco Small Business Support Center

Randy Manthey

CCNA, CCNA - Security