Clavister Security Gateway changes from v8.60.01 to v8.60.02

Clavister Security Gateway changes from v8.60.01 to v8.60.02

Release date: 2006-02-22 [ISO]

Users upgrading from v7.0x or earlier should read changes-7.0x.xx-to-8.00.02.html first.

Version 8.60.02 contains a number of new features which are highlighted here:

» RADIUS Interim Accounting support enables interim accounting updates for logged in users.
» GRE Session Keys support enables the possibility to identify tunnels by ID.

Version 8.60.02 contains fixes to problems in the Security Gateway Core and the Firewall Manager. This document outlines problems solved as well as improvements for each component.

The upgrade procedures in this document refer to upgrades from earlier v8.0x installations.

Files installed by v8.60.02

How to upgrade earlier v8.0x firewalls to v8.60.02

How to upgrade v6.0x/v7.0x firewalls to v8.0x

HA upgrade procedure

Firewall Manager
[Problems Solved]

Security Gateway Core
[Changes] [Problems Solved] [Considerations]

For future reference: This document is stored in the "Docs" sub-folder of your Firewall Manager install folder.

Change logs / release notes for earlier versions of Clavister Security Gateway are available in the release notes section of www.clavister.com/support.

Summary of changes and problems solved

Firewall Manager

  Problem solved: IXP interface driver not configurable in the Firewall Manager

  Problem solved: IPsec Config Mode pools in global namespace does not work

  Problem solved: Not possible to configure null encryption in IPsec proposals

Security Gateway Core

  Change: RADIUS Interim Accounting supported

  Change: GRE session keys supported

  Problem solved: Realtek interfaces lose the link status description after a reconfigure

  Problem solved: The "ping" command will ignore the interface PBR setting when the "-r " parameter is used

  Problem solved: Problems administrating a Security Gateway over netcon on a virtual router interface

  Problem solved: Problems terminating a L2TP session inside a virtual router

  Problem solved: L2TP server may stop to listen for incoming connection attempts

  Problem solved: The L2TP engine may use 0 as session ID, which is not allowed according to RFC 1661

  Problem solved: IPsec engine runs out of internal states

  Known problem: Problems with root certificates also used as gateway certificates

  Known problem: IPsec tunnels configured to use different root certificates should be configured to use ID-lists as well

  Known problem: HA: Transparent Mode won't work in HA mode

  Known problem: HA: No state synchronization for ALGs

  Known problem: HA: Tunnels unreachable from inactive node

  Known problem: HA: No state synchronization for L2TP and PPTP

Files installed by v8.60.02

This is a list of files that are new to the v8.60.02 release. All paths are relative to your Firewall Manager install folder.

»	Cores/sgc-8.60.02-full.cfx This is the v8.60.02 full Security Gateway Core. Upload it to your existing Security Gateway, or create new boot media with it. It contains all available functionality.
»	Cores/sgc-8.60.02-mini.cfx This is a version of the v8.60.02 core with certain features removed. It is less than half the size of the full version. The features removed are: - IPsec VPN - The H.323 Application Layer Gateway - OSPF
»	Cores/sgc-8.60.02-sg50.cfx This is the v8.60.02 Security Gateway Core for the SG50 appliance. Upload it to your existing Security Gateway. It contains all available functionality. Note that SG50-series users with units delivered with core version 8.60.02-RC1 as factory default are highly recommended to upgrade the firmware to the version supplied with the 8.60.02 release. Upgrade to core version 8.60.02 before upgrading the firmware.
»	Docs/changes-8.60.01-to-8.60.02.html This document.
»	FWMgr8.exe This is the v8.60.02 Firewall Manager. Earlier version 8 Firewall Managers will be backed up with the extensions ".old1" and ".old2".

How to upgrade earlier v8.0x firewalls to v8.60.02

Upgrading a previous v8.0x firewall to v8.60.02 is completely straightforward.
Simply upload the new core, "sgc-8.60.02-full.cfx", or "sgc-8.60.02-sg50.cfx" in case a SG50 appliance is used, to your Security Gateway and restart it.
(Alternatively, upload the "-mini" version, not available for SG50, if the removed functionality is not required.)

HA upgrade procedure

Note: For upgrades from v7.x HA clusters, first follow the HA upgrade procedures outlined in changes-7.0x.xx-to-8.00.02.html.

