Sendto to 224.0.0.1 on aaa.bbb.ccc.1: Permission denied

MrPeteH commented 3 years ago

pimd consistently puts this error in syslog.

I've been searching for answers. The best suggestion I've seen:

 #set broadcast permissions for the socket for sendto to work.
 int on=1;
 setsockopt(sock, SOL_SOCKET, SO_BROADCAST, &on, sizeof(on));

troglobit commented 3 years ago

Hi Pete!

That shouldn't be necessary. Could you tell me a bit more about your setup? Like, what operating system and hardware are you running on, what version of pimd are you running, how do the interface flags on your interfaces look, and do you perhaps have a firewall enabled? This could also be caused by SELinux, AppArmor, or similar.

troglobit commented 3 years ago

Final ping before closing due to inactivity. I'd really like to know more about your setup, because I've never run into your problem with any of the multicast routing daemons I maintain (SMCRoute, pimd-dense, pimd, pim6sd, mrouted).

troglobit commented 3 years ago

Closing, no reply from reporter.

MrPeteH commented 3 years ago

Sorry, Real Life got crazy... I will try to come back regularly.

My setup:

pfSense 2.4.5 based on FreeBSD 11.3-STABLE
With pimd packaged up from pimd 2.3.2
It's running on a generic PC box (multicore i5) with generally nice performance (I typically get full bandwidth on my fiber-to-the-doorstep gigabit up/download. Quite a difference from being on DSL at the end of a 20,000 ft wire - barely 0.5mbit/sec :) but that's a rabbit trail!)
I have quite a few subnets. Internal, VPN, IoT, Guest... wired and WiFi. Wifi is Ubiquiti, as transparent as possible - all DHCP etc from pfSense.
Physically, for performance I am set up as follows:
- pfSense has one Ethernet directly to fiber WAN box (pfSense providing PPPoE)
- pfSense has a second Ethernet trunking (VLAN) to a Netgear 8 port smart switch that breaks out the VLANs to separate ethernet ports. All Wifi VLANs show up on ports dedicated to each of my Ubiquiti WiFi AP's, and then I have a few other switches on the other ports (24 port for most ethernet, a PoE switch for various IoT devices, and a dedicated switch for in-house servers. This is actually my home -- I am Mr Gray Haired Tech Guy who registered domain #42 after all ;) ;) )

Yes, there's a firewall. I have logging turned up quite far and am not seeing ANY firewall blockages related to pimd (the only internal block being triggered is a LAN monitoring app I'm testing that currently is poking at port 0 on the router, which doesn't like that ;) )

Interface flags (good question! I have no idea what sets these ;) ) All with Multicast enabled look like this: re0.11: flags=8a43<UP,BROADCAST,RUNNING,ALLMULTI,SIMPLEX,MULTICAST> My NAS/server subnet (generally not multicast-enabled): re0.77: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> And my OpenVPN (I was trying to get multicast working... with difficulty ;) ): ovpns1: flags=8251<UP,POINTOPOINT,RUNNING,ALLMULTI,MULTICAST>

Below is a typical minute from my system.log: Dec 27 05:53:00 jasmine pimd[8193]: For src 169.254.0.1, iif is 10, next hop router is 184.99.0.13: NOT A PIM ROUTER Dec 27 05:53:14 jasmine pimd[8193]: Sendto to 224.0.0.1 on 192.168.11.1: Permission denied Dec 27 05:53:14 jasmine pimd[8193]: Sendto to 224.0.0.1 on 192.168.1.1: Permission denied Dec 27 05:53:14 jasmine pimd[8193]: Sendto to 224.0.0.1 on 10.8.0.1: Permission denied Dec 27 05:53:19 jasmine pimd[8193]: For src 169.254.0.1, iif is 10, next hop router is 184.99.0.13: NOT A PIM ROUTER Dec 27 05:53:29 jasmine pimd[8193]: Sendto to 224.0.0.1 on 192.168.11.1: Permission denied Dec 27 05:53:29 jasmine pimd[8193]: Sendto to 224.0.0.1 on 192.168.1.1: Permission denied Dec 27 05:53:29 jasmine pimd[8193]: Sendto to 224.0.0.1 on 10.8.0.1: Permission denied Dec 27 05:53:40 jasmine pimd[8193]: For src 169.254.0.1, iif is 10, next hop router is 184.99.0.13: NOT A PIM ROUTER Dec 27 05:53:44 jasmine pimd[8193]: Sendto to 224.0.0.1 on 192.168.11.1: Permission denied Dec 27 05:53:44 jasmine pimd[8193]: Sendto to 224.0.0.1 on 192.168.1.1: Permission denied Dec 27 05:53:44 jasmine pimd[8193]: Sendto to 224.0.0.1 on 10.8.0.1: Permission denied Dec 27 05:53:59 jasmine pimd[8193]: Sendto to 224.0.0.1 on 192.168.11.1: Permission denied Dec 27 05:53:59 jasmine pimd[8193]: Sendto to 224.0.0.1 on 192.168.1.1: Permission denied Dec 27 05:53:59 jasmine pimd[8193]: Sendto to 224.0.0.1 on 10.8.0.1: Permission denied

