cryptostorm's community forum

by df » Sat Apr 10, 2021 2:09 am

As I said before, there's no reason to create a MacOS widget because software like Tunnelblick and Viscosity already exist. Why don't you try one of those? Tunnelblick is free and includes the latest OpenVPN/OpenSSL. Viscosity isn't free ($14), but some people say it's easier to use than Tunnelblick. It'll increase speeds too if you're connecting to the VPN on the host system instead of a VM.

by **lajola** » Sat Apr 10, 2021 1:54 am

df wrote: ↑
Sat Apr 10, 2021 1:38 am
Can you run the widget on the host system?

Eh.. it's impossible for me.

I have only a mac. For this i have asked some times a osx widget.

by df » Sat Apr 10, 2021 1:38 am

Can you run the widget on the host system? That'll let us know that the issue is specific to Parallels. When testing the widget on different Windows versions, I use VirtualBox and never saw this issue before. For Windows 10 testing I also use a laptop that's not doing virtualization.

by **lajola** » Sat Apr 10, 2021 12:33 am

Windows 10 on Parallels

by df » Sat Apr 10, 2021 12:29 am

What kind of virtual machine?

by **lajola** » Sat Apr 10, 2021 12:23 am

df wrote: ↑
Sat Apr 10, 2021 12:17 am
I mean are you using any other VPN software? Most of them make the assumption that their TAP adapter is the only one that'll ever be installed, so they'll often trample all over other adapters, changing settings arbitrarily etc.

The only vpn that i am using, on virtual machine, using tap adapter is cryptostorm. And how written in previous posts i have try with many tap drivers. Now i am using the last stable linked by you.

by df » Sat Apr 10, 2021 12:17 am

I mean are you using any other VPN software? Most of them make the assumption that their TAP adapter is the only one that'll ever be installed, so they'll often trample all over other adapters, changing settings arbitrarily etc.

by **lajola** » Sat Apr 10, 2021 12:13 am

df wrote: ↑
Sat Apr 10, 2021 12:08 am
What about other VPN software? And when you say you never see csvpn.exe, does that include when you're connected? Because it has to be in the process list if you're connected.

I edited previous post. I see csvpn.exe and it is there without problems. Other vpn software have no problem.

by df » Sat Apr 10, 2021 12:08 am

What about other VPN software? And when you say you never see csvpn.exe, does that include when you're connected? Because it has to be in the process list if you're connected.

by **lajola** » Sat Apr 10, 2021 12:04 am

df wrote: ↑
Fri Apr 09, 2021 11:24 pm

Trying again with last new tap driver linked previously. With new tap driver i see this thing: only if i exit from widget the tap goes in disconnect and standard connection is working again. We need a way to avoid this EXIT continually from widget to have again standard connection and reopen it again every time we need the vpn connection.
So when you click the Disconnect button on the widget the TAP adapter is still in a connected state? It only leaves that state when you exit? I'm not seeing that behavior on Windows 10:
widget.gif
EDIT:
The TAP adapter should be unplugged/disconnected whenever OpenVPN (csvpn.exe) exits. The widget forcibly kills that process using a couple of different methods. Maybe an AV or something is preventing that from happening? When you disconnect, check if csvpn.exe is still in the process list by opening the task manager with ctrl+shift+escape then clicking on the Details tab, see if there's a csvpn.exe in there still.

Yes.

I see csvpn.exe. I have only windows standard antivirus and also disabling it nothing changes. I don't know honestly. But this is a big bug on my side.

by df » Fri Apr 09, 2021 11:24 pm

Trying again with last new tap driver linked previously. With new tap driver i see this thing: only if i exit from widget the tap goes in disconnect and standard connection is working again. We need a way to avoid this EXIT continually from widget to have again standard connection and reopen it again every time we need the vpn connection.

So when you click the Disconnect button on the widget the TAP adapter is still in a connected state? It only leaves that state when you exit? I'm not seeing that behavior on Windows 10:

EDIT:
The TAP adapter should be unplugged/disconnected whenever OpenVPN (csvpn.exe) exits. The widget forcibly kills that process using a couple of different methods. Maybe an AV or something is preventing that from happening? When you disconnect, check if csvpn.exe is still in the process list by opening the task manager with ctrl+shift+escape then clicking on the Details tab, see if there's a csvpn.exe in there still.

by **lajola** » Fri Apr 09, 2021 10:58 pm

Trying again with last new tap driver linked previously. With new tap driver i see this thing: only if i exit from widget the tap goes in disconnect and standard connection is working again. We need a way to avoid this EXIT continually from widget to have again standard connection and reopen it again every time we need the vpn connection.
There is also a second problem: after the first vpn connection and then disconnected, also if tap adapter seems still connected it's impossible make a new vpn connection because there is not internet at this moment, non standard connection also obviously. So also here the only way is completely EXIT from widget and then reopen it to have again both standard connection or a the possibility to make a vpn connection.
This also with the last stable tap driver, with the standard one incluse in the crypto widget bug are bigger.

With this last we need a way that when we disconnect from widget the tap must disconnect itself. In this way all is solved/fixed. Because now tap driver disconnect itself only if we EXIT from widget. Why?

by **lajola** » Fri Apr 09, 2021 10:54 pm

df wrote: ↑
Fri Apr 09, 2021 10:53 pm
@lajola
forgot to say, when you install the new one, you need to go into network connections and rename that TAP adapter to "cryptostorm"

Yeah done, but problem is still there

this bug is really tedious

by df » Fri Apr 09, 2021 10:53 pm

@lajola
forgot to say, when you install the new one, you need to go into network connections and rename that TAP adapter to "cryptostorm"

by **lajola** » Fri Apr 09, 2021 10:15 pm

This new tap version doesn't solve the problem. Not only, when i try the crypto connection the widget install the own tap driver so now i have 2 tap drivers connected and enabled together. When i disconnect from widget now both remain enabled and the vpn connection is still ENABLED! So with this new one problem is still there.
Please you need to solve this bug with windows 10.

Edit: now i have uninstalled all tap drivers but now when i try to connect from widget, this last can not install its tap driver anymore. So no more connection with vpn. So how can solve this problem?

