CISCO VPN CLIENT CONFIGURATION - SETUP FOR IOS ROUTER

Remote VPN access is an extremely popular service amongst Cisco routers and ASA Firewalls. The flexibility of having remote access to our corporate network and its resources literally from anywhere in the world, has proven extremely useful and in many cases irreplaceable. All that is required is fast Internet connection and your user credentials to log in – all the rest are taken care by your Cisco router or firewall appliance.

To initiate the connection, we use the Cisco VPN client, available for Windows operating systems (XP, Vista, Windows 7 - 32 & 64bit), Linux, Mac OS X10.4 & 10.5 and Solaris UltraSPARC (32 & 64bit), making it widely available for most users around the globe. Cisco VPN Clients are available for download from our Cisco Downloads section.

The Cisco VPN also introduces the concept of ‘Split Tunneling'. Split tunneling is a feature that allows a remote VPN client access the company's LAN, but at the same time surf the Internet. In this setup, only traffic destined to the company's LAN is sent through the VPN tunnel (encrypted) while all other traffic (Internet) is routed normally as it would if the user was not connected to the company VPN.

Some companies have a strict policy that does not allow the remote VPN client access the Internet while connected to the company network (split tunneling disabled) while others allow restricted access to the Internet via the VPN tunnel (rare)! In this case, all traffic is tunnelled through the VPN and there's usually a web proxy that will provide the remote client restricted Internet access.

From all the above, split tunneling is the most common configuration of Cisco VPN configuration today, however for educational purposes, we will be covering all methods.

Setting up a Cisco router to accept remote Cisco VPN clients is not an extremely difficult task. Following each step shown in this article will guarantee it will work flawlessly.

Below is a typical diagram of a company network providing VPN access to remote users in order to access the company's network resources.

The VPN established is an IPSec secure tunnel and all traffic is encrypted using the configured encryption algorithm:

Engineers and administrators who need to restrict VPN user access to Layer-4 services e.g www, smtp, pop on a specific internal host (e.g web/email server) should read our How to Restrict Cisco IOS Router VPN Client to Layer-4 (TCP, UDP) Services - Applying IP, TCP & UDP Access Lists article.

The Cisco IPSec VPN has two levels of protection as far as credentials concern. The remote client must have valid group authentication credential, followed by valid user credential.

The group credentials are entered once and stored in the VPN connection entry, however the user credentials are not stored and requested every time a connection is established:

We should note that configuring your router to support Point-to-Point Tunnel Protocol VPN (PPTP) is an alternative method and covered on our Cisco PPTP Router Configuration article, however PPTP VPN is an older, less secure and less flexible solution. We highly recommend using Cisco IPSec VPN only.

In order to configure Cisco IPSec VPN client support, the router must be running at least the 'Advanced Security' IOS otherwise most of the commands that follow will not be available at the CLI prompt!

To begin, we need to enable the router's 'aaa model' which stands for 'Authentication, Authorisation and Accounting'. AAA provides a method for identifying users who are logged in to a router and have access to servers or other resources.

AAA also identifies the level of access that has been granted to each user and monitors user activity to produce accounting information.

We enable the 'aaa new-model' service followed by X-Auth for user authentication and then group authentication (network vpn_group_ml_1):

R1# configure terminal
R1(config)# aaa new-model
R1(config)# aaa authentication login default local
R1(config)# aaa authentication login vpn_xauth_ml_1 local
R1(config)# aaa authentication login sslvpn local
R1(config)# aaa authorization network vpn_group_ml_1 local
R1(config)# aaa session-id common

When trying to establish an IPSec tunnel, there are two main phase negotiations where the remote client negotiates the security policies and encryption method with the Cisco VPN router.

Now we create the user accounts that will be provided to our remote users. Each time they try to connect to our VPN, they will be required to enter this information:

R1(config)# username adminitrator secret $cisco$firewall
R1(config)# username firewallcx secret $fir3w@ll!

We next create an Internet Security Association and Key Management Protocol (ISAKMP) policy for Phase 1 negotiations. In this example, we've create two ISAKMP policies, and configure the encryption (encr), authentication method, hash algorithm and set the Diffie-Hellman group:

R1(config)# crypto isakmp policy 1
R1(config-isakmp)# encr 3des
R1(config-isakmp)# authentication pre-share
R1(config-isakmp)# group 2
R1(config-isakmp)#
R1(config-isakmp)#crypto isakmp policy 2
R1(config-isakmp)# encr 3des
R1(config-isakmp)# hash md5
R1(config-isakmp)# authentication pre-share
R1(config-isakmp)# group 2
R1(config-isakmp)# exit

