Multicast Routing vs Multicast Forwarding on FortiGate

By Manny Fernandez

June 4, 2026

Multicast Routing vs Multicast Forwarding on FortiGate

These are two distinct mechanisms on FortiOS, and conflating them is a common source of “my multicast isn’t working” tickets. Here is the breakdown.

Multicast Routing (PIM-based, Layer 3)

Multicast routing handles the dynamic distribution of multicast traffic across different subnets using a multicast routing protocol, primarily PIM (Protocol Independent Multicast).

Key characteristics:

Enabled globally with config router multicast and set multicast-routing enable.
Uses PIM Sparse Mode (PIM-SM) or Sparse-Dense Mode to build distribution trees based on group membership.
Relies on IGMP (typically IGMPv2/v3) to learn receiver interest on downstream interfaces.
Requires a Rendezvous Point (RP) for PIM-SM. The FortiGate can act as the RP or point to an external one via static RP or bootstrap router (BSR).
Builds and maintains state in the multicast routing table, viewable with get router info multicast table and diagnose ip multicast.
Forwarding decisions are dynamic and adapt as receivers join and leave groups.

Use this when multicast sources and receivers live on different subnets/interfaces and you need the FortiGate to participate intelligently in the multicast topology.

Multicast Forwarding (Static, Policy-based)

Multicast forwarding is a simpler, static mechanism. The FortiGate forwards specified multicast traffic between interfaces based on explicitly configured multicast policies, without running a routing protocol.

Key characteristics:

Configured under config firewall multicast-policy.
You define source/destination interfaces, source/destination address ranges (the multicast group), protocol, and action (accept/deny).
No PIM, no RP, no dynamic tree building. The FortiGate simply relays matching multicast frames between the interfaces you specify.
Supports NAT of the multicast source address via set snat enable and set snat-ip, which standard multicast routing does not do.
A multicast policy is required to permit multicast traffic through the firewall even when multicast routing is enabled. By default, the policy list will deny multicast traffic if no matching accept policy exists.

Use this for straightforward “push this group from interface A to interface B” scenarios, lab/streaming setups, or when you need source NAT on multicast streams.

The Critical Interaction

The point that trips people up: enabling multicast routing alone is not enough. Multicast traffic must still be permitted by a multicast firewall policy (config firewall multicast-policy) to traverse the FortiGate. PIM builds the path; the multicast policy authorizes the traffic across that path. You generally need both for inter-subnet multicast to actually flow.

By contrast, pure static multicast forwarding can work with just the multicast policy and no PIM at all, provided the topology is simple enough that dynamic tree building is unnecessary.

Quick Comparison

Aspect	Multicast Routing	Multicast Forwarding
Mechanism	PIM-SM / Sparse-Dense	Static policy relay
Config context	`config router multicast`	`config firewall multicast-policy`
Dynamic tree building	Yes	No
RP / IGMP / PIM needed	Yes	No
Source NAT support	No	Yes (snat)
Best for	Multi-subnet, dynamic membership	Simple A-to-B relay, NAT scenarios
Policy still required?	Yes (must permit traffic)	Yes (it is the mechanism)

Bottom line: routing decides the path dynamically using protocols; forwarding statically relays defined groups between interfaces. In most real FortiGate deployments doing inter-VLAN multicast, you configure both: PIM for the path and a multicast policy to allow the traffic.

Multicast Routing vs Multicast Forwarding on FortiGate

Multicast Routing (PIM-based, Layer 3)

Multicast Forwarding (Static, Policy-based)

The Critical Interaction

Quick Comparison

Recent posts