You are currently browsing articles tagged ASA.

As a matter of personal preference, I was never a HUGE fan of the ASA as a firewall appliance.  For VPN termination, it’s pretty slick but still has some issues.  Either way, I have a 5505 at home that I use for firewall and VPN.  Being bored some time ago (wish I had free time now) I decided to upgrade the device from 8.2 to 9.1 code.  Along with this change came the dreaded ASA 8.3 NAT configuration change.  I’d argue that NAT on the ASA never made true sense, but once you knew how it worked, you could make it do what you wanted it to do.  Not knowing how to configure the new mode of NAT in the CLI, I decided to try it through ASDM (this of course breaking my ‘ASDM is awful never use it’ rule (and yes, I know you have to use ASDM for some of the AnyConnect XML stuff)).  The ASDM configuration lead to the automagic creation of NAT groups I didn’t need, object groups I didn’t need, and ACLs I didn’t need.  Somehow I managed to click enough buttons that it worked, but I wasn’t happy with the end state of the config. 

Fast forward to now.  Now I want to be able to connect to VPN at my house, access local resources, as well as access the internet through my local Comcast connection (internet hairpin).  Thinking this would be straight forward, I pulled down a copy of my ASA config into notepad and realized that it was full of random stuff I didn’t need.  After some clean up, I came to some realizations about NAT on the newer ASA code.  Namely, the fact that you don’t HAVE to use the NAT configuration under the objects themselves.  This, at least for me, was a HUGE help.  Let’s take a quick look at my config so you can see what I’ve setup…


So the real goal here is to be able to access a hosting container I use out on the internets from my laptop.  The hosting container only allows certain IP addresses (my home IP) to access it.  So if I could VPN to my house and use my home internet connection to access the hosting space from my laptop, I’d be all set!

In order to accomplish this, you need to do some ‘weird’ NAT configuration. I’m not going to run through my whole ASA config, but here are the important pieces…

hostname ASA
ip local pool vpn mask
interface Ethernet0/0
switchport access vlan 2
interface Ethernet0/1
interface Ethernet0/2
interface Ethernet0/3
interface Ethernet0/4
interface Ethernet0/5
switchport access vlan 3
interface Ethernet0/6
interface Ethernet0/7
switchport access vlan 3
interface Vlan1
nameif inside
security-level 100
ip address
interface Vlan2
nameif outside
security-level 0
ip address <removed>
interface Vlan3
no forward interface Vlan1
nameif guest
security-level 50
ip address
boot system disk0:/asa911-k8.bin
same-security-traffic permit intra-interface
object network guest
object network locallan
object-group network VPNPOOL
nat (outside,inside) source static VPNPOOL VPNPOOL
nat (outside,outside) source dynamic VPNPOOL interface
nat (inside,outside) source dynamic locallan interface
nat (guest,outside) source dynamic guest interface
route outside <removed> 1
route inside 1
telnet inside
telnet timeout 1440
ssh timeout 5
console timeout 0
management-access inside
dhcpd address inside
dhcpd dns interface inside
dhcpd enable inside
dhcpd address guest
dhcpd dns interface guest
dhcpd enable guest
enable outside
anyconnect image disk0:/anyconnect-macosx-i386-2.5.2017-k9.pkg 1
anyconnect image disk0:/anyconnect-win-2.5.3055-k9.pkg 2
anyconnect profiles vpn disk0:/vpn.xml
anyconnect enable
group-policy DfltGrpPolicy attributes
vpn-idle-timeout none
vpn-tunnel-protocol ikev1 l2tp-ipsec ssl-client ssl-clientless
group-policy gp_anyconnect internal
group-policy gp_anyconnect attributes
dns-server value
vpn-tunnel-protocol ikev2 ssl-client
split-tunnel-policy tunnelall
split-tunnel-network-list value splitvpn
  anyconnect profiles value vpn type user
  anyconnect ask none default anyconnect
username <removed> password <removed>
tunnel-group tg_vpn type remote-access
tunnel-group tg_vpn general-attributes
address-pool vpn
default-group-policy gp_anyconnect
tunnel-group tg_vpn webvpn-attributes
group-url <removed> enable

Lot’s of config there, but I want to focus on are the bolded lines.  The first bolded line is what tells the ASA to allow the ‘hairpin’ to occur.  Specifically, you are telling the ASA with this command that it’s ok for traffic to come in a interface with a certain security level (0) and leave through an interface with an identical security level (0).  This allows VPN traffic to come in the outside interface encrypted, and leave back out the outside interface to get to the internet. 

The next 4 bolded lines are the NAT configuration.  This is what I’m really interested in…

nat (outside,inside) source static VPNPOOL VPNPOOL
nat (outside,outside) source dynamic VPNPOOL interface
nat (inside,outside) source dynamic locallan interface
nat (guest,outside) source dynamic guest interface

Let’s line these statements up on our diagram to give you a visual of what’s actually going on…


