Site to Site VPN between Checkpoint and Palo Alto Firewalls

[Anu_Cherian]

Hi All,

We have a requirement to setup Site-to-Site vpn between our Checkpoint FW and customer Palo Alto FW. I have created one, but the issue is IKE phase 2 fails. I have confirmed the negotiation parameters with my customer engineer and it looks like everything is in order. What could be the possible issue?

I used VPN tu and SmartView  monitor to view but to no success. Any advices will be highly appreciated

Thank you so much

[Vincent_Bacher]

Hi,
i would debug the vpn using

• "vpn debug trunc"
• delete the SAs using "vpn tu"
• replicate the issue
• "vpn debug truncoff"
• analyze $FWDIR/log/ike.elg using ikeview.exe or iketool on cli

Or just removing proxy ID config on palo alto side and using "one tunnel per gateway pair" on checkpoint side to use proxy id 0.0.0.0/0.0.0.0  0.0.0.0/0.0.0.0 on both sides.

Cheers
Vincent

[Anu_Cherian]

It looks like Palo Alto side they have a proxy ID configured. Do we need to create a proxy at Checkpoint Side? 

[Vincent_Bacher]

Proxy ID is defined by configuring VPN topology in the gateway object and setting in tunnel management config.

Default is (i think) one tunnel per subnet pair.
So you have to look at the network objects defined in the VPN topology.

[Anu_Cherian]

Ok. So I have one tunnel per subnet selected at Checkpoint side. The cusotmer engineer told me that he have a proxy ID PID.23 configured at PaloAlto side.

[Yuri_Slobodyany]

IF Phase 2 fails chances are encryption domains as seen by firewalls differ, if not using VTI interfaces with dynamic routing to announce encryption domains, it is usually a bad idea to set 0.0.0.0 as encryption domain - I'd advise to set encryption domains to specific nets and in a mirror like fashion.

Pay attention that by default Checkpoint has supernetting enabled for encryption domain networks, i.e. if you set 10.1.1.0/24 , 10.1.2.0/24 etc as encryption domain , the Checkpoint will announce these nets as one network of 10.1.0.0/23 .

On the CP cli look for encryption domain via fw tab -f -t vpn_enc_domain 

[Anu_Cherian · Accepted solution]

Thank you Yuri

I ran the command fw tab -f -t vpn_enc_domain  and I can see the domain as 10.0.0.0. how can I specify the subnet I need.

[Vincent_Bacher]

If you'd use "smaller" Network objects and the Gateway performs supernetting, you may disable supernetting only for 3rd party VPN devices as per sk101219 (New VPN features in R77.20) and have look if that succeeds.
As you mention, you have 10.0.0.0/8 defined in VPN topology, you may have to modify user.def file, adding a subnet_for_range_and_peer config. It's explained in sk108600, Scenario 1. Location of user.def in the sms is described in sk98239.

I am sure that (as always) there is a much better solution but i learned that long time ago and it's got just a matter of habit.

[Timothy_Hall]

Palo Alto firewalls employ route-based VPNs, and will propose (and expect) a universal tunnel (0.0.0.0/0) in Phase 2 by default; however the Palo can be configured to mimic a domain-based setup by configuring manual Proxy-IDs.   When attempting an interoperable VPN between a Check Point and a Palo Alto you have basically two options:

1) In your VPN Community settings on the Check Point end under "VPN Tunnel Sharing" set "One tunnel per gateway pair".  This will cause the Check Point to propose a universal tunnel in Phase 2, yet still use the VPN Domains for tunnel and peer determination.  In this case there should not be any manual Proxy-IDs specified on the Palo side.  On the Palo side typically static routes are used to route traffic bound for the Check Point side into the VPN tunnel interface leading to the peer.

2) Set explicit Proxy-IDs for the tunnel on the Palo side to mimic a domain-based setup, but then the Check Point subnet proposals in Phase 2 must EXACTLY match how the Proxy-IDs are defined on the Palo side.  Just like on Juniper (strange coincidence there!), a Phase 2 proposal by the Check Point that is a subset of the manual Proxy-IDs will NOT be accepted by the Palo.  So for example if the Palo is manually set for 192.168.1.0/24 as a Proxy-ID and the Check Point proposes a subset of 192.168.1.0/25 it will fail, whereas a Cisco or Check Point would accept that subset proposal.  The only way to reliably ensure that the Check Point will always propose an exact match for the Palo are the user.def modifications specified in Scenario 1 here: sk108600: VPN Site-to-Site with 3rd party.  Per-community VPN domains are on the product roadmap for Check Point and will really come in handy for scenarios like these...

Either way, make sure that a new VPN tunnel can be successfully initiated in both directions by either peer.

--
Second Edition of my "Max Power" Firewall Book
Now Available at http://www.maxpowerfirewalls.com

[Anu_Cherian]

Hi Timothy,

Thank you. During troubleshooting we found the below error at Palo Alto side,

