cryptostorm's community forum

Ξ welcome to cryptostorm's member forums ~ you don't have to be a cryptostorm member to post here Ξ
Ξ any OpenVPN configs found on the forum are likely outdated. For the latest, visit here or GitHub Ξ
Ξ If you're looking for tutorials/guides, check out the new https://cryptostorm.is/#section6 Ξ

Looking for a bit more than customer support, and want to learn more about what cryptostorm is , what we've been announcing lately, and how the cryptostorm network makes the magic? This is a great place to start, so make yourself at home!

UPDATE: a cable fault was determined to be the cause of hang at splash screen (need to trap PHY errors)

Also noticed some state corruption related to suspend/resume. Observed the following issues:

- widget appears in tray but connection is not routed through VPN
- widget disappears from tray but VPN connnection still active
- widget crashes on exit request and clearnet connectivity is not restored (but can reconnect to VPN if widget is relaunched)

@KungFuChe
XP is no longer supported. Anyone still on XP will have to stay on the older v2.22, which won't receive any new updates, unless some horribly vulnerable issue is discovered in the openvpn/openssl that version uses.
It's usually a bad idea to provide backwards compatibility for an OS version that stopped receiving security updates several years ago.
I do plan on doing more tests regarding the different ways internet can be disconnected and how to detect it so the widget responds accordingly.
Same goes for the different CPU features and architectures, and the systray issues that seem to vary by Windows version.

@ATurtle
If anyone is still using XP, they clearly don't care about security.
You could argue that Microsoft updates doesn't equate to security (which is accurate), but since XP hasn't received security patches for several years now, using it under any pretense is just plain dumb.
Maybe in a system/VM that's offline, or behind such a restrictive firewall that nothing's possible... but then what's the point?

So just looking for an update, and it looks like I can't upgrade the client? Even running as admin on Windows 8.1 gives me the following error:

Of course, watching that file, it gets created, and what looks like a temp file, and then this error pops up. So something is trying to change the client.exe before this happens.

Any ideas?

---------------------------------------------------------------------------------------------------You derive personal satisfaction from the continued existence of the near perfect day-night cycles of the hyper cube.....

&#9658; Show Spoiler

Hidden Content

This board requires you to be registered and logged-in to view hidden content.

@JTD121
Do you get that error when running cryptostorm_setup.exe? If so, you should exit the widget before you begin the installation. Windows can't overwrite client.exe if it's already running. Although, the installation should detect if the widget is already running and ask if it's okay to close it before attempting to overwrite it.

@df, Y'know, I don't know what the issue was, but I restarted this specific laptop and just tried again, and it worked without a hitch.

Previously I made sure the client.exe and csvpn EXEs weren't running, so maybe it was pending OS updates?

Since we're on the subject, any updates past 3.0.0.72?

---------------------------------------------------------------------------------------------------You derive personal satisfaction from the continued existence of the near perfect day-night cycles of the hyper cube.....

&#9658; Show Spoiler

Hidden Content

This board requires you to be registered and logged-in to view hidden content.

Hey, just joined cryptostorm last weak, I've a question, will there be a client based on opoenvpn 2.4?
Also how are plans going for an android client?
Thanks!
It's pretty awesome what a great service with many good Ideas you build!
Realy looking forward what you will create in the future!
Thanks!

noticed this too but unsure of your present OS type...
This happens if you are also running another DNScrypt instance.

with simplednscrypt (windoze) you will just need to re-select your earlier dnscrypt enabled servers from the dropdown menu.
And to re-select the adapters for which dnscrypt has temporarily changed ie the TAP/tun adapters and LAN adapter

Then, if other nameserver values still remain ,
you only have to remove-and-reinstall the DNSCrypt service.

through a few mouse clicks (and there is no need to uninstall/reinstall the present dnscrypt software you are using).

If the service is up and listening on the correct ports

Primary nameserver ---------> 127.0.0.1 (port 53) and

sec. nameserver #2 -------------------> 127.0.0.2

the gui is easiest route if unsure about terminal based commands.

Those with only the dnscrypt-proxy service installed have to type the stuff via the console/terminal method. Or restart the service under "Services"

i opened cryptostorm a couple of days ago and it asked and performed an update. Since then I have not been able to connect, it hangs at the point "Logging into the darknet". I have uninstall and reinstalled with no luck. I have also removed OpenVPN and halted the AV software during the re-installation. How do I get the logs to see what is causing the issue as area where the logs are usually visible is black. I am running Windows 10 32 bit version.

