0

I have an IPsec site-site VPN set up and working, however I'm having problems once the connection has been established for over an hour. After an hour ASDM still thinks the VPN is connected and the connection duration continues to increment, however as soon as UI try to send data down it the tunnel gets torn down and recreated along with a rst packet sent from our firewall to the client machine on our network. I've turned logging on and the following two lines look the most interesting:

Session Disconnected. ... Reason: crypto map policy not found
...
Connection terminated for peer 213.123.59.222.  Reason: Peer Terminate  Remote Proxy 78.129.136.64, Local Proxy 171.28.18.50

The 213.123.59.222 is their external ip for the checkpoint box, 78.129.136.64 is a machine on our local network sending the data, and 171.28.18.50 is a machine on their network I'm trying to send data to.

My timeout config is as follows:

timeout conn 0:00:00 half-closed 0:10:00 udp 0:02:00 icmp 0:00:02
group-policy DfltGrpPolicy attributes
 vpn-idle-timeout 180
 vpn-tunnel-protocol IPSec svc 

I'd like to understand if the problem is config on ours (ASA5505) or the customers firewalls (Checkpoint). Is there anything else I can check my side before I get in touch with them?

Update: When I do show configuration my access lists and crypto maps are as follows (sorry if there's missing lines and funny names like 'bob', I'm a little out of my depth and found it a bit trial and errorish setting the VPN up!):

access-list basic extended permit tcp any any eq 3389 
access-list basic extended permit tcp any any eq ssh 
access-list basic extended permit tcp any any eq www 
access-list basic extended permit tcp any any eq https 
access-list basic remark MySQL
access-list basic extended permit tcp any any eq 3306 
access-list allow extended permit ip any any 
access-list NoNAT extended permit ip 78.129.136.64 255.255.255.240 10.199.2.0 255.255.255.0 
access-list SiteAtoSiteB extended permit ip 78.129.136.64 255.255.255.240 10.199.2.0     255.255.255.0 
access-list SiteAtoSiteB extended permit tcp 78.129.136.64 255.255.255.240 host 171.28.18.50 eq telnet 
access-list bob standard permit host 171.28.18.50 
...
crypto map SiteToSiteVPN 10 match address SiteAtoSiteB
crypto map SiteToSiteVPN 10 set pfs 
crypto map SiteToSiteVPN 10 set peer 213.123.59.222 
crypto map SiteToSiteVPN 10 set transform-set SiteAToSiteBtransform
crypto map SiteToSiteVPN 10 set security-association lifetime seconds 28800
crypto map SiteToSiteVPN 10 set security-association lifetime kilobytes 4608000
crypto map SiteToSiteVPN interface Outside

Sorry, I think I misunderstood Shane's comment, perhaps this info was in the error statement. The logging statements generated when the first piece of data after an hr is sent is:

