ATTENTION
We'll be deprecating our RSA OpenVPN configs soon.
See this post for more details

Search found 485 matches

by df
Wed Sep 15, 2021 7:42 pm
Forum: guides, HOWTOs & tutorials
Topic: HOWTO: OpenWRT Routers
Replies: 23
Views: 128693

Re: HOWTO: OpenWRT Routers

Locking this old thread since we now have an OpenWrt guide at https://cryptostorm.is/openwrt
by df
Sat Sep 11, 2021 12:14 am
Forum: member support & tech assistance
Topic: GL-INet Slate router and CS wireguard
Replies: 1
Views: 558

Re: GL-INet Slate router and CS wireguard

It's just bad security if we generated your public key for you like that, since we would also have to generate your private key too. There's just too many security issues with doing something like that in the browser.

Most routers I've seen that support WireGuard don't have any way to generate keys from their web interface. You'll probably need to SSH into the device and manually run a command like:

wg genkey | tee privatekey | wg pubkey > publickey

That'll generate a private key and save it to the file 'privatekey', and from that it'll generate a public key to the file 'publickey'.
To view each one do `cat privatekey` or `cat publickey`
Most likely the router's web interface will ask for that private key. Our website needs the public key.

If you can't SSH into the device, another option is to use the official WireGuard app on any other device. Just create an empty profile, copy down the private key and public key that's generated from there, and feed the private key into the router's web interface, and the public key into our cryptostorm.is/wireguard. We don't have a GL-Inet device to test with, so I'm not sure what the exact position of the buttons/pages are, but it's generally the same concept with all supported routers (generate keys, import keys into interface, add peer, setup networking so all traffic goes through wg0, etc.)
by df
Sat Sep 11, 2021 12:03 am
Forum: general chat, suggestions, industry news
Topic: cryptostorm vs ivpn comparison
Replies: 3
Views: 3213

Re: cryptostorm vs ivpn comparison

@donmccarlos
What part are you having trouble understanding?
by df
Sat Sep 04, 2021 6:22 am
Forum: member support & tech assistance
Topic: public sshtunnel?
Replies: 1
Views: 2180

Re: public sshtunnel?

The only thing those tunnels can connect to is cryptostorm servers, so you still need to be a paying customer in order to make any use of them.
The idea behind the SSH (or HTTPS) tunnels is just to make your VPN traffic look like SSH traffic instead, in case VPN protocols are blocked.
Our free server does also support SSH tunneling though.
by df
Sun Aug 15, 2021 7:56 pm
Forum: member support & tech assistance
Topic: Default port forwarding
Replies: 16
Views: 22704

Re: Default port forwarding

Just noticed this thread because ExpressVPN asked me to remove a link to their /what-is-my-ip page in that one post by Main Sequence. My guess is they're either switching domains or moving that page to a different URL, or something, so went ahead and redacted that from his post.

Anyways, to answer OP's question, all TCP and UDP ports from 1-29999 will appear to be open if you scan any of our VPN entry or exit IPs. That's because of our https://cryptostorm.is/blog/port-striping-v2 setup that allows clients to connect to the service on any port (from 1-29999). Normally, having more open ports means less security, because usually a separate service/daemon is using each port, and more services = more potential attack vectors. In our setup, that's not the case since all of those ports are just forwarding to OpenVPN or WireGuard. That's why port forwarding is restricted to ports 30000 and up, because < 30000 is reserved for the "port striping" feature. So no, you can't use a port < 30000 for forwarding, even if you have that port open locally, any connections to that VPN IP on that port would forward to our OpenVPN/WireGuard, not to your open port.

As for Main Sequence's issue with the real IP showing up in the swarm list, that's normal. It doesn't mean your real IP is being broadcasted to the entire swarm. It's only showing up on your end because your torrent client is connecting to the VPN's IP on the port you're forwarding, which is causing you to connect to yourself (from your IP). The rest of the swarm only sees the VPN IP. That's what the cryptostorm.is/torrentip page is for, to show exactly what the rest of the swarm would see.
by df
Thu Jul 22, 2021 3:08 am
Forum: cryptostorm in-depth: announcements, how it works, what it is
Topic: widget v3
Replies: 279
Views: 1882439

Re: widget v3

v3.49.0.52 released - https://cryptostorm.is/cryptostorm_setup.exe
  • Change:The chosen cipher (AES-256-GCM or CHACHA20-POLY1305) wasn't remembered on next launch, now it is
  • Change:Added the Tokyo and Sydney nodes to the node list
by df
Sun Jul 04, 2021 10:13 pm
Forum: cryptostorm in-depth: announcements, how it works, what it is
Topic: We're deprecating the RSA configs
Replies: 0
Views: 4328

We're deprecating the RSA configs

We'll be deprecating our RSA OpenVPN configs soon, so if you're still using those you need to switch over to the ECC ones (or use WireGuard).

The reason we're doing this is because the RSA configs only exist for people using ancient 2.3.x versions of OpenVPN, and according to https://community.openvpn.net/openvpn/w ... edVersions version 2.3.x reached it's end-of-life last month.
We've kept supporting it for this long because a handful of stubborn clients are still using 2.3.x, probably on certain embedded devices that sometimes make it difficult to upgrade, but it's time to force those clients to upgrade. The last 2.3.x release was on Sep 25, 2017, so if you're still using 2.3.x, you really need to upgrade.

Another reason we've had the RSA configs for so long is that a lot of our clients use Ubuntu, and Ubuntu's repos are slow about updating the OpenVPN plugin for Network Manager, which is also slow at supporting new features in OpenVPN. https://gitlab.gnome.org/GNOME/NetworkM ... aster/NEWS says they didn't add support for 'tls-crypt' until version 1.2.10, and they didn't add support for 'tls-version-min', 'tls-version-max', and 'compress' until version 1.8.12. https://packages.ubuntu.com/search?suit ... chon=names says everything is using 1.8.12, except bionic which is still on 1.8.2. So if you're still using bionic, you should use the terminal to connect to the VPN instead of Network Manager, or just upgrade.

