Issue with the Firewall configuration after problems with updates

Hi Markus Hartmann 

Could you please provide more details about the error message you receive while update fails a screenshot would be great. Also, the firewall client should pull the policy that you have deployed. You can refer to this article for Sophos Client firewall policy setting. 

Dear Shweta,

thank you for your reponse.
Below is are a few blocks for each client, causing mulitple issues with the updates.

I have selected to deploy the policies for all clients, that had issues.
At the end, as mentioned, I just had the option to force the update via "protect computers".
The clients have installed the firewall, but somehow the FW policy was not deployed.
So the clients did enable the firewall to protect, even the client was in the corporate network.

Can I enable a task, that - when an installation via "protect computer" is engaged - the clients pulls the policies in a very short time until completed
and comply with all polices?

Each block is for one computer

Sophos AutoUpdate status Date/time Code Description
7/8/2019 11:13:59 AM 0000006b Download of RMSNT failed from server sophosav.vamed.com/.../
7/8/2019 11:06:45 AM 0000006b Download of Sophos Clean failed from server sophosav.vamed.com/.../OPMHMPA
7/8/2019 10:54:13 AM 0000006b Download of Sophos Clean failed from server sophosav.vamed.com/.../OPMHMPA
7/8/2019 10:35:02 AM 00000000 Updated successfully
7/8/2019 10:27:53 AM 0000006b Download of SAVXP failed from server sophosav.vamed.com/.../
7/8/2019 10:23:10 AM 0000006b Download of Sophos HitmanPro Alert failed from server sophosav.vamed.com/.../OPMHMPA
7/8/2019 10:07:00 AM 00000000 Updated successfully
7/8/2019 10:00:44 AM 0000006b Download of Sophos Endpoint Defense failed from server sophosav.vamed.com/.../
7/8/2019 8:06:35 AM 00000000 Updated successfully
7/8/2019 7:59:55 AM 0000006b Download of Sophos Client Firewall failed from server sophosav.vamed.com/.../
7/8/2019 7:40:00 AM 0000006b Download of Sophos Clean failed from server sophosav.vamed.com/.../OPMHMPA
7/8/2019 7:09:41 AM 00000000 Updated successfully

Sophos AutoUpdate status Date/time Code Description
7/5/2019 3:23:05 PM 0000006e Updating failed because no update source has been specified
7/5/2019 7:35:12 AM 0000006e Updating failed because no update source has been specified
7/4/2019 10:03:05 AM 0000006e Updating failed because no update source has been specified
7/4/2019 8:57:17 AM 0000006e Updating failed because no update source has been specified
7/3/2019 8:39:31 AM 0000006e Updating failed because no update source has been specified
7/2/2019 2:10:51 PM 0000006e Updating failed because no update source has been specified
7/2/2019 8:45:57 AM 0000006e Updating failed because no update source has been specified
7/1/2019 10:48:14 AM 0000006e Updating failed because no update source has been specified
7/1/2019 8:16:49 AM 0000006e Updating failed because no update source has been specified
7/1/2019 6:52:06 AM 0000006e Updating failed because no update source has been specified
6/28/2019 6:49:58 AM 0000006e Updating failed because no update source has been specified
6/27/2019 11:30:17 AM0000006e Updating failed because no update source has been specified
6/27/2019 8:09:47 AM 0000006e Updating failed because no update source has been specified
6/26/2019 7:57:02 AM 0000006e Updating failed because no update source has been specified
6/25/2019 10:37:08 AM0000006e Updating failed because no update source has been specified

Sophos AutoUpdate status Date/time Code Description
6/25/2019 4:19:39 PM 0000006b Download of Sophos Network Threat Protection failed from server sophosav.vamed.com/.../
6/25/2019 3:39:13 PM 00000000 Updated successfully
6/25/2019 3:32:16 PM 0000006b Download of Sophos Clean failed from server sophosav.vamed.com/.../OPMHMPA
6/25/2019 12:15:17 PM00000000 Updated successfully