Teardown local-host Outside:171.28.18.50 duration 1:59:35
Teardown TCP connection 27792859 for Outside:171.28.18.50/23 to Inside:78.129.136.66/48572 duration 1:59:35 bytes 86765 Tunnel has been torn down
Ignoring msg to mark SA with dsID 72404992 dead because SA deleted
Group = 213.123.59.222, Username = 213.123.59.222, IP = 213.123.59.222, Session disconnected. Session Type: IPsec, Duration: 1h:59m:53s, Bytes xmt: 45646, Bytes rcv: 53194, Reason: crypto map policy not found
Pitcher: received key delete msg, spi 0xf025f6b
Pitcher: received key delete msg, spi 0x7447991f
Pitcher: received key delete msg, spi 0x7447991f
IP = 213.123.59.222, IKE_DECODE SENDING Message (msgid=27f78398) with payloads : HDR + HASH (8) + DELETE (12) + NONE (0) total length : 80
Group = 213.123.59.222, IP = 213.123.59.222, constructing qm hash payload
Group = 213.123.59.222, IP = 213.123.59.222, constructing IKE delete payload
Group = 213.123.59.222, IP = 213.123.59.222, constructing blank hash payload
IPSEC: An outbound LAN-to-LAN SA (SPI= 0x0F025F6B) between 87.117.211.90 and 213.123.59.222 (user= 213.123.59.222) has been deleted.
IPSEC: An inbound LAN-to-LAN SA (SPI= 0x7447991F) between 87.117.211.90 and 213.123.59.222 (user= 213.123.59.222) has been deleted.
Group = 213.123.59.222, IP = 213.123.59.222, sending delete/delete with reason message
Group = 213.123.59.222, IP = 213.123.59.222, IKE SA MM:a6daae8d terminating:  flags 0x01000002, refcnt 0, tuncnt 0
Group = 213.123.59.222, IP = 213.123.59.222, IKE SA MM:a6daae8d rcv'd Terminate: state MM_ACTIVE  flags 0x00000042, refcnt 1, tuncnt 0
Group = 213.123.59.222, IP = 213.123.59.222, IKE Deleting SA: Remote Proxy 171.28.18.50, Local Proxy 78.129.136.64
Group = 213.123.59.222, IP = 213.123.59.222, Active unit receives a delete event for remote peer 213.123.59.222.
Group = 213.123.59.222, IP = 213.123.59.222, Connection terminated for peer 213.123.59.222.  Reason: Peer Terminate  Remote Proxy 78.129.136.64, Local Proxy 171.28.18.50
Group = 213.123.59.222, IP = 213.123.59.222, processing delete
Group = 213.123.59.222, IP = 213.123.59.222, processing hash payload
IP = 213.123.59.222, IKE_DECODE RECEIVED Message (msgid=b3da5da4) with payloads : HDR + HASH (8) + DELETE (12) + NONE (0) total length : 68
Built inbound UDP connection 27794863 for Outside:213.123.59.222/500 (213.123.59.222/500) to identity:87.117.211.90/500 (87.117.211.90/500)
Built local-host Outside:213.123.59.222
4
  • What's your crypto map ... and associated ACL configuration look like? Jul 13, 2011 at 18:16
  • @Shane I've probably posted far more than I needed to in the edit but the first time I thought it was the entire acl and crypto map config you was after and then something clicked that your ... probably meant it was in the logging.
    – James
    Jul 13, 2011 at 19:15
  • Config was what I was after, but the logs helped more in this case (config looks good). Looks like the remote peer tore down the connection - you may be stuck contacting them for info and logs. The connection time was just a hair under 2 hours; that may be significant. Jul 13, 2011 at 20:03
  • @Shane Thanks for your help, I'll get in touch with them tomorrow. If they did tear it down, why does the connection still show as active before it's torn down? The 2 hours is because the previous request was at approx 0:59:35 and I wait an hour before sending more data. I'm pretty sure this idle hr is unrelated in the config my side - I've been fixing idle timeouts for the past couple of days and the problem now seems to have moved to the other side of the VPN.
    – James
    Jul 13, 2011 at 21:06

1 Answer 1

2

This is a common issue with Cisco + CP VPNs. Please check the SA Life Expiry settings for both sides, I believe it's 28800 seconds with Check Point and 86400 with Cisco (or the other way around)

4
  • Would this be set with crypto map SiteToSiteVPN 10 set security-association lifetime seconds 28800?
    – James
    Jul 14, 2011 at 11:26
  • 1
    @James There's two different lifetime settings; one for ISAKMP (phase 1) and one for IPSec (phase 2). Both default to 86400 in Cisco's world, and both should match the other side of the tunnel. The command that you listed controls IPsec, while the ISAKMP lifetime is under the crypto isakmp policy XX config. Jul 14, 2011 at 15:06
  • @Shane OK got it. I've been through and changed the config, I'm pretty sure it matches the other side now. It seems that the phase 1 is 86400 and the phase 2 is 3600. Since the tunnel keeps dropping after an hr it looks suspiciously like the 3600 lifetime. If the settings matched etc and everything was working as it should, what would happen to an active tcp connection after the 3600 seconds? Can a new tunnel be established and the tcp connection remain active?
    – James
    Jul 14, 2011 at 15:50
  • @James Phase 2 should rekey at the end of its lifetime, keeping the session alive (but forcing resend on a few packets to trigger the rekey and during it). And a correction to my earlier statement - defaults for Cisco look to be 86400 on phase 1 and 28800 on phase 2. Jul 14, 2011 at 16:03

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .