cryptostorm's community forum

BillShannonA wrote: ↑ Do I have to encrypt? Is it even possible not to encrypt? Is it good enough to hide who/where I am, or do I need to hide what I am doing as well? Can I install a less stringent encryption?

Yes, you have to encrypt. It's not possible to connect to our service without encryption. What you're looking for is more of a basic proxy, which we don't offer. The reason we don't offer weaker (or no) encryption for those who want faster speeds is because that opens up everyone to downgrade attacks where people wanting the most secure option could be forced by a malicious person to use whatever the weakest algorithm is. It's basically the whole "only as strong as it's weakest link" concept.

BillShannonA wrote: ↑ How do I switch the UDP port to 53?

Edit the OpenVPN config file (.ovpn), find the four lines that start with "remote", they'll have "443" near the end of each of them.
Just change 443 to 53 to use that port instead.

BillShannonA wrote: ↑ I do not know what version of OpenVPN I am using? Is this found on the Edgerouter or somewhere else? And if I am using OpenVPN 2.5, which config do you recommend... ecc, ed25519, or ed448.

The ed25519 configs will probably give you the best speeds, but they do require at least OpenSSL 1.1.1 and OpenVPN 2.4.3.
The OpenVPN 2.5 requirement was just if you wanted to switch to the Poly1305-Chacha20 cipher.
If you are using OpenVPN 2.5, you can do that by editing the config and changing the line "cipher AES-256-GCM" to "cipher CHACHA20-POLY1305"

BillShannonA wrote: ↑ I could not find out if Edgerouter X supports AES-NI instruction. I know not what it is. I did a search for it on the Ubiquiti site. Could not find "AES-NI." I sent them a support ticket to find out if it does or not. Where do I change the cipher?

See above. AES-NI is a feature in most modern CPUs that lets the processor do AES related functions faster.

BillShannonA wrote: ↑ I am not going to try WireGuard, but thanks for that suggestion. It took me long enough to get it to work with OpenVPN.

Just try it out locally on your computer first (OpenVPN too). That will give you a baseline that you can use for bandwidth you expect to get.

BillShannonA wrote: ↑ I am in Denver, CO. The only server in Mountain Time Zone is Las Vegas. I picked Chicago because it was close to Wisconsin and I like the Green Bay Packers. Shall I try Las Vegas? Can I choose one of the balanced configs and insure that I am getting a USA server.

Vegas does have less users on it usually. If you chose the balancer configs it wouldn't ensure you connect to a US server. Most of our customers don't want to connect to US servers, so the only way to do that is to manually choose the US configs.

@BillShannonA
No VPN is going to give you speeds close to what you see when you're not on a VPN, unless the VPN has encryption completely disabled, or it's using a very weak algorithm. The encryption algorithms we use are the strongest available at the moment, and that does take resources (CPU/RAM). The Edgerouter X router only has a Dual-Core 880 MHz MIPS1004Kc CPU and 256 MB of RAM. That's not much, especially when that small device is handling the networking for a whole house of devices.

That being said, there are some things you can try to boost your VPN speeds. First, you should try to connect to the VPN from a computer, just to see what kind of speeds you get when you do it directly instead of going through the router. If the speeds are good, then it's the router. If they still suck, try switching the UDP port to something other than the default 443 (53 might help). Comcast in some regions is known to do QoS (Quality of Service) on some traffic, so the Ed25519 or Ed448 UDP configs might give you better speeds since they use ports that are commonly associated with VoIP.

The version of OpenVPN you have will also affect your speeds. If it's something ancient, the algorithms used might not be very efficient. OpenVPN 2.5 is the latest, and it includes support for the cipher CHACHA20-POLY1305 on OpenVPN's data channel (that's the part that handles your actual traffic). For any of the ecc/ed25519/ed448 configs, if you have openvpn 2.5, you can change the "cipher AES-256-GCM" line to "cipher CHACHA20-POLY1305" to use that algorithm. In my tests, CHACHA20-POLY1305 shows better performance, except on CPUs with support for the AES-NI instruction (I haven't checked if EdgeRouter X's CPU does or not).

Another thing you can try is WireGuard instead of OpenVPN. WireGuard is much faster because it uses more modern encryption than OpenVPN, and it's not a userspace program like OpenVPN is, WireGuard is a kernel-space program. So it would be a better choice for a VPN running on a small embedded device (like a router). Here's a guide DDG found: https://www.adamintech.com/install-wire ... er-edgeos/

Also, if you're geographically close to Chicago and that's why you picked that server, try picking another one, even if it's a little bit further away. Some data centers have uplinks (their ISP) that might share some of the same networks as your ISP. That means you can sometimes get better speeds on a server that's further away than another that's closer.

Hope this helps :-)

@nio
See the tutorial @ https://cryptostorm.is/macintosh.html#tunnelblick
You need to change the default OpenVPN/OpenSSL version used.
For the regular ECC configs, it needs OpenVPN => 2.4.0, and OpenSSL => 1.0.1d
For the ed25519 or ed448 configs, it needs OpenVPN => 2.4.3 and OpenSSL => 1.1.1

