cryptostorm exitnode clusters: listing+requests+roadmap

i0n · Post by **i0n** » Tue Nov 12, 2013 5:08 am

{direct link: cluster.cryptostorm.ch}

In the ovpn config file there is a gateway called "exitnode_balancer.cryptostorm.ch". Do you plan to support other gateways or will there always be a single one? Will you deploy gateways in countries other than Canada?

Guest · Post by **Guest** » Tue Nov 12, 2013 5:31 am

i0n wrote:In the ovpn config file there is a gateway called "exitnode_balancer.cryptostorm.ch". Do you plan to support other gateways or will there always be a single one? Will you deploy gateways in countries other than Canada?

From what i can remember/ what i took it as, is that canada is a good test gateway. With the .is Domain and the stories of Iceland being a nice lil haven of protection right now, and Iceland gateway I assume is sure to pop up. Thats just my .02.

DesuStrike · Post by **DesuStrike** » Tue Nov 12, 2013 6:22 am

The bruno_exitnode is kinda a "test_node" for now. Next to come is a German exit node if I am correctly informed. In general I can say that there will be more exit nodes to come as we go along.

Keep in mind that cryptostorm is unlike most VPN providers and not just rents the next best VPS in country X to provide an exit node there. They are very picky when it comes to choosing a suitable colo and as far as I can say finding one for Germany already wasn't all that easy.

This list is absolutely inoffical and just reflects the information I was able to gather and still remember!

In full production mode there are/will be:

- Canada
- USA
- Germany
- Switzerland
- Iceland
- and probably more

Mousy · Post by **Mousy** » Tue Nov 12, 2013 4:20 pm

Okay, responding to something said on Twitter, this is a placeholder for information pertaining to exitnode clusters and a build-out roadmap for clusters to come!

Let the information dump commence in 5, 4, 3, 2… GO!

I've left the poll regarding next round cluster choices for another thread, I think that keeps the right signal-to-noise ratio. Feel free to correct!

cryptostorm_ops · Post by **cryptostorm_ops** » Wed Nov 13, 2013 10:15 am

We'll be populating this thread with relevant info shortly. Currently in prep for production is our German exitnode cluster - we should be ready for in-house testing in a couple days, and addition to the full public exitnode pool following immediately.

Additional clusters have been targeted in U.K. (Isle of Man), U.S., & a dedicated unmetered machine in Iceland. More details on those when we do a proper update to this thread.

Running a poll to get a sense of member preferences for additional cluster locations is an excellent idea.

Respectfully,

~ cryptostorm_ops

cryptostorm_ops · Post by **cryptostorm_ops** » Sun Nov 17, 2013 6:24 pm

Guest wrote:From what i can remember/ what i took it as, is that canada is a good test gateway. With the .is Domain and the stories of Iceland being a nice lil haven of protection right now, and Iceland gateway I assume is sure to pop up. Thats just my .02.

We've stayed with a single geographic exitnode cluster - in Québec - to improve the effectiveness of our network and parameter tuning. Load-balancing across disparate geographic clusters is a black art; we know how to do it and do it well, but it's not the situation in which to be chasing down incremental improvements in network configuration and performance.

We've had generally excellent working relations with the systems administration team at iWeb - they're exceedingly knowledgeable about the guts of network tech, and have been generous with their time and expertise as we tune our own configuration. They've even helped us debug a very, very troublesome Xen virtual NIC bridging issue that had us at wit's end for quite some time.

As we have tuned the baseline OpenVPN configuration and implementation considerably versus a "stock" install, there's been extensive testing and adjustment of the guts of the networking framework during this extended beta test phase. Of course, that's not necessary if you just install "out of the box" OpenVPN - like most "VPN services" - but the security implications of doing that are horrific.

Some folks have chafed a bit that our "official" launch hasn't been announced yet, and we're still in beta with the network (release 0.92 for the framework). That's because of tech ops, so you can blame our tech ops team for the extension of our beta process. We have felt that further tuning with only the Québec exitnode cluster would prove fruitful, even after performance was adequate. We were correct - even today, we've found some additional adjustments that appear to have jumped effective throughput on a per-session basis considerably.

This is why we beta test. It's also why we didn't make our beta test with a bunch of distributed clusters - there's no real way to performance-tune that setup.

As to additional clusters, tech ops is currently testing out the OS/hypervisor (paravirtualised Xen on x86 architecture, CentOS) setup on our German node. Once that passes our review, we'll stripe it with our "golden image" VM & ensure it's mapped into the load balancer properly. Then, we'll open it to some private beta testing with existing network members to ensure there's no unexpected snags. Then, it enters the "pool" via the above-cited load-balancer DNS entry. At which point it becomes part of the production topology.

From what we've heard from the development folks the version 1.0 widget includes client-side exitnode selection; internal test versions of the 1.0 widget already have that code operational and it works well. Remember that there's no "saving your exitnode preference in the cloud" since there's no "account" in the cloud - only tokens. Node selection is and will always be determined client-side. This enhances the security model.

Every cluster is built on dedicated, leased hardware we configure from the metal forward: hypervisor, OS, dom0, guest VMS. We're not in the game of laundry-listing "servers" that are just cheap, insecure VPS instances with little production capacity. We'd much rather a small handful of node clusters to manage well and closely, than a giant pile of pathetic VPS "servers" that barely carry enough traffic for one of our higher-throughput cryptostorm network sessions. It might not play well in the marketing game, but whatever. We're not in the marketing game. Sorry.

Exitnode cluster administration sits at the core of our tech ops responsibilities, and is something we work hard to do well - and to improve over time. It might not be as glamorous as widget development or crypto magic, but it's what moves packets around without drama. Which matters.

~ cryptostorm_ops

cryptostorm_ops · Post by **cryptostorm_ops** » Thu Dec 05, 2013 3:38 pm

This morning, we completed a major capacity addition to our Montréal exitnode cluster. The new machine has been cycled into our loadbalancer as the primary connect point, with existing capacity deprecated to fallback status. Cryptostorm members don't have to make any changes to have the transition take place (we cycled VMs to initiate the transition over to the primary machine, which takes place transparently during a session).

As member network traffic has increased and increased again, our primary test hardware in Montréal began to feel the strain. In fact, after much troubleshooting and fine-tuning of network performance we finally came to the conclusion based on all available metrics that it has been CPU that's bottlenecking total network performance. This is vastly different than traditionally is the case with "VPN services" - for example, we've seen 300+ megabit/second throughput on a box with dual processors (older procs, too) and CPU utilization not go over 20%. Ever. But, with cryptostorm's crypto suite selection choosing vastly more powerful (and CPU intensive) algorithms and ephemeral session cycling parameters, this has flipped totally in reverse: now, we're seeing boxes choke on CPU long before any sort of networking bottleneck comes forth.

