Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 4 replies
  • Subscribers 27 subscribers
  • Views 9702 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

XG Firewall 17.1.2 Blocking Microsoft Office Deployment Tool Downloads - Shows Invalid TCP RST in Log

AllanD

NOTE: This looks to be the same issue as https://community.sophos.com/products/xg-firewall/f/firewall-and-policies/100393/invalid-tcp-rst/372613 but in that thread people are saying this error message is normal.  It is NOT and although the log entry might be wrong there is something else going on blocking these downloads.

 

I am having a problem trying to get the Office Deployment Tool ( www.microsoft.com/.../details.aspx ) to download Office images/software from Microsoft.  When running the tool I was seeing lots of "Invalid TCP RST" entries all from my computer to a Microsoft server:

 

 

The deployment tool log showed me this:

10/10/2018 10:15:14.850    SETUP (0xec0)    0x1d40        Click-To-Run Non Task Error    bg87a    Unexpected    DownloadOffice::DownloadFile {"MachineId": "xxxxxxxsnippedxxxxxxx", "SessionID": "xxxxxsnippedxxxxxx", "GeoID": xxx, "Ver": "16.0.10827.20138", "C2RClientVer": "16.0.10827.20138", "ErrorCode": 30125, "ErrorType": "WinHttpSendRequestFailed", "AppVErrorSource": "", "ErrorMessage": "WinHttpSendRequestFailed (Unexpected status code received for Http Send request , Error:0x1a0)", "ErrorDetails": "", "ContextData": "Oexception throw when downloading officecdn.microsoft.com/.../stream.x86.en-us.dat,Retry:1,BufferSize:104857600"}   

 

So it said the file that failed downloading was http://officecdn.microsoft.com/pr/492350f6-3a01-4f97-b9c0-c7c6ddf67d60/Office/Data/16.0.10827.20150/stream.x86.en-us.dat

A quick ping of officecdn.microsoft.com showed the IP address of 23.215.130.144 which matched the log.  So as a test I made a new firewall rule:

Rule Name: Allow Unscanned HTTP Access  |  Source:  LAN - Any  |  Destination: Wan - 23.215.130.144

I turned off all options under Web Malware and Content Scanning and under Advanced I turned off all Intrusion Prevention, Web Policy, etc.  I tried the download and it was successful!  I then, just to make sure, disabled the rule and tried the download again and again my log filled up with Invalid TCP RST entries and the download failed on the same file.  There was no other log entries.  The only difference was now the download, over port 80, was going through our "standard" web access rule which has scanning enabled.

 

Whats going on here?  I tried adding a exception rule for *.microsoft.com but it didn't work.  I tried officecdn.microsoft.com and that failed also.  Only when I specifically called out the IP address in my bypass rule was I able to download the file which I can't rely on as IP addresses change.

 Why do I only see "Invalid TCP RST" entries and no other errors when its obviously blocking something and what would be a more permanent fix?



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

    Just tried a different office product, before it was Office 2016 and this time it was Visio 2016.  Had the same issue, did a ping of the server it was trying to DL off of and the IP address changed.  Added the new IP address to my bypass rule and it downloaded.  Again not the answer but it would be nice to know whats going on.

     

    Also as a side note if I download the exact same file manually using FireFox it downloads without a issue even without the bypass rule.  Could the Office Deployment Tool be doing something getting the file that the Sophos XG doesn't like?  Why would a browser DL of the same file work fine but a program designed to download the file is getting blocked?

  • 0 in reply to AllanD

    Hey Allan,

     

    I noticed you set some exceptions, but have you referred to the Sophos KB for all the Office365 exceptions they recommend?  https://community.sophos.com/kb/en-us/132291

     

    The KB includes all exceptions necessary for installing, updating and general usage.  I can't say this is the only thing preventing it from working, but it's a good start.

Reply Children
  • 0 in reply to GushyJoseph

    I did and it didn't help.  The file being downloaded (blocked I should say) is coming from http://officecdn.microsoft.com and I have added "^([A-Za-z0-9.-]*\.)?microsoft\.com/?" to the Web Exceptions list with no success.  But again if I add the IP address it's pulling from to a "bypass" rule that skips all checks it works.

     

    I have tried adding *.microsoft.com to the Bypass rule but it doesn't seem to use it.  It's like it needs actual IP addresses and I really don't want to plug in all 60+ IP addresses and ranges that are called out on Microsoft site ( https://docs.microsoft.com/en-us/office365/enterprise/urls-and-ip-address-ranges ) but I will if I have to.

  • 0 in reply to AllanD
    If you are doing an exception, please make sure you are excepting both AV scanning and policy.  The reason is that if the policy contains any file types it still engages the AV scanner to do filetype detection.
     
    Can you please temporarily try the following:
    Have it go through the firewall rule so that it is failing.
    Confirm that the rule has "Scan HTTP" checked and Web Policy set (not None).
    Uncheck the scan HTTP.  This will turn off the virus scanner.  As long as there is still a web policy set it will still go through the proxy.
    This effectively will work like an AV exception for all web traffic.
    Does it start working?

    When you have the failure can you please do the following:
    Log Viewer
    Click on the icon to switch to detailed view
    Select the Modules firewall and Web Filter
    Filter to just the time / srcip so that you are only seeing the traffic for this download.
    Can you post the log?  You may need to look at at least a 5 minute chunk around the TCP RST.
     
    The *.microsoft.com method should work.  After configuring it, give it an hour minutes before testing.  In order for it to work then DNS queries need to either go to the XG itself or through the XG.  There is a process that watches the DNS queries and collects the IPs associated with a given domain, this can take time especially as clients can cache with the DNS TTL (time to live).  That being said, there are unconfirmed reports that a change in 17.1 MR3 is causing problems with fqdn based rules.