Over the past few weeks, I’ve been contacted by multiple customers experiencing the same frustrating issue. Applications and SSMS sessions that had been rock-solid for years suddenly started throwing errors when connecting over VPN:
- Msg 10054: “An existing connection was forcibly closed by the remote host.”
- “Connection Failure (status code = 3000, [Microsoft][ODBC Driver 17 for SQL Server] The connection is broken and recovery is not possible…”
Naturally, everyone assumed it was a SQL Server problem – which is why they called me.
On the server side, though, everything looked normal. The client would connect, run a query, and then the connection would drop. Basic network checks (firewall rules, logins, port 1433) all passed. So I started digging deeper with the customer and my network engineer.
Finding the Real Culprit
The queries returning larger result sets were the ones failing. I had them test with a simple SELECT TOP 1 on a single column, it worked fine. Then we gradually added more columns: 4, 8, 20… and boom, same error again. Back it off a bit and it succeeded. This pointed straight to packet size and the amount of data being returned.
Nothing had changed on the network (or so we thought), so I asked the client to adjust the packet size in their SSMS connection.
In older versions of SSMS, you’d go to Options > Additional Connection Parameters and add something like:
packet size=1300
In newer versions, it’s even easier: you’d go to Advanced – look for Packet Size and set it to a lower value (e.g., 1300-1400).
Once they made that change and reconnected, the queries started working – even the original with the large result set. That confirmed we were dealing with an MTU mismatch.
The Fix (and the Root Cause)
One customer simply set their VPN router interface MTU to 1300 and the problem disappeared. Another had to allow ICMP Type 3 Code 4 packets (“Fragmentation Needed”) that were being blocked by their firewall.
Here’s what’s happening:
- Standard Ethernet MTU is 1500 bytes.
- VPN encapsulation adds overhead, typically dropping the effective MTU to 1350 – 1400 bytes.
- SQL Server (and client drivers like SSMS, ODBC, and .NET) default to a 4096 – byte network packet size.
- When Path MTU Discovery (PMTUD) works, everything negotiates nicely.
- When PMTUD fails – which is extremely common on VPNs because firewalls often block the necessary ICMP messages – large packets get silently dropped. You see intermittent disconnects, “Malformed TDS” errors, timeouts, or partial results.
Recent Windows cumulative updates (late 2025 into early 2026) included networking stack improvements and stricter security defaults around ICMP handling. These changes didn’t “break” anything on purpose, they simply made the environment less tolerant of marginal MTU configurations that had previously been working by luck.
Key Takeaways
- Don’t assume it’s always a SQL Server problem. Yes we know that “DBA = Default Blame Acceptor”, and we will help troubleshoot, however, Network-related connection drops are often MTU or packet-size related, especially over VPNs.
- Test with smaller result sets to isolate the issue.
- Adjust the client-side Packet Size as a quick workaround.
- Fix the underlying MTU on the VPN/router and ensure ICMP Type 3/Code 4 messages are allowed for proper PMTUD.
- Consider lowering the server-side network packet size configuration only if you have a widespread need (and test thoroughly).
This is a classic example of something that “just worked” until the environment got stricter. If you’re seeing similar symptoms with VPN users, start with packet size and MTU, it solves the issue more often than you’d think.
Have you run into this lately? Drop your experiences in the comments.
The post VPN + SQL Server Connections: Why Long-Working Setups Suddenly Fail with Msg 10054 and “Connection Broken” appeared first on Tim Radney.