Note: Upgrades from versions prior to v8.40.01: Upgrading to directly v8.50.00 or later from a version prior to v8.40.01 will lead to loss of state synchronization. All open states will be closed as a result of the upgrade. If this is acceptable, continue with the upgrade as described below. Otherwise, first upgrade to v8.40.01 or a later v8.4x core and then upgrade to v8.60.02.

Simply upload the new Security Gateway Core file to the Security Gateways in your cluster and make sure that the first upload and restart is successful before uploading to the second Security Gateway.

We recommend beginning with the Security Gateway that is currently active, even though this will necessitate two failovers. The reason for this is that ALG sessions are not synchronized.

The "immediate availability" method

Upload the core to the currently active Security Gateway ("Security Gateway A") and restart it.
Issue a 'reconfigure' on the Security Gateway B to rapidly fail back to the now upgraded Security Gateway A. Make sure Security Gateway A functions properly.
Upload the core to Security Gateway B and restart it.
End result: Security Gateway A is now the active node, just as it was before the upgrade procedure.

Note that this leaves the second Security Gateway untested, even though it most likely will work just as well as the first Security Gateway. If you want to specifically test the second Security Gateway, you can:
1) cause two failovers manually, or
2) connect to it via e.g. the remote console just to make sure it's running, or
3) if ALG and tunnel synchronization is not a concern, follow this procedure:

The "long-term safe" procedure:

Upload the core to the currently inactive Security Gateway ("Security Gateway B") and restart it.
Issue a 'reconfigure' on Security Gateway A. This causes failover to Security Gateway B. Make sure Security Gateway B functions properly.
Upload the core to Security Gateway A and restart it.
Issue a 'reconfigure' on Security Gateway B to fall back to Security Gateway A. Make sure Security Gateway A functions properly.
End result: Security Gateway A is now the active node, just as it was before the upgrade procedure.

Note that the "availability" issues affect only synchronization of ALGs and tunnels; there is more information about this in the Considerations section. All other states are, as usual, fully synchronized and not affected in either procedure.

Firewall Manager Problems Solved

IXP interface driver not configurable in the Firewall Manager
Issue:	When creating a new interface configuration for the SG50 appliance, it is not possible to select the IXP interface driver.
Results:	It is not possible to create a new configuration for an IXP network interface.
Affects:	Firewall Manager v8.60 and up.
Solution:	Solved in v8.60.02.

IPsec Config Mode pools in global namespace does not work
Issue:	Creating a tunnel with Config Mode enabled won't work if the Config Mode pool is configured in the global namespace.
Results:	Clicking apply/ok only generates a alert box with the message "No cfg mode pool configured".
Affects:	Firewall Manager v8.60 and up.
Solution:	Solved in v8.60.02.

Not possible to configure null encryption in IPsec proposals
Issue:	It is not possible to configure null encryption for IPsec proposals from the Firewall Manager.
Results:	IPsec proposals cannot be configured with null encryption enabled.
Affects:	Firewall Manager v8.60.00 and up.
Solution:	Solved in v8.60.02.

Security Gateway Core Changes

RADIUS Interim Accounting supported
Issue:	RADIUS interim update messages can now be sent to the accounting server at an interval specified in the configuration of the Security Gateway or the RADIUS Accounting server. This allows the RADIUS Accounting server to be continuously updated with user statistics.
Change:	As of v8.60.02, RADIUS Interim Accounting is supported by the Security Gateway.

GRE session keys supported
Issue:	A GRE session key can now be configured on GRE tunnels to specify an ID for the tunnel.
Change:	As of v8.60.02, GRE tunnels support session keys.

Security Gateway Core Problems Solved

Realtek interfaces lose the link status description after a reconfigure
Problem:	Realtek interfaces will lose the link status description displayed with the "ifstat" command after a reconfigure has been done.
Results:	It is not possible to get the correct link status for a Realtek interface after a reconfigure.
Affects:	Clavister Security Gateway v8.60.00 and up
Solution:	Solved in v8.60.02.

The "ping" command will ignore the interface PBR setting when the "-r " parameter is used
Problem:	The "ping" console command will ignore the PBR setting for an interface when the "-r " parameter is supplied to the console command.
Results:	The "ping" command will not use the correct routing table.
Affects:	Clavister Security Gateway v8.50.00 and up
Solution:	Solved in v8.60.02.

