[OSL | CCIE_Security] Certificates
Hi, Is there a difference between: subject-name cn=R5.ipexpert, ou=CCIE, c=PL and subject-name cn=r5.ipexpert, ou=CCIE, c=PL Is it case-sensitive? Thanks Johan ___ For more information regarding industry leading CCIE Lab training, please visit www.ipexpert.com
Re: [OSL | CCIE_Security] Certificates
I guess so. With regards Kings On Mon, Sep 13, 2010 at 11:57 AM, Johan Bornman jo...@isc.co.za wrote: Hi, Is there a difference between: subject-name cn=R5.ipexpert, ou=CCIE, c=PL and subject-name cn=r5.ipexpert, ou=CCIE, c=PL Is it case-sensitive? Thanks Johan ___ 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
Re: [OSL | CCIE_Security] ASA ARP Inspection
Hi Dave In transparent firewall, if the mac address is not in the mac address table then the ASA doesn't flood the packet to all the interfaces rather does the following: - Sends ARP request for the IP address, if directly connected to find the interface on which the ARP response is got. - Send a Ping request to the IP address, if not directly connecred to find the interface on which the response is got. Does the ASA have mac-address of the outside router in it's mac table? Can you try adding mac-address-table static outside router mac address Just a try With regards Kings On Mon, Sep 13, 2010 at 12:21 AM, Mack, David A (Dave) dm...@verizon.comwrote: Kingsley, The issue is with the ASA itself. I have static ARPs on the ASA for the router on the inside and the router on the outside. I also have static ARPs on each of the routers for the other router. The routers are working just fine. In this scenario, the ASA only has a default route pointed to the IP Address of the outside router. It should not have to ARP for any other remote networks beyond the outside router, but rather forward to the MAC address of the “default” gateway. However the ASA instead of using it’s default route to the outside router and static ARP for that router, ARPs for a remote network. The inside router also has a default route and static ARP for the outside router and it works fine. To summarize, the ASA is insisting on ARPing for remote networks, even though it has a static default route and a static ARP entry for the next hop of that default route. That ARP is what is failing ARP inspection. Thanks! Dave *From:* Kingsley Charles [mailto:kingsley.char...@gmail.com] *Sent:* Sunday, September 12, 2010 12:39 PM *To:* Mack, David A (Dave) *Cc:* OSL Security *Subject:* Re: [OSL | CCIE_Security] ASA ARP Inspection Are you telling that the ARP inspection fails when you try to reach the remote address from the ASA or from the router inside? Did you add static arp for the remote IP address and the next hop router's mac address With regards Kings On Sun, Sep 12, 2010 at 7:59 PM, Mack, David A (Dave) dm...@verizon.com wrote: Hello everyone! I ran into an issue with ASA ARP inspection and would like to know if I am missing something and ask if anyone else has seen this behavior? In a nutshell, if you want to do ARP inspection to prevent MitM attacks you can enable ARP inspection with static ARP entries and combine that with no-flood to tighten it up. For the routers on either side of the ASA, you will also need static ARP entries. So in a practice lab, I did exactly that and the routers on either side were fine. I was able forward traffic between them just fine, however it appears as if the ASA itself is stupid. I had configured a management IP on the Transparent sub-net, and configured a default route to one of the routers on the outside interface. What happened was that the ASA will ARP for the destination even though there is a static route with the next hop already there and an ARP for the next-hop. The router on the outside interface be nice and will proxy-arp respond, but ARP inspection will fail. If I disa ble proxy-arp on the outside router, the ASA's arp just goes unanswered and the ASA still cannot reach anything. Has anyone seen this? Also, I ran across a potential time bomb, the router on the inside was a switch using a SVI interface. When I rebooted it to do some validations, the MAC address for the SVI interface changed! This broke my static arp entry for that interface. I don't seem to recall a way to statically assign a mac address to a SVI. Thanks! Dave ___ 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
[OSL | CCIE_Security] IPSec shared profile
Hi all IPSec shared profiles enables more than two GRE tunnels that has the same tunnel source, destination and tunnel key to use the same IPSec SADB. Here the spokes uses IPSec shared profile. The spokes peer with two hubs. With IPsec profile the SADB are the same. The spoke's T0 and T1 that tunnels to Hub1 and hub2 uses the same SA. I am wondering how can that happen? The spokes are negotiating DH with two different hubs. How come they come up with the same shared secret. Hub 1 and Hub 2 doesn't communicate each other. Can someone provide the insight. http://www.cisco.com/en/US/docs/ios/sec_secure_connectivity/configuration/guide/share_ipsec_w_tun_protect_ps6441_TSD_Products_Configuration_Guide_Chapter.html With regards Kings ___ For more information regarding industry leading CCIE Lab training, please visit www.ipexpert.com
Re: [OSL | CCIE_Security] IPSec shared profile
Hi Kings,I use the shared profile in combination with isakmp profiles. What I found, whether it is multiple tunnels or one tunnel and ezvpn / site-to-site tunnels) on a single router, sometimes, altough the isakmp profile should restrict it, the inbound sa would be set into a different sadb then the outbound sa. E.g. For tunnel0 inbound the spoke sa would be in the system, or even the wrong tunnel, while the outbound would be in the tunnel0 sadb.What then happens is for example eigrp flapping, nhrp registration not working, etc.. Basically traffic comes in, but can't get out, or vice versa, that traffic isn't even hitting the tunnel interface.So to prevent it, I specify shared on all tunnels, so that the sadb between the tunnels is shared.In production it means that you have a short interruption on the database.What do you mean with that the same SA is valid? Where did you put the shared profile, on the hub side, or the spoke side?Kind regardsPJOn 13 sep 2010, at 14:43, Kingsley Charles wrote:Hi allIPSec shared profiles enables more than two GRE tunnels that has the same tunnel source, destination and tunnel key to use the same IPSec SADB.Here the spokes uses IPSec shared profile. The spokes peer with two hubs. With IPsec profile the SADB are the same. The spoke's T0 and T1 that tunnels to Hub1 and hub2 uses the same SA. I am wondering how can that happen? The spokes are negotiating DH with two different hubs. How come they come up with the same shared secret. Hub 1 and Hub 2 doesn't communicate each other. Can someone provide the insight. http://www.cisco.com/en/US/docs/ios/sec_secure_connectivity/configuration/guide/share_ipsec_w_tun_protect_ps6441_TSD_Products_Configuration_Guide_Chapter.html With regardsKings ___For more information regarding industry leading CCIE Lab training, please visit www.ipexpert.com ---Nefkens AdviesEnk 264214 DD VurenThe NetherlandsTel: +31 183 634730Fax: +31 183 690113Cell: +31 654 323221Email: pjnefk...@nefkensadvies.nlWeb: http://www.nefkensadvies.nl/Think before you print. ___ For more information regarding industry leading CCIE Lab training, please visit www.ipexpert.com
Re: [OSL | CCIE_Security] ASA ARP Inspection
Tyson, I turned the default route around towards the inside interface and I did not have the same problem. I am not sure I like that behavior, but it is definitely something to know about! Thanks! Dave From: Tyson Scott [mailto:tsc...@ipexpert.com] Sent: Sunday, September 12, 2010 11:44 PM To: Mack, David A (Dave); 'Kingsley Charles' Cc: 'OSL Security' Subject: RE: [OSL | CCIE_Security] ASA ARP Inspection I seem to remember this being an issue with ARP inspection. If you run the default route in the opposite direction I don't think you will have the same problem. I think it is only when it is going external. Test it turning the interfaces around. Regards, Tyson Scott - CCIE #13513 RS, Security, and SP Managing Partner / Sr. Instructor - IPexpert, Inc. Mailto: tsc...@ipexpert.commailto:tsc...@ipexpert.com Telephone: +1.810.326.1444, ext. 208 Live Assistance, Please visit: www.ipexpert.com/chathttp://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 (RS, 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/communitieshttp://www.ipexpert.com/communities and our public website at www.ipexpert.comhttp://www.ipexpert.com/ From: ccie_security-boun...@onlinestudylist.com [mailto:ccie_security-boun...@onlinestudylist.com] On Behalf Of Mack, David A (Dave) Sent: Sunday, September 12, 2010 2:51 PM To: 'Kingsley Charles' Cc: OSL Security Subject: Re: [OSL | CCIE_Security] ASA ARP Inspection Kingsley, The issue is with the ASA itself. I have static ARPs on the ASA for the router on the inside and the router on the outside. I also have static ARPs on each of the routers for the other router. The routers are working just fine. In this scenario, the ASA only has a default route pointed to the IP Address of the outside router. It should not have to ARP for any other remote networks beyond the outside router, but rather forward to the MAC address of the default gateway. However the ASA instead of using it's default route to the outside router and static ARP for that router, ARPs for a remote network. The inside router also has a default route and static ARP for the outside router and it works fine. To summarize, the ASA is insisting on ARPing for remote networks, even though it has a static default route and a static ARP entry for the next hop of that default route. That ARP is what is failing ARP inspection. Thanks! Dave From: Kingsley Charles [mailto:kingsley.char...@gmail.com] Sent: Sunday, September 12, 2010 12:39 PM To: Mack, David A (Dave) Cc: OSL Security Subject: Re: [OSL | CCIE_Security] ASA ARP Inspection Are you telling that the ARP inspection fails when you try to reach the remote address from the ASA or from the router inside? Did you add static arp for the remote IP address and the next hop router's mac address With regards Kings On Sun, Sep 12, 2010 at 7:59 PM, Mack, David A (Dave) dm...@verizon.commailto:dm...@verizon.com wrote: Hello everyone! I ran into an issue with ASA ARP inspection and would like to know if I am missing something and ask if anyone else has seen this behavior? In a nutshell, if you want to do ARP inspection to prevent MitM attacks you can enable ARP inspection with static ARP entries and combine that with no-flood to tighten it up. For the routers on either side of the ASA, you will also need static ARP entries. So in a practice lab, I did exactly that and the routers on either side were fine. I was able forward traffic between them just fine, however it appears as if the ASA itself is stupid. I had configured a management IP on the Transparent sub-net, and configured a default route to one of the routers on the outside interface. What happened was that the ASA will ARP for the destination even though there is a static route with the next hop already there and an ARP for the next-hop. The router on the outside interface be nice and will proxy-arp respond, but ARP inspection will fail. If I disa ble proxy-arp on the outside router, the ASA's arp just goes unanswered and the ASA still cannot reach anything. Has anyone seen this? Also, I ran across a potential time bomb, the router on the inside was a switch using a SVI interface. When I rebooted it to do some validations, the MAC address for the SVI interface changed! This broke my static arp entry for that interface. I don't seem to recall a way to statically assign a mac address to a SVI. Thanks! Dave ___ For more information regarding industry leading CCIE Lab training, please visit www.ipexpert.comhttp://www.ipexpert.com ___ For more information regarding
Re: [OSL | CCIE_Security] IPexpert Vol 1 , Lab 7A , Task 7.13
The question should have stated FPM not NBAR. I have updated the question to be titled Flexible Packet Matching instead of MQC using NBAR. Regards, Tyson Scott - CCIE #13513 RS, Security, and SP Managing Partner / Sr. Instructor - IPexpert, Inc. Mailto: tsc...@ipexpert.com 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 (RS, 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: ccie_security-boun...@onlinestudylist.com [mailto:ccie_security-boun...@onlinestudylist.com] On Behalf Of Yogesh Gawankar Sent: Monday, September 13, 2010 1:09 AM To: OSL Security; Vybhav Ramachandran Subject: Re: [OSL | CCIE_Security] IPexpert Vol 1 , Lab 7A , Task 7.13 Ok Thx. In that case I feel we need to use Nbar if the question mentions it but maybe somebody else can shed more light on this. Speaking of nbar does anyone have any tips on engaging the nbar engine without the IOS crashing? Thanks and regards Yogesh Gawankar --- On Mon, 9/13/10, Vybhav Ramachandran tac...@tacack.com wrote: From: Vybhav Ramachandran tac...@tacack.com Subject: Re: [OSL | CCIE_Security] IPexpert Vol 1 , Lab 7A , Task 7.13 To: Yogesh Gawankar yogesh...@yahoo.com, OSL Security ccie_security@onlinestudylist.com Date: Monday, September 13, 2010, 2:23 PM Hello Yogesh, Well FPM is by far the most detailed method to match payload in the traffic , but i think NBAR could also be used to perform some crude payload matching. For example , suppose we want to match traffic destined to port UDP 6060 which has the hex string 98AB at an offset of 6 bytes from the start of the packet, we could define a custom protocol and configure it to match the string , like this: # ip nbar custom NAME OF THE CUSTOM PROTOCOL 6 hex 98AB destination udp 6060. This definitely is not as powerful as FPM in the sense that, for defining a custom NBAR protocol , we need to know the TCP or UDP ports that the traffic is destined for. It's not as flexible as FPM. My question was, since the question mentioned NBAR , are we allowed to use FPM as our matching technique? If yes, great :) Cheers, TacACK ___ For more information regarding industry leading CCIE Lab training, please visit www.ipexpert.com
Re: [OSL | CCIE_Security] IPexpert Vol 1 , Lab 7A , Task 7.13
Thanks a lot Tyson. Cheers, TacACK ___ For more information regarding industry leading CCIE Lab training, please visit www.ipexpert.com