We now create a group and configure the DNS server and other parameters as required. These parameters are passed down to the client as soon as it successfully authenticates to the group:

R1(config)# crypto isakmp client configuration group CCLIENT-VPN
R1(config-isakmp-group)# key firewall.cx 
R1(config-isakmp-group)# dns 10.0.0.10
R1(config-isakmp-group)# pool VPN-Pool
R1(config-isakmp-group)# acl 120
R1(config-isakmp-group)# max-users 5
R1(config-isakmp-group)# exit
R1(config)# ip local pool VPN-Pool 192.168.0.20 192.168.0.25

The above configuration is for the 'CCLIENT-VPN' group with a pre-share key (authentication method configured previously) of 'firewall.cx'. Users authenticating to this group will have their DNS set to 10.0.0.10. A maximum of 5 users are allowed to connect simultaneously to this group and will have access to the resources governed by access-list 120.

Lastly, users authenticating to this group will obtain their IP address from the pool named 'VPN-Pool' that provides the range of IP address: 192.168.0.20 up to 192.168.0.25.

Creation of the Phase 2 Policy is next. This is for actual data encryption & IPSec phase 2 authentication:

R1(config)# crypto ipsec transform-set encrypt-method-1 esp-3des esp-sha-hmac 
R1(cfg-crypto-trans)#

The transformation named 'encrypto-method-1' is then applied to an IPSec profile named 'VPN-Profile-1':

R1(config)# crypto ipsec profile VPN-Profile-1
R1(ipsec-profile)# set transform-set encrypt-method-1

Note the encryption and authentication method of our IPSec crypto tunnel as shown by a connected VPN client to the router with the above configuration:

Now its time to start binding all the above together by creating a virtual-template interface that will act as a 'virtual interface' for our incoming VPN clients. Remote VPN clients will obtain an IP address that is part of our internal network (see diagram above - 192.168.0.x/24) so we therefore do not require this virtual interface to have an ip address and configure it as an 'ip unnumbered' interface on our router's LAN interface.

Setting an interface as an ip unnumbered enables IP processing through it without assigning an explicit IP address, however you must bind it to a physical interface that does have an IP address configured, usually your LAN interface:

R1(config)# interface Virtual-Template2 type tunnel
R1(config-if)# ip unnumbered FastEthernet0/0
R1(config-if)# tunnel mode ipsec ipv4
R1(config-if)# tunnel protection ipsec profile VPN-Profile-1

Above, our virtual template also inherits our configured encryption method via the 'ipsec profile VPN-Profile-1' command which sets the transform method to 'encrypt-method-1' (check previous configuration block) which in turn equals to 'esp-3des esp-sha-hmac'.

Notice how Cisco's CLI configuration follows a logical structure. You configure specific parameters which are then used in other sections of the configuration. If this logic is understood by the engineer, then decoding any given Cisco configuration becomes an easy task.

So far we've enabled the authentication mechanisms (aaa), created an ISAKMP policy, created the VPN group and set its parameters, configured the encryption method (transform-set) and binded it to the virtual template the remote VPN user will connect to.

Second-last step is to create one last ISAKMP profile to connect the VPN group with the virtual template:

R1(config)# crypto isakmp profile vpn-ike-profile-1
R1(conf-isa-prof)# match identity group CCLIENT-VPN
R1(conf-isa-prof)# client authentication list vpn_xauth_ml_1
R1(conf-isa-prof)# isakmp authorization list vpn_group_ml_1
R1(conf-isa-prof)# client configuration address respond
R1(conf-isa-prof)# virtual-template 2

Last step is the creation of our access lists that will control the VPN traffic to be tunnelled, effectively controlling what our VPN users are able to access remotely.

Once that's done, we need to add a 'no NAT' statement so that traffic exiting the router and heading toward the VPN user is preserved with its private IP address, otherwise packets sent through the tunnel by the router, will be NAT'ed and therefore rejected by the remote VPN Client.

When NAT is enabled through a VPN tunnel, the remote user sees the tunnelled traffic coming from the router's public IP address, when in fact it should be from the router's private IP address.

We assume the following standard NAT configuration to provide Internet access to the company's LAN network:

