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

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

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

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.

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

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

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

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.

@DF

Win 10 Pro x64 OS Build 17763.134

Clean install CS widget - all options checked

Feedback

1.

3.35.0.271

switzerland and vancouver no issue connecting and loading sites

cryptofree - can connect but cannot load any sites, error message take too long to respond

frankfurt & dusseldorf - connecting half way through and then stall - so cannot connect


2.

3.36.0.274

switzerland, vancouver and cryptofree no issue connecting and loading sites

frankfurt & dusseldorf - connecting half way through and then stall - so cannot connect

staying with 3.36.0.274


Thank you for your time and patience!

@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: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!

@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

Win 10 Pro x64 OS Build 17763.134

Clean install CS widget 3.33.0.263

all options checked

Feedback

1.

on loading widget getting "Error: &dnscrypt:"

clicking ok, then can connect

2.

cryptofree - can connect but cannot load any sites, error message take too long to respond

switzerland - connecting half way through and then stall - so cannot connect

frankfurt - same issue as for switzerland

vancouver - no issue

3.

uninstall 3.33.0.263

install 3.32.0.219

switzerland and frankfurt no issue connecting and loading sites

4.

uninstall 3.32.0.219

install 3.33.0.263

switzerland and frankfurt - connecting half way through and then stall - so cannot connect

5.

going back to 3.32.0.219 and switzerland

@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

I still get blocking of outside dns even after unticking the relevant option and adding it to custom.conf. How to remove this option?

Also the dns proxy is clashing with dns crypt. The widget turns dns crypt off now after a warning.

I disappear for a month and everything is changed! Wow.

@DF

1. ipconfig /flushdns

2. Followed all your instructions and still getting the error message.

Have another machine (same win 10 build initially) and no error message.

As I can connect, I won't take your time any further, I will look into it when I'll rebuild it i.e. clean install of win 10.

Thank you for your time!

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

Feedback for 3.32.0.219

Win 10 Pro x64 OS Build 17763.55

Installed 3.32.0.219 on top of 3.31.0.218 and it's all working :

all security options checked
ECC default
choice of exit nodes available
no error messages

On a side note (minor), getting the message do I wish to set the DNS to 1.1.1.1 always come up even though it's already set to that (checked it again just after appearance of the message).

Thank you!

Win 10 Pro x64 OS Build 17763.55 (previously 17763.1)

3.30.0.217 was working yesterday but stopped today, even with all security options unchecked.

Went back to 3.18.0.201 (not clean install), and connected immediately.

Downloaded 3.31.0.218, installed it on top and it's all working :

all security options checked
ECC default
choice of exit nodes available
no "Error: Cannot resolve voodoo-windows-isleofman,cstorm,pw:" message

On a side note (minor), getting the message do I wish to set the DNS to 1.1.1.1 always come up even though it's already set to that (checked it again just after appearance of the message).

Thank you!

@DF

Win 10 Pro x64 OS Build 17763.55 (previously 17763.1)

Re-installed 3.30.0.217 again on top of 3.18.0.201

All working now :

all security options checked
ECC default
choice of exit nodes (more added?) available again
no "Error: Cannot resolve voodoo-windows-isleofman,cstorm,pw:" message

Thank you!

Hi, I am also having issues after upgrading to 3.30.
I can only connect to "Global Random" as any other nodes only attempts a connection but then nothing , ends in not connected.

I have tried turning all the security features off but it makes no difference...

When I manage to connect to Global Random, no dns is available.. Or at least no dns lookup works . not even for cryptostorm.is.

Where can I get ahold of v3.18 to attempt a downgrade until the issues have been solved?

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

Hi,

Win 10 Pro x64 OS Build 17763.1

CS widget 3.30.0.217

Feedback

1.

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.

Thank you.

It seem that my reply wasn't posted. I try to post again.

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.

@Sakura
The CS widget uses a bundled DNScrypt-proxy to protect pre-connect DNS. If you'd prefer to use your own DNSCrypt setup, simply disable ours by going to Options -> Security and uncheck the "Enable DNSCrypt" box.

If you'd like to use our DNSCrypt servers, https://raw.githubusercontent.com/crypt ... proxy.toml has a list that's compatible with the latest DNSCrypt-proxy v2.
If you're still using DNSCrypt-proxy v1, the list you should use is @ https://raw.githubusercontent.com/crypt ... olvers.csv