The first NAT statement tells the ASA to allow the client space in from the outside interface to the inside interface and to not modify the addresses.  This allows my VPN pool (tail end of my to talk to the Local LAN space. 


The second NAT statement tells the ASA to take the VPN client space in the outside interface, back out the outside interface, but to dynamically overload it to the outside interface IP.  This is the actual NAT hairpin configuration that allows a VPN client to come in the outside and then leave back out towards the internet with the NAT overload.  



The last two NATs are simple dynamic overloads for the Local LAN and the Guest LAN network.  This allows both RFC 1918 spaces to be hidden behind the outside interface of the ASA.

Not really a ton too it actually, but I did struggle initially with the NAT until I figured out I could do it without defining the NAT under the object group itself.

Tags: , ,

So I ran into another interesting problem today at work.  The solution was interesting to me so I thought I’d do a quick write up on it.  As many people know, firewalls (ASAs in particular) handle ICMP traffic a little differently than most would expect.  When doing a tracert from a linux box through a firewall I was something like this…

[root@CentosBox ~]# traceroute -I
traceroute to (, 30 hops max, 40 byte packets
1  <removed Internal MLS> 0.471 ms  0.879 ms  1.061 ms
2  <removed ASA>  0.680 ms  1.340 ms  1.320 ms
3  * * *
4  * * *
5  * * *
6  * * *
7  * * *
8  * * *
9 (  44.674 ms * *

What’s interesting here is that it started to miss hops in the middle, but then suddenly arrived at the destination and replied.  What confused me even more was that I could successfully ping  After reviewing the firewall I noted that ICMP inspection was enabled.  My thought with ICMP inspection was that it would inspect ICMP (traceroute included) and allow it out and back in.  After some further investigation I determined that this wasn’t the case. 

ICMP inspection allows a one to one connection.  That is, it allows one response for one request.  In addition, it apparently doesn’t play well with ICMP time-exceeded messages.  So now this makes sense.  The first couple of hops work but once I get past the firewall the time-exceeded messages don’t get allowed back in with the inspection.  To fix this, you need to explicitly allow it on the outside interface.  I added….

access-list inbound extended permit icmp any any

Or if you want to be more specific with it you could do…

access-list inbound extended permit icmp any any unreachable
access-list inbound extended permit icmp any any time-exceeded
access-list inbound extended permit icmp any any echo-reply

Once you add those, you should see…

[root@CentosBox ~]# traceroute -I
traceroute to (, 30 hops max, 40 byte packets
1  <removed Internal MLS> 0.471 ms  0.879 ms  1.061 ms
2  <removed ASA>  0.680 ms  1.340 ms  1.320 ms
3 (  15.812 ms  16.264 ms  16.243 ms
4  <removed hop>  17.192 ms  17.173 ms  17.172 ms
5  <removed hop>  16.126 ms  17.095 ms  17.080 ms
6  <removed hop>  19.412 ms  17.651 ms  17.586 ms
7  <removed hop> 33.128 ms  32.470 ms  32.329 ms
8 (  35.257 ms  76.288 ms  76.307 ms
9 (  35.666 ms  36.134 ms  35.172 ms
10 (  48.745 ms  49.005 ms  48.986 ms
11 (  47.844 ms  46.955 ms  46.828 ms
12 (  74.307 ms  73.806 ms  73.662 ms
13 (  45.573 ms  44.733 ms  41.836 ms
[root@CentosBox ~]#

So that was the fix.  There are a couple of other commands I added to make traceroute through the ASA seem more normal…

Allows the ASA to show as a hop and decrement the TTL
policy-map global_policy
   class class-default
      set connection decrement-ttl
Allows the ASA to respond with traceroute statistics when it’s on its hop.
icmp unreachable rate-limit 10 burst-size 5



Despite having done this many many times.  I still manage to not exactly recall all of the steps to load a software image onto a ASA in ROMMON mode.  Today I had to do it again and managed to muddle my way through it using the ‘help’ commands.  However, I neglected to recall that ping doesn’t work even after you assign the IP and interface.  That fact lead to an hour of needless troubleshooting as I tried to determine why the ASA couldn’t ping my laptop over a crossover cable.  So here we go….

Boot the ASA into ROMMON
Press break or escape key during boot

Configure the ASA with the information it will need to connect to the TFTP Server
You should now be at a ‘rommon #1>’ prompt.  When Im doing a process like this I usually directly connect my laptop to the ASA with a crossover cable.  That being said, I only need to enter in the following commands….

rommon #1> ADDRESS=<The IP you want to give the ASA>
rommon #2> SERVER=<The IP of the TFTP Server>
rommon #3> IMAGE=<The file name of the image you want to load>
rommon #4> PORT=<The port that you have the crossover plugged into>

This is all of info you need if the connection is layer 2.  If your TFTP server is somewhere else on the LAN, you can use the ‘GATEWAY=<Default Gateway>’ command to set a default gateway

Copy the image
At this point all you have to do is enter in one last command to start the copy….

rommon #5> tftp

After the copy is complete, the ASA will load the new software image and you should be back in business!


« Older entries