Solved: Ironport, IE11, and EUN Not Being Displayed for Blocked Pages

Rchaoua12 · ‎10-30-2014

Greetings!

Our current WSA setup uses Persistent Cookies with Transparent Redirection and Credential Encryption disabled. This setup works really well for Web Proxy of HTTP traffic. Recently, we've been working on HTTPS Proxy functions and noticed that we do not see user identities when HTTPS traffic is being filtered through the WSA.

This finding was a result of our current setup with cookies and transparent redirection. From what I've read, in order to get user identities while still using cookies we must use explicit forwarding with credential encryption disabled.

Since our Web Proxy is in production, we've kept the persistent cookies and transparent redirection in place. From my understanding, we should be able to keep transparent redirection in place while also testing explicit forwarding. I have setup a test workstation and configured the proxy settings. Additionally, I have IP spoofing enabled for only transparent redirection (for the web proxy).

One issue I am having, is on my test workstation using Chrome all filters (decryption and access) work great. I get the EUN page and it shows my user credentials. However, on IE 11 blocked pages just hang they do not show the EUN page. I used fiddler and it shows the EUN page coming to the browser it just won't display it. What in IE could be causing the issue?

Thanks for the help!

jhenkel · ‎10-30-2014

Hello,

I had a customer run into issues with IE not displaying the block pages properly after they applied a MS patch. What we found was that IE was not processing the HTML block page properly due to the standard meta tag in the block pages. They either needed to remove the IE patch, or customize their WSA block pages to remove the meta tag. You should test this carefully, but it may be worth looking into if this is the same issue or not that you are seeing. It's worth noting that not only did the block pages not render properly after this IE patch, but it actually caused the clients to generate excessive HTTPS requests because IE was not understanding the block page.

Here is the MS KB article which is the patch that was applied:

http://support.microsoft.com/kb/2977629/en-us

This is what we did to correct the issue (other than removing the patch)

WORK AROUND:

=============

Remove the <meta> tag from the <head> section of the 403 response.

Again, this may not be the same issue, but it's worth looking into.

Good luck,

Jason

View solution in original post

jhenkel · ‎10-30-2014

Hello,

I had a customer run into issues with IE not displaying the block pages properly after they applied a MS patch. What we found was that IE was not processing the HTML block page properly due to the standard meta tag in the block pages. They either needed to remove the IE patch, or customize their WSA block pages to remove the meta tag. You should test this carefully, but it may be worth looking into if this is the same issue or not that you are seeing. It's worth noting that not only did the block pages not render properly after this IE patch, but it actually caused the clients to generate excessive HTTPS requests because IE was not understanding the block page.

Here is the MS KB article which is the patch that was applied:

http://support.microsoft.com/kb/2977629/en-us

This is what we did to correct the issue (other than removing the patch)

WORK AROUND:

=============

Remove the <meta> tag from the <head> section of the 403 response.

Again, this may not be the same issue, but it's worth looking into.

Good luck,

Jason

Rchaoua12 · ‎10-30-2014

LMAO...I was just reading about that. I am fixing to try it out. Let y'all know if it works!

Rchaoua12 · ‎10-30-2014

Yep that was it! Updated the EUN by removing

<meta http-equiv="Content-Type" content="text/html; charset=utf-8">