Something we need to consider when connecting our edges is network address
translation or
NAT.
Yes, NAT.
That can be a big problem depending on where our edges are located.
For example, we might have a situation where either we have to worry about NAT,
meaning
we've got a firewall here at the edge, and because of how we do our networking,
the router
sits behind the firewall and has a private RFC 1918 address.
This would be our 192.168 or maybe something like 10.0.0.1, something along
those lines.
The public address that communicates here connects into the internet was
represented
by the firewall here.
Maybe it's something a little bit more public like 190.20.16.37.
Just totally making up an IP address here.
This is a public IP address that is here at the edge and now are the edge of
our network,
by the way, and now the edge device for SD-WAN, our SD-WAN edge is no longer at
the edge and
is in fact behind this NAT arrangement.
When we have this in place, we actually have the capability of still having
edges that
are natively connecting to the internet and having a public IP address here.
For that matter, other devices that maybe are behind NAT in some capacity such
that it has
a private IP address.
We have the ability to form data plane tunnels to both of these types.
However, there are a little bit of or at least there are a few caveats that we
need to be
aware of and we need to understand that there are multiple NAT types that we
need to start
to become aware of.
Now in the Cisco world, we often start to relate this back to what we're used
to configuring.
We think about dynamic NAT and static NAT and this and that.
It wasn't intended to rhyme but is what it is.
When we're looking at NAT types as defined by the industry, we have four
different types
that we want to explore and understand what the implications are here.
The first one we want to take a look at is what's known as full-cone NAT.
If we've been doing Cisco NAT for a while, we're going to think of this as
static NAT.
Static NAT or full-cone simply means that we actually have a one-to-one
relationship
between our public and our private address.
Meaning that I as an edge device have a private address and I'm the only one
that gets to
use that public address.
Well, that's kind of interesting.
That is actually the what we call the ideal world here.
It makes things a whole lot easier for us when I just have a one-to-one
relationship
with this public IP address.
Essentially, what we're saying is if we get a packet that has a destination of
this public
address, what is this device supposed to do with it?
Well in our case here with full-cone or static NAT, we know that we're directly
forwarding
it to this device and we're always forwarding it to that device.
And so the public address that we're using for NAT effectively equates to this
address
and therefore there are no restrictions.
It's ideal because we don't have to worry about any problems with this NAT
device from
an SD-WAN perspective.
So that is great.
That is the end of our easy answers.
Unfortunately, we do have to worry about a couple of other topologies.
So next we're going to talk about what we might consider to be dynamic NAT in
the Cisco
world.
Dynamic NAT is when we have to start thinking about the fact that we're sharing
this public
address with other private addresses.
As soon as we have to start sharing things, things get a little more
complicated.
And so the first one we're going to talk about is what's known as restricted
cone.
Ad cone NAT is a form of dynamic NAT, but it still ends up being in a one-to-
one relationship.
However, it is subject to change.
What does that mean exactly?
Well, it means that the edge could have one public address representing it one
day and
a different public address the next day.
And again, we're sharing this, but it's sort of this concept of usually a first
-come-first-serve
model when we're running a pool of addresses.
So if I go out and I get a public address one day, then maybe when I go out to
renew it,
I'm given a different address or potentially what might happen is my router
might reload
and by the time the router reloads, my old public address has been handed out
to somebody
else.
So this is known as restricted cone.
We can't rely on the fact that this address belongs to this router or a
specific address
belonging to that router.
Instead, we're going to have to perform some type of discovery.
We're going to have to figure out what this router is using on a potentially
day-to-day
basis.
The good news is once we perform this discovery, we're good to go until
something changes,
and so we're actually still in pretty good shape.
This is not that big of a concern, and as a result, there are still no
restrictions.
So long as discovery, again, that's the key here, so long as discovery can take
place.
And spoiler alert, this is what the V-bond is going to help us to do in these
types of
situations.
Now, we do have another one to be aware of, and it is tied to restricted cone.
It is known as port restricted cone.
The port restricted cone is similar to a restricted cone.
However, it's going to only allow inbound connections on the same port.
So now it becomes port specific.
This is a little bit complicated.
Essentially, what we're saying now is I don't just own this concept of one-to-
one.
Everything sent to my IP address belongs to me, but now it's a port specific
concept.
The good news is it does still fall into that category of we just need to
perform discovery,
and once again, the V-bond can help us out with this.
Now lastly, we have what's known as symmetric, and yes, I am intentionally
using red here
because symmetric, or in the Cisco world, we call this port address translation
, symmetric
is by far the least ideal situation, and it is heavily restrictive.
In fact, there is a scenario where we will not be able to form tunnels with
symmetric
net.
We'll talk about that here coming up.
So what exactly is symmetric net?
Well, once again, it's port address translation.
In the Cisco world, that essentially means that we have many devices sharing
one public
address, so one public address, and the way we can tell who's speaking and how
to handle
return traffic is by performing port scrambling.
Up until now, we haven't actually changed the ports.
We've used the ports, for example, in port restricted cone.
We used the ports to help identify traffic, but with symmetric net, we're
actually changing
the ports.
We're scrambling those port IDs to make sure that we don't have any duplicate
ports.
So what does this mean for being restrictive?
Well, so long as we're using IPsec, the good news here is that the only
restriction is
we can't do symmetric net to symmetric net.
There is no way for the V-bond to help facilitate that type of connection.
There's too many variables happening, and we're not going to be able to form
that connection.
However, everything else, so long as the V-bond is performing its job, we will
be able to
form connections.
However, that does change with GRE.
GRE is a little bit more restrictive, but because in the real world, we don't
tend to
use GRE, we're going to focus here on IPsec and take a look at that.
Now Cisco does have a list of all of these restrictions on their website, and
we'll include
that link, so you can go take a look at what exactly this all entails in a
little bit more
detail.
But what we really want to take away from this conversation is understanding
that even
though we have a lot of different net options, for the most part, these are all
going to
work thanks to the V-bond, whereas symmetric net does indeed have a restriction
, it's
not going to allow communication to other symmetric net edges.
So for example, if we have symmetric net way out here, and we have symmetric
net here,
then this tunnel can't happen.
However, if we have symmetric net on the right and restricted cone here on the
left,
then we actually can form that connection, no problem, because it's not symm
etric on
both sides.
So really quickly, we've mentioned the V-bond a few times.
What is the V-bond doing?
Well, the V-bond is running what's known as a stun server.
Stun stands for session traversal utilities for net.
So if anything, we take away from that, the end stands for net, and it's going
to allow
for, first of all, detecting net, that's part of its job.
When the router first reaches out to V-bond, we're going to be able to figure
out whether
or not it's behind net.
And it's going to run a few different things for that, but it's going to log,
for example,
the private address, as well as the public address, assuming that they are
different.
If we're using net, they would be different.
If we're not using net, they would not be any different.
Not only that, it's able to utilize what we call a punch-through technique.
One of the challenges with net is that if a packet proactively arrives on an
interface,
we don't know what to do with that because nobody has actually claimed a
particular
port or whatever the situation is.
However, if traffic is first sent out, then that return traffic can come back,
and that's
why devices can function with net no problem.
They send a request out, the response comes back, and now this device in the
middle knows
to glue those together.
Now if we have two different nets, this punch-through concept simply allows us
to coordinate, this
is a coordination concept, where we're going to have both of these devices sent
to each
other at the same time.
It appears that we sent traffic out and got a response back.
That's the coordination via this punch-through mechanism that the V-bond
provides.
So in the real world, what do we want to do with all of this?
Well, as much as possible, we want to use static net and full cone where net is
required.
However, if we do have symmetric net in play because we can't plan on there
being data
plane tunnels necessarily to other devices, at that point we probably want to
plan on it
being some sort of partial mesh or hub and spoke topology.
And let's just be intentional about that from the get-go rather than having to
scramble
to adapt our topology to meet the needs of the net.