On 04/20/2013 10:16 AM, Dash Four wrote: > >>> Correct? >>> >> >> [teastep@foobar64 two-interfaces]$ cat accounting >> # >> # Shorewall version 4 - Accounting File >> # >> # For information about entries in this file, type "man >> shorewall-accounting" >> # >> # Please see http://shorewall.net/Accounting.html for examples and >> # additional information about how to use this file. >> # >> ################################################################################################################# >> #ACTION CHAIN SOURCE DESTINATION PROTO DEST >> SOURCE USER/ MARK IPSEC >> # PORT(S) PORT(S) GROUP >> SECTION FORWARD >> dmz_fwd - - eth1 >> net2dmz dmz_fwd eth0 >> [teastep@foobar64 two-interfaces]$ shorewall check -r . >> Checking... >> Processing /home/teastep/two-interfaces/shorewall.conf... >> Checking /home/teastep/two-interfaces/zones... >> ... >> Optimizing Ruleset... >> >> cat << __EOF__ >&3 >> # >> # Generated by Shorewall 4.5.15 - Sat Apr 20 09:40:15 2013 >> # >> ... >> >> *filter >> :INPUT DROP [0:0] >> :FORWARD DROP [0:0] >> :OUTPUT DROP [0:0] >> :Broadcast - [0:0] >> :Drop - [0:0] >> :Reject - [0:0] >> :accountfwd - [0:0] >> ... >> :net2dmz - [0:0] >> ... >> -A FORWARD -j accountfwd >> ... >> -A accountfwd -o eth1 -j dmz_fwd >> -A dmz_fwd -i eth0 -j net2dmz >> ... >> Shorewall configuration verified >> [teastep@foobar64 two-interfaces]$ >> >> So you reversed the SOURCE/DEST interfaces. >> > Indeed - I realised that as soon as I ran "shorewall compile" and looked > at the produced output. Thanks Tom. > >> Also note though that if you actually have a zone named 'dmz' and if >> ACCOUNTING_TABLE=filter, your example won't work because there is a >> chain name collision on 'net22dmz'. >> > Yep, that's why I use "mangle" instead. > > Something else you might wish to consider for future implementation: > about 80% of my accounting rules will mimic what I have in "rules" (both > in terms of chain structure as well as iptables rules/matches), so I am > thinking of what could be the best way to "attach" an accounting object > to the rules I am interested in, "cloning" the chain structure as well. > > In other words, if I have, let's say, a separate column in "rules" for > the name of the accounting object to use, then shorewall could then > recreate that same set of matches I used in that "rules" statement to > attach the nfacct object I specified, also mimicking the chain structure > as well. For example: > > rules > ~~~~~ > SECTION NEW > ACCEPT net $FW:+web-ports [... all other columns ...] web > > Assuming that "web" was indicated in a new column in rules, then > shorewall could attempt to create the same set of matches I used in that > rule (ignoring the connection state, of course!), as well as the > existing chain structure, and use it to create an accounting object > called "web". That would save an enormous amount of work, as well as > maintenance (having to sync "rules" with "accounting"). Thoughts? >
Why does it have to be a separate set of chains? If you are using nfacct, why not just bump the accounting objects in the rules chains? -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 \________________________________________________
signature.asc
Description: OpenPGP digital signature
------------------------------------------------------------------------------ Precog is a next-generation analytics platform capable of advanced analytics on semi-structured data. The platform includes APIs for building apps and a phenomenal toolset for data science. Developers can use our toolset for easy data analysis & visualization. Get a free account! http://www2.precog.com/precogplatform/slashdotnewsletter
_______________________________________________ Shorewall-devel mailing list Shorewall-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-devel