IKE phase-2 negotiation failed when processing proxy ID. 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 type IPv4_subnet protocol 0 port 0

I did follow sk108600 and Scenario 1.

Still the issue has not resolved. Do I have to follow any specific steps?

Thank you

[Timothy_Hall]

Are you sure there are no manual Proxy-IDs configured on the Network > IPSec Tunnels > Proxy IDs tab for the corresponding IPSec tunnel on the Palo side?   The list should be blank.

If that still doesn't work, try defining a manual IPSec Proxy-ID on the Palo like this: Local IP: 0.0.0.0/0, Remote: 0.0.0.0/0, Protocol: Number 0.  I seem to have a vague memory that the Palo doesn't like the Check Point asking for Protocol 0 with no manual Proxy-IDs set.

What happens when the Palo tries to initiate the tunnel?  Your error message indicates the Check Point is trying to start the tunnel.

--
Second Edition of my "Max Power" Firewall Book
Now Available at http://www.maxpowerfirewalls.com

[Anu_Cherian]

They do have an IP set in proxy id .. for eg. 10.0.0.0/8 as local and 192.168.1.0/24 as remote. 

[Timothy_Hall]

Please read my August 3rd response again, if they have manual Proxy-IDs set on the Palo side you need to do scenario 2 on the Check Point.

--
Second Edition of my "Max Power" Firewall Book
Now Available at http://www.maxpowerfirewalls.com

[Worapong_Janloy]

Hi Timothy Hall

To specific proxy-id in checkpoint I need to configure in user.def.x. but I not sure when I configure the user.def.x it work on tunnel base only or not? and I have to create blank network group on encrypt domain or not?

[Timothy_Hall]

In the user.def file you call out the specific peer and then what subnets/Proxy-IDs you want to propose only with that peer.  The Check Point will propose whatever you hardcode in user.def and ignore the VPN domains, at least as far as crafting the Phase 2 proposal.  However in a domain-based VPN the VPN domains are used to determine interesting traffic so they can't be left blank.  The only time you would use blank VPN domains is when using a route-based VPN on the Check Point side involving VPN Tunnel Interfaces (VTIs) and (usually) static routes to direct interesting traffic into the VPN tunnel.  Route-based VPNs are not common on Check Point firewalls due to the longstanding incompatibility between CoreXL and route-based VPNs which was finally resolved in R80.10 gateway.

--
Second Edition of my "Max Power" Firewall Book
Now Available at http://www.maxpowerfirewalls.com

[Worapong_Janloy]

For the route-based VPN Can I define proxy id in user.defl?

[Timothy_Hall]

I suppose you could do that, but it would probably be best to set "one tunnel per pair of gateways" in the VPN Community settings instead, so that the gateway proposes a universal tunnel (0.0.0.0/0) in Phase 2 which is appropriate for a route-based VPN.

--
Second Edition of my "Max Power" Firewall Book
Now Available at http://www.maxpowerfirewalls.com

[Mike_Jensen]

I have been tasked with building a site to site IPSEC VPN between a Check Point R80.10 appliance and a Palo Alto for the first time.

The encryption domain on the Check Point has many networks in it that need to be reachable from the Palo Alto side.

If I am understanding correctly I can set the "One tunnel per gateway pair" on the Check Point and then add static routes to the Palo Alto to identify the remote networks without the need for any proxy id's?

[Timothy_Hall · Accepted solution]

If you use a route-based VPN on the check point side, yes you will want a universal tunnel.  Palo Alto does route-based VPNs by default.

If you still want to do domain-based VPN on the Check Point side, you must explicitly configure all the subnets behind the Check Point in the Palo Alto configuration which will cause the Palo to mimic a domain-based VPN.

Please read my reply earlier in this thread where I laid out these two options in detail, you will need to pick one or the other.

[Mike_Jensen]

Hi Tim,

I am attempting to use your option # 1.  I was able to get the tunnel to show all green on the Palo side even though no production traffic would pass through it.  I have a static route on the Palo pointed at the remote private network with the next hop being the tunnel interface.  When I had no proxy ID's configured on the Palo I kept getting "ike-nego-p2-proxy-id-bad" "IKE phase-2 negotiation failed when processing proxy ID. cannot find matching phase-2 tunnel for received proxy ID. received local ID 10.30.30.0/24 type IPv_4_subnet protocol 0 port 0, received remote id: 10.10.10.0/24 type IPv4_subnet protocol 0 port 0.

Seeing that I added a proxy ID with the local side as the local private net 10.30.30.0/24 and the remote 10.10.10.0/24 and the tunnel went completely down.

I then deleted the proxy ID an the Palo, committed the changes and on the Palo side receive IKE_protocol notification message received: NO-PROPOSAL_CHOSEN".

The Check Point log states "Quick Mode Sent Notification: no proposal chosen"

Do you are anyone else have any ideas on how I can make these VPN function?

[Timothy_Hall]