If you try to use the RSA configs on a more recent OpenVPN you'll notice that it gives warnings about the "cipher AES-256-CBC" config directive. That's only there so that it'll work with those ancient OpenVPN versions, the server would still negotiate the cipher to AES-256-GCM if your OpenVPN supports it, and the TLS cipher would upgrade to whatever the best available is too. It's still more secure than the defaults most VPN providers use, but it's adding confusion for a lot of new customers, especially the ones new to Linux. Even though we've been recommending the ECC configs for years now, a lot of them are still using the RSA configs instead. So to avoid the confusion, and because of the other reasons listed above, we're ditching the RSA configs.
by df
Sun Jul 04, 2021 4:06 am
Forum: general chat, suggestions, industry news
Topic: cryptostorm vs ivpn comparison
Replies: 3
Views: 3213

cryptostorm vs ivpn comparison

This is a response to https://twitter.com/prince_ghee/status/ ... 6113477633, since this would be way too many characters for twitter's limit.

We can't evaluate whatever IVPN is doing server-side since that information isn't public, so we're only going to take a look at their OpenVPN client-side configs and infer what we can from those.
Their UDP configs are at https://www.ivpn.net/releases/config/iv ... config.zip and their TCP configs are at https://www.ivpn.net/releases/config/iv ... ig-tcp.zip
All of their configs are pretty much the same, only the host/CN names are different, and the TCP configs have "proto tcp-client" while the UDP ones have "proto udp".

The first thing that catches my eye is that they're still using the "AES-256-CBC" cipher for the "data channel" (the thing that actually encrypts your traffic). That cipher is still considered secure, but it's not the best available anymore. The more efficient AES-256-GCM has been supported in OpenVPN since version 2.4.0, which came out in 2016. Our recommended configs have plenty of technical details on this at line https://github.com/cryptostorm/cryptost ... P.ovpn#L87
We added support for AES-256-GCM as soon as it was available, around 5 years ago. These days we also support CHACHA20-POLY1305, which became available with OpenVPN 2.5.0's release in late 2020. I didn't do any test connects to IVPN, but it is possible that their server-side config is doing cipher negotiations when you connect, so that AES-256-GCM or CHACHA20-POLY1305 is used instead of the AES-256-CBC specified in the config, if the client supports it. That's how our RSA configs work, but we don't recommend using those since they're just for backwards compatibility, and our elliptic curve cryptography (ECC) configs use better crypto.

Next is the TLS ciphers they're using, "TLS-DHE-RSA-WITH-AES-256-CBC-SHA:TLS-DHE-DSS-WITH-AES-256-CBC-SHA:TLS-RSA-WITH-AES-256-CBC-SHA". Those ciphers are used to encrypt OpenVPN's "control channel", which is used to establish a TLS session that'll be used later to exchange cipher and HMAC keys to protect the data channel. There's three cipher suites specified here, separated by semi-colons, and these ciphers are negotiated to whichever the client prefers or supports. The TLS is only as strong as the weakest link, since downgrade attacks are possible in some man-in-the-middle scenarios. According to https://ciphersuite.info/search/?q=TLS_ ... 56_CBC_SHA, the second cipher is considered weak.
Our RSA configs on the other hand specify the much more secure:
TLS-ECDHE-RSA-WITH-CHACHA20-POLY1305-SHA256:TLS-ECDHE-RSA-WITH-AES-256-GCM-SHA384:TLS-DHE-RSA-WITH-AES-256-CBC-SHA
and our ECC configs use:
TLS-ECDHE-ECDSA-WITH-CHACHA20-POLY1305-SHA256:TLS-ECDHE-ECDSA-WITH-AES-256-GCM-SHA384
with support for TLSv1.3 added via the server-side:
--tls-ciphersuites TLS_CHACHA20_POLY1305_SHA256:TLS_AES_256_GCM_SHA384

The CA certificate embedded in their config is using 4096-bit RSA:

Code: Select all

[root@b ~]# sed -ne '
   /-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p
   /-END CERTIFICATE-/q' ivpn_france.ovpn|openssl x509 -noout -text|grep -B1 -- -Key
            Public Key Algorithm: rsaEncryption
                RSA Public-Key: (4096 bit)
which is probably secure enough, but it's not the most efficient option available. Our ECC configs use 521-bit elliptic curves instead:

Code: Select all

[root@b ~]# sed -ne '
   /-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p
   /-END CERTIFICATE-/q' cryptostorm_france.ovpn|openssl x509 -noout -text|grep -B1  -- -Key
            Public Key Algorithm: id-ecPublicKey
                Public-Key: (521 bit)
According to the chart on https://archive.is/G7TQq (https://www.nsa.gov/business/programs/elliptic_curve.shtml archived), a 521-bit EC key is roughly the equivalent of 15360-bit RSA. So it's much more secure, but since the key space is smaller and the algorithm is more efficient, there's less overhead.
and just for fun, our RSA instances are doing 8192-bit RSA.

Another thing I see is that they're doing "comp-lzo no". This is to disable compression, which is a good idea since using compression in OpenVPN can make you vulnerable to attacks like the VORACLE one described at https://github.com/skepticfx/voracle. The problem is that "comp-lzo no" doesn't always have the intended effect. In our research, we found that compression isn't always disabled whenever there's a certain combination of different client and server OpenVPN versions being used. This is a known bug described on https://community.openvpn.net/openvpn/ticket/952 and https://community.openvpn.net/openvpn/ticket/861. It appears that the only way to be completely sure compression won't be used is to remove "comp-lzo" from both server-side and client-side configs.

And finally, they're using "tls-auth". According to OpenVPN man page, "tls-auth adds an additional layer of HMAC authentication on top of the TLS control channel to mitigate DoS attacks and attacks on the TLS stack". Using tls-auth is better than nothing, but there's a newer "tls-crypt" option that's been available since 2016, it does authentication AND encryption of the TLS control channel. We've had it in our ECC configs for about 5 years now. There's also an even newer v2 of tls-crypt that we'll be supporting soon, it's docs are at https://github.com/OpenVPN/openvpn/blob ... ypt-v2.txt
by df
Sun Jun 20, 2021 3:12 pm
Forum: member support & tech assistance
Topic: Transparent Tor & I2P Access - Still Working?
Replies: 3
Views: 11731

