Trouble with Per-Connection Direct Proxy Authentication

Yes.  This appears to be the case.  This morning, I worked with one of your engineers via Zoom and was advised of this issue.  Because we cannot remove "Match known users" for standard transparent HTTP traffic, we created a separate rule for Proxy traffic and unchecked "Match known users."  This allowed proxy traffic to flow and counter-intuitive to the setting, users of the proxy were authenticated and user-based web-filtering rules were applied successfully.

What I'm contemplating now is simply listing all internal hosts as "Multi-user hosts," and forcing all hosts (thin client and standard desktops) to use the proxy for HTTP/HTTPS traffic.  Then, I would rid myself of STAS and IP-based authentication entirely.  Would there be any problem with doing this?  I understand that I wouldn't be able to use the DPI / Fast Path, but so what?  65% of my users use terminal servers, so most of my web traffic is going to use the Web Proxy anyway.  Is it worth leaving STAS / transparent proxy in place for 35% of my HTTP/HTTPS traffic?  In my opinion, the authentication process and configuration would be far simpler and easier to understand.  As a bonus, we would be able to return to the setup I had pre-Sophos, with multiple services running on a single server (IP address), with each service separately authenticating with the proxy using a different user id.  Thus, per-service rules could be established versus having to enable an entire server, or generically whitelisting dozens of external endpoints and making these available for everyone.  Please advise.

Hi Patrick, I'm glad you were able to resolve the issue. Thanks for taking the time to try this feature out during our EAP. 

The approach you suggest would work for HTTP/HTTPS traffic but would mean that you lose the ability to do any user-based rules at the firewall level, and you also lose visibility of user reporting for non-HTTP/HTTPS traffic. Basically, any connection that doesn't go through the proxy would have no user ID associated with it.

Regards

Rich

Can this odd behaviour be fixed? In my opinion this is counter-intuitive. This breaks the logic behind unified firewall rule design in XG, where all components and features come together, being merged into a single rule.

Do you have the same rule for your Terminal Server like your Backup Server? 

Because right now, i would highly recommend to split up and segment the different systems. 

Therefore a lot of customers uses a segment of terminal Server, one for backup servers, another for server infrastructure and a client network segment. Each Segment has it own rule set of policies. 

Because thinking about IPS and other rules, you do not want to enable "everything" for a segment, which does not run the related products. For example, IPS policies with postfix pattern are not needed for a LAN segment. 

What does this have to do with backup servers? Nothing. Let's just ignore all other auth mechanisms for a moment. According to RichBaldry (correct me, if I'm wrong), I have to configure two firewall rules just so my multi-host system per-connection authentication setup will work. I have to configure one rule for proxy traffic without match known users and one rule for relevant web traffic, where match known users can be enabled for user identity awareness. This is confusing and counter-intuitive. When looking at all other auth mechanisms, they can be configured into a single rule, even with "match known users" enabled.

Hi cougz

The challenge we have here is the simple timeline of decision making. The 'odd behaviour' is actually a fundamental part of this feature and yes, it does break the unified firewall rule design in XG. We have tried to implement this feature in a way that makes it possible without having to fundamentally change the way Firewall rules operate for the majority of customers who don't need the feature.

SFOS's firewall component uses the rules table to make a decision about how to handle a connection at the time that the connection is first established - when the first TCP SYN packet is sent from the client to the server. The firewall needs to have all relevant information in order to look through the rules table and find the matching rule. When "Match known users" is checked in a firewall rule, that means it also needs to have user identity resolved at this time.

All of our other authentication methods are designed with that in mind - either SATC or Heartbeat auth, that use agents at the endpoint to send auth information out of band so it arrives before the first TCP packet - or captive portal, agents or classic web auth, which do an authentication challenge one time and then store the user ID against the IP address.

But per-connection authentication specifically defers the authentication of a connection to the HTTP exchange, which has to happen AFTER the TCP connection is established and therefore AFTER the Firewall has decided which rule applies to the connection. At the point the Firewall first handles the connection it MUST be treated as 'unauthenticated'. Rules with 'Match known users' will not work for traffic coming from those source IP addresses.

This is why it's recommended that you have one specific firewall rule for your per-connection authentication hosts. This rule should specify these hosts in the source IP address field and will be applied to all traffic coming from those IP addresses. The web policy that you select in this rule can have user or group based conditions, which will be applied correctly because they happen AFTER the proxy authentication.

At the end of the day, the behaviour of this feature is consistent with how the firewall rules have always worked under the hood. It ensures that we can implement the feature without creating a lot of confusion for customers who don't need to use it, but I recognise that it does create a bit of a learning curve for those who do. We are in the process of completing the documentation for the feature prior to the v19 release and we will take all this discussion into account in the how-to article that we plan to include.