Fawad,
It is always good to add more to a discussion! I think Andrei gave the correct answer that Jimmy was looking for. I gave an incorrect answer in follow-up and had to correct my answer with another follow-up with the debugs showing that it does actually work like Andrei described it. Regards, Tyson Scott - CCIE #13513 R&S, Security, and SP Managing Partner / Sr. Instructor - IPexpert, Inc. Mailto: <mailto:[email protected]> [email protected] Telephone: +1.810.326.1444, ext. 208 Live Assistance, Please visit: <http://www.ipexpert.com/chat> 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 <http://www.ipexpert.com/communities> www.ipexpert.com/communities and our public website at <http://www.ipexpert.com/> www.ipexpert.com From: Fawad Khan [mailto:[email protected]] Sent: Sunday, April 17, 2011 10:42 PM To: Tyson Scott Cc: Andrew Wurster; OSL Security Subject: Re: [OSL | CCIE_Security] ASA-generated traffic thru lan2lan-tunnel? 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 <tel:%2B1.810.326.1444> , ext. 208 Live Assistance, Please visit: www.ipexpert.com/chat eFax: +1.810.454.0130 <tel:%2B1.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 <http://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/acces s_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 <http://blogg.kvistofta.nu/> > >>> ------- > >>> > >>> _______________________________________________ > >>> For more information regarding industry leading CCIE Lab training, > please > >>> visit www.ipexpert.com <http://www.ipexpert.com/> > >>> > >>> > >> > > > > > > -- > > ------- > > Jimmy Larsson > > Ryavagen 173 > > s-26030 Vallakra > > Sweden > > http://blogg.kvistofta.nu <http://blogg.kvistofta.nu/> > > ------- > > _______________________________________________ > For more information regarding industry leading CCIE Lab training, please > visit www.ipexpert.com <http://www.ipexpert.com/> > > _______________________________________________ For more information regarding industry leading CCIE Lab training, please visit www.ipexpert.com <http://www.ipexpert.com/>
_______________________________________________ For more information regarding industry leading CCIE Lab training, please visit www.ipexpert.com
