Posts tagged asa
ASA 8.3.1 – Smart Tunnel and NAT Changes
Mar 11th
I’ll start off with a warning. I’ve been running 8.3.1 on my home 5505 for a few hours now. Not only is not really enough time for a thorough review, it’s also not the environment to test enterprise-level configurations. There are also a lot of details missing that I just don’t know about yet, so please do some research on your own to figure out what’s going to break if you upgrade your ASA.
If you haven’t heard, Cisco has released version 8.3.1 of their ASA operating system. I’m excited about this for only one reason – Smart Tunnels with tunnel policies.
If you’ve never heard of Smart Tunnels, you’re probably not alone. I don’t know why they’re not more popular than they are, but I dig them. A user connects to a URL, logs in, and a little applet loads on the machine that is used to proxy traffic through the ASA. It doesn’t proxy all your traffic, though; only traffic from applications that you define are sent through the tunnel. There is a huge problem that I can’t stand, though. What if you need to SSH through the firewall and to your local LAN at the same time? The smart tunnel applet doesn’t care or even know what you want to do; it tunnels all the traffic from the application. Not good, eh?
The big change to this in 8.3.1 is the addition of tunnel policies to the smart tunnels. According to the release notes, you can now dictate which connections do and don’t go through the smart tunnel. Now, I can configure the tunnel so that some traffic goes through the ASA to get to the production gear, but other traffic pukes out the NIC normally. I know a lot of users who are going to like not having to log in and out all day.
Note: I may do an article on smart tunnels once everything slows down a bit. It’s a solid way to implement a clientless VPN that doesn’t require administrative access on the machine to run.
The big feature that everyone is talking about, though, is the change to the way NAT is done. Back in the day (that means earlier this morning), if I wanted to configure a static NAT, I’d do something like this to create a static and a service NAT to two different boxes.
firewall(config)#static (inside,outside) 192.0.2.1 192.168.1.100 firewall(config)#static (inside,outside) tcp interface ssh 192.168.1.101 ssh
Now, you create an object and give that object all the attributes. I think Cisco calls this auto-NAT. I have no idea what the auto part means. In our example, we would do something like this.
firewall(config)#object network TESTHOST1 firewall(config-network-object)#host 192.168.1.100 firewall(config-network-object)#nat (inside,outside) static 192.0.2.1 firewall(config)#object network TEST2 firewall(config-network-object)#host 192.168.1.101 firewall(config-network-object)#nat (inside,outside) static interface service tcp ssh ssh
I would say that the configuration is easier to parse with your eyes if the ASA didn’t break up the configuration into two parts. If you were to do a show run and look for our configuration, you would have to look in two places. The first part declares the object name and the host/subnet/IP range for which it’s associated. The next part, which comes after the ACLs, declares the NAT stuff.
object network TESTHOST1 host 192.168.1.100 object network TESTHOST2 host 192.168.1.101 [SNIP a billions lines of ACL] pager lines 24 logging enable logging timestamp logging buffer-size 8192 logging buffered informational logging asdm informational logging host inside x.x.x.x flow-export destination inside x.x.x.x 12345 mtu outside 1500 mtu guests 1500 mtu inside 1500 icmp unreachable rate-limit 1 burst-size 1 icmp permit x.x.x.0 255.255.255.0 inside asdm image disk0:/asdm-631.bin asdm history enable arp timeout 14400 object network TESTHOST1 nat (inside,outside) static 192.0.2.1 object network TESTHOST2 nat (inside,outside) static interface service tcp ssh ssh
It may be simpler to configure, but it’s not simpler to figure out later. I’d rather have single lines of static statements; at least I can use regex on those efficiently.
There is a bright side to the new NAT thing, though. Because the NAT statements are configured in the object, you can now reference the real IP of the host in ACLs instead of the NATted IP. This will help those of us who use firewalls with 488249284 interfaces and that many NATs for each host. If we wanted to allow access to the SSH host in the example, we would write an ACL that allows access to 192.168.1.101 instead of finding the NATted address on that interface and building the rules to that address.
Speaking of ACLs, you can actually create a global access-group. Instead of creating an ACL with rules and an access-group to bind to an interface, you can build one single ACL and configure an access-group with the global directive to basically apply that ACL to all interfaces. A few quick tests show that you can have both interface and global access-group configured simultaneously and that interface ACLs will be executed first. I need to do some more testing to figure out exactly how these work together.
Everyone should upgrade, right? Nope. I don’t ever upgrade to something cool just because it’s cool. I also don’t like to have to buy more hardware to go up a minor revision. Take a look at the the memory requirements for 8.3.1; every model up to the 5510 requires more than the base amount to upgrade. I got lucky since my 5505 has 512MB in it already, but I would hate to have to justify quadrupling (!) the RAM in a 5540 just for some cool features.
Send any rotten tomatoes questions to me.
Sources:
Using SPF Records To Build Objects
Oct 16th
My biggest complain about modern firewalls is their lack of the ability to create rules based on URLs or HTTP streams; you have to open access between IP addresses. Yes, I know there are other means to do that, but I want my ASA/PIX/FWSM to do it without making me do so much work.
Anyway, the fact that you have to use IPs brings up some interesting problems. Let’s say you have a server in a DMZ that needs to query Google for some content. Since you’re a hard-ass network guy like I am, you tell the admin that they have provide the data flow they want to use — source IP, destination IP, protocol, port. They come back and tell you that they need their server to connect via HTTP to 74.125.45.100. You put in the rules as given, but the IP has suddenly changed on you.
Google (and lots of other big sites) uses some tricks to keep the load down on their servers and to help with availability, and one such trick is to use round robin DNS, which rotates the A record so everyone doesn’t slam the same boxes. You can query google.com once and get an address, but, when you query it again, you may get a different address. That means that when your new rules don’t work, you have to check the logs, see what got denied, open that up, rinse, and repeat. That sucks.
An easier way might be to create an object-group that includes IPs as you discover them. You put in rules based on an object-group, then, when it fails, you just add to the object-group so you don’t have to put in any more rules. The problem is that you’ll spend a lot of time building up a good baseline. If only there were a way to get a list of IP addresses that Google uses. Hmmm. *segue*
Have you ever heard of SPF netblock records? SPF is an email security mechanism that allows an email server to verify that an email message is coming from an authorized email source. In other words, when a mail server receives mail, it can check to see if the sending server is actually allowed to send mail on behalf of the source domain. It supposed to cut down on spam and whatnot, but I don’t follow it closely enough to know if it’s working. The moral of the story is that is involves a list of IP addresses that an organization maintains; Google happens to be a participant in SPF.
If you query for the TXT record _netblocks.google.com, you get back a text record that looks like this.
[jac@holland ~]$ dig +short txt _netblocks.google.com
“v=spf1 ip4:216.239.32.0/19 ip4:64.233.160.0/19 ip4:66.249.80.0/20 ip4:72.14.192.0/18 ip4:209.85.128.0/17 ip4:66.102.0.0/20 ip4:74.125.0.0/16 ip4:64.18.0.0/20 ip4:207.126.144.0/20 ip4:173.194.0.0/16 ?all”
This record includes all IP addresses that Google says is authorized to send email from google.com. That’s a lot of IP addresses, isn’t it? It might make sense that this list might also be the definitive list of Google production IPs.
My company has used this TXT record in the past to open access to Google. We had an app that needed to query Google maps, and one of our engineers was tired of nickel and diming it to death, so he found the SPF block and put them all in. Works like a champ.
There are always dangers when you rely on information from somebody else, though, right? Google’s usually pretty good about stuff like this, but what if you did the same for another company who only half-heartedly kept their records up-to-date? You may only have half of their IPs in your object-gropu. You might even wind up opening access to or from a cable modem system or from another company who bought the IP addresses.
I’ll also note that there aren’t that many domains using this technique, so finding SPF netblock records may be a challenge. It’s worth the time to do a simply query, though; it might save you some time.
Send any carved pumpkins questions my way.
Object Groups in the ASA/FWSM/PIX
Oct 1st
I can’t believe I haven’t talked about object-groups yet. I had a whole other blog entry written up, and, when I went to link things over, I realized I couldn’t find an intro to it. Here it goes.
Welcome to the modern world. A world of wonder. A world of quickly-advancing technology. A world where clusters of machines sit behind load balancers for scalability and availability. A world where those clusters need access to other clusters. A world where your firewall rulebase gets so big that it’s unreadable without some help.
Enough with the drama already. I would say I hate the cheesy stuff, but I think my whole blog is nothing but cheesy stuff, right? To the point. Enterprise firewall configurations can get quite large with ACLs applied in different directions to different interfaces. Our ACL entries number in the 6000 range, but the firewall we’re running says we’re only at 5% utilization in the ACLE memory space. That means that our not-top-of-the-line firewall is designed to handle 120k lines of ACLs. That can be quite a handful to configure by hand. There may be an easier-to-maintain solution, though.
Let’s say you have a cluster of servers behind your CSM that all need to access a database. Since there’s a nice ASA, FWSM, or PIX between the servers and database (as there should be), you have to open up access for this connection. Let’s say that you have four servers with the IPs of 192.168.100.101-104 that need access to 10.10.10.1 on the mySQL port (TCP/3306).
access-list LIST1 permit tcp host 192.168.100.101 host 10.10.10.1 eq 3306 access-list LIST1 permit tcp host 192.168.100.102 host 10.10.10.1 eq 3306 access-list LIST1 permit tcp host 192.168.100.103 host 10.10.10.1 eq 3306 access-list LIST1 permit tcp host 192.168.100.104 host 10.10.10.1 eq 3306
Where are your remarks? Why don’t you document something for once in your life?
Anyway, that’s easy, right. Four configuation lines isn’t so bad, but some of the server admins come to you one day and tell you that the company actually marketed the new web app and that tey are adding 37 more servers to the cluster. Now the 37 new servers need the same rules, right? The server dudes also tell you that, since the app has grown so much, the DBAs have set up a split-read-write scenario where the current database handles the reads and a new database handles the writes. That’s 78 new rules (37 to the old and 41 for the new). That’s a lot of rules.
Object-groups to the rescue. An object-group is a logical group of objects (duh!) that you can use to create ACLEs. You can create a group of hosts, a group of network, or a group of ports. For our example, let’s create an object-group that includes all the hosts in the new huge cluster.
object-group network CLUSTER1 description The Huge Cluster (that's what she said) network-object host 192.168.100.101 network-object host 192.168.100.102 ... network-object host 192.168.100.141
What do we do with it, though? You treat it (almost) just like it was a host in an ACL. Remember we wanted to open access to the old database on TCP/3306, right?
access-list LIST1 permit tcp object-group CLUSTER1 host 10.10.10.1 eq 3306
If you do a show access-list LIST1 now, you’ll see that a new rules has been added for each object in the object-group. It should look something like this.
access-list LIST1 permit tcp object-group CLUSTER1 host 10.10.10.1 eq 3306 access-list LIST extended permit tcp host 192.168.100.101 host 10.10.10.1 eq 3306 (hitcnt=0) access-list LIST extended permit tcp host 192.168.100.102 host 10.10.10.1 eq 3306 (hitcnt=0) ... access-list LIST extended permit tcp host 192.168.100.141 host 10.10.10.1 eq 3306 (hitcnt=0)
Notice that the firewall created 41 rules for you out of your one configured line, but now the rules are indented. The indention means that the rules is generated automagically instead of by hand. Since you can only take out rules that you put in by hand, so you can’t take out the line allowing 192.168.100.123 access; it’s an all-or-nothing scenario. Be aware of that.
You can use object-group for ports, too. Let’s add to our example and say that the cluster will need to access the memcached instance on the database server as well. Those processes run on TCP ports 15000 – 15100.
First we build an object-group for the ports we need.
object-group service DBPORTS description mySQL and memcached ports service-object tcp eq 3306 service-object tcp range 15000 15100
Now let’s apply it to the ACL.
access-list LIST1 permit tcp object-group CLUSTER1 host 10.10.10.1 object-group DBPORT
What does the ACL look like now? Well, it’s a Duesenberg.
access-list LIST1 permit tcp object-group CLUSTER1 host 10.10.10.1 object-group DBPORTS access-list LIST extended permit tcp host 192.168.100.101 host 10.10.10.1 eq 3306 (hitcnt=0) access-list LIST extended permit tcp host 192.168.100.101 host 10.10.10.1 eq 15000 (hitcnt=0) ... access-list LIST extended permit tcp host 192.168.100.101 host 10.10.10.1 eq 15099 (hitcnt=0) access-list LIST extended permit tcp host 192.168.100.101 host 10.10.10.1 eq 15100 (hitcnt=0) ... access-list LIST extended permit tcp host 192.168.100.141 host 10.10.10.1 eq 3306 (hitcnt=0) access-list LIST extended permit tcp host 192.168.100.141 host 10.10.10.1 eq 15000 (hitcnt=0) ... access-list LIST extended permit tcp host 192.168.100.141 host 10.10.10.1 eq 15099 (hitcnt=0) access-list LIST extended permit tcp host 192.168.100.141 host 10.10.10.1 eq 15100 (hitcnt=0)
That’s a lot of ACL entries for one configuration line, isn’t it? Let’s see. 102 ports times 41 servers is 4182 lines in the ACL. You can see how might be to your advantage to use object-groups at times.
Send any candy corn questions my way.
ASA and Proxy ARP
Sep 11th
Wow. A new entry. Everyone sit down before you pass out.
I’ve got a real-world example for you today. We have an ASA 5540 installed at a business unit with interfaces in multiple networks, including one containing the production servers and another containing the accounting servers. The production network sits on a 7600 that’s not ours, so, to avoid IP conflicts, we are statically NATting connections into that network. The 7600 has with many, many VLANs, and, since the firewall production servers are on different VLANs, there’s an interface VLAN between us. Sounds pretty straightforward, but it just wasn’t working when we try to connect between the interfaces.
When we tried to connect from the accounting servers to the production gear, the firewall saw the SYN, built the outbound connection, sent the packet on, and waited. Nothing back. SYN timeout. The vendor on the production side checked the routing. Fine. Checked the ACLs. None installed. When the (other) vendor ran TCPDump on the production servers, they saw the SYN landing and the SYN-ACK leaving, but it never got to the ASA. We even looked at the inline IDS and still didn’t see the SYS-ACK hitting the firewall. It was simply not getting passed on.
I got tired of walking people through stuff over the phone, so I drove up there to see what I could find. When I checked the ARP table on the 7600, I noticed that the statically NATted IP we were serving was conveniently incomplete. For those who don’t know, that means that the 7600 was ARPing for the address, but nothing was answering for it. Obviously, our ASA should be answering, right? To make the situation a little more dire, I did a debug arp (or something close) on the firewall and generated an ARP request; the firewall saw the request but just ignored it. Ugh!
If you couldn’t tell by the title, it turns out that the solution was to enable proxy ARP. It’s off by default for good reason, but here’s how to enable it.
no sysopt noproxyarp PRODUCTIONINTERFACE
Enabling proxy ARP, however, could be a security issue. Any time you use the word “proxy”, there is a potential to spoof addresses, and, in this case, an attacker could (potentially) use the firewall to discover hosts that are on the other side of it. That wouldn’t be good.
A more-secure solution is to use static ARP entries. In our case, we added a static ARP entry on the 7600 that points our NATted IP to the MAC address of the firewall. Now, when you ping the IP, the 7600 doesn’t ARP; it already has the MAC in the ARP table, so it just sends the packet on. Since we only have one static translation in this case, it’s no big deal, but, if we had a whole class-C of addresses to NAT, there would be a management problem.
A part of me wants to do the simple thing and enable proxy ARP, but the vast majority of article, blogs, forums, lists, etc., that I’ve ready say to turn it off for security and efficiency purposes. The more I think about it, though, the more Iwonder why proxy ARP needs to be enabled to make staic NATs work. I looked back at an old PIX running 6.x, and proxy ARP is on by default. The same holds true for an FWSM running 2.x. I’m going to have to ask Cisco what’s up with that.
Send any misconfigured subnet masks questions my way.
Port Forwarding on the ASA/FWSM/PIX
May 27th
Here’s a simple one since I haven’t updated in a while. I have my ASA 5505 at home and want to forward TCP/80 traffic to my public IP to my webserver at 10.10.10.10. There are two steps here — forward the port and open the ACL.
To forward the port, I would use the static directive, but there are two ways to do that. I can either set up a one-to-one NAT or a port redirection. In the one-to-one NAT, you have a outside address that’s mapped directly to an inside address, and any traffic to that IP is passed to the inside host (if it passes ACLS, of course). One of the limitation, though, of using this setup is that you can’t use that IP as your PAT address, and, since I only have one IP, no other inside hosts would have a outside address to which to be NATted. The other method — port redirection — is a much better solution. In this setup, I actually forward a protocol/port on a outside address to a protocol/port on an inside address. Since there are other ports available on that outside address, the address is still available for other hosts to use as a NAT address.
In an enterprise, I would probably use an address out of my pool for the port forwarding, but, since I only have one address at home, I’ve got another decision to make. I can configure the static statement with an IP address or I can use the reserved word interface to indicate the IP that is on an interface. This is a great feature, actually, since my outside IP could potentially change without notice. I’m going to use that feature, too.
static (inside,outside) tcp interface 80 10.10.10.10 80
This is pretty simple, but I’ll explain. The ASA will take any request that comes in on TCP/80 (HTTP) on its outside interface’s IP and forward it to TCP/80 of 10.10.10.10. If my webserver ran on TCP/81 on my box, I could just change the last 80 to 81 to make it work.
The port is redirecting, but I still need to open the ACL. When that’s done, everything should work as expected.
ASA + HSRP/VRRP/GLBP = undef
Apr 4th
I use Google Analytics to track the 2 or 3 hits I get a day, and sometimes I see some interesting search terms. Yesterday, some googled up the term “does the ASA 5505 run HSRP”; I think that deserves a short article.
The ASA and PIX firewalls don’t actually run any of the usual HA solutions you use on routers. They don’t do HSPR, VRRP, or GLBP at all. Since firewalls have all sorts of state tables, connection tables, translation tables, blah, blah, blah, they need to share more information than just if they’re alive or not, so they use different methods to provide HA.
Cisco uses two different methods to handle this issue – a failover cable or a failover interface. On a PIX (above the 501s and 506s), you’ll see a DB-15 interface labelled…wait for it…”failover”. When a very expensive Cisco cable is placed between the failover ports of two PIXes, the boxes do some election stuff over it and decide on an active and a standby state for each (it does all sorts of stuff, but I won’t go into it). The other method is basically the same, but, instead of an expensive, proprietary Cisco cable, it uses one of the interfaces to connect the two. You basically connect a crossover cable between two of them, do some configuration, and we’re good. The ASA doesn’t come with a failover cable so it uses the interface method, but you need a license for that (imagine that).
Just for the record, if an ASA or PIX becomes the active member of the cluster, it takes over both the IP and MAC address of the primary. There’s no election and configuration of a standby address. The use of the real addresses, along with the constant sync of the state data, means a very fast and seamless failover. I actually SSHed through an FWSM (think of it as a PIX on a blade) and pulled the power plugs from it; I actually only lost one packet.
DHCP on the ASA 5505
Apr 2nd
Let’s keep going with our example setup on the ASA 5505 and set up DHCP on this guy. You can set it up to either forward (relay) DHCP requests to a DHCP server somewhere or have it be the DHCP server. Let’s do it.
To set up DHCP forwarding, you have to configure where the DHCP server is and then enable the relaying on the proper interfaces. Let’s say we have a DHCP server on the inside interface at 192.168.14.11 and we want it to serve IPs to the guests network. Setting up the DHCP server is beyond the scope here, so you’ll have to look elsewhere on how to set that up.
dhcprelay server 192.168.14.11 inside
dhcprelay enable guests
Another piece of cake, right?
Setting up the 5505 to be the DHCP server requires a few more lines, but, again, it’s easy. In the simplest setup, you only have to define your DHCP scopes and enable it on an interface. Let’s set up a DHCP scope for the inside interface of 192.168.14.101 – 120.
dhcpd address 192.168.14.101-120 inside
dhcpd enable inside
You probably want to serve a DNS server to the DHCP clients as well. You have two options — you can provide your own DNS server or have the 5505 serve the DNS servers it got from the upstream provider (like your cable modem provider) via DHCP. To serve out your DNS server at 192.168.14.12, just do this.
dhcpd dns 192.168.14.12
Serving the same DNS servers that the firewall got from the provider via DHCP is a little weird. Who puts underscores in commands? Assuming your outside interface is toward your ISP, just do this.
dhcpd auto_config outside
There’s the basics, but you can do all sorts of stuff with it. Change the lease time. Set the default search domain. Set a WINS server. Notice one thing, though; there’s no way to configure a default gateway. The ASA 5505 (and the rest of the 5500 series) only serve their own IPs as the default gateway, so be aware.
Setting Up VLANs on an ASA 5505
Apr 1st
I’ve had my ASA 5505 in place at home on my Comcast cable for a few weeks now, and, let me tell you, this thing rocks. I did, however, have a few problems finding a clear answer on how I could set up my VLANs. It turns out that the base license on the ASA 5505 comes with a few restrictions with regards to VLANning — in particular the number of VLANs and the number of trunks.
When you have the base license and the ASA is in routed mode (you have IPs on interfaces), you can have three VLANs configured. One of them, however, has to be configured to not forward to one of the other VLANs. I had to go over that a few times before I got what the doc was saying. Basically, you have two VLANs that are fully functional and one that can only initiate traffic to one of the others. At home, I consolidated my network down to three VLAN — outside (I’net), inside (Users), and a DMZ (Guests). The inside interface can initiate connections to both outside and the DMZ, but the DMZ can only talk to the outside VLAN. This is probably not a very big deal to an average user, but I’m a network guy and will add networks just to say I’ve got one more subnet than you do. 
I also had some confusion over the number of trunks available on this guy. My Aironet 1231 is set up to tag multiple bridged VLANs to the Ethernet so that I could have multiple SSIDs on it with each in their own VLAN. I did this by making the switch port on the 2950 into a tagged trunk. With the base license on the 5505, you don’t get any trunks. I didn’t find any docs that said you couldn’t, but it’s pretty obvious from the “show version” info.
VLAN Trunk Ports : 0
This really puts a damper on my AP setup. I had to reconfigure it to just use a single, untagged bridged interface with a single SSID. If I wanted to implement the Aironet 1231 the way I had it beforehand, I would have to upgrade my license on the 5505. I’m not paying any more money for this thing, so I’ll have to get one of my lab APs in place for guests. Thank God for eBay.
So, how do you configure this thing? First, let decide on our VLANs — say VLANs 11, 12, and 13. The configuration is just like any PIX 7.X
interface Vlan11
description OUTSIDE
nameif outside
security-level 0
ip address dhcp setroute
!
interface Vlan12
description GUESTS
no forward interface Vlan13
nameif guests
security-level 10
ip address 192.168.13.1 255.255.255.0
!
interface Vlan13
description USER
nameif inside
security-level 100
ip address 192.168.14.1 255.255.255.0
The interface VLANs are what handles the IP addresses. We’ll put specific ports in the VLANs in a minute, so hold tight. The configuration is pretty self-explanatory with VLAN11 being the outside (I’net), VLAN 12 being the DMZ (guests), and VLAN13 being the inside (users). There is, however, the one line that reads no forward interface Vlan13. This is the line that makes dictates which VLAN is a DMZ with respect to the base license and that this VLAN (VLAN12) can’t initiate connections to VLAN13. You also might have noticed the line ip address dhcp setroute. You can read one of the earlier articles on that guy.
The last thing you do is to put ports in VLANs. The ports on the 5505 are labeled Ethernet0/0 – 7, and you treat them just like an IOS switch with the switchport access vlan X command. At home, you would plug your cable modem (or whatever) into one of the interfaces (say, Ethernet0/0) and put that port into VLAN11.
interface Ethernet0/0
switchport access vlan 11
Plug all your stuff in, put the ports in the right VLAN, and enjoy.
Default Route via DHCP on an ASA 5505
Mar 22nd
I finally got my ASA 5505 up and running at the house, but I ran into a little problem — the box wouldn’t add the DHCP-provided default route into its routing table. That one threw me for a loop since the box is made for SOHOs, but it makes sense in some corporate, lazy way.
I got an IP from the DHCPD on the 5505, but I couldn’t get to the Internet. I checked the console, and it had an IP from the provider, so I checked ACLs; those were fine. I looked at the log and found this.
%ASA-6-110002: Failed to locate egress interface for UDP from inside:x.x.x.x/1028 to y.y.y.y/53
I had no clue what this really meant until I checked the routing table; there was no default route at all. For some reason, the ASA 5505 was ignoring the default route from the DHCP server upstream. The fix? Assuming your outside interface is VLAN 1, just do this.
interface Vlan1
ip address dhcp setroute
The box will go out and get the DHCP default route by itself, so no need to shut/no shut.
NAT on a PIX/ASA
Mar 13th
NATting sucks and can be confusing. I’m sure everyone agrees to that, but you have to use it at some times. In a PIX/ASA, it’s easy to configure a simple setup, but can be super-complicated in larger networks. In a simple lab, we have set up an ASA with inside and outside interfaces, with the inside as your internal and outside as the Internet.
The NAT setup here is easy.
nat (inside) 1 0.0.0.0 0.0.0.0
global (outside) 1 interface
This NATs everyone on the inside (0.0.0.0 with a mask of 0.0.0.0, or 0/0) to the IP of the outside interface (overload in the IOS world). The nat command says who gets NATted; the global command says what they get NATted to. Notice the number “1″ in both commands; this is the NAT group and allows you to have some flexibility in your NAT strategy. In essence, if you match a nat line with a “1″ in it, you’ll be matched to a “1″ on the global list.
What if you add a DMZ interface and don’t want to NAT when your inside network talks to it? That, my friend, is a little more complicated. We’ll assume your internal network is 10.0.0.0/24 and your DMZ is 192.168.0.0/24.
access-list NONAT permit ip 10.0.0.0 255.255.255.0 192.168.0.0 255.255.255.0
nat (inside) 0 access-list NONAT
nat (inside) 1 0.0.0.0 0.0.0.0
nat (dmz) 1 0.0.0.0 0.0.0.0global (outside) 1 interface
That was painful, but what did it do? That’s a very good question.
We have multiple nat lines on the inside, so the firewall starts at the top and works its way down (there are exceptions). The first nat line has a group of 0, which is very special. If you match group 0, you are not NATted at all, and your connection is passed as-is with no changes. In our second example, you match if the ACL matches, so, if you’re going from the inside network to the DMZ, you won’t be NATted. If your connection didn’t match this line (like you’re downloading porn from the Internet), the firewall goes to the next line, which says to NAT everyone to group 1 just as we did in the first example.
Another twist here is the “nat (dmz) 1 0.0.0.0 0.0.0.0″ line. This says that anything from the DMZ is NATted to group 1 just as the inside traffic is.
So, if the inside network connects to the DMZ, it doesn’t get NATted. If the inside goes to the Internet, it gets NATted to the outside IP of the firewall. If the DMZ connects to the Internet, it gets NATted to the outside IP as well, but what if the DMZ connects to the inside? That’s another story.
