Help needed to understand pfSense Multicast and Broadcast behavior.
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.
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.
That is why I wrote this message hoping for comments and help. I also hope the description will help others.
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.
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.
SSDP does have following addressing modes:
• 18.104.22.168 (IPv4 site-local address)
• [FF02::C] (IPv6 link-local)
• [FF05::C] (IPv6 site-local)
• [FF08::C] (IPv6 organization-local)
• [FF0E::C] (IPv6 global)
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.
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.
- 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;
- Is using a TTL-value (Time to live, as checked by the firewall) high enough to reach the destination;
- And has a receive scope settings corresponding with the destination scope;
- The local firewall on the media server should allow to pass the messages;
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.
There are two situations to distinguish:
The media server and the media receiver(s) are on the same subnet
o This is the simple situation the firewall should not pass the traffic;
o The traffic is not to be routed.
The media server and one or more receivers are on another subnet (guest-lan, IoT-lan, whats ever)
o Tja ….. the real-scope is not corresponding with the routing scope
o There are solutions for this using “pimd”, “mcproxy”, “IGMP proxy”, however note that
“pimd” is IPV4-only (not supported by pfSense ),
“pim6sd” IPV6 version of pimd (not supported by pfSense ),
“IGMP proxy” is IPV4-only. I am almost sure, and I am not the only one, it is “not at all working (201907)”
o I assume that a FW-rule is needed to pass the “local” traffic towards the “interworking application” (not sure);
o And an (outbound) rule to allow messages to allow traffic coming back from the “interworking application” to enter the involved subnets;
Site-local, organization-local, global:
- There should be a rule to pass the traffic
Situation-1: the media receiver(s) are on the same subnet
o there is no routing ;
Situation-2: Link-local routing is used across subnets, using an “interworking function”,
o there is routing needed towards and from the (internal) “interworking function”;
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);
o I assume the used broadcast / multicast addresses should be bind towards the “interworking function”;
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.
I really do not know what the pfSense behavior. That is one of the reasons for this memo!
My expectation in case of a site-local-address-scope is that:
o the broadcast should be forwarded to all local-subnets;
o assuming a rule the (LAN)-gateway is forwarding the broadcast / multicast message towards the “pfSense core”
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;
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.
My feeling is that:
o In a lot of cases site-local tricks are not necessary / can be solved by using site-local-addressing (in opposite link-local);
o Not being an expert, I also have a feeling that site-local-addressing is not implemented / or working …
- My expectation in case of a global-address-scope is that:
o The broadcast is only send to the specified address;
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.
- The media player firewall (assume there is one) should pass traffic coming from and going to the media server
Be aware that I am not an expert on multicast and that probably not everything written above is correct!
Please comment on and improve my description about how to route multicast and broadcast traffic!
There are also Multicast Routers supporting functions like Multicast VLAN Registration (MVR). Out of scope here.
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).
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".
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).
I do have some doubts if it is possible to get those things working with actual software.
However, I did a lot of research and would like to share some links with you,
I did a lot of research and would like to share some links with you,
NetBIOS over TCP/IP
IPv6 - Addressing Modes etc.
IPv6 - Special Addresses
By the way my media server is using IGMP V3 (the actual standard) and I think IGMP-proxy is not (yet?) supporting that.