Closed wellloaded closed 10 months ago
Our latest guinea pig build replaces our custom wintun driver implementation with the OEM driver. The driver is also ephemeral, meaning that a wintun adapter instance is created when the connection starts and is destroyed when the connection ends (tldr we no longer install the wintun/tap drivers). Please note that this build no longer supports the TAP driver, just in case any of your custom ovpn configs explicitly specify use of the TAP driver. Does this build resolve your issue? https://deploy.totallyacdn.com/desktop-apps/2.8.1/Windscribe_2.8.1_guinea_pig.exe
I'm testing it I will get back with a feedback soon. Thanks!
1) Installed guineapig 2) disconnected the VPN 3) connected the VPN 4) Network number stayed at 37
You fixed it! Thank you :-)
Excellent! Glad we were able to resolve the issue for you. Thank you for raising the issue and testing our patch. Cheers!
1 image is worth 1000 words:
I'm using a custom .ovpn in this case. I know this is mainly an issue with Windows if we can call it so, but can you think of a way for this to be prevented/worked-around?
Perhaps you can record the prev network number and delete is via internal powershell interaction before reconnecting? Or perhaps you can impose a network number like 1000 to be statically assigned to that .ovpn?
I'm just concerned all those network configs, even if not in use any more will eventually affect Windows.
Thanks