Edit2: installed the "original" from cryptostorm folder in /Programs

by df » Fri Apr 09, 2021 5:06 am

@lajola
The widget isn't what's changing the TAP adapter from connected/disconnect, that's all handled by OpenVPN. Remember, the widget is mostly just a GUI frontend to OpenVPN. You might be running into that TAP bug I saw a few times where it's state would become unchangeable until a reboot. The TAP adapter the widget comes with is older because the newer ones require different privileges and signing methods, but it might solve your problem if you remove that TAP adapter (from the device manager or network connections window), then install the latest TAP adapter from https://build.openvpn.net/downloads/rel ... stable.exe
There's a few newer versions at https://build.openvpn.net/downloads/releases/ too that might include fixes for that bug, though they might still be in a testing phase.

EDIT:
I am still seeing an issue where it takes about 5-20 seconds for the internet to become reachable after connecting to the VPN, but only in win7. This doesn't seem to be caused by the VPN though, it's caused by Windows and a lag before ipconfig /registerdns kicks in (or it might be that the route additions are taking a while for Windows to recognize them). It might help to change that one --ip-win32 setting in Options -> Advanced to ipapi or netsh (or it might break things altogether, who knows with Windows).

by **Moonlight** » Fri Apr 09, 2021 1:48 am

@df

win 10 x64 os build 19042.906

Security Tab: All options checked

v3.46.0.46

v3.47.0.49

Thank you.

P.S. Had same issue as lajola but with v3.43.0.19 and a few prior versions only and with Killswitch on. When exiting at that time with Killswitch off, had to wait a few minutes before being able to connect to the internet, or alternatively reboot.

by **lajola** » Fri Apr 09, 2021 12:50 am

Ok these are the problems:

1) reboot windows
2) connect with cryptostorm widget
3) disconnect with cryptostorm widget
4) web surfing/connection is not more available
---
5) cryptostorm tap adapter is still ENABLED but CONNECTED
6) manullay disabled it
7) manually enabled it again but now is DISCONNECTED
8) now web surfing/connection is available and working!
---
9) tried again a new vpn cryptostorm connection but doesn't work because widget can't move the TAP adapter from ENABLED(disconnected) to CONNECTED
10) close widget
11) reopen widget and try a new connection
12) now cryptostorm widget can move the TAP adapter from ENABLED(disconnected) to CONNECTED
13) VPN is working
---
14) from point 3

Now why widget can't do all this automatically?

by **lajola** » Fri Apr 09, 2021 12:18 am

df wrote: ↑
Fri Apr 09, 2021 12:14 am
I tested on Windows 10, not seeing the issue you're describing. Check in Options -> Security and see if the kill switch is enabled. The kill switch uses the Windows Firewall, so even if you've never used it before there might be some old rules leftover in there from the widget. Try disabling DNSCrypt in there too. If that's enabled and the DNS isn't getting restored on disconnect then it would cause DNS failures. There's also a big button in Options -> Advanced that says "Reset DNS to DHCP". Try clicking that after disconnecting and see if your internet works then.

Tried. KS was disabled like all other options.
"Reset DNS to DHCP" doesn't fix the problem. Tried many times. It deletes my google dns insert by me.

Which are the kill switch rules remained in the firewall?

by df » Fri Apr 09, 2021 12:14 am

I tested on Windows 10, not seeing the issue you're describing. Check in Options -> Security and see if the kill switch is enabled. The kill switch uses the Windows Firewall, so even if you've never used it before there might be some old rules leftover in there from the widget. Try disabling DNSCrypt in there too. If that's enabled and the DNS isn't getting restored on disconnect then it would cause DNS failures. There's also a big button in Options -> Advanced that says "Reset DNS to DHCP". Try clicking that after disconnecting and see if your internet works then.

by **lajola** » Fri Apr 09, 2021 12:03 am

Yes, same problem with last version 3.47.0.49.
The first connection with the widget works without problems. But after disconnected there is no more connection. Nothing. The only way is a windows reboot.
Don't remember if kill switch was enabled. I use the standard windows 10 firewall and i never touched it.

So what you need to fix this weird bug? I can't reboot honestly every connection.

by df » Thu Apr 08, 2021 10:44 pm

@lajola
Are you seeing the same problem in v3.47.0.49?
My guess would be DNS related, but the widget should tell you if it can't resolve the VPN host you're connecting to. Either that or the kill-switch was enabled (or in a weird half-enabled state). Could check the Windows Firewall rules to see if there's anything in there that's blocking.
I do remember seeing a weird bug in OpenVPN's TAP driver where it would go into an odd semi-immutable state where you can't change or access any setting on it. But when I ran into that bug it only stopped the TAP adapter from working, not the other network adapters.

by **lajola** » Thu Apr 08, 2021 10:26 pm

I have had this problem for many versions, I don't remember when it started, obviously I'm on windows 10: the first connection to a server is always successful, but after I have disconnected there is no longer an internet connection working even if there are no obvious errors. In fact, if I try to reconnect the vpn the app crashes on "Connecting". As if there was a DNS problem. Basically it is impossible to navigate, tried anything. The only way to browse again is to reboot the system.

by df » Thu Apr 08, 2021 10:13 am

v3.47.0.49 released - https://cryptostorm.is/cryptostorm_setup.exe

