erp software unusable slow via VPN?
Posted by Reasonable_Host_5004@reddit | sysadmin | View on Reddit | 24 comments
Hi everyone,
we do have an erp system which uses a microsoft sql server as database. Everything is running locally on our hypervisor. When accessing the erp system (via their client software) from a vpn tunnel the software is unusable slow.
The erp system provider told us we need to set up a remote computer which people from vpn can connect to and run the erp client on this machine on the lan.
In the company I did work before the erp system was much bigger and used heavily compared to the erp system in the current company I am working for. We didn't had any issues via vpn on this software back then, tough the database was an oracle one.
I am really not a database expert but is this a common issue with software that relies on ms sql? Or is the database from the current erp system set up really bad?
Running a seperate virtual machine just for connecting to the erp system seems very strange to me in year 2026...
kreload@reddit
“I am really not a database expert but is this a common issue with software that relies on ms sql?”
No, it’s not. Some companies thats sells erp’s are idiots or have stupid programmers that insteed of doing the data parsing on the server, they download gigabytes of data locally, on user computers and do the parsing there. Probably if you monitor the network card of the server or user computers you will see gigabytes of data transferred after each sql query.
artifex78@reddit
Well, you are really really wrong. Old legacy erp software like Sage or Dynamics NAV use the classic client/server model where the client runs the business logic and the server just stores the data (aka database server). The magic IS happening on the client and that's by design.
One simple request can cause hundreds of MB of data transfer and these are NOT bad queries. And because of latency locking takes longer and can cause serious blocking issues for everyone.
These programs are not optimised for VPN/WAN and do not throttle if bandwidth is low.
The modern versions are web-based and 3-tier. They are compatible with WAN/VPN scenarios.
statikuz@reddit
Oh lord this hurts. We use Sage 300 and to open like... one work order, it would download hundreds of MB. Close that one, open another, the same several hundred MB. So yeah, definitely did not work on a VPN.
artifex78@reddit
If the erp client directly communicates with the database server, a VPN won't do the trick because of latency and especially bandwidth.
The software might be designed with LAN in mind. In this case a rds server (farm) is the right choice.
Modern erp systems use web technologies for their clients and APIs and a middleware (application server) which does all the hard work and speaks with the database server. The clients only send inputs to the app server (I want x) and receive a result set.
Fantastic-Shirt6037@reddit
Actually, I wouldn’t think we can assume that rds would work. There are medical imaging and practical management software that is specifically unsupported in rds environments - so I wouldn’t say that so confidently.
The vendor is stating they must use a remote pc, they will be the ones to state whether the software is supported in an RDS environment.
To answer the OPs question yes a lot of software still sucks in the medical / medical adjacent field.
artifex78@reddit
While you are not wrong and hence why you should always work with the vendor/check the system requirements, in this case that's what the vendor basically told OP. It's up to OP to clarify with their vendor.
t4pnb@reddit
This exactly. It's 2026, if the client is still directly talking to the sql server it's old legacy shit software and should be replaced asap.
derfmcdoogal@reddit
So... What version of Sage software is it?
OregonTechHead@reddit
Sage 100 no doubt
derfmcdoogal@reddit
*shudder* I remember those days...
kg7qin@reddit
It is definitely an MTU problem, but a lot of sysadmins have only a basic or surface level understanding of networking, which is unfortunate.
The easy fix, like others have said, is to either setup a system VPN users can remote into or publish the ERP as a remote app so they only need to connect and launch it.
I've seen this problem with Infor's Visual.
OregonTechHead@reddit
Possibly, but I'm guessing it's more of a software/ERP problem. I'd bet this is Sage 100. Nothing you can do is going to fix that pile of garbage.
Best solution is to setup a RemoteApp server. But that brings into a whole host of other things to consider.
FactMuch6855@reddit
The original question and some of the responses, especially the first one, are AI.
thewunderbar@reddit
Not everything that's not written in perfect sentence structure is AI.
The only thing worse than AI slop are people who just drive by saying "lol AI"
ProfessorWorried626@reddit
No AI here.
Reasonable_Host_5004@reddit (OP)
Since I am not an english native speaker you can surely find several grammar mistakes in my original question. My original question was written by me.
natefrogg1@reddit
For our legacy ERP system it runs like crap over a VPN, most of them were never made with running over a VPN in the plan. Our users remote into a virtual or physical desktop system at the same location that the ERP system lives, they run the software that way. Splashtop is a decent remote access tool to make this happen, there are quite a few others
Curious201@reddit
if the ERP client talks directly to the database, the VPN is probably only exposing the real problem: a chatty client/server design that was fine on a LAN and terrible over latency. i would not treat this as “VPN is slow” until you measure where the time is going. run the ERP client on the same LAN as the database, then over VPN, then from an RDS/terminal server sitting next to the database. if RDS feels normal, the answer is likely to publish the app through RDS/RemoteApp or move users onto a hosted desktop near the SQL server, not keep tuning the VPN forever. also check whether the client is pulling large datasets, using mapped drives, doing name resolution weirdly, or hitting SMB shares for reports/templates. a separate VM just to run the ERP client is not strange in 2026 if the software was never designed for WAN use.
caspianjvc@reddit
Pretty standard for any direct connection to SQL. As others have said check MTU by using ping. Could also be that.
Step 1: Run the Command for Your OS
Open your terminal or command prompt and test a standard maximum payload size of 1472 bytes (which equals a 1500 MTU once headers are added).
Windows
Command: ping 8.8.8.8 -f -l 1472
Linux
Command: ping 8.8.8.8 -M do -s 1472
macOS
Command: ping -D -s 1472 8.8.8.8
🔍 Step 2: Interpret the Results
✅ Scenario A: The Ping is Successful
What it means: Your MTU is perfectly fine at the standard size of 1500.
Action: You do not need to change anything!
❌ Scenario B: You get a "Packet needs to be fragmented" error
What it means: Your MTU is set too high for your specific network connection.
Action: You need to find your actual maximum MTU.
🛠️ Step 3: How to Find Your Correct MTU (If it Failed)
If the test above failed, you need to lower the size number (1472) by increments of 10 or 20 until the ping succeeds.
Drop the size to 1460 and test again.
If that fails, drop to 1450, and so on, until you get a successful reply.
Once it succeeds, increase the number by 1 at a time until you find the absolute highest number that works without failing.
Take that maximum working number and add 28 to it (this accounts for the 20-byte IP header and 8-byte ICMP header).
The resulting number is the exact MTU size you should configure in your router or network adapter settings!
To get more tailored advice:
Tell me your operating system(Windows, Mac, or Linux).
Share the exact error messageor results you got from the test.
sgocken@reddit
If you find fragmenting you can use MSS Clamping on the VPN to deal with the smaller MTU.
Procat@reddit
For a Microsoft Navision / Business Central system, it was a thing for the old versions that latency between client and the SQL would really ruin your user experience. It's less so with the "newer" RTC client since the service tier the client communications with, would usually be closer to the SQL server network-wiese. I expect this could be an issue with other ERP systems.
Defconx19@reddit
Depends on the ERP. Typically you'd use remote app or a remote desktop when you risk data corruption on a dropped connection. Shouldn't factor into speed though. What's the ERP?
Moontoya@reddit
vpn tunnels can be limited bandwidth - 5-6mbit each way (depending on vpn host/client/software)
also - whats their home ip range vs "work" range, a lot of home routers are on 192.168.0.x /24s - which is a pain in the ass supporting clients who have that internal range (SMB's - MSP support). thanks to using the same company provided routers (under business class !).
is the ERP "host" machine slow to run the queries when youre physically in front of it?
If so, its the PC/setup - if its fast in person but slow via remote desktop/vpn, then its that side of things.
ProfessorWorried626@reddit
Most of those issues are mtu related.