New package: pimd
-
Seems to be working between interfaces on both my lab routers. I intend to connect two routers together and see if I can get traffic from one LAN to the other through a third LAN. But so far so good.
-
@chpalmer I'm complete new to this, is it possible to share some basic setup tip?
I'm trying to have my Media Vlan working (Sonos, TV and Google chrome cast) but no luck so far
-
Still working on it myself..
Seems when I updated snapshots I had to go back into the config page and hit "save" to get the package to "work" again.
Even though its running Ive had no success as of yet with a multicast test program.. But I am trying to traverse two routers each connected to the other with a /30 subnet.
I need to test more when I have time.
-
@jimp firstly thank you! awesome that you've made PIMD available as a package, really appreciated!
I currently have a working Sonos implementation running over split VLAN's, using PIMD (manually installed as a package at OS level) and working perfectly.
This PIMD package installed perfectly on 2.4.4-RELEASE-p3 for me, however for some reason it's not working like the OS installed version of PIMD does. I'll do some debugging today and figure out why.
UPDATE
Manually configuring an RP address seems to have resolved my issue, now fully operation with Sonos discovering speakers on separate VLAN.
-
@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.
-
@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..