CP-to-CP Site-to-Site VPN woes

[klps]

Been trying to figure this out for a couple weeks now and getting nowhere.

Running R81.20 on all devices.

2 5200's in a cluster we'll call FW-HA, FW-MGMT server behind them

A new 6200 at a remote site called FW-DR

Have everything communicating and looking good for policy pushing but can't get the VPN to come up

Key install logs from FW-HA side have IKE showing  Phase1 Received Notification from Peer: invalid certificate

Key install logs from FW-DR side show Main Mode Sent Notification to Peer: invalid certificate

Also have a reject showing in the logs from FW-DR trying to communicate with FW-HA citing a gateway to gateway authentication failure and under IKE "Main Mode Could not retrieve CRL.CN=FW-HA VPN Certificate,O=FW-MGMT"

We have an existing star network VPN to a CP appliance that is working that I've tried adding FW-DR as an additional remote site to with same results, have tried matching all NAT and security rules to be like the functioning VPN with no change.

Unsure of where to go from here. Thanks

To add, I have tried https://support.checkpoint.com/results/sk/sk32648 but oddly I don't see any communication port 18264 whatsoever between any of our gateway's and the management server even for everything that's working as it should. And I can't apply https://support.checkpoint.com/results/sk/sk66381 as I get the error "applying NAT on security gateway control connections is allowed only when the rule is installed on a single gateway", but also our other gateway and it's VPN work fine without this

[Lesley]

Have you checked if the VPN certificate is still valid?

You can see that if you open the FW object in SmartConsole under ipsecVPN and then renew/view

Maybe worth renew it anyway on both members (after renew policy push). 

Try to see the CRL traffic with tcpdump to be 100% sure it is sending yes or no. And if other side get's the traffic.

Sometimes firewall tries to do CRL via VPN tunnel towards management system that will create a looping issue 😉 

tcpdump -nnei any port 18264

[JozkoMrkvicka]

Exactly, there will be some issue with CRL and/or certificates between MGMT and FWs. If FW-HA and FW-DR are managed by the same FW-MGMT, for VPN establishment the certificates and used (not pre-shared keys).

It can also happen that ICA cert on MGMT is expired.

There might be some communication dropped (tcp/18264) between FWs and MGMT which is used for CRL downloads.

[klps]

Got tied up in another project but now am back on this.

Thanks for the info, the tcpdump has given me direction.

It appears it comes down to FW-DR not being able to get the cert from FW-MGMT which sits behind FW-HA.

I can see in the tcpdump that FW-DR is trying to connect to the internal address on FW-MGMT to retrieve the certificate. A NAT rule on FW-DR to translate the internal 10.x.x.x address of FW-MGMT to the external IP doesn't seem to be having any effect. I'm not sure what was done on our other site firewall to get it to communicate on the external IP for certs as our original firewalls were upgraded by our Checkpoint seller

We do have a dummy management object, FW-MGMT-EXT, which has the external IP set on it, but I'm not sure how to get FW-DR to use that object to retrieve its certs

[the_rock]

Can you tell us please how is below configured? On the management object...

Andy

 

[klps]

Sure thing, it's currently set to hide behind gateway.

I'm going to try setting it explicitly to the external IP address now to see if it changes anything

[the_rock]

I have a gut feeling that will help.

Andy

[klps]

Unfortunately not, can still see it trying the internal 10.x.x.x address on port 18264 after a policy push

[the_rock]

What is the error now? Is it still related to certificate?

Andy

[klps]

Same thing, unable to do the key install, "Certificate defaultCert cannot be validated.", "Could not retrieve CRL."

From onsite at FW-DR I can access the ICA_CRL1.crl of FW-MGMT over port 18264 using the external IP, it's just that the FW itself keeps trying to use the internal address it seems.

I have FW-DR in a VPN community by itself for now to figure out this issue so not like it's getting stuck in a VPN loop either

[the_rock]

Are you able to quickly renew vpn cert and install the policy and test again?

Andy

[the_rock]

You can also run below on mgmt to verify certs validity.

Andy

https://community.checkpoint.com/t5/Scripts/Valid-Certificates-Overview-Oneliner/m-p/179954

[klps]

All of our SIC and IKE certs are good, that is a handy command to have though, thanks

I've been renewing the FW-DR cert almost every time I make a troubleshooting change now to force the key install to attempt sooner so definitely not expired.

[the_rock]

I get it, thats fair enough. I will tell you I had situation like yours twice with clients and once they renewed the vpn cert and installed the policy, all worked, though they were NOT expired. Now, Im not saying that would fix it for you, but cant make it worse either.

Andy

[the_rock]

I agree with the points made. If you renew vpn certs and test, may start working. If not, then do simple debug as per below and examine vpnd and ike* files in $FWDIR/log

Andy

vpn debug trunc

vpn debug ikeon

-test traffic

vpn debug ikeoff

[Duane_Toler · Accepted solution]

Go back to sk66381. Check the control connections checkbox. From the drop down, choose the one gateway that sits in front of the management server (unless this is a CloudGuard management server).  Install policy to all gateways.  Should be good to go.

[klps]

I decided to try this again and this time it has worked. I don't know if something else I changed along the way allowed this to work this time or what. But just glad the VPN is coming up now.

[Duane_Toler]

All gateways managed by this management server need to contact it on port 18264 every 24 hours for CRL updates.  Otherwise the VPN dies.  Login to your remote gateway as expert mode and make sure you can Telnet to the management server NAT IP on port 18264:

telnet <public ip> 18264

You need to get a response saying it is connected.  Press Control and ] like the prompt says, then type “quit”. You’re good to go. Keep a close eye on this for the next 24 hours, however.  It will be at the precise 24 hour mark, too; not 1 second late.

Good luck!

[emmap]

Seems like it should be being sent as part of IKE, do you have caching disabled? 

https://support.checkpoint.com/results/sk/sk116340