ASA 8.4 NAT, the (mostly) definitive guide



Hi Guys!


if your anything like me you have had a bit of difficulty with the new NAT statements in the ASA 8.3 and above firmware, I have found it needs a little getting used to and thus I wanted to investigate and make sure I could document it and understand it for you guys :).

So, first of all let's have a look at some examples, in particular common things you would do on ASA pre 8.3

dynamic NAT overload
-------------------------

Easily the most common thing you might do on an ASA is NAT some internal addresses to a single global address, seems pretty common to me!

To give you some background I have two interfaces
Inside: 192.168.227.50
outside: 203.1.1.1

 So, most likely we want to do something like say that anything from 192.168.227.0/24 is nat'd to our outside address, this would be accomplished on firmware below 8.3 with:

nat (inside) 1 192.168.227.0 255.255.255.0
global (outside) 1 interface

Here is the new way of accomplishing this.

first, you must specify an object that will define the NAT rules for this subnet, this is the way the ASA does NAT now so I am afraid we have to get used to it :p

object network insidenetwork
 subnet 192.168.227.0 255.255.255.0 

  nat (inside,outside) dynamic interface
 !


Now i will just mention, very confusingly these two statements when you do a show run will not be grouped together,  confusing.

Anyway, so now with just that we should have enough to see an incoming nat connection when we ftp from our inside network to some host on the outside

ciscoasa# show xlate
1 in use, 1 most used
Flags: D - DNS, i - dynamic, r - portmap, s - static, I - identity, T - twice
TCP PAT from inside:192.168.227.40/1040 to outside:203.1.1.1/62977 flags ri idle 0:00:04 timeout 0:00:30






Success, we can see our NAT rule being applied.

Here is a handy way to see what NAT rule is being applied to a particular subnet:

ciscoasa# show nat 192.168.227.50 255.255.255.0  detail

Auto NAT Policies (Section 2)
1 (inside) to (outside) source dynamic insidenetwork interface
    translate_hits = 1, untranslate_hits = 0
    Source - Origin: 192.168.227.0/24, Translated: 203.1.1.1/24

Next let's look at what you might typically do, a static NAT.


Static NAT (Whole Host)
-------------------------

The new way of doing a static NAT is fairly similiar to the dynamic NAT we showed you previously, you must define an object that your going to NAT for

object network statichost
  host 192.168.227.40

  nat (inside,outside) static 203.1.1.253

Now we have a static NAT for that particular address range.


ciscoasa# show xlate
1 in use, 1 most used
Flags: D - DNS, i - dynamic, r - portmap, s - static, I - identity, T - twice
NAT from inside:192.168.227.40 to outside:203.1.1.253
    flags s idle 0:00:04 timeout 0:00:00



We can see more info from show nat detail:

ciscoasa# show nat detail

Auto NAT Policies (Section 2)
1 (inside) to (outside) source static statichost 203.1.1.253
    translate_hits = 3, untranslate_hits = 3
    Source - Origin: 192.168.227.40/32, Translated: 203.1.1.253/32
2 (inside) to (outside) source dynamic insidenetwork interface
    translate_hits = 1, untranslate_hits = 0
    Source - Origin: 192.168.227.0/24, Translated: 203.1.1.1/24




Static NAT (Individual Port)

-------------------------

Next let's have a look at static NAT for just a single port likeFTP

object network statichost
 nat (inside,outside) static 203.1.1.253 service tcp ftp ftp





As usual this comes up for us as a xlate rule:

ciscoasa# show xlate
1 in use, 2 most used
Flags: D - DNS, i - dynamic, r - portmap, s - static, I - identity, T - twice
TCP PAT from inside:192.168.227.40 21-21 to outside:203.1.1.253 21-21
    flags sr idle 0:01:04 timeout 0:00:00

We can also see it under show nat detail:

ciscoasa# show nat detail

Auto NAT Policies (Section 2)
1 (inside) to (outside) source static statichost 203.1.1.253   service tcp ftp ftp
    translate_hits = 0, untranslate_hits = 2
    Source - Origin: 192.168.227.40/32, Translated: 203.1.1.253/32
    Service - Protocol: tcp Real: ftp Mapped: ftp
2 (inside) to (outside) source dynamic insidenetwork interface
    translate_hits = 1, untranslate_hits = 0
    Source - Origin: 192.168.227.0/24, Translated: 203.1.1.1/24



