Hallo all out there,
I really hope, that anyone on this great world can help me - respectively my organisation.
Did anyone of you tried to open the URL above? And did you have no problems to open this site with all of the included objects without any problems?
So - we have problems ... until about 3 weeks ago!
But then -suddenly and without any omen- we get some problems, which are not very easy to explain. We will open a ticket with our support-level, but perhaps some of you gets a good idea.
Now, here it goes:
Our normal Proxy-sytem is a cluster containing two appliances(debian) which are called over one adress. All clients are connected through a proxy.pac-file.
"github.com" can only be opened correctly with Firefox, or the latest version of InternetExplorer. In the further text I only will talk about Firefox FrontMotion or the normal FireFox Browser in its latest version.
As a subject to compare the behavior or for testing new rules or settings we have an exact clone of those appliances running as a VMWare. The only difference is the web cache, which does not exist on the WebGateway-VM, and of course, the "ground-system"- VMWare is installed on a windows platform. All other settings, rules and configuration is exactly the same as on the originals.
So far the basics, now the specials:
The normal way open the site "https://github.com" with FireFox should look like this:
, but using our proxy-systems over the proxy.pac-file it looks that way:
With this result I nearly tried everything on the system - beginning with the rule sets, settings and even in the configuaration. Global Whitelisting was equally useless as tunneling all certificates, which you get with a trace or logging the session.
Next step was our test-system - as I told this is the exact clone of the real systems >> and there everything works and looks like it has to look, without any change in the rules or something like that.
Next step was an entry in the proxy.pac-file, that " *github* " should connect directly without the proxy-systems >> of course this works fine!
Next step was an entry in the proxy.pac-file, that all requests, which has anything to do with " *github* " will redirect on the test-system >> and it works fine.
Next step was the same entry, but now "hard" on one of the clustered appliances >> fail
Now my thought was, that the only difference is the web-cache (as I told above). So I deactivated it on the real system, tried again without any entry in the proxy.pac-file >> and failed.
And now I am at the end of my ideas. The state now is, that this one and only URL got an entry in the proxy.pac-file with a redirect on the test-system, so at least all filters are active. But this cannot be the final solution, because it is only a test-system.
And that is the reason, why I beg your help and your ideas. We cannot imagine, that our organisation here in Germany is the onliest place in the universe, which got this problem.
...and already yet a big ThankYou for your answers!
because of really heavy restrictions in our organisation it is at this point not possible for me to install this real important tool. I know, this is ridiculous, but this is our city council.
I try to get the permission - otherwise I hope you got plan B !?
But please remember: There are absolut identical webgateways and there is such a difference in presentation a CSS or Java ???
Greetings from WuppertalNachricht geändert durch michael-s-w on 21.08.13 03:45:11 CDT
it is hard to guess, I currently think that it may be a problem with categorization/false positive or similar of an embedded URL...
It does not sound reasonable because you have two MWGs and it works on one and fails on the other one, but there are also some evidences that I could be right:
- The problem started "overnight" without (most likely) any changes to the rules
- The problem does not occur when you exclude some hosts from proxy.pac
- Even if all rules are identical there could be a setting or a version difference between test/production system causing the trouble
- It just looks like the typical CSS (blocked embedded object) problem :-)
github loads CSS files from here:
Look what happens to my Github when I block access to that URL:
Looks close to yours :-)
If there is no firebug, what happens when you browse to
Do you see CSS content? Or maybe a block page?
You could also review the access.logs and see if (from your IP) any non 200 status codes are reported when browsing to github.
Finally it could also be a connection problem, such as Production MWG can't talk to the server mentioned above, while the test server can... But browsing that URL should reveal it, if there is a problem connecting.
you are my hero!
I really did not know exactly what happened, but it seems, that the hint "github.global.ssl.fastly.net" was the point, where I could repair the problem.
Yes, the only difference between the mwg´s is, that one is a real appliance and the other is a VM, where a web-cache is not possible.
The URL you send, where I should have a look to see the CSS content, there I could only reach a site with very much text. So I could reach it, but not in the correct way.
Then I took all changes I made in the last days back, put your hint "github.global.ssl.fastly.net" in the section for Tunnel Certificates with the action "stop Rule Set" together with the other certificate-sites. I even delete all the entries in the proxy.pac-file in context with github.com. And at last I deleted the entry where github.com was whitelisted for web-cache and >>>>>>>>>>>> tadaaa, it works without any problems.
I swear, that this combination we had already and it works not! I do not know what happens. But here we think that the webmasters are working already at their site. We will see, what the next days will bring - we hope, that there will be no changes in the future.
And, by the way, now I will get my normal FireFox where I can install FireBug.
But I think, the most helpful thing was that you gave me the hint with this one site, which I could not see.
Thank you very much for your help.
Much greetings from Wuppertal
even if I am still not sure what exactly may have caused the problem it is good that you were abel to solve it :-) Firebug will be very helpful for you in the future, I think that I solve at least half of my MWG issues with that tool :-)
We should see if the page now works as expected or starts causing trouble again... hopefully it works :-)
Best regards from Paderborn,