Either one will do the multicast. You can build GRE tunnels, which in
a source to receiver (i.e. star topology 4 hosts = 4 tunnels and the
1 source has 4 tunnels). You can do the same in a full mesh, but you
will have to build a tunnel for each receiver to each receiver (4
hosts = 32 tunnels). This is the old way. You will have to tunnel
the IGMP I believe over the VPN as it will not handle IGMP traffic. I
may be wrong on that.

Try these also:

products_configuration_guide_chapter09186a00800ca7 94.html


On Jan 29, 2007, at 4:25 PM, Kurt Buff wrote:

> Situation in the case is that we're implementing equipment that uses
> multicast to talk between multiple instances of themselves - I'm not
> clear yet whether there'll be a designated talker with multiple
> listeners, or whether there'll be multiple talkers and multiple
> listeners.
> I'm reading the doco now - thanks for the tip. This should provide me
> with a running start.
> I'll be interested in finding out whether I can use a layer3 switch at
> each end to do this, or if I need edge routers to set this up.
> Kurt
> On 1/28/07, Chris Myers wrote:
>>> Hi Kurt,

>> I am not sure what you are exactly needing to use the IGMP
>> for, but
>> most firewall and vpn solutions can do what you want to do. It's a
>> matter of creating the right tunnels or forwarding the right ports
>> and protocols. Cisco is a solution, but Juniper can do it just as
>> well. It really depends on the implementation you are needing IGMP
>> for. IGMP is associated with multicast formats, so here is a Cisco
>> doc that should get you started.
>>> http://www.cisco.com/application/pdf...ol/ns171/c649/
>>> ccmigration_09186a008074f26a.pdf

>> Thank You,
>> cmyers

>> On Jan 26, 2007, at 1:55 PM, Kurt Buff wrote:
>>> Honorable Ones,
>>> I've been handed the task of getting IGMP traffic between remote
>>> offices, over an IPSec tunnel.
>>> I have run into the apparently well-known issue of their not playing
>>> nicely together, and was wondering if I could get recommendations on
>>> making such a thing happen.
>>> We're looking at upgrading/replacing our current hardware soon
>>> anyway,
>>> so recommendations as to brands that would help support this
>>> would be
>>> useful, as would workarounds that don't require replacement of
>>> current
>>> hardware, as I believe that would broaden the choices I have when
>>> I do
>>> upgrade.
>>> I'm stumped, not least because my network-fu is not up to the
>>> standards of many on this list, and would really appreciate some
>>> pointers in the right direction.
>>> Kurt

> _______________________________________________
> firewall-wizards mailing list
> firewall-wizards@listserv.icsalabs.com
> https://listserv.icsalabs.com/mailma...rewall-wizards

firewall-wizards mailing list