Hello Tom.
Thank you for the new convenient fetaures in Shorewall.
But there are some questiones:
1. In your announce-mail wrote:
"Example using CHAIN:
# This example shows how you can aggretate two counters. The
# counters being aggregated are input and output counters on
# the device ''ppp0''. The CHAIN declarations go in the
first
# section of the /etc/shorewall/accounting file.
CHAIN tunnel # Create a chain called
''tunnel''
CHAIN tunnelin tunnel # Create a chain called
# ''tunnelin''
with all
# traffic sent to
# ''tunnelin''
being sent
# on to
''tunnel''
CHAIN tunnelout tunnel # Create a chain called
# ''tunnelout''
with all
# traffic sent to
# ''tunnelout''
being sent
# on to
''tunnel''
# any more matches
tunnelin ppp0 # send all traffic from
# ppp0 to the chain called
# ''tunnelin''
tunnelout any ppp0 # send all traffic to
# ppp0 to the chain called
# ''tunnelout''
"
but in http://shorewall.net/Accounting.html wrote:
"In the first section of the file, the columns are:
ACTION - Must be CHAIN <----?
CHAIN - The name of an accounting chain that you want Shorewall to
create.
NEXT CHAIN - Optional; if specified, the name of an accounting chain
created in an
earlier entry in this section."
So, ACTION must be CHAIN or any chain?
2. I am sorry but don''t understand next phrase:
"For DNAT and REDIRECT rules, rate limiting occurs in the nat table
DNAT rule;
the corresponding ACCEPT rule in the filter table is not rate limited.
If you
want to limit the filter table rule, you will need to create two rules;
a DNAT- rule and an ACCEPT rule which can be rate-limited
separately."
and don''t saw any example for this words.
"Let''s take an example:
ACCEPT<2/sec:4> net dmz tcp 80"
I don''t see in this where we make separate rules.
3. In http://shorewall.net/Accounting.html wrote:
"Associating a counter with a chain allows for aggregation. For
example:
#ACTION SOURCE DESTINATION PROTOCOL DEST PORT SOURCE
PORT
webin:DONE eth0 eth1 tcp 80
webout:DONE eth1 eth0 tcp - 80
webin:DONE eth0 eth1 tcp 443
webout:DONE eth1 eth0 tcp -
443"
and then:
"With these declarations in the first section of the file,
''shorewall show web'' will
show the sum of the ''webin'' and
''webout'' chains.
Example:
[root@gateway etc]# shorewall show webin
Shorewall-1.4.6-20030809 Chain webin at gateway.shorewall.net - Sun
Aug 10 18:29:30 PDT 2003
Counters reset Sun Aug 10 16:35:53 PDT 2003
Chain webin (2 references)
pkts bytes target prot opt in out source
destination
5232 429K web all -- * * 0.0.0.0/0
0.0.0.0/0
..."
but why prot=all but not prot=tcp and where is indicate that SOURCE=eth0,
DESTINATION=eth1, DEST_PORT=80,443?
And i think that DEST_PORT (SOURCE_PORT and other column name in other
config files) more convenient than "DEST PORT". I must not
calculate how much
whitespaces between words (one or more) for define columnes in config files
and may not use quote for write column name in text (as beyond).
4. And yet one thing. I belief that Shorewall only will be yet better if
you realize check for double records when adding new rule by
Shorewall and then any users can use iptables with maximum efficiency
and convenience (without use different style DNAT, DNAT-, REDIRECT,
REDIRECT- and may be in other cases).
With best wishes.
Aleks
On Thu, 2003-08-14 at 07:16, alshu@tut.by wrote:> # This example shows how you can aggretate two counters. The > # counters being aggregated are input and output counters on > # the device ''ppp0''. The CHAIN declarations go in the first > # section of the /etc/shorewall/accounting file. > > CHAIN tunnel # Create a chain called ''tunnel'' > CHAIN tunnelin tunnel # Create a chain called > # ''tunnelin'' with all > # traffic sent to > # ''tunnelin'' being sent > # on to ''tunnel'' > CHAIN tunnelout tunnel # Create a chain called > # ''tunnelout'' with all > # traffic sent to > # ''tunnelout'' being sent > # on to ''tunnel'' > # any more matches > tunnelin ppp0 # send all traffic from > # ppp0 to the chain called > # ''tunnelin'' > tunnelout any ppp0 # send all traffic to > # ppp0 to the chain called > # ''tunnelout'' " > > but in http://shorewall.net/Accounting.html wrote: > "In the first section of the file, the columns are: > > ACTION - Must be CHAIN <----? > CHAIN - The name of an accounting chain that you want Shorewall to create. > NEXT CHAIN - Optional; if specified, the name of an accounting chain created in an > earlier entry in this section." > > So, ACTION must be CHAIN or any chain?For entries in the first section of the file, the first column must contain the token CHAIN. In the example above, the first three entries would be in the first section of the file; the last two would be in the second section. Note that Shorewall doesn''t check that all CHAIN entries come first -- it is simply a convenient way to organize the file.> > 2. I am sorry but don''t understand next phrase: > "For DNAT and REDIRECT rules, rate limiting occurs in the nat table DNAT rule; > the corresponding ACCEPT rule in the filter table is not rate limited. If you > want to limit the filter table rule, you will need to create two rules; > a DNAT- rule and an ACCEPT rule which can be rate-limited separately." > and don''t saw any example for this words. > "Let''s take an example: > > ACCEPT<2/sec:4> net dmz tcp 80"DNAT and REDIRECT Shorewall rules generate TWO Netfilter rules; a DNAT RULE in the nat table and an ACCEPT rule in the filter table. The above is saying that only the one in the nat table is rate-limited.> > I don''t see in this where we make separate rules.The rule: DNAT net dmz:1.2.3.4 tcp 80 is roughly equivalent to DNAT- net dmz:1.2.3.4 tcp 80 ACCEPT net dmz:1.2.3.4 tcp 80> > 3. In http://shorewall.net/Accounting.html wrote: > > "Associating a counter with a chain allows for aggregation. For example: > > #ACTION SOURCE DESTINATION PROTOCOL DEST PORT SOURCE PORT > webin:DONE eth0 eth1 tcp 80 > webout:DONE eth1 eth0 tcp - 80 > webin:DONE eth0 eth1 tcp 443 > webout:DONE eth1 eth0 tcp - 443" > and then: > "With these declarations in the first section of the file, ''shorewall show web'' will > show the sum of the ''webin'' and ''webout'' chains. > Example: > > [root@gateway etc]# shorewall show webin > Shorewall-1.4.6-20030809 Chain webin at gateway.shorewall.net - Sun Aug 10 18:29:30 PDT 2003 > > Counters reset Sun Aug 10 16:35:53 PDT 2003 > > Chain webin (2 references) > pkts bytes target prot opt in out source destination > 5232 429K web all -- * * 0.0.0.0/0 0.0.0.0/0 > ..." > but why prot=all but not prot=tcp and where is indicate that SOURCE=eth0, > DESTINATION=eth1, DEST_PORT=80,443?To see that you have to look at how packets GET to this chain.> And i think that DEST_PORT (SOURCE_PORT and other column name in other > config files) more convenient than "DEST PORT". I must not calculate how much > whitespaces between words (one or more) for define columnes in config files > and may not use quote for write column name in text (as beyond).I have no idea what you are talking about. Shorewall files are aligned on normal 8-column tab stops (with the exception of the rules file which is getting a little crowded). And Shorewall only requires that there be SOME whitespace between the columns; there has never been (nor will there ever be) a requirement that entries appear in a particular column.> > 4. And yet one thing. I belief that Shorewall only will be yet better if > you realize check for double records when adding new rule by > Shorewall and then any users can use iptables with maximum efficiency > and convenience (without use different style DNAT, DNAT-, REDIRECT, > REDIRECT- and may be in other cases). >Again, I don''t understand what you are asking. Sorry -Tom -- Tom Eastep \ Shorewall - iptables made easy Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net