Configure and test static multicast routing on Sophos Firewall

A static multicast route forwards the data stream from a known sender to a fixed multicast group through selected interfaces. This is suitable, for example, for a video, audio, or telemetry stream whose source, group, and receiver networks remain fixed.

This procedure covers static IPv4 multicast routing. IPv6 multicast is outside the scope of this guide.

The short procedure is:

Document the source IP, multicast group, UDP port, inbound interface, and outbound interface.
Under Routing > Static routes, select Enable multicast forwarding.
Under Manage multicast route > Add, enter the source, group, and interfaces.
Create a narrowly scoped, logged IPv4 firewall rule for the data stream.
Have a real receiver join the group and start the stream.
Check the route, Rule ID, inbound traffic, and outbound traffic with mroute show, Log Viewer, and Packet Capture.

⚠️ Static Multicast Forwarding and PIM-SM cannot be configured at the same time on Sophos Firewall. PIM must be disabled for Static Multicast Forwarding. Before switching, determine whether PIM-SM or another static multicast route is already in production use.

Understand multicast, IGMP, and the static route

With unicast, a host sends to one destination address. With multicast, the source sends once to a group address, and multiple receivers can join the same data stream. The firewall does not copy the stream to arbitrary networks, but only to the Destination Interfaces entered in the multicast route.

The example uses the fixed combination of sender 10.10.10.20 and group 239.10.10.10. This combination is commonly considered the Source and Group, abbreviated as (S,G). If the application changes its source IP or group, the route no longer matches.

IGMP indicates within the local IPv4 segment that a receiver wants to join or leave a multicast group. A switch with IGMP Snooping can therefore send the stream only to ports with interested receivers. However, the static Sophos route does not learn new Destination Interfaces from this: Port3 remains fixed in the configuration even when no receiver is currently listening there.

PIM-SM solves a different problem. It builds multicast paths dynamically between multiple multicast routers and requires a planned Rendezvous Point and unicast routing design. For one known sender and a few fixed receiver interfaces, a static route is usually easier to understand. With multiple routers, changing groups, or many multicast paths, PIM-SM requires a dedicated design.

A static multicast route is also not a normal static unicast route. It does not use a traditional next hop and appears in a separate area.

mDNS is a different use case

mDNS for Bonjour, AirPlay, or many Chromecast discovery requests uses the link-local address 224.0.0.251. Sophos permits groups from 224.0.2.0 to 239.255.255.255 in a static multicast route. mDNS is outside this range and is not forwarded by routers like normal multicast traffic.

This guide therefore does not replace an mDNS reflector or discovery gateway. A media stream can work over multicast while automatic device discovery between VLANs still does not work.

Plan the example topology

The example uses these values:

Sender: 10.10.10.20
Source Interface: Port2
Source Zone: DMZ
Multicast group: 239.10.10.10
Application service: UDP 5000
Destination Interface: Port3
Destination Zone: LAN
Receiver network: 10.20.20.0/24
Test receiver: 10.20.20.50

10.10.10.20 and 10.20.20.0/24 are private example values. 239.10.10.10 belongs to the administratively scoped multicast range and is suitable for a controlled local example. In the actual environment, replace the source, group, port, and interfaces together with the values required by the application and topology. Do not change the group arbitrarily: the sender and receivers must use the same address and service.

The application must also send with a sufficient TTL. During normal routing, each hop reduces the TTL by one. If the application sends with TTL 1, the stream cannot reach another segment while TTL decrementing is active.

Before making the change, establish the following:

The firewall runs in Gateway Mode.
The sender reaches Port2, and the receivers are behind Port3.
The receiver application can actually join group 239.10.10.10 on UDP 5000.
Existing PIM-SM, other multicast routes, and their dependencies are documented.
The switches, VLANs, and IGMP Snooping settings in the receiver network are known.
A configuration backup and independent management access are available.

Configure Sophos Firewall zones and interfaces explains how interfaces, VLANs, and zones fit together.

Create the static multicast route

Enable Multicast Forwarding

In WebAdmin, open Routing > Static routes.
Under Multicast forwarding setting, select Enable multicast forwarding.
Click Apply, then OK.

If the option cannot be enabled, first check whether PIM-SM is active. The two methods cannot be configured in parallel. Do not disable PIM-SM without first documenting its existing neighbors, groups, and receivers.

Enter the source, group, and interfaces

Under Manage multicast route, click Add.
Under Source IPv4 address, enter 10.10.10.20.
Select Port2 as the Source interface.
Under Multicast IPv4 address, enter 239.10.10.10.
Select Port3 as the Destination interface.
Click Save.

WebAdmin can save multiple Destination Interfaces in one route. However, every additional interface expands the area to which the stream is forwarded. Select an interface only when receivers really exist there and the security rule also covers it. The Source Interface and Destination Interface must not be identical.

Restrict the firewall rule

The multicast route determines the path, but it does not allow the data stream by itself. For forwarding from DMZ to LAN, create a dedicated IPv4 firewall rule:

Rule name: DMZ_to_LAN_Multicast_5000
Action: Accept
Log firewall traffic: enabled
Source zone: DMZ
Source network: Host 10.10.10.20
Destination zone: LAN
Destination network: Host 239.10.10.10
Services: a dedicated UDP service with Destination Port 5000

