Never say it can't be done

I have recently come across a fairly simple task, that as decidedly difficult to figure out how to implement on the Cisco ASA, multiple external IPs NAT'd to a single internal IP.

A google search will bring up several forums in which the consensus is that it can't be done:

"There is no way the device would allow you to have 2 public ip to point to the same internalip."

That's not correct, sadly if you call tier 1 Cisco support they will give you the same answer. The issue is how the ASA performs various NATs:

static - This is a bi-directional NAT that is used for traffic to the host and from the host
static (inside,outside) public-ip internal-ip netmask 255.255.255.255

nat (pat) - This is for traffic FROM the host only, traffic cannot be initiated TO the NAT IP
nat (inside) 1 inside-ip
global (outside) 1 outside-ip

The issue is that the static is bi-directional, so the ASA will not let you add two statics since this would cause a conflict for outgoing traffic.

Now, I refused to accept the answer "it can't be done"...I refuse to believe that Checkpoint..the peak of early 90's technology can do this..yet the ASA cannot. So I escalated.

I was right it can be done, and here is how:

Given two Public IPs: 200.100.30.40 & 200.100.30.41
Given one Private IP: 10.10.10.1

First, you create an ACL for each NAT:

access-list nat1 extended permit ip host 10.10.10.1 any
access-list nat2 extended permit ip host 10.10.10.1 any

Now you create that static NAT statement:

static (inside, outside) 200.100.30.40 access-list nat1
static (inside, outside) 200.100.30.41 access-list nat2

NOTE: Traffic generated FROM the inside will always get NAT'd to the first static entry.

You can verify by doing a show xlate:

Global 200.100.30.41 Local 10.10.10.1
Global 200.100.30.40 Local 10.10.10.1

Cisco Nexus gear

We recently installed a Nexus 5020 with 12 2048T Fabirc Extenders (FEX). This will become the core switching environment for our new network. These are some pretty sweet switches with some wicked cool features. Some of the nice features:

• Unified Fabirc - Allows IP and Native SAN over the same infrastructure.
  
• VMWare intergration - Allowes the creation of VM network profiles that can travel with the VM.
  
• Multi-switch Etherchannel - On the Nexus it's refered to as Virtual Port Channel (vPC)
• No Spanning Tree - Can be either a plus or minus..but for us its simplifies in our current deployment.
  

For all of the good features there are a few gotcha's that we ran into:

• FEX ports are GigE...only...don't even think of doing 10/100
• 5020 has limited GigE....16 ports are GigE the remaing 32 are 10Gig
• vPC limits the number of Etherchannel ports per FEX to ONE

One of the interesting things we ran into with this system was configuring TACACS+ for authentication. Normally it's pretty straight foreward you define TACACS servers & the key..bam you're good to go. For the nexus it's slightly different:

1. Enable TACACS on the system:

switch (config)# feature tacacs+

2. Add TACACS+ servers:

switch (config)# tacacs-server host 12.123.34.5

3. Add TACACS+ Key:

switch(config)# tacacs-server key

4. Add authentication group:

swith (config)# aaa group server tacacs+ tacplus

5. Add Server to auth group:

switch (config-tacacs+)# server 12.34.56.7

6. set AAA to use the tacplus group:

switch (config)# aaa authentication login default group tacplus

7. Log it on the tacacs server:

switch (config)# aaa accounting default group tacplus

8. Finally, this line was needed for our set-up:

(config)# aaa authentication login ascii-authentication

So far, fairly pleased with the Nexus. We aren't doing anything too cutting edge, but our set-up on the Nexus cost considerably less than a comparable 6509 configuration. Obviously, there are pros & cons to each set-up so your mileage may vary based on the requirements for your specific deployment.

ASA, ASDM, and longevity

I have spent the last several day cleaning up firewall configurations. These were brand new, out of the box firewalls and in less than a year their configuration was utter crap. I blame this on two things the administrator and the ASDM gui.

I blame the administrator, for relying soley on the GUI and operating under the impression that it doesn't matter how the changes are made. Let me assure you...it does.

I blame the ASDM GUI for all of the extraneous crap that it puts in the configuration. Some are due to the administrator not using it correctly, and some of it is just the way the GUI works.

Let me just give a few do's and don'ts to ASA management:

1. DO use object-groups in rules. Let's face it, it's easier to update one object-group than multiple rules.
2. DO use descriptive names for object-groups and access-lists. When troubleshooting it's much easier when you know what things are.
3. DO NOT accept the default names the GUI assignes for anything. It is for this reason that I have object-groups like DM_INLINE_NETWORK_1, interfaces name OUTSIDE_VPN_VLAN999, and access-list named OUTSIDE_VPN_VLAN999_access_in

Now, there are few other tips I have, these are really dependent on your site...but I find them to be pretty standard:

DO NOT use interface access-lists for your VPNs:

I've seen this done at several places, and honestly I don't know why. This actually introduces a new risk..especially if public IPs are used on both ends of the tunnel.What happens if the tunnel configuration is removed, but the ACL is not? The traffic will go out the interface unencrypted.

DO use VPN filters to apply ACLs to VPNs:

group-policy tunnel-name-filter internal
group-policy tunnel-name-filter attributes
vpn-filter value access-list-name

tunnel-group peer-ip general-attributes
default-group-policy tunnel-name-filter

Now, if we use descriptive names...we can tell which ACLs pertain to which tunnels.

DO NOT use names in the configuraiton:

no names

This is really just a preference, but when troubleshooting I like to be able to run the command 'sh access-list | in 12.234.45.6' and get all rules associated with that host. If I have names, I would first need to resolve that host to the name configured and then search for the name.

What happens if the hostname has changed or the host is known by several names?

DO AUDIT your firewall periodically:

Now, if you've followed the tips I've laid out auditing should be able to breeze. Simply capture the output from 'show access-list'. It's in cvs delimited format with the [space] as the delimiter. You can easily import into EXCEL.

Now if your object-group names are descriptive...you should be able to tell what each rule is for and since the object-groups are expanded..you can verify all of the IPs that have access. You can annotate the excel with the any POC information for a set of rules, justifications, etc.. that you will need during your audit.

In my experience by following these tips, you will have a firewall that is easy to manage for years to come. Troubleshooting issues is simpler, since you can visually distinguish what ACLs and object-groups apply.

I have to thank my mentor at Sun Sam Munzani, who casually mentioned these tips to me as he handed off some ASA firewalls. It was immediately clear the genius behind it the first time I had to audit the firewall. It was also amazingly simple to troubleshoot issues.