Intermission
----------------------
So far we are cooking with gas! and this probably all seems very familiar, the tricky parts are the next few parts, which includes things you do every day like making sure that VPN traffic is not Nat'd (Big one) and also making sure that your static translations that you have done work with VPN Clients (a common issue)


NAT Exemption
---------------------------
Let's have a look at how NAT exemption is performed.

Let's say you have a VPN on your outside interface, 10.0.0.0/24, and you want to exclude this from being NAT'd

The order of operation still matters in ASA 8.3 firmware, just like it did on your old ASA's, the only thing here is that there are three distinct sections, manual-section, the auto-section, and "After auto" manual section. (Confusing I know), as usual with NAT first match wins

So, first thing we have to do is create an object again (groan)

object network insidenetwork
 subnet 192.168.227.0 255.255.255.0
 

object network vpnhosts
 subnet 10.0.0.0 255.255.255.0


We already had insidenetwork defined but I am just showing it here again for your benefit :).

Next, you go into global config mode and specify that a NAT rule exists which nat's inside to itself and vpnhosts to itself.

nat (inside,outside) source static insidenetwork insidenetwork destination static vpnhosts vpnhosts

we can now see this in our show nat detail we have become so familiar with:
Manual NAT Policies (Section 1)
1 (inside) to (outside) source static insidenetwork insidenetwork   destination static vpnhosts vpnhosts
    translate_hits = 0, untranslate_hits = 0
    Source - Origin: 192.168.227.0/24, Translated: 192.168.227.0/24
    Destination - Origin: 10.0.0.0/24, Translated: 10.0.0.0/24

Auto NAT Policies (Section 2)
1 (inside) to (outside) source static statichost 203.1.1.253   service tcp ftp ftp
    translate_hits = 0, untranslate_hits = 0
    Source - Origin: 192.168.227.40/32, Translated: 203.1.1.253/32
    Service - Protocol: tcp Real: ftp Mapped: ftp
2 (inside) to (outside) source dynamic insidenetwork interface
    translate_hits = 7, untranslate_hits = 0
    Source - Origin: 192.168.227.0/24, Translated: 203.1.1.1/24


You will notice our NAT got put at the top, this is what we are expecting, and means that it will work the way we want it to :).

We then ping from a host in the 192.168.227.0 subnet


You can see that we now DON't have an entry for this in our NAT table:

ciscoasa# show xlate
2 in use, 4 most used
Flags: D - DNS, i - dynamic, r - portmap, s - static, I - identity, T - twice
NAT from inside:192.168.227.0/24 to outside:192.168.227.0/24
    flags sI idle 0:00:12 timeout 0:00:00
TCP PAT from inside:192.168.227.40 21-21 to outside:203.1.1.253 21-21
    flags sr idle 0:03:51 timeout 0:00:00



But if you look at the counter for show nat detail you can see that it is incrementing

ciscoasa# show nat detail
Manual NAT Policies (Section 1)
1 (inside) to (outside) source static insidenetwork insidenetwork   destination static vpnhosts vpnhosts
    translate_hits = 2, untranslate_hits = 3
    Source - Origin: 192.168.227.0/24, Translated: 192.168.227.0/24
    Destination - Origin: 10.0.0.0/24, Translated: 10.0.0.0/24

So now we have lots of NAT rules all working together super well :)

If you where to go to an outside host and try to ftp to the public address (203.1.1.253) that we setup, it would work, if you tried to communicate from the VPN (10.0.0.0) to a host in the 192.168.227.0 subnet, it would work, if you tried to get out to a public address from the host itself that would all work too.


More complicated example
------------------------------------


Let's go for a more complicated example, let's say you want to allow VPN users to VPN in and use your internet on the ASA, if you want to do this obviously you need to NAT the VPN as it goes back outside to the internet:

object network vpnhosts
 nat (outside,outside) dynamic interface





Helpful Hints
-------------------

The NAT in ASA 8.3 can be a bit tricky at times, what helped me was using the
"show nat detail"
command, this command shows you all your rules, and you can watch as hits register against each of your NAT rules, it also shows you the order that the rules are applied in (order still matters just like it did in the previous ASA releases).

Finally, to see just the nat objects if you have a huge running config, I found the following command useful:

show run nat

I hope this helps someone out there





 


 




 

Running nested VM's

Hi Guys

