Newly OpenVPN connected Windows file share client crashing on file operations (drag/drop/copy/move)

ADFHAU

Hi folks,

I have a router running AsusWRT Merlin with OpenVPN 2.4.6, and a windows 10 notebook machine running OpenVPN I downloaded only a week or so ago (I'm not infront of the client machine right now). I'm wondering if I've borked something up, or it's something other than the VPN causing the problems? I tried the router's TUN setting where it created an adjacent network and routing and couldn't get that to work on the windows client, so then created a TAP network, and after a slight tweak to the autogenerated client config, managed to get the client connected to the vpn server and able to communicate with the remote windows file server..

The windows client is accessing the server via a UNC with a static IP (Eg \\a.b.c.d\sharename) and is assigned an IP in the same /24 as the windows file server.

I didn't go with the completely default options, as I wanted to make sure the traffic was encrypted, so followed some guides as best I could to select appropriate options - but maybe I borked something?

I opted for certificate and username/password authentication.

Am I missing something? Any rookie mistakes? Basically, the user is able to see files on the remote windows file share, open them, but if they try and drag and drop some files, they experience crashes and explorer hangs.

# Automatically generated configuration
daemon ovpn-server1
server-bridge
push "route 0.0.0.0 255.255.255.255 net_gateway"
proto udp
port MYPORT
dev tap21
ncp-ciphers AES-256-GCM:AES-256-CBC:AES-128-CBC
auth SHA256
compress
keepalive 15 60
verb 3
duplicate-cn
tls-crypt static.key
plugin /usr/lib/openvpn-plugin-auth-pam.so openvpn
ca ca.crt
dh dh.pem
cert server.crt
key server.key
status-version 2
status status 5

# Custom Configuration
cipher AES-256-GCM

client
dev tap
# Windows needs the TAP-Win32 adapter name
# from the Network Connections panel
# if you have more than one.
;dev-node MyTap
proto-force udp
remote MYIP MYPORT
float
cipher AES-256-GCM
ncp-ciphers AES-256-GCM:AES-256-CBC:AES-128-CBC
auth SHA256
compress
keepalive 15 60
auth-user-pass
remote-cert-tls server
<ca>
-----BEGIN CERTIFICATE-----
REDACTED
-----END CERTIFICATE-----
</ca>
<cert>
-----BEGIN CERTIFICATE-----
REDACTED
-----END CERTIFICATE-----
</cert>
<key>
-----BEGIN PRIVATE KEY-----
REDACTED
-----END PRIVATE KEY-----
</key>
<tls-crypt>
-----BEGIN OpenVPN Static key V1-----
-----END OpenVPN Static key V1-----
</tls-crypt>
resolv-retry infinite
nobind

TinCanTech

ADFHAU wrote if they try and drag and drop some files, they experience crashes and explorer hangs.

Crashes in what ? -- I presume openvpn does not crash ..

ADFHAU

I should have been more specific, sorry.. I was doing a bit of a braindump 🙂

You are correct, OpenVPN itself does not appear to be crashing at this point, it's Windows Explorer that's crashing.

Brand new, out of the box Thinkpad T480 running Windows 10 Pro with the basic set of apps that Lenovo bundles (including office)... other software added to the notebook besides OpenVPN is a GDS client which also has a proprietary VPN of its own (only for the GDS, not for other traffic). I got the user to sign into the GDS and OpenVPN at the same time, and then quickly browse the UNC successfully, and confirm that the GDS was operational.

Other users on the same LAN as the Windows server, running the same GDS, have no issues accessing the Windows server, so I'm looking at OpenVPN as the new thing in the mix initially. I understand I may need to collect more information, but wanted to know if anyone else had noticed this explorer crashing behaviour with an OpenVPN TAP configuration before... or if in trying to opt for some strong encryption/authentication, I'd done something stupid in the OpenVPN configuration?

I did wonder if, perhaps, there was some timeout kicking in on the OpenVPN session and perhaps I needed to set a "keepalive" somewhere (I know windows can get shirty if a CIFS/SMB session changes its IP mid-way, and the user could be leaving the link idle for awhile). I did note on initially launching the VPN, that windows didn't prompt "Is this a public or private network connection?" as it does usually when discovering a new network.

ADFHAU

I have made the topic more accurate.

TinCanTech

ADFHAU wrote Brand new, out of the box Thinkpad T480 running Windows 10 Pro with the basic

There is a very new download which we would like tested.

https://openvpn.net/community-downloads/

It is the 603 version.

ADFHAU

No worries, @TinCanTech, we'll give it a go!

ADFHAU

... Incidentally, does my config look "sane"?

TinCanTech

If it works for you then that is sane enough .. I don't use TAP but it is useful to know it works.

ADFHAU

Hi @TinCanTech,

I tweaked the config slightly by adding:

keepalive 10 60
ping-timer-rem
persist-remote-ip

... to the server config, upgraded to the latest build advised on the notebook, added the windows file server to the local intranet zone on the notebook, and disabled power management on the notebook whilst it's docked. They also upgraded their office internet (it was woeful) on the notebook side. That increased link resilience but didn't fix things entirely.

In the end, the culprit on a brand new computer for the biggest part of crashing, was actually Lenovo's pre-installed Microsoft Office! Even though it had been activated with a valid Office 365 license, testing revealed that Explorer only crashed when Office files were involved. An uninstall of the pre-installed, and then an install of the Office 365 click-to-run install solved the issue.

Thanks for your help. I would not have thought a factory install of such a common product would be so bodgy.

TinCanTech

ADFHAU wrote In the end, the culprit on a brand new computer for the biggest part of crashing, was actually Lenovo's pre-installed Microsoft Office! Even though it had been activated with a valid Office 365 license, testing revealed that Explorer only crashed when Office files were involved. An uninstall of the pre-installed, and then an install of the Office 365 click-to-run install solved the issue.

Thanks for your help. I would not have thought a factory install of such a common product would be so bodgy.

MSO-365 has been plagued with Fudd since day one of it's launch .. Day One!

Try some other solution and break the M$ strangle hold ..

M$ also bought github for $7Billion .. because M$ are parasites .. that was a dark day 🙁