perhaps the management-access might help. not every feature on the ASA has a source interface option though...
i believe i had a situation once where i had to send SNMP traps across a L2L tunnel, that required crypto ACL modifications as stated earlier in the thread. maybe the management-access would have helped in that case too, but i would have to lab it up though to confirm. and to clarify for jimmy, i believe we've got about 3 different scenarios so far on this thread :) . also, in reading the feature guide, i do not see any specification on *sourcing* of management plane traffic: http://www.cisco.com/en/US/docs/security/asa/asa82/configuration/guide/access_management.html#wp1064497 i believe this command *management access* simply allows you to terminate a management session *from* an 'unexpected' interface. maybe i'm crazy but i like to think of it kind of like the *same-security-traffic *command sets... just another nifty way to bypass normal firewall operations. in terms of the firewall *initiating *traffic over the IPsec tunnel when the AAA command ( *aaa-server group (interface) *) points elsewhere, i am not so sure about that. not saying it wouldn't work but i have my doubts. again, just like any other topic, the labbing of the scenario, and including configurations/debugs to confirm are key. happy sunday, andrew On Sun, Apr 17, 2011 at 9:38 AM, Tyson Scott <[email protected]> wrote: > The aaa server command is what makes the difference. I didn't use the > management command in lab 20 and it works. But what you did is good > practice. > > Regards, > > Tyson Scott > CCIE # 13513 (R&S, Security, SP) > Managing Partner/Technical Instructor - IPexpert Inc. > [email protected] > > > > ----- Reply message ----- > From: "Andrei Lucian Coman" <[email protected]> > Date: Sun, Apr 17, 2011 3:31 am > Subject: [OSL | CCIE_Security] ASA-generated traffic thru lan2lan-tunnel? > To: "Andrew Wurster" <[email protected]> > Cc: "OSL Security" <[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 > > > > > > >
_______________________________________________ For more information regarding industry leading CCIE Lab training, please visit www.ipexpert.com
