Sophos Client AV Blocking all connection of workstations

Hello Chamara Wijayawardane,

the logs suggest that this particular endpoint has updated the firewall in the afternoon. Sound the the issue described in SCF blocks traffic until the client is rebooted, if it still applies your users should have noticed yesterday though. Furthermore it should have worked after the reboot.

The ALUpdate log doesn't tell when SCF apparently "forgot" the policy. The endpoints' firewall log should have more information - when it happened and if perhaps there was a preceding error. Is this the first time that it happened? Did it affect all endpoints with SCF?

Christian

Hi Christian,

Thanks for the quick response. yes this is the first time this issue happened and spreed to several workstations (15). i have restarted affected workstations before post this problem.

please check attached firewall logs for further inspection. once the issue is happened workstation appear as disconnect to the Sophos console.

in to this scenario we cant connect to the workstation over remotely. consider we have 20 branch office and more than 650 AV clients, even users can't login to their domain account until put a tick for allow all traffic option in client firewall tab.

Firewall n Sys log.rar

Thanks

Chamara

Hello Chamara,

thanks. Are the logs from the same endpoint? Looks like.
The SCF System log shows 11/15/2017 2:47:54 PM    Firewall successfully configured (primary location) which coincides with an update of SCF. It was still "open" afterwards though as the Firewall log shows. After another 11/15/2017 3:20:46 PM    Firewall successfully configured (primary location) SCF was in Block all activity mode, but there was no update at this time. I don't think SCF would re-configure itself at an arbitrary point in time, it rather looks like it has received a policy (ruling out a local reconfiguration).
Could you show the Agent and Router logs,  in %ProgramData%\Sophos\Remote Management System\3\Agent\Logs\ and ...\Router\Logs\ respectively, from around this time (3:20:46 PM)? Just in case please run SDU (sdugui.exe in %ProgramData%\Sophos\Sophos Anti-Virus\diagnose\) to collect all logs.

Christian

Hello Christian,

please consider all logs belong to same PC and i uploaded logs which you requested for refer ( agent and router logs) around mentioned time frame. today we didn't identify any PC with this kind of issue,

i confirmed didn't deploy any policy or configuration change from Sophos console/ related PC clients at that time period.

Thanks

Chamara

Hello Chamara,

both the Router (15.11.2017 15:20:45 1BA4 I Routing to Agent: id=060C0DF5, origin=Router$DC-IRDAV.EM, dest=Router$07UNIT-5E:180241.Agent, type=EM-SetConfiguration) and the Agent (15.11.2017 15:20:45 19A8 I Received configuration for SCF) log confirm that a firewall policy was received from the management server. In the Agent log 15.11.2017 15:20:45 1A48 I SCF state observer received a status: shows that it was RevID="FactoryDefault", with the mode non-interactive-block.

There was something that looks like an attempt to redeploy Sophos in the early afternoon (around 14:44) which failed as another one (that eventually succeeded) was apparently in progress. And it seems that the endpoint was directed to another management server. Either (if it was already known) it ended up in the wrong group, has been move to a group with the Default policy, or the group had the Default assigned.

BTW: You might want to delete the WeTransfer ...

Christian 

Hello Christian,

You are absolutely correct regarding above suggestion. yes, we have another Sophos management server run by other units for a specific purpose in same domain. We are using manual method for the adding client PCs to console and other server using GPO for adding PCs to their management server. Therefore something wrong with the GP i think.

please can you find IP or host name of other management server, then we can confirm the issue what you mention in above post.

Thank you very much for the support.

Chamara

Hello Chamara,

the "old" one was 10.2.150.245 whereas the "new" mrinit.conf points to 10.2.10.22 (this server advertises, i.e. returns in the IOR response from port 8192, four IIOPs in the order: 192.168.147.1, 192.168.242.1, 10.2.10.22, and 10.2.16.13).

Christian

Thanks Christian, you are correct.

Chamara