(for those technically curious, we've seen unusually high packet losses on our virtual NICs, within the Xen framework, that act as SDN-based gateways between domU "guest" VMs and domO hypervisors - even on paravirtualised OS frameworks)

We've tuned, and tuned, and tuned... convinced we were missing something obvious in resolving this apparent CPU bottleneck. Eventually, our resident crypto geek (pj) convinced the rest of the team that, yes, these cipher suites can make smoke come out the ears of a big, modern, multi-CPU server. Easily. Astonishingly, he was proved right - we tend to think of him as like that guy in Jurassic Park ranting on about how "life will find a way" and "chaos manifests" and whatnot. Except with him, it's crypto.

Anyway.

With the help of the great folks at iWeb, we got a line on a badassed, CPU-heavy machine with 24 gigs of RAM (!!). We stripped down all non-security-essential elements on our standard exitnode "golden snapshot," and began the process of provisioning it for production use. This was given primary-priority in the work queue, meaning our tech folks have worked cyclical shifts 24/7 to bring things up as fast as safely possible.

The machine is now in production after accelerated internal testing. It seems quite speedy thus far.

We ask folks to hammer it with heavy loads, and let us know of any performance issues - good or bad. We're closely watching packet characteristics at the physical NIC, to ensure we've got no bottlenecks. There's still some fine-tuning of the kernels' TCP and general network characteristics going on, and for the next few days we expect to see ongoing per-session improvements.

The existing nodes in the cluster are still online, and we're tuning our loadbalancer to dynamically stripe sessions across machines in the cluster based on realtime performance characteristics - this is an ongoing process.

Cryptographic suites, session parameters, auth procedures, and all other security-centric components do not vary between exitnodes. There is no "more secure" exitnode than another, and thus no need to change between them apart from performance considerations (pingtimes/latency, throughput, packet integrity, route topology, etc.).

Here's how we do the process, and information for folks that might want to compare specific nodes in the cluster manually to see how performance is evolving. Note that the next release of the widget includes menu-based exitnode selection; the information below is purely for those curious about the inner workings of the system.

exitnode_balancer.cryptostorm.ch is the old (deprecated) resolver - per bugfix submitted by a beta tester, it's now been replaced with exitnode-balancer.cryptostorm.ch (although the deprecated version continues to be maintained for backwards compatability).

exitnode-balancer.cryptostorm.net is the new, preferred resolver for network wide best-performance - we're using this TLD as frontline network admin preference (although we're striping in numerous fallback TLDs in parallel for systemic redundancy in the event of DNS-based attack vectors)

exitnode-shadow.cryptostorm.net is the new node in the cluster

exitnode-bruno.cryptostorm.net is the previous "primary" node in the cluster, still online and available for direct connections and in use as fallback rolling forward

exitnode-germany.cryptostorm.net is our new German cluster; it's very nearly ready for production connects and may well be able to handle connections at the time of this forum post going live (we'll announce it formally, as well)

exitnode-iceland.cryptostorm.net is not yet mapped, as the cluster is still in provisioning stage

(all resolvers are set to a fairly low TTL setting of 1337 seconds... naturally)

For those who prefer to manually control their node selection by swapping out the "remote" entry in the client configuration file - this is fine, and there's no security risks or operational problems in doing so. Once you're finished experimenting, you can default back to exitnode-balancer and return to automated node/cluster selection, if you prefer.

As a reminder: our servers are actually servers - physical machines we run from the hardware forward. By controlling our machines at the "iron" level, we retain substantially improved security and audit controls, as well as direct capability to ensure full cipher suite compatibility. We don't spin out hypeware lists of "a hundred servers" that only represent low-capacity, insecure VPS instances - that may be easier and aid in fooling the less experienced into thinking that these networks are "bigger," they aren't. That's like saying a house with 100 rooms is "bigger" than one with only three... and the three rooms are a warehouse, as compared to a dollhouse with dozens of tiny little cubbies.

Let us know how the cluster is performing. We're happy with the location, and the datacentre - even as we know we've got plenty of room for performance improvements as we grow. Our goal is to seamlessly handle 100megabit/second individual network sessions without any loss of throughput as compared to bareback/plaintext transit, if needed. Indeed, because encrypted packets generally avoid packet-shaping/DPI tools often deployed by local ISPs, many members see faster real throughput of network data on-net with cryptostorm than bareback. This is how it should be - those who say that "VPN networks are always slower" are referring to poorly-run, poorly-provisioned, poorly-administered "networks" generally using default setting, parameters, libraries, and protocols.

We tune every piece of our network to be (of course) secure... but also fast as fuck. That's our internal motto: fast as fuck. We want it to scream, always. If it doesn't, we drop everything to make it do so. Indeed, if/when you see us tech ops folks vanish from view, it's likely because we're seeing suboptimal network performance and we're digging into that to get it back to fast. We monitor performance continuously, internally, and a drop in performance is a "all-hands alarm" state for our team.

Fast as fuck - let us know if we're doing the job.

~ cryptostorm_ops

marzametal · Post by **marzametal** » Fri Dec 06, 2013 11:28 am

Is there any way I can log into the German server instead of the Canadian one via the widget? .... the only reason I ask is because I think Germany is closer to Australia than Canada is?! *cbf searching for the answer on StartPage*... lmao

EDIT: For the first time, I've seen 1MB/s downstream... woo hoo!!!

DesuStrike · Post by **DesuStrike** » Fri Dec 06, 2013 7:02 pm

Forum Helper to the Rescue:

Frankfurt am Main (Germany) to Australia: 14.607,70 km

Quebec (Canada) to Australia: 16.186,43 km

If you can tell me the city you live in (or some other big city near that) I can give you even more exact distances. Australia is a big country after all.

EDIT: And the German exitnode is still not accessible anyways.

marzametal · Post by **marzametal** » Sun Dec 08, 2013 6:21 am

Melbourne

DesuStrike · Post by **DesuStrike** » Sun Dec 08, 2013 8:38 am

Frankfurt am Main (Germany) to Melbourne (Australia): 16.320,70 km

Quebec (Canada) to Melbourne (Australia): 16.624,89 km

Wow! This is actually way more different than I thought! Australia IS a big country!

So, enough posing around for me: http://www.luftlinie.org/
It's in German but as long as you are capable of reading the metric system (so basically everybody on this planet except for the USA

) you should be fine.

Lignus · Post by **Lignus** » Sat Dec 14, 2013 11:24 am

cryptostorm_ops wrote: This is vastly different than traditionally is the case with "VPN services" - for example, we've seen 300+ megabit/second throughput on a box with dual processors (older procs, too) and CPU utilization not go over 20%. Ever. But, with cryptostorm's crypto suite selection choosing vastly more powerful (and CPU intensive) algorithms and ephemeral session cycling parameters, this has flipped totally in reverse: now, we're seeing boxes choke on CPU long before any sort of networking bottleneck comes forth.

Yup. We have now entered an era where CPUs matter again. The cipher suite you guys are using is intensive. Without AES acceleration available in Haswell/some earlier highend Intel or the newer AMD processors, you were looking at about 50-70MHz per megabit. Even being generous, if your servers were running 16 cores of 2.4GHz and the sessions were perfectly balanced, you are still not likely to get more than 600MBps from the machine. Seeing as OpenVPN isn't multithreaded, which means more overhead from dividing up the processes. If you brought old servers online, there were probably quad core and not much more than 2.6GHz, leaving you guys scratching your heads when you were barely, if at all, pushing 150MBps.

I have not had the chance to run AES-NI versus None on my i7 machine, but I suspect the performance difference is 2-4x performance per clock based on other benchmarks I have seen on AMD cpus (4x boost) that support it. Given that, an AMD FX-8350 (8x4GHz) probably pushes 500+MBps without AES and potentially over 2GBps with AES acceleration enabled. My estimates are based on a fairly even distribution of bandwidth per core. The same FX-8350 running only a single instance isnt going to top 70MBps for a single user without AES. With, that single customer could probably top 250MBps if they were similarly tuned and had the bandwidth.

Pattern_Juggled · Post by **Pattern_Juggled** » Sat Dec 21, 2013 3:02 pm

This introductory tutorial on optimizing throughput on OpenVPN-based network sessions has some useful background on the parameters driving optimal performance and the constraints introduced when 'real' crypto is mixed into the production equation:

https://community.openvpn.net/openvpn/w ... orks_Linux

cryptostorm_ops · Post by **cryptostorm_ops** » Sat Dec 21, 2013 6:15 pm

We have just posted release candidate version 1.1 of the client configuration files, which allow for exitnode & cluster selection as well as enhanced failover/redundancy against DNS-based filtering attacks, & round-robin stochastic connection selection capabilities.