R1#show running-config
<output omitted>
ip nat inside source list 100 interface Dialer1 overload
access-list 100 remark -=[Internet NAT Service]=-
access-list 100 permit ip 192.168.0.0 0.0.0.255 any
access-list 100 remark

Based on the above, we proceed with our configuration. First, we need to restrict access to our remote VPN users, so that they only access our SQL server with IP address 192.168.0.6 (access-list 120), then we deny NAT (access-list 100) to our remote VPN Pool IP range:

R1(config)# access-list 120 remark ==[Cisco VPN Users]==
R1(config)# access-list 120 permit ip host 192.168.0.6 host 192.168.0.20
R1(config)# access-list 120 permit ip host 192.168.0.6 host 192.168.0.21
R1(config)# access-list 120 permit ip host 192.168.0.6 host 192.168.0.22
R1(config)# access-list 120 permit ip host 192.168.0.6 host 192.168.0.23
R1(config)# access-list 120 permit ip host 192.168.0.6 host 192.168.0.24
R1(config)# access-list 120 permit ip host 192.168.0.6 host 192.168.0.25

R1(config)# no access-list 100 
R1(config)# access-list 100 remark [Deny NAT for VPN Clients]=-
R1(config)# access-list 100 deny ip 192.168.0.0 0.0.0.255 host 192.168.0.20 
R1(config)# access-list 100 deny ip 192.168.0.0 0.0.0.255 host 192.168.0.21
R1(config)# access-list 100 deny ip 192.168.0.0 0.0.0.255 host 192.168.0.22
R1(config)# access-list 100 deny ip 192.168.0.0 0.0.0.255 host 192.168.0.23
R1(config)# access-list 100 deny ip 192.168.0.0 0.0.0.255 host 192.168.0.24
R1(config)# access-list 100 deny ip 192.168.0.0 0.0.0.255 host 192.168.0.25
R1(config)# access-list 100 remark
R1(config)# access-list 100 remark -=[Internet NAT Service]=-
R1(config)# access-list 100 permit ip 192.168.0.0 0.0.0.255 any

Note that for access-list 100, we could either 'deny ip host 192.168.0.6' to our remote clients, or as shown, deny the 192.168.0.0/24 network. What's the difference? Practically none. Denying your whole network the NAT service toward your remote clients, will make it easier for any future additions.

If for example there was a need to deny NAT for another 5 servers so they can reach remote VPN clients, then the access-list 100 would need to be edited to include these new hosts, where as now it's already taken care of. Remember, with access-list 100 we are simply controlling the NAT function , not the access the remote clients have (done with access-list 120 in our example.

At this point, the Cisco VPN configuration is complete and fully functional.

SPLIT TUNNELING

We mentioned in the beginning of this article that we would cover split tunneling and full tunneling methods for our VPN clients. You'll be pleased to know that this functionality is solely determined by the group's access-lists, which our case is access-list 120.

If we wanted to tunnel all traffic from the VPN client to our network, we would use the following access-list 120 configuration:

R1(config)# access-list 120 remark ==[Cisco VPN Users]==R1(config)# access-list 120 permit ip any host 192.168.0.20R1(config)# access-list 120 permit ip any host 192.168.0.21R1(config)# access-list 120 permit ip any host 192.168.0.22R1(config)# access-list 120 permit ip any host 192.168.0.23R1(config)# access-list 120 permit ip any host 192.168.0.24R1(config)# access-list 120 permit ip any host 192.168.0.25

In another example, if we wanted to provide our VPN clients access to networks 10.0.0.0/24, 10.10.10.0/24 & 192.168.0.0/24, here's what the access-list 120 would look like (this scenario requires modification of NAT access-list 100 as well):

