ASA-generated traffic – part2

 

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

0 packet captured

0 packet shown
ciscoasa(config)# sh capture outside

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

0 packet captured

0 packet shown
ciscoasa(config)# sh capture outside

2 packets captured

 

 

 

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“?


Tagged with: ,
Posted in Uncategorized
6 comments on “ASA-generated traffic – part2
  1. Henning says:

    Okay, I have a slightly different question for you. I use the older Cisco VPN client to loginto ASA #1, and wish to authenticate  through a Site2Site VPN tunnell towards a Radius server behind ASA #2. I’ve got successful authentication from the command line (using test aaa-server …), but debug and packet capture show absolutely nothing when I try to authenticate using the Cisco VPN client from outside ASA #1… Any clues?

    • The only clue I can give without seeing the actual config is that if test aaa-server works, your L2L-tunnel and AAA-definition is working. Sounds more like you have a misconfiguration when it comes to authentication of vpn-clients. Ie. You have a working aaa server-group, but is it really applied and in use when the client tries to connect?

      /Jimmy

  2. Mo says:

    great article.

  3. MarlinDal says:

    хакер форумы лучшие – услуги хакера форум, форум хакеров россии

  4. vgxqqozy says:

    side effects of cialis price of cialis cialis super active

Leave a Reply to MarlinDal Cancel reply

Your email address will not be published.

*

Signuppp

[mc4wp_form id="2457"]
Website Security Test