SmartConsole fails only for remote VPN administrators after management failover
A customer runs an R81.20 distributed deployment with a Primary Management Server (mgmt-a, 10.10.5.10) and a Secondary Management Server (mgmt-b, 10.10.5.11) in HA. After a planned failover to mgmt-b, administrators in the office VLAN can open SmartConsole normally. Three administrators working from the remote VPN subnet 10.200.8.0/24 receive 'Connection failed: server is not responding'. They can ping 10.10.5.11 and browse to https://10.10.5.11:443. On mgmt-b, cpwd_admin list shows cpm and fwm running, and cpstat mg reports Overall Status OK. Local SmartConsole on mgmt-b works. The VPN access policy permits ICMP and TCP/443 from 10.200.8.0/24 to 10.10.5.11; all other ports are blocked. The remote administrators can also reach the old primary 10.10.5.10 on TCP/19009, but that server is now passive. No SmartConsole build or management certificate changes were made recently.
1. Which management service and TCP port should you verify first, and what evidence would separate a CPMI/port problem from a CPM process problem? Give commands.
Read the worked answer
SmartConsole does not rely only on TCP/443. After the initial web connection, the GUI uses Check Point's CPMI service, normally TCP/19009, to reach cpm. A browser test on 443 therefore proves only that the web front end is reachable. On mgmt-b, confirm the listener with ss -ltnp | grep 19009 (or netstat -anp | grep 19009) and check cpwd_admin list for cpm. Then reproduce from a remote host with Test-NetConnection 10.10.5.11 -Port 19009 or nc -vz 10.10.5.11 19009. On mgmt-b run tcpdump -ni any port 19009 during the attempt. If no SYN arrives, the problem is before cpm: VPN policy, routing, or client-side. If SYN arrives but no SYN-ACK, inspect cpm.elg and cpm status. Because office SmartConsole works and cpm is running, a cpm crash is less likely than a path or port issue.
2. If `ss` shows 19009 listening and tcpdump sees no packets from 10.200.8.x, what is the most likely cause and least-risk remediation?
Read the worked answer
ss shows 19009 listening, so the management process is not the immediate suspect. No SYN from 10.200.8.x means the remote client's packets are not reaching mgmt-b. The VPN policy you described permits only ICMP and TCP/443 to 10.10.5.11; SmartConsole's CPMI connection is therefore blocked even though the browser and ping succeed. Confirm on the VPN gateway with fw monitor -e 'host(10.200.8.0) and host(10.10.5.11) and port(19009);' or the VPN gateway's logs. The lowest-risk fix is a narrow rule allowing TCP/19009 from 10.200.8.0/24 to 10.10.5.11, not an any-any rule. Install the policy, retest with Test-NetConnection and SmartConsole, then confirm the rule's hit count. If the VPN client also needs 443, keep that rule. Do not open 19009 to the Internet.
3. If remote admins still fail while local login works after TCP/19009 is allowed, what management-side authorization would you check and why?
Read the worked answer
With 19009 reachable, check management-side client authorization. R81.20 management can restrict which GUI clients are allowed; cpconfig has a GUI Clients section, and the configured list is stored under $FWDIR/conf/gui-clients. If the remote subnet is not listed, local or office clients may work while VPN clients are rejected. Verify with cpconfig or by inspecting the file, and compare the remote addresses. Also review cpm.elg and fwm.elg at the exact login timestamp for client or certificate errors. If the list is the cause, add the remote subnet or a jump-host address, not the whole Internet. Then retest. If logs show a certificate error instead, validate the management certificate and the SmartConsole trust prompt before changing access controls.