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

    Hi Christian,

    I tried the other Mach-O binary and it also fails to download. I also tried using the --header option with the IP address with the same result. It is strange as it seems something on the CentOS 6.5 installation, other than iptables, squid and selinux is blocking scripts from being downloaded.

    I tried with the following and it made no difference:

    service squid stop

    service iptables stop

    setenforce 0

    I am baffled.

    Cheers,

    Vlad

    :52901
  • 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
  • 0

    Hi Christian,

    Your hunch was correct.

    I just tried wget --no-check-certificate https://d1.sophosupd.com/update/639f...fb6374x000.dat

    and it worked.

    So it is looking a lot like something on CentOS is snooping the packet and preventing the download using http.

    Cheers,

    Vlad

    :52909
  • 0

    Hello Vlad,

    something on CentOS

    so you can definitely rule out an upstream (network) component? But CentOS or outside - what would be the rationale for blocking Mach-O binaries (unless there are mistaken for Java Class files)?

    Christian

    :52911
  • 0

    All fixed. We have two Cisco routers, one for each part of our segmented corporate network. The routers were meant to have the same configuraution but the one with the issue has HTTP Inspection turned on and it did not like the reply header for the Mach-O binaries and so rejected it. The Ubuntu server I had success with was actually on the other segment where the Cisco router had the HTTP Inspection turned off.

    Cheers all for the help,

    Vlad

    :53329