Problems administrating a Security Gateway over netcon on a virtual router interface
Problem:	If a Security Gateway is administrated via the manager and the management interface of the Security Gateway is inside a virtual router, connection problems may occour.
Results:	It is not possible to use for instance a remote console on a Security Gateway if the management interface is inside a virtual router.
Affects:	Clavister Security Gateway v8.50.00 and up
Solution:	Solved in v8.60.02.

Problems terminating a L2TP session inside a virtual router
Problem:	If a Security Gateway is configured to accept incoming L2TP connections on an interface inside a virtual router, connections from clients will fail.
Results:	It is not possible for clients to connect to a L2TP server that is configured to listen on an interface inside a virtual router.
Affects:	Clavister Security Gateway v8.50.00 and up
Solution:	Solved in v8.60.02.

L2TP server may stop to listen for incoming connection attempts
Problem:	If the load is high on the Security Gateway and the concurrent connection limit has been reached, the Security Gateway may stop to listen on incoming L2TP connection attempts.
Results:	Once the limit has been reached, the Security Gateway will start to flush old connections. The listening connection for the L2TP server may be subject of being flushed, which means that the L2TP server may stop to listen on incoming connection attempts.
Affects:	Clavister Security Gateway v8.50.00 and up
Solution:	Solved in v8.60.02.

The L2TP engine may use 0 as session ID, which is not allowed according to RFC 1661
Problem:	The L2TP engine may use a session ID value of 0, which is not allowed according to RFC 1661.
Results:	Some clients/servers reacts to this RFC violation and refuses to set up a new session.
Affects:	Clavister Security Gateway v8.50.00 and up
Solution:	Solved in v8.60.02.

IPsec engine runs out of internal states
Problem:	The IPsec engine keeps track of internal flow states for connections over IPsec tunnels. The number of flow states are limited and it is possible to run out of states depending on the tunnel limit in the license.
Results:	When the IPsec engine has run out of states, new connections in the tunnel are disallowed.
Affects:	Clavister Security Gateway v8.60.00 and up
Solution:	Solved in v8.60.02.

Security Gateway Core Considerations

Problems with root certificates also used as gateway certificates
Problem:	A certificate that is used as root certificate on any IPsec tunnel in the configuration cannot be used as a gateway certificate on a tunnel in the same configuration.
Results:	Authentication will fail for IPsec tunnels that use a gateway certificate that also is used as root certificate on IPsec tunnels in the configuration.

IPsec tunnels configured to use different root certificates should be configured to use ID-lists as well
Problem:	If two or more IPsec tunnels are configured to use different root certificates the tunnels should also be configured to use ID-lists. If ID-lists are not used, the Security Gateway may have problems finding the correct root certificate to use for a specific tunnel.
Results:	Authentication may fail for IPsec tunnels that use different root certificates and have no ID-lists configured.

HA: Transparent Mode won't work in HA mode
Problem:	There is no state synchronization for Transparent Mode and there is no loop avoidance.
Results:	Transparent Mode won't work in HA mode. There is no state synchronization and loop avoidance is not in place.

HA: No state synchronization for ALGs
Problem:	No aspect of ALGs are state synchronized
Results:	This means that all traffic handled by ALGs will freeze when the cluster fails over to the other peer. If, however, the cluster fails back over to the original peer within approximately half a minute, frozen sessions (and associated transfers) should begin working again. Note that such failover (and consequent fallback) occurs each time a new configuration is uploaded.

HA: Tunnels unreachable from inactive node

Problem:

The inactive node in a HA cluster cannot communicate over IPsec, PPTP, L2TP and GRE tunnels, as such tunnels are established to/from the active node.

Results:

»	Inactive HA member cannot send log events over tunnels.
»	Inactive HA member cannot be managed / monitored over tunnels.
»	OSPF: If the cluster members do not share a broadcast interface so that the inactive node can learn about OSPF state, OSPF failover over tunnels uses normal OSPF failover rather than accelerated (<1s) failover. This means 20-30 seconds with default settings, and 3-4 seconds with more aggressively tuned OSPF timings.

HA: No state synchronization for L2TP and PPTP
Problem:	There is no state synchronization for L2TP and PPTP tunnels.
Results:	On failover, incoming clients will re-establish their tunnels after the tunnels are deemed non-functional. This timeout is typically in the 30 -- 120 second range.