Sophos AutoUpdate status Date/time Code Description
7/5/2019 11:49:29 AM 0000006b Download of Sophos Clean failed from server sophosav.vamed.com/.../OPMHMPA
7/4/2019 10:41:01 AM 00000000 Updated successfully
7/3/2019 12:04:49 PM 0000006b Download of Sophos Clean failed from server sophosav.vamed.com/.../OPMHMPA
7/3/2019 8:03:57 AM 00000000 Updated successfully
7/2/2019 8:08:16 AM 00000000 Updated successfully
7/1/2019 10:39:53 AM 00000000 Updated successfully
6/28/2019 8:45:14 AM 0000006b Download of SAVXP failed from server sophosav.vamed.com/.../
6/28/2019 8:07:46 AM 0000006b Download of Sophos Clean failed from server sophosav.vamed.com/.../OPMHMPA
6/27/2019 12:09:26 PM0000006b Download of SAVXP failed from server sophosav.vamed.com/.../
6/27/2019 8:56:20 AM 0000006b Download of Sophos Clean failed from server sophosav.vamed.com/.../OPMHMPA
6/27/2019 8:43:52 AM 0000006b Download of Sophos AutoUpdate failed from server sophosav.vamed.com/.../
6/27/2019 8:32:00 AM 0000006b Download of Sophos Clean failed from server sophosav.vamed.com/.../OPMHMPA
6/25/2019 11:49:05 AM00000000 Updated successfully
6/25/2019 9:36:49 AM 0000006b Download of Sophos Clean failed from server sophosav.vamed.com/.../OPMHMPA

Hello Markus Hartmann,

these are different issues.

Updating failed because no update source has been specified
is an internal issue and has to be resolved by reprotecting.

All the Download failed (three blocks) with subsequent Updated successfully are transient errors, the failure is most of the time for just one component (otherwise you'd get a Could not find a source for updated packages - not to confuse with the no update source).  You're updating over HTTP, aren't you? What is your updating interval? The ALUpdate log on the endpoints has the error details, it could simply be that the server is overloaded.  

the clients pulls the policies in a very short time
after install the default policies are in effect, the endpoint's policy status is Awaiting policy from console - and these should be sent in response to this status message.
The 2.x firewall (up to Windows 7) needed a reboot before it became fully functional, might no longer be necessary with 3.x. Do you indeed see (i.e. the console shows it) non-compliance with the FW policy?

Christian 

Dear Christian,

Thank you for your detailed response.

A) Updating failed because no update source has been specified
is an internal issue and has to be resolved by reprotecting.
>> I will document this in our info for Sophos.
>> This reprotecting caused the FW issues at C)

B) no update source....
>> I will have to look at the devices, once they are back online.
>> Thank you for the details to look at.

C) FW policy
>> actually this happend on 20 Windows 10 devices...! They did not pull the FW policies, after I have reprotected the devices for the AV update.
>> I had to manully do this on most devices, on 2 devices, I even had to "enable primary location" before it was able to get the FW policy update.

Hello Markus Hartmann,

let me add some more details.

Updating failed because no update source has been specified
since when do you use Sophos? I'm asking because this is a rather obscure issue with, as far as I can tell, low incidence (affects less than 0.5% of the endpoints/year). Interesting thing is that the endpoints report the correct update locations that you can even change from the console, it's also correct in iconn.cfg, but when ALUpdate.exe tries to retrieve the values via the COM infrastructure they are empty. Mind you, everything else works.
Latest information (from March) promises it will be fixed in 10.8.5, than planned for May, meanwhile not before Q4.

As said, Download failed is usually transient. And ERROR: Could not find a source for updated packages is most of the time transient as well. This happens when AutoUpdate checks for updates while the endpoint has not yet established a network connection, e.g. when the computer wakes from sleep. 

