holm/shorewall_code
1
0
Fork 0
forked from extern/shorewall_code
Code Pull Requests Activity
cd512d2779
shorewall_code/Shorewall2/releasenotes.txt
teastep 8933f61524 Add QUEUE policies 
git-svn-id: https://shorewall.svn.sourceforge.net/svnroot/shorewall/trunk@2016 fbd18981-670d-0410-9b5c-8dc0c1a9a2bb
2005-03-30 15:08:37 +00:00

847 lines
29 KiB
Plaintext
Executable File
Raw Blame History

Shorewall 2.2.3
-----------------------------------------------------------------------
Problems corrected in version 2.2.3
1) If a zone is defined in /etc/shorewall/hosts using
<interface>:!<network> in the HOSTS column then startup errors occur
on "shorewall [re]start".
-----------------------------------------------------------------------
New Features in version 2.2.3
1) A new extension script "continue" has been added. This script is
invoked after Shorewall has set the built-in filter chains'
policy to DROP, deleted any existing Netfilter rules and user
chains and has enabled existing connections.
It is useful for enabling certain communication while Shorewall is
being [re]started. Be sure to delete any rules that you add here in
your /etc/shorewall/start file.
2) There has been ongoing confusion about how the
/etc/shorewall/routestopped file works. People understand how it
works with the 'shorewall stop' command but when they read that
'shorewall restart' is logically equivalent to 'shorewall stop'
followed by 'shorewall start' then they erroneously conclude that
/etc/shorewall/routestopped can be used to enable new connections
during 'shorewall restart'. Up to now, it cannot -- that file is not
processed during either 'shorewall start' or 'shorewall restart'.
Beginning with Shorewall version 2.2.3, /etc/shorewall/routestopped
will be processed TWICE during 'shorewall start' and during
'shorewall restart'. It will be processed early in the command
execution to add rules allowing new connections while the command
is running and it will be processed again when the
command is complete to remove the rules added earlier.
The result of this change will be that during most of [re]start, new
connections will be allowed in accordance with the contents of
/etc/shorewall/routestopped.
3) The performance of configurations with a large numbers of entries in
/etc/shorewall/maclist can be improved by setting the new
MACLIST_TTL variable in /etc/shorewall/shorewall.conf.
If your iptables and kernel support the "Recent Match" (see the
output of "shorewall check" near the top), you can cache the results
of a 'maclist' file lookup and thus reduce the overhead associated
with MAC Verification.
When a new connection arrives from a 'maclist' interface, the packet
passes through then list of entries for that interface in
/etc/shorewall/maclist. If there is a match then the source IP
address is added to the 'Recent' set for that interface. Subsequent
connection attempts from that IP address occuring within
$MACLIST_TTL seconds will be accepted without having to scan all
of the entries. After $MACLIST_TTL from the first accepted
connection request from an IP address, the next connection request
from that IP address will be checked against the entire list.
If MACLIST_TTL is not specified or is specified as empty (e.g,
MACLIST_TTL="" or is specified as zero then 'maclist' lookups
will not be cached.
4) You can now specify QUEUE as a policy and you can designate a
common action for QUEUE policies in /etc/shorewall/actions. This is
useful for sending packets to something like Snort Inline.
-----------------------------------------------------------------------
Problems corrected in version 2.2.2
1) The SOURCE column in the /etc/shorewall/tcrules file now allows IP
ranges (assuming that your iptables and kernel support ranges).
2) If A is a user-defined action and you have file /etc/shorewall/A
then when that file is invoked, the $TAG value may be incorrect.
3) Previously, if an iptables command generating a logging rule
failed, the Shorewall [re]start was still successful. This error
is now considered fatal and Shorewall will be either restored from
the last save (if any) or it will be stopped.
4) The port numbers for UDP and TCP were previously reversed in the
/usr/share/shorewall/action.AllowPCA file.
5) Previously, the 'install.sh' script did not update the
/usr/share/shorewall/action.* files.
6) Previously, when an interface name appeared in the DEST column of
/etc/shorewall/tcrules, the name was not validated against the set
of defined interfaces and bridge ports.
-----------------------------------------------------------------------
New Features in version 2.2.2
1) The SOURCE column in the /etc/shorewall/tcrules file now allows $FW
to be optionally followed by ":" and a host/network address or
address range.
2) Shorewall now clears the output device only if it is a
terminal. This avoids ugly control sequences being placed in files
when /sbin/shorewall output is redirected.
3) The output from 'arp -na' has been added to the 'shorewall status'
display.
4) The 2.6.11 Linux kernel and iptables 1.3.0 now allow port ranges
to appear in port lists handled by "multiport match". If Shorewall
detects this capability, it will use "multiport match" for port
lists containing port ranges. Be cautioned that each port range
counts for TWO ports and a port list handled with "multiport match"
can still specify a maximum of 15 ports.
As always, if a port list in /etc/shorewall/rules is incompatible
with "multiport match", a separate iptables rule will be generated
for each element in the list.
5) Traditionally, the RETURN target in the 'rfc1918' file has caused
'norfc1918' processing to cease for a packet if the packet's source
IP address matches the rule. Thus, if you have:
SUBNETS TARGET
192.168.1.0/24 RETURN
then traffic from 192.168.1.4 to 10.0.3.9 will be accepted even
though you also have:
SUBNETS TARGET
10.0.0.0/8 logdrop
Setting RFC1918_STRICT=Yes in shorewall.conf will cause such traffic
to be logged and dropped since while the packet's source matches the
RETURN rule, the packet's destination matches the 'logdrop' rule.
If not specified or specified as empty (e.g., RFC1918_STRICT="")
then RFC1918_STRICT=No is assumed.
WARNING: RFC1918_STRICT=Yes requires that your kernel and iptables
support 'Connection Tracking' match.
-----------------------------------------------------------------------
Problems corrected in version 2.2.1
1) The /etc/shorewall/policy file contained a misleading comment and
both that file and the /etc/shorewall/zones file lacked examples.
2) Shorewall previously used root's default umask which could cause
files in /var/lib/shorewall to be world-readable. Shorewall now uses
umask 0177.
3) In log messages produced by logging a built-in action, the packet
disposition was displayed incorrectly.
Example:
rejNotSyn:ULOG all all tcp
produces the log message:
Feb 12 23:57:08 server Shorewall:rejNotSyn:ULOG: ...
rather than
Feb 12 23:57:08 server Shorewall:rejNotSyn:REJECT: ...
3) The comments regarding built-in actions in
/usr/share/shorewall/actions.std have been corrected.
4) The /etc/shorewall/policy file in the LRP package was missing the
'all->all' policy.
-----------------------------------------------------------------------
Issues when migrating from Shorewall 2.0 to Shorewall 2.2:
1) Shorewall configuration files except shorewall.conf are now empty
(they contain only comments). If you wish to retain the defaults
in any of the following files, you should copy these files before
upgrading them then restore them after the upgrade:
/etc/shorewall/zones
/etc/shorewall/policy
/etc/shorewall/tos
2) The following builtin actions have been removed and have been
replaced by the new action logging implementation described in the
new features below.
logNotSyn
rLogNotSyn
dLogNotSyn
3) If shorewall.conf is upgraded to the latest version, it needs to be
modified to set STARTUP_ENABLED=Yes
4) The Leaf/Bering version of Shorewall was previously named:
shorwall-<version>.lrp
Beginning with 2.2, that file will now be named:
shorewall-lrp-<version>.tgz
Simply rename that file to 'shorwall.lrp' when installing it on your
LEAF/Bering system.
5) The ORIGINAL DEST column of the /etc/shorewall/rules file may no
longer contain a second (SNAT) address. You must use an entry in
/etc/shorewall/masq instead.
Example from Shorewall FAQ #1:
Prior to Shorewall 2.2:
/etc/shorewall/interfaces
loc eth1 detect routeback,...
/etc/shorewall/rules
DNAT loc loc:192.168.1.12 tcp 80 \
- 130.252.100.69:192.168.1.254
Shorewall 2.2 and Later:
/etc/shorewall/interfaces
loc eth1 detect routeback,...
/etc/shorewall/masq:
eth1 eth1 192.168.1.254 tcp 80
/etc/shorewall/rules:
DNAT loc loc:192.168.1.12 tcp 80 \
- 130.252.100.69
6) The 'logunclean' and 'dropunclean' options that were deprecated in
Shorewall 2.0 have now been removed completely.
7) A new IPTABLES variable has been added to shorewall.conf. This
variable names the iptables executable that Shorewall will use. The
variable is set to "/sbin/iptables". If you use the new
shorewall.conf, you may need to change this setting to maintain
compabibility with your current setup (if you use your existing
shorewall.conf that does not set IPTABLES then you should
experience no change in behavior).
8) The default port for OpenVPN tunnels has been changed from 5000 to
1194 to reflect the recent IANA allocation of that port for
OpenVPN.
-----------------------------------------------------------------------
New Features in Shorewall 2.2.0:
1) ICMP packets that are in the INVALID state are now dropped by the
Reject and Drop default actions. They do so using the new
'dropInvalid' builtin action. An 'allowInvalid' builtin action is
also provided which accepts packets in that state.
2) The /etc/shorewall/masq file INTERFACE column now allows additional
options.
Normally MASQUERADE/SNAT rules are evaluated after one-to-one NAT
rules defined in the /etc/shorewall/nat file. If you preceed the
interface name with a plus sign ("+") then the rule will be
evaluated before one-to-one NAT.
Examples:
+eth0
+eth1:192.0.2.32/27
Also, the effect of ADD_SNAT_ALIASES=Yes can be negated for an
entry by following the interface name by ":" but no digit.
Examples:
eth0:
eth1::192.0.2.32/27
+eth3:
3) Similar to 2), the /etc/shorewall/nat file INTERFACE column now allows
you to override the setting of ADD_IP_ALIASES=Yes by following the
interface name with ":" but no digit.
4) All configuration files in the Shorewall distribution with the
exception of shorewall.conf are now empty. In particular, the
/etc/shorewall/zones, /etc/shorewall/policy and /etc/shorewall/tos
files now have no active entries. Hopefully this will stop the
questions on the support and development lists regarding why the
default entries are the way they are.
5) Previously, including a log level (and optionally a log tag) on a
rule that specified a user-defined (or Shorewall-defined) action
would log all traffic passed to the action. Beginning with this
release, specifying a log level in a rule that specifies a user-
or Shorewall-defined action will cause each rule in the action to
be logged with the specified level (and tag).
The extent to which logging of action rules occurs is goverend by
the following:
a) When you invoke an action and specify a log level, only those
rules in the action that have no log level will be changed to log
at the level specified at the action invocation.
Example:
/etc/shorewall/action.foo:
ACCEPT - - tcp 22
bar:info
/etc/shorewall/rules:
foo:debug fw net
Logging in the invoked 'foo' action will be:
ACCEPT:debug - - tcp 22
bar:info
b) If you follow the log level with "!" then logging will
be at that level for all rules recursively invoked by the action
Example:
/etc/shorewall/action.foo:
ACCEPT - - tcp 22
bar:info
/etc/shorewall/rules:
foo:debug! fw net
Logging in the invoke 'foo' action will be:
ACCEPT:debug - - tcp 22
bar:debug!
This change has an effect on extension scripts used with
user-defined actions. If you define an action 'acton' and you have
an /etc/shorewall/acton script then when that script is invoked,
the following three variables will be set for use by the script:
$CHAIN = the name of the chain where your rules are to be
placed. When logging is used on an action invocation,
Shorewall creates a chain with a slightly different name from
the action itself.
$LEVEL = Log level. If empty, no logging was specified.
$TAG = Log Tag.
Example:
/etc/shorewall/rules:
acton:info:test
Your /etc/shorewall/acton file will be run with:
$CHAIN="%acton1"
$LEVEL="info"
$TAG="test"
6) The /etc/shorewall/startup_disabled file is no longer created when
Shorewall is first installed. Rather, the variable STARTUP_ENABLED
is set to 'No' in /etc/shorewall/shorewall.conf. In order to get
Shorewall to start, that variable's value must be set to
'Yes'. This change accomplishes two things:
a) It prevents Shorewall from being started prematurely by the
user's initialization scripts.
b) It causes /etc/shorewall/shorewall.conf to be modified so that
it won't be replaced by upgrades using RPM.
7) Some additional support has been added for the 2.6 Kernel IPSEC
implementation. To use this support, you must have installed the
IPSEC policy match patch and the four IPSEC/Netfilter patches
from Patch-0-Matic-ng. The policy match patch affects both your
kernel and iptables.
There are two ways to specify that IPSEC is to be used when
communicating with a set of hosts; both methods involve the new
/etc/shorewall/ipsec file:
a) If encrypted communication is used with all hosts in a zone,
then you can designate the zone as an "ipsec" zone by placing
'Yes" in the IPSEC ONLY column in the /etc/shorewall/ipsec:
#ZONE IPSEC OPTIONS ...
# ONLY
vpn Yes
The hosts in the zone (if any) must be specified in
/etc/shorewall/hosts but you do not need to specify the 'ipsec'
option on the entries in that file (see below).
Dynamic zones involving IPSEC must use that technique.
Example:
Under 2.4 Kernel FreeS/Wan:
/etc/shorewall/zones:
net Net The big bad Internet
vpn VPN Remote Network
/etc/shorewall/interfaces:
net eth0 ...
vpn ipsec0 ...
Under 2.6 Kernel with this new support:
/etc/shorewall/zones:
net Net The big bad Internet
vpn VPN Remote Network
/etc/shorewall/interfaces:
net eth0 ...
/etc/shorewall/hosts:
vpn eth0:0.0.0.0/0
/etc/shorewall/ipsec
vpn Yes
b) If only part of the hosts in a zone require encrypted
communication, you may use of the new 'ipsec' option in
/etc/shorewall/hosts to designate those hosts.
Example:
Under 2.4 Kernel FreeS/Wan:
/etc/shorewall/zones:
net Net The big bad Internet
loc Local Extended local zone
/etc/shorewall/interfaces:
net eth0 ...
loc eth1 ...
loc ipsec0 ...
Under 2.6 Kernel with this new support:
/etc/shorewall/zones:
net Net The big bad Internet
vpn VPN Remote Network
/etc/shorewall/interfaces:
net eth0 ...
loc eth1 ...
/etc/shorewall/hosts:
vpn eth0:0.0.0.0/0 ipsec,...
Regardless of which technique you choose, you can specify
additional SA options for the zone in the /etc/shorewall/ipsec
entry.
The OPTIONS, IN OPTIONS and OUT OPTIONS columns specify the
input-output, input and output characteristics of the security
associations to be used to decrypt (input) or encrypt (output) traffic
to/from the zone.
The available options are:
reqid[!]=<number> where <number> is specified using setkey(8) using
the 'unique:<number>' option for the SPD level.
spi[!]=<number> where <number> is the SPI of the SA. Since
different SAs are used to encrypt and decrypt traffic, this
option should only be listed in the IN OPTIONS and OUT OPTIONS
columns.
proto[!]=ah|esp|ipcomp
mss=<number> (sets the MSS value in TCP SYN packets and is not
related to policy matching)
mode[!]=transport|tunnel
tunnel-src[!]=<address>[/<mask>] (only available with mode=tunnel)
tunnel-dst[!]=<address>[/<mask>] (only available with
mode=tunnel). Because tunnel source and destination are
dependent on the direction of the traffic, these options
should only appear in the IN OPTIONS and OUT OPTIONS columns.
strict (if specified, packets must match all policies;
policies are delimited by 'next').
next (only available with strict)
Examples:
#ZONE IPSEC OPTIONS IN OUT...
# ONLY OPTIONS OPTIONS
vpn Yes mode=tunnel,proto=esp spi=1000 spi=1001
loc No reqid=44,mode=transport
The /etc/shorewall/masq file has a new IPSEC column added. If you
specify Yes or yes in that column then the unencrypted packets will
have their source address changed. Otherwise, the unencrypted
packets will not have their source addresses changed. This column
may also contain a comma-separated list of the options specified
above in which case only those packets that will be encrypted
by an SA matching the given options will have their source address
changed.
8) To improve interoperability, tunnels of type 'ipsec' no longer
enforce the use of source port 500 for ISAKMP and OpenVPN
tunnels no longer enforce use of the specified port as both the
source and destination ports.
9) A new 'allowBcast' builtin action has been added -- it silently
allows broadcasts and multicasts.
10) The -c option in /sbin/shorewall commands is now deprecated. The
commands where -c was previously allowed now permit you to specify
a configuration directory after the command:
shorewall check [ <configuration-directory> ]
shorewall restart [ <configuration-directory> ]
shorewall start [ <configuration-directory> ]
11) Normally, when SNAT or MASQUERADE is applied to a tcp or udp
connection, Netfilter attempts to retain the source port
number. If it has to change to port number to avoid
<source address>,<source port> conflicts, it tries to do so
within port ranges ( < 512, 512-1023, and > 1023). You may
now specify an explicit range of source ports to be used
by following the address or address range (if any) in the
ADDRESS column with ":" and a port range in the format
<low-port>-<high-port>. You must specify either "tcp" or
"udp" in the PROTO column.
Examples 1 -- MASQUERADE with tcp source ports 4000-5000:
#INTERFACE SUBNET ADDRESS PROTO
eth0 192.168.1.0/24 :4000-5000 tcp
Example 2 -- SNAT with udp source ports 7000-8000:
#INTERFACE SUBNET ADDRESS PROTO
eth0 10.0.0.0/8 192.0.2.44:7000-8000 udp
12) You may now account by user/group ID for outbound traffic from the
firewall itself with entries in /etc/shorewall/accounting. Such
accounting rules must be placed in the OUTPUT chain.
See the comments at the top of /etc/shorewall/accounting for
details.
13) Shorewall now verifies that your kernel and iptables have physdev
match support if BRIDGING=Yes in shorewall.conf.
14) Beginning with this release, if your kernel and iptables have
iprange match support (see the output from "shorewall check"), then
with the exception of the /etc/shorewall/netmap file, anywhere that
a network address may appear an IP address range of the form <low
address>-<high address> may also appear.
15) Support has been added for the iptables CLASSIFY target. That
target allows you to classify packets for traffic shaping directly
rather than indirectly through fwmark. Simply enter the
<major>:<minor> classification in the first column of
/etc/shorewall/tcrules:
Example:
#MARK/ SOURCE DEST PROTO PORT(S)
#CLASSIFY
1:30 - eth0 tcp 25
Note that when using this form of rule, it is acceptable to include
the name of an interface in the DEST column.
Marking using the CLASSIFY target always occurs in the POSTROUTING
chain of the mangle table and is not affected by the setting of
MARK_IN_FORWARD_CHAIN in shorewall.conf.
16) During "shorewall start", IP addresses to be added as a consequence
of ADD_IP_ALIASES=Yes and ADD_SNAT_ALIASES=Yes are quietly deleted
when /etc/shorewall/nat and /etc/shorewall/masq are processed then
the are re-added later. This is done to help ensure that the
addresses can be added with the specified labels but can have
the undesirable side effect of causing routes to be quietly
deleted. A new RETAIN_ALIASES option has been added to
shorewall.conf; when this option is set to Yes, existing addresses
will not be deleted. Regardless of the setting of RETAIN_ALIASES,
addresses added during "shorewall start" are still deleted at a
subsequent "shorewall stop" or "shorewall restart".
17) Users with a large black list (from /etc/shorewall/blacklist) may
want to set the new DELAYBLACKLISTLOAD option in
shorewall.conf. When DELAYBLACKLISTLOAD=Yes, Shorewall will
enable new connections before loading the blacklist rules. While
this may allow connections from blacklisted hosts to slip by during
construction of the blacklist, it can substantially reduce the time
that all new connections are disabled during "shorewall [re]start".
18) Using the default LOGFORMAT, chain names longer than 11 characters
(such as in user-defined actions) may result in log prefix
truncation. A new shorewall.conf action LOGTAGONLY has been added
to deal with this problem. When LOGTAGONLY=Yes, logging rules that
specify a log tag will substitute the tag for the chain name in the
log prefix.
Example -- file /etc/shorewall/action.thisisaverylogactionname:
Rule:
DROP:info:ftp 0.0.0.0/0 0.0.0.0/0 tcp 21
Log prefix with LOGTAGONLY=No:
Shorewall:thisisaverylongacti
Log prefix with LOGTAGONLY=Yes:
Shorewall:ftp:DROP
19) Shorewall now resets the 'accept_source_route' flag for all
interfaces. If you wish to accept source routing on an interface,
you must specify the new 'sourceroute' interface option in
/etc/shorewall/interfaces.
20) The default Drop and Reject actions now invoke the new standard
action 'AllowICMPs'. This new action accepts critical ICMP types:
Type 3 code 4 (fragmentation needed)
Type 11 (TTL exceeded)
21) Explicit control over the kernel's Martian logging is now provided
using the new 'logmartians' interface option. If you include
'logmartians' in the interface option list then logging of Martian
packets on will be enabled on the specified interface.
If you wish to globally enable martian logging, you can set
LOG_MARTIANS=Yes in shorewall.conf.
22) You may now cause Shorewall to use the '--set-mss' option of the
TCPMSS target. In other words, you can cause Shorewall to set the
MSS field of SYN packets passing through the firewall to the value
you specify. This feature extends the existing CLAMPMSS option in
/etc/shorewall/shorewall.conf by allowing that option to have a
numeric value as well as the values "Yes" and "No".
Example:
CLAMPMSS=1400
23) Shorewall now includes support for the ipp2p match facility. This
is a departure from my usual policy in that the ipp2p match
facility is included in Patch-O-Matic-NG and is unlikely to ever be
included in the kernel.org source tree. Questions about how to
install the patch or how to build your kernel and/or iptables
should not be posted on the Shorewall mailing lists.
In the following files, the "PROTO" or "PROTOCOL" column may
contain "ipp2p":
/etc/shorewall/rules
/etc/shorewall/tcrules
/etc/shorewall/accounting
When the PROTO or PROTOCOL column contains "ipp2p" then the DEST
PORT(S) or PORT(S) column may contain a recognized ipp2p option;
for a list of the options and their meaning, at a root prompt:
iptables -m ipp2p --help
You must not include the leading "--" on the option; Shorewall will
supply those characters for you. If you do not include an option
then "ipp2p" is assumed (Shorewall will generate "-m ipp2p
--ipp2p").
24) Shorewall now has support for the CONNMARK target from iptables.
See the /etc/shorewall/tcrules file for details.
25) A new debugging option LOGALLNEW has been added to
shorewall.conf. When set to a log level, this option causes
Shorewall to generaate a logging rule as the first rule in each
builtin chain.
- The table name is used as the chain name in the log prefix.
- The chain name is used as the target in the log prefix.
Example: Using the default LOGFORMAT, the log prefix for logging
from the nat table's PREROUTING chain is:
Shorewall:nat:PREROUTING
IMPORTANT: There is no rate limiting on these logging rules so
use LOGALLNEW at your own risk; it may cause high CPU and disk
utilization and you may not be able to control your firewall after
you enable this option.
DANGER: DO NOT USE THIS OPTION IF THE RESULTING LOG MESSAGES WILL
BE SENT TO ANOTHER SYSTEM.
26) The SUBNET column in /etc/shorewall/rfc1918 has been renamed
SUBNETS and it is now possible to specify a list of addresses in
that column.
27) The AllowNNTP action now also allows NNTP over SSL/TLS (NNTPS).
28) For consistency, the CLIENT PORT(S) column in the tcrules file has
been renamed SOURCE PORT(S).
29) The contents of /proc/sys/net/ip4/icmp_echo_ignore_all is now shown
in the output of "shorewall status".
30) A new IPTABLES option has been added to shorewall.conf. IPTABLES
can be used to designate the iptables executable to be used by
Shorewall. If not specified, the iptables executable determined by
the PATH setting is used.
31) You can now use the "shorewall show zones" command to display the
current contents of the zones. This is particularly useful if you
use dynamic zones (DYNAMIC_ZONES=Yes in shorewall.conf).
Example:
ursa:/etc/shorewall # shorewall show zones
Shorewall-2.2.0-Beta7 Zones at ursa - Sat Nov 27 11:18:25 PST 2004
loc
eth0:192.168.1.0/24
eth1:1.2.3.4
net
eth0:0.0.0.0/0
WiFi
eth1:0.0.0.0/0
sec
eth1:0.0.0.0/0
ursa:/etc/shorewall #
32) Variable expansion may now be used with the INCLUDE directive.
Example:
/etc/shorewall/params
FILE=/etc/foo/bar
Any other config file:
INCLUDE $FILE
33) The output of "shorewall status" now includes the results of "ip
-stat link ls". This helps diagnose performance problems caused by
link errors.
34) Previously, when rate-limiting was specified in
/etc/shorewall/policy (LIMIT:BURST column), any traffic which
exceeded the specified rate was silently dropped. Now, if a log
level is given in the entry (LEVEL column) then drops are logged at
that level at a rate of 5/min with a burst of 5.
35) Recent 2.6 kernels include code that evaluates TCP packets based on
TCP Window analysis. This can cause packets that were previously
classified as NEW or ESTABLISHED to be classified as INVALID.
The new kernel code can be disabled by including this command in
your /etc/shorewall/init file:
echo 1 > /proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_be_liberal
Additional kernel logging about INVALID TCP packets may be
obtained by adding this command to /etc/shorewall/init:
echo 1 > /proc/sys/net/ipv4/netfilter/ip_conntrack_log_invalid
Traditionally, Shorewall has dropped INVALID TCP packets early. The
new DROPINVALID option allows INVALID packets to be passed through
the normal rules chains by setting DROPINVALID=No.
If not specified or if specified as empty (e.g., DROPINVALID="")
then DROPINVALID=Yes is assumed.
36) The "shorewall add" and "shorewall delete" commands now accept a
list of hosts to add or delete.
Examples:
shorewall add eth1:1.2.3.4 eth1:2.3.4.5 z12
shorewall delete eth1:1.2.3.4 eth1:2.3.4.5 z12
The above commands may also be written:
shorewall add eth1:1.2.3.4,2.3.4.5 z12
shorewall delete eth1:1.2.3.4,2.3.4.5 z12
37) TCP OpenVPN tunnels are now supported using the 'openvpn' tunnel
type. OpenVPN entries in /etc/shorewall/tunnels have this format:
openvpn[:{tcp|udp}][:<port>] <zone> <gateway>
Examples:
openvpn:tcp net 1.2.3.4 # TCP tunnel on port 1194
openvpn:3344 net 1.2.3.4 # UDP on port 3344
openvpn:tcp:4455 net 1.2.3.4 # TCP on port 4455
38) A new 'ipsecvpn' script is included in the tarball and in the
RPM. The RPM installs the file in the Documentation directory
(/usr/share/doc/packages/shorewall-2.2.0-0RC1).
This script is intended for use on Roadwarrior laptops for
establishing an IPSEC SA to/from remote networks. The script has
some limitations:
- Only one instance of the script may be used at a time.
- Only the first SPD accessed will be instantiated at the remote
gateway. So while the script creates SPDs to/from the remote
gateway and each network listed in the NETWORKS setting at the
front of the script, only one of these may be used at a time.
39) The IANA has recently registered port 1194 for use by OpenVPN. In
previous versions of Shorewall (and OpenVPN), the default port was
5000 but has been changed to 1194 to conform to the new OpenVPN
default.
40) The output of "shorewall status" now lists the loaded netfilter
kernel modules.
41) The range of UDP ports opened by the AllowTrcrt action has been
increased to 33434:33524.
View Git Blame Copy Permalink