Hi there and welcome back to this series on configuring the Cisco ASA in GNS3 through the ASDM. In the last article, we configured both PAT and Dynamic NAT rules on the ASA to allow connectivity from the inside to the DMZ and outside zones. This is the usual configuration in many organizations. However, there is also another configuration done by companies with DMZ servers that requires public access and this is what we will be looking at in this article.
Our network diagram is as shown below:
Let’s first take a brief look at the DMZ to understand why it is needed. Some organizations have web servers (and other servers) that are hosted internally and should also be available to the public i.e. accessible from the Internet. However, giving the public access to your servers also means you make yourself available to attacks from the outside. Therefore, organizations create a Demilitarized Zone (DMZ) to isolate their internal trusted network (e.g. LAN) from the systems that need to be accessed from the outside. This means that a compromise on the DMZ does not necessarily result in a compromise to the trusted network.
Having this knowledge in mind, let’s assume there is a web server in the DMZ that should be accessible from the outside. Using static NAT, we are able to translate the web server’s real IP address in the DMZ zone to a mapped IP address in the outside zone.
Note: In our scenario, we are only concerned with the technology behind static NAT. The normal case is that the DMZ servers will have public routable IP addresses so that they can be accessed from the Internet.
To implement this, I will create a loopback on the DMZ-RTR with an IP address of 172.16.2.20; I will also enable the HTTP server on this router and finally set the DMZ-RTR’s default gateway as the ASA.
ip http server ip route 0.0.0.0 0.0.0.0 172.16.1.1 interface Loopback0 ip address 172.16.2.20 255.255.255.255
Note that because we are not using any dynamic routing protocol in our network, I will need to add a static route on the ASA for that new IP address as shown below:
The equivalent CLI command for the above static route is:
route dmz 172.16.2.20 255.255.255.255 172.16.1.2 1
It is also a good thing to check that you can successfully ping the new network.
We will now configure a static NAT rule for this new loopback IP address using a mapped IP address of 192.168.20.20. The reason we use static NAT is because static NAT is bidirectional i.e. it allows a connection to be made from both the real IP address and to the mapped IP address.
Hint: In a real organization, to avoid double NAT, you may configure a public IP address as the mapped IP address. However, since there is still a hop to the Internet (the Internet router), you will have to configure a static route for that mapped IP address pointing to the ASA.
Configuring static NAT is the same way we configured PAT and dynamic NAT. We will navigate to Configuration > Firewall > NAT Rules and add a new Network Object NAT rule.
We will click on the Advanced button so that we can specify the real and mapped interface.
The equivalent configuration to be sent to the CLI is as follows:
object network Web_Server host 172.16.2.20 nat (dmz,outside) static 192.168.20.20
At this point, we can test whether our translation is active. I will open a connection from the DMZ-RTR to the Internet-RTR using the newly created loopback interface as the source interface.
Hint: When I first tried the telnet connection, it didn’t go through. I will just assume the ASA was ‘booting’. If you are sure of your configuration, just wait a few seconds and try again.
As you can see, the Internet-RTR “sees” the DMZ-RTR as 192.168.20.20 i.e. the mapped IP address. This is because when the Internet-RTR got a connection request from 192.168.20.20, it sent an ARP request for that IP address and the ASA responded on behalf of the DMZ-RTR. This is known as Proxy ARP. If we were to check the ARP table of the Internet-RTR, you will understand better:
Notice that the 192.168.20.20 IP address has the same MAC address as the ASA (192.168.20.1). This is the function of Proxy ARP i.e. a device sends its own MAC address on behalf of another device thus acting as a proxy.
A question to ask then is: What happens if proxy ARP is disabled on the ASA? I will edit the NAT rule I just created by double-clicking on it and then click on the Advanced button to check the Disable Proxy ARP on egress interface option as shown below:
The command to be sent to the ASA is as follows:
object network Web_Server
nat (dmz,outside) static 192.168.20.20 no-proxy-arp
clear xlate interface dmz local 172.16.2.20
We also have to clear the ARP cache on the Internet-RTR because it already knows the MAC address of 192.168.20.20. The clear arp-cache <ip_addr> or clear ip arp <ip_addr> should normally work but if it doesn’t (like it didn’t work in my case), just shut down that interface (Fa0/0) and bring it up again.
Now, I will try to open the telnet connection again from the DMZ-RTR.
Notice that it fails. What is happening is that the ASA is not replying on behalf of the DMZ-RTR anymore and without the MAC address, the Internet-RTR cannot successfully reply the telnet session. Also, if you were to capture packets on the link between the Internet-RTR and the ASA, specifying the Internet-RTR’s Fa0/0 as the source interface, you will see the ARP broadcasts as shown below (note that you will still see the output below regardless of whether proxy ARP is enabled on the ASA):
In a case such as this where proxy ARP is disabled for whatever reason, how do you ensure that connectivity is not broken? You will have to configure a static route for the mapped IP address on the upstream device (i.e. the Internet-RTR) pointing to the ASA. Of course, the external device has to be in your control for this to be done but that’s not the focus here.
Let’s now attempt to open a telnet session again:
Cool that works now. To wrap this up, two instances where you would configure a static route on the upstream device (e.g. Internet-RTR) is if the mapped IP address is not on the same subnet with the upstream device or when proxy ARP is turned off on the device performing NAT.
In this article, we began by explaining why organisations need a DMZ. We then went on to configure static NAT for a DMZ server and finally considered the effect of proxy ARP on NAT.
In the next article, we will configure access control policies on the ASA using the ASDM. I hope you have found this article insightful and I look forward to the next article in the series.
The TCP/P Guide- Proxy ARP: http://www.tcpipguide.com/free/t_ProxyARP.htm