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:

1. Take a look at the pre-launch development thread if you're curious about the backstory and technical architecture of cryptofree.

2. The OpenVPN configuration file ("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!

Thanks,

~ cryptostorm_team

Here's the fulltext of the conf, to make public review more efficient:

Great philanthropy, this could change the industry

I guess more users per node, turns up the anonymous factor for all?

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

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.

Hello,

I tried to test your cryptofree access on Max OSX with Tunnelblick, but haven't been successful in connecting. The log says the following:

Options error: --txqueuelen not supported on this OS

Could you let me know what I have done wrong? Do I need to edit the conf file to suit my system?

Thanks in advance!

mrdude

mrdude,

Please open conf file and delete the line: txqueuelen 686

If there's an issue with logging: devnull, please follow the following thread:
viewtopic.php?f=32&t=6108&p=8740&hilit=tunnelblick+log#p8740

Regards,

/Fermi

Hello Fermi,

Thanks for the quick help! Your instruction solved the problem instantly. I'm connecting from China and so far am seeing very satisfactory speed and responsiveness.

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

mrdude

cryptostorm_team wrote:connection speeds per-session are capped at 256kb downstream & 128kb upstream.

This part is not working. I'm mostly limited to 1.5-2Mbps, but I'm seeing spikes up to 5-9Mbps(10/1 connection).

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.

I did some tests using a public site hosting iperf (located in France).
Results are:

Without Cryptofree connection:
------------------------------------------------------------
Client connecting to test-debit.free.fr, TCP port 5001
TCP window size: 22.9 KByte (default)
------------------------------------------------------------
[ 3] local 192.168.1.204 port 52187 connected with 212.27.42.153 port 5001
[ ID] Interval Transfer Bandwidth
[ 3] 0.0-10.2 sec 11.5 MBytes 9.42 Mbits/sec

With Cryptofree connection:

[[email protected] ~]# iperf -c test-debit.free.fr
------------------------------------------------------------
Client connecting to test-debit.free.fr, TCP port 5001
TCP window size: 20.9 KByte (default)
------------------------------------------------------------
[ 3] local 10.55.0.2 port 59714 connected with 212.27.42.153 port 5001
[ ID] Interval Transfer Bandwidth
[ 3] 0.0-11.5 sec 1.38 MBytes 1.01 Mbits/sec
[[email protected] ~]# iperf -c test-debit.free.fr
------------------------------------------------------------
Client connecting to test-debit.free.fr, TCP port 5001
TCP window size: 20.9 KByte (default)
------------------------------------------------------------
[ 3] local 10.55.0.2 port 59715 connected with 212.27.42.153 port 5001
[ ID] Interval Transfer Bandwidth
[ 3] 0.0-12.1 sec 1.38 MBytes 955 Kbits/sec
[[email protected] ~]# iperf -c test-debit.free.fr
------------------------------------------------------------
Client connecting to test-debit.free.fr, TCP port 5001
TCP window size: 20.9 KByte (default)
------------------------------------------------------------
[ 3] local 10.55.0.2 port 59761 connected with 212.27.42.153 port 5001
[ ID] Interval Transfer Bandwidth
[ 3] 0.0-12.1 sec 1.38 MBytes 954 Kbits/sec
[[email protected] ~]# iperf -c test-debit.free.fr
------------------------------------------------------------
Client connecting to test-debit.free.fr, TCP port 5001
TCP window size: 20.9 KByte (default)
------------------------------------------------------------
[ 3] local 10.55.0.2 port 60194 connected with 212.27.42.153 port 5001
[ ID] Interval Transfer Bandwidth
[ 3] 0.0-12.1 sec 1.38 MBytes 955 Kbits/sec
[[email protected] ~]# iperf -c test-debit.free.fr
------------------------------------------------------------
Client connecting to test-debit.free.fr, TCP port 5001
TCP window size: 20.9 KByte (default)
------------------------------------------------------------
[ 3] local 10.55.0.2 port 60195 connected with 212.27.42.153 port 5001
[ ID] Interval Transfer Bandwidth
[ 3] 0.0-12.1 sec 1.38 MBytes 953 Kbits/sec

Results seem stable, but not according to: 256kb downstream & 128kb upstream.

Regards,

/Fermi

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.



EDIT: I've sent some of this information off for review, and if it's what I think it is, it should be a simple fix

Unreliable old Speedtest giving false results for the burst, it seems. However, it does appear someone confused bytes for bits on the caps.



Traffic graph seems to confirm it. (Note: OS X double counts the traffic because of the architecture)

After some discussion, we're going to leave the caps as they are and see how it goes. Further changes to proposed speed caps will likely be announced here.

Lignus wrote:

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

vpnDarknet wrote:

Lignus wrote:

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.

@thread

yields:

2014-11-10 17:16:19 (207 KB/s) - `/dev/null' saved [12500000/12500000]

@Lingus - Thanks man much appreciated, updating the .conf with the IP address worked... & even I'm not that much of a n00b to enter an IP address with dashes

Freemium

2014-11-11 20:24:58 (201 KB/s) - ‘/dev/null’ saved [12500000/12500000]

Compared with my terrible non throttled connection

2014-11-11 20:29:21 (251 KB/s) - ‘/dev/null’ saved [12500000/12500000]

Scanning back through this thread, two things become apparent.

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:




Cheers,

~ pj

Speedtest.net: Ping 98ms | DL 1.92Mbs | UL 10.49Mbs

highlighter wrote:Speedtest.net: Ping 98ms | DL 1.92Mbs | UL 10.49Mbs

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.

Thank you,

cryptostorm_admin