The files are available here and feedback is being sought as to any issues that may surface as they go into full production.

Thank you,

~ cryptostorm_ops

cryptostorm_ops · Post by **cryptostorm_ops** » Wed Dec 25, 2013 4:33 pm

cryptostorm_team · Post by **cryptostorm_team** » Mon Jan 06, 2014 5:49 pm

Our Icelandic exitnode cluster is live and in production. We've capped simultaneous connections at 300, for the time being, as we performance-tune the loadbalancer logics within the cluster.

Attached is the requisite client configuration file for connections. This is tested & structured for "raw" connections - we are in process of provisioning a widget-specific framework for this cluster, and will roll out the needed installer files shortly. If folks want to try manual edits to the config of their Windows widget in the meantime, we'd be curious to see the results you achieve - but we've not tested that edit ourselves and thus cannot confirm it's going to be immediately able to connect until we are ready with the dedicated daemon instances.

Enjoy

marzametal · Post by **marzametal** » Tue Jan 28, 2014 4:04 am

Lignus wrote: Yup. We have now entered an era where CPUs matter again. The cipher suite you guys are using is intensive. Without AES acceleration available in Haswell/some earlier highend Intel or the newer AMD processors, you were looking at about 50-70MHz per megabit. Even being generous, if your servers were running 16 cores of 2.4GHz and the sessions were perfectly balanced, you are still not likely to get more than 600MBps from the machine. Seeing as OpenVPN isn't multithreaded, which means more overhead from dividing up the processes. If you brought old servers online, there were probably quad core and not much more than 2.6GHz, leaving you guys scratching your heads when you were barely, if at all, pushing 150MBps.

I have not had the chance to run AES-NI versus None on my i7 machine, but I suspect the performance difference is 2-4x performance per clock based on other benchmarks I have seen on AMD cpus (4x boost) that support it. Given that, an AMD FX-8350 (8x4GHz) probably pushes 500+MBps without AES and potentially over 2GBps with AES acceleration enabled. My estimates are based on a fairly even distribution of bandwidth per core. The same FX-8350 running only a single instance isnt going to top 70MBps for a single user without AES. With, that single customer could probably top 250MBps if they were similarly tuned and had the bandwidth.

I have a question about this... is this implying that CPUs need to be hardcore on both server and client side, or just server side? Using logic, I think both sides would need a killer CPU setup. I doubt a Pentium II could provide decent support for the darknet (also the router comes into play too). This has got me thinking about my system... Intel Core i7-2630QM CPU @ 2.00GHz, 16GB RAM (no Paging File). Would building a new system around a better CPU, lets say (fork out cash for a Intel Core i7-4960X Processor Extreme Edition (15M Cache, up to 4.00GHz) or Intel Core i7-4900 Desktop Processor Extreme Edition (8M Cache, up to 3.80GHz)) with 64GB DDR3-1866 RAM boost network performance?... assuming one also picks a reputable decent router too...

Pattern_Juggled · Post by **Pattern_Juggled** » Wed Jan 29, 2014 12:42 am

More often, we see bottlenecks client-side at the router level... because residential routers are a hot mess, to be blunt. About 80% of performance tuning of network throughput likely needs to be done router-side, versus on the client machine itself, in most cases.

Further, even the "slowest" modern CPUs tend to have more than enough horsepower to handle our cipher suites. We've some dev team members running heavy cryptostorm sessions off of laptops in the 2008 era vintage... no problems. Now, if you try to push 100megabits/second through one of those, you might need to tune it a bit - but I bet we could actually make it sing, if needed.

Server-side, recall, we're dealing with session concurrency issues. We can individual hardware units (physical servers) at 300 concurrent sessions - even before that, we're doing some serious kernel tuning to ensure good throughput without chocking things inadvertently.

Depending on your OS, there's ample session tuning opportunities at the kernel level - for Linux, starting with all the params in sysctl, which is a treasure trove of tuning goodness

For Windows, err... I've not the faintest idea. Sorry.

Post by **parityboy** » Wed Feb 05, 2014 6:24 am

Just out of interest, I've noticed one territory conspicuously missing from your planned exit node list. Considering the fact that many VPN exit nodes are/were placed in NL, is there a specific reason why that territory is not in your immediate plans?

On a completely separate topic, the point about CPU performance is an interesting one. Do you think that crypto accelerator or GPGPU cards will become an attractive option for offloading (or assisting) the CPU?

cryptostorm_team · Post by **cryptostorm_team** » Tue Feb 18, 2014 2:34 pm

During the past two weeks, cryptostorm's network has seen new peaks in member connections and total traffic transiting across the darknet. This is excellent!

It also means we're getting ready to add new cluster capacity. This will include more hardware in existing clusters - Montreal is due for new capacity, in particular - as well as new clusters entirely. We've our ideas on where on the map clusters would be most useful, in terms of pingtime considerations and to some degree political realities, but we'd much prefer to open this up to community engagement. For reference, our current clusters are found in:

~ Montréal, Québec
~ Frankfurt, Germany
~ Reykjavik, Iceland

So, which of the above options would be your top choice for the next exitnode cluster to add to cryptostorm?

DesuStrike · Post by **DesuStrike** » Tue Feb 18, 2014 3:20 pm

Concerning additional cluster capacity I would opt for Frankfurt/Germany. I put heavy load on this one regularly but also want low latency performance for online fps gaming. The latter always worked great btw. No micro lags, no disconnects, no packet loss. Good job!
But tbh you are the ones who know best which cluster has still lots of capacity left and which one needs additional ressources.

As to new clusters:

Russia - good for cheap license purchases and registration for software with region lock. (Often cost only 1/3 or even less.) Also we need a cluster in the eastern parts of the world anyways and Uncle Vladimir wouldn't mind helping us, or would he?

UK/USA - Mainly due to region restrictions on some media. On the other hand the legal stuff might get tricky. Especially patriot act bullshit.

Sweden - For some reason people love Sweden based VPNs. Maybe cater towards this strange preference, even though I don't see any real benefits from that location.

Pattern_Juggled · Post by **Pattern_Juggled** » Tue Feb 18, 2014 3:49 pm

DesuStrike wrote:Sweden - For some reason people love Sweden based VPNs. Maybe cater towards this strange preference, even though I don't see any real benefits from that location.

It's ironic, because Sweden has passed some particularly nasty data retention laws - that do apply to "VPN services" - and in general made it clear it's not at all to be considered a "data haven"... but back when Relakks was first selling tens of thousands of useless PPTP subscriptions, in 2007, they did some nice marketing about how Sweden would never violate the data privacy of citizens or behave like government goons! Since then, of course, they've acted as US stooges to harass Julian Assange, passed ugly snooping laws, and been outed as complicit with all sorts of NSA badness.

But the "Sweden is cool!!!" marketing still works for coattails-riding "VPN services," so they keep running the same kinds of ads - and people keep buying the story. It's... weird.

What Sweden did to TPB's founders is reason enough to see their government as essentially pariahs, to my way of thinking. Oddly, Sunde - the one pimping PPTP as "security" for years, and profiting from it, is the only one of the founders who didn't get ground underfoot by the Swedes. The other guys got the full "fuck you" treatment, didn't they - it's disgraceful. And to Peter's credit he's spoken out vociferously against it, just to be clear.

So, yeah, we didn't put Sweden on that list for a reason. I'd personally rather put a cluster in Russia and know full well the FSB's poking at it from Day One, than ride the crusty detritus of an old Relakks marketing campaign that hyped Sweden as data visionaries. Turns out that's Iceland's role - and that's why we worked so hard to secure dedicated hardware there, not coincidentally...

DesuStrike · Post by **DesuStrike** » Tue Feb 18, 2014 7:14 pm