The destination is the multicast group, not the receiver network 10.20.20.0/24. Restrict the rule to the real sender, the actual group, and the required service. This example does not use a broad Any rule or a blanket allow rule for IGMP or PIM.

The rule is the narrowly scoped intended configuration for this example topology. Confirm its actual match on the deployed SFOS version using the expected Rule ID. If Rule 0 appears, do not broaden the rule without control; investigate it with Log Viewer and Packet Capture.

This example does not use SNAT so that the source and (S,G) mapping remain intact. Nevertheless, check existing NAT rules for an unexpected match. Configure Sophos Firewall rules securely explains the general rule structure.

Test the data stream in a controlled manner

A saved route does not prove that the receiver obtains the stream. Validate the path from the application to the client:

On 10.20.20.50, start the receiver application and join group 239.10.10.10 on UDP 5000.
Start a clearly bounded test stream from 10.10.10.20, and record the start time and expected duration.
In Log Viewer, check whether DMZ_to_LAN_Multicast_5000 or the expected Rule ID matches.
Under Diagnostics > Packet capture, filter with this BPF expression:
```
src host 10.10.10.20 and dst host 239.10.10.10 and udp port 5000
```
In the packet list, confirm that the stream arrives on Port2 and appears on Port3 with status Forwarded.
On the receiver, confirm that packets arrive and the application processes the content.

Use Packet Capture on Sophos Firewall explains the Packet Capture workflow with interfaces, Rule IDs, and status values.

The static multicast routing table can also be displayed read-only in the Device Console. The path is 3. Route Configuration > 2. Configure Multicast Routing > 2. Configure Static-routes:

mroute show

The output must show the expected source, group, inbound interface, and outbound interface. The command does not change the configuration.

For deeper troubleshooting, the current SFOS 22 documentation identifies mrouting.log. In the Advanced Shell, read only the most recent entries:

tail -n 200 /log/mrouting.log

Sophos Firewall service and log files lists additional files and service mappings.

Troubleshoot by symptom

The route cannot be enabled or saved

Check whether PIM-SM is still active. Static Multicast Forwarding and PIM-SM cannot be configured at the same time.
Check the source IP, group range, and interfaces. Permitted groups range from 224.0.2.0 to 239.255.255.255.
The Source Interface and Destination Interface must not be identical.
If a route already exists, check whether the same (S,G) combination is already configured.

The stream arrives but is not forwarded

Do the actual source IP and group exactly match the route?
Does mroute show display the expected interfaces?
Does the intended firewall rule match, or does the capture show a different Rule ID or Rule 0?
Is Port3 really selected as the Destination Interface?
Does a NAT rule unexpectedly change the source?

The stream leaves the firewall but does not reach the receiver

Check the sender TTL and the global multicast-decrement-ttl setting. Do not change the setting as a blanket measure.
Check the VLAN, switch port, and IGMP Snooping in the receiver network.
Make sure 10.20.20.50 joins the correct group and UDP port.
Check the local host firewall and the application on the receiver.
Compare a capture on the receiver or switch port with the SFOS timestamps.

Device discovery fails even though the stream works

Discovery protocols such as mDNS are link-local and are not reflected by this static route. Test the actual data stream and device discovery separately.

Handle VPN and HA separately

Sophos does not support multicast over SSL VPN. Static multicast routes over IPsec or a previously validated GRE tunnel are possible and use separate CLI forms. For IPsec, Sophos additionally requires an explicit unicast host with /32 in the VPN configuration. The publicly documented examples contain several inconsistent notations, so they should not be copied unverified into a production firewall.

The firmware version is also important when multicast passes through a VPN tunnel. IPsec troubleshooting for NC-180433 covers repeated firewall crashes that coincide with this traffic. The issue is fixed in SFOS 22.0 MR2 Build 546; normal packet loss or a missing stream does not prove this specific issue.

In an HA cluster, multicast is not load-balanced between both nodes. After a planned failover, check the route, Rule ID, inbound traffic, outbound traffic, and receiver again. Sophos does not document a guarantee of uninterrupted multicast failover, so perform the test in a maintenance window. Save logs and Packet Captures on the currently active node.

Roll back safely

Before rolling back, document the route, rule name, and previous test values. Then:

Stop the test stream.
Disable the new firewall rule.
Remove the static multicast route in WebAdmin.
Disable Enable multicast forwarding only when no other static multicast route depends on it.
Test the previous state of the affected applications and networks again.

A CLI delete command is not required for this rollback. This keeps the rollback traceable and avoids the inconsistent publicly documented delete syntax.

Frequently asked questions

When is a static multicast route better than PIM-SM?

A static route is usually simpler when the sender, group, and a few Destination Interfaces remain fixed. PIM-SM is suitable for multiple multicast routers, dynamic paths, and many changing groups.

Can this discover Bonjour, AirPlay, or Chromecast devices across VLANs?

Not with this route alone. mDNS uses 224.0.0.251, is link-local, and requires a purpose-built reflection or gateway function for forwarding between VLANs.

Why is an additional firewall rule required?

The multicast route specifies where the stream is forwarded. The firewall rule still determines whether this exact source, group, and UDP service may pass between the participating zones.