New package: pimd
-
@msass there's a couple of elements to this in my experience, one is getting multicast working across VLAN's but you'll probably need some rules tuning as well (depending on how locked down your connectivity is between VLAN's).
In terms of configuring PIMD, I'd suggest starting with a fully open configuration and then starting to lock it down. If you've installed PIMD then then change "Default Bind" to "Bind to All" and enable it. If that then gets everything working you'll need to start locking it down, as I wouldnt recommend having it running on, for example, your external interface.
-
@PacketMan Could you show us in more detail what you did to make it work for the Sonos devices or PM me
-
@Qinn said in New package: pimd:
@PacketMan Could you show us in more detail what you did to make it work for the Sonos devices or PM me
I'd be happy to help but probably easier if you tell me how far you've got and I help debug your setup. Most of my setup I did 18 months ago so it's not all fresh, do you have PIMD installed and are you seeing any multicast routes appear?
UPDATE I've just found your other posts so I know you're further on, have you added a RP address? I didn't need to add the multicast group and the address has to be one reachable from all VLAN's.
-
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.
-
@jimp just testing out the package on 2.4.4-p3. When stopping/restarting I see a few of these:
/status_services.php: The command '/usr/local/etc/rc.d/pimd.sh stop' returned exit code '1', the output was ''every time the service is stopped. Perhaps a little error/oversight in the package?
-
@JeGr said in New package: pimd:
When stopping/restarting I see a few of these:
Might be something we can avoid, not sure what might be causing that off the top of my head, though. It tries to shut down pimd nicely and then attempts to kill anything left over, but I didn't think either of those steps would cause the whole script to exit with an error like that.
Remember: Upvote with the 👍 button for any user/post you find to be helpful, informative, or deserving of recognition!
Need help fast? Netgate Global Support!
Do not Chat/PM for help!
-
@jimp Also seem to have the problem that the package doesn't save its configuration in all dialogues right. Added/removed RP adresses by trial and error and even after removing all entries, the package restarted with "load static rp x.y.z.a". Only saving in the general settings after all removal and restarting seemed to solve that. There definitely seem to be config issues with adding/removing things.
-
2.5 after a reboot-
PIMD is enabled but not running. Check the configuration.
I have to go hit save on the main PIMD screen to get this-
Virtual Interface Table ======================================================
Vif Local Address Subnet Thresh Flags Neighbors
0 24.xx.xxx.xxx 24.xx.48/20 1 DISABLED
1 192.168.1.1 192.168.1 16 DR NO-NBR
2 10.50.1.1 10.50.1/30 16 PIM 10.50.1.2
3 192.168.1.1 register_vif0 1Vif SSM Group Sources
Multicast Routing Table ======================================================
--------------------------------- (,,G) ------------------------------------
Number of Groups: 0
Number of Cache MIRRORs: 0 -
@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.
-
Just pushed out pimd version 0.0.2:
- Fixed bonus tabs in status output
- Fixed input validation of RP Candidate entries to allow empty group prefix
- Fixed sync on delete for entries on tabs
- Fixed error in stop script
- Fixed shortcuts on config tabs other than 'General'
It should be available now (or in a few moments, anyhow) for 2.4.4-p3, and with the next snapshot run for others.
-
@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..
