Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 9 replies
  • Subscribers 1 subscriber
  • Views 1708 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

Web Filter weirdness with Dual-Homed machine

jdobiash
So we've been running our UTM for a short while now with few issues.  The setup is we allow both Transparent and Standard mode with AD SSO turned on.   The policy requires authentication (Block Access on authentication failure).     I just ran into an issue with a Laptop that essentially has two active NICs, one wired and one wireless.   Both are on our internal network and would go out via the UTM for it's internet access.    One NIC works properly, traffic going out via it authenticates and shows the name of the user in the logs.  The other NIC, when it is used, seems to allow all traffic out completely unauthenticated (or at least not logged properly).   The log entry shows no exceptions and no username on it.  If I type that IP address into the "Policy Test" area with the same URL that the logs show being allowed out, it shows it should be blocked with no username inserted.  The policy itself seems to be working, it's more like the UTM isn't properly logging the data as the actual user.  It's a bit of an issue for us as we need that information for reporting purposes.

Any thoughts?  Here are two entires from the logs, both from the same computer but each IP address:

[NOT WORKING]
2014:07:16-08:27:31 utm-1 httpproxy[32727]: id="0001" severity="info" sys="SecureWeb" sub="http" name="http access" action="pass" method="CONNECT" srcip="10.0.12.153" dstip="173.194.33.78" user="" statuscode="200" cached="0" profile="REF_DefaultHTTPProfile (Default Web Filter Profile)" filteraction="REF_DefaultHTTPCFFAction (Global Web Filter)" size="7025" request="0xe2303980" url="clients2.google.com/" exceptions="" error="" authtime="2" dnstime="7" cattime="156" avscantime="0" fullreqtime="240147752" device="1" auth="2" category="178" reputation="neutral" categoryname="Internet Services"

[WORKING]
2014:07:16-13:45:04 utm-1 httpproxy[32727]: id="0001" severity="info" sys="SecureWeb" sub="http" name="http access" action="pass" method="GET" srcip="10.0.22.111" dstip="23.235.47.130" user="CTGR\" statuscode="200" cached="0" profile="REF_DefaultHTTPProfile (Default Web Filter Profile)" filteraction="REF_HttCffIsWebFilte (IS Web Filter)" size="1547" request="0xe2302aa0" url="a.disquscdn.com/.../avatar92.jpg

BTW, is there anyway to tell from the logs if the request came in via direct proxy or transparently?


This thread was automatically locked due to age.
Parents
  • 0
    It is last known user for that IP address.

    You should be able to see in the logs the Filter Action that was chosen and from that determine what Policy was used.


    Block access on authentication failures is not related to this.  With SSO that feature is basically to request the SSO username/password but if it fails do not request it a second time (which causes a screen pop).  When turned off it is intended to be minimally intrusive way of getting username for logging purposes without ever asking the user for their username.  When the box is checked it behaves the same as 9.1.

    For HTTPS traffic there is no way for the UTM to request authentication without doing a man-in-the-middle in the SSL stream - which is decrypt and scan.  Assuming for a moment that we cannot do that (not configured) then the only options are to block (via "server refused connection" since we cannot display a block page) or to do "best guess" and use stored credentials and logic for no user name.

    Is there a reason you don't configure the computer to use the UTM as an explicit proxy?  I think it would solve all the problems.
Reply
  • 0
    It is last known user for that IP address.

    You should be able to see in the logs the Filter Action that was chosen and from that determine what Policy was used.


    Block access on authentication failures is not related to this.  With SSO that feature is basically to request the SSO username/password but if it fails do not request it a second time (which causes a screen pop).  When turned off it is intended to be minimally intrusive way of getting username for logging purposes without ever asking the user for their username.  When the box is checked it behaves the same as 9.1.

    For HTTPS traffic there is no way for the UTM to request authentication without doing a man-in-the-middle in the SSL stream - which is decrypt and scan.  Assuming for a moment that we cannot do that (not configured) then the only options are to block (via "server refused connection" since we cannot display a block page) or to do "best guess" and use stored credentials and logic for no user name.

    Is there a reason you don't configure the computer to use the UTM as an explicit proxy?  I think it would solve all the problems.
Children
No Data