User is having issues opening MS Office files over SSL VPN

VPN
1

Hello Everyone, I hope you’re all having a good week so far.

​

I recently got a new remote user setup with a Surface Pro 9 running Windows 11 Pro while they were in the office for orientation - once setup and situated, everything was working fine, including access to network resources over VPN.

​

Now that the user is back home, a pretty major issue has cropped up - When he’s connected via NetExtender, he cannot open MS Office files (Excel, Word, or PowerPoint) that are stored on our network drives. He is not having issues opening files of other types like PDF, JPG, MP4, TXT, etc.

​

While continuous pinging one of our internal resources, I can see the pings start to drop off once the user attempts to open an Office file. The office app will then hang, and eventually file explorer crashes and restarts. The connection to our internal systems then stops working until NetExtender is disconnected, then reconnected.

​

I logged into his account on my test laptop in the office, connected it to my hotspot, then connected with NetExtender - no issues opening any of these files.

​

I had the user go to another one of his properties and try from there - No issues opening these files and the VPN connection stays up during the whole process.

​

I think I can rule out permissions issues and local NetExtender client issues, as well as SSL VPN configuration issues.

​

The user’s home network is Verizon FIOS; the user’s second property where he didn’t have any issues is also running FIOS. I thought that this could maybe be an issue with his local IP Schema, but both locations were setup the same way, so I do not think that is the cause (and if it was, I would think he would have trouble connecting to the VPN all together.)

​

I had the user reboot his home router, which had no effect. I haven’t checked out the local router settings, as I’d rather not touch any of those if I can avoid it due to the user being hours away and having no networking knowledge in case something breaks. I’m currently pretty much at a loss for what could be causing this.

​

After thinking about it some more, I will be checking on Office Trust Center settings as well as Windows Defender Firewall, but do not expect those are to blame.

​

Has anyone experienced this issue before? I have plenty of other users with the same setup who have not ever had an issue like this, but most of them are running Comcast in their homes. Could this be a weird issue with the way Verizon routes traffic?

​

I’d be greatly appreciative of any suggestions or help y’all might be able to give me.

​

Thanks!

2

We have seen this with people who have bad ISP connections before. SMB is pretty demanding and latency-sensitive over VPN for some reason. We have a sonicwall unit that is like overspecced 10x what our requirements would be, and it always happens on the people that are out in the boonies either on line of sight internet or really old dsl.

Login to their PC remotely, start an SMB transfer of any kind, and watch the ping shoot up dramatically to determine it’s the same problem. The only thing that solved it for one of our users who had the most problems with it was to call his ISP and complain till they came by and updated the crap old hardware and wiring they had to his house.

Also, never mess with your user’s home router settings, you don’t know what their contract is with their ISP. Tell them to call their ISP and complain and elevate to higher level tech support. It’s almost guaranteed something wrong with ISP side of things, there’s some jitter.

3

I have seen similar behaviour when you are using SMB jumbo frames. SMB will increase TCP window sizeto acheive greater throughput and when it hits your WAN MTU, the TCP window size continues increasing packet size, bogging down any and all buffers with fragmented packets. Try disabling SMB jumbo frames on your server. This should increase general VPN performance for all VPN clients - but NOT for your other LAN clients, as jumbo frames was designed for 10GE traffic optimization. So keep the VPN clients on a separate interface.
MS says something like this will do the trick (if i’m rigtht, that is) :

# Disable SMB-LargeMTU
Set-SmbClientConfiguration -EnableLargeMtu $false