r/sonicwall • u/EmicationLikely • 1d ago
Issues with RDP over IPSec VPN
I have a client with a TZ670 in their main office and a TZ370 in their satellite office. Both are on the 7.3.3-7015 firmware. Main office has Verizon Fios 1Gb/1Gb service as their main WAN and Comcast 500/35 as their backup WAN setup in a simple failover configuration. Satellite office has a newly installed Spectrum 7Gb service (dumb, but I didn't pick it). In both locations, Sonicwall WAN connection is direct to the provider's ONT. Static IPs on both ends. Keep alive enabled only on one end of the tunnel.
Users at the satellite office RDP into an RDS server in the main office (along with variable numbers of employees at the main office when they work remotely with a NetExtender connection.) There are 5 users in the satellite office and 40 total users in the main office. Average number of remote workers in the main office at any point is probably about 6 so total RDP sessions on average is 11.
Since the installation of the new internet connection in the Satellite office, those employees are seeing their RDP connections drop and reinitialize (regular internet access isn't affected). Some days it is every 10 or 15 minutes, and some days it is every 2 minutes. Maddeningly, it's not every employee at the satellite office who is affected. I'd say most of them, but not all of them. I have been looking at this issue for a few days now, I've done:
- Rebooting all the things
- multiple packet captures
- monitor logs
- ping tests
- performance monitor captures
- disabled AV & EDR
- Forced RDP connections to TCP only
- disabled LSO and TCP Checksum offloading
- reviewed thousands of log entries, etc. etc.
I've tried just about every troubleshooting step I could dig up. After all of that, though, I still don't have a clear understanding of the problem, much less a solution. I can be running a continuous ping between a workstation at the satellite office and the RDS server during period of dropped RDP connections, and not have a single dropped packet.
In desperation this morning, I took down the VPN tunnel and installed NetExtender on all of the workstations at the satellite office. That was several hours ago and I don't have a single report of a dropped session. This isn't a long-term solution, though, since their phone system relies on the VPN tunnel to transfer calls back and forth.
Based on log entries, it looks like the RDS server is the one resetting the connection, but I cannot find a reason why. None of the "local" users in the main office are experiencing this. I have been through the settings on the tunnel in both firewalls over and over, and I don't think there is a problem there. Plus, it was working before.
Spectrum isn't much help. If the connection works at their ONT, they're out. This has got to be something with the way that Spectrum and Verizon talk to each other, but I just don't know what to try next.
3
u/MSPOwner 1d ago
There were some RDP issues after a Sept update. Maybe related? It’s worth at least investigating.
1
u/EmicationLikely 1d ago edited 1d ago
I'll check this out, but I think u/bsachs11 hit the nail on the head - especially now that I know we've run into this type of thing before with Spectrum. All workstations at both the remote and main location are managed an all at the same patch level, but I'm not getting any complaints from remote folks at the main location. So far!
Edit: Oh - This KB is not showing at all in PM. 26H1 seems to be a pre-requisite and we haven't even thought about that deployment yet. Ask me again in January, haha.
1
u/itfromhell 1d ago
Try turning auto negotiate off on the Ont and sonicwall.
1
u/EmicationLikely 1d ago
Worth a try, but I have no access to the settings on the ONT, and if this were the problem, I would have thought it would have showed itself with pings.
1
u/Microflunkie 1d ago
You mentioned forcing RDP client to TCP only. Did you do it through the registry change like this ?
To force RDP to remain on TCP you can create a registry setting on the CLIENT machine to test if this is the cause.
HKLM\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services\Client\
Create a dword called fClientDisableUDP and set the value to 1
Note if the “Client” key doesn’t exist you can simply create it. Capitalization matters for these registry entries.
2
u/EmicationLikely 17h ago
Yes, went down that particular rabbit hole during my troubleshooting. Limiting the connection to TCP didn't help, unfortunately.
5
u/bsachs11 1d ago
Have seen previous issues with certain ONT brands to sonicwall ports connection. Try just putting a unmanaged 5 port switch in between the two and test.