redman wrote:i opened cryptostorm a couple of days ago and it asked and performed an update. Since then I have not been able to connect, it hangs at the point "Logging into the darknet". I have uninstall and reinstalled with no luck. I have also removed OpenVPN and halted the AV software during the re-installation. How do I get the logs to see what is causing the issue as area where the logs are usually visible is black. I am running Windows 10 32 bit version.
Screen.PNG

It does still tend to crash if you put the PC to sleep while it is running though. (Win 7 laptop) That isn't a huge issue in itself, as the old version used to fairly reliably die or get confused when sleeping too. Fair enough - if it is disconnected for a while the VPN connection is bound to drop. What *is* more of an issue is that it fails open now.

So if I restore my lappie from sleep, the client is minimised in the taskbar and refuses to be restored, I am no longer connected to the VPN, and (unprotected) Internet access is working. Previously when the client had a connection error, it would also break Internet access in general until it was closed.

Cannot resolve windows-switzerland-cryptostorm.net:443 (No such host is known. )
This usually means something is wrong with your DNS settings.

Also not getting immediately another windows with the error message:

Error: Cannot resolve windows-switzerland.cstorm.pw

While the widget is still open with the error message, I go the DNS settings which are now 127.0.0.1. I change them to Obtain DNS server address automatically, and click connect again, and it is now connecting.

Had I exited the widget after the error message and then change the DNS to Obtain DNS server address automatically, I would get the same error connection message.

This happens every morning (after overnight shutdown of the PC and modem) since the change over from the Narwhal widget. When the PC and modem are shutdown during the day (for a couple of hours), no issue reconnecting.

Don't know if and how this issue can be fixed.

Suggestion

2. When I lose connection I am not getting immediately (it is taking a long time and it does not come on top) on top of everything another windows with the error message (like for the Narwhal widget):

Error: Cannot resolve windows-switzerland.cstorm.pw

I become aware of the lost connection because pages are no longer loading and the small widget icon in the taskbar has discreetly become red.

Would appreciate if this issue can be looked into and possibly resolved with the next release.

The same thing is happening to me that Moonlight is describing. "Obtain DNS server automatically" must be set manually back every time I disconnect or get disconnected from cryptostorm before I can reconnect to the internet or to cryptostorm. Sometimes the widget leaves the DNS that it set from DNScrypt. Sometimes it's 127.0.0.1.
It's been like this for me since the last big build update to Windows 10 64 bit

Also, "network reset" in windows 10 Network and Internet settings no longer repairs the issue, for me. It has in the past though so some may want to try it. Just open network and internet settings scroll all the way to the bottom and there it is. The system will reboot and may or may not fix your issues.

Included in this latest widget is access to the new ECC (Elliptic-Curve Cryptography) instances, which use the strongest available crypto OpenVPN 2.4.x has to offer. You can turn on this feature by going to Options -> Security and selecting the "Use ECC instances" checkbox. Only for 64 bit Windows, since these features require OpenVPN 2.4.x, which has dropped support for 32 bit Windows.
The server/CA certificate for these instances is also using EC, which means smaller key size with better (or equivalent) crypto, which generally means better speeds.
More info about these instances can be found at https://github.com/cryptostorm/cryptost ... master/ecc
and if you want to learn more about the specific configuration directives used, there's comments on almost every line of each of those configs explaining them.

Also included is a killswitch! You can turn it on under Options -> Security then clicking "Enable killswitch".
It'll turn on when you press the Back button to go back to the main window.
It uses Windows firewall to block everything except our VPN server IPs and our DNS IPs, so if your internet disconnects or your connection to the VPN is severed, you won't leak anything to the internet.
Of course, since this is Windows, I would still recommend using an external device to implement your own killswitch on your router/firewall, since it's known that Microsoft has the ability to remove firewall rules remotely.

The other changes are mostly bug fixes, such as better handling of DNS settings when switching to/from dnscrypt-proxy. This should fix the problem people were having where DNS was getting left at 127.0.0.1 after exiting the widget.

It no longer changes my DNS to 127.0.0.1 when I exit the widget, but it still changes it to that when I first open the widget every time and once I exit settings to go back to the main screen of the widget. Also, the random port checkbox must be selected every time the widget is opened. It will not stay selected once the widget is closed then reopened.

