I wonder if one can convert a Cisco Wireless Controller 2106 into an ASA 5505 or vice versa. It seems to be the same hardware. Anyone that knows if there is any burned-in differences, or is it just a matter of replacing the software?

I will try to swap the CF-card in an ASA5505 with one from an WLC and see what happens. Stay tuned.

ASA5505:

WLC2106:

I think Windows 7 behaves strange with AnyConnect and IPv6

I have recently been doing a lot of ipv6-configurations and as part of that I tried out the ipv6-support in the Cisco Anyconnect-client. While doing that I found out a lack of functionality when it comes to ipv6 in combination with Windows 7 and the Aynconnect-client.

Since I have no native v6-support from my ISP I have an ipv6-tunnel from sixxs.net, providing my with my own /48-prefix network. An internal linux-host on my home networks serves as an ipv6 default-gateway and my home ASA firewall has an ipv6 default-route pointing towards that machine.

I have been abroad for a few days and fooled around with the Anyconnect while wasting time at the hotel room, and what I found out is a bit strange. Windows simply doesnt care about the Aynconnect v6-address when it comes to DNS lookups.

The ASA firewall at home has been configured with an v6-address on the inside interface and a default-route as stated above. I have added an ipv6-pool in addition to the normal ipv4 vpn-pool configured in my DfltGrpPolicy and my VPN-clients gets an v6-address as well as an v4-address:

So I have a Windows7-client with ipv4-only configured on the nic, and dual-stack configured on the tunnel-interface. Look what happens when I try to resolve an hostname that only has an A-record (that is, v4):

The wireshark-capture prooves that only an A-record is resolved:

On the other hand, when I manually resolves an AAAA-record (v6) I get an instant lookup:

And the corresponding wireshark-capture:

Also, when I enter http://[2a00:1450:8001:63] in an browser I get the Google web-page.

So: My client has full connectivity with both v4-internet and v6-internet. Still, I cannot reach v6-internet in a decent way since windows doesnt resolve AAAA-records.

Shouldnt it do lookups of both AAAA and A-record as it would if I had dual stacks configured on the ordinary nick? Is this something wrong in Windows? Or in the Anyconnect-client? Or have I done something wrong?

Enlighten me!

Newer versions of Cisco ASA requires more memory. Running anyconnect with multiple platform support requires more flash-memory than built in. There are memory upgrades available for purchase from cisco.com which I highly recommend. However, for lab-purposes any DDR memory and CompactFlash-card will do. Have a look in my lab gear.

First, an ASA5505. On the overview photo below you can see that it has one single DDR memory-slot (to the far lower right corner on the picture). I have tried both 512Mb-modules and 1Gb-modules and both worked fine. Even if it is not visible from outside there is also an CF-slot. Remove the cover and replace the current CF-module with a bigger. I have tried both 2Gb and 4Gb-modules with success.

Picure of ASA5505 internals. Note the CF-slot in the bottom part and the memory to the right.

Picture of upgraded memory module from an ASA5505

ASA5510 comes in different flavours depending on hardware revision. Older versions have 4 memory slots that needs to be filled with pairs of identical modules. In newer revisions there are only one single memory slot, and I guess (but I am not sure) that it support larger memory modules!

Picture of label on top of an Revision 01 ASA5510.

Picture of an ASA5510 Revision 01 filled with 2x512Mb. Note the disk1: CF-card accessible from outside and the internal disk0: CF-module just adjacent to in in the bottom of the picture.

Picture of the memory-modules I use in an ASA5510 Revision 01.

Picture of an ASA5510 Revision 03-label.

Picture of an Revision 03 ASA5510 with one single memory slot.

Picture of the memory module I use in an ASA5510 revision 03.

Again, remember that third party memory modules are not supported from Cisco. I strongly discourage using non-supported hardware in any production environment!

And one final note: When you replace the CF-module you will notice that your current startup-config as well as the activation-key are gone. To avoid this, take your old original CF-card and put it in your computer. Make sure that your computer shows “hidden files“. Copy all content from the old module (maybe via a folder on your computer if you can only insert one CF at a time) and paste it back to your brand new large CF. And voila, all licensing and config are visible to the ASA! Also. On 5510+ there are double CF-slots: one internal and one external. Replace the external and address it as disk1:, put all large files there and your startup-config as well as hidden files containing your licenses will be untouched on the internal CF-card, addressed as disk0:

To Håkan: This is the memory module I bought. J

Every single decent Cisco-device on earth has the ability to make an CLI-user jump to another device with telnet or ssh. Except the ASA. I really wish that this feature could be added. Right now I am troubleshooting a firewall and from where I am right now the only way in is to SSH to the ASA. I can do whatever I want inside the firewall from my SSH-window, but I need to access a router inside of that firewall, and if this feature wasn´t missing i could simply run “ssh ip-address” to jump to the switch´s CLI.

