Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 15 replies
  • Subscribers 1 subscriber
  • Views 29297 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

SUM cannot download Mac OS X subscription

VladGuan

Hi All,

We have a Windows 2008 R2 domain network (with Windows 2008 R2 servers, Windows 7 workstations, Mac OS X 10.9.4 workstations and CentOS 6.5 servers/workstations) that access the internet via a proxy (Squid). I have set up a Sophos Server on Windows Server 2008 R2 and have successfully subscribed to Windows and Linux subscriptions and have protected all Windows and Linux machines. However, whenever I add the Mac OS X 10.6+ subscription, the SUM throws errors saying there is an issue with the proxy/gateway and the HTTP response code is 502. We do not have any issues with the proxy as we can get to the internet without issues. Our paid subscription includes Windows, Linux and Mac OS X.

Anyone else experienced this? I can't seem to find any related posts on Google.

Edit: We are using SEC 5.1.

Thanks in advance,

Vlad

:52615


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

    Hello Vlad,

    well, this confirms that it's neither just this file nor the backend CDN. I'm blissfully ignorant of CentOS (and Squid and wget as well) so I won't be of much help in the further investigation. I'm not yet totally convinced that the culprit is (something on) CentOS. That wget reports the reset in headers suggests that it did not receive the header/content separator (and likely not a response at all). Maybe Wireshark could show whether the CentOS box does indeed receive data at least up to the CAFEBABE magic number - if not, then it's not CentOS which intercepts the download. One more thing to try - use https with wget (or a browser) instead of http. It should work, but the certificate would be invalid (you'd get the default Akamai certificate). While this wouldn't help to resolve the problem it would confirm that "something" is indeed inspecting the data. 

    Christian

    :52903
Reply
  • 0

    Hello Vlad,

    well, this confirms that it's neither just this file nor the backend CDN. I'm blissfully ignorant of CentOS (and Squid and wget as well) so I won't be of much help in the further investigation. I'm not yet totally convinced that the culprit is (something on) CentOS. That wget reports the reset in headers suggests that it did not receive the header/content separator (and likely not a response at all). Maybe Wireshark could show whether the CentOS box does indeed receive data at least up to the CAFEBABE magic number - if not, then it's not CentOS which intercepts the download. One more thing to try - use https with wget (or a browser) instead of http. It should work, but the certificate would be invalid (you'd get the default Akamai certificate). While this wouldn't help to resolve the problem it would confirm that "something" is indeed inspecting the data. 

    Christian

    :52903
Children
No Data