ASA - Checkpoint IPSEC issue

VPN
1

HI, I have a tunnel between the above mentioned technologies. We have strange behavior that servers stop being able to access some servers on the remote tunnel (ASA side) It only impacts a few subnets. While this issue is present I can see data travelling across for other interesting traffic. the only way to get things working again is to clear the association, however this does not always work and either requires multiple attempts at clearing the association or restarting the ASA altogether. I think the issue is triggered when the association expires (which is set by time alone).

I created a script to ping to one of the impacted subnets and log and alert me when data flow stops. I was trying to 100% prove that it was stopping when the association expired however found something interesting. see the following config excerpt:

​

rypto ipsec security-association lifetime seconds 86400

crypto ipsec security-association pmtu-aging infinite

crypto map VPN 1 match address VPN-UK-CP

crypto map VPN 1 set peer X.X.X.X

crypto map VPN 1 set ikev1 transform-set VPN-TS

crypto map VPN 1 set security-association lifetime seconds 28800

crypto map VPN 1 set security-association lifetime kilobytes unlimited

​

I was expecting the SA to expire after 8 hours (28800 Seconds) however it didn’t and when i checked the SA status noticed it had plenty of time remaining, in fact more than 28,800 seconds. It seems the config is not taking on the crypto map specific setting and is using the global 86400 setting. According to Cisco docs this should be the other way around which makes more sense

​

IKE Peer: X.X.X.X

Type : L2L Role : responder

Rekey : no State : MM_ACTIVE

Encrypt : aes-256 Hash : SHA

Auth : preshared Lifetime: 86400

Lifetime Remaining: 57524

​

Although the reassociation may be the trigger for the data stopping, i would like to get to the root cause.

​

Some other info that may help

Originally we had exact matching rule set on both sides of the Tunnel, however in attempt to simplify the issue from the ASA end I simply allowed all traffic to flow between the two subnets. Checkpoint still has specific IPs and port selectors defined

Config example

object-group network KL-LAN

Network object 172.27.1.0 255.255.255.0

Network object 172.27.2.0 255.255.254.0

object-group network UK-LAN

Network object 10.1.1.0 255.255.255.0

Network object 10.1.10.0 255.255.255.0

Network object 10.32.2.0 255.255.254.0

​

access-list VPN-UK-CP extended permit ip object-group UK-LAN object-group KL-LAN

access-list VPN-UK-CP extended permit ip object-group KL-LAN object-group UK-LAN

​

Below are the failures encountered:

All IP traffic stops that originates from AD server 10.1.1.8 with destination of AD Server 172.27.1.10, however 172.27.1.10 can still ping and communicate with 10.1.18

While in this failure mode users from 10.32.2.0/23 can ping 172.27.1.10 which is allowed by the same rulebase.

​

Any thoughts appreciated.

​

2

Thoughts about the IPsec configuration:

  • IKEv1 was deprecated by IETF about a year ago. It doesn’t offer the current strong cryptographic algorithms.
  • The ASA ACL for VPN should contain only the IPs on the ASA side as source and remote side as destination.
  • If the tunnel is down, can it be initiated from both sides without restrictions?
  • Your command crypto ipsec security-association lifetime seconds 86400 changes the global phase 2 lifetime from 28800 to 86400, the command crypto map VPN 1 set security-association lifetime seconds 28800 changes the phase 2 lifetime back to the default 28800. Your show command displays phase 1 lifetime, which is default 86400.
  • For troubleshooting you should observe phase 2 SAs, not phase 1

Phase 2 proposals (local/remote proxy) should match on both sides, otherwise the behavior can be asymmetric. Also other parameters for the child SA should be identical, e.g. perfect forward secrecy.

The RFC doesn’t specify the behavior if initiator and responder proxies are different.

Cisco’s responder implementation:

Initiator proxy is a subset of responder proxy: the subset is chosen and installed in the child SA.

Initiator proxy is a superset of responder proxy: the request is rejected.

Thoughts about traffic denied:

When you observe pings successful in one direction but fail in the other it’s more likely a statefull firewall issue than IPsec.

General recommendations:

Keep the IPsec configuration simple on both sides, use only IP and mask. Solve traffic policies like protocol/ports with firewall rules.

https://www.cisco.com/c/en/us/td/docs/security/asa/asa91/configuration/vpn/asa_91_vpn_config/vpn_ike.html#18947

Using Interface ACLs

By default, the ASA lets IPsec packets bypass interface ACLs. If you want to apply interface ACLs to IPsec traffic, use the no form of the sysopt connection permit-vpn command.

3

The Cisco configuration looks okay from what I can tell. The main thing with CheckPoint is to make sure the tunnel sharing is setup properly, if not, you get weird IKE SA issues with one way traffic. ASA & CheckPoint are normally solid when this is configured properly.

First, what CheckPoint version is in play here? Hopefully R80.40+, as that makes things easier.

The CheckPoint should be setup to one tunnel per subnet, otherwise they might be sending you hosts, which would make the IKE negotiations weird.

If they are setup for subnet sending, it might be the wrong size due to whatever is in their main encryption domain for their gateway. This can easily be resolved in R80.40+, which allows for granular encryption domains per VPN community. If not, then you’ll have to match what they have or they need to rework their end.

4

Thanks for your reply.

  1. I will raise the issue of IKEv1 with the peer admin.

  2. What your saying is i don’t need the reverse of the rule? remove

access-list VPN-UK-CP extended permit ip object-group UK-LAN object-group KL-LAN

  1. Tunnel can be initiated from both sides and when working well traffic flows as required

I would be interested in tips for troubleshooting phase 2 in more detail.

Also interested to know more about this statement and how to confirm it.

Phase 2 proposals (local/remote proxy) should match on both sides, otherwise the behavior can be asymmetric. Also other parameters for the child SA should be identical, e.g. perfect forward secrecy.

Regards