DD-WRT instructions
Before you begin, you should upgrade to the latest DD-WRT firmware version.
DD-WRT's web interface is horribly buggy, at least for the OpenVPN settings page.
Instead of explaining all the various steps needed to address all of those issues, we wrote a script that does everything.
It's a bit long, but it's much easier this way. At the bottom of this page is more information about everything the script does.
In the script below, the only thing that MUST BE CHANGED is the first line.
You need to replace CsTok-enGvX-F4b4a-j7CED with your actual token.
Don't worry about hashing it, the script will do that for you.
You can edit it here on this page to make things easier.
If you'd like to connect to a specific region, replace balancer.cstorm.is with any of the nodes listed here.
You can also change the port from 443 to anything from 1 to 29999, excluding 5061 and 5062.
If you'd like to use TCP instead of UDP, simply change the udp below to tcp
The useKillswitch=1 part enables the killswitch, explained at the bottom of this page.
Change that to useKillswitch=0 if you don't want to use it.
The useTrackerSmacker=1 line is our DNS-based ad/tracker blocking service described here.
If you don't want to use that, change the 1 to 0.
Now, login to your DD-WRT's web interface and go to the "Administration" tab, then "Commands".
After you edit the first line, copy everything in the box below, and paste it into the "Commands" box on the DD-WRT page.
In pretty much all browsers, you can click on anywhere in the box below and do CTRL+A to select everything, then CTRL+C to copy.
After you've pasted the above into your DD-WRT's Commands page, click the "Save Startup" button at the bottom.
Next, simply reboot your DD-WRT router to have it connect to cryptostorm.
If you don't want to reboot, you can instead run this command on that same page:
After that, your router and all devices connected to it will be on cryptostorm.
The killswitch included in the script above applies to devices connected to your DD-WRT router, but not the router itself.
In other words, if OpenVPN crashes or the VPN goes down for some other reason, the router will still be able to reach the internet.
Devices connected to the router will not.
DNS leaks are also addressed by the script. All devices connected to the router (and the router itself) will use our DNS servers.
If the VPN goes down, DNS will fail on those devices, but the router's DNS will continue to work.
As stated at the top of this page, the main reason that this script is necessary is because the DD-WRT web interface contains several bugs.
It uses a lot of old/obsolete OpenVPN options (which is weird because it has a recent OpenVPN), and it makes some assumptions that might not always be true.
An example would be the tls-auth OpenVPN option that can be set from the web UI using the "TLS Auth Key" section.
According to the DD-WRT source code here, in the start_openvpnserver() function used to start OpenVPN as a server, it does:
DD-WRT incorrectly assumes that 0 means server and 1 means client, but according to the OpenVPN manual:
The direction parameter should always be complementary on either side of the connection, i.e. one side should use "0" and the other should use "1", or both sides should omit it altogether.
So those direction numbers don't necessarily mean client or server, they simply need to be the opposite of whatever is set on the remote side.
Another issue is that the web UI doesn't support the newer tls-crypt feature that encrypts the data channel with an additional layer, even though the OpenVPN behind the UI supports it.
The older tls-auth option used by the web UI only does authentication against the control channel, not encryption.
In other words, with tls-crypt, the TLS handshake gets encrypted too, which means it's more difficult to block using a DPI capable firewall.
The older tls-auth doesn't, so it's easier to block.
Also, there's no support in the web UI for the newer "compress" OpenVPN option, even though the OpenVPN behind the UI does support it.
Yet another issue is that in the web UI, under "Encryption Cipher", there's an option to use "AES-512 CBC".
We double checked the code of every single OpenVPN version, there are no official versions that support a 512-bit AES cipher.
It appears that the commit here from 2010 is when they modified their OpenSSL to include AES-512, but it's since been removed.
According to this StackExchange post, AES is defined for key sizes k∈{128,192,256} only.
But they also reference this PDF which describes how an AES-512 implementation would work.
So it is technically possible to implement AES using 512-bit key sizes, it just won't actually be considered "AES" anymore.
Either way, it's not officially supported by OpenSSL or OpenVPN. So the only way to use it in a client/server setup would be if both sides were using this modified OpenSSL and a modified OpenVPN.
But since this is cryptography, we would strongly advise against using experimental algorithms that haven't been thoroughly tested.
The rest of the script mainly implements modern features that the web UI hasn't been updated to yet, such as the method used to verify the remote server's certificate, or support for AES-GCM.
The web UI still uses the obsolete "nsCertType", while OpenVPN now uses "remote-cert-tls". And the UI uses AES-CBC, while AES-GCM has been supported since OpenVPN 2.4.0
Instead of explaining all the various steps needed to address all of those issues, we wrote a script that does everything.
It's a bit long, but it's much easier this way. At the bottom of this page is more information about everything the script does.
In the script below, the only thing that MUST BE CHANGED is the first line.
You need to replace CsTok-enGvX-F4b4a-j7CED with your actual token.
Don't worry about hashing it, the script will do that for you.
You can edit it here on this page to make things easier.
If you'd like to connect to a specific region, replace balancer.cstorm.is with any of the nodes listed here.
You can also change the port from 443 to anything from 1 to 29999, excluding 5061 and 5062.
If you'd like to use TCP instead of UDP, simply change the udp below to tcp
The useKillswitch=1 part enables the killswitch, explained at the bottom of this page.
Change that to useKillswitch=0 if you don't want to use it.
The useTrackerSmacker=1 line is our DNS-based ad/tracker blocking service described here.
If you don't want to use that, change the 1 to 0.
Now, login to your DD-WRT's web interface and go to the "Administration" tab, then "Commands".
After you edit the first line, copy everything in the box below, and paste it into the "Commands" box on the DD-WRT page.
In pretty much all browsers, you can click on anywhere in the box below and do CTRL+A to select everything, then CTRL+C to copy.
After you've pasted the above into your DD-WRT's Commands page, click the "Save Startup" button at the bottom.
Next, simply reboot your DD-WRT router to have it connect to cryptostorm.
If you don't want to reboot, you can instead run this command on that same page:
$(nvram get rc_startup)Just be sure to click the "Run commands" button and not the other buttons.
After that, your router and all devices connected to it will be on cryptostorm.
The killswitch included in the script above applies to devices connected to your DD-WRT router, but not the router itself.
In other words, if OpenVPN crashes or the VPN goes down for some other reason, the router will still be able to reach the internet.
Devices connected to the router will not.
DNS leaks are also addressed by the script. All devices connected to the router (and the router itself) will use our DNS servers.
If the VPN goes down, DNS will fail on those devices, but the router's DNS will continue to work.
Below is an explanation of some of the bugs addressed by the script above
As stated at the top of this page, the main reason that this script is necessary is because the DD-WRT web interface contains several bugs.
It uses a lot of old/obsolete OpenVPN options (which is weird because it has a recent OpenVPN), and it makes some assumptions that might not always be true.
An example would be the tls-auth OpenVPN option that can be set from the web UI using the "TLS Auth Key" section.
According to the DD-WRT source code here, in the start_openvpnserver() function used to start OpenVPN as a server, it does:
fprintf(fp, "tls-auth /tmp/openvpn/ta.key 0\n");while in the start_openvpn() function used to start OpenVPN as a client, the code is:
fprintf(fp, "tls-auth /tmp/openvpncl/ta.key 1\n");The 0 or 1 at the end of both of those lines of code would be equivalent to setting key-direction 0 or key-direction 1.
DD-WRT incorrectly assumes that 0 means server and 1 means client, but according to the OpenVPN manual:
The direction parameter should always be complementary on either side of the connection, i.e. one side should use "0" and the other should use "1", or both sides should omit it altogether.
So those direction numbers don't necessarily mean client or server, they simply need to be the opposite of whatever is set on the remote side.
Another issue is that the web UI doesn't support the newer tls-crypt feature that encrypts the data channel with an additional layer, even though the OpenVPN behind the UI supports it.
The older tls-auth option used by the web UI only does authentication against the control channel, not encryption.
In other words, with tls-crypt, the TLS handshake gets encrypted too, which means it's more difficult to block using a DPI capable firewall.
The older tls-auth doesn't, so it's easier to block.
Also, there's no support in the web UI for the newer "compress" OpenVPN option, even though the OpenVPN behind the UI does support it.
Yet another issue is that in the web UI, under "Encryption Cipher", there's an option to use "AES-512 CBC".
We double checked the code of every single OpenVPN version, there are no official versions that support a 512-bit AES cipher.
It appears that the commit here from 2010 is when they modified their OpenSSL to include AES-512, but it's since been removed.
According to this StackExchange post, AES is defined for key sizes k∈{128,192,256} only.
But they also reference this PDF which describes how an AES-512 implementation would work.
So it is technically possible to implement AES using 512-bit key sizes, it just won't actually be considered "AES" anymore.
Either way, it's not officially supported by OpenSSL or OpenVPN. So the only way to use it in a client/server setup would be if both sides were using this modified OpenSSL and a modified OpenVPN.
But since this is cryptography, we would strongly advise against using experimental algorithms that haven't been thoroughly tested.
The rest of the script mainly implements modern features that the web UI hasn't been updated to yet, such as the method used to verify the remote server's certificate, or support for AES-GCM.
The web UI still uses the obsolete "nsCertType", while OpenVPN now uses "remote-cert-tls". And the UI uses AES-CBC, while AES-GCM has been supported since OpenVPN 2.4.0