Anything else that might be helpful?

THANK YOU for all you do! Pete

MrPeteH commented 3 years ago

oh... pimd.conf (with command line disable-vifs)

spt-threshold packets 0 interval 100 phyint re0.71 enable phyint re0.9 enable phyint re0.12 enable phyint re0.15 enable phyint re0.11 enable phyint re0.79 enable phyint ovpns1 enable bsr-candidate priority 5 rp-candidate priority 20 time 30 group-prefix 224.0.0.0/4

troglobit commented 3 years ago

I have very little experience with FreeBSD, have only set it up in very plain routing scenarios to do interop testing of pimd et al against other operating systems. FreeBSD has actually been the best of the *BSDs to work with, never really had any problems.

Your issue really sounds like exactly the same problem that you run into on a Linux box with a very strict firewall. Searching duckduckgo yields this:

https://www.freebsd.org/doc/en/books/faq/networking.html#idp49801592

which points to the manual here:

https://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/firewalls-ipfw.html

If everything really is denied by default, you need to open it up for IGMP and PIM protocols on the interfaces you want to run pimd on. Try enabling firewall logging to see if you get any hits. I found this forum thread that may be relevant:

https://forums.freebsd.org/threads/ipfw-igmp-query-v3.72547/

Dunno if it helps but it's probably worth trying.

MrPeteH commented 3 years ago

As I noted, I do have logging on for all (?) related items, including the fall-through blocking. I'll check those links and see what I can find. THANKS!

troglobit commented 3 years ago

Any progress on this?

MrPeteH commented 3 years ago

Thanks for asking.

I did some captures but haven't yet captured the actual issue... and then I had to take a break for the Real World (my wife will soon have back surgery).

I think I can track it down this coming week.

(IF it is a firewall issue, it is not simple ;) )

Joachim Wiberg said (on 1 Jan 2021)...

Any progress on this?

troglobit commented 3 years ago

OK, good luck hunting it down! (And with the surgery!)

Marc05 commented 3 years ago

I'm running into the same issue, and have firewall rules allowing all IGMP and PIM traffic. Though I'm not sure that I have the config correct:

phyint ixv2 enable dr-priority 1 ttl-threshold 1 distance 101 metric 1024
phyint ixv0 enable dr-priority 10 ttl-threshold 1 distance 101 metric 1024
bsr-candidate ixv0
rp-candidate ixv0
    group-prefix 224.0.0.0/4
# ixv0 interface address
rp-address 10.0.10.1

Is the rp-address line needed in this case? Not that removing it made a difference.

The process is started like so: /usr/local/sbin/pimd -c /var/etc/pimd/pimd.conf --disable-vifs -s debug

Which shows in logs (reverse order):


