And the "inside" interface is not the one that terminates you ipsec-tunnel?
/Jimmy 2011/4/17 Andrei Lucian Coman <[email protected]> > 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 >> ------- >> > > -- ------- 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
