Achieving Domain Controller via SSL VPN is impossible

Hi to all of you.

I have two Sophos XGS 136 in HA (active / passive); the firmware version is SFOS 18.5.3 MR-3-Build408.

IT infrastructure consists on:

  • 1 Windows Server 2019 Host with Hyper-V role
  • n.2 VM Windows Server 2019: both are DC and one of them has file server Role
  • Many Windows 10 Pro clients

All servers (Host and VM) and clients are on the same subnet


I have configured user authentication via active directory on Sophos XG; users access via VPN SSL using them AD credentials and they are able to reach all the devices on the network (PC clients, NAS, networks printers, access point, or the Hyper-V Host server), but not the Domain controllers VM!

On the firewall, Active Directory Server authentication was originally set with "Plaintext" connection security, but in this moment is set with SSL/TLS connection security (and the Test connection works). 

There's no way to reach DCs: ping, rdp session, shares browsing on file server, etc always fail, but If I make the same tests to the Host Server, they perfectly work.

DCs are not reachable also if I try to connect using SSL VPN local user of the Sophos XG

If Host Server and VMs are on the same subnet (10.0.0.0/24), can the problem be a bad traffic rules configuration?

PS: To exclude that it is a Hyper-V problem, I installed a Windows 10 VM on the Hyper-V Host server and It's perfectly reached from SSL VPN user
PPS: Having a Qnap NAS at my disposal, I enabled OpenVPN server on it; in this case SSL VPN (qnap) users can perfectly reach DCs servers. 

Can you help me to solve this big problem? Thanks for your support!



Edited TAGs
[edited by: emmosophos at 6:11 PM (GMT -7) on 17 Jun 2022]
Parents
  • Broadcast Domains (Same subnet) traffic is likely be reachable directly. That means, the firewall is not involved. 

    The client from 10.0.0.10 will send directly the traffic to 10.0.0.1. The firewall will never see this traffic. If the SSLVPN is not working as well, it is likely a network problem within your hyper-v / Server. 

    __________________________________________________________________________________________________________________

  • The problem is only from SSL VPN. SSL VPN clients are not on the subnet 10.0.0.0/24, they are on 10.81.234.0/24.
    No problems tryng to access the DCs from a PC client inside the network or accessing from outside using Qnap NAS SSL VPN instead of Sophos SSL VPN.

  • Hello,

    You should do a tcpdump on the traffic arriving from the SSL VPN client, first to confirm the traffic directed to the DCs is actually making it to the tunnel, then do another TCPdump on the Interface where the traffic is meant to exit (Interface where the DC connects to) see if the XG is sending the traffic out, if you see this is correct and don't see a reply back from the DC most likely your Hypervisor or VM is doing something with the traffic, most likely might be the Local Firewall of the DCs blocking traffic not coming from the same subnet.

    Regards,


     
    Emmanuel (EmmoSophos)
    Community Support Engineer | Sophos Technical Support
    Sophos Support VideosProduct Documentation  |  @SophosSupport  | Sign up for SMS Alerts
    If a post solves your question use the 'Verify Answer' link.
  • Thanks for your support! Today I will try to use TCPdump (I have never used it before).
    However I want to inform you that I have already tried:
    1. turn off DC's firewall and antivirus -> nothing has changed
    2. install a Windows 10 test VM on the same Hyper-V host -> all services work (ping, rdp, shared browsing)
    3. Setup OpenVPN server on Qnap NAS -> DC servers are perfectly reachable from SSL VPN on Qnap

  • emmosophos said:

    Hello,

    You should do a tcpdump on the traffic arriving from the SSL VPN client, first to confirm the traffic directed to the DCs is actually making it to the tunnel, then do another TCPdump on the Interface where the traffic is meant to exit (Interface where the DC connects to) see if the XG is sending the traffic out, if you see this is correct and don't see a reply back from the DC most likely your Hypervisor or VM is doing something with the traffic, most likely might be the Local Firewall of the DCs blocking traffic not coming from the same subnet.

    Regards,

    I connected using SSL VPN, I launched tcpdump on the firewall, and I tried to connect to the DC server via RDP

    This is the TCPDUMP to the Firewall Lan IP  --> www.dropbox.com/.../dump_lanfire.pcap

    This is the TCPDUMP to the client connected via SSL VPN  --> www.dropbox.com/.../dumpvpncli.pcap

    This is the TCPDUMP to the DC Server  --> https://www.dropbox.com/s/3ip4zg9j8dvcqh9/dump_dcsrv.pcap?dl=0

    I'm not able to read them :-( Could you please analyze them for me?

    I also noticed that using the command pscp.exe -scp admin@10.0.0.254:/tmp/data/dumpvpncli.pcap c:/pscp I got: FATAL ERROR Network error: Connection timed out The strange thing is that that I was perfectly able to ping the firewall lan ip (10.0.0.254) or open its administration page.

    In order to download the pcap files, I had to connect with the VPN of the Qnap NAS!. 

  • Hello,

    Please add the files a ZIP file an upload directly into the thread, I can't open external links.

    Insert >> Image/Video/File >> Upload >> A new window will open >> Search your file >>  Open >> OK

    Regards,


     
    Emmanuel (EmmoSophos)
    Community Support Engineer | Sophos Technical Support
    Sophos Support VideosProduct Documentation  |  @SophosSupport  | Sign up for SMS Alerts
    If a post solves your question use the 'Verify Answer' link.
Reply Children
  • Hi Emmanuel. So sorry for this delay, but I had some personal problem..
    I uploaded the ZIP file. Thank you very much!0243.tcpdump.zip

  • A quick peek at your "dumpvpncli" pcap shows what I assume would be your DCs at 10.0.0.201 and 10.0.0.202 repeatedly doing an ARP request for 10.81.234.6. This leads me to believe that the traffic from the host at 10.81.234.6 on the SSL VPN is indeed reaching the DC but it appears the DCs do not know how to route back to the 10.81.234.0 network. I wouldn't expect to see an ARP from 10.0.0.201 for 10.81.234.6. Since they arent in the same subnet the proper response would be for the DC to look into its routing table first for the 10.81.234.0 network and then find the next hop and ARP for that IP if it wasnt already in the ARP table. I wonder if your subnet setting on the DC are correct? Is the NIC setup as IP - 10.0.0.201, Subnet 255.255.255.0 and GW 10.0.0.254? Right now the DCs think 10.81.234.6 resides inside its subnet so it doesn't send the traffic to its default gateway (the Sophos). 

  • Thanks, thanks thanks!!! It's incredible, I don't know why, but both the DC servers were using the subnet mask 255.0.0.0 instead of 255.255.255.0! I'm sure that in the past they were using the subnet mask 255.255.255.0, so the only thing I can immagine, is that a NIC driver's update has bring back the subnet mask configuration to the default value for the subnet 10.0.0.0.
    Remember that if you come to Rome, you will be my guest for a nice pizza!