- CheckMates
- :
- Products
- :
- Quantum
- :
- Security Gateways
- :
- Re: CP-to-CP Site-to-Site VPN woes
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Mute
- Printer Friendly Page
Are you a member of CheckMates?
×- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
CP-to-CP Site-to-Site VPN woes
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
- Labels:
-
Site to Site VPN
Accepted Solutions
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
If you like this post please give a thumbs up(kudo)! 🙂
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
Jozko Mrkvicka
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Can you tell us please how is below configured? On the management object...
Andy
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I have a gut feeling that will help.
Andy
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Unfortunately not, can still see it trying the internal 10.x.x.x address on port 18264 after a policy push
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
What is the error now? Is it still related to certificate?
Andy
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Are you able to quickly renew vpn cert and install the policy and test again?
Andy
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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!
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Seems like it should be being sent as part of IKE, do you have caching disabled?