One-way IPSec tunnel between 4800 cluster and Quantum Spark 1575

[Daniel_Cimpeanu]

Hi,

I'm struggling to get a VPN tunnel properly up and running; one appliance (4800 cluster) is running on R77.30, the second is a Quantum Spark 1575 on R81.10. 

IPSec from Spark appliance towards networks behind the 4800 cluster works, but not the other way around. SIC is established, VPN certificates are renewed. I see both IKE SA and SPI's on the 4800 for the Spark appliance, yet traffic still doesn't go through.

Key install log entry gives me "Informational Exchange Sent Delete IPSEC-SA to Peer:x.x.x.x"

I'm completely out of ideas in regards to troubleshooting. Both being Checkpoint gateways in the same VPN community, i would expect mismatch in IPSec parameters to not be an issue.

Any advice on how to proceed with troubleshooting? 

Thanks,

Daniel

[G_W_Albrecht]

The 4800 appliance is out of support since Jun-2022 and R77.30 since September 2019 - do you still have a valid support contract ?

[Daniel_Cimpeanu]

Hi,

Indeed, support is expired. Issue seems to have been on the routers/switches in front of the Spark Cluster, I'm still not yet up and running with the cluster as expected, currently using a single appliance - but services are good for now.

It seems I have focused too much on finding an issue on the appliances themselves instead of challenging the other network devices that I've been told to be properly configured - lesson learned, assumption is the mother of f*ckups 😕 

[AmirArama · Accepted solution]

if VPN tunnels are UP, (vpn tu/ vpn tu tlist) but traffic is not flow to the other side:

run traffic capture on both sides.

'fw monitor' to see the actual lan to lan traffic on the initiator side. verify that traffic was encrypted through the tunnel ('vpn tu conn - - - - -' ), and if seems ok, check it also on the receiver side.

run: 'tcpdump'/'cppcap' on the esp or nat-t packets (in case nat device in the middle).

make sure esp/nat-t packets are sent out from the initiator side GW from the correct interfaces. then look if those packets received on the receiver side GW, if not, something probably dropped it in the middle. if it received in the other side, check if it isn't blocked by 'fw ctl zdebug + drop' (break with ctrl+C + reset debug with 'fw ctl debug 0')

if for any reason traffic is not encrypted for example on the initiator side, and it's not dropped. run VPN kernel debug / open TAC.

p.s not sure if all those commands was there in R77.30, as it's very old version.

[Daniel_Cimpeanu]

Hi @AmirArama ,

Thanks a lot for the info, I will for sure be using this for similar cases in the future.

/Daniel