This is my topology: CS-ACS server <--> Local ASA <-- IPSec tunnel --> Remote ASA
Maybe it's version-dependant, but in this topology, with ASA OS 8.2(2) or 8.2(4), and with the configuration outlined in my previous email, I'm looking in the CS-ACS server access logs and I see the requests coming from the remote ASA inside interface. Andrei On Sun, Apr 17, 2011 at 8:31 PM, Jimmy Larsson <[email protected]> wrote: > > Sorry, I dont follow. Whats your topology? > > Are you saying that you can source your tacacs+-packets from another > interface than the one closest to the tacacs+-server? And thru a vpn-tunnel? > Because my experience so far is that you cannot choose source-interface in > any way. But i´d very much like to be over-conviced. :-) > > /Jimmy > > 2011/4/17 Andrei Lucian Coman <[email protected]> > >> Hey guys, >> >> I have two ASA's in a production networks configured with the same >> requirement: one of the ASA should authenticate with a tacacs+ server >> located behind the other ASA, using the existing IPSec tunnel between the >> ASA's. This is how they both are configured: >> >> management-access inside >> aaa-server CS-ACS protocol tacacs+ >> aaa-server CS-ACS (inside) host 192.168.254.10 >> >> I think that "management-access inside" makes the difference. I'm pretty >> sure that this works, because: >> >> 1. Looking at the CS-ACS passed authentication logs, I can see the >> authentication requests coming from the inside interface of the remote ASA. >> 2. The remote ASA falls back to local authentication when the WAN link is >> down. >> >> Can someone test this in a lab? >> >> >> Andrei Lucian Coman >> >> >> On Thu, Apr 14, 2011 at 11:36 PM, Andrew Wurster < >> [email protected]> wrote: >> >>> oh true i forgot about that aaa server interface. that specifies the >>> interface to egress to reach the aaa server. so yes in your case specify >>> the outside interface there and also that interface's address in your crypto >>> acls and you should be golden. i am 99.9% sure you need to specify both of >>> those things using the outside interface. >>> >>> keep us posted. >>> On Apr 14, 2011 12:59 PM, "Jimmy Larsson" <[email protected]> wrote: >>> > Cool! This is mu gut feeling aswell, but I have never tried it. One >>> question >>> > is regarding the interface-relation when defining a radius-server. If I >>> look >>> > at the ASA-syntax it saids: >>> > >>> > ciscoasa(config)# aaa-server RAD ? >>> > >>> > 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 >>> > >>> > In my world there is really no need for defining an interface for this >>> since >>> > it´s "all about routing". Given that the radius-server ip is x.x.x.x >>> and >>> > there is a rout for x.x.x.x, why defining an interface? My own feeling >>> about >>> > this is that this is for defining the source ip for outbound radius >>> packets. >>> > But looking at the syntax help above the interface-relationship is only >>> a >>> > way to define where to send the traffic (which in my world could be >>> done >>> > just by using the routing table). >>> > >>> > So you are saying that I should define my remote radius-server as >>> (outside)? >>> > Another hypothesis I had (if I were right regarding the >>> interface-definition >>> > above) was to use (inside) so that the radius-packets were sourced from >>> the >>> > inside ip and thereby included in the "normal" crypto-acl defining >>> > inside-LAN-2-Inside-Lan (and sending it via outside only because of the >>> > default route). >>> > >>> > Two theories. Mine is probably wrong. I will also lab it up quite soon >>> if >>> > noone else here knows for sure. ;) >>> > >>> > Thanks for your input! >>> > >>> > /Jimmy Larsson >>> > >>> > >>> > 2011/4/14 Andrew Wurster <[email protected]> >>> > >>> >> jimmy - >>> >> >>> >> as bruno said - it's possible :) . >>> >> >>> >> think about it from a routing perspective. know that the crypto >>> happens as >>> >> the traffic is pushed towards the egress interface (post nat). this is >>> true >>> >> for routers and firewalls, but on firewall we choose the local address >>> based >>> >> on routing only, so we usually have no "source address" or looback >>> interface >>> >> selection commands like we do on the routers (think local-address for >>> the >>> >> crypto map commands in IOS). >>> >> >>> >> SO... you're most likely going to assume it will be sourced using the >>> >> outside interface IP address. so all you've got to do is add the >>> traffic >>> >> between ASA1's outside interface IP address to the internal radius >>> server >>> >> behind ASA2. AND THEN of course you've got to tell your SNMP server >>> that >>> >> the client is at the public outside interface IP address (for instance >>> >> 20.20.20.20) and not the private inside one. AND ALSO if you're doing >>> NAT - >>> >> make sure to exempt the NAT from the SNMP server to the new host >>> address. >>> >> it's all about the layers baby!!! >>> >> >>> >> so it might look something like: >>> >> >>> >> !!! ASA1 !!! >>> >> access-list CRYPTO_ACL extend permit ip host 20.20.20.20 host >>> 192.168.2.10 >>> >> >>> >> !!! ASA2 !!! >>> >> access-list CRYPTO_ACL extend permit ip host 192.168.2.10 host >>> 20.20.20.20 >>> >> access-list NO_NAT extend permit ip host 192.168.2.10 host 20.20.20.20 >>> >> >>> >> and bingo bango (hopefully)... give it a shot and let us know. i'll >>> try to >>> >> lab it up for you this weekend if i have time. >>> >> >>> >> cheers, >>> >> >>> >> andrew >>> >> >>> >> On Thu, Apr 14, 2011 at 11:36 AM, Jimmy Larsson <[email protected] >>> >wrote: >>> >> >>> >>> Hi guys >>> >>> >>> >>> I have a question that I have tried to find time to lab out myself >>> without >>> >>> success so I am throwing it out here in hope for a quick answer. >>> >>> >>> >>> Lets say that my ASA1 has a Lan2Lan-tunnel to ASA2. On the inside of >>> ASA2 >>> >>> is a radius-server and ASA1 needs to authenticate vpn-clients on that >>> radius >>> >>> server. Can I do that thru the vpn-tunnel? And if so, how do I define >>> the >>> >>> crypto acl and which interface should I specify in ASA1 that the >>> >>> radius-server resides on? >>> >>> >>> >>> Topology: >>> >>> >>> >>> Radius-server .10 on Lan2 192.168.2.0/24 -----(.1) ASA2 >>> =====VPN-tunnel >>> >>> over internet=====ASA1 .1 --- Lan1 192.168.1.0/24 >>> >>> >>> >>> How do I configure aaa-server for radius on ASA1? >>> >>> >>> >>> Thanks in advance! >>> >>> >>> >>> Best regards >>> >>> Jimmy Larsson >>> >>> >>> >>> >>> >>> -- >>> >>> ------- >>> >>> Jimmy Larsson >>> >>> Ryavagen 173 >>> >>> s-26030 Vallakra >>> >>> Sweden >>> >>> http://blogg.kvistofta.nu >>> >>> ------- >>> >>> >>> >>> _______________________________________________ >>> >>> For more information regarding industry leading CCIE Lab training, >>> please >>> >>> visit www.ipexpert.com >>> >>> >>> >>> >>> >> >>> > >>> > >>> > -- >>> > ------- >>> > Jimmy Larsson >>> > Ryavagen 173 >>> > s-26030 Vallakra >>> > Sweden >>> > http://blogg.kvistofta.nu >>> > ------- >>> >>> _______________________________________________ >>> For more information regarding industry leading CCIE Lab training, please >>> visit www.ipexpert.com >>> >>> >> > > > -- > ------- > Jimmy Larsson > Ryavagen 173 > s-26030 Vallakra > Sweden > http://blogg.kvistofta.nu > ------- >
_______________________________________________ For more information regarding industry leading CCIE Lab training, please visit www.ipexpert.com
