cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1704
Views
0
Helpful
4
Replies

Problem with LAN to LAN VPN tunnel dropping randomly between an ASA-5510 and a CheckPoint

baskervi
Level 1
Level 1

We've been fighting this problem for some time. The company that controls the CheckPoint will not make changes on their end because the VPN tunnel to our ASA is the only one dropping (it's the only tunnel to an ASA they have), but our tunnel to them is the only one that's dropping (and they are the only CheckPoint we have). Our VPN domain consists of 5 host entries, and when connectivity fails, it's only to one or two hosts. The other hosts traversing the tunnel to the CheckPoint are still passing bidirectional traffic. When a host can no longer reach the remote site, the packet tracer fails at the following:

Result:
input-interface: DMZ2
input-status: up
input-line-status: up
output-interface: outside
output-status: up
output-line-status: up
Action: drop
Drop-reason: (acl-drop) Flow is denied by configured rule

We have no ACL configured on our end to block traffic. We have no hits at this point for phase 2 - packets encapsulated and decapsulated both show 0. We can clear the tunnel, and it comes back up just fine, and all hosts can pass traffic just fine. The packet tracer then goes all the way through just fine, and there is no longer any Drop-reason. We've increased the timeouts for phase 1 and phase 2, and although the problem seems to be slightly better, it still happens a few times per week (sometimes a few times per day). We did confirm the timeouts were the same on both ends before we increased them on our side, so I didn't expect a change.

Does anyone have any ideas? We're getting to the end of our ropes here. Thanks

 

4 Replies 4

Hello baskervi

 

- When there is not communication between the hosts, is Phase 1 or Phase 2 down?

- Is there any log error when the issue happens? 

- What's your phase 1 and phase 2 lifetime configuration?

Thanks for the response, Andres.

1) When there is no communication between hosts, phase 1 (MM Active) and phase 2 are both up. I can do a show cryp ips sa, and I see an entry for the two hosts, but the packet count is 0. 

2) I noticed something looking at the logs I hadn't seen before. When the tunnel is not passing traffic, I see phase 2 continuing to renegotiate every 3 seconds or so. There are no error messages or reason for the tunnel to renegotiate (maybe I need to increase the debug level), but I see a "crypto map matched" followed by a "Looking for crypto map matching 5-tuple" over and over with nothing in between.

IPSEC(crypto_map_check)-3: Looking for crypto map matching 5-tuple: Prot=6, Src=x.x.118.31:64215, Dest=10.7.2.54:61701
IPSEC(crypto_map_check)-5: Checking crypto map FOTMAP 5: skipping because 5-tuple does not match ACL ipsec1.
...
IPSEC(crypto_map_check)-3: Checking crypto map FOTMAP 97: matched.
IPSEC(crypto_map_check)-3: Looking for crypto map matching 5-tuple: Prot=6, Src=x.x.118.31:64215, Dest=10.7.2.54:61701
IPSEC(crypto_map_check)-5: Checking crypto map FOTNMAP 5: skipping because 5-tuple does not match ACL ipsec1.
...
IPSEC(crypto_map_check)-3: Checking crypto map FOTNMAP 97: matched.

 

3) Currently, phase 1 is set to "lifetime none" and phase 2 is set to 2147483647 seconds. When I initially filled out the VPN checklist (and as far as I've been told) the remote end is set to phase 1 of 28,800 seconds and phase 2 of 3,600 seconds. However, during a debug, I ran across the following:

May 11 20:59:29 [IKEv1]: IP = x.x.31.148, Keep-alives configured on but peer does not support keep-alives (type = None)

Hello baskervi, 

 

If I understand correctly, when the issue happens (no communication between x.x.118.31 and 10.7.2.54), phase 1 and phase 2 remains up but according to the logs they are trying to negotiate this phase 2 SA again. 

Setting the logs to debuging would definitely give you a better idea about what's happening with this renegotiation. 

In the ASA you cannot set up a Phase 1 or phase 2 lifetime to "none"; however, keepalives (DPD) can be setup this way. According to the log it seems like you may have it enabled but the remote end doesn't or doesn't support DPDs. 

 

- Was this tunnel working fine before or it has been always having this problem?

- I would suggest to look in your configuration for any duplicate ACL entry for this tunnel and the rest of your tunnels. 

- What ASA version are you running? Check for a duplicate ASP entry in the ASA even if you don't match the versions described on CSCtb53186

The tunnel has been setup for about 9-10 months. It worked OK maybe a month before it started exhibiting this problem, but it wasn't established very long before it starting occurring.

I've checked for duplicate entriies in the past and did again today just to make sure. There are no duplicate ACLs for this or any other tunnel. If I enter "dallasfw01# sh runn | in 10.7.2.54", the only line returned in the entire configuration is access-list MYVPNTUNNEL extended permit ip host x.x.118.31 host 10.7.2.54.

 

The ASA is running 8.2(5). I checked for duplicate ASP entry, but in the VPN Phase, I see "hits=3750, user_data=0x0, cs_id=0xd86176c0, reverse, flags=0x0, protocol=0". I do see the hits continue to increase, but the user_data remains 0x0 for the broken tunnel until the tunnel is reset. The same host on our end (x.x.118.31) is also sending data to another host behind the same firewall (10.8.56.6), and that tunnel never goes down.

The tunnel went down yesterday and again just a moment ago, so I turned on "deb cryp isa 255" and "deb cryp ips 255". For ISAKMP, I had absolutely no hits for this tunnel. For phase 2, I see the same thing as previously:

IPSEC(crypto_map_check)-5: Checking crypto map FOTNMAP 5: skipping because 5-tuple does not match ACL ipsec1.
...
IPSEC(crypto_map_check)-3: Checking crypto map FOTNMAP 97: matched.
IPSEC(crypto_map_check)-3: Looking for crypto map matching 5-tuple: Prot=6, Src=x.x.118.31:63445, Dest=10.7.2.138:36895
IPSEC(crypto_map_check)-5: Checking crypto map FOTNMAP 5: skipping because 5-tuple does not match ACL ipsec1.
...
IPSEC(crypto_map_check)-3: Checking crypto map FOTNMAP 97: matched.
IPSEC(crypto_map_check)-3: Looking for crypto map matching 5-tuple: Prot=1, Src=x.x.118.31:256, Dest=10.7.2.54:256
IPSEC(crypto_map_check)-5: Checking crypto map FOTNMAP 5: skipping because 5-tuple does not match ACL ipsec1.
...

The above repeats every second or two. The only thing else I can find is the packet-tracer that shows the following for the VPN Phase: "

Phase: 10
Type: VPN
Subtype: encrypt
Result: DROP
Config:
Additional Information:
 Forward Flow based lookup yields rule:
 out id=0xd8622ee8, priority=70, domain=encrypt, deny=false
        hits=3754, user_data=0x0, cs_id=0xd86176c0, reverse, flags=0x0, protocol=0
        src ip=216.138.118.31, mask=255.255.255.255, port=0
        dst ip=10.7.2.54, mask=255.255.255.255, port=0, dscp=0x0

Result:
input-interface: DMZ2
input-status: up
input-line-status: up
output-interface: outside
output-status: up
output-line-status: up
Action: drop
Drop-reason: (acl-drop) Flow is denied by configured rule

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: