This is pretty much deviated thread so far. Anyways. my question is that the vpn-clients that are to be authenitcated , are they by chance remote-access vpn clients? If not, then what I have done before is that I built a L2L vpn tunnel, one side of the ASA had a tacacs/radius server which authenticates any connection that the 'vendor' initiates using virtual telnet/secure http.
my topology looks like this. vendor-lan>>>>vendor firewall<<<<<VPN TUNNEL>>>>my ASA>>>my-LAN(all servers, ACS) so whenever the vendor wants to access any service at my end, he has to initiate a connection to my ACS(virtual telnet). This attempt actually brings up the Ipsec VPN tunnel. I hope I was able to understand the scenario and to contribute to the community. Regards FNK On Sun, Apr 17, 2011 at 6:04 PM, Tyson Scott <[email protected]> wrote: > snmp-server host inside x.x.x.x would work with that too. Well I tested > and I am wrong. I found I cannot get it to work without the > management-access command. I looked in the final configurations of ASA2 > from Lab20 and I see that I did add that command but I didn't add it to the > Detailed Solution Guide. I will need to fix that. > > > > Let me show you it working here: > > > > Topology: > > 1.1.1.1 (R1 Loopback)<-> > R1(10.1.1.1)<->outside(10.1.1.10)<->ASA1<->inside(11.1.1.10) > > > > Configurations > > inter E0/0 > > nameif outside > > ip add 10.1.1.10 255.255.255.0 > > inter E0/1 > > nameif inside > > ip add 11.1.1.10 255.255.255.0 > > ! > > management-access inside > > logging on > > logging trap debug > > logging host inside 1.1.1.1 > > aaa-server RADIUS protocol radius > > aaa-server RADIUS (inside) host 1.1.1.1 > > route outside 1.1.1.1 255.255.255.255 10.1.1.1 > > snmp-server host inside 1.1.1.1 > > > > Here are the results of a "debug ip packet detail" on R1 > > Router(config)# > > *Apr 17 22:02:54.298: IP: tableid=0, s=11.1.1.10 (FastEthernet0/0), > d=1.1.1.1 (Loopback0), routed via RIB > > *Apr 17 22:02:54.298: IP: s=11.1.1.10 (FastEthernet0/0), d=1.1.1.1, len > 91, rcvd 4 > > *Apr 17 22:02:54.298: UDP src=1025, dst=1645 > > *Apr 17 22:02:54.298: IP: tableid=0, s=10.1.1.1 (local), d=11.1.1.10 > (FastEthernet0/0), routed via FIB > > *Apr 17 22:02:54.298: IP: s=10.1.1.1 (local), d=11.1.1.10 > (FastEthernet0/0), len 56, sending > > *Apr 17 22:02:54.298: ICMP type=3, code=3 > > *Apr 17 22:02:54.302: IP: tableid=0, s=11.1.1.10 (FastEthernet0/0), > d=1.1.1.1 (Loopback0), routed via RIB > > *Apr 17 22:02:54.302: IP: s=11.1.1.10 (FastEthernet0/0), d=1.1.1.1, len > 164, rcvd 4 > > *Apr 17 22:02:54.302: UDP src=514, dst=514 > > *Apr 17 22:02:54.302: IP: tableid=0, s=11.1.1.10 (FastEthernet0/0), > d=1.1.1.1 (Loopback0), routed via RIB > > *Apr 17 22:02:54.302: IP: s=11.1.1.10 (FastEthernet0/0), d=1.1.1.1, len 82, > rcvd 4 > > *Apr 17 22:02:54.302: UDP src=514, dst=514 > > *Apr 17 22:02:54.302: IP: tableid=0, s=11.1.1.10 (FastEthernet0/0), > d=1.1.1.1 (Loopback0), routed via RIB > > *Apr 17 22:02:54.302: IP: s=11.1.1.10 (FastEthernet0/0), d=1.1.1.1, len > 135, rcvd 4 > > *Apr 17 22:02:54.302: UDP src=514, dst=514 > > *Apr 17 22:02:54.302: IP: tableid=0, s=11.1.1.10 (FastEthernet0/0), > d=1.1.1.1 (Loopback0), routed via RIB > > *Apr 17 22:02:54.302: IP: s=11.1.1.10 (FastEthernet0/0), d=1.1.1.1, len > 130, rcvd 4 > > *Apr 17 22:02:54.302: UDP src=514, dst=514 > > *Apr 17 22:02:54.302: IP: tableid=0, s=11.1.1.10 (FastEthernet0/0), > d=1.1.1.1 (Loopback0), routed via RIB > > *Apr 17 22:02:54.302: IP: s=11.1.1.10 (FastEthernet0/0), d=1.1.1.1, len > 102, rcvd 4 > > *Apr 17 22:02:54.302: UDP src=514, dst=514 > > Router(config)# > > > > > > Regards, > > > > Tyson Scott - CCIE #13513 R&S, Security, and SP > Managing Partner / Sr. Instructor - IPexpert, Inc. > Mailto: [email protected] > Telephone: +1.810.326.1444, ext. 208 > Live Assistance, Please visit: www.ipexpert.com/chat > eFax: +1.810.454.0130 > > > > IPexpert is a premier provider of Self-Study Workbooks, Video on Demand, > Audio Tools, Online Hardware Rental and Classroom Training for the Cisco > CCIE (R&S, Voice, Security & Service Provider) certification(s) with > training locations throughout the United States, Europe, South Asia and > Australia. Be sure to visit our online communities at > www.ipexpert.com/communities and our public website at www.ipexpert.com > > > > *From:* Andrew Wurster [mailto:[email protected]] > *Sent:* Sunday, April 17, 2011 1:42 PM > *To:* Tyson Scott > *Cc:* Andrei Lucian Coman; OSL Security > *Subject:* Re: [OSL | CCIE_Security] ASA-generated traffic thru > lan2lan-tunnel? > > > > 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 > >
_______________________________________________ For more information regarding industry leading CCIE Lab training, please visit www.ipexpert.com
