Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 5 replies
  • Subscribers 4 subscribers
  • Views 3021 views
  • Users 0 members are here
Options
Suggested
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Transparent Mode proxy and Filtering Options - Websites

Wouter Goossens

Hi all,

Maybe this question is asked before, but I cannot find a clear answer on this.

Scenario:

Our company uses Standard Mode proxy for our Citrix Xenapp environment. Untill last year, internet was only allowed thru your Citrix environment.

Last year we decided to open up internet connection from everyone's client by using the Transparent Mode proxy, so we created a profile and added the client subnets as Allowed Networks. We set it on AD-SSO authentication and are using a Base Policy that blocks all categories and uses a specific user policy (with AD domain users) that allows some categories.

Now regularly we see some issues with this: 

1st: Often the user is not authenticated. in the Web filter logging you can see this by an empty username and ad_domain.

Logging example:

2021:01:29-10:51:24 [name of UTM] httpproxy[26192]: id="0060" severity="info" sys="SecureWeb" sub="http" name="web request blocked, forbidden category detected" action="block" method="CONNECT" srcip="192.168.10.193" dstip="" user="" group="" ad_domain="" statuscode="403"

So we decided to change that default Base Policy to open up the same categories as the users policy. That is of course not what we want, but several tries to fix it didn't help.

2nd: When the user is indeed authenticated, the website, for example a Youtube video is not opening and blocked by Surf Protection. Even when we created a Website exception in Filtering Options - Websites. (on complete url, not just youtu.be or youtube.com)

Logging example:

2021:01:29-15:50:45 [name of UTM] httpproxy[26192]: id="0060" severity="info" sys="SecureWeb" sub="http" name="web request blocked, forbidden category detected" action="block" method="CONNECT" srcip="192.168.160.100" dstip="" user="[username]" group="Active Directory Users" ad_domain="[our domainname]" statuscode="403" cached="0" profile="REF_HttProContaInterLan (Transparant Proxy voor clients lokaal)" filteraction="REF_HttCffUsersConteFilte (Users content filter action)" size="3165" request="0xc0f53500" url="">https://youtu.be/" referer="" error="" authtime="62" dnstime="0" aptptime="103" cattime="87" avscantime="0" fullreqtime="225084" device="1" auth="2" ua="" exceptions="" reason="category" category="147" reputation="trusted" categoryname="Streaming Media"

Indeed, this Streaming Media category is blocked in the Users content filter, as soon as I allow this it will work.

But why doesn't it see the Website exception that we created for that specific youtube video? 

When I add the website exception 'youtu.be' it does work fine, but we want to block Streaming Media sites like youtube and only open up specific video's or other specific websites, not only domains.

I hope someone can clear this up and point me to the right direction.

Many thanks!



This thread was automatically locked due to age.
Parents
  • 0

    When https inspection is off, UTM only sees the host name, and can only filter on that.   The rest of the path is in the encrypted part of the packet, so it is invisible.

    To filter on the path, https inspection must be on.   Based on your symptoms, it sounds like https inspection is still off.

Reply
  • 0

    When https inspection is off, UTM only sees the host name, and can only filter on that.   The rest of the path is in the encrypted part of the packet, so it is invisible.

    To filter on the path, https inspection must be on.   Based on your symptoms, it sounds like https inspection is still off.

Children
  • 0 in reply to DouglasFoster

    My biggest frustration with https inspection is that UTM uses an old version of OpenSSL which provides FIPS compliance but does not support the newer encryption algorithms.   As a result, some websites will refuse to connect with UTM, and you will have to configure inspection bypass for those sites.  Over time, the number of affected sites is likely to increase, while UTM development seems to have no plan to update the OpenSSL subsystem.   I used https inspection for awhile, but I have currently given up on it.

    Some websites do unusual things that also encounter problems with https inspection, and I cannot provide a general description of when or why problems will occur.   It means that you really need to do intense monitoring of your logs to find and fix the problems that https inspection creates with those sites.   That effort requires good log parsing tools, which you need to create first.   I have documented my approach to log parsing, which is based on a SQL database.  If you have a SYSLOG parsing tool like Splunk, the problem should be easier.   But in either case, you need to study the logs to understand what they are reporting..

Unfiltered HTML