The "inside" interface is connected to the LAN and the "outside" interface is connected to the WAN and terminates the IPSec tunnel.
On Sun, Apr 17, 2011 at 9:00 PM, Jimmy Larsson <[email protected]> wrote: > 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
