Chapter 3: Securing Networks with ACLs and NAT
In This Chapter
Working with Access Control Lists (ACLs) to restrict traffic flow
Creating ACLs
Detecting viruses with ACLs
Configuring NAT
I could cover Access Control Lists (ACLs) along with switches, routers, or firewalls because most Cisco products use ACLs in one manner or another. As such, I cover them all in one place. Although the syntax may vary slightly from platform to platform, the principles and application of ACLs remain fairly consistent.
ACLs are actually required as part of implementing Network Address Translation (NAT) on your network, so I discuss both ACLs and NAT within this chapter. Additionally, I show you how easy it is to restrict traffic with just a few key strokes (and therefore, how easy it is to mess up traffic flow on your network with just a few key strokes).
Securing Networks with ACLs
ACL stands for Access Control List. An ACL has a list of entries, which are called Access Control Entries (ACEs). The entries that make up the list affects the access that one network device has to another network device. ACEs are not necessarily a negative restriction; in some cases, an ACE is a method of granting a person or device access to something. Therefore, an ACE’s two big roles are in the Deny category and the Permit category.
To work with ACLs properly, you should know where to apply them on your network. You can apply ACLs in two areas, either near the source of the traffic or close to the destination. If you put an entry close to the source or the destination, then you can likely take care of your control needs by needing to touch only that one device.
If you can place your rules near the source of the traffic, then you have a benefit of stopping the traffic at that point. If you have the rules placed near the destination of the traffic flow, the traffic actually goes almost all the way to the destination before being told that it is not allowed. For example, Canadians have something called preclearance for travelling into the United States. This is like placing ACLs near the source because, before you board your plane in Canada, you go through all the U.S. Customs processing. This means that you know if you are allowed in the United States before you get to the plane. Likewise, putting your ACLs near the source cuts down on the traffic crossing your network.
In some cases, you do not have control over the source location or locations. If you have a very large WAN, traffic could enter the network from the Internet in several locations. This means you need to put matching ACLs on several devices across the WAN so, rather than putting those rules on all the other devices, you can put the ACLs or rules in one or two devices near the destination of the traffic. This means that traffic crosses the network, only to be rejected as the traffic approaches the goal. Although this strategy increases traffic on the network, it gives you an implementation that is easier to maintain because you now have to worry about only one device.
Creating ACLs
You will work with two types of ACLs:
• Standard ACLs, which have fewer options for classifying data and controlling traffic flow
• Extended ACLs, which offer the ability to filter or control traffic based on a variety of criteria
This section delves into these ACLs, including creating and managing your network’s traffic flow with them.
Standard ACLs
Standard ACLs are easier and simpler to use than extended ACLs. However, in their simplicity, you lose some functionality, such as managing access based on Transmission Control Protocol (TCP) or User Datagram Protocol (UDP) ports. Standard ACLs are numbered from 1–99 and from 1300–1999 (expanded range). They only permit or deny access based on the source IP addresses.
Wildcard masks
When you create a standard ACL or an extended ACL, you use a wildcard mask to identify the devices or addresses that will be affected by the ACL.
In a subnet mask, the bit pattern has ones separated from zeros with the ones on the left of the number and the zeros on the right. This scenario is more concerned with the network that devices are on and less concerned with the actual hosts on that network. Therefore, the focus on the number is where the ones are, not where the zeros are located. The same is true of the wildcard mask, where you are dealing with the access of hosts to a resource. Because you are now concerned with the hosts, the focus is reversed; therefore, the bits are reversed. In the wildcard mask, you are less concerned with the networks and more concerned with the hosts on that network. Therefore, the wildcard mask still has zeros and ones separated, but now the ones are on the right and the zeros are on the left.
With that said, for a Class C network block, such as 192.168.5.0/24, where you are looking at the subnet mask of 255.255.255.0, for a wildcard mask you would be looking at 0.0.0.255 (which would still focus on the network address and the hosts found on that network block). Table 3-1 shows a breakdown of comparable subnet masks and wildcard masks. Although you use CIDR notation to simplify writing subnet masks (with 255.0.0.0 becoming /8), this notation does not apply to wildcard masks.
Access Control Entries
The Access Control List is made up of a series of entries. Each ACL is numbered, and all entries in the same list are equally numbered. By default, when you add entries to the list, the new entries appear at the bottom. The only exception is the implicit entry at the bottom of every list, which is a deny all. Each Access Control Entry (ACE) has the following structure in your configuration:
access-list <number> <access> <source network or host ID> <wildcard mask>
If you create a single entry ACL permitting all hosts on the Class C network of 192.168.8.0, then the complete ACL would be:
access-list 10 permit 192.168.8.0 0.0.0.255
access-list 10 deny any
In the previous ACL, however, the last line would not actually appear in the ACL. If you used the show command to view this ACL you would actually see:
Switch1>enable
Password:
Switch1#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
Switch1(config)#access-list 50 permit 192.168.8.0 0.0.0.255
Switch1(config)#end
Switch1#show access-list 50
Standard IP access list 50
permit 192.168.8.0, wildcard bits 0.0.0.255
So what happens if you want to add another entry to your list? You would use the same command. The following code shows how to add the 192.168.9.0/24 block to ACL with a permit:
Switch1>enable
Password:
Switch1#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
Switch1(config)#access-list 50 permit 192.168.9.0 0.0.0.255
Switch1(config)#end
Switch1#show access-list 50
Standard IP access list 50
permit 192.168.8.0, wildcard bits 0.0.0.255
permit 192.168.9.0, wildcard bits 0.0.0.255
Modifying ACLs
Notice that each new entry you add to the ACL appears at the bottom of the list, which in this case, does not make a difference. Unlike the routing table, which looks for the closest match in the list when processing an ACL entry that will be used as the first matching entry. If, for instance, you want to have one host on the 192.168.8.0/24 blocked on your ACL, then there would be a difference. You need to add deny for 192.168.8.200 to your ACL:
Switch1>enable
Password:
Switch1#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
Switch1(config)#access-list 50 deny 192.168.8.200 0.0.0.0
Switch1(config)#end
Switch1#show access-list 50
Standard IP access list 50
deny 192.168.8.200
permit 192.168.8.0, wildcard bits 0.0.0.255
permit 192.168.9.0, wildcard bits 0.0.0.255
Notice deny was added to the top of the list, whereas the additional permit was added to the bottom of the list. Additionally, this entry does not include the wildcard bits. The ordering behavior is by design, with any entry for a single host being more important and therefore filtered to the top of the list. The reduction of the ACE for the single host is also expected. You could add the single host this way, instead of writing out all the zeros in the wildcard mask.
Switch1(config)#access-list 50 deny host 192.168.8.200
You can make a new ACL that will deny the same two Class C address blocks, but permit the first four addresses in the 192.168.8.0/24 range (192.168.8.0-192.168.8.3). Here is the result if you build the ACL in this order.
Switch1#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
Switch1(config)#access-list 60 deny 192.168.8.0 0.0.0.255
Switch1(config)#access-list 60 deny 192.168.9.0 0.0.0.255
Switch1(config)#access-list 60 permit 192.168.8.0 0.0.0.3
Switch1(config)#end
Switch1#show access-list 60
Standard IP access list 60
deny 192.168.8.0, wildcard bits 0.0.0.255
deny 192.168.9.0, wildcard bits 0.0.0.255
permit 192.168.8.0, wildcard bits 0.0.0.3
Because the entries are added to the ACL in the order that you type them, the permit ends up at the bottom of the list. If you test this ACL, an address like 192.168.8.2 would be picked up by the first ACE and would not receive the permit from the third ACE. How do you fix this? Well, you have a few choices:
• You can remove the ACL from where it is being used, delete the ACL, create a new one in the correct order, and add it back to where it is being used. This lengthy process actually leaves the system open from the time you remove the ACL from where it is being used, until it is added back. This has been the standard method of managing ACLs. When working with ACLs this way, you would copy all the steps required into notepad.exe. This includes the steps to remove the old ACL and add the new ACL. After the entire process is staged in notepad.exe, use the copy command to copy and paste into your CLI management application, such as putty.exe.
• If your device supports it, you can edit the ACL by using the IP command in the following code. This allows you to put line numbers into your ACL, an option that you do not have when editing the ACL from Global Configuration mode. This makes use of ACL Configuration mode. When putting your line numbers in, you want to leave a gap between the entries in the ACL.
Router1(config)#ip access-list standard 60
Router1(config-ext-nacl)#10 deny 192.168.8.0 0.0.0.255
Router1(config-ext-nacl)#20 deny 192.168.9.0 0.0.0.255
Router1(config-ext-nacl)#30 permit 192.168.8.0 0.0.0.3
With this pre-planning done, you can then add a new ACL entry at the top of the ACL by choosing a number that is less than 10, similar to the following:
Router1>enable
Password:
Router1#configure terminal
Router1(config)# ip access-list standard 60
Router1(config-ext-nacl)#5 permit 192.168.8.0 0.0.0.3
Router1(config-ext-nacl)#end
Router1#show access-list 60
Standard IP access list 60
5 permit 192.168.9.0, wildcard bits 0.0.0.3
10 deny 192.168.9.0, wildcard bits 0.0.0.255
20 deny 192.168.9.0, wildcard bits 0.0.0.255
30 permit 192.168.8.0, wildcard bits 0.0.0.3
This allows you to edit the ACL on the fly (that is, without removing it from the interfaces where it is used) without removing the ACL and recreating it, saving you a lot of time and effort, as long as there is a gap in the numbering where you can add your new entry.
Depending on the IOS version and device, you may have other options. If you look at the Adaptive Security Appliance (ASA), you do not have to preplan. So review the following code, where the ASA automatically numbers the lines for you:
ASAFirewall1>enable
Password:
ASAFirewall1#configure terminal
ASAFirewall1(config)# access-list 60 deny 192.168.8.0 255.255.255.0
ASAFirewall1(config)# access-list 60 deny 192.168.9.0 255.255.255.0
ASAFirewall1(config)# exit
ASAFirewall1# show access-list 60
access-list 60; 2 elements
access-list 60 line 1 standard deny 192.168.8.0 255.255.255.0 (hitcnt=0) 0x318d5521
access-list 60 line 2 standard deny 192.168.9.0 255.255.255.0 (hitcnt=0) 0xba5e90e1
ASAFirewall1#configure terminal
ASAFirewall1(config)# access-list 60 line 1 permit 192.168.9.0 255.255.255.248
ASAFirewall1(config)# exit
ASAFirewall1# show access-list 60
access-list 60; 3 elements
access-list 60 line 1 standard permit 192.168.9.0 255.255.255.248 (hitcnt=0) 0x451bbe48
access-list 60 line 2 standard deny 192.168.8.0 255.255.255.0 (hitcnt=0) 0x318d5521
access-list 60 line 3 standard deny 192.168.9.0 255.255.255.0 (hitcnt=0) 0xba5e90e1
By using the ASA, you can still add lines on the fly or manually number ACL entries. If you want to use the same line again, the ASA will renumber your entire list if it needs to. This is truly the best of both worlds.
Adding remarks
When you look at your running-config to view the ACLs, it can become somewhat confusing because the ACLs will all run together, as shown here:
Switch1#show running-config | include access-list
access-list 50 deny 192.168.8.200
access-list 50 deny 192.168.8.201
access-list 50 permit 192.168.8.0 0.0.0.255
access-list 50 permit 192.168.9.0 0.0.0.255
access-list 60 permit 192.168.8.0 0.0.0.3
access-list 60 deny 192.168.8.0 0.0.0.255
access-list 60 deny 192.168.9.0 0.0.0.255
To make this easier to read, you should start each ACL with a remark line. This does not show up when using the show command; but is in your running-config. This is what it would look like:
Switch1#show running-config | include access-list
access-list 50 deny 192.168.8.200
access-list 50 deny 192.168.8.201
access-list 50 permit 192.168.8.0 0.0.0.255
access-list 50 permit 192.168.9.0 0.0.0.255
access-list 60 remark This ACL is to control the outbound router traffic.
access-list 60 permit 192.168.8.0 0.0.0.3
access-list 60 deny 192.168.8.0 0.0.0.255
access-list 60 deny 192.168.9.0 0.0.0.255
So far, I have shown you how to work the ACLs on a switch or router, but syntactically it is a little different on the ASA. For starters, the ASA does not make use of the wildcard mask, but rather uses the less confusing (unless you are expecting it) subnet mask. In the following code, I paused to get the help information on a switch and on an ASA while adding the access list. Notice in the help information it actually tells me if it wants a subnet mask or a wildcard mask.
Switch1(config)#access-list 50 permit 192.168.8.0 ?
A.B.C.D Wildcard bits
log Log matches against this entry
<cr>
ASAFirewall1(config)# access-list 50 permit 192.168.8.0 ?
configure mode commands/options:
A.B.C.D Netmask for the IP address
Otherwise, the creation and management of the ACLs is the same across most of the Cisco product line.
Extended ACLs
The previous sections describe Standard ACLs, but there is another type, Extended ACLs. Here is a summary of what extended ACLs support:
• Numbered from 100–199 and from 2000–2699 (expanded range)
• Permit or deny based on source or destination IP addresses
• Permit or deny based on protocol, such as ICMP, GRE, TCP, UDP, and so on
In this section, I describe a router that is connected to the 192.168.8.0/24 segment on an internal interface (FastEthernet 0/0) using address 192.168.8.1/24, and to the 10.0.2.0/24 segment on an external interface (FastEthernet 0/1) using address 10.0.2.1/24. In this case, you would manage the 192.168.8.0/24 network and some unknown and untrusted group manages the rest of the network, as shown in Figure 3-1. On this network, you want to allow users to access only web servers outside the network. In order to support this, you need to create two ACLs, 101 and 102.
Figure 3-1: A sample network to implement ACLs.
You use access-list 101 (see Listing 3-1) to manage the traffic leaving the office and access-list 102 (see Listing 3-2) to manage traffic coming from the untrusted network into the office.
Listing 3-1: Creating ACL 101
Router1>enable
Password:
Router1#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
Router1(config)#access-list 101 remark This ACL is to control the outbound router traffic.
Router1(config)#access-list 101 permit tcp 192.168.8.0 0.0.0.255 any eq 80
Router1(config)#access-list 101 permit tcp 192.168.8.0 0.0.0.255 any eq 443
Router1(config)#end
Listing 3-2: Creating ACL 102
Router1>enable
Password:
Router1#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
Router1(config)#access-list 102 remark This ACL is to control the inbound router traffic.
Router1(config)#access-list 102 permit tcp any 192.168.8.0 0.0.0.255 established
Router1(config)#end
If you examine ACL 101 in Listing 3-1, the breakdown on the format of the command is as follows:
• The ACL is number 101
• It permits traffic
• It allows TCP traffic
• The source that it is allowed from is defined by 192.168.8.0 with a wildcard mask of 0.0.0.255
• The destination host is any host
• The TCP traffic that is allowed is on port 80
• The second line is the same, but it allows traffic on TCP port 443
If you do the same examination of the second ACL, ACL 102 in Listing 3-2, you should end up with the following:
• The ACL is number 102
• It permits traffic
• It allows TCP traffic
• The source that it is allowed from is any host
• The destination host is defined by 192.168.8.0 with a wildcard mask of 0.0.0.255
• The TCP traffic that is allowed is any traffic on an established session
The last item on ACL 102 is something to look at a bit more. In Figure 3-2, a client computer on the 192.168.8.0/24 network has created a TCP session with a remote server. This TCP session had a handshaking process that established what ports were going to be used, which was a randomly chosen port on the client and port 80 on the server. The port that is used in the ACE is dependent on the destination address, and in this case, the destination port is a randomly chosen port on the client. Rather than specifying that every possible port is open, which would not be secure, the option is to say that any established session on the client is allowed. Therefore, if the client opens the connection, this ACL will allow the traffic to come back in.
Figure 3-2: Allowing traffic in on established connections.
Applying an ACL
After you create an ACL, it would be good to use it. Your router has two interfaces and each has a direction of traffic travel where you can apply an ACL. In this case, you apply the ACLs only to the outside interface.
Applying an ACL or modifying an ACL on the fly can give you a lot of grief if you do it remotely across the network, even more so if that device is in a locked room a continent away. Schedule a reboot to deal with mistakes or errors. There is nothing more annoying than applying an ACL, only to lose your SSH or Telnet access to the device because you did not include those ports (TCP 22 and 23) in your ACL. So, before you apply the ACL, use a command such as reload in 10 that will cause the router to reboot in 10 minutes. If you lose access to the router in those 10 minutes, you will have it back after the reboot. If you do not make any mistakes or need to reboot, then you can abort the reboot with reload cancel and then save your changes with copy running-config startup-config. Here is a copy of the whole process:
Router1#reload in 10 *ACL Change Recovery*
System configuration has been modified. Save? [yes/no]: yes
Building configuration...
[OK]
Reload scheduled in 10 minutes by console
Reload reason: *ACL Change Recovery*
Proceed with reload? [confirm]
Router1#
*Apr 19 13:46:45.637: %SYS-5-SCHEDULED_RELOAD: Reload requested for 13:56:26 UTC Tue Apr 19 2011 at 13:46:26 UTC Tue Apr 19 2011 by console. Reload Reason: *ACL Change Recovery*.
Router1#reload cancel
Router1#
***
*** --- SHUTDOWN ABORTED ---
***
*Apr 19 13:46:57.557: %SYS-5-SCHEDULED_RELOAD_CANCELLED: Scheduled reload cancelled at 13:46:57 UTC Tue Apr 19 2011
This can sometimes be confusing if you think of out as out of your network. Instead, think of out as out of the network device. Picture the router as a bucket with two hoses for each interface; two hoses carry water into the bucket, and two carry water out of the bucket. If you want to, you can use a stopper (an ACL) to restrict the flow of water into or out of the bucket.
In most cases, you want to apply both of your ACLs to the same interface, and typically to what I call the most hostile interface. Using only one interface will help in your frame of reference, FastEthernet0/1. (I discuss why you use FastEthernet0/1 shortly.)
Router1>enable
Password:
Router1#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
Router1(config)#interface fastEthernet0/1
Router1(config-if)#ip access-group 101 out
Router1(config-if)#ip access-group 102 in
Router1(config-if)#end
If you use an older IOS or a different type of device, you may find that while in Interface Configuration mode that the access-group command is the root command, and not found in the ip command. Do not worry, that is just how it is. So do not be afraid to use access-group 101 out instead of ip access-group 101 out.
You can only apply one ACL, on each interface, in each direction. That is your limitation.
Although I applied the configuration to the outside interface, I could have applied the configuration to different interfaces, in different directions; but that affects what traffic crosses the inside boundaries in the router or network device. The same ACLs could have been applied like this:
Router1>enable
Password:
Router1#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
Router1(config)#interface fastEthernet0/1
Router1(config-if)#ip access-group 101 out
Router1(config-if)#exit
Router1(config)#interface fastEthernet0/0
Router1(config-if)#ip access-group 102 out
In this case, all the traffic crosses the inside boundary in the router. Another example could be blocking ICMP traffic using the example in Figure 3-3. If you block ICMP traffic, you prevent people from pinging addresses in the range. In this case, the range is 192.168.8.0/24. By applying that ACL to the exterior interface (FastEthernet0/1) in the inbound direction, you prevent devices from pinging any addresses in that range, including the address associated with FastEthernet0/0. Interior users can still ping the 192.168.8.1 of the router. Now, if you move that ACL to the interior interface, in the outbound direction, you still prevent that traffic from reaching the hosts on the 192.168.8.0/24 network segment, but you see these side effects:
• Hosts on the network cannot ping the router.
• Hosts outside of the network cannot ping hosts on the network.
• Hosts outside the network can ping the internal address of the router.
Figure 3-3: Applying ACLs to interfaces.
Why is that, you may wonder. Well, the rule now applies to traffic that is leaving the interior interface of the router. The interface of the router that has 192.168.8.1 address associated with it is actually inside the router, and the ACL only applies to traffic that is leaving the router, not to traffic that is inside of the router. Keep this in mind as you decide which interfaces to apply the ACLs to. As I said earlier, typically, it will be applied for In and Out on your hostile interface. (Hostile is a relative term; think of it as more protected/secured interface and less protected/secured interface, with the lesser interface being the hostile interface.)
Using ACLs as a Virus Detection Tool
You can do a few things with your ACLs related to viruses. If you know a virus that has a certain type of traffic, perhaps on TCP port 1090, you can create an ACL that makes use of the log option. This allows information about these packets to be recorded in the system log, which could go to a centralized Syslog server. I tell you more about Syslog servers right after you look at this code example showing you the little change you need to make to your ACEs to enable logging. Simply by adding log to the end of the ACE, any traffic that matches the ACE will be logged.
ASAFirewall1(config)# access-list 103 deny tcp any any eq 1090 ?
configure mode commands/options:
inactive Keyword for disabling an ACL element
log Keyword for enabling log option on this ACL element
time-range Keyword for attaching time-range option to this ACL element
<cr>
Router1(config)#access-list 103 deny tcp any any eq 1090 ?
dscp Match packets with given dscp value
fragments Check non-initial fragments
log Log matches against this entry
log-input Log matches against this entry, including input interface
precedence Match packets with given precedence value
time-range Specify a time-range
tos Match packets with given TOS value
<cr>
Cisco IOS devices have a small log configured on them. When you consider that your router may have as little as 64MB of memory, this does not leave very much space to maintain log information for very long. The alternative to using the router’s memory for logging is to have your log information sent to a server on the network. Syslog is an industry standard format for accepting and storing these log messages. Many Syslog servers are available for different operating systems, including Kiwi Syslog Server for Windows from www.kiwisyslog.com. Kiwi Syslog Server is available as a free version and is often suitable enough for many people. To enable your device to send messages to a Syslog server, use this command on your IOS device (192.168.1.5 is the IP address of my Syslog server):
Router1>enable
Password:
Router1#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
Router1(config)#logging 192.168.1.5
Rather than logging the data, you can view it in real time on the device using the debug command, such as debug ip packet 103 detail, on the device where you expect to see that type of data. The following is debug showing a denied access attempt for a device with the 10.0.2.25 IP address:
Router1>enable
Router1#terminal monitor
Router1#debug ip packet 103 detail
IP packet debugging is on (detailed) for access list 103
Router1#
00:11:55: %SEC-6-IPACCESSLOGP: list 103 denied tcp 10.0.2.25(3541) -> 192.168.8.10(1090), 1 packet
Router1#no debug all
All possible debugging has been turned off
Where You Can Use ACLs
Although the focus of ACLs seems to be about controlling traffic flow, the ACL can be used as a tool in other areas as well. Here is just a short list:
• Control the propagation of routing information: You can use an ACL to manage a distribute list for where your routing table updates will be sent.
• Control debug output: You can use an ACL to permit a type of traffic with the sole intention of using the log option to be able to track when that traffic occurs. (See the previous section for an example.)
• Router management: By implementing an ACL, you can control which devices can access your virtual terminal (vty) connections.
• Encryption management: ACLs can manage which data you want to encrypt between two points or routers, as well as what traffic you want to leave unencrypted or drop.
Setting Up Network Address Translation
You cannot use private address spaces on a network and have those devices communicate with Internet devices without doing some type of translation to convert addresses of one type to addresses of another type. Think about a large company with a large building and many offices. Mail comes to the mailroom and someone in that mailroom has the job of translating addresses from John Smith, Big Company, 123 Some Street, Thistown, Thatstate to Office 212. To translate the address, the mail clerk looks up John Smith’s office address in a table. People outside the company do not need to worry about the fact that John’s office is 212.
Network Address Translation (NAT), as defined in RFC1631, works on a similar principle. All your devices have internal addresses that are used, and you have a pool of external of public addresses that you can use. When an internal device talks to an external device, then a mapping is placed in a table between those two addresses. This mapping can be done manually or automatically. Devices outside of the network will see only the external address, and when they send data back, it is matched on the mapping table and redirected to the correct internal address. The actual device inside the network using that outside address can change over time. For example, you may see 192.168.8.50 using the public address of 192.0.2.100, but tomorrow you may have 192.168.8.58 using the address of 192.0.2.100 and 192.168.8.50 using the address of 192.0.2.101. This would be the same as moving John Smith to office 503 and placing another person in office 212; the mailroom will still deliver the mail to the correct person. Figure 3-4 illustrates NAT.
Figure 3-4: NAT implementation on a simple network.
Requirements for NAT
NAT resolves a few problems for the world at large:
• Shortage of IPv4 addresses: NAT allows everyone to use a functionally unlimited number of addresses inside of their network, while only needing a handful of public addresses; thereby reducing the number of public addresses in use.
• Security: NAT adds a layer of obfuscation to your network by providing different addressing to your public connections.
• Administration: NAT allows you to restrict outside access to only those devices or addresses that you have manually configured, rather than allowing the Internet free access to your network.
Types of NAT
NAT can be configured to work on your network a few different ways. How you choose to implement NAT depends on what your goals are for NAT and your public address management. NAT methods include
• Static NAT: Puts a permanent mapping between an internal private address and a public address. In this scenario, 192.168.8.50 will always map out to 192.0.2.75. This type of NAT may be used for allowing traffic into a mail server or web server.
• Dynamic NAT: Puts a dynamic mapping between an internal private address and a public address. This also creates a one-to-one relationship on a first-come-first-served basis. The public address that is used by private devices can change over time and cannot be trusted. This would allow systems out, when you are not concerned with outside devices trying to connect in, as with the previous web server example.
• Overloading: This is also known as Port Address Translation (PAT). In this case, multiple internal devices are able to share one public address, as mappings are placed into the mappings table based on the source and destination ports that are used. As long as ports are available to be remapped, then any number of devices can share a very small pool of public addresses or just one public address.
• Overlapping: NAT can be used when public or registered addresses are used inside your network. In this case, you may use a public address block on multiple internal networks. NAT allows you to translate those “internal” addresses to other publicly accessible addresses when you connect to the “public” side of the router.
Many people quickly become lost understanding local, global, inside, and outside addresses. The following list describes the different types of addresses:
• Local: This refers to what happens on the inside of your network.
• Global: This refers to what happens on the outside of your network.
• Inside Local Address: This is an address of a host on your internal network, for example, 192.168.8.25.
• Inside Global Address: This is the mapped address that people on the Internet would see, which represents the inside host.
• Outside Global Address: The IP address of a remote Internet-based host as assigned by the owner that can communicate with an inside host, for example, 192.0.2.100.
• Outside Local Address: This is the address that the inside hosts use to reference an outside host. The outside local address may be the outside host’s actual address or another translated private address from a different private address block. Therefore, the router could translate that address to 192.168.10.50, or it could be the public address of the external host. The internal hosts would contact this address to deal with the external host.
The following list summarizes the basic process that NAT follows (see Figure 3-5):
1. An internal host (HostA) sends an IP packet to an external host (HostB).
2. When the packet arrives at the router, the router examines the packet and sees whether the NAT configuration is supposed to apply to it.
3. The source IP address and port are recorded in the mapping table and matched to an external address and port on the router. This may be in the external range of addresses or be the actual router’s address, based on the NAT configuration.
4. The data is sent to HostB referencing the mapped address information as the source of the new IP packet.
5. When HostB sends data back to HostA, HostB references the known source address (192.0.2.100) in the IP packet that it received.
6. When the router receives the IP packet, it examines its mapping table and finds the referenced destination IP address information and the internal it maps to. When the mapping is found in the table, it re-addresses the destination address in the IP packet and sends it onto the new destination.
7. The IP packet arrives at HostA using its internal network address.
Figure 3-5: NAT process in action.
A timer is set when dynamic entries are added to the mapping table. Every time that mapping is used, the timer is reset. If the mapping is not used before the timer expires, then that mapping is removed from the mapping table.
Setting up NAT
NAT is very easy to set up. For these examples, I use the network shown in Figure 3-6.
Figure 3-6: NAT network using two internal segments.
This example sets up NAT on the router, but implements a one-to-one dynamic mapping. This allows dynamic assignment of the actual addresses, but you have the same number of inside and outside addresses so that every device receives an address. Without overloading, this is critical. Here are the commands that you need to issue to configure NAT on the router:
interface FastEthernet 0/0
description Inside Interface
ip address 192.168.8.1 255.255.255.0
ip nat inside
exit
interface FastEthernet 0/1
description Inside Interface
ip address 192.168.9.1 255.255.255.0
ip nat inside
exit
interface FastEthernet 0/2
description Outside Interface
ip address 192.0.2.1 255.255.255.0
ip nat outside
exit
access-list 10 permit 192.168.8.8 0.0.0.7
access-list 10 permit 192.168.9.8 0.0.0.7
!--- Access list only allows hosts 192.168.8.8 to
!--- 192.168.8.15 and 192.168.9.8 to 192.168.9.15
!--- out through NAT.
ip nat pool no-overload 192.0.2.10 192.0.2.25 prefix 24
ip nat inside source list 10 pool no-overload
For this example, say you only have one outside address assigned to you by your ISP. All your traffic must go through this one address. This is the PAT example, as the one address will be translated on a port basis.
interface FastEthernet 0/0
description Inside Interface
ip address 192.168.8.1 255.255.255.0
ip nat inside
exit
interface FastEthernet 0/1
description Inside Interface
ip address 192.168.9.1 255.255.255.0
ip nat inside
exit
interface FastEthernet 0/2
description Outside Interface
ip address 192.0.2.1 255.255.255.252
ip nat outside
exit
access-list 10 permit 192.168.8.8 0.0.0.7
access-list 10 permit 192.168.9.8 0.0.0.7
!--- Access list only allows hosts 192.168.8.8 to
!--- 192.168.8.15 and 192.168.9.8 to 192.168.9.15
!--- out through NAT.
ip nat pool ovrld 192.0.2.1 192.0.2.1 prefix 30
ip nat inside source list 10 pool ovrld
Finally, you have two servers on the inside of the network that have internal addresses of 192.168.8.20 and 192.168.9.20. The first server is used for e-mail and the second server is a web server. The web server has the site running on the less standard TCP port 8080, but you want outside users to use TCP port 80.
interface FastEthernet 0/0
description Inside Interface
ip address 192.168.8.1 255.255.255.0
ip nat inside
exit
interface FastEthernet 0/1
description Inside Interface
ip address 192.168.9.1 255.255.255.0
ip nat inside
exit
interface FastEthernet 0/2
description Outside Interface
ip address 192.0.2.1 255.255.255.252
ip nat outside
exit
access-list 10 permit 192.168.8.8 0.0.0.7
access-list 10 permit 192.168.9.8 0.0.0.7
!--- Access list only allows hosts 192.168.8.8 to
!--- 192.168.8.15 and 192.168.9.8 to 192.168.9.15
!--- out through NAT.
ip nat pool ovrld 192.0.2.1 192.0.2.1 prefix 30
ip nat inside source list 10 pool ovrld
ip nat inside source static tcp 192.168.9.20 8080 192.0.2.2 80
!--- This uses the second available address on external
!--- interface, while it could have used the configured
!--- address on FastEthernet0/2. It could have also been
!--- configured for the Interface address using this command.
ip nat inside source static tcp 192.168.8.20 25 interface FastEthernet0/2
Use your ports when you create static mappings to allow inside resources to publish out through the external interface of your router or firewall. Avoid using commands such as ip nat inside source static 192.168.1.50 192.0.2.50, which effectively places your entire host 192.168.1.50 outside of your router or firewall. This is much more exposure than you need for that host.
Making use of the interface command is useful when your ISP assigns your outside address through either DHCP or PPPoE dynamically. The interface command allows your configuration to use whatever address happens to be assigned to your router or firewall.
Using the later scenario, if you are required to change the IP address of the web server (perhaps moving from the 192.168.9.0/24 network to the 192.168.8.0/24 network, or changing the port number back to the standard port 80), then these changes can be made at the router with no impact to users outside of the network. The DNS entry pointing to the outside address will remain the same and their lives will continue as normal. Often, people are amazed by how easy managing this exterior/interior mapping of their network is.
Viewing translations
If you want to see the IP NAT mappings or translations, you can use the show and debug commands. Table 3-2 summarizes some of the commands that give you information about the translations running on your Cisco device.
