Configure and validate PIM-SM on Sophos Firewall

PIM-SM is suitable when multicast crosses multiple routers and receivers dynamically join or leave groups. Instead of maintaining a fixed route for every source and outgoing interface, PIM-SM builds the required multicast path through a Rendezvous Point, or RP.

The short procedure is:

Prepare a backup and independent management access, then document the source, group, UDP service, routers, and receiver networks.
Check unicast reachability to the RP and source network on every router.
Back up existing static multicast routes and disable Enable multicast forwarding in a controlled manner.
Check Device Access in the zones containing actual PIM neighbors and allow Dynamic Routing only where required.
Under Routing > Multicast (PIM-SM), enable PIM on the participating IPv4 interfaces.
Configure the same static RP and group range on all PIM routers.
Allow the multicast data stream with narrow, logged IPv4 firewall rules.
Check the receiver join, neighbor, RP SET, multicast state, Rule ID, and packet path together.

⚠️ PIM-SM and Static Multicast Forwarding cannot be configured at the same time on Sophos Firewall. Switching changes the production multicast path. Existing routes, groups, receivers, and a rollback path must be documented first.

This article covers dynamic IPv4 multicast routing with a static RP. Within a PIM domain, a Bootstrap Router, or BSR, distributes the information that determines which RP is responsible for which groups. Candidate RP is discussed later, but it is not treated as an ostensibly automatic Bootstrap Router solution.

When PIM-SM is the right choice

PIM-SM is particularly useful when several multicast routers are involved, receivers reside in different networks, or group memberships change frequently. The routers then build state only where a sender or an interested receiver exists.

For one known sender and a few permanently fixed outgoing interfaces, a static multicast route is usually simpler. It requires neither an RP nor a PIM neighbor relationship. PIM-SM is not simply a better option for the same small setup; it is a different operating model.

PIM-SM also replaces neither unicast routing nor firewall rules:

Unicast routing determines the direction in which the source and RP are reachable.
PIM-SM uses that information to build the multicast distribution tree between routers.
IGMP signals which hosts want to receive a group in the local receiver network.
Firewall rules allow or block the actual multicast data stream between zones.

Understand IGMP, RP, and RPF

A receiver sends an IGMP membership report for its group on the local IPv4 network. The last multicast router translates this interest into a PIM Join toward the RP. The RP is the common meeting point through which senders and receivers initially find each other. Depending on the state that is established, the data path may later switch to a shorter source tree, so the RP does not necessarily have to forward every data packet permanently.

In the multicast table, (*,G) represents the shared state for a group independently of a specific source. (S,G), by contrast, represents the state for a specific source S and group G. In this example, it is (10.10.10.20, 239.10.10.10).

The decisive control mechanism is Reverse Path Forwarding, or RPF. For a packet from source 10.10.10.20, the firewall checks which interface it would use to reach this source according to the routing table. If the multicast stream arrives on a different interface, the reverse path does not match and the state or data flow may fail.

PIM is independent of the unicast routing protocol in use, but it is not independent of working unicast routes. Static routes, OSPF, or BGP can provide the RPF path. Static unicast routes are sufficient for the following example; in larger routing domains, OSPF can provide the same foundation dynamically.

Plan the example topology

The example connects a sender behind Firewall A to a receiver behind Firewall B:

Sender: 10.10.10.20
Source network on Firewall A: 10.10.10.0/24, interface Port2, zone DMZ
Firewall A transit: 10.255.0.1/30, interface Port4, zone PIM-Transit
Firewall B transit: 10.255.0.2/30, interface Port4, zone PIM-Transit
Receiver network on Firewall B: 10.20.20.0/24, interface Port3, zone LAN
Test receiver: 10.20.20.50
Multicast group: 239.10.10.10
Application service: UDP 5000
Static RP: 10.255.0.1
RP group range: 239.10.10.0/24

The addresses are private example values. Replace the source, receiver network, transit network, group, and service together with the values of the real application. In this example, RP 10.255.0.1 is located on Firewall A and must be reachable from all PIM routers by unicast.

The group range 239.10.10.0/24 is deliberately narrower than *. An asterisk assigns all groups to the RP and should only be used when the entire PIM domain is designed that way. Sophos documents a maximum of eight group or network entries per RP.

The unicast routes must be in place before PIM is configured. Firewall A receives a route to 10.20.20.0/24 through 10.255.0.2; Firewall B receives a route to 10.10.10.0/24 through 10.255.0.1. For RPF, the path from Firewall B back to the source is particularly important. Under Diagnostics > Tools > Route lookup, a lookup for 10.10.10.20 must therefore point to Port4 and the expected next hop. These unicast routes do not replace the PIM distribution tree.

Configure Sophos Firewall zones and interfaces explains how to separate interfaces and zones cleanly for this type of transit.

Prepare PIM-SM safely

Record the following points before the maintenance window:

The transit IP addresses and unicast routes have been tested in both directions.
The source, group, UDP port, and receiver application are known.
The static RP and its group range are documented identically for all routers.
Existing static multicast routes and Enable multicast forwarding have been inventoried.
A configuration backup and independent management access are available.
Switches in the receiver network use IGMP Snooping only with a clarified and working querier role.

The current Sophos documentation lists physical, RED, and GRE interfaces for PIM. Alias, PPPoE, and Cellular WAN interfaces are excluded. Other interface types such as XFRM are not explicitly confirmed on the PIM page and therefore do not belong in this basic setup without prior validation.

Check Dynamic Routing selectively

PIM messages belong to the firewall’s control plane. The general SFOS help groups routing protocols under Administration > Device access > Dynamic Routing; however, the current PIM page does not explicitly state this dependency.

If no PIM neighbor relationship is established, check whether Dynamic Routing must be allowed in the zone containing the actual neighbor. In the example, the dedicated PIM-Transit zone contains only the transit network between the two firewalls. If this permission is required for the setup, enable it on both devices exclusively in that zone.

The matrix permission applies to the entire zone. If the same zone contains additional untrusted networks, leave the checkbox cleared and use a narrowly scoped Local Service ACL Exception to allow Dynamic Routing only from the intended neighbors. An additional exception does not restrict a zone permission that is already enabled.

This Device Access layer is intended for routing control traffic. If the deployed build requires this permission for PIM, it does not apply to the forwarded stream and does not replace its firewall rule. Secure Device Access on Sophos Firewall explains the two access layers.

Replace Static Multicast Forwarding in a controlled manner

Under Routing > Static routes, document the existing multicast routes, dependent applications, and destination interfaces. Disable Enable multicast forwarding only during the maintenance window. PIM-SM can then be enabled.

Do not delete existing static multicast routes as a precaution. Keep them as a documented rollback template until PIM-SM has been fully validated.

Configure PIM-SM

Perform the following steps on Firewall A and Firewall B.

Enable PIM and the participating interfaces

Open Routing > Multicast (PIM-SM).
Select Enable PIM.
Under PIM-enabled interface, select only the IPv4 interfaces participating in the multicast path:
- Firewall A: Port2 and Port4
- Firewall B: Port4 and Port3
Do not yet treat the change as successful; check the neighbor and state only after the full RP configuration is complete.

Do not enable PIM indiscriminately on all LAN or WAN interfaces. Every additional interface expands the control plane and can permit new neighbors or multicast paths.

Configure the static RP and group range

Under RP settings, enable the option and enter the same static mapping on both firewalls:

RP IP: 10.255.0.1
Multicast group: 239.10.10.0/24

The RP IP is a unicast address. From both firewalls, it must be reachable through the intended PIM path. A saved value alone is not sufficient: under Routing > Information > PIM-SM > RP SET, the group must later actually be assigned to this RP.

Save the configuration. If PIM cannot be enabled, first check whether Enable multicast forwarding is still active.

When Candidate RP is appropriate

Candidate RP is appropriate for an existing PIM domain in which the BSR role and RP selection procedure have already been designed. For this purpose, SFOS provides an interface IP as the Candidate RP IP, a group list, a priority from 1 to 255, and an advertisement interval from 30 to 180 seconds.

However, configuring Candidate RP alone does not automatically make the firewall a functioning BSR or guarantee the desired RP selection. Sophos does not document a complete Bootstrap Router setup in WebAdmin. Therefore, use Candidate RP only when the BSR role is known and the resulting group-to-RP mapping can be checked in RP SET. For this manageable example, Static RP is easier to understand.

Create firewall rules for the data stream

The PIM neighbor relationship does not provide a blanket security permission. On every router, the stream requires a narrow IPv4 firewall rule for the corresponding zone crossing.

The intended configuration on Firewall A is:

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

On Firewall B, create a second rule from PIM-Transit to LAN with the same source, group, and UDP service. No SNAT is intended for this test so that the source and (S,G) remain intact.

The rules apply to the multicast data stream. Do not combine PIM Hellos and IGMP membership reports in a broad Any rule. Verify through the Rule ID that the group object matches as expected on the deployed build. If Rule 0 appears, do not broaden the rule without control; analyze the packet path instead.

Configure secure Sophos Firewall rules explains the general setup.

Validate PIM-SM from the neighbor to the receiver

A visible PIM neighbor relationship is only the first part of validation:

Under Routing > Information > PIM-SM > Interface table, the other firewall must appear as a neighbor on the transit interface.
Under RP SET, 239.10.10.0/24 must point to 10.255.0.1.
On 10.20.20.50, start the receiver application and join 239.10.10.10 on UDP 5000.
Start a time-limited test stream from 10.10.10.20.
Under Multicasting routing table, look for (*,G) or (S,G) state for the group. The incoming and outgoing interfaces must match the topology.
Check the expected Rule ID in Log Viewer on both firewalls.
Under Diagnostics > Packet capture, check with the following BPF filter:
```
src host 10.10.10.20 and dst host 239.10.10.10 and udp port 5000
```
The stream must enter Firewall A on Port2 and leave on Port4. On Firewall B, it must enter on Port4 and be forwarded through Port3. Then verify the actual content on the receiver.

Use Packet Capture on Sophos Firewall explains the Packet Capture workflow with interface, Rule ID, status, and reason.

During a bounded test, the following BPF filters can additionally be used for control traffic:

ip proto 103

103 represents PIM. IGMP uses IP protocol 2:

ip proto 2

The filters show whether PIM and IGMP packets are present. By themselves, they prove neither that the RP is correct nor that the data stream works.

In the Advanced Shell, pimd.log provides additional context. The following commands only read data:

tail -n 200 /log/pimd.log
grep '239.10.10.10' /log/pimd.log | tail -n 100

An empty grep result does not prove an error; the current state in WebAdmin and the real packet path remain decisive. Sophos Firewall service and log files explains additional routing and log files.

Troubleshoot by symptom

No PIM neighbor appears

Check direct reachability between transit IP addresses 10.255.0.1 and 10.255.0.2.
Verify that Port4 is selected as a PIM-enabled interface on both firewalls.
Check Dynamic Routing in the correct transit zone or the corresponding Local Service ACL Exception.
Use ip proto 103 to check whether PIM packets reach and leave the transit interface.
Make sure an interface type documented by Sophos for PIM is used.

The neighbor is present, but RP SET is missing or incorrect

Compare the RP IP and group range character by character on all routers.
Check unicast reachability to 10.255.0.1.
When using Candidate RP, first clarify the actual BSR role. A configured candidacy alone is not sufficient.
Do not broaden the range to * until the reason the specific group is not assigned has been identified.

RP SET is correct, but no multicast state is established

Check whether the receiver has actually joined the correct group and UDP port.
Use ip proto 2 to look for IGMP Reports and Queries in the receiver network.
If IGMP Snooping is used, check the querier role in the VLAN. Do not change IGMP timers speculatively; the basic procedure does not require timer adjustments.
Verify that the sender is actually transmitting to 239.10.10.10:5000.

State exists, but the incoming interface is incorrect

Run Route Lookup for source 10.10.10.20 and RP 10.255.0.1 on every firewall.
Check static, OSPF, SD-WAN, and VPN routes for an unexpected better path.
Do not change the global Route Precedence until the incorrect RPF path has been demonstrated with the routing table and a capture.
Document asymmetric return paths and parallel connections separately.

The stream leaves the firewall but does not reach the receiver

Check the Rule ID, status, and outgoing interface on both firewalls.
Check the switch port, VLAN, and IGMP Snooping in the receiver network.
Check the local host firewall and receiver application.
Compare a capture on the receiver or switch port with the SFOS timestamps.

Consider HA and interface limitations

In Active-Active HA, multicast is not load-balanced between both nodes. UDP, broadcast, and multicast sessions are not retained during failover. A controlled role switch can therefore interrupt the stream; afterwards, check the neighbor, RP SET, RPF, multicast state, rules, and receiver again.

Logs are stored locally on each node. In the event of an HA problem, save the data from the node that was active before the switch. Do not assume hitless synchronization of the PIM state.

This basic article uses physical interfaces. Sophos additionally lists RED and GRE as PIM-capable. This is not confirmation of PIM directly on XFRM, IPsec, or SSL VPN interfaces. An encrypted or provider-dependent multicast design therefore requires a separate, tested architecture.

Roll back safely

Perform the rollback during the maintenance window:

Stop the test stream and document the last working or failed state.
Disable the newly created multicast firewall rules.
Disable PIM on both firewalls.
Remove Dynamic Routing from the transit zone only if no other routing protocol depends on it.
Re-enable Static Multicast Forwarding only if the previous state and its routes are fully documented.
Recheck management access, unicast routes, and the previously operational applications.

No PIM service restarts, debug switches, or undocumented Advanced Shell commands are required for this rollback.

Frequently asked questions

Does PIM-SM replace IGMP or the firewall rule?

No. IGMP signals receiver interest on the local network, PIM-SM connects the participating multicast routers, and the firewall rule permits the specific data stream between zones. All three layers must match the same design.

Why does a unicast route affect the multicast path?

PIM-SM uses RPF. Based on its routing information, the firewall checks which interface it would use to reach the source or RP. If this route points to the wrong interface, the expected reverse path does not match and the multicast state may remain incorrect or incomplete.