That's why I called it a strange preference. If Sweden proofed anything the last few years then that they are one of the many willing henchmen of the US empire. But on the other hand: Same applies to basically all of the EU especially Germany, France and UK. That's why I also called it an option without any benefits.

But I can understand that there are reasons based on principle to especially avoid Sweden.

I also know that KG... FSB would be poking on a russian cluster instantly. But then again: I (hope to) know that this wouldn't impact on privacy/security a lot. Because really: I promise you that BND, Verfassungsschutz and NSA are doing the exact same thing in Germany.

cryptostorm_ops · Post by **cryptostorm_ops** » Tue Feb 18, 2014 7:59 pm

Update: we've just leased a nice little dedicated machine in the US as a starting footprint for our cluster over there - and are in negotiations on some serious additional hardware with a specialist premium-network provisioner, which likely will take a bit longer to complete and spin up. But the decision to create our US exitnode footprint has been taken - both based on early feedback here, and on structural realities.

Please do keep voting, as we're likely to bring a second new cluster online imminently, as well - and perhaps a third. Once clusters are established, they scale smoothly - so we do prefer to take on the work of spawning new clusters in batches, if possible.

Thank you,

~ c_o

edited to add: also, I've only just been informed (

) we apparently have a new cluster footprint in Paris, France. I don't know those details yet - appears to be a call pj made based on some particular circumstances with a datacenter he knows down there - but I'm told it's been purchased and, I assume, I'll eventually be told it's in queue for provisioning. So there you go.

Post by **parityboy** » Tue Feb 18, 2014 8:23 pm

I voted for Netherlands. I know an exit for the old CC network was there, and I assume the team is familiar with the Dutch DC setup process and all that jazz. However, I didn't see Switzerland on the list. Is it a territory you've considered?

marzametal · Post by **marzametal** » Wed Feb 19, 2014 2:51 am

Australia!

Pattern_Juggled · Post by **Pattern_Juggled** » Wed Feb 19, 2014 12:48 pm

parityboy wrote:I voted for Netherlands. I know an exit for the old CC network was there, and I assume the team is familiar with the Dutch DC setup process and all that jazz. However, I didn't see Switzerland on the list. Is it a territory you've considered?

We're actually in negotiations regarding a cluster in Zurich - it might take a bit of time, but I believe we'll put together a really nice platform there.

As to a Dutch cluster... yes, indeed. We were the first "VPN service" to place a machine in Amsterdam back in 2008, so we're indeed familiar with the lay of the land. It's fine, I suppose. Neither good, nor bad. Just... fine.

Pattern_Juggled · Post by **Pattern_Juggled** » Wed Feb 19, 2014 12:50 pm

marzametal wrote:Australia!

This is something we'd quite like to do - what we're lacking is confidence in a datacentre over there that can meet our needs, just through lack of direct experience in that market on behalf of our team. So, if you've any recommendations we'd very much like to hear them as that's someplace we'd put a cluster tomorrow (literally) once we find a strong local DC with whom to work.

Post by **parityboy** » Wed Feb 19, 2014 5:02 pm

@PJ

Isn't international data traffic in the Asia/Australasia region rather expensive compared to say the EU or the US? Al least, that's what I've read...

acid1c · Post by **acid1c** » Thu Feb 20, 2014 7:20 am

Just a thought, but with all the Kim Dotcom BS going, and some of the news about NZ soon to be an internet powerhouse, maybe its of interest? Its at least the next closest thing to Australia.

Pattern_Juggled · Post by **Pattern_Juggled** » Thu Feb 20, 2014 6:44 pm

parityboy wrote:Isn't international data traffic in the Asia/Australasia region rather expensive compared to say the EU or the US? Al least, that's what I've read...

The best that can be said about transit costs is that... they make negotiating to buy a used car look transparent and simple.

Some places are unquestionably expensive due to hard constraints on actual cable capacity - Iceland, South America are two examples I know firsthand. And some are putatively "cheap" - like the US - but... yeah. Cheap isn't cheap, it's all over the map. And there's no standard pricing, no standard metrics, no standard QoS, no standard nothing.

I've been tangled up on provisioning data capacity since back in the mid 1990s... and I still routinely hear about "traditional" schemes for data pricing that are totally novel to me. Or just plain made-up! Some so complex it'd take a doctoral student to understand 'em - and even so I'd say they're incomprehensible. Billing that's simply random, or bizarrely tracked, or whatever. It's a total fiasco.

So we don't take at face-value much when it comes to assumed costs of clusters and/or nodes. Having enough experience on the purchasing side of things, we can generally work with providers "up the chain" from baseline retail, and thus often capture much better cost metrics for our sorts of traffic. Plus we do traffic shape internally, understand how to dicker on QoS, don't accept oversold "unlimited" plans, etc. So we get much, much more than what the average buyer gets - and that allows us to scale the network in a much different way than someone who is simply clicking around Google looking for "Cheap VPS Australia" or whatever.

I like the .nz angle - does Mega host anything down there, themselves? I know they're pretty tight with Leaseweb (for good reason - generally good folks), but I think most of that capacity's up in Europe isn't it?

Thanks for the feedback - it's all quite helpful.

Pattern_Juggled · Post by **Pattern_Juggled** » Fri Feb 21, 2014 6:29 pm

U.S. cluster in beta production:

UnSAe.cryptostorm.ch

Post by **parityboy** » Sat Feb 22, 2014 7:19 am

@PJ

Question concerning traffic costs for servers: is it true that in peering arrangements, outbound server traffic (responses) is cheaper than inbound server traffic (requests), hence the proliferation of asymmetric residential Internet connections?

DesuStrike · Post by **DesuStrike** » Sat Feb 22, 2014 7:36 pm

Obvious fake is obvious. I lack the powers to readjust the results but be assured that it is very easy to spot such manipulation even when it's not done in such an dilettante way like here. No we don't log your IPs upon voting. This wouldn't help anyways because duh... VPN?! But there are other ways which neither compromise on community privacy nor involve any kind of logging. Just an open eye and common sense.

This is a situation for the Admins to resolve but whoever thought to get through with faking the Luxembourg voting: You didn't.

Tealc · Post by **Tealc** » Sat Feb 22, 2014 11:31 pm

So I have my "2 cents" on this cluster thing....

1) I really don't believe that putting a cluster in the USA is the smart way to go, since the recent events I've shutdown 2 servers that the company that I worked for add in Florida and LA. We shouldn't trust a USA based company, period!

2) Switzerland is my "business" country, I'm currently living and working here. And speaking of putting a cluster here is a good bet, since this is probable the last country that I now, that P2P is actually legal, and this is the home of several very good app's privacy concern, like https://threema.ch/en/ (this is were I work

) for android and iOs (lol making a little pub here).
And the current network of data centers have a very good backbone connection to everywhere in the world, since we are actually in the middle of the EU, I do believe that this would be a fast server.

3) Thinking of cluster one country came to mind.... what about Portugal? For obvious reason for me and 10 people that work with me, this would be awesome

Post by **parityboy** » Sat Feb 22, 2014 11:36 pm

@Tealc

I've recently read that Portugal now have the 6th biggest datacentre in the world, which is also the biggest in Europe. Looks like Portugal is on the up-and-up.

Tealc · Post by **Tealc** » Sun Feb 23, 2014 3:52 pm

parityboy wrote:@Tealc

I've recently read that Portugal now have the 6th biggest datacentre in the world, which is also the biggest in Europe. Looks like Portugal is on the up-and-up.

I actually didn't know that.... great... Portugal is on the fast track to higher technology.
Actually when I left Portugal the maximum speed in a big city like Aveiro, was 2MB's/30MB's, that was with cable connection, now in the same street as before I could have 1GBps

