Ξ 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 ΞΞ We've updated our CA certificate. All members need to be using the latest ones by Dec 22. See this page for more infoΞ

This is a placeholder thread for discussion of what has colloquially come to be known as the "cryptostorm router" over the years - and which we're now officially referring to as "stormlink" (http://stormlink.is is the domain, although currently it's just parked on top of our main site). We've been asked about a "cryptostorm router" many, many times - and in general our reply has been twofold:

One, we support a passle of opensource router firmware frameworks and we're always happy to put the effort in necessary to support more. So if folks want to do router-side cstorm installs, excellent! We're 100% in favour of such topologies, and always have been. There's some excellent tutorials here in the connection guide subforum on doing router-based cryptostorm installs, and we've many network members running from the router.

Two, we've all along been (not so) secretly hoping that someone would come along and bundle up cryptostorm service with a hardware router and sell that bundled solution as a standalone product. Heck, we've pitched just that model to more than one prospective vendor... many of whom agree it sounds like a great idea. That's because it is a great idea. Sadly, none of these discussions has resulted in a commercially-available product thus far.

As a result, we've realised that we might need to do this in-house - or at least "prime the pump" with an in-house version - in order to get it into the market quickly and effectively.

Then came anonabox...

Sigh.

We're not going to weigh in on the details of that situation - nor are we going to join in the gleeful denunciations of the backers of anonabox. Partly that's a reflection of our distaste for mob-frenzy judgement-frenzies, and partly it's because we've not taken the time to really learn the facts of the whole thing - nor are we likely to ever take the time. So we're not passing judgement on the motives or decisions of those involved.

However, the anonabox kerfuffle certainly did demonstrate one thing clearly: people really, really want a customer-friend, easy-to-use, cost-effective, plug-and-play appliance that will tunnel all their 'net traffic through a secure channel. That pent-up demand is simply not being met by geek-centric solutions that require flashing firmware, installing OS patches, compiling underlying libraries, configuring iptables, and so forth. We're not denigrating the great opensource projects out there which make these setups possible for the technically inclined; rather, we're observing that these solutions in and of themselves won't be useful for 95+% of folks out there.

Therefore: stormlink.

On the one hand, this is far from rocket science to implement - all the tools exist, thanks to good work by good opensource teams. Rather, it's a question of stringing them together securely, reliably, resiliently, and elegantly. That's not easy - but it's not like coding up some amazing new thing out of thin air, from scratch.

On the other hand... hardware. Yikes. We're not a hardware-based team, and don't pretend to be one. So when we see heavy hardware questions, we recognize that we're not subject matter experts and won't become subject matter experts overnight. But we've decided that, despite the spooky nature of hardware gizmos, this is a worthwhile project & we will dedicate the resources necessary to make it happen.

Already in twitter we've had the benefit of advice and information from some really well-qualified hardware experts - by opening this thread, we're hoping to gather that and more in one place where we can winnow it down to a product/project spec.

This is a project we need to do, and we're doing it. We're not rushing into it, but having had years to ponder it and wait for it to be "done right" by others, we do have a bit of useful perspective as a starting point. Plus, we do know a little bit about secure network service by now

Our request: please share with us your questions, suggestions, recommendations, hard-won warnings, and so on. We'll do our best to leverage what we learn into the best, most elegant, most secure, most cost-effective route-based secure networking product we can create!

Straight from the bat, there would have to be two types of routers, one dealing with the Ethernet users out there... and the other dealing with the Wireless fans. I don't see any other way to approach such a task, successfully, as mentioned in the opening post if one is not willing to separate the herds.

It's obvious from posts on this forum... RAW configs (I don't call these Linux configs, I call them router configs... it's just happenstance that the code is written in Linux) are handled differently in comparison to OS-based configs. The same should apply for the router itself. This whole "travelling through the air" thing called wireless could break off into another forum thread which would reach 100 pages quick smart, and I guess the topic of Ethernet could garner some comments too.