R1(config)# access-list 120 remark ==[Cisco VPN Users]==R1(config)# access-list 120 permit ip 10.0.0.0 0.0.0.255 host 192.168.0.20R1(config)# access-list 120 permit ip 10.0.0.0 0.0.0.255 host 192.168.0.21R1(config)# access-list 120 permit ip 10.0.0.0 0.0.0.255 host 192.168.0.22R1(config)# access-list 120 permit ip 10.0.0.0 0.0.0.255 host 192.168.0.23R1(config)# access-list 120 permit ip 10.0.0.0 0.0.0.255 host 192.168.0.24R1(config)# access-list 120 permit ip 10.0.0.0 0.0.0.255 host 192.168.0.25R1(config)#
R1(config)# access-list 120 permit ip 10.10.10.0 0.0.0.255 host 192.168.0.20R1(config)# access-list 120 permit ip 10.10.10.0 0.0.0.255 host 192.168.0.21R1(config)# access-list 120 permit ip 10.10.10.0 0.0.0.255 host 192.168.0.22R1(config)# access-list 120 permit ip 10.10.10.0 0.0.0.255 host 192.168.0.23R1(config)# access-list 120 permit ip 10.10.10.0 0.0.0.255 host 192.168.0.24R1(config)# access-list 120 permit ip 10.10.10.0 0.0.0.255 host 192.168.0.25R1(config)#
R1(config)#
R1(config)# access-list 120 permit ip 192.168.0.0 0.0.0.255 host 192.168.0.20R1(config)# access-list 120 permit ip 192.168.0.0 0.0.0.255 host 192.168.0.21R1(config)# access-list 120 permit ip 192.168.0.0 0.0.0.255 host 192.168.0.22R1(config)# access-list 120 permit ip 192.168.0.0 0.0.0.255 host 192.168.0.23R1(config)# access-list 120 permit ip 192.168.0.0 0.0.0.255 host 192.168.0.24R1(config)# access-list 120 permit ip 192.168.0.0 0.0.0.255 host 192.168.0.25R1(config)#
R1(config)#
R1(config)# no access-list 100 R1(config)# access-list 100 remark [Deny NAT for VPN Clients]=-R1(config)# access-list 100 deny ip 10.0.0.0 0.0.0.255 host 192.168.0.20 R1(config)# access-list 100 deny ip 10.0.0.0 0.0.0.255 host 192.168.0.21R1(config)# access-list 100 deny ip 10.0.0.0 0.0.0.255 host 192.168.0.22R1(config)# access-list 100 deny ip 10.0.0.0 0.0.0.255 host 192.168.0.23R1(config)# access-list 100 deny ip 10.0.0.0 0.0.0.255 host 192.168.0.24R1(config)# access-list 100 deny ip 10.0.0.0 0.0.0.255 host 192.168.0.25R1(config)#
R1(config)#
R1(config)# access-list 100 deny ip 10.10.10.0 0.0.0.255 host 192.168.0.20 R1(config)# access-list 100 deny ip 10.10.10.0 0.0.0.255 host 192.168.0.21R1(config)# access-list 100 deny ip 10.10.10.0 0.0.0.255 host 192.168.0.22R1(config)# access-list 100 deny ip 10.10.10.0 0.0.0.255 host 192.168.0.23R1(config)# access-list 100 deny ip 10.10.10.0 0.0.0.255 host 192.168.0.24R1(config)# access-list 100 deny ip 10.10.10.0 0.0.0.255 host 192.168.0.25R1(config)#
R1(config)#
R1(config)# access-list 100 deny ip 192.168.0.0 0.0.0.255 host 192.168.0.20 R1(config)# access-list 100 deny ip 192.168.0.0 0.0.0.255 host 192.168.0.21R1(config)# access-list 100 deny ip 192.168.0.0 0.0.0.255 host 192.168.0.22R1(config)# access-list 100 deny ip 192.168.0.0 0.0.0.255 host 192.168.0.23R1(config)# access-list 100 deny ip 192.168.0.0 0.0.0.255 host 192.168.0.24R1(config)# access-list 100 deny ip 192.168.0.0 0.0.0.255 host 192.168.0.25R1(config)# access-list 100 remarkR1(config)# access-list 100 remark -=[Internet NAT Service]=- R1(config)# access-list 100 permit ip 10.0.0.0 0.0.0.255 anyR1(config)# access-list 100 permit ip 10.10.10.0 0.0.0.255 anyR1(config)# access-list 100 permit ip 192.168.0.0 0.0.0.255 any

When the VPN client connects, should we go to the connection's statistics, we would see the 3 networks under the secure routes, indicating all traffic toward these networks is tunnelled through the VPN:

 

CISCO VPN CONFIGURATION TIPS

Engineers and administrators who need to restrict VPN user access to Layer-4 services e.g www, smtp, pop on a specific internal host (e.g web/email server) should read our How to Restrict Cisco IOS Router VPN Client to Layer-4 (TCP, UDP) Services - Applying IP, TCP & UDP Access Lists article.

