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.