Try removing all manually defined proxy-IDs on the Palo side and on the Check Point set the VPN Tunnel Sharing setting to "one tunnel per pair of gateways".

[Mike_Jensen]

Thank you Tim. I already had "one tunnel per pair of gateways" selected.
What I did was change the encryption and hashing for IKE phase 2 on both the CP and PA side and with a proxy ID in the PA the tunnel came up and passed traffic successfully.
I will test removing the proxy ID and see what happens. My production Check Point has a lot of sub networks in it's encryption domain so it will be nice if I don't have to enter proxy id's on the PA for all of them.

[Mike_Jensen]

Hi Tim,

As mentioned below I was able to get my test VPN operational with a proxy ID entered on the Palo Alto side.  In my lab I only had one inside network behind the firewalls at each site.

In production where I have to do this my Check Point side has a encryption domain defined with approximately 50+ networks and hosts.  The Palo Alto side only needs to talk to a select few of these networks and hosts.  In order for the VPN to be successful will I need to enter a proxy ID on the Palo Alto side for every single entry in the Check Point encryption domain?

I don't know if the Check Point will try to advertise every single network and host it has in it's encryption domain during phase 2 and if it will fail when the Palo Alto and Check Point don't match exactly.  

[Johannes_Schoen]

Hi Timothy,

in this scenario: How do you find out, which proxy IDs the Check Point will propagate by default?
(when I do not want to use a user.def change)

Regards
Johannes

[Timothy_Hall]

It depends on the VPN Tunnel Sharing setting.  If it is "pair of hosts" the Check Point will propose /32's for both source and destination.  If it is "pair of gateways" the Check Point will propose 0.0.0.0/0's also known as a universal tunnel.

If the setting is "pair of subnets" the answer is much more complicated and depends on your code version and whether the remote gateway is an Externally-Managed Gateway or Interoperable Device.  If you can get to R80.40 on your SMS, you can specify exactly what subnets you want to propose in the properties of the VPN Community itself.  The gateways need not be running R80.40 to take advantage of this, and there have been anecdotal reports that this works even as far back as R80.10 on gateways.  But the SMS must be at least R80.40. 

That is what I would recommend rather than trying to speculate what the Check Point will propose, as a future unrelated change to your own gateway's VPN domain can suddenly and unexpectedly change what is proposed, which can cause total mayhem with multiple existing VPNs.  

[Johannes_Schoen]

Many thanks for that response - that will help in some scenarios.

I never understood, why the VPN part is such a voodoo with Check Point - is there a document, which describes the "more complicated" version how the phase-2 and how to view the results on CLI?

[Timothy_Hall]

Sort of, how the pair of subnets setting behaves is related to the hidden ike_enable_supernet variable.  References:

sk115455: "Invalid ID information" log in SmartView Tracker when Security Gateway initiates Quick Mo...

sk104760: ATRG: VPN Core

[Yuri_Slobodyany]

And for completeness sake (and what I usually do) - starting with R77.20 we have the option of Disabling supernetting of encryption domain networks altogether - (as always before editing database save Database Revision, just in case) - then in GuiDBedit set ike_enable_supernet  property in the firewall_properties of the Global properties table to False (default is True). No need to reboot or anything, just install policy. 

[Anu_Cherian]

Hi Yuri,

I check the ike_enable_supernet property using GuiDBedit tool  and it was already set to false. I also followed Tim's advice but  I am still not able to successfully initiate the tunnel. The negotiation fails in phase -2. 

As per the scenario, we have two VPN(primary and backup) sites which need to be in VPN community. 

Checkpoint side have a subnet of /24

Other side have a subnet  of /8 for both gateways

They want us to NAT /32 subnet (each peer GW have a /32 NAT IP), to establish the Site to Site VPN. 

I have already followed Scenario 1 in VPN Site-to-Site with 3rd party 

subnet_for_range_and_peer = { <peerGW_IP, first_IP_in_range1, last_IP_in_the_range1; subnet_mask>, <peerGW_IP, first_IP_in_range2, last_IP_in_the_range2; subnet_mask>, ... ... ... <peerGW_IP, first_IP_in_rangeN, last_IP_in_the_rangeN; subnet_mask> };

As per the Palo Alto side they have declared the proxy id as 

Local : 10.0.0.0/8

peer : 10.10.10.10/32 (replaced for security and compliance reasons)

but during IKE phase 2 Checkpoint negotiates using my public_ip/32 subnet.It should negotiate with 10.10.10.10/32.

What could be the issue? I have worked through all the solutions posted in the checkmates community and still not able to resolve.

FYI, I am using a Checkpoint 3200 with R80.10

[_Val_]

Check Point VPN GW is using int Main address by default to negotiate IPsec VPN tunnel, unless something else is configured in Link Selection.

If you are trying to use one of the internal IP addresses, VPN is likely to fail. Why are you using 10.10.10.10? This is not the IP address used to reach your GW from outside, is it?