, and that's only 4 years after.

Post by **parityboy** » Sun Feb 23, 2014 4:42 pm

@Tealc

I've also recentry read that in the UK, Virgin Media Business will sell you a 1Gb/s symmetrical link for £21,000 per year and that's if you're already connected to the Virgin network. If not, it's £30,000 per year. I swear these people make up their prices out of thin air...

Pattern_Juggled · Post by **Pattern_Juggled** » Sun Feb 23, 2014 6:49 pm

Tealc wrote:1) I really don't believe that putting a cluster in the USA is the smart way to go, since the recent events I've shutdown 2 servers that the company that I worked for add in Florida and LA. We shouldn't trust a USA based company, period.

First off, we're in 100% agreement that trusting a datacentre provider in the USA is simply impossible at this point in time. That's actually true in almost every country of the world, but for now let's focus on the USA. Given how the "rule of law" in that country has been effectively subverted by military spy agencies gone rogue, it's not reasonable to expect any kind of protection to be provided by the legal system there.

That said, we don't actually trust anybody with anything when we set up clusters.

This zero-trust assumption underlies our entire token-based auth model. Exitnodes, and clusters (which are just nodes in close geographic proximity that dynamically share/balance traffic), contain absolutely no customer information whatsoever. They have only a mongoDB shard which contained hashed token values and the details of token expiry. That's it. An attacker gaining full control of a node gets nothing in the way of stored data, or customer data. Indeed, there's no use in sitting on the node and waiting for it to query a central authentication database (and thus learn real-life data about a 'subscriber')... because there is no central database. No database calls, no core repository of customer information.

This is a very different approach to secure network service from the way every other "VPN service" does things.

Now, obviously we're not in the business of passively sitting back to allow attackers to gain control of exitnodes. We do our best to run tight IDS on those machines, to audit them routinely, and generally to keep a close eye on them. But, honestly, that's never going to be 100% successful - and anyone who claims otherwise is completely full of shit. Underneath the OS, even on a dedicated machine that you've striped personally with a known-good OS image (as we do), there's always a BIOS... and the BIOS is riven with security flaws, backdoors, and known vulns. That is reality. There is little anyone can do to comprehensively protect against that - an attacker who pwns the BIOS also owns the OS, in fundamental theoretical terms. Likewise, an attacker who pwns the CPU (or related bits of architecture, or even weird interstitial ephemeral stuff like Sergey Brautus' amazing "weird machines" running Turning-complete computational engines in things like error-control registers in RAM) also owns the BIOS, and thus the OS.

This isn't to fear-monger, but only to be honest and objective about things.

And if you're dealing with, say, the TAO... well, they know and use those tools as well or better than anyone out there. So a little exitnode sitting on a server in any datacentre in the world is relatively easy prey for a TAO operative with access to negative-day BIOS vulns/backdoors. With that, she can gain root - and do so secretly, without any practical way to catch her doing so (we do remote syslog archiving at distributed machines for exactly this reason - it's by far the most effective way to catch someone rooting a machine and then expertly covering her tracks as she goes... since the logs are also spooled off realtime to non-connected machines that can then be compared to local logs for any signs of pruning). Once she's root, she can of course rummage through all files on the machine, sit on eth(x) and capture packets, etc.

So we take it as axiomatic that such a threat vector is real, and extant in the real world.

When she, in this example, pwns one of our nodes, she has nothing locally of any worth whatsoever in terms of data-at-rest. A list of SHA512 hashed token values... which is mathematically impossible to reverse back to tokens... let alone real-life "subscriber" data. Some running tallies of network sessions running across that node, which means total traffic in and out per session. Our usual config files and whatnot, the detritus of running what amounts to a fancy, cryptographically aggressive router.

That's it.

She can sit on the NIC and watch packet traffic of course, but that's not terribly instructive given the work involved in rooting the machine. She can see plaintext network traffic coming in and off the NIC (the concomitant traffic going into and out of tun(x) is encrypted, but of course since she's root she can siphon that off pre-crypto... which is pointless since she can see the parallel traffic as it transits the other direction of the virtual NIC). What does that get her? Well, of course, that gets her session-specific payload data: login credentials and whatnot... so long as the target isn't using viable TLS (assuming web traffic) or something like OTR (for IM), or PGP (for email). Getting plaintext web traffic which is already plaintext, by rooting a box, is dumb: just sit at the rim of the datacentre and listen for those packets... they're plaintext anyway!

The most damning thing she can see is physical IPs of network members. That's nontrivial - but a physical IP isn't a real-life identity. If she's part of a drone targeting squad, she's going to use that IP to help zero in on an actual person - no legal process required. But if this is supposed to be part of some "legal case" in some jurisdiction, then just getting a physical IP is one step in many steps. And to winnow out that IP, she's going to have to have some way to know which network session is interesting... after all, there's dozens of sessions on each node. Who is her target? What profiling characteristics is she using?

Further, recall that our dynamic model of assigning network sessions to specific node is not an accidental design. Think about it: an attacker who wants to zero in on, say, one visitor to one website, gains enormous benefit if that visitor always transits the same network path: she can then sniff her way up that path, step by step. But we don't have static network paths - it's one core reason I am the legendary stick-in-the mud, on the cryptostorm team, when it comes to assigning exitnode IPs statically as connection parameters. Never! Over my dead body! Because, by keeping those assignments somewhat mutable, we make that sniff-tracing process much harder. For most network members, our "dynamic" or "locked" profiles see them cycling both amoungst nodes in a cluster and across divergent clusters, as their session reconnects (due to local network hiccups, the client machine powering-off, etc.). So the operative trying to track that one visitor... oops, now suddenly that visitor is routing through Iceland, or Frankfurt, or Paris...

To solve that problem, one would need to root all the nodes in all the clusters... which is entirely possible, but becomes substantially more time-intensive and risky in terms of making a mistake and getting seen in process. Even with full node pwnage, you don't get real-life identities, anywhere in our system, on any machine. We don't have that: we just have hashed tokens, in our production systems.

Which is to say: we don't have to trust a datacentre to put a cluster there. We don't trust any of our datacentres (well, we actually trust Datacell to a very high degree - but we need not, within our model). Not to mention, of course, that it's no more difficult for the TAO to root a machine in Vladivostok than it is to do so a machine in Dulles, Virginia - it's all remote exploits anyway, not like they have to drive over and sit at the keyboard.

(I've left off the whole question of KVM-style "remote admin" toolsets, ILOMs, FDE-on-the-fly, and related issues as to me they're essentially subsumed under the "BIOS vulns win" category in conceptual terms... but in practical terms we do take numerous steps to make known attack vectors deployed against these systems more difficult/expensive, as possible, to at the least slow down attackers and increase the chances we can see that a machine has been compromised)

Folks like US machines because it gets them access to Netflix and Hulu and stuff. That's cool - it's perfectly fine to use the network for those sorts of things. That the machine is sitting 20km from the Puzzle Palace is rich with ironic overtones, but I don't see how it makes for a genuine increase in risk for network members using the cluster. As to sniffing traffic in and out of datacentres, or even on local network segments within DCs... again, what one gets with that is transit traffic (assuming unencrypted) but no RL identities (unless it's in a plaintext email caught in transit, for example). Doing that kind of sniffing might be incrementally easier if the operative can drive down and stick a Narus box on the local network segment herself... but that never actually happens, in real life, so we don't really see that as dispositive when it comes to the security model itself.

