No update path for UTM Endpoint Clients

From Support today.

Thank you for contactnig Sophos technical support.
There is currently an issue with the broker service, our development team are aware of the issue and are working on a resolution

Wingman

Windows 7 Professional 64bit

With the current installation - checked the following to confirm it exist.

C:\Users\MyUserName\AppData\Local\Sophos - YES
C:\ProgramData\Sophos - YES
C:\Program Files (x86)\Sophos - YES
C:\Program Files (x86)\Common Files\Sophos - NO Sophos Folder

Summary of Solution:
There appears to be a bug in Microsoft's IP stack.  The problem appears [to me] to be associated to having a default gateway and DNS entry being equivalent as is frequently the case in Astaro/Sophos environments.
In Win7 if you follow the steps listed above [previous comment] and manually set IP, Gateway, and DNS settings, you'll notice two things.  1) A warning about having two default gateways.  Makes no sense. and 2) The Sophos update will fail.  Setting the machine to DHCP/Automatic IP address definition solves the problem.

Note:  Manually setting the DNS server to something other than the default gateway and creating any necessary firewall rules will also allow the update to occur. 

What's interesting is that in the DHCP/Automatic setup, the default gateway and DNS server are the same [in my case], yet the update works.  

All of this suggests there may be bigger problems with Windows than just this update irritant.

EUREKA!!!

The Alternative Confugration appears to be the problem.
I did change 2 things at once unfortunately.
1.  I removed the alternative configuration and set it to automatic.
2. I changed the primary ip4 address from manual to automatic - with the same settings.

It appears there's a problem with the ip stack and this app.  Another thought is that there are new elements in the DHCP server that are required for this update to work.  If that's true, manually setting ip addresses could be the source of the problem.

Can anyone else duplicate this fix?

Steps: 
1.  Open Network & Sharing Center [Win7]
2. Click on the Connection currently accessing the internet.
3. Click Properties
4. Click IPv4 then click the 'Properties' button
5. Choose Obtain an IP address automatically
6. On the top of the windows there is a "Altnerantive Configuration' tab - click it.  
7. Choose 'Automatic Private IP Address"

I did find an 'alternative configuration' in the ip4 properties of this troublesome Win7 machine.
It has IP: 192.168.1.2  subnet: 255.255.255.0 and default: 192.168.1.1.

I wonder if somehow the updating app is getting confused by this.

It works fine...
IP Addr:         10.1.255.254
Subnet Mask: 255.255.0.0
Default Gtw:  10.1.1.2

I'm stumped. 
This is a VM with Win7 running on a Mac plugged into a switch on the same segment as my straight hardware Win7 that won't update.

Clearly my troubles are local to the hardware machine...  

Flummoxed!

Using VMWare on my Macbook Air I have a network with a class C address space:

IP Address:  192.168.58.175
Subnet:         255.255.255.0
Default:        192.168.58.2
Updating works so my theory above is not correct. 
I'll move this to the Class A subnet and see if updating still works.

I turned on a sniffer then clicked 'Update Now'

Machine's IP addr: 10.1.2.1
Default Gateway: 10.1.1.2


Traffic seen

Source     Dest        Protocol   Length    Info
10.1.2.1   10.1.1.1   TLSv1     331          Application data
10.1.2.1   10.1.1.1   TLSv1     1227        https > 49320
10.1.1.1   10.1.2.1   TLSv1     1056        Application Data, Application Data
10.1.2.1   10.1.1.1   TCP            54         49320  >  https [ACK]...

10.1.1.1 should not be in any route from this machine.
It is the hypervisor on which Astaro (10.1.1.2) is running.

This is very odd.   

Wild guess: It's at least possible the programmers for the update piece have completely botched a basic understanding of networking and are using a 'calculated/guessed' version of the default gateway which breaks if their guess is wrong.

My subnet is 255.255.0.0 so if a noob were to think that the default gateway is x.y.1.1 then they would think in my case it's 10.1.1.1.  This is not the case.   This ridiculous calculation works on 192.168.1.x and 192.169.0.y which seems to be the majority of private networks.  On Class A or B non-routable networks, this will fail. 


I'll do some testing to see if I can validate this ridiculousness.

My responce when attempting to access this page:
This Connection is Untrusted
      
You have asked Firefox to connect
securely to mcs1-5804.broker.sophos.com, but we can't confirm that your connection is secure.
        
     
mcs1-5804.broker.sophos.com uses an invalid security certificate.

The certificate is not trusted because no issuer chain was provided.

(Error code: sec_error_unknown_issuer)

what are you trying to achieve?

My responce when attempting to access this page:
This Connection is Untrusted
      
You have asked Firefox to connect
securely to mcs1-5804.broker.sophos.com, but we can't confirm that your connection is secure.
        
     
mcs1-5804.broker.sophos.com uses an invalid security certificate.

The certificate is not trusted because no issuer chain was provided.

(Error code: sec_error_unknown_issuer)