Hi folks, When we first started talking about Shorewall post-Tom, a few people offered to help with testing. Would those people please raise their hands again? :-) I''m investigating Nicolas Helleringer''s recent message on shorewall-users (http://lists.shorewall.net/pipermail/shorewall-users/2005-June/018898.html), and a good test environment would come in really handy, especially if it were a virtual host that we could trash and recreate. I probably need to get around to trying out Xen for this myself, but until then does anyone have a canned test host they''d be willing to let me use for a while? P.S. SourceForge still haven''t got around to moving our list, so we''ll have to keep going here for a while... Thanks in advance, Paul <http://paulgear.webhop.net> -- Did you know? Using accepted quoting conventions makes your email easier to understand. Learn how at <http://www.netmeister.org/news/learn2quote.html>. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 256 bytes Desc: OpenPGP digital signature Url : http://lists.shorewall.net/pipermail/shorewall-devel/attachments/20050624/b9f4b0c4/signature.bin
Hi Paul, what do you need wxactly? Il set up a testbed for you according to your needs. Guess this weekend is possible. Paul Gear wrote:>Hi folks, > >When we first started talking about Shorewall post-Tom, a few people >offered to help with testing. Would those people please raise their >hands again? :-) > >I''m investigating Nicolas Helleringer''s recent message on >shorewall-users >(http://lists.shorewall.net/pipermail/shorewall-users/2005-June/018898.html), >and a good test environment would come in really handy, especially if it >were a virtual host that we could trash and recreate. > >I probably need to get around to trying out Xen for this myself, but >until then does anyone have a canned test host they''d be willing to let >me use for a while? > >P.S. SourceForge still haven''t got around to moving our list, so we''ll >have to keep going here for a while... > >Thanks in advance, >Paul ><http://paulgear.webhop.net> >-- >Did you know? Using accepted quoting conventions makes >your email easier to understand. Learn how at ><http://www.netmeister.org/news/learn2quote.html>. > > >------------------------------------------------------------------------ > >_______________________________________________ >Shorewall-devel mailing list >Shorewall-devel@lists.shorewall.net >https://lists.shorewall.net/mailman/listinfo/shorewall-devel > >
Alexander Wilms wrote:> Hi Paul, what do you need wxactly? Il set up a testbed for you according > to your needs. Guess this weekend is possible.I need something that has at least 4 network interfaces (2 internal, 1 net, 1 DMZ) and a couple of clients, one one each of two internal zones, that i can test this potential DNAT bug with. -- Paul <http://paulgear.webhop.net> -- Did you know? Many viruses specifically target Microsoft Outlook and Outlook Express. You can help to keep your computer free of viruses by using one of the more secure alternatives from <http://mozilla.org>. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 256 bytes Desc: OpenPGP digital signature Url : http://lists.shorewall.net/pipermail/shorewall-devel/attachments/20050624/3ce98d0c/signature.bin
Yep, I think that''s possible. I can do tat this afternoon (German time). Is it suitable for you? BTW, do you have any IM? If yes, mail me off-list. Alex Paul Gear wrote:>Alexander Wilms wrote: > > >>Hi Paul, what do you need wxactly? Il set up a testbed for you according >>to your needs. Guess this weekend is possible. >> >> > >I need something that has at least 4 network interfaces (2 internal, 1 >net, 1 DMZ) and a couple of clients, one one each of two internal zones, >that i can test this potential DNAT bug with. > > > >------------------------------------------------------------------------ > >_______________________________________________ >Shorewall-devel mailing list >Shorewall-devel@lists.shorewall.net >https://lists.shorewall.net/mailman/listinfo/shorewall-devel > >
> Hi Paul, what do you need wxactly? Il set up a testbed for you according > to your needs. Guess this weekend is possible. > > Paul Gear wrote: > > >Hi folks, > > > >When we first started talking about Shorewall post-Tom, a few people > >offered to help with testing. Would those people please raise their > >hands again? :-) > > > >I''m investigating Nicolas Helleringer''s recent message on > >shorewall-users > >(http://lists.shorewall.net/pipermail/shorewall-users/2005-June/018898.html),> >and a good test environment would come in really handy, especially if it > >were a virtual host that we could trash and recreate. > > > >I probably need to get around to trying out Xen for this myself, but > >until then does anyone have a canned test host they''d be willing to let > >me use for a while? > > > >P.S. SourceForge still haven''t got around to moving our list, so we''ll > >have to keep going here for a while... > > > >Thanks in advance, > >Paul > ><http://paulgear.webhop.net> > >-- > >Did you know? Using accepted quoting conventions makes > >your email easier to understand. Learn how at > ><http://www.netmeister.org/news/learn2quote.html>.Paul: I was looking for the cause of that also, separate_list(), in the fuction file, gets called on the creation of the chains. This function, I believe, excludes the original variable that gets past to it. Jerry
Jerry Vonau wrote:>> >>Paul Gear wrote:>>>I''m investigating Nicolas Helleringer''s recent message on >>>shorewall-users >>(http://lists.shorewall.net/pipermail/shorewall-users/2005-June/018898.htm > l),> I was looking for the cause of that also, separate_list(), in the fuction > file, > gets called on the creation of the chains. This function, I believe, > excludes > the original variable that gets past to it.Folks Even back in 1.4.6, I had no intention that "all" should generate intra-zone rules. In both 1.4.6c and in the current code, there is a specific test for the intra zone case:>From 1.4.6c:for yclients in $xclients; do for yservers in $xservers; do if [ "${yclients}" != "${yservers}" ] ; then --------------------------------------- <yada yada yada> fi done done>From 2.4.0:for yclients in $xclients; do for yservers in $xservers; do ysourcezone=${yclients%%:*} ydestzone=${yservers%%:*} if [ "${ysourcezone}" != "${ydestzone}" ] ; then ------------------------------------------- eval ypolicy=\$${ysourcezone}2${ydestzone}_policy <yada yada yada> fi done done The difference here is that the 2.4.0 isolates the zone name from both the source and destination before the comparison whereas the 1.4.6c code doesn''t. So with a rule like DNAT all lan:10.0.0.1 tcp http - 192.0.0.1 the zone name being generated by expanding "all" was (incorrectly) being compared against "lan:10.0.0.1" by the 1.4.6c code; the current code (correctly) compares against just "lan". In short, Nicolas took advantage of a bug that was subsequently fixed. The only way to restore the 1.4.6c behavior would be to either: a) Create new syntax like ("all!") or some such thing. b) Add a new option to shorewall.conf that restores the old (erroneous) behavior. The second is easier. -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 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature Url : http://lists.shorewall.net/pipermail/shorewall-devel/attachments/20050624/e0b2eff2/signature.bin
Paul Gear wrote:> > P.S. SourceForge still haven''t got around to moving our list, so we''ll > have to keep going here for a while... >Do we need to rethink our strategy for migrating the lists? We certainly aren''t going to be able to silence the User''s list for several weeks while SF procrastinates. -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 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature Url : http://lists.shorewall.net/pipermail/shorewall-devel/attachments/20050624/7641ddf5/signature.bin
Tom Eastep wrote:> ... >>P.S. SourceForge still haven''t got around to moving our list, so we''ll >>have to keep going here for a while... >> > > > Do we need to rethink our strategy for migrating the lists? We certainly > aren''t going to be able to silence the User''s list for several weeks > while SF procrastinates.Indeed, but i can''t think how, without moving all the lists again to another place, which seems a little, well, gratuitous... -- Paul <http://paulgear.webhop.net> -- Did you know? If you use two dashes followed by a space as your signature separator, good email programs will chop them off automatically, reducing noise in email replies. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 256 bytes Desc: OpenPGP digital signature Url : http://lists.shorewall.net/pipermail/shorewall-devel/attachments/20050624/2cd41e3f/signature.bin
Tom Eastep wrote:> ... > Even back in 1.4.6, I had no intention that "all" should generate > intra-zone rules. In both 1.4.6c and in the current code, there is a > specific test for the intra zone case: > ... > The difference here is that the 2.4.0 isolates the zone name from both > the source and destination before the comparison whereas the 1.4.6c code > doesn''t. So with a rule like > > DNAT all lan:10.0.0.1 tcp http - 192.0.0.1 > > the zone name being generated by expanding "all" was (incorrectly) being > compared against "lan:10.0.0.1" by the 1.4.6c code; the current code > (correctly) compares against just "lan".Oh, well. So much for our test environment fun this weekend... ;-)> In short, Nicolas took advantage of a bug that was subsequently fixed. > The only way to restore the 1.4.6c behavior would be to either: > > a) Create new syntax like ("all!") or some such thing. > b) Add a new option to shorewall.conf that restores the old (erroneous) > behavior. > > The second is easier.What about a 3rd? The principle of least surprise would mean that "all" should do what Nicolas thinks it should do. If process_wildcard_rule() is only called when all is either the source or destination, couldn''t we just leave out the test for source & destination zones being different? -- Paul <http://paulgear.webhop.net> -- Did you know? Email addresses can be forged easily. This message is signed with GNU Privacy Guard <http://www.gnupg.org> and Enigmail <http://enigmail.mozdev.org> so you can be sure it comes from me. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 256 bytes Desc: OpenPGP digital signature Url : http://lists.shorewall.net/pipermail/shorewall-devel/attachments/20050624/a301509c/signature.bin
Paul Gear wrote:> Tom Eastep wrote: >>... >>Even back in 1.4.6, I had no intention that "all" should generate >>intra-zone rules. In both 1.4.6c and in the current code, there is a >>specific test for the intra zone case: >>... >>The difference here is that the 2.4.0 isolates the zone name from both >>the source and destination before the comparison whereas the 1.4.6c code >>doesn''t. So with a rule like >> >> DNAT all lan:10.0.0.1 tcp http - 192.0.0.1 >> >>the zone name being generated by expanding "all" was (incorrectly) being >>compared against "lan:10.0.0.1" by the 1.4.6c code; the current code >>(correctly) compares against just "lan". > > Oh, well. So much for our test environment fun this weekend... ;-) > >>In short, Nicolas took advantage of a bug that was subsequently fixed. >>The only way to restore the 1.4.6c behavior would be to either: >> >>a) Create new syntax like ("all!") or some such thing. >>b) Add a new option to shorewall.conf that restores the old (erroneous) >>behavior. >> >>The second is easier. > > What about a 3rd? The principle of least surprise would mean that "all" > should do what Nicolas thinks it should do. If process_wildcard_rule() > is only called when all is either the source or destination, couldn''t we > just leave out the test for source & destination zones being different?If you like generating superfluous chains, sure. By default, intra-zone traffic is ACCEPTed without any extra jumps or chains. And if you want to dig through the documentation and fix up all of the places where it says that "all" DOESN''T generate intra-zone rules. For example, from the rules file itself: # # When "all" is used either in the SOURCE or DEST column # intra-zone traffic is not affected. You must add # separate rules to handle that traffic. # Only people who don''t read the documentation should be surprised by how this works. -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 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature Url : http://lists.shorewall.net/pipermail/shorewall-devel/attachments/20050624/66a18e02/signature.bin
Skipped content of type multipart/mixed-------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 256 bytes Desc: OpenPGP digital signature Url : http://lists.shorewall.net/pipermail/shorewall-devel/attachments/20050625/5d5362cf/signature-0001.bin
Paul Gear wrote:>> >>If you like generating superfluous chains, sure. > > Except they''re only created when you use an ''all'' rule, right?Right.> I just > tested that two-line change (commenting out the test for src & dest > zones) on one of my boxes, and it resulted in no difference in rules > (presumably because i don''t have any ''all'' rules).That''s correct.> >>By default, intra-zone traffic is ACCEPTed without any extra jumps or >>chains. > > If i remember correctly, did that change around 1.2 or 1.3, or am i just > getting confused? (It''s nearly 1 am here in +1000 - i should be in bed...)I noticed that you were up late :-) I don''t recall off-hand when that happened; http://shorewall.net/News.htm tells all.> >>And if you want to dig through the documentation and fix up >>all of the places where it says that "all" DOESN''T generate >>intra-zone rules. > > No problem, if we decide to go that way.Given that I had to drive back to Seattle to get the mailing lists working again, I had 4 1/2 hours this morning to think about this while I drove back to our vacation home. The documentation load will be about the same no matter which option is chosen.> :-) > > I guess from that perspective, it''s working as designed, but speaking > from the perspective of someone who didn''t write the code or > documentation, it never would have occurred to me to go back and read > the rules file when my ''all'' DNAT rule broke (as was the case with Nicolas).True. But I don''t think it is necessary to change Shorewall and impact many configurations just because one user took advantage of a bug and complained when the bug got fixed.> > I''ve sent Nicolas the attached patch (with a warning about the > documented behaviour) and asked for a copy of his iptables output before > and after - we''ll see how he goes with that. > > If anyone else cares to test this for me, i''d be interested to see how > many configurations this change would actually affect. ><patch snipped> With your proposed change, people who want to use a single "all" rule but don''t want Shorewall to generate absurd rules for each of their zones must now add a "Z Z NONE" policy for each of their zones (including $FW). Again, I think this is overreacting to appease someone whose configuration depended on a bug that produced results that were and still are contrary to the documentation. Just my $,02US -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:> Paul Gear wrote:>>If i remember correctly, did that change around 1.2 or 1.3, or am i just >>getting confused? (It''s nearly 1 am here in +1000 - i should be in bed...) > > I noticed that you were up late :-) I don''t recall off-hand when that > happened; http://shorewall.net/News.htm tells all. >It appears that I didn''t document the behavior of "all" vis a vis intra-zone traffic in the rules file until 2.0.3. The "all" feature was implemented in 1.3.11; here is the item from the release notes: "It is now allowed to use ''all'' in the SOURCE or DEST column in a rule. When used, ''all'' must appear by itself (it may not be qualified) and it does not enable intra-zone traffic. For example, the rule ACCEPT loc all tcp 80 does not enable http traffic from ''loc'' to ''loc''." The feature whereby intra-zone traffic is accepted by default was introduced in 1.4.1. -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 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature Url : http://lists.shorewall.net/pipermail/shorewall-devel/attachments/20050624/1dfd1183/signature.bin
On Fri, 2005-06-24 at 06:22, Paul Gear wrote:> Tom Eastep wrote: > > ... > >>P.S. SourceForge still haven''t got around to moving our list, so we''ll > >>have to keep going here for a while... > >> > > Do we need to rethink our strategy for migrating the lists? We certainly > > aren''t going to be able to silence the User''s list for several weeks > > while SF procrastinates.Tom, The import went well, and had no errors. It was done at the same time the announce list was. The generation of the SF interface to the mailman archive didn''t update properly. That issue was escalated to one of the SF sysadmins. The SF web archive doesn''t preclude the list from functioning properly, and can be regenerated AFAIK.> Indeed, but i can''t think how, without moving all the lists again to > another place, which seems a little, well, gratuitous...-- Mike Noyes <mhnoyes at users.sourceforge.net> http://sourceforge.net/users/mhnoyes/ SF.net Projects: leaf, phpwebsite, phpwebsite-comm, sitedocs