Problems connection to Kaspersky EC management console on port 8080
-
Hi to all,
I'm trying from several hours, to connect to the KES management console on port 8080.
I'm using pfsense squid proxy on default port / transparent mode and SSL filtering, no anti-virus.I have already tried to use direct connection but keep receiving errors on SSL management.
Either it fails to connect to page, stating that it is not available (direct mode) or that there is an error on SSL (proxy mode).I'm a bit stuck and tired, and all of this is being done remotely so ...
Any help and hints will be much appreciated.
Regards.
JG -
You are connecting outbound from a client inside pfSense?
If it's only using port 8080 then Squid in transparent mode won't even see that traffic. If not then something may be blocked.
You could whitelist the IP as a test.Steve
-
@stephenw10
Thank you for your reply.
Its oubound yes, yes I agree, something is 'blocking' but I cannot figure it out.
Even in 'direct mode' it doesn't allow the SSL connection to happen.
Tried with Squid disabled too, transparent mode is now disabled, rules to allow 'any' ... still nothing.
I also have Snort and pfblockerNG active, but even with those disabled can't access.Squid log shows this::
19.09.2020 12:26:15 10.10.0.18 NONE/000 error:transaction-end-before-headers - - 19.09.2020 12:26:15 10.10.0.18 NONE/503 s029.cloud.kaspersky.com:8080 - - 19.09.2020 12:26:15 10.10.0.18 NONE/200 s029.cloud.kaspersky.com:8080 - - 19.09.2020 12:26:15 10.10.0.18 NONE/000 error:transaction-end-before-headers - - 19.09.2020 12:26:15 10.10.0.18 NONE/503 s029.cloud.kaspersky.com:8080 - - 19.09.2020 12:26:15 10.10.0.18 NONE/200 s029.cloud.kaspersky.com:8080 - - 19.09.2020 12:26:15 10.10.0.18 NONE/000 error:transaction-end-before-headers - - 19.09.2020 12:26:15 10.10.0.18 NONE/503 s029.cloud.kaspersky.com:8080 - - 19.09.2020 12:26:15 10.10.0.18 NONE/000 error:transaction-end-before-headers - - 19.09.2020 12:26:15 10.10.0.18 NONE/503 s029.cloud.kaspersky.com:8080 - - 19.09.2020 12:26:15 10.10.0.18 NONE/200 s029.cloud.kaspersky.com:8080 - - 19.09.2020 12:26:15 10.10.0.18 NONE/200 s029.cloud.kaspersky.com:8080 - - 19.09.2020 12:26:15 10.10.0.18 NONE/200 cloud.kaspersky.com:443 - - 19.09.2020 12:26:15 10.10.0.18 NONE/200 cloud.kaspersky.com:443 - -SSL interception is on 'strip mode', but the machine has the pfsense cert installed too ...
webpage on proxy mode:
Webpage on direct mode ::
If I do it thru direct mode it only say 'Can't connect' on the web page.
Any ideas?
-
Hmm, I so not expect to see any logs for port 8080 in Squid in transparent mode unless you have set port 8080 there specifically.
But disabling squid will remove the port redirects and traffic will just be passed outbound by the firewall unless you are blocking it.
Do you have Snort running in blocking mode? Did you clear the blocks? Disabling Snort does not clear already blocked IPs.Steve
-
@stephenw10
Thank you Steve.
I forgot to mention that port 8080 was the Squid port before ...
I changed it to the default one.
That logs was not on transparent mode, was on proxy mode.
There is no logs on the direct mode, not yet at least ,
Yes, snort is running in blocking mode, but only for the WAN interface, I have it configured for both WAN and LAN. Also there is no blocks for the KES ips's or internal one.JG
-
First of all, and I should know this already, since I'm a 35+ old IT guy ....
Never try to solve issues TIRED ...
Second, it always good to have another perspective about your problem.
I was so focused on the issue beeing in the proxy level, don't know why. but I was, that I forgot to deep analyse the others, snort and pfblockNG.
Althoug I have tried to disable the before mentioned services I forgot to remove the block !!! from the snort, and I forgot to compare the KES cluster IP agains them ...
It was only when @stephenw10 mentioned it that I tried all the three:- Disable proxy;
- Disable snort;
- Disable pfblockerNG;
- Deleted the blocked IPs on snort;
- Disabled the proxy setting on server;
Tried to access the page, SUCCESS !!
Enabled one-by-one until it fails, Snort did it, blocking the port due to a (http_inspec) rule being triggered.
Again, thank you Stephen for your help.
Cheers and stay sage all.JG
