Guest User!

You are not Sophos Staff.

Thread Info
  • State Verified Answer
  • Locked Locked
  • Replies 7 replies
  • Answers 1 answer
  • Subscribers 29 subscribers
  • Views 10537 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 Proxy Always Active and Interferes With DNS

Phill Campbell

Version: SFOS 16.01.2

There appears to be no way to fully disable the transparent web proxy functionality, even when using a FW rule with:

  • Scan HTTP: Off
  • Decrypt & Scan HTTPS: Off
  • Web Policy: "None"

Although no rules are applied to web traffic, and SSL certificates are not changed, the XG firewall still appears to proxy the request in some manner, in the requests are sent to the IP address based on a DNS lookup from XG and not the IP address specified by the client.

Steps to reproduce:

  1. Create a FW rule with the above proxy settings (should not be proxied at all)
  2. Add a static DNS entry for a website under "Network" -> "DNS" using a different IP address to the real website (example add an entry for "bbc.co.uk" pointing to the IP address of www.google.co.uk (216.58.210.35)
  3. Restart "Web Proxy" service under "System Services" -> "Services"
  4. Browse to the website (https://www.bbc.co.uk)

Expected behaviour:

  • The BBC website should be displayed

Actual behaviour:

  • Google website is displayed

Summary:

Despite the fact that the client connection should not have been proxied, XG firewall has redirected the client connection to another IP address based on its own DNS lookup, rather than the IP address specified by the client.

Full example:

With a static host entry added on the XG as above, the below commands demonstrate that the client can correctly lookup the IPs of the BBC and Google websites.

$ host www.google.com
www.google.com has address 216.58.210.35
$ host www.bbc.co.uk
www.bbc.co.uk is an alias for www.bbc.net.uk.

www.bbc.net.uk has address 212.58.244.69

The following command demonstrates the client requesting a direct connection to the BBC web server using the explicit IP address and a SNI of "www.bbc.co.uk"

openssl s_client -connect 212.58.244.69:443 -servername www.bbc.co.uk

Certificate chain

Certificate chain

 0 s:/C=US/ST=California/L=Mountain View/O=Google Inc/CN=google.com

   i:/C=US/O=Google Inc/CN=Google Internet Authority G2

 1 s:/C=US/O=Google Inc/CN=Google Internet Authority G2

   i:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA

 2 s:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA

   i:/C=US/O=Equifax/OU=Equifax Secure Certificate Authority […]

 

Here it can be seen that the SSL certificate returned is that of the Google website. Clearly the XG has redirected the request based on its static host entry.

We are currently trailing XG firewall and this is causing problems with our "guest only" wifi, as the XG uses internal DNS servers and the wifi clients use public DNS servers. In our cases it is causing our own websites to be accessed internally rather than external from the guest wifi, breaking things like VPN access (DirectAccess) and web mail. 

This will also prevent any clients using static host entries from accessing the intended website - despite the fact that they should not be being proxied. 

Please advise if further details are required. 



This thread was automatically locked due to age.
Parents
  • 0

    Hi Phill, I tried to replicate your DNS problem in the latest 16.05 RC1 but I could not replicate it. A couple of questions

    1. You are obviously using a different DNS server than XG right?

    2. Are you flushing your browser's DNS cache? I used chrome incognito mode and and closed window after each test.

     

    Here is what I did...

    I set up a firewall policy on my XG, Allow LAN> WAN > Any Service, everything unchecked/NONE including user authentication and masq to WAN gateway. I also enabled logging on the rule. I defined bbc.co.uk as 216.58.210.35 just like your post above and tested it against each server.

    Next, i used google as my DNS server on the test machine

     Next I went to firewall logging and turned on packet capture and sure enough the DNS request is being made to 8.8.8.8

    Checked chrome's DNS cache

    and it seems to be caching the right address.

    After clearing all the caches, I changed the DNS on my test machine to XG and tried bbc.co.uk and the website returned was google with the 216.58.210.35 cached in chrome.

  • 0 in reply to Billybob

    Hi Billybob,

    Many thanks for the response. With regards to your questions:

    1) Yes, the client is using Google public DNS and the XG is using our internal Active Directory DNS servers.

    2) DNS/Browser cache was cleared between requests, but with the openssl example command there would be no caching anyway as the connection was made directly to the IP address.

    In your example, you set the DNS entry for "bbc.co.uk" as I mentioned, but your screenshot is showing a DNS lookup for "www.bbc.co.uk" - has your browser automatically completed the "www" for you?

    In my tests, the client always believed itself to have the correct IP address and it was only when the HTTP/S connection is made through the XG that things got weird. I suspected that normally the XG would translate ports 80/443 to the local proxy service, but in the case where it was disabled, instead of allowing the traffic directly out, traffic is either proxied with no restrictions, or still translated, but rather than keeping the destination IP address from the client, the XG was performing its own DNS lookup based on the host header/SNI and translating to that. 

    I will attempt to verify the issue with 16.05 RC1 (currently on 16.01.2), and will report back. 

  • 0 in reply to Phill Campbell

    Phill, you obviously know what you are doing. It maybe a change between v16.01 to 16.05 or maybe our test dynamics are different. I am testing in the US and bbc.co.uk automatically forwards to www and then www.bbc.com. Also if you go into system > administration > device access, you can turn off access to different services (DNS, web proxy) from different zones. Try changing those settings during your tests to get a better understanding of what is going on. Of course packet capturing will give you a clear indication of where the packets are going. You may have to filter your packet captures for DNS traffic only etc. to make it more readable.

    In any case, keep us posted.

  • +1 in reply to Phill Campbell

    Yes, even with firewall rules configures to completely not do Web, the XG still sends traffic through the web proxy.  There are reasons for doing it this way.

    Can you go into Web \ Protection.

    Make sure that "Enable Pharming Protection" is turned off.

    As per the feature description "Protect users against pharming and other domain name poisoning attacks by repeating DNS lookups before connecting."

  • 0 in reply to Michael Dunn

    Many thanks, disabling the pharming protection has done the trick. I had somehow missed that option previously. 

    As, at present, it seems to be a global on or off option, would it ever be considered to add an excluded interfaces option? For most of our 'normal' subnets (where the users DNS will match the internal DNS used by the XG), this would be a desired feature. However for other interfaces, namely our guest wifi (non Sophos AP) and subnets for more technical users (who have a business requirement for custom DNS entries in hosts files and connections to explicit IPs), the pharming protection causes the problems I listed above, which are a show stopper.  

  • 0 in reply to Phill Campbell

    There are no plans currently to change this.  It would not be an easy thing to do.  You would need to move it from the Web settings to the Firewall Rule.

    Feel free to put in a feature request, but unless you can show great value to it, I think the priority would be quite low compared to the other things we are working on.

  • 0 in reply to Michael Dunn

    Thanks for the explanation.

    This explains why I've been banging my head against the wall for the past two days trying to get an IPv6 tunnel working - the transparent web proxy is failing to parse any requests over IPv6, but is quite happy over IPv4 (as well as getting out of the way when IPv4 firewall rules don't use a Web policy).

    I'll try 16.5, as well as reconfiguring the XG Firewall in Bridge Mode and having the modem handle DHCPv6-PD. If neither of those work I guess I'll be looking for a replacement for the XG Firewall.

Reply
  • 0 in reply to Michael Dunn

    Thanks for the explanation.

    This explains why I've been banging my head against the wall for the past two days trying to get an IPv6 tunnel working - the transparent web proxy is failing to parse any requests over IPv6, but is quite happy over IPv4 (as well as getting out of the way when IPv4 firewall rules don't use a Web policy).

    I'll try 16.5, as well as reconfiguring the XG Firewall in Bridge Mode and having the modem handle DHCPv6-PD. If neither of those work I guess I'll be looking for a replacement for the XG Firewall.

Children
No Data