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

note: folks using Tunnelblick for the Mac/OSX will want to ensure they don't include the --log directives that are found in these default/Linux configuration files; we've a separate dedicated thread offering excellent information on connecting to cryptostorm with Tunnelblick, and all the data in that thread work for cryptofree just fine! Our thanks to @nickoutprintln for catching this & letting us know.

Here are the beta testing configuration settings for folks to use with the cryptofree service. A few notes:

2. The OpenVPN configuration files ("config") attached to this post will enable connections from Linux and Mac/OSX computers; with a bit of fiddling it'll work for Android, Unix, and most other platforms as well.

3. Yes, there's a Windows version of cryptofree - based around our client widget - to be released for beta testing shortly. We released the Linux/Mac side first in order to get early community feedback and guidance; no offence intended to our Windows friends!

4. Cryptofree's private networking service is identical to full cryptostorm service in all regards - cryptographic suites deployed, server-side configuration, source code edits, logging disablement, and so on - with only one exception: connection speeds per-session are capped at 256kb downstream & 128kb upstream.

5. Finally, when your client asks you for username/password during the network connection process, you can provide any value... so long as it's not a null character, i.e. nothing at all. Type "foo" or "blah" or whatever makes you happy - just don't type nothing ("nothing" is fine, however ;- ). This is a funky thing with OpenVPN itself, & we'll figure a clever workaround for the full production launch of cryptofree, but for now anything but [null] is a-ok.

Otherwise, please do share your experiences, feedback, and critique of the service so that we can learn and improve over time!

vpnDarknet wrote:Are you handing out a generic password to Beta testers for this conf, or would a hashed token allow access?

It is pretty much like token access as it exists with the exception that it will accept any value(other than NULL) as a valid token. You can use your existing token without issue and it will work, just at cryptofree speeds.

What tool are you using to test with, Lignus? Many people use speedtest.net, but they were consistently mis-reporting speeds, both upload and download during testing. While we were still fine-tuning the bandwidth caps, actual downloads were kept just above 56k levels, but speedtest.net was reporting speeds anywhere from 1 Mbps to over 130Mbps

Guest wrote:Hello Fermi,Sorry if this is the wrong place to post this, but do you plan to add to your access plans (whether paid or free) any nodes in Asia (such as Japan, Korea, Hongkong)?

An Asian node is something we've been looking at for a decent while now, and it's something we want to (and will) do. I'm not sure the current state of that effort, as it got put on hold while we were attending to cryptofree and getting our Portugal node running as it should (still ongoing as of now).

An Asian node will be coming though, and until we've decided definitively on a geographical location, we're always gladly accepting suggestions and insight.

Definitely something funny going on there. I ran the same test you did and got similar results to those that you saw, but when I monitor the throughput indicated by tunnelblick I'm only seeing uploads of ~130 KB/s

Whereas if I run the same curl command used during testing, (curl -o/dev/null http://proof.ovh.net/files/100Mb.dat) my downloads average 243, both very close to the caps we have in place, but in KB/s. That would give a connection close to 2 Mbps, which is obviously tuned too high. I have a feeling that it's just a simple mixup of Kb and KB.

vpnDarknet wrote:Are you handing out a generic password to Beta testers for this conf, or would a hashed token allow access?

It is pretty much like token access as it exists with the exception that it will accept any value(other than NULL) as a valid token. You can use your existing token without issue and it will work, just at cryptofree speeds.

Doh! My bad, I haven't freed up the IP for my firewall... what is the IP address

My connection is very poor, so looking forward to testing how this performs

vpnDarknet wrote:Are you handing out a generic password to Beta testers for this conf, or would a hashed token allow access?

It is pretty much like token access as it exists with the exception that it will accept any value(other than NULL) as a valid token. You can use your existing token without issue and it will work, just at cryptofree speeds.

Doh! My bad, I haven't freed up the IP for my firewall... what is the IP address

My connection is very poor, so looking forward to testing how this performs

Edit: found it 212-129-34-154... although still no luck

Dots, not dashes, but yes. Just take your existing working config for normal connections and change the remote address(IP). That should do it.

A highly parsimonious explanation for the confusion about the caps, and the sense that the capping is "off," is this: we've done a poor job of distinguishing between bits - little "b" - and Bytes - bit "B." This can happen really easily. Software folks tend to thing in Bytes: 1 teraByte hard drive. Network geeks (usually) thin in bits: a gigabit NIC. It's sort of a big deal which one you choose, because...

1 byte = 8 bits

So, if you go through the posts and try to figure out who's talking about b's and who's talking about B's, it makes sense. This has also happened during the dev process; indeed, some on team thought we were doing little-b 256/128; some public comments on the project have been really clear on this. Other dev folks were thinking in Bytes, and when they did the testing and tuning they reported back to the team that it was "throtting accurately at 256/128" - which it was, and is... in Bytes. D'oh.

Which sort of means we provisioned the service with nearly an order of magnitude more network capacity per session than some had expected. Apparently that was meant to be, so (for now) we're leaving those big-B caps.

I will say this: we tested the hell out of the capping methodology, from all angles. It works. It's not easy to break, either. So it's a good test-bed for seeing how weird speedtest metrics can be sometimes. We know the NIC is only letting in/out packets at a certain rate. That's just a hair off the hardware level of network control. So if you go five or more layers up the OSI model, and some application thinks it's sending packets alot faster than that... well, I trust close-to-metal alot more than up-the-stack, to be blunt.

Second, it'd be really great to distil down this dev-type thread into a howto that folks can jump right to and follow. Someone's opened up such a thread placeholder already, so hopefully that final step can be completed and we'll have a more or less robust connection guide for Linux cryptofree.

Oh and yeah this...

A generous twitter colleague has been kind enough to share these Linux start/stop scripts, as well as some icons to go with them. Which is generous, and much appreciated:

Thanks for posting the results. It is always interesting to see how these present in the wild.

During in-house testing of cryptofree, we found enormous variance between what speedtest.net (and other automated, web-based tools) report, and what wgets and other closer-to-metal tools report. In the end, we decided to trust the closer to metal tools, despite the fact that in many cases the web-based tools showed far higher packet transit rates.

Also, we watched statistics reported by hardware NICs as part of our testing, and those universally aligned more closely with what we were seeing in wget/terminal applications. And in the end, if the NIC says it has transited a certain number of bits of raw data, that is what ends up being "true" in a sense.

My own suspicion is that the particular manner in which we've implemented tc-based capping has an unintended impact on the mechanisms underlying these web-based testing tools. I have a couple theories on what exactly is going on, but not having tested them they remain only theories at this point. It is worth noting that the web tools are, for cryptofree, always over-reporting throughput as compared to both terminal and NIC-based metrics. An important clue, we think.