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

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

Release date: 2005-12-22 [ISO]

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

Version 8.60.01 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.01

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

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

HA upgrade procedure

Firewall Manager
[Changes] [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

  Change: Dialog for adding switchroutes has been changed

  Change: Two new default proposal lists added

  Problem solved: CRL setting for CA certificates overwritten by manager

  Problem solved: Real-time Logger and Remote Console may crash in Firewall Manager.

  Problem solved: The firewall manager crashes if a user clicks in the authentication column for a IPsec tunnel

  Problem solved: Firewall Manager cannot remove integrity algorithms from proposal lists

  Problem solved: It is not possible to add routes to the "core" interface

  Problem solved: IPSec/IKE Proposals are written down to configuration file in the wrong order

  Problem solved: Problems with switchroutes in PBR tables

  Problem solved: Erroneous warning displayed

Security Gateway Core

  Change: Packets with disallowed source Ethernet addresses are now dropped when using Transparent Mode

  Change: New advanced settings for forwarded ARP traffic when Transparent Mode is used

  Problem solved: Multiple entries may be added in the layer 3 cache for a host if Transparent Mode is configured

  Problem solved: SG50-series appliances may fail to restart after software issued reboot or core crash.

  Problem solved: L2TP client/server does not send a unique hostname during negotiations

  Problem solved: Link status problems on SG50-series LAN interfaces

  Problem solved: Tulip interface driver problems

  Problem solved: SLB monitoring problems

  Problem solved: Promiscuous mode is enabled by default on all interfaces

  Problem solved: Calling the shutdown console command does not always restart the core

  Problem solved: Transparent Mode feature can cause memory leakage

  Problem solved: ARP handling in Transparent Mode incompatible with Microsoft Network Load Balancing

  Problem solved: Filtered "conn" console command displays wrong number of not shown connections

  Change: IPSec NAT-traversal behaviour changed

  Problem solved: IPSec Config Mode IP pool problem

  Problem solved: Problems with reconfiguration when using a license allowing only a few IPSec tunnels

  Problem solved: Certificate setting to not validate with CRL is lost after reconfiguration

  Problem solved: Memory leakage using hardware crypto accelerator in SG3100-series

  Problem solved: MTU problems over IPSec interfaces

  Problem solved: Problems sending LDAP traffic over IPSec tunnels

  Problem solved: IPSec keepalive does not work

  Problem solved: IPSec tunnels using ID-lists may fail to be re-authenticated after being taken down

  Problem solved: Security Gateway does not complain if private key file is not understood

  Problem solved: IPSec re-keying fails

  Problem solved: IPSec re-configuration problems

  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.01

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

»	Cores/sgc-8.60.01-full.cfx This is the v8.60.01 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.01-mini.cfx This is a version of the v8.60.01 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.01-sg50.cfx This is the v8.60.01 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.01-RC1 as factory default are highly recommended to upgrade the firmware to the version supplied with the 8.60.01 release. Upgrade to core version 8.60.01 before upgrading the firmware.
»	Docs/changes-8.60.00-to-8.60.01.html This document.
»	FWMgr8.exe This is the v8.60.01 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.01

Upgrading a previous v8.0x firewall to v8.60.01 is completely straightforward.
Simply upload the new core, "sgc-8.60.01-full.cfx", or "sgc-8.60.01-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.01.

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 Changes

Dialog for adding switchroutes has been changed
Change:	As of v8.60.01, the dialog for adding switchroutes has been modified. The possibility to add a default gateway for a switchroute has been removed and it is no longer possible to configure monitoring on a switchroute.
Reason:	The reason for these changes is that a default gateway on a switchroute cannot be used, and monitoring on switchroutes does not work.

Two new default proposal lists added
Change:	As of v8.60.01, two new proposal lists, ike-default and esp-default, are added in the list of default proposal lists. To get these new proposal lists, a new installation of the Firewall Manager is needed.
Reason:	These proposal lists are more fine-tuned to the refined IPSec engine than the old default proposal lists.

Firewall Manager Problems Solved

CRL setting for CA certificates overwritten by manager
Issue:	The firewall Manager does not handle NO_CRLS flag on certificates.
Results:	If NO_CRLS flag was is set for a CA certificate via text mode configuration and the Security Gateway is reconfigured via the manager, the NO_CRLS flag will be disabled. The result of this is that certificates that should not validate with CRL tries to do so after reconfiguration.
Affects:	Firewall Manager v8.60.00
Solution:	Solved in v8.60.01

Real-time Logger and Remote Console may crash in Firewall Manager.
Issue:	The firewall manager may crash when text output from the Real-time Logger or Remote Console is copied to clipboard and the window contains lots of data.
Results:	The firewall manager may crash.
Affects:	Firewall Manager v8.00.00 and up
Solution:	Solved in v8.60.01

The firewall manager crashes if a user clicks in the authentication column for a IPsec tunnel
Issue:	If a user clicks (or press F2) in the authentication column in the grid with IPsec tunnels, the Firewall Manager will crash.
Results:	The firewall manager will crash.
Affects:	Firewall Manager v8.60.00
Solution:	Solved in v8.60.01

Firewall Manager cannot remove integrity algorithms from proposal lists
Issue:	If a user removes one of the integrity algorithms (SHA1 or MD5) for an ike or ipsec proposal list, the Firewall Manager will remove it correctly when saving it to the configuration file. The change is however not reflected to the Security Editor in the Firewall Manager, and if the configuration is saved a second time, the integrity algorithm previously removed will be written down again.
Results:	The integrity algorithm previously removed will be written down again at the next check-in.
Affects:	Firewall Manager v8.60.00
Solution:	Solved in v8.60.01

It is not possible to add routes to the "core" interface
Issue:	It is not possible to add a route to the "core" interface via the Security Editor.
Results:	Cannot add or choose the "core" interface for a route.
Affects:	Firewall Manager v8.00.00 and up
Solution:	Solved in v8.60.01
Note:	A user can add a single-host route via the "core" interface to enable the firewall to respond to an extra ARP published IP.

IPSec/IKE Proposals are written down to configuration file in the wrong order
Issue:	The firewall manager writes down IPSec/IKE proposals in the wrong order.
Results:	Security Gateways running older cores than 8.60.00 will get the wrong ordering of IPSec/IKE proposals in the configuration file. This may lead to the wrong proposal being selected first.
Affects:	Firewall Manager v8.60.00
Solution:	Solved in v8.60.01

Problems with switchroutes in PBR tables
Issue:	The firewall manager cannot correctly add switchroutes in PBR tables.
Results:	The firewall manager will convert the switchroute to a normal possibly invalid route.
Affects:	Firewall Manager v8.60.00
Solution:	Solved in v8.60.01

Erroneous warning displayed
Issue:	The firewall manager displays an incorrect warning about PSKs and ID-lists
Results:	When uploading a configuration using ID-lists, an erroneous warning is displayed, complaining about PSKs and ID-lists.
Affects:	Firewall Manager v8.60.00
Solution:	Solved in v8.60.01

Security Gateway Core Changes

IPSec NAT-traversal behaviour changed
Issue:	As of 8.60.00, IPSec NAT-traversal behaviour has changed.
Change:	NAT-traversal behaviour now follows RFC 3947, section 6, which says that when a client connects to the Security Gateway, all SAs associated with the same ID payload SHOULD be removed. This is true when two or more clients behind the same NAT gateway connect using the same ID and PSK/certificate.
Note:	Security Gateway versions before 8.60.00 did NOT remove all SAs associated with the same ID payload.

Packets with disallowed source Ethernet addresses are now dropped when using Transparent Mode

Issue:

As of 8.60.00, the Security Gateway would accept and forward packets according to the rule set with unchanged Ethernet header when Transparent Mode is used, even if the source Ethernet address would be illegal.

Change:

As of 8.60.01, the following changes are made for traffic received on interfaces where Transparent Mode is used:


»	Packets with nulled out sender Ethernet address (0000:0000:0000) are never allowed. The new advanced setting NullEnetSender can however be used to specify if such packets should be logged or not. (Default: DropLog)

»	The new setting BroadcastEnetSender specifies what to do with packets with the sender Ethernet address set to the broadcast Ethernet address (FFFF:FFFF:FFFF). (Default: DropLog)

»	The new setting MulticastEnetSender specifies what to do with packets with the sender Ethernet address set to a multicast Ethernet address. (Default: DropLog)

Note:

When Transparent Mode is not used, the Security Gateway doesn't care about the Ethernet sender as that address is never used. One exception is ARP packets; The setting ARPMatchEnetSender might demand that the address in Ethernet and ARP headers match.

New advanced settings for forwarded ARP traffic when Transparent Mode is used

Issue:

In 8.60.00 there was no way to configure the behaviour of ARP transaction states.

Change:

As of 8.60.01, there are two new settings that can be used to modify the behaviour of ARP transaction states:


»	Transparency_ATSExpire, Lifetime of an unanswered ATS entry in seconds (Default: 3)

»	Transparency_ATSSize, Number of ATS entries, total (Default: 4096)

As of 8.60.01, the following ARP settings now also applies for ARP traffic forwarded when using Transparent Mode:


»	ARPMatchEnetSender, If the Ethernet Sender address does not match the hardware address in the ARP data (Default: DropLog)

»	ARPQueryNoSenderIP, If the IP source address of an ARP query (NOT response!) is 0.0.0.0 (Default: DropLog)

»	ARPSenderIP, The IP Source address in ARP packets (Default: Validate)

»	ARPMulticast, ARP packets claiming to be multicast addresses; may need to be enabled for some load balancers / redundancy solutions (Default: DropLog)

»	ARPBroadcast, ARP packets claiming to be broadcast addresses; should never need to be enabled (Default: DropLog)

Note:

Security Gateway Core Problems Solved

IPSec Config Mode IP pool problem
Problem:	The IP pool used by Config Mode does not wrap correctly when all IPs have been used once.
Results:	The authentication will fail as there is no IP available to hand out in the Config Mode negotiation.
Affects:	Clavister Security Gateway v8.60.00
Solution:	Solved in v8.60.01.

Problems with reconfiguration when using a license allowing only a few IPSec tunnels
Problem:	If the number of configured IPSec tunnels have reached the license limit, and the Security Gateway is reconfigured with a new configuration containing changes on these IPSec tunnels, the reconfiguration will fail with a "Failed to create tunnels" error message.
Results:	The configuration will fail and a "Failed to create tunnels" error message will be shown.
Affects:	Clavister Security Gateway v8.60.00
Solution:	Solved in v8.60.01.

Multiple entries may be added in the layer 3 cache for a host if Transparent Mode is configured
Problem:	If Transparent Mode is enabled and a single host switchroute is configured, multiple entries may be added for that host in the layer 3 cache.
Results:	This will potentially fill up the layer 3 cache and force random removal of layer 3 cache entries. This may slow down transparent handling of other switched hosts and networks.
Affects:	Clavister Security Gateway v8.60.00
Solution:	Solved in v8.60.01.

Certificate setting to not validate with CRL is lost after reconfiguration
Problem:	Certificates configured not to validate with CRLs forget this setting after reconfiguration.
Results:	Certificate that should not validate with CRL tries to do so after reconfiguration.
Affects:	Clavister Security Gateway v8.60.00
Solution:	Solved in v8.60.01.

Memory leakage using hardware crypto accelerator in SG3100-series
Problem:	In 8.60.00, memory leakages can occur when the SG3100-series appliances hardware accelerator is used for IPSec traffic.
Results:	The memory usage of the system will increase until the system finally is out of memory, forcing a reboot of the Security Gateway.
Affects:	Clavister Security Gateway SG3100-series, core v8.40.00 and up
Solution:	Solved in v8.60.01.

SG50-series appliances may fail to restart after software issued reboot or core crash.
Problem:	SG50-series appliances that restarts due to software issued reboot or a core crash may fail to restart correctly, leaving the unit unreachable.
Results:	The unit may fail to reboot correctly and become unreachable. The only way to reboot it correctly from this unreachable state is to do a hard reboot by cutting the power and then put the power back on.
Affects:	Clavister Security Gateway SG50-series, core v8.60.00
Solution:	Solved in v8.60.01.
Note:	Note that SG50-series users with units delivered with core version 8.60.01-RC1 as factory default are highly recommended to upgrade the firmware to the version supplied with the 8.60.01 release. Upgrade to core version 8.60.01 before upgrading the firmware.

L2TP client/server does not send a unique hostname during negotiations
Problem:	In 8.60.00 the L2TP client/server sent an empty hostname during negotiation with the other peer.
Results:	L2TP clients/servers that rely on the other peer to send a unique hostname may have problems negotiating with Clavister Security Gateways.
Affects:	Clavister Security Gateway v8.50.00 and up
Solution:	Solved in v8.60.01.
Note:	The hostname can be configured using the advanced setting SNMPSysName.

MTU problems over IPSec interfaces
Problem:	In 8.60.00 IPSec interfaces did not handle packets tagged with the "Don't Fragment" flag correctly.
Results:	Peers trying to do Path MTU Discovery will have their packets dropped by the Security Gateway due to a faulty IP header checksum.
Affects:	Clavister Security Gateway v8.60.00
Solution:	Solved in v8.60.01.

Link status problems on SG50-series LAN interfaces
Problem:	In 8.60.00 the link status shown in the console for the SG50-series LAN interface could be wrong after reconfiguration.
Results:	Wrong link status will be displayed after reconfiguration when the ifstat command is used on the LAN interface of the SG50-series.
Affects:	Clavister Security Gateway SG50-series v8.60.00
Solution:	Solved in v8.60.01.

Problems sending LDAP traffic over IPSec tunnels
Problem:	In 8.60.00 there was a problem with LDAP traffic being blocked when sent over IPSec tunnels.
Results:	LDAP traffic will be dropped in the IPSec tunnel.
Affects:	Clavister Security Gateway v8.60.00
Solution:	Solved in v8.60.01.

Tulip interface driver problems
Problem:	In 8.60.00 the tulip driver may in some conditions crash during reconfiguration.
Results:	The Security Gateway will reboot.
Affects:	Clavister Security Gateway v8.60.00
Solution:	Solved in v8.60.01.

SLB monitoring problems
Problem:	In 8.60.00 the SLB TCP monitoring does not work on all ports.
Results:	SLB monitoring will not work for all configured ports.
Affects:	Clavister Security Gateway v8.60.00
Solution:	Solved in v8.60.01.

Promiscuous mode is enabled by default on all interfaces
Problem:	Promiscuous mode is enabled by default on all interfaces.
Results:	The Security Gateway will pick up packets that do not have the Security Gateway as destination, leaving the Security Gateway to process packets that will be dropped anyway.
Affects:	Clavister Security Gateway v8.60.00
Solution:	Solved in v8.60.01.

Calling the shutdown console command does not always restart the core
Problem:	In 8.60.00 the shutdown console command does not always make the Security Gateway restart the core.
Results:	The Security Gateway will not restart the core. The only way to restart the Security Gateway is by turning off the power and then turning it on again.
Affects:	Clavister Security Gateway v8.60.00
Solution:	Solved in v8.60.01.

Transparent Mode feature can cause memory leakage
Problem:	When Transparent Mode is used memory leakage can occur in some scenarios.
Results:	If excessive amounts of memory are consumed to the point that the system is out of memory, the Security Gateway will eventually cease to work correctly and finally reboot.
Affects:	Clavister Security Gateway v8.60.00
Solution:	Solved in v8.60.01.

ARP handling in Transparent Mode incompatible with Microsoft Network Load Balancing
Problem:	Microsoft NLB sends ARP queries with a source MAC address in the ARP data that differs from the source address in the Ethernet header. The Security Gateway only allows ARP responses sent to the MAC address found in the Ethernet header of the ARP query.
Results:	When hosts on the other side of the Security Gateway sends ARP responses to the MAC address found in the ARP data the responses are dropped instead of forwarded back to the original querier.
Affects:	Clavister Security Gateway v8.60.00
Solution:	Solved in v8.60.01.

Filtered "conn" console command displays wrong number of not shown connections
Problem:	When using a filtered "conn" console command, the printout of the number of not shown connections is wrong.
Results:	The number of not shown connections is not the number of not shown filtered connections, but the total number of connections not shown.
Affects:	Clavister Security Gateway v8.50.00 and up
Solution:	Solved in v8.60.01.

IPSec keepalive does not work
Problem:	In 8.60.00 IPSec keepalive does not work.
Results:	The IPSec tunnel will be taken down as no response is received on the keepalive packets.
Affects:	Clavister Security Gateway v8.60.00
Solution:	Solved in v8.60.01.

IPSec tunnels using ID-lists may fail to be re-authenticated after being taken down
Problem:	In 8.60.00, IPSec tunnels using ID-lists may fail to be re-authenticated after being taken down if a reconfiguration was done in between.
Results:	The establishment of the IPSec tunnel will fail.
Affects:	Clavister Security Gateway v8.60.00
Solution:	Solved in v8.60.01.

Security Gateway does not complain if private key file is not understood
Problem:	If an incompatible private key file is uploaded to an 8.60.00 Security Gateway, the user is not informed that the private key cannot be used.
Results:	The Security Gateway will ignore the private key.
Affects:	Clavister Security Gateway v8.60.00
Solution:	Solved in v8.60.01. A configuration error is now generated if the private key file is not understood.

IPSec re-keying fails
Problem:	With some clients, the Security Gateway will fail to re-negotiate IPSec policies.
Results:	The IPSec tunnel will be taken down completely and a new negotiation will take place instead of a re-negotiation.
Affects:	Clavister Security Gateway v8.60.00
Solution:	Solved in v8.60.01.

IPSec re-configuration problems
Problem:	If a new configuration containing more IPSec tunnels than before is uploaded to the Security Gateway, the Security Gateway may in some cases fail to read the configuration and reboot.
Results:	The Security Gateway will reboot.
Affects:	Clavister Security Gateway v8.60.00
Solution:	Solved in v8.60.01.

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.