That's a no on both. It works fine as long as DNSCrypt is disabled. I hope I can resolve this though.
I like DNSCrypt and appreciate your help and the time you have taken developing the widget and all of it's features for us. I'm looking forward to seeing what else is coming. I just bought another 1yr token today.

In this version, almost all of the DNS related code was rewritten to automatically address a lot of the previous issues people were having.
The widget now "pre-resolves" the host you're connecting to. One reason for this is that it allows the widget to detect (and fix) common DNS related issues, such as a firewall blocking DNS or DNS not being set correctly before the widget runs.
If the system's default DNS isn't working correctly, the widget will first try to use DNSCrypt (if it's not already enabled, and only after asking the user if that's okay). If that fails, the final fix is to switch to Cloudflare's 1.1.1.1 DNS server (again, only after asking the user if that's okay).

Another reason for the pre-resolving is that it's needed for the new feature "Let me choose my exit IP", available under Options -> Connecting.
When you select that option, a window will pop up when you connect to a node, and if that node has more than one IP associated with it (most do), it'll let you choose which one to use.
It also includes a "Remember my choice" option so that it'll automatically choose that IP next time you connect, useful for those with the "Automatically connect" option enabled.
If you want the widget to forget one of your IP choices (or all of them), you can also do that under Options -> Connecting. If you have any IPs remembered, a drop down list will appear there with all the IPs you've saved, and under that a "Forget" button.

Another new feature is that TrackerSmacker ("TS"), our DNS-based ad/tracker blocking service, is now optional. It's enabled by default in the new widget, but if you want to disable it you can now do so under Options -> Security. More info @ https://cryptostorm.is/ts

In version 3.16, a minor bug caused the widget to not remember your node selection choice when the widget starts (it kept defaulting to "Global random").
I also added some new text when DNS fails with the killswitch enabled, because some people were enabling the kill switch without enabling DNSCrypt or setting their system/network's DNS to a CS one, which of course would be blocked by the killswitch to prevent DNS leaks during pre-connect.
Now it'll explain that they need to use our DNS or enable DNSCrypt, otherwise the killswitch won't allow DNS out.

@RubRiches
It's just a false positive. The CS widget installer randomly gets caught up in their database because it uses the same compression (LZ4) as some trojans.
I use a local win7 VM for widget dev, and the only thing installed on it is the stuff needed for widget dev (Perl, Notepad++, etc.).
I do file integrity checks on that stuff to make sure when I downloaded them they weren't MiTM'd.
The widget installer's hashes were generated on that local VM, and they're checked on the remote VM I use to build the widget, and then they're checked a final time when they're put up on the website.

For instance, it can enter your machine when you click on a malicious link, provided on YouTube, Facebook, Skype, visit a phishing web portal, put infected removable media drive onto your machine, etc. Besides, it is also known that Trojan: Win32/Fuery.B!cl has been spread through Java vulnerabilities and Adobe Flash

Yea, I'm not using/doing any of that crap on any of the VMs or servers.

Anyways, I'll do what I did last time this happened: send M$ a false positive report so they'll remove it.

EDIT:
I just tested with Windows Defender on win7 and win10 with updated databases, they didn't find anything in the latest installer.

df wrote:@RubRiches
It's just a false positive. The CS widget installer randomly gets caught up in their database because it uses the same compression (LZ4) as some trojans.
I use a local win7 VM for widget dev, and the only thing installed on it is the stuff needed for widget dev (Perl, Notepad++, etc.).
I do file integrity checks on that stuff to make sure when I downloaded them they weren't MiTM'd.
The widget installer's hashes were generated on that local VM, and they're checked on the remote VM I use to build the widget, and then they're checked a final time when they're put up on the website.

For instance, it can enter your machine when you click on a malicious link, provided on YouTube, Facebook, Skype, visit a phishing web portal, put infected removable media drive onto your machine, etc. Besides, it is also known that Trojan: Win32/Fuery.B!cl has been spread through Java vulnerabilities and Adobe Flash

Yea, I'm not using/doing any of that crap on any of the VMs or servers.

Anyways, I'll do what I did last time this happened: send M$ a false positive report so they'll remove it.

EDIT:
I just tested with Windows Defender on win7 and win10 with updated databases, they didn't find anything in the latest installer.

Huh, that is weird. I ran Malware bytes and my system is ok.
No worries though I was able to download the new version and now I am stuck on the progress bar while connecting.

Would it be safe to assume that the above means if I choose a random node to connect to in the widget, then all nodes will be attempted to be pre-resolved... and if I choose one specific node from the dropdown, then just that one will be pre-resolved?

