Remote user upload errors

[swany6mm]

So, I'm at a loss here.

First, I'm at work and can't remote into my QNap to get current version, but as of this post (last night really, 8 Aug 2017), I am running latest 4.3. The rest of my server info in my sig is correct.

As for my problem. I THINK, at this point, it's really on the users end. He can VPN (OpenVPN) in with no problems, and he can download files (any size) with no issues. However, he seems to have lost the ability to upload.

He is running Win10 current updates, has AT&T DSL (only option available to him, cable isn't out at his remote location)

He always had a little issue, but was able to upload in the past. It's been a while since he needed to upload anything, so I'm not sure of the exact timing of the failure (I can't trace it to a QNap update or a Win update, etc)

We've tried through Filestation (running latest version) through Edge (latest), Chrome (latest), IE Explorer (latest). We can map drives all day long with no issues and, like with Filestation, can DL without issues, but can't upload via Windows Explorer. I've turned on SMB 3, jumbo set to 9k. I've rebooted the server several times and he his computer. File size doesn't seem to matter. He'll fail on a 9MB, a 150MB, or a 1+GB.

One thing that does strike me as off is the files usually fail in the same spot relative to the file (ie file 1 will always fail at 44% done, file 2 at 20%, 3 at 85%, etc). The one time we did get a failing file to actually succeed, it was perfect on my end (no corruption), so I know his file system/integrity is good (when it did work was right after a reboot of the server and his Win10 machine. Subsequent reboots have not repeated the success).

We have check and rechecked user permissions. The one thing we haven't tried in that area is creating a user on the QNap with the exact user/password that he has on his computer. We didn't go down this path as he can map and download with no problems in Filestation and Windows Explorer with the QNap user credentials. its just that blasted upload.

I'm down to thinking something is wrong with AT&T on his end, or something in OpenVPN is killing packets? I'm grabbing at straws here. Any thoughts/ideas are appreciated

Swany

[Toxic17]

It is most likely fragmentation is taking place since he is using a standard MTU (1492 or 1500) and VPN's require a lower MTU size for fragmentation to be non existent

also are you using UDP or TCP for Openvpn?

UDP just sends and if fragmentation happens there is no resend of lost packets.

TCP is better at this but at a cost of overheads and more processing of data.

google is your friend....

[swany6mm]

Didnt even think about UDP vs TCP. It was running on UDP. I Switched it to TCP, reset the frames to 1500, verified he was on 1500 as well as my router. Reboots all the way around - No luck.

One thing I want to update, when I was confirming his upload rate, I thought it was 5MB up. He's on .5 (half) MB. I could see really slow uploads messing with one large file, but smaller 9MB files or 100MB files?

Anyone have any other thoughts? I'll do a bit more research on the OpenVPN and MTU sizes, but my NAS is only allowing to go as low as 1500

[swany6mm]

Update since last post - I think it's the MTU for my DDNS. Found a simple Windows command (ping -f -l xxxx (mtu pacet size)) and discovered it hates anything over 1472. We'll start doing some manual settings on his end and see how things going. I'll let you know one way or the other

Swany

*EDIT* Doing more research, I've found that once you find your "optimum" MTU, you need to add 28, so we're right back to 1500, so don't think my DDNS is going to be the probem

[swany6mm]

So, still having the same issue and still can't find a resolution. Due to lack of responses, I'm guess not many, if any, are running into an issue like this?

Changing to TCP and playing with MTU didn't make any difference

[immortal]

For UDP try a much lower MTU like 1000
If that helps then experiment with ever increasing values until it breaks again.