It is evident from our last example with the tunneling of our 3 networks, that should our VPN IP address pool be larger, for example 50 IP addresses, then we would have to enter 50 IPs x 3 Networks = 150 lines of code just for the access-list 120, plus another 150 lines for access-list 100 (no NAT)! That is quite a task indeed!

To help cut down the configuration to just a couple of lines, this is the alternative code that would be used and have the same effect:

Mark VPN Traffic to be tunnelled:

R1(config)# access-list 120 remark ==[Cisco VPN Users]==R1(config)# access-list 120 permit ip 10.0.0.0 0.0.0.255 192.168.0.0 0.0.0.255R1(config)# access-list 120 permit ip 10.10.10.0 0.0.0.255 192.168.0.0 0.0.0.255R1(config)# access-list 120 permit ip 192.168.0.0 0.0.0.255 192.168.0.0 0.0.0.255

Do not NAT any traffic from our LANs toward VPN clients, but NAT everything else destined to the Internet:

R1(config)# access-list 100 remark [Deny NAT for VPN Clients]=-R1(config)# access-list 100 deny ip 10.0.0.0 0.0.0.255 192.168.0.0 0.0.0.255 R1(config)# access-list 100 deny ip 10.10.10.0 0.0.0.255 192.168.0.0 0.0.0.255R1(config)# access-list 100 deny ip 192.168.0.0 0.0.0.255 192.168.0.0 0.0.0.255 R1(config)# access-list 100 remarkR1(config)# access-list 100 remark -=[Internet NAT Service]=- R1(config)# access-list 100 permit ip 10.0.0.0 0.0.0.255 anyR1(config)# access-list 100 permit ip 10.10.10.0 0.0.0.255 anyR1(config)# access-list 100 permit ip 192.168.0.0 0.0.0.255 any 

The access-list 120 tells the router to tunnel all traffic from the three networks to our VPN clients who's IP address will be in the 192.168.0.0/24 range!

So, if the VPN client received from the VPN Pool, IP address 192.168.0.23 or 192.168.0.49, it really wouldn't matter as the '192.168.0.0 0.0.0.255' statement at the end of each access-list 120 covers both 192.168.0.23 & 192.168.0.49. Even replacing the '192.168.0.0 0.0.0.255' with the 'any' statement would have the same effect.

For 'access-list 100' that controls the NAT service, we cannot use the 'any' statement at the end of the DENY portion of the ACLs, because it would exclude NAT for all networks (public and private) therefore completely disabling NAT and as a result, Internet access.

As a last note, if it was required the VPN clients to be provided with an IP address range different from that of the internal network (e.g 192.168.50.0/24), then the following minor changes to the configuration would have to be made:

R1(config)# crypto isakmp client configuration group CCLIENT-VPN
R1(config-isakmp-group)# key firewall.cx 
R1(config-isakmp-group)# dns 10.0.0.10
R1(config-isakmp-group)# pool VPN-Pool
R1(config-isakmp-group)# acl 120
R1(config-isakmp-group)# max-users 5
R1(config-isakmp-group)# exit
R1(config)#
R1(config)# ip local pool VPN-Pool 192.168.50.10 192.168.50.25R1(config)#
R1(config)# interface Virtual-Template2 type tunnelR1(config-if)# ip address 192.168.50.1 255.255.255.0 R1(config-if)# tunnel mode ipsec ipv4R1(config-if)# tunnel protection ipsec profile VPN-Profile-1

Assuming 3 internal networks

Mark VPN Traffic to be tunnelled:

R1(config)# access-list 120 remark ==[Cisco VPN Users]==R1(config)# access-list 120 permit ip 10.0.0.0 0.0.0.255 192.168.50.0 0.0.0.255R1(config)# access-list 120 permit ip 10.10.10.0 0.0.0.255 192.168.50.0 0.0.0.255R1(config)# access-list 120 permit ip 192.168.0.0 0.0.0.255 192.168.50.0 0.0.0.255

Do not NAT any traffic from our LANs toward VPN clients, but NAT everything else destined to the Internet:

R1(config)# access-list 100 remark [Deny NAT for VPN Clients]=-R1(config)# access-list 100 deny ip 10.0.0.0 0.0.0.255 192.168.50.0 0.0.0.255 R1(config)# access-list 100 deny ip 10.10.10.0 0.0.0.255 192.168.50.0 0.0.0.255R1(config)# access-list 100 deny ip 192.168.0.0 0.0.0.255 192.168.50.0 0.0.0.255 R1(config)# access-list 100 remarkR1(config)# access-list 100 remark -=[Internet NAT Service]=- R1(config)# access-list 100 permit ip 10.0.0.0 0.0.0.255 anyR1(config)# access-list 100 permit ip 10.10.10.0 0.0.0.255 anyR1(config)# access-list 100 permit ip 192.168.0.0 0.0.0.255 any 

 

