Hello and welcome. This is the VCD Roundtable, episode number 54. And the topic of the day is the vDefend Firewall, IDS / IPS, and Advanced Threat Protection.
And let me quickly cover why we thought this topic should be at the top of the agenda again, not only because this is quite an interesting additional service, which can be offered by service providers, but also due to the latest changes in the licensing scenarios with Usage Meter 9 and changes in the license guide, it's now finally possible that we can actually license the firewall features on an overage scenario as well.
So you are no longer bound to actually make a three-year commit if you want to use the firewall features potentially to test it out with a customer or something else. But Sascha is going to cover that for a bit and Matthias is going to tell us a bit more about use cases and everything else for the vDefend Firewall, distributed firewalls, gateways, and whatever else. So let me throw the ball over to Matthias first, who can then throw it to Sascha for the licensing piece.
And then Matthias can give us the tech dive. Yeah, as always, I just try to take a sip, and then I have to talk. It's always a same. Hello. Welcome from my side. Now I'm looking forward to this more technical session again. Sascha, what are you going to offer us? What do you have to offer us today? Yes. Nice to meet you here. I think it's important that we talk a bit about all of that stuff from a license perspective. What does it mean?
What options we now have also with the changes, how we can license vDefend. So yeah, happy to share this information with you. Then why don't we start with the licensing part before we get into the tech part? Yeah, let's do it. So, Yves told us that there were changes, and now we can license - as a service provider - vDefend as an overage. So that's very important for us.
So that means with changes, Usage Meter 9... two weeks ago, there came the announcement that on demand is now available for all vDefend products. And what does it mean for us? So there are still some open questions to be fair. So we got this information that only 200% of license keys can be generated. So does that also mean that the service providers that don't use vDefendcan use vDefend on demand? Currently, nobody knows, but let's see.
But you are also able to say, "hey, I want to activate or license vDefend on the host space." That helps us a lot now, because service providers don't need to start to say, "hey, I need to license my complete cluster or create a dedicated cluster for vDefend with Advanced Threat Protection or whatever." And that is very beneficial for you, because you can now say, "hey, create a rule that vDefend only -- or a vDefend feature -- runs only on virtual machines on host one, two, three."
And the other hosts don't need to be licensed for vDefend. So that will help us a lot. And then, additional to that, that makes sense. We can go with the commit for three hosts and can say, "hey, if you need a fourth one, we can go as an overage." So that's beneficial. That makes absolutely sense with this 200%. So that will helps us a lot. Other question?
What license-- But Sasha, let's stick on this one a little bit, because... let's start with a short discussion here, because I totally understand what you're talking about. That introduces a ton of administrative overhead. So it is a solution just to license only a few hosts of a cluster. But it's always a trade-off because, on the other hand, you have the administrative overhead to create the RTS groups, to stick virtual machines or to glue virtual machines to certain hosts.
What if one host of that group fails, hardware error, whatever? You need to add another host to the group. That load gets redistributed and so on and so forth. So because we're blunt on all this stuff, so we need to say, "guys, be careful if or if you go down that route, you have administrative overhead. Firstly, and secondly, if you fat-finger something, it has a high price tag associated, because if you accidentally add a host to that group, thank you. You pay overage."
So I think we should be very honest on that part. Absolutely. But compared to that, the other way is to create a dedicated cluster for VCF, if I want to start with VCF. And then I use the complete flexibility to say, "hey, one customer wants to test VCF Advanced Threat Protection." And I think that becomes more and more interesting from a security perspective to run Advanced Threat Protection on microsegmentation, for example.
Let's face it. Advanced Threat Protection requires you to actually install the Kubernetes pieces and stuff like that for that special features in any way. If you just want to have the baseline features, it's not that bad. But also, I mean, the cost is $100 per year per core for vDefend basic. So for the... I think it's $120. 120, yeah. So we are talking about $10 per core. So even if by mistake, you put in a host and you would not actually put that in by 120 divided by 12 is 10. That's easy.
Why 12? But let's not start math here. Why 12? Because 12 months is in a year. Oh, Okey-dokey. I was thinking about cores. How 12, right? No, because-- You always talk 16. So it would be per core a total cost of $10 per month. And typically, you don't turn on the host at the first of the month at zero or at 001 or something like that. I think the overall, yes, if you make the mistake, it's not going to be that bad. Because it's not like you turn on a feature like by mistake in Avi Load Balancer.
So that's a totally different piece. Absolutely... but it's not $10 a month, Yves. It's $10 times at least 16. Yeah, that's $160. It's not us. Yeah, but to be fair, so we have all the operation stuff now included. And it's an easy one for a service provider to create an alert if I'm using more licenses than expected. For me, it's an open discussion, because honestly, I don't get, why should I not license vDefend? Because I still consider vDefend being a base feature.
And as Yves mentioned, we're not talking a big amount of money here. So as a CSP, I should at least license one cluster with vDefend. And if I have only a single cluster, I'm not that large anyway. So we're not talking that big of an additional cost. So that's honestly speaking. It's easier to sell and it's higher flexibility. And I need to compare the cost of the licenses with the administrative overhead I have on the other hand.
Yeah, the challenge is, I think-- and that's what we got out of the meetings with most of the service providers is that they say,"hey, I want to start with vDefend, but I can only start with one to three customers and then migrate more and more customers to vDefend." That doesn't start with day one. And that's a challenge for service providers currently to say, "hey, I need to license my complete cluster on day one. And now I need at least one or two years until every customer is using it."
So this is an option to license only dedicated hosts. And everyone needs to decide for themselves. If they want to take the time to do all the configurations and save some money, especially at the beginning, or make the decision to go with the dedicated cluster, or make the decision to license a complete cluster from day zero. But yes, maybe you can tell us a bit more about the features and what we can do with that protection, with microsegmentation, and why this is important. Why ATP?
Let's start basic with microsegmentation. There is not always the need to have ATP on top. So with microsegmentation, you enable a more secure infrastructure also to protect workloads from each other within a single tenant. I think that's the most overseen feature of what microsegmentation introduces to your infrastructure. Most people think like, "oh, I have to protect my environment against threats from the internet or from the bad guys sitting somewhere."
But honestly, most of the attacks are from inside, so internally, because someone clicks a link in an email or whatever. And then the big question is, how fast is a threat able to spread itself within the infrastructure? And that's where the whole microsegmentation kicks in. Because if you protect workloads even within a single layer 2 subnet, the spread rate is a lot slower compared to no protection within the whole environment.
I think that's one of the most important features that the whole vDefend (DFW) brings to the table. The vDefend, of course, the other part is the gateway firewall. But I consider this one being like a perimeter, as we have always treated a firewall sitting at the border of our environment. It's an additional firewall sitting behind a physical firewalling device, because I still have my opinion. I'm not moving a micrometer off.
There is always a physical firewalling device in front of the environment. So vDefend is always an additional solution, not an in-stead of solution. So that's the whole vDefend Firewall part. And I think it's also important that everyone is aware that if I have two networks, two routed networks in Cloud Director on one edge gateway, I have the default one distributed routing enabled that there is no firewall rule. I can create this firewall rule on the edge gateway, but it doesn't match.
Exactly, Sascha. So that's a very valid point you have taken. If a tenant creates, as you said, two router or multiple router networks within a single tenant, they assume the gateway protects those networks from each other, but it doesn't. For that specific behavior, I think we typically recommend having the CSP or instructor CSPs have a document ready to provide guidance for their tenants how to use those two firewalls together, because it's not using either the gateway or the DFW.
How can I combine those two firewalls to achieve the best solution for me as a tenant. Absolutely. Because, yes, you can create this firewall rules, but they don't match. And that's the interesting part of it. And a lot of times, really funny, if you are doing-- And you spend hours and hours and hours of troubleshooting. Why is the traffic still flowing? Or they only test what's possible or what's allowed and never test what's not possible.
Yeah. So especially with Cloud Director, because if we talk about a CSP environment, it's even easier, because Cloud Director adds some very nice gimmicks or actually some configurations to the DFW by default, which is not part of the base NSX configuration. So with Cloud Director, Cloud Director automatically configures the DFW to create an internally any-any-any drop-wall instead of an any-any-any block globally. So that's a pretty cool feature.
So it protects only tenant local flows instead of protecting flows from or to the tenant. So that's the big difference if you compare the Cloud Director environment with a base or plain NSX environment. That's pretty cool. And that, at least from my perspective, makes the combination of the two firewalls, gateway and DFW, a lot easier, because on the DFW, you focus on internal flows only. And on the gateway, you focus on flows from and to your tenant. So that's pretty cool.
Yeah. And let me add one part. So please be aware, when you enable distributed firewall in your tenant that you don't start in a brownfield environment with the any-any deny rule or any-any reject rule retract rule; that will not work. Oh, it will work. It will work. It works as designed. That's right. And to dramatically reduce unwanted traffic. But also wanted traffic. But I think from a business perspective of the customers, it will not work. So yeah. But you know what I mean.
And I think we need to mention it. So what you forgot to mention, that's another unbelievable feature we have with VCF. Because VCF contains the whole Aria Suite, which implies we have Aria Operations for Log. And if you configure Aria Operations for Log being the syslog receiver for the vSphere part of VCF and the NSX part of VCF and all the gateways, you have the ability to feed back the tenant-specific firewall logs into the Cloud Director UI.
So that enables a tenant to troubleshoot their own firewall rule set. That's amazing. But there was one point, or there is one point, with the IP addresses. If you have overlapping IP ranges, is this fixed? As far as I know, it should be fixed. Okay. I don't know. We need to look it up. Yeah, maybe we should do it. Because I heard it again from one service provider that it is not fixed. But I never tested it myself. Let's move forward to IDS/IPS. I was just about to say.
So now there are some prerequisites you need to fulfill for IDS/IPS. It's not just a turn-on feature. Isn't it? Yeah, you need this crazy Kubernetes cluster. But it should be no longer. Not for basic IDS/IPS. You need the Kubernetes for all the other ATP features. Yeah, you're right. So IDS/IPS... so ATP contains four features, as far as I have, out of my head. One is IDS/IPS. There is the mobile protection. The-- help me out. It's mobile protection, mobile prevention.
It's the whole visualization thingy, the flow visualization, and that part. And there is a fourth feature. IDS/IPS is the only feature of ATP, which is not dependent on the Kubernetes. Yeah, that part. But, Yves is right somehow, because the big thing with IDS/IPS from a CSP standpoint of view is it's not a self-service feature. It still is not. It can only be consumed as a managed service. But the amazing thing is if you think about Gateway IDS/IPS, it can be enabled on a per T1 base.
So I can enable it only for a single tenant. But a T1 runs on an Edge Gateway, and the Edge Gateway needs to be licensed for IDS/IPS. That's the ATP license. Or if you're aiming for the Distributed IDS/IPS implementation, you need to license all the hosts with ATP. But Sascha, can you license ATP also, as you have mentioned, for the vDefend Firewall on a dedicated host perspective in a single cluster? Or do you need to license the whole cluster with ATP? No, that's the same rule like vDefend.
OK, cool. That's important to know. Because for IDS/IPS-- Sorry? If I run it on a gateway, I can also run the vDefend Advanced Threat Protection licenses on the same regulations like we have it for normal gateway firewalls. Yeah, cool. So the only thing what we need to be aware of is with IDS/IPS, deploy at least extra large Edge transport nodes. Otherwise, you might have issues with the throughput.
Yes. Speaking of IDS/IPS, there is another very important prerequisite, and this is internet connection of the NSX managers. Because they need to download all the patterns and those are downloaded from a cloud service. So the NSX manager needs to have internet access. A proxy can be configured, and Broadcom provides a proper documentation which of URLs need to be allowed to access. If you're not able to provide an internet connectivity, I think you can do an air gap installation as well.
But then you need to ship all the patterns and all the stuff you need manually via USB stick or whatever. And I think with IDS/IPS, it's an amazing feature, especially the distributed implementation. Because you can, again, filter the traffic internally so that the different flows you have between the stages of an application or the layers of an application. But always keep in mind, do not try to filter every traffic you find in your infrastructure with IDS/IPS.
That's just consuming so many CPU cycles, so you will barely run any workloads anymore, because of just traffic filtering. So before doing IDS/IPS, build a proper design, think about which traffic flows to analyze, and configure the redirect rules accordingly. Yes, redirect rules. So you redirect certain traffic flows to the IDS/IPS analysis. But that's the same on the physical firewalls. So you're not able to run every traffic through the IDS/IPS filters.
Well, you can, but throughput will suffer. Yeah, and the memory and CPU will also go higher and higher. And then there will be a stop. Yeah, but that's, again, a very important thing. And that's also good that IDS/IPS can only be consumed as a managed service because the CSP has a perfect overview how much CPU is left, how much throughput is an Edge transport node still able to handle if we talk about gateway IDS. Especially in shared environments.
So there is a lot of stuff to consider, not only licensing also, infrastructure. Yeah, but that's like with every other product. So you need to have a proper design before you start with the implementation. So you have the right size of Edge nodes rolled out, decide which firewall rules make sense to be routed over IDS/IPS.
Yeah. Good. So I think when we sum it all up, so on one end, we have the licensing changes which make it easier to play around with it or try it out or deploy it at the customer or for individual customers. We have the uncertainty that it's unclear how to deal with customers where we have-- or for service providers who don't have any customer commit for NSX so far or for vDefend so far because NSX is always included. So that's the vDefend part that you need to license specifically.
So that is still outstanding. Maybe we get some answers on that in the upcoming weeks. But I think there is a huge opportunity not only from additional features which we have in the system, but also how to actually charge customers for that. And as we discussed last week at the Service Provider Summit as well, it's like the importance for service providers to provide additional services you can charge for.
So not only technology services, but also manual consulting, architecture, et cetera, services you can charge for is becoming more and more important because the other thing which happened due to the Broadcom change is that everybody has now the same license package more or less except for the add-ons is that the space for VCSPs or for VMware Cloud Service Providers to take it the long road has become more competitive, because it's much easier to compare.
Previously, customers were like, "oh, I have a future ABC included with this provider. I don't have it with that one." That is actually far more leveled. So that is going to be quite interesting. So I think overall, it's definitely something service providers should look into. It's definitely something which can open the market for additional features. And potentially from a lot of the other add-ons, it's the one which is the easiest for service providers to monetize.
So that being-- To be fair... Go on. Yeah, so what I want to mention additionally to that is, with the end of life of Cloud Director and all of this information, so we will not expect that we will get new features out of Cloud Director in the next one, two, three years, until the end of life. But your customers will expect that you have new features in your products or in your offerings as a service provider.
And I think now we need to take a look what products are included now, what can we use, and then offer these products to your customers to show your customers, hey, we are still working. We have still more products available for you. I think that's an important part. Nice closing word, I would say. Matthias, anything to add? Yeah, come up with proper product and packaging. Sell it. It's easy to sell, easy to use, easy to consume.
Good. So I would say thank you all for listening in today's episode of our VCD Roundtable number 54. 55 is going to come out in approximately two weeks. That is going to be from Palo Alto, I think, Sascha? Yes. As far as my head actually is correct. So maybe you have some fantastic news from the VMware mothership and can share them with you. Hopefully we get something. And yeah, that being said, thank you all for watching live today.
As always, if you watch us live, which is typically recorded every other Thursday, you can always throw in some questions. Otherwise, thank you for listening to us on all the usual podcast platforms and hope to see you, hear you again soon. Good day. Perfect. Bye. Bye.