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

Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 16 replies
  • Subscribers 40 subscribers
  • Views 2551 views
  • Users 0 members are here
Options
Suggested
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

Luke Jenions

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
  • 0

    Do you use STAS ? 

    __________________________________________________________________________________________________________________

  • 0 in reply to LuCar Toni

    Hey, yes we do. forgot to mention that. 

  • 0 in reply to Luke Jenions

    Switch it to No and it should resolve your issues. 

    __________________________________________________________________________________________________________________

  • 0 in reply to LuCar Toni

    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?

  • 0 in reply to Luke Jenions

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

    __________________________________________________________________________________________________________________

  • 0 in reply to LuCar Toni

    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. 

  • 0 in reply to LuCar Toni

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

  • 0 in reply to Luke Jenions

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

    __________________________________________________________________________________________________________________

  • 0 in reply to LuCar Toni

    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. 

  • 0 in reply to Luke Jenions

    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. 

    __________________________________________________________________________________________________________________

  • 0 in reply to LuCar Toni

    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.  

  • 0 in reply to LuCar Toni

    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

Reply
  • 0 in reply to LuCar Toni

    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

Children
  • 0 in reply to Luke Jenions

    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. 

    __________________________________________________________________________________________________________________

  • 0 in reply to LuCar Toni

    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. 

Unfiltered HTML