INSTALLING SECURITY DEVICE MANAGER (SDM) ON A CISCO ROUTER

 Cisco has been developing its Security Device Manager (SDM) software. This web-based software is designed to help the less experienced users and administrators to work and configure various services and functions of a Cisco router.

There are two different editions of SDM, the full SDM package and the SDM Express package.

The full SDM package contains a number of modules and options for your router's configuration, while the Express package is essentially a cut-down version containing the core modules. You should note that you'll need Java Runtime 1.5 installed on your workstation in order for SDM to function. To obtain the necessary Java Runtime click here.

The full SDM can be found on the CD that came with your router but is also downloadable via Cisco's website. The SDM Express package usually comes preinstalled on your router's flash memory.

If you would like to download the latest available Cisco SDM, you can conveniently find it in our Cisco Tools & Application Download Section or alternatively go to Cisco's website, log in to your CCO account and download from there. If you don't have a CCO account, you can register one for free and proceed to the following location http://www.cisco.com/cgi-bin/tablebuild.pl/sdm as shown below:

Once you log in, you'll be presented with the download table from where you can select the latest version:

Once you select and download the appropriate zip file (SDM-V25.zip in our example) you'll be able to unzip it and start your installation, however, to ensure your installation succeds, you must telnet into your router or use the console port to log in via CLI, create a username & password, and enable HTTP authentication:

R1# configure terminal 
R1(config)# username firewall.cx privilege 15 password ciscorocks 
R1(config)# ip http authentication local
R1(config)# exit
R1# copy running-config startup-config
Destination filename [startup-config]? (hit enter) 
Building configuration...
[OK]
R1#

Now start your installation. During the installation you'll be prompted to select if you'd like to install Cisco SDM on your computer, router or both. Select your router:

In the next screen, you'll be asked for your router's details (IP Address, username, password) in order to have the SDM software installed on it:

Once you provide all necessary information, you'll get the progress bar indicating the connection towards your router:

Next is the section where you can select a 'Typical' installation or 'Custom'. Select 'Typical' as it will automatically choose the appropriate settings and packages for your router:

As you can see, SDM v2.5 requires approximately 8.9MB of flash space. Hit 'Next' and your installation begins:

This process will take a couple of minutes as all files are transferred to your router's Flash and final configuration changes are made. Once complete, you'll be given the option to start SDM. If you choose to do so, you'll be redirected to your web browser and asked for the appropriate credentials.

You'll have to make sure you've disabled any pop-up blockers otherwise you won't be able to see the necessary windows that will try to 'pop-up'. After a minute or so you should see the first screen of SDM collecting information on your router:

Once this step is over, you'll get your first real-time overview of your router. From here you can configure or monitor any aspect of your Cisco router. The SDM software is constantly being updated with new features, bringing it closer to the flexibility and power of the IOS command line - however, it does still have a long way to go :)

The following screenshot is from the 'Monitor' tab, which can provide a wealth of information regarding the router's status and is extremely useful even for the most experienced:

CONFIGURING DYNAMIC NAT ON A CISCO ROUTER

NAT (Network Address Translation) is a method that allows the translation (modification) of IP addresses while packets/datagrams are traversing the network. Dynamic NAT enables multiple internal hosts access to the Internet by assigning each host a unique real (Public) IP address for the duration of the session.

Once the internal host stops sending and receiving packets from the Internet, the router's NAT timeout will clear the Dynamic NAT entry from its NAT table, making the real IP address available to the next internal host.

The following steps explain basic Cisco router Dynamic NAT configuration. If you would like to read more on the NAT theory, be sure to read our popular NAT articles, which explain in great depth the NAT functions and applications in today's networks. Lastly, if you're only interested in Dynamic NAT, you can simply follow this link and read up on our theoretical example covered on Firewall.cx.

EXAMPLE SCENARIO

The diagram below represents our example network, which consists of a number of internal clients trying to access the Internet via our router. The router is connected to the ISP via its serial interface. The company has been assigned the following Class C subnet: 200.2.2.0/29 (255.255.255.248). This translates to the following usable Public IP addresses: 200.2.2.1 - 200.2.2.6.

