Battle.net Client Can't Download Updates

In v2 this configuration screen will be rewritten.  I don't know what the UI will look like but it will probably be closer to the way the UTM does exceptions.

There are two different bypasses involved.

To stop the man-in-the-middle decryption of SSL traffic in an HTTPS connection then you must use the HTTPS Scanning Rules.  If in the firewall rule you have "HTTPS scanning" turned off this option will make no difference.

To stop the AV scanning of HTTP traffic or the AV scanning of HTTPS traffic that has been decrypted then put it in the HTTP Scanning Rules,  I don't know the full details but it might turn off some other scanning in addition to AV (eg I don't know if it would also skip category blocks).

If you have turned of the decryption of SSL traffic (HTTPS scanning rules) then there is no decrypted traffic to send to the AV scanner and the HTTP Scanning Rules makes no difference.  So in theory if you are having HTTPS / SSL problems you only need to put it in the HTTPS rules.  Though if that still does work you throw theory out and try putting it in both.  :)

Michael Dunn 

Thanks for the reply.  It's still not working.  HTTP bypass doesn't seem to work for IP connections.

Here are the rules:

and here is a packet capture, once again saying consumed by rule 1 which is the default network policy with HTTP scanning turned on.

Any ideas?

First of all, I will admit this is getting out of my area of expertise - partially because I'm not a firewall guy and partially because I'm new to the XG.  I'm just a Sophos employee volunteering off hours to help in the forums.  If you have a paid license you can try to go through proper support.

When a packet comes to the XG it first goes the the Firewall.

The Firewall then decides what to do with it.  It could allow the packet through.  It could drop or reject it.  It could take the packet and give it to the httpproxy and let it decide.

If the httpproxy gets the packet then it will assemble packets, decode the HTTP/HTTPS headers and make a decision, then it will log that decision in the Web Proxy logs.

The scanning rules that you posted above relate to the scanning that the httpproxy does.

Your logs are from the firewall.  Not the proxy.  If the firewall is blocking you that means that the packets are never processed by httpproxy.  The scanning rules don't apply because you are being blocked before then.

Try looking at your firewall rules to see if there is a reason in there that you might be blocked.  Try making higher priority firewall rules that match that source/destination and do not have "HTTP Scanning" and "Web Filter Policy" set.

Thanks for the response!  I will give that a shot.  Just to be clear though turning off HTTP scanning and keeping everything the same allows these packets to pass.  Thanks for your time.

here are the regex needed for the battle.ent updates to work:

^https?://([A-Za-z0-9.-]*\.)?blizzard\.com/

^https?://([A-Za-z0-9.-]*\.)?edgesuite\.net/

sorry forgot one

^https?://([A-Za-z0-9.-]*\.)?battle\.net/

I give these regexes every bypass option in the web proxy.  I can download just fine.  make sure you change battle.net client to http download otherwise it tries to use bit torrent...put my expressions into an exception under web filtering and change battle.net to http download and it should work.

You may have to uninstall/reboot/reinstall the client to change to http.  I have had this running for over a year so it works.  Unless XG has something totally different these three regex expressions should be all you need.

Thanks William.  There isn't an option to disable P2P downloads from Blizzard, that was removed over a year ago.  Unless there's some trick.  My problem is that the client is trying to do a direct IP download from Blizzard servers.  I checked ARIN and Blizzard owns them.

I am convinced HTTP scanning is just broken.   I mean it works, but trying to make and exception for direct IP does not.  I created a brand new rule and only enabled HTTP scanning and made an IP exception for 24.105.29.75 and then turned on packet capture and once again I see it getting consumed by the new rule (44) I just created.

Here's the new rule.  Only http scanning turned on and I have an exception for 24.105.29.75

I really wish a staff member who works on this feature would just confirm or deny that IP based exceptions for HTTP scanning work.  I have wasted hours and went above and beyond providing information.   I'm chalking this up as a bug and done "playing" with XG for now.