Also, is there any documentation that shows me which country the server names relate to? eg: brabant, blocko, etc...

With the new additions to the widget, have to sorta' redesign my firewall rules to accomodate. Just trying to get enough info to work with... thanks in advance!

UPDATE:
What is the IP address that is referenced when I want to update node list?
Not sure is cryptostorm.nu is down? Just saw this post from @df "about node list"
Is it still 212.83.185.245

@marzametal
Each VPN instance uses a different 10.x.0.0/16 B-class, mostly because if I used the same B-class (or C-class) for multiple instances, two different clients might be assigned the same 10.x.x.x IP.
There's a check in place to prevent that from happening per-instance, but not per-server, so each instance gets it's own B-class.

On the newer servers that have large(ish) IP pools assigned to them (currently: frankfurt, paris, england, romania, ussouth, and switzerland), I'll usually start at 10.60.0.0/16 and increment it by one per IP.
But some of those servers (frankfurt, paris, and romania) are using new IP pools plus the above ranges, because
those three weren't new servers, they were just old ones I bought more IPs for.
Doing it that way on those three servers meant I could setup the new instances without disturbing the VPN sessions of people who were connected to the old instances.
For england, ussouth, and switzerland, they were new servers so I didn't have to bother with working around old instances. So for those 3, they only use 10.60.0.0/16 and onward (highest atm being 10.149.0.0/16).

Some time in the near future there might be more 10.x.0.0/16 networks used when other things get added (new instances for obfuscation protocols, wireguard [if they ever release a stable branch of that], etc.)

As for your firewall rules against 10.0.0.0/8, the only reason to do that would be to prevent your machine from accessing other things in your LAN (if your LAN is also in 10.0.0.0/8), since the networks listed in RFC1918 (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16) can't reach the internet.

If you're using a local firewall on the same machine you'll be connecting to cryptostorm with, you should keep in mind that the CS 10.0.0.0/8 traffic is only going out on the tunnel interface/adapter. The interface/adapter for your internet connection (eth0 in Linux, "Ethernet" in Windows, etc.) will only see traffic from you to the public/internet CS VPN IP.
Knowing that, you could add an exception to the local firewall so that only the tunnel interface can reach 10.0.0.0/8 (Usually tun0 in Linux, or whatever the TAP network adapter name is in Windows).
That way you can still prevent your machine from accessing the rest of your LAN by blocking access to 10.0.0.0/8 on your other non-tunnel interfaces/adapters.

If your firewall is on the network's router, and you're connecting to cryptostorm using a machine behind that router, it won't be seeing your traffic to the CS 10.0.0.0/8 network since that'll already be encrypted by the time it reaches your router.
So for that setup, you should be using the public CS IPs for a killswitch. You could even setup a rule based on source IP, for when you only want to do a killswitch for one or specific machines on your network.

If you're doing both the killswitch and connecting to cryptostorm on your router, then the stuff I said the paragraph before the last one would apply.

EDIT:
And yes, cryptostorm.nu is still @ 212.83.185.245, and the widget still uses that to check for nodelist updates.
And if using an external killswitch, with the new IP pools, you can't just use the balancer's DNS anymore since not all IPs are listed there.
You could do what the widget does and load all the hosts from https://cryptostorm.nu/nodelist3.txt (I.e., `awk -F: '{print $NF}' nodelist3.txt`), then resolve them, then add those IPs to your firewall.
FYI: If you add a hostname to an iptables rule, it'll add all the IPs that hostname resolves to.
If you don't wanna do that, https://cryptostorm.is/whitelist also has a list of all the possible exit IPs.

Regarding your question about the server names, I've gone ahead and updated https://cryptostorm.is/whitelist to also include the region in the comments, next to the server name:

Tried unchecking ECC instance, then DNS leak etc... but no good.
Please see if there is something I need to do.

One more request can you guys improve the widget as such that I don't have to exit the widget to go to Options while it is trying to connect.

Yea, the malware bytes scan means it was just a false positive.
For your progress bar issue, is csvpn.exe running? Open up the task manager and go to the processes tab to see.
If it is, check with cryptostorm.is/test to see if your IP changed.
If not, or if csvpn.exe isn't running, then something else is most likely closing csvpn.exe (That's OpenVPN).
Try adding to both Malware Bytes and Windows Defender an exclusion for the folder C:\Program Files (x86)\Cryptostorm Client\

