similar to: Shorewall-1.4.6a

Shorewall 1.4.6 is now available. Thanks to Francesca Smith, the 1.4.6 Sample configurations are also available. The release is currently available at: http://shorewall.net/pub/shorewall ftp://shorewall.net/pub/shorewall It will be available at the other mirrors shortly. This is a minor release of Shorewall. Problems Corrected: 1) A problem seen on RH7.3 systems where Shorewall encountered

Hey all, Just a sanity check, but should the shorecap script in shorewall6-lite be sourcing /usr/share/shorewall6-lite/lib.base rather than /usr/share/shorewall-lite/lib.base like it does currently? In fact shouldn''t there be a general s/shorewall-lite/shorewall6-lite/ in shorecap in shorewall6-lite? Maybe there is more of that lurking about as well. Also, the first line of the

Beta 1 is now available at: http://shorewall.net/pub/shorewall/testing ftp://shorewall.net/pub/shorewall/testing This is a minor release of Shorewall. Problems Corrected: 1) A problem seen on RH7.3 systems where Shorewall encountered start errors when started using the "service" mechanism has been worked around. 2) Where a list of IP addresses appears in the DEST column of a

This is a bug-fix roll-up. Problems corrected since 1.4.6: 1) Corrected problem in 1.4.6 where the MANGLE_ENABLED variable was being tested before it was set. 2) Corrected handling of MAC addresses in the SOURCE column of the tcrules file. Previously, these addresses resulted in an invalid iptables command. 3) The "shorewall stop" command is now disabled when

Problems Corrected: 1) A problem seen on RH7.3 systems where Shorewall encountered start errors when started using the "service" mechanism has been worked around. 2) A problem introduced in earlier snapshots has been corrected. This problem caused incorrect netfilter rules to be created when the destination zone in a rule was qualified by an address in CIDR format.

The rule: ACCEPT loc $FW::3128 tcp www doesn''t work propertly, the http access does not redirect to squid but directly exit. what''s wrong? Thanks ------- Dario Lesca (d.lesca@ivrea.osra.it) -------------------------------------- @@@@@@@ this is my shorewall-1.2.13 config: #[/etc/shorewall/common.def]-----------------------------------------------

I''m beginning to believe that the use of the last column in the rules file to designate redirection/forwarding is too subtle for many users. For 1.3, I think I''ll do something like the following: Current rule: ACCEPT net loc:192.168.1.3 tcp 80 - all New rule: FORWARD net loc:192.168.1.3 tcp 80 Current rule: ACCEPT net fw::3128 tcp 80 - all New rule: REDIRECT net

http://shorewall.net/pub/shorewall/Snapshots ftp://shorewall.net/pub/shorewall/Snapshots Problems Corrected since version 1.4.6: 1) Corrected problem in 1.4.6 where the MANGLE_ENABLED variable was being tested before it was set. 2) Corrected handling of MAC addresses in the SOURCE column of the tcrules file. Previously, these addresses resulted in an invalid iptables command.

Hi all, I was trying to test ROUTE specific code with a multi-isp serviced box. There is a bug somewhere, but I''m not able to understand what the real problem is: when I issue a "shorewall show capabilities" I get: Loading /usr/share/shorewall/functions... Processing /etc/shorewall/params ... Processing /etc/shorewall/shorewall.conf... Loading Modules... Shorewall has

http://shorewall.net/pub/shorewall/Snapshots ftp://shorewall.net/pub/shorewall/Snapshots Problems Corrected since version 1.4.6: 1) Corrected problem in 1.4.6 where the MANGLE_ENABLED variable was being tested before it was set. 2) Corrected handling of MAC addresses in the SOURCE column of the tcrules file. Previously, these addresses resulted in an invalid iptables command.

http://shorewall.net/pub/shorewall/Snapshots ftp://shorewall.net/pub/shorewall/Snapshots Problems Corrected since version 1.4.6: 1) Corrected problem in 1.4.6 where the MANGLE_ENABLED variable was being tested before it was set. 2) Corrected handling of MAC addresses in the SOURCE column of the tcrules file. Previously, these addresses resulted in an invalid iptables command. 3)

Hi, I created a modification (more like a hack) to shorewall that backups a configuration after succesfully (re)starting it. In case a future (re)start fails it will use this backup configuration. (instead of stopping the firewall and generating a massive ammount phonecalls ;) I didn''t pay too much attention to the ramifications of this patch, so let me know if i screwed anything up.

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi: I have a small infrastructure of network of local area, that are based on a computer, with computer and with a Point Access, with Debian Etch 4.0r1. With Shorewall 3.2.6-2. Well. Since I have two cards of network, which of which, I have left like that: Internet --> Router (217.126.221.65) --> eth1 (217.126.221.117) --> eth0 (LAN

http://shorewall.net/pub/shorewall/Snapshots ftp://shorewall.net/pub/shorewall/Snapshots Problems Corrected since version 1.4.6: 1) Corrected problem in 1.4.6 where the MANGLE_ENABLED variable was being tested before it was set. 2) Corrected handling of MAC addresses in the SOURCE column of the tcrules file. Previously, these addresses resulted in an invalid iptables command.

Hello all, Yesterday I noticed that my system was "leaking" traffic towards the 10/8 network, I have shorewall installed on multiple machines ranging from single interface devices to ones with 10+ interfaces. I tested all the boxes and they are showing the same behavior. All systems are CentOS 3.4, 2.4.21-27.0.2.ELsmp. Shorewall version: 2.2.1 For the host mentioned is a single

Been trying to track down an issue where when I issue a restart on shorewall it stalls for maybe 5 minutes. I have tracked it down to the removing of the rules portion but have not been able to get any closer yet. Some place after "strip_file rules" and echo "Deleting user chains..." It seems to fix itself after a reboot of the system for an unknown time then it resurfaces

On 2014-02-16 16:36, Elliot Dierksen wrote: > On 2/5/2014 8:24 AM, Charles Lepple wrote: >> On Feb 4, 2014, at 10:48 PM, Elliot Dierksen wrote: >> >>> NUT will complain endlessly about communication errors and never >>> establish SNMP communication with my APC UPS >> Hmm, at first glance, I read the "complain endlessly" part as a figure >> of

On Jul 30, 2013, at 10:39 AM, Pavel Potcheptsov (EKTOS) wrote: > Is this a trouble? Driver use path /var/state/ups/ but upsd use path /var/db/nut/upsd.pid Yes, the driver and upsd need to agree on the path to the socket. From the FreeBSD ports tree: /usr/ports/sysutils/nut/Makefile: STATEDIR?= /var/db/nut [...] CONFIGURE_ARGS= --sysconfdir=${PREFIX}/etc/nut \

http://shorewall.net/pub/shorewall/Snapshots ftp://shorewall.net/pub/shorewall/Snapshots Release Notes are attached Changes since last Snapshot: a) The per-interface dynamic blacklisting chains are now displayed by "shorewall monitor" b) IP Traffic Accounting support has been added. c) Rules may now be rate-limited. d) Bridge interfaces (br[0-9]) may now appear in entries in the

In an email yesterday evening, Perry Nguyen expressed concern about the moving of the ''restarted'' file from /var/lib/shorewall to $STATEDIR (STATEDIR is set in your shorewall.conf file and defaults to /var/state/shorewall). I''m afraid I was a bit short with Perry for which I apologize. Here''s the story: 1. What is the ''restarted'' file