Create a Post
cancel
Showing results for 
Search instead for 
Did you mean: 
Highlighted
Contributor

Site to Site VPN between Checkpoint and Palo Alto Firewalls

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

Tags (1)
36 Replies
Highlighted

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

and now to something completely different
Highlighted
Contributor

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

Highlighted

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.

and now to something completely different
Highlighted
Contributor

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.

0 Kudos
Highlighted
Collaborator

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 

Highlighted
Contributor

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.

0 Kudos
Highlighted

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.

and now to something completely different
Highlighted
Champion
Champion

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

R80.40 addendum for book "Max Power 2020" now available
for free download at http://www.maxpowerfirewalls.com
Highlighted
Contributor

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

0 Kudos
Highlighted
Champion
Champion

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

R80.40 addendum for book "Max Power 2020" now available
for free download at http://www.maxpowerfirewalls.com
Highlighted
Contributor

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. 

0 Kudos
Highlighted
Champion
Champion

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

R80.40 addendum for book "Max Power 2020" now available
for free download at http://www.maxpowerfirewalls.com
0 Kudos
Highlighted
Contributor

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?

Highlighted
Champion
Champion

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

R80.40 addendum for book "Max Power 2020" now available
for free download at http://www.maxpowerfirewalls.com
Highlighted
Contributor

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

0 Kudos
Highlighted
Champion
Champion

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

R80.40 addendum for book "Max Power 2020" now available
for free download at http://www.maxpowerfirewalls.com
0 Kudos
Highlighted
Collaborator

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?

0 Kudos
Highlighted
Champion
Champion

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.

 

R80.40 addendum for book "Max Power 2020" now available
for free download at http://www.maxpowerfirewalls.com
0 Kudos
Highlighted
Collaborator

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?

 

 

0 Kudos
Highlighted
Champion
Champion

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".

R80.40 addendum for book "Max Power 2020" now available
for free download at http://www.maxpowerfirewalls.com
0 Kudos
Highlighted
Collaborator

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.
Highlighted
Collaborator

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.  

0 Kudos
Highlighted
Collaborator

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. 

Highlighted
Contributor

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

0 Kudos
Admin
Admin

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?

0 Kudos
Highlighted
Contributor

We are not using 10.10.10.10 internally nor it is used externally. Our extenal IP ,for example : 192.168.1.2.

The 10.10.10.10/32 is the IP configured at customer site and they need us to use that IP, as it is set as an encryption domain( at Palo Alto side they have configured the remote IP in Proxy ID side as 10.10.10.10/32). So during IKE phase 2 the subnet will fail if I use my subnet ie, 172.31.1.0/24.

The error is ,

": IKE phase-2 negotiation failed when processing proxy ID. cannot find matching phase-2 tunnel for received proxy ID. received local id: 11.0.0.0/8 type IPv4_subnet protocol 0 port 0, received remote id: 192.168.1.2/32 type IPv4_address protocol 0 port 0. "

Let us say for the Primary GW(customer side) : the remote IP is 10.10.10.10/32 and for the secondary GW(cust side) : the remote IP is 10.10.11.10/32

May be they choose these IPs to segregrate the network as for both the Gateways, the domain is 11.0.0.0/8

What will be the best way to accomodate the requirement. 

0 Kudos
Highlighted
Admin
Admin

Pardon me, still not clear enough. Proxy ID is the IP address of the remote GW. PAN has to use your main IP address for the tunnel to work. Now, that 10.10.10.10, does it belong to one of your GW interfaces?

0 Kudos
Highlighted
Contributor

No. I have no interface with that IP. Customer have their Palo Alto like that.

as per their proxy ID settings,

Proxy ID             Local             Remote               Protocol

PID.10               11.0.0.0/8      10.10.10.10/32      any

0 Kudos
Highlighted
Admin
Admin

Ask them to change remote proxy ID IP to your address. There no way you can build a VPN with a dummy IP

0 Kudos