08-15-2011 11:55 AM
Hello, I'm curious as to why a website would be blocked despite it being whitelisted.
From the trace policy I get:
Custom URL Category: HR Allowed
Policy Match
IronPort Data Security policy: None
Decryption policy: None
Routing policy: Global Routing Policy
Identity policy: Authenticated_Users
Access policy: HR
Final Result
Request blocked
Details: ERR_INTERNAL
Trace session complete
This site is put in the whitelist in HR Allowed. The user name followed under access policy HR, which is tied to HR Allowed. The policy HR also has the finance category set to monitor.. not block. The URL in question is being tagged as "finance".
But you see the request is blocked because the details are: ERR_INTERNAL.
So I tried this site on my iphone through AT&T. Got a cannot connect to server error. Well if it's a bad URL or difficulty why would the IronPort display a blocked message?
08-19-2011 05:54 AM
We ran into the same issue when we first install our web proxy. What we did was create a new identity called "allowed" which allows the websites in your white list to completely bypass your iron port solution. Similar to the way you can setup a static IP address that bypasses the web proxy.
Hope this helps.
Josh
09-22-2011 09:28 AM
Ah so your putting whitelisted websites under it's own identity that bypasses authentication then?
See we are using active directory groups to determine different levels of access. Like HR and Marketing have more access than regular people, and front line staff have even less access.
The only issue with using active directory is that you need to use IE to pass NTLM credentials through the transparent proxy at least once an hour, or all other internet based applications will fail to connect. I've tried scripted wget and things like that to 'touch' a website, but wget does not pass NTLM.
My biggest confusion is that our IronPort is joined to our domain and we used the Administrator account to do the join. So why doesn't it see the domain and see who's signed in and where? I worked at a job that used Websense and that worked flawlessly.
I hope that Cisco updates the IronPort to be more aware of who's signed in and where, and also provided better logging in the GUI.
I'd like to thank edadios for the link to accessing the logs. That method provides much more information than the GUI.
08-23-2011 12:00 AM
I suggest you instead pass the traffic to the Ironport, while you are collecting access logs as documented here.
The logs you will get may have further information on what is the actual result for the traffic.
You can paste here, and we can check further. Please just clearly indicate the url you are trying to go to.
09-22-2011 09:19 AM
I have this exact same problem. The site is http://www.livingonadime.com. The logs show:
1316707148.641 150275 172.29.30.30 NONE/502 4030 GET http://www.livingonadime.com/ - DIRECT/www.livingonadime.com - OTHER-NONE-DefaultGroup-NONE-NONE-NONE-DefaultGroup
09-28-2011 09:50 AM
Gene,
The HTTP-502 in the logs indicate Bad Gateway. It means WSA received an invalid resposne from an upstream server. If you perform a telnet test from WSA command-line to the website www.livingonadime.com on port 80, you should notice "Connection refused" by the website. This is typically noticed when a upstream server blocks WSA from accessing the website or in few cases if the original web-server is sending 502 error.
-
Satish
09-28-2011 02:34 PM
But what actually constitutes a bad gateway? If the Ironport is bypassed, whether through it's web security bypass settings or through the WCCP access rules, the site comes up clean and quick. Short of bypassing security settings, which one obviously wouldn't want to do, what options are available?
10-05-2011 02:33 PM
I have ran into the same problem. Did anyone find a solution?
04-16-2013 02:04 PM
I have the same issue, when I remove the Ironport, the site works, but turn it back on and even with the site in the Bypass filter it errors out. Surely someone has seen this or knows how to fix it.
04-17-2013 10:45 AM
I'm going from memory here, but I think I had found a solution to this problem.
The issue was with the L4 traffic monitor, which was why the bypass settings never worked. In Security Services > L4 Traffic Monitor I changed the "Traffic Monitored On" from "All Ports" to "All Ports Except Web Ports (HTTP/HTTPS)". My problem went away after this. I'm ok with this solution as the L4 monitor is still scanning the other ports, while the normal Ironport operations would be scanning the web ports for malware type activity.
If this doesn't take care of it, then best of luck to you.
04-18-2013 07:31 AM
Gene,
Thanks for responding. I checked, and unfortunately we have already made that change, and still some sites we attempt to bypass error out (502/Bad Gateway) and when we remove the proxy, it works just fine.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide