Recently we tried to join an Cisco ISE instance to Active Directory without success. The problem seemed to be because of the length of the ISE host name. Even though the system supports host names up to 19 characters long, we couldn’t add the ISE to AD until we shortened the name to be maximum 14 characters.

Another one of those undocumented “features” that I wish I have read about before getting stuck. I wish this short post is indexed so that other people find out and gets a push in the right direction because of it.

Hello

I am currently working on a task (INE CCIE Security WB 1 Task 2.9) where I am supposed to configured an radius-based IOS auth-proxy. The task is this:

Configure Authentication PRoxy settings on R3 per the following requirements.

• US the radius server at 10.0.0.100 with the authentication key CISCO.
• The authentication proxy should apply to the users sessions initiated from VLAN23 towards VLAN13.
• Authentication users should be allowed to send ICMP packets and initate TCP sessions.
• Configure the ACS server with the user named PROXY and the password of CISCO1234.

In ACS I have added the R3 as AAA client (Cisco IOS Radius). I have also added the user PROXY with the following cisco av pair´s:


auth-proxy:priv-lvl=15
auth-proxy:proxyacl#1=permit icmp any any
auth-proxy:proxyacl#1=permit tcp any any

 
In R3 I have added the following config:


aaa new-model
aaa authen login CON none
line con 0
login authen CON
aaa authen login default group radius
aaa author auth-proxy default group radius
!
ip http server
ip http authen aaa
ip auth-proxy name AUTHPROXY http
!
ip access-l ext INBOUND
permit udp any any eq rip
permit tcp any host 136.1.23.3 eq www
deny ip any any log
!
int fa0/1.23
ip access-group INBOUND in
ip auth-proxy AUTHPROXY

 
This is what happens when I fire up a browser and http´s to the R3 interface:
 
(debug aaa authen, aaa author, auth-proxy and radius is on)
 

Rack1R3#
*Jan 3 01:15:40.229: AUTH-PROXY:proto_flag=4, dstport_index=4
*Jan 3 01:15:40.229: SYN SEQ 984706124 LEN 0
*Jan 3 01:15:40.229: dst_addr 136.1.23.3 src_addr 136.1.23.123 dst_port 80 src_port 1103
*Jan 3 01:15:40.237: AUTH-PROXY:proto_flag=4, dstport_index=4
*Jan 3 01:15:40.237: ACK 4057202766 SEQ 984706125 LEN 0
*Jan 3 01:15:40.237: dst_addr 136.1.23.3 src_addr 136.1.23.123 dst_port 80 src_port 1103
*Jan 3 01:15:40.241: AUTH-PROXY:proto_flag=4, dstport_index=4
*Jan 3 01:15:40.241: PSH ACK 4057202766 SEQ 984706125 LEN 282
*Jan 3 01:15:40.241: dst_addr 136.1.23.3 src_addr 136.1.23.123 dst_port 80 src_port 1103
Rack1R3#
*Jan 3 01:15:40.245: Router interested packet returning src 136.1.23.123, dst 136.1.23.3
*Jan 3 01:15:40.257: AUTH-PROXY:proto_flag=4, dstport_index=4
*Jan 3 01:15:40.261: ACK 4057202967 SEQ 984706407 LEN 0
*Jan 3 01:15:40.261: dst_addr 136.1.23.3 src_addr 136.1.23.123 dst_port 80 src_port 1103
Rack1R3#
Rack1R3#! I fired up IE, entered the url and it is now showing a login prmpt "level_15 or view_access"
Rack1R3#
Rack1R3#! I enter the credentials PROXY/CISCO1234 and hit enter...
Rack1R3#
Rack1R3#
*Jan 3 01:16:52.743: AUTH-PROXY:proto_flag=4, dstport_index=4
*Jan 3 01:16:52.743: FIN ACK 4057202967 SEQ 984706407 LEN 0
*Jan 3 01:16:52.743: dst_addr 136.1.23.3 src_addr 136.1.23.123 dst_port 80 src_port 1103
*Jan 3 01:16:52.748: AUTH-PROXY:proto_flag=4, dstport_index=4
*Jan 3 01:16:52.748: SYN SEQ 1525595421 LEN 0
*Jan 3 01:16:52.748: dst_addr 136.1.23.3 src_addr 136.1.23.123 dst_port 80 src_port 1104
*Jan 3 01:16:52.756: AUTH-PROXY:proto_flag=4, dstport_index=4
*Jan 3 01:16:52.756: ACK 2275096303 SEQ 1525595422 LEN 0
*Jan 3 01:16:52.756: dst_addr 136.1.23.3 src_addr 136.1.23.123 dst_port 80 src_port 1104
*Jan 3 01:16:52.756: AUTH-PROXY:proto_flag=4, dstport_index=4
*Jan 3 01:16:52.760: PSH ACK 2275096303 SEQ 1525595422 LEN 325
*Jan 3 01:16:52.760: dst_addr 136.1.23.3 src_addr 136.1.23.123 dst_port 80 src_port 1104
*Jan 3 01:16:52.764: Router interested packet returning src 136.1.23.123, dst 136.1.23.3
*Jan 3 01:16:52.772: AAA/BIND(00000006): Bind i/f
*Jan 3 01:16:52.772: AAA/AUTHEN/LOGIN (00000006): Pick method list 'default'
*Jan 3 01:16:52.776: RADIUS/ENCODE(00000006):Orig. component type = HTTP
*Jan 3 01:16:52.776: RADIUS/ENCODE(00000006): dropping service type, "radius-server attribute 6 on-for-login-auth" is off
*Jan 3 01:16:52.776: RADIUS(00000006): Config NAS IP: 0.0.0.0
*Jan 3 01:16:52.776: RADIUS/ENCODE(00000006): acct_session_id: 4
*Jan 3 01:16:52.776: RADIUS(00000006): sending
*Jan 3 01:16:52.776: RADIUS/ENCODE: Best Local IP-Address 10.0.0.3 for Radius-Server 10.0.0.100
*Jan 3 01:16:52.780: RADIUS(00000006): Send Access-Request to 10.0.0.100:1645 id 1645/4, len 71
*Jan 3 01:16:52.780: RADIUS: authenticator 63 22 AD D4 03 CA 91 6C - 71 F8 27 E9 70 12 2A 18
*Jan 3 01:16:52.780: RADIUS: User-Name [1] 7 "PROXY"
*Jan 3 01:16:52.784: RADIUS: User-Password [2] 18 *
*Jan 3 01:16:52.784: RADIUS: NAS-Port-Type [61] 6 Virtual [5]
*Jan 3 01:16:52.784: RADIUS: Calling-Station-Id [31] 14 "136.1.23.123"
*Jan 3 01:16:52.784: RADIUS: NAS-IP-Address [4] 6 10.0.0.3
*Jan 3 01:16:52.796: RADIUS: Received from id 1645/4 10.0.0.100:1645, Access-Accept, len 181
*Jan 3 01:16:52.796: RADIUS: authenticator 4E 80 7B 47 1A 03 96 83 - BA 01 FE 83 9E A6 BB A6
*Jan 3 01:16:52.800: RADIUS: Framed-IP-Address [8] 6 255.255.255.255
*Jan 3 01:16:52.800: RADIUS: Vendor, Cisco [26] 30
*Jan 3 01:16:52.800: RADIUS: Cisco AVpair [1] 24 "auth-proxy:priv-lvl=15"
*Jan 3 01:16:52.800: RADIUS: Vendor, Cisco [26] 49
*Jan 3 01:16:52.800: RADIUS: Cisco AVpair [1] 43 "auth-proxy:proxyacl#1=permit icmp any any"
*Jan 3 01:16:52.800: RADIUS: Vendor, Cisco [26] 48
*Jan 3 01:16:52.804: RADIUS: Cisco AVpair [1] 42 "auth-proxy:proxyacl#2=permit tcp any any"
*Jan 3 01:16:52.804: RADIUS: Class [25] 28
*Jan 3 01:16:52.804: RADIUS: 43 41 43 53 3A 30 2F 31 37 34 39 66 2F 61 30 30 [CACS:0/1749f/a00]
*Jan 3 01:16:52.804: RADIUS: 30 30 30 33 2F 50 52 4F 58 59 [0003/PROXY]
*Jan 3 01:16:52.808: RADIUS(00000006): Received from id 1645/4
*Jan 3 01:16:52.812: AAA/AUTHOR (00000006): Method list id=0 not configured. Skip author
*Jan 3 01:16:54.815: AUTH-PROXY:proto_flag=4, dstport_index=4
*Jan 3 01:16:54.815: ACK 2275096504 SEQ 1525595747 LEN 0
*Jan 3 01:16:54.815: dst_addr 136.1.23.3 src_addr 136.1.23.123 dst_port 80 src_port 1104
Rack1R3#
Rack1R3#! ... and the browser give me another login prompt...
Rack1R3#
Rack1R3#

 