Some of ours are included in the official DNSCrypt resolvers list @ https://dnscrypt.info/public-servers , but they don't keep it as up to date as ours is.

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?

Forgot to update this thread with info on the latest build.

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

@RubRiches

RubRiches wrote: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.

This is where it is stuck:
Sat Jul 07 07:52:09 2018 us=54756 [cryptostorm server] Peer Connection Initiated with [AF_INET]213.163.64.210:5060
Sat Jul 07 07:52:10 2018 us=150762 SENT CONTROL [cryptostorm server]: 'PUSH_REQUEST' (status=1)


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.

@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 older servers that only have 4 VPN IPs, there's 6 instances:
win TCP, ECC TCP, linux TCP, win UDP, ECC UDP, linux UDP
On those servers, I generally stick to networks:
10.33.0.0/16 for linux UDP
10.34.0.0/16 for linux TCP
10.44.0.0/16 for win UDP
10.45.0.0/16 for win TCP
10.54.0.0/16 for ECC UDP
10.55.0.0/16 for ECC TCP

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:

don't worry about the updating node list issue... I went a bit spastic during a copy and paste and ruined a rule!

By the way, I've noticed when it connects now...
Sat Jul 07 00:57:18 2018 us=108037 C:\Windows\system32\route.exe ADD 128.0.0.0 MASK 128.0.0.0 10.84.0.1

How often does the 10.84.0.1 change?
In the past 3 connections, I've seen it go from 10.84 to 10.88 and then 10.94...

No big deal, just means I gotta broaden the rules haha

"The widget now "pre-resolves" the host you're connecting to"

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

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.

So it's highly unlikely that something as simple as "Win32/Fuery.B!cl" is going to find it's way into the widget installer (unless your system is already infected ).
http://deletespywares.blogspot.com/2017 ... rybcl.html -

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.

This is where it is stuck:
Sat Jul 07 07:52:09 2018 us=54756 [cryptostorm server] Peer Connection Initiated with [AF_INET]213.163.64.210:5060
Sat Jul 07 07:52:10 2018 us=150762 SENT CONTROL [cryptostorm server]: 'PUSH_REQUEST' (status=1)


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.

Thank @df

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

So it's highly unlikely that something as simple as "Win32/Fuery.B!cl" is going to find it's way into the widget installer (unless your system is already infected ).
http://deletespywares.blogspot.com/2017 ... rybcl.html -

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.

Hey Guys,
Windows defender detected a Trojan and blocks the download.
Trojan detected is Trojan:Win32/Fuery.B!cl and Severity level is High. Please check and update.

Did some research and this looks like a Trojan.

Err, make that version 3.17.0.220.

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.

Also upgraded dnscrypt-proxy to the latest v2.0.15.

New version 3.16.0.220 is out, available at https://cryptostorm.is/cryptostorm_setup.exe

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

Although not specifically a widget feature, we now allow port forwarding as well. Details on that are available at https://cryptostorm.is/portfwd

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.

@crimghost
When you first open the widget or when you exit settings, does DNS get set to 127.0.0.1 even if the DNSCrypt option is disabled?

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.

New widget build released just now, v3.13.
Those of you on v3.12, you should get a prompt informing you of the new version then asking you if you want to upgrade.
For anyone else not already using the widget (or using < v3.12), it's available at https://cryptostorm.is/cryptostorm_setup.exe with hashes @ https://cryptostorm.is/cryptostorm_setup.exe.txt

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.

Source code is up at https://github.com/cryptostorm/cstorm_w ... /client.pl if anyone's interested.

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.

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

Hi,

Win 10 Pro OS Build 16299.192

CS widget 3.12

Feedback

1.

DNS set to 185.60.147.77 (Switzerland)

Clicking connect getting error message within the widget:

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.

Thank you.

New client seems to be working pretty well!

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.

and after downloading a new version (3.12) it works again

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

This is exactly where it al stops for me
(but i try the paid servers)

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.

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"

Next you could try :

/nslookup cryptostorm.is

to determine the current resolvers

Is there an "undo" batch file or instructions anywhere?

It seems this version of the launcher can leave you with strange DNS settings after it's uninstalled, even if you deselect dnscrypt before uninstalling it.

Presumably it tweaks other settings as well that aren't properly reset to defaults.

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!

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

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

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?

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

Thank you very much.

