Sophos Central Endpoint and SEC: Computers fail/hang on boot after the Microsoft Windows April 9, 2019 update. Please follow knowledge base article 133945
Learn about the Benefits of Multi-Factor Authentication (MFA). Turn your MFA on now!
We'd love to hear about it! Click here to go to the product suggestion community
SG230 UTM 9.510-5
I have currently have 3 RED 15s deployed with standard-split tunnels that are all functioning properly. They are used for server file access and RDP.
I recently deployed a 4th RED 15 with absolutely identical configs to the other three. The only one difference is that the remote computer (behind RED) is not a domain computer. The user can access the server files and map a drive but cannot connect to their domain desktop via RDP.
Using nslookup from the remote (non-domain) computer, the domain computer is identified with it's name/IP, but pinging the domain computer name and IP fail. RDP fails with "cannot find computer on this network...". Sophos software VPN client works perfectly (but dreadfully slow).
I tried both the DNS name and IP address in RDP but get the same result.
Is this related to non-domain->domain authentication or could there be an underlying DNS issue I am missing?
This feels like a problem with the configuration of the domain desktop, Tom, but you might want to do #1 in Rulz to be sure.
If the UTM isn't blocking anything, this might be a better question for a Windows forum. Still, there are a few Windows gurus here that probably can tell you exactly what to do.
Cheers - Bob
In reply to BAlfson:
Thanks for the thoughts Bob. I had already checked logs & everything is clean. UTM not blocking anything and gives the RED an IP in DHCP. Your suggestion to look in Windows made me realize that the non-domain machine is a Surface/Win 10 while the domain system is an older tower with Win7 Pro. Shouldn't normally be an issue but...
In reply to TomMorgan:
So as not to leave this hanging:
After checking UTM & Windows settings, server permissions (ad nauseam) and redeploying the RED 2 more times, it turned out to be a bad RED. Acknowledged by Sophos & RMA'd.
Just in case, have you checked that the users have permissions to RDP to the non-domain workstation?
In reply to badrobot:
Yes thank you. The user/employee is connecting FROM his non-domain box at home, through a RED, TO his domain box at work. So he already had permissions logging in as himself in RDP. In fact, he could RDP successfully using the UTM provided software VPN, but not through the RED. Sophos confirmed that something in the RED was disallowing (or not finding) the network device.
This issue was not resolved with my last post since, unknown to me, the employee was still using the Sophos software VPN after I deployed the new RED. Upon discovery of that, I found that the new RED was still unable to make the RDP connection.
With the help of Sophos support, it was found that the remote computer was not able to respond back to the RED network. The solution?? Add a route to the remote computer:
route -p ADD [RED subnet] MASK [RED netmask] [remote network gateway]
route -p ADD 192.168.10.0 MASK 255.255.255.0 192.168.50.1
BOOM! Instant connection to RDP.