Understanding a kernel vpn debug

[ibrown]

Good morning all.

I've got a repeating vpn issue between my R81.20 cluster and a 3rd party cisco gateway. It fails to re-negotiate on the phase 2 timeout without me resetting the vpn at the CP end.
I've checked with the the 3rd party and the ikev2 vpn settings all match, but it still fails.

I've taken a kernel debug with the instructions here https://support.checkpoint.com/results/sk/sk180488 but I'm not totally sure how to interpret the debug output, anyone got any pointers to help read through it to isolate the issue ?

Thank you

Ian

[the_rock]

My good colleague and I came up with it ourselves while back after hours of troubleshooting with TAC and Azure folks, we were thinking "lets just set both enc domains as empty groups for the community, enable permanent tunnels and per gateway option" and worked great after policy install. We just stuck doing the same for everyone now...why spend hours on end troubleshooting, when you can make it work in few minutes : - )

[Vincent_Bacher]

Our VPN gateways are managed by someone else, but it's good to know.

[the_rock]

You know, not to sound funny or ironic now, but when I was in my 20s, I could troubleshoot things for hours on end and still be fine...now in my 40s, I do NOT want to do that, UNLESS there is very good reason for it lol

[Vincent_Bacher]

I feel the same way, and I have the luxury of simply leaving it to my CP PS colleague to deal with.

[the_rock]

I dont have that luxury...well, sometimes lol

[ibrown]

Sigh, I tried empty group, restricted group, per gateway, per pair of hosts and all come back with 'traffic selector unacceptable' in the fresh trace. I guess I am going to have to do a debug with the third party to get to the bottom of this.

Thanks to everyone for the help !!

[the_rock]

Are you allowed to do quick remote? Im free for another 50 minutes...if so, message me directly, can send you zoom link. Its free accouint good for 40 mins, since teams has so many restrictions.

[ibrown]

wow, that is a fantastic generous offer. My security team would break my fingers though !

really appreciated

[the_rock]

K, we dont want that lol. Anywho, mind send screenshot of all the tabs in vpn community? Just blur out sensitive details.

[ibrown]

here is the encryption 
color: "black"
encryption-method: "ikev2 only"
encryption-suite: "custom"
ike-phase-1:
encryption-algorithm: "aes-256"
diffie-hellman-group: "group-20"
ike-p1-rekey-time: 1440
data-integrity: "sha512"
ike-phase-2:
encryption-algorithm: "aes-gcm-256"
ike-p2-use-pfs: true
ike-p2-pfs-dh-grp: "group-20"
ike-p2-rekey-time: 28800
data-integrity: "sha512"

[the_rock]

What I would do is set tunnel mgmt to per gateway and then at generic (1st tab) in community, edit both objects and assign vpn domain as EMPTY group, or whatever you want to call it, just make sure to add one if it does not exist. You can call it null vpn group, empty vpn domain (makes no difference) and make sure you do NOT add anything to it.

Save, install policy, test.

[the_rock]

@ibrown 

Will send you screenshot shortly of what Im referring to.

[the_rock]

@ibrown 

here you go

  

[JozkoMrkvicka]

From the screenshot provided, domain-based VPN is used here. Converting it to route-based VPN would cause much more headache and not desired setup/design.

And since we are talking about Check Point <> Cisco setup, setting VPN Tunnel Sharing to Gateway pair is not good idea. Per Gateway pair should be used only between Check Point <> Check Point VPN. If any other vendor is on the other end, subnet pair should be selected.

One more point I just remember from couple of VPN cases I worked on. If 3rd party vendor is involved within S2S VPN:

1. If you choose VPN per subnet pair, then encryption domains configured on both ends are supposed to be network objects ONLY (not ranges, not hosts, only network objects). No mix of ranges, hosts and networks. Only network objects.

2. If you choose VPN per host pair, then encryption domains configured on both ends are supposed to be host objects ONLY (not ranges, not network objects, only host objects). No mix of ranges, hosts and networks in encryption domain. Only host objects.

[the_rock]

Hi @JozkoMrkvicka 

I would have to slightly disagree with part of that statement, specially route based tunnel part. I had set up MANY route based tunnels between CP and other vendors (cloud ones as well) and we ALWAYS use per gateway setting, even if its just hosts communicating, never had an issue.

[ibrown]

Thanks. I can try that.

3rd party has confirmed their enc domain is single host, so the fact that mine drops when I set it to that and works when it's much broader is a source of confusion to me !

[the_rock]

If you allow remote, happy to check it further.

[ibrown]

Hmm, when I reduce my enc domain, I start seeing a different traffic selector, one just covering the gateway external ip itself, which implies the objects hide nat for general internet traffic is getting priority somehow above my manual nat for the vpn. Some more digging needed

[JozkoMrkvicka]

Check Point is using seconds for Phase 2 timers. In your case it is set to 28800 SECONDS, which is 480 minutes, which is 8 hours. Make sure that Phase 2 on Cisco is using the same timer for Phase 2 (28800 seconds or 480 minutes or 8 hours).

My guess would be that you see *narrow* or *eclipsed* in "vpn tu tlist" output for Cisco peer. That means encryption domain on Check Point is not matching exactly the same traffic selectors (TS) on Cisco. It has to be 1:1 on both ends (for local and also for remote peer).

For more info see IKEv2 Site to Site VPN instability when the VPN tunnel is narrowed.

[the_rock]

I just want to say something. I always see lots of people get confused or are not clear about those enc domain/phase1 and 2 settings and what vpn rule should look like. Here is what I gather from all the testing I had done over the years and lately with the cloud providers and route based tunnels. I always find that with route based tunnels, having both enc domains as empty group is totally fine, regardless of whether there are hosts or subnets involved and you set tunnel mgmt per gateway.

Then, goes without saying, you set up rule according to what needs to communicate.

Now, when it comes to domain based tunnels, tunnel mgmt does matter way more, so above philosophy for vpn community settings may not work,so enc domains and tunnel management needs to be 100% right.

Just my 2 cents, based on my own experience.

[ibrown]

Hello Jozko, vpn tu tlist doesn't show anything except the two hosts in the enc domain. And the 3rd party has confirmed that is how they are configured too. And the timers are the same, I made a point of making sure he knew it was minutes and seconds. Thank you

[CaseyB]

You would need both the NAT address and the original address in the encryption domain.

[the_rock]

100% agree, thats definitely needed.

[WiliRGasparetto]

Hi ibrown,
I usually run into IKEv2 interoperability issues with third-party vendors as well. In many cases, switching to IKEv1 resolves the problem. I know IKEv1 isn’t the preferred option, but in practice it tends to work reliably with vendors like Cisco and FortiGate.