I''m just looking for a quick sanity check to make sure what I''m finding is really all necessary here. I''m upgrading a gateway/firewall from Linux 2.4 to 2.6 using Mandrake 10.1. In the old 2.4 kernel I structured my firewall rules around the ipsec0 interface, which I understand isn''t present with Openswan running under 2.6 (no KLIPS). Ok, So as I start to tackle the new problem, here is what I''m finding, at least with Mandrake 10.1... Shorewall 2.2.0+ has nice features to simplify new ipsec rules. Mandrake is several versions behind, so I upgrade with Jack Coates rpms, very helpful; so far so good. Except it requires the Patch-O-Matic-NG Policy Match patches in the kernel (I''m using 2.6.11.8), which isn''t there. To get the patches, it looks like I need to recompile and reload netfilter, and the kernel with the patches I download from the Patch-O-Matic ftp site. The latest stable version I found is from 20040621. So if I follow all this to conclusion, I''m supposed to put a 10 month old patch for netfilter into a brand-new kernel, combine it with a brand-new netfilter/iptables and replace the rpm install from Mandrake. All to get a simple ipsec rule to work in Shorewall? Wow... I thought the netfilter patching days were long gone. Short of all this, how effective of a firewall rule can I set up without using the new Policy Match features? Is there an alternative? Can I just accept 10.20.0.0/24 (my private subnet) packets in my public interface for rules? If I''m way off in left field somewhere, someone please redirect me back to the sane world before I risk destroying my newly installed firewall if something in this process goes foobar. Many thanks, Brian
Brian Foddy wrote:> it looks like I need to recompile and reload netfilter, and > the kernel with the patches I download from the Patch-O-Matic > ftp site. The latest stable version I found is from 20040621.With a 2.6.11 Kernel, you will probably want a current CVS snapshot rather than that ancient release.> > So if I follow all this to conclusion, I''m supposed to put a 10 > month old patch for netfilter into a brand-new kernel, combine it with > a brand-new netfilter/iptables and replace the rpm install > from Mandrake. All to get a simple ipsec rule to work in > Shorewall? Wow... I thought the netfilter patching days were > long gone.Don''t complain to me -- complain to the Netfilter team who for various reasons haven''t been able to release their IPSEC patches to the kernel.org tree. OR Install SuSE. Their kernel''s already have all necessary patches installed.> > Short of all this, how effective of a firewall rule can I set up > without using the new Policy Match features? Is there an > alternative? Can I just accept 10.20.0.0/24 (my private subnet) > packets in my public interface for rules?Please read http://shorewall.net/IPSEC.htm. It talks about how you can still use simple net<->net setups without the new stuff in the kernel -- just don''t expect NAT to work. -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
Tom Eastep wrote:> Brian Foddy wrote: > >>it looks like I need to recompile and reload netfilter, and >>the kernel with the patches I download from the Patch-O-Matic >>ftp site. The latest stable version I found is from 20040621. > > With a 2.6.11 Kernel, you will probably want a current CVS snapshot > rather than that ancient release. > >>So if I follow all this to conclusion, I''m supposed to put a 10 >>month old patch for netfilter into a brand-new kernel, combine it with >>a brand-new netfilter/iptables and replace the rpm install >>from Mandrake.You also apparently missed this news article linked from near the top of the Netfilter home page: "No more patch-o-matic-ng releases The netfilter project ceased to issue ''official'' patch-o-matic-ng releases. Please use the most current daily snapshot available from ftp.netfilter.org" -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
On Mon, 2 May 2005, Tom Eastep wrote:> Brian Foddy wrote: > >> it looks like I need to recompile and reload netfilter, and >> the kernel with the patches I download from the Patch-O-Matic >> ftp site. The latest stable version I found is from 20040621. > > With a 2.6.11 Kernel, you will probably want a current CVS snapshot > rather than that ancient release. > >> >> So if I follow all this to conclusion, I''m supposed to put a 10 >> month old patch for netfilter into a brand-new kernel, combine it with >> a brand-new netfilter/iptables and replace the rpm install >> from Mandrake. All to get a simple ipsec rule to work in >> Shorewall? Wow... I thought the netfilter patching days were >> long gone. > > Don''t complain to me -- complain to the Netfilter team who for various > reasons haven''t been able to release their IPSEC patches to the > kernel.org tree. >I''m not complaining as much as just a little miffed that we are still at this point over a year after 2.6 and 2-3 distro releases. I know its not necessarily a Shorewall issue, but its where the limitations become apparent.> OR > > Install SuSE. Their kernel''s already have all necessary patches installed.I supposed I could, all my other machines run Mandrake and its nice to standarize where possible...>> Short of all this, how effective of a firewall rule can I set up >> without using the new Policy Match features? Is there an >> alternative? Can I just accept 10.20.0.0/24 (my private subnet) >> packets in my public interface for rules? > > Please read http://shorewall.net/IPSEC.htm. It talks about how you can > still use simple net<->net setups without the new stuff in the kernel -- > just don''t expect NAT to work. > > -Tom >Ok, thanks, I may try the simplier approach first. Also, in reference to your second post, not needing to patch iptables helps remove one of the steps. Thanks again. Brian
Hi. I have a question about multicast and Shorewall. I have a multi cast audio video stream originating on my internal network which I want to make available on one of my DMZ networks so the clients there have access to the stream. Is there a way in Shorewall to configure it to forward the multicast traffic to the DMZ? Or would I need some sort of proxy (therefore a non-Shorewall solution) to listen to the multicast stream on the internal network and relay/rebroadcast it into the DMZ? Apologies in advance for my vague question, I am still trying to wrap my head around how multicast traffic will effect my Shorewall implementation. Thank you. Si.
Bob Smith wrote:> > Hi. > > I have a question about multicast and Shorewall. I have a multi cast > audio video stream originating on my internal network which I want to > make available on one of my DMZ networks so the clients there have > access to the stream. Is there a way in Shorewall to configure it to > forward the multicast traffic to the DMZ? Or would I need some sort of > proxy (therefore a non-Shorewall solution) to listen to the multicast > stream on the internal network and relay/rebroadcast it into the DMZ? > > Apologies in advance for my vague question, I am still trying to wrap my > head around how multicast traffic will effect my Shorewall implementation.The general requirements for Multicast routing are: a) The appropriate routes need to be created. b) Multicast Routing must be enabled in the kernel. c) You must run a multicast routing daemon that keeps track of which hosts are members of which multicast groups (such as zebra) d) In Shorewall you must enable multicast traffic: - to the firewall (IGMP) from any stream consumer zones - from the firewall (IGMP) - from the source to the destination(s) (whatever streaming you are doing). For the first two, I would: ACCEPT fw all 2 ACCEPT all fw 2 There is a multicast routing chapter (8) in the LARTC Howto -- it''s a bit out of date but you should read it none the less. And the above exhausts my knowledge of multicast routing so I''ll not be able to advise you further unless you have very specific problems with traffic being dropped/rejected once you try to get this working. -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
Brian Foddy wrote:>> > > I''m not complaining as much as just a little miffed that we are still > at this point over a year after 2.6 and 2-3 distro releases. > I know its not necessarily a Shorewall issue, but its where the > limitations become apparent. >I''m miffed as well. I gave a presentation about Native IPSEC and Shorewall this weekend at LinuxFest NW (see http://shorewall.net/LinuxFest.pdf). When I chose that topic a couple of months ago, I thought certain that these issues would be resolved in 2.6.11. As you can see, they are not resolved and I had to admit as much (see slides 31 and 32). Furthermore, it doesn''t look like they are going to be resolved in 2.6.12 either :-( -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
On Mon, 2 May 2005, Tom Eastep wrote:> Brian Foddy wrote: > >>> >> >> I''m not complaining as much as just a little miffed that we are still >> at this point over a year after 2.6 and 2-3 distro releases. >> I know its not necessarily a Shorewall issue, but its where the >> limitations become apparent. >> > > I''m miffed as well. I gave a presentation about Native IPSEC and > Shorewall this weekend at LinuxFest NW (see > http://shorewall.net/LinuxFest.pdf). When I chose that topic a couple of > months ago, I thought certain that these issues would be resolved in > 2.6.11. As you can see, they are not resolved and I had to admit as much > (see slides 31 and 32). Furthermore, it doesn''t look like they are going > to be resolved in 2.6.12 either :-( > > -Tom >Tom, the info in your presentation is excellent. I''ll study it more carefully tonight. Thanks, Brian
Hi Tom, Thanks your response. I figured it would be a combination of Shorewall configuration and another daemon to make this work. I really appreciate your insight, as it steers me in the right direction to get this set up. Si.>The general requirements for Multicast routing are: > >a) The appropriate routes need to be created. >b) Multicast Routing must be enabled in the kernel. >c) You must run a multicast routing daemon that keeps track of which >hosts are members of which multicast groups (such as zebra) >d) In Shorewall you must enable multicast traffic: > - to the firewall (IGMP) from any stream consumer zones > - from the firewall (IGMP) > - from the source to the destination(s) (whatever streaming > you are doing). > > For the first two, I would: > > ACCEPT fw all 2 > ACCEPT all fw 2 > >There is a multicast routing chapter (8) in the LARTC Howto -- it''s a >bit out of date but you should read it none the less. > >And the above exhausts my knowledge of multicast routing so I''ll not be >able to advise you further unless you have very specific problems with >traffic being dropped/rejected once you try to get this working.
You also need to allow the multicast traffic in Shorewall. See Tom''s post here http://lists.shorewall.net/pipermail/shorewall-users/2005-January/016793.html ACCEPT net fw:224.0.0.0/4 ACCEPT net loc:224.0.0.0/4 ACCEPT fw loc:224.0.0.0/4 Just a note: The current open source multicast routing daemons only work when you have _routable addresses_ on the downstream interfaces. If you use NAT, it will not work. To use multicast with NAT, you need a (multicast) IGMP proxy. An IETF draft: http://www1.ietf.org/internet-drafts/draft-wing-behave-multicast-00.txt (I have not found an updated document) It is possible to use smcroute http://www.cschill.de/smcroute/ to setup static membership and routing. I have started to modify pimd to be able to use it as an multicast proxy. However, my ISP has a problem routing multicast to me, so I do not know what is not working. If anyone is interested in testing, please let me know. Discussions like this should probably be kept out of the Shorewall list. There is a limit for Tom''s extraordinary support and patience. Any suggestions?. -- Gerhard To reply, remove the first nospam but not the second.