@rwilcher
The latest one is always at https://cryptostorm.is/cryptostorm_setup.exe

What is the correct v3 widget I should get ? Confusing.

Just built a new widget v3.0.0.72 that includes code that now saves that connect timeout value (Under "Options" -> "Connecting") so it's remembered on restart.

Also OpenVPN/OpenSSL binaries/libraries upgraded to 2.3.16/1.0.2l.

Latest hashes for https://cryptostorm.is/cryptostorm_setup.exe -
crc32: 6fe993a6
md4: 2c09931daadb7ac8e88401422364c0ea
md5: 47a1d8d88fbe1c9b8655669af25f65a9
ripemd160: 0d233cd5f3c4842c772df06f2ebb4d42eccf93d0
sha1: b87c4cf014e70b8eabb462d2330388f9f87ce4a8
sha256: f9cabb029ea14a30feff44a33ed2ec8b73f9508d5840eb0bb495b7ab6bf4e083
sha384: ded51f638c8cef40a9a2ea268360d90ef213e6bf049a5aa5e427f027bc867ea2e65e767a332d9a564110b168903bab00
sha512: 3b6f4e4c14880f77dd980edcd9bbb414d83ed183a8dce91c9801858d6cedc53ceea1acb39bb567fa4f0b0e8ae3aded3f03858790d6efdd3805a7a9f687a828e0
wpool512: e407fe382d3f31d3189b0f237feb41a6541e7be1e5f1dfbfa75d6baedeae1ff815af2d32f2a3a8f6b5c16ddee18926443a5364e0d096150682bf9c1179aa4342


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

I have been running v3 for 3 days now. Have seen no instability
under Windows 10. Works like a champ so far.

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)

+ Suggest testing for OS/CPU compatibility

(example: dont install latest TAP driver on XP/POSready, dont install binaries with SSE2 instructions on unsupported CPU)

PS - forum says you can edit your posts but edit button does not appear at the next login

some good progress is being made on the widget here but i see a major issue on some 32 bit platforms:

client.exe hangs at splash screen with high CPU load
(the initial window with the controls does not appear)
then it constantly retries some I/O read operation - looks like it might involve a call to mswsock.dll (WSPStartup)
this produces a memory leak: client.exe allocates +1 MB every 2 seconds until system halts
nothing related is seen in event log

not really looking for old platform support - just pointing out that v2 was working so if you are going to fail now lets make a clean exit

