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

site to site VPN troubleshooting without monitoring blade

Checkpoint 80.10 has several VPN are up and working fine.

There is a problem a VPN to a paloalto firewall. The VPN is up but can't send or receive traffic. There is no monitor blade licence so troubleshooting options are limited.

1. "vpn tu" command shows tunnels are up.

2. fw.log shows icmp traffic from local to peer going out (description "Encrypted in community")

3. fw.log shows icmp traffic from peer to local coming in (description "Decrypted in community")

Yet the peer firewall team say nothing is hitting their side over the tunnel and neither side gets a ping reply.

100% confirmed all the usual phase 1, phase 2, IKE v1, main mode, preshared key, firewall rules, encryption domains etc.

No problem with VPNs to any other firewall (Cisco ASA, Sonicwall, Watchguard). 

0 Kudos
6 Replies

As you are initiating traffic towards the remote network, do you see packets going to to/from the VPN peer (encrypted ones) with tcpdump?

I would assume so if it's showing tunnels up.

You need to have someone on the Palo end debugging to get a clear picture of what's happening.

I would also use something other than ICMP to test.

0 Kudos

tcpdump confirms traffic flowing okay.

PaloAlto team say they see nothing on their end

Can we see more troubleshooting details like tunnel rx/tx counters without the monitoring blade?

0 Kudos
Champion Champion

Please see my post here: 

Which of the two techniques detailed in this post are you using to establish the VPN to the Palo Alto?  I'd use fw monitor instead of tcpdump in this case so you can see the traffic hitting the various capture points and whether it is actually being encrypted/decrypted.

Second Edition of my "Max Power" Firewall Book
Now Available at

Gateway Performance Optimization R81.20 Course
now available at
0 Kudos

We are using the second method with specific proxy ID's (we also have One tunnel per gateway pair set).

Per-community VPN domains would be ideal rather than the way CheckPoint does one global section for VPN domains but it seems to be fine and we can see the PaloAlto proxy-id subnets match and the tunnel comes up:

Tunnel negotiation Log from PaloAlto (no logs available from Checkpoint as no Monitoring blade licence):

IKE phase-1 negotiation is started as initiator, main mode. Initiated SA: <public IP of peer PA>[500]-<public IP of local CP>[500] cookie:XXXXXXXXXXXXX:0000000000000000.

IKE phase-1 negotiation is succeeded as initiator, main mode. Established SA: <public IP of peer PA>[500]-<public IP of local CP>[500] cookie:XXXXXXXXXXXXXXXXXXX lifetime 86400 Sec.

IKE phase-2 negotiation is succeeded as initiator, quick mode. Established SA: <public IP of peer PA>[500]-<public IP of local CP>[500] message id:0xXXXXXXXX, SPI:0xXXXXXXXXXXXX.' )

IPSec key installed. Installed SA: <public IP of peer PA>[500]-<public IP of local CP>[500] SPI:0xXXXXXXXXXXXXXX lifetime 3600 Sec lifesize unlimited.

CheckPoint "vpn tu" option 2 also shows tunnel up:

Peer  <public IP of peer PA> , VPN-TO-PALOALTO SAs:

                        1. 0xXXXXXX    (i: 1)
                        1. 0xXXXXXX   (i: 1)

Looks good and the tunnel is up according to both PaloAlto and CP

Send a ping down it from the peer side to our local network gives this log in the PaloAlto:

Source Dest Interface: Tunnel.10 Bytes Sent: 74; packets 1; Action: Allow; Session Ended, Reason: Aged-out

-PaloAlto is sending it but not getting a reply.

CheckPoint fw monitor shows:

[vs_0][fw_0] eth0:O[60]: -> (ICMP) len=60 id=31312
ICMP: type=8 code=0 echo request id=1 seq=19550
[vs_0][fw_0] eth0:i[60]: -> (ICMP) len=60 id=8733
ICMP: type=0 code=0 echo reply id=1 seq=19550

-We can see the peer packet coming in and the local packet replying. But the reply is not getting back to the PaloAlto

and the CheckPoint fw.log shows:

Blade: VPN; Action: Decrypt; Source:; Dest:; Service: echo-request; Description: Decrypted in community VPN-TO-PALOALTO

-fw.log also shows the the peer packet coming in and decrypting. 

Next try ping the other direction from our local to the peer:

PaloAlto log:

-Nothing showing up.

CheckPoint fw monitor:

[vs_0][fw_0] eth8:O[60]: -> (ICMP) len=60 id=9077
ICMP: type=8 code=0 echo request id=1 seq=62856

-That's it, no echo reply coming back from

CheckPoint fw.log:

Blade: VPN; Action: Encrypt; Source:; Dest:; Service: echo-request; Description: Encrypted in community VPN-TO-PALOALTO

-Checkpoint is sending the packet to the tunnel but PaloAlto not receiving it.

Tunnel is up and the PaloAlto peer is sending packets across fine. The local CP is sending across but PaloAlto not receiving.

0 Kudos

This is fixed. The problem was the setting "IP Selection by remote peer - Main address".

Changing to "IP Selection by remote peer  to - IP based on topology" fixed the VPN to paloalto.

All other firewall VPNs dropped after this change but running the command "vpn tu" and option 0 to delete them forced them all to come back up fine.



I have exactly the same trouble with our CheckPoint (15600 appliance in R80.10) and a Palo Alto remote peer : the IPSEC tunnel seems OK (phase 1 and 2) but no traffic inside the VPN tunnel, in the 2 ways.

When you say changing "link selection" option from "main address"  to "ip network based topology" fixed the trouble :   is it the link selection for your checkpoint GW (global property of the CP gateway) or the  for the remote Palo (interoperable device) peer in the VPN community you have defined beetween the Checkpoint and the Palo Alto ?

Do you've declared a specific topology or leave it to blank for the Palo Alto object ? 

Thank you for your reply

0 Kudos


Epsum factorial non deposit quid pro quo hic escorol.

Upcoming Events

    CheckMates Events