AD Server Authentication Drops over IPSEC S2S VPN

Do you use STAS ? 

Hey, yes we do. forgot to mention that. 

Could you check for STAS Quarantine in the Firewall, if it is set to True? 

I have just checked and believe i am looking at the correct setting?

Switch it to No and it should resolve your issues. 

Perfect, thank you. Will monitor for a few days. Thanks so much for your help.

So i guess technically the IP's being used are in this Quarantine? is there a way we can get them unblocked so we can set the machines back to DHCP and not have to worry about a new device connecting and then being blocked because its picked up one of the IP's that was having this issue?

Could you tell me, which version you installed? And this setting was not enabled on the HQ firewall per default, correct? 

we have "Sophos Transparent Authenticaion Suite" Version 2.5.1.0 installed on the server. 

That is the first i have seen of that setting and it was not myself that setup this client with STAS it was one of my colleagues who is no longer with the company, so I am unsure if it was enabled by default. 

However i did enable STAS on the Branch firewall during testing and can see the it was also set to Yes on that aswell. 

Hey, We have had the same issue happen this morning with this setting switched to No. Any other ideas?

Hey, We have had the same issue happen this morning with this setting switched to No. Any other ideas?

You need to get the packet capture and the drop packet capture of this time frame. 

I have just switched on the packet capture for one of the IP's and will send over the logs once the issue happens again. It happened this morning to one of the guys but I have not been in the office to get the packet capture going. 

Could be related to the logoff detection. 

https://support.sophos.com/support/s/article/KB-000035623?language=en_US

Check the steps of the AD Server, if it can actually verify the user logged in via WMI or not. 

So it happened again this morning at around 10:30 which was about 2 hours ago. i logged onto the firewall and checked the packet capture but it had switched itself off, is there a way to keep this on? 

Still need to log into the above which i am booked in tomorrow to have a look at and check.  

Hi Lucar,

Have setup the GP rules as listed in the KB you sent across and i can verify on the local network but i get the below when checking the branch.

Also when I run the below test I get a failure

I also had a look at some of the logs and found the below, if they are any help. This was as they called us saying things had stopped working and we have given them new IP's

DEBUG [0x17ec] 19/04/2022 10:23:47 : dca_eventlog: userinfo enqueued to dca processor
DEBUG [0x17ec] 19/04/2022 10:23:47 : dca_eventlog: got Kerberos authentication event
MSG [0x17ec] 19/04/2022 10:23:47 : init_userinfo_kerberos: UserName: USER1
MSG [0x17ec] 19/04/2022 10:23:47 : init_userinfo_kerberos: DomainName: *******.LOCAL
MSG [0x17ec] 19/04/2022 10:23:47 : init_userinfo_kerberos: IPv6 WorkstationIP: :
MSG [0x17ec] 19/04/2022 10:23:47 : init_userinfo_kerberos: IPv4 WorkstationIP: 192.168.102.179
DEBUG [0x17ec] 19/04/2022 10:23:47 : init_userinfo_common: Event ID: 4768
DEBUG [0x17ec] 19/04/2022 10:23:47 : init_userinfo_common: EventType: AuditSuccess
DEBUG [0x17ec] 19/04/2022 10:23:47 : init_userinfo_common: CreateTime: 1650327826
DEBUG [0x17ec] 19/04/2022 10:23:47 : init_userinfo_common: ExpireTime: 1650328431
DEBUG [0x17ec] 19/04/2022 10:23:47 : init_userinfo_common: LogonType: 2
DEBUG [0x17ec] 19/04/2022 10:23:47 : dca_eventlog: userinfo enqueued to dca processor
DEBUG [0x17ec] 19/04/2022 10:23:52 : dca_eventlog: got Kerberos authentication event
MSG [0x17ec] 19/04/2022 10:23:52 : init_userinfo_kerberos: UserName: USER2
MSG [0x17ec] 19/04/2022 10:23:52 : init_userinfo_kerberos: DomainName: ********.local
MSG [0x17ec] 19/04/2022 10:23:52 : init_userinfo_kerberos: IPv6 WorkstationIP: :
MSG [0x17ec] 19/04/2022 10:23:52 : init_userinfo_kerberos: IPv4 WorkstationIP: 192.168.102.18
DEBUG [0x17ec] 19/04/2022 10:23:52 : init_userinfo_common: Event ID: 4768
DEBUG [0x17ec] 19/04/2022 10:23:52 : init_userinfo_common: EventType: AuditSuccess
DEBUG [0x17ec] 19/04/2022 10:23:52 : init_userinfo_common: CreateTime: 1650327831
DEBUG [0x17ec] 19/04/2022 10:23:52 : init_userinfo_common: ExpireTime: 1650328436
DEBUG [0x17ec] 19/04/2022 10:23:52 : init_userinfo_common: LogonType: 2
DEBUG [0x17ec] 19/04/2022 10:23:52 : dca_eventlog: userinfo enqueued to dca processor
DEBUG [0x17ec] 19/04/2022 10:23:52 : dca_eventlog: got Kerberos authentication event

You should verify, what WMI is blocked to those nodes. Is it a Firewall issue (blocked) or a Windows Client issue. Check the packet captures on all ends. 

Hi Luca,

I never did manage to work out what was blocking it, the WMI checks were successful from the Windows WMI checker (WBEMTEST) and the WMI verification check in STAS and i could see live users in STAS etc. This was after I had to put a command in the console on the branch to allow STAS = system auth cta vpnzonenetwork add source-network 192.168.102.0 netmask 255.255.255.0

So even after the STAS connections were live and connecting we still were presented with the same issue. 

A test i had not done but have now is disable the IPSEC site to site and setup an SSL Site to site and this started working straight away.

We had an IP address 192.168.102.30 which this morning could not access shares / server etc and the normal changing the IP got around the issue, i set a test laptop to the same address and it was still the same, i then disabled IPSEC site to site and then started the SSL Site to Site and the machine still on 192.168.102.30 sprung to life and has been solid since. 

So something is up with the IPSEC Site to site connection but for the life of me i cant work out what is wrong.

Thanks for your help but i am happy to leave the SSL in place and see how that goes.