<pre>----------------------------------------------------------------------------<br> R E L E A S E 4 . 4 H I G H L I G H T S<br>----------------------------------------------------------------------------<br><br>1) Support for Shorewall-shell has been discontinued. Shorewall-perl<br> has been combined with Shorewall-common to produce a single<br> Shorewall package.<br><br>2) Support for the "Hierarchical Fair Service Curve" (HFSC) queuing<br> discipline has been added. HFSC is superior to the "Hierarchical<br> Token Bucket" queuing discipline where realtime traffic such as<br> VOIP is being used.<br><br>3) Support for the "flow" traffic classifier has been added. This<br> classifier can help prevent multi-connection applications such as<br> BitTorrent from using an unfair amount of bandwidth.<br><br>4) The Shorewall documentation and man pages have been purged of<br> information about earlier Shorewall releases. The documentation<br> describes only the behavior of Shorewall 4.4 and later versions.<br><br>5) The interfaces file OPTIONs have been extended to largely remove the<br> need for the hosts file.<br><br>6) It is now possible to define PREROUTING and OUTPUT marking rules<br> that cause new connections to use the same provider as an existing<br> connection of the same kind.<br><br>7) Dynamic Zone support is once again available for IPv4; ipset support is<br> required in your kernel and in iptables.<br><br>8) A new AUTOMAKE option has been added to shorewall.conf and<br> shorewall6.conf. Setting this option will allow Shorewall to skip<br> the compilation phase during start/restart if no configuration<br> changes have occurred since the last start/restart.<br><br>9) The LIMIT:BURST column in /etc/shorewall/policy<br> (/etc/shorewall6/policy) and the RATE LIMIT column in<br> /etc/shorewall/rules (/etc/shorewall6/rules) may now be used to<br> limit on a per source IP or per destination IP basis.<br><br>10) Support for per-IP traffic shaping classes has been added.<br><br>11) Support for netfilter's TRACE facility has been added. TRACE allows<br> you to trace selected packets through Netfilter, including marking<br> by tcrules. <br><br></pre>
<pre>Problems corrected in Shorewall 4.2.10<br><br>1) A 'large quantum' warning log message during restart has been<br> eliminated. The log message occurred when an interface with a large<br> OUT-BANDWIDTH was defined in /etc/shorewall/tcdevices.<br><br>2) When a REJECT rule included a log entry, the disposition in the log<br> message was incorrectly shown as 'reject' rather than 'REJECT'.<br><br>3) When 'forward' was specified on one or more interfaces in<br> /etc/shorewall6/interfaces, the progress message "Compiling<br> Interface forwarding..." was issued multiple times. Now, only one<br> instance of the message is generated.<br><br>4) A typing error in the IPv6 two-interface sample shorewall6.conf<br> file has been corrected. This error prevented the compiler from<br> being able to find macros in /usr/share/shorewall/.<br><br>Known Problems Remaining:<br><br>1) When exclusion is used in an entry in /etc/shorewall/hosts, then<br> Shorewall-shell produces an invalid iptables rule if any of the <br> following OPTIONS are also specified in the entry: <br><br> blacklist<br> maclist<br> norfc1918<br> tcpflags<br><br>2) Shorewall-shell generates inversion rules which produce<br> warnings with iptables 1.4.3. <br><br> Example:<br><br> iptables -A lan2fw -p 6 --dport 999 -s ! 192.168.20.1 -j ACCEPT<br><br> with iptables 1.4.3.1 the following information message is produced:<br><br> Using intrapositioned negation (`--option ! this`) is deprecated in<br> favor of extrapositioned (`! --option this`).<br><br> We don't intend to fix this. It's time to migrate to Shorewall-perl<br> anyway.<br><br>New Features in Shorewall 4.2.10<br><br>1) Shorewall's suppport for dynamic gateways on interfaces managed by<br> dhclient works on OpenSuSE systems but not on some other<br> distributions.<br><br> In order to generalize support for learning the gateway for dynamic<br> interfaces, a new 'findgw' extension script (user exit) has been<br> added.<br><br> The exit will be invoked in a function that has a single argument:<br><br> $1 = <name of an interface><br><br> If the function can determine the gateway for the passed interface,<br> it should write the gateway to standard out. Here is a sample<br> /etc/shorewall/findgw that works with dhclient (dhcp3) in Debian<br> Lenny:<br><br> if [ -f /var/lib/dhcp3/dhclient.${1}.leases ]; then<br> grep 'option routers' /var/lib/dhcp3/dhclient.${1}.leases |\<br> tail -n 1 |\<br> while read j1 j2 gateway; do\<br> echo $gateway | sed 's/;//';\<br> done<br> fi<br><br> The same code works on Ubuntu Jaunty if you replace the first '.'<br> with '-' and replace '.leases' with '.lease' (don't you just love<br> the consistency between distributions?).<br><br> That code also works on CentOS if you replace 'dhcp3' by<br> 'dhclient'.<br><br> 'findgw' files that have been customized for various distributions<br> may be found at<br> http://www.shorewall.net/pub/shorewall/contrib/findgw.<br></pre>
<pre>Problems corrected in Shorewall 4.2.9<br><br>1) The Shorweall-perl 4.2.8 compiler did not rename the output script<br> file with the result that:<br><br> a) Shorewall would not start for the first time after<br> installation.<br> b) Configuration changes were apparently ignored.<br><br>2) Placing a broadcast address in the BROADCAST column of<br> /etc/shorewall/interfaces caused Shorewall-perl to generate an<br> error:<br><br> ERROR: Invalid BROADCAST address : /etc/shorewall/interfaces\<br> (line 225)<br><br>3) When Shorewall could not determine the MAC address of of a gateway<br> router where multiple providers are configured through the same<br> interface, invalid iptables-restore input was generated. This<br> resulted in an error message similar to the following:<br><br> iptables-restore v1.3.5: Bad mac address `-j'<br><br>4) Shorewall-perl was not processing the tcrules file when<br> TC_ENABLED=No.<br><br>5) When 'all' appeared in the SOURCE column of a DNAT rule, no rule to<br> redirect output from the firewall itself was generated.<br><br>6) The 'shorewall iprange' command failed to produce a minimal list of<br> networks.<br><br>New Features in Shorewall 4.2.9<br><br>1) Shorewall6 has now been validated on Ubuntu Hardy running kernel<br> 2.6.24. Shorewall6 is now supported on that kernel version.<br></pre>
<p><strong>2009-04-16 Shorewall 4.2.8<br>
</strong></p>
<p><strong></strong></p>
<pre>Problems Corrected in Shorewall 4.2.8<br><br>1) The 'start -f' command would previously skip the compilation step<br> unconditionally when the 'make' utility was not installed. Now, the<br> compilation step is run unconditionally in this case.<br><br>2) When ADD_IP_ALIASES=Yes in shorewall.conf, entries in<br> /etc/shorewall/nat produce this failure at compile time when<br> using Shorewall-perl:<br><br> ERROR: Internal Error in emit : /etc/shorewall/nat (line 12)<br><br>3) When LOG_MARTIANS=Yes with Shorewall-perl, setting logmartians=0 in<br> an entry in /etc/shorewall/interface failed to suppress martian<br> logging on the interface.<br><br>4) Shorewall-perl now generates rules with inversion that are<br> compatible with iptables 1.4.3.<br><br>5) When a network address was specified in the SOURCE or DEST column of<br> /etc/shorewall/tcfilters, Shorewall-perl was generating an incorrect<br> netmask.<br><br>New Features in 4.2.8<br><br>1) The /usr/share/shorewall/modules and /usr/share/shorewall6/modules<br> files have been updated for iptables 1.4.3/kernel 2.6.29.<br></pre>
<pre>Problems corrected in 4.2.7<br><br>1) Previously, the 'start' command set the permission flags on<br> /var/lib/shorewall*/state so that it could be read by<br> non-root users while the 'stop' command set the permissions such<br> that the file could not be read by those users.<br><br> Beginning with 4.2.7, both commands will secure the file for<br> root-only access. If you want the file to be world-readable, then<br> add <br><br> chmod 744 <file name><br><br> To your /etc/shorewall/started, /etc/shorewall/stopped and<br> /etc/shorewall/restored files.<br><br>2) The 'shorewall6 dump' command now correctly displays the installed<br> version of Shorewall-perl. It also displays the IPv6 neighbor table<br> contents rather than the ARP table contents.<br><br>3) Under some circumstances, interface options like nosmurfs and<br> tcpflags would not be applied to forwarded traffic when using<br> Shorewall-perl.<br><br>4) The following rule was badly mis-handled:<br><br> DNAT- loc net:1.2.3.4:2525 tcp 25<br><br> The result:<br><br> WARNING: Destination zone (1.2.3.4) ignored : /etc/shorewall/rules (line 459)<br> Can't call method "inet_htoa" without a package or object reference at<br> /usr/share/shorewall-perl/Shorewall/IPAddrs.pm line 150,<br><$currentfile> line 459.<br><br>5) Previously, OPTIONS were not allowed with a bridge port in<br> /etc/shorewall/interfaces. That oversight has been corrected and<br> now the following OPTIONS are allowed:<br><br> blacklist<br> maclist<br> norfc1918<br> nosmurfs<br> routeback<br> tcpflags<br><br>6) Tuomo Soini provided a workaround patch for a problem seen in some<br> kernel's (see FAQ 82) that caused 'shorewall start' to fail when<br> USE_DEFAULT_RT=Yes .<br><br>New Features in Shorewall 4.2.7<br><br>1) Prior to Shorewall version 3.0.0, rules generated by<br> /etc/shorewall/tunnels were traversed before those generated by<br> /etc/shorewall/rules. When SECTIONs were added to the rules file in<br> 3.0.0, traversal of the tunnel rules was deferred until after those<br> generated by the NEW section of the rules file. <br><br> Beginning with Shorewall-perl 4.2.7, the tunnel rules are back<br> where they started -- right before the first rule generated by the<br> NEW section of /etc/shorewall/rules.<br><br>2) To allow bypassing of connection tracking for certain traffic,<br> /etc/shorewall/notrack and /etc/shorewall6/notrack files have been<br> added.<br><br> Columns in the file are:<br><br> SOURCE - <zone>[:<interface>][:<address list>]<br><br> DEST - [<address list>]<br><br> PROTO - <protocol name or number><br><br> DEST PORT(S) - <port number list><br><br> SOURCE PORT(S) - <port number list><br><br> USER/GROUP - [<user>][:<group>]<br><br> May only be specified if the SOURCE <zone> is $FW.<br><br> Traffic that matches all given criteria will not be subject to<br> connection tracking. For such traffic, your policies and/or rules<br> must deal with ALL of the packets involved, in both the original<br> and the opposite directions. All untracked traffic is passed<br> through the relevant rules in the NEW section of the rules<br> file. Untracked encapsulated tunnel traffic can be handled by<br> entries in /etc/shorewall/tunnels just like tracked traffic<br> is. Because every packet of an untracked connection must pass<br> through the NEW section rules, it is suggested that rules that deal<br> with untracked traffic should appear at the top of the file.<br><br> Example:<br><br> /etc/shorewall/tunnels:<br><br> #TYPE ZONE GATEWAY<br> 6to4 net<br><br> /etc/shorewall/notrack<br><br> #SOURCE DEST PROTO DEST SOURCE USER/<br> # PORT(S) PORT(S) GROUP<br> net:!
<pre>Problems corrected in 4.2.6<br><br>1) The CONFIG_PATH in the two- and three-interface Shorewall6 sample<br> configurations was incorrect with the result that this error<br> occurred on 'shorewall6 check' or 'shorewall6 start'.<br><br> ERROR: No IP zones defined<br><br>2) Setting TCP_FLAGS_DISPOSITION=REJECT caused both Shorewall-shell<br> and Shorewall-perl to create invalid iptables commands. This has<br> been corrected but we still strongly recommend against that<br> setting; TCP_FLAGS_DISPOSITION=DROP is preferred.<br><br>3) Shorewall-perl was generating code that checked for state match<br> before kernel modules were loaded. This caused start/restart to<br> fail on systems without kernel module loading. <br><br>4) The Shorewall6 and Shorewall6-lite Makefiles were incorrect.<br><br>5) If a service name is used in a port-mapping rule (a DNAT or<br> REDIRECT rule that changes the destination port), and if the<br> kernel and iptables include Extended Connection Match support, then<br> invalid iptables-restore input is produced by Shorewall-perl.<br><br>6) If iptables 1.4.1 or later was installed, Shorewall-perl generated<br> incorrect iptables-restore input if exclusion was used in the<br> ORIGINAL DEST field of a DNAT or REDIRECT rule.<br><br>7) On kernels earlier than 2.6.20, the 'shorewall show connections'<br> command fails.<br><br>New Feature in Shorewall 4.2.6<br><br>1) A BitTorrent32 macro has been added. This macro matches the<br> extended TCP port range used by BitTorrent 3.2 and later.<br><br>2) A new COUNT action has been added to Shorewall-perl. This action<br> creates an iptables (ip6tables) rule with no target. Connections<br> matching such a rule are simply counted and the packet is passed on<br> to the next rule.<br><br> Shorewall-shell ignores COUNT in actions and macros, thus allowing<br> the standard actions (action.Drop and action.Reject) to have a<br> COUNT rule as their first entry.<br><br>3) A new RESTORE_DEFAULT_ROUTE option has been added to<br> shorewall.conf. It is used to determine whether to restore the<br> default route saved when there are 'balance' providers defined but<br> all of them are down.<br><br> The default is RESTORE_DEFAULT_ROUTE=Yes which preserves the<br> pre-4.2.6 behavior. <br><br> RESTORE_DEFAULT_ROUTE=No is appropriate when you don't want a<br> default route in the main table (USE_DEFAULT_RT=No) or in the<br> default table (USE_DEFAULT_RT=Yes) when there are no balance<br> providers available. In that case, RESTORE_DEFAULT_ROUTE=No<br> will cause any default route in the relevant table to be deleted.<br><br>4) IPv4 firewall scripts produced by Shorewall-perl now use dhcpcd's<br> database when trying to detect the gateway for an interface<br> ("detect" in the GATEAWAY column in /etc/shorewall/interfaces).<br><br> As part of this change, it is now permitted to specify 'detect'<br> when USE_DEFAULT_RT=Yes; in that case, the script will only detect<br> gateways for point-to-point devices and for devices configured by<br> dhcpcd.<br><br>5) Shorewall-perl now supports port inversion. A port number or list<br> of port numbers may be preceded by '!" which will cause the rule to<br> match all ports EXCEPT those listed:<br><br> Example: To blacklist 206.124.146.176 for all tcp ports except 80:<br><br> ADDRESS/SUBNET PROTO PORT(S)<br> 206.124.146.177 tcp !80<br><br>6) Shorewall-perl now supports protocol inversion. A protocol name or<br> number may be preceded by '!' to specify all protocols except the<br> one following '!'.<br><br> Example: To blacklist 206.124.146.176 for all protocols except <br> UDP:<br><br> ADDRESS/SUBNET PROTO PORT(S)<br> 206.124.146.177 !udp<br><br> Note that ports may not be specified when protocol inversion<br> is used.<br><br>7) When using Shorewall-perl, neither the 'start' nor 'started
<pre>Problems corrected in 4.2.5<br><br>1) If exclusion is used to define a zone in /etc/shorewall/hosts and<br> that zone is used as the SOURCE zone in a DNAT or REDIRECT rule,<br> then Shorewall-perl can generate invalid iptables-restore input.<br><br>2) A bug in the Perl Cwd module (see<br><a
class="moz-txt-link-freetext"
href="http://rt.cpan.org/Public/Bug/Display.html?id=13851">http://rt.cpan.org/Public/Bug/Display.html?id=13851</a>) causes the<br> Shorewall-perl compiler to fail if it doesn't have at least read<br> access to its current working directory. 4.2.5 contains a<br> workaround.<br><br>3) If 'critical' was specified on an entry in<br> /etc/shorewall6/routestopped, Shorewall6 (Shorewall-perl) would<br> generate an error.<br><br>4) In certain cases where exclusion occurred in /etc/shorewall/hosts,<br> Shorewall-perl would generate incorrect iptables-restore input.<br><br>5) In certain cases where exclusion occurred in /etc/shorewall/hosts,<br> Shorewall-perl would generate invalid iptables-restore input.<br><br>6) The 'shorewall6 refresh' command runs iptables_restore rather than<br> ip6tables_restore.<br><br>7) The commands 'shorewall6 save-start', 'shorewall6-save-restart' and<br> 'shorewall6 restore' were previously broken.<br><br>8) The Debian init script was checking $startup in<br> /etc/default/shorewall rather than in /etc/default/shorweall6<br><br>9) The Archlinux init scripts for Shorewall6 and Shorewall6 Lite were<br> unconverted Shorewall scripts.<br><br>10) When 'detect' is used in the GATEWAY column of<br> /etc/shorewall/providers, Shorewall-perl now ensures that the<br> gateway was successfully detected. If the gateway cannot be<br> detected, action is taken depending on whether the provider is<br> 'optional' or not. If the provider is optional, it's configuration<br> is skipped; if the provider is not optional, the current operation<br> is aborted.<br><br>11) The command 'shorewall6 debug start' would previously fail with<br> ERROR: Command "/sbin/ip6tables -t nat -F" Failed<br><br>12) Both ipv4 and ipv6 compiled programs attempt to run the tcclear<br> script itself at run time rather than running the copy of the<br> file in the compiled script. This usually isn't noticable unless<br> you are running Shorewall Lite or Shorewall6 Lite in which case,<br> the script doesn't get run (since it is on the administrative<br> system and not the firewall system).<br><br>13) If your iptables/kernel included "Extended Connection Tracking<br> Match support" (see the output of "shorewall show capabilities"),<br> then a REDIRECT rule that specified a port list or range would<br> cause Shorewall-perl to create invalid iptables-restore input:<br><br> Running /usr/sbin/iptables-restore...<br> iptables-restore v1.4.2-rc1: conntrack: Bad value for<br> "--ctorigdstport" option: "1025:65535"<br> Error occurred at line: 191<br> Try `iptables-restore -h' or 'iptables-restore --help' for more information.<br> ERROR: iptables-restore Failed. Input is in <i
class="moz-txt-tag">/</span></i>.iptables-restore-input<br><br>Known Problems Remaiining:<br><br>1) When exclusion is used in an entry in /etc/shorewall/hosts, then<br> Shorewall-shell produces an invalid iptables rule if any of the<br> following OPTIONS are also specified in the entry:<br><br> blacklist<br> maclist<br> norfc1918<br> tcpflags<br><br>New Feature in Shorewall 4.2.5<br><br>1) A new 'fallback' option is added in<br> /etc/shorewall/providers. The option works similar to 'balance'<br> except that the default route is added in the default routing table<br> (253) rather than in the main table (254).<br><br> The option can be used by itself or followed by =<number> (e.g,<br> fallback=2).<br><br> When the option is used by itself, a separate (not balanced)<br> default route is added with a metric equal to the provider's NUMBER.<br><br> When the option is used with a number, a balanced route is added<br> with the weight set to the specified number.<br><br> 'fallback' is ignored if USE_DEFAULT_RT=Yes in shorewall.conf and<br> is only available with Shorewall-perl.<br><br> 'fallback' is useful in situations where:<br><br> - You want all traffic to be sent via one primary provider unless<br> there is a compelling reason to use a different provider<br><br> - If the primary provider is down, then you want to balance the<br> outgoing traffic among a set of other providers or to a<br> ordered list of providers.<br><br> In this case:<br><br> - Do not specify 'balance' on any of the providers.<br> - Disable route filtering ('ROUTE_FILTER=No' in shorewall.conf).<br> - Specify 'fallback' on those providers that you want to use if<br> the primary is down.<br> - Only the primary provider should have a default route in the main<br> routing table.<br><br> See <a
class="moz-txt-link-freetext"
href="http://www.shorewall.net/MultiISP.html#Complete">http://www.shorewall.net/MultiISP.html#Complete</a> for an example<br> of this option's use.<br><br>2) Shorewall-perl now transparently handles the xtables-addon version<br> of ipp2p. Shorewall detects whether the installed ipp2p is from<br> patch-o-matic-ng or from xtables-addon and proceeds accordingly.<br><br> If the patch-o-matic-ng version is installed:<br><br> a) If no DEST PORT is supplied, the default is "--ipp2p".<br> b) If "ipp2p" is supplied as the DEST PORT, it will be passed to<br> iptables-restore as "--ipp2p".<br><br> If the xtables-addons version is installed:<br><br> a) If no DEST PORT is supplied, the default is "--edk --gnu --dc<br> --kazaa".<br> b) If "ipp2p" is supplied as the DEST PORT, it will be passed to<br> iptables-restore as "--edk --gnu --dc --kazaa".<br><br> Shorewall-perl now also accepts a comma-separated list of options<br> (e.g., "edk,gnu,dc,kazaa).<br><br> Additionally, Shorewall now looks for modules in <i
class="moz-txt-slash"><spanclass="moz-txt-tag">/</span>extra and in /lib/modules<span
class="moz-txt-tag">/</span></i>$(uname -r)/extra/ipset<br><br> This change introduced a new capability ("Old IPP2P Match Syntax")<br> so if you use a capabilities file, be sure to re-generate the<br> file(s) after you have installed 4.2.5.<br><br>3) There is now a macro.Git, which opens git-daemon's port (9418/tcp).<br><br>4) There is also a macro.IRC which open's the Internet Relay Chat port<br> (6667/tcp).</pre>
<p><strong>2009-01-06 Winner of the Shorewall Logo Design Competition
Announced</strong></p>
The Shorewall developers are pleased to announce that after deliberating<br>
upon the matter, we have chosen Gareth Davies' #3 design.<br>
<pre>1) In 4.2.4, two new packages are included:<br><br> a) Shorewall6 - analagous to Shorewall-common but handles IPv6<br> rather than IPv4.<br><br> b) Shorewall6-lite - analagous to Shorewall-lite but handles IPv6<br> rather than IPv4.<br><br> The packages store their configurations in /etc/shorewall6/ and<br> /etc/shorewall6-lite/ respectively. <br><br> The fact that the packages are separate from their IPv4 counterparts<br> means that you control IPv4 and IPv6 traffic separately (the same<br> way that Netfilter does). Starting/Stopping the firewall for one<br> address family has no effect on the other address family.<br><br> For additional information, see<br> http://www.shorewall.net/IPV6Support.html.<br><br> Other features of Shorewall6 are:<br><br> a) There is no NAT of any kind (most people see this as a giant step<br> forward). When an ISP assigns you a public IPv6 address, you are<br> actually assigned an IPv6 'prefix' which is like an IPv4<br> subnet. A 64-bit prefix allows 4 billion squared individual hosts<br> (the size of the current IPv4 address space squared).<br><br> b) The default zone type is ipv6.<br><br> c) The currently-supported interface options in Shorewall6 are:<br><br> blacklist<br> bridge<br> dhcp<br> nosmurfs (traps multicast and Subnet-router anycast addresses<br> used as the packet source address).<br> optional<br> routeback<br> sourceroute<br> tcpflags<br> mss<br> forward (setting it to 0 makes the router behave like a host<br> on that interface rather than like a router).<br><br> d) The currently-supported host options in Shorewall6 are:<br><br> blacklist<br> routeback<br> tcpflags<br><br> e) Traffic Shaping is disabled by default. The tcdevices and<br> tcclasses files are address-family independent so<br> to use the Shorewall builtin Traffic Shaper, TC_ENABLED=Internal<br> should be specified in Shorewall or in Shorewall6 but not in<br> both. In the configuration where the internal traffic shaper is<br> not enabled, CLEAR_TC=No should be specified.<br><br> tcfilters are not available in Shorewall6.<br><br> f) When both an interface and an address or address list need to<br> be specified in a rule, the address or list must be enclosed in<br> angle brackets. Example:<br><br> #ACTION SOURCE DEST<br> ACCEPT net:eth0:<2001:19f0:feee::dead:beef:cafe> dmz<br><br> Note that this includes MAC addresses as well as IPv6 addresses.<br><br> The HOSTS column in /etc/shorewall6/hosts also uses this<br> convention:<br><br> #ZONE HOSTS OPTIONS<br> chat6 eth0:<2001:19f0:feee::dead:beef:cafe><br><br> Even when an interface is not specified, it is permitted to<br> enclose addresses in <> to improve readability. Example:<br><br> #ACTION SOURCE DEST<br> ACCEPT net:<2001:1::1> $FW<br><br> g) The options available in shorewall6.conf are a subset of those<br> available in shorewall.conf.<br><br> h) The Socket6.pm Perl module is required if you include DNS names<br> in your Shorewall6 configuration. Note that it is loaded the<br> first time that a DNS name is encountered so if it is missing,<br> you get a message similar to this one:<br><br> ...<br> Checking /etc/shorewall6/rules...<br> Can't locate Socket6.pm in @INC (@INC contains: /root ...<br> teastep@ursa:~/Configs/standalone6$ <br></pre>
<pre>Problems corrected in Shorewall 4.2.3<br><br>1) Previously, Shorewall would allow compilation for export of a<br> script named 'shorewall' with the unfortunate side effect that<br> the 'shorewall.conf' file was overwritten. Scripts named<br> 'shorewall' now cause a fatal error to be raised.<br><br>2) Previously, Shorewall-perl attempted to do Shell variable<br> substitution on the first line in /etc/shorewall/compile.<br><br>3) Following the Netfilter tradition, the IPP2P maintainer has made an<br> incompatible syntax change (the --ipp2p option has been<br> removed). Shorewall has always used "-m ipp2p --ipp2p" when<br> detecting the presence of IPP2P support.<br><br> Shorewall-common and Shorewall-perl have been modified to use<br> "-m ipp2p --edk" instead.<br><br>4) When Extended Conntrack Match support was available, Shorewall-perl<br> would create invalid iptables-restore input for certain DNAT rules.<br><br>5) An optimization in all Shorewall-perl 4.2 versions could cause<br> undesirable side effects. The optimization deleted the<br><interface>_in and <interface>_fwd chains and moved their rules<br> to the appropriate rules chain (a <zone>2<xxx> chain).<br><br> This worked badly in cases where a zone was associated with more<br> than one interface. Rules could be duplicated or, worse, a rule<br> that was intended for only input from one of the interfaces would<br> be applied to input from all of the zone's interfaces.<br><br> This problem has been corrected so that an interface-related<br> chains is only deleted if:<br><br> a) the chain has no rules in it; or<br> b) the interface is associated with only one zone and that zone is<br> associated with only that interface in which case it is safe to<br> move the rules.<br><br>Other changes in Shorewall 4.2.3<br><br>1) Except with the -e option is specified, the Shorewall-perl compiler<br> now verifies user/group names appearing in the USER/GROUP column of<br> the rules file.<br><br>2) The output of 'shorewall dump' now includes the output from<br> 'netstat -tunap'.<br><br>3) Shorewall-perl now accepts '+' as an interface name in<br> /etc/shorewall/interfaces. That name matches any interface and is<br> useful for defining a zone that will match any interface that might<br> be added after Shorewall is started.<br><br> A couple of words of caution are in order.<br><br> a) Because '+' matches any interface name, Shorewall cannot<br> verify interface names appearing in other files when '+' is<br> defined in /etc/shorewall/interfaces.<br><br> b) The zone assigned to '+' must be the last one defined in<br> /etc/shorewall/zones.<br><br>4) Shorewall-perl now uses the iptables --goto parameter in obvious<br> cases.<br><br>5) The 'reset' command now allows you to reset the packet and byte<br> counter on individual chains:<br><br> shorewall reset chain1 chain2 ...<br> shorewall-lite reset chain1 chain2 ...<br></pre>
<pre><br>1) Shorewall-perl now insures that each line copied from a<br> configuration file or user exit is terminated with a newline<br> character.<br><br>2) When ipranges were used to define zones, Shorewall-perl could<br> generate invalid iptables-restore input if 'Repeat Match' was not<br> available. Repeat Match is not a true match -- it rather is a<br> feature of recent iptables releases that allows a match to be<br> repeated within a rule.<br><br>3) With Shorewall-perl, if a destination port list had exactly 16<br> ports, where a port-range counts as two ports, then Shorewall-perl<br> would fail to split the rule into multiple rules and an<br> iptables-restore error would result.<br><br>4) The change to Shorewall-perl in 4.2.1 that promised iptables 1.4.1<br> compatibility contained a typo that prevented it from working<br> correctly.<br><br>5) If a no-NAT rule (DNAT-, ACCEPT+, NONAT) included a destination IP<br> address and no zone name in the DEST column, Shorewall-perl would<br> reject the rule. If a zone name was specified, Shorewall-perl <br> would issue a Warning message.<br><br>6) Previously, if Extended conntrack match support was available, a<br> DNAT rule that specified a server port but no destination port <br> would generate invalid iptables-restore input. <br><br>Other changes in Shorewall 4.2.2<br><br>1) A macro supporting JAP (anonymization protocol) has been added.<br> It can be used as any other macro (e.g., JAP/ACCEPT) in the rules<br> file.<br><br>2) A macro supporting DAAP (Digital Audio Access Protocol) has been added.<br> It can be used as any other macro (e.g., DAAP/ACCEPT) in the rules<br> file.<br><br>3) A macro supporting DCC (Distributed Checksum Clearinghouse) has been<br> added. It can be used as any other macro (e.g., DCCP/ACCEPT) in the<br> rules file.<br><br>4) A macro supporting GNUnet (secure peer-to-peer networking) has been<br> added. It can be used as any other macro (e.g., GNUnet/ACCEPT) in the<br> rules file.<br><br>5) In 4.2.1, a single capability ("Extended conntrack match support")<br> was used both to control the use of --ctorigport and to trigger use<br> of the new syntax for inversion of --ctorigdst (e.g., "!<br> --ctorigdst ..."). In 4.2.2, these are controlled by two separate<br> capabilities. If you use a capabilities file when compiling your<br> configuration, be sure to generate a new one after installing<br> 4.2.2.<br></pre>
<p><strong>2008-10-25 Shorewall 4.2.1<br>
</strong><strong></strong></p>
<pre>Problems corrected in Shorewall 4.2.1<br><br>1) A description of the CONNBYTES column has been added to<br> shorewall-tcrules(5).<br><br>2) Previously, Shorewall-perl would accept zero as the <max> value in<br> the CONNBYTES column of tcrules even when the <min> field was<br> non-zero. A value of zero for <max> was equivalent to omitting<br><max>.<br><br>3) iptables 1.4.1 discontinued support of syntax generated by<br> shorewall in some cases. Shorewall now detects when the new syntax<br> is required and uses it instead.<br><br>4) The Shorewall-perl implementation of the LENGTH column in<br> /etc/shorewall/tcrules was incomplete with the result that <br> all LENGTH rules matched. Thanks to Lennart Sorensen for the patch.<br><br>5) The 'export' command no longer fails with the error:<br><br> /sbin/shorewall: 1413: Syntax error: "(" unexpected (expecting "fi")<br><br>Other changes in Shorewall 4.2.1<br><br>1) With the recent renewed interest in DOS attacks, it seems<br> appropriate to have connection limiting support in Shorewall. To<br> that end, a CONNLIMIT column has been added to both the policy and<br> rules files.<br><br> The content of these columns is of the format<br><br> [!] <limit>[:<mask>]<br><br> where<br><br><limit> is the limit on simultaneous TCP connections.<br><br><mask> specifies the size of the network to which<br> the limit applies and is specified as a<br> CIDR mask length. The default value for<br><mask> is 32 which means that each remote<br> IP address can have <limit> TCP connections<br> active at once.<br><br> ! Not allowed in the policy file. In the rules file, it<br> causes connections to match when the number of<br> current connections exceeds <limit>.<br><br> When specified in the policy file, the limit is enforced on all<br> connections that are subject to the given policy (just like<br> LIMIT:BURST). The limit is checked on new connections before the<br> connection is passed through the rules in the NEW section of the<br> rules file.<br><br> It is important to note that while the limit is only checked for<br> those destinations specified in the DEST column, the number of<br> current connections is calculated over all destinations and not<br> just the destination specified in the DEST column.<br><br> Use of this feature requires the connlimit match capability in your<br> kernel and iptables. If you use a capabilities file when compiling<br> your Shorewall configuration(s), then you need to regenerate the<br> file using Shorewall or Shorewall-lite 4.2.1.<br><br>2) Shorewall now supports time/date restrictions on entries in the <br> rules file via a new TIME column.<br><br> The contents of this column is a series of one or more "time<br> elements" separated by apersands ("&"). Possible time elements are:<br><br> utc Times are expressed in Greenwich Mean Time.<br> localtz Times are expressed in local civil time (default)<br> timestart=hh:mm[:ss]<br> timestop=hh:mm[:ss] Start and stop time of day for rule<br> weekdays=ddd[,ddd]... where ddd is Mon,Tue,Wed,Thu,Fri,Sat or<br> Sun<br> monthdays=dd[,dd]... where dd is an ordinal day of the month.<br> datestart=yyyy[-mm[-dd[Thh[:mm[:ss]]]]]<br> datestop=yyyy[-mm[-dd[Thh[:mm[:ss]]]]]<br> where yyyy = Year<br> first mm = Month<br> dd = Day<br> hh = Hour<br> 2nd mm = Minute<br> ss = Second<br><br> Examples:<br><br> 1) utc&timestart=10:00&timestop=12:00<br><br> Between 10am and 12 noon each day, GMT<br><br> 2) datestart=2008-11-01T12:00<br>
<pre>Problems corrected in Shorewall-perl 4.0.10.<br><br>1) Shorewall-perl 4.0.9 erroneously reported an error message when a<br> bridge port was defined in /etc/shorewall/interfaces:<br><br> ERROR: Your iptables is not recent enough to support bridge ports<br><br>2) Under Shorewall-perl, if an empty action was invoked or was named<br> in one of the DEFAULT_xxx options in shorewall.conf, an<br> iptables-restore error occured.<br><br>3) If $ADMIN was empty, then the rule:<br><br> ACCEPT loc:$ADMIN all<br><br> became<br><br> ACCEPT loc net<br><br> It is now flagged as an error.<br><br>4) Previously, Shorewall-perl would reject an IP address range in the<br> ecn and routestopped files.<br><br>5) A POLICY of ":" in /etc/shorewall/policy would produce Perl<br> run-time errors.<br><br>6) An INTERFACE of ":" in /etc/shorewall/interfaces would produce Perl<br> run-time errors.<br><br>7) A MARK of ":" in /etc/shorewall/tcrules would produce Perl<br> run-time errors.<br><br>Problems corrected in Shorewall-shell 4.0.10.<br><br>1) Specifying a value for ACCEPT_DEFAULT or QUEUE_DEFAULT resulted in<br> a fatal error at compile time.<br><br>Known Problems Remaining.<br><br>1) The 'refresh' command doesn't refresh the mangle table. So changes<br> made to /etc/shorewall/providers and/or /etc/shorewall/tcrules may<br> not be reflected in the running ruleset.<br><br>Other changes in 4.0.10.<br><br>1) The Sample configurations have been updated to set<br> LOG_MARTIANS=keep. In 4.2, this will be changed to<br> LOG_MARTIANS=Yes.<br><br>2) Shorewall-perl now generates a fatal error if a non-existant shell<br> variable is used in any configuration file (except<br> /etc/shorewall/params).<br><br>3) Shorewall-perl now supports an 'l2tp' tunnel type. It opens UDP<br> port 1701 in both directions and assumes that the source port will<br> also be 1701. Some implementations (particularly OS X) use a<br> different source port. In that case, you should use<br> 'generic:udp:1701' rather than 'l2tp'.<br></pre>
<pre>1) Shorewall now removes any default bindings of ipsets before<br> attempting to reload them. Previously, default bindins were not<br> removed with the result that the ipsets could not be destroyed.<br><br><br>2) When HIGH_ROUTE_MARKS=Yes, unpredictable results could occur when<br> marking in the PREROUTING or OUTPUT chains. When a rule specified a<br> mark value > 255, the compiler was using the '--or-mark' operator<br> rather than the '--set-mark' operator with the result that when a<br> packet matched more than one rule, the resulting routing mark was<br> the logical product of the mark values in the rules.<br><br><br> Example:<br><br><br> 0x100 192.168.1.44 0.0.0.0/0<br> 0x200 0.0.0.0/0 0.0.0.0/0 tcp 25<br><br><br> A TCP packet from 192.168.1.44 with destination port 25 would end<br> up with a mark value of 0x300.<br><br><br>3) Shorewall now properly parses comma separated SOURCE (formerly<br> SUBNET) values in the masq configuration file. Previously, the comma<br> separated list was not split up into its components, resulting in an<br> invalid address being passed to the iptables command.<br><br><br> Example:<br><br><br> # /etc/shorewall/masq<br> #INTERFACE SUBNET ADDRESS PROTO PORT(S) IPSEC<br> eth0 192.168.2.1,192.168.2.3<br><br><br>4) Previously, specifying both an interface and a MAC address in the<br> SOURCE column of the tcrules file caused a failure at runtime.<br> Thanks to Justin Joseph for the patch.<br><br><br>5) Previously, specifying both an interface and an address in the<br> tcrules DEST column would cause an incomplete rule to be generated.<br><br><br> Example:<br><br><br> 1 192.168.1.4 eth2:206.124.146.177 tcp 22<br><br><br> The resulting tcrule would be as if this had been specified:<br><br><br> 1 0.0.0.0/0 eth2:206.124.146.177 tcp 22<br><br><br>6) When HIGH_ROUTE_MARKS=Yes, the routing rules generated to match<br> fwmarks to routing tables overflowed the designated range for such<br> marks (10000 - 11000).</pre>
<pre>Problems corrected in Shorewall-perl 4.0.9.1<br><br>1) In 4.0.9, Shorewall-perl incorrectly generated the following error<br> message:<br><br> ERROR: Your iptables is not recent enough to support bridge ports<br><br>Problems corrected in Shorewall-perl 4.0.9<br><br>1) If a zone was defined with exclusion in /etc/shorewall/hosts, then<br> the rules generated for directing outgoing connections to the zone<br> were incorrect.<br><br> Example:<br><br> /etc/shorewall/zones:<br><br> z ipv4<br><br> /etc/shorewall/interfaces:<br><br> - eth2 <br><br> /etc/shorewall/hosts:<br><br> z eth2:192.168.1.0/24!192.168.1.5<br><br> Traffic from the firewall to 192.168.1.5 was incorrectly classified<br> as $FW->z.<br><br>2) Qualifying 'SOURCE' and 'DEST' with an IP address in a macro file<br> caused 'SOURCE' or 'DEST' to be interpreted incorrectly as the name<br> of an interface.<br><br> Example:<br><br> PARAM DEST SOURCE:224.0.0.22<br><br>3) Specifying '!<user>' in the USER/GROUP column of the files that<br> support it resulted in an invalid iptables rule under<br> Shorewall-perl.<br><br>4) Previously, Shorewall would accept both an interface and an IP<br> address in tcrules POSTROUTING entries (such as CLASSIFY).<br><br> Example:<br><br> 1:11 eth1:192.168.4.9 - tcp 22<br><br> It also allowed both a destination interface and address.<br><br> Example:<br><br> 1:P - eth1:192.168.4.9 tcp 22<br><br> Because Netfilter does not allow an input interface to be specified<br> in POSTROUTING or an output interface to be specified in<br> PREROUTING, Shorewall must use the routing table to generate a list<br> of networks accessed through any interface specified in these<br> cases. Given that a specific address (or set of addresses) has<br> already been specified, it makes no sense qualify it (them) by<br> another list of addresses.<br><br>5) Shorewall-perl incorrectly generated a fatal error when ':C', <br> ':T' or ':CT' was used in a tcrules entry that gave $FW as the<br> SOURCE.<br><br>6) Users have been confused about this error message:<br><br> ERROR: Bridge Ports require Repeat match in your kernel and iptables <br><br> The message has been replaced with:<br><br> ERROR: Your iptables is not recent enough to support bridge ports<br><br> The minimum version required is 1.3.8.<br><br>Problems corrected in Shorewall-shell 4.0.9.<br><br>1) An optimization added to Shorewall-shell in 4.0.0 has been backed<br> out to work around a limitation of Busybox 'sed'.<br><br>2) Previously, specifying both an interface and an address in the<br> tcrules DEST column would cause an incomplete rule to be generated.<br><br> Example:<br><br> 1 192.168.1.4 eth2:206.124.146.177 tcp 22<br><br> The resulting tcrule would be as if this had been specified:<br><br> 1 0.0.0.0/0 eth2:206.124.146.177 tcp 22<br><br>3) When HIGH_ROUTE_MARKS=Yes, the routing rules generated to match<br> fwmarks to routing tables previously overflowed the designated<br> range defined for such marks (10000 - 11000). <br><br>Known Problems Remaining.<br><br>1) The 'refresh' command doesn't refresh the mangle table. So changes<br> made to /etc/shorewall/providers and/or /etc/shorewall/tcrules may<br> not be reflected in the running ruleset.<br><br>Other changes in 4.0.9.<br><br>1) The Shorewall-perl now flags unprintable garbage characters in<br> configuration files with the message:<br><br> ERROR: Non-ASCII gunk in file <br><br>2) The /usr/share/shorewall/modules file has been updated to reflect<br> module renaming in kernel 2.6.25.<br><br>3) The 'ip route replace' command is broken in kernel 2.6.24. To work<br> around this problem, the undocumented option BROKEN_ROUTING has<br> been added to shorewall.conf. The default is BROKEN_ROUTING=No.<br><br> If you are experiencing 'File Exists' errors from 'ip route<br> replace' c
<pre>Problems corrected in Shorewall-perl 4.0.8.<br><br>1) Mark tests (such as in the TEST column of tcrules or the MARK<br> column of the rules file) were ignoring the value 0. As part of<br> this fix, the default mask generated by entries in these columns<br> has been changed from 0xFF to 0xFFFF for compatibility with<br> Shorewall-shell.<br><br>2) The compilation date recorded in the firewall.conf file produced by<br> Shorewall-perl was previously mangled.<br><br>3) The ability to specify a DEST IP range (round-robin) in a DNAT rule<br> has been restored. In versions 4.0.5 - 4.0.7, an IP range was<br> incorrectly flagged as an error.<br><br>Problems corrected in Shorewall-shell 4.0.8.<br><br>1) Shorewall-shell now properly parses comma separated SOURCE (formerly<br> SUBNET) values in the masq configuration file. Previously, the comma<br> separated list was not split up into its components, resulting in an<br> invalid address being passed to the iptables command.<br><br> Example:<br><br> # /etc/shorewall/masq<br> #INTERFACE SUBNET ADDRESS PROTO PORT(S) IPSEC<br> eth0 192.168.2.1,192.168.2.3<br><br>Known Problems Remaining.<br><br>1) The 'refresh' command doesn't refresh the mangle table. So changes<br> made to /etc/shorewall/providers and/or /etc/shorewall/tcrules may<br> not be reflected in the running ruleset.<br><br>Other changes in 4.0.8.<br><br>None.<br></pre>
<pre> This problem was experienced mostly by Debian users and users of<br> Debian derivatives such as Ubuntu.</pre>
<pre>2) The iptables utility doesn't retry operations that fail due to<br> resource shortage. Beginning with this release, Shorewall reruns<br> iptables when such a failure occurs.</pre>
<pre>3) Previously, Shorewall-perl did not accept log levels in upper case<br> (e.g., INFO). Beginning with 4.0.7, log levels are treated in a<br> case-insensitive manner by Shorewall-perl.</pre>
<pre>4) The column headers in macro files were not aligned. This has been<br> corrected, along with some inaccuracies in the macro.template file.</pre>
<pre>5) The shorewall.conf files in the Samples did not contain some<br> recently-defined options. They are now up to date.</pre>
<pre>6) The names of the Jabber macros were shuffled. They are now named<br> correctly.</pre>
<pre>7) If ADD_IP_ALIASES=Yes, an alias was incorrectly added when the<br> specified INTERFACE ended with ":" (e.g., eth0:).</pre>
<pre>8) Shorewall-shell generated an incorrect iptables rule from the<br> following:</pre>
<pre>1) The 'refresh' command doesn't refresh the mangle table. So changes<br> made to /etc/shorewall/providers and/or /etc/shorewall/tcrules may<br> not be reflected in the running ruleset.</pre>
<pre>Other changes in 4.0.7</pre>
<pre>1) If the program named in SHOREWALL_SHELL doesn't exist or is not<br> executable, Shorewall and Shorewall-lite now both fall back to<br> /bin/sh after issuing a warning message. Previously, both<br> terminated with a fatal error.</pre>
<pre>2) The error message has been improved when a non-root user attempts<br> "shorewall show capabilities".</pre>
<pre>3) Shorewall-perl now generates fatal error conditions when there are<br> no IPv4 zones defined and when there are no interfaces defined.<hr></pre>
<pre>1) If NFLOG or ULOG was specified with parameters, the resulting<br> iptables-restore input contained elements that were incorrectly<br> up-cased.</pre>
<pre>2) If STARTUP_LOG is specified without LOG_VERBOSITY, /sbin/shorewall<br> produces an error.</pre>
<pre>3) If LOG_VERBOSITY is specified without STARTUP_LOG, run-time error<br> messages are produced.</pre>
<pre>4) Shorewall-shell was mishandling the entries in /etc/shorewall/rules<br> and in /etc/shorewall/tcrules where both a SOURCE interface and MAC<br> address were specified.</pre>
<pre>1) If the program named in SHOREWALL_SHELL doesn't exist or is not<br> executable, Shorewall and Shorewall-lite now both fall back to<br> /bin/sh after issuing a warning message. Previously, both<br> terminated with a fatal error.</pre>
<pre>2) The error message has been improved when a non-root user attempts<br> "shorewall show capabilities".</pre>
<pre>3) Shorewall-perl now generates fatal error conditions when there are<br> no IPv4 zones defined and when there are no interfaces defined.</pre>
<pre>4) Shorewall now unconditionally uses tc filter rules to classify<br> traffic by MARK value. Previously, Shorewall used the CLASSIFY<br> target in the POSTROUTING chain if it was available.</pre>
<pre>5) The Shorewall-common installer (install.sh) now works on Windows<br> under Cygwin.</pre>
<pre> To install Shorewall-perl under Cygwin:</pre>
<pre> $ tar -xf shorewall-perl-4.1.3.tar.bz2<br> $ tar -xf shorewall-common-4.1.3.tar.bz2<br> $ cd shorewall-perl-4.1.3<br> $ ./install.sh<br> $ cd ../shorewall-common-4.1.3<br> $ USER=<your user id> GROUP=None ./install.sh<br> <br> The 'shorewall' program is installed in /bin/ (a.k.a, /usr/bin/).<hr></pre>
<pre>Problems corrected in Shorewall-perl 4.0.6.<br><br>1) In a DNAT or REDIRECT rule, if no serverport was given and the DEST<br> PORT(S) list contained a service name containing a hyphen ("-") then<br> an ERROR was generated.<br><br> Example -- Rules file:<br><br> DNAT net loc:$WINDOWS_IP tcp https,pptp,ms-wbt-server,4125<br><br> Results in:<br><br> ERROR: Invalid port range (ms:wbt:server) : rules (line 49)<br><br> Problem was introduced in Shorewall 4.0.5 and does not occur in<br> earlier releases.<br><br>2) If a long destination port list needed to be broken at a port pair,<br> the generated rule contained an extra comma which resulted in an<br> iptables-restore failure.<br><br>3) Several problems involving port ranges and port lists in REDIRECT<br> rules have been corrected.<br><br>4) Shorewall-perl no longer requires an address in the GATEWAY column<br> of /etc/shorewall/tunnels. If the column is left empty (or contains<br> '-') then 0.0.0.0/0 is assumed.<br><br>5) Previously with Shorewall-perl, redirecting both STDOUT and STDERR<br> to the same file descriptor resulted in scrambled output between<br> the two. The error messages were often in the middle of the<br> regular output far ahead of the point where the error occurred.<br><br> This problem was possible in the Debian Shorewall init script<br> (/etc/init.d/shorewall) which redirects output to the<br> Debian-specific /var/log/shorewall-init.log file in this way:<br><br> $SRWL $SRWL_OPTS start >> $INITLOG 2>&1 && ...<br><br>6) With both compilers, when HIGH_ROUTE_MARKS=Yes, unpredictable<br> results could occur when marking in the PREROUTING or OUTPUT<br> chains. When a rule specified a mark value > 255, the compilers<br> were using the '--or-mark' operator rather than the '--set-mark'<br> operator. Consequently, when a packet matched more than one<br> rule, the resulting routing mark was the logical product of the<br> mark values in the matching rules rather than the mark value from<br> the last matching rule.<br><br> Example:<br><br> 0x100 192.168.1.44 0.0.0.0/0<br> 0x200 0.0.0.0/0 0.0.0.0/0 tcp 25<br><br> A TCP packet from 192.168.1.44 with destination port 25 would have<br> a mark value of 0x300 rather than the expected value of 0x200.<br><br>7) Previously, a 'start -f' on Shorewall Lite would produce the<br> following distressing output before starting the firewall:<br><br> make: *** No rule to make target `/firewall', needed by<br> `/var/lib/shorewall-lite/restore'. Stop.<br><br> Furthermore, the Makefile for both Shorewall and Shorewall Lite<br> failed to take into account the /etc/shorewall/vardir file.<br><br> This has been corrected. As part of the fix, both /sbin/shorewall<br> and /sbin/shorewall-lite support a "show vardir" command that<br> displays the VARDIR setting.<br><br>8) Shorewall-perl was previously ignoring the USER/GROUP column of the<br> tcrules file.<br><br>9) Supplying the name of a built-in chain in the 'refresh' command<br> caused entries in the chain to be duplicated. Since this is a<br> feature of iptables-restore with the '-n' option, built-in chains<br> in the 'refresh' list will now be rejected.<br><br>Known Problems Remaining.<br><br>1) The 'refresh' command doesn't refresh the mangle table. So changes<br> made to /etc/shorewall/providers and/or /etc/shorewall/tcrules may<br> not be reflected in the running ruleset.<br><br>Other changes in Shorewall 4.0.6.<br><br>1) Shorewall-perl now uses the '--physdev-is-bridged' option when it<br> is available. This option will suppress messages like the following:<br><br> kernel: physdev match: using --physdev-out in the OUTPUT, FORWARD and<br> POSTROUTING chains for non-bridged traffic is not supported<br> anymore.<br><br> This change only affects users who use bport/bport4 zones in a<br> briged configuration and requires that capabilities fil
<pre>Problems corrected in Shorewall 4.0.5.<br><br>1) Previously, Shorewall-perl misprocessed $FW::<port> in the DEST<br> column of a REDIRECT rule, generating an error. '$FW::<port>' now<br> produces the same effect as '<port>'.<br><br>2) If the PROTOCOL (PROTO) column contained 'TCP' or 'UDP' and SOURCE<br> PORT(S) or DEST PORT(S) were given, then Shorewall-perl rejected<br> the entry with the error:<br><br> ERROR: SOURCE/DEST PORT(S) not allowed with PROTO TCP : /etc/shorewall/rules <br><br> The rule was accepted if 'tcp' or 'udp' was used instead.<br><br>3) Shorewall-shell now removes any default bindings of ipsets before<br> attempting to reload them. Previously, default bindings were not<br> removed with the result that the ipsets could not be destroyed.<br><br>Other changes in Shorewall 4.0.5.<br><br>1) Two new options have been added to /etc/shorewall/hosts<br> (Shorewall-perl only).<br><br> broadcast: Permits limited broadcast (destination 255.255.255.255)<br> to the zone.<br><br> destonly: Normally used with the Multi-cast range. Specifies that<br> traffic will be sent to the specified net(s) but that <br> no traffic will be received from the net(s).<br><br> Example:<br><br> wifi eth1:192.168.3.0/24 broadcast<br> wifi eth1:224.0.0.0/4 destonly<br><br> In that example, limited broadcasts from the firewall with a source<br> IP in the 192.168.3.0/24 range will be acccepted as will multicasts<br> (with any source address).<br><br>2) A MULTICAST option has been added to shorewall.conf. This option<br> will normally be set to 'No' (the default). It should be set to <br> 'Yes' under the following circumstances:<br><br> a) You have an interface that has parallel zones defined via<br> /etc/shorewall/hosts.<br> b) You want to forward multicast packets to two or more of those<br> parallel zones.<br><br> In such cases, you will configure a 'destonly' network on each <br> zone receiving multicasts.<br><br> The MULTICAST option is only recognized by Shorewall-perl and is<br> ignored by Shorewall-shell.<br><br>3) As announced in the Shorewall 4.0.4 release notes, Shorewall-perl<br> no longer supports the 'detectnets' option. Specifying that option<br> now results in the following message:<br><br> WARNING: Support for the 'detectnets' option has been removed<br><br> It is suggested that 'detectnets' be replaced by<br> 'routefilter,logmartians'. That will produce the same filtering<br> effect as 'detectnets' while eliminating 1-2 rules per connection.<br><br> One user has asked how to retain the output of 'shorewall show<br> zones' if the 'detectnets' option is removed. While I don't advise<br> doing so, you can reproduce the current 'shorewall show' behavior<br> as follows.<br><br> Suppose that you have a zone named 'wifi' that produces the<br> following output with 'detectnets':<br><br> wifi (ipv4)<br> eth1:192.168.3.0/24<br><br> You can reproduce this behavior as follows:<br><br> /etc/shorewall/interfaces:<br><br> - eth1 detect ...<br><br> /etc/shorewall/hosts:<br><br> wifi eth1:192.168.3.0/24 broadcast<br><br> If you send multicast to the 'wifi' zone, you also need this entry<br> in your hosts file:<br><br> wifi eth1:224.0.0.0/4 destonly<br><br>4) (Shorewall-perl only) The server port in a DNAT or REDIRECT rule<br> may now be specified as a service name from<br> /etc/services. Additionally:<br><br> a) A port-range may be specified as the service port expressed in<br> the format <low port>-<high port>. Connections are assigned to<br> server ports in round-robin fashion.<br><br> b) The compiler only permits a server port to be specified if the<br> protocol is tcp or udp.<br><br> c) The compiler ensures that the server IP address is valid (note<br> that it is still not permitted t
<pre>Problems Corrected in Shorewall 3.4.7<br><br>1) A bug prevented proper handling of PREROUTING marks when<br> HIGH_ROUTE_MARKS=No and the track option was specified in<br> /etc/shorewall/providers.<br><br>2) Previously, if the following sequence of routing rules was<br> specified, then the first rule would always be omitted.<br><br> #SOURCE DEST PROVIDER PRIORITY<br> $SRC_A $DESTIP1 ISP1 1000<br> $SRC_A $DESTIP2 SOMEISP 1000<br> $SRC_A - ISP2 1000<br><br> The reason for this omission was that Shorewall uses a<br> delete-before-add approach and attempting to delete the third rule<br> resulted in the deletion of the first one instead. <br><br> This problem occurred with both compilers.<br><br>3) When using Shorewall-shell, provider numbers were not recognized in<br> the PROVIDER column of /etc/shorewall/route_rules.</pre>
<pre>Problems Corrected in Shorewall 4.0.4<br><br>1) If no interface had the 'blacklist' option, then when using<br> Shorewall-perl, the 'start' and 'restart' command failed:<br><br> ERROR: No filter chain found with name blacklst<br><br> New Shorewall-perl 4.0.3 packages were released that corrected this<br> problem; it is included here for completeness.<br><br>2) If no interface had the 'blacklist' option, then when using<br> Shorewall-perl, the generated script would issue this harmless<br> message during 'shorewall refresh':<br><br> chainlist_reload: Not found<br><br>3) If /bin/sh was a light-weight shell such as ash or dash, then<br> 'shorewall refresh' failed.<br><br>4) During start/restart, the script generated by Shorewall-perl was<br> clearing the proxy_arp flag on all interfaces; that is not the<br> documented behavior.<br><br>5) If the module-init-tools package was not installed and<br> /etc/shorewall/modules did not exist or was non-empty, then<br> Shorewall-perl would fail with the message:<br><br> ERROR: Can't run lsmod : /etc/shorewall/modules (line 0)<br><br>6) Shorewall-perl now makes a compile-time check to insure that<br> iptables-restore exists and is executable. This check is made when<br> the compiler is being run by root and the -e option is not<br> given.<br><br> Note that iptables-restore must reside in the same directory as the<br> iptables executable specified by IPTABLES in shorewall.conf or<br> located by the PATH in the event that IPTABLES is not specified.<br><br>7) When using Shorewall-perl, if an action was invoked with more than<br> 10 different combinations of log-levels/tags, some of those<br> invocations would have incorrect logging.<br><br>8) Previously, when 'shorewall restore' was executed, the<br> iptables-restore utility was always located using the PATH setting<br> rather than the IPTABLES setting.<br><br> With Shorewall-perl, the IPTABLES setting is now used to locate<br> this utility during 'restore' as it is during the processing of<br> other commands.<br><br>9) Although the shorewall.conf manpage indicates that the value<br> 'internal' is allowed for TC_ENABLED, that value was previously<br> rejected ('Internal' was accepted).<br><br>10) The meaning of the 'loose' provider option was accidentally reversed<br> in Shorewall-perl. Rather than causing certain routing rules to be<br> omitted when specified, it actually caused them to be added (these<br> rules were omitted when the option was NOT specified).<br><br>11) If the 'bridge' option was specified on an interface but there were<br> no bport zones, then traffic originating on the firewall was not<br> passed through the accounting chain.<br><br>12) In commands such as:<br><br> shorewall compile <directory><br> shorewall restart <directory><br> shorewall check <directory><br><br> if the name of the <directory> contained a period ("."), then<br> Shorewall-perl would incorrectly substitute the current working<br> directory for the name.<br><br>13) Previously, if the following sequence of routing rules was<br> specified, then the first rule would always be omitted.<br><br> #SOURCE DEST PROVIDER PRIORITY<br> $SRC_A $DESTIP1 ISP1 1000<br> $SRC_A $DESTIP2 SOMEISP 1000<br> $SRC_A - ISP2 1000<br><br> The reason for this omission was that Shorewall uses a<br> delete-before-add approach and attempting to delete the third rule<br> resulted in the deletion of the first one instead. <br><br> This problem occurred with both compilers.<br><br>14) When using Shorewall-shell, provider numbers were not recognized in<br> the PROVIDER column of /etc/shorewall/route_rules.<br><br>15) An off-by-one problem in Shorewall-perl caused the value 255 to be<br> rejected in the MARK column of /etc/shorewall/tcclasses.<br><br>16) When HIGH_ROUTE_MARKS=Yes, marks with values > 255 must be a<br> mu
<pre>Problems Corrected in 4.0.3<br><br>1) Using the LOG target in the rules file could result in two LOG<br> rules being generated by Shorewall-shell. Additionally, using an IP<br> address range in a rule that performed logging could result in an<br> invalid iptables command.<br><br>2) Shorewall now loads the act_police kernel module needed by traffic<br> shaping.<br><br>3) Previously, "shorewall show -f capabilities" and "shorecap" omitted<br> the "TCPMSS Match" capability. This made it appear to a compiler<br> using a capabilities file that the TCPMSS Match capability was not<br> available.<br><br>4) Previously, Shorewall would truncate long log prefixes to 29<br> characters. This resulted in there being no space between the log<br> prefix and the IN= part of the message.<br><br> Example: fw2net:LOG:HTTPSoutIN= OUT=eth0<br><br> Beginning with this release, Shorewall will truncate the prefix to<br> 28 bytes and add a trailing space.<br><br> Example: fw2net:LOG:HTTPSou IN= OUT=eth0<br><br>5) Previously, if:<br><br> - FASTACCEPT=No<br> - The policy from Z1 to Z2 was CONTINUE<br> - Neither Z1 nor Z2 had parent zones<br> - There were no Z1->Z2 rules<br><br> then connections from Z2->Z1 would fail even if there were<br> rules/policies allowing them. This has been<br> corrected.<br><br>6) The 'shorewall add' and 'shorewall delete' command would fail when:<br><br> - The running configuration was compiled with Shorewall-perl.<br> - The name of the interface specified in the command contained an<br> embedded special character such as '.' or '-'.<br><br> This problem was the result of the change in Shorewall 4.0.2 that<br> removed the legacy mapping of interface names when embedding such<br> names in a Netfilter chain name. To correct the problem, the<br> pre-4.0.2 name mapping is restored when DYNAMIC_ZONES=Yes.<br><br>5) A bug in Shorewall-shell prevented proper handling of PREROUTING<br> marks when HIGH_ROUTE_MARKS=No and the track option was specified<br> in /etc/shorewall/providers.<br><br>6) With Shorewall-perl, if EXPORTPARAMS=Yes then INCLUDE directives in<br> the params file would fail at script execution time with "INCLUDE:<br> not found". This has been corrected.<br><br>7) Shorewall-perl was mis-sorting the zone list when zones were nested<br> more than one deep.<br><br>8) Stale references to http://www.shorewall.net/Documentation.htm have<br> been removed from the config files (including samples). That URL<br> has been replaced by the online manpages.<br><br>Other Changes in 4.0.3<br><br>1) A script generated by Shorewall-perl now tries to modify/restore<br> /etc/iproute2/rt_tables only if the file is writable. This prevents<br> run-time errors when /etc is mounted read-only.<br><br> A new KEEP_RT_TABLES option has been added to shorewall.conf. When<br> set to Yes, this option prevents Shorewall from altering the<br> /etc/iproute2/rt_tables database. The KEEP_RT_TABLES option is only<br> recognized by Shorewall-perl and is ignored by Shorewall-shell.<br><br>2) Shorewall-perl now requires the FindBin Perl module.<br><br>3) When an optional provider is not available, a script generated by<br> Shorewall-perl will no longer add the corresponding<br> routing rules.<br><br>4) A new 'isusable' extension script has been added. This script<br> allows you to extend the availability test that Shorewall performs<br> on optional providers.<br><br> Here's an example that uses ping to ensure that the default<br> gateways through eth0 and eth1 are reachable:<br><br> case $1 in<br> eth0)<br> ping -c 4 -I eth0 206.124.146.254 > /dev/null 2>&1<br> return<br> ;;<br> eth1)<br> ping -c 4 -I eth1 192.168.12.254 > /dev/null 2>&1<br> return<br> ;;<br> *)<br> # Assume we don't need to do any additional testing<br> # for this interface beyond Shorewall's<br>
<pre>Problems Corrected in 3.4.6.<br><br>1) If the "Mangle FORWARD Chain" capability was supported, entries in<br> the /etc/shorewall/ecn file would cause invalid iptables<br> commands to be generated.<br><br>2) Certain errors occurring during<br> start/restart/safe-start/safe-restart/try processing could cause<br> the lockfile to be left behind. This resulted in a 60-second delay<br> the next time one of these commands was run.<br><br>3) It was not previously possible to define traffic shaping on a<br> bridge port; the generated script complained that the<br> interface was not up and configured.<br><br>4) Previously, using a port list in the DEST PORT(S) column of the<br> rules file or in an action file caused an invalid iptables command<br> to be generated.<br><br>5) Using the LOG target in the rules file could result in two LOG<br> rules being generated. Additionally, using an IP address range in a<br> rule that performed logging could result in an invalid iptables<br> command.<br><br>6) Shorewall now loads the act_police kernel module needed by traffic<br> shaping.<br><br>7) Previously, "shorewall show -f capabilities" and "shorecap" omitted<br> the "TCPMSS Match" capability. This made it appear to a compiler<br> using a capabilities file that the TCPMSS Match capability was not<br> available.<br><br>8) Previously, Shorewall would truncate long log prefixes to 29<br> characters. This resulted in there being no space between the log<br> prefix and the IN= part of the message.<br><br> Example: fw2net:LOG:HTTPSoutIN= OUT=eth0<br><br> Beginning with this release, Shorewall will truncate the prefix to<br> 28 bytes and add a trailing space.<br><br> Example: fw2net:LOG:HTTPSou IN= OUT=eth0<br><br>9) Previously, if:<br><br> - FASTACCEPT=No<br> - The policy from Z1 to Z2 was CONTINUE<br> - Z1 and Z2 were orphans (neither had parent zones)<br> - There were no Z1->Z2 rules<br><br> then connections from Z2->Z1 would fail even if there were<br> rules/policies allowing them. This has been<br> corrected. <br><br>Other changes in 3.4.6.<br><br>1) Processing of the message log in the 'show log', 'logwatch' and<br> 'dump' commands has been speeded up thanks to a suggestion by<br> Andrew Suffield.</pre>
<pre>Problems corrected in 4.0.2<br><br>1) The Shorewall-perl compiler was still generating invalid<br> iptables-restore input from entries in /etc/shorewall/ecn.<br><br>2) When using Shorewall-perl, unless an interface was specified as<br> 'optional' in the interfaces file, the 'restore' command would<br> fail if the routes through the interface or the addresses on the<br> interface could not be detected.<br><br> Route detection occurs when the interface is named in the SOURCE<br> column of the masq file. Address detection occurs when<br> DETECT_DNAT_IPADDRS=Yes and the interface is the SOURCE for a DNAT<br> or REDIRECT rule or when 'maclist' is specified for the interface.<br><br> Since the 'restore' command doesn't use the detected information,<br> detection is now skipped if the command is 'restore'.<br><br>3) It was not previously possible to define traffic shaping on a<br> bridge port; the generated script complained that the<br> interface was not up and configured.<br><br>4) When Shorewall-shell was not installed, certain options in<br> /etc/shorewall/interfaces and /etc/shorewall/hosts would cause the<br> 'add' and 'delete' commands to fail with a missing library error.<br><br> OPTION FILE<br> maclist interfaces,hosts<br> proxyarp interfaces<br><br>5) The /var/lib/shorewall/zones file was being overwritten during<br> processing of the 'refresh' command by a script generated with<br> Shorewall-perl. The result was that hosts previously added to<br> dynamic zones could not be deleted after the 'refresh'.<br><br>6) If the file named as the output file in a Shorewall-perl 'compile'<br> command was a symbolic link, the generated error message<br> erroneously stated that the file's parent directory was a symbolic<br> link.<br><br> As part of this change, cosmetic changes were made to a number of<br> other error messages.<br><br>7) Some intra-zone rules were missing when a zone involved multiple<br> interfaces or when a zone included both IPSEC and non-IPSEC<br> networks.<br><br>8) Shorewall was not previously loading the xt_multiport kernel<br> module.<br><br>9) The Russian and French translations no longer have English headings<br> on notes, cautions, etc..<br><br>10) Previously, using a port list in the DEST PORT(S) column of the<br> rules file or in an action file could cause an invalid iptables<br> command to be generated by Shorewall-shell.<br><br>11) If there were no bridges in a configuration, Shorewall-perl would<br> ignore the CHAIN column in /etc/shorewall/accounting.<br><br>Other changes in 4.0.2<br><br>1) Shorewall-perl now detects when a port range is included in a list<br> of ports and iptables/kernel support for Extended Multi-port Match<br> is not available. This avoids an iptables-restore failure at<br> run-time.<br><br>2) Most chains created by Shorewall-shell have names that can be<br> embedded within shell variable names. This is a workaround for<br> limitations in the shell programming language which has no<br> equivalent to Perl hashes. Often chain names must have the name of<br> a network interface encoded in them. Given that interface names can<br> contain characters that are invalid in a shell variable name,<br> Shorewall-shell performs a name mapping which was carried forward to<br> Shorewall-perl:<br><br> - Trailing '+' is dropped.<br> - The characters ".", "-", "%' and "@" are translated to "_".<br><br> This mapping has been elminated in the 4.0.2 release of Shorewall-<br> perl. So where before you would see chain "eth0_0_in", you may now<br> see the same chain named "eth0.0_in". Similarly, a chain previously<br> named "ppp_fwd" may now be called "ppp+_fwd".<br><br>3) Shorewall-perl now uses the contents of the BROADCAST column in<br> /etc/shorewall/interfaces when the Address Type match capability is<br> not available.</pre>
<pre>Problems corrected in 4.0.1.<br><br>1) The Shorewall Lite installer was producing an empty shorewall-lite<br> manpage. Since the installer runs as part of creating the RPM, the<br> RPM also suffered from this problem. The 4.0.0 Shorewall-lite <br> packages were re-uploaded with this problem corrected.<br><br>2) The Shorewall Lite uninstaller incorrectly removed /sbin/shorewall<br> rather than /sbin/shorewall-lite.<br><br>3) Both the Shorewall and Shorewall Lite uninstallers did a "shorewall<br> clear" if Shorewall [Lite] was running. Now, the Shorewall Lite<br> uninstaller correctly does "shorewall-lite clear" and both<br> uninstallers only perform the 'clear' operation if the other<br> product is not installed. This prevents the removal of one of the<br> two products from clearing the firewall configuration established<br> by the other one.<br><br>4) The 'ipsec' OPTION in /etc/shorewall/hosts was mis-handled by<br> Shorewall-perl. If the zone type was changed to 'ipsec' or<br> 'ipsec4' and the 'ipsec' option removed from the hosts file entry,<br> the configuration worked properly.<br><br>5) If a CLASSID was specified in a tcrule and TC_ENABLED=No, then<br> Shorewall-perl produced the following:<br><br> Compiling...<br> Use of uninitialized value in string ne at /usr/share/shorewall-perl/Shorewall/Tc.pm line 285, <$currentfile> line 18.<br> ERROR: Class Id n:m is not associated with device eth0 : /etc/shorewall/tcrules (line 18)<br><br>6) If IPTABLES was not specified in shorewall.conf, Shorewall-perl was<br> locating the binary using the PATH environmental variable rather<br> than the PATH setting in shorewall.conf. If no PATH was available<br> when Shorewall-perl was run and IPTABLES was not set in<br> shorewall.conf, the following messages were issued:<br><br> Use of uninitialized value in split at /usr/share/shorewall-perl/Shorewall/Config.pm line 1054.<br> ERROR: Can't find iptables executable<br> ERROR: Shorewall restart failed<br><br>7) If the "Mangle FORWARD Chain" capability was supported, entries in<br> the /etc/shorewall/ecn file would cause invalid iptables commands<br> to be generated. This problem occurred with both compilers.<br><br>8) Shorewall now starts at reboot after an upgrade from shorewall <<br> 4.0.0. Previously, Shorewall was not started automatically at<br> reboot after an upgrade using the RPMs.<br><br>9) Shorewall-perl was generating invalid iptables-restore input when a<br> log level was specified with the dropBcast and allowBcast builtin<br> actions and when a log level followed by '!' was used with any<br> builtin actions.<br><br>10) Shorewall-perl was incorrectly rejecting 'min' as a valid unit of<br> time in rate-limiting specifications.<br><br>11) Certain errors occurring during<br> start/restart/safe-start/safe-restart/try processing could cause<br> the lockfile to be left behind. This resulted in a 60-second delay<br> the next time one of these commands was run.<br><br>Other changes in Shorewall 4.0.1.<br><br>1) A new EXPAND_POLICIES option is added to shorewall.conf. The<br> option is recognized by Shorewall-perl and is ignored by<br> Shorewall-shell.<br><br> Normally, when the SOURCE or DEST columns in shorewall-policy(5)<br> contains 'all', a single policy chain is created and the policy is<br> enforced in that chain. For example, if the policy entry is<br><br> #SOURCE DEST POLICY LOG<br> # LEVEL<br> net all DROP info<br><br> then the chain name is 'net2all' which is also the chain named in<br> Shorewall log messages generated as a result of the policy. If<br> EXPAND_POLICIES=Yes, then Shorewall-perl will create a separate<br> chain for each pair of zones covered by the policy. This makes the<br> resulting log messages easier to interpret since the chain in the<br> messages will have a name of the form 'a2b' where 'a' is the SOURCE<br> zone and 'b' i
<pre>----------------------------------------------------------------------------<br> R E L E A S E H I G H L I G H T S<br>----------------------------------------------------------------------------<br>1) This is the first Shorewall release that fully integrates the new<br> Shorewall-perl compiler. See the "New Features" section below.<br><br>2) You are now offered a choice as to which compiler(s) you install. In<br> 4.0.0, there are the following packages:<br><br> - Shorewall-common ( common files )<br> - Shorewall-shell ( the shell-based compiler )<br> - Shorewall-perl (the Perl-based compiler )<br><br> You must install at least one of the compiler packages (you may<br> install them both) along with Shorewall-common.<br><br> YOU DO NOT NEED TO UNINSTALL ANY OF YOUR CURRENT PACKAGES.<br><br> See the Migration Considerations below for further information.<br><br>3) The facilities for supporting bridge/firewalls under earlier<br> releases are deprecated and their documentation is omitted from the<br> 4.0 distribution. New bridge support is implemented in the<br> Shorewall-perl compiler. This support utilizes the reduced-function<br> physdev match support available in Linux kernel 2.6.20 and later.<br><br>Problems corrected in 4.0.0 Final.<br><br>1) The shorewall-lite install.sh may now be run multiple times from<br> the same directory. Previously, the manpages were gzipped in-place<br> which made it impossible to rerun the script.<br><br>2) If shorewall.conf contained SHOREWALL_COMPILER=shell (which it can<br> on Shorewall 3.4.2-4 systems) and the shorewall-shell RPM was<br> removed, subsequent "shorewall [re]start" operations failed. When<br> shorewall-shell is removed, the shorewall.conf file is modified to<br> specify SHOREWALL_COMPILER= and the original is saved in<br> shorewall.conf.rpmsave.<br><br>3) The contents of the LOG LEVEL column in /etc/shorewall/policy are<br> now validated at compile time by Shorewall-perl.<br><br>Other changes in Shorewall 4.0.0 Final.<br><br>1) The Perl modules in /usr/share/shorewall-perl/Shorewall/ have been<br> consolidated somewhat, leading to slightly faster compilation.<br><br>Migration Considerations:<br><br>1) Beginning with Shorewall 4.0.0, there is no single 'shorewall'<br> package. Rather there are two compiler packages (shorewall-shell<br> and shorewall-perl) and a set of base files (shorewall-common)<br> which are required by either compiler package.<br><br> Although the names of the packages are changing, you can upgrade<br> without having to uninstall/reinstall.<br><br> To repeat: YOU DO NOT NEED TO UNINSTALL ANY EXISTING PACKAGE.<br><br> If you attempt to upgrade using the shorewall-common RPM, you get<br> this result:<br> gateway:~ # rpm -Uvh shorewall-common-4.0.0.noarch.rpm <br> error: Failed dependencies:<br> shorewall_compiler is needed by shorewall-common-4.0.0-1.noarch<br> gateway:~ #<br><br> You must either:<br><br> rpm -Uvh shorewall-shell-4.0.0.noarch.rpm \<br> shorewall-common-4.0.0.noarch.rpm<br><br> or<br><br> rpm -Uvh shorewall-shell-4.0.0.noarch.rpm \<br> shorewall-perl-4.0.0.noarch.rpm \<br> shorewall-common-4.0.0.noarch.rpm<br><br> If you don't want to use shorewall-perl exclusively then use the<br> second command above then<br><br> rpm -e shorewall-shell<br><br> If you are upgrading using the tarball, you must install <br> shorewall-shell and/or shorewall-perl before you upgrade<br> using shorewall-common. Otherwise, the install.sh script fails with:<br><br> ERROR: No Shorewall compiler is installed<br><br> The shorewall-shell and shorewall-perl packages are installed from<br> the tarball in the expected way; untar the package, and run the<br> install.sh script.<br><br> Example 1: You have 'shorewall' installed and you want to continue<br> to use the shorewall-shell compiler.<br><br> tar -jxf shorewall-common-4.0.0.tar.bz2<br>
<pre>Problems Corrected in 3.4.5.<br><br>1) DYNAMIC_ZONES=Yes can now coexist with Shorewall-perl's 'bport'<br> zones. Those zones themselves may not be dynamically modified but<br> the presence of bport zones no longer causes the 'shorewall add'<br> command to fail.<br><br>2) Shorewall's internal traffic shaper once again works when the 'sed'<br> utility is provided by the Busybox package.<br><br>3) Version 3.4.4 erroneously accepted the values On, Off, on, off, ON<br> and OFF for the IP_FORWARDING option. These values were treated<br> like 'Keep'. The listed values are now once again flagged as an<br> error.<br><br>4) If 'routeback' and 'detectnets' were specified on an interface,<br> limited broadcasts (to 255.255.255.255) and multicasts were dropped<br> when forwarded through the interface. This could cause<br> broadcast-based and multicast applications to fail when running<br> through a bridge with 'detectnets'.<br><br>5) The 'hits' command works once again.<br><br>6) IPSECFILE=ipsec (either explicitly or defaulted) works<br> now. Previously, processing of the ipsec file was bypassed; often<br> with a confusing "missing file" message.<br><br>7) If DETECT_DNAT_IPADDRS=Yes in shorewall.conf but you did't have conntrack<br> match support, then the generated script was missing 'done's.<br><br>Other changes in 3.4.5.<br><br>1) When a Shorewall release includes detection of an additional<br> capability, existing capabilities files become out of<br> date. Previously, this condition was not detected.<br><br> Beginning with this release, each generated capabilities file<br> contains a CAPVERSION specification which defines the capabilities<br> version of the file. If the CAPVERSION in a capabilities file is<br> less than the current CAPVERSION, then Shorewall will issue the<br> following message:<br><br> WARNING: <file> is out of date -- it does not contain all of<br> the capabilities defined by Shorewall version <version><br><br> where<br><br><file> is the name of the capabilities file.<br><version> is the current Shorewall version.<br><br> Existing capabilities files contain no CAPVERSION. When such a file<br> is read, Shorewall will issue this message:<br><br> WARNING: <file> may be not contain all of the capabilities defined<br> by Shorewall version <version><br><br>2) When a directory is specified in a command such as 'start' or<br> 'compile', Shorewall now reads the shorewall.conf file (if any) in<br> that directory before deciding which compiler to use. So if<br> SHOREWALL_COMPILER is not specified in<br> /etc/shorewall/shorewall.conf and the -C option was not specified<br> on the run-line, then if Shorewall-perl is installed, the additional<br> shorewall.conf file is read to see if it specifies a<br> SHOREWALL_COMPILER.<br><br>3) The 'save' command now uses iptables-save from the same directory<br> containing iptables. Previously, iptables-save was located via the<br> PATH setting.</pre>
<pre>Problems corrected in 3.4.4:<br><br>1) The commands "shorewall add <interface><zone>" and "shorewall<br> delete <interface><zone>" no longer produce spurious error<br> messages.<br><br>2) The command "shorewall delete <interface><zone>" now actually deletes<br> entries when it successfully completes. Previously, it would appear<br> to remove an entry, even when removing that entry should fail. <br><br>3) Setting HIGH_ROUTE_MARKS=No no longer causes TC_EXPERT flagging.<br><br>4) When run as root, the 'shorewall load' and 'shorewall reload'<br> commands would fail if the LOGFILE setting in<br> /etc/shorewall/shorewall.conf specified a non-existant file.<br><br>5) Entries in /etc/shorewall/tcrules that specify both a source and<br> destination port fail with the following diagnostic:<br><br> iptables v1.3.3: multiport can only have one option<br><br>6) Previously, Shorewall-lite did not allow DHCP traffic through an<br> interface when the interface was a bridge with 'dhcp' specified<br> unless there was a bridge on the administrative system with the<br> same name.<br><br>7) SOURCE and DEST are now flagged as invalid zone name to avoid<br> problems with macros that use those names as keywords.<br><br>8) Previously, Shorewall could *increase* the MSS under some<br> circumstances. This possibility is now eliminated, provided that<br> the system has TCPMSS match support (be sure to update your<br> capabilities files!).<br><br>9) Firewall zone names other than 'fw' no longer cause a error when<br> IPSECFILE is not set or is set to 'ipsec'.<br><br>10) The 'proxyarp' option on an interface was previously ignored when<br> the /etc/shorewall/proxyarp file was empty.<br><br>11) Previously, if action 'a' was defined then the following <br> rule generated an error:<br><br> a: z1 z2 ...<br><br> The trailing ":" is now ignored.<br><br>12) Previously, if a RATE/LIMIT was specified on a REJECT rule, the<br> generated error messages referred to the rule as a DROP rule.<br><br>13) The 'nolock' keyword was previously ignored on several<br> /sbin/shorewall[-lite] commands. <br><br>Other changes in 3.4.4:<br><br>1) The accounting, masq, rules and tos files now have a 'MARK' column<br> similar to the column of the same name in the tcrules file. This<br> column allows filtering by MARK value.<br><br>2) The "shorewall show zones" command now flags zone members that have<br> been added using "shorewall add" by preceding them with a plus sign<br> ("+").<br><br> Example:<br><br> Shorewall 3.9.4 Zones at gateway - Mon May 14 07:48:16 PDT 2007<br><br> fw (firewall)<br> net (ipv4)<br> eth0:0.0.0.0/0<br> loc (ipv4)<br> br0:0.0.0.0/0<br> eth4:0.0.0.0/0<br> eth5:0.0.0.0/0<br> +eth1:0.0.0.0/0<br> dmz (ipv4)<br> eth3:0.0.0.0/0<br> vpn (ipv4)<br> tun+:0.0.0.0/0<br><br> In the above output, "eth1:0.0.0.0/0" was dynamically added to the<br> 'loc' zone. As part of this change, "shorewall delete" will only<br> delete entries that have been added dynamically. In earlier<br> versions, any entry could be deleted although the ruleset was only<br> changed by deleting entries that had been added dynamically.<br><br>3) Eariler generations of Shorewall Lite required that remote root<br> login via ssh be enabled in order to use the 'load' and 'reload'<br> commands.<br><br> Beginning with this release, you may define an alternative means<br> for accessing the remote firewall system.<br><br> Two new options have been added to shorewall.conf:<br><br> RSH_COMMAND<br> RCP_COMMAND<br><br> The default values for these are as follows:<br><br> RSH_COMMAND: ssh ${root}@${system} ${command}<br> RCP_COMMAND: scp ${files} ${root}@${system}:${destination}<br><br> Shell variables that will be set when the commands are envoked are<br> as follows:<br><br> root - root user. Normally 'root' but ma
<hr>
<p><strong>2007-06-12 New Host for www.shorewall.net and
ftp.shorewall.net</strong></p>
<pre>I'm pleased to announce that Ty Christiansen and the folks at Master Mind<br>Productions (http://mastermindpro.com) have volunteered to host<br>www.shorewall.net and ftp.shorewall.net.<br><br>The new site is up and running and I've just changed DNS to point to the new<br>server. Let me know if you experience any problems.<br><br>Please join me in thanking Ty and Master Mind for their support of the<br>Shorewall project.</pre>
<pre>Problems Corrected in 3.2.10<br><br>1) Previously, if a 'start' or 'restart' command failed during the<br> compilation step, /sbin/shorewall erroneously returned an exit<br> status of zero.<br><br>2) If IMPLICIT_CONTINUE=Yes was in effect, then sub-zones received the<br> implicit CONTINUE policy for their intra-zone traffic (rather than<br> the implicit ACCEPT policy for such traffic). This could cause<br> intra-zone traffic to be rejected by rules in one of the parent<br> zones.<br><br>3) The "shorewall-[lite] [re]start and stop" commands reset the<br> proxy_arp flag on all interfaces on the system making it impossible<br> to control proxy arp manually with Shorewall installed. With this<br> change, shorewall will only clear proxy arp if there were entries in<br> /etc/shorewall/proxyarp the last time that Shorewall was<br> [re]started.<br><br>4) The /usr/share/shorewall[-lite]/modules file has been updated for<br> kernel 2.6.20.<br><br>5) The /proc/net/ip_conntrack pseudo-file has been inexplicably<br> renamed /proc/net/nf_conntrack in kernel 2.6.20. The lib.cli<br> library has been updated to look for both files.<br><br>6) Tunnels of type 'ipsecnat' failed to work properly due to a missing<br> rule.<br><br>7) The 'shorecap' program was not loading modules correctly. <br><span
<pre>Problems corrected in Shorewall 3.4.2<br><br>1) The /usr/share/shorewall[-lite]/modules file has been updated for<br> kernel 2.6.20.<br><br>2) The /proc/net/ip_conntrack pseudo-file has been inexplicably<br> renamed /proc/net/nf_conntrack in kernel 2.6.20. The lib.cli<br> library has been updated to look for both files.<br><br>3) Shoreall 3.4 was not consistent with respect to its treatment of<br> log level 'none' and 'none!' and built-in actions. In particular,<br> specifying 'none' with the Limit action produced a run-time error.<br> Shorewall now correctly suppresses generation of log messages when<br> a log level of 'none' or 'none!' is given to a built-in action.<br><br>4) Tunnels of type 'ipsecnat' would sometimes fail to work because of<br> a missing rule.<br></pre>
<pre>Problems Corrected in 3.4.1<br><br>1) The "shorewall-[lite] [re]start and stop" commands reset the<br> proxy_arp flag on all interfaces on the system making it impossible<br> to control proxy arp manually with Shorewall installed. There was a<br> partial fix included in 3.4.0; unfortunately, it did not correct the<br> problem completely. Shorewall 3.4.1 includes the rest of the change <br> necessarey to only clear proxy arp if there were entries in<br> /etc/shorewall/proxyarp the last time that Shorewall was<br> [re]started.<br><br>2) If the log-prefix in a log message exceeded 29 characters, <br> 'shorewall restart' fails with 'truncate: command not found' and a<br> possible segmentation fault in iptables.<br><br>3) Log messages specifying a log tag had two spaces appended to the<br> log prefix. This could cause mysterious "log-prefix truncated"<br> messages. <br><br>4) When nested zones were defined in the /etc/shorewall/zones file and<br> IMPLICIT_CONTINUE=Yes was given in /etc/shorewall/shorewall.conf,<br> shell error messages ( usually '<zone>: not found' ) during<br> compilation resulted.<br><br>5) Use of CONTINUE policies lead to startup errors with a message<br> such as the following:<br><br> Applying Policies...<br> iptables v1.3.7: Couldn't load target<br> `CONTINUE':/usr/local/lib/iptables/libipt_CONTINUE.so: cannot open<br> shared object file: No such file or directory<br><br> Try `iptables -h' or 'iptables --help' for more information.<br><br> ERROR: Command "/sbin/iptables -A net2c148 -j CONTINUE"<br> Failed<br><br>6) If there were hosts defined as 'critical' in<br> /etc/shorewall/routestopped then problems occured in two cases:<br><br> i) On a Shorewall Lite system when 'shorewall stop' or 'shorewall<br> clear' was issued.<br><br> ii) On Shorewall or Shorewall lite system when 'start' or 'restart'<br> failed during execution of the compiled script and there was no saved<br> configuration ('shorewall[-lite] save' has not been issued).<br><br> The symptoms were that the following shell messages were issued and<br> the 'critical' hosts were not enabled:<br><br> /var/lib/shorewall/.start: line nnn: source_ip_range: command not found<br> /var/lib/shorewall/.start: line nnm: dest_ip_range: command not found<br><br>Other changes in 3.4.1<br><br>1) Several changes are included which allow testing of experimental<br> versions of Shorewall on systems with 3.4.1 and later 3.4 releases<br> installed. Among these changes is the detection and reporting of<br> "Address Type Match" which may be used in future 3.4 releases.<br> These changes have no effect on normal Shorewall operation. </pre>
<pre>Shorewall 3.4.0<br><br>Release Highlights<br><br>1) Shorewall can now be tailored to reduce its footprint on embedded<br> systems. As part of this change, actions are now completely<br> optional.<br><br> See http://www.shorewall.net/Modularization.html for details.<br><br>2) Exclusion is now possible in /etc/shorewall/hosts. This is required<br> for bridge/firewalls under kernel 2.6.20 and later.<br><br> See http://www.shorewall.net/NewBridge.html.<br><br>3) Shorewall and Shorewall Lite now include man pages. There is a <br> man page for shorewall(8), one for shorewall-lite(8) and one for<br> each configuration file. As part of this change, all documentation<br> has been removed from Shorewall configuration files. This should<br> make it easier from users to upgrade from one release to the next<br> since the configuration files will only change when column is added<br> or renamed.<br><br> See http://www.shorewall.net/manpages/Manpages.html<br><br>4) Shorewall now remembers the changes that it has made to routing as<br> a result of entries in /etc/shorewall/providers and<br> /etc/shorewall/route_rules and reverses those changes when<br> appropriate.<br><br>Problems Corrected in 3.4.0 Final.<br><br>1) In the rules file, following the action with "!" is supposed to<br> exempt the rule from being suppressed by OPTIMIZE=1. That feature<br> was not working.<br><br>2) If both a macro body and a macro invocation contained an entry in the<br> SOURCE or DEST column, then compilation failed with the error:<br><br> merge_macro_source_dest: command not found<br><br>3) An obscure bug in rule activation having to do with the new<br> exclusion feature in /etc/shorewall/hosts has been corrected.<br><br>4) The "shorewall-[lite] [re]start and stop" commands reset the<br> proxy_arp flag on all interfaces on the system making it impossible<br> to control proxy arp manually with Shorewall installed. With this<br> change, shorewall will only clear proxy arp if there were entries in<br> /etc/shorewall/proxyarp the last time that Shorewall was<br> [re]started.<br><br>New Features in Shorewall 3.4:<br><br>1) In order to accomodate small embedded applications, Shorewall 3.4<br> is now modularized. In addition to the base files, there are<br> loadable "libraries" that may be included or omitted from an<br> embedded system as required.<br><br> Loadable Shorewall libraries reside in /usr/share/shorewall/ and<br> have names that begin with "lib.". The following libraries are<br> included in Shorewall 3.4:<br><br> - lib.accounting. Must be available if you include entries in<br> /etc/shorewall/accounting.<br><br> - lib.actions. Must be available if you do not specify<br> USE_ACTIONS=No in /etc/shorewall/shorewall.conf.<br><br> - lib.base. The base Shorewall library required by all programs,<br> including compiled firewall scripts. This library is also<br> released as part of Shorewall Lite and is installed in<br> /usr/share/shorewall-lite/.<br><br> - lib.cli. Library containing the code common to /sbin/shorewall,<br> /sbin/shorewall-lite. This library is also released as part of<br> Shorewall Lite and is installed in /usr/share/shorewall-lite/.<br><br> - lib.config. Library containing the code that is common to<br> /usr/share/shorewall/compiler and /usr/share/shorewall/firewall. <br><br> - lib.dynamiczones. Must be available if you specify<br> DYNAMIC_ZONES=Yes in shorewall.conf.<br><br> - lib.maclist. Must be available if you specify the 'maclist'<br> option in /etc/shorewall/interfaces or /etc/shorewall/hosts.<br><br> - lib.nat. Must be available if you have entries in<br> /etc/shorewall/masq, /etc/shorewall/nat or /etc/shorewall/netmap<br> or if you use DNAT or REDIRECT rules.<br><br> - lib.providers. Must be available if you have entries in<br> /etc/shorewall/providers.<br><br> - lib.proxyarp. Must be available if you have entries in<br> /etc/
