I''m trying to get multicast traffic passing through my firewall. I''ve found a few really old items on mailing lists but nothing has worked yet. Right now I am just trying to get mDNS working. Is there a guide anywhere that lists step-by-step instructions for how to get at least mDNS passing through Shorewall? Thank you, -Matt ------------------------------------------------------------------------------ This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon''s best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev
Matt Stocum wrote:> I''m trying to get multicast traffic passing through my firewall. I''ve > found a few really old items on mailing lists but nothing has worked > yet. Right now I am just trying to get mDNS working. Is there a guide > anywhere that lists step-by-step instructions for how to get at least > mDNS passing through Shorewall?No. -Tom -- Tom Eastep \ When I die, I want to go like my Grandfather who Shoreline, \ died peacefully in his sleep. Not screaming like Washington, USA \ all of the passengers in his car http://shorewall.net \________________________________________________ ------------------------------------------------------------------------------ This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon''s best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev
On Dec 22, 2009, at 10:09 AM, Tom Eastep wrote:> No.Okay, how about a rough guide of things I need to make sure I''m doing in order to have a chance at making this work? Is there at least a way to tell Shorewall to log multicast traffic that it''s blocking? I think I recall reading somewhere that it doesn''t in order to keep the logs from exploding with what would normally be useless information. -Matt ------------------------------------------------------------------------------ This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon''s best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev
I''m starting to think I''ve been approaching this in entirely the wrong way. Right now I''m using proxyarp, but looking at the documentation here, http://www.shorewall.net/bridge-Shorewall-perl.html, I think I may be able to get things working with bridging instead. Does it seem like this approach might allow multicast traffic to pass through properly? Thanks, -Matt ------------------------------------------------------------------------------ This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon''s best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev
Matt Stocum wrote:> I''m starting to think I''ve been approaching this in entirely the > wrong way. Right now I''m using proxyarp, but looking at the > documentation here, > http://www.shorewall.net/bridge-Shorewall-perl.html, I think I may be > able to get things working with bridging instead. Does it seem like > this approach might allow multicast traffic to pass through properly? >Hard to say without knowing the particulars. -Tom -- Tom Eastep \ When I die, I want to go like my Grandfather who Shoreline, \ died peacefully in his sleep. Not screaming like Washington, USA \ all of the passengers in his car http://shorewall.net \________________________________________________ ------------------------------------------------------------------------------ This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon''s best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev
On Dec 22, 2009, at 6:15 PM, Tom Eastep wrote:> Hard to say without knowing the particulars.The bridge approach so far is working, and has the ?nice? side effect of hiding the firewall from traceroute. The one issue I did find is that the firewall is logging a lot of dropped packets that aren''t destined for any of the hosts behind the firewall. For some reason traffic to a few hosts on the network is apparently being broadcast, instead of directed to one specific port on a switch. My solution was to add the following line to the end of /usr/share/shorewall/action.Drop DROP - !$ALLHOSTS Where $ALLHOSTS is defined in params to be a list of all of my hosts. Is there a better, more automatic way, that I can tell Shorewall to ignore any traffic not destined for a host on the protected side of the firewall? Thanks, -Matt ------------------------------------------------------------------------------ This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon''s best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev
Matt Stocum wrote:> The bridge approach so far is working, and has the ?nice? side effect > of hiding the firewall from traceroute. The one issue I did find is > that the firewall is logging a lot of dropped packets that aren''t > destined for any of the hosts behind the firewall. For some reason > traffic to a few hosts on the network is apparently being broadcast, > instead of directed to one specific port on a switch. My solution was > to add the following line to the end of > /usr/share/shorewall/action.Drop > > DROP - !$ALLHOSTS > > Where $ALLHOSTS is defined in params to be a list of all of my hosts. > Is there a better, more automatic way, that I can tell Shorewall to > ignore any traffic not destined for a host on the protected side of > the firewall?It is never a good idea to modify any file in /usr/share/shorewall. Next time you upgrade, your change will get wiped out. The recommended method is to copy the file you want to change to /etc/shorewall and then to modify the copy. A more straight-forward way to approach this would be to add the appropriate simple DROP rules to your rules file. -Tom -- Tom Eastep \ When I die, I want to go like my Grandfather who Shoreline, \ died peacefully in his sleep. Not screaming like Washington, USA \ all of the passengers in his car http://shorewall.net \________________________________________________ ------------------------------------------------------------------------------ This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon''s best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev
Tom Eastep wrote:> Matt Stocum wrote: > >> The bridge approach so far is working, and has the ?nice? side effect >> of hiding the firewall from traceroute. The one issue I did find is >> that the firewall is logging a lot of dropped packets that aren''t >> destined for any of the hosts behind the firewall. For some reason >> traffic to a few hosts on the network is apparently being broadcast, >> instead of directed to one specific port on a switch. My solution was >> to add the following line to the end of >> /usr/share/shorewall/action.Drop >> >> DROP - !$ALLHOSTS >> >> Where $ALLHOSTS is defined in params to be a list of all of my hosts. >> Is there a better, more automatic way, that I can tell Shorewall to >> ignore any traffic not destined for a host on the protected side of >> the firewall? > > It is never a good idea to modify any file in /usr/share/shorewall. Next > time you upgrade, your change will get wiped out. The recommended method > is to copy the file you want to change to /etc/shorewall and then to > modify the copy. > > A more straight-forward way to approach this would be to add the > appropriate simple DROP rules to your rules file. >It would also be a good idea to identify the source of this traffic and to understand why it is being passed to your router/firewall. It''s presence may signal a network and/or switch configuration issue. -Tom -- Tom Eastep \ When I die, I want to go like my Grandfather who Shoreline, \ died peacefully in his sleep. Not screaming like Washington, USA \ all of the passengers in his car http://shorewall.net \________________________________________________ ------------------------------------------------------------------------------ This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon''s best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev
On Dec 23, 2009, at 9:57 AM, Tom Eastep wrote:> It is never a good idea to modify any file in /usr/share/shorewall. Next > time you upgrade, your change will get wiped out. The recommended method > is to copy the file you want to change to /etc/shorewall and then to > modify the copy.So if I copy /usr/share/shorewall/action.Drop to /etc/shorewall, the copy in /etc/shorewall will override the version in /usr/share/shorewall? -Matt ------------------------------------------------------------------------------ This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon''s best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev
Matt Stocum wrote:> On Dec 23, 2009, at 9:57 AM, Tom Eastep wrote: > >> It is never a good idea to modify any file in /usr/share/shorewall. >> Next time you upgrade, your change will get wiped out. The >> recommended method is to copy the file you want to change to >> /etc/shorewall and then to modify the copy. > > So if I copy /usr/share/shorewall/action.Drop to /etc/shorewall, the > copy in /etc/shorewall will override the version in > /usr/share/shorewall?Assuming that you haven''t altered the setting of CONFIG_PATH in unnatural ways.... -Tom -- Tom Eastep \ When I die, I want to go like my Grandfather who Shoreline, \ died peacefully in his sleep. Not screaming like Washington, USA \ all of the passengers in his car http://shorewall.net \________________________________________________ ------------------------------------------------------------------------------ This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon''s best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev