In the last article, we configured basic settings such as interface settings and static routing on the Cisco ASA using the ASDM. We discovered that while the ASA could connect to all the networks, there was no connectivity among the networks themselves. In this article, we will explain why the networks could not communicate and we will configure policies to allow this connectivity.

Our network setup is shown below: the 41.1.1.2/32 will simulate a host on the Internet although it is just a loopback on the Internet-RTR.

To begin, let’s consider why the networks cannot connect among themselves. From my laptop (the ASDM host), I will attempt to ping the Internet host – 41.1.1.2. I have created a route for that network on my Windows computer. At the same time, I will debug ICMP traffic received on the Internet-RTR.

As can be seen from the screenshot above, the ICMP traffic is actually getting to the Internet host (a loopback on the Internet-RTR) but the ping still fails. One of the reasons this is happening is because the Internet-RTR does not have a route for the Internal LAN – 192.168.10.0/24.

Now that we understand that one of the issues was routing (the other issue deals with ICMP inspection), let’s go ahead and come up with policies for our network.

It is common that an organization’s policy will be that the Internal LAN should go through NAT not just to conserve public IP addresses but also as a security measure. Therefore, we will configure a policy that translates all internal IP addresses (192.168.10.0/24) going to the outside, to the IP address of the outside interface (Gi0) of the ASA.

To configure this, we will navigate to Configuration > Firewall > NAT Rules.

In the main content pane, if we click on the Add button, we will configure a NAT rule before the “Network Object” NAT rules. Note that any NAT rule before or after the “Network Object” NAT rules are Twice NAT rules. The main difference between Network Object NAT and Twice NAT is that Twice NAT gives you more flexibility for complex NAT configuration which we don’t need in this case. (You can go here to see the differences outlined). Therefore, for this policy, we will click on the dropdown arrow beside the Add button to bring up the options:

This brings up the Add Network Object dialog box where we can also configure NAT. Remember that beginning from ASA version 8.3, the NAT configuration changed to split NAT configuration into Network Object NAT and Twice NAT. We configure the former under a network object.

Hint: We could also have double-clicked on the network objects on the right-hand pane e.g. inside-network/24 to configure Network object NAT.

I will assign a name to this network object and configure the IP address network as shown below:

Now, we need to specify the NAT options. There are three types of NAT that we configure: Static, Dynamic PAT (Hide), Dynamic.

The Static NAT type generally provides a one-to-one mapping (there may be variations to this rule); the Dynamic PAT (Hide) NAT type provides a many-to-one mapping; and the Dynamic NAT type provides a many-to-many mapping. For our policy, we need the Dynamic PAT (Hide) NAT type.

In the translated address field, we want this address to be the IP address of the ASA’s outside interface. Note that up till this point, I have not specified a source interface of the real address. This means that if there is also a 192.168.10.0/24 network on the DMZ (there shouldn’t be in a properly designed network), that network will also be translated to the IP address of the ASA’s outside interface. We can use the Advanced button to specify a source interface.

At the end of my configuration, this is what I have:

When I click on the OK button and then on Apply, the ASDM shows me the configuration to be sent to the ASA as follows:

object network inside-network
 subnet 192.168.10.0 255.255.255.0
 description Internal LAN
 nat (inside,outside) dynamic interface

If we were to try our ping again from the internal host, it will still fail because ICMP inspection is not enabled by default on the ASA. However, we will notice that the ICMP debug on the Internet-RTR now shows a different IP address than before.

To confirm that we have connection, let’s open a telnet connection to 41.1.1.2.

Note that we have only configured a PAT rule for the inside addresses going to the outside. This means that any connection from the internal network to the DMZ-RTR will fail because that router does not have a route for the internal network. Therefore, we will configure another policy for inside to DMZ communication. For this policy, we will use a dynamic NAT i.e. range of IP addresses rather than one IP address (PAT). First, we define our network object:

You will notice that I have defined another network object even though it’s the same network i.e. 192.168.10.0/24. This is because when configuring Network object NAT, you can only configure one NAT rule under a given object. The way around this limitation if you want to configure several NAT rules like in our case, is to configure another object with a different name but the same IP address range as shown above.

Next, we want to set the NAT type as ‘Dynamic’ and configure the translated address.

I will add a new network object for the translated address but instead of using a network object of type “Network”, I will use the “Range” type. This allows me to specify a start and end IP address.

At the end of my configuration, the screenshot below shows what I have. Notice that I have checked the Fall through to interface PAT (dest intf) option so that interface PAT can be used should the DMZ-MAPPED-ADDRS be exhausted.

When I click on OK and then on the Apply button, the ASDM shows me the configuration to be sent to the ASA as follows:

object network DMZ-MAPPED-ADDRS
 range 172.16.1.10 172.16.1.50
object network inside-network-dmz
 subnet 192.168.10.0 255.255.255.0
 nat (inside,dmz) dynamic DMZ-MAPPED-ADDRS interface

Now if I were to try to open a telnet connection to the DMZ-RTR, the ASA will assign me an IP address from the DMZ-MAPPED-ADDRS pool and my telnet connection should succeed.

Keep in mind that only the internal LAN can access the other networks (dmz and outside); the reverse is not the case. It all depends on your policy but usually, the internal LAN should be inaccessible from other zones for security reasons. Also, the DMZ cannot access the outside network or vice versa. In the next article, we will configure static NAT for DMZ to outside communication and see how NAT is affected by proxy ARP.

Summary

In this article, we have seen how to use NAT and PAT rules to enable connectivity between networks. In the next article in this series, we will enable a DMZ server which should be accessible from the outside and also configure access control rules to allow this connection.

I hope you have found this article insightful and I look forward to the next article in the series.

Further reading