Welcome back to this series where we cover CCNA Security topics using Cisco Packet Tracer in our labs. In the last lab, we configured routing, ICMP inspection using MPF and SSH access to the ASA.

In this lab, we will configure Network Address Translation (NAT) as well as access lists (ACLs) to meet security access policies. The lab setup we will be using in this article is as shown below:

Two files are attached to this article:

  • cisco_asa_nat_acl_init.pkt: This Packet Tracer file is actually the “final” PKT file from the previous lab with some changes: the loopback interface on the Outside_RTR has been removed and a Web/DNS_Server ( has been connected to the Gi0/1 interface of this router. The Inside_User has also been configured with a DNS server of
  • cisco_asa_nat_acl_final.pkt: This Packet Tracer file contains the lab setup with the ASA fully configured to meet the lab tasks.

The tasks for this lab are as follows:

  • Traffic initiated from devices on the inside interface going out through the outside interface should be seen as coming from the IP address of the Cisco ASA’s outside interface. Verify that the Inside_User can open a web page to https://www.example1.com.
  • Connections from devices on the outside interface to should be directed to the Web_Server in the DMZ.
  • Ensure that only HTTP and HTTPS traffic from external (outside) devices are allowed to the Web_Server.

Lab Solutions

Task 1: PAT

With the current state of our lab, a ping from the Inside_User to the Outside_RTR will not be successful, not because the ping traffic is not getting to its destination, but because the Outside_RTR does not know how to get back to the source of the traffic:

Therefore, we either sort out the routing or configure NAT. Since private IP addresses are not routable over the Internet, then the most suitable option in this scenario is to use NAT to translate the private IP addresses to a public address.

Port Address Translation (PAT), also known as NAT Overload on the Cisco IOS, is a way to translate multiple IP addresses to just one IP address and this is what is required by this task. The configuration on the Cisco ASA to achieve this is as follows:

object network INSIDE
 nat (inside,outside) dynamic interface

With this configuration, let’s try to ping from the Inside_User again:

If we look at the ICMP debug output on the Outside_RTR, we see that replies are being sent to, which is the outside interface IP address of the ASA:

While the ping is still running, we can view the translation entry on the ASA using the show xlate command:

Cool. The task also requires that the Inside_User be able to open a web page to https://www.example1.com. To be able to open this URL, the host will contact its DNS server for the IP address associated with the FQDN. The DNS server on the Inside_User is configured as is the IP address of the Web/DNS_Server which has its DNS service turned on and an A record for www.example1.com pointing to

So let’s try to open that web page:

Great, it works.

Task 2: Static NAT

Static NAT allows for one-to-one* mapping between real and mapped IP addresses. This task requires that the IP address of the Web_Server ( should be mapped to Unlike dynamic PAT and dynamic NAT, static NAT allows bi-directional initiation of traffic, i.e. from the host and to the host (if allowed in access policies).

Note: * There are other variations of static NAT such as one-to-many, few-to-many, and many-to-few.

The configuration on the ASA is as follows:

object network WEB_SERVER
 nat (dmz,outside) static

One way to quickly test this configuration is to ping the Outside_RTR (with ICMP debugging turned on) from the Web_Server:

Hint: The first ping failed because the Outside_RTR was trying to find the MAC address for

Task 3: ACL

Even though we have configured static NAT for the Web_Server, hosts from the outside will not be able to access this server, as shown below:

This is because the dmz interface is on a higher security level (50) than the outside interface (0). To allow access from a lower security interface to a higher security interface, we need to configure access lists.

The task requires that only HTTP and HTTPS traffic should be allowed to this server. The question that now remains is: To configure the ACL, should we use the real or mapped IP address of the server? The answer to that question depends on the ASA version you are running. From ASA version 8.3, ACLs should now specify the real IP address no matter where the ACL is applied. However, even though the ASA version on Packet Tracer says 8.4(2), it still requires that we use the mapped IP address in our ACL.

Therefore, our configuration on the ASA will be as follows:

access-list OUTSIDE_IN extended permit tcp any host eq www
access-list OUTSIDE_IN extended permit tcp any host eq 443
access-group OUTSIDE_IN in interface outside

Note: We can also use objects and object-groups in our configuration but I found some issues with it on Packet Tracer.

To test this configuration, we will try to open an HTTPS connection to again; hopefully, the request will not timeout this time:



This brings us to the end of this lab where we have configured NAT and ACL on the Cisco ASA. There are a couple of unsupported features on the Cisco ASA in Packet Tracer, such as dynamic NAT and ASDM access management, but it still provides a good start for becoming familiar with the Cisco ASA.

I hope you have found this lab helpful and I look forward to more labs in this series.

References and Further Reading