Important note about SSL VPN compatibility for 20.0 MR1 with EoL SFOS versions and UTM9 OS. Learn more in the release notes.

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

AD Server Authentication Drops over IPSEC S2S VPN

Hi All,

Recently one of our clients who have a server setup with a Sophos XG210 at their HQ have opened up a new branch that only has desktops and no servers. Machines are connected to a domain and a few of the users from head office have moved to the new branch. We have installed a XG106 and have setup an IPSEC S2S connection using the Sophos guide. 

After speaking to Sophos support they have advised that we do not need to setup the routes as mentioned in https://support.sophos.com/support/s/article/KB-000035830?language=en_US 

We have been since experiencing an issue where things are fine for a few days and then randomly one of the users is unable to access the main DC at HQ, browsing to network shares just hangs, to get around this we can change the IP address on the machine to a new static and things are then fine again but a few days later it will either happen to the same person or a different person. The strange thing is that the same user can still access the terminal server located at HQ and the other servers, they just lose access to the main DC. Also if we connect to the SSL remote VPN everything works fine. 

The setup is:

Site 1: HQ: XG210, Lan 192.168.100.1, Network 192.168.100.0/24, Main DC (192.168.100.5) located at this office

Site 2: Branch: XG106: Lan 192.168.102.1, Network: 192.168.102.0/24 No Servers at this location only domain joined PC's

- Forgot to mention that we have STAS setup aswell.

Thank you in advance to anyone who has any ideas.



This thread was automatically locked due to age.
Parents Reply Children
  • 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?

  • 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