Private Network / Cloud Network

Isn't this what openvpn was created for? :-)

@sbrendtro:

If Linode could implement custom private networks in a way that spanned multiple data centers before RackSpace implemented it, Linode would be one step ahead!

Look at what Rackspace charges versus what Linode charges.

Imagine what Rackspace's R&D budget is versus what Linode's R&D buget is.

Think about how many engineers each company has to throw at such a project.

Personally, I don't want to Linode to start charging Rackspace prices, nor do I want Linode to start providing crappy Rackspace customer service.

Why is it some people just can't leave a successful business model alone - not every provider needs to be a swiss-army knife.

@sweh:

Isn't this what openvpn was created for? :-)

I've contemplated using openvpn on the private network, but a solution like that probably wouldn't survive a serious PCI compliance audit. Plus, running a vpn chews up quite a bit of processor cycles.

@vonskippy:

Look at what Rackspace charges versus what Linode charges…. Imagine what Rackspace's R&D budget is versus what Linode's R&D buget is…. Why is it some people just can't leave a successful business model alone - not every provider needs to be a swiss-army knife.

Again, as I said, I'm sticking with Linode. However I don't buy the fact that it takes a huge R&D budget to accomplish what Rackspace is doing with private networks. I think it takes creative people coming up with a creative solution to a problem. It simply requires thinking outside the box. And it would hardly require turning Linode a swiss army knife.

I am curious however, if anyone else sees the value in something like this… or if its just me. I know I've regretfully had several clients that I had to steer other places because we simply couldn't implement what they wanted to do on Linodes, and the primary reason was because of how the private network was implemented.

It looks like all RackSpace did was build a web interface for Open vSwitch, which is built into XenServer anyhow. Not all that much R&D required…

That said, there seems to be no real difference between doing that and using OpenVPN, except that RackSpace's solution is totally unsecured, in that it really just gives you software VLANs and still has your data flying around over their internal network in the clear. With OpenVPN, you get the same functionality, but your data is encrypted while it flies around.

If anything, the OpenVPN solution is both more flexible and more secure.

@sbrendtro:

@sweh:

Isn't this what openvpn was created for? :-)

I've contemplated using openvpn on the private network, but a solution like that probably wouldn't survive a serious PCI compliance audit.
I'd argue the opposite; with openvpn you control the endpoints and secure the data transmission, rather than relying on an outside config that's external to your machine. OpenVPN is the more secure solution.

@Guspaz:

That said, there seems to be no real difference between doing that and using OpenVPN, except that RackSpace's solution is totally unsecured, in that it really just gives you software VLANs and still has your data flying around over their internal network in the clear. With OpenVPN, you get the same functionality, but your data is encrypted while it flies around.

If anything, the OpenVPN solution is both more flexible and more secure.
Plus OpenVPN can be used cross-vendor; you could have servers hosted with multiple suppliers and secure a network between them.

@sweh:

I'd argue the opposite; with openvpn you control the endpoints and secure the data transmission, rather than relying on an outside config that's external to your machine. OpenVPN is the more secure solution.

I definitely understand your point of the security of OpenVPN in this situation… its perfectly logical… but sometimes the PCI standards are illogical and fail to keep up with technology like this. I've been through audits before that would fail on this, simply because it doesn't fit the "standard".

Another of my initial concerns with OpenVPN on a Linode is the CPU utilization (based on previous experiences with OpenVPN on multiple Xen guests). I don't know if things have gotten any better in this regard over the past couple years… possibly some testing is in order.

And then there's the simplicity of someday being able to click "add a secure private network" in the admin to set up secure networks of several Linodes. OpenVPN config on the other hand… not so simple. The primary reason I stopped hosting my own Xen servers and switched to Linode is that they make it so much simpler. I spend less of my time managing the Xen nodes and more of my time on the servers themselves building out the business solutions. Simple is good. Linode is good.

I've never had a problem with openvpn using a lot of cpu on Linode, I've been using it on and off for years.

As for rackspace, they still use ftp for their cloud sites, I don't think security is their highest concern ;)

OpenVPN does have some "click to enable" style options, like OpenVPN Access Server (a commercial product). It's intended for more of a star topology, though, if memory serves.

OpenVPN CPU usage is really not a concern; a single core in a Linode should be able to saturate a gigabit connection, but your linode has four cores, and can't send at one gigabit (50 Mbps upstream cap by default, subject to increase if you request and need it).

I'd be surprised if the PCI standards don't include any mention of VPN, since VPNs are as old as the hills. Bizarre unencrypted and insecure software-VLAN stuff like what Rackspace is doing would be far less likely to be covered by the PCI standards. Sending all of your data in the clear over an untrusted network really doesn't sound like a great idea when you're dealing with credit card info…

@sbrendtro:

@sweh:

I'd argue the opposite; with openvpn you control the endpoints and secure the data transmission, rather than relying on an outside config that's external to your machine. OpenVPN is the more secure solution.

I definitely understand your point of the security of OpenVPN in this situation… its perfectly logical… but sometimes the PCI standards are illogical and fail to keep up with technology like this. I've been through audits before that would fail on this, simply because it doesn't fit the "standard".
PCI standards (I work in security in a megabank; there's a good chance you have one of our cards) typically have high-level security requirements and then, as the auditee, it's up to you to demonstrate how you meet those requirements. Using "standard technology" makes it easy to demonstrate. Using 'something else' makes it an education campaign; you need to educate the auditor.

Dealing with auditors is an art. A properly managed OpenVPN solution will pass PCI "[e]ncrypt transmission of cardholder data across open, public networks" requirements; an externally managed VPN (such as Rackspace's) would be harder to prove since that will require your auditor talking to Rackspace to prove their setup is encrypted and can not allow untrusted endpoints to join the VPN and sniff the traffic. Alternatively ensuring that your endpoints use SSL encrypted channels (eg SSH) for all communication would also meet the requirements; no VPN needed.

Proving that Rackspace encrypts is difficult since they never claim it does, and the software they're claiming to use doesn't support it…