5.Cisco ASA Static NAT Configuration



In previous lessons I explained how you can use dynamic NAT or PAT so that your hosts or servers on the inside of your network are able to access the outside world. This is great but it’s only for outbound traffic or in “ASA terminology”…traffic from a higher security level going to a lower security level.

What if an outside host on the Internet wants to reach a server on our inside or DMZ? This is impossible with only dynamic NAT or PAT. When we want to achieve this we have to do two things:

  • Configure static NAT so that the internal server is reachable through an outside public IP address.
  • Configure an access-list so that the traffic is allowed.

To demonstrate static NAT I will use the following topology:

ASA1 Outside DMZ R1 R2Above we have our ASA firewall with two interfaces; one for the DMZ and another one for the outside world. Imagine that R1 is a webserver on the DMZ while R2 is some host on the Internet that wants to reach our webserver. Let’s configure our firewall so that this is possible…

1.Static NAT Configuration

First we will create a network object that defines our “webserver” in the DMZ and also configure to what IP address it should be translated. This configuration is for ASA version 8.3 and later:

ASA1(config)# object network WEB_SERVER
ASA1(config-network-object)# host 192.168.1.1
ASA1(config-network-object)# nat (DMZ,OUTSIDE) static 192.168.2.200

The configuration above tells the ASA that whenever an outside device connects to IP address 192.168.2.200 that it should be translated to IP address 192.168.1.1. This takes care of NAT but we still have to create an access-list or traffic will be dropped:

ASA1(config)# access-list OUTSIDE_TO_DMZ extended permit tcp any host 192.168.1.1

The access-list above allows any source IP address to connect to IP address 192.168.1.1. When using ASA version 8.3 or later you need to specify the “real” IP address, not the “NAT translated” address. Let’s activate this access-list:

ASA1(config)# access-group OUTSIDE_TO_DMZ in interface OUTSIDE

This enables the access-list on the outside interface. Let’s telnet from R2 to R1 on TCP port 80 to see if it works:

R2#telnet 192.168.2.200
Trying 192.168.2.200 ... Open

Great, we are able to connect from R2 to R1, let’s take a look at the ASA to verify some things:

ASA1# show xlate
1 in use, 1 most used
Flags: D - DNS, e - extended, I - identity, i - dynamic, r - portmap,
       s - static, T - twice, N - net-to-net
NAT from DMZ:192.168.1.1 to OUTSIDE:192.168.2.200
    flags s idle 0:08:44 timeout 0:00:00
ASA1# show access-list
access-list cached ACL log flows: total 0, denied 0 (deny-flow-max 4096)
            alert-interval 300
access-list OUTSIDE_TO_DMZ; 1 elements; name hash: 0xe96c1ef3
access-list OUTSIDE_TO_DMZ line 1 extended permit tcp any host 192.168.1.1 eq www (hitcnt=6) 0x408b914e

Above you can see the static NAT entry and also the hit on the access-list. Everything is working as it is supposed to be.

2.Static NAT for entire subnet

The previous example was fine if you have only a few servers since you can create a couple of static NAT translations and be done with it. There is another option though, it’s also possible to translate an entire subnet to an entire pool of IP addresses. Let me give you an example of what I’m talking about:

ASA1-R1-R3-dmz-R2-outsideThe topology above is the exact same as the previous example but I have added R3 to the DMZ. Now imagine that our ISP gave us a pool of IP addresses, let’s say 10.10.10.0 /24. We can use this pool to translate all the servers in the DMZ, let me show you how:

ASA1(config)# object network PUBLIC_POOL
ASA1(config-network-object)# subnet 10.10.10.0 255.255.255.0

First we configure the pool with IP addresses. Our next step is to create a network object for the DMZ subnet and to enable NAT:

ASA1(config)# object network DMZ
ASA1(config-network-object)# subnet 192.168.1.0 255.255.255.0
ASA1(config-network-object)# nat (DMZ,OUTSIDE) static PUBLIC_POOL

The configuration above tells the ASA to translate any IP address from the subnet DMZ (192.168.1.0 /24) to an IP address in the PUBLIC_POOL (10.10.10.0 /24). Last but not least, let’s make the access-list:

ASA1(config)# access-list OUTSIDE_TO_DMZ permit tcp any 192.168.1.0 255.255.255.0

and activate it on the outside:

ASA1(config)# access-group OUTSIDE_TO_DMZ in interface OUTSIDE

That’s all we have to configure, let’s verify our work:

ASA1# show xlate 
1 in use, 1 most used
Flags: D - DNS, e - extended, I - identity, i - dynamic, r - portmap,
       s - static, T - twice, N - net-to-net
NAT from DMZ:192.168.1.0/24 to OUTSIDE:10.10.10.0/24
    flags s idle 0:02:00 timeout 0:00:00

You can see that the entire DMZ subnet 192.168.1.0 /24 will be translated to our 10.10.10.0 /24 pool. Let’s enable a debug so we can see what addresses are used when we translate:

ASA1# debug nat 255
debug nat  enabled at level 255

Now I’ll connect from R2 to the first IP address in the pool:

R2#telnet 10.10.10.1
Trying 10.10.10.1 ... Open

You can see that it connects and the ASA will show the following output:

ASA1# nat: untranslation - OUTSIDE:10.10.10.1/23 to DMZ:192.168.1.1/23 (xp:0xab2b3980, policy:0xad2632a0)

Whenever we connect to 10.10.10.1 it corresponds with the first IP address of the DMZ so we are connected to R1. Let’s see how we can connect to R3:

R2#telnet 10.10.10.3
Trying 10.10.10.3 ... Open

It’s connected and this is what the ASA thinks of it:

ASA1# nat: untranslation - OUTSIDE:10.10.10.3/23 to DMZ:192.168.1.3/23 (xp:0xab2b3980, policy:0xad2632a0)

The third IP address in the pool is translated to the third IP address of the DMZ which is R3.

This demonstrates that each IP address in the pool is translated to the “same” IP address in the DMZ. For example:

  • 10.10.10.1 > 192.168.1.1
  • 10.10.10.3 > 192.168.1.3
  • 10.10.10.200 > 192.168.1.200
  • etc.

That’s all I have about static NAT on the Cisco ASA firewall for now. Hopefully this lesson has been useful, if you have any questions feel free to leave a comment!

Comments

Post a Comment

Popular posts from this blog

Cisco ASA Packet Drop Troubleshooting

Image
As a firewall, the Cisco ASA drops packets. That’s great until it drops packets that you want to permit, and you have no idea what is going on. Fortunately, the ASA supports different tools to show you why and what packets it drops. In this lesson, we’ll cover the following tools: Connection State Interface Drops Syslog ASP Drops Packet Capture Packet Tracer Service Policy Conclusion Here is the topology I use: We use a simple topology: Two “host” devices: These are routers with ip routing disabled, and they use ASA1 as their default gateway. An HTTP server is enabled on both devices. ASA1 runs ASAv Version 9.9(2) and has two interfaces: INSIDE: security level 100 OUTSIDE: security level 0 In this topology, H1 will be able to initiate a connection to H2. H2 won’t be able to initiate a connection to H1 because we go from a  low-security level (0) to a high-security level (100) . Configurations ASA1 H1 H2 hostname ASA1 ! interface GigabitEthernet0/0 nameif INSIDE security-level 100...
Read more

show asp drop Command Usage

The  show asp drop  command shows the packets or connections dropped by the accelerated security path, which might help you troubleshoot a problem. See the general operations configuration guide for more information about the accelerated security path. This information is used for debugging purposes only, and the information output is subject to change. Consult Cisco TAC to help you debug your system with this command. The following sections include each drop reason name and description, including recommendations: rame Drop Reasons   ---------------------------------------------------------------- Name: natt-keepalive NAT-T keepalive message: This counter will increment when the appliance receives an IPSec NAT-T keepalive message. NAT-T keepalive messages are sent from the IPSec peer to the appliance to keep NAT/PAT flow information current in network devices between the NAT-T IPSec peer and the appliance.   Recommendation: If you have configured IPSec NAT-T on your ...
Read more

1.Cisco ASA Clock Configuration

The Cisco ASA firewall has a battery on the motherboard that saves the clock settings. Even when it’s is powered off, the clock will be stored. There are two important reasons why you want to make sure that your ASA has the correct date/time: In case of a security breach you want to track log files for events. With an incorrect timestamp, your log files are useless. PKI (Public Key Infrastructure) that we use for digital certificates to authenticate remote users (IPSEC or SSL VPN) requires the correct date/time. The most simple method is to configure the date/time manually, you can do it like this: ASA1(config)# clock set 13:15:00 Dec 19 2014 Just use the  clock set  command and enter the correct time/date. You can verify it like this: ASA1# show clock 13:15:15.709 UTC Fri Dec 19 2014 As you can see, the default timezone is UTC. If you are in another timezone like me then you have to change this: ASA1(config)# clock timezone CET +1 Use the  clock timezone  command t...
Read more