On 9/22/10 5:37 PM, Tom Eastep wrote:
On 9/22/10 4:52 PM, KP Kirchdoerfer wrote:
Hi Shorewall team;
Am Dienstag, 21. September 2010, 17:50:31 schrieb Tom Eastep:
The Shorewall team is pleased to announce the availability of Shorewall
4.4.13.
I've build a new 4.4.13 based package for the
Am Donnerstag, 23. September 2010, 16:22:14 schrieb Tom Eastep:
On 9/22/10 5:37 PM, Tom Eastep wrote:
On 9/22/10 4:52 PM, KP Kirchdoerfer wrote:
Hi Shorewall team;
Am Dienstag, 21. September 2010, 17:50:31 schrieb Tom Eastep:
The Shorewall team is pleased to announce the availability
On 09/23/2010 08:29 AM, KP Kirchdoerfer wrote:
Am Donnerstag, 23. September 2010, 16:22:14 schrieb Tom Eastep:
On 9/22/10 5:37 PM, Tom Eastep wrote:
On 9/22/10 4:52 PM, KP Kirchdoerfer wrote:
Hi Shorewall team;
Am Dienstag, 21. September 2010, 17:50:31 schrieb Tom Eastep:
The Shorewall team
Am Donnerstag, 23. September 2010, 17:59:36 schrieb Tom Eastep:
On 09/23/2010 08:29 AM, KP Kirchdoerfer wrote:
Am Donnerstag, 23. September 2010, 16:22:14 schrieb Tom Eastep:
On 9/22/10 5:37 PM, Tom Eastep wrote:
On 9/22/10 4:52 PM, KP Kirchdoerfer wrote:
Hi Shorewall team;
Am
The Shorewall team is pleased to announce the availability of Shorewall
4.4.13.
Hi Tom and all,
I've just updated some systems to 4.4.13 and I see a new log message on
RHEL4 (yes I know it's ancient):
MARK: can only be called from mangle table, not filter
Does it hurt? Do you know a
On 9/21/10 11:47 PM, Simon Matter wrote:
I've just updated some systems to 4.4.13 and I see a new log message on
RHEL4 (yes I know it's ancient):
MARK: can only be called from mangle table, not filter
Does it hurt? Do you know a solution? (it does not happen with 4.4.12.2)
Hi Simon,
The
On 9/21/10 11:47 PM, Simon Matter wrote:
I've just updated some systems to 4.4.13 and I see a new log message on
RHEL4 (yes I know it's ancient):
MARK: can only be called from mangle table, not filter
Does it hurt? Do you know a solution? (it does not happen with 4.4.12.2)
Hi Simon,
The
Hi Shorewall team;
Am Dienstag, 21. September 2010, 17:50:31 schrieb Tom Eastep:
The Shorewall team is pleased to announce the availability of Shorewall
4.4.13.
I've build a new 4.4.13 based package for the LEAF distribution and did some
preliminary tests in my qemu test environment.
I see a
On 9/22/10 4:52 PM, KP Kirchdoerfer wrote:
Hi Shorewall team;
Am Dienstag, 21. September 2010, 17:50:31 schrieb Tom Eastep:
The Shorewall team is pleased to announce the availability of Shorewall
4.4.13.
I've build a new 4.4.13 based package for the LEAF distribution and did some
The Shorewall team is pleased to announce the availability of Shorewall 4.4.13.
I. P R O B L E M S C O R R E C T E D I N T H I S R E L E A S E
On 9/21/10 9:53 AM, Mr Dash Four wrote:
shorewall.net still shows 4.4.13 RC1, is that right?
Look in the 'Current Stable Release' line
-Tom
--
Tom Eastep\ When I die, I want to go like my Grandfather who
Shoreline, \ died peacefully in his sleep. Not screaming like
Washington,
This is a natural consequence of making blacklisting a zone-related
attribute rather than an interface-related attribute. Interface-oriented
filtering comes first; so if more than one zone shares an
Internet-facing interface then interface-related filtering can occur
prior to zone-related
On 09/17/2010 08:22 PM, Tom Eastep wrote:
On 9/17/10 4:31 PM, Tom Eastep wrote:
COM_IF_fwd is similar.
I'm not sure whether or not I'll be able to do anything about this in
the short term.
This is a natural consequence of making blacklisting a zone-related
attribute rather than an
Tom
Tcfilters entry:
eth0:33 2.2.2.2 1.1.1.1 tcp :22
produces the following message:
ERROR: Invalid/Unknown 6 port/service (0) : /etc/shorewall2/tcfilters (line
13)
Steven.
--
Start uncovering the many
On 09/18/2010 08:58 AM, Tom Eastep wrote:
On 09/17/2010 08:22 PM, Tom Eastep wrote:
On 9/17/10 4:31 PM, Tom Eastep wrote:
COM_IF_fwd is similar.
I'm not sure whether or not I'll be able to do anything about this in
the short term.
This is a natural consequence of making blacklisting a
On 9/18/10 9:01 AM, Steven Jan Springl wrote:
Tcfilters entry:
eth0:33 2.2.2.2 1.1.1.1 tcp :22
produces the following message:
ERROR: Invalid/Unknown 6 port/service (0) : /etc/shorewall2/tcfilters (line
13)
Thanks, Steven
This should fix it.
-Tom
--
Tom Eastep\ When I
On Saturday 18 September 2010 17:13:03 Tom Eastep wrote:
On 9/18/10 9:01 AM, Steven Jan Springl wrote:
Tcfilters entry:
eth0:33 2.2.2.2 1.1.1.1 tcp :22
produces the following message:
ERROR: Invalid/Unknown 6 port/service (0) : /etc/shorewall2/tcfilters
(line 13)
Thanks,
Beta 6 is now available for testing. Pay close attention to the
Blacklisting change in this release; static blacklisting is incompatible
with blacklisting in Beta 5.
Problems corrected:
1) 'shorewall clear' (and 'shorewall6 clear') now work again (broken
in Beta 5).
2) To work around an
On 9/17/10 9:10 AM, Tom Eastep wrote:
Beta 6 is now available for testing. Pay close attention to the
Blacklisting change in this release; static blacklisting is incompatible
with blacklisting in Beta 5.
There are a couple of known problems.
a) Mr Dash 4 has reported that a perl diagnostic
On 9/17/10 9:10 AM, Tom Eastep wrote:
Beta 6 is now available for testing. Pay close attention to the
Blacklisting change in this release; static blacklisting is incompatible
with blacklisting in Beta 5.
Problems corrected:
1) 'shorewall clear' (and 'shorewall6 clear') now work again
Tom
When routestopped contains:
eth3 192.168.0.0/29,10.1.1.1 notrack
After 'shorewall start' and 'shorewall clear' commands have been executed,
iptables-save shows the following rules are still active:
raw
:PREROUTING ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
-A PREROUTING -s 192.168.0.0/29 -i br1
On 9/17/10 4:35 PM, Steven Jan Springl wrote:
Tom
When routestopped contains:
eth3 192.168.0.0/29,10.1.1.1 notrack
After 'shorewall start' and 'shorewall clear' commands have been executed,
iptables-save shows the following rules are still active:
raw
:PREROUTING ACCEPT [0:0]
On 9/17/10 4:41 PM, Tom Eastep wrote:
On 9/17/10 4:35 PM, Steven Jan Springl wrote:
Tom
When routestopped contains:
eth3 192.168.0.0/29,10.1.1.1 notrack
After 'shorewall start' and 'shorewall clear' commands have been executed,
iptables-save shows the following rules are still active:
On Saturday 18 September 2010 01:12:09 Tom Eastep wrote:
On 9/17/10 4:41 PM, Tom Eastep wrote:
On 9/17/10 4:35 PM, Steven Jan Springl wrote:
Tom
When routestopped contains:
eth3 192.168.0.0/29,10.1.1.1 notrack
After 'shorewall start' and 'shorewall clear' commands have been
On 9/17/10 4:31 PM, Tom Eastep wrote:
COM_IF_fwd is similar.
I'm not sure whether or not I'll be able to do anything about this in
the short term.
This is a natural consequence of making blacklisting a zone-related
attribute rather than an interface-related attribute. Interface-oriented
On 9/14/10 7:33 AM, Tom Eastep wrote:
3) The IN-BANDWIDTH column in both /etc/shorewall/tcdevices and
/etc/shorewall/tcinterfaces now accepts an optional burst parameter.
rate[:burst]
The default burst is 10kb. A larger burst can help make the rate
more accurate;
I had not planned on another Beta, but the work that I've been doing
with Simple Traffic Shaping has been so promising that I want to get it
into the 4.4.13 release.
New Features:
1) The OPTIONS column in the blacklists file may now be a comma-
separated list of 'to' and 'from'. Duplicates
Tom
tcrules entry:
SAME:P 192.168.120.0/24 0.0.0.0
produces the following messages:
iptables v1.4.9.1: Cannot use -A with -A
ERROR: Command /usr/local/sbin/iptables -A setsticky -A -s
192.168.120.0/24 -d 0.0.0.0 -m mark --mark 0x1/0xff -m recent --name
sticky001 --set Failed
Steven.
On 9/11/10 7:40 AM, Steven Jan Springl wrote:
tcrules entry:
SAME:P 192.168.120.0/24 0.0.0.0
produces the following messages:
iptables v1.4.9.1: Cannot use -A with -A
ERROR: Command /usr/local/sbin/iptables -A setsticky -A -s
192.168.120.0/24 -d 0.0.0.0 -m mark --mark 0x1/0xff -m
On 9/11/10 9:06 AM, Tom Eastep wrote:
On 9/11/10 7:40 AM, Steven Jan Springl wrote:
tcrules entry:
SAME:P 192.168.120.0/24 0.0.0.0
produces the following messages:
iptables v1.4.9.1: Cannot use -A with -A
ERROR: Command /usr/local/sbin/iptables -A setsticky -A -s
192.168.120.0/24
On Saturday 11 September 2010 17:06:34 Tom Eastep wrote:
On 9/11/10 7:40 AM, Steven Jan Springl wrote:
tcrules entry:
SAME:P 192.168.120.0/24 0.0.0.0
produces the following messages:
iptables v1.4.9.1: Cannot use -A with -A
ERROR: Command /usr/local/sbin/iptables -A setsticky
On 9/11/10 9:40 AM, Steven Jan Springl wrote:
After applying the fix, the following messages are produced (this is with
OPTIMIZE=15):
iptables v1.4.9.1: Couldn't load target
`sticky':/usr/local/libexec/xtables/libipt_sticky.so: cannot open shared
object file: No such file or directory
On Saturday 11 September 2010 17:38:04 Tom Eastep wrote:
On 9/11/10 9:06 AM, Tom Eastep wrote:
On 9/11/10 7:40 AM, Steven Jan Springl wrote:
tcrules entry:
SAME:P 192.168.120.0/24 0.0.0.0
produces the following messages:
iptables v1.4.9.1: Cannot use -A with -A
ERROR:
On 9/11/10 10:43 AM, Steven Jan Springl wrote:
On Saturday 11 September 2010 17:38:04 Tom Eastep wrote:
I just corrected the case where SAME is used with SOURCE $FW; that's
commit 367fc041b8b34deb60bc6bdd821a9de5333f2c06.
I can't find this commit.
Sorry -- it's there now.
-Tom
--
Tom
On Saturday 11 September 2010 18:50:13 Tom Eastep wrote:
On 9/11/10 10:43 AM, Steven Jan Springl wrote:
On Saturday 11 September 2010 17:38:04 Tom Eastep wrote:
I just corrected the case where SAME is used with SOURCE $FW; that's
commit 367fc041b8b34deb60bc6bdd821a9de5333f2c06.
I can't
On 9/11/10 11:05 AM, Steven Jan Springl wrote:
On Saturday 11 September 2010 18:50:13 Tom Eastep wrote:
On 9/11/10 10:43 AM, Steven Jan Springl wrote:
On Saturday 11 September 2010 17:38:04 Tom Eastep wrote:
I just corrected the case where SAME is used with SOURCE $FW; that's
commit
On Saturday 11 September 2010 19:13:19 Tom Eastep wrote:
On 9/11/10 11:05 AM, Steven Jan Springl wrote:
On Saturday 11 September 2010 18:50:13 Tom Eastep wrote:
On 9/11/10 10:43 AM, Steven Jan Springl wrote:
On Saturday 11 September 2010 17:38:04 Tom Eastep wrote:
I just corrected the
On 9/11/10 11:39 AM, Steven Jan Springl wrote:
e93a7fe9df34ce9e3b3e03e7535ce278a654e4d6 works with both OPTIMIZE=15 and
OPTIMIZE=0.
Thanks, Steven!
-Tom
--
Tom Eastep\ When I die, I want to go like my Grandfather who
Shoreline, \ died peacefully in his sleep. Not
Beta 4 is now available for testing.
Problems Corrected:
None.
New Features:
1) Shorewall now supports the SECMARK and CONNSECMARK targets for
manipulating the SELinux context of packets.
See the shorewall-secmarks and shorewall6-secmarks manpages for
details.
As part of
Beta 3 is now available for testing.
Problems corrected:
1) Exclusion in the blacklist file was correctly validated but was then
ignored when generating iptables (ip6tables) rules.
2) Previously, non-trivial exclusion (more than one excluded
address/net) in CONTINUE, NONAT and ACCEPT+
Beta 2 is now available for testing.
Problems corrected in this release:
1) Under rare circumstances where COMMENT is used to attach comments
to rules, OPTIMIZE 8 through 15 could result in invalid
iptables-restore (ip6tables-restore) input.
2) Under rare circumstances involving
41 matches
Mail list logo