Bugfix: The bugfix in 3.46 where the widget would forget your token added a dumb bug where Cryptofree would complain about no token being entered (which you can't do when Cryptofree is selected). Added the missing code, all good now.

by df » Thu Apr 08, 2021 3:12 am

v3.46.0.46 released - https://cryptostorm.is/cryptostorm_setup.exe

Feature: SSH and HTTPS tunneling now built into the widget. They're under Options -> Advanced.
With SSH you can select the tunnel host (has to be different than the VPN node you're connecting to). With HTTPS it'll tunnel through the node you're connecting to, but since the server-side stunnel is doing round-robin balancing against all the server's IPs, the exit IP you get will most likely be different than the one you're connecting to.

Change: OpenSSL upgraded to the latest 1.1.1k

Change: Instead of dealing with 32-bit and 64-bit copies of all the .exe/.dll's, just doing 32-bit only since there's not really any performance difference with 32-bit and 64-bit OpenVPN. Should make things easier on 32-bit Windows users.

Change: Removed the fallback to Cloudflare's 1.1.1.1 DNS server when DNSCrypt fails. The only way that would happen now is if all of the DNSCrypt servers are unreachable, which is unlikely to happen (unless you're offline, in which case you wouldn't have been able to reach 1.1.1.1 anyways).

Change: For the backend Tcl/Tk that powers the GUI, switched from ActiveTcl to IronTcl because I think it's neat :-P

Bugfix: If you had a regular token in the token text box then selected Cryptofree and exited, the widget would forget your token. Now it won't do that.

Bugfix: Some code was iterating through the network adapters list via the registry, but there was a bug where it would keep looping and creating subkeys until a limit was reached. This is what was causing the widget to take so long to start or disconnect/exit, especially when restoring DNS settings on exit (like if DNSCrypt was enabled). Now it starts/exits/disconnects much faster.

Bugfix: The SOCKS port under Options -> Advanced sometimes wasn't getting saved correctly on exit, would affect people using Tor Browser's built-in local SOCKS server to do Tor -> CS.

Bugfix: Some missing logic was causing autoconnect to fail, mostly when Cryptofree was selected. Should be good now.

Bugfix: Removed the "--dev-node cryptostorm" OpenVPN option that forced the widget to use a TAP adapter named "cryptostorm", because sometimes OpenVPN would detect the adapter but Windows wouldn't.

Bugfix: Found a bug in the Net::DNS::Resolver module that was being used to pre-resolve the VPN hosts against the local DNSCrypt server (so the user could choose their exit IP, if that option was enabled). The bug would sometimes cause DNS to fail even when the DNSCrypt server was up and running correctly. The idea was to use that module so the DNS didn't need to be set system-wide to DNSCrypt, but the widget does that anyways, so Net::DNS::Resolver isn't necessary.

Bugfix: Sometimes the system tray icon would disappear if grouped under hidden icons. Now it should stay visible even if it gets sent there.

by df » Sat Mar 20, 2021 9:45 pm

@lajola
Tunnelblick and Viscosity work just fine on Mac OS X

by **lajola** » Sat Mar 20, 2021 9:32 pm

Why we haven't a good widget also for Osx? I can't understand. Please @df buy a mac, we need a good widget also for Osx. Or buy a dev to do it, it's necessary.

by df » Tue Mar 16, 2021 10:56 am

Found another bug, in the latest v3.45.0.43 (and possibly previous versions). If "Global random" is selected, the widget fails to resolve the hostname. I'm also seeing gethostbyname fail to resolve the node if you connect with DNSCrypt enabled, disconnect, disable DNScrypt, then try to reconnect. Trying to pinpoint why that's happening.

by df » Mon Mar 15, 2021 3:39 pm

I found the main issue with v3.45.0.2 and versions before it, some core features in the language itself were broken like backticks for executing commands (needed to get the OpenVPN/OpenSSL versions, run the firewall stuff, etc. etc.), certain file system functions, and probably some other things. It would run correctly from client-debug.exe or if client.exe was started from an admin command prompt, or from the installer, but if you run it again from it's desktop/startmenu shortcut, the bugs would show up and the VPN won't start. These bugs are all caused by the way Perl2Exe (insufficiently) tries to scan and bundle the required modules, so I'm giving up on the idea of switching to that for packaging.

I just put v3.45.0.43 up on the website, that one's back to the old Cava Packager, and it doesn't seem to have any of those bugs. Tested on several VMs (win7, 32-bit win7, win8.1, win10) and it connects just fine. The whole reason for switching to Perl2Exe from Cava was that Cava was taking 20-30 seconds to load the GUI, but in my tests just now it only took about 3 seconds. Not sure if that's because some of the fixes for Perl2Exe's bugs are still in the widget, causing modules to load more efficiently, or maybe because Tcl is now included separately in the installer instead of bundled into the .exe, but at any rate, it loads just as fast now and seems to work well :-)

by **Moonlight** » Mon Mar 15, 2021 3:17 pm

v3.45.0.2 (over 3.43.0.19), all good!

Thank you.

P.S. for feedback purpose only - 3.45.0.1, tried to install as per your request with the given link but it didn't work.

by **Moonlight** » Sun Mar 14, 2021 8:05 am

win 10 x64 os build 19042.867

was on 3.44.02, 3.45.0.1 install completed.

running 3.45.0.1 stops at "Installing tap driver" then get following error message:

: cs_3.45.0.1.png (10.51 KiB) Viewed 62339 times

In control panel there was no TAP adapter listed.

Noticed that TAP-Windows 9.21.2 x64 was installed, so uninstalled it, and re-installed 3.45.0.1, TAP-Windows 9.21.2 x64 was reinstalled. Still the same error message when running 3.45.0.1.

After a reboot, did a fresh install of 3.45.0.1 with same error message when running it.

3.44.0.2 is no longer working for me either i.e. hanging when trying to connect, so went back to 3.43.0.19.

by df » Sun Mar 14, 2021 1:24 am

Alright, v3.45 is out now. I'm pretty sure I fixed all the bugs that were in 3.44. Tested on 64-bit Windows 7, 8.1, 10, and 32-bit Windows 7. Only issue I found was on the 32-bit Windows 7 VM where the TAP adapter wouldn't install because of some stale ones that were on the system. After a clean OS install the widget and the TAP adapter installed correctly.

I couldn't see a difference in speeds between 32-bit and 64-bit Windows, so instead of dealing with 32 and 64-bit copies of the same program (OpenVPN + OpenSSL + tap utilities), everything is 32-bit now. That cleared out some code, which means the widget should load faster now. Also got rid of all the AES-NI detection crap, and the RSA-if-32bit code since ECC & OpenVPN 2.5.1 works fine on 32-bit. Now, if you really want to use RSA, you can do so from Options -> Securty -> TLS cipher. It'll still use ChaCha2020/Poly1305, but on top of ECDHE RSA. That's only if you want to use RSA though, which you shouldn't. Default TLS cipher is still secp521r1. Ed25519 or Ed448 still available too.

Main problem with v3.44 is that I switched from Cava Packager (which bundles modules/submodules correctly) to Perl2Exe (which doesn't bundle modules/submodules correctly). But Perl2exe creates a client.exe that loads a lot faster (~2-5 secs, Cava's is ~20-40 secs), so I really wanted to switch to that. With all of Perl2Exe's bundling fumbling, it was looking for the TCL .dll's (among other things) in the wrong places, that's why the GUI wouldn't load at all for most people trying to use 3.44. Those issues should be fixed in v3.45.

by df » Mon Mar 08, 2021 11:39 pm

@noplanman
I'm still working on the latest release. I thought I fixed an issue where an embedded Tcl library .dll sometimes wasn't included, but I'm running into some very odd bugs in the core Perl libraries, or rather in the way perl2exe embeds those libraries into client.exe. I really want to use perl2exe though because the thing I used to use (Cava Packager) takes way too long to start up client.exe. I just have to rewrite some of the widget's code because regular threads aren't working correctly.

by **noplanman** » Mon Mar 08, 2021 3:35 pm

@df, the older version is working, thanks again.

Any update on the new release?

I understand the reasoning to make sure people use the latest version, but as you say, having at least 1 "back up" version does make sense.
Well, it totally gets my vote anyway

by df » Sun Feb 28, 2021 9:11 am

@noplanman
GitHub is still used for the configs and deepdns info, but the other repos there are abandoned. There's no real versioning system in place for the widget since (normally) we don't want people using an older version. But with the most recent update some major changes were made that could cause errors like we're seeing now, so it might be a good idea to at least keep around the previous version.

by **noplanman** » Sun Feb 28, 2021 5:08 am

Thanks for the link @df, will give it a shot when I have time and let you know

Regarding the question of versioning, is there some place where the development is happening openly?
I saw the GitHub repo is pretty much abandoned, right?

by df » Sun Feb 28, 2021 4:46 am

@noplanman
I'm working on a new version that should fix whatever issue some people are having. In the meantime, there is an older version at https://cryptostorm.is/setup.exe that seems to work for everyone.

by **noplanman** » Sun Feb 28, 2021 4:38 am

I'm faced with the same issue of having updated and now the widget isn't showing up at all.

Where can I download older versions? Seems to me the versioning of the client doesn't really exist and only finding a single link to the latest version is very unhelpful.

Can anybody point me to a place where older versions can be downloaded directly?

by df » Sat Feb 27, 2021 11:12 am

Yea, was gonna mention here that 3.44.0.1 had a bug in it that caused the whole thing not to display. Some obscure TCL lib issue, took a minute to figure out. That's why I didn't use PAR::Packer or perl2exe in the past, because Cava Packager didn't have an issue with TCL. but Cava causes it to load really slowly.
3.44.0.2's TCL issue should be fixed now, but I noticed there's still an issue of something else not working correctly on 32-bit Windows, I'll fix that soon. There's also a 32-bit TAP issue that stems from https://community.openvpn.net/openvpn/ticket/592 (6 yr old issue, still getting comments), but I think I can fix that too by replacing tap32.exe with the newer tapctl.exe.

v3.44.0.2 was several different build attempts, which is why I didn't announce it yet. The list of instructions part should be there in the status bar, just above the black window. Everything in the black window has almost always been OpenVPN output and nothing else.
I see the update node list issue you're talking about. It doesn't show up in perl, but it does when I compile the script into an .exe. I'll try n figure out why it's doing that. And the cs-dnsc-p.exe issue should be easy enough to fix, just need an extra check on exit if it's running (or just blindly kill any 'cs-dns-p.exe' process on exit).

For now, just don't click the update button :-P there's no other new servers anyways, the node list v3.44.* has is the most recent.

by **Moonlight** » Sat Feb 27, 2021 10:33 am

v3.44.0.2 is now working!

one little hiccup, before i connect, is if i click to update the list of nodes, the application close/disappear, but it's still running in the background (cs-dnsc-p.exe (32 bit) is still being listed in task manager), on clicking again the cryptostorm client the application re-open without mentioning that another instance is already running.

also, i noted on opening the widget, a list of instructions that were running/appearing (at the bottom window of the widget) in v3.43 is now absent/invisible (e.g. enabling stun/webrtc leak protection, blocking protocols ... etc).

by **Moonlight** » Fri Feb 26, 2021 3:33 pm

win 10 x64 os build 19042.844

v3.44.0.1 doesn't work, user account control panel doesn't even come up

installed 3.44.0.1 by clicking yes to the updated version available, no go

so downloaded the widget separately from cryptostorm.is, doesn't work either

uninstalled and did a fresh install, no go too

noticed that v3.44 is 10.5MB vs 17.3MB for v3.43

went back to v3.43

by **Moonlight** » Mon Nov 25, 2019 4:59 am

Had the same issue as marzametal last month (didn't have that issue prior) under win10 1903. So I changed to "Obtain DNS server address automatically" and it worked without the error message.

Under win10 1909, it's the opposite. I have to select "Use the following DNS server addresses:" and input 127.0.0.1 for both the cs and ethernet adapters, and I don't get the error message. Once connected, I checked both adapters and the option "Use the following DNS server addresses:" has been changed automatically back to "Obtain DNS server address automatically".

Under both above instances, I have IP selection on (widget 3.43.0.19).

I have another PC, and had no issue at all under both win10 1903 and then 1909 (same physical specs and same ethernet adapter).

In regard to the "The Widget also hangs when disconnecting..." I always had to use the Task Manager except when connected for less than a couple of hours (under both PCs).

Above issues are a very small hassle but not consequential as long as I can connect.

reCAPTCHA is now implemented.

by **sysfu** » Sat Nov 23, 2019 4:49 am

marzametal wrote: ↑
Fri Nov 15, 2019 6:05 am
I recently upgraded to the latest version of the widget.
This time around, the widget actually completes executing the killswitch (before it stopped on one of the exit nodes).

However, the widget now changes my dns to 127.0.0.1, which results in no chance in connection.
I have to use the Cloudflare 1.1.1.1 dns if I want to connect.
This did not happen with the previous release, which let me connect automatically.

NOTE: This is not the error with the tap adapter, a different error pops up. I will disconnect and connect again to provide a print screen.

dns.jpg

Can confirm the same issue on Windows 10 1909 with 3.43 CS Widget.

The Widget also hangs when disconnecting, process must be terminated forcefully to recover.

by **marzametal** » Fri Nov 15, 2019 6:05 am

I recently upgraded to the latest version of the widget.
This time around, the widget actually completes executing the killswitch (before it stopped on one of the exit nodes).

However, the widget now changes my dns to 127.0.0.1, which results in no chance in connection.
I have to use the Cloudflare 1.1.1.1 dns if I want to connect.
This did not happen with the previous release, which let me connect automatically.

NOTE: This is not the error with the tap adapter, a different error pops up. I will disconnect and connect again to provide a print screen.

: DNS error message

by df » Sat Jul 27, 2019 12:08 am

@Behoove
with the widget closed, open up c:\Program Files (x86)\Cryptostorm Client\user\config.ini in Notepad++ (since it needs admin privs) and change the line:
nostun=on
to
nostun=off
then restart the widget.

by **Behoove** » Thu Jul 18, 2019 11:36 am

As of yesterday (IIRC), I'm getting a hang in the app: "Disabling STUN/WebRTC leak protection...".

I reinstalled twice over these last two days to try and fix. Also did the advanced windows firewall reset just in case.
On startup, the status locks up showing "Enabling STUN/WebRTC leak protection...".
Selecting / Deselecting the "Enable STUN/WebRTC leak prevention" under Security tab, then hitting the "Back" button results in the hang every time now.
Only way to even exit the program is to manually kill all the CS processes; as the 'Close Window' button hangs it the same as 'Exit' button.

Some part of this process doesn't rely on IPv6, does it?

Windows 7 x64 on AMD
CS Widget client v3.42
Latest TAP driver
CS and TAP directories added to AV exclusion list
Connect on port 5062
IPv6 and Teredo blocked in Win Firewall beforehand, also de-selected in adapter configs.

by **Moonlight** » Tue May 28, 2019 9:27 am

@DF

Did the modification to the config.ini as suggested, and it's now working!

Tried on a different PC with the same build and it's working, so the problem is with the PC I'm using, will rebuild it in due course.....

Thank you very much for your time and prompt help!

by df » Sun May 26, 2019 11:15 pm

@Moonlight
My guess would be a DNS issue. Switzerland currently has 26 IPs, and Frankfurt has 28. Only way I could see the widget not displaying the select IP window is if somehow the host was resolving to only one IP.
If you mean that option doesn't show up at all in the widget's options, then that might be possible if your screen's resolution is very low. The option is at the bottom of the connecting window, so if the screen's too small it might cut off that bit. That build does have code in it though that should detect things like that so that the option is still displayed correctly, but it's possible that there might be something missing in the code causing it not to work on your system.
Anyways, you can enable it manually by editing c:\Program Files (x86)\Cryptostorm Client\user\config.ini and changing the dnschoice_opt line to dnschoice_opt=on
(You'll need admin access to write to that file, so use Notepad++ since Notepad++ will automatically switch to admin mode when you try).

by **Moonlight** » Fri May 24, 2019 6:37 pm

Win 10 Pro x64 OS Build 18362.116

Clean install CS widget 3.42.0.17

All security options checked

When connecting to Switzerland or Frankfurt, option to select IP is no longer available (was yesterday).

Thank you.

by df » Mon Apr 08, 2019 5:34 am

DudeOfLondon: secp521r1 is default because it is more secure than Ed448 or Ed25519, but because it's an NIST curve we decided to also provide Ed25519/Ed448 options.
And there's no such thing as security overkill :-P

by **AnonAsPossible** » Tue Mar 26, 2019 10:31 pm

I don't use their widget, only the openvpn gui.

You should contact their support at; support@cryptostorm.is , the response is usually quite fast.

And post their response here, so we can all learn...

by **DudeOfLondon** » Tue Mar 26, 2019 4:41 am

So it seems this must be an MTU problem that is only present when using UDP.
I found out that the MTU of my router is 1440 for the bonding tunnel of the DSL+LTE connection.
Minus 28 for UDP should be a link mtu of 1412 and a tunnnel MTU or tun-mtu of 1362.

If I edit the OVPN config file and enter tun-mtu=1362 internet works on my android. (or enter 1362 in the tunnel mtu field of the GUI of Anre Schwabe's app).

But how can I edit the inbuilt configs of the widget to use a different MTU than default?

by **DudeOfLondon** » Tue Mar 26, 2019 2:48 am

Thanks.

I got a problem though.
When using UDP I can't browse any site, it hangs there on "TLS handshake with www.12324.com ..." in the browser status line.
Doesn't matter which server or ECC cuve. Also tried different ports, doesn't matter, it does not work with UDP.
When switching to TCP I can browse the web.

What can I do? WHy does UDP not work? I'm on Windows 10, no firewall insalled except the win10 integrated one.

EDIT: Same exact problem and behavior on my android device!

by **AnonAsPossible** » Tue Mar 26, 2019 12:52 am

See this comprehensive reply in their blog; https://cryptostorm.is/blog/which-config-to-use

by **DudeOfLondon** » Mon Mar 25, 2019 5:12 am

Can anyone tell me the differences between the ECC curves that are selectable in the widget?

I found that ED448 is even more security overkill than ED25519 and ED25519 is enough in most cases.
And both are not from NIST.

But why is the secp521 selected as default, and what does it offer compared to ED25519?

by **marzametal** » Wed Mar 13, 2019 6:19 am

I tried disabling "Enable DNS leak prevention" and the block-outside-dns thing still shows up.

by df » Tue Mar 12, 2019 11:56 am

@marzametal
Only reason that would happen is if your system is using a different DNS than the one pushed by the VPN server.
The only other IPs that'll work with block-outside-dns are 10.31.33.8 (same thing as the pushed IP), or 10.31.33.7 (the TS enabled IP).

After connecting, try doing `nslookup whoami.cryptostorm.is` to see what DNS server is being used. I vaguely recall an old widget bug where sometimes DNS would get left set to DNSCrypt's 127.0.0.1 even after connect, which block-outside-dns would block. Pretty sure that bug was fixed a while back though.

If you really do want to use a different DNS IP than the one pushed by the VPN server, go into Options -> Security and disable the "Enable DNS leak prevention" option. That'll tell OpenVPN to ignore the --block-outside-dns option that gets pushed from the server to the client.

by **marzametal** » Tue Mar 12, 2019 6:49 am

@df
Blocking outside DNS
Block_DNS: WFP engine opened
Block_DNS: Using existing sublayer
Block_DNS: Added permit filters for exe_path
Block_DNS: Added block filters for all interfaces
Block_DNS: Added permit filters for TAP interface

No browsing allowed.

by df » Tue Mar 12, 2019 1:08 am

@marzametal
What block-outside-dns thing?

by **marzametal** » Mon Mar 11, 2019 12:05 pm

Getting the blockotsidedns thing on the new version...

To make things worse, I forgot what version I was using so I could go back!

by **Stan** » Mon Feb 25, 2019 5:23 am

@df

I understood that, but hoped there was a way to allow both to be achieved. Which you have done by pointing out the option to suit my situation.

Thank You for that.

by df » Fri Feb 22, 2019 3:44 am

v3.42 is up now.

Fixed a few bugs in v3.40 where the widget would crash on disconnect, and sometimes on exit.
Switched from using slow as hell `netsh` commands for changing the system's DNS to much faster registry changes.
Removed the TLS version GUI option since it'll now default to TLSv1.3, unless you're on 32-bit Windows.
Fixed a few code logic errors that would make things run less smoothly, like disabling IPv6 on startup, and when going back to the main window from the options window, and when connecting. The last one's unnecessary. Same goes for the STUN blocking code.
The old IPv6 disabling code made changes to the 4to6/isatap/teredo adapters, and doing that is very slow. So removed that code since IPv6 blocking is accomplished with firewall rules anyways.

Updated OpenVPN to 2.4.7, and with the server-side changes, TLSv1.3 will default to ChaCha20/Poly1305 instead of AES.

@Stan
I wanted to keep that code in that resets DNS to DHCP if your DNS is set to 127.0.0.1 on start, to account for the bug in older widget versions.
But to account for your scenario, or for anyone else who wants to use their own DNSCrypt, you can open the config file at:
C:\Program Files (x86)\Cryptostorm Client\user\config.ini
and change "dnscrypt=on" (or "dnscrypt=off") to:
dnscrypt=local
You'll need admin privileges to write to that file, so use Notepad++ since it'll switch to admin mode automatically when you try to do that.
That config option will tell the widget not to mess with DNS settings or run it's own DNSCrypt, even if DNS is set to 127.0.0.1 when starting up.

by **Stan** » Sun Feb 17, 2019 3:47 pm

@df

Thanks for pointing out it's intentional.

The problem is that the reason I use a local one is so that it is used when I'm disconnected from cryptostorm too, so it would be annoying to have to keep changing that all the time.

by df » Sat Feb 16, 2019 10:54 pm

@Stan
That's a bugfix for previous widget versions that would sometimes set DNS to 127.0.0.1 even when the widget's dnscrypt-proxy isn't running.
You shouldn't need to run your own dnscrypt-proxy anyways, the widget includes it.
If you want to use your own dnscrypt servers instead of ours, edit the c:\Program Files (x86)\Cryptostorm Client\bin\dnscrypt-proxy.toml file.
It uses the newer format described at https://github.com/jedisct1/dnscrypt-pr ... proxy.toml

by **Moonlight** » Fri Feb 15, 2019 2:54 am

@DF

All good!

No longer have the DNS error message and its proposed fix!

Thank you.

by **Stan** » Thu Feb 14, 2019 12:45 pm

The newest version resets DNS to DHCP, instead of leaving it on my own setting of local dnscrypt-proxy.

by df » Thu Feb 14, 2019 7:56 am

Just released v3.40, it's up on the main website now.

It includes a new "Advanced" tab under Options that allows you to change a few defaults that might help in certain network setups
(--route-method, --ip-win32, binding to a specific network adapter or IP, switching between TLSv1.2 and TLSv1.3).

Also included under that "Advanced" tab is the ability to set a SOCKS proxy to connect to before you connect to cryptostorm.
It defaults to 127.0.0.1 port 9150 because that's the default SOCKS settings for Tor Browser.
So if you want to do you -> Tor -> cryptostorm, just start up Tor Browser like normal, then in our widget select the "Use SOCKS proxy" option, then connect like you normally would.

There's also a whole bunch of bug fixes that should address issues a few people were having with previous versions, such as DNS getting left set to 127.0.0.1 even whenever DNSCrypt wasn't running, or this one error that occurred whenever the system sleeps/hibernates.

Also, upgraded OpenSSL to the latest 1.1.1a for 64-bit users, and 1.0.2q for people still using 32-bit Windows, and upgraded dnscrypt-proxy for everyone.
Normally, we would use the prebuilt OpenSSL Windows binaries from https://slproweb.com/products/Win32OpenSSL.html
but it looks like that person has started using Visual Studio 2017 for the build environment, which means that OpenSSL would require .NET 4.x to be installed, which is lame.
So we compiled our own OpenSSL binaries using a Cygwin environment, but with a MinGW compiler, that way cygwin1.dll isn't also required.

I suspect that there are some widget users who never bother going into the Options since for them, everything seems to work correctly.
If they're not paying attention to our website or Twitter, they might not know about our ECC support that was added a few years back.
To account for them, this v3.40 widget will default to ECC (secp521r1) since there's really no need to use RSA.
RSA is only necessary if on 32-bit Windows, since ECC won't work on that.

by **Moonlight** » Thu Nov 22, 2018 2:11 am

@DF

Dusseldorf and Cryptofree now working!

Thank you!

(P.S. Lately Switzerland has been so slow at night to the point of being unusable.)

by **Moonlight** » Sun Nov 18, 2018 4:51 am

@DF

Connected to Frankfurt!

Thank you.

by df » Sat Nov 17, 2018 6:31 am

@Moonlight
Try Frankfurt again. Someone else was having issues too, turns out something between their PC and the frankfurt server was mucking around with IP headers just enough to make our port striping v2 thing to not work.
So I added some extra rules to check for that.
If it works for you too, then I'll add the Frankfurt fix to the other servers.

by **Moonlight** » Sat Nov 17, 2018 4:01 am

@DF

Win 10 Pro x64 OS Build 17763.134

clean install CS widget 3.36.0.274

reboot pc

cs tap-windows adapter is set to: obtain dns server address automatically
ethernet adapter is set to: obtain DNS server address automatically

cs-dnsc-p.exe not running

frankfurt - connection stalling (no difference if dns is set to 1.1.1.1 or to obtain dns server address automatically)

(don't know how to copy with the scrolling function)

Code: Select all

OpenVPN 2.4.6 x86_64-w64-mingw32 [SSL (OpenSSL)] [LZO] [LZ4] [PKCS11] [AEAD] built on Apr 26 2018
Windows version 6.2 (Windows 8 or greater) 64bit
library versions: OpenSSL 1.1.1  11 Sep 2018, LZO 2.10
Outgoing Control Channel Encryption: Cipher 'AES-256-CTR' initialized with 256 bit key
Outgoing Control Channel Encryption: Using 256 bit message hash 'SHA256' for HMAC authentication
Incoming Control Channel Encryption: Cipher 'AES-256-CTR' initialized with 256 bit key
Local Options String (VER=V4): 'V4,dev-type tun,link-mtu 1550,tun-mtu 1500,proto UDPv4,comp-lzo,cipher AES-256-GCM,auth [null-digest],keysize 256,key-method 2,tls-client'
Expected Remote Options String (VER=V4): 'V4,dev-type tun,link-mtu 1550,tun-mtu 1500,proto UDPv4,comp-lzo,cipher AES-256-GCM,auth [null-digest],keysize 256,key-method 2,tls-server'
TCP/UDP: Preserving recently used remote address: [AF_INET]84.16.240.42:443
Socket Buffers: R=[65536->65536] S=[65536->65536]
UDP link local (bound): [AF_INET][undef]:1194
UDP link remote: [AF_INET]84.16.240.42:443
TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
TLS Error: TLS handshake failed
TCP/UDP: Closing socket
SIGUSR1[soft,tls-error] received, process restarting
Restart pause, 5 second(s)
Outgoing Control Channel Encryption: Cipher 'AES-256-CTR' initialized with 256 bit key
Outgoing Control Channel Encryption: Using 256 bit message hash 'SHA256' for HMAC authentication
Incoming Control Channel Encryption: Cipher 'AES-256-CTR' initialized with 256 bit key
Local Options String (VER=V4): 'V4,dev-type tun,link-mtu 1550,tun-mtu 1500,proto UDPv4,comp-lzo,cipher AES-256-GCM,auth [null-digest],keysize 256,key-method 2,tls-client'
Expected Remote Options String (VER=V4): 'V4,dev-type tun,link-mtu 1550,tun-mtu 1500,proto UDPv4,comp-lzo,cipher AES-256-GCM,auth [null-digest],keysize 256,key-method 2,tls-server'
TCP/UDP: Preserving recently used remote address: [AF_INET]84.16.240.42:443
Socket Buffers: R=[65536->65536] S=[65536->65536]
UDP link local (bound): [AF_INET][undef]:1194
UDP link remote: [AF_INET]84.16.240.42:443

switzerland - working (will connect only if dns set to 1.1.1.1 [when presented with the message if i want the dns set to 1.1.1.1 i say yes, but it doesn't, i have to set it up manually - this option was working as intended in previous widget versions])

Code: Select all

OpenVPN 2.4.6 x86_64-w64-mingw32 [SSL (OpenSSL)] [LZO] [LZ4] [PKCS11] [AEAD] built on Apr 26 2018
Windows version 6.2 (Windows 8 or greater) 64bit
library versions: OpenSSL 1.1.1  11 Sep 2018, LZO 2.10
Outgoing Control Channel Encryption: Cipher 'AES-256-CTR' initialized with 256 bit key
Outgoing Control Channel Encryption: Using 256 bit message hash 'SHA256' for HMAC authentication
Incoming Control Channel Encryption: Cipher 'AES-256-CTR' initialized with 256 bit key
Local Options String (VER=V4): 'V4,dev-type tun,link-mtu 1550,tun-mtu 1500,proto UDPv4,comp-lzo,cipher AES-256-GCM,auth [null-digest],keysize 256,key-method 2,tls-client'
Expected Remote Options String (VER=V4): 'V4,dev-type tun,link-mtu 1550,tun-mtu 1500,proto UDPv4,comp-lzo,cipher AES-256-GCM,auth [null-digest],keysize 256,key-method 2,tls-server'
TCP/UDP: Preserving recently used remote address: [AF_INET]81.17.31.36:443
Socket Buffers: R=[65536->65536] S=[65536->65536]
UDP link local (bound): [AF_INET][undef]:1194
UDP link remote: [AF_INET]81.17.31.36:443
TLS: Initial packet from [AF_INET]81.17.31.36:443, sid=b4513a84 634e3cce
VERIFY OK: depth=1, CN=cryptostorm CA
VERIFY KU OK
Validating certificate extended key usage
Control Channel: TLSv1.2, cipher TLSv1.2 ECDHE-ECDSA-CHACHA20-POLY1305, 521 bit EC, curve: secp521r1
[cryptostorm server] Peer Connection Initiated with [AF_INET]81.17.31.36:443
SENT CONTROL [cryptostorm server]: 'PUSH_REQUEST' (status=1)
PUSH: Received control message: 'PUSH_REPLY,persist-key,persist-tun,redirect-gateway def1,dhcp-option DNS 81.17.31.34,route-gateway 10.66.2.1,topology subnet,ping 20,ping-restart 60,redirect-gateway bypass-dhcp,register-dns,block-outside-dns,ifconfig 10.66.2.192 255.255.255.0,peer-id 0,cipher AES-256-GCM'
OPTIONS IMPORT: timers and/or timeouts modified
OPTIONS IMPORT: --persist options modified
Outgoing Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
Incoming Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
ROUTE_GATEWAY 192.168.0.1/255.255.255.0 I=14 HWADDR=00:1a:a0:c0:47:62
open_tun
TAP-WIN32 device [cryptostorm] opened: \\.\Global\{E3A13870-D906-4C80-8063-8DBC242CD57B}.tap
TAP-Windows Driver Version 9.21 
TAP-Windows MTU=1500
Set TAP-Windows TUN subnet mode network/local/netmask = 10.66.2.0/10.66.2.192/255.255.255.0 [SUCCEEDED]
DHCP option string: 06080a1f 21075111 1f22
Successful ARP Flush on interface [24] {E3A13870-D906-4C80-8063-8DBC242CD57B}
do_ifconfig, tt->did_ifconfig_ipv6_setup=0
Blocking outside DNS
Block_DNS: WFP engine opened
Block_DNS: Using existing sublayer
Block_DNS: Added permit filters for exe_path
Block_DNS: Added block filters for all interfaces
Block_DNS: Added permit filters for TAP interface
C:\WINDOWS\system32\route.exe ADD 81.17.31.36 MASK 255.255.255.255 192.168.0.1
ROUTE: CreateIpForwardEntry succeeded with dwForwardMetric1=35 and dwForwardType=4
Route addition via IPAPI succeeded [adaptive]
C:\WINDOWS\system32\route.exe ADD 0.0.0.0 MASK 128.0.0.0 10.66.2.1
ROUTE: CreateIpForwardEntry succeeded with dwForwardMetric1=3 and dwForwardType=4
Route addition via IPAPI succeeded [adaptive]
C:\WINDOWS\system32\route.exe ADD 128.0.0.0 MASK 128.0.0.0 10.66.2.1
ROUTE: CreateIpForwardEntry succeeded with dwForwardMetric1=3 and dwForwardType=4
Route addition via IPAPI succeeded [adaptive]
Initialization Sequence Completed
Sat Nov 17 08:40:29 2018 Start ipconfig commands for register-dns...
Sat Nov 17 08:40:29 2018 C:\WINDOWS\system32\ipconfig.exe /flushdns
Sat Nov 17 08:40:29 2018 C:\WINDOWS\system32\ipconfig.exe /registerdns
Connected
Sat Nov 17 08:40:32 2018 End ipconfig commands for register-dns...

Thank you.

!	Message from: parityboy
	Added code tags to improve readability of logs.

by df » Sat Nov 17, 2018 12:10 am

@Moonlight
It might be that a previous widget version caused your DNS to be set to something invalid (like 127.0.0.1 even when the widget's not running). So when this version first starts, it remembers whatever DNS settings you have on launch so that it can restore that if the program crashes. If there's invalid DNS settings on start, it'll remember that too.

I'd suggest closing the widget completely, then open up your network adapter settings ( start -> run -> ncpa.cpl ) then right clicking on whichever adapter is your main internet one (Ethernet prolly) and going to Properties -> Internet Protocol Version 4 (TCP/IP) -> Properties -> and make sure "Obtain DNS server address automatically" is selected.

If it's already set to that, then maybe a stale DNSCrypt process is running? Could try looking for cs-dnsc-p.exe in the process list (while the widget's NOT running) and if it's there then end that process.

by **Moonlight** » Fri Nov 16, 2018 6:20 pm

@DF

Win 10 Pro x64 OS Build 17763.134

CS widget 3.36.0.274

connecting tab - did not change anything (i.e. port 443, protocol UDP, Timeout 60, Random port unchecked, Let me choose the IP address checked)

security tab - all options checked and did not change anything else

rebooted the PC and now getting this message when trying to connect through Frankfurt (after having said OK to set the DNS to 1.1.1.1)

"DNS is still not functioning correctly........."

cs tap-windows adapter is set to: obtain DNS server address automatically
ethernet adapter is set to: 1.1.1.1.

no issue connecting through Switzerland

I encountered this issue with one of the previous widget (sorry can't remember which version) but it was fixed when you introduced the message option to set the DNS to 1.1.1.1. with an updated version.

by df » Fri Nov 16, 2018 2:42 pm

@Brucie
Try rebooting your system. There's a weird TAP adapter bug outside of the scope of our widget that causes the existing adapter to go into a strange read-only state.
I wasn't able to reproduce it on win7, but I did get a win10 system do end up like that.
For me, after rebooting it worked correctly.

If that fails, just open up your network adapter settings ( start -> run -> ncpa.cpl ) and manually rename whatever your TAP adapter's name is to "cryptostorm" (without the double quotes)

@Moonlight
Were you using the default connect settings for frankfurt & dusseldorf, or did you switch to TCP, or turn on ECC, or change the port? The widget defaults to RSA UDP on port 443, so I just tested RSA UDP 443 and RSA TCP 443 for frankfurt and dusseldorf, it connects fine from here with those.

by **Brucie** » Fri Nov 16, 2018 2:22 pm

df wrote:@Brucie
Oh god damnit. You're right, I just tested on a Vista VM and it still did the TAP loop thing.
Pretty sure I know what the problem is though. Apparently M$ thought it was a good idea to change the way simple IF statements work in batch files across different Windows versions. Either that or it's getting different exit codes from the TAP installer each time, even though the installation happens the same each time, which in turn causes the IF statement to do different things.

Anyways, it should be fixed now in v3.36. That's up at https://cryptostorm.nu/cryptostorm_setup.exe
I'll test first on another win7 VM, and win8.1, and win10 just to be absolutely sure before I put it up at cryptostorm.is and push it to the clients who have auto-update enabled.

EDIT:
I've tested the latest v3.36 against win7 (32-bit and 64-bit), win8.1, and win10. The TAP issue seems to be fixed.
On the 32-bit win7 I also noticed a dnscrypt related bug for 32-bit Windows, and a potential DNS bug that could have left DNS set to 127.0.0.1 after exiting the widget (which means DNS would be broken if the widget wasn't running).
All that should be fixed now. https://cryptostorm.is/cryptostorm_setup.exe has the latest build of v3.36, and I'm uploading it to all the servers now, so the new version notification should popup next time you reconnect.

Nothing changed in v3.36 for me. The same situation with loop installing TAP driver on Windows 7 go on.

Post a reply

Expand view Topic review: widget v3