New package: pimd
-
@jimp is there any chance for a short guide how to basic setup this for
-
Not from me, I don't have a use case here that I could test. Check the other threads out like the one linked a few replies up. You'll find examples there that worked for others.
-
If I was going to do this, I would do it on my switches.. I have no use for multicast routing currently, nor can I see a need in the future either... To be honest in a home setup just best to put the stuff that needs to talk multicast on the same L2.. In an enterprise it would be done on the switches normally.
Connect your phone or whatever to that L2 when you want to do whatever that requires to talk multicast to other devices. Ie if you want to control your sonos speakers or stream to them - then connect to that network.. That is way better then sending multicast traffic over multiple vlans..
What I currently do on my switches for multicast is block it - because for me all it is noise! have nothing that uses it..
The only use case I can see for this is where you need/want multicast routing and your switches are very lowend smart switches that can barely do vlans. So I am sure there will be plenty of users that can use it - just not something I would have a want or need to spend time doing a guide for.
-
@jimp thanks
-
@msass it's worth noting that @jimp has exposed all of the configuration options available via PIMD but you really don't need the vast majority for a basic home setup (might be an idea to have a simple mode and advanced mode). Literally decide on what interfaces should participate in multicast routing and it should work. I've found it gets complicated when your firewall rules get involved. I've found that whichever rule matches your multicast traffic must have the option to "Allow IP Options" enabled, as many multicast packets have this. PIMD's automatic selection of the RP didn't work for me either, this appears to be because I didn't have a reachable interface IP between the two VLAN's that both segments could reach.
@johnpoz I should admit that my career in InfoSec has made me paranoid but I'm a big believer in L2 separation of IOT devices from other more sensitive systems (i.e. my NAS) and even run Snort between the two VLAN's. I also have an increasing number of systems and IOT devices that rely on multicast for discovery of services. I run numerous IOT closed eco-systems (e.g. Sonos, Smartthings, Heatmiser, Fibaro, HomeKit, Harmony Remote, Apple TV and then a series of Chinese copy products) with a HomeBridge providing a single interface via Apple HomeKit.
PIMD has been a life saver and Pfsense's support for multicast routing makes it stand out from the crowd!
-
I have multiple alexas, I have harmony remote.. I have multiple other iot devices. smart bulbs, smart switches, nest protect, s30 thermostat, garage door is iot for gosh sake.. None of which requires any sort of multicast bleeding from 1 L2 into another...
All of these devices are isolated from the rest of my vlans..
The closest thing that I have run into any sort of issue with discovery is clients being able to do airprint to printer... Simple solution is just to put the wired printer on my trusted wireless vlan.. So now my wifes phone, tablets, laptops that need/want to use airprint can just connect to that wireless network. My pc which is on my main lan, no wireless connectivity too can just print to the printers IP.. Doesn't need discovery, etc.
While I understand that multicast has vast amount of uses.. I think blurring the line between between your vlans you isolated for "security" via routing multicast across them so you can discover something with multicast is defeating the whole purpose of isolation in the first place.
If I want to do something with my roku's for example that requires discovery, I just connect my phone/tablet to do that.. But once the device has been setup once - the phone/table doesn't have to be on that vlan anymore, etc.
Especially if your going to allow the full multicast group of 224/4, if you do need to do it, you should limit it to the specific groups required for X to work.
While I am quite sure this function/feature can be of great use for specific use cases in the pfsense community.. And is great add to the product in general.. What I am concerned with is that users just doing this without understanding the underlaying security implications of just joining your multiple L2 together via multicast..
-
@johnpoz I can't argue with your point on caution of security implications, although I guess there's already some expectation you should have some knowledge of what you're doing when you build a home firewall (understanding how to build effective rulesets isn't a novice task imho).
I've certainly had problems with my Apple handsets and tablets (Airprint was another good example), maybe you're using Android for your mobile kit, I dunno but Sonos is by far the most popular use case as you'll see from the numerous posts. Whilst I'm happy to change networks for a given application, my wife certainly isn't, just switching HDMI inputs usually involves plenty of cursing at high amplitude (for my benefit of course).
I guess my motivation was to ensure it's value isn't dismissed, I for one am on pfsense purely for the ability to support Sonos across VLAN's and I feel multicast use (or to be more precise mDNS) in the consumer electronics segment isn't going away anytime soon (I'd also suggest that L3 enabled switches aren't common place in the home market).
(Naturally I've filtered my multicast groups)
-
No android personal devices in my home (not my choice).. Not sure what some of this iot stuff runs. You get sucked into a eco system.. And then its hard to break out ;) I am on my last ipad that is for sure.. But work phone and wife phone are apple. I was pretty excited that work was going to allow choice of work phone - and then they changed their mind.. And only apple as choice.
Sonos yes is very common.. Security issues with them are nothing new.. Their latest debacle about updates with older stuff is example of how fun this stuff can be ;)
You don't need L3 enabled switches to help fix some of the issues, just vlan support and soho routers that can support them.. You have these $300 plus mesh wifi systems everywhere - and they have zero actual vlan support - WTF!!! sad, you don't have to make it a requirement for the use to do - but it should be able to if you so desire..
If anything - hopefully such exchanges of information will get users to do a bit of research before clicking to allow XYZ..
I can understand the need of multicast in sending audio to multiple speakers at the same time.. Do they have documentation on how to do it correctly, what multicast group to allow.. How to set it up if your actually using vlans. Or do they just assume everyone using their products are one big flat L2?
As to lowering security for user ease of use - this is a wide spread issue to be sure ;) Seems maybe your wife just needs some instruction - hehehe.. Yeah my wife complains the same - this is not printing.. Well your on the wrong network hun.. Just click here.. After 10 or 20 times it seems to have sunk in ;) Why apple will not just allow you to put in the IP of the printer vs that airprint nonsense is beyond me to be honest...
These companies should really step up their game - but problem is proper security cost, and would reduce their profit margins or raise the cost and users want things for cheap as possible, vs actually functional secure setups.. And I get it, when 99.9% of your user base is just on 1 flat network and using of non secure discovery methods makes it easier for the user - then damn straight that is what is going to be on pretty much all soho devices. It really is just a sad state of affairs!
-
@johnpoz you're baiting me now with technology religion and politics, I can't resist ;)
L3 switches, I was referring to your point on having the switches deal with Multicast.
Sonos actually insist, and try to limit that everything is on the same L2 segment but also to their own Sonosnet rather than your existing WIFI (that took me hours to figure out how to migrate onto my actual WIFI). I don't believe Multicast is used for the streaming, in terms of their app, it's purely the initial discovery of the "master" speaker using mDNS then the address of it is cached in the app and it's all unicast.
Now if you want to write a howto on convincing the wife to adopt new technology, I will personally give you a months salary! I love her to bits but mine, when doing the online shopping, just sits there for hours moaning about how crap online shopping is (EXPLETIVE Internet, EXPLETIVE Technology, how stupid the tool is (in that she can't find what she wants). My attempts to suggest getting off her butt then and down the supermarket don't seem to be helping ;)
I think the reality is many of the engineers developing this stuff aren't security aware and they don't seem to pen test their own products, I guess with the drive to reduce manufacturing costs and the pressures from China, or am I just making excuses for them now.
-
@PacketMan said in New package: pimd:
L3 switches, I was referring to your point on having the switches deal with Multicast.
Doesn't have to do L3 to route multicast.. Example the cisco sg200 line is only L2, and it can route multicast ;)
https://www.cisco.com/c/en/us/support/docs/smb/switches/cisco-small-business-200-series-managed-switches/smb1137-multicast-router-port-configuration-on-200-300-series-manage.htmlNow my sg300, can also do it - but it can also do L3 routing..
it's all unicast.
So you have 3 speakers for example about your house - and your sending the same song to all 3... It unicast those on sep streams, vs just multicasting it? That seems moronic!! And sure and the hell would not be efficient..
-
@PacketMan said in New package: pimd:
@Qinn said in New package: pimd:
https://forum.netgate.com/topic/139218/sonos-speakers-and-applications-on-different-subnets-vlan-s/102 just to be sure could you add a screenshot of your setting or if you don't want to share it publicly PM it to me, thanks.
There would be no value in me sharing my PIMD setup, all I have done is enabled it, added the two interfaces (with no other config) and then an RP address (again none of the other fields).
I think there's something in the RP address, someone used the Sonos speaker as the RP address but I suspect the problem is the reachable of the RP address from both subnets. The VLAN my speakers are on can't access the LAN for which the clients are on but I have a third interface/VLAN which is reachable by both and I put the IP address of the pfsense box as the RP address within that globally reachable VLAN.
I've tried this exact configuration and I still am unable to connect to my existing Sonos devices when trying to configure the application from scratch on a workstation installed behind a VLAN. Are you doing anything special in your switches to make this happen, i.e. IGMP snooping?
-
@johnpoz I knew you’d find a switch that does but wouldn’t class Cisco as being consumer grade kit. I don’t know the SG range myself but I’d imagine you don’t have anywhere near the filtering control you do on pfsense. Multicast on switches is great for LAN distribution of streaming media but I’ll be sticking to my Pfsense/PIMD setup for giving the control and filtering of multicast (and especially inter-VLAN).
My unicast point was about the control connection for Sonos and the need for multicast in that. I’ve not taken the time to analyse how the Sonos is distributing its media streams. I wouldn’t assume multicast though, as whilst it’s the standard in this space, Sonos have some sort of proprietary “Sonosnet” which provides a mesh network for the speakers, appears to hub off one of the speakers which has been elected master (I do see a single unicast stream to the master) and apparently some proprietary solution to synchronise audio (sharing the same multicast stream doesn’t guarantee synchronisation).
-
@Deviant0ne I have a suggestion for you, can you add a rule on both interfaces that matches the multicast group you want, with “Allow IP options” and logging enabled. This rule alone may kick it in to life, assuming my theory on “allow IP options”, if not hopefully some logging insight.
-
@PacketMan said in New package: pimd:
but I’d imagine you don’t have anywhere near the filtering control you do on pfsense.
Huh? Not using it as L3 firewall, talking about a multicast router function.. What filtering are you doing on pfsense for your multicast?
As to homekit, they are small business line.. The other makers fully managed switches also support multicast routing and filtering.. They are priced where they could be used in home.. Atleast anyone in home serious about their networking ;)
Again not saying this bad thing, anything that brings features to pfsense is good.. My concern, is misuse of it by users without any real understanding to what they are doing, to try and get something to work - that could have security and performance implications.. When done on the switch I can control exactly which ports are going to play in the multicast, along with filtering multicast groups. When done on the switching infrastructure pfsense doesn't have to even see the multicast traffic for it to be routed, etc.
With the correct switch, I can keep a multicast noise maker from sending that multicast to the rest of the vlan.. Pfsense has no control over that. If I have the correct switch, really have no need for pimd on pfsense, where now users could misuse it, is the point trying to make..
-
This seems to have strayed very far from the original intent of the thread. If you'd like to continue to discuss the merits of multicast routing in general, rather than issues directly related to the functionality of the package, start a new thread in an appropriate (non-packages) category.
For those who have feedback about pimd, start a fresh thread for your individual issues. Please include details about your use case as well as current package settings. Ensure you are on pimd version 0.0.2.
Locking this.
