Website blocked due to :err_internal

[keithsauer507]

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?

[jvandenburg]

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

[keithsauer507]

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.

[edadios]

I suggest you instead pass the traffic to the Ironport, while you are collecting access logs as documented here.

http://tinyurl.com/6ekeec

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.

[gschwab]

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 -

[ravmadir]

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

[gschwab]

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?

[swholliman]

I have ran into the same problem.  Did anyone find a solution?

[Michael Cole]

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.

[gschwab]

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. 

[Michael Cole]

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.