Introduction

Linux kernel's reverse path filtering (RPF) is a security feature designed to help prevent IP address spoofing. While effective for security, this feature can cause unintended side effects, such as dropping legitimate multicast packets. This issue is particularly prevalent in embedded devices running Linux when multicast packets are received with a source IP address from a different subnet than the device's interfaces.

This article explains how reverse path filtering works, why it causes problems for multicast traffic in certain cases, and how to resolve this issue on Linux-based embedded devices.

What is Reverse Path Filtering?

Reverse path filtering (RPF) is a kernel-level feature designed to enforce that inbound packets only arrive from interfaces that the kernel believes can reach the packet's source IP address. This check is done to prevent spoofed packets—malicious traffic that uses a fake source IP to hide the attacker’s identity.

The reverse path filter works in two modes:

• Strict mode: The kernel checks if the packet's source IP address would be routed back through the interface it arrived on. If not, the packet is dropped.
• Loose mode: The kernel checks if the packet's source IP address could be routed through any of the device’s interfaces. If it could, the packet is accepted; otherwise, it’s dropped.

The relevant settings are stored in /proc/sys/net/ipv4/conf/<interface>/rp_filter:

• 0: Disable RPF (no filtering)
• 1: Enable strict mode (the default on many Linux systems)
• 2: Enable loose mode

How Does RPF Affect Multicast Traffic?

Multicast traffic is often used in networked devices for efficient delivery of data streams, but it can be problematic when reverse path filtering is enabled. Here’s why:

1. Multicast Destination with Different Source IP Subnet: Multicast traffic often uses a source IP address that doesn’t belong to the same subnet as the receiving device’s interfaces. For example, a multicast packet may come from a source in a different network, but its destination is valid and intended for a group that the device has subscribed to.

2. Reverse Path Filter Drops Packets: When strict reverse path filtering is enabled, the kernel checks the source IP of the multicast packet and attempts to verify whether it could reach that IP through the interface on which it was received. If the source IP belongs to a different subnet, the packet will be dropped, even if the packet is legitimate and part of a multicast group that the device has subscribed to.

This behavior can lead to multicast packet loss. Some multicast applications that can be affected by this, are IGMP and PTPv2 boundary clock.

Example Scenario

Consider an embedded device with two network interfaces:

• eth0 (192.168.1.2/24)
• eth1 (10.0.0.2/24)

The device subscribes to a multicast group, say 239.1.1.1, and starts receiving multicast packets. However, the source IP address of these packets is from the 172.16.0.0/16 network.

With RPF in strict mode, when the packet arrives on eth0, the kernel checks if the source IP (172.16.x.x) can be routed via eth0 (192.168.1.2). Since there’s no valid route back to the source through eth0, the packet is dropped.

Practical issues as a result of Reverse Path Filtering:

IGMP querier IP

PTPv2 boundary clock

Workaround

Conclusion

Reverse path filtering is a useful security mechanism but can lead to issues with multicast traffic on embedded Linux devices when source IP addresses are from different subnets. By adjusting RPF settings—either disabling it or switching to loose mode—we can prevent the kernel from dropping legitimate multicast packets and ensure proper operation of the embedded device in multicast environments. This typically has to be done by the device manufacturer, in firmware.