I sent this a couple of days ago, and don''t see it in the archive, so I''m assuming it didn''t go through. If it did (or does) please excuse the duplicate message. I''ve improved this a bit since then, based on some new discoveries and I''ve included a "shorewall dump" in hopes that one of you generous folks might find it useful. ---------- Forwarded message ---------- Date: Jan 17, 2008 4:31 PM Subject: Allow multicast in Shorewall 3.4.4 To: shorewall-users@lists.sourceforge.net Hello. I''m trying to allow multicast between zone $FW and zone loc. I have verified that loc <--> loc is working, and I have verified that with shorewall stopped, the machine that is $FW works with multicast, so everything should be good with the kernel and modules needed for multicast. I''m using shorewall 3.4.4 on Ubuntu Gutsy x64, (the shell version not the perl version). FWIW, I''m trying to run PulseAudio on the $FW machine and have it use RTP audio sinks. Note that I do NOT need to route between interfaces; I just want the internet subnet 10.0.0.0/24 to have RTP support, and have verified that it works when shorewall is stopped when the $FW machine is part of 10.0.0.0/24with no firewalling. Looking through the archives, I see some very old (2002, 2005) instructions for enabling multicast. I tried these instructions to no avail. I''ve tried this in policy: loc $FW ACCEPT:allowBcast $FW loc ACCEPT:allowBcast and this in rules: ACCEPT:allowBcast $FW $FW: 224.0.0.0/4 ACCEPT:allowBcast $FW loc:224.0.0.0/4 ACCEPT:allowBcast loc $FW: 224.0.0.0/4 and this in rules: allowBcast $FW $FW allowBcast $FW loc allowBcast loc $FW and this in rules: ACCEPT $FW loc:224.0.0.0/4 ACCEPT loc $FW: 224.0.0.0/4 But no luck. Interestingly, I had to explicitly block 224.0.0.0/4 from going out my net zone, or my connection got saturated and became useless. Still, I''m not seeing anything in my logs about loc <--> $FW being dropped or rejected. I''d appreciate a tip; I''m sure it''s something obvious that I''m overlooking. Thanks; Shorewall has served me and my company very well with more conventional configurations for more than 5 years! It''s excellent software! -- Matt ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
Matt Feifarek wrote:> I sent this a couple of days ago, and don''t see it in the archive, so > I''m assuming it didn''t go through. If it did (or does) please excuse the > duplicate message. > > I''ve improved this a bit since then, based on some new discoveries and > I''ve included a "shorewall dump" in hopes that one of you generous folks > might find it useful.There was no dump attached to your post. -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
Argh; I''m sorry; forgot the attachment. On Jan 19, 2008 8:00 PM, Matt Feifarek <matt.feifarek@gmail.com> wrote:> I sent this a couple of days ago, and don''t see it in the archive, so I''m > assuming it didn''t go through. If it did (or does) please excuse the > duplicate message. > > I''ve improved this a bit since then, based on some new discoveries and > I''ve included a "shorewall dump" in hopes that one of you generous folks > might find it useful. > > > ---------- Forwarded message ---------- > Date: Jan 17, 2008 4:31 PM > Subject: Allow multicast in Shorewall 3.4.4 > To: shorewall-users@lists.sourceforge.net > > Hello. > > I''m trying to allow multicast between zone $FW and zone loc. I have > verified that loc <--> loc is working, and I have verified that with > shorewall stopped, the machine that is $FW works with multicast, so > everything should be good with the kernel and modules needed for multicast. > > I''m using shorewall 3.4.4 on Ubuntu Gutsy x64, (the shell version not the > perl version). FWIW, I''m trying to run PulseAudio on the $FW machine and > have it use RTP audio sinks. > > Note that I do NOT need to route between interfaces; I just want the > internet subnet 10.0.0.0/24 to have RTP support, and have verified that it > works when shorewall is stopped when the $FW machine is part of > 10.0.0.0/24 with no firewalling. > > Looking through the archives, I see some very old (2002, 2005) > instructions for enabling multicast. I tried these instructions to no avail. > > I''ve tried this in policy: > loc $FW ACCEPT:allowBcast > $FW loc ACCEPT:allowBcast > > and this in rules: > ACCEPT:allowBcast $FW $FW: 224.0.0.0/4 > ACCEPT:allowBcast $FW loc:224.0.0.0/4 > ACCEPT:allowBcast loc $FW: 224.0.0.0/4 > > and this in rules: > allowBcast $FW $FW > allowBcast $FW loc > allowBcast loc $FW > > and this in rules: > ACCEPT $FW loc: 224.0.0.0/4 > ACCEPT loc $FW: 224.0.0.0/4 > > But no luck. > > Interestingly, I had to explicitly block 224.0.0.0/4 from going out my net > zone, or my connection got saturated and became useless. Still, I''m not > seeing anything in my logs about loc <--> $FW being dropped or rejected. > > I''d appreciate a tip; I''m sure it''s something obvious that I''m > overlooking. > > Thanks; Shorewall has served me and my company very well with more > conventional configurations for more than 5 years! It''s excellent software! > > -- Matt > >------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
Matt Feifarek wrote:> Argh; I''m sorry; forgot the attachment. > >I don''t see anything wrong. Multicast packets are leaving your firewall and you have a loc->fw ACCEPT policy so IGMP packets can reach the server. For the dump to be useful, the period of time covered by the dump must include failures. Apparently there were none in the 27 seconds covered by this dump. -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
On Jan 19, 2008 8:25 PM, Tom Eastep <teastep@shorewall.net> wrote:> I don''t see anything wrong. Multicast packets are leaving your firewall > and you have a loc->fw ACCEPT policy so IGMP packets can reach the server. > > For the dump to be useful, the period of time covered by the dump must > include failures. Apparently there were none in the > 27 seconds covered by this dump.Thanks for the prompt reply! Yes, I was hoping to have a small slice of time, to help isolate the problem. Maybe this is a clue: if I do: $ ping 224.0.0.1 I get: ping: sendmsg: Operation not permitted If I turn off shorwall, I don''t get that message... I don''t get anything back from ping, but that''s probably another question, obviously unrelated to shorewall. I get the same thing when running the pulseaudio server... # pulseaudio --system -C E: sap.c: sendmsg() failed: Operation not permitted This last message repeats indefinitely, about once per second. The "sap.c" gives me the clue that multicast is implicated. I did both of these things (ping and pulseaudio) in those 27 seconds. I didn''t see them in the DROP/REJECT tables either. Does shorewall flip any kernel switches that might turn off broadcast or multicast in a way that doesn''t show up in the iptables? In other words, if my packets aren''t getting caught in netfilter, what else might happen in "shorewall start" that causes the change in results? P.S. Just to be sure, I tried looking in sap.c to see what address(es) it uses, and found 224.0.0.56. Also, I looked at the RFC for SAP[1] and found this: "IPv4 global scope sessions use multicast addresses in the range 224.2.128.0 - 224.2.255.255 with SAP announcements being sent to 224.2.127.254 (note that 224.2.127.255 is used by the obsolete SAPv0 and MUST NOT be used)." But later in the same doc there is mention of using 239.x.y.z... which I also allowed in rules, but no difference. Thanks! [1] : http://tools.ietf.org/html/rfc2974 ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
Matt Feifarek wrote:> On Jan 19, 2008 8:25 PM, Tom Eastep <teastep@shorewall.net> wrote:> > Yes, I was hoping to have a small slice of time, to help isolate the problem. > > Maybe this is a clue: if I do: > $ ping 224.0.0.1 > I get: > ping: sendmsg: Operation not permitted > > If I turn off shorwall, I don''t get that message... I don''t get > anything back from ping, but that''s probably another question, > obviously unrelated to shorewall. > > I get the same thing when running the pulseaudio server... > # pulseaudio --system -C > E: sap.c: sendmsg() failed: Operation not permitted > > This last message repeats indefinitely, about once per second. The > "sap.c" gives me the clue that multicast is implicated. > > I did both of these things (ping and pulseaudio) in those 27 seconds. > I didn''t see them in the DROP/REJECT tables either. > > Does shorewall flip any kernel switches that might turn off broadcast > or multicast in a way that doesn''t show up in the iptables? In other > words, if my packets aren''t getting caught in netfilter, what else > might happen in "shorewall start" that causes the change in results? > > P.S. Just to be sure, I tried looking in sap.c to see what address(es) > it uses, and found 224.0.0.56. Also, I looked at the RFC for SAP[1] > and found this: > > "IPv4 global scope sessions use multicast addresses in the range > 224.2.128.0 - 224.2.255.255 with SAP announcements being sent to > 224.2.127.254 (note that 224.2.127.255 is used by the obsolete SAPv0 > and MUST NOT be used)." > > But later in the same doc there is mention of using 239.x.y.z... which > I also allowed in rules, but no difference.I need a dump showing the failure. Nothing else will be useful. -tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
On Jan 19, 2008 9:11 PM, Tom Eastep <teastep@shorewall.net> wrote:> I need a dump showing the failure. Nothing else will be useful.I appreciate that, but how can I do that? It''s failing, but it''s not showing a failure. Before I run "shorewall start" this service works, after I run it, it does not. Seems to me that the problem might be other than the netfilter tables, since it''s not showing up in there. I really do appreciate your help, and am really trying to be useful as you generously help. I suppose that I will get the service running, then switch on the shorewall and see what happens... though, that may be "ESTABLISHED". ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
Matt Feifarek wrote:> On Jan 19, 2008 9:11 PM, Tom Eastep <teastep@shorewall.net> wrote: > >> I need a dump showing the failure. Nothing else will be useful. > > I appreciate that, but how can I do that? It''s failing, but it''s not > showing a failure. Before I run "shorewall start" this service works, > after I run it, it does not. Seems to me that the problem might be > other than the netfilter tables, since it''s not showing up in there. > > I really do appreciate your help, and am really trying to be useful as > you generously help. > > I suppose that I will get the service running, then switch on the > shorewall and see what happens... though, that may be "ESTABLISHED".a) start shorewall b) do whatever you do that doesn''t work c) take the dump d) send the dump -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
Matt Feifarek wrote:> On Jan 19, 2008 8:25 PM, Tom Eastep <teastep@shorewall.net> wrote: > >> I don''t see anything wrong. Multicast packets are leaving your firewall >> and you have a loc->fw ACCEPT policy so IGMP packets can reach the server. >> >> For the dump to be useful, the period of time covered by the dump must >> include failures. Apparently there were none in the >> 27 seconds covered by this dump. > > Thanks for the prompt reply! > > Yes, I was hoping to have a small slice of time, to help isolate the problem. > > Maybe this is a clue: if I do: > $ ping 224.0.0.1 > I get: > ping: sendmsg: Operation not permitted > > If I turn off shorwall, I don''t get that message... I don''t get > anything back from ping, but that''s probably another question, > obviously unrelated to shorewall. > > I get the same thing when running the pulseaudio server... > # pulseaudio --system -C > E: sap.c: sendmsg() failed: Operation not permitted > > This last message repeats indefinitely, about once per second. The > "sap.c" gives me the clue that multicast is implicated. > > I did both of these things (ping and pulseaudio) in those 27 seconds. > I didn''t see them in the DROP/REJECT tables either. > > Does shorewall flip any kernel switches that might turn off broadcast > or multicast in a way that doesn''t show up in the iptables? In other > words, if my packets aren''t getting caught in netfilter, what else > might happen in "shorewall start" that causes the change in results? > > P.S. Just to be sure, I tried looking in sap.c to see what address(es) > it uses, and found 224.0.0.56. Also, I looked at the RFC for SAP[1] > and found this: > > "IPv4 global scope sessions use multicast addresses in the range > 224.2.128.0 - 224.2.255.255 with SAP announcements being sent to > 224.2.127.254 (note that 224.2.127.255 is used by the obsolete SAPv0 > and MUST NOT be used)." > > But later in the same doc there is mention of using 239.x.y.z... which > I also allowed in rules, but no difference. > > Thanks! >One think I think I can help you with. You report that ping 224.0.0.1 doesn''t work with Shorewall started. That''s because you don''t have a route for 224.0.0.0/4 out of your local interface. So with Shorewall started, I suspect that the default route is used and the pings are being rejected out of your ''net'' interface. Every HOWTO I''ve read about multicast talks about adding a route to 224.0.0.0/4 out of the interfaces that need multicast. Just a guess. I''ve never had a need for multicast[1] so I haven''t experimented with it (and there is no article on the Shorewall site about it). -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
On Jan 19, 2008 9:31 PM, Tom Eastep <teastep@shorewall.net> wrote:> One think I think I can help you with. You report that ping 224.0.0.1 > doesn''t work with Shorewall started. That''s because you don''t have a > route for 224.0.0.0/4 out of your local interface. So with Shorewall > started, I suspect that the default route is used and the pings are > being rejected out of your ''net'' interface.Hot damn, you got it. For future searchers out there... All linux multicast related docs on the net are at least 5 years old... some 9. I did add routes, but still can''t ping the multicast responder address. But this appears to be a red herring, as it''s now working. Here''s the fix: On the box that is $FW: route add -net 224.0.0.0 netmask 240.0.0.0 dev eth0 Thanks, Tom! ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/