When configuring things from a centralized perspective via manager,
it's going to look a little bit different,
but the end result and the end goal is the same.
What we want to do is we want to use a two-step process.
We're going to start with a feature template,
which is going to push the NAT configuration down to our devices.
And then we're going to use a policy,
which gets pushed to the SD-WAN controller or vSmart.
And we're going to use that policy in order to match the traffic
and set an action of using NAT.
So it's that match action concept that we have anytime we're using a policy.
So we also need to recall that when we're configuring a centralized data policy
that yes, we're configuring it on manager.
And yes, it's going to get pushed to the controller,
but it's being enforced on the edge itself.
And so there's no real end difference between performing it centrally versus
performing that static configuration we just did.
Other than this scales a whole lot better because I can push the configuration
out to all of my WAN edges at once or whatever subset of WAN edges that I
desire.
Now we're going to use SD-WAN manager and we know that we're managing sites 11
and 12 with SD-WAN manager. So we're going to do the configuration there.
So let's go ahead and flip over to the Ubuntu host at site 11.
And so what we have here from a topology perspective is really the same
situation. We've got a edge 11 here.
We have an Ubuntu host behind it and it is connecting to the internet.
And so again, what we need to do is from a controller perspective,
we need to see the SD-WAN controller push our NAT configuration down as well as
a policy that's going to tell it which traffic to match to the NAT.
So let's go ahead and just make sure that this host,
host 10-11 see if it can ping the internet.
We're not expecting that it can and indeed it is unreachable.
All right.
So the goal should be to come back here and see that it is now reachable at site
11. So let's flip back to our SD-WAN manager.
So let's go ahead and go to configuration and we'll go down to policies here and
we're going to go up to custom options and we want to start by creating a
traffic policy. So again, when we look at custom options,
the traffic policy is the data side of centralized policies.
All of these other things are usually used more for centralized control
policies, especially like topology here.
But traffic policy is our centralized data option. So when we look here,
we see application aware routing,
which is going to be a centralized data policy as well.
And then we can click over to traffic data and now I can create a policy here.
And so let's go ahead and give our policy a name.
We'll call it DIA policy with a description of DIA policy.
From here I'm going to add a sequence type of custom.
This is what we'll use for DIA and then add a sequence rule. Now again,
we're doing match and action.
The match is matching on specific host traffic or possibly subnets or maybe
even just matching everything. So on the match side,
I'm going to choose source data prefix and I have a prefix list here for host
11. We can either create one here if we need to,
or we could just add the prefix or really the IP address of the host right into
this field down here if we so desire. Now the action is defaulting to drop.
So let's go ahead and take a look at that. We're going to flip over to action,
change it to accept.
And now what we want to do is we want to look here in the list until we see NAT
VPN. This means that we're going to NAT the traffic.
Anything we match over here, we will NAT.
We don't need to change any of these settings.
I'm just going to say save match and actions. Now we do have to be careful here.
Remember,
we're applying this policy to a set of edges and it's going to impact traffic
that we're matching. Well, if we're going to apply this as a data policy,
we need to make sure we're, yeah, setting host 11 to use NAT,
but we also need to make sure that we're not denying every other packet from
traversing the router.
So we need to go over here to default action right here and we need to make
sure that this is not set to drop.
So I'm going to change it over to accept and we'll save that as the default
action. So from here, I'm just going to save the policy.
And now we need to actually create the centralized policy.
So I can scroll up a little bit and click centralized policy here.
Add a centralized policy. We'll skip through a few of these things.
A topology and VPN membership. These would be for control policies. Next,
application aware routing. We're not doing, but traffic data.
That is what we just created was a policy for that.
So I'm going to import my DIA policy
and then click next. Now from here, I'm naming the centralized policy.
So we'll say DIA sent policy,
DIA centralized policy for the description.
Now we're not quite done because I need to click on traffic data here and
provide what information I'm matching against. So I can say, for example,
I can click this button and I can select a site list to say,
I'm going to want to impact site 11 here and deploy it only for VPN 10.
So I can make sure that I'm only applying it where I want to in my environment.
Now notice also that we've got the option for this from service or from tunnel.
We know that we want to do this from service.
We're bringing traffic in from the service side and we're sending it out to
really the WAN environment.
We're not even sending it onto a tunnel at that point because we're bypassing
the tunnel, but we do want to make sure it's selected to say from service.
That is the default setting. But it's worth noting that.
So I'm just going to click add here and that should add in our VPN list,
So from here I'm going to save policy
and now we can push the policy out.
So the way I do that is by using these three dots and I click activate.
So let's go ahead and see what exactly that's going to do from a CLI perspective.
I scroll down, see I'm getting rid of an existing policies.
I don't need to worry too much about that.
But what we do see is that we're adding a data policy and we're applying it to a
specific VPN list. So VPN 10 is what we're doing.
And then we see our match action statement.
So matching against that source data prefix.
Remember a data prefix list is just a prefix list used for data policies.
So it's a prefix list targeting host 11 and the action is going to be to use our
NAT for VPN zero. So again, kind of what we did at the CLI on edge 13,
we're saying to use NAT that is using the global VRF table.
And then from here we're just applying the list that we need.
And down here importantly under apply policy,
we are specifying our data policy. Here's the name of the policy.
And then again,
where control policy will have a direction in or out for the most part,
we are specifying from service to be very clear about what we want to have
happen here. So this is going to push our NAT configuration out centralized,
but we're not quite done because as mentioned,
we do need to configure that feature template.
So we'll wait for this to be successful and then we'll go configure the feature
template changes. All right,
so now I'm going to come to configuration and go to templates and we're going
to come over to our feature template,
find the interface for our internet interface is internet there.
I'm going to edit this and we're going to look for the NAT section.
So I could scroll up here a little bit and here it is.
So NAT. So we want to, first of all,
change this to global and then say on. So now we're enabling NAT.
NAT type is we're just going to leave that on interface.
That'd be the overload concept.
We can leave the timeouts the same and really we don't have to change any of
these settings. So I'm just going to say update
and then we'll want to push this out. So if I click on this,
we can see what configuration is being pushed to the edge.
And if I scroll down, all right,
so we should see similar to what we configured at the CLI before IP NAT inside
source via this list and then interface gigabit ethernet one overload. All right,
cool. That looks pretty familiar. Then if I scroll down,
we've got IP NAT outside on the external interface and that's all it's pushing.
So it's basically doing the CLI configuration that we needed to do via static
configuration,
but now it's going to do it for all of the SD-WAN edges that are using this
particular feature template.
So let's go ahead and let this push and then we'll go to the CLI to confirm.
All right. And that didn't take very long.
So let's go ahead and flip over. So let's start with the main thing.
Let's see if we can now ping out to the internet from our host that's at site 11
and indeed we can. So our policy was able to effectively take note of it.
Now notice this,
what happens if I try to ping the host that's at whoops site 13.13.50.
This is not going through and there's a good reason for that.
And remember what we did, we basically told using our policy,
we told this edge that any traffic coming in from this edge needs to go to the,
to use NAT. So it's actually being NATed out and sent out to the internet,
even though it's not going to go anywhere from there.
So this is why we have to be very careful with our policies.
We need to make sure that when we're matching traffic,
we don't just match everything.
We need to make sure that we're matching traffic that's actually destined for
the internet.
This is one reason why this type of policy is actually best used with guest
access because guest access doesn't need to target any internal resources.
We can just send it straight out the internet and we're good to go.
Otherwise it's going to take a little bit of effort for us to make sure that
we're not targeting internal subnets.
So we don't want to reject any traffic that's destined towards 10 dot
something or 192.168 something or 172.
So we've got lots of considerations there to make when we're deploying this
policy. Oh, and notice that this is my internet router.
That's actually saying that it can't reach this subnet that we're,
this IP address that we're trying to reach,
which isn't a surprise because it's a private IP address.
So that's kind of funny.
It shows that we actually are sending it out not only into our fake internet
cloud, but in my lab environment,
the fake internet cloud is connected to the real internet and it's trying to
continue to make it towards its destination, which again,
doesn't exist on the internet. So one last thing we can look at here.
If we go take a look at edge 11,
we recall we've got this great command show SD WAN policy from vsmart.
Any policy that's being pushed down from vsmart when we're talking about data
policies will be listed here because recall with control policies,
we enforce it simply by restricting our OMP messages that we send around.
But with data policies, I'm yeah, the vsmart's involved,
but it's not actually just withholding information.
It has to actually pass configuration along.
So it uses OMP updates to pass a configuration.
And our edge now knows that this is the policy that's being enforced that was
received from the vsmart or our SD WAN controller.
So we see the direction here.
We see the VPN list and the match action statements telling it to use NAT for
example, again, we're matching all of our host 11 traffic,
which makes it so host 11 can't actually reach the other hosts in our lab
environment.
And so it's always good to verify that the policy is actually being received
from vsmart and this is the command that we can use to do so.