DYNAMIC TRANSLATIONS USING AUTO NAT
One important difference in functionality, however, is that while static translations never expire, translation slots created by a dynamic NAT rule expire after being idle for 3 hours, by default (not seeing any traffic that uses the translation slot). The presented scenario will once again use a familiar example to begin. We will configure a dynamic translation for the inside network, 10.0.100.0/24, to a range of translated addresses, 184.108.40.206–50, for use on the outside interface.
These translations will be one-to-one (NAT, not PAT). If this pool of addresses is exhausted, you want to “back up” this translation range by using PAT with the interface address of the ASA acting as the PAT translation address.
In this short demonstration, we are going to show you how a PC on the INSIDE network of the ASA which also happen to be a WEB server on the INSIDE network is able to access the internet resources on the OUTSIDE interface of the ASA. Dynamic Object NAT makes all this possible as it will be demonstrated here shortly.
DYNAMIC INSIDE OBJECT NAT ON THE ASA
The following figure shows the ASA configured with Dynamic NAT for the INSIDE network hosts as they access the internet.
THE INSIDE HOST/SERVER ACCESSING INTERNET RESOURCES
The following figure shows a PC on the INSIDE network of IP address 10.0.10.5 able to access Web resources on the internet at the web address of http://220.127.116.11 as shown in the figure below.
NAT TRANSLATION ON THE ASA
As you can see from the figure below, the PC coming from the INSIDE network going to the Internet resources that are found on the OUTSIDE network of the ASA has been translated from the private address of 10.0.100.5 to a global address of 18.104.22.168.
As you can see in the ASA NAT table below, the hosts on the INSIDE-NETWORK are being translated to the INSIDE-NAT-DYNAMIC-POOL.
004. NETWORK ADDRESS TRANSLATION ON THE ASA
NAT NETWORK TOPOLOGY
The Cisco Adaptive Security Appliance (ASA) is frequently deployed at the border between a network using a private IP addressing scheme and the public Internet address space. To solve addressing issues when interconnecting these networks, the Cisco ASA supports Network Address Translation (NAT) and Port Address Translation (PAT).
NAT performs the translation of source and/or destination IP addresses in packets traversing the ASA. PAT, in addition to translating IP addresses, translates source port numbers in TCP or UDP packets, thus allowing many-to-one translation of source IP addresses. This allows numerous internal hosts to share a single public IP address when communicating with external networks.
UNDERSTANDING HOW NAT WORKS
Network Address Translation (NAT) was developed to overcome IP addressing problems that occurred when the ARPANet, which interconnected only a few dozen large institutions, became the Internet, which had the ability to interconnect networks and computers globally, leading to massive growth. There simply were not enough addresses available in the originally designed IP addressing scheme to accommodate universal connectivity, especially given the manner in which addresses were originally assigned.
Therefore, a system of “private” IP addresses was developed, first in RFC 1597, which was then superseded by the better-known RFC 1918, which allows multiple networks around the world to deploy the exact same IP addresses for addresses that require only local uniqueness. This eliminates the need to maintain globally unique addresses for every connected host worldwide.
Because private IP addresses are intended for local use only and are considered “nonroutable” on the public Internet, NAT is required to translate these private (local) IP addresses to public (global), routable addresses when hosts on a private network need to communicate with hosts outside of that private network.
Additionally, because many organizations can deploy the same private IP addresses, due to local significance, NAT is required if hosts on these networks with overlapping addresses need to communicate with each other.
STATIC TRANSLATIONS USING AUTO NAT
Static inside NAT creates permanent, fixed translations between a local address and a global address. Translation slots created using static translation rules are always present in the translation table, and are persistent across reboots. They have no idle timer leading to expiration. If you delete a static NAT rule from the ASA, the associated entries in the translation table are automatically removed; however, existing sessions remain functional unless manually cleared by an administrator.
Because translation slots based on static translation rules are always active, hosts from less secure networks can initiate communications to the statically translated local hosts, as long as the access list rules on the ASA permit such traffic. These factors make static inside NAT ideal for servers that need to be accessed from less secure interfaces, where the address configured on the server needs to be translated.
In this demonstration scenario we have two application servers exist on the DMZ interface that require access from the Internet. A web server with native IP address 172.16.0.5 and an FTP server with native IP address 172.16.0.6. The web server will use translated IP address 22.214.171.124 when communicating with the outside interface (the Internet), and the FTP server will use translated IP address 126.96.36.199.
STATIC PORT TRANSLATIONS USING AUTO NAT
Using static inside PAT, you can create a fixed translation from a local host IP address and local Layer 4 port (for TCP or UDP) to a global IP address and global Layer 4 port. Static inside PAT is useful when you want to allow inbound connectivity to a number of local servers, using a single global IP address.
An interface access list on the ASA would still need to be configured to allow such connections. It also allows you to reuse a global IP address that is used for dynamic inside NAT/PAT (because outgoing sessions will use port numbers of 1024 and higher) to also support inbound connectivity to servers on specific global ports (which will generally be 1023 and below), forwarded to specific local hosts, on specific local ports.
In this demonstration scenario you have two servers located on the DMZ segment. The first, with a native IP address of 172.16.0.5, hosts a secure web-based application and listens for HTTPS connections on customized TCP port 8443. The second is a mail server, with a native IP address of 172.16.0.6, and listens for SMTP connections on the standard TCP port 25. You have only one global IP address available for use: 188.8.131.52.
ROUTING WITH OSPF ON THE ASA
OSPF is a link-state routing protocol that can partition a network into a hierarchy of distinct numbered areas. Area 0 is always considered the backbone area of the OSPF domain or autonomous system, which must connect to all other areas.
When an OSPF router connects to two or more different areas, it is called an Area Border Router (ABR).
When an OSPF router connects an area to a non-OSPF domain and it imports routing information from other sources into OSPF, it is called an Autonomous System Boundary Router (ASBR).
OSPF routers build a common database of the status of all links in the area by exchanging link-state advertisements (LSA). The routers build their routing tables by computing the shortest path first (SPF) algorithm based on that database. OSPF uses a path cost value, which is based on link bandwidth, as a routing metric. An ASA can support at most two different OSPF processes.
In our OSPF demonstration we are going to use the same network topology as the one we used in RIPv2 and EIGRP routing protocols. The OSPF network topology is shown below.
ASA OSPF NETWORK TOPOLOGY
In this OSPF demonstration, the ASA Firewall has learned the routes 10.0.10.0/24, 10.0.20.0/24, 10.0.30.0/24, and 10.0.40.0/24 from the MOIGETECH-INSIDE-ROUTER. At the same time MOIGETECH-INSIDE-ROUTER has learned the routes 172.16.0.0/24, 184.108.40.206/24, 10.0.0.0/24 as well as the default of 0.0.0.0/0 from the ASA firewall.
OSPF ROUTES ON THE ASA FIREWALL
OSPF ROUTES ON THE INSIDE ROUTER
This marks the end of Routing on the Cisco ASA firewall. What we have covered is just a fraction on what the ASA firewall can as far as routing is concerned. The ASA can be fine-tuned to meet all your routing needs.
ROUTING WITH EIGRP ON THE ASA
The Enhanced Interior Gateway Routing Protocol (EIGRP) uses a complex routing metric that is based on a combination of delay, bandwidth, reliability, load, and MTU. EIGRP combines the advantages of link-state and distance-vector routing protocols, making it a hybrid of both methods.
EIGRP uses a neighbor discovery mechanism that works by sending hello messages to directly connected neighboring routers. Neighbors can be dynamically discovered or statically configured. All EIGRP messages, including the hello protocol, are sent as multicast packets to address 220.127.116.11, the “all EIGRP routers” address, using IP protocol 88.
EIGRP supports variable-length subnet masks (VLSM) and route summarization, providing plenty of flexibility in its routing information. It also uses the Diffusing Update Algorithm (DUAL) to compute and maintain routing information from all of its neighbors.
Our demonstration example uses the same network topology as the one we used in the RIPv2 routing protocol. The ASA is going to advertise the network 172.16.0.0/24, 10.0.0.0/24, 192.168.10.0/24 and 18.104.22.168/24 using the EIGRP routing protocol. At the same time the MOIGETECH-INSIDE-ROUTER is going to advertise 10.0.10.0/24, 10.0.20.0/24, 10.0.30.0/24, 10.0.40.0/24 and 192.168.10.0/24 using EIGRP routing protocol. The network topology is shown below.
EIGRP NETWORK TOPOLOGY
The following diagram shows that the ASA has learned EIGRP routes from the MOIGETECH-INSIDE-ROUTER as shown in the figure below.
The following figure shows the MOIGETECH-INSIDE-ROUTER having learned routes using the EIGRP routing protocol from the ASA firewall as show in the diagram below.
TRACKING A STATIC ROUTE ON THE ASA
Normally, if a static route is configured, it stays active until it is manually removed with the no route configuration command. A static route is simply an unchanging definition of a next-hop destination, regardless of whether that destination is reachable. If a single Internet service provider (ISP) is the sole means of reaching the outside world, a static default route works nicely to point all outbound traffic to the ISP’s gateway address.
Suppose that you had connections to two ISPs, so you configured one default route to each. One ISP might be favored over the other, but the ASA will treat the default routes to each ISP equally and will try to balance the outbound traffic across the two connections.
Even if the connection to one ISP goes down, the firewall will still use the static default route that points to that ISP as if nothing had happened—effectively sending some outbound traffic into a black hole.
You can leverage the static route tracking feature to make a static route conditional, based on the reachability of some target address. If the target address is reachable, the tracked static route remains active; if the target is not reachable, the static route becomes inactive, allowing other similar routes to be preferred.
This allows you to configure multiple static or default routes without worrying about whether or not one ISP connection is working. To make a static route conditional, you configure a service-level agreement (SLA) monitor process that monitors an arbitrary target address. That process is associated with a static route so that the route tracks the reachability of the target.
The figure below shows an example scenario where the ASA has two paths to the outside world. Therefore, it could be configured with two default routes that point to the two next-hop routers: 22.214.171.124 and 126.96.36.199. The link to 188.8.131.52 should be preferred and used, as long as the router 184.108.40.206 is alive and reachable; otherwise, the ASA should use the backup default route toward 220.127.116.11.
A STATIC ROUTE CONFIGURATION ON THE ASA
As you can see in the figure below, the ASA has been configure with two default routes pointing to different ISPs. The one going through SAFARICOM ISP is the primary one with a lower Administrative distance of 1. This static default route is also tracked, meaning that as long a the ISP’s address 18.104.22.168 is reachable then it will continue to be used otherwise the ASA will start using the second default route through the TELKOM KENYA ISP’s router which is reachable at 22.214.171.124. This default route through the TELKOM KENYA’s router has a higher administrative distance of 100.
NORMAL TRAFFIC ROUTING (THROUGH SAFARICOM ISP)
As you can see from the diagram above traffic traveling towards the internet (126.96.36.199) takes/follows the upper path through SAFARICOM ISP as the recommended normal path to the internet until the reachability towards the SAFARICOM interface/router on the address 188.8.131.52 in unavailable/unreachable.
SIMULATING LINK FAILURE ON THE PRIMARY PATH
To simulate the primary ISP link failure, I am going to shut down the Ethernet interface on SAF-ISP1-ROUTER that connects to the ASA’s ISP1-SAFARICOM interface which is the primary path towards the internet. After the primary link towards the internet is shut down, the ASA should start routing traffic through the second ISP TELKOM KENYA as shown below.
PRIMARY LINK SHUT DOWN
THE ASA STARTING TO USE THE BACKUP ISP LINK