Check Point & Palo Alto IPSEC VPN - proxy ID configuration & Issues

[Mike137843]

I have an existing Check Point only mesh VPN setup amongst numerous sites.

I have a new site that is running Palo Alto VPN.

I want to incorporate this new site running Palo Alto into the existing Check Point mesh VPN.

I have it all configured; IKE is up, IPSEC Tunnel is up & showing green. Traffic initiated from host on Palo Alto end traverses tunnel just fine and works. Traffic initiated from Check Point end does not work. Does not reach Palo Alto side, does not show in packet captures.

I understand that Check Point is policy based, and Palo Alto is route based and as per this Palo Alto KB that it won't work unless Proxy IDs are configured to match Check Point.

Currently, I have NO proxy IDs configured and traffic flows 1-way as mentioned.

Check Point end has encryption domain with many networks in it.

Palo Alto end entire site is behind 10.222.0.0/16.

Interoperable object for the Palo Alto is created on Check Point config and is part of the mesh, 10.222.0.0/16 defined in the topology encryption domain.

What should I be setting the Proxy IDs to on Palo Alto to make this work? Can this even work? Or is this square peg round hole?

If I set any specific proxy IDs on Palo side, this is what I see in the logs on Palo below. The tunnel does go down for about 30 seconds then comes back up and returns to 1-way traffic, with this error repeating endlessly:
Configured proxy-IDs do not match the proxy-IDs in the IPSec proposal. Please ensure that proxy-IDs match in the configuration on both sides. cannot find matching phase-2 tunnel for received proxy ID. received local id: 0.0.0.0/0 type IPv4_subnet protocol 0 port 0, received remote id: 0.0.0.0/0 type IPv4_subnet protocol 0 port 0

 If I go with no proxy IDs at all, I don't get any errors like above, but it's still just 1-way traffic.

[the_rock]

Here is how you fix all that.

Set BOTH enc domains to empty groups for needed vpn community, make sure its set as permanent tunnel, per gateway enabled in tunnel management, and create rule based on what access is needed.

Push policy, test.

[israelfds95]

I see two possibles ways: 

Possible approaches to fix this:

Option 1 – Align Proxy-IDs (policy-based):
Explicitly define Proxy-IDs on the Palo Alto side that match the required networks on the Check Point side (you can summarize if possible).
On Check Point, make sure the correct VPN Domains are defined for the Palo Alto peer and double-check that security rules allow traffic both directions.
Also review NAT: confirm if a bidirectional No-NAT rule is needed or if any existing NAT rule may be interfering.

Option 2 – Go fully route-based:
Create a dedicated VPN community for this the Palo Alto and configure the tunnel as route-based on both sides (Check Point and Palo Alto), relying on routing instead of Proxy-IDs or VPN Domain to control traffic.

[the_rock]

100% true!

[Vincent_Bacher]

Would recommend to perform vpn debug first.

b4 testing: vpn debug trunc 

after: vpn debug truncoff 

Then look at the logs using ikeview
on m end in such cases this was always the first step.

[the_rock]

Yes, totally valid thing to do.

[Alex-]

If you change settings for the Meshed, you change it for all your peers.

We don't use mesh much unless all members are completely managed by the same manager, but generally IPSEC VPN are defined to 3rd parties.

So you could actually create a separate star community with the PAN and you central CP and allow routing through the center so that your central GW can perform VPN routing. This makes sense as it's a deviation to your "All-CP" meshed topology.

This wya, you can modify VPN options without nuking your entire BPN mesh. You can then use "one tunnel per gateway" and so on to use an universal ID (0.0.0.0/0), or as mentioned, go route-based which is also efficient - except that annoying obligation to automatically fetch topology. You can'r create a VTI manually in the topology.

With route-based, you don't deal with encryption domains as it's empty, just routing.

[Vincent_Bacher]

This is the option I would prefer as well, same reasons and I never used mesh.

[Alex-]

The use case of Mesh here is if the locations need to communicate together and are geographically diverse, so the central routing could cause latency.

But I had a similar case where an external DR site had to be connected which didn't work well in the mesh, it was solved by VPN routing and a dedicated community.

[the_rock]

Exactly! I recall even all CP sk articles about this also suggest to create community as star.

[the_rock]

I never ever recall creating vpn community as mesh when setting up cloud providers VPN tunnel in smart console and always worked fine. 

[Mike137843]

Thanks for the responses! So given above comments vs. your initial reply, would you recommend then just creating a separate Star VPN community with the Palo Alto and the subset of Check Point sites that need to connect to it? Would the Palo interoperable be the Central, and the Check Point sites the satellites?

[the_rock]

Yes and no. Star community yes, centre gateway is CP, satellite PAN. Give both empty group vpn domains,but JUST for that specific community. Set tunnel as permenent, per gateway in tunnel mgmt, like below.

The rule itself, set it per subnets that need to communicate.