As one would expect, we need to sacrifice two IP addresses: one for the router's serial interface and one for the ISP's router. This leaves us with the following pool of usable Public IP addresses: 200.2.2.2 - 200.2.2.5.

The goal here is to configure the router to dynamically allocate the pool of Public IP addresses to our internal network.

CONFIGURE DYNAMIC NAT

Dynamic NAT configuration is a pretty straightforward process and is almost identical to other types of NAT configurations. The first step in any NAT configuration is to define the inside and outside interfaces. It is imperative that we define these interfaces for the Dynamic NAT service to function.

Set the fast ethernet 0/0 interface as the inside interface:

R1# configure terminal
R1(config)# interface fastethernet0/0R1(config-if)# ip nat inside

Next step is to set the serial interface S0/0 as the outside interface:

R1(config-if)# interface serial0/0R1(config-if)# ip nat outside 
R1(config-if)# exit

Next step is to create our pool of Public IP addresses that will be handed out by the router to our internal hosts trying to connect to the Internet. Each time a host sends a packet destined for the Internet, the router will automatically allocate one of the Public IP addresses for the length of that session.

When the session is over, the NAT entry will timeout and the Public IP address is released, making it available once again to the Dynamic NAT pool. Let us define the NAT Pool:

R1(config)# ip nat pool Public-IPS 200.2.2.2 200.2.2.5 prefix-length 29

We now need to create an Access Control List (ACL) that will include local (private) hosts or network(s), depending on how large the internal network is.

This ACL will be applied to the NAT pool named 'Public-IPS', effectively controlling the hosts that will be assigned a Public IP address and therefore able to access the Internet.

You can use standard or extended access lists depending on your requirements:

R1(config)# ip nat inside source list 100 pool Public-IPS 
R1(config)# access-list 100 remark == [Control NAT Pool Service]==
R1(config)# access-list 100 permit ip 192.168.0.0 0.0.0.255 any

The above command instructs the router to allow the 192.168.0.0/24 network to use the NAT Pool and provide each host with a unique Dynamic Public IP address. Note that Cisco router standard and extended ACLs always use wildcards (0.0.0.255).

VERIFYING DYNAMIC NAT OPERATION

By viewing the Dynamic NAT table you can easily verify that the internal hosts are correctly being assigned a Dynamic IP address from the configured pool:

R1# show ip nat translations
Pro    Inside global         Inside local        Outside local         Outside global
---      200.2.2.2               192.168.0.6          ---                         ---
---      200.2.2.3               192.168.0.8          ---                         ---

 As shown, two internal hosts (192.168.0.6 & 192.168.0.8) have each been assigned an external IP address from the pool we previously created.

These translations will eventually timeout if no activity is present from the internal hosts, however, if you need to forcibly clear them this can be easily done by entering the following command:

R1# clear ip nat translation *

CONFIGURING NAT OVERLOAD ON A CISCO ROUTER

NAT (Network Address Translation) is a method that allows the translation (modification) of IP addresses while packets/datagrams are traversing the network. NAT Overload, also known as PAT (Port Address Translation) is essentially NAT with the added feature of TCP/UDP ports translation.

The main purpose of NAT is to hide the IP address (usually private) of a client in order to reserve the public address space. For example a complete network with 100 hosts can have 100 private IP addresses and still be visible to the outside world (internet) as a single IP address. Other benefits of NAT include security and economical usage of the IP address ranges at hand.

The following steps explain basic Cisco router NAT Overload configuration. NAT overload is the most common operation in most businesses around the world, as it enables the whole network to access the Internet using one single real IP address. If you would like to know more about the NAT theory, be sure to read our popular NAT articles, which explain in great depth the NAT functions and applications in today's networks.

 

EXAMPLE SCENARIO

The diagram below represents our example network which consists of a number of internal clients and a router connected to our ISP via its serial interface. The company has been assigned the following Class C subnet: 200.2.2.0/30 (255.255.255.252).

This translates to one usable real IP address - 200.2.2.1 - configured on our router's serial interface. IP address 200.2.2.2 will be used on the other end, that is, the ISP's router. Our ISP has also provided us with the necessary default gateway IP address (configured on our router - not shown) in order to route all traffic to the Internet.

