Strange S2S VPN issue between ASA and Checkpoint

Site Feedback
1

Hi all, been having a frustrating issue on a IKEv2 S2S VPN from our ASA to the customer’s Checkpoint and wondering if anyone has encountered anything similar.

Basically, both sides can bring up the tunnel with interesting traffic with both phases negotiating successfully - however, when the tunnel is brought up from the ASA side the tunnel is unstable; we only seem to get unidirectional traffic (see bytes tx but nothing rx) - TCP pings from the ASA time out, and then the tunnel tears itself down after a couple of minutes with log messages simply saying ‘reason: peer lost’. When the tunnel is brought up from the Checkpoint side however, the tunnel comes up and there are zero issues - we can successfully TCP ping from the ASA and the tunnel doesn’t tear itself down.

During troubleshooting the engineer on the Checkpoint side confirmed that the tunnel comes up with both phases negotiated correctly when initiated from the ASA, and then said he was seeing the tunnel tear down due to DPD on the ASA (apparently they have disabled DPD on the Checkpoint).

As such, I have disabled DPD for this tunnel (setting the Idle Timeout on the tunnel’s group policy to Unlimited - I believe this disables DPD correct?) but I’m still seeing the same issues when initiating the tunnel from the ASA.

​

Q1: Post change I am seeing logs - “Local: x.x.x.x:4500 Remote: x.x.x.x:4500 Username: x.x.x.x IKEv2 need to send a DPD message to peer” → is this saying the ASA has received a DPD R-U-There message and needs to respond or is it saying the ASA is sending R-U-There messages to the Checkpoint and needs a response?

​

Q2: One difference I have noticed when the tunnel is initiated from the Checkpoint is that the tunnel SA is listed as “IKEv2 IPsecOverNatT” whereas when the tunnel is initiated from the ASA the SA is listed as just “IKEv2 IPsec”. I would say this is the biggest indicator of the issue, but I can’t figure out why it would be causing an issue when NAT-T is enabled on the ASA and presumably it’s enabled on the Checkpoint if tunnels initiated from there negotiate with an ipsecovernatt SA. Does anyone have any past experience with a situation similar to this?

​

EDIT:

Believe I’ve finally cracked it, disabling DPD stopped the tunnel tearing itself down so quickly after being initiated but the tunnel still seemed to be stuck and unable to reach the subnets in the remote encrypt domain (lots of UDP:4500 packets discarded in the logs), I’ve just disabled NAT-Traversal for this tunnel on the ASA and boom, I can bring the tunnel up with successful TCP pings.

To be sure the issue is resolved I’ll need the customer to try initiating the tunnel from their side as it may be that the tunnel can only be brought up from their side with the use of NAT-T (potentially some funny PAT/NAT on their side that they didn’t tell me about).

Thanks for the suggestions and input.

​

Edit2: Customer tested and tunnel can be brought up in a working state from both sides now, job done :slight_smile:

​

Cheers, Lie

2

DPD is disabled by disabling keepalives under the tunnel group config.

3

I’ve encountered two scenarios where an ASA-to-non-ASA VPN link was establishing but not passing traffic. In both scenarios the issue was resolved by replacing the ASA with something else… ANYTHING else.

4

Out of curiosity, is this a new setup or issue from an existing setup?

5

Encountered a similar situation a few years back, had to change to IKEv1

6

Read the bit about “DPD Responder Mode” from here

The DPD mechanism is based on IKE SA keys. In some situations, the Check Point Security Gateway deletes IKE SAs, and a VPN peer, usually a 3rd Party gateway, sends DPD requests and does not receive a response. As a result, the VPN peer concludes that the Check Point Security Gateway is down. The VPN peer can then delete the IKE and IPsec keys, which causes encrypted traffic from the Check Point Security Gateway to be dropped by the remote peer.

7

I know that, historically, CPs tend to aggregate their encryption domains and that causes problems with 3rd party S2S. There is a setting in the GUIDBEdit app to change this behavior.

I’ve worked with ASAs for years and they had a really good track record of working well with other vendors. That may have changed, it’s been since 2014 or so, that I worked on them.

8

I’ve been dealing with a very similar, ongoing issue between checkpoint and ASA. Traffic only resumes when resetting vpn from my checkpoint fw. There were lifesize messages that I originally thought was the issue, but the issue persisted after disabling a size limit. We also tried converting to subnet-to-subnet mode to no avail. The only other difference is we’re running ikev1, but I’m very interested if you find the issue.

9

Ah you’re right, wondered why I was still seeing DPD messages in the logs

10

Meh, I really like the ASA for vpns, solid as a rock for that sort of thing IME. Super easy to debug too, I found checkpoint kind of a PITA for that sort of thing

Now you mention “ANYTHING” how about sophos UTM, or sonicwall, both of those are nasty.

11

It was a new setup but on devices with many other VPN’s, all of which had been operating without issue. After disabling NAT-T on the ASA the issue seems to be resolved, though I’m concerned this change will mean the customer can no longer bring up the tunnel from their side seeing as the tunnel would always negotiate with a IPsecOverNatT SA when brought up from their side.

12

I was going to suggest double/triple checking the encdom at both ends seen those not matching cause all sorts of issues

13

Believe I’ve finally cracked it, disabling DPD stopped the tunnel tearing itself down so quickly after being initiated but the tunnel still seemed to be stuck and unable to reach the subnets in the remote encrypt domain (lots of UDP:4500 packets discarded in the logs), I’ve just disabled NAT-Traversal for this tunnel on the ASA and boom, I can bring the tunnel up with successful TCP pings.

To be sure the issue is resolved I’ll need the customer to try initiating the tunnel from their side as it may be that the tunnel can only be brought up from their side with the use of NAT-T (potentially some funny PAT/NAT on their side that they didn’t tell me about).

Edit: Customer tested and tunnel can be brought up in a working state from both sides now, job done :slight_smile:

14

It’s funny you mention that, because both ASAs were replaced with SonicWalls and that was the last time we had any VPN issues with those sites LOL

15

That’s the main reason to get a failed phase 2.

16

Honestly, from a managed services perspective ASA’s are the gold standard - the tools and visibility provided by the GUI are excellent for rapid in-depth troubleshooting and I’ve found that in 95% of cases its the customer’s kit that’s at fault. Fuck Checkpoints and Drayteks.

17

Have to say I’ve been using ASA since they were spelled Pix. The entire OS is bad. IOS is tolerable because the debugs are fairly useful after you learn to read them. Admittedly not easy.

Sonicwall VPN has always been a trainwreck with any other vendor though. I’ve always been able to get ASAs to work with anyone… Except azure. Azure seems to not get along well with older ASAs at least.

18

Fair enough, and to each their own. We are in the process of ripping out a pair of ASA 5555-x today and we are celebrating. As a basic router/firewall the ASA is OK.

But the ASA is easily the worst of all NGFWs. Firepower is a bolt-on, nightmare piece of shit.