- CheckMates
- :
- Products
- :
- Quantum
- :
- Management
- :
- Re: Policy installation in SmartDashboard fails wi...
- 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
Policy installation in SmartDashboard fails with: Reason: TCP connectivity failure ( port = 18191 )( IP = X.X.X.X )[ error no. 10 ] Policy installation canceled.
Dear Sir/Madam,
I tried to install my first policy on a virtual firewall and got this error message. "TCP connectivity failure ( port = 18191 )( IP = X.X.X.X )[ error no. 10 ] Policy installation canceled."
Please assist with what I could do.
Kind regards,
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
What version of code are we talking about?
This SK looks like the most relevant: Policy installation fails with "TCP connectivity failure ( port = 18191 )" error due to crash of CPD...
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I upgraded the code and it was fixed, thanks so much everyone.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
You might need to debug cpd on the gw and fwm on the mgmt server in addition to that run traffic captures to see waht is happening to the traffic on port 18191 and make sure the firewall not dropping the traffic from it's mgmt server.
Thanks
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
The real solution in my case to this problem was: re-initialized, re-created SIC and re-established communication the 2nd time. Problem went away. No upgrade, no patch, no hotfix was required!
The same policy installation was successful.
The line below was in-accurate when policy installation failed.
Br-FW2> fw ctl zdebug drop
::::::::::::::............
;[cpu_0];[fw4_1];fw_log_drop_ex: Packet proto=6 10.0.0.113:44749 -> 10.0.0.112:18191 dropped by fw_send_log_drop Reason: Rule base drop - on layer "FW2-Rule1 Network" rule 4
------------------
However, what said about SIC at SmartDashboard was correct.
Also, SIC message below at the FW was helpful.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Glad it is working for you now. As mentioned already, SIC seemed to be reset on GW side
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
A picture for future reference. I'm having the same issue on the 2nd FW (at the remote office but is managed by the Mgr from local office behind another CP GWY). I don't understand how code upgrade had fix the problem because both local and remote GWYs are installed using the same iso (version).
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Now, with more details, can the expert tell me what is missing? Two GWYs running the same SW version but only remote FW2 fails policy installation.
Here's the local GWY (HQ-FW1 - 172.16.0.111 is internal mgmt interface)
HQ-FW1 has 10.0.0.111 at its external interface
HQ-Mgr is 172.16.0.25 which has static NAT to 10.0.0.113 installed on HQ-FW1 (HQ-Mgr is internal of HQ-FW1)
Br-FW2 has 10.0.0.112 at its external interface
I'm using HQ-Mgr to manage both HQ-FW1 and Br-FW2
below is the remote GWY that fails policy installation. (10.0.0.112 is external mgmt interface for Br-FW2)
Two GWYs running the same SW version but only FW2 fails policy installation with reason "TCP connectivity failure ( port = 18191 )( IP = X.X.X.X )[ error no. 10 ]
.... and ...
Br-FW2> fw ctl zdebug drop
::::::::::::::............
;[cpu_0];[fw4_1];fw_log_drop_ex: Packet proto=6 10.0.0.113:44749 -> 10.0.0.112:18191 dropped by fw_send_log_drop Reason: Ru lebase drop - on layer "FW2-Rule1 Network" rule 4;
----------
HQ-FW1 is 10.0.0.111
HQ-Mgr is 172.16.0.25 which has static NAT to 10.0.0.113 installed on HQ-FW1
Br-FW2 is 10.0.0.112
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
ok, I have some investigation to do but if someone knows, please share your knowledge...
I got this from the trouble FW (Br-FW2)
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Did you try to reset SIC for this GW? It seems it is already reset on the GW side.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Yes, SIC was re-set & re-initialized (trust was re-established between Mgr-GWY) once on this GWY before.
However, when policy installation fails I got this SIC error. Is it possible that SIC is broken by policy installation from Mgr?
I wonder if this will go in a cycle or loop. I'll try again soon.
The GWY appears to get the policy but the process is incomplete.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- SIC was re-initialized, re-created and trust was re-established the 2nd time. Problem went away. No upgrade, no patch, no hotfix was required!
The same policy installation was successful.
Notes: the rules have not changed.
Some how earlier policy installations broke the SIC between this GWY and Mgr.
So, can I conclude the line below was in-accurate?
Br-FW2> fw ctl zdebug drop
::::::::::::::............
;[cpu_0];[fw4_1];fw_log_drop_ex: Packet proto=6 10.0.0.113:44749 -> 10.0.0.112:18191 dropped by fw_send_log_drop Reason: Rule base drop - on layer "FW2-Rule1 Network" rule 4
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello Matthew,
How did you resolve this issue.??I am having the same issue ,my fw box is standalone,it acts as firewall and mgmt server under the same box.
your help would be highly appreciated
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hey this can be anti-spoofing. I had the same issue the other day. Had to add the SC subnet to the anti-spoof group for my firewall.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
