Multicast over IPSEC VPN possible?

I ' m not aware of any firewalls that natively support multicast over a ipsec tunnel. GRE btw is not a routing protocol and by it' s self will not carry a layer3 ( class D network ) traffic without some type of routing protocol or multicast-proxy. fwiw: GRE natively supports unicast traffic. What you can look at are using some type of 3rd party devices, like a L2TPv3 or psuedo ethernet, or encapsulated this into a 3rd party GRE/ip-in-ip tunnel with the appropiate multicast routing support and send that traffic ( GRE proto47 ) over the vpn/ipsec. Any of these will approaches will create more ip overhead with double encapsulation and might restrict any advance or deep packet inspections. Or lastly, use some type of application that converts mcast to unicast and then back to mcast. Once it' s converted to unicast, you can then easier route and police and control it thru common firewalls.

Yes kinda but that DNS request is still a unicast dest_address You need to keep in mind it has nothing todo with connectionless or connection or state. ICMP is connectionless and works thru firewalls if allowed. With traditional layer3 devices, they make routing decision solely via the dst_address, unless you have RPF ( unicast verify ) or PBR routing going on. Here we make choice that include; protocol, which interface it comes in, what src_address, but this ( PBR ) is not the normal and any router, still looks up the destination address going forward. With multicast routing, the source address is just as important or more so than the group subscription address of the subscriber. So this where the problems comes into play , & with routing and more so with Firewalls. e.g in you dns request example, you send a packet to the dst_addr x.x.x.x:53/udp. Any router(s) involved thru the path , don' t make any decision, based on the source of the client, but rather via of the dst_addr of the target but in .................. In mcast routing, they (multicast-routers) have more complexity due to the dst_group that a client is a member of, and the intra-routers, must show how know of the src_address(s) of the mcast and what interface to expect that src_address on, plus when and if I should forward it ( dense mode vrs sparse... igmp and group(s) subscriptions & leaves ) Your not technically routing to an " address" per se with multicast, sense an igmp subscriber could be at any part of the multicast tree. A lot of the newer firewalls does allow you to route local multicast and have options for IGMP proxy and setting of PIM Dense/Sparse mode interfaces. But to do this over a IPSEC tunnel, is yet to be seen. So unless you can define a tunnel interface, with ip_addres and PIM/IGMP multicast configurations, I highly doubt you can just send multicast traffic thru it ( ipsec/tunnel ) , without deploying a true native multicast architect underneath.

Fortinet gave me this link so i will go through this configuration... http://kb.fortinet.com/kb/microsites/search.do?cmd=displayKC&docType=kc&externalId=FD30094&sliceId=1&docTypeID=DT_KCARTICLE_1_1&dialogID=23848452&stateId=0%200%2023850059