Hi Peter Try adding "permit ip any any" and mostly that should encrypt ospf packets. I used "permit ip any any" and try sending multicasting pings. Since I used AH, I was able to see multicast icmp packets inside AH with wireshark. Why should that not work? I am doing the same thing which IPSec based in doing and hence it should work.
So using the IPSec based VTI or regular crypto map, we can encrypt multicast but IPSec baset VTI is more feasible feature. But both these uses unicast IP header. Now coming to another topic of having multicast address in the IPSec header. The ISAKMP rfc does not address this. The key management is not made for multicast address. With regards Kings On Wed, Mar 7, 2012 at 6:10 PM, Peter Debye <[email protected]> wrote: > Kings, > try to set three (three, not 2) routers talking OSPF over a LAN, > use crypto with permit ospf on phy interfaces. You'll see that, while > in the case of only two routers the OSPF works (and multicast is > encapsulated IP[ESP[mcastIP]], then, adding the 3rd router everyting > breaks apart. > To make it work you create static VTIs (i.e. p2p links) between three > peers with mode and protection set to ipsec. Note how OSPF will change > from bcast to p2p type... > > This proves the conclusion that to make multicast work over > ipsec you need p2p mesh between peers. > =================================== > > > On 7 March 2012 07:17, Joe Astorino <[email protected]> wrote: >> I was talking about multicast as a destination IP address in the >> original IP header. >> >> On Wed, Mar 7, 2012 at 1:03 AM, Kingsley Charles >> <[email protected]> wrote: >>> If you have "permit ip any any", crypto maps will encrypt multicast >>> and I have confirmed it with wireshark using AH. >>> >>> >>> Here, we are talking about two things - Multicast in the payload and >>> Multicast in the IPsec IP header. >>> >>> Multicast in the IPsec IP header has not been addressed in the rfcs. >>> Are we talking about that? >>> >>> >>> With regards >>> Kings >>> >>> On Tue, Mar 6, 2012 at 10:17 PM, Peter Debye <[email protected]> wrote: >>>> We were able to protect IP multicast with good old IPSEC cryptomaps >>>> when applying them to GRE tunnels. Functionally, there's no >>>> difference with the newer VTI. For GRE tunneled traffic you >>>> said "permit all gre" in your crypto, and then the traffic to protect >>>> was chosen according to IP routing tables for unicast or multicast. >>>> The same way you say: "permit all ip sent to VTI". >>>> Pobably, your question is: Why do we need a tunnel interface >>>> in both cases? Why don't we apply a multicast crypto to a physical >>>> interface directly? -- I guess that for multicast implemented the way >>>> we are discussing we need p2p interfaces between peers. The physical >>>> router interfaces are not in p2p mode in all cases. Imagine what will >>>> happen if you have several routers connected to a LAN... >>>> >>>> ============================================= >>>> _______________________________________________ For more information regarding industry leading CCIE Lab training, please visit www.ipexpert.com Are you a CCNP or CCIE and looking for a job? Check out www.PlatinumPlacement.com
