- CheckMates
- :
- Products
- :
- Quantum
- :
- Management
- :
- Re: Failed to connect to the peer
- 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
Failed to connect to the peer
Hi guys, I'm asking here because it was suggested in the forums.
We recently inherited a Checkpoint infra and we just realized that, in the Management High Availability, the Secondary server is not reachable.
I've tried some workarounds found in the forums to no avail so far:
-cpstop in primary and secondary, delete contents of %fwdir%\conf\mgha, cpstart
-copy (possibly corrupted) $FWDIR/conf/refs.c file from primary
-Install Database on Secondary
There is no NAT as suggested in some SK articles (both servers are in the same vlan)
Platform is Windows, R77.20
Any help is welcome.
Kind regards,
Alberto
- Tags:
- high availability
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
What do you mean by "its not reachable?" By the management client? If so and you can ssh to it perform a cpwd_admin list and see if the processes are terminated. It may be easiest and quickest to just re-image the box and re-sync.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Paul,
here is the output of cpwd_admin list:
APP PID STAT #START START_TIME MON COMMAND
CPD 3176 E 1 [19:35:48] 2/11/2017 Y cpd
FWD 3736 E 1 [19:35:55] 2/11/2017 N fwd -n
FWM 0 T 0 [08:44:43] 6/11/2017 N fwm
STPR 3824 E 1 [19:35:55] 2/11/2017 N status_proxy
DBSYNC 4084 E 1 [19:35:58] 2/11/2017 N dbsync
SVR 3888 E 1 [19:36:00] 2/11/2017 N SVRServer.exe
LC_10.94.59.227 3044 E 1 [19:36:03] 2/11/2017 N log_consolidator.exe -R -s 10.94.59.227
CPSEMD 0 T 0 [09:44:55] 6/11/2017 N cpsemd
CPSEAD 3228 E 1 [19:36:03] 2/11/2017 N cpsead
CPWMD 4288 E 1 [19:36:05] 2/11/2017 N cpwmd -D -app SmartPortal
CPHTTPD 4336 E 1 [19:36:05] 2/11/2017 N cp_http_server -f 'C:\Program Files\CheckPoint\R77\SmartPortal\R77\SmartPortal\conf\cp_httpd_admin.conf'
CP3DLOGD 4432 E 1 [19:36:06] 2/11/2017 N cp3dlogd
Answering your question, the Secondary management server and the Primary are having issues to see each other (please take a look at the screenshot)
Regarding the strategy to rebuild the box; if it comes to that, I guess we'll have to do it. I just want to try to fix this, if possible, in a less agressive way.
Thank you,
Alberto
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
The upgrade is non-aggressive and definitely the best path forward. IMHO. GaIA is definitely worth looking into as well. It eliminates all of the Windows problems...
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I recommend upgrading to R77.30 (or R80.10) with the latest Jumbo Hotfix first, because R77.20 is not supported anymore.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Danny, thank you for your answer.
Does the upgrade to R77.30 involve any change in the agents at all? We cannot affor that just now.
Kind regards,
Alberto
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
In your output to me your FWM process is terminating. The best bet is really to upgrade to 77.30 because if you had to call support for your problem right now its not supported. Why its terminating though IMHO is not worth worrying about because likely a fresh install of 77.30 will fix your problem. 77.20>>>77.30 is an easy upgrade. 77.30 should work with all of your earlier FW releases unless your firewalls are super old.
FWM 0 T 0 [08:44:43] 6/11/2017 N fwm <--- shows FWM terminated
Looking at the 77.30 release notes these GWs are still able to be managed from 77.30
NGX R65 R70, R70.1, R70.20, R70.30, R70.40, R70.50 R71, R71.10, R71.20, R71.30, R71.40, R71.50 R75, R75.10, R75.20, R75.30, R75.40, R75.45, R75.40VS, R75.46, R75.47, R76, R77, R77.10, R77.20, R77.30.
However, I would recommend you consult 77.30 release notes and validate for yourself.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I'm not sure what you mean by agent, but we're not talking about upgrade the gateways here, which might involve upgrading more components.
As others have mentioned, R77.20 is End of Life and no longer supported.
It's strongly encouraged that you upgrade your gateways and management to supported versions.
R77.30 is the last release where it is supported to run Security Management on Windows.
From R80 onward, Windows is no longer a supported OS for Security Management.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Since it is a secondary management server that is already not working, you can simply rebuild the Windows server. Reinstall the R77.20 as a secondary management server specifying new SIC activation key in the process.
Bring the HFAs to the same exact level as primary.
Reinitialize SIC on the secondary management object in the SmartDashboard.
Perform manual synchronization from "Policy/Management High Availability".
If successful, test the fail-over process.
This being said, I agree with Danny Jung: you are probably better off taking this opportunity to migrate to R77.30, preferably running on Gaia.
More headache in the short run, but definitely a better strategy.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thank you for your Answer Vladimir.
Looks like a good idea to start with. However, for the second part, we'd rather not touch this infra if possible. And Gaia is definetively not in the map 🙂
Kind regards,
Alberto