As for your last request, that design is intentional. Allowing the user to change options while connecting can cause leaks or other unexpected results. The only way to prevent those issues would be to create more CPU threads that constantly check for option changes, which would make the widget's overall CPU utilization a lot higher than it needs to be. Instead, I choose to simply disable the options button while connecting/connected.

@marzametal

marzametal wrote:
Would it be safe to assume that the above means if I choose a random node to connect to in the widget, then all nodes will be attempted to be pre-resolved... and if I choose one specific node from the dropdown, then just that one will be pre-resolved?

If you choose "Global random", it just resolves "windows-balancer.cstorm.pw" (or .cryptostorm.nu, i forget).
If you choose a specific node, it only resolves that one.
Basically, it does the exact thing OpenVPN would have done, only now that it pre-resolves it allows me to check for common DNS errors. Once the pre-resolve is done, it gives OpenVPN the IP you pick.

The only time all the hosts (balancers and nodes) are resolved is whenever you enable the killswitch, since that's now necessary due to those new servers with the bigger IP pools.

I have noticed that all relevant DNS addresses relating to the specific node you are connecting to have to be reachable to prevent the user being asked if they want to go to 1.1.1.1

I found this out because I use a DNS Proxy, and since for this example, USA SOUTH has 3 DNS addresses, if two are commented out in my proxy configuration file, and the widget references one of the commented DNS addresses,then it throws that option.

So, to prevent the 1.1.1.1 reference, for those who use a DNS Proxy such as Acrylic, uncomment all DNS addresses relating to the node you want, and then post-connection comment out the ones that were not used by widget.

Also, for those who use Acrylic (not sure how this would be done for other DNS Proxy software), I now have two entries that bypass 127.0.0.1 and go straight to the DNS Server (on router have CS DNS entries)... without these two entries, every time I click on the UPDATE button for node list, it would time out, and when the latest widget would resolve on connection, it would also time out... just for those who are interested
NAME1=cryptostorm.nu
NAME2=cstorm.pw

Thanks for adding the extra information on the whitelist df... makes things easier!
Keep up the good work!

I knew I was doing something wrong!
"10.5.0.2-10.5.255.254,10.44.0.2-10.44.255.254,10.66.0.2-10.66.255.254,10.84.0.2-10.84.255.254,10.86.0.2-10.86.255.254,10.88.0.2-10.88.255.254,10.92.0.2-10.92.255.254" this is what it looks like at the moment for an outbound rule hahaha

Fixed a GUI issue some had when running Windows at a non-default scaling setting.
It would cause the progress bar to overlap a little bit with the "Connect" button.
In the Options window the "Block intrusive ads/trackers" wouldn't be visible to the user.

Some people complained that the previous version would open an extra cmd.exe
The reason for that is that OpenVPN 2.4.6 now requires a password to be specified for the management interface, which the widget opens on 127.0.0.1
Previously, the widget was doing a simple

to start OpenVPN.
That echo command is why the extra cmd.exe was being created and left open.
Now, the management password is stored in a temporary file in the "user" folder, so an extra cmd.exe isn't left in the process list.
And that management password is changed on every connect for added security.

I also modified the LZMA2 compression configuration for the installer, which seems to make all the AV false positives go away. But from now on, I'll scan the latest installer @ virustotal.com and jotti.org just to make sure there's not any false positives before I release it.

I'm not sure if this is the most relevant topic to come up with this issue, but: every time I update the CS widget it screws up my DNScrypt-proxy. I need to reinstall it, otherwise no adresses resolve. This turns a simple update into quite a hassle. Especially since DNScrypt-proxy is hard to configure but after that it needs no maintanace, so by the time I need to reinstall it I forget how to configure it and have the relearn the whole thing.
I've seen that the CS widget has a DNScrypt-proxy too, and I'd gladly use that, but it can't be configured at all, and when I don't connect to the VPN my ISP-s DNS server will be used.

Is there any way to make the widget not conflict with the proxy or to have it's own proxy a better use?

I'd use the bundled DNScrypt-proxy, but it seems to work only when connected to the VPN service. I can't configure anything on it and even though dnscrypt-proxy.exe is running in the background when the client is started (but only then), still my ISP's DNS servers are used. Even if I start the dnscrypt-proxy.exe manually, still sometimes it canges the DNS server, sometimes it doesn't.
So, unless there is a solution to use the bundled DNScrypt-proxy when not connected to the service (that would be optimal), I'm better off with the official proxy. The problem is, that when I update the CS client, it asks to turn off the installed DNScrypt-proxy, and then I can't just re-enable it, I have to reinstall it.

