FortiGate IGMP Snooping: Multicast Not Forwarding Across VLAN

Multicast traffic on FortiGate firewalls relies on IGMP (Internet Group Management Protocol) snooping to learn which ports or VLANs have active group members. When multicast packets fail to cross VLAN boundaries, the root cause often traces to IGMP snooping state, firewall policy, or routing configuration rather than a hardware issue. Understanding how FortiGate handles IGMP snooping and multicast forwarding is essential for video conferencing, IPTV, and other group-based services.

How IGMP Snooping Works on FortiGate

IGMP snooping allows a Layer 2 or Layer 3 device to listen to IGMP membership reports and dynamically build a map of which ports or interfaces have active listeners for a given multicast group. On FortiGate, IGMP snooping operates at the switch fabric level when internal switching is enabled, and also at the routing level when multicast crosses security domains or VLANs managed by different policies.

By default, FortiGate performs IGMP snooping on bridge interfaces and internal switch ports. However, multicast forwarding between separate VLANs or security zones requires either a multicast routing entry (mroute) or an explicit firewall policy permitting the traffic. If IGMP snooping is disabled or if no group membership is detected, the firewall will not forward multicast frames, even if unicast traffic is allowed.

Common Causes of Multicast Forwarding Failure

• →IGMP snooping disabled on the bridge interface or VLAN
• →No IGMP membership report received from downstream hosts
• →Multicast traffic blocked by firewall policy or implicit deny
• →Source and group address not matching any mroute or policy rule
• →IGMP querier not present or misconfigured on the network
• →Multicast routing disabled when traffic must cross security zones
• →TTL (Time To Live) too low; packets dropped before reaching destination

Diagnosing and Enabling IGMP Snooping

Start by verifying IGMP snooping status on the relevant bridge or VLAN interface. Use the CLI to inspect current IGMP group membership and snooping state:

# Check IGMP snooping status on a bridge interface
get system interface

# View IGMP group membership
get router multicast

# Display IGMP snooping table
diag netlink brctl mdb show

# Check multicast routing table
get router mroute

If IGMP snooping is disabled, enable it on the bridge interface:

config system interface
  edit "bridge1"
    set type bridge
    set igmp-snooping enable
  next
end

For multicast crossing VLANs or security zones, configure a multicast route or add a firewall policy explicitly allowing the source and group address pair:

config router multicast
  config route
    edit 1
      set destination 224.0.0.0 255.0.0.0
      set device "port1"
    next
  end
end

config firewall policy
  edit 100
    set srcintf "vlan10"
    set dstintf "vlan20"
    set srcaddr "all"
    set dstaddr "all"
    set action accept
    set schedule "always"
    set service "all"
  next
end

Verification and Testing

After enabling IGMP snooping and adding multicast routes or policies, verify that group membership is learned and traffic flows correctly. Use a multicast traffic generator or packet capture to confirm that IGMP reports are sent and received:

# Capture IGMP packets on an interface
diag sniffer packet port1 'igmp' 4 0 l

# Monitor real-time IGMP snooping activity
diag debug app igmp -1
diag debug enable

Ensure that the multicast source is reachable and that the TTL value in the IP header is sufficient to traverse all hops. Many IPTV and video systems use TTL=1 or TTL=32; if packets are dropped before reaching the destination VLAN, increase TTL or verify that the source and destination are on the same network segment or within a configured multicast domain.