The huge flaw in "VPN services," one that has been exploited by LEO and rogue spy agencies over and over and over is the "subscriber database." With such a database in existence, all attackers have to do is pressure the kid running the me-too "VPN service" to fess up who "owns the account" used on a certain day. Done. These kids - and I say kids, because in fact the people running 95% of "VPN services" are kids who got into the "industry" to make some easy money with an already-developed "business model" that requires no technical skill on their part, and only needs some SEO wizardry or good tricks to bribe "VPN review" sites into giving them fake high ratings from fake "customers - these kids always roll over and divulge customer info. They can't claim they don't have it, because obviously anyone running a "subscription business" has to know who their subscribers are. The whole "no logging" thing becomes totally, utterly pointless - as has been proved over and over when "no logging" VPN services betray their customers, get caught doing so, apologize, and keep right on going...

Incidentally, I read an interview published in the last few weeks with the "owner" of a big, highly-SEO'd "VPN service" that does great work in bribing fake positive reviews from VPN review sites. In it, he brags about how they've never "divulged information to law enforcement" about subscribers. Which is funny, because I had a phone call personally with the marketing guy at that very same "VPN service" last year... and he was bragging about how, in the month prior to our call, they'd extensively cooperated with the FBI five times without any subpoenas, court orders, notice to the subscribers, etc. Five times - in one month. That's just the FBI. He was bragging to me, 'cause the FBI gave him hats and caps and other schwag - and also the implicit promise that they'd get "special treatment" in their favour if they ever got into problems personally. I won't divulge who that is, and what company it is, as it was a private phone call and that's my ethical boundary. But it's indicative - that's not an uniquely sleazy company, just one of dozens who have popped up in recent years to make easy money selling subscriptions to naive buyers who think they're getting protected against real threats. They aren't.

Cut out the customer database, and you cut out the whole incentive to pressure the company to turn over information. What could we turn over, at cryptostorm? Tokens? Hashed tokens? What the hell use are those? That's the only "database" we have - for customers who buy tokens from resellers, we literally don't know a damned thing about them. Nothing. They're just network sessions. Pressure us all you want, and we can't tell you anything about them of use. Which makes pressuring us essentially pointless, which cuts down on the temptation to pressure, which is a good thing.

So, in sum, we're ok with a cluster in the USA because we don't need to trust the host country to put a machine there - and any "VPN service" who builds their model on the assumption that trusting a DC or country to be "secure" is engaging in a fairy-tale, far removed from reality...

Tealc · Post by **Tealc** » Tue Mar 04, 2014 1:09 am

@Pattern_Juggled

Every time that I read one of your remarks I just remember my old "Computer Science" Professor, he was one of the first ever to teach "Computer Science" and we would though that the "old Professor" would stop in time, but NO, he keeps on puling every remark and comment that we did over some paper like 10 years ago and putting it in actual examples and future possibilities.
One of this was about 3 years ago, when he said "What if someone sniffed a tier 1 provider like Level 3 Communications?", all of us instantly thought what would be the point in doing that, and what kind of "super computer" could do that..... Now I think that we wasn't very far from the truth

This for telling you that I deeply respect people that pointing out their opinion give real life examples from actual events and futuristic ones, and with your remark I now understand a little bit more of this brand new darknet that is so much more them a VPN service!
With this, I really think that it's time to put one question in the FAQ for the cryptostorm site: "What is Cryptostorm, and where do we stand?" and just paste your comment!

And since I see that you're one of the most active members here in the forum, how about an exit node in portugal?

Tealc · Post by **Tealc** » Tue Mar 04, 2014 1:18 am

parityboy wrote:@Tealc

I've also recentry read that in the UK, Virgin Media Business will sell you a 1Gb/s symmetrical link for £21,000 per year and that's if you're already connected to the Virgin network. If not, it's £30,000 per year. I swear these people make up their prices out of thin air...

Shit that's expensive! So for base cost in Switzerland, you would get 300Mb/s of download for 149CHF/month and for more 80CHF/month you would get 1Gb/s, that's 2748CHF a year (aprox. 1,867 GBP) so has you say, I think that more expensive than gold!

Post by **parityboy** » Tue Mar 04, 2014 3:08 pm

@PJ

Plus we do traffic shape internally, understand how to dicker on QoS, don't accept oversold "unlimited" plans, etc.

How do you manage to traffic shape encrypted packets? Basic rate limiting?

vpnDarknet · Post by **vpnDarknet** » Tue Mar 04, 2014 3:12 pm

I'd really like to use BBC iPlayer, but that's a huge cost I can live without

Post by **parityboy** » Tue Mar 04, 2014 5:37 pm

@Tealc

Is that 300Mb/s connection symmetrical or asymmetrical? What's the upload speed?

Tealc · Post by **Tealc** » Thu Mar 06, 2014 12:33 am

parityboy wrote:@Tealc

Is that 300Mb/s connection symmetrical or asymmetrical? What's the upload speed?

It's asymmetric:

300Mb/s Download
15Mb/s Upload

It's true that the upload speed is a big shit, but it's still great!
On the other side, there is another provider with fiber optic that gives 1Gb/s (download/upload) symmetric connection, but that's like 600CHF a month, I believe that that's mostly for business

Post by **parityboy** » Thu Mar 06, 2014 5:28 am

@Tealc

I really don't know what it is with European Internet providers, they just cannot stand the idea of handing out a symmetrical connection. I'd take 100/100 over 300/15 or even 300/30 which is what they have in the UK. It seems to be only the Scandinavian countries that recognise the benefit of symmetrical connections - or perhaps more likely, they don't have the protectionist mentality of the other countries. They also seem to have a greater diversity of providers (such as the electricity company) as opposed to the usual duopoly of cable TV company and incumbent state telco.

Tealc · Post by **Tealc** » Fri Mar 07, 2014 1:13 am

parityboy wrote:@Tealc

I really don't know what it is with European Internet providers, they just cannot stand the idea of handing out a symmetrical connection. I'd take 100/100 over 300/15 or even 300/30 which is what they have in the UK. It seems to be only the Scandinavian countries that recognise the benefit of symmetrical connections - or perhaps more likely, they don't have the protectionist mentality of the other countries. They also seem to have a greater diversity of providers (such as the electricity company) as opposed to the usual duopoly of cable TV company and incumbent state telco.

I have to agree with you.... in my case, that's fiber optic, I can't understand WHY they don't do symmetrical I would very much prefer to have at least half the download speed as upload

300/150 would be just great! But I can say that here in Switzerland that's really better that most country's I now, since at least the speed they announce are REAL, and they don't say "The download speed can change according the many factors that depends... blah blah blah"

Portugal is one of this country's, announcing 100MB download but they never exist, I remember a commercial from MEO (National Internet/TV/Phone Provider) that said "All over the country one membership, one price, one speed, all the year" and actually that's not even close, since this 100MB was with fiber optic and 70% of the country only have ADSL2+

marzametal · Post by **marzametal** » Mon Mar 10, 2014 5:32 am

Has the DNS address for the USA exit node been released yet? Or is it still just the following 3?
198.100.146.51
91.191.136.152
213.73.91.35

Lunar · Post by **Lunar** » Wed Mar 26, 2014 10:44 pm

Poll is kind of old but I thought I would cast my vote anyways. I think Russia or Hong Kong would be a nice addition to the locations. Even though Russia has many censorship issues you have to pick between NSA or FSB

asia · Post by **asia** » Tue Apr 08, 2014 9:35 pm

i quite like your vpn service and want to buy an aleph token, only thing holding me back, is the lack of nodes in asia.
i'm quite willing to invest in your service and trust you enough to believe you will still be around 4 years from now

would totally love you if you could bring a node online there, so that i can use it around china, south korea, japan, thailand, vietnam, without having a murderious ping to iceland.

any plans for this?
anything at all to say about using your service around asia?

i'm not sure if this is the right place or if should post here: posting.php?mode=reply&f=38&t=4885
or make a new thread...

asia · Post by **asia** » Sun Apr 27, 2014 1:07 pm

