Secure VPN internal IPs
While the internal IPs are nice, they are still open to the rest of the rackspace world, right?
Having a secure VPN interface that is accessible only to the other machines in the rackspace account would be awesome.
Daniel Huckstep
shared this idea
This is planned as part of the Network Services product based on NOVA.
31 comments
-
Christopher Amatulli
commented
Hate to recommend another vendor, but hamachi from LogMeIn works pretty well for this.
-
Roberto Aguilar
commented
@Chris M, @Brad Knowles:
I have tried rolling my own using OpenVPN. The problem I have with this solution is that in order for it to work you end up with a "hub and spoke" topography. In order to communicate over VPN everything has to go through a central machine. When the number of servers increase this becomes a bottleneck.
-
arobb
commented
If you actually think about it, servicenet is potentially extremely unsecure. If a malicious user can simply provision a box and start scanning on the 'trusted' side of the firewall then the system is clearly broke.
Amazon has security groups, could you do something similar?
-
Brad Knowles
commented
Unfortunately, S/WAN is a point-to-point VPN solution, IIRC. As you get more and more servers, you have an exponential progression in terms of how many other machines you need to connect to. That stops scaling really, really quickly.
-
Chris M
commented
This is not only possible, but pretty easy to do on your own. If you're running a Linux install just setup strongswan. You can build your own IPSEC network on top of the ServiceNet.
On CentOS:
1) Download and compile strongswan.
2) Alias eth1 and use a private address with a /32 netmask. E.G. 192.168.***.*** 255.255.255.255
3) Bring up the alias (ifup 'eth1:0')
4) Configure strongswan on both boxes (see strongswan documentation)
5) Bring up the tunnel.
6) Provided you installed and configured strongswan properly you should be able to ping any the adjacent node.You can set this up as a full-mesh configuration(so nodes talk to each other), or for a more simpler config spin up a small VM (256mg ram) and use it as a gateway. Configure all of your nodes to route say, /16 to the gateway and so long as you have ip_forward enabled and have strongswan configured to modify the firewall (leftfirewall), when you bring up the tunnels on the gateway you'll be good to go. This is probably the most transparent solution (to the system). Since the tunnels exists at a very low level after you get it configured you don't have to do anything complicated on the application layer. You can even use this solution to create a network across distinct virtualization providers, and or extend your corporate network to cloud...
I would take this solution over:
stunnel
ssh tunneling
OpenVPNany day...
-
Francisco Reyes
commented
This would be most useful if one could do VPNs of internal IPs across accounts too.
Perfect example.. due to redundancy one creates one account on one data center and the second account in another data center. If one could have VPNs accross accounts one could have the monitoring and DB connections go through the VPN instead of having to do SSL or some form of tunneling.. or implement one's own VPN.
-
JohnC
commented
Any luck on this? Be nice to have this soon....
-
FD Media
commented
Would be nice
-
Wordpad
commented
Our CIO turned down RackSpace for this sole reason. I was very dissapointed since I've heard great things of RackSpace. Hopefully some solution will be provided in the near future, since any of the "work-arounds" available now just don't cut it. Our servers have to be able to communicate with each-other on their own private LAN interfaces, no other RackSpace customers able to interfere or intercept with for example arp poisoning/what not. Individually setting up software-based firewalls just to get around this is definitely not good security practice. I will follow this suggestion and be crossing my fingers :)
-
Dan Prince
commented
We have developed an application (a Rails app) that provides an API on top of the Rackspace Cloud Servers v1.0 API to automatically configure secure OpenVPN server groups. The app is up on GitHub:
https://github.com/rackspace/cloud_servers_vpc
I would add that this is not a service run by Rackspace but it is something you can run yourself if you are interested in automating the creation of secure OpenVPN server groups. Several of the groups in Rackspace are making use of the tool for some of our development and testing efforts.
-
Mit Rowe
commented
we use a load-balanced redundant setup using the rackspace cloud, and would like to avoid having to jump through hoops to ensure that our user's personal information (and our intellectual property) trasmitted between the servers is secure. So, having a distinct, secure internal IP group that stil allows us to connect to the cloudfiles API on 'servicenet' would be very welcome.
-
Zanzamar
commented
This would be a nice bonus. Currently our Ubuntu boxes are all using OpenVPN back to a central database Instance... Would be nice not to have the overhead on the individual instances. Not that there is much overhead, but hey, every bit helps!
-
Adam
commented
This is great, our software is currently dependent on multi-cast.
-
acgann
commented
How would we firewall the private VLAN? Or would we even need to, because it sort of sounds like you are planning to give us an interface to help do that. We are in the process of setting up a baby VPS to use as a firewall machine (and there's a suggestion out there asking for a "firewall" flavor from Rackspace). We also kicked around the idea of using our Dedicated-side hardware firewall, but last I heard you guys were 6 months out on implementing that.
-
Jack Lindsay
commented
Excellent news, Chad. Looking forward to seeing that implemented.
-
Roberto Aguilar
commented
Chad, that's great to hear! Would the VLAN setup allow accessing other private servers I own through an OpenVPN gateway server?
-
Chad Keck
commented
Our end goal is to give each customer the ability to create Private VLANs between your Cloud Servers so you don't have to worry about having to create iptables rules or disabling the private interface on each server you provision. This will also allow other functions such as multi-cast which you cannot do today.
-
Daniel Huckstep
commented
My thinking when I submitted this:
I'd like to be able to treat my Rackspace servers as if they were in a datacenter I owned. I don't want to worry about the internal network, so I could crank up a Cassandra cluster (whose security model is sort of based on a 'secure' internal network) and not have to worry about locking stuff down.
I could accomplish the same thing with iptables (ubuntu's ufw would make it pretty easy), but then I'd have to ensure that each machine in the cluster gets updated with a new rule whenever a new machine comes online. Not the most difficult thing in the world, but it's one more thing to think about.
If my servers only had access to my other servers on the internal interface, this would solve the problem. The problem this creates is for a company like MongoHQ where they want you to connect on the internal network to keep speed high and bandwidth costs low. A VPN control panel/way to configure/allow other IPs to connect would solve the problem.
But really, the less I have to worry about internal network security the better.
-
Roberto Aguilar
commented
That makes sense. That could be done in many ways, the immediate ones that come to mind:
- turn off the private interface by default
- drop all incoming packets on the private interface by default.Both solutions are kind of sledge hammer, but usually the best security opens up holes as needed rather than starting with everything open.
-
acgann
commented
Sure you can lock it down with IPtables, but that means the minute you bring up a new machine, there's the capability for it to be hacked. It would make a lot more sense if the machines were locked down on the internal IPs by account by default.
