So I tried it and it didn't work for me, am I missing something else? policy-map global_policy class inspection_default inspect dns preset_dns_map inspect ftp inspect h323 h225 inspect h323 ras inspect rsh inspect rtsp inspect esmtp inspect sqlnet inspect skinny inspect sunrpc inspect xdmcp inspect sip inspect netbios inspect tftp inspect icmp inspect icmp error class DEFAULT set connection decrement-ttl
icmp unreachable rate-limit 10 burst-size 5 (add as per the documentation, but I tried without it also) this is what I get pinging from inside the ASA: Type escape sequence to abort. Tracing the route to 192.168.35.5 1 192.168.9.3 0 msec 0 msec 9 msec (R3) 2 192.168.35.5 0 msec * 0 msec (R5) -----Original Message----- From: Simon Baumann [mailto:[email protected]] Sent: Tuesday, November 09, 2010 12:20 PM To: [email protected] Subject: Re: [OSL | CCIE_Security] CCIE_Security Digest, Vol 53, Issue 26: Traceroute Through ASA. Wale, you need to decrement the TTL to make the ASA visible as hop: ! policy-map global_policy class class-default set connection decrement-ttl ! Here's the corresponding Cisco document: http://www.cisco.com/en/US/products/hw/vpndevc/ps2030/products_tech_note09186a0080094e8a.shtml Cheers Simon Am 09.11.2010 um 18:00 schrieb [email protected]: > Send CCIE_Security mailing list submissions to > [email protected] > > To subscribe or unsubscribe via the World Wide Web, visit > http://onlinestudylist.com/mailman/listinfo/ccie_security > or, via email, send a message with subject or body 'help' to > [email protected] > > You can reach the person managing the list at > [email protected] > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of CCIE_Security digest..." > > > Today's Topics: > > 1. Traceroute Through an ASA (wale ogunyemi) > 2. Re: Lab 15 task 4.4 / GETVPN (Jerome Dolphin) > 3. Sinkhole configuration (Vybhav Ramachandran) > 4. Re: Sinkhole configuration (Kingsley Charles) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Tue, 9 Nov 2010 00:34:39 -0800 (PST) > From: wale ogunyemi <[email protected]> > To: [email protected] > Subject: [OSL | CCIE_Security] Traceroute Through an ASA > Message-ID: <[email protected]> > Content-Type: text/plain; charset="us-ascii" > > Can anyone give me an idea or a link of how you can enable traceroute through > an > ASA without using an ACCESS-LIST. > > Regards, > > Olawale Ogunyemi > > > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > </archives/ccie_security/attachments/20101109/8345a6e7/attachment-0001.html> > > ------------------------------ > > Message: 2 > Date: Tue, 9 Nov 2010 20:01:59 +1100 > From: Jerome Dolphin <[email protected]> > To: Tyson Scott <[email protected]> > Cc: OSL Security <[email protected]> > Subject: Re: [OSL | CCIE_Security] Lab 15 task 4.4 / GETVPN > Message-ID: > <[email protected]> > Content-Type: text/plain; charset="iso-8859-1" > > Hi all, the problem is not multicast config, I have configured RP mapping, > mcast routing and PIM where needed. I can see the *,G for the rekey mcast > address on the KS, the KS is also the RP, and I can see the GMs in the KS/RP > OIL. > > R2#show ip mroute 239.0.1.2 | sec 239.0.1.2 > (*, 239.0.1.2), 00:35:07/00:02:28, RP 2.2.2.2, flags: SJC > Incoming interface: Null, RPF nbr 0.0.0.0 > Outgoing interface list: > Serial1/1.5, Forward/Sparse, 00:00:50/00:02:09 > Serial1/1.6, Forward/Sparse, 00:33:41/00:02:28 > R2# > R2#show ip pim rp map > PIM Group-to-RP Mappings > > Group(s): 224.0.0.0/4, Static > RP: 2.2.2.2 (?) > R2# > > > !It seems that in my setup the rekey ACL defines what interface the rekey > mcast is sent out of. Perhaps this is a 12.4(15)T14 issue, or perhaps this > is deliberate IOS behaviour: > > R2#show run | i crypto gdoi group|match address|rekey address > ipv4|access-list (101|121|122) > crypto gdoi group GETVPN1 > rekey address ipv4 121 > match address ipv4 122 > access-list 101 permit ip any host 239.0.1.2 > access-list 121 permit udp host 192.1.25.2 eq 848 host 239.0.1.2 eq 848 > access-list 122 permit ip 9.0.0.0 0.255.255.255 host 192.1.6.16 > access-list 122 permit ip host 192.1.6.16 9.0.0.0 0.255.255.255 > R2# > > > !trigger rekey by changing crypto ACL > !rekey is sent out physical interface with ip address 192.1.25.5 > !R5 recieves the rekey but R6 does not. > > R2#debug ip packet 101 > IP packet debugging is on for access list 101 > R2# > R2#conf t > Enter configuration commands, one per line. End with CNTL/Z. > R2(config)#ip access-l ex 122 > R2(config-ext-nacl)#40 permit ip host 111.111.111.111 host 222.222.222.222 > R2(config-ext-nacl)#end > R2# > *Mar 1 00:10:22.771: %SYS-5-CONFIG_I: Configured from console by console > *Mar 1 00:10:22.863: IP: s=192.1.25.2 (local), d=239.0.1.2 (Serial1/1.5), > len 1256, sending broad/multicast > R2# > *Mar 1 00:10:22.871: %GDOI-5-KS_SEND_MCAST_REKEY: Sending Multicast Rekey > for group GETVPN1 from address 192.1.25.2 to 239.0.1.2 with seq # 1 > *Mar 1 00:10:23.055: IP: s=192.1.25.5 (Serial1/1.5), d=239.0.1.2, len 28, > rcvd 0 > R2# > > > !change rekey ACL to source rekeys from loopback0, and rekeys are only sent > out loopback 0 > !debugs on GMs confirm no GMs recieve the rekey > > R2# > R2#conf t > Enter configuration commands, one per line. End with CNTL/Z. > R2(config)#ip access-l ex 121 > R2(config-ext-nacl)#no 10 > R2(config-ext-nacl)#10 permit udp host 2.2.2.2 eq 848 host 239.0.1.2 eq 848 > R2(config-ext-nacl)#ip access-l ex 122 > R2(config-ext-nacl)#no 40 > R2(config-ext-nacl)#end > R2# > *Mar 1 00:15:01.916: %SYS-5-CONFIG_I: Configured from console by console > *Mar 1 00:15:02.008: IP: s=2.2.2.2 (local), d=239.0.1.2 (Loopback0), len > 1272, sending broad/multicast > *Mar 1 00:15:02.016: %GDOI-5-KS_SEND_MCAST_REKEY: Sending Multicast Rekey > for group GETVPN1 from address 2.2.2.2 to 239.0.1.2 with seq # 1 > R2# > *Mar 1 00:15:02.024: IP: s=2.2.2.2 (Loopback0), d=239.0.1.2, len 1272, > unroutable > R2# > > > !change rekey ACL to a source address of any, and the rekey is sent out ALL > interfaces > !debugs on GMs confirm all GMs recieve the rekey mcast packets, but do not > treat them as rekeys > > R2(config)#ip access-l ex 121 > R2(config-ext-nacl)#no 10 > R2(config-ext-nacl)#10 permit udp any eq 848 host 239.0.1.2 eq 848 > R2(config-ext-nacl)#ip access-l ex 122 > R2(config-ext-nacl)#40 permit ip host 111.111.111.111 host 222.222.222.222 > R2(config-ext-nacl)#^Z > R2# > *Mar 1 00:19:24.091: %SYS-5-CONFIG_I: Configured from console by console > *Mar 1 00:19:24.175: IP: s=192.1.12.2 (local), d=239.0.1.2 > (FastEthernet0/1), len 1256, sending broad/multicast > *Mar 1 00:19:24.183: IP: s=192.1.24.2 (local), d=239.0.1.2 (Serial1/1.4), > len 1256, sending broad/multicast > *Mar 1 00:19:24.187: IP: s=192.1.25.2 (local), d=239.0.1.2 (Serial1/1.5), > len 1256, sending broad/multicast > *Mar 1 00:19:24.191: IP: s=192.1.26.2 (local), d=239.0.1.2 (Serial1/1.6), > len 1256, sending broad/multicast > *Mar 1 00:19:24.199: IP: s=2.2.2.2 (local), d=239.0.1.2 (Loopback0), len > 1256, sending broad/multicast > *Mar 1 00:19:24.203: %GDOI-5-KS_SEND_MCAST_REKEY: Sending Multicast Rekey > for group GETVPN1 from address 0.0.0.0 to 239.0.1.2 with seq # 1 > *Mar 1 00:19:24.215: IP: s=2.2.2.2 (Loopback0), d=239.0.1.2, len 1256, > unroutable > R2# > > Unfortunately, when the source address is defined as 'any' in the rekey ACL, > the GMs receive the mcast rekey, but they don't accept it as valid, I guess > because they're actually looking for a source of 0.0.0.0: > > R5#show crypto gdoi gm rekey > Group GETVPN1 (Multicast) > Number of Rekeys received (cumulative) : 0 > Number of Rekeys received after registration : 0 > > Rekey (KEK) SA information : > dst src conn-id my-cookie his-cookie > New : 239.0.1.2 0.0.0.0 1015 57BD8510 764B72D0 > Current : --- --- --- --- --- > Previous: --- --- --- --- --- > > R5# > > > So that's it, I never want to look at a GETVPN problem again :) > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > </archives/ccie_security/attachments/20101109/90028807/attachment-0001.html> > > ------------------------------ > > Message: 3 > Date: Tue, 9 Nov 2010 15:53:06 +0530 > From: Vybhav Ramachandran <[email protected]> > To: OSL Security <[email protected]> > Subject: [OSL | CCIE_Security] Sinkhole configuration > Message-ID: > <[email protected]> > Content-Type: text/plain; charset="iso-8859-1" > > Hello All, > > I'm looking for a good reference document on how to configure Sinkholes. > Does anyone have a link? > > Cheers, > TacACK > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > </archives/ccie_security/attachments/20101109/25f9fb2a/attachment-0001.html> > > ------------------------------ > > Message: 4 > Date: Tue, 9 Nov 2010 17:26:01 +0530 > From: Kingsley Charles <[email protected]> > To: Vybhav Ramachandran <[email protected]> > Cc: OSL Security <[email protected]> > Subject: Re: [OSL | CCIE_Security] Sinkhole configuration > Message-ID: > <[email protected]> > Content-Type: text/plain; charset="iso-8859-1" > > http://www.cisco.com/web/about/security/intelligence/worm-mitigation-whitepaper.html#tt_sinkholes > > With regards > Kings > > On Tue, Nov 9, 2010 at 3:53 PM, Vybhav Ramachandran <[email protected]>wrote: > >> Hello All, >> >> I'm looking for a good reference document on how to configure Sinkholes. >> Does anyone have a link? >> >> Cheers, >> TacACK >> >> _______________________________________________ >> For more information regarding industry leading CCIE Lab training, please >> visit www.ipexpert.com >> >> > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > </archives/ccie_security/attachments/20101109/f2f15d99/attachment-0001.html> > > End of CCIE_Security Digest, Vol 53, Issue 26 > ********************************************* ----------------------------------------- Disclaimer: This e-mail communication and any attachments may contain confidential and privileged information and is for use by the designated addressee(s) named above only. If you are not the intended addressee, you are hereby notified that you have received this communication in error and that any use or reproduction of this email or its contents is strictly prohibited and may be unlawful. If you have received this communication in error, please notify us immediately by replying to this message and deleting it from your computer. Thank you. _______________________________________________ For more information regarding industry leading CCIE Lab training, please visit www.ipexpert.com