And WireGuard is back

The Cryptofree WireGuard page is up and running now, as is the paid nodes

All the configs on the website and github are still valid. The only server that's offline is Poland, which is why it's DNS is temporarily pointing to Frankfurt until the replacement server comes in. But all the configs should work right now.

What error are you getting?

The auth server was down for a bit. If the server-side OpenVPN can't connect to the auth server, it lets anyone in regardless of whether the token is valid/expired or not. This is so users are still protected even if the auth server is unreachable. It's back up now though, so keys/tokens should be expiring like normal. Also, as parityboy said, tokens don't start to expire until first use, so even when the auth server is behaving normally a token won't start expiring until the first time you connect with it. So a one week token purchased a year ago would still be valid today if you've never used it.

I think the problem was that cryptostorm.nu had no main A record because I deleted it a few days ago (since the box it pointed to was dead). It's since been moved to the main website's server, and I just finished putting the token checker and whatnot on it, so that might fix the widget DNS issue you two were having. The chat thing is back up too - https://cryptostorm.nu/chat

Also try disabling the killswitch temporarily by opening the same file and setting killswitch=on to killswitch=off, then re-enable it in the GUI.
There were 4 IPs in public.deepdns.net's DNS that were pointing to dead servers, they're removed now, so if that was the issue just wait a few mins for the DNS to propagate (shouldn't take more than a few minutes, caching aside) then try again

That is the latest version. Try closing the widget, then disabling DNSCrypt manually by editing C:\Program Files (x86)\Cryptostorm Client\user\config.ini and changing dnscrypt=on to dnscrypt=off (use a text editor like Notepad++ that'll correctly switch to Administrator mode since you need admin access to edit that file), then restarting the widget.

My guess is either firewall rules are preventing it, or the DNS is set to something odd. Start -> run -> firewall.cpl -> Advanced settings and check the inbound and outbound rules, remove any cryptostorm ones already there. If it's DNS, start -> run -> ncpa.cpl -> right click on your active network adapter -> properties -> IPv4 -> properties -> Obtain DNS settings automatically (or manually specify something else, like 1.1.1.1 or 8.8.8.8)

EDIT:
That part in the widget resolves public.deepdns.net, which resolves to all of the DeepDNS IPs. Since there's alot of them, it'll switch over to TCP for the response. So if you've got anything block TCP port 53, that'll also break it.

https://cryptostorm.is/blog/https-tunnels

I'm back :E
Been back a few days now, took a minute to get situated.
Busy replacing the dead servers, and redoing cs.nu, fixing/upgrading wireguard, updating ossl/vpn/ssh everywhere, killing the spam here, etc. etc.
I'll do a proper announcement after I finish some of those more urgent tasks.

works for me

Code: Select all

[root@b ~]# host switzerland.cstorm.is
switzerland.cstorm.is has address 81.17.31.49
switzerland.cstorm.is has address 81.17.31.51
switzerland.cstorm.is has address 81.17.31.39
switzerland.cstorm.is has address 81.17.31.58
switzerland.cstorm.is has address 81.17.31.52
switzerland.cstorm.is has address 81.17.31.42
switzerland.cstorm.is has address 81.17.31.40
switzerland.cstorm.is has address 81.17.31.50
switzerland.cstorm.is has address 81.17.31.44
switzerland.cstorm.is has address 81.17.31.55
switzerland.cstorm.is has address 81.17.31.43
switzerland.cstorm.is has address 81.17.31.62
switzerland.cstorm.is has address 81.17.31.36
switzerland.cstorm.is has address 81.17.31.47
switzerland.cstorm.is has address 81.17.31.54
switzerland.cstorm.is has address 81.17.31.59
switzerland.cstorm.is has address 81.17.31.61
switzerland.cstorm.is has address 81.17.31.48
switzerland.cstorm.is has address 81.17.31.60
switzerland.cstorm.is has address 81.17.31.53
switzerland.cstorm.is has address 81.17.31.56
switzerland.cstorm.is has address 81.17.31.41
switzerland.cstorm.is has address 81.17.31.57
switzerland.cstorm.is has address 81.17.31.46
switzerland.cstorm.is has address 81.17.31.45
[root@b ~]# host balancer.cstorm.is
balancer.cstorm.is has address 5.104.108.10
balancer.cstorm.is has address 185.117.118.23
balancer.cstorm.is has address 64.42.181.228
balancer.cstorm.is has address 109.71.42.231
balancer.cstorm.is has address 192.158.232.98
balancer.cstorm.is has address 5.133.8.131
balancer.cstorm.is has address 213.163.64.200
balancer.cstorm.is has address 185.94.193.237
balancer.cstorm.is has address 108.62.5.173
balancer.cstorm.is has address 167.114.84.135
balancer.cstorm.is has address 142.234.200.148
balancer.cstorm.is has address 162.221.207.74
balancer.cstorm.is has address 128.127.104.109
balancer.cstorm.is has address 178.175.139.213
balancer.cstorm.is has address 82.163.72.124
balancer.cstorm.is has address 104.152.222.6
balancer.cstorm.is has address 174.34.157.65
balancer.cstorm.is has address 109.248.149.131
balancer.cstorm.is has address 185.107.80.85
balancer.cstorm.is has address 173.208.77.65
balancer.cstorm.is has address 5.254.96.226
balancer.cstorm.is has address 212.83.189.89
balancer.cstorm.is has address 162.210.192.210
balancer.cstorm.is has address 185.212.169.142
balancer.cstorm.is has address 209.58.147.37
balancer.cstorm.is has address 84.16.240.40
balancer.cstorm.is has address 81.17.31.35
balancer.cstorm.is has address 37.120.147.4

There was another problem with the cron job we made earlier, it was trying to restart encrypted-dns before the last instance cleanly exited, which caused it to sometimes not run.
Should be good now.

EDIT:
https://github.com/jedisct1/encrypted-d ... er/pull/13
submitted a pull request so encrypted-dns-server's cert refresh is the same as dnscrypt-proxy's default of 4 hours.
our cron script seems to be doing the trick though.

The new setup is backwards compatible with the old setup, so no changes need to be made to the .toml file client-side.
Looks like the problem is that keys aren't rotating correctly, or maybe they're not rotating often enough like with the old setup.
I'll go through the code and see what the problem is, but everything should work correctly now, no more "No useable certificate found" or TIMEOUT errors.

EDIT:
Ah, there it is. The dnscrypt-proxy.toml that comes with our widget and the one on our GitHub does:
cert_refresh_delay = 240
which would refresh the cert every 4 hours (240 minutes), but the new encrypted-dns thing on the server does:
pub const DNSCRYPT_CERTS_RENEWAL: u32 = 28800;
which would refresh the cert every 8 hours (28800 seconds).
So we could change that server-side 28800 to 14400 seconds (4 hours), but I think instead we'll do a cron job that restarts the instance every 20 minutes (causing a certificate renewal too) since lower is better with that

ping and mtupath use ICMP.
So you can connect to the UDP OpenVPN instances, but when you try to do TCP things in that tunnel (like loading websites) it doesn't work?
See https://community.openvpn.net/openvpn/w ... tu-problem
My guess is your router is changing the MTU, or a setting in your local system is doing that (maybe you manually set the MTU/MSS on a network adapter at one point?). That or it's unnecessarily fragmenting things that don't need fragmentation, which would explain why TCP inside the tunnel is broken.
You can test that UDP inside the OpenVPN UDP tunnel is working correctly by resolving something, i.e. nslookup google.com

But it looks like you found the mssfix value that works for your situation, so just use that :P

The official installation guide at https://github.com/StreisandEffect/stre ... llation.md has all the info anyone would need.
Just keep in mind the second point made on https://cryptostorm.is/faq

The issue should be resolved now

Looks like there is a bug in our random IP generating code that could cause you to get assigned the internal DHCP IP as your internal client IP.
The bash code that generates the last octet for the internal IP in the server-side OpenVPN --up script is:
echo $[ 3 + $[ RANDOM % 254 ]]
The bash man page says $RANDOM is "a random integer between 0 and 32767".
That means the lowest octet is 3 (which is what we wanted), but the highest is .256, which would be invalid since that can only go up to .255.
Since we don't even want it to get to .254, I'll change the code to:
echo $[ 3 + $[ RANDOM % 251 ]]
which would still make the lowest possible octet 3, but the highest possible is now .253

I think that's great. As Mullvad mentioned in that page, there's still the issue of "closed-source (and encrypted!) firmware" in the CPU, but hopefully that'll change one day too. The open source firmware on a server platform is a good step towards that direction. The only negative thing I can say about it is that it still requires a degree of trust on the user's part, since there's no way for them to verify that a VPN provider is actually using that open source firmware.

Follow the directions on https://cryptostorm.is/nix#dnsleak

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

chrispeddler wrote: ↑
Tue Jul 16, 2019 2:38 pm
I heard that AzireVPN also works well with Wireguard. They stared strong with no logging policy an additional security they called "blind operator mode," Anyone tested it yet?

Their blind operator mode is pretty silly, even Jason (WireGuard author) says so himself - https://archive.is/ixN9A
More info about WireGuard and our no-logging policy is @ https://cryptostorm.is/blog/wireguard-privacy-concerns

@gangelop
I'm seeing something different when I use it with the Switzerland config (or anything else with multiple IPs).
For me, that `route -n|grep UGH` command only returns the route for the VPN IP that I'm connected to, not the other IPs the host resolves to.
It shouldn't be possible for there to be multiple routes like that, unless you're doing something like multihop...
Maybe a stale route was leftover because you were killing openvpn in an unclean way (SIGKILL [kill -9] instead of SIGTERM [kill -15], etc.) before reconnecting?
Also, iirc, [[:space:]] wasn't added until bash v3 or v4, and some of our clients are still running ancient bash versions (or shells like BusyBox that might not implement it), so I try to avoid things like that. Maybe I could just do VPNIP=`route -n|grep UGH|head -n1|awk '{print $1}'` instead, but then I'm not sure if the first line would have the correct IP...

@parityboy
Just had someone else in IRC showing this same symptom, where dns leak test sites would show the vpn's exit IP instead of the DNS IP.
But this person was also not able to resolve some obvious things like google/youtube/etc. from a host machine.
They were running WireGuard directly on an OPNsense router, which is similar to PfSense:

[19:43] <web_86194> I fixed opnsense
[19:44] <web_86194> I finally did it. I kept looking at the firewall logs and the addresses were being blocked every time. Only the google cryptostorm etc addresses. I messed with it for sooooooooo long and eventually i figured out that it was due to no interface adapter being added. No guide has had that in it

Not sure exactly what he meant by "no interface adapter being added", maybe the wg0 interface wasn't being created? Also dunno what the fix was since they left shortly after that.

Another thing that we noticed is that unbound is used on the router as a DNS server whose IP is pushed to the machines behind the router.
There was also no nameserver entry in /etc/resolv.conf, so the router's local DNS was also forwarded to that unbound instance using pf rules.
My suggestion was to edit unbound.conf and remove any forwarder that might already be in there and replace it with:

forward-zone:
name: "."
forward-addr: 212.129.46.32@53

But that would only work if the host was only connecting to the France VPN server.

Those messages usually mean a packet was sent by the server out of sequence, which is fairly common on cellular networks. You can safely ignore them.

By the way, if you start openvpn with `openvpn --config whatever.ovpn --daemon` it'll go into the background so you don't have to keep that terminal window open. As for knowing which config type it is (RSA, ECC, etc.), that's really only possible if you bump --verb up to something higher like 6, but even then that'll only tell you whether the config is RSA or ECC, it can't differentiate between ECC and Ed25519/Ed448 since the only difference between them is the certificate's algorithm.
Best thing to do is keep all the configs for different types in separate dirs, like the structure https://github.com/cryptostorm/conf uses. Then if you start openvpn with `openvpn --config rsa/whatever.ovpn`, you'll be able to tell which one you're using by looking at the output from `ps xa|grep openvpn`.

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

If resolv.conf doesn't support lsattr/chattr, then it's most likely mounted onto a non-ext4 filesystem.
On my Ubuntu system, /etc/resolv.conf is a symlink to /run/resolvconf/resolv.conf and /run is mounted as:
tmpfs on /run type tmpfs (rw,nosuid,noexec,relatime,size=385288k,mode=755)
You should still be able to edit /etc/resolv.conf or /run/resolvconf/resolv.conf though, so long as you're root.

As for the different terminal session thing, it doesn't matter if it's the same session or a different one. The commands still get executed as root either way, and the iptables commands apply rules system-wide, not just for that session.

Those iptables DNAT commands should be ran after connecting to the VPN, not before (since 10.31.33.8 isn't accessible until after you're connected).
Be sure to read the note on https://cryptostorm.is/nix#dnsleak about how if you've got 127.0.0.x in your /etc/resolv.conf, then you'll need to change it to something else, anything thing else, so long as it's an IP that's on the internet (I.e., not 10.0.0.0/8 or 192.168.0.0/16 or 127.x.x.x). It doesn't matter what internet IP you use because of those iptables DNAT commands, DNS would get redirected to 10.31.33.8.

Oh and you need to be root to write to /etc/resolv.conf, or anything else in /etc/. If you still get an permission denied error while trying to write to it as root, make sure you don't still have it set to immutable with the command `lsattr /etc/resolv.conf`. If it's still set to immutable, you'll see:
----i---------e--- /etc/resolv.conf
if not, you'll get:
--------------e--- /etc/resolv.conf
To remove the immutable bit, run `chattr -i /etc/resolv.conf`.
The 10.31.33.8 and 10.31.33.7 DNS servers should be working on all servers, except Latvia. We're having issues with that one, still trying to figure out what's up with it. Everything else should be good though.

Not really, they both perform the same task. It's just that it's Linux, so there's more than one way to do the same thing.

just do a `grep ^up whatever.ovpn` to check the up lines in the config.
The update-resolv-conf script doesn't use iptables, it updates /etc/resolv.conf
But killswitch does use iptables for DNS leak protection.
You can check if those rules are still there with `iptables -L -n -t nat`
But if they were still there, DNS would fail when trying to connect.

It doesn't matter whether the script-security line is before or after up/down.
Only other thing I can think of is that there's more than one up/down line, that would also cause the killswitch not to run (like if your config is still using the old update-resolv-conf thing for DNS leak prevention).

That scenario #3 kill switch will remove the kill switch if OpenVPN exits "cleanly" (like it does via NM).
You can test it by killing openvpn with `killall -9 openvpn` then trying to ping 8.8.8.8

It should also stay active if you keep the --up part but remove the --down part, but I haven't tested with NM. It's possible that NM is changing something in the config before or after it gets loaded, which is often the case with most OpenVPN GUIs.
Try it out using openvpn at the terminal instead. If that works, then verify that the config NM is actually using still has those --up/--down lines (I think NM stores configs somewhere in /etc/NetworkManager).
Also, don't forget to include a --script-security 2 in your config, otherwise the --up/--down scripts won't run.

The page on http://10.31.33.7/fwd only accepts a single port per request, so your script would need to do it multiple times per port.
Since you're using a script to connect to the VPN, you could add something like this that would run after being connected:

Code: Select all

#!/bin/bash
declare -a ports=(
31340
31341
31342
)
for port in "${ports[@]}"; do
 resp=`wget -T4 -t1 -qO- http://10.31.33.7/fwd --post-data="port=$port"`
 if [ $? != 0 ] || [[ `echo $resp|grep Error:` ]]; then
  echo "Port $port $resp"|head -n1|sed -e's/<.*//'
  exit 1
 fi
 echo $resp|sed -e's/<.*//'
done
exit 0

Replace 31340, 31341, and 31342 with the actual ports you want to use, then have your VPN connecting script call the one above after connecting (or just embed the above code into your script, minus the #!/bin/bash).
You could also add better error reporting to the bit after resp= so that instead of just echoing errors (like if a port's already in use or the connection to 10.31.33.7 times out, or whatever), you could instead have it email you or send the error to a logfile, etc.

Yea, comment out or remove those existing lines. The killswitch script does it's own DNS leak protection, so using the update-resolv-conf script isn't necessary.
And yes, you would have to remove the config from NM and set it up again for NM to see the changes.

@parityboy
Maybe you're right, something in pfSense changed recently... the .i2p/.onion/.bit/etc. thing works by first resolving to something in 10.0.0.0/8 (10.99.0.0/16 for .onion, a single 10.98.0.1 for .i2p) and the VPN server sees the client trying to reach one of those ranges and forwards it to the proxy running on the server to get the whole thing to work.
So if pfSense is doing something else with those ranges, or if it doesn't know to route those ranges to the tunnel interface, then the transparent .onion/.i2p thing would fail.

As for the DNS leak test failing, I can only see that happening on a host behind the router, and only if the host is set to use DHCP and a DNS server running on the router (which would be connected to CS, and maybe set to use the DNS pushed by the VPN).

Do you have any custom iptables rules that are doing any SNAT or DNAT or MASQUERADE?
Because I can't think of any other reason why an exit IP would show up in the whoami results or the dnsleaktest one, since none of the exit IPs are running any DNS servers.
That's why `host whoami.cryptostorm.is 88.202.180.213` fails, but `host whoami.cryptostorm.is 82.163.72.123` goes through, since the former is a VPN IP, the latter is one of our public DNS IPs.

@parityboy
Weird... Not sure how that could happen.
What do you get if you go to: https://aeopfieahofherurt.dnsl.cryptostorm.is/ ?
That's the backend site that loads the images containing IPs, the "aeopfieahofherurt" bit can be any random letters.
The IP in the image is what the custom DNS server sees as making the request for that "aeopfieahofherurt" hostname.

@parityboy
You sure it's exit node IPs that's showing? Because it shouldn't do that...
The custom DNS server behind it works the same way whoami.cryptostorm.is does, i.e. it only sees your DNS IP, no direct connection to the custom DNS server should happen.
If you do `host whoami.cryptostorm.is` it should show you the same thing as https://cryptostorm.is/dnsleaktest

I haven't noticed that issue, but I don't use ipleak.net often. My go to is usually dnsleaktest.com.

We also have our own at https://cryptostorm.is/dnsleaktest that might work better for some people.
It's kinda BETA-ish, so it might fail to load completely, sometimes, but it seems fine so far in our tests.

Those DNS leak test sites work by resolving a random sub-domain (or sub-sub-domain) against a domain's DNS server, which is configured to log requests, then the page checks that log and tells the visitor what the DNS client's IP was.
The problem is that those random sub-domains usually don't resolve to anything, so you have to wait for your browser to timeout the DNS request before the page will finish loading. That might cause problems in some cases, especially if you're doing a bunch of other stuff and there's a limit set somewhere on how many things can be in a "waiting for timeout" state.

In our DNS leak test page, the random sub-domains resolve to a real IP of a web server setup to actually respond to requests, so no waiting for the timeout to finish. And just because, we wrote ours to work without JavaScript =D

See the very bottom of https://cryptostorm.is/multihop
it includes some info on how to do this.

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

https://cryptostorm.is/wireguard just went live :-D
Be sure to check out https://cryptostorm.is/blog/wireguard-support-added too for info on device limits and whatnot

EDIT:
Like it says on https://cryptostorm.is/wireguard and https://www.wireguard.com/ -

WireGuard is not yet complete. You should not rely on it. It has not undergone proper degrees of security auditing and the protocol is still subject to change.

We've been playing with it since 2016 and it doesn't seem like the protocol is going to change significantly anytime soon, so it should be stable enough to use now.
But keep in mind, it hasn't had any proper audits, so you shouldn't be using it for high security scenarios.
If you just want better speeds for torrenting or whatever, it should be fine for that.

We're working on the interface for it now. Almost done.

Yea, if you save the default page it will save the HTML, which OpenVPN doesn't know how to read.
Need to click the "Raw" button, or download the master.zip, or download from https://cryptostorm.is/configs/ instead.

@marzametal
The node list used by the widget is at https://cryptostorm.nu/nodelist4.txt
and an easier to read version is at https://cryptostorm.nu/nodes.txt

The whitelist that contains all the VPN IPs is at https://cryptostorm.is/whitelist.txt
and the one with all the DNS IPs is at https://cryptostorm.is/dns.txt

The problem here is that the update-resolv-conf script needs to be added to the OpenVPN configs.
https://cryptostorm.is/nix#dnsleak has the instructions

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

@marzametal
What block-outside-dns thing?

No, of course not. Just update the file that contains your token (or it's hash), the file that's called by auth-user-pass in the openvpn config file.

I'm pretty sure this was a temporary issue.
The .onion's aren't hosted on this web server, they're hosted on our Romanian server using a simple nginx reverse proxy that relays to the clearnet websites.
Since that'll cause the Romanian server's IP to show up in things like https://cryptostorm.is/test (which was confusing a few people), we changed the reverse proxy to also go over Tor when relaying to the clearnet sites, which is why now when you goto the main site's .onion it'll say at the top that you're on Tor and show some random Tor exit IP.
So now it does you (on tor) -> our .onion on the romanian server -> tor again -> https://cryptostorm.is (or .nu/.org/whatever)

It's usually best to host .onion's on the same server that's hosting the website, especially when you've got a .onion-only website.
But since our .onions are just relays to the clearnet sites for people who can't access them regularly, or don't want their ISP knowing that they're accessing them, there wasn't any harm in hosting them on the Romanian server.

Yea, just use CoinPayments for BTC.
Bitpay's BTC thing is weird, doesn't use wallet addresses like normal, it uses some new payment protocol they're trying to push.
That's why with BitPay, only the wallets listed at https://support.bitpay.com/hc/en-us/art ... ompatible- will work.

FYI, TS is disabled by default because a lot of people were complaining about it, mostly because they wanted to do something similar themselves.
If you want to use TS now, set your DNS to 10.31.33.7

Well I was going to delete this old thread, but since KungFuChe showed that it's still relevant, I'll keep it up :-)

There's just the one Cryptofree server in France. If you want more location options, buy a token :-P

https://github.com/jedisct1/dnscrypt-pr ... tion-linux for DNSCrypt

A killswitch will need to be written yourself, depending on your needs.
We have one at https://cryptostorm.is/killswitch_user.txt that applies a killswitch to a specific user, it should make it relatively easy to write up one that works system-wide, or network-specific, depending on what you want to do.

IPv6 can be disabled by adding to /etc/sysctl.conf:
net.ipv6.conf.all.disable_ipv6 = 1
net.ipv6.conf.default.disable_ipv6 = 1
net.ipv6.conf.lo.disable_ipv6 = 1
followed by the `sysctl -p` command.

Connect on startup can be done with init.d scripts or ifcfg scripts.

We don't normally provide information for doing the above on Linux since all of that information can be found with a few simple DuckDuckGo searches, and because most of our Linux clients run a whole mess of different networking scenarios, distros, and threat models that might not require those specific instructions.

The old theme wasn't supported in the latest phpBB, and I really didn't feel like going through changing colors in the current theme.

v3.42 is up now.

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

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

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

@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

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

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

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

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

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

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

Sounds like you're probably using a browser addon like NoScript that's preventing the checkout page from working correctly.
Disable it, or add *.coinpayments.net to your whitelist, then try again.

Ah, that's right. In the ancient 2013 post @ viewtopic.php?f=38&t=5981 PJ describes in his round-about way something that sounds an awful lot like VORACLE, which was the reason we've (almost) always had compression disabled.
IIRC, back then we had a mixture of "comp-lzo no" in the server configs and "comp-lzo" in the client configs.
The latter would normally default to "adaptive" compression, which the manual describes as:

"Adaptive compression tries to optimize the case where you have compression enabled, but you are sending predominantly incompressible (or pre-compressed) packets over the tunnel, such as an FTP or rsync transfer of a large, compressed file. With adaptive compression, OpenVPN will periodically sample the compression process to measure its efficiency. If the data being sent over the tunnel is already compressed, the compression efficiency will be very low, triggering openvpn to disable compression for a period of time until the next re-sample test."

But then the server would push "comp-lzo no", overriding the client-side "comp-lzo", essentially disabling LZO.
At least, until OpenVPN 2.4 came around. As I stated in https://cryptostorm.is/blog/new-features -

"In certain mixtures of the client running OpenVPN 2.3 and the server running 2.4, "--comp-lzo no" doesn't disable compression, it instead enables LZO compression with the stub algorithm, which means it's still vulnerable to VORACLE."

So compression might have been used in certain setups in the past.

I just talked to someone else who had this same issue, they also were using the app from Google's Play Store.
The problem ended up being that Google Play Store has v0.7.5 of the app, which uses OpenSSL 1.1.0h, and the Ed25519/Ed448 configs require at least OpenSSL 1.1.1.
F-Droid has version 0.7.6, which uses OpenSSL 1.1.1
http://plaisthos.de/android/ics-openvpn-0.7.7.apk has the very latest 0.7.7, which uses OpenSSL 1.1.1a

So either install the one on F-Droid or install the .apk from the link above

@Moonlight
Yes, all of the nodes are running a DNSCrypt server. With the widget, all you need to do is enable the DNSCrypt option, it'll start in the background and your DNS settings will be changed to point to that DNSCrypt instance.

We no longer offer any official support for Windows XP since Microsoft stopped supporting XP in April of 2014, and OpenVPN themselves stopped supporting it early last year. In 2017, Microsoft did release security patches for the vulnerability the WannaCry ransomware exploited, but that was a major vulnerability that they needed to do something about. Most other vulnerabilities in XP are never going to be patched.

You won't be able to use our widget to connect with XP since it explicitly checks if your Windows is older than Vista, but it is still possible to connect to our servers (including Cryptofree) using an older version of OpenVPN GUI.
OpenVPN 2.4 isn't supported on XP, but the last 2.3 version is (2.3.18).
If you're using a 64-bit version of XP, you can find OpenVPN GUI 2.3.18 at http://build.openvpn.net/downloads/rele ... x86_64.exe
or if you're using a 32-bit version of XP, that installer is at http://build.openvpn.net/downloads/rele ... p-i686.exe

Once you have either of those installed, the only configs of ours that'll work with it are the RSA ones from https://cryptostorm.is/configs/rsa/
The Cryptofree RSA configs are at https://cryptostorm.is/configs/cryptofr ... a-udp.ovpn for UDP and https://cryptostorm.is/configs/cryptofr ... a-tcp.ovpn for TCP

Keep in mind that using such an old version of OpenVPN (and OpenSSL) will downgrade the security of your VPN session to --tls-cipher TLS-DHE-RSA-WITH-AES-256-CBC-SHA and --cipher AES-256-CBC, but you will still get 8192-bit DH params (--dh), and 521-bit EC (~15360-bit RSA) for the CA (--ca), and 8192-bit RSA for the TLS certificate (--cert).
That combined cryptography is still considered very secure, but it's nowhere near the best available that you would get with a more recent version of OpenVPN/OpenSSL.

I just updated my Windows 10 Home VM to the latest, and updated Windows Defender to the latest (threat definition version: 1.283.2606.0), and I'm not seeing anything about the CS widget being detected, nor is any new firewall rules blocking it....

But then again, Microsoft doesn't use a single database for threats. From what I can tell, there's different versions of that database for each different version of Windows, and probably different versions for each edition of Windows (Pro, Home, Server, etc.).
So even though nothing is being detected on my VM, something in the widget might be getting detected on another edition of Windows 10.

To add an exception to Windows Defender: Open the "Windows Defender Security Center" from the start menu, click on "Virus & threat protection", then "Virus & threat protection settings", scroll down a bit and you'll find "Exclusions". Click "Add or remove exclusions" then "Add an exclusion", and from that drop-down list choose "Folder". Type into the new window:

C:\Program Files (x86)\Cryptostorm Client

then click "Select Folder".
That should tell Windows Defender to exclude all the widget's files from being scanned or deleted due to false positives.

As for Windows Firewall, you can edit your firewall rules by opening "Windows Defender Firewall with Advanced Security" from the start menu. In that screen, check any blocking rules (they'll have a red circle with a line in the middle) for anything that might have to do with the widget. Be sure to check both Inbound and Outbound Rules. I'm not sure if adding an exclusion for the widget would work if there's already another rule blocking it, so you might need to find and remove that rule first.
You could try to simply enable the killswitch from the widget's Options -> Security section. That'll add rules to the Windows Firewall to allow all the CS related IPs through, and block all other IPs that aren't on your LAN.

@parityboy
No, it's always been enabled, at least until Oct of last year

I'm sure you already have, but if not, you need to upgrade to the latest v3.36 widget. It fixes most DNS issues.
The --block-outside-dns option is now pushed from the server if you connect from Windows (either via the widget or OpenVPN GUI).

To tell your client to ignore that pushed setting, in the widget just disable the DNS leak prevention option, or in OpenVPN GUI add to your config:
pull-filter ignore "block-outside-dns"

EDIT:
Oh yea, the pull-filter option was added in OpenVPN 2.4.0, so if you're using an earlier version the above won't work.
But the only reason you would be using OpenVPN < 2.4.0 is if you're on 32-bit Windows, and if that's the case you should really upgrade to a 64-bit Windows.

I haven't heard of anything like this happening, but my suggestion would be to make sure you're using the latest OpenVPN for Android app from http://plaisthos.de/android/ics-openvpn ... stable.apk

Other than that, check the logs and see if anything unusual is there (or post it here and we'll look into it)

FYI, even when you're using our DNS servers, it's still regular DNS, which is very easy to manipulate or block entirely.
To bypass anything like that, use our DNSCrypt servers instead. Most DNS blocking methods won't block that since it's TCP port 443, and it doesn't look anything like DNS.

I just posted an update in that other thread. Basically, those commands will only work if your distro branch/version is listed at https://build.openvpn.net/debian/openvpn/stable/dists/

@FoodMaven
You need to change the "auth-user-password" line in /etc/openvpn/cstorm_linux-lisbon_udp.ovpn to point to a file containing your token (or it's hash) on the first line, and any random text on the second line.
Otherwise it'll try to prompt you for the user/pass, but since you're not running OpenVPN from an interactive terminal, it'll give you the error that you saw.

I guess any of the styles at https://www.phpbb.com/customise/db/styl ... _styles-12 would work (just the ones that say "3.2.5"), but I'm not sure how to go about switching the styles on a per-user basis (via the UCP)

Notice the time/date stamp in the original post of this thread, it was started way back in 2013, so there's some outdated things here.
But at the very top of the page (and every other page here), there's the notice "Ξ any OpenVPN configs found on the forum are likely outdated. For the latest, visit here or GitHub Ξ"
with links to https://cryptostorm.is/configs/ and https://github.com/cryptostorm/conf/
Those two are the only place you should download configs from since they're up to date.

The separate ca.crt file is indeed not needed anymore since it's embedded in all the client configs.
I'm not sure if uploading config.zip will work since not every OpenVPN web UI will recognize and automatically unzip zip files like that.
But if you can login via SSH, you can download the same zip file from there and unzip it from the terminal.

I don't know what OpenWRT firmware version you have, but the first thing you should do is check your OpenVPN version with the command `openvpn --version`
https://cryptostorm.is/configs/ has a list of the four config types and their supported OpenVPN/OpenSSL versions:
RSA - Works with OpenVPN 2.3.2 through 2.4.6, and OpenSSL 1.0.0 through 1.1.1a
ECC - Works with OpenVPN 2.4.0 through 2.4.6, and OpenSSL 1.0.1d through 1.1.1a
Ed25519/Ed448 - Requires at least OpenVPN 2.4.3 and at least OpenSSL 1.1.1

Keep in mind that both the Network Manager and Terminal instructions on https://cryptostorm.is/nix were intended for Ubuntu.
They'll work on a few other Debian based distros, but not ones that aren't up to date or have their own version/branch names (such as Linux Mint).

Here's a simple(ish) script that'll automate checking if your distro is supported:

Code: Select all

#!/bin/bash
if ! [ -f "/etc/lsb-release" ]; then
 echo "Error: /etc/lsb-release does not exist"
 exit
fi
codename=`grep DISTRIB_CODENAME= /etc/lsb-release|awk -F= '{print $2}'`
if [ "$codename" == "" ]; then
 echo "Error: Could not find DISTRIB_CODENAME in /etc/lsb-release"
 exit
fi
if [ "$(command -v wget)" == "" ]; then
 echo "Error: Could not find the wget command"
 exit
fi
wget -qO- https://build.openvpn.net/debian/openvpn/stable/dists/$codename > /dev/null
if [ $? == 0 ]; then
 echo $codename is supported
else
 echo $codename is NOT supported
fi

save that to somewhere and chmod +x it and run it. It'll grab the distro codename from /etc/lsb-release then check if it's listed on https://build.openvpn.net/debian/openvpn/stable/dists/

They only have a few Ubuntu/Debian ones listed there though. For other distros you'll need to use whatever version your package manager installs, or if you want the latest OpenVPN/OpenSSL you'll have to install from source.

On Linux Mint and Debian and a bunch of others, installing from source would look something like:

Code: Select all

[[ $UID == 0 ]] || exec sudo -p "[?] This program requires root privileges. Please enter the password for %u to continue: " -- "$BASH" -- "$SELF" "${ARGS[@]}"
cd /usr/src/
apt install -y build-essential zlib1g-dev liblz4-dev liblzo2-dev
wget http://www.openssl.org/source/openssl-1.1.1a.tar.gz;tar zxf openssl-1.1.1a.tar.gz;rm -f openssl-1.1.1a.tar.gz;cd openssl-1.1.1a;./config --prefix=/usr -fPIC no-gost shared zlib enable-ec_nistp_64_gcc_128 -Wl,-rpath=/usr/local/ossl111a/lib --prefix=/usr/local/ossl111a;make depend;make;make install
cd /usr/src/
wget http://swupdate.openvpn.org/community/releases/openvpn-2.4.6.tar.gz;tar zxf openvpn-2.4.6.tar.gz;rm -f openvpn-2.4.6.tar.gz;cd openvpn-2.4.6;CFLAGS="-I/usr/local/ossl111a/include -Wl,-rpath=/usr/local/ossl111a/lib -L/usr/local/ossl111a/lib" ./configure --disable-plugin-auth-pam --prefix=/usr;make;make install

That'll install OpenSSL 1.1.1a to /usr/local/ossl111a (so as not to cause conflicts with anything else on the system that might rely on the OpenSSL version you already have installed), then it compiles and installs OpenVPN 2.4.6 against that OpenSSL install.

Search found 434 matches