Strange Behaviour after upgrade to 1.1.4
Strange Behaviour after upgrade to 1.1.4
Hello,
We have the following situation:
1. We are using windows AD integration. We open a browser, the browser ask for user and password, the user and password are accepted.
2. After that you put any URL in the browser, the browser does shot anything but waiting for site http://www.xxxxxxxx.com.
3. After 2 minutes the site start loading.
In the monitoring facility of cache guard (port:8091) we can observe at the same time the following:
After 2 you see:
Client IP Auth User Date Request Status Bytes Cache Peer
x.x.x.x - d.m.y connect xxxxx 407 2067 DENIED
This is strange because you are already authenticated (from machine x.x.x.x, but users still shows as "-") and also the status 407 is strange.
Then after 2 minutes. (Point 3) it starts to load.
and you start to see the authenticated user and status 200 in the log.
We have already spent 12+ hours with diagnostic of connectivity, DNS , different PCs, different browsers, different OSs, etc.
Our conclusion so far is that it should be CacheGuard. Any Ideas ?
ADDENDUM:
We turned off URL guarding, and the symptom is gone, you don't have to wait 2 minutes, it start to load the pages straight away and from the initial second you see status 200 in the log.
We turn on URL guarding back on; the problem is back.
We have only one simply policy to block porn for everybody. And we have only loaded that category.
Thanks,
Miguel
We have the following situation:
1. We are using windows AD integration. We open a browser, the browser ask for user and password, the user and password are accepted.
2. After that you put any URL in the browser, the browser does shot anything but waiting for site http://www.xxxxxxxx.com.
3. After 2 minutes the site start loading.
In the monitoring facility of cache guard (port:8091) we can observe at the same time the following:
After 2 you see:
Client IP Auth User Date Request Status Bytes Cache Peer
x.x.x.x - d.m.y connect xxxxx 407 2067 DENIED
This is strange because you are already authenticated (from machine x.x.x.x, but users still shows as "-") and also the status 407 is strange.
Then after 2 minutes. (Point 3) it starts to load.
and you start to see the authenticated user and status 200 in the log.
We have already spent 12+ hours with diagnostic of connectivity, DNS , different PCs, different browsers, different OSs, etc.
Our conclusion so far is that it should be CacheGuard. Any Ideas ?
ADDENDUM:
We turned off URL guarding, and the symptom is gone, you don't have to wait 2 minutes, it start to load the pages straight away and from the initial second you see status 200 in the log.
We turn on URL guarding back on; the problem is back.
We have only one simply policy to block porn for everybody. And we have only loaded that category.
Thanks,
Miguel
Last edited by miguelp on 29 Oct 2015 20:27, edited 1 time in total.
Re: Strange Behaviour after upgrade to 1.1.4
Hello
Could you please give me your initial version (the version you first installed)?
Best Regards,
Could you please give me your initial version (the version you first installed)?
Best Regards,
Re: Strange Behaviour after upgrade to 1.1.4
Hello David,
It was 1.1.2.
Thanks,
Miguel
PD.: Please see my comment update above that if we turn URL guarding off the symptom is gone.
It was 1.1.2.
Thanks,
Miguel
PD.: Please see my comment update above that if we turn URL guarding off the symptom is gone.
Re: Strange Behaviour after upgrade to 1.1.4
Dear Miguel
Thanks for the complementary information. Actually there was a bug in the 1.1.2 making the guarding policy inconsistent when one of its guard filters has been deleted. I assume that you are encountering this bug which is now fixed but depending on your configuration the problem may persist (see http://www.cacheguard.net/doc/guide/changelogs.html).
Could you please send me the output of the following commands:
Thanks in advance.
Thanks for the complementary information. Actually there was a bug in the 1.1.2 making the guarding policy inconsistent when one of its guard filters has been deleted. I assume that you are encountering this bug which is now fixed but depending on your configuration the problem may persist (see http://www.cacheguard.net/doc/guide/changelogs.html).
Could you please send me the output of the following commands:
Code: Select all
guard filter
guard policy
guard rule
Re: Strange Behaviour after upgrade to 1.1.4
Hello David,
This are the outputs:
guard filter ip <null>
guard filter time <null>
guard filter ldap GR_INET_BLOQ_WAREZ:
groupDN: DC=mydomain,DC=me
loginAttribute: sAMAccountName
ldapFilter: memberOf=CN=GR_INET_BLOQ_WAREZ,CN=Users,DC=mydomain,DC=me
-----
guard policy Warez: ldap GR_INET_BLOQ_WAREZ
----
guard rule default deny: Porno
Warez deny: Warez
Cheers,
Miguel
This are the outputs:
guard filter ip <null>
guard filter time <null>
guard filter ldap GR_INET_BLOQ_WAREZ:
groupDN: DC=mydomain,DC=me
loginAttribute: sAMAccountName
ldapFilter: memberOf=CN=GR_INET_BLOQ_WAREZ,CN=Users,DC=mydomain,DC=me
-----
guard policy Warez: ldap GR_INET_BLOQ_WAREZ
----
guard rule default deny: Porno
Warez deny: Warez
Cheers,
Miguel
Re: Strange Behaviour after upgrade to 1.1.4
Hello Miguel
It is possible that due the bug I was talking about makes that your guard policy set contain hidden filters. That's why it may require to be cleaned. To do so please try the following:
Please let me know if it would resolve the issue.
Also FYI we reproduced your configuration in our lab but didn't encounter the issue you are encountering (we installed the v1.1.2 and configured the appliance with guards similar to yours. We then upgraded it to 1.1.3 and then to 1.1.4).
The symptom you described seems to be due to a problem that avoids the proxy to be started properly. The health checking system continuously tries to restart the proxy but without success. Did you reduce the RAM of your machine? Did you change any hardware configuration on your machine. Are you using a VM or a hardware machine?
Best Regards,
It is possible that due the bug I was talking about makes that your guard policy set contain hidden filters. That's why it may require to be cleaned. To do so please try the following:
Code: Select all
guard policy raz
guard rule raz
guard policy add Warez ldap GR_INET_BLOQ_WAREZ
guard rule add Warez deny Warez
guard rule add default deny Porn
mode guard on
apply
Also FYI we reproduced your configuration in our lab but didn't encounter the issue you are encountering (we installed the v1.1.2 and configured the appliance with guards similar to yours. We then upgraded it to 1.1.3 and then to 1.1.4).
The symptom you described seems to be due to a problem that avoids the proxy to be started properly. The health checking system continuously tries to restart the proxy but without success. Did you reduce the RAM of your machine? Did you change any hardware configuration on your machine. Are you using a VM or a hardware machine?
Best Regards,
Re: Strange Behaviour after upgrade to 1.1.4
Hello David,
Problem came back after I issued the commands.
We are using a VM , no changes to configuration was done.
Br,
Miguel
Problem came back after I issued the commands.
We are using a VM , no changes to configuration was done.
Br,
Miguel
Re: Strange Behaviour after upgrade to 1.1.4
Hello
Could you please save and post your complete configuration?
As all operations you can either use the CLI: conf save ...
or
the GUI at [GENERAL] / [Whole Configuration] / [Load Save Configuration].
Thanks in advance.
Best Regards,
Could you please save and post your complete configuration?
As all operations you can either use the CLI: conf save ...
or
the GUI at [GENERAL] / [Whole Configuration] / [Load Save Configuration].
Thanks in advance.
Best Regards,
Re: Strange Behaviour after upgrade to 1.1.4
Hello David,
The file is attached.
Cheers,
Miguel
The file is attached.
Cheers,
Miguel
Re: Strange Behaviour after upgrade to 1.1.4
Dear Miguel
We tested your configuration with a fresh v1.1.4 installation of CG and we didn't encounter issues you described. I can't understand yet what's going on with your installation. Maybe something went wrong during the upgrade... We are still investigating.
It is also possible that your guard category contents were be corrupted. To make sure please rebuild all your guard category contents form our ftp server using the Web administration GUI (menu item "Reload Page[SECURITY] / [URL Guarding] / [Load Category Contents]").
If you are blocked I suggest you to rebuild your CG from scratch (install CG, load your configuration file, load guard categories).
Also I noticed in your configuration that your guard categories are not automatically updated. Please use the following command to keep your blacklists up to date:
You can also configure that with the Web administration GUI (menu item "[SECURITY] / [URL Guarding] / [Auto Load Contents]").
Unfortunately because you don't have a support contract I can't help you more actively.
Best Regards
PS: For security reasons I deleted the configuration file you posted here.
We tested your configuration with a fresh v1.1.4 installation of CG and we didn't encounter issues you described. I can't understand yet what's going on with your installation. Maybe something went wrong during the upgrade... We are still investigating.
It is also possible that your guard category contents were be corrupted. To make sure please rebuild all your guard category contents form our ftp server using the Web administration GUI (menu item "Reload Page[SECURITY] / [URL Guarding] / [Load Category Contents]").
If you are blocked I suggest you to rebuild your CG from scratch (install CG, load your configuration file, load guard categories).
Also I noticed in your configuration that your guard categories are not automatically updated. Please use the following command to keep your blacklists up to date:
Code: Select all
guard category auto Porno on vload update daily ftp ftp.cacheguard.net Porn
guard category auto Warez on vload update daily ftp ftp.cacheguard.net Warez
apply
Unfortunately because you don't have a support contract I can't help you more actively.
Best Regards
PS: For security reasons I deleted the configuration file you posted here.