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
path mtu 1500, ipsec overhead 74, media mtu 1500
current outbound spi: 28DAEB5B
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
Leave a Reply