Am I the last CLI-.guy on this planet? Please, Cisco?

Update: Greg Ferro wrote an reply on this and here are my comments:

This could be divided into several different questions.

1) Should we use SSH to manage the firewall? In my opinion CLI is superior to GUI for most tasks. There are exceptions, but for daily maintenance I prefer CLI for several reasons.  The alternative ASDM-GUI is equally safe/secure because both SSH and ASDM uses encrypted transports and the authentication-part can be configured equally for both entrance-types.

2) From where should we allow maintance of the firewall? Of course the most obvious answer to this is “from somewhere inside, but not from internet”. Sure, I agree. And you SHOULD lock down from which networks/hosts/directions management of the firewall should be enabled, and you SHOULD lock it down as tight as possible. 

But what if you NEED to manage your firewall “from internet”? In most implementations there is some kind of fallback needed so that the administrator can reach the network from abroad and do changes. This can be done in a ton of ways: VPN-client, SSL-portal, Citrix, you name it. The common thing with all these access ways is that they must be enabled “from anywhere”. What´s the point of allowing vpn-client in if you must be at a specific location (from a specific IP) to connect your vpn-client? Or Citrix-session? So this must be enabled from anywhere.

So there are 2 ways to make this “from anywere”-connection secure:

1) It is encrypted. VPN-client-traffic is encrypted. The Citrix access-gateway traffic is encrypted, the VPN-portal is encrypted. And you know what? SSH is encrypted. 

2) Authentication is safe enough. Validation of user rights can be done in a number of ways. Most common is of course username/password, but you can any other method available, from soft tokens and hard tokens to biometry or certificates. And you know what? All these authentication methods can be done for both VPN-clients, all other access method mentioned above, as well as for SSH-traffic.

So, what is it that makes people (not only you Greg ) so stubornly convinced that SSH-access to the firewall should be avoided? I can see no differences in security between SSH and other access methods.

And a final note: the original post was about SSH:ing FROM the device, not to. Following my dialogue with myself above I come to the conclusion that you CAN allow ssh into the device. Given that, what is so unsafe about giving someone that you trust, using a secure connection, the ability to reach the network behind the device? After all, this user has already God access to the firewall and could alter any configuration in the firewall.

Cisco ASA has an built-in dhcp-server that can become handy in some situations. Corporate deployments almost certainly contains one or more servers and especially when it comes to Windows networks I wouldn’t recommend anything else than a proper server-based dhcp-server.

In smaller implementations however, the youngest sibling in the ASA family, 5505 is often the only network equipment on-site and for those purposes the dhcp-server functionality is quite neat.

One feature I miss a lot in ASA dhcp-server is the ability to do static leases. I often get questions like

“We use dhcp for simple mobility of our laptops and uses the ASA dhcp-server at remote locations. But I wanna permit or deny certain traffic for one specific computer, and want to make sure that he/she always gets the same IP. How do I solve this? And by the way, don’t tell me to configure that computer with static IP because then it doesn’t work when the user moves the pc to another network.”

And the simple answer to this is: Sorry, you can’t. Because ASA dhcp-server doesnt do static leases.

Cisco, can we have this feature pretty please with sugar on top?

In my previous post I successfully made ASA-generated traffic go into an VPN-tunnel. The catch with that was that the traffic (in my case: radius) was sources from the interface closest to the destination (outside) and I had to add that traffic to my crypto access-list to make it into the tunnel.

This case inducted an discussion on my favorite ASA mailing-list OSL and with good help from Tyson and the rest of the guys there I understood what I describes below.

Basic setup:


interface Vlan1
nameif inside
security-level 100
ip address 10.10.10.1 255.255.255.0
!
interface Vlan2
nameif outside
security-level 0
ip address 1.2.3.4 255.255.255.0
!
interface Ethernet0/0
switchport access vlan 2
!
interface Ethernet0/1
!
route outside 0.0.0.0 0.0.0.0 1.2.3.1 1
!
aaa-server RAD protocol radius
aaa-server RAD (inside) host 5.6.7.8
key cisco
!


If I wanna talk to the outside radius-server using my outside ip-address I would simply change the “aaa-server RAD (inside) host 5.6.7.8″ above to “aaa-server RAD (outside) host 5.6.7.8″. That is what I did in the previous post and it works. In that post I also prooved that the above config doesn´t work. If the radius-server is on one interface (in my case outside) and the radius-definition points to another interface (inside) there will be no outbound radius traffic generated. Let´s see it again:
ciscoasa(config)#capture inside type raw-data interface inside
ciscoasa(config)#capture outside type raw-data interface outside
ciscoasa(config)#
ciscoasa(config)#test aaa-server authen RAD host 5.6.7.8 user user pass pass
INFO: Attempting Authentication test to IP address <5.6.7.8> (timeout: 12 seconds)
ERROR: Authentication Server not responding: No error
ciscoasa(config)#
ciscoasa(config)# sh capture inside

