How does pfSense handle multicast (and broadcast) traffic!!??
-
I put a lot of effort in trying to get SMB and a media server visible in a second subnet. And despite all the effort and searching internet, I did not manage.
Both problems are related to broadcast and multicast traffic. And one thing is for sure it is absolutely not clear to me how pfSense is dealing with multicast. So let me describe the situation and related my questions a bit further below.
Let start to mention that you can have broadcasts with a couple of different scopes:- Scope is local subnet. =>The FW should block (not pass) that
- Scope is side local => the FW should pass (if there is a rule)
- Scope is organization-local => the FW should pass (if there is a rule)
- Scope is global => the FW should pass (if there is a rule)
But if the firewall should pass the broadcast / multicast than there have to be a destination as well !
Extra factor is that multicast destinations are a bit strange, in the sense that it is more a signal / data / store than an IP-address with a mac and “an processor” behind it.
As said there should be a destination, and that destination can be on a local subnet or it can be on another router (organization global) or on the internet (if the “provider” is elsewhere).
Assuming the FW is, in relation to address allocation, not behaving different than which unicast traffic, a GW will forward a multicast/broadcast traffic to wards the next higher level if it is not the owner of the given range.
So …… if using multicast/broadcast it should (IMHO) be possible to assign a certain multicast/broadcast range to a certain interface/gateway. No idea how
Then there is the issue of how to define the related FW-rules. A normal unicast rule has a source a destination a port and voila. However there are also vague “Advanced attributes” like “Allow IP options”. Not clear to me what it is doing and when it is exactly needed
All described above should of course work in case of IPV4 and in case IPV6.
I also noted that if you have “Block bogon networks” activated on a certain interface, that bogon rule is blocking part of the broadcasts. I did create a bug-report for that. But Netgate did react, you should not use that rule (on local interface). That may be partly true, but IMHO it is definitely a bug anyway.A little bit apart from this but related, not to be discussed here should be separate subject, are IMGP-proxi and Avahi.
Here for info some info related to SSDP
from the WIKI, to make you think
Protocol transport and addressing[edit]
SSDP is a text-based protocol based on HTTPU. It uses UDP as the underlying transport protocol. Services are announced by the hosting system with multicast addressing to a specifically designated IP multicast address at UDP port number 1900. In IPv4, the multicast address is 239.255.255.250[4] and SSDP over IPv6 uses the address set ff0X::c for all scope ranges indicated by X.[5]
This results in the following well-known practical multicast addresses for SSDP:
• 239.255.255.250 (IPv4 site-local address)
• [FF02::C] (IPv6 link-local)
• [FF05::C] (IPv6 site-local)
• [FF08::C] (IPv6 organization-local)
• [FF0E::C] (IPv6 global)Hope that will lead to better understanding of how pfSense is handling multicast/unicast and how we users can have multicast applications working. I did not manage
Sincerely,
-
@louis2 said in How does pfSense handle multicast (and broadcast) traffic!!??:
But if the firewall should pass the broadcast / multicast than there have to be a destination as well !
I'm having difficulty understanding what you're saying here. However, on IPv4, broadcasts are normally not passed by a router and don't even exist on IPv6. Multicasts take place in a block of addresses, many assigned to common uses. A router has to be configured either automatically or manually to pass them. Typically, if a device wants to receive multicasts from beyond the local network, it has to advise the router, which then in turn joins the multicast, this part is recursive, depending on how many routers are in between the requesting device and source.
-
Hello,
A short reaction
But if the firewall should pass the broadcast / multicast than there have to be a destination as well !
I'm having difficulty understanding what you're saying here.What I intended to say is, that when an IP-address occurs within the router / FW core, in case of unicast, the address range (IPV4 / IPV6) assigned to an particular interface determines where it is yes/no delivered.
The interface assigned address range determines the routing.
I assume there is something comparable in regard to multicast/broadcast ranges. However .. it must be a bit different. Because it should / could be distributed over multiple interfaces.
As example take a side-local multicast occurrence/message. I think what happens is something like this:
A (side-local) broadcast message occurs in a subnet and the interface-subnet-rules/ the GW allows the message to pass. The message arrives at the core of pfSense.
The message should IMHO be distributed towards the gateways / subnets / routes which are “interested/listening/ subscribed” to that particular range.
However I do not have any idea how I should “subscribe” interfaces to a particular type of broadcast event.
Louis
-
My understanding is that, beyond the usual ICMP stuff, an application has to initiate the request. That's detected by by the nearest router (and sometimes switch) that in turn forwards the request on to the next hop. Eventually, this will set up a path for the multicasts to the ultimate destination. However, multicast is not my strong point, so you should read up on how it works.
-
Yep, multicast is a domain on itself also for me … and a complex one ..
What came into my mind after writing my previous reaction, is that it could be (just an idea !!!) ……… that pfSense is spreading the broadcasts across every interface.
If so a floating rule is required to stop unwanted traffic … but that is just guessing ……. Other point is that if that guess would be true the messages would also go out into direction internet ….. and I can hardly image that.
A few words for those interested on multicast.
The main difference between broadcast and multicast is, that broadcasts are spread to every computer in one (ore more) subnets and a multicast message/stream in theory only to the computers witch send a message ‘that they want to have the messages from that source / source address’.
I did write ‘in theory’ because the level-2 switch should be capable to send the multicast messages only to the related (physical) ports / ip’s. Cheap switched do not have that capability, and treat multicast as broadcast.
The function that prevent sending the multicast messages towards “uninterested” computers is called IGMP snooping (IPV4).
For IPV6 it is more complex. There is a function called MLD Snooping Proxy, which is more or less doing the same and more (I do not completely understand what).
Than there is a multicast router function called MVR (Multicast VLAN registration) which is there to forward multicast traffic. For more details, see internet wiki etc.
I do not know for sure but my feeling is that the pfSense IMGP-proxi is more or less emulating a MVR. However I am surprised about the IMGP-proxi gui fields. I would have expect other fields there …. Perhaps for later investigation
Louis
-
@louis2 said in How does pfSense handle multicast (and broadcast) traffic!!??:
What came into my mind after writing my previous reaction, is that it could be (just an idea !!!) ……… that pfSense is spreading the broadcasts across every interface.
If so a floating rule is required to stop unwanted traffic … but that is just guessing ……. Other point is that if that guess would be true the messages would also go out into direction internet ….. and I can hardly image that.As I mentioned, broadcasts are normally not passed by routers, so no need for a rule. Multicast can go out to the Internet. How else could someone subscribe to it? However, that sort of multicast must be requested by some app and the routers/switches along the way pass on the request and the traffic.
The main difference between broadcast and multicast is, that broadcasts are spread to every computer in one (ore more) subnets and a multicast message/stream in theory only to the computers witch send a message ‘that they want to have the messages from that source / source address’.
Again, there are no broadcasts in IPv6, only all hosts multicasts. Routers will pass the requests and traffic as required.
I did write ‘in theory’ because the level-2 switch should be capable to send the multicast messages only to the related (physical) ports / ip’s. Cheap switched do not have that capability, and treat multicast as broadcast.
The function that prevent sending the multicast messages towards “uninterested” computers is called IGMP snooping (IPV4).
For IPV6 it is more complex. There is a function called MLD Snooping Proxy, which is more or less doing the same and more (I do not completely understand what).
Again, the switches learn of multicasts by "snooping". A switch that's not capable of that would pass the multicast traffic to all ports.
-
Hum,
Routers (I assume you also refer to FW's) should not pass multicast you write. But I can hardly believe that since there are multiple scopes defined, and appart form link local, all other types need to pass routers and firewalls IMHO.
This results in the following well-known practical multicast addresses for SSDP:
• 239.255.255.250 (IPv4 site-local address)
• [FF02::C] (IPv6 link-local)
• [FF05::C] (IPv6 site-local)
• [FF08::C] (IPv6 organization-local)
• [FF0E::C] (IPv6 global)Louis
-
@louis2 said in How does pfSense handle multicast (and broadcast) traffic!!??:
Routers (I assume you also refer to FW's) should not pass multicast you write.
I didn't write that. Look at the different types of multicast. For example, there are things like router advertisements and neighbour solicitations that are link local scope only. There is absolutely no reason for those to be passed through a router. In fact, the hop limit field is used to ensure a router has not passed them. The hop limit on those is set to 255, which means that if a router passed a packet, then it had to have a limit of 0 before the router, but a router will discard any packet with a limit of 0.
On the other hand, there may be some media, such as a "radio station" that people want to listen to. Those would likely be somewhere else and not on the local network, though they could be. In this instance, the multicasts are not transmitted, unless requested. If the server is on the local network, then it would start transmitting, when it receives the request. If beyond the local network, then the router will have to accept the request and forward it on to the source, which could be many hops away. Then when the multicast is received by the router, it then has to be passed on to the local network. Of course the scope can be used to limit how far the multicasts can travel.
BTW, firewalls are a separate function, though often performed by routers. In multicasts, it is the router that has to accept and forward the requests and also pass the traffic. If a firewall is so configured, then the multicasts or requests can be blocked, even if otherwise might be passed by a router.
