forked from extern/shorewall_code
389a3c6a1c
git-svn-id: https://shorewall.svn.sourceforge.net/svnroot/shorewall/trunk@9073 fbd18981-670d-0410-9b5c-8dc0c1a9a2bb
160 lines
5.7 KiB
Plaintext
160 lines
5.7 KiB
Plaintext
Shorewall 4.3.4
|
|
|
|
Notice:
|
|
|
|
It was previously my intention to defer release of IPv6 support until
|
|
4.4. That plan was based on an architecture that supported a single
|
|
configuration for both IPv4 and IPv6.
|
|
|
|
Splitting IPv6 support out into separate products has made adding that
|
|
support an order of magnitude easier and less invasive. So it is my
|
|
current plan to release IPv6 support in a future 4.2.x release.
|
|
|
|
I am therefore opening the testing of the development branch to a wider
|
|
audience.
|
|
|
|
----------------------------------------------------------------------------
|
|
R E L E A S E 4 . 3 H I G H L I G H T S
|
|
----------------------------------------------------------------------------
|
|
1) Support is included for IPv6.
|
|
|
|
Minimun system requirements:
|
|
|
|
- Kernel 2.6.25 or later.
|
|
- iptables 1.4.0 or later with 1.4.1 strongly recommended.
|
|
- Perl 5.10 if you wish to use DNS names in your IPv6 config files.
|
|
In that case you will also have to install Perl Socket6 support.
|
|
|
|
Problems Corrected in 4.3.4
|
|
|
|
1) Previously, an extra 'done' could be emitted in the generated shell
|
|
script resulting in a shell syntax error at run-time.
|
|
|
|
2) In IPv6, ipranges were previously not supported even when the
|
|
kernel and ip6tables included support for them.
|
|
|
|
3) An optimization in all Shorewall-perl 4.2 and 4.3 versions could
|
|
cause undesirable side effects. The optimization deleted the
|
|
<interface>_in and <interface>_fwd chains and moved their rules
|
|
to the appropriate rules chain (a <zone>2<xxx> chain).
|
|
|
|
This worked badly in cases where a zone was associated with more
|
|
than one interface. Rules could be duplicated or, worse, a rule
|
|
that was intended for only input from one of the zone's interfaces
|
|
would be applied to input from all of the zone's interfaces.
|
|
|
|
This problem has been corrected so that an interface-related
|
|
chains is only deleted if:
|
|
|
|
a) the chain has no rules in it; or
|
|
b) the interface is associated with only one zone and that zone is
|
|
associated with only that interface in which case it is safe to
|
|
move the rules.
|
|
|
|
Other Changes in 4.3.4
|
|
|
|
1) Shorewall and Shorewall Lite now show only IPv4 connections in the
|
|
output of 'shorewall show connections', 'shorewall-lite show
|
|
connections', 'shorewall dump' and 'shorewall-lite dump'.
|
|
|
|
2) The Shorewall and Shorewall lite commands that show log messages
|
|
('shorewall show log', ...) now show only IPv4 messages. The
|
|
corresponding commands in Shorewall6 and Shorewall6 Lite only show
|
|
IPv6 messages.
|
|
|
|
Migration Issues.
|
|
|
|
None.
|
|
|
|
New Features in Shorewall 4.3
|
|
|
|
1) Two new packages are included:
|
|
|
|
a) Shorewall6 - analagous to Shorewall-common but handles IPv6
|
|
rather than IPv4.
|
|
|
|
b) Shorewall6-lite - analagous to Shorewall-lite but handles IPv6
|
|
rather than IPv4.
|
|
|
|
The packages store their configurations in /etc/shorewall6/ and
|
|
/etc/shorewall6-lite/ respectively.
|
|
|
|
The fact that the packages are separate from their IPv4 counterparts
|
|
means that you control IPv4 and IPv6 traffic separately (the same
|
|
way that Netfilter does). Starting/Stopping the firewall for one
|
|
address family has no effect on the other address family.
|
|
|
|
Other features of Shorewall6 are:
|
|
|
|
a) There is no NAT of any kind (most people see this as a giant step
|
|
forward). When an ISP assigns you a public IPv6 address, you are
|
|
actually assigned an IPv6 'prefix' which is like an IPv4
|
|
subnet. A 64-bit prefix allows 4 billion squared individual hosts
|
|
(the size of the current IPv4 address space squared).
|
|
|
|
b) The default zone type is ipv6.
|
|
|
|
c) The currently-supported interface options in Shorewall6 are:
|
|
|
|
blacklist
|
|
bridge
|
|
dhcp
|
|
nosmurfs (traps multicast and Subnet-router anycast addresses
|
|
used as the packet source address).
|
|
optional
|
|
routeback
|
|
sourceroute
|
|
tcpflags
|
|
mss
|
|
forward (setting it to 0 makes the router behave like a host
|
|
on that interface rather than like a router).
|
|
|
|
d) The currently-supported host options in Shorewall6 are:
|
|
|
|
blacklist
|
|
routeback
|
|
tcpflags
|
|
|
|
e) Traffic Shaping is disabled by default. The tcdevices and
|
|
tcclasses files are address-family independent so
|
|
to use the Shorewall builtin Traffic Shaper, TC_ENABLED=Internal
|
|
should be specified in Shorewall or in Shorewall6 but not in
|
|
both. In the configuration where the internal traffic shaper is
|
|
not enabled, CLEAR_TC=No should be specified.
|
|
|
|
tcfilters are not available in Shorewall6.
|
|
|
|
f) When both an interface and an address or address list need to
|
|
be specified in a rule, the address or list must be enclosed in
|
|
angle brackets. Example:
|
|
|
|
#ACTION SOURCE DEST
|
|
ACCEPT net:eth0:<2001:19f0:feee::dead:beef:cafe> dmz
|
|
|
|
Note that this includes MAC addresses as well as IPv6 addresses.
|
|
|
|
The HOSTS column in /etc/shorewall6/hosts also uses this
|
|
convention:
|
|
|
|
#ZONE HOSTS OPTIONS
|
|
chat6 eth0:<2001:19f0:feee::dead:beef:cafe>
|
|
|
|
Even when an interface is not specified, it is permitted to
|
|
enclose addresses in <> to improve readability. Example:
|
|
|
|
#ACTION SOURCE DEST
|
|
ACCEPT net:<2001:1::1> $FW
|
|
|
|
g) The options available in shorewall6.conf are a subset of those
|
|
available in shorewall.conf.
|
|
|
|
h) The Socket6.pm Perl module is required if you include DNS names
|
|
in your Shorewall6 configuration. Note that it is loaded the
|
|
first time that a DNS name is encountered so if it is missing,
|
|
you get a message similar to this one:
|
|
|
|
...
|
|
Checking /etc/shorewall6/rules...
|
|
Can't locate Socket6.pm in @INC (@INC contains: /root ...
|
|
teastep@ursa:~/Configs/standalone6$
|