2 packets captured

1: 23:02:38.662838 802.1Q vlan#2 P0 192.168.2.10.138 > 192.168.2.255.138: udp 201
2: 23:11:22.075618 802.1Q vlan#2 P0 192.168.2.10.138 > 192.168.2.255.138: udp 216
2 packets shown
ciscoasa(config)#

But there is a solution! (Thanks OSL!) And the solution is within the “management-access” command. This is what is written in the configuration guide about the command:

Managing the Security Appliance on a Different Interface from the VPN Tunnel Termination Interface

If your IPSec VPN tunnel terminates on one interface, but you want to manage the adaptive security appliance by accessing a different interface, then enter the following command:

hostname(config)# management access management_interface

where management_interface specifies the name of the management interface you want to access when entering the security appliance from another interface. For example, if you enter the adaptive security appliance from the outside interface, this command lets you connect to the inside interface using Telnet; or you can ping the inside interface when entering from the outside interface.

You can define only one management-access interface.

So, what has this to do with radius-packets? The undocumented secret here is that this command is also used to define a source-interface for outbound packets, for example radius-dito. Look. We add this command:

ciscoasa(config)# management-access inside
ciscoasa(config)#

Next we reset our capture buffers:

ciscoasa(config)# clear capture inside
ciscoasa(config)# clear capture outside
ciscoasa(config)#


…and generates radius-packets…


ciscoasa(config)# test aaa-server authen RAD host 5.6.7.8 user user pass pass
INFO: Attempting Authentication test to IP address <5.6.7.8> (timeout: 12 seconds)
ERROR: Authentication Server not responding: No error
ciscoasa(config)#

Please ignore the fact that there is no answer. There is simply no radius-server in this lab…But, what happened in our captures.

ciscoasa(config)# sh capture inside

1: 23:49:06.205433 802.1Q vlan#2 P0 10.10.10.1.1025 > 5.6.7.8.1645: udp 62
2: 23:50:39.478994 802.1Q vlan#2 P0 192.168.2.10.138 > 192.168.2.255.138: udp 201
2 packets shown
ciscoasa(config)#


Hey! Look at that packet, #1 on outside! It is sources from out inside ip, destined to our radius-server on outside, and sent out on our outside interface. And it is a radius-packet (udp 1645). Cool!

Conclusion: With the management-access interface you can select the source ip for packets generated from the ASA, for example radius.

So we have 3 different parameters for this traffic that controls the source address and/or destination interface:

1. Routing-entry. In our example 5.6.7.8 is beyond another router and we have an outbound default route. Without that the device would never know in which direction to send the traffic.
2. The interface-relation in the aaa-server-command. See below.
3. The “management-interface”-command that can be used to configure the source ip.

But how about #2. That interface-definition bothered me already in my last post. Why does it exist?

It surely isn´t used to define the source interface/address because above I proove that it is the addition of the “management-access”-command that makes all the differ. Before adding that there was no packets sent out on outside when the radius-server was defined as “(inside)”.

And at the same time, it is not being used to define the outbound interface. This is being done with the routing-table. And as we see above stating (“inside”) doesn´t make the packet go out on interface inside.

So, my officially question to Cisco is: Why is there an mandatory parameter to the aaa-server command that makes me define “the name of the network interface where the designated AAA server is accessed“?

Recently I got an request from a Cisco ASA customer who wanted to authenticate VPN-users with a remote Radius-server. Using Radius is piece of cake, but those of us that have been working with Cisco Pix/ASA for a while know that traffic to/from the box is no nearly treated the same way as traffic going thru the box. And this customer wanted to use a Radius-server via an Lan2Lan-tunnel that terminates in the same ASA-box.

So. Does it work? First of all I built a small little lab with 2 ASA:s connected back to back and an Lan2Lan-tunnel connecting the both inside networks. Plain vanilla.

Topology:

Relevant parts of ASA1 config:

ASA Version 8.2(1)
!
hostname ASA1
!
interface Vlan1
nameif inside
security-level 100
ip address 192.168.1.234 255.255.255.0
!
interface Vlan2
nameif outside
security-level 0
ip address 192.168.169.1 255.255.255.0
!
interface Ethernet0/0
switchport access vlan 2
!
interface Ethernet0/1
!
access-list crypto-acl extended permit ip 192.168.1.0 255.255.255.0 192.168.2.0 255.255.255.0
access-list OUTSIDE extended permit ip any any
no nat-traversal
route outside 0.0.0.0 0.0.0.0 192.168.169.2 1
!
crypto ipsec transform-set tset esp-aes esp-sha-hmac
!
crypto map cmap-outside 10 match address crypto-acl
crypto map cmap-outside 10 set peer 192.168.169.2
crypto map cmap-outside 10 set transform-set tset
crypto map cmap-outside interface outside
crypto isakmp enable outside
crypto isakmp policy 10
authentication pre-share
encryption aes
hash sha
group 5
lifetime 86400
tunnel-group 192.168.169.2 type ipsec-l2l
tunnel-group 192.168.169.2 ipsec-attributes
pre-shared-key cisco
!


And ASA2:
ASA Version 8.2(1)
!
hostname ASA2
!
interface Vlan1
nameif inside
security-level 100
ip address 192.168.2.1 255.255.255.0
!
interface Vlan2
nameif outside
security-level 0
ip address 192.168.169.2 255.255.255.0
!
interface Ethernet0/0
switchport access vlan 2
!
interface Ethernet0/1
!
access-list crypto-acl extended permit ip 192.168.2.0 255.255.255.0 192.168.1.0 255.255.255.0
!
crypto ipsec transform-set tset esp-aes esp-sha-hmac
!
crypto map cmap-outside 10 match address crypto-acl
crypto map cmap-outside 10 set peer 192.168.169.1
crypto map cmap-outside 10 set transform-set tset
crypto map cmap-outside interface outside
crypto isakmp enable outside
!
crypto isakmp policy 10
authentication pre-share
encryption aes
hash sha
group 5
lifetime 86400
!
tunnel-group 192.168.169.1 type ipsec-l2l
tunnel-group 192.168.169.1 ipsec-attributes
pre-shared-key cisco


So, this configuration connects the inside networks over the unsecure network 192.168.169.0/24. But what if ASA1 wanna talk radius to the ACS-server 192.168.2.10 beyond ASA2?

First of all, the way of configuring an aaa-server in ASA is in my opinion a bit confusing. It´s all about pointing out the server ip-address together with a radius key. But if we look at the syntax for defining a radius-server we see that we also need to define an interface. Whatfor?


ASA1(config)# aaa-server GROUPTAG protocol radius
ASA1(config-aaa-server-group)# aaa-server GROUPTAG ?
configure mode commands/options:
( Open parenthesis for the name of the network interface
where the designated AAA server is accessed
deadtime Specify the amount of time that will elapse between the
disabling of the last server in the group and the
subsequent re-enabling of all servers
host Enter this keyword to specify the IP address for the
server
max-failed-attempts Specify the maximum number of failures that will be
allowed for any server in the group before that server
is deactivated
protocol Enter the protocol for a AAA server group
ASA1(config-aaa-server-group)# aaa-server GROUPTAG


So, we need to specify an interface. The reason that I think this is a bit weird is that there should already be a route in the routing-table for our radius-server 192.168.2.10. If nothing else, there is probably an default route, and in our case there is definately one. So why stating that “in order to reach 192.168.2.10 go via interface outside” in the radius-definition? I have no idea. A few moment I thought of this not as a way to specify outbound interface but source interface. What if I wanna send the radius packets to outside (according to routing table, with or without an vpn-tunnel) but use the inside interface ip as source? That would be cool, because then I didn´t have to add anything in the crypto acl (see below). This is still untested, but when we look at the syntax help above it certanly states “for the name of the network interface where the designated AAA server is accessed”, which of course is outside in my example.

So, lets add the radius definition. And what else? We need to add traffic to the crypto acl for making it go into the vpn tunnel. And since it is traffic from the ASA1 outside interface to the host 192.18.2.10 behind ASA2, that is what we add:

ASA1 – addition:

access-list crypto-acl extended permit ip host 192.168.169.1 host 192.168.2.10
aaa-server RAD protocol radius
aaa-server RAD (outside) host 192.168.2.10
key cisco


and ASA2 – addition:

access-list crypto-acl extended permit ip host 192.168.2.10 host 192.168.169.1


And, as a proof that this works we use the “test aaa”-command to generate an radius authentication request from ASA1 to the Radius-server.


ASA1(config)# test aaa authentication RAD host 192.168.2.10 username user pass$
INFO: Attempting Authentication test to IP address <192.168.2.10> (timeout: 12 seconds)
INFO: Authentication Successful
ASA1(config)#
ASA1(config)#
ASA1(config)# sh crypto ipsec sa
interface: outside
Crypto map tag: cmap-outside, seq num: 10, local addr: 192.168.169.1

access-list crypto-acl permit ip host 192.168.169.1 host 192.168.2.10
local ident (addr/mask/prot/port): (192.168.169.1/255.255.255.255/0/0)
remote ident (addr/mask/prot/port): (192.168.2.10/255.255.255.255/0/0)
current_peer: 192.168.169.2

#pkts encaps: 1, #pkts encrypt: 1, #pkts digest: 1
#pkts decaps: 1, #pkts decrypt: 1, #pkts verify: 1
#pkts compressed: 0, #pkts decompressed: 0
#pkts not compressed: 1, #pkts comp failed: 0, #pkts decomp failed: 0
#pre-frag successes: 0, #pre-frag failures: 0, #fragments created: 0
#PMTUs sent: 0, #PMTUs rcvd: 0, #decapsulated frgs needing reassembly: 0
#send errors: 0, #recv errors: 0

local crypto endpt.: 192.168.169.1, remote crypto endpt.: 192.168.169.2

inbound esp sas:
spi: 0x53870178 (1401356664)
transform: esp-aes esp-sha-hmac no compression
in use settings ={L2L, Tunnel, }
slot: 0, conn_id: 24576, crypto-map: cmap-outside
sa timing: remaining key lifetime (kB/sec): (3914999/28682)
IV size: 16 bytes
replay detection support: Y
Anti replay bitmap:
0x00000000 0x00000003
outbound esp sas:
spi: 0x28DAEB5B (685435739)
transform: esp-aes esp-sha-hmac no compression
in use settings ={L2L, Tunnel, }
slot: 0, conn_id: 24576, crypto-map: cmap-outside
sa timing: remaining key lifetime (kB/sec): (3914999/28682)
IV size: 16 bytes
replay detection support: Y
Anti replay bitmap:
0x00000000 0x00000001


So, what happens if we follow my idea that the interface-relation within the radius-configuration was not a way to define outbound interface but instead a way to define source address for our radius packets. Well, let´s try. We have already a working tunnel between our LAN:s, so if we reconfigure ASA1 to use inside instead, that traffic (from 192.168.1.234 to 192.168.2.10) should already be included in our proxy acl so nothing else should be needed. Lets try:


ASA1(config)# sh run aaa-server
aaa-server RAD protocol radius
aaa-server RAD (outside) host 192.168.2.10
key cisco
aaa-server GROUPTAG protocol radius
ASA1(config)#
ASA1(config)# clear configure aaa-server RAD
ASA1(config)#
ASA1(config)# aaa-server RAD proto radius
ASA1(config-aaa-server-group)# aaa-server RAD (inside) host 192.168.2.10
ASA1(config-aaa-server-host)# key cisco
ASA1(config-aaa-server-host)#
ASA1(config-aaa-server-host)# end
ASA1#


ok, let´s give it a shot!
ASA1# test aaa authentication RAD host 192.168.2.10 username user password cis$
INFO: Attempting Authentication test to IP address <192.168.2.10> (timeout: 12 seconds)
ERROR: Authentication Server not responding: No error
ASA1#
ASA1#
ASA1# test aaa authentication RAD host 192.168.2.10 username user password cis$
INFO: Attempting Authentication test to IP address <192.168.2.10> (timeout: 12 seconds)
ERROR: Authentication Server not responding: No error
ASA1#
ASA1# test aaa authentication RAD host 192.168.2.10 username user password cis$
INFO: Attempting Authentication test to IP address <192.168.2.10> (timeout: 12 seconds)
ERROR: Authentication Server not responding: No error
ASA1#


It obviously doesnt work. But what happened?
ASA1# sh crypto ipsec sa
There are no ipsec sas
ASA1#

Ok, so no tunnels triggered. But this really mean that the radius packets were sent to inside instead of outside? Lets capture packets!
ASA1# capture OUTSIDE interface outside
ASA1# capture INSIDE interface inside
ASA1#
ASA1# test aaa authentication RAD host 192.168.2.10 username user password cis$
INFO: Attempting Authentication test to IP address <192.168.2.10> (timeout: 12 seconds)
ERROR: Authentication Server not responding: No error
ASA1#
ASA1#
ASA1# sh capture OUTSIDE

0 packet captured

0 packet shown
ASA1# sh capture INSIDE

17 packets captured

1: 03:45:53.705194 802.1Q vlan#1 P0 arp who-has 192.168.1.213 tell 192.168.1.1
2: 03:45:58.704019 802.1Q vlan#1 P0 arp who-has 192.168.1.213 tell 192.168.1.1
3: 03:46:03.702844 802.1Q vlan#1 P0 arp who-has 192.168.1.213 tell 192.168.1.1
4: 03:46:03.968089 802.1Q vlan#1 P0 arp who-has 192.168.1.213 tell 192.168.1.1
5: 03:46:05.702340 802.1Q vlan#1 P0 arp who-has 192.168.1.213 tell 192.168.1.1
6: 03:46:06.702112 802.1Q vlan#1 P0 arp who-has 192.168.1.213 tell 192.168.1.1
7: 03:46:08.335904 802.1Q vlan#1 P0 192.168.1.203.57621 > 255.255.255.255.57621: udp 44
8: 03:46:10.277665 802.1Q vlan#1 P0 192.168.1.72.17500 > 255.255.255.255.17500: udp 176
9: 03:46:10.278244 802.1Q vlan#1 P0 192.168.1.72.17500 > 192.168.1.255.17500: udp 176
10: 03:46:10.701150 802.1Q vlan#1 P0 arp who-has 192.168.1.213 tell 192.168.1.1
11: 03:46:14.292892 802.1Q vlan#1 P0 192.168.1.107.138 > 192.168.1.255.138: udp 201
12: 03:46:15.699976 802.1Q vlan#1 P0 arp who-has 192.168.1.213 tell 192.168.1.1
13: 03:46:15.806858 802.1Q vlan#1 P0 192.168.1.73.138 > 192.168.1.255.138: udp 201
14: 03:46:17.743522 802.1Q vlan#1 P0 192.168.1.203.17500 > 255.255.255.255.17500: udp 172
15: 03:46:17.745795 802.1Q vlan#1 P0 192.168.1.203.17500 > 255.255.255.255.17500: udp 172
16: 03:46:17.746146 802.1Q vlan#1 P0 192.168.1.203.17500 > 192.168.1.255.17500: udp 172
17: 03:46:17.746512 802.1Q vlan#1 P0 192.168.1.203.17500 > 255.255.255.255.17500: udp 172
17 packets shown
ASA1#
ASA1#


What we see above is that there is absolutely no packets at all seen on ASA1 outside interface. On inside interface we see various packets (because that is my home network), but no radius packets.

So, what are our conclusions?

• Traffic generated from the ASA can very well be included in our Lan2Lan-tunnel so that for example the ASA can have a secure connection to an remote authentication server.
• The interface-definition in the aaa-server command has nothing to do with source addresses. As a matter of fact, you cannot configure a source interface/address for radius-traffic the way you can do in an IOS-router.
• The interface-definition shouldnt really be needed. The way to the remote server is pointed out by the routing table. The interface-definition must point the same direction as the routing-table, otherwise the ASA won´t know where to send the packets.
• I was wrong
• I can tell the customer that we can do radius over vpn.

am I missing something here? Please don´t hesitate to comment!

Update: I was missing something. Look at my update post…

/Jimmy

 I am a true Cisco ASA-guy. I eat, live and sh…. ASA:s. I have been working with Cisco gear since forever and the first Cisco Firewall I configured was a Cisco 520 with floppy.

Nevertheless, I also know some stuff about other firewalls. I have been working with iptables, Watchguards, Symantec/Raptor/whatever and installed a few Checkpoints. Actually I am certified CCSA and CCSE for checkpoint firewall. Still I try to avoid them. The reason is simple. They are complex, there is only 24h available per day and there are people that know checkpoint better than I do.

Whatever firewall I run into I compare them to ASA:s. I cant avoid it because it is ASA:s that I know by heart. And I have for a while tried to understand the complexity of load-distribution of Checkpoint clusters. Then I run into this incredible blog post by Greg Ferro at etherealmind.com. And There Was Light.

Instead of trying to explain it again half as good as the original I simply suggest anyone interrested in Checkpoint or other firewalls technology of load sharing to read the blog post above. It is great!

ASA:s doesnt do load balancing(*). A “cluster” can contain only two members and it is always(*) a active/passive solution where the passive member is a hot-standby. It is not as near as sophisticated as the Cluster XL-solution from Checkpoint. But it it simple. And rock solid. If you want to “keep it simple, stupid” the ASA failover-solution is your setup if you ask me. 

It would be interresting to do a cost analysis and compare the cost of purchasing equal setups of ASA:s and Checkpoint-wirewalls for a specific thruput/size. I am already quite sure that it way cheaper to buy one ASA that is big enogh to handle the thruput needed, and one hot-spare, than buying 2 Checkpoint-units with the same performance.

(*) Yes, there is an active/active-solution from Cisco. But it requires multi context. And unless you have need for multiple virtual firewalls you cant make both hardware units in the cluster processing traffic at the same time.

Thanks for the most informative blog post this year, Greg Ferro!

Cisco Pix/ASA hairpinning

The term hairpinning comes from the fact that the traffic comes from one source into a router or similar devices, makes a U-turn and goes back the same way it came.
Visualize this and you see something that looks like a hairpin.

Hairpinning is only relevant when the firewall is in routed mode since the “turnaround” of traffic is a routing decision. Also there needs to be another router
involved. If the firewall is setup to only pass traffic between interfaces no hairpinning will be taking place. Typical hairpinning is done when there is a router
inside of the firewall beyond which there is another network that needs to be reached to/from the inside network. See picture:

Another fundament for hairpinning taking place is that not all network equipment has full knowledge of the network topology. Typically these are computers with only
a default route (“default gateway”) to something but not aware of the fact that the remote network is reachable directly via the other router without taking the path
via the firewall (see picture above). If the computer had that knowledge it would never involve the firewall.
A workaround like this could be in a windows-host to add “route -p 192.168.2.0 mask 255.255.255.0 192.168.1.2″ from the command prompt. However this is in most cases
not very flexible since it is a manual work at each host.

ver 6.x and prior

No hairpinning was possible. The historic reason for this was that the fact that interfaces with the same security-level was not allowed to exchange traffic was a
security fature. If you needed to isolate two interfaces from each other (but allow each of them to talk to other interfaces) you could give them the same security-
level and by design there was no traffic allowed between these interfaces no matter of access-list, nat or conduit-configuration. Unfortunately this also meant that
since traffic in an out thru the same interface was per definition “same security-level”, no hair-pinning was possible.

ver 7.0

The command “same-security” was introuduced with this version. The purpose with this command was to override the isolation between interfaces with the same
security-level. The command has 2 parameters: “permit-inter-interface” that allows traffic between different interfaces with same security-level and “permit-intra-
interface” that allows traffic thru the same interface, aka hairpinning. However, with this version the intra-interface-parameter was only functional for vpn-
traffic, for example traffic from an outside vpn-client destined to internet (full tunneling).

ver 7.2

Beginning with v7.2 the “same-security permit-intra-interface”-command becomes useful and can be used for other traffic than vpn-initiated. Now we can do hair-
pinning. So, what is needed? First of all, the “same-security permit -intra-interface”. Also we need to allow inbound traffic if we have an access-list applied
inbound on the interface. Let´s have another look at our example:

In this example we have one host at 192.168.1.100 using the firewall .1 as default gateway. The firewall has a route for the 192.168.2.0/24-network via 192.168.1.2
and the route is directly connected to both networks. Because of this configuration the traffic from 192.168.1.100 is hair-pinned back, to the router.


interface Vlan1
nameif inside
security-level 100
ip address 192.168.1.1 255.255.255.0
!
route inside 192.168.2.0 255.255.255.0 192.168.1.2 1
!
same-security-traffic permit intra-interface
!
no nat-control


All magic lies in the “same-security-traffic”-command. In the example above we have no access-list applied. If we have we must also open for that traffic:


access-list acl_inside extended permit ip 192.168.2.0 255.255.255.0 192.168.1.0 255.255.255.0
access-list acl_inside extended permit ip 192.168.1.0 255.255.255.0 192.168.2.0 255.255.255.0
access-list acl_inside extended deny ip any any
!
access-group acl_inside in interface inside


We most likely has a NAT/global configured for the inside network to be able to reach internet. If we add this to our example we kill our hair-pinning:


nat (inside) 1 0.0.0.0 0.0.0.0
global (outside) 1 interface


Now, when we try to ping from 192.168.1.100 to 192.168.2.200 we get this log output of the firewall:


%ASA-3-305006: portmap translation creation failed for icmp src inside:192.168.1.100 dst inside:192.168.2.200 (type 8, code 0)
%ASA-3-305006: portmap translation creation failed for icmp src inside:192.168.1.100 dst inside:192.168.2.200 (type 8, code 0)
%ASA-3-305006: portmap translation creation failed for icmp src inside:192.168.1.100 dst inside:192.168.2.200 (type 8, code 0)
%ASA-3-305006: portmap translation creation failed for icmp src inside:192.168.1.100 dst inside:192.168.2.200 (type 8, code 0)
%ASA-3-305006: portmap translation creation failed for icmp src inside:192.168.1.100 dst inside:192.168.2.200 (type 8, code 0)


As soon as we add ANY nat-configuration for an interface we must configure nat for all traffic from that interface, even hairpinned traffic. We do this with the static-command below. The purpose of this is to “static” translate traffic from interface “inside” to interface “inside” where the source is “192.168.1.0″ (netmask 255.255.255.0 and translate the source to “192.168.1.0″ (the same address). We also do the same for the 192.168.2.0-network to ensure that traffic can flow initiated in both directions.


static (inside,inside) 192.168.1.0 192.168.1.0 netmask 255.255.255.0
static (inside,inside) 192.168.2.0 192.168.2.0 netmask 255.255.255.0


The compilation of relevant configuration lines in the firewall to ackomplish this is shown here:


hostname fw
!
interface Vlan1
nameif inside
security-level 100
ip address 192.168.1.1 255.255.255.0
!
interface Vlan222
nameif outside
security-level 0
ip address dhcp setroute
!
boot system disk0:/asa725-k8.bin
!
same-security-traffic permit intra-interface
!
access-list acl_inside extended permit ip 192.168.2.0 255.255.255.0 192.168.1.0 255.255.255.0
access-list acl_inside extended permit ip 192.168.1.0 255.255.255.0 192.168.2.0 255.255.255.0
access-list acl_inside extended deny ip any any
!
nat-control
!
global (outside) 1 interface
nat (inside) 1 0.0.0.0 0.0.0.0
!
static (inside,inside) 192.168.1.0 192.168.1.0 netmask 255.255.255.0
static (inside,inside) 192.168.2.0 192.168.2.0 netmask 255.255.255.0
!
access-group acl_inside in interface inside
!
route inside 192.168.2.0 255.255.255.0 192.168.1.2 1


Ver 8.3

In this version the nat-concept is totally rewritten with a new command syntax. More about this can be read about elsewhere, but the technique is the same. This is the converted version of the configuration snippet above:


hostname fw
!
interface Vlan1
nameif inside
security-level 100
ip address 192.168.1.1 255.255.255.0
!
interface Vlan222
nameif outside
security-level 0
ip address dhcp setroute
boot system disk0:/asa831-k8.bin
!
same-security-traffic permit intra-interface
!
object network obj-192.168.1.0
subnet 192.168.1.0 255.255.255.0
object network obj-192.168.2.0
subnet 192.168.2.0 255.255.255.0
object network obj_any
subnet 0.0.0.0 0.0.0.0
object network obj_any-01
subnet 0.0.0.0 0.0.0.0
object network obj-0.0.0.0
host 0.0.0.0
!
access-list acl_inside extended permit ip 192.168.2.0 255.255.255.0 192.168.1.0 255.255.255.0
access-list acl_inside extended permit ip 192.168.1.0 255.255.255.0 192.168.2.0 255.255.255.0
access-list acl_inside extended deny ip any any
!
object network obj-192.168.1.0
nat (inside,inside) static 192.168.1.0
object network obj-192.168.2.0
nat (inside,inside) static 192.168.2.0
object network obj_any
nat (inside,outside) dynamic interface
object network obj_any-01
nat (inside,outside) dynamic obj-0.0.0.0
!
access-group acl_inside in interface inside
!
route inside 192.168.2.0 255.255.255.0 192.168.1.2 1


Assymetric routing

An issue with the configuration above is that since the firewall is stateful (which means that it keeps track of TCP-states) and the fact that traffic in one direction goes via the firewall (from 192.168.1.100 to 192.168.2.200) but the traffic in the other direction goes direct makes the firewall going bananas. If the traffic initiates from the 1-network all is fine since the firewall allowes the initial packet and never sees the return traffic. It might build a quite large list of incomplete sessions that eventually will time out, but it will work:

However, when the traffic is initiated from the 2-network the first packet that will be seen by the firewall is the second (SYN-ACK) which is not very appreciated.

Beginning with version 8.2 there is a solution for this in the “tcp state bypass”-functionality. By using this you can with MPF (modular policy framework) specify traffic that should not be handled stateful. Here is an example of doing that.
Genereally my solution to hairpinning- and/or assymetric routing-issues is to avoid it. If you have one or more routers in your topology it is probably a good idea to use that router as the default gateway instead and only direct traffic to the firewall that should pass it. The drawback from this is that internet-traffic needs to go via the router instead. However this seldom causes any trouble since the router is not stateful and has no issues with doing hairpinning.

Another solution if you need to pass WAN-traffic thru the firewall (for security reasons) can be to put the WAN-router(s) on a dedicated firewall interface.

Conclusion

Hairpinning of traffic in Cisco Pix/ASA and problems with assymetric routing can be a pain. There are workarounds but mostly assymetric issues are symptoms of bad network design rather than configuration issues.
There are more dimensions of hairpinning than just internal traffic turning around to a WAN-router. Such a common example is U-turning of VPN-traffic, for example traffic from an VPN-client going via the firewall out to internet or into another vpn-tunnel. Or spoke-hub-spoke VPN-traffic. This type of traffic seldom gives routing or assymetric issues but is more a matter of defining proxy ACL:s for vpn-traffic and not doing NAT on that traffic.

You know how it is? You are typing so fast making changes in you cisco gear you not always pay attention to which mode you are in? Doing config-command in exec-level, exec-commands in config-level and adding “do” in front just to make them pass? Wanna know if that happens to fast and you are in the wrong place doing the wrong time?

Below I am in system context of a multi context ASA firewall. My intention is to do something with a context. I go into config mode and then into the context definition of the context I wanna change. What if I get interrupted or whatever and enter the “conf t”-command in the context configuration mode?


act# sh mode
Security context mode: multiple
act#
act# conf t
act(config)# context LEFT
act(config-ctx)# conf t
INFO: Converting t to disk0:/t
.
WARNING: Could not fetch the URL disk0:/t
INFO: Creating context with default config
INFO: Admin context will take some time to come up .... please wait.
act(config-ctx)#


Congrats! Your firewall is gone!