Re: Transparent Tor & I2P Access - Still Working?

@tori2p
transparent .i2p and .onion wasn't dropped, only DNSChain's .bit, .p2p, and .eth was.

@parityboy
works for me. just double checked, it's resolving correctly on everything but the london server, the manchester one, and one of the two NY servers.
the manchester one just needed a tor restart, the other two needed a pdns-recursor restart. now they're all resolving stormgm7blbk7odd.onion correctly.
accessing the transparent .i2p/.onion service might be a little tricky on a router though, since the router needs to tell the connected devices how to access the IPs those things resolve to, or the devices need to know that those IPs go through your router (which might be the default, depending on your setup). if it helps, all .onion's will resolve to something in 10.99.0.0/16 and all .i2p hosts will resolve to 10.98.0.1

by the way, Tor says they're deprecating those v2 .onion addresses in favor of the longer v3 ones - https://lists.torproject.org/pipermail/ ... 14365.html
by df
Tue May 11, 2021 10:06 pm
Forum: member support & tech assistance
Topic: cryptostorm unable to validate certificate
Replies: 1
Views: 9155

Re: cryptostorm unable to validate certificate

Issue addressed via email. Our Romania and Moldova server wasn't authorizing connections if the token's sha512 hash was used to login, now it will.
by df
Fri Apr 30, 2021 5:05 am
Forum: member support & tech assistance
Topic: Inconsistent 'tls-ciphers' for 'TLSv1.3' across different servers
Replies: 1
Views: 7765

Re: Inconsistent 'tls-ciphers' for 'TLSv1.3' across different servers

I thought I responded to this already, oops. When I added "--tls-ciphersuites TLS_CHACHA20_POLY1305_SHA256:TLS_AES_256_GCM_SHA384" for TLSv1.3 to the server-side openvpn configs, I screwed up and missed a few of them. They're all fixed now, and they should have been restarted a while back to apply the changes. I restarted them a while back when adding "--data-ciphers CHACHA20-POLY1305:AES-256-GCM" so people can choose "--cipher CHACHA20-POLY1305" client-side (if they're running OpenVPN 2.5.x). That's the part that handles encrypting the actual traffic, the --tls-ciphersuites part just handles the encryption for the initial handshake.
Comments were also reintroduced to the configs, so you can read all about these changes in any of the configs on https://cryptostorm.is/configs/ or https://github.com/cryptostorm/conf
by df
Wed Apr 28, 2021 5:55 am
Forum: cryptostorm in-depth: announcements, how it works, what it is
Topic: widget v3
Replies: 279
Views: 1882439

Re: widget v3

v3.48.0.50 released - https://cryptostorm.is/cryptostorm_setup.exe
  • Change: OpenVPN upgraded to the latest 2.5.2
  • Bugfix: Right-clicking in the area where your token goes would spit out an error. Now in brings up the copy/paste menu like it should.
  • Change: That copy/paste menu will have the paste option greyed out (disabled) if the clipboard doesn't contain a valid token (or hash), to help prevent invalid tokens from getting entered. Copy will also be disabled if you're not selecting a valid token.
  • Bugfix: If you had a valid token in the textbox, then edited it so that it was invalid, then exited, the widget would forget the valid token. Now it won't save unless the token is valid.
by df
Tue Apr 20, 2021 9:15 am
Forum: cryptostorm in-depth: announcements, how it works, what it is
Topic: Can I create a social media account from cryptostorm?
Replies: 1
Views: 4351

Re: Can I create a social media account from cryptostorm?

You should be able to, most of our IPs aren't banned anywhere. I don't know about instagram since I don't use that one, but I use twitter and reddit often, always from a CS IP and I've never had any problems.
by df
Sat Apr 10, 2021 2:09 am
Forum: cryptostorm in-depth: announcements, how it works, what it is
Topic: widget v3
Replies: 279
Views: 1882439

Re: widget v3

As I said before, there's no reason to create a MacOS widget because software like Tunnelblick and Viscosity already exist. Why don't you try one of those? Tunnelblick is free and includes the latest OpenVPN/OpenSSL. Viscosity isn't free ($14), but some people say it's easier to use than Tunnelblick. It'll increase speeds too if you're connecting to the VPN on the host system instead of a VM.
by df
Sat Apr 10, 2021 1:38 am
Forum: cryptostorm in-depth: announcements, how it works, what it is
Topic: widget v3
Replies: 279
Views: 1882439

Re: widget v3

Can you run the widget on the host system? That'll let us know that the issue is specific to Parallels. When testing the widget on different Windows versions, I use VirtualBox and never saw this issue before. For Windows 10 testing I also use a laptop that's not doing virtualization.
by df
Sat Apr 10, 2021 12:29 am
Forum: cryptostorm in-depth: announcements, how it works, what it is
Topic: widget v3
Replies: 279
Views: 1882439

Re: widget v3

What kind of virtual machine?
by df
Sat Apr 10, 2021 12:17 am
Forum: cryptostorm in-depth: announcements, how it works, what it is
Topic: widget v3
Replies: 279
Views: 1882439

Re: widget v3

I mean are you using any other VPN software? Most of them make the assumption that their TAP adapter is the only one that'll ever be installed, so they'll often trample all over other adapters, changing settings arbitrarily etc.
by df
Sat Apr 10, 2021 12:08 am
Forum: cryptostorm in-depth: announcements, how it works, what it is
Topic: widget v3
Replies: 279
Views: 1882439

Re: widget v3

What about other VPN software? And when you say you never see csvpn.exe, does that include when you're connected? Because it has to be in the process list if you're connected.
by df
Fri Apr 09, 2021 11:24 pm
Forum: cryptostorm in-depth: announcements, how it works, what it is
Topic: widget v3
Replies: 279
Views: 1882439

Re: widget v3

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

Re: widget v3

@lajola
forgot to say, when you install the new one, you need to go into network connections and rename that TAP adapter to "cryptostorm"
by df
Fri Apr 09, 2021 5:06 am
Forum: cryptostorm in-depth: announcements, how it works, what it is
Topic: widget v3
Replies: 279
Views: 1882439

Re: widget v3

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

