site to site VPN troubleshooting without monitoring blade

[Bob_Bobson]

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

[PhoneBoy]

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.

[Bob_Bobson]

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?

[Timothy_Hall]

Please see my post here:

https://community.checkpoint.com/message/24527-site-to-site-vpn-between-checkpoint-and-palo-alto-fir... 

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 http://www.maxpowerfirewalls.com

[Bob_Bobson]

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:

        IKE SA <XXXXXXXXXXXXXXXXXXXXXX>
                INBOUND:
                        1. 0xXXXXXX    (i: 1)
                OUTBOUND:
                        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 192.168.0.1 to our local network 10.0.0.1 gives this log in the PaloAlto:

Source 192.168.0.1 Dest 10.0.0.1 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]: 192.168.0.1 -> 10.0.0.1 (ICMP) len=60 id=31312
ICMP: type=8 code=0 echo request id=1 seq=19550
[vs_0][fw_0] eth0:i[60]: 10.0.0.1 -> 192.168.0.1 (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: 192.168.0.1; Dest: 10.0.0.1; 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]: 10.0.0.1 -> 192.168.0.1 (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 192.168.0.1.

CheckPoint fw.log:

Blade: VPN; Action: Encrypt; Source: 10.0.0.1; Dest: 192.168.0.1; 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.

[Bob_Bobson]

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.

[arnaud_jayet]

Hello,

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