Mar 12 17:57:50 | pimd | 1592 | Sendto to 224.0.0.1 on 10.0.5.1: Permission denied
-- | -- | -- | --
Mar 12 17:57:50 | pimd | 1592 | Sendto to 224.0.0.1 on 10.0.10.1: Permission denied
Mar 12 17:57:41 | pimd | 1592 | New RP candidate 10.0.10.1 for group 224.0.0.0/4, priority 0
Mar 12 17:57:41 | pimd | 1592 | For src 169.254.0.1, iif is 6, next hop router is 177.231.47.1: NOT A PIM ROUTER
Mar 12 17:57:35 | pimd | 1592 | For src 169.254.0.1, iif is 6, next hop router is 177.231.47.1: NOT A PIM ROUTER
Mar 12 17:57:35 | pimd | 1592 | Sendto to 224.0.0.1 on 10.0.5.1: Permission denied
Mar 12 17:57:35 | pimd | 1592 | Sendto to 224.0.0.1 on 10.0.10.1: Permission denied
Mar 12 17:57:19 | pimd | 1429 | Interface register_vif0 comes up; vif #8 now in service
Mar 12 17:57:19 | pimd | 1429 | Interface ovpns1 is DISABLED; vif #7 out of service
Mar 12 17:57:19 | pimd | 1429 | Interface igb0 is DISABLED; vif #6 out of service
Mar 12 17:57:19 | pimd | 1429 | Interface ixv5 is DISABLED; vif #5 out of service
Mar 12 17:57:19 | pimd | 1429 | Interface ixv4 is DISABLED; vif #4 out of service
Mar 12 17:57:19 | pimd | 1429 | Interface ixv3 is DISABLED; vif #3 out of service
Mar 12 17:57:19 | pimd | 1429 | Sendto to 224.0.0.1 on 10.0.5.1: Permission denied
Mar 12 17:57:19 | pimd | 1429 | Interface ixv2 comes up; vif #2 now in service
Mar 12 17:57:19 | pimd | 1429 | Interface ixv1 is DISABLED; vif #1 out of service
Mar 12 17:57:19 | pimd | 1429 | Sendto to 224.0.0.1 on 10.0.10.1: Permission denied
Mar 12 17:57:19 | pimd | 1429 | Interface ixv0 comes up; vif #0 now in service
Mar 12 17:57:19 | pimd | 1429 | Local static RP: 169.254.0.1, group 232.0.0.0/8
Mar 12 17:57:19 | pimd | 1429 | Adding Cand-RP group prefix 224.0.0.0/4
Mar 12 17:57:19 | pimd | 1429 | Local Cand-RP address 10.0.10.1, priority 0, interval 60 sec
Mar 12 17:57:19 | pimd | 1429 | Local Cand-BSR address 10.0.10.1, priority 0
Mar 12 17:57:19 | pimd | 1429 | Getting vifs from /var/etc/pimd/pimd.conf
Mar 12 17:57:19 | pimd | 1429 | Disabling all vifs from kernel
Mar 12 17:57:19 | pimd | 1429 | Installing ovpns1 (172.20.0.1 -> 172.20.0.2) as vif #7 - rate=0
Mar 12 17:57:19 | pimd | 1429 | Installing igb0 (177.231.47.6 on subnet 177.231.47/24) as vif #6 - rate 0
Mar 12 17:57:19 | pimd | 1429 | Installing ixv5 (10.0.20.1 on subnet 10.0.20/24) as vif #5 - rate 0
Mar 12 17:57:19 | pimd | 1429 | Installing ixv4 (10.0.1.1 on subnet 10.0.1/24) as vif #4 - rate 0
Mar 12 17:57:19 | pimd | 1429 | Installing ixv3 (10.0.50.1 on subnet 10.0.50/24) as vif #3 - rate 0
Mar 12 17:57:19 | pimd | 1429 | Installing ixv2 (10.0.5.1 on subnet 10.0.5/24) as vif #2 - rate 0
Mar 12 17:57:19 | pimd | 1429 | Installing ixv1 (10.0.100.1 on subnet 10.0.100/24) as vif #1 - rate 0
Mar 12 17:57:19 | pimd | 1429 | Installing ixv0 (10.0.10.1 on subnet 10.0.10/24) as vif #0 - rate 0
Mar 12 17:57:19 | pimd | 1429 | Getting vifs from kernel
Mar 12 17:57:19 | pimd | 1429 | pimd version 2.3.2 starting ...

Rules are floating rules as such:

pass log  quick  on {  ixv2  ixv0  } inet from any to 224.0.0.0/4 tracker 1615217947  allow-opts keep state  label "USER_RULE: TEST float igmp"
pass log  quick  on {  ixv2  ixv0  } inet proto igmp  from any to any tracker 1615591889  allow-opts keep state  label "USER_RULE: TEST float igmp3"
pass log  quick  on {  ixv2  ixv0  } inet proto pim  from any to any tracker 1615591929  allow-opts keep state  label "USER_RULE: TEST float pim"

stromnet commented 2 years ago

Hi,

ran into the same issue. And after some debugging, it turned out to be PF that is blocking it, even with an empty ruleset. The devil is in the pf.conf details:

 allow-opts
       By default, IPv4 packets with IP options or IPv6 packets with routing
       extension headers are blocked.  When allow-opts is specified for a
       pass rule, packets that pass the filter based on that rule (last
       matching) do so even if they contain IP options or routing extension
       headers.  For packets that match state, the rule that initially
       created the state is used.  The implicit pass rule that is used when
       a packet does not match any rules does not allow IP options.

So, the following rule does not work

pass in on $int inet proto igmp

But modifying it to this...

pass in on $int inet proto igmp allow-opts

..and :tada: we now have working pimd! Note that this affects regular IGMP as well, a regular listener will not be able to send it's join-group messages if PF is enabled but the above is missing.

Big kudos to Kristof Provost of FreeBSD team for digging this up oddity very quickly after my (as it turned out, semi-invalid) bug report: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=259879

Edit: now I see that post above this one actually mentions allow-opts in the rules. And now looking at https://troglobit.com/howtos/pimd-on-freebsd/ I did not see this mentioned, buuut following the link to https://troglobit.com/howtos/pimd-on-openbsd/ I see that it is mentioned, but with another error message.

troglobit commented 2 years ago

Yeah, firewall issues are very common. Originally these fine protocols were not intended to be run with firewalls and such, so error messages are not always very useful. But EPERM is a really good indicator that the kernel has some policy in place. On Linux you can get it with SELinux, Apparmor, and similar hardening mechs. as well.

I should really update my howtos ... :roll_eyes:

MrPeteH commented 2 years ago

I am back on this, after a lot of Real World challenges.

At a surface level, I do have allow-opts set "everywhere"... but we shall see.

What I REALLY want to find at this point is tools for diagnosing issues like this. "Permission denied" is not exactly helpful.

Hopefully back soon...

troglobit / pimd

Sendto to 224.0.0.1 on aaa.bbb.ccc.1: Permission denied #171