Scalable compute services.
Simple object storage.
Run managed Kubernetes clusters.
Tools & Integrations
Automate your infrastructure.
Deploy pre-built applications.
Connect, share and learn
DevOps and development guides
Questions & Answers
Development and systems Q&A
by Justin Ellingwood
Would be nice to have VLANs between instances
This is a deal breaker for me as well
They are gathering feedback and iirc the latest changes to their private address allocations lock them to your account. So you in essense get an account level vlan. Though they can enable access to private addresses between accounts.
How is this 2018 and this still hasn't been addressed? 5 years isn't enough to gather feedback?
PLZ PLZ add this feature, I had enough building SSH tunnels and worrying about security
Please add multi-dc vpn, paying double the amount on EC2 vs DO for this pleasure.
This to me, is the difference between whether DO is used by customers for single servers or for full application architectures. Obviously one of these is more valuable to you as a business
Private Networking + Cross Region Private Networking (as easy as in AWS - or even simpler if you will!)
We can't move to DO as long as there's no Private Networking (instead of Shared Private Networking) that can also operate cross region (so we can maintain High Availability). And although we can manually setup VPN and tweak the firewalls every time we add a machine, this is not the way to go as it increases the Points Of Failure exponentially.
+3 The lack of a truly private networking feature at DO is the ONLY THING preventing me from moving my operations (and those of other clients) from Rackspace (and others) to DO. It's just too time consuming to configure and maintain individual VM firewall configs to allow for restricted network traffic between machines.
This would mean I would use DO to link my app and db.
Openstack Networking or Amazon VPC style networking
just like Amazon Lightsail is copying DO,
DO should also have Virtual Networking to compete ;)
This would be a great addition to the DO services.
Please take our money and deliver us from openssl ! :)
Up :) I would love this feature
Are there any updates after December 2014? Is there any hope to see this within the next 6 months?
If you ever do a beta please send me an invite, thanks!
I'd also be happy to pay for this. The current "private network" is not private at all. From DO support:
> The main advantage of the private network is reduced latency rather than security. For all intents and purposes, it's best to treat as a public network.
This is a major issue with **Redis** for example, which is meant to run in a protected environment.
It would be enough to have a VPN or VLAN between all the user's droplets inside the same region.
Please add this feature, otherwise I'll have to move to a PaaS
I'd be happy to pay a few $ per month for this, especially if I could create multiple VLANs and assign droplets to them within my DO account.
@stretch sorry for the misunderstanding, that is still a disappointment.
> Okay, DO are clearly working on this judging by the activity on their GitHub.
Please note that our open source NetBox project is not in any way indicative of features or products that we're working on. It started as an internal tool and has been opened to the community as a general purpose IPAM/DCIM application.
Okay, DO are clearly working on this judging by the activity on their GitHub.
DO, along with the community, are working on a project called NetBox. This software is a tool for IP address management (IPAM) and data center infrastructure management (DCIM).
I am sure it would not take that much time to work this into the SDN and the API to be able to work virtual SDN based private (proper private) networking.
It would be a case of every user would need to be allocated a VLAN, which may not be plausible due to the large number of DO customers.
If their SDN is capable of five million VLANs, then each data centre should be fine.
Staging Droplets for large customers in specific racks might be a good solution, but have segregation in place for other users too.
Having a VPN/VPC like Amazon/Google has would be extremely cool. This VPN should span across regions. It would be no problem for me to count the traffic between regions against the droplets traffic limit or pay extra for it.
I have been an avid user and fond of Digital Ocean, but their so-called 'private networking' feature is not private among their clients. This is unacceptable and is a reason why Digital Ocean can not compete with the big boys yet. In addition, there support seem to think it's all trivial and just do some firewalling. Yet, in their documentation, they warn everyone in their network can see my traffic and communication between nodes.
Get It Done
Unfortunately, I now might have to switch to AWS according to my team members. I'm researching IPSec, etc and other security protocols, but even if they work, I will need to sacrifice performance to protect from Digital Ocean's clients.
++ on this one. We want to host machines for several customers, but if their private network is the same they'll see each others and that's a showstopper. Or we'll make 10's of separate accounts maybe...
Basically I see 2 options:
- Allow to create several private networks in the console and let us select which one a droplet belongs to,
- Make a private network that supports VLAN 802.1q and let your customer create as many VLANs as they want and make the addressing.
In fact solution 1 can rely on solution 2 but will be easier to figure with less technical crowd.
Hi DO, we need two internal networks: IPv4 with VLANs and IPv6 with VLANs.
Please bring these features to London first! I would love to use it there first.
Without this I think I might have to move most of my applications to AWS. :(
This is essential. This determines whether or not we will use DO
I would like to know whether a proposal has been made for User Specific Private Network provisioning in all of the DigitalOcean data centres.
Any updates on when and if this feature would be available?
I'm looking for this feature. Scale app become hell when setting firewall for each droplet :(
if you offer the opportunity to connect two vps in different data centers through a LAN ( VLAN ) without counting the traffic would be a cool service
More and more services are offering true private networking, I would love to see it at DO. Even Go Daddy offers it now (https://www.godaddy.com/pro/cloud-servers), a side from AWS, etc.
Well good bye digitalicean.... you have ignored us for 2 years, unfortunately for you, your competition listened Vultr included this and custom ISO installations https://www.vultr.com/features/
This would make scaling out so much easier and make DO much more attractive to enterprise users. Please Add!!!!!
The single most differentiator all the more established cloud providers and DigitalOcean is their capability of private VLANs.
This feature very importance with a lot of system architecture, voted !
For security reasons it is necessary, even it is a must feature.
I'd certainly be willing to pay more for a VPC like EC2 offers. The last admin comment here was more than 2 years ago so I suspect this just isn't going to be fixed. I don't know how any customer could possibly trust their servers in an environment where other customers have network access to their servers.
Any update on that ? It's been more than 2 years and there's still no easy way for DMZ and secure communication between nodes.
This is the only missing feature preventing me, the company I work for as my $dayjob, and every single freelance client I do work for from using DigitalOcean in production for anything more than a single server deployment. Dedicated *Private* VLAN only accessible by my/our account is crucial to a secure environment. Managing UFW/IPTABLES on a per-node basis is just not a good solution.
This is something that AWS has working extremely well. Having a VPC of sorts or VLANs would be a massive step forward. These virtual networks should also support cross data centers. In addition to this, having security rules for blocking at a firewall level.
+1 DO is the home of all my personal stuff (because it's simply the best), but vlans is a big consideration for me when choosing a host for very large projects and projects I expect to grow very large. In fact, I think this is the last remaining feature that would keep me from using DO for any new big projects. So +10 actually :)
How was softlayer able to accomplish this without issue?
Firewalls are just not adequate and can become a nightmare to manage for say a very large Openshift Origin v3 docker deployment. VLANS and private network only droplets are a must to protect proprietary data from both external and internal threats when dealing with an auto scaling/ auto healing infrastructure built on digital ocean.
Definitely a must have! OpenStack achieves this through using openvswitch and GRE/VXLAN tunnels (they're built into the linux kernel too), so it could potentially just sit on top of the private network?
Private network for one account - very important thing!
+1 I fully agree with this, it also needs to have a VPN access point that we can connect into the private network and only access our VLAN like the softlayer.com management layer.
Here is what I wrote in the questions and answers section but was told to post here on uservoice:
1) Does this mean that our VPS are not on their own VLAN? seems like a major security flaw to me even with IP tables this creates a risk which would not exist if vlans were used... IP tables would also be hard to manage with large deployments, even with tools like ansible the orchestration required to make sure only your VPS could talk to eachother would be a nightmare and cause a lot of uneeded troubleshooting when stuff did not work as expected
2) I have scripted ansible to disable to public network interface on the droplets when they get created but there is a rather large window of opportunity for attack when deploying large clusters of droplets. First the droplets all get spun up which is a very time consuming process when created 20 - 100 droplets at once, then the ansible playbook connects to all those droplets and disables the public interface. During this window automated scanners could already do their damage with 0 day exploits.
We would like the ability in the API to private_networking=yes public_networking=no this will make it easy to keep backend services secure that do not have a need to be accessed directly from the internet.
3) Private network access - this one is not a huge deal because we can setup a vpn on a public droplet but it would be nice to see digitalocean out of the box supporting large application deployments with backend services that do not require public access. to make it easy to manage and access these backend service droplets you could deploy a private network vpn access solution that when a customer logs in, it will only give them access to their vlan. This is what softlayer.com has done, they call it the "management layer"
It would be even better if we could have multiple ones - that way we can completely separate production/dev networks.
Better security even within the organization.
Please. This is the next big step, which will truly open up endless possibilities with DigitalOcean's service!
Out of votes, but excellent suggestion. Private network between droplets would be very welcome, especially as described between database and web servers.
i know i would pay extra to have local access between vm's. i want to have a separate mail, mysql, and apache server with out the lag and extra (billed) bandwidth between them, despite being in the same datacenter (or possibly same physical host)
I agree with what some other commenters have said: IMHO, the best option would be
1. An internal network for DO that doesn't actually section off groups of droplets. It's just an easy way of easily keeping stuff off the internet as a whole.
2. Let us pay for a private VPN if we want to. I know I would be happy to shell out the cash to have all my VPN's talking over a network that I can be semi-sure other people aren't on.
I would very much like to see private subnets available. fully private vlan would be nice, but a subnet that didn't count towards your bandwidth limit would be very nice. I wouldn't mind paying a bit extra, like a flat fee (per month?) for each private subnet or vlan.
As a comparison, AWS has this feature.
What's with OpenVPN (combined with free traffic inside the same DC)? That's how I handle it with my OVH server.
I would pay more for private vlans.
VXLAN is designed to solve the networking challenges, but it's still fairly new.
Making internal traffic in the same datacenter free of charge would be enough for me.
Would like this, would be even more perfect for loadbalancers
Linode shows 4 items in their bandwidth usage graph - outgoing public, incoming public, outgoing private and incoming private.
A typical database server would look like this:
Bunch of private IP traffic, zero public transportation.
Here's my idea:
- Since VLAN needs some resource in your backplane, you can charge for it - we certainly pay extra $$ for such flexible networking features.
- But also consider offering single private IP space for free, for those who don't need to assemble hundreds of servers. They just need unmetered traffic between their own servers, and use ufw / iptables or whatever to secure them. Start with this dead simple feature as not having it would be no go for quite a few customers. The Lean Startup Way. :)
Bandwidth will be pooled account wide for your virtual servers so you don't have to worry about sizing.
I'm aware there isn't a limit, just an additional charge if I go over. That is why I wonder are you going to pool my transfer quote from all my droplets or are they separate? This can become problematic I'd I setup a load balancer infront of my servers because I would like to use a $5 server but it has the smallest quota. I would have other servers with allocated bandwidth that aren't being used yet I would still get charged if it isn't pooled.
You dont have a limit to 1TB, is this unclear in the language, perhaps we can improve it some how to make it clearer? This is just the amount of bandwidth that is included and whatever is over that you will be charged at $0.02 cents.
There would be no charge for internal traffic which is part of the reason customers request it.
As for a vlan charge its just because of networking costs involved and limitations there.
I would be open to it, but please think about how you are charging for bandwidth. Does this internal traffic count too? if so, then please don't double charge me.
Also, if I want to setup some load balancing myself and put some light weight $5 servers in front, I would I be charge for any extra bandwidth usage from the sum of all my servers, or from just the public facing servers. In other words, I don't want to be limited to 1TB transfer because I have a light weight server in front of my site.
You are right about the vlan limitations so we're still debating which direction to head with that.
Given vlan limitations if we implement it there may be a small monthly charge for that, would people be open to that?
If the number of available VLANs is going to be problematic, how about just offering single private IP space? In other words, VMs are given 2 addresses (public IP and private IP) and all private IPs are accessible within the same datacenter - for instance, User A's 192.168.1.1 can talk to User B's 192.168.1.2. Less than ideal but that's what Linode does. Food for thought.
Is there any suggestions on what users can do if we have multiple machines?
I plan on running multiple instances over time. I have three types of images: Web services, a DB, and a worker. How would you suggest we set something like that up right now if we have machines that talk to each other a lot?
We are investigating offering customers private vlans for private networking but there are switching limitations on the number of available vlans which may cause an issue down the road.
This is absolutely huge
+1 for bridged VLANs between regions too.
@Moisey Uretsky I think pay-for-VLAN is fair, but to my previous comment, built-in spanning between DC/Regions. Add a simple VPN (say, openvpn) to the private network and you have a winner
Don't forget cross datacenter private networks! https://ideas.digitalocean.com/ideas/DO-I-1620
This feature was shipped back in 2013 https://blog.digitalocean.com/introducing-private-networking/
Unfortunately during the migration of the idea website these comments lost their original timestamps. For more information about Private Networking, see https://blog.digitalocean.com/introducing-private-networking/
This idea did not ship in 2013. A flat internal Network shipped in 2013.
This is private networks between droplets managed by individual customers. If you are claiming victory over your old product then you should not be an admin here. These features are not the same. Re open this or delete it but don't waste out time lying.
Private networks do behave as L2 networks between Droplets, which was the original request. We are constantly working on improving them, like the update we did last year to fully isolate customers and we are still working on more improvements, but the request was delivered.
Besides that, we do appreciate some civility on the comments.
This has been a thorn in my side as well; DigitalOcean really needs to improve their private networking options! Please :)
For everyone who commented on this issue and feels like it was not resolved with what DO "shipped", I have created a new idea on this topic with clearer definition of an acceptable solution: https://ideas.digitalocean.com/ideas/DO-I-2662
The "followup-idea", what Michael Wangerin mentioned is here:https://ideas.digitalocean.com/ideas/NETSECX-I-5
You won't be notified about changes to this idea.