forked from extern/shorewall_code
84486d9115
git-svn-id: https://shorewall.svn.sourceforge.net/svnroot/shorewall/trunk@766 fbd18981-670d-0410-9b5c-8dc0c1a9a2bb
66 lines
2.2 KiB
Plaintext
Executable File
66 lines
2.2 KiB
Plaintext
Executable File
This is a minor release of Shorewall.
|
|
|
|
Problems Corrected since version 1.4.6:
|
|
|
|
1) Tuomo Soini has supplied a correction to a problem that occurs using
|
|
some versions of 'ash'. The symptom is that "shorewall start" fails
|
|
with:
|
|
|
|
local: --limit: bad variable name
|
|
iptables v1.2.8: Couldn't load match `-j':/lib/iptables/libipt_-j.so:
|
|
cannot open shared object file: No such file or directory
|
|
Try `iptables -h' or 'iptables --help' for more information.
|
|
|
|
2) Andres Zhoglo has supplied a correction that avoids trying to use
|
|
the multiport match iptables facility on ICMP rules.
|
|
|
|
Example of rule that previously caused "shorewall start" to fail:
|
|
|
|
ACCEPT loc $FW icmp 0,8,11,12
|
|
|
|
3) Previously, if the following error message was issued, Shorewall
|
|
was left in an inconsistent state.
|
|
|
|
Error: Unable to determine the routes routes through interface xxx
|
|
|
|
4) Handling of the LOGUNCLEAN option in shorewall.conf has been
|
|
corrected.
|
|
|
|
Migration Issues:
|
|
|
|
None.
|
|
|
|
New Features:
|
|
|
|
1. A new QUEUE action has been introduced for rules. QUEUE allows you
|
|
to pass connection requests to a user-space filter such as p2pwall
|
|
(http://p2pwall.sourceforge.net).
|
|
|
|
For example, to use p2pwall to filter P2P applications, you would
|
|
add the following rules:
|
|
|
|
QUEUE loc net tcp
|
|
QUEUE loc net udp
|
|
QUEUE loc fw udp
|
|
|
|
You would normally want to place those two rules BEFORE any ACCEPT
|
|
rules for loc->net.
|
|
|
|
Note: When the protocol specified is TCP ("tcp", "TCP" or "6"),
|
|
Shorewall will only pass connection requests (SYN packets) to user
|
|
space. This is for compatibility with p2pwall.
|
|
|
|
2. A BLACKLISTNEWNONLY option has been added to shorewall.conf. When
|
|
this option is set to "Yes", the blacklists (dynamic and static)
|
|
are only consulted for new connection requests. When set to "No"
|
|
(the default if the variable is not set), the blacklists are
|
|
consulted on every packet.
|
|
|
|
Setting this option to "No" allows blacklisting to stop existing
|
|
connections from a newly blacklisted host but is more expensive in
|
|
terms of packet processing time. This is especially true if the
|
|
blacklists contain a large number of entries.
|
|
|
|
|
|
|