with all of us running virtualization and nested VM's even possibly so that we can study hard for our exams I found the following link EXTREMELY useful, it summarizes all the diffirent ways to get nested VM virtulization working :)
 

http://communities.vmware.com/docs/DOC-8970


iSCSI Discovery Mechanisms

Hi Guys!

This post comes to you due to my EMC Studies, I can strongly recommend them for a greater understanding of all the relevant protocols that make up storage such as FC, FCoE and iSCSI (although the course material i have on FCoE is a little dated)

Anyway I wanted to talk about iSCSI and the different discovery mechanisms available to you with iSCSI. I am sure some of you already know all of this detail but for me some of it was new :)

OK first of all let's talk theory then we will worry about detail from there :).


Important note: This blog post is NOT intended as a from-start-to-finish post on how to configure an iSCSI target with LUN's etc, it is simply a blog post to demonstrate the different ways of discovering targets using iSCSI :)


Really quickly, iSCSI has two main components just like SCSI, an initiator and a target, your target is a storage device of some description (tape, disk, whatever) and your initiator is a client wishing to access and use that storage, you can have combined initiator/target devices too.

So, let's say your an iSCSI Host and you want to discover some delicious storage to use, you have to be aware of a target, there are many ways you can become aware of target devices (and indeed for targets to become aware of you)

 

  • Static Configuration of a target using the iSCSI Qualified Name or EUI 
  • SendTargetsDiscovery message
  • iSNS (internet storage name server)
So, let's quickly show an example of the first one and we will use VMWARE ESXi as a software initiator (iSCSI) to demonstrate this.

First of all, i have setup an iSCSI target on my EMC Celerra VSA, as you can see below:

 

This is pretty much the only information i need to be able to configure ESXi to connect to this target, being able to see a LUN is a different matter (you need to configure the LUN masking on the EMC for that) but to at least connect to my target this is all i need.

 Here is my configuration under my iSCSI Software Adapater in ESXi:







So as you can see i've had to copy/paste my iSCSI qualified name into ESXi and hope i don't make any mistakes, and specify the network portal. The network portal is basically the address that the iSCSI target is accepting iSCSI TCP/IP Connections on, so what IP address has the iSCSI Port open essentially :)


Now it is actually much easier than this if you like, what you can do is just add the network portal address and get iSCSI to discover the iSCSI Target name automatically! Way better than having to copy paste or type out that long iSCSI Qualified Name






 
When you do this in ESXi, now the static discovery will show the dynamically discovered target and you didn't have to type all those seemingly random characters :p

 
OK next we will talk about iSNS. iSNS allows you to have targets and initiators register to a central server to report what iSCSI Targets and initiators exist out there on the network, think of it like the name-server for fibre channel (And like FC, it has a method of ensuring that particular targets/initiators are only able to see the targets/initiators they should be able to see)

Now here is a big drawback: ESXi even 5.0 as far as i can tell doesn't support iSNS!!!! it won't register as a initiator :(, so for my examples we will use the iSCSI initiator you can download for Windows.

I have set my EMC Celerra to register to the iSNS Server below:

 

You can install an iSNS server on windows Server 2008 by going to add/remove roles and you will see it there :).

OK so next, I go to my software initiator in Windows and configure my iSNS Server:



 
 
Now when i go back to the iSCSI client main page i will see my discovered targets off the iSNS Server:
 


Next, Let's try and "zone" the iSCSI targets and initiators, in my above example, the windows box should NOT be able to see this storage as it is actually a VMFS Formatted LUN behind that iSCSI Target! SO woops we don't want Windows to be able to see THAT!

So how do we stop that? Easy


Under the iSNS Server you will see  the registered targets and initiators:




Discovery Domains are groups of initiators and targets that should be able to see each other (like a zone in FC), a discovery domain set is a collection of discovery domains. A iSCSI Node can be a member of multiple discovery domains, and unlike FC, you can have multiple active Discovery domain sets at one time.


So, in our example we won't bother changing the discovery domain set, but we will modify the default discovery domain :).

 
As you can see, by default all devices are a member of the default discovery domain, let's make a new one for Windows and put windows in that one :).

 

 DON'T FORGET YOU HAVE TO REMOVE THE INITIATOR FROM THE DEFAULT DD AS HE WILL BE IN THERE BY DEFAULT :)

Windows can now no longer see any targets :( ForeverAlone.Jpeg

 
 

I hope this was insightful :)
 

  


 
 

Popular old posts.