EDIT:
I am still seeing an issue where it takes about 5-20 seconds for the internet to become reachable after connecting to the VPN, but only in win7. This doesn't seem to be caused by the VPN though, it's caused by Windows and a lag before ipconfig /registerdns kicks in (or it might be that the route additions are taking a while for Windows to recognize them). It might help to change that one --ip-win32 setting in Options -> Advanced to ipapi or netsh (or it might break things altogether, who knows with Windows).
by df
Fri Apr 09, 2021 12:14 am
Forum: cryptostorm in-depth: announcements, how it works, what it is
Topic: widget v3
Replies: 279
Views: 1882439

Re: widget v3

I tested on Windows 10, not seeing the issue you're describing. Check in Options -> Security and see if the kill switch is enabled. The kill switch uses the Windows Firewall, so even if you've never used it before there might be some old rules leftover in there from the widget. Try disabling DNSCrypt in there too. If that's enabled and the DNS isn't getting restored on disconnect then it would cause DNS failures. There's also a big button in Options -> Advanced that says "Reset DNS to DHCP". Try clicking that after disconnecting and see if your internet works then.
by df
Thu Apr 08, 2021 10:44 pm
Forum: cryptostorm in-depth: announcements, how it works, what it is
Topic: widget v3
Replies: 279
Views: 1882439

Re: widget v3

@lajola
Are you seeing the same problem in v3.47.0.49?
My guess would be DNS related, but the widget should tell you if it can't resolve the VPN host you're connecting to. Either that or the kill-switch was enabled (or in a weird half-enabled state). Could check the Windows Firewall rules to see if there's anything in there that's blocking.
I do remember seeing a weird bug in OpenVPN's TAP driver where it would go into an odd semi-immutable state where you can't change or access any setting on it. But when I ran into that bug it only stopped the TAP adapter from working, not the other network adapters.
by df
Thu Apr 08, 2021 10:13 am
Forum: cryptostorm in-depth: announcements, how it works, what it is
Topic: widget v3
Replies: 279
Views: 1882439

Re: widget v3