Cannot connect with ECC default checked (all other options in security tab are checked as well).

Tried the 3 different ECC options and cannot connect either.

Unchecked the ECC option and still cannot connect.

No error message, just displaying not connected.

Tried Switzerland, Germany (both), Sweden and Canada West.

2.

Went back to 3.18.0.201 (after complete uninstall of 3.30.0.217)

Can connect but option to select exit node (Switzerland and Canada West) is no longer working - do not think it's related to latest win10 update (3 Oct) as I had the option yesterday for Switzerland (a quickly disappearing message says something about skipping IP as there is only one?).

Also now when I exit from the security tab, I get the following message : Error: Cannot resolve voodoo-windows-isleofman,cstorm,pw:

On a side note, a few days ago the 185... Switzerland exit node disappeared, it was a good one as I was not prompted for a captcha for several sites compared to the current 81.17.31.38. Less captcha with 81.17.31.40 yesterday, but still.

@Moonlight
See https://cryptostorm.is/new
We've changed some things around, and got rid of the voodoo instances (for now).
3.30.0.217 includes all these changes though. I'd suggest trying to disable different things in the security tab to see if any of those are causing issues (the killswitch, dnscrypt, etc.)

@Moonlght
v3.32 should fix a DNS issue that happened whenever people had several network adapters with ambiguous names, or more than one TAP adapter, or a oddly named TAP adapter.

It's possible that one of the last versions permanently changed your DNS settings even when the widget is closed, which might be the cause of that 1.1.1.1 message.
I'd recommend making sure your DNS settings for your main network adapter are set to whatever they should be.
See http://solverbase.com/w/Windows_10:_Cha ... NS_Servers for instructions, just replace Google's 8.8.8.8 in their example with "Obtain DNS server address automatically" or whatever static IP you normally use for your non-VPN DNS.

@marzametal
The blocking of outside DNS issue should be fixed now in the latest version that's up now.

The dns proxy thing is clashing with dnscrypt-proxy because the widget is bundled with it's own dnscrypt-proxy.
I renamed the one the widget comes with to cs-dnsc-p.exe so that when it checks the process list to see what thing is already listening on port 53, it'll close your dnscrypt-proxy instead of the widget's (if you allow it to).
If you want to use your dnscrypt-proxy instead of the widget's, just untick the dnscrypt option in the widget and make sure your main adapter's DNS is set to 127.0.0.1

@Moonlight
Ah, there's the damn problem. The killswitch adds the VPN IPs all in one line using netsh advfirewall, but there's a character limit in the command prompt.
The VPN IPs including the balancer IPs brings the total to > 600, so it hits that character limit and that cmd spits out an error.

Seems like even with the error, most IPs do get added to the firewall's whitelist, but the IP list is getting cut off, which is probably why Cryptofree + Switzerland + Frankfurt didn't work for you.

Oh and I just noticed Switzerland's iptables rules were reverted back to the pre-port striping v2 rules, so the stuff at https://cryptostorm.is/blog/port-striping-v2 wasn't applied on Switzerland.
That's why the ECC instances weren't working there, since the new ECC configs default to port 443 (same as RSA), which requires those rules to be in place.

So Switzerland has been fixed, and v3.35 of the widget was just put up on the website.

Also in v3.35 is a fix for this weird TAP adapter issue where it would be stuck in a loop of installing/deleting/reinstalling the TAP adapter.
Reason for that bug was that https://community.openvpn.net/openvpn/w ... nameScript doesn't work on Windows 10, but it did in Windows 7.
Instead of using that batch script, I rewrote it to instead use `openvpn --show-adapters` to get the TAP adapter's GUID, which is the part of the TapRenameScript that's broken on Windows 10.

df wrote:
Also in v3.35 is a fix for this weird TAP adapter issue where it would be stuck in a loop of installing/deleting/reinstalling the TAP adapter.
Reason for that bug was that https://community.openvpn.net/openvpn/w ... nameScript doesn't work on Windows 10, but it did in Windows 7.
Instead of using that batch script, I rewrote it to instead use `openvpn --show-adapters` to get the TAP adapter's GUID, which is the part of the TapRenameScript that's broken on Windows 10.

This bug still is on. v3.35 don t even connect to nodes on win7. Check it please!

@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.

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.

@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.

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.

@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.

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])

@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.

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.

@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

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.

@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.