Beta 3 is now available for testing.
This version corrects several issues with ''update -b'' reported
by Steven Springl. As part of those changes, the ''blacklog''
target is now available in the blrules file.
Also:
1) This release formalizes the feature that has long been
documented at http://www.shorewall.net/PacketMarking.html#Values.
The WIDE_TC_MARKS and HIGH_ROUTE_MARKS options have traditionally
been used to define the various fields in a packet/connection mark.
But more flexible control is provided using these options.
TC_BITS
The number ob bits at the least-significant end of the mark
to be used for traffic shaping marking. May be zero.
PROVIDER_BITS
The number of bits in the mark to be used for provider
marks. May be zero.
PROVIDER_OFFSET
The offset from the right (low-order end) of the provider
number field. If non-zero, must be >= TC_BITS. Shorewall
automatically adjusts PROVIDER OFFSETs value to inforce this
restriction. May be zero, in which case the TC mark field
and Provider mark field overlay.
MASK_BITS
The number of low-order bits to be masked when clearing the
traffic shaping mark. Must be >= TC_BITS and <
PROVIDER_OFFSET (provider that PROVIDER_OFFSET > 0).
Beginning with Shorewall 4.4.12, the field between MASK_BITS and
PROVIDER_OFFSET can be used for any purpose you want.
Beginning with Shorewall 4.4.13, the first unused bit from the
right is used by Shorewall as an ''exclusion mark'' which
allows
exclusion in CONTINUE, NONAT and ACCEPT+ rules.
It is actually the values of the above four options that determine
how Packet/Connection Marks are layed out. Their default values are
derived from the settings of WIDE_TC_MARKS and HIGH_ROUTE_MARKS as
shown in the table at
http://www.shorewall.net/PacketMarking.html#Values.
2) This release introduces limited support for using back-to-back veth
devices to access a bridge.
Consider this setup:
-- eth1 (zone1)
/
WAN ---- eth0 veth0 <-> veth1-- br0 --- eth2 (zone2)
\
-- eth3 (zone3)
In this configuration, it is veth0 that has an IP address; the
bridge does not.
Because veth1 is a port on br0, Netfilter allows filtering between
that interface and each of the other ports. All connections from
the firewall (fw) and the WAN ((net) enter the bridge through
veth1. All traffic from zone1-zone3 enter the routing firewall
through veth0.
Note that, in this configuration, packets between zones1-zone3 and
the rest of the world go through Netfilter twice. Assume that we
associate veth0 with an ip zone called ''bridge'' and veth1
with a
bport zone called ''portal''. Then the two traversals of
Netfilter
are:
a) Between eth1-eth3 and veth1. Source zone is zone1-zone3 and the
destination zone is ''portal''.
b) Between veth0 and the final destination. The source zone is
bridge and the destination zone is either fw or net.
A similar scenario occurs with traffic originating in the net or
firewall zones and destined for zone1-zone3.
As you can see, the problem here is that in the first traversal, we
know the real source zone but not the real destination zone; and in
the second traversal, we know the real destination zone but not the
real source zone.
The solution allows us to know the real source zone during the
second traversal.
A new ZONE_BITS option is added to shorewall.conf
(shorewall6.conf). Its value determines the number of bits of the
packet mark to use for zone marks. When ZONE_BITS is non-zero,
Shorewall automatically assigns a mark value to each zone (the
firewall zone always has value 0). Zone marks are assigned to all
zones except those that specify ''nomark'' in the OPTION
column of
their zones file entry. In the above example, the bridge and portal
zones would have ''nomark'' specified.
With ZONE_BITS and ''nomark'' specified appropriately, now
each
packet from the ''bridge'' zone has a packet mark that lets
us know
which of the three bport zones (zone1-zone3) the packet originated
on.
Similarly, packets entering the bridge through veth1 have a mark
value that records whether the packet is from the net zone or the
fw zone.
As part of these changes, the compiler now accepts a zone name in
the MARK column of the rules file, when ZONE_BITS is non-zero. This
permits rules of this type:
ACCEPT bridge net ... ; mark=zone2
to control connections from zone2 to the net, and rules such as
ACCEPT portal zone1 ...; mark=net
to control connections from the net to zone1.
One final note; DNAT rules should be placed in the first traversal
(net->bridge on input).
See http://www.shorewall.net/bridge-Shorewall-perl for a fuller
example.
Tom Eastep \ When I die, I want to go like my Grandfather who
Shoreline, \ died peacefully in his sleep. Not screaming like
Washington, USA \ all of the passengers in his car
http://shorewall.net \________________________________________________
------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure
contains a definitive record of customers, application performance,
security threats, fraudulent activity, and more. Splunk takes this
data and makes sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-novd2d