on other platforms where it works, i see some issues with suspend / resume:
upon resuming client.exe is still running and it appears in tray
- but nothing happens when you click on it (and https://cryptostorm.is/test fails)
so the user must manually test connectivity every time the machine wakes
need some way to fail safe (= no access without VPN)

Is it possible to get a comprehensive comparative of issues that the windows widged is supposed to fixes and features added that might not exist or lack on linux/mac osx with other clients?

Im a recent CS user on OSX with tunnelblick and as relative novice I would like to be informed if I can try to improve things on my side? Already disables ipv6 altogether :p

thanks

Currently using Tunnelblick and dropped by to make a little prayer for a mac/linux port of widget Much love x

@justintime
Just as parityboy said, Windows requires more effort to make things more secure/anonymous.
It's non-trivial to run DNSCrypt along with OpenVPN while also blocking DNS, WebRTC/STUN/ICE, and IPv6 leaks in Windows.
On Linux, it is trivial. Plus, most of the issues that the Windows Widget fixes don't even exist in Linux.

@parityboy
MD5 and SHA1 are considered broken, but in order for someone to perform a collision (like if they were able to manipulate the cryptostorm_setup.exe file and wanted to get past integrity checks), they would have to cause the other hashes to change too (md5 collision would change the sha1 and sha512 hashes, sha1 collision would change the md5 and sha512 hashes, etc.). That's why you should check all 3 hashes.
Even so, here's the sha256 hash of the last build (v3.0.0.71): d93e388f90b8177f3dcc16365e25c575f1be64df7a6a1b9caca13bbae87f1733

The only reason I'm still including SHA1 and MD5 hashes is that there's a lot of free products (like https://www.microsoft.com/en-us/downloa ... x?id=11533 ) that only does MD5 and SHA1, and a lot of people are probably using one of those programs.

If anyone out there is using one of those programs that only supports MD5 or SHA1, try out https://sourceforge.net/projects/simplehasher/
It's free and supports a lot more ciphers (more than I've provided for the .exe actually), and is pretty easy to use.

@justintime

Most Linux users know enough to handle their security issues in terms of firewalls, leaks etc. Not only that, but also consider that those security features are in the widget because...Windows. However, you do have a point: as desktop Linux becomes more popular, that popularity will be represented by users who are not as familiar with Linux and network security as us *nix heads are.

I'm a bit shocked/surprised that there is ONLY a windows widget version. CS has always prided itself on being as secure as possible, and I don't understand why that wouldn't include Unix? The windows widget has many added security features...

But anyone who is REALLY concerned with security, is either running it on Linux, or on their router which means they cannot take advantage of any of these extra security enhancements.

I left CS a year ago, waiting for this to be released, but it still hasn't happened yet

It just feels wrong on so many levels.

@df

Why are you still posting MD5 signatures for the widget? Would it not be better to deprecate it and replace it with SHA-256, if you still want to provide 3 hashes?

Just a thought.

Great update! Installing now!

Nice update! Thanks.

New widget build out, v3.0.0.71
hashes:

md5: 6bf40dd09b2b7851849e5630e24f7121
sha1: 747e75eaaa623f5dcbbd6ed22430d4f5235989ee
sha512: 31bb34f65c73788e7f5149c295f649ad5b6ca6b07f2d113891bf64d2007efdee648473a127ff7bb868314b4e5e2c340fc028aaa81babee3d11d402440518843f

Up at the usual places, https://cryptostorm.is/cryptostorm_setup.exe and https://b.unni.es/cryptostorm_setup.exe

The main feature in this build is better closing of the openvpn process, so your session counter will decrease instantly when you disconnect or exit.
In all the previous builds it was doing an 'unclean' kill of that process, which meant the server didn't recognize your disconnect until the server-side openvpn timed out the connection, which takes 2 minutes.
Now it should happen instantly, so no more auth failures when you quickly disconnect/reconnect.

The other feature is in Options -> Connecting, you can now specify that 60 second connect timeout to something a little higher if you need more than 60 seconds to connect (like if on bad WiFi).

@crimghost, you should come along into the IRC Support channel. We lurk and talk about random stuff, sometimes actually support new users such as yourself

Well, I fixed it.
Windows Settings, Network & Internet, in the Status tab all the way at the bottom click "Network reset". It auto reboots the system and then after that it was fixed.
Sorry for the confusion, and for cluttering your thread here when the problem was on my end.

PS I ended up buying a 1 year token with CS. Very impressive service. Nothing else came close after extensive research and testing.

Some other weird things about it:
My connection to the internet works if I also go down a digit as well. So, if I changed ***.**.147.76 to ***.**.147.75 That change also repairs the connection. So one digit either up or down makes it work

When I use the v3 client to connect at the end I get the green bar that says I'm connected and no errors are reported even though I cannot browse the internet with any standard browser. Firefox, Microsoft Edge, Brave Browser all don't work. Tor Browser however, does work even before any changes are made by me manually to the Primary DNS IP address.

The only thing that I've installed recently was mullvad's windows client, in order to compare VPN services. That has since been completely uninstalled and the system has been rebooted, and the problem remains.

@Khariz
The widget does manually set the DNS if DNSCrypt is enabled. Everything else is done via TAP, but there might be some code still in there that's leftover from before --block-outside-dns was implemented into OpenVPN, back when the widget had to do the DNS leak blocks itself.

@crimghost
That is very weird. There's nothing in the code that does any sort of math against any DNSCrypt server IP, and the DNS server IP you get when you connect is pushed directly from the server...
You sure you're not running any other software that might be modifying your DNS settings?

I find that exceptionally weird considering the fact that the widget should not be manually setting the DNS IP to the actual servers IP address anyway, it should be sending it to the tap adapter gateway. I wonder if some setting is being pushed differently from the servers than it used to be.

I've run into a problem where when I connect to Cryptostorm service, no matter which server I connect to, the v3 client sets my preferred DNS server 1 digit too low. So my browser cannot connect to the internet until I go into Windows 10 settings and manually increase the final digit on the right 1 digit higher than client v3 sets it automatically.
To be clear if client v3.0.0.67 sets my preferred DNS to ***.**.147.76 I cannot connect until I go in and manually set my preferred DNS to ***.**.147.77 instead. Every server I've tried works fine once I make this change though.