Our goal in this example is to configure NAT Overload (PAT) and provide all internal workstations with Internet access using one public IP address (200.2.2.1).

CONFIGURE NAT OVERLOAD - PAT (PORT ADDRESS TRANSLATION)

'Overloading' means that the single public IP assigned to your router can be used by multiple internal hosts concurrently. This is done by translating source UDP/TCP ports in the packets and keeping track of them within the translation table kept in the router (R1 in our case). This is a typical NAT configuration for almost all of today's networks.

In addition, NAT Overload (PAT) is covered in great depth on Firewall.cx. Those interested can visit our NAT Overload (PAT) article.

The first step in any NAT configuration is to define the inside and outside interfaces. It is imperative that we define the these interfaces for NAT overload to function.

Set the fast ethernet 0/0 interface as the inside interface:R1# configure terminal
R1(config)# interface fastethernet0/0
R1(config-if)# ip nat inside
Next step is to set the serial interface S0/0 as the outside interface:

R1(config-if)# interface serial0/0R1(config-if)# ip nat outside 
R1(config-if)# exit

We now need to create an Access Control List (ACL) that will include local (private) hosts or network(s). This ACL will later on be applied to the NAT service command, effectively controlling the hosts that will be able to access the Internet. You can use standard or extended access lists depending on your requirements:

R1(config)# access-list 100 remark == [Control NAT Service]==
R1(config)# access-list 100 permit ip 192.168.0.0 0.0.0.255 any

The above command instructs the router to allow the 192.168.0.0/24 network to reach any destination. Note that Cisco router standard and extended ACLs always use wildcards (0.0.0.255).

All that's left now is to enable NAT overload and bind it to the outside interface previously selected:

R1(config)# ip nat inside source list 100 interface serial 0/0 overload

From this point onward, the router will happily create all the necessary translations to allow the 192.168.0.0/24 network access to the Internet.

VERIFYING NAT OVERLOAD OPERATION

Viewing the NAT translation table can sometimes reveal a lot of important information on your network's activity. Here you'll be able to identify traffic that's not supposed to be routed to the Internet or traffic that seems suspicious.

As packets start traversing the router it will gradually build up its NAT/PAT translation table as shown below:

R1# show ip nat translations
Pro Inside global           Inside local            Outside local         Outside global

udp 200.2.2.1:53427  192.168.0.6:53427      74.200.84.4:53        74.200.84.4:53

udp 200.2.2.1:53427  192.168.0.6:53427      195.170.0.1:53        195.170.0.1:53

tcp 200.2.2.1:53638   192.168.0.6:53638      64.233.189.99:80    64.233.189.99:80

tcp 200.2.2.1:57585   192.168.0.7:57585      69.65.106.48:110    69.65.106.48:110

tcp 200.2.2.1:57586   192.168.0.7:57586      69.65.106.48:110    69.65.106.48:110

As shown, the first 2 translations directed to 74.200.84.4 & 195.170.0.1 are DNS requests from internal host 192.168.0.6. The third entry seems to be an http request to a web server with IP address 64.233.189.99.

Looking at the fourth and fifth translation entry, you should identify them as pop3 requests to an external server, possibly generated by an email client.

Because these entries are all dynamically created, they are temporary and will be removed from the translation table after some time.

Another point you might want to keep in mind is that when we use programs that create a lot of connections e.g Utorrent, Limewire, etc., you might see sluggish performance from the router as it tries to keep up with all connections. Having thousands of connections running through the router can put some serious stress on the CPU.

In these cases, we might need to clear the IP NAT table completely to free up resources.
This is easily done using the following command:

R1# clear ip nat translation * 
Assuming no request has been sent right after the command was entered, the NAT translation table should be empty:

R1# show ip nat translations
Pro Inside global ...........Inside local .....Outside local .......Outside global

Lastly, you can obtain statistics on the overload NAT service. This will show you the amount of current translations tracked by our NAT table, plus a lot more:

R1# show ip nat statistics
Total active translations: 200 (0 static, 200 dynamic; 200 extended)
Outside interfaces:
Serial 0/0
Inside interfaces:
FastEthernet0/0
Hits: 163134904 Misses: 0
CEF Translated packets: 161396861, CEF Punted packets: 3465356
Expired translations: 2453616
Dynamic mappings:
-- Inside Source
[Id: 2] access-list 100 interface serial 0/0 refcount 195
Appl doors: 0
Normal doors: 0
Queued Packets: 0