v3.47.0.49 released - https://cryptostorm.is/cryptostorm_setup.exe
  • Bugfix: The bugfix in 3.46 where the widget would forget your token added a dumb bug where Cryptofree would complain about no token being entered (which you can't do when Cryptofree is selected). Added the missing code, all good now.
by df
Thu Apr 08, 2021 3:12 am
Forum: cryptostorm in-depth: announcements, how it works, what it is
Topic: widget v3
Replies: 279
Views: 1882439

Re: widget v3

v3.46.0.46 released - https://cryptostorm.is/cryptostorm_setup.exe
  • Feature: SSH and HTTPS tunneling now built into the widget. They're under Options -> Advanced.
    With SSH you can select the tunnel host (has to be different than the VPN node you're connecting to). With HTTPS it'll tunnel through the node you're connecting to, but since the server-side stunnel is doing round-robin balancing against all the server's IPs, the exit IP you get will most likely be different than the one you're connecting to.
  • Change: OpenSSL upgraded to the latest 1.1.1k
  • Change: Instead of dealing with 32-bit and 64-bit copies of all the .exe/.dll's, just doing 32-bit only since there's not really any performance difference with 32-bit and 64-bit OpenVPN. Should make things easier on 32-bit Windows users.
  • Change: Removed the fallback to Cloudflare's 1.1.1.1 DNS server when DNSCrypt fails. The only way that would happen now is if all of the DNSCrypt servers are unreachable, which is unlikely to happen (unless you're offline, in which case you wouldn't have been able to reach 1.1.1.1 anyways).
  • Change: For the backend Tcl/Tk that powers the GUI, switched from ActiveTcl to IronTcl because I think it's neat :-P
  • Bugfix: If you had a regular token in the token text box then selected Cryptofree and exited, the widget would forget your token. Now it won't do that.
  • Bugfix: Some code was iterating through the network adapters list via the registry, but there was a bug where it would keep looping and creating subkeys until a limit was reached. This is what was causing the widget to take so long to start or disconnect/exit, especially when restoring DNS settings on exit (like if DNSCrypt was enabled). Now it starts/exits/disconnects much faster.
  • Bugfix: The SOCKS port under Options -> Advanced sometimes wasn't getting saved correctly on exit, would affect people using Tor Browser's built-in local SOCKS server to do Tor -> CS.
  • Bugfix: Some missing logic was causing autoconnect to fail, mostly when Cryptofree was selected. Should be good now.
  • Bugfix: Removed the "--dev-node cryptostorm" OpenVPN option that forced the widget to use a TAP adapter named "cryptostorm", because sometimes OpenVPN would detect the adapter but Windows wouldn't.
  • Bugfix: Found a bug in the Net::DNS::Resolver module that was being used to pre-resolve the VPN hosts against the local DNSCrypt server (so the user could choose their exit IP, if that option was enabled). The bug would sometimes cause DNS to fail even when the DNSCrypt server was up and running correctly. The idea was to use that module so the DNS didn't need to be set system-wide to DNSCrypt, but the widget does that anyways, so Net::DNS::Resolver isn't necessary.
  • Bugfix: Sometimes the system tray icon would disappear if grouped under hidden icons. Now it should stay visible even if it gets sent there.
by df
Mon Apr 05, 2021 10:23 pm
Forum: member support & tech assistance
Topic: Windows 10 Client DNS Errors
Replies: 1
Views: 6868

Re: Windows 10 Client DNS Errors

Try the older version at https://cryptostorm.is/setup.exe
Some people are having DNS/TAP issues with 3.45, I'm working on a 3.46 that should address the problem.

EDIT: 3.46 is out now, details at viewtopic.php?f=37&p=45425#p45425
by df
Thu Apr 01, 2021 2:44 am
Forum: member support & tech assistance
Topic: Switzerland node - error connecting to some sites
Replies: 4
Views: 8310

Re: Switzerland node - error connecting to some sites

The Switzerland server was down for 1 hour and 40 minutes yesterday because I was migrating it to the new Arch Linux setup. Normally doesn't take that long, but ran into some issues. It should be good now.
by df
Mon Mar 29, 2021 11:28 pm
Forum: general chat, suggestions, industry news
Topic: Suggestion servers and routing
Replies: 1
Views: 12750

Re: Suggestion servers and routing

The reason we don't have more cities/servers in those countries is because we already have plenty in major cities, and most of the smaller cities won't have the same connectivity as Paris, etc. So speeds would be pretty bad outside of major cities. Also, none of the servers are anywhere near capacity.

As for BBCplayer/Netflix/Sky/etc. it's pretty easy to detect VPN IPs for them, they just block any IPs that don't appear to be residential, which all VPN IPs will appear to be (since they're hosted at a data center). The only way past that is to use residential IPs, but residential ISPs don't sell IP blocks, so the only way to use them is to actually be a customer of that ISP. Some VPNs get past this by doing a kind of bandwidth-sharing program where clients can use the VPN if they share their bandwidth with other clients (and some VPNs will just blatantly do this without permission, turning clients into a botnet). Either way, that's a horrible idea because it opens up so many different attack vectors to any VPN client using that network.

We will add more exotic servers sometime in the future, but probably not in Africa. That whole continent has terrible internet connectivity, and very high prices ($200-500+/month for a shitty "fair-use" [shared] 100mbps server @ 5TB/month max). Same goes for South America. And it's probably best to avoid Russia at the moment. We had one a few years ago, but Russia passed a law requiring VPNs to comply with a federal blacklist that prevents Russians from accessing certain sites (see https://torrentfreak.com/russia-orders- ... es-190328/ ). Instead of dealing with that, we ditched the Russian server and got some new ones on the European side of the Russian border so Russian citizens that could bypass the ban would still get decent speeds. More recently, Russian has been implementing GFW style techniques to block VPNs (like China does), so obfs4 might be useful there (which we are planning to implement soon).
by df
Fri Mar 26, 2021 2:09 am
Forum: member support & tech assistance
Topic: Wireguard connection problem
Replies: 13
Views: 15230

Re: Wireguard connection problem

lajola wrote: @df

i have this error after maked 6 wireguard connection:

Error: That token is limited to 6 wireguard keys,
and there's already 6 keys in the system.
Go here if you need to delete your other keys.

So we can not add and use all servers like in other vpns?
You're confusing connections with keys. What you're doing on that page isn't making connections, it's making keys. Each key gets added to all of our servers so that you can connect to any of them using that key. Each cryptostorm token can only have a certain number of keys associated with it. The page at https://cryptostorm.is/blog/wireguard-support-added under "Device limits" show the number of WireGuard keys that are allowed for each cryptostorm token type (in your case, 6). WireGuard won't allow you to connect to more than one server on the same device (at the same time), but we don't have any network-wide connection limits, so technically you could (for example) have 30 devices each using the same key and connecting to different servers.
by df
Fri Mar 26, 2021 12:05 am
Forum: member support & tech assistance
Topic: Switzerland node - error connecting to some sites
Replies: 4
Views: 8310

Re: Switzerland node - error connecting to some sites

That server's been under a heavy DNS-based DDoS attack for a couple of days now that's causing the upstream to block DNS traffic. I just temporarily disabled the public DNS server there on 81.17.31.34 so now DNS is only reachable on the 10.31.33.7 and 10.31.33.8 IPs that can only be accessed while on the VPN.
Now we just need to wait for the upstream to unblock us. The VPN server is still reachable, but DNS won't work until they unblock us.

EDIT:
For now, I'll just forward all DNS on the Switzerland server to the Austrian server so people connecting to Switzerland won't get anymore DNS errors. I'll switch it back to 81.17.31.34 whenever it's unblocked.
by df
Wed Mar 24, 2021 11:52 pm
Forum: member support & tech assistance
Topic: Wireguard connection problem
Replies: 13
Views: 15230

Re: Wireguard connection problem

@prospav
DNS server on Switzerland is under a heavy DoS attack right now, working with the ISP to block it. The server's still up and running fine, but since the DNS server running on it is recursive, some of the root DNS servers have blocked requests from it, causing DNS to fail.

EDIT:
since the attack is still ongoing a few days later, I've disabled the public DNS server on the Switzerland node, and until the root DNS servers unblock the IP, all DNS for the Switzerland node will be forwarded to the Austria node's DNS server. That should keep DNS working for anyone connected to the Switzerland node.
by df
Wed Mar 24, 2021 10:11 am
Forum: member support & tech assistance
Topic: Not connecting - hanging on "connecting..." after "logging onto cryptostorm..."
Replies: 1
Views: 6231

Re: Not connecting - hanging on "connecting..." after "logging onto cryptostorm..."

Can you run "C:\Program Files (x86)\Cryptostorm Client\bin\csvpn.exe" ? If it disappears too quickly, you could try running it from a command prompt, just copy paste "C:\Program Files (x86)\Cryptostorm Client\bin\csvpn.exe" into the window (double quotes included) and press enter.

Only reason I can think of for it to get stuck at "logging onto cryptostorm" is if it can't run csvpn.exe (OpenVPN).
by df
Wed Mar 24, 2021 10:04 am
Forum: member support & tech assistance
Topic: Cryptostorm network - news
Replies: 30
Views: 124235

Re: Cryptostorm network - news

A WireGuard issue was just fixed too, see viewtopic.php?f=32&t=29355&p=45401#p45401
So if you weren't able to get any traffic through your WireGuard tunnel, try again, it should be working now
by df
Wed Mar 24, 2021 10:02 am
Forum: member support & tech assistance
Topic: Cryptostorm Mac Issues
Replies: 2
Views: 7085

Re: Cryptostorm Mac Issues

The WireGuard issue should be resolved now, see viewtopic.php?f=32&t=29355&p=45401#p45401
by df
Wed Mar 24, 2021 10:00 am
Forum: member support & tech assistance
Topic: Wireguard connection problem
Replies: 13
Views: 15230

Re: Wireguard connection problem

Disregard my last posts, it was an issue on our end. WireGuard should be working correctly now. Problem was the server was doing `wg syncconf` (among other things) to update the config without disrupting active sessions, but syncconf wasn't always adding the 10.10.x.x IP to the routing table. Without that IP in the routing table, some new clients would be able to connect but no traffic would go through the tunnel.
I grabbed all the 10.10.x.x IPs from the wg database and added them to all the server's routing tables, so they shouldn't have this problem anymore. Also updated the backend and all the servers to add that IP to the routing table automatically when new peers are added, so nobody else should see this issue either.

EDIT:
Didn't need to add every active 10.10.x.x IP to the routing table, `route add -net 10.10.0.0/16 wg0` accomplishes the same thing. Not sure why, but some servers didn't have that in the routing table, and some did.
by df
Sat Mar 20, 2021 9:55 pm
Forum: member support & tech assistance
Topic: Wireguard connection problem
Replies: 13
Views: 15230

Re: Wireguard connection problem

Only other thing I can think of is the MTU is getting set to something unusual on your end. Server-side's wg0 interface has the default MTU of 1420, client-side's interface should be the same.

If that's not it, email support@cryptostorm.is with your config so we can double check the IP/PSK/keys on our end. We'll need your private key too, but that can always be regenerated later once we pinpoint the issue.
by df
Sat Mar 20, 2021 9:45 pm
Forum: cryptostorm in-depth: announcements, how it works, what it is
Topic: widget v3
Replies: 279
Views: 1882439

Re: widget v3

@lajola
Tunnelblick and Viscosity work just fine on Mac OS X
by df
Tue Mar 16, 2021 10:56 am
Forum: cryptostorm in-depth: announcements, how it works, what it is
Topic: widget v3
Replies: 279
Views: 1882439

Re: widget v3

Found another bug, in the latest v3.45.0.43 (and possibly previous versions). If "Global random" is selected, the widget fails to resolve the hostname. I'm also seeing gethostbyname fail to resolve the node if you connect with DNSCrypt enabled, disconnect, disable DNScrypt, then try to reconnect. Trying to pinpoint why that's happening.
by df
Mon Mar 15, 2021 3:39 pm
Forum: cryptostorm in-depth: announcements, how it works, what it is
Topic: widget v3
Replies: 279
Views: 1882439

Re: widget v3

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

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

Re: Wireguard connection problem

I just checked the servers, the Manchester node's WireGuard peer list was out of sync with the others. Looks like it was missing from the backend API that updates the nodes when new peers get added/deleted. That's fixed now, so if you were trying the Manchester node, try again and it should work.

If that's not the node you were on and another WireGuard VPN works fine, then my guess is that the PSK or IP is incorrect. Did you try creating a new one @ cryptostorm.is/wireguard ?
by df
Sun Mar 14, 2021 1:44 am
Forum: member support & tech assistance
Topic: Cryptostorm Mac Issues
Replies: 2
Views: 7085

Re: Cryptostorm Mac Issues

Make sure you're using the latest WireGuard according to https://www.wireguard.com/install/ (as of this post, v1.0.12 via the App Store), and double check any firewall settings that might block the traffic, or routing settings that might conflict with 10.10.x.x (what WireGuard uses internally). You could also try WireGuard on another system and see if it works with your publickey/PSK/IP/etc., if not then you could try removing the key from your token @ https://cryptostorm.is/wireguard_man then readding it with https://cryptostorm.is/wireguard

As for Tunnelblick, make sure you're not skipping the step shown in Image
from the instructions on https://cryptostorm.is/macintosh.html
The OpenSSL/OpenVPN required by the different config types are listed at the top of https://cryptostorm.is/configs/
by df
Sun Mar 14, 2021 1:39 am
Forum: member support & tech assistance
Topic: Wireguard connection problem
Replies: 13
Views: 15230

Re: Wireguard connection problem

I don't have a macOS system here to test with, but other users have reported that Catalina works fine for them, so I guess make sure you're using the latest WireGuard according to https://www.wireguard.com/install/ (as of this post, v1.0.12 via the App Store), and double check any firewall settings that might block the traffic, or routing settings that might conflict with 10.10.x.x (what WireGuard uses internally). That log file isn't very useful since it's not very verbose, basically just tells when a session is opened. See if whatever was used to make that log file can increase it's verbosity to show more details. You could also try WireGuard on another system and see if it works with your publickey/PSK/IP/etc., if not then you could try removing the key from your token @ https://cryptostorm.is/wireguard_man then readding it with https://cryptostorm.is/wireguard
by df
Sun Mar 14, 2021 1:24 am
Forum: cryptostorm in-depth: announcements, how it works, what it is
Topic: widget v3
Replies: 279
Views: 1882439

Re: widget v3

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

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

Main problem with v3.44 is that I switched from Cava Packager (which bundles modules/submodules correctly) to Perl2Exe (which doesn't bundle modules/submodules correctly). But Perl2exe creates a client.exe that loads a lot faster (~2-5 secs, Cava's is ~20-40 secs), so I really wanted to switch to that. With all of Perl2Exe's bundling fumbling, it was looking for the TCL .dll's (among other things) in the wrong places, that's why the GUI wouldn't load at all for most people trying to use 3.44. Those issues should be fixed in v3.45.
by df
Thu Mar 11, 2021 4:09 am
Forum: member support & tech assistance
Topic: Cryptostorm network - news
Replies: 30
Views: 124235

Re: Cryptostorm network - news

@lajola
Haven't heard back from jedisct1 yet. You'll see that error if you're running dnscrypt-proxy at the console/terminal. I haven't tested any GUI frontends for dnscrypt-proxy, so not sure what it would look like in those. If you get that error, then add to your config "force_tcp = true". If you don't see it anywhere in your terminal or the log files, then don't worry about it.
by df
Tue Mar 09, 2021 3:33 pm
Forum: member support & tech assistance
Topic: Swiss Node IPs indicating Panama location?
Replies: 3
Views: 7409

Re: Swiss Node IPs indicating Panama location?

Well the iplocation.net site isn't for leaks, it's just for knowing your IP (and what ISP/region it belongs to).
Here's some decent leak test sites:
https://dnsleaktest.com for DNS leaks (we've got one at https://cryptostorm.is/dnsleak too, but it's not great. it's more of a proof of concept for a dns leak test page that doesn't use javascript).
https://cryptostorm.is/torrentip for checking that your torrent client isn't leaking your ip (this one is great, uses opensource software that you can install on any website if you don't want to use it on ours).
https://ipv6leak.com/ - for making sure IPv6 isn't leaking (hosted by PIA)
https://diafygi.github.io/webrtc-ips/ - webrtc/STUN leaks, I think this was the original
there's also that geolocation feature most modern browsers have, explained on https://stackoverflow.com/questions/363 ... eolocation
easiest way to stop those is to just deny the request if it comes up, or better yet disable the feature entirely in your browser's settings.
by df
Tue Mar 09, 2021 11:35 am
Forum: member support & tech assistance
Topic: Swiss Node IPs indicating Panama location?
Replies: 3
Views: 7409

Re: Swiss Node IPs indicating Panama location?

Some GeoIP databases are inaccurate, and some "whatismyip" sites only use one GeoIP db. https://www.iplocation.net/ is decent, it shows the results from 4 different GeoIP databases. On that site, our Swiss node's IPs are listed in the first db as Switzerland, the second db as Germany, the third db as Switzerland, and in the fourth db as Panama.
The problem is that Private Layer Inc (the Swiss node's ISP) is registered in Panama, but owns servers in Switzerland. From their ToS: "Private Layer is incorporated in the country of Panama, and provides services from the countries of Switzerland and Panama".
No clue where that second db got Germany from.
The physical server is located at the Ticino DC in Switzerland - https://www.datacenters.com/swisscoloca ... -inferiore

EDIT:
Never use doileak.com. Any leak test that asks you to turn your VPN off should be avoided. If they require you to turn your VPN off before the test begins, they're doing some shady shit behind the scenes. The website redirects to https://www.top10vpn.com/do-i-leak/ , and top10vpn.com is one of the many vpn review sites that only accept paid listings. That's why we're not listed there, we don't pay for reviews like ExpressVPN, NordVPN, etc. does.
by df
Mon Mar 08, 2021 11:39 pm
Forum: cryptostorm in-depth: announcements, how it works, what it is
Topic: widget v3
Replies: 279
Views: 1882439

Re: widget v3

@noplanman
I'm still working on the latest release. I thought I fixed an issue where an embedded Tcl library .dll sometimes wasn't included, but I'm running into some very odd bugs in the core Perl libraries, or rather in the way perl2exe embeds those libraries into client.exe. I really want to use perl2exe though because the thing I used to use (Cava Packager) takes way too long to start up client.exe. I just have to rewrite some of the widget's code because regular threads aren't working correctly.
by df
Sun Feb 28, 2021 9:11 am
Forum: cryptostorm in-depth: announcements, how it works, what it is
Topic: widget v3
Replies: 279
Views: 1882439

Re: widget v3

@noplanman
GitHub is still used for the configs and deepdns info, but the other repos there are abandoned. There's no real versioning system in place for the widget since (normally) we don't want people using an older version. But with the most recent update some major changes were made that could cause errors like we're seeing now, so it might be a good idea to at least keep around the previous version.
by df
Sun Feb 28, 2021 4:46 am
Forum: cryptostorm in-depth: announcements, how it works, what it is
Topic: widget v3
Replies: 279
Views: 1882439

Re: widget v3

@noplanman
I'm working on a new version that should fix whatever issue some people are having. In the meantime, there is an older version at https://cryptostorm.is/setup.exe that seems to work for everyone.
by df
Sat Feb 27, 2021 11:12 am
Forum: cryptostorm in-depth: announcements, how it works, what it is
Topic: widget v3
Replies: 279
Views: 1882439

Re: widget v3

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

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

For now, just don't click the update button :-P there's no other new servers anyways, the node list v3.44.* has is the most recent.
by df
Fri Feb 26, 2021 2:50 pm
Forum: member support & tech assistance
Topic: Cryptostorm network - news
Replies: 30
Views: 124235

Re: Cryptostorm network - news

Alrighty, I think that's it.
Added a bunch of new servers. A couple are upgrades for existing servers that were still running crap hardware (like Portugal and it's Intel Athlon, now Intel Xeon).
Main website's been updated. Same layout/colors/etc., just updated the text to more accurately reflect the current network setup. Also added a server map in the area just before https://cryptostorm.is/#section5 , so people don't have to go digging around to find cryptostorm.is/uptime to get the server locations, and I put a direct link to the faq on the main page too (at the top, to the left of the ip checker thing).
OpenVPN configs have been updated @ https://cryptostorm.is/configs/ and https://github.com/cryptostorm/conf/ . I decided to bring back those comments filled with techie details (now updated), but this time I moved any of the stuff people might wanna change (auth-user-pass, dns, cipher, remote) to the top of the file so you don't have to sift through all the comments to find those lines.
wireguard keys on https://cryptostorm.is/wireguard have been updated for the new servers too.
most of the wireguard backend auth API's code has been rewritten so that it works more efficiently (before, when wireguard was working, it sometimes didn't add/del keys to all the servers, now it will).
widget updated to v3.45, should be pushed to all the servers now so next time you connect it'll prompt to upgrade (or just grab it from https://cryptostorm.is/cryptostorm_setup.exe ). It includes the latest dnscrypt-proxy, openvpn, openssl, a buncha bug fixes. I also ditched Cava Packager for something more recent, which brought the initial load time from something like 15-30 seconds down to a couple of seconds. Also added an option under Security that lets you switch between AES-256-GCM or POLY1305-CHACHA20 for the data channel cipher (the one that encrypts your traffic). POLY1305-CHACHA20 should be faster on most systems.
Since CentOS 6.10 went EOL, I decided to switch over to Arch Linux, at least for new servers. So all the new ones are running Arch, not CentOS.
That should make things easier to update since I won't have to compile most things from source anymore. On those Arch systems, I'm also not doing grsecurity, since it's not free anymore and I can't just keep using the last free version. Instead, https://github.com/anthraxx/linux-hardened and https://github.com/GrapheneOS/hardened_malloc is used on those systems to provide similar security features.
The dnscrypt files on https://github.com/cryptostorm/cstorm_deepDNS/ are updated now too, but there's an issue going on with some of the relays, something to do with UDP fragmentation that's occuring, or being reported as occuring by dnscrypt-proxy. I left a message about it for jedisct1 (the guy that wrote dnscrypt-proxy), maybe he'll know what's going on there. So if you're trying to use our Anonymous DNS relays (relays.md) and you get a "[another DNS server] couldn't be reached anonymously" error, then just add to your dnscrypt-proxy.toml the line "force_tcp = true" and it'll stop using UDP, which gets past that error.
I also moved this forum onto a dedicated server. Before it was on a VM that had way too many overly paranoid settings to keep script kiddies from pwning the forum, but it ended up just making it easier to DoS the site, which is why it used to be so laggy. Instead of trying to secure it like that, it made more sense to just buy a cheap dedicated server and dedicate it to the forum, so if some phpbb zero day does come along, it won't affect anything else.
The webchat thing is back up too, that was one of the first things I worked on getting back up. https://cryptostorm.nu/chat/ , I'm usually there, I just might not have that window in the foreground, so if you PM me there it might take a while for a response.

I think that's about it... I'll do a a more detailed (and less-messy) annoucement on https://cryptostorm.is/blog/ in a day or so, for the people who don't check the forum.
by df
Wed Feb 17, 2021 9:33 pm
Forum: cryptostorm in-depth: announcements, how it works, what it is
Topic: The CryptoStorm Speed Test Thread
Replies: 83
Views: 325027

Re: The CryptoStorm Speed Test Thread

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.
by df
Wed Feb 17, 2021 8:36 am
Forum: cryptostorm in-depth: announcements, how it works, what it is
Topic: The CryptoStorm Speed Test Thread
Replies: 83
Views: 325027

Re: The CryptoStorm Speed Test Thread

@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 :-)
by df
Mon Feb 15, 2021 1:15 pm
Forum: member support & tech assistance
Topic: Configs
Replies: 3
Views: 10768

Re: Configs

@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
by df
Wed Feb 10, 2021 7:06 pm
Forum: cryptofree: no-cost cryptostorm network access
Topic: Free service registration broken
Replies: 4
Views: 29273

Re: Free service registration broken

The Cryptofree WireGuard page is up and running now, as is the paid nodes
by df
Wed Feb 10, 2021 7:05 pm
Forum: member support & tech assistance
Topic: Configs
Replies: 3
Views: 10768

Re: Configs

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?
by df
Tue Feb 09, 2021 10:08 pm
Forum: member support & tech assistance
Topic: Connecting with old key
Replies: 3
Views: 11767

Re: Connecting with old key

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.
by df
Sat Jan 23, 2021 5:09 am
Forum: member support & tech assistance
Topic: Killswitch / DeepDNS Problem
Replies: 10
Views: 14830

Re: Killswitch / DeepDNS Problem

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
by df
Wed Jan 20, 2021 11:13 pm
Forum: member support & tech assistance
Topic: Killswitch / DeepDNS Problem
Replies: 10
Views: 14830

Re: Killswitch / DeepDNS Problem

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
by df
Wed Jan 20, 2021 1:47 pm
Forum: member support & tech assistance
Topic: Killswitch / DeepDNS Problem
Replies: 10
Views: 14830

Re: Killswitch / DeepDNS Problem

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.
by df
Wed Jan 20, 2021 9:35 am
Forum: member support & tech assistance
Topic: Killswitch / DeepDNS Problem
Replies: 10
Views: 14830

Re: Killswitch / DeepDNS Problem

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.
by df
Tue Jan 12, 2021 3:29 pm
Forum: member support & tech assistance
Topic: Cryptostorm network - news
Replies: 30
Views: 124235

Re: Cryptostorm network - news

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.
by df
Wed Nov 06, 2019 5:53 am
Forum: member support & tech assistance
Topic: cs dnscrypt-proxy server TIMEOUT
Replies: 10
Views: 17042

Re: cs dnscrypt-proxy server TIMEOUT

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
by df
Tue Nov 05, 2019 4:39 am
Forum: member support & tech assistance
Topic: cs dnscrypt-proxy server TIMEOUT
Replies: 10
Views: 17042

Re: cs dnscrypt-proxy server TIMEOUT

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.
by df
Mon Nov 04, 2019 6:34 pm
Forum: member support & tech assistance
Topic: cs dnscrypt-proxy server TIMEOUT
Replies: 10
Views: 17042

Re: cs dnscrypt-proxy server TIMEOUT

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
by df
Sun Oct 20, 2019 5:43 am
Forum: member support & tech assistance
Topic: MTU value, DSL+LTE hybrid connection (UDP/TCP)
Replies: 2
Views: 10095

Re: MTU value, DSL+LTE hybrid connection (UDP/TCP)

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
by df
Fri Oct 11, 2019 7:43 pm
Forum: #cleanVPN ∴ encouraging transparency & clean code in network privacy service
Topic: streisand wireguard server
Replies: 2
Views: 23565

Re: streisand wireguard server

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
by df
Mon Sep 09, 2019 6:21 pm
Forum: member support & tech assistance
Topic: internal DHCP ip clash only on Dusseldorf UDP
Replies: 3
Views: 12474

Re: internal DHCP ip clash only on Dusseldorf UDP

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
by df
Mon Aug 12, 2019 8:54 pm
Forum: general chat, suggestions, industry news
Topic: Mullvad coreboot
Replies: 1
Views: 8468

Re: Mullvad coreboot

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.
by df
Sat Jul 27, 2019 12:08 am
Forum: cryptostorm in-depth: announcements, how it works, what it is
Topic: widget v3
Replies: 279
Views: 1882439

Re: widget v3

@Behoove
with the widget closed, open up c:\Program Files (x86)\Cryptostorm Client\user\config.ini in Notepad++ (since it needs admin privs) and change the line:
nostun=on
to
nostun=off
then restart the widget.
by df
Tue Jul 16, 2019 2:46 pm
Forum: general chat, suggestions, industry news
Topic: [Suggestion] Support WireGuard
Replies: 13
Views: 50853

Re: [Suggestion] Support WireGuard

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
by df
Mon Jun 10, 2019 8:07 am
Forum: member support & tech assistance
Topic: Circuit Breaker
Replies: 24
Views: 32680

Re: Circuit Breaker

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