BiDirectional NAT on a Cisco PIX or ASA
Thursday, June 29, 2006 at 03:30PM
Mike Storm
Cisco PIX/ASA Security - Bidirectional NAT with DMZ Interfaces
It is time to get rid of that pesky ALIAS command!
If any of you have ever dealt with a Cisco PIX or ASA appliance with at least one DMZ interface that contains a public resource (like a web server) that users on the inside also need to access directly by URL – you might have used the PIX alias command to make it happen. This presents several problems and with some of the built in limitations of the PIX ‘Finesse’ Operating System and ASA, the PDM or ASDM GUI and the fact that everyone seems to use DNS in different ways, lots of security administrators struggle with figuring out how to make bidirectional NAT work properly in their environment.
One of the biggest issues, is that Cisco has decided to deprecate the alias command, both in version 6.3 and version 7x (which still works great BTW, as long as you don’t care to use PDM or ASDM to manage your PIX or ASA device) and suggests using bidirectional NAT…this is great….if only….we had some documentation to show us how to do it….not to mention the fact that bidirectional NAT normally refers to the use of OUTSIDE NAT in the (NAT RFCs) and doesn’t really relate at all to how the PIX is using it.
Let me start by giving some background on why I am even bringing this up and then I’ll show you a few solutions that will let you follow your security policy to a ‘T’ (Incidentally, multi-homing your web server, such that it has both a DMZ interface and an Inside network interface for internal user access, is NOT an acceptable solution! DUH! If you are going to do this, go ahead and remove the PIX completely because it is not doing you any good! By doing this, you’ve already decided to bypass it using the most vulnerable system in your entire architecture! DUH! Good Job!)
Note: This content applies to both PIX/ASA version 6.x and 7.x
Background and Setup
So, you have a perimeter network that may look something like this: Note the trust sec-level on the PIX/ASA interfaces…
In this case we are focused on the public WWW Server on the Protected DMZ (172.16.1.100) and its virtual counterpart on the Screened DMZ (51.88.80.100). Our goal is to allow internal users to access this system using the URL of www.abccorp.com. Keep Reading…
Imagine that your DNS architecture is separated into both an internal zone (int.abccorp.com) and your Internet-based external zone (abccorp.com) and your DMZ WWW server is a public resource. Having said this, the PIX will likely be configured with both a static and an ACL which allows external port 80 access to the WWW server on the protected DMZ by using the virtual address:
static (dmz,outside) 51.88.80.100 172.16.1.100 netmask 255.255.255.255
access-list inbound permit tcp any host 51.88.80.100 eq 80
access-group inbound in interface outside
In addition, you will have a nat and global set which allows inside users to access the dmz and the outside (Internet) environment: (we won’t worry about direct DMZ access to the Internet for now, since it really doesn’t apply to the content of this blog…)
nat (inside) 1 0.0.0.0 0.0.0.0
global (outside) 1 51.88.80.10
global (dmz) 1 172.16.1.10
Here is where the problems lie, and why we have had to use the alias command in the past:
Currently with this config, users have no problem accessing the Internet from the inside. They also have no problem accessing the DMZ systems by IP address, as long as they are using 172.16.1.x as their target. The problem is when an internal user accesses www.abccorp.com. Most companies that use an Internal/External DNS environment will point their client systems to the inside DNS (maybe a DC or other server) that is answering for (in our example) int.abccorp.com. If an address is not resolved by this internal DNS, the internal DNS server, which normally points to either root hints or another external system with visibility to the registered abccorp.com which contains an A entry for www, will now recursively look up www.abccorp.com and return a response to the client of 51.88.80.100 (a key here is the recursive query sourced from the internal DNS server versus an external DNS request sourced directly from the client, where DNS fixup on the PIX could have been used to solve this problem. I’ll talk about that in another blog)
Thus, in our example, if an internal user attempts access to www.abccorp.com, eventually external DNS returns the address 51.88.80.100 (the external NAT address of our target web server) and this is the address our client PC will attempt to use to access the DMZ WWW server.
Rule: The PIX ASA has a built-in rule that states that only two interfaces can ever be involved in any legitimate conversation (a security thing). However, since the request for the web server comes initially from a user in the 10.1.1.x network (inside), and the user is trying to access the DMZ 172.16.1.100 by the resolved 51.88.80.100 (outside) suddenly all three interfaces are involved on the PIX appliance. This violates the rules and is denied by the PIX.
The alias command was designed to allow requests sourced from an internal client to be ‘address flipped’ by the PIX on the inside interface, thus not breaking the “two-interface” rule:
alias (inside) 51.88.80.100 172.16.1.100 255.255.255.255
This alias states that if the PIX receives a request for 51.88.80.100 on the inside interface (the result of the above DNS architecture) flip the target address in the request to 172.16.1.100 so that the DMZ WWW server can be accessed directly. This works great…and our trusted user is ‘none-the-wiser’ about anything even happening…they are just happy to access their own web server by URL. (Of course you could ‘try’ to train your users that while they are at work, our web server is accessed by 172.16.1.100, but everywhere else in the world they should use www.abccorp.com ...yeah RIGHT, good luck trying to get that to make sense to your users!) So that is what the alias command was designed to fix. And it works…STILL….
But…if you are one of those admins that likes to use PDM or ASDM from time-to-time to add/remove options or monitor your PIX, you have probably received the message about the alias command not being supported anymore and you should use bidirectional NAT instead. Yep, now we are getting to what we came here for. How do you implement Bidirectional NAT on the PIX? Check Cisco’s website and you will find TONS of references to it, BUT, nowhere do they show you how to implement it on a multi-DMZ PIX. (Which, if I am not mistaken, is just about the de facto standard for how most businesses implement public resources in a perimeter network. hmmm)
Bidirectional NAT Solution:
Before you start, realize that we will not be changing any of our current statics, or our ACLS, or our NAT/Global pairs at all. We will simply be removing our alias, and creating the new Bidirectional NAT solution.
Our solution involves the creating of an additional static for our target system…yep, that’s it! Nothing more. Most of the time however, our statics follow the rule of IN-OUT-OUT-IN, that is: static (‘inside-int’, outside-int’) ‘outside-global address’ ‘inside-local address’. We have to “flip it’ to make Bidirectional NAT do its job. There are two ways to flip it…either dmz, inside or outside,dmz.
Either one will do the trick. Depending upon your DNS architecture…one may be more consistent for you than the other. I use the second option for my network due to my DNS structure.
Here are the possible solutions:
static (dmz,inside) 51.88.80.100 172.16.1.100 255.255.255.255
or
static (outside,dmz) 172.16.1.100 51.88.80.100 255.255.255.255
You will notice that what has been ‘flipped’ in the first static is the interface names in the parenthesis only, where in the second static both the interface names and the addresses have been flipped. Either solution is valid, depending upon your DNS architecture or whether or not you use remote access / site-to-site VPNs. Try ‘em both and see which one is more consistent for your perimeter implementation. That’s it!!!