i humbly request a node in asia, maybe hong kong.
should have good routing to japan, south korea, china and south east asia.

having to use iceland will probably decrease performance quite a bit, sadly.

i will buy a lifetime token, if i can use it in asia and hopefully soon in more continents without a huge decrease in performance.

privangle · Post by **privangle** » Sat May 24, 2014 12:13 am

Hi,

what is about the Switzerland exit node ? Is it in progress ?

And yes, an NL exit node would be nice too.

Post by **cryptostorm_support** » Sat May 24, 2014 12:26 am

As for a server in Asia, there were some discussions taking place just last night on that subject. It's definitely a gap in our geographical coverage we need and want to cover, but we're still fairly early in determining exactly where best it should be located (so "where" is the primary factor here, as opposed to "when").

As for switzerland, the short answer is we don't have one ready yet. A slightly longer answer is that it's definitely something we would love to do (especially when expanding our load capacity), but I'm honestly not 100% how high it currently falls on our to-do list. I will poke at some bodies here for word on that.

Guest · Post by **Guest** » Wed May 28, 2014 7:48 pm

This is an important question. I wondered about the precise Asian location as well and I didn't come to a satisfactory conclusion so far.

First question is "how far" do we want to go into east. Considering that we have no Asian location but lots of European ones it should be far enough away from Europe but also central enough for all Asains to reach it well.

Russia covers practically everything from eastern Europe to the most eastern parts of the world but might not be the first choice for an exit point for obvious reasons. But maybe in future because we also have one in the United States of NSA so... same shit, different asshole. Russia has lots of nicely priced region locked stuff so it would be useful indeed.
China is also nicely placed, even better than Russia but I guess it's not really possible to run an useful exit node there. Maybe Hong Kong? I heard the Administration there is mostly independent and relatively open minded. I could be wrong though.
Japan is on an island so I guess the connection to it is not too good? They also have some very conservative laws there. Don't get fooled by all the kinky porn they produce. It may be to much on the east anyways.
South Korea is an American puppet just like Sweden and there is a reason why we don't have a Swedish exit point. I guess we should keep it that way.
Mongolia, Kazakhstan, and so on. I really don't know too much about them but I guess Internet infrastructure isn't the best there.
Moving towards the Arab countries we quickly get either too close to Europe or into territories with bad infrastructure and/or laws that lock down the Internet like in China.

Also on the agenda should be

Australia. Those are so far out that it's hard to service them well via mainland. They could also provide for all the smaller island around them and far southern Asia.
South Africa. The only country on the African continent that has the necessary infrastructure and is also "free" enough to run an exit point in it. The latter is just a guess though.
An South American country. Although I have no idea whatsoever what the situation in the individual countries is there. Brazil is giving very mixed signals lately and I really don't know in which direction they will be heading in future.

I hope I was able to provide some kind of starting point for a community discussion about this.

Post by **cryptostorm_support** » Sun Jun 01, 2014 9:50 pm

You raised some excellent points there; some of them were even part of our initial discussion

I'll make sure that the rest of it is seen by the other guys here as it (and any other input proffered by other community members) will help in picking the best location to serve everyone's needs.

asia · Post by **asia** » Mon Jun 02, 2014 3:22 pm

good points.

i would appreciate a node in Japan and South Korea, just from the performance/latency point as both are "islands" (korea kind of is, due to north korea), with very high speed "domestic" inter(intra)-net, but really bad connectivity once you access servers outside the island.
using a HK vpn in South Korea for example, degrades the performance immensely. while torrent performance goes down flaking from 1.1 MB/s to 2.7 MB/s instead of the usual 5-6 MB/s, accessing websites - which range from sites behind stellar CDN's with a node at the same ISP, to other CDN's at least closer to the region, to sites without any CDN, hosted in europe, us, whatever - can take 5-10 seconds now. definitely hard to accept, not only for korean standards, but also compared to normal slowish european, american consumer grade internet connections.
voip or gaming is impossible due to 300 to 600ms latency or so.

concerning censoring/data storing etc i'm not up to date and knowledgeable enough if moving to a friendly jurisdiction is enough to avoid the traffic being stored, since there's the whole route to consider, censoring can obviously be annoying.
a US node exists already, clearly not the best jurisdiction but good for users in the US.
i rather use a vpn in a not ideal jurisdiction with acceptable performance and have it always on, instead of no vpn connection active, only for select activity or having a huge performance loss and increased frustration.

my plea is to set up a japanese and south korean node, with another one in hong kong or singapore, for a more friendly jurisdiction.
this may be a bit much to wish for, right now i'm simply frustrated on what to do.

europe is so easy, iceland, netherlands, germany, uk, all pretty much the same, no noticeable performance degradation, at least in the western european countries from my experience.

asia is frustrating

Brazil · Post by **Brazil** » Thu Jun 05, 2014 6:07 am

Guest,

What mixed signals are you referring to regarding Brazil? Last I heard they were going to lay they're own cable across the Atlantic so they could avoid the UNSA.

It makes sense to set up a node in asia, for the market itself. Taiwan? As far as geopolitically neutral countries in the region I would say Malaysia or Indonesia. The Australians have been recorded as spying on the Indonesians and they're a bit upset about that so I don't see the regulation being more strict on VPNs. Malaysia has a few VPN hosts in there already, albeit I'm not sure about their security. But Malaysia has the infrastructure.. and it seems that they can't even find a passenger jet flying over their territory.

IMO strategically Brazil and Malaysia as your next spots. If you're looking at getting buy-in to your nodes, Brazil has a huge alternative software community that's very concerned about privacy (see Twister, ZapZap, etc.)

Graze · Post by **Graze** » Thu Jun 12, 2014 4:54 am

asia wrote:good points.

i would appreciate a node in Japan and South Korea, just from the performance/latency point as both are "islands" (korea kind of is, due to north korea), with very high speed "domestic" inter(intra)-net, but really bad connectivity once you access servers outside the island.
using a HK vpn in South Korea for example, degrades the performance immensely. while torrent performance goes down flaking from 1.1 MB/s to 2.7 MB/s instead of the usual 5-6 MB/s, accessing websites - which range from sites behind stellar CDN's with a node at the same ISP, to other CDN's at least closer to the region, to sites without any CDN, hosted in europe, us, whatever - can take 5-10 seconds now. definitely hard to accept, not only for korean standards, but also compared to normal slowish european, american consumer grade internet connections.
voip or gaming is impossible due to 300 to 600ms latency or so.

...

I hear ya on Asia. It was to be our next exitnode, however, we've run into some disagreements with our Canadian provider so may spin up another Canada node for redundancy, as well as another US node just to cover immediate growth.

By the end of the month we should have an Asia server.

Now, as to where exactly in Asia, I love the discussion here. However, I would want our customers to always assume that people above our servers somewhere on the tree are watching what comes out of the tunnel, so even though we never log traffic, and our encryption rocks, the regime that a server is running in can watch or be bought/bribed into watching that traffic. So I guess I'm of the "we should assume that all that exiting traffic is being watched, thus ANY country can be an issue."

As with Canada, if we run into any issues with a node or provider, we'll just spin up another. If the laws of the country begin to work against us (Canada is probably going to legalize warrantless customer requests next month, pretending it has something to do with child protection when it's clearly overreaching into politics and activism) we'll just leave that country. Nodes are fairly quick to spin up these days.

EDITED TO ADD: What I mean about "we should assume that all that exiting traffic is being watched, thus ANY country can be an issue" is that .gov has tools that allow it to see your Google, Yahoo, Facebook cookies, etc. on the exiting side of the tunnel, thus if you log into Google, you may be dragging those cookies around with you, allowing the .gov to make an educated guess about your identity when mixed with other data.

