<?xml version="1.0" encoding="UTF-8"?><rss xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:atom="http://www.w3.org/2005/Atom" version="2.0"><channel><title><![CDATA[Help needed to understand pfSense Multicast and Broadcast behavior.]]></title><description><![CDATA[<p dir="auto">Hello,</p>
<p dir="auto">I am using pfSense as firewall but of course also as router. pfSense is the node where data streams between subnets should be passed / interchanged, if that is required. That for unicast, broadcast and multicast.</p>
<p dir="auto">The problems I am facing are related to broadcast and multicast. Despite a lot of effort I simply do not manage to get broadcast and multicast working across subnets.</p>
<p dir="auto"><em>That is why I wrote this message hoping for comments and help. I also hope the description will help others.</em></p>
<p dir="auto">Multicast is complex. A lot of things should be OK, to make it work. To mention: the sending application, the local firewall on that server, the pfSense firewall, the pfSense router, the receiving firewall, the receiving application.</p>
<p dir="auto">I have chosen to take Simple Service Discovery Protocol (SSDP) as example, trying to describe a more generic situation. SSDP is essential for communication between e.g. a media server and a media player / uPNP.</p>
<p dir="auto">SSDP does have following addressing modes:<br />
•	239.255.255.250 (IPv4 site-local address)<br />
•	[FF02::C] (IPv6 link-local)<br />
•	[FF05::C] (IPv6 site-local)<br />
•	[FF08::C] (IPv6 organization-local)<br />
•	[FF0E::C] (IPv6 global)</p>
<p dir="auto">Below a (concept) description from what is needed to make the communication between a media-server and a media player work, under link-local, site-local and global-scope address conditions.</p>
<p dir="auto">It is important to understand that in case IPV4 but equally if not more important also in case IPV6. I hope to improve this description with your help.</p>
<p dir="auto"><strong>media server</strong></p>
<ul>
<li>the media server have to make his its presence known. It does so by sending broadcast messages towards the scoped destination being “link-local”, “site-local”, “organization-local” or “global”. Normally the server sends a couple of messages starting with link-local up to and including the desired level;</li>
<li>Is using a TTL-value (Time to live, as checked by the firewall) high enough to reach the destination;</li>
<li>And has a receive scope settings corresponding with the destination scope;</li>
<li>The local firewall on the media server should allow to pass the messages;<br />
Note that most users only have one subnet and for that and for security reasons, the default settings are often related to the “link-local” scope.</li>
</ul>
<p dir="auto"><strong>pfSense Firewall</strong></p>
<p dir="auto"><em>Link-local:</em><br />
There are two situations to distinguish:</p>
<ul>
<li>
<p dir="auto">The media server and the media receiver(s) are on the same subnet<br />
o	This is the simple situation the firewall should not pass the traffic;<br />
o	The traffic is not to be routed.</p>
</li>
<li>
<p dir="auto">The media server and one or more receivers are on another subnet (guest-lan, IoT-lan, whats ever)<br />
o	Tja ….. the real-scope is not corresponding with the routing scope<br />
o	There are solutions for this using “pimd”, “mcproxy”, “IGMP proxy”, however note that<br />
	“pimd” is IPV4-only (not supported by pfSense <img src="https://forum.netgate.com/assets/plugins/nodebb-plugin-emoji/emoji/android/2639.png?v=717669fab53" class="not-responsive emoji emoji-android emoji--white_frowning_face" style="height:23px;width:auto;vertical-align:middle" title="☹" alt="☹" />),<br />
	“pim6sd” IPV6 version of pimd (not supported by pfSense <img src="https://forum.netgate.com/assets/plugins/nodebb-plugin-emoji/emoji/android/2639.png?v=717669fab53" class="not-responsive emoji emoji-android emoji--white_frowning_face" style="height:23px;width:auto;vertical-align:middle" title="☹" alt="☹" />),<br />
	“IGMP proxy” is IPV4-only. I am almost sure, and I am not the only one, it is “not at all working (201907)”<br />
o	I assume that a FW-rule is needed to pass the “local” traffic towards the “interworking application” (not sure);<br />
o	And an (outbound) rule to allow messages to allow traffic coming back from the “interworking application” to enter the involved subnets;</p>
</li>
</ul>
<p dir="auto"><em>Site-local, organization-local, global:</em></p>
<ul>
<li>There should be a rule to pass the traffic</li>
</ul>
<p dir="auto"><strong>pfSense Routing</strong></p>
<p dir="auto"><em>Link-local:</em></p>
<ul>
<li>
<p dir="auto">Situation-1: the media receiver(s) are on the same subnet<br />
o	there is no routing <img src="https://forum.netgate.com/assets/plugins/nodebb-plugin-emoji/emoji/android/1f60a.png?v=717669fab53" class="not-responsive emoji emoji-android emoji--blush" style="height:23px;width:auto;vertical-align:middle" title="😊" alt="😊" />;</p>
</li>
<li>
<p dir="auto">Situation-2: Link-local routing is used across subnets, using an “interworking function”,<br />
o	there is routing needed towards and from the (internal) “interworking function”;<br />
o	Or towards a gateway / route in case of an external destination (no idea how to do that and if that really should be an option);<br />
o	I assume the used broadcast / multicast addresses should be bind towards the “interworking function”;<br />
o	And that the results are forwarded to all given destination subnets.  Probably a broadcast to all local subnet with a blocking rule added for all subnets to be excluded.</p>
</li>
</ul>
<p dir="auto"><em>Site-local:</em></p>
<ul>
<li>
<p dir="auto">I really do not know what the pfSense behavior. That is one of the reasons for this memo!</p>
</li>
<li>
<p dir="auto">My expectation in case of a site-local-address-scope is that:<br />
o	the broadcast should be forwarded to all local-subnets;<br />
o	assuming a rule the (LAN)-gateway is forwarding the broadcast / multicast message towards the “pfSense core”<br />
o	so all local subnets should not only listen to the unicast ranges they own, but also to site-local broadcast and multicast address ranges;<br />
o	and personally I would always create two floating rules: the first one to pass (quick) the traffic to the intended subnets the second to block (quick) the rest.</p>
</li>
<li>
<p dir="auto">My feeling is that:<br />
o	In a lot of cases site-local tricks are not necessary / can be solved by using site-local-addressing (in opposite link-local);<br />
o	Not being an expert, I also have a feeling that site-local-addressing is not implemented / or working …</p>
</li>
</ul>
<p dir="auto"><em>Global:</em></p>
<ul>
<li>My expectation in case of a global-address-scope is that:<br />
o	The broadcast is only send to the specified address;<br />
o	If the “pfSense core” has that destination for the “broadcast / multicast” address it will forward the message to that destination locally. If that internal destination is not available it will forward the message towards the WAN-gateway.</li>
</ul>
<p dir="auto"><strong>media player</strong></p>
<ul>
<li>The media player firewall (assume there is one) should pass traffic coming from and going to the media server</li>
</ul>
<p dir="auto">Be aware that I am not an expert on multicast and that probably not everything written above is correct!</p>
<p dir="auto">Please comment on and improve my description about how to route multicast and broadcast traffic!</p>
<p dir="auto">Sincerely.</p>
<p dir="auto">Louis</p>
<p dir="auto">Notes:<br />
There are also Multicast Routers supporting functions like  Multicast VLAN Registration (MVR). Out of scope here.<br />
To prevent multicast traffic of being send to every address on the network, there is a layer-2 function called snooping. This function should be activated on the switches (if they support that).</p>
]]></description><link>https://forum.netgate.com/topic/144755/help-needed-to-understand-pfsense-multicast-and-broadcast-behavior</link><generator>RSS for Node</generator><lastBuildDate>Sun, 19 Jul 2026 18:20:07 GMT</lastBuildDate><atom:link href="https://forum.netgate.com/topic/144755.rss" rel="self" type="application/rss+xml"/><pubDate>Mon, 08 Jul 2019 13:17:33 GMT</pubDate><ttl>60</ttl><item><title><![CDATA[Reply to Help needed to understand pfSense Multicast and Broadcast behavior. on Fri, 12 Jul 2019 13:48:37 GMT]]></title><description><![CDATA[<p dir="auto">Hello,</p>
<p dir="auto">pfSense its firewall- and routing-behavior in regard to multicast and broadcast is still not clear to me. Especially not as soon as it is "above link-local scope".</p>
<p dir="auto">And .... that is where I have problems. I cannot make my media-server (Twonky) visible across subnets or making a SMB3 share visible in another subnet (note that the share is not visible but accessible).</p>
<p dir="auto">I do have some doubts if it is possible to get those things working with actual software.</p>
<p dir="auto">However, I did a lot of research and would like to share some links with you,</p>
<p dir="auto">I did a lot of research and would like to share some links with you,</p>
<p dir="auto">Zero-configuration networking<br />
https://en.wikipedia.org/wiki/Zero-configuration_networking#DNS-SD</p>
<p dir="auto">Using pimd<br />
https://forum.netgate.com/topic/139218/sonos-speakers-and-applications-on-different-subnets-vlan-s</p>
<p dir="auto">NetBIOS over TCP/IP<br />
https://en.wikipedia.org/wiki/NetBIOS_over_TCP/IP</p>
<p dir="auto">IP-V6 multicast<br />
http://what-when-how.com/ipv6-advanced-protocols-implementation/ipv6-multicast-address-to-layer-2-multicast-address-mapping/</p>
<p dir="auto">IPv6 - Addressing Modes etc.<br />
https://www.tutorialspoint.com/ipv6/ipv6_addressing_modes.htm</p>
<p dir="auto">IPv6 - Special Addresses<br />
https://www.tutorialspoint.com/ipv6/ipv6_special_addresses.htm</p>
<p dir="auto">By the way my media server is using IGMP V3 (the actual standard) and I think IGMP-proxy is not (yet?) supporting that.</p>
<p dir="auto">Sincerely,</p>
<p dir="auto">Louis</p>
]]></description><link>https://forum.netgate.com/post/853021</link><guid isPermaLink="true">https://forum.netgate.com/post/853021</guid><dc:creator><![CDATA[louis2]]></dc:creator><pubDate>Fri, 12 Jul 2019 13:48:37 GMT</pubDate></item></channel></rss>