Thread Info
  • State Suggested Answer
  • Locked Locked
  • Replies 7 replies
  • Answers 1 answer
  • Subscribers 6 subscribers
  • Views 2688 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

Download of larger iOS and macOS updates fails due to reset connection

MH@V

For some reason, whenever I try to download a larger iOS or macOS update/upgrade (e.g., iOS 13 or macOS Catalina), the update starts but then inevitably fails after a few minutes; and it is only affecting Apple downloads.  No problems with updates from Ubuntu, CentOS, Microsoft, etc.

I have gone to Web Protection > Filtering Options and Application Control and exempted every single Apple-related URL, as well as the entire 17.0.0.0/8 range, but it hasn't helped. I have also tried to exempt the iOS and macOS devices, but that hasn't helped either.  Switching temporarily to another firewall product allowed me to download and update a few test devices, so I don't think it is the Apple devices or the ISP.

But I cannot figure out what other option to try.  By running tcpdump on the UTM, I noticed that the updating device always ends up resetting the connection (see below).  If anyone has some insight as to why this is happening, it would be greatly appreciated.

 

21:13:37.654711 IP ussea4-vip-bx-006.aaplimg.com.http > 192.168.0.202.51888: Flags [.], seq 152689905:152692793, ack 390, win 117, options [nop,nop,TS val 353833104 ecr 267897259], length 2888
21:13:37.654925 IP 192.168.0.202.51888 > ussea4-vip-bx-006.aaplimg.com.http: Flags [.], ack 152689905, win 113, options [nop,nop,TS val 267897274 ecr 353833104], length 0
21:13:37.655042 IP ussea4-vip-bx-006.aaplimg.com.http > 192.168.0.202.51888: Flags [.], seq 152692793:152695681, ack 390, win 117, options [nop,nop,TS val 353833104 ecr 267897259], length 2888
21:13:37.655290 IP 192.168.0.202.51888 > ussea4-vip-bx-006.aaplimg.com.http: Flags [.], ack 152692793, win 91, options [nop,nop,TS val 267897274 ecr 353833104], length 0
21:13:37.655386 IP ussea4-vip-bx-006.aaplimg.com.http > 192.168.0.202.51888: Flags [.], seq 152695681:152698569, ack 390, win 117, options [nop,nop,TS val 353833104 ecr 267897259], length 2888
21:13:37.655700 IP ussea4-vip-bx-006.aaplimg.com.http > 192.168.0.202.51888: Flags [.], seq 152698569:152701457, ack 390, win 117, options [nop,nop,TS val 353833104 ecr 267897259], length 2888
21:13:37.656015 IP ussea4-vip-bx-006.aaplimg.com.http > 192.168.0.202.51888: Flags [.], seq 152701457:152702901, ack 390, win 117, options [nop,nop,TS val 353833104 ecr 267897259], length 1444
21:13:37.656351 IP ussea4-vip-bx-006.aaplimg.com.http > 192.168.0.202.51888: Flags [.], seq 152702901:152704345, ack 390, win 117, options [nop,nop,TS val 353833104 ecr 267897259], length 1444
21:13:37.657009 IP 192.168.0.202.51888 > ussea4-vip-bx-006.aaplimg.com.http: Flags [.], ack 152704345, win 0, options [nop,nop,TS val 267897276 ecr 353833104], length 0
21:13:37.897580 IP ussea4-vip-bx-006.aaplimg.com.http > 192.168.0.202.51888: Flags [.], ack 390, win 117, options [nop,nop,TS val 353833348 ecr 267897276], length 0
21:13:37.898222 IP 192.168.0.202.51888 > ussea4-vip-bx-006.aaplimg.com.http: Flags [.], ack 152704345, win 0, options [nop,nop,TS val 267897516 ecr 353833104], length 0
21:13:38.369383 IP ussea4-vip-bx-006.aaplimg.com.http > 192.168.0.202.51888: Flags [.], ack 390, win 117, options [nop,nop,TS val 353833820 ecr 267897516], length 0
21:13:38.370095 IP 192.168.0.202.51888 > ussea4-vip-bx-006.aaplimg.com.http: Flags [.], ack 152704345, win 0, options [nop,nop,TS val 267897987 ecr 353833104], length 0
21:13:39.361304 IP ussea4-vip-bx-006.aaplimg.com.http > 192.168.0.202.51888: Flags [.], ack 390, win 117, options [nop,nop,TS val 353834812 ecr 267897987], length 0
21:13:39.361875 IP 192.168.0.202.51888 > ussea4-vip-bx-006.aaplimg.com.http: Flags [.], ack 152704345, win 0, options [nop,nop,TS val 267898977 ecr 353833104], length 0
21:13:39.725296 IP 192.168.0.202.51888 > ussea4-vip-bx-006.aaplimg.com.http: Flags [R.], seq 390, ack 152704345, win 0, length 0



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

    Hi MH and welcome to the UTM Community!

    You might want to check the Web Filtering log file for statuscode="50." related to these blocks.  What you're seeing is often caused by the remote server's "frustration" with the speed of your responses after receiving a block of data.  The first thing to try is an Exception for anti-virus.  If that doesn't eliminate the "50." messages, you will need to use the log to determine which IPs you need to add to the destinations for which the Proxy is skipped.

    Cheers - Bob
    PS If my guess is on-target, I'll move this thread to the Web Protection forum.

     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
  • 0 in reply to BAlfson

    Hi,

     

    Thanks for the welcome and the search tip.

    I've checked the logs, and there are a number of 50. class status codes, but none related to that particular situation.

    I did try with the anti-virus exception, and also adding the destination IP(s) to the skip list, but unfortunately that did not help.

     

    Thanks,

     

    MH

  • 0 in reply to MH@V

    Is the traffic still being handled by Web Filtering after you've added the IPs to the Skiplist?  If that's the case, then you must be using the proxy in Standard mode - explicit proxy in your browser and you will need to place your skips there.

    Cheers - Bob

     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
  • 0 in reply to BAlfson

    Thanks for the suggestion. I checked and it was in Transparent mode.

    I wonder if there is something going on at the OS level.  I just reset the UTM to factory defaults, then restarted with Web Filtering turned off completely.  As before, the download started and proceeded for a while before the error came up again.

    So I switched back to the other firewall, and the download succeeded.

    I may have to do a complete reinstall at this point.

    Thanks again,

    MH

Reply
  • 0 in reply to BAlfson

    Thanks for the suggestion. I checked and it was in Transparent mode.

    I wonder if there is something going on at the OS level.  I just reset the UTM to factory defaults, then restarted with Web Filtering turned off completely.  As before, the download started and proceeded for a while before the error came up again.

    So I switched back to the other firewall, and the download succeeded.

    I may have to do a complete reinstall at this point.

    Thanks again,

    MH

Children
  • 0 in reply to MH@V

    Further to my previous note, I ended up reinstalling everything from scratch.  I can now download without any issues.  So there must have been some setting that was not touched by the factory reset.

     

    Thanks again for all your suggestions.

     

    MH

Unfiltered HTML