Graze · Post by **Graze** » Thu Jun 12, 2014 5:00 am

Brazil wrote: ...
IMO strategically Brazil and Malaysia as your next spots. If you're looking at getting buy-in to your nodes, Brazil has a huge alternative software community that's very concerned about privacy (see Twister, ZapZap, etc.)

I personally love the idea of a Brazil node. Just putting in my vote.

asia · Post by **asia** » Tue Jun 24, 2014 7:43 pm

very good to hear.
i really want some protection around here and will be sure to invest (aleph) into cryptostorm to give something back for fulfilling my wish, that is if the performance is acceptable in korea. i'm guessing you're gonna do hong kong, singapore or malaysia. i trust you and just hope that the latency and bandwith hit will be tolerable.

if only asia had better counry-to-country performance. i'm just too used to paradise (europe).

Guest · Post by **Guest** » Sun Jul 13, 2014 12:39 pm

damn, south korea's routing to the world is horrible.
a connection to japanese servers allow for ~50ms ping and good up/down performance.
hong kong increases the ping to 300ms+ with around 7mbit up/down from a 100mbit symetric connection.
very hard to tolerate and unsuable for voip/gaming and things like that.

looks like i need to bribe you to get a japan node or find another service

Post by **cryptostorm_support** » Wed Jul 16, 2014 12:18 am

lol, no, no bribes are necessary *extends hand with a wink* (jk, obviously

)

There was a lot of talk a little while ago about getting an asian exit node going, but I think it may have been subtly pushed a couple places back in the mental queue as other things came up. I've poked a couple people here for their current thoughts on that situation, and as always, input from folks familiar with that (rather large) region is always appreciated and will be considered before making a final decision on location.

privangle · Post by **privangle** » Sat Sep 20, 2014 7:44 am

Hello,

are there any news about new exit-nodes ?

marzametal · Post by **marzametal** » Sat Sep 20, 2014 10:22 am

I just produced an exit node cluster in my dunny bowl... lmao

Post by **cryptostorm_support** » Wed Sep 24, 2014 6:16 am

Privangle: A portugal exit node should be coming online shortly, and we still desperately want an asian node as well. That'll likely be next.

privangle · Post by **privangle** » Wed Sep 24, 2014 9:15 am

Support: thank you for your answer. So I'll look in from time to time to read about it.
All the best for the work!

Tealc · Post by **Tealc** » Wed Sep 24, 2014 11:00 pm

cryptostorm_support wrote:Privangle: A portugal exit node should be coming online shortly, and we still desperately want an asian node as well. That'll likely be next.

Did you got my last pvt?

Nevertheless I'm happy to know that the Portugal exit node is on track

Yyyyuuupppiiiiiiii

Post by **cryptostorm_support** » Sun Sep 28, 2014 8:34 am

Portugal exit node - "brisa" - should now be ready to accept connections

privangle · Post by **privangle** » Sun Sep 28, 2014 11:35 am

Thank you.

What exactly is the adress of "brisa" ?

I tried to take the conf-file of a working exit-node, by replacing the adress

<connection>
remote cluster-xxcountry.cryptostorm.net 443 udp
</connection>

by

<connection>
remote cluster-portugal.cryptostorm.net 443 udp
</connection>

but I don't get connect.

I tried also

<connection>
remote cluster-portugal.cryptostorm.ch 443 udp
</connection>

<connection>
remote raw-portugal.cryptostorm.nu 443 udp
</connection>

<connection>
remote raw-portugal.cstorm.pw 443 udp
</connection>

and

<connection>
remote raw-brisa.cryptostorm.net 443 udp
</connection>

and

<connection>
remote raw-brisa-1.cryptostorm.net 443 udp
</connection>

P.S. I run a Linux distribution (Suse)

Post by **Fermi** » Sun Sep 28, 2014 2:58 pm

Hi Privangle,

You can use:
Linux:
raw-brisa.cryptostorm.net/org/nu (94.46.8.229)
Windows:
windows-brisa.cryptostorm.net/org/nu (94.46.8.228)

Regards,

/Fermi

Post by **cryptostorm_support** » Sun Sep 28, 2014 5:56 pm

Tested and working on my mac, my config looks like this:

Code: Select all

remote-random

<connection>
remote raw-brisa.cryptostorm.net 443 udp
</connection>

<connection>
remote raw-brisa.cryptostorm.ch 443 udp
</connection>

<connection>
remote raw-brisa.cryptostorm.nu 443 udp
</connection>

Tealc · Post by **Tealc** » Sun Sep 28, 2014 10:32 pm

Yupi..... it's alive.... ehheeh I'm very happy with the new exit node, it was on my "agenda" for quite some time now.

BTW who comes up with the names for the nodes? eheheh brisa? Why? lol

privangle · Post by **privangle** » Mon Sep 29, 2014 3:02 am

Thank you for the informations.

Unfornately I always can't get connected to Portugal.

I tried the adresses from cs_support, I took a conf-file of annother country that works for me and I replaced the <connection> stuff, does not work for me.

I downloaded one of the official conf files from here: "raw"/Linux-based connections use these files... and replaced the adresses (<connection from portugal...> ) : doesn't work.

Something strange: I activated the log funktion :

Code: Select all

log devnull.txt
verb 5
mute 0

but the devnull.txt file is not produced or altered. (??)

20 times I looked up if I really use the right username (hashed token), password : yes I do, its the right one (same I use in the other connections).

I noticed the following thing:

In the Network Manager, when I import the conf file, the last adress in the list of connection adresses appears in the "Gateway" field.

Example:

Code: Select all

remote-random

<connection>
remote raw-brisa.cryptostorm.net 443 udp
</connection>

<connection>
remote raw-brisa.cryptostorm.ch 443 udp
</connection>

<connection>
remote raw-brisa.cryptostorm.nu 443 udp
</connection>

So the Gateway is raw-brisa.cryptostorm.nu in the Network Manager.

With a Network tool, I did a lookup onto these adresses.

lookup raw-brisa.cryptostorm.net gives the ip 94.46.8.229 (portugal IP, ok)
lookup raw-brisa.cryptostorm.ch gives the same ip. (ok)

lookup raw-brisa.cryptostorm.nu does not give this ip number, but a.root-servers.net nstld.verisign-grs.com. 2014092801 1800 900 604800 86400.

So I said to me, perhaps the gateway adress is the problem and I omit the .nu adress in the conf file. That means I try a conf file with only the .net and .org adresses. (In this case the .org adress appears in the "Gateway" field). But that does not work either.

(I dit the same lookup onto all config files on all adresses (.net, .org, .nu, .pw), all give the ip adress of the country.)

I don't know what else to try or to look for.

Do you have any idea, any suggestions ?

Post by **Fermi** » Mon Sep 29, 2014 4:05 am

Hi privangle,

The files you have used still contain the pre-heartbleed certificate. brisa is of course a post-heartbleed node.
Please change the certificate in the conf file with the following one (just copy paste): newclientcerts.zip, and import the file again.

raw-brisa.cryptostorm.nu doesn't resolve indeed , but having .org and .net should be sufficient (just redundancy).

Wrt. logging, if you use network manager, it will log to syslog (/var/log). I normally use 'tail -f syslog | grep openvpn' if I need a log while connecting.
(/var/log$ tail -f syslog | grep openvpn)

regards,

/Fermi

privangle · Post by **privangle** » Mon Sep 29, 2014 5:27 am

Hi Fermi,

You are great, thank you very much, your advice dit it !

The files you have used still contain the pre-heartbleed certificate. brisa is of course a post-heartbleed node.

So would you suggest to replace in all conf-files the certificate by the new one, or is there work to do on the old nodes before we can use the post-heartbleed-certificate ?