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

Unable to connect to internal web servers through web proxy

Whenever an internal client device tries to access one of our internally hosted public web servers, the page is blocked by the UTM Firewall with the following message:

08:21:40 WebAdmin connection attempt HTTP  
*.*.*.120 : 46760
*.*.*.120 : 443
 
[SYN] len=60 ttl=64 tos=0x00 srcmac=00:00:00:00:00:00
  1.  *.*.*.120 in the logs is the public IP address of the web server being accessed.

The "WebAdmin connection attempt" error is particularly weird, because our WebAdmin console is not available on that interface, IP, or port.

Clients on the Internet, from outside of our network, are able to access the sites successfully. It is only clients using the UTM proxy being blocked.

We are using 3 Sophos UTM components:

1. Web Filter - Our clients all access the internet through the Sophos proxy server in Standard mode.

2. Firewall - All of our global IPs are on Sophos UTM Interfaces protected by the firewall.

3. Web Application Firewall - Our publicly hosted web servers are configured behind this.

Sophos support told me to use the browser settings to proxy bypass. This doesn't work, and frankly doesn't make any sense to me as a solution. The client would still be routed in and out of the same interfaces regardless.

One potential solution is split DNS. Unfortunately the internal web server is on a non-standard port, so this is less than ideal for our clients.

Any assistance would be very appreciated! I've seen this sort of problem posted many times on the Sophos forums, but haven't found any posts with a solution.



This thread was automatically locked due to age.
  • Hi, Austin, and welcome to the UTM Community!

    Your best bet is to set up split DNS and clone the Virtual Servers to attach the clones to the Internal interface.

    EDIT 2016-11-02: Thanks to Derek below, I was reminded that you need to make sure your client browsers skip the Proxy and go directly to the Virtual Servers.  That's the Transparent Mode Skiplist for Profiles using Transparent mode and, for Standard mode Profiles, in a PAC file or GPO to configure 'LAN Settings' in Windows clients.

    Cheers - Bob

     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
  • Thanks Bob,

    I was hoping there was a solution other than split DNS, as the web server is on a non-standard port internally.

    There is no way to prevent the Sophos firewall from blocking internal traffic in this scenario?

  • Split DNS to aim the FQDNs at Additional Addresses on the Internal interface. You just duplicate the structure that you have defined on the External interface.

    Cheers - Bob

     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
  • We ran into the same exact issue. Please check to see if your User Portal is listening over port 443. If it is, try changing it to 4443, etc.

    Appears to be a bug with UTM. We have an External interface (ETH1) with additional addresses associated to it. Our User Portal listens over 443 on the primary External interface's public IP. Our Virtual Web Servers listen over 443 on their corresponding additional addresses associated to the same External ETH1 adapter.

    For whatever reason, all clients going through the Web Proxy could not connect to the Virtual Web Servers over 443, but instead tried connecting to the User Portal's 443, which would generate the "WebAdmin connection attempt" error.

    On the other hand, clients that bypass the Web Proxy entirely (not via Web Proxy Filter exceptions) had no issues accessing the Virtual Web Servers.

  • Hi, Derek, and welcome to the UTM Community!

    It's great that your first post was helping others!  All of your suggestions are spot on.  I also suggest using a different port for the SSL VPN if the client has only a single IP - my preference is a UDP port, but those are sometimes blocked in European hotels.

    What you perceive as a bug is expected behavior.  I'll edit my original post above to reflect the fact that browsers should go directly to the Virtual Servers and not via Web Filtering.

    Cheers - Bob

     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
  • Thanks for the prompt response BAlfson!

    I perceived it as as bug since the User Portal and Virtual Servers at our Co-Lo Sophos were both listening over 443 on different External addresses without issue. We didn't start having issues until the migration of our web server's VM and Virtual Server settings from the Co-Lo Sophos to our On-site Sophos.

    The only difference is that our Virtual Server now resides on the On-Site Sophos which clients use as their Web Filter Proxy. I guess I don't understand why clients making HTTPS requests through the Web Filter to our Virtual Server would be interpreted as "WebAdmin Connection Attempts" to the Virtual Server's address ending with .195, even though the User Portal is setup to listen on External address ending with .222.

     

     

  • I always set the Listen Address to "Any" - also allowing access from inside the LAN.  In any case, you've inadvertently changed the User Portal listening port to 4443 - the port reserved for WebAdmin.  I suspect that changing that to 2443 will get rid of the strange messages in the Firewall Live Log.  Any luck with that?

    Cheers - Bob

     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
  • I'll change it to 2443 instead. Sounds like that's what Sophos documents as well. It did work over 4443 since our WebAdmin portal's listening port is non-default.

     

    Thanks Bob.