Windows clients always have to reinstall the Client GUI
-
Thanks for the relays. Yes they're on the latest 9.24.2 TAP driver.
Most of the ones with the issue where never on the old version. They've always had OpenVPN 2.4.8 & TAP 9.24.2, so I don't think it's an upgrade issue. But I'll try the stock installer on one of them anyways.
@johnpoz said in Windows clients always have to reinstall the Client GUI:
But your saying this happens again, after they reboot - they once again have to install twice?
Actually they don't have to reboot for it to happen. They will be connected, then disconnect, then try to reconnect & it won't. Then we do an uninstall & reinstall of OpenVPN (from the export tool) & then it connects fine. So It's not really twice once after another, but twice since it was already previously installed.
-
these users don't have admin rights? An admin should be installing, or the user needs to be able to elevate the install as admin..
Been using openvpn on windows for a very long time - have never seen such an issue to be honest.. .Don't have a huge sample of machines, etc. But can't say I have seen anything like this..
-
Ya I know it's kind of a weird one...
I have added the users to the local "Administrators" group to insure that wasn't an issue. -
Sure not related to your endpoint protection?
-
That did cross my mind, but I ruled it out, since all the users have the same protraction, but only a few have the VPN connection issue. I'll disable it just to be sure.
-
Grrrr, still no luck. I disabled Anti-virus, still didn't work. I installed from the stock installer, still didn't work.
I collected these screen shots of ipconfig of the TAP adapter when it works & when it doesn't.
Why would it Auto configure the IP address & why isn't it receiving the correct DNS server?
And here are the logs when it works & when it doesn't compared side-by-side.
And here are the full log files....
pfSense-UDP4-1194-pintar-config_good.txt
pfSense-UDP4-1194-pintar-config_bad.txt -
Check in the Services control panel on Windows and see the the OpenVPN services which are running are the same when it's in both states. Maybe something is killing its service.
-
This seems to be related.. You could try the suggestions in there
https://community.openvpn.net/openvpn/ticket/665 -
Just a wild guess :
I had an issue very comparable with the PC of a fellow home worker.Someone or something swapped the TAP driver out ....
It was one of the 2 (!) client apps installed for his private VPNxxxxx and VNbbbb access. These often use their own versions.
@bazzacad : check your Network card's list : how many TAP-virtual-NIC drivers are listed there ?
You named one of them to "tipping.lan", but not the other. Up to you to discover where the other came from. There is probably even a program running that 'repairs' it's settings and files after you installed the OpenVPN-client-from-pfSense.edit : or even multiple OpenVPN instances running with their own TAP versions ...
edit2 : jimp said the same thing. Look and check also all the tasks at services.msc
-
@johnpoz said in Windows clients always have to reinstall the Client GUI:
An admin should be installing, or the user needs to be able to elevate the install as admin
In addition when running the OpenVPN GUI it needs to be run as admin so it can modify the routes in Windows. (I am a standard user on my PC). Could it still be running as an admin when launching from the install? It's been a long time since I installed...
-
The current version has a service that will do the admin stuff.. So no the user doesn't have to be admin.
-
This link: https://community.openvpn.net/openvpn/ticket/665 from @johnpoz look promising, so I'll try those solutions.
The users have full admin rights when installing & running the GUI. -
OK, I'm pretty sure I've got it fixed now. Per the bug report link above, all I had to do was add dhcp-renew to the client config file.
-
Your posting of the log showing the route waiting for interface to come up was key in finding that info...
So glad you got it sorted!
