CP 3950 - lost Gaia access after installaition of the migrated policy

[Exonix]

Hello everyone,

I connected our on-premises Management Server (managing a CP1900) to Cloud-1 (managing a CP3950 with IP 192.168.111.51), then successfully migrated all policies and objects.

After a small cleanup and adjusting the policies for the new 3950 firewall, and after installing these policies, I lost web access to Gaia.

Port 443 is open, the gateway is responding, but nothing opens in the browser. What could be the reason for this?

Meanwhile, SSH is working fine. In firewall logs I see HTTPS was successful. 

17:29:32.503910 ethertype IPv4, IP 192.168.111.40.53391 > 192.168.111.51.443: Flags [SEW], seq 1769120811, win 64240, options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0
17:29:32.503910 ethertype IPv4, IP 192.168.111.40.53390 > 192.168.111.51.443: Flags [SEW], seq 1785169404, win 64240, options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0
17:29:32.503912 IP 192.168.111.40.53391 > 192.168.111.51.443: Flags [SEW], seq 1769120811, win 64240, options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0
17:29:32.503913 IP 192.168.111.40.53390 > 192.168.111.51.443: Flags [SEW], seq 1785169404, win 64240, options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0
17:29:32.504922 ethertype IPv4, IP 192.168.111.51.443 > 192.168.111.40.53391: Flags [S.], seq 3979140708, ack 1769120812, win 32768, options [mss 1460,nop,nop,sackOK,nop,wscale 5], length 0
17:29:32.504923 ethertype IPv4, IP 192.168.111.51.443 > 192.168.111.40.53390: Flags [S.], seq 2784020504, ack 1785169405, win 32768, options [mss 1460,nop,nop,sackOK,nop,wscale 5], length 0
17:29:32.504924 IP 192.168.111.51.443 > 192.168.111.40.53391: Flags [S.], seq 3979140708, ack 1769120812, win 32768, options [mss 1460,nop,nop,sackOK,nop,wscale 5], length 0
17:29:32.504924 IP 192.168.111.51.443 > 192.168.111.40.53390: Flags [S.], seq 2784020504, ack 1785169405, win 32768, options [mss 1460,nop,nop,sackOK,nop,wscale 5], length 0
17:29:32.504926 ethertype IPv4, IP 192.168.111.40.53391 > 192.168.111.51.443: Flags [.], ack 1, win 8212, length 0
17:29:32.504926 ethertype IPv4, IP 192.168.111.40.53390 > 192.168.111.51.443: Flags [.], ack 1, win 8212, length 0
17:29:32.504928 IP 192.168.111.40.53391 > 192.168.111.51.443: Flags [.], ack 1, win 8212, length 0
17:29:32.504928 IP 192.168.111.40.53390 > 192.168.111.51.443: Flags [.], ack 1, win 8212, length 0
17:29:32.504929 ethertype IPv4, IP 192.168.111.40.53391 > 192.168.111.51.443: Flags [.], seq 1:1461, ack 1, win 8212, length 1460
17:29:32.504930 IP 192.168.111.40.53391 > 192.168.111.51.443: Flags [.], seq 1:1461, ack 1, win 8212, length 1460
17:29:32.504931 ethertype IPv4, IP 192.168.111.40.53391 > 192.168.111.51.443: Flags [P.], seq 1461:1766, ack 1, win 8212, length 305
17:29:32.504932 IP 192.168.111.40.53391 > 192.168.111.51.443: Flags [P.], seq 1461:1766, ack 1, win 8212, length 305
17:29:32.504936 ethertype IPv4, IP 192.168.111.40.53390 > 192.168.111.51.443: Flags [.], seq 1:1461, ack 1, win 8212, length 1460
17:29:32.504936 IP 192.168.111.40.53390 > 192.168.111.51.443: Flags [.], seq 1:1461, ack 1, win 8212, length 1460
17:29:32.504937 ethertype IPv4, IP 192.168.111.40.53390 > 192.168.111.51.443: Flags [P.], seq 1461:1702, ack 1, win 8212, length 241
17:29:32.504938 IP 192.168.111.40.53390 > 192.168.111.51.443: Flags [P.], seq 1461:1702, ack 1, win 8212, length 241
17:29:32.505938 ethertype IPv4, IP 192.168.111.51.443 > 192.168.111.40.53391: Flags [.], ack 1766, win 1049, length 0
17:29:32.505940 IP 192.168.111.51.443 > 192.168.111.40.53391: Flags [.], ack 1766, win 1049, length 0
17:29:32.505940 ethertype IPv4, IP 192.168.111.51.443 > 192.168.111.40.53391: Flags [F.], seq 1, ack 1766, win 1049, length 0
17:29:32.505941 IP 192.168.111.51.443 > 192.168.111.40.53391: Flags [F.], seq 1, ack 1766, win 1049, length 0
17:29:32.505941 ethertype IPv4, IP 192.168.111.40.53391 > 192.168.111.51.443: Flags [.], ack 2, win 8212, length 0
17:29:32.505942 IP 192.168.111.40.53391 > 192.168.111.51.443: Flags [.], ack 2, win 8212, length 0
17:29:32.505943 ethertype IPv4, IP 192.168.111.40.53391 > 192.168.111.51.443: Flags [F.], seq 1766, ack 2, win 8212, length 0
17:29:32.505943 IP 192.168.111.40.53391 > 192.168.111.51.443: Flags [F.], seq 1766, ack 2, win 8212, length 0
17:29:32.505946 ethertype IPv4, IP 192.168.111.40.53393 > 192.168.111.51.443: Flags [SEW], seq 2326915469, win 64240, options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0
17:29:32.505946 IP 192.168.111.40.53393 > 192.168.111.51.443: Flags [SEW], seq 2326915469, win 64240, options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0
17:29:32.505955 ethertype IPv4, IP 192.168.111.51.443 > 192.168.111.40.53390: Flags [.], ack 1702, win 1049, length 0
17:29:32.505956 IP 192.168.111.51.443 > 192.168.111.40.53390: Flags [.], ack 1702, win 1049, length 0
17:29:32.505957 ethertype IPv4, IP 192.168.111.51.443 > 192.168.111.40.53390: Flags [F.], seq 1, ack 1702, win 1049, length 0
17:29:32.505957 IP 192.168.111.51.443 > 192.168.111.40.53390: Flags [F.], seq 1, ack 1702, win 1049, length 0
17:29:32.505959 ethertype IPv4, IP 192.168.111.40.53390 > 192.168.111.51.443: Flags [.], ack 2, win 8212, length 0
17:29:32.505959 IP 192.168.111.40.53390 > 192.168.111.51.443: Flags [.], ack 2, win 8212, length 0

[the_rock]

Hey @Exonix 

Mind check few things for us?

First, is the issue same for any browser you try?

What is the output of fw stat command?

Can you check the output of show web ssl-port and show web daemon-enable in clish?

If all above is good, did you try change web portal to another port in smart console fw object?

Also, any relevant logs when this fails?

[Exonix]

Hi @the_rock ,
the issue exists in any browser.
No I didn't try to change any Ports, where can I do this in Smart Console? This is a cluster object

fw stat
HOST      POLICY           DATE
localhost company_2026       7Jan2026 18:08:00 :  [>eth3.2] [<eth3.2] [>eth11.111] [>eth11.11] [<eth11.11] [>eth4.7]

show web ssl-port
web-ssl-port 443

show web daemon-enable
WebDaemonEnable on

[Lesley]

platform portal and gaia config port has to match. check this

1. In SmartConsole:

   1. Open the Security Gateway / Cluster object.
      
      
   2. Go to Platform Portal.

   3. In Main URL, set a new port for the Gaia Portal server (for example, port 4434):

      https://IP_ADDRESS:PORT
   4. Add a firewall rule to allow traffic on the new port.
      
      
   5. Click on OK to apply the changes.
      
      
   6. Install the security policy on this Security Gateway / Cluster object.

2. In Clish:

   1. Connect to the Security Gateway command line (for clusters, connect to each member).
      
      
   2. Log in to Clish.

   3. Set the new port for the Gaia Portal server (for example, port 4434):

      HostName> set web ssl-port <Port_Number>

[the_rock]

All good points, though based on the description of the post, seems that should be correct. But, still worth confirming, for sure.

[Exonix]

Hello @Lesley 
I was thinking about this, but I got a warning and canceled it. Shall I continue?

In the cluster object, I have a public IP assigned to the cluster. Therefore, I can’t change it, because a new IP and port would not affect each node — they can’t share the same IP. And there is no "Platform Porlat" for each member...

[Exonix]

I checked the settings of another working cluster — it has a cluster IP address, and since my new cluster is connected via public addresses, the Platform Portal is also configured with a public IP, but even that is not working anymore…

[RickLin]

In the meantime, you can also SSH into the 3950 appliance and execute the following debug command:

fw ctl zdebug + drop | grep 192.168.111.51

While the command is running, attempt to access the Gaia Web Portal via your browser again. Checking for any output from this command will help identify the root cause of the access issue.

[the_rock]

Absolutely great way to test.

[Exonix]

Hi @RickLin 

I used this command already (I know about the great way to test 😉 ) - there were no drops

[Lesley · Accepted solution]

Maybe check out here, the edit and if there is the correct port

[Exonix]

This is a complete configuration:

[Exonix]

It looks like changing the port to 4434 has helped. I’m checking this now. At least it worked from the local network

[the_rock]

Glad you were able to sort it out!

[Exonix]

@Lesley  thanks a lot! 

Interesting why the port changed, even though port 443 was still configured in the Smart console… 

Now I can continue with the configuration; the next step is ISP redundancy 🙂

[saitoh]

Hi @Exonix ,

I personally do not experience GAiA Portal unavailability when trying CP3950, maybe because web port changed to 4434.

As this problem emerges after policy installation, I am a bit curious whether fw unloadlocal will let you open GAiA Portal or not.

Is the cluster mode Active/Standby?

If so, would you mind if I ask you to make it failover to see if the problem persists or not when other cluster member is active?

Just out of curiosity, one of my 3950 cluster accepts L2TP, the other does not.

Saitoh

[Exonix]

Hi @saitoh 

yes, my cluster is in Active/Standby, but each node was available via Gaia, like all other clusters. Now, none of the nodes are available. Right now, I suspect that there is an issue either with the certificate, with SSL in general, or that something else might be listening on port 443.

[saitoh]

Judging from tcpdump you provided, since the gateway sent FIN, I echo your opinion, and would start investigating cert issue.

Does apache error_log says anything suspicious?

ADDED: Glad you found root cause!

Saitoh