Firewall policy:
After protecting a computer the policy status should be Awaiting policy from console. This status doesn't change for any policy, just the FW policy, or changes to Differs from policy? Haven't used SCF for quite some time, IIRC it should permit the Sophos processes regardless of the location. But deducing from symptoms is more speculation than troubleshooting.
I understand that this is more or less reproducible and stable, so ... starting with Protect Computers from the console, the computer icon overlay should change to hourglass, down arrow, then change to connected (green). The policy status should be Awaiting policy from console for all policies - but it shouldn't stay long until it changes to Same as policy.  

Wanted to tell you how to proceed or troubleshoot if it doesn't but just got a call that I'm needed elsewhere, won't be back today.

Christian

Hello Markus Hartmann,

to continue where I've left off yesterday.

If you get the Awaiting policy from console the install succeeded and the endpoint is communicating. As said, this status should change after a short while provided the server can connect to the endpoint's port 8194 ("downstream"). Otherwise it requires a message from the endpoint that will arrive sooner or later. As Comply with ... results in the same action as the Awaiting ..., namely sending the policy immediately if the downstream path is available or enqueuing it to supply it in a response, it won't make a difference.

If the endpoint seems stuck in the awaiting check if the downstream path is there (assuming it should). If it's not you can test whether the policies are indeed still enqueued and are supplied and processed as designed by forcing the endpoint to send a message. Simply disable on-access scanning, the console show reflect this change after a few seconds, the endpoint should receive the policies and re-enable on-access.

If there's no change then it might be (as said, I don't use SCF and I have no experience with 3.x on Windows 10) that upon receiving the FW policy the endpoint blocks the connection. While I think that SCF permits the Sophos processes I won't rule out that "something" is not right as you've mentioned enable primary location.  There's a known issue (WINEP-1758) where bluntly or use Windows Firewall instead is suggested as workaround.
Anyway, the Firewall log should tell when it blocks communication. The Router and Agent logs (%ProgramData%\Sophos\Remote Management System\) will show whether policies have been received and status messages could be sent or not.

Last but not least I want to point out that SCF is doomed. 3.x (on Windows 8 and newer) has already lost some functionality (not exactly Sophos' fault), has the mentioned issue on Windows 10, and I wouldn't bet that it will survive all Windows 10 updates and last the full two years.

Christian 

Hello Markus Hartmann,

to continue where I've left off yesterday.

If you get the Awaiting policy from console the install succeeded and the endpoint is communicating. As said, this status should change after a short while provided the server can connect to the endpoint's port 8194 ("downstream"). Otherwise it requires a message from the endpoint that will arrive sooner or later. As Comply with ... results in the same action as the Awaiting ..., namely sending the policy immediately if the downstream path is available or enqueuing it to supply it in a response, it won't make a difference.

If the endpoint seems stuck in the awaiting check if the downstream path is there (assuming it should). If it's not you can test whether the policies are indeed still enqueued and are supplied and processed as designed by forcing the endpoint to send a message. Simply disable on-access scanning, the console show reflect this change after a few seconds, the endpoint should receive the policies and re-enable on-access.

If there's no change then it might be (as said, I don't use SCF and I have no experience with 3.x on Windows 10) that upon receiving the FW policy the endpoint blocks the connection. While I think that SCF permits the Sophos processes I won't rule out that "something" is not right as you've mentioned enable primary location.  There's a known issue (WINEP-1758) where bluntly or use Windows Firewall instead is suggested as workaround.
Anyway, the Firewall log should tell when it blocks communication. The Router and Agent logs (%ProgramData%\Sophos\Remote Management System\) will show whether policies have been received and status messages could be sent or not.

Last but not least I want to point out that SCF is doomed. 3.x (on Windows 8 and newer) has already lost some functionality (not exactly Sophos' fault), has the mentioned issue on Windows 10, and I wouldn't bet that it will survive all Windows 10 updates and last the full two years.

Christian