| Built-in DHCP server implemented
| | Change: |
Clavister Firewall now includes a highly flexible DHCP server.
Multiple pools can be specified per interface and/or group of
interfaces. All relevant settings maybe adjusted on a per-pool
basis, and for virtual firewall scenarios, the same IP span
can be reused in individual pools on different interfaces.
|
| User authentication via HTTPS
| | Change: |
As of v8.10, Clavister Firewall has been able to do user
authentication via HTTP. This same functionality is now
also available via encrypted HTTP: HTTPS. This, in combination
with an SSL server certificate installed on the firewall,
allows secure user authentication.
|
| PPPoE support implemented
| | Change: |
An increasing number of DSL and cable modem ISPs use the
PPP-over-Ethernet protocol for customer authentication.
Clavister Firewall now includes a PPPoE client, which allows
it to function in such networks.
|
| Traffic shaping now controlled by separate pipe ruleset
| | Change: |
The traffic shaping functionality of Clavister Firewall has
so far been controlled through pipe settings on a per-rule
basis in the standard ruleset.
As of 8.30.00, the new pipe ruleset contains all
rules regarding pipes. It is evaluated after the
main ruleset.
The main benefit is reduced ruleset complexity; the main
ruleset can now concentrate on access policy while the
pipe ruleset handles traffic shaping policy.
| | Note: |
When a firewall has been upgraded to 8.3, you will be offered
the opportunity to move your pipe settings to the pipe
ruleset. This operation is not destructive.
Everything will keep working exactly as it did before
the conversion. If you still do not want to do this
immediately, you can decline, and do it at a later point
via the context menu of the "Rules" node in the tree.
| | Sidenote: |
The "pipe rules" view now has two columns where the main
ruleset previously had one: one column for pipes in the
forward direction, and one column for the reverse direction.
With in-cell editing enabled, this makes it even easier
to manage your pipe settings.
|
| User authentication via IKE XAuth now carries to main ruleset
| | Change: |
Previously, user authentication done via IKE XAuth only
controlled the opening of the actual IPsec tunnel. Now, this
logon information is also carried to the main ruleset;
policies using authenticated network objects can now be
written the same way as with users logged on via HTTP(s).
|
| DHCP relayer state kept over reboot
| | Change: |
The built-in DHCP relayer will now keep its state over reboot.
This changes very little from a pure relaying standpoint, but
is very helpful when the DHCP relayer is configured to automatically
add routes to the routing table according to relayed leases.
By default, it will save the relay table on config re-read
and shutdown, but can also be configured to save the relay
table periodically. See the DHCPRelay_SaveRelayPolicy and
DHCPRelay_AutoSaveRelayInterval advanced settings.
|
| Pipe user grouping per source/destination interface/VLAN
| | Change: |
The Clavister Firewall traffic shaper allows users in each "pipe"
to be grouped according to a number of parameters. Previously, this
list has included Network (configurable mask), IP address and TCP/UDP ports.
As of 8.30.00, pipe users may also be grouped per source/destination
interface, which of course includes VLAN interfaces.
|
| DHCP relayer can now add routes to PBR tables
| | Issue: |
It has previously been possible to have the DHCP relayer
automatically add routes to the routing table for leases
that it relays. This, in combination with proxy ARP allows
for great flexibility in network designs.
| | Change: |
As of 8.30.00, the DHCP relayer can also add routes to routing
tables other than the main routing table. The routing table
to manipulate may be specified on a per-rule basis.
|
| DHCP relayer leases can now be ended from console
| | Change: |
The "dhcprelay" console command now has
"-release <ipaddr>" switch, which
forcefully makes the relayer forget about a relayed
lease, including removing automatically added routes, if any.
|
|