Explicit Proxy usage - Not working as expected

Can you look at:

https://community.sophos.com/kb/en-us/132117

There is an issues in XG (including both 17.5 and 18.0) that if you have an explicit drop all rule for source any dst any, that interferes with a direct proxy only.  You need to include http/https service as well or change the drop all rule to specify specific zones.  I don't think that this would have changed between 17.5 and 18.0.  Please let me know.

Hi,

first thank you for your help.
What I don't understand, why it worked with SFOS 17.5.8 MR-8 and now it did not work with the latest v18?

What I've seen is that the NAT is running over the default SNAT rule, that okay I hope?

Is it correct to check the: Use web proxy instead of DPI engine .....in this case?
I dont get it, what the HTTP/HTTPS rule with WebPolicy Deny All really does.

Any help is welcome :)

I also do not know why it used to work and does not, except that it probably has to do with the changing of NAT rules.

Yes, you should have "use web proxy" checked (as you you for any upgraded rule) although for explicit mode it doesn't really matte.

The underlying issue is that with the proxy there are two connections.  From the client to the XG proxy and then from the XG proxy to the web server.

In a configuration where there is just the default drop rule (readonly) the XG to web server works fine.

In a configuration where an admin has created their own default drop rule, the XG to web servier connection fails.  The firewall doesn't allow connections on those ports.

By creating a port 80/443 rule, you are telling the firewall to open the ports.  When the XG's web proxy is making a connection to the outside web server the Deny All policy does not take affect (it already has a policy from the client connection).  But if there are any transparent clients that try to connect they will have the Deny All policy enforced.

Do you have any sort of SD-WAN Rules and a Multi WAN concept? 

Hi,

I just stumbled across this topic again. I have a fresh XG v18MR1 appliance, there is only one firewall rule here:

SOURCE: Allow LAN Any
DESTINATION: WAN Any TCP_3128

...and it will not work until I do the workaround with the "HTTP HTTPS rule".

The problem with the workaround is the following, in the web-protection there are several ports for the proxy, by default, I would have to add all these ports to the workaround rule.
This is really no fun. :=(

We have customers who have the requirement of a direct proxy, but so?
Then I better stay with SFOS v17x

Is there any feedback or meanwhile a solution to this?

Yes, you would need a single firewall rule that includes all the destination ports you want to allow in the explicit proxy, a duplicate of the list under Web, General Settings, Allowed Destination Ports.

Hi!

Have same problem with explicit proxy.

After update from 17.5.12 to SF 18.0 MR1-1 (18.0.1.396) explicit proxy policy do not match any traffic and users cannot get to internet.

Policies work fine after downgrade.

Sofos support does not give clear answers(((.

I have the same issue.

Proxy just do not work as it was in v17.5.12.

Could someone help?

As per the discussion in this thread

1)

https://support.sophos.com/support/s/article/KB-000038109?language=en_US

Read the "All requests result in error in direct mode only" and follow the workaround.

If that does not do it then

2)

Review all the NAT rules.  If you upgraded then you may have a lot of NAT rules bound to firewall rules, which should make the behavior the same but is not clear, efficient, or what most people who are building policy and rules natively in v18 would do.  What the video in the link to understand NAT and then remove/update the migrated NAT rules to replace them with better rules.

If you have done that and it still does not work, then post explaining your setup, all firewall rules that affect web traffic, and clearly explain what the users are experiencing - including waiting for error messages that may occur after timeouts.

Hello,

after using this workaround to get a working "direct proxy only" on port 3128 I have big troubles with the automatic windows connection tests. (msftconnecttest.com / msftncsi.com)

They dont´t do as they should.

Windows periodically pops up a browser window. (mostly the msm.com website becouse of msftconnecttest.com/redirect)

Clients without internet access (no proxy address is added) get´s the blocked website from sophos. (because the browserwindow opens too but no internet is available)

Without this workaround (and the direct proxy dont work) or on version v17.x this problem does not exist.

This workaround (allow 3128/80/443 on one side for the network and block it again with another web based proxy rule "deny all" completly crashes the standard windows connection test.

I am not sure I fully understand.

You have a client that does not have a proxy set in Internet Explorer (which is used by the rest of Windows).

Therefore if you tried to access a webpage, it would fail to load.

The periodic test to msftconncttest.com fails.

Isn't the msftconncttest.com failures correctly stating that you have no internet access?

Let me show you the problem in detail:

overall setup goal: global network internetaccess only through a direct proxy on port 3128

-> with v17.x and without an optional "drop all rule" at the end (no workaround needed)

- enable web proxy, at general settings set listening port to 3128, add allowed destination ports 80, 443 (minimal setup)

- add a firewall rule to allow lan,any to wan,any on port 3128

now every client with the correct proxy address added at internetoptions have a working internetconnection. At least they can surf through the web (http/https) and windows shows the network icon "internet access"

clients without the proxy address enabled don´t have internet access, they get the normal windows "no connection" error message in the browser if they try to surf and the windows network icon shows "limited connectivity"

<<< that is the normal windows behavior, but with the workaround it´s different:

-> with v18.x or with optional "drop all rule" at the end (v17.x) (workaround needed)

- web proxy settings are still the same, but now you have to add port 80,443 to your firewall proxy 3128-rule as well. (after this step, you have a transparent proxy as well, but that´s not desired (internetaccess is possible without adding the proxy settings at your client))

- so you need to add the lan to wan web rule "deney all" for 80,443 as shown in the workaround.

now every client with the correct proxy address added at internetoptions have a working internetconnection. The windows connection test is now broken, don´t work as expected for your windows system and you get the symptome that your system just opens a browser window on startup. (msftconnecttest.com/redirect -> msm.com) (you find this at google with keywords: msn opent at startup, explorer opens, ...) This all because your network setup isn´t a "normal one" for windows and this is the last possible step of the connection test to see if the open browser window has a connection. Respectively windows wants to open the proxy login/authenthication page to get full network access for your client. (your client has internet access and therefore msm.com opens)

Microsoft says: https://support.microsoft.com/en-us/help/4494446/an-internet-explorer-or-edge-window-opens-when-your-computer-connects

Overall the popup browser is just annoying in this kind of setup. (sometimes if you dont use the internet and windows runs the periodically passive connection test you get the pop up again)

- bigger problem with clients without the proxy address enabled (no internet allowed and you dont want/need any internet). After startup and periodically windows connection test opens the browser and the client get´s the "blocked site message" from sophos because now there is a "deny all" web firewall rule and windows wants to "fix" this by granting proxy access. This is a windows feature (see microsoft link above). You can fix this with another workaround but that´s not the way to go.

With the sophos workaround windows allways sees the direct proxy (also if you dont enter any proxy ip) and then windows wants you to log in/get access by pushing browser popups. (you dont get any "no connection" error messages any more like expected, just sophos blocked screens)

 In any direct proxy network setup you should not get/see any proxy features without adding the proxy to the client. If I dont add the proxy I dont want any connection and I dont want any popups because windows sees the proxy because of a workaround fix from sophos.

(I have about 20 windows 10 client, mostly all fully updatet but that makes no different)

Let me show you the problem in detail:

overall setup goal: global network internetaccess only through a direct proxy on port 3128

-> with v17.x and without an optional "drop all rule" at the end (no workaround needed)

- enable web proxy, at general settings set listening port to 3128, add allowed destination ports 80, 443 (minimal setup)

- add a firewall rule to allow lan,any to wan,any on port 3128

now every client with the correct proxy address added at internetoptions have a working internetconnection. At least they can surf through the web (http/https) and windows shows the network icon "internet access"

clients without the proxy address enabled don´t have internet access, they get the normal windows "no connection" error message in the browser if they try to surf and the windows network icon shows "limited connectivity"

<<< that is the normal windows behavior, but with the workaround it´s different:

-> with v18.x or with optional "drop all rule" at the end (v17.x) (workaround needed)

- web proxy settings are still the same, but now you have to add port 80,443 to your firewall proxy 3128-rule as well. (after this step, you have a transparent proxy as well, but that´s not desired (internetaccess is possible without adding the proxy settings at your client))

- so you need to add the lan to wan web rule "deney all" for 80,443 as shown in the workaround.

now every client with the correct proxy address added at internetoptions have a working internetconnection. The windows connection test is now broken, don´t work as expected for your windows system and you get the symptome that your system just opens a browser window on startup. (msftconnecttest.com/redirect -> msm.com) (you find this at google with keywords: msn opent at startup, explorer opens, ...) This all because your network setup isn´t a "normal one" for windows and this is the last possible step of the connection test to see if the open browser window has a connection. Respectively windows wants to open the proxy login/authenthication page to get full network access for your client. (your client has internet access and therefore msm.com opens)

Microsoft says: https://support.microsoft.com/en-us/help/4494446/an-internet-explorer-or-edge-window-opens-when-your-computer-connects

Overall the popup browser is just annoying in this kind of setup. (sometimes if you dont use the internet and windows runs the periodically passive connection test you get the pop up again)

- bigger problem with clients without the proxy address enabled (no internet allowed and you dont want/need any internet). After startup and periodically windows connection test opens the browser and the client get´s the "blocked site message" from sophos because now there is a "deny all" web firewall rule and windows wants to "fix" this by granting proxy access. This is a windows feature (see microsoft link above). You can fix this with another workaround but that´s not the way to go.

With the sophos workaround windows allways sees the direct proxy (also if you dont enter any proxy ip) and then windows wants you to log in/get access by pushing browser popups. (you dont get any "no connection" error messages any more like expected, just sophos blocked screens)

 In any direct proxy network setup you should not get/see any proxy features without adding the proxy to the client. If I dont add the proxy I dont want any connection and I dont want any popups because windows sees the proxy because of a workaround fix from sophos.

(I have about 20 windows 10 client, mostly all fully updatet but that makes no different)