All in all, for this to be taken seriously, and not just as a product pushed onto the market, one would be wise to cover the fundamental networking topologies (don't worry, just trying to sound smart). We all know what they are... 1) Wired ... 2) Wireless

marzametal wrote:All in all, for this to be taken seriously, and not just as a product pushed onto the market, one would be wise to cover the fundamental networking topologies (don't worry, just trying to sound smart). We all know what they are... 1) Wired ... 2) Wireless

It's quite possible I'm being obtuse here, but isn't the distinction between wired and wireless connectivity in this context merely a question of the below-layer-2 physical LAN communications channel? And while surely there's some security implications to be consider for packets are they come and go across the LAN, in general I'd always assumed the larger security issue at play here is non-LAN (i.e beyond the local physical space): the risk of someone surreptitiously installing a Narus surveillance box is (should be?) several orders of magnitude lower in one's own physical premises than it is at the upstream ISP or backbone transit provider.

There is a substantive point in that network sessions to cryptostorm that are instantiated directly at the client-side machine have the benefit of ensuring that packets are encrypted before they leave the physical NIC, a a matter of systems architecture. In contrast, for router-based installs, packets leave local machines plaintext (apart from any LAN-specific crypto; see below) and there is a trust placed in the router to handle the encryption... as well as a trust that those packets won't get snarfed up by an attacker pre-router.

Nowadays, wifi-based LAN crypto is reasonably robust - certainly we're no longer in the era of MS-CHAP based schemes that can be brute-cracked with trivial ease. And my knee-jerk assumption is that the risk of serious network session attack is proportionately lower on the LAN than it is ex-LAN... but is that actually accurate?

It could be argued that, given the relative ease of ensuring wifi-carried packet streams are encrypted locally as compared to the plaintext nature of wired LANs tech, a decision should be made to require wifi-based (and WPA-2 encrypted) local connectivity for any stormlink-ish device... deprecating wired LAN connectivity entirely, as a matter of security policy. Which, on the surface, seems counterintuitive... local wired connections aren't broadcasting network data hundreds of meters for all the world to hear if they simply decide to listen - but naively sending packets along a plaintext local wired segment only to have them picked up by an attacker could horribly expose sensitive network data to an attack that would simply never exist with a direct-from-client cstorm network session.

So, does this mean a user can use any computer operating system (within reason and common sense)? For example, a CS user making use of RAW configs DOES NOT need to have a Linux OS? All the RAW config users here, from what I have seen, all make use of Linux OS's. So, I am not sure if a Linux OS is required if one is to make use of RAW configs, so don't bite my head off...

Nowadays, wifi-based LAN crypto is reasonably robust - certainly we're no longer in the era of MS-CHAP based schemes that can be brute-cracked with trivial ease. And my knee-jerk assumption is that the risk of serious network session attack is proportionately lower on the LAN than it is ex-LAN... but is that actually accurate?

It could be argued that, given the relative ease of ensuring wifi-carried packet streams are encrypted locally as compared to the plaintext nature of wired LANs tech, a decision should be made to require wifi-based (and WPA-2 encrypted) local connectivity for any stormlink-ish device... deprecating wired LAN connectivity entirely, as a matter of security policy. Which, on the surface, seems counterintuitive... local wired connections aren't broadcasting network data hundreds of meters for all the world to hear if they simply decide to listen - but naively sending packets along a plaintext local wired segment only to have them picked up by an attacker could horribly expose sensitive network data to an attack that would simply never exist with a direct-from-client cstorm network session.

Pattern_Juggled wrote:It could be argued that, given the relative ease of ensuring wifi-carried packet streams are encrypted locally as compared to the plaintext nature of wired LANs tech, a decision should be made to require wifi-based (and WPA-2 encrypted) local connectivity for any stormlink-ish device... deprecating wired LAN connectivity entirely, as a matter of security policy. Which, on the surface, seems counterintuitive... local wired connections aren't broadcasting network data hundreds of meters for all the world to hear if they simply decide to listen - but naively sending packets along a plaintext local wired segment only to have them picked up by an attacker could horribly expose sensitive network data to an attack that would simply never exist with a direct-from-client cstorm network session.

Depends on the threat vector.

If your computer is in close physical proximity to the stormlink(You can physically see the two ends of the cable), there is not any reason to avoid wired.

There are reasons to avoid wireless they have absolutely nothing to do with encryption. That is, if your machine is 'pwnd', the attacker can see what local WiFi networks are available and pinpoint you in seconds. I have long recommended that people remove their WiFi/BT cards from their computers if they are serious about security. You can use a pocket-router as a wireless bridge and that is OK, but having your computer be able to pinpoint you to an intruder in seconds is a bad idea.

My recommendation, especially if you do not require more than 3-5Mbps, is to use the (usb powered) pocket router that you are hardwired to as the stormlink. Let the WAN side be the WiFi of the stormlink and the LAN side be the 1ft ethernet cable needed for this. This removes any network awareness from your computer and allows you all the portability that you could want.

I have had a router configured as a stormlink for almost a year now. I personally use WiFi as LAN because what I am doing(Torrents and Geoblocking) will not have any negative repercussions should my computer be pwned and my location be revealed. Anyone that is dealing with a hostile environment should not use WiFi as LAN.

I run dd-wrt and it's been a fairly positive expirience. Having a router makes your wan facing attack surface much smaller- simple purpose built routing software managing things, instead of gobs of bloated insecure modern OS... -with the systemD virus even formerly lite wieght linux distros are smelling kinda funny hear lately. With a proper router- the users computer doesn't ever have to know the real wan ip= best leak prevention possible. dd-wrt (and likely openwrt as well) segregate your wireless from you wired by default (sending both over vpn- but there's no lan to wlan bridge unless you purposfully set that up).

Unfortunatly I wouldn't consider my setup to be quite 'production ready'- it requires tinkering from time to time, I havn't experianced a connection failure yet (I expect it's comming honestly- happened semi-frequently with previous vpn provider) but it has had weird slowdowns, dns related lags, and ntp out-of-sync cert tls failures that cause (so far brief) (re)connection delays. An ip table rule to allow dns resolution would help this (hint,hint,poke) as then it could take advatage of both pool.ntp.org, and maybe even CS's HAF system (is that available for raw config? -load balancing would be nice..). Another irritating thing is my router is only compatable with a specific build of dd-wrt- and although the dev has been really good about jumping on critical patches, he's fallen a bit behind latetly- I worry that eventually the router won't be supported anymore. So I'd think compatability should weight heavy into whatever decision is made- going with a mini-itx system, with say pfsense, makes allot of sense here... That's what I'd be looking at should this router go caput- cheap wifi replacement + a seperate powerful mini-itx router setup.

My dd-wrt router is 1ghz dual core- it may be slightly slower vs native performance of openvpn on early i7, on an "8mb" connection- I once tested @ 620kBs vs 650kBs... (~700kBs w/o vpn) maybe that's small enough to be an anomoly? idk. For future proofness I don't think going any weaker with the hardware would be wise. -I kinda laugh at these Pi routers; the price is apealing, but how could they have the horsepower to manage any decent throuput- for about double the $$ you can get 10x the processing power with a mini-itx system- that would seam a good way to go, if not simply with a high end off the shelf wifi routers for a bit more $$$. both asus and netgear make open-wrt/dd-wrt compatable units I belive, err 8mo or so ago they did at least.

If you guys are looking for an all in one solution, you might try these guys http://www.FlashRouters.comallthough- some of there other clientell will probably make you cringe.. ie hidemyass

I find the sentament on wifi being more secure kinda shocking- admitedly I don't keep up much with hacking, but last I'd heard it was quite possible to sniff and break wpa2 after recording a few logins, has that changed? Personally I just run an openwifi- my routers admin is pass protected and dhcp bound to eth mac/ip only though, no ssh, no telnet, no radius, no cfs or usb, and as meantioned no wlan to lan bridge- if I were in a city invironment, I might have things buttoned up a bit more, as is I don't use wifi for anything even remotely scetchy and I havn't really considered being hacked through wifi as much of a threat. am I wrong?

TLDRseperate routers are awesome.dd-wrt is still a bit quirky (and needs an iptables rule for dns)High end wifi-routers are great but may have long term support issues.weak hardware is weak and will ruin CS expiriance.check out http://www.FlashRouters.commini-itx is powerful/cheap, pfsense rockssecure wifi- lolz.

If may, I'd like to share my experience of using CS through a router, and some of the problems I have had. It may be useful, but it's only from a layman consumer's POV, not from the uber geek level. I suspect, if you get this thing going, you'll deal with it's consequences at some point from a percentage of your costumers.

I bought what I considered a relatively good router to get round very slow speeds on a WRT3500L - an Asus RT-AC68U. Our connection was about 25Mbps down, and about 1Mbps up.The provider promised speed was 38down and 4 up, but I wrote off the difference...maybe I'm too used to being ripped off.

I installed Tomato and set up as per the guide on this site which connected first time. But. Try as I might I could not get more than about 11/12Mbps. Not cool, especially as the 3500L was getting around 6Mbps and was a lot less than half as powerful, by my understanding. It was difficult not to let this problem transfer into my feelings about CS, admittedly mainly through ignorance...but I trawled the net looking for solutions, even doing a thread here. Again and again I read and was directly told "It's because the processors in consumer routers are shit." For some reason instinct was telling me this was not the whole problem, it kinda felt dogmatic. Experimenting with over-clocking (checking bogomips for actual changes)...made no difference, which made me further question that dogma. But anyway, long story short this went on, with me reading away for fixes...till, one day, our connection dropped hard - 4Mbps - and our phone line went dead.

Turns out pretty much everything about the copper wire coming from the fiber connected street cabinet was fucked. The wire outside to the pole was frayed, the connection as it entered the house almost rusted away, the face place of the main phone plug antiquated - as it all was. Out it was all ripped, and replaced with new...

New naked speed - 42Mbps/6Mpbs. Fuckin yay! I then started OpenVPN/CS, with an un-pimped CPU at that stage, to get my shit nice and randomised through my ISP....22Mbps!!!! After over-clocking (1200/800) ~28Mbps!!! (admittedly, though, wget sucking up an ubuntu snappy distro 'only' got about about 25Mbps, but still makes me gush after previous speeds)

So, yeah, the "all consumer routers are incapable of reasonable speed" dogma appears to be wrong. Line noise - whatever the true infrastructure issue/sofware interaction - will play a big role in the consumer experience, regardless of the uber-geekness of the router's creator...I presume. I think perhaps that that should be mentioned when users start associating their problems with your service in this context. On the Asus, the presumed fact I was hitting a hard limit inherent to the device itself was just plain wrong.

Many thanks for the update, and I'm glad you saw an increase in performance after your issues with the physical infrastructure were rectified. Bear in mind though that the relationship between your naked speeds and your CS speeds has pretty much remained the same - 48% (12Mb/s from 25Mb/s) before and 52% (22Mb/s from 42Mb/s) after, 59% after overclocking (according to wget).

If we ignore the overclocking result - because end users generally don't overclock PCs, let alone routers - the percentage gain is 4%. If I remember rightly, the same connection originating from your PC was pretty much 100%.

So yes you are quite correct when you state that external (especially copper) infrastructure can play havoc with Internet connections, however the presumption that domestic routers are weak when handling VPN encryption still holds.

...you telling me I have to get this I Fixed The Internet tattoo removed?

There is a good chance I'm an idiot, yes, and a long winded one at that. But-but-but...I read about this. Loads! I can accept the mistake is mine, but all the advice on this ceiling issue seemed to imply it was a hard one, and not relative. I thought I was being told that 11/12 speed (18 on the laptop) would be it, be it through a 25Mbps connection or a 100Mbps. This has clearly confused me!

Well bloody hell...I'm still confused as to why over-clocking did not change a damn thing pre the remedial works on the physical connection, yet it clearly is capable of more as evidenced by the big-ish jump said pimping elicits post-fix. That ceiling ignored to a lesser degree by the laptop confused me more at the time, as the more power = more openvpn speed was not shown on the router when it was given more umpf...is that just fucking weird or am I missing something else?

And I wouldn't have learned (a little) about over-clocking, and a few other things, had I not been head-butting this issue...although just enough to hang myself, clearly . It has been useful to this very newbish newb who has a lot more enthusiasm than skill and experience . For now.

Sorry to bring my issues to this party. Perhaps binning my waffle to the basement forum would tidy it up.

Your waffle is appreciated, so it stays. The advice we gave (including myself) was no doubt based upon the assumption that there was nothing fundamentally wrong with your Internet connection - i.e. no broken, frayed or corroded cabling, no loose connections etc.

As for why you got no performance increase via overclocking, pre-remedial works...I'm not entirely sure, to be honest. I suspect however, that

a) due to the fact that OpenVPN has to decrypt every packet,b) the router has no AES hardware support so the crypt process has to be done by the router's CPU,c) OpenVPN is single-threaded, and d) the router's CPU has to then process the decrypted packet

the rate of incoming packets was simply too low for overclocking to have any real effect. Once you got a clean signal across your external link, the router's CPU had more to work with.

Cheers mate I'll no doubt continue to fiddle. If I gain any clarity, with numbers and stuff:D, I'll let you know. Or just drop it, which may be equally as likely if my foray into the Dr Suess webpage of network topology is anything to go by. Baffling and best left alone

Oh, and just to be clear - I don't mean to sound like I'm bitching about the advice I've had here. That's not my intention at all, I'm really appreciative of the info on this forum. I'm actually bitching about all the internets.

One last thing and I'll STFU, promise. Can I use Tap instead of Tun on a linux based router with CS? I see the windows widget seems to use Tap. I want to play with http://linux.die.net/man/8/ifenslave - bond 2 CS instances, each with it's own token - but it has a hatred of Tun. The process is important to me in itself, just a learning vehicle really, but is it worth putting effort into or just a deranged, stupid waste of time in your mind? Wadaya fink?