> 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)?
>> 2. "-r" and "-T" shorewall update options are not documented.
>>
>
> The last sentence in the 'update' section of the manpage is:
>
> For a description of the other options, see the check command above.
>
Noted.
> 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?
> That's an error in the manpage -- to use NFLOG, specify "LOG:NFLOG(1,0,1)".
>
Taking into account your latest response on this - I'll use
"NFLOG(1,0,1)" and see if that does the job.
> Use "LOG:<level>!" (note the '!'). e.g., 'LOG:NFLOG(2,0,1)!'
>
Noted, though I have some reservations about using actions - see below.
> Again, USE_ACTIONS=No is no longer supported. I'll correct the manpage.
>
OK, the way I understand it, I could only use actions in my policy file,
right? 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.
> 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?
------------------------------------------------------------------------------
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
