Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 12 replies
  • Subscribers 31 subscribers
  • Views 4976 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

Explicit Proxy usage - Not working as expected

Mr.Roboto

Hi,

I upgraded an XG to v18 yesterday.
Since the update, access to the Internet, for the CLients on the LAN, no longer works.
The clients use an explicit proxy server (XG).

At first I thought there was a problem with the migrated NAT rules, I deleted all superfluous ones and currently used the default snat rule. But to get the clients to the internet I had to add HTTP and HTTPS to the destination in addition to TCP_3128.

Otherwise I got the message that the proxy server did not react.

Does anyone have any idea what could be the reason for this?

Translated with www.DeepL.com/Translator (free version)



This thread was automatically locked due to age.
  • 0

    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.

  • 0 in reply to Michael Dunn

    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 :)

  • 0 in reply to Mr.Roboto

    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.

  • 0 in reply to Michael Dunn

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

  • 0 in reply to Michael Dunn

    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?

  • 0 in reply to Mr.Roboto

    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.

  • 0 in reply to Mr.Roboto

    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(((.

  • 0 in reply to Viacheslav Moroz

    I have the same issue.

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

    Could someone help?

  • 0 in reply to Kaloian Kirchev

    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.

  • 0 in reply to Michael Dunn

    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.