|
0:00:14
|
The next topic we're going to look at in IP services
|
|
0:00:16
|
is our network address translation or NAT config
|
|
0:00:20
|
which as we know is used to rewrite the IP addresses
|
|
0:00:23
|
in the Layer 3 packet header for either
|
|
0:00:27
|
IP version 4 or IP version 6
|
|
0:00:30
|
Now typically this is used to change the source addresses
|
|
0:00:33
|
of packets where we're trying to hide our private addresses
|
|
0:00:36
|
like the RFC 1918 space and IP version 4
|
|
0:00:40
|
from public destinations on the rest of the network.
|
|
0:00:45
|
But it could also be used for overlapping subnet issues
|
|
0:00:48
|
where maybe one network requires another one
|
|
0:00:51
|
and they're both using the 192.168.0.0/24 subnet.
|
|
0:00:57
|
To get communication between the two of them, we would either
|
|
0:01:00
|
have to renumber the networks or do some sort of translation
|
|
0:01:04
|
which in this case is called a double NAT translation
|
|
0:01:08
|
where we are translating not only the source addresses, but the
|
|
0:01:11
|
destination at the same time
|
|
0:01:14
|
so from one subnet that is 192.168.0.0 they're seeing
|
|
0:01:19
|
the remote subnet as a different address and then
|
|
0:01:21
|
vice versa. This could also be used to change the
|
|
0:01:24
|
destination addresses either in that double NAT scenario
|
|
0:01:28
|
for overlapping addresses or when we are trying to
|
|
0:01:31
|
allow access to our internal private services from the
|
|
0:01:36
|
outside public network
|
|
0:01:39
|
where for example we have our web server or mail server
|
|
0:01:42
|
on a DMZ that's using internally private addressing
|
|
0:01:47
|
if we want to give them access to the outside network
|
|
0:01:50
|
by mapping a public address to them.
|
|
0:01:54
|
Typically this is done with a static configuration
|
|
0:01:58
|
where we would say IP NAT inside source static
|
|
0:02:02
|
or IP NAT source static, but technically we
|
|
0:02:05
|
could do this dynamically which could be used for
|
|
0:02:08
|
TCP load distribution with NAT where if we had
|
|
0:02:12
|
multiple we servers that were mirrors of each other
|
|
0:02:15
|
we could simply use the NAT process to load balance
|
|
0:02:19
|
between the servers. In most real applications
|
|
0:02:23
|
of this, you would have a dedicated device to do the
|
|
0:02:25
|
load balancing, but technically you could just use the
|
|
0:02:29
|
NAT process on the routers in order to accomplish this.
|
|
0:02:33
|
The other very common implementation with this is
|
|
0:02:35
|
the port address translation which is used for our overloading
|
|
0:02:40
|
of many to one
|
|
0:02:42
|
where on the inside network we have more private addresses
|
|
0:02:45
|
then we do have public addresses allocated on the outside, so we could
|
|
0:02:50
|
either change the addresses to the interface address of the
|
|
0:02:53
|
outside router or some sort of public pool that
|
|
0:02:55
|
we are allocated. Now part of the problem with the
|
|
0:02:58
|
NAT configuration comes in from a confusion of
|
|
0:03:02
|
how the terminology is used. The difference between
|
|
0:03:05
|
the inside addresses and the outside addresses
|
|
0:03:08
|
and the global versus the local values.
|
|
0:03:11
|
Now the inside local and global addresses those are
|
|
0:03:15
|
used to denote the networks that we are trying to translate
|
|
0:03:20
|
where the inside local is what we are translating from
|
|
0:03:23
|
and inside global is what we are translating to.
|
|
0:03:26
|
The key point here being that inside means that it's part of our
|
|
0:03:29
|
own network where local is the locally significant addressing
|
|
0:03:34
|
like the RFC 1918s
|
|
0:03:36
|
and global is going to be globally significant to everyone.
|
|
0:03:40
|
So typically inside local is our private addresses
|
|
0:03:43
|
inside global is our public addresses.
|
|
0:03:47
|
For the outside network, the outside global is the destination
|
|
0:03:52
|
that we are trying to reach.
|
|
0:03:55
|
And outside local is going to be used in a double NAT translation
|
|
0:04:00
|
which is the true address on the outside host translation.
|
|
0:04:06
|
So in most NAT scenarios you would only see inside local
|
|
0:04:10
|
inside global and outside global.
|
|
0:04:13
|
Outside local is going to be used when you're translating both sources and
|
|
0:04:16
|
destinations at the same time. One of the important points to
|
|
0:04:19
|
keep in mind with network address translation is that the order of
|
|
0:04:23
|
operations is different whether traffic is moving from the inside of
|
|
0:04:28
|
the network out or moving from the outside of the network in.
|
|
0:04:33
|
Additionally, it's important to keep in mind that the NAT process
|
|
0:04:37
|
is separate from the routing process.
|
|
0:04:41
|
So just because I can translate the addresses doesn't necessarily
|
|
0:04:44
|
mean that the destinations have a route back to the pool.
|
|
0:04:48
|
Or just because I have a route to the destination doesn't necessarily mean
|
|
0:04:51
|
that I have a translation. So they're two separate
|
|
0:04:55
|
processes that need to be dealt with. The routing is
|
|
0:04:57
|
always going to control where is the traffic going
|
|
0:04:59
|
then the NAT rules are controlling how we are changing either the
|
|
0:05:03
|
source addresses or the destination addresses in the Layer 3 header
|
|
0:05:08
|
where for traffic flows that are going from the inside
|
|
0:05:10
|
out, first we are going to route the packets, then we
|
|
0:05:15
|
are going to translate their sources. Now the idea behind
|
|
0:05:19
|
this is that typically destinations are globally significant where
|
|
0:05:23
|
those are referenced as the outside globals.
|
|
0:05:27
|
So we pick what is the outgoing interface before
|
|
0:05:30
|
we actually run into the translation rule.
|
|
0:05:33
|
This would allow us to do separate translations
|
|
0:05:37
|
on a per interface basis.
|
|
0:05:39
|
And the design that this is typically useful for is if we
|
|
0:05:43
|
have a router that has an inside segment that
|
|
0:05:48
|
goes to the LAN, then multiple outside interfaces
|
|
0:05:52
|
where one of them goes to service provider one
|
|
0:05:58
|
and another one goes to service provider two
|
|
0:06:02
|
and Router 1 does not have its own provider independent
|
|
0:06:06
|
address base, so we're not running BGP. We just have a
|
|
0:06:10
|
simple solution where we're doing default routing on both
|
|
0:06:13
|
both of the links.
|
|
0:06:15
|
But the key is that if we are routing the traffic out to
|
|
0:06:18
|
ISP 1, I need to translate my sources.
|
|
0:06:24
|
I need to translate my sources to the addresses that ISP 1 has
|
|
0:06:29
|
allocated me, so maybe this is pool A.
|
|
0:06:33
|
Where if I go out this direction to ISP 2, I need to
|
|
0:06:36
|
translate to pool B
|
|
0:06:39
|
because I don't have my own provider independent address base.
|
|
0:06:42
|
Now configuration wise in this type of implementation
|
|
0:06:46
|
this is where we would have separate NAT pools
|
|
0:06:49
|
then the router is going to reference these based on
|
|
0:06:51
|
a route map.
|
|
0:06:53
|
So since the routing process is happening first,
|
|
0:06:56
|
once the traffic gets to the NAT rule
|
|
0:06:59
|
the router will already know what is the outgoing interface
|
|
0:07:03
|
where we can tell the router to match based on what's
|
|
0:07:05
|
the outgoing link and then do the translation according to that.
|
|
0:07:10
|
So you can actually get into really complicated rules
|
|
0:07:13
|
with the NAT process where you're doing this type of
|
|
0:07:16
|
translation based on the outgoing link.
|
|
0:07:19
|
You could also do the translation based on the particular destination
|
|
0:07:23
|
so we could do per port translations
|
|
0:07:27
|
like if I'm going to TCP port 80, I could translate
|
|
0:07:30
|
that way or if I'm going to port 25, I could go that way.
|
|
0:07:35
|
Now within the scope of the lab exam, you don't necessarily
|
|
0:07:38
|
need to be an expert in the NAT process just like
|
|
0:07:41
|
any of these other IP services.
|
|
0:07:43
|
So you'll see there are a lot of advanced examples of
|
|
0:07:46
|
this in the volume 1 workbook. As long as you try out a couple
|
|
0:07:49
|
of them and know how to reference this in the documentation
|
|
0:07:52
|
then you should be fine. In our particular case
|
|
0:07:56
|
we're going to look at some examples of this on Router 5
|
|
0:08:00
|
where we'll say that the link that is going to
|
|
0:08:06
|
Fast Ethernet 0/0 this is going to be our inside
|
|
0:08:08
|
network and the frame relay is going to be our outside network.
|
|
0:08:14
|
So the rest of the outside network they're not going to have
|
|
0:08:16
|
routing information to the devices on the inside.
|
|
0:08:20
|
In order to get there, they're going to have to use the
|
|
0:08:22
|
inside global addresses that Router 5 has allocated.
|
|
0:08:27
|
So whether this be a NAT pool that we're defining
|
|
0:08:30
|
or whether we are just overloading to an interface
|
|
0:08:35
|
we need to make sure that whatever sources Router 5
|
|
0:08:37
|
translates to, the rest of the network has a route back to this.
|
|
0:08:42
|
Documentation wise, the NAT process is going to be
|
|
0:08:46
|
under the IP addressing services.
|
|
0:08:50
|
So under IP, IP addressing services configuration guide
|
|
0:08:55
|
then network address translation.
|
|
0:08:59
|
This second document configuring NAT for IP address conservation
|
|
0:09:03
|
this is going to be the basic configurations of how
|
|
0:09:05
|
we do the inside source translations
|
|
0:09:11
|
so again, those hosts are inside our network
|
|
0:09:14
|
we're trying to translate the source addresses from the
|
|
0:09:16
|
locally significant values to the globally significant values.
|
|
0:09:21
|
So the first thing I'm going to do here on the link between
|
|
0:09:24
|
Router 5 and switch 2
|
|
0:09:28
|
I'm going to change the addresses here so there's something that the
|
|
0:09:32
|
rest of the network does not have a route to.
|
|
0:09:34
|
I'll say ip address 10.0.0.5
|
|
0:09:38
|
on Router 5 this will be /24
|
|
0:09:42
|
then switch 2 on vlan 58 the address is 10.0.0.8
|
|
0:09:54
|
Now again, the routing process is separate from the NAT process
|
|
0:09:58
|
so we need to make sure that the traffic can get from the inside
|
|
0:10:00
|
out first through routing
|
|
0:10:04
|
then it is going to be translated.
|
|
0:10:07
|
So this would then now imply that switch 2 is going to
|
|
0:10:09
|
have to have a route out to the rest of the network. I'll simply
|
|
0:10:12
|
configure a default route to account for this.
|
|
0:10:15
|
I'll say I'll default all traffic out to Router 5
|
|
0:10:23
|
To test this, I could say on switch 2
|
|
0:10:26
|
I'll just ping the loopback address of Router 5
|
|
0:10:28
|
if I can reach this, then I know the basic static routing process is working.
|
|
0:10:32
|
If I look on the routing table for the dynamic routes
|
|
0:10:36
|
I'm not going to be learning anything in from five
|
|
0:10:40
|
because I changed the address on the link
|
|
0:10:43
|
to something that I do not have a network statement for under the
|
|
0:10:46
|
EIGRP process.
|
|
0:10:48
|
And I could tell this because as soon as I changed the address
|
|
0:10:51
|
the EIGRP -- was then going down
|
|
0:10:56
|
which is fine though because we're going to change the source
|
|
0:10:58
|
addresses to something the rest of the network does have a route to.
|
|
0:11:01
|
So now on Router 5, the next is going to be to define
|
|
0:11:05
|
what is the addresses we're translating to
|
|
0:11:08
|
and what is the specific NAT rule.
|
|
0:11:12
|
The addresses we are translating to they could either
|
|
0:11:16
|
be defined by a pool or we could use some attached interface
|
|
0:11:20
|
whether it's the loopback or the outgoing interface
|
|
0:11:28
|
so I'll define the IP NAT pool
|
|
0:11:31
|
I'll say this is my inside global pool
|
|
0:11:36
|
The prefix will be 155.28.254.0 with a prefix length of
|
|
0:11:51
|
or two
|
|
0:11:51
|
155.28.254.255
|
|
0:11:55
|
with a prefix length of 24
|
|
0:12:00
|
Now what the NAT mask and prefix length match
|
|
0:12:04
|
is essentially what address range the router is going to
|
|
0:12:07
|
proxy for.
|
|
0:12:10
|
So when now on the outside, someone sends an ARP request
|
|
0:12:13
|
for any addresses that go from the .1 to the .254
|
|
0:12:19
|
Router 5 is then going to proxy with its own Mac address.
|
|
0:12:24
|
So if your prefix length doesn't actually match
|
|
0:12:26
|
what you're trying to translate to
|
|
0:12:28
|
you're going to have a Layer 3 to Layer 2 resolution
|
|
0:12:30
|
process when traffic is actually sent to the router.
|
|
0:12:35
|
So now I know what are the addresses I'm translating to
|
|
0:12:38
|
next I need to specify the rule that says how do I classify
|
|
0:12:42
|
what traffic I actually want to translate.
|
|
0:12:46
|
And this is where most of the problems come in with
|
|
0:12:48
|
the NAT configuration that if we translate too much traffic.
|
|
0:12:53
|
So we are not specific enough in the classification.
|
|
0:12:57
|
The NAT process can translate the locally generated control
|
|
0:13:02
|
plain traffic from the router itself.
|
|
0:13:04
|
Now to demonstrate this on Router 5, what I'm going to do
|
|
0:13:08
|
is configure a BGP peering
|
|
0:13:11
|
I'll say this is BGP 5
|
|
0:13:13
|
and I'm going to peer with Router 6
|
|
0:13:18
|
So I'll say neighbor 150.28.6.6
|
|
0:13:24
|
who is in AS 100
|
|
0:13:29
|
and they're in ebgp multihop here.
|
|
0:13:35
|
On Router 6, I'm going to peer with the frame relay
|
|
0:13:41
|
interface of Router 5 who's in AS 5
|
|
0:13:45
|
they are in ebgp multihop here.
|
|
0:13:51
|
So assuming that routing is working to begin with
|
|
0:13:58
|
I should have reachability to that destination.
|
|
0:14:00
|
From Router 5 if I ping 150.28.6.6
|
|
0:14:06
|
I am able to reach them.
|
|
0:14:08
|
If we look at the show ip bgp summary
|
|
0:14:14
|
Router 6 needs to say that its update source
|
|
0:14:19
|
is loopback 0
|
|
0:14:37
|
If we look at the show ip bgp summary
|
|
0:14:41
|
we see now we have the peering up to Router 5
|
|
0:14:46
|
So Router 5 is running TCP on the outside interface
|
|
0:14:48
|
for the BGP session and it's also running the EIGRP process.
|
|
0:14:54
|
So two different control plain protocols I have now
|
|
0:14:57
|
EIGRP and BGP
|
|
0:15:00
|
So next step I had my NAT pool already, if we show run include nat
|
|
0:15:06
|
Next step is to figure out how am I going to classify the
|
|
0:15:09
|
traffic that I want to translate.
|
|
0:15:13
|
In this case, I'm simply going to say everything. I'll say
|
|
0:15:15
|
access list 1 permit any
|
|
0:15:20
|
Now I'm going to do the actual translation. I'll say
|
|
0:15:22
|
ip nat
|
|
0:15:24
|
and depending on the particular version that you're using
|
|
0:15:27
|
the newer versions get rid of the syntax that says
|
|
0:15:33
|
inside and outside
|
|
0:15:36
|
because the direction on the interface doesn't matter anymore.
|
|
0:15:40
|
Where previously you had to specify what's the IP
|
|
0:15:42
|
NAT inside and what's the IP NAT outside interfaces.
|
|
0:15:46
|
In the newer versions, you simply say ip nat enable
|
|
0:15:51
|
so then you can define any translation that you want
|
|
0:15:54
|
regardless of what the direction is.
|
|
0:15:58
|
So it makes it easier to translate from outside in versus inside out.
|
|
0:16:01
|
We could technically use either syntax, it doesn't really matter.
|
|
0:16:04
|
I'll simply say ip nat source
|
|
0:16:08
|
ip nat source, the source list is one
|
|
0:16:12
|
so if traffic matches ACL 1 which is anything
|
|
0:16:15
|
I'm going to translate to the pool which I called
|
|
0:16:20
|
the inside global.
|
|
0:16:25
|
And I'll do a port translation, I'll say overload.
|
|
0:16:31
|
Then the last step would be to configure the interfaces
|
|
0:16:34
|
for the NAT process, so ip nat enable
|
|
0:16:37
|
at the link levels.
|
|
0:16:44
|
Next on Router 5, let's look at the show ip nat translations.
|
|
0:16:51
|
And we should see that as traffic comes from the inside
|
|
0:16:53
|
and then goes out, it's changed to the addresses
|
|
0:16:57
|
of that pool that we've defined.
|
|
0:17:00
|
So from switch 2 I'm going to send traffic to the let's say the
|
|
0:17:03
|
loopback of Router 1
|
|
0:17:06
|
On Router 5 when we look at the show ip nat translations
|
|
0:17:10
|
we should see that that traffic is changing
|
|
0:17:14
|
its addresses to what I've defined in the pool.
|
|
0:17:21
|
So let's show run include nat
|
|
0:17:26
|
I have NAT on, it says that if the source has matched list 1
|
|
0:17:30
|
where access list 1
|
|
0:17:33
|
is essentially everything.
|
|
0:17:40
|
I'm going to change this source address and the packet
|
|
0:17:42
|
to something that is inside this particular pool.
|
|
0:17:48
|
So what's changed about this configuration now
|
|
0:17:51
|
is that Router 5 is not using a definition inside and outside.
|
|
0:17:59
|
But we should see here in the translation
|
|
0:18:04
|
that the packets are being matched, so on Router 5 let's look at the
|
|
0:18:08
|
debug ip nat detailed
|
|
0:18:13
|
and this should tell us whether the actual translation is occurring.
|
|
0:18:17
|
So from switch 2 let's
|
|
0:18:20
|
keep this ping going
|
|
0:18:24
|
Router 5 says it allocated a port for 10.0.0.8
|
|
0:18:30
|
We translated it to 254.1
|
|
0:18:36
|
This is telling us that the packet was translated, so the
|
|
0:18:39
|
source changed from 10.0.0.8 to 155.28.254.1
|
|
0:18:44
|
it's really going to 150.28.1.1
|
|
0:18:50
|
so if we look at the show ip nat translations
|
|
0:18:53
|
we should see this
|
|
0:18:59
|
in here. We may need to say let's say detailed.
|
|
0:19:07
|
Or show ip nat translations
|
|
0:19:17
|
So we could see from the debug, the translation is actually occurring.
|
|
0:19:20
|
If we were to go to Router 1 and look at the debug ip icmp
|
|
0:19:27
|
we see that the packets are coming in
|
|
0:19:30
|
from 155.28.254.1
|
|
0:19:36
|
but if we look at the debug ip packet on Router 1
|
|
0:19:44
|
Router 1 says that for that particular destination
|
|
0:19:52
|
it's being routed out Ethernet 0/0
|
|
0:19:59
|
which essentially is the wrong leg.
|
|
0:20:04
|
So Router 1 is getting the packets if we look at the diagram
|
|
0:20:07
|
the traffic is coming from the inside network
|
|
0:20:15
|
inside network and going out, it gets to 1
|
|
0:20:19
|
when 1 is replying, they reply is actually going this way.
|
|
0:20:25
|
So what this means is that there's a problem in the routing process
|
|
0:20:28
|
which again is separate from the NAT process.
|
|
0:20:32
|
So just because I did the translation doesn't necessarily
|
|
0:20:35
|
mean that destinations have a route back to the pool.
|
|
0:20:39
|
So now what I need to do on Router 5 is advertise that
|
|
0:20:42
|
pool that I defined 155.28.254.0/24
|
|
0:20:50
|
I basically need to advertise this into the EIGRP process.
|
|
0:20:54
|
Now on Router 5 if we look at the
|
|
0:20:59
|
the show ip interface brief
|
|
0:21:05
|
in the newer versions, there's a specific link that is called
|
|
0:21:09
|
the NAT virtual interface
|
|
0:21:11
|
or NVI 0
|
|
0:21:13
|
that's used to solve an order of operations problem
|
|
0:21:16
|
with the routing process where traffic is always sent to the
|
|
0:21:20
|
NVI first before it is translated
|
|
0:21:24
|
which is why we don't necessarily need to specify what is inside versus
|
|
0:21:27
|
outside.
|
|
0:21:31
|
If we look at the show ip route
|
|
0:21:38
|
and let's say show ip route include 254
|
|
0:21:41
|
Notice that the actual pool is not in the table
|
|
0:21:47
|
because the only place that it exists is internal to the NAT
|
|
0:21:52
|
process on Router 5
|
|
0:21:55
|
so there's a couple different ways that we could solve this
|
|
0:21:57
|
problem. When we're defining the pool
|
|
0:22:02
|
which is the inside global pool
|
|
0:22:06
|
we could say add the route to the NAT virtual interface
|
|
0:22:12
|
which means that I'm going to have to disable this temporarily
|
|
0:22:18
|
so let's say show run include nat
|
|
0:22:24
|
so I'll remove the translation
|
|
0:22:30
|
dynamic mapping in use, I need to stop these pings is what it is.
|
|
0:22:55
|
So you can see from the config it is sensitive to the order of operations.
|
|
0:22:58
|
Probably what I need to do now to allow me to delete this
|
|
0:23:03
|
is to remove the interfaces from the NAT process.
|
|
0:23:06
|
So on the frame relay I'll say no ip nat enable
|
|
0:23:11
|
and the same on the Ethernet
|
|
0:23:13
|
So I should now be able to
|
|
0:23:18
|
delete the nat rule
|
|
0:23:22
|
Dynamic mapping still in use let's try clear ip nat
|
|
0:23:28
|
translation *
|
|
0:23:42
|
which now allows me to remove it.
|
|
0:23:43
|
So now what I want to say for the nat pool
|
|
0:23:46
|
when I'm creating this, I want the router to automatically
|
|
0:23:49
|
add a route.
|
|
0:23:55
|
If we look at the show ip route connected
|
|
0:24:01
|
or let's say show ip route does it show up as static? Yes it does.
|
|
0:24:04
|
So the router basically puts a route that goes to null zero
|
|
0:24:09
|
which is represented by the NAT virtual interface
|
|
0:24:13
|
which would now allow me to advertise the static route
|
|
0:24:16
|
into IGP or to BGP
|
|
0:24:20
|
so in this particular case, since I'm running EIGRP
|
|
0:24:23
|
as my routing protocol
|
|
0:24:25
|
I could go under the EIGRP process and say
|
|
0:24:29
|
redistribute static and I'll say any arbitrary metric
|
|
0:24:36
|
Now once I look at the rest of the network, if we were to
|
|
0:24:38
|
look at Router 1 and say show ip route 155.28.254.0
|
|
0:24:45
|
now I have an exact match for this via external EIGRP
|
|
0:24:49
|
So the key again is that the NAT process is separate
|
|
0:24:53
|
from the routing process. You always need to make sure that
|
|
0:24:55
|
you can get to the destination and the destination can get
|
|
0:24:58
|
back, otherwise, the translation is not going to matter.
|
|
0:25:04
|
So one way to issue -- one way to fix this
|
|
0:25:06
|
is under the pool's definition you could say add route to the end of it
|
|
0:25:11
|
which is going to put a static route pointing to the NVI
|
|
0:25:16
|
Another way would just be to manually install the
|
|
0:25:19
|
static route, so if I said IP route 155.28.254.0/24
|
|
0:25:26
|
is via null zero
|
|
0:25:28
|
then I can redistribute static into EIGRP
|
|
0:25:32
|
The third method would be to take a loopback interface
|
|
0:25:35
|
and allocate it an address from the pool.
|
|
0:25:39
|
As long as the prefix can get into the routing table
|
|
0:25:43
|
that's really the only thing that I care about.
|
|
0:25:45
|
Now if we look at the running configuration for the NAT process
|
|
0:25:50
|
or static routing
|
|
0:25:52
|
notice that in the running config, it doesn't actually
|
|
0:25:56
|
put the ip route statement
|
|
0:26:00
|
this is the replacement for it, so it's saying automatically
|
|
0:26:03
|
add a static route for this specific prefix which is /24
|
|
0:26:08
|
that points to the NAT virtual interface.
|
|
0:26:12
|
But again, it's the same logic as saying ip route 155.28.254.0
|
|
0:26:19
|
/24 is via null zero
|
|
0:26:24
|
then I can say redistribute static.
|
|
0:26:28
|
So whichever one we do, it doesn't really matter
|
|
0:26:30
|
as long as somehow we solve the routing process.
|
|
0:26:37
|
Once I have the routing configured, now I can
|
|
0:26:39
|
put the NAT rule back in
|
|
0:26:43
|
which is the source list
|
|
0:26:46
|
then at the link level say ip nat enable
|
|
0:26:52
|
on the serial and the frame relay.
|
|
0:26:55
|
So from the internal network on switch 2 if I were to telnet
|
|
0:27:00
|
to Router 1's loopback
|
|
0:27:04
|
if we look at the show users
|
|
0:27:07
|
notice the source address
|
|
0:27:10
|
is the post translated address.
|
|
0:27:14
|
So it's not the 10 network where the packet is actually
|
|
0:27:17
|
coming from, it's the translated address of 155.28.254.1
|
|
0:27:24
|
So this configuration is going to allow traffic to go from the
|
|
0:27:27
|
inside network out
|
|
0:27:30
|
but from the outside network, if I were to go to Router 1
|
|
0:27:34
|
and let's say we telnet back to that address
|
|
0:27:36
|
the 254.1
|
|
0:27:42
|
since there is no translation rule that is specific to TCP
|
|
0:27:45
|
port 23, Router 5 is dropping this as the
|
|
0:27:50
|
traffic comes inbound.
|
|
0:27:55
|
So the NAT process could also be thought of as a
|
|
0:27:57
|
security mechanism, it worked kind of like how
|
|
0:27:59
|
the active firewall process of either CBAC or the
|
|
0:28:02
|
zone based policy firework works
|
|
0:28:06
|
where unless the traffic was originated from the
|
|
0:28:08
|
inside to begin with which is creating the state information
|
|
0:28:12
|
in the NAT table, then the router's not going to allow
|
|
0:28:16
|
the traffic back in.
|
|
0:28:19
|
So on Router 5 if we look at the show ip nat translations
|
|
0:28:25
|
we should be able to see the traffic being translated there
|
|
0:28:29
|
let's see show ip nat
|
|
0:28:32
|
-- say nvi translations
|
|
0:28:35
|
So this one is for the when we say ip nat enable
|
|
0:28:40
|
as opposed to ip nat inside or ip nat outside
|
|
0:28:43
|
so now this is essentially the inside source
|
|
0:28:48
|
for the global address, so that's what we're translating to.
|
|
0:28:51
|
This is what we translated from.
|
|
0:28:56
|
But notice see we're going in both directions.
|
|
0:28:58
|
We tried to translate that telnet session for Router 1 on the outside
|
|
0:29:07
|
but we didn't actually know where to send it because no one
|
|
0:29:09
|
had the previous translation to begin with.
|
|
0:29:15
|
So for that application where you're trying to translate
|
|
0:29:17
|
the destination, typically this is what a static entry is going to be for.
|
|
0:29:21
|
So we'll say ip nat source static
|
|
0:29:28
|
and we could also do this based on a port number
|
|
0:29:31
|
for basically port forwarding through the NAT process.
|
|
0:29:37
|
So let's now say on the outside interface for
|
|
0:29:41
|
TCP port for the source
|
|
0:29:46
|
local address which is going to be the inside address.
|
|
0:29:52
|
Here I'll say this is 10.0.0.8
|
|
0:29:57
|
they're going to listen at port 23
|
|
0:30:01
|
but on the outside, I'm going to have this be my interface address.
|
|
0:30:06
|
The frame relay and I'll listen at 12345
|
|
0:30:13
|
So what this now essentially means is that if someone
|
|
0:30:15
|
telnets to Router 5's interface
|
|
0:30:21
|
at port 12345
|
|
0:30:23
|
we're actually changing the -- not trace route telnet
|
|
0:30:27
|
telnet to 155.28.0.5 at 12345
|
|
0:30:31
|
we're changing the destination address
|
|
0:30:37
|
to what we specified here on Router 5
|
|
0:30:42
|
as what the source is.
|
|
0:30:46
|
So the syntax logic is kind of backwards because
|
|
0:30:48
|
we're actually doing a destination translation
|
|
0:30:52
|
but since the router is putting this statically in the table
|
|
0:30:56
|
we can use it in either direction. Either outside in or inside out.
|
|
0:31:03
|
So this is a useful way here that you can get the router
|
|
0:31:05
|
to listen to different port values for different applications
|
|
0:31:11
|
where let's say that we don't want Router 5 to listen at
|
|
0:31:14
|
port 23 for telnet
|
|
0:31:17
|
we want it to listen to any other value.
|
|
0:31:20
|
What we could do is essentially translate a
|
|
0:31:23
|
local address.
|
|
0:31:29
|
Let's say clear ip nat
|
|
0:31:31
|
clear ip nat translation *
|
|
0:31:37
|
so I need to disconnect this, so I'll exit
|
|
0:31:56
|
I need to say clear ip nat nvi translations
|
|
0:31:59
|
so you see the syntax is a little bit different depending on
|
|
0:32:01
|
which version you're using. The inside outside format of the
|
|
0:32:05
|
syntax or just the source and destination.
|
|
0:32:11
|
So now let's say when someone telnets to port
|
|
0:32:15
|
8080, we want this to go to Router 5's exec process.
|
|
0:32:21
|
So I'll say ip nat source static tcp
|
|
0:32:27
|
I'll send this to Router 5's loopback
|
|
0:32:29
|
at port 23
|
|
0:32:32
|
but I'm going to listen on my outside interface
|
|
0:32:37
|
at 8080
|
|
0:32:42
|
so now when Router 1 telnets to Router 5
|
|
0:32:45
|
at 8080
|
|
0:32:50
|
this goes to...
|
|
0:32:57
|
Actually did we direct it to Router 1?
|
|
0:32:58
|
that should have said -- yeah, that should have said 5.5
|
|
0:33:02
|
which is kind of weird I looped the traffic back to Router 1 itself
|
|
0:33:06
|
so I need to say now clear ip nat nvi translations
|
|
0:33:20
|
so that should say 5.5
|
|
0:33:29
|
which then on the loopback I would need to enable the
|
|
0:33:32
|
NAT process, so on loopback 0 let's say ip nat enable
|
|
0:34:05
|
so for TCP traffic that is really going to my
|
|
0:34:10
|
outside interface at 8080
|
|
0:34:13
|
it should be redirected to the loopback
|
|
0:34:19
|
at port 23, let's make sure that's the right address
|
|
0:34:22
|
155.28.5.5
|
|
0:34:33
|
so it looks like five is not doing the translation
|
|
0:34:36
|
let's look at the debug debug ip nat
|
|
0:34:43
|
debug ip nat detailed
|
|
0:34:44
|
I want to see when Router 1 sends this TCP packet
|
|
0:34:48
|
what is Router 5 doing with it.
|
|
0:35:02
|
It says the
|
|
0:35:13
|
address came from 155.28.0.1
|
|
0:35:17
|
going to 155.28.0.5 at 8080
|
|
0:35:23
|
I changed the destination to 23
|
|
0:35:28
|
but then I changed the source to 254.1
|
|
0:35:34
|
so basically now this an error in the classifier on Router 5
|
|
0:35:38
|
which is kind of strange because even thought the
|
|
0:35:41
|
traffic is coming in the outside interface
|
|
0:35:47
|
which normally would be the outside interface, but again
|
|
0:35:50
|
it doesn't have it -- there's no difference between inside and
|
|
0:35:52
|
outside anymore, so we can translate in, in either direction.
|
|
0:35:59
|
So essentially what the problem is now is that
|
|
0:36:03
|
when we look at the let's say show run include nat
|
|
0:36:08
|
this access list is now too broad
|
|
0:36:14
|
for what the particular traffic is that I want to translate.
|
|
0:36:22
|
So there's essentially an overlapping between what the static entry says
|
|
0:36:28
|
and what the inside global translation I was trying to do was.
|
|
0:36:36
|
So you'll see in some certain cases there's going to be a problem
|
|
0:36:39
|
when the classifier is too broad. In other cases
|
|
0:36:42
|
it's not going to make a difference, but to fix this problem
|
|
0:36:45
|
in the first place, what you want to do is essentially
|
|
0:36:48
|
when we say show access list 1
|
|
0:36:52
|
you should never say match everything
|
|
0:36:56
|
in the NAT process.
|
|
0:37:03
|
So if I want to match just the traffic that's coming
|
|
0:37:06
|
from this segment
|
|
0:37:11
|
so the inside going out
|
|
0:37:14
|
what I should actually say in the access list is to match
|
|
0:37:17
|
sources that come from 10.0.0.0/24
|
|
0:37:25
|
and translate those.
|
|
0:37:28
|
So in the older syntax, it's usually not as much of a problem
|
|
0:37:32
|
because there's a clear separation as to what
|
|
0:37:36
|
is the inside interface versus the outside interface
|
|
0:37:43
|
whereas in the newer NAT process there's no difference
|
|
0:37:47
|
between inside and outside so you can do the translation in
|
|
0:37:50
|
whatever direction that you want, so what I actually need to
|
|
0:37:52
|
change here is on Router 5 I'll say access list 1 permits
|
|
0:38:01
|
the 10 network
|
|
0:38:04
|
with an inverse mask of 24
|
|
0:38:08
|
then if we show access list
|
|
0:38:14
|
ip access list standard 1
|
|
0:38:17
|
I'm going to remove sequence number 10
|
|
0:38:21
|
then when we show ip nat nvi translations
|
|
0:38:29
|
we should see now when we come from the outside in
|
|
0:38:35
|
and debug ip nat detailed
|
|
0:38:50
|
now the translation is correct, so now it's going into the loopback
|
|
0:38:54
|
of Router 5
|
|
0:38:59
|
but it says can't create the entry
|
|
0:39:03
|
I may need to clear out the process now, so let's
|
|
0:39:06
|
say show run include nat
|
|
0:39:11
|
and show ip nat
|
|
0:39:18
|
nvi translations. It says the packet is coming from
|
|
0:39:22
|
Router 1
|
|
0:39:24
|
with the destination of the outside interface of Router 5
|
|
0:39:28
|
It has been translated to the loopback
|
|
0:39:31
|
but it looks like Router 1 is not getting the response
|
|
0:39:34
|
back in now, so on Router 1 let's look at the debug ip packet
|
|
0:39:37
|
detail and see when it sends the telnet to five
|
|
0:39:43
|
what is the response it gets back in.
|
|
0:39:52
|
It is coming back at 8080
|
|
0:40:10
|
and then there's also a packet that's going to the loopback of Router 1
|
|
0:40:13
|
this must be from...
|
|
0:40:18
|
that's from the inside here.
|
