|
Clavister Firewall v8.50.00 changes many aspects of routing, and
especially policy-based routing as a result of the virtual system/
router support. In this document, all routing-related changes have
been moved to its own section directly beneath this section.
| H.323 Application Layer Gateway implemented
| | Issue: |
The H.323 conferencing (VoIP, video, whiteboard, etc) protocol,
used by most IP telephones, and also by Microsoft NetMeeting,
makes heavy use of dynamic datachannels in both directions,
and has previously only been able to pass through firewalls
with all ports above 1024 open in both directions between
peers involved in the H.323 call.
| | Change: |
As of v8.50.00, there is an H.323 ALG capable of handling
peer-to-peer H.323 calls, as well as listening in on
H.323 "gatekeeper" communication in order to automatically
allow calls to protected hosts that register with the gatekeeper.
| | Note: |
Note that H.323 is a fairly complex protocol, and that applications
such as Microsoft NetMeeting allow remote control of computers
running it. Clavister generally does not recommend allowing H.323
directly from unsecured networks such as the Internet to network
segments with high security requirements. This is an application
where making use of Clavister Firewall's network segmentation
capabilities could be of immense help.
|
| PPTP and L2TP clients and servers implemented
| | Change: |
As of v8.50.00, Clavister Firewall supports both PPTP and L2TP
clients and servers. Multiple PPTP and L2TP servers may be
run simultaneously, getting user authentication information
from either local user databases or from RADIUS servers.
| | |
L2TP over IPsec as well as L2TP with MPPE is supported.
|
| IPsec: The "Secure" rule flag was removed
| | Issue: |
Before Clavister Firewall v8.20.00, the "Secure" rule flag was the
only way to cause plaintext traffic to be sent over an IPsec tunnel.
As of v8.20.00 however, traffic could be routed across
IPsec tunnels just as with any other interface type.
| | Change: |
As of v8.50.00, the "Secure" flag had to be removed as a result
of the changes caused by the new dynamic routing functionality.
| | |
Rules flagged as "Secure" encountered in the configuration will now
result in a configuration warning, and the rule will be transformed
to an explicit "Drop".
| | |
Also note that before v8.50.00, any connection arriving over an
IPsec tunnel would result in return traffic automatically being sent
back over the same tunnel. As of v8.50.00, this is no longer the case.
If there is no route back through the VPN tunnel, the connection
will simply not open.
The most likely place for this happening is with roaming client
tunnels, where connections back through the tunnel are seldom
required, so the lack of a return route would not have shown
before v8.50.00.
| | Remedy: |
"Secure" rule usage: Most often associated with lan-to-lan tunnels.
Make sure there are routes to the remote networks over the
appropriate tunnel interfaces. Remove the "Secure" flag from
the affected rules.
| | Remedy: |
Return traffic to roaming users: Enable the "Automatically Add
Route to Remote Network" setting on roaming user tunnels.
| | |
| » | This change is also documented as KB #10072.
|
|
| Local user database added
| | Issue: |
Previously, Clavister Firewall has been able to authenticate
users using remote RADIUS servers.
| | Change: |
As of v8.50.00, a local user database has been added, which
can be used for the same purposes as RADIUS servers.
Multiple user databases may be configured; selecting between
them is done in the User Authentication ruleset.
| | |
Note that passwords are stored in the firewall configuration using
reversible cryptography. This is in order to be compatible with
various challenge-response authentication methods such as CHAP,
MS-CHAP, and so forth, where passwords stored using non-reversible
cryptography (such as hashing) would be unusable.
|
| PPP: IP addresses and remote networks may now be configured per user
| | Issue: |
In PPP-based protocols such as L2TP and PPTP, remote network information
is not exchanged in the same way that e.g. IPsec does. Therefore, there
must be some other mechanism to control which IP spans get routed to which
user connecting to an L2TP or PPTP server.
| | Change: |
As of v8.50.00, each user may be given a fixed IP address and one or more
"remote networks", which will be routed to the user. These settings are
used by the L2TP and PPTP servers.
| | |
Both IP addresses and remote networks may be configured in local user databases.
IP addresses may also be configured in RADIUS servers, in the "Framed-IP-Address"
attribute. Support for the RADIUS "Framed-Route" attribute may be implemented
in a future version.
|
| Hosts and ranges may now be excluded from network objects
| | Issue: |
In may cases, it is useful to be able to take a large network,
or a previously defined network objects, and exclude a number
of networks, ranges or hosts.
| | Change: |
As of v8.50.00, it is possible to make exclusions in network objects.
Exclusions are shown as "-" prefixed to the exclusion.
| | Note: |
Double exclusions are encapsulated according to standard mathematical
perceptions. Consider the following three network objects:
object1: 192.168.2.0/24, -192.168.2.5
object2: 192.168.0.0/16
object3: object2, -object1
| | |
"object3" will contain the following ranges:
192.168.0.0 -- 192.168.1.255
192.168.2.5
192.168.3.0 -- 192.168.255.255
|
| IPsec: Transport mode may now be selected per tunnel
| | Issue: |
IPsec is most commonly used in Tunnel mode, where the original
packet is placed inside IPsec encapsulation and another, outer,
IP header.
In Transport mode, IPsec encapsulation is done after the
original header, thus saving 20 bytes per packet. It is, however
mostly useful for client-to-single host tunnels.
| | Change: |
As of v8.50.00, transport mode may be selected on a per-tunnel
basis. In the IPsec proposal editor, transport or tunnel mode
may also be selected on a per-proposal basis, although the default
is to use the same mode that the tunnel uses.
|
| "All-to-One" mappings for SAT rules rewriting the destination
| | Issue: |
Previously, SAT rules have normally done "transposition" mappings, i.e.
if you translate "192.168.0.0/24" to the new destination "172.16.0.0",
it would translate 192.168.0.0 to 172.16.0.0, 192.168.0.1 to 172.16.0.1,
etc. The one exception to this was cases when the destination network
was 0.0.0.0/0, in which case all addresses would be rewritten to the
same destination address.
| | Change: |
As of v8.50.00, "All-to-One" mappings may be configured, resulting in
any destination address being rewritten into the same single destination
address, regardless of the original network size.
|
| Allow two windows machines to ping each other simultaneously
| | Issue: |
All OSes except Windows will select unique ICMP IDs for each ping,
which Clavister Firewall uses to differentiate pings. Windows however
will always use "512". If such a ping was active in one direction,
Clavister Firewall would drop pings with the same ID in the reverse direction,
triggering "LogReverseOpen" log events.
| | Change: |
As of v8.50.00, Clavister Firewall rewrites ICMP IDs (if they are set to 512)
on behalf of the misbehaving senders in order to make them unique.
|
| PPPoE client can now request a "preferred IP" from server
| | Issue: |
PPP clients can requested a "preferred IP address" from the
server. The server may or may not grant the request. If not
it will respond with a different address to use.
| | Change: |
As of v8.50.00, the PPPoE (and PPTP and L2TP) client in Clavister Firewall
may request a "preferred IP" from a PPPoE/PPTP/L2TP server.
This is controlled via setting the host object that receives the
IP address from the server, e.g. "ip_mypppiface", to something other
than 0.0.0.0. The address set will be requested from the server.
|
| IPsec: The "ikesnoop" command can now filter IP addresses
| | Issue: |
Enabling IKE snooping on a busy IPsec gateway may lead to excessive
amounts of output.
| | Change: |
As of v8.50.00, the "ikesnoop" command can take an optional
IP address parameter. If used, only IKE traffic involving that
IP address is shown.
|
| RTL8139 (Realtek) NIC performance enhanced
| | Issue: |
The RTL8139 NIC has a maximum transmit ring size of 4 packets, while
nearly every other chip allows transmit rings of 128 packets or
greater. This causes packetloss problems when traffic arrives in
bursts at or near 100Mbit/s linespeed.
| | Change: |
As of v8.50.00, there is an extra buffer in software which queues
packets before handing them to the chip. This improves resilience
to traffic bursts.
|
| Buffered log sending implemented
| | Issue: |
The syslog protocol as well as Clavister's proprietary logging
protocol both use UDP for delivery. It is the nature of UDP
to perform no buffering and rather attempt to send each message
immediately. If hundreds of log messages were sent during the
same fraction of a millisecond, interface TX rings would
be overwhelmed, and log event loss would occur.
| | Change: |
As of v8.50.00, Clavister Firewall will buffer log events
and send only 100 messages every 10 milliseconds, for a maximum
of 10 000 events each second. The buffer size may be up to
2 MB if enough RAM is available, which is enough to accomodate
approximately one second's worth of log events during maximum
rate.
| | |
Note however that the maximum amount of log messages sent
each second is still limited by the LogSendPerSec advanced
setting.
| | Change: |
As of v8.50.00, the LogSendPerSec default value is increased
from 500 events per second to 2000 events per second. This
equals a network load of about 4 Mbit/s, or about 2GB of
data per hour.
| | Change: |
If the rate of events is throttled for some reason, e.g.
if the send buffer fills up, or if the LogSendPerSec limit
is exceeded, a "SYSTEM" category log message including a count
of dropped events will now be generated when logging can resume.
| | |
Note that log events may still be lost due to reasons
outside the firewall's control, for instance due to
network saturation, excessive log server load, or other
reasons. Such loss will not result in warning events
in the logs.
|
| DHCP Server: "next server" field now configurable
| | Issue: |
In more complex boot setups, such as some PXE configurations use,
one DHCP server can use the "next server" field to point to another
server that the client should talk to in order to complete the boot process.
| | Change: |
As of v8.50.00, the "Next server" field is configurable under
the "Options" tab of the DHCP Server properties.
|
| FTP ALG: List of known and disallowed commands updated
| | Issue: |
The FTP ALG keeps a list of commands that are "known" and hence
allowed through it. By default, everything else is disallowed.
However, it is possible to tell it to "Allow Unknown Commands",
in which case there is a list of explicitly disallowed commands
that is still used. The reason for the latter list is that they
won't work through the ALG anyway.
| | Change: |
As of v8.40.05 and v8.50.00, the following commands have been added
to the "known commands" list:
"XMKD", "XRMD", "XPWD", "XCUP" and "XCWD".
| | |
Two commands have been added to the "disallowed commands" list:
"MLST" and "MLSD". The reason is that MLSD uses data channels that would not
work without explicit support in the FTP ALG anyway. Support for this
may be added in a future release.
|
| IPsec: XAuth client support added
| | Change: |
As of v8.50.00, Clavister Firewall can act as an XAuth when originating
IPsec tunnels and authenticate to the remote gateway with a username
and password.
|
| IPsec: Full draft-beaulieu-ike-xauth-02 support
| | Issue: |
Although support for authenticating IPsec clients via XAuth
has existed for some time, XAuthInit* notifications were not
sent. Some IPsec clients have been confused by this behavior.
| | Change: |
As of v8.50.00, XAuthInit* notifications are sent.
|
| DHCP Relayer and Server now support DHCPINFORM messages
| | Issue: |
In situations where a client already has an IP address, for example
when PPP LCP is used, but the client wants to learn other IP configuration
parameters, the client will use DHCPINFORM messages.
| | Change: |
As of v8.50.00, the DHCP Relayer will relay DHCPINFORM messages.
The IP address that the client uses is still validated against
the "Allowed IP span" in the DHCP relayer rule.
| | Change: |
As of v8.50.00, the DHCP Server will answer DHCPINFORM messages
in accordance with the DHCP server ruleset.
|
| Packets from originator is now enough to keep non-TCP states alive
| | Issue: |
The state engine normally keeps separate timeouts in each direction,
so that packets only in one direction will not be enough to keep
a state alive, which makes sense, since the majority of protocols
are bi-directional.
| | Change: |
As of v8.50.00, packets from the originator only will be enough to
keep a stateless (UDP, Raw IP, Ping) connection alive. Closing it
while the originator is active is pointless since another packet from
the originator will open it right back up again; it was, after all,
allowed by the ruleset to begin with.
|
| New advanced setting: IPOPT_RTRALT
| | Issue: |
Many H.323 applications make use of the RSVP protocol, which sets the
IP option "RTRALT" in the IP header. Previously, IPOPT_RTRALT
would trigger IPOPT_Other, which defaults to "Drop and log", causing
excessive log activity while the H.323 call was active.
| | Change: |
As of v8.50.00, there is a separate setting for the "RTRALT" IP option,
which defaults to "Validate, log only if bad". Clavister Firewall
itself does not obey RTRALT options nor the RSVP protocol, but it
will now pass through the firewall if the policy allows it.
|
| DHCP client will now include options 12, 60 and 61 in requests
| | Issue: |
Some DHCP servers require options 12 (Host Name), 60 (Class Identifier)
and 61 (Client Identifier) to be set in DHCP requests. Although
requiring optional data in this manner could be considered a
violation of the DHCP RFC, measures have been taken in the
DHCP client in Clavister Firewall.
| | Change: |
As of v8.40.05 and v8.50.00, the above options are included
in all DHCP requests. The host name is constructed from the
MAC address of the interface in question.
|
| "-verbose" switch added to arpsnoop console command
| | Change: |
As of v8.50.00, a "-verbose" switch is added to the arpsnoop command.
It displays the results of PBR rule lookups, route lookups, whether
or not something is published due to Proxy ARP being enabled on a route,
or if Local IP is in use, and plenty of additional behind-the-scenes
information that is useful in troubleshooting complex routing
situations.
|
| ARP section: IP addresses may now be published on multiple interfaces at once
| | Change: |
As of v8.50.00, a group of interfaces, and even "Any", may be specified
as the interface in a "Publish" in the ARP section. This results in
the address being published on multiple interfaces at once.
|
|