Ξ 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 Ξ

Looking for a bit more than customer support, and want to learn more about what cryptostorm is , what we've been announcing lately, and how the cryptostorm network makes the magic? This is a great place to start, so make yourself at home!

note: folks seeking the most current client configuration files need not wade through this entire discussion thread! The current versions are always posted in a separate, dedicated thread, and will be continuously updated there. Continue reading this thread if you're curious about the details of the config files, want to see earlier versions of them, or have comments/feedback to provide - thanks!

Within the next couple of days, the cryptostorm admin team is finishing deployment of an upgrade/migration of the core nodes within the Montreal exitnode cluster, and we wanted to give folks some background information and a place to discuss things as the process unfolds. So... here goes.

Since our alpha launch last year, we've had our core Montreal cluster hardware provisioned via iWeb. That's been a mutually beneficial relationship, and we do appreciate everything iWeb has done over the past year for the cryptostorm project. During that time, we've gone from an early-alpha concept with a few dozen testers using the service, to one that nowadays has member connecting from all around the globe in ever-growing volume. Whereas we used to watch aggregate traffic for gigabit-level perturbations, nowadays the network transits terabits of traffic per day... and those are on the slow days.

In other words, much has changed during that time; it's been quite a ride. And, sadly, now it's time for us to part ways from our colleagues at iWeb.

Back in the day, our traffic volumes fit well into their business model (that's what we've been told, anyway - they can of course speak for themselves!). But since then, iWeb has been sold, cryptostorm has grown like the proverbial weed, and now we find ourselves often disagreeing about billing issues. That's usually a good sign that it's time to part company, and retain a collegial and mutually respectful relationship along the way. It's a small world, after all, and surely our paths will cross again.

As a result, in the next few days/weeks, you'll notice - if you're the sort who watches such things closely - that IP resolutions for various cluster- & loadbalancer-based HAF entries will stop pointing at iWeb-based IPs, and start rolling over to new infrastructure providers. Mostly, we wanted to let folks know that panic is not required: this isn't the NSA or someone else pwning our infrastructure, or domain resolution functionality, or anything else scary. Rather, it's just us growing and expanding and deploying infrastructure that best fits the project's ever-expanding ability to serve more members, more effectively, around the world.

We don't expect any actual "hiccups" in the process; it should all be more or less transparent to members. You might, if you're a denizen of the Montreal cluster, see a network session drop and reconnect at some point (if you stay connected continuously for days at a time, this is more likely - not that there's anything wrong with that, just to be clear!). Otherwise, one time you reconnect to Montreal, that new connection will auto-magically resolve to the new instance IPs... and away you go. No muss, no fuss.

There will also be a migration of our much-beloved tokenizer (i.e. cryptostorm.nu) - which borrows infrastructure resources mostly from Montreal, for historical reasons too boring to explain here. Again, that should be a fairly seamless cut-over: just a divergence in IPs to which the host record resolves. But, in the event there's weirdness in some local DNS lookup caching on the part of members, we wanted to let everyone know so there's no unnecessary panic.

Also: if you do notice weirdness, we suggest you take whatever steps are needed to flush your local DNS cache. The process for doing so varies quite a bit between OSes and whatnot; if you're not sure how to do that, post a note in this thread & surely someone will share the needed info. Mostly, this isn't necessary... but sometimes it is. We thought you should know, anyhow.

In terms of improvements, we're cautiously optimistic that this infrastructure upgrade will result in consistently better throughput for all of our Montreal-based nodes. Historically, one of our machines in the cluster (dear old, beloved Bruno...) had some issues with a less-than-modern NIC; folks might remember that, last winter, we worked hard to upgrade the drivers for several of the Montreal NICS. Mostly that was successful, and we didn't migrate back then as a result. But, there have been transient performance hiccups ever since.

Basically, we were driving those machines too hard for what they're really able to support. In the "old days" of last fall, that wasn't a big deal. Nowadays, with so many members pushing 20+ megabit sessions up & down, consistently, that older-era hardware struggles to keep up (NICs are a big problem, even more so than proc or memory bottlenecks, usually). So upgrading is required.

tl;dr is that it's a good thing, and shouldn't be a big hassle - but we wanted everyone to know, so there's not worry about Bad Things having taken place mysteriously

By all means, feel free to post questions and comments and suggestions here. As always. In the meantime, if there's any major info updates, we'll post 'em here as well. If you don't hear anything like that, it means the migration/upgrade has gone off more or less smoothly. No news, in this case, is actually good news.

One thing to watch out for is for all you users who do not use the DNS names to contact the VPN nodes, but use IPs instead. My sig. has the a link to all of the current IP addresses, but they should probably be maintained in a sticky on the forum.

@admin

With regard to the NIC issue, who makes them? Intel, Broadcom or someone else?

I still haven't been able to connect to Montreal. I am using Linux Mint 17. I flushed my DNS and downloaded the config files again from the linux set up page and the cert. Iceland and Dynamic connects, but not to the Montreal servers. Are the config files on the linux connection page up to date? There was another post linking to a conf file called Maple, but it was a Windows conf file, so I'm wondering if the Monreal conf files on that page are out of date.

The only difference (next to the hosts of course) between the Montreal and Frankfurt config files (on:https://cryptostorm.org/viewtopic.php?f=37&t=5996), is the following snippet, which is present in the Montreal config:txqueuelen 486# expanded packet queue plane, to improve throughput on high-capacity sessions

are not valid, I do not know if the DNS records will be changed, so that the conf file will be reusable, or if CS will change the conf file.

In the mean time you can use Montreal by trying the conf file: cryptostorm_client_raw-montreal1_3 v2.confThis used the following FQDN's: raw-maple.cryptostorm.org 443 udp raw-maple.cryptostorm.net 443 udp(both resolving to 198.27.89.56 being the IP address of the raw type Maple node)

It repeats this block message for another 10 or so times and then times out.

If it's a bigger issue it's not a big deal for me. I still get a very solid connection on the german and icelandic servers. It's only that Montreal is a bit closer to me and I do get a faster connection with it. But no rush for a fix right now!

As Maple is a post-heartbleed node we need to use the new certificate (this has been overlooked in previous reply: cryptostorm_client_raw-montreal1_3 v2.conf).Please use: cryptostorm_client_raw-montreal1_3 v2_post_hb.conf

BTW I got this working. The certificates that are posited on parityboy's email sig (ca2.crt) make my linux mint connect to the montreal server properly. I recommend to CryptoStorm staff to update the certificates on the official "how-to" connect page for linux to use the new certificates, because the one that is on that page is not up to date.

Have Cryptostorm thought about having a single page to keep most of this info aggregated for proper versioning? It would make it easier for non-experts like me to find the right, or 'official' information.