Service insertion is a great way to insert a firewall into our traffic path in an SD-WAN environment.
But we can also take SD-WAN, our infrastructure, and sort of turn it into a firewall.
We can make sure that we're blocking traffic from going from certain hosts to other hosts.
And the way we can do that is by leveraging the feature known as the Application Aware Firewall.
The Application Aware Firewall is going to be a zone-based set of policies that's going to allow us to again control traffic.
And furthermore, not just performing things like access control.
Sure, we can do access control, but we can also do stateful inspection of traffic.
Meaning that we can allow return traffic, for example, to come back through even if it's not explicitly allowed on the other interface.
So what do we mean by zone-based? And what exactly is this whole concept meant to be?
When we look at a traditional zone-based firewall, the idea of a zone-based firewall was to make it so we didn't have to have interface-to-interface policies.
For example, I might have a single interface here that connects to my internal network.
Well, that makes it look like it's the internet. I'll call this the local area network, so it's our internal interface.
We can have an external interface. This does go to the internet.
And then we can also have maybe a DMZ that comes down here and has another network.
So this is great. In a traditional environment, I could define policies for what traffic looks like when it goes from one of these interface types to another type.
I would need three policies.
Well, here's the problem with a traditional firewall mechanism.
What if I have another interface that connects into the LAN, maybe for redundancy from a Layer 3 perspective?
In fact, I could technically add this from a redundancy perspective into all of these.
Well, if I'm doing interface-based, now all of a sudden I need all kinds of more policies.
I don't just have three anymore. I've got to have one from this interface on the LAN to this DMZ interface, and also another one to this DMZ interface.
But then I need to do that from the internal here to the internal here.
And so we start creating this full mesh of connectivity, or at least of policies, that we'd have to define.
So what a zone-based firewall does is it says, hey, we're going to, instead of doing all of our policies between interfaces, we're going to define zones that include interfaces, and then we run zone-to-zone policies.
So the policy goes here, what traffic's allowed and what traffic isn't allowed.
So now I can put both of these interfaces into a zone.
So this could be my internal zone.
And then these two interfaces can be my external zone.
And then down here, these can be my DMZ zone.
So when we have three zones, we still have just the three policies.
It keeps it a whole lot simpler than trying to define the same policy across many different sets of interfaces.
So this is exactly what we can do, except now we can sort of replace this firewall concept with our SD-WAN environment.
And then furthermore, I can replace the zone concept with VPNs.
So now I could say I've got VPN10 here and VPN20 here and VPN30 here.
And now I can define policy among specific VPNs without having to worry about where in the network things are.
But then I have another set of traffic that's going from edge 13 to edge 20, and then also edge 13 to edge 21, which is also in VPN20.
Well, we can imagine if we had to define all of those interface-level policies, it would start to get very cumbersome.
But because we have effectively zone-based between the VPNs, it doesn't matter what our configuration is.
We don't have to worry about it for a particular traffic flow, which ingress edge it's coming in on and the egress edge it's targeting.
It doesn't matter. All of the policy is enforced from VPN to VPN.
So some nice things about our application-aware firewall.
And by the way, we want to key in on this concept of application-aware.
So first of all, it, as we mentioned, is stateful.
That's a very big benefit.
It does allow for us to take a look at IP addresses and ports and protocol numbers, and the statefulness allows us to track specific sessions.
So we can look at TCP sessions when they open up and allow return traffic back.
We can do UDP, which doesn't allow for that, but we can still track UDP and ICMP traffic and all kinds of things.
So this is very, very useful to us as far as the feature set is concerned.
Furthermore, we are actually application-aware.
So as with some other aspects of SD-WAN that we've talked about, it's really nice when an edge can just look at a packet and know what the application is.
So we can identify the application that's inside of the packet.
And then that allows us to perform our matches that we need to do.
This is going to use Cisco's NBAR2 technology, Network-Based Application Recognition 2, NBAR2.
It can recognize up to 1,400 or more applications.
And we can, importantly, we can also select allowed and blocking policies based on categories.
So that's kind of interesting, too.
So I could block certain categories of applications from speaking to other categories of applications or certain hosts or whatever the situation is.
Now, one thing to be aware of in all of this is that this sounded great for the moment.
You might have a couple questions about this, as I certainly did the first time I learned about it.
Specifically, when do we ever really have VPN to VPN traffic?
For the most part, our VPNs are meant to stay isolated because usually a VPN is akin to either a customer, if we're a service provider, or possibly maybe some kind of department that requires isolation.
So when are we communicating between VPNs?
So, yes, this Application-Aware Firewall is focused on these more complex situations where we have VPNs communicating to other VPNs.
But what this allows for us to do is make it so that if we did need certain VPNs to communicate to one another, chances are they're in different VPNs because they require isolation.
So if we're going to allow, for example, VPN 10 and VPN 20 to communicate, it's probably for a very specific purpose, and we don't want to open up a whole bunch of other communications capabilities between those VPNs in the process.
Now, with that said, here's the good news.
We can do – well, here, we'll draw a dividing line here.
We can do inter-VPN policies, inter meaning between different VPNs, so that would be exactly what we just talked about.
That's inter-VPN.
But we can also do intra-VPN policies, and this maybe is going to apply in certain other situations.
And so intra-VPN means that it's within the same VPN.
So if I'm sending from one VPN but to a host in the same VPN, then I can start to inspect that traffic and maybe enforce some policy against it.
But I do want to comment on that real quick.
So if we're going to talk about intra-VPN, we might say, okay, well, that's great.
Why did we even worry about having this conversation down here?
Because I can still deploy firewall policies within a VPN.
Eh, kind of.
Because we have to think about what exactly we're talking about here.
If I have an edge with a tunnel to another edge, maybe a tunnel to an edge up here, and I have some hosts.
So if I'm host A and I want to send to one of these other hosts, the good news is no matter what, I have to go through the edge, which means that my intra-VPN policy can hold firm.
It can actually enforce maybe I'm not allowed to go to host B, even though it's on the same edge, but it's in a different layer three segment.
I have to get routed by the edge, and the edge recognizes I'm not allowed to communicate there.
Likewise, I'm not allowed to send out to host C or host D, and that's all great.
But what if this looked a little different?
What if instead of a direct connection, I go through a layer three switch, and I've got a segment here and a segment here, and host A and B are down here?
Well, at this point, host A and B can communicate, unlike me.
They can communicate all day long because I send my packet to the layer three switch, and it sends it down to host B and vice versa.
So I can try to block that traffic, but that traffic is being enforced by the edge.
So if the edge never sees it, then it's not going to be able to enforce it.
So that is the problem with relying on this concept for intra-VPN firewalling.
So just be aware of that.
I think it's important for us to understand where this is intended to play.
First and foremost, it's intended to play here, VPN to VPN traffic, because then you have to go through an edge.
We just have to recognize that there are going to be some instances where traffic is not enforced.
So as long as it makes sense to do it that way, then we should be able to still get value out of the application-aware firewall.
All right, let's wrap this up.
So when we're going to do our configuration, and by the way, configuration of most of our security services is outside of the scope of the exam,
And as a result, we'll just talk a little bit briefly about configuration without actually going and doing it.
So in order to perform configuration, we're going to have to configure a firewall policy, and that will be part of our global security policy.
So I configure the firewall policy.
It's going to be similar to an access control list in that I'm going to add some things like allowed traffic and drop traffic.
I'm also going to have a deny all sort of at the end of the policy that blocks everything that's not explicitly allowed.
But then I'm going to have to define my zones.
So my policy is going to be between a source zone and a destination zone like this.
Now remember, zones are VPNs.
So I might say my source zone is VPN 10 and my destination is VPN 20, but I could also say 10 to 10.
So if it's 10 to 20, then it would be an inter-VPN policy.
If it's 10 to 10, then it's an intra-VPN policy.
That's how we decide which one is simply by defining the zones here in the policy.
We can also use the self zone.
This is important.
A self zone is equivalent to the edge itself.
So if traffic is targeting the edge, this would be a way that we can perform some control plane protection by allowing or disallowing traffic to the edge itself.
So I might say that I don't want users on VPN 10 to be able to manage this device.
There's never a reason for them to be able to do that.
And so I can use the self zone, which is traffic targeting the edge itself.
We then, in this policy, add the rules, and the rules are going to be what we just talked about with allowing and disallowing traffic.
Importantly, we actually end up having three different policies or three different results of our policy that we can configure.
So we can configure is to pass, and we can configure traffic to be inspected, and we can allow traffic to be dropped.
So those are our three options.
So what's the difference between inspect and pass?
Well, inspect is this stateful concept all the way up here.
If we want to allow return traffic, we would say that we're going to inspect traffic.
If we don't want to do it statefully, then we can just select pass.
And if we want the traffic to be dropped, then naturally we'd choose drop as the result of the rules that we're creating for our traffic inspection.