-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello, =09I am using MNF (Multi Network Firewall from Mandrake), and it is based on=20 Shorewall ver 1.3.7c at the moment. I am using the web interface to set up=20 the basic stuff, and based on source and destination zones and subnets, the=20 traffic of interest is routed through a special chain with a default policy=20 of CONTINUE. ie... /etc/shorewall/policy auth=09lan=09ACCEPT auth=09fw=09REJECT info auth=09wan=09CONTINUE lan=09auth=09ACCEPT wan=09auth=09CONTINUE wan=09fw=09DROP info all=09all=09REJECT info The special zone is auth, and it is a sub-zone of lan. It will be used to=20 open traffic to special clients with no restriction by adding a ACCEPT rule=20 that will match there Source IP & Mac for outgoing traffic, and Destination=20 IP for incoming traffic. This list of clients will be dynamic, and stored in=20 a PostgreSQL database.=20 In the docs it says that I can use a script with the names "auth2wan" and=20 "wan2auth" to add the rules into the two chains. =20 My question to Tom is, if I have the database system dump the rules into files=20 named auth2wan.rules and wan2auth.rules, in the same formate as the rules=20 file, can I use the same code that reads the rules file to read these? Or=20 would it just be easyer to use the run_iptables command? - --=20 Regards Joseph Watson -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQE9m5ieABydhMNsDgMRApgOAJ9S6vlMe8ww0cj9jjwGpl1nVSsh/wCgxT0A M8Sm09Cap8bEczZ3UKL9JWc=3D =3DD7Tq -----END PGP SIGNATURE-----
On Wed, 2 Oct 2002, Joseph Watson wrote:> > My question to Tom is, if I have the database system dump the rules into files > named auth2wan.rules and wan2auth.rules, in the same formate as the rules > file, can I use the same code that reads the rules file to read these? Or > would it just be easyer to use the run_iptables command? >Depends on how closely you want to be tied to my code. If you store the rules using your own format and use your own code to generate iptables commands then you are independent of what I do -- If you use my code and I decide to go in a different direction then you may have to recode. Your choice... You may wish to look at the recent archives of the Shorewall Development list. I''m working on a concept called "Dynamic Zones" which might help you... -Tom -- Tom Eastep \ Shorewall - iptables made easy AIM: tmeastep \ http://www.shorewall.net ICQ: #60745924 \ teastep@shorewall.net
Hum I''ve a strange bug on a new installation of shorewall (In fact my personal server, as I''ve found shorewall working very successfully on the company main firewall) iptables: libiptc/libip4tc.c:384: do_check: Assertion `h->info.valid_hooks == (1 << 0 | 1 << 3)'' failed. Aborted iptables: libiptc/libip4tc.c:384: do_check: Assertion `h->info.valid_hooks == (1 << 0 | 1 << 3)'' failed. Aborted I had this bug with kernel-2.4.18 (athlon optimized) and with kernel-2.4.19 (grsecurity & athlon optimized) iptables 1.2.6a and 1.2.7a. Wow ! Wait a minute... tc ? isn''t for TC ? Do I need to activate QoS ??? Or maybe a specific modules for iptables. Hum can you guide me into the right way please ? Thanks.
Forget to mention : Redhat 7.2...
Jérôme Tytgat wrote:> Hum I''ve a strange bug on a new installation of shorewall (In fact my > personal server, > as I''ve found shorewall working very successfully on the company main > firewall) > > iptables: libiptc/libip4tc.c:384: do_check: Assertion `h->info.valid_hooks > == (1 << 0 | 1 << 3)'' failed. > Aborted > iptables: libiptc/libip4tc.c:384: do_check: Assertion `h->info.valid_hooks > == (1 << 0 | 1 << 3)'' failed. > Aborted > > I had this bug with kernel-2.4.18 (athlon optimized) > and with kernel-2.4.19 (grsecurity & athlon optimized) > iptables 1.2.6a and 1.2.7a. > > Wow ! >Please -- next time at LEAST check the Errata before reaching for your emailer..... http://www.shorweall.net/errata.htm#Debug -Tom -- Tom Eastep \ Shorewall - iptables made easy AIM: tmeastep \ http://www.shorewall.net ICQ: #60745924 \ teastep@shorewall.net
Jérôme Tytgat wrote:> Yes I''ve read it, but looks like you didn''t read my post with enough > attention > > I''m using a self compiled iptables (1.2.7a) and not a Redhat iptables... > (Your point was : Problems with kernels >= 2.4.18 and RedHat iptables, v > 1.2.5) > > I''ve even done a rpm -e iptables... > > I''ve found that : > ================================================================> - I''ve checked my kernel config and there was packet filtering debugging > enabled here, so I''ve supressed it. > - And I''ve found this from a Iptables developper : > > since iptables 1.1.1 thru 1.2.5 this line was in the Makefile from iptables > COPT_FLAGS:=-O2 -DNDEBUG > > in 1.2.7a I have this... > COPT_FLAGS:=-O2 > > - So I''ve changed it to reflect the Old fashioned one... > - Redone all the make process > - Found that even with rpm -e iptables, I had still /sbin/iptables, so i''ve > statically linked them with > /usr/local/bin/iptables > - Now It works. > =================================================================> > Ok, next time wait at least two seconds before beginning to flame me. > > Thanks anyway > > Jerome > > PS: This mail was only sent to you, you are free to forward it to the list > if > you found it useful. >Jerome, I''m sorry if you feel that I flamed you unfairly. a) The fact that you had compiled your own iptables was certainly not clear from your post. b) The errata article that I referred you to explains that the source of the errors you were seeing is that debugging has been enabled when iptables was built (which is what you discovered from the iptables developer). c) If you had seen the Errata article, you should probably have mentioned it in your post and explained that the symptoms you were seeing were the same but that you were not using RedHat RPMs. -Tom -- Tom Eastep \ Shorewall - iptables made easy AIM: tmeastep \ http://www.shorewall.net ICQ: #60745924 \ teastep@shorewall.net
> I''m sorry if you feel that I flamed you unfairly.I think I can live with that :)> a) The fact that you had compiled your own iptables was certainly not > clear from your post.Hum, ok I should have been more clear...> b) The errata article that I referred you to explains that the source of > the errors you were seeing is that debugging has been enabled when > iptables was built (which is what you discovered from the iptablesdeveloper). Yes, but the real final blocking problem was that /sbin/iptables was still there from an old version. In my personal script I was using a variable looking to /usr/local/sbin, even "type iptables" give /usr/local/sbin, typing iptables -V on the command line give the expected results (1.2.7a and not the old rpm one). It was in your script that something was looking to /sbin/iptables (maybe you check if it''s a redhat system and that''s why you look here for the binaries)> c) If you had seen the Errata article, you should probably have mentioned > it in your post and explained that the symptoms you were seeing were the > same but that you were not using RedHat RPMs.Ok shame on me :) Jerome.
Jerome, Jérôme Tytgat wrote:>>I''m sorry if you feel that I flamed you unfairly. > > I think I can live with that :) > > >>a) The fact that you had compiled your own iptables was certainly not >>clear from your post. > > Hum, ok I should have been more clear... > > >>b) The errata article that I referred you to explains that the source of >>the errors you were seeing is that debugging has been enabled when >>iptables was built (which is what you discovered from the iptables > > developer). > Yes, but the real final blocking problem was that /sbin/iptables was still > there > from an old version.Ah -- that can also be a problem :-) I''ve done that to myself before....> In my personal script I was using a variable looking to /usr/local/sbin, > even > "type iptables" give /usr/local/sbin, typing iptables -V on the command > line give the expected results (1.2.7a and not the old rpm one). > It was in your script that something was looking to /sbin/iptables (maybe > you check if it''s a redhat system and that''s why you look here for the > binaries)Shorewall always looks in /sbin before looking in /usr/local/sbin.From /sbin/shorewall: PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/bin:/usr/local/sbin> > >>c) If you had seen the Errata article, you should probably have mentioned >>it in your post and explained that the symptoms you were seeing were the >>same but that you were not using RedHat RPMs. > > Ok shame on me :) >At least your problem is solved. Cheers, -Tom -- Tom Eastep \ Shorewall - iptables made easy AIM: tmeastep \ http://www.shorewall.net ICQ: #60745924 \ teastep@shorewall.net
On Thu, 03 Oct 2002 07:28:48 -0700 Tom Eastep <teastep@shorewall.net> wrote:> Please -- next time at LEAST check the Errata before reaching for your > > emailer..... > > > http://www.shorweall.net/errata.htm#Debug >And I take it, in return, you will check the splleing of your URLS :-)
Dirk Koopman wrote:> On Thu, 03 Oct 2002 07:28:48 -0700 > Tom Eastep <teastep@shorewall.net> wrote: > > >>Please -- next time at LEAST check the Errata before reaching for your >> >>emailer..... >> >> >>http://www.shorweall.net/errata.htm#Debug >> > > > And I take it, in return, you will check the splleing of your URLS :-)--------- :))) Touche!! :-) -Tom -- Tom Eastep \ Shorewall - iptables made easy AIM: tmeastep \ http://www.shorewall.net ICQ: #60745924 \ teastep@shorewall.net
Tom Eastep wrote:> > > Shorewall always looks in /sbin before looking in /usr/local/sbin.From > /sbin/shorewall: > > PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/bin:/usr/local/sbin >So that users can change this, I''ve added PATH= to shorewall.conf for the next release. -Tom -- Tom Eastep \ Shorewall - iptables made easy AIM: tmeastep \ http://www.shorewall.net ICQ: #60745924 \ teastep@shorewall.net