SIC problem after upgrade to R81.20

[Olusegun_Adekun]

Hi All,

Am having issue with a 3000 series Firewall Upgraded from R81.10 to R81.20. The SIC between the Management Server and the Gateway is not establishing.

With cpconfig, option 5, am able to reset the SIC on the Gateway, however on the Smart Console, it failed with error: Failed to connect to Gateway.

All routing on the Gateway checked all interfaces on with IP addresses.

From the upgraded Gateway, am able to ping the Active Cluster member.

From the upgraded Gateway, am able to ping the Management Server.

But am not able to ping the upgraded Gateway from the Active cluster member and also from the Management Server.

There is something blocking access to the Upgraded Firewall.

Anybody have any idea please as I have run out idea. Even ask TAC, they also ran out of idea.

 TAC advises to restore back to R81.10 which am not really happy to do. I have upgraded other firewalls to R81.20 without any issue but this particular one is becoming a nightmare.

Please help.

Thank you all always.

Regards,

Olu

[the_rock]

Try this...when you reset SIC on the gw, run fw stat and see what it shows? If it shows initial policy, which most likely it will, run fw unloadlocal and then try establish SIC on the mgmt server.

Andy

[Olusegun_Adekun]

Hi The rock,

I have tried it already , even tried with TAC.

Didnt work unfortunately 

Regards

olu

[the_rock]

K, so lets take a step back here...IF you say routing is correct and same as other fw (I will take your word for it, as I got no proof to the contrary), and you do fw unloadlocal and sic still fails, there has to be something blocking the connection. Can you make sure if you run netstat -np that sic port is showing there as listening?

Andy

[emmap]

I would also suggest that you run a tcpdump on the gateway to see if the SIC connection from the management server is even arriving. It will help narrow down where to troubleshoot.

Generally speaking I would always recommend troubleshooting the network layer before resetting SIC if you have a SIC error like that. There's no point resetting SIC if the layer 1/2/3/4 stuff isn't working.

[the_rock]

100%, I agree. Its always better to do so.

Andy

[CheckPointerXL]

Is the main IP of the gw in the same net of mgmt server? If not, is the main ip configured on the first interface hitted by packets from mgmt server?

[Olusegun_Adekun]

Thanks all for your advice. I will check the connectivity again.

Much Appreciated.

[the_rock]

100% thats your issue, SIC has to work as long as connectvity with mgmt server is there.

Andy

[the_rock]

I was thinking about this and remembered ages ago, when I was on the phone with a customer troubleshooting this exact issue on R65 running splat (good times lol) and every time client would try reset sic, it would fail, even unloading the policy and after about 30 mins, we confirmed that there was indeed proper route missing.

Can you double check 100% that route is indeed there? From the fw, say if mtmt ip was 10.10.10.10, simply run ip r g 10.10.10.10 from expert mode and check that it is right.

Best,

Andy

[Olusegun_Adekun · Accepted solution]

Hi Andy, 

You are very right; it was routing issue but very difficult to spot because customer was using ISP redundancy. Traffic from management to Firewall was coming in through one ISP interface and going back through the second ISP which is then been dropped. So, I configured a static route telling the FW to use same ISP interface gateway for return traffic to Management.

SIC was established.

Thanks to everyone that has contributed. Much Appreciated.

[the_rock]

Glad we can help mate, its always a team effort.

Happy its solved now.

Best,

Andy