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.
Have a real receiver join the group and start the stream.
Check the route, inbound traffic, and outbound traffic with mroute show and Packet Capture.

⚠️ Enable multicast forwarding is a global setting. Before enabling it, inventory existing PIM-SM configurations, static multicast routes, and dependent streams. Test the change first with a limited test stream; if unexpected behavior occurs, revert it before adding further Destination Interfaces.

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.

From SFOS 23 onward, this separate discovery task is configured through the mDNS reflector under Network > mDNS. Selecting internal interfaces and service categories, along with separately allowing application traffic, is part of this distinct procedure; it does not replace the static multicast route described here.

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, review the existing multicast configuration. Do not change an existing PIM-SM configuration without planning: the relevant pages of the current SFOS 22 help do not document a blanket statement about coexistence, so the behavior of the installed build and the approved network design are decisive.

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.

Use the CLI as a controlled fallback

In Device Console, go to 3. Route Configuration > 2. Configure Multicast Routing. Multicast forwarding must be active before the first route is added. It can be enabled in Gateway and Transparent Mode, but static multicast routes can only be configured in Gateway Mode. Under option 1, this command enables global forwarding:

enable multicast-forwarding

⚠️ According to Sophos, incomplete Device Console commands can cause access_server to stop responding. Complete the syntax against the installed build using ? or Tab, and run the full command only after doing so.

Under 2. Configure Static-routes, add a route between two static interfaces and verify it immediately:

mroute add input-interface Port2 source-ip 10.10.10.20 dest-ip 239.10.10.10 output-interface Port3
mroute show

The CLI requires a separate mroute add entry for every output interface. It only offers static interfaces, while WebAdmin can also show dynamic interfaces such as DHCP and PPPoE. The input and output interfaces must differ; a non-Ethernet interface such as IPsec0 does not belong in this port form.

For a targeted rollback of a physical route, Sophos specifies the values positionally. Verify the interface names with mroute show first:

mroute del Port2 10.10.10.20 239.10.10.10 Port3
mroute show

Sophos publishes separate input-tunnel and output-tunnel forms for IPsec and GRE routes, but the examples do not use consistent spelling throughout. Treat command completion on the installed SFOS version as authoritative and do not paste a public example without verification.

Do not assume a security rule is required

The official SFOS 22 procedure for creating a static multicast route does not specify an additional firewall or NAT rule. Therefore, this example does not create a broad precautionary Any rule. Use Packet Capture to determine from the actual packet status whether the installed build or an existing policy nevertheless requires an additional match.

If the firewall shows a policy-related drop, do not guess. First record the source 10.10.10.20, group 239.10.10.10, UDP 5000, the participating zones, and the displayed rule context. Only after confirming the requirement for the deployed build should an allow rule be limited to exactly these values and logged. 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.
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. If a packet is dropped, record the displayed status and rule context without broadening a rule on suspicion.
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 context, 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 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 the same (S,G) combination already exists, also compare the Destination Interface. For multiple outbound interfaces, the CLI requires a separate entry with the same source and group for each one.

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 capture show Forwarded, or a drop with usable rule context?
Is Port3 really selected as the Destination Interface?

The stream leaves the firewall but does not reach the receiver

Check the sender TTL. Do not change global routing parameters on suspicion.
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 Active-Active HA, multicast is not load-balanced between both nodes. Sophos also excludes multicast from session failover. A role change must therefore be expected to interrupt the stream. Before failover, save the capture and timestamps on the previously active node; afterward, check the route, inbound traffic, outbound traffic, and receiver again on the new active node.

Roll back safely

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

Stop the test stream.
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.

If the example route was created through the CLI instead, remove it with the officially documented mroute del command for physical interfaces shown above, and verify the result with mroute show. No unconfirmed deletion example is used for tunnel routes.

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.