See those lines in bold? What is happening here? They are not in the output from the solution guide. The “radius-server attribute 6 on for login-auth”-message can be tweaked away with a specific command but why should that be neccesary? And what about “AAA/AUTHOR Metod list id=0 not configured. Skip author”, that feels like a fatal error. But I do have “aaa authorization auth-proxy default group radius”-command.
 
Anyone?

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

 I while ago I got into a discussion with one of my customers regarding ipv6. He told me that one reason not to migrate to ipv6 was for security. 

- I dont want to tell the entire world what IP addresses I have on my servers. And when using ipv4 and NAT my internal ip addresses are hidden.

The discussion was interrupted and I didnt get any chance to finish it. 

When using private ipv4-addresses on your LAN i can assume that you have any of these addresses:

• 10.0.0.0/8
• 172.16.0.0/12
• 192.168.0.0/16

So, how many addresses do you have to choose from? Lets count (roughly!):

• 10.0.0.0/8, that is 256 * 256 * 256 addresses, 16 777 216 available addresses
• 172.16.0.0/12, that is 16 * 256 * 256 addresses, 1 048 576
• 192.168.0.0/16, that is 256 * 256 addresses, 65 536.

That gives us a total sum of 17 891 328 available addresses. That´s a lot, isnt it?

But what if you get yourself a nice little pool of ipv6-addresses? For various reasons we can be pretty sure that you will get a /48 network from your ISP. Then you will probably divide this into one or many /64-networks on your internal LAN. So, how many addresses are there available?

First of all, dividing that /48-range into /64-subnets will give you 65536 different available networks. Next, an ipv6-address is 128 bits long. With 64 bits for specifying the network part you will have 64 bits left for addressing each individual host on your internal network. And 64 bits gives us 18446744073709551616 unique combinations. So that is how many addresses you have available in each subnet when using ipv6.

So, if you see it as a security benefit to hide your sensitive servers addresses, which do you prefer? ipv4 or ipv6?

If a hacker would portscan your ipv6-range, how long will it take? Lets assume that he scans 100 addresses per second, then it will take him 5 849 424 173 years(*). And that should be compared to the 50 hours it will take to port scan all private ipv4-addresses mentioned above.

And besides. That attack would probably be performed from internet. How many public ipv4-addresses do you have? It will be enough to portscan them. 100 addresses per seconds, you do the math.

/Jimmy

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