Ξ welcome to cryptostorm's member forums ~ you don't have to be a cryptostorm member to post here Ξ
∞ take a peek at our legendary cryptostorm_is twitter feed if you're into that kind of thing ∞
Ξ we're rolling out voodoo network security across cryptostorm - big things happening, indeed! Ξ
Ξ any OpenVPN configs found on the forum are likely outdated. For the latest, visit GitHub Ξ

cryptofree.me howto Android | cryptofree.me/cfandroid

cryptofree: full-bore cryptostorm protection... for free! Capped to 1 megabit down / 500kb up, it's a great way to use cryptostorm in a pinch. Play nice & be safe, ok?
User avatar

Topic Author
Posts: 159
Joined: Sat Mar 02, 2013 12:12 am

cryptofree.me howto Android | cryptofree.me/cfandroid

Postby cryptostorm_team » Thu Nov 20, 2014 8:46 am

{direct link: cfandroid.cryptofree.me}

This is pretty easy...

  • Download this file and put it somewhere on yer android device:
    (5.26 KiB) Downloaded 1339 times

  • Download "OpenVPN for Android" from the Google store for free - This is the best, open-source client for OpenVPN. That Arne Schwabe guy did a great job with this app, and if it works out for you send him some $'s here. Source is here for the paranoid/wise.
  • Run that app!
  • Import the file we just saved on the phone...

  • Click on the disk icon (bottom right?) to save it
  • Now click on the line it created called "cryptofree_client_android1_4.conf"
  • When it asks for a user/password, type "snowden" "rocks!" (actually it doesn't matter what you type, but type something)
  • Check "remember password" and CONNECT!!

As always, please share any issues!


cryptostorm_team - a shared, team-wide forum account (not a person)
PLEASE DON'T SEND PRIVATE MESSAGES to this account, as we can't guarantee quick replies!
--> feel free to use any of our other contact channels, or post in the support forum
cryptostorm: structurally anonymous, token-based, unlimited ☂ bandwidth, opensource, darknet data security for everyone!
keybase.io validatorsonename.io validatorsPGP key @ MITnetwork statuscryptostorm github
support team bitmessage address: BM-2cTMH8K5JnjbfSALjZtSkRWCLfc3Tr8GBV
support team email: [email protected]
live chat support: #cryptostorm

User avatar

Posts: 129
Joined: Thu Feb 27, 2014 2:42 pm

Re: cryptofree.me on Android!

Postby vpnDarknet » Thu Nov 20, 2014 12:39 pm

It wouldn't connect for me so I changed the server address to {redacted, to avoid Wrath of Cthulu}

Just playing, it seems pretty good, faster than expected.
Buy your tokens via vpnDark.net and cryptostorm cannot and does not know anything about users - no link between a token & purchase details
Unofficial Wiki cryptostorm access guide
Ways to talk to me

User avatar

Posts: 1493
Joined: Sun Dec 16, 2012 6:34 am

linux-cryptofree.cryptostorm.net HAF entry = win

Postby Pattern_Juggled » Thu Nov 20, 2014 7:40 pm

vpnDarknet wrote:It wouldn't connect for me so I changed the server address to {redacted}

Acting as the neighbourhood curmudgeon, I do my duty by warning that direct IP-based connections to individual node instances are brittle, in that any problems with that particular instance will result in a hard-fail for the entire session. Such "problems" are routine parts of large-scale production network management and are, as such, not entirely uncommon: instance hits session-count cap and loadbalances to other nodes and/or other instances; instance is down for maintenance or software update, instance is subject to short-term DoS, datacentre in which node resides has a connectivity glitch, etc.

As such, the officially supported - and strongly recommended - "remote" target for cryptofree sessions from Android is:


Additionally, the following four HAF-based redundant TLD remote mappings will also pull from the same pool of deployed cryptofree linux/*nix instances:


These four cryptofree balancers are 100% interchangeable - pick whichever you want. Note that, alas, in the current build of the Android OpenVPN client used in this thread, there is no support for the "--remote-random" conf parameter. A shame, as that's something we use elsewhere within our network architecture to add yet another layer of hostname-lookup resilience in the face of TLD-based cache poisoning, BPG-level, or brute-censorship attacks on specific canonical domains and/or TLDs that serve as part of our session connection framework.

If any of these five HAF resolvers don't return an IP when queried (either manually, or just via inclusion in the "remote" parameter of an Android session connection), that's something the network admin team here would really like to hear about. It could be that there's some system-level problem and we'll be able to squash a bug. It could be transient and will resolve all by itself (DNS, as deployed in the wild, is based substantially on black magic, occult worship, and the blessings of the god of chaos himself: Cthulu). It could be evidence of an organised attack on access to our network, or it could be something specific to your local network/handset/wireless provider environment. In any of these cases (apart from the Cthulu matter), there's benefits to poking at the issue rather than working around it with a hard-coded IP.

Finally, given that cryptofree is definitionally a load-balanced network service, we really need the flexibility at the network level to ensure we can stripe sessions across instances in something resembling a coherent manner; unfortunately, folks hitting specific session IPs prevent us from doing that with their network connection attempts, and that in turn ripples through the fabric of the entire system-level process of keeping resources available for session connections. There's a fascinating mathematical structure that underlies the cryptofree approach to decentralised resource balancing... I'd be happy to go on for much longer describing it, but tl;dr it breaks when people hard-code IPs. So don't - please - if possible.

All that said, we don't block IP-to-instance connections (yes, we could if we wanted to; no, we're not going to) and instead I routinely issue these dire, long-winded, boring warnings as an alternative method of keeping these IP-based profiles reasonably in check. Yes: you're welcome.

As cryptofree has sped thru beta testing into something resembling a production deployment, we've been lax in getting proper documentation out to the membership - we hope folks will continue to help backfill that need via contributions here in the forum, and we appreciate the understanding that our unconventional "build it, deploy it, document it on the fly" methodology here sounds astonishingly dumb... but in this case might be somewhat less dumb given the benefit of having the service accessible even as we smooth out the documentary requirements, collaboratively.


    ~ pj

Return to “cryptofree: no-cost cryptostorm network access”

Who is online

Users browsing this forum: No registered users and 2 guests