On 11/19/12 7:47 AM, Mr Dash Four wrote:
I'm unable to reproduce that problem.
Test case? If so, what would you like me to include (what is the likely
cause of this)?
The problem is associated with LOAD_HELPERS_ONLY=No; patch attached.
If you want the tcp-ack filter to have priority 1, specify it as
tcp-ack(1)
I thought that is what the "priority" column is for, isn't that the
case? From the shorewall-tcclasses man page:
PRIORITY - priority
[...]
For both HTB and HFSC, the priority is used to calculate the priority of
following Shorewall-generated classification filters that refer to the
class:
* Packet MARK
* tcp-ack and the tos options (see below)
Setting "tcp-ack:1" does indeed suppress that message, though I am
intrigued as to why the priority specified in the "priority" column is
disregarded?
This has been a point of confusion before. The priority displayed in
these messages is the *filter* priority. For compatibility with earlier
releases, they default to what you are seeing; this is clearly
documented in the manpages. Placing the tcp-ack filter at priority 1
means that ACK packets from low-priority bulk traffic will still be
treated as high-priority. If that's what you want, then you need to
explicitly specify it.
OK, the way I understand it, I could only use actions in my policy file,
right?
Correct.
> If so, I am going to have another set of problems:
Currently, by its own definition, shorewall macros can "assign" log
levels "automatically" to all operators in that macro. For example, if I
have the following:
macro.C_MACRO
~~~~~~~~~~~~~
LOG
NFLOG(1,0,1)
NFLOG(2,0,1)
DROP
and then call it with "C_MACRO:info" in, say, my "rules" file, this will
pass this log level (info) "automatically" to LOG (the first operator of
C_MACRO) as well as the DROP statement (and create an additional -
standard LOG jump) before the packet is dropped.
If I use action, how can I achieve this? This is particularly evident in
the policy file: When I use "$FW net DROP:C_ACTION info" I would expect
the "info" log level to be, somehow, passed to C_ACTION. That doesn't
happen though - all I get is a jump to the C_ACTION chain and then I
have an additional LOG in fw2net chain itself - completely detached from
C_ACTION.
There is additional benefit of using macros as far as I can see: when I
use macro, the "code" of that macro is inserted "inline". That has the
added benefit of creating the appropriate "labels" and comments for the
chain in which this macro originated. In other words, when I use
rules
~~~~
C_MACRO:info $FW net
This will create 5 inline statements, like so:
-A fw2net -j LOG --log-level 6 --log-prefix "Shorewall:fw2net:LOG:" -m
comment --comment "C_MACRO"
-A fw2net -j NFLOG --nflog-group 1 --nflog-range 0 --nflog-threshold 1
--nflog-prefix "Shorewall:fw2net:LOG:" -m comment --comment "C_MACRO"
-A fw2net -j NFLOG --nflog-group 2 --nflog-range 0 --nflog-threshold 1
--nflog-prefix "Shorewall:fw2net:LOG:" -m comment --comment "C_MACRO"
-A fw2net -j LOG --log-level 6 --log-prefix "Shorewall:fw2net:DROP:" -m
comment --comment "C_MACRO"
-A fw2net -j DROP -m comment --comment "C_MACRO"
Note the "nflog-prefix", "log-prefix" and "comment" - they are all
"tailored" specifically for the chain in which I use that macro - very
handy since if I am going to use one macro across the board, the chain
from which this call originated could be easily identified
("Shorewall:fw2net:LOG:" and "Shorewall:fw2net:DROP:"). If I use action
instead, that won't be possible since I am going to get this instead:
-A C_ACTION -j NFLOG --nflog-group 1 --nflog-range 0 --nflog-threshold 1
--nflog-prefix "Shorewall:C_ACTION:LOG:"
-A C_ACTION -j NFLOG --nflog-group 2 --nflog-range 0 --nflog-threshold 1
--nflog-prefix "Shorewall:C_ACTION:LOG:"
Notice the nflog-prefix (Shorewall:C_ACTION:LOG:) - there is no way I
could identify which chain the packet originated from and there is no
comment there either.
This might not sound like a big deal, but when I wish to use a single
macro in various policy statements for different directions ($FW->net,
net->$FW etc), when I get a packet logged, I won't know which chain this
packet originated from, or, at the very least, I have to scratch my head
to find out. If I were able to deploy macros in the "policy" instead,
this problem goes away as the macro will be included "inline" with the
appropriate labels and comments to boot.
I'll take a look at this. But in the mean time, you can achieve the same
goal by simply placing your logging rules at the end of the rules file
with SOURCE and DEST set to 'all'.
Patch attached. The new suffixes are:
:U (UNTRACKED)
:NU (NEW,UNTRACKED)
:NIU (NEW,INVALID,UNTRACKED)
Noted, I'll test this later.
Patch attached. Adds a DROP action to the format-2 conntrack file.
Noted, wasn't aware of the "conntrack" file, but I'll test this as well
- I take it the support for ipsets is there, right?
Yes.
-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 \________________________________________________
--
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 \________________________________________________
diff --git a/Shorewall/Perl/Shorewall/Config.pm b/Shorewall/Perl/Shorewall/Config.pm
index c7252f8..4be8c10 100644
--- a/Shorewall/Perl/Shorewall/Config.pm
+++ b/Shorewall/Perl/Shorewall/Config.pm
@@ -3738,7 +3738,7 @@ sub determine_capabilities() {
qt1( "$iptables -t nat -X $sillyname" );
}
- if ( $capabilities{RAW_ENABLED} ) {
+ if ( $capabilities{RAW_TABLE} ) {
qt1( "$iptables -t raw -F $sillyname" );
qt1( "$iptables -t raw -X $sillyname" );
}
------------------------------------------------------------------------------
Monitor your physical, virtual and cloud infrastructure from a single
web console. Get in-depth insight into apps, servers, databases, vmware,
SAP, cloud infrastructure, etc. Download 30-day Free Trial.
Pricing starts from $795 for 25 servers or applications!
http://p.sf.net/sfu/zoho_dev2dev_nov
_______________________________________________
Shorewall-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/shorewall-devel
