Three different issues were identified and resolved:
Issue #1 applies to IPv4 IGMP packets only
IGMP reports are sent as a multicast packets. For non-bridge mode, these packets are processed by the Security Gateway to manage IGMP state, because the Gateway acts as the layer 3 multicast router.
For this scenario, the IGMP packets are never forwarded outbound. For bridge mode, the Gateway operates as layer 2 only, and an external device must be used for layer 3 routing. For this case, IGMP packets must be forwarded to the external router so it is able to maintain IGMP state.
Issue #2 applies to IPv4 multicast traffic in general
SecureXL performs acceleration of layer 3 routing for multicast traffic. For bridge mode, layer 3 routing is N.A. And, by design, multicast packets are not accelerated for this case.
There is an issue for bridge mode where multicast packets were being dropped by SecureXL because the FW1 module attempted to accelerate them.
Issue #3 applies to all IPv4 unicast/multicast packets having IP options (this includes IGMP packets which always have the "router alert" option)
SecureXL strips IP options from the layer3 header, and then restores them before performing F2F, or sending the packet outbound. There is an issue where the IP options restore logic was damaging the layer2 header.