Upgrades

• If packet filtering for TCP was used, a malicious attacker could send a SYN+RST packet through the firewall in the reply direction. If the destination TCP stack only looks at the SYN flag, this could result in successful establishment of a TCP connection that the firewall should have blocked. [Tracking ID: 832]
• An attacker could crash the firewall if "Dynamic FTP management" rules were used from a NAT:ed network. CVE: CAN-2003-0467. More information is available on the Netfilter site: www.netfilter.org/security/2003-08-01-nat-sack.html [Tracking ID: 821]

• Added PPPoE support. [Tracking ID: 124]
• It is now possible to erase the pending email queue from the "admin" account.
• The configuration can now be saved and loaded via Zmodem on the serial console. [Tracking ID: 789]

• Both the MD5 and SHA-1 fingerprints of X.509 certificates are now displayed. Some VPN products print the MD5 fingerprint, and some the SHA-1 fingerprint. This way, it is possible to check the certificates with either type of product.
• The subject of a CA certificate may not contain a "/". An attempt to import such a certificate is now properly diagnosed. Previous versions could not handle a subject that contained a ",", but that now works properly. [Tracking ID: 809]

• The SIP module could only handle a handful of clients that connects via TCP or TLS.
• Application sharing did not work when url encryption was used. [Tracking ID: 843].
• The SIP module no longer changes port numbers when a re-INVITE is sent on an ongoing session. [Tracking ID: 219]
• Some resources were lost when the firewall was reconfigured while a SIP call was active. [Tracking ID: 578]
• Forked calls could sometimes lead to media in one direction being dropped by the SIP module during the first minute. [Tracking ID: 645]
• It is no longer necessary to restart the SIP module after changing or adding a TLS certificate for SIP. [Tracking ID: 670]
• Interface eth10 and above can now be used for SIP. [Tracking ID: 554]
• Attempts to use "*" in the SIP user table when authentication is on are now reported as an error. It used to fail without an error message. [Tracking ID: 801] (See also tracking ID 579 below under "Known SIP-related problems".)
• Attempts to use "@" in the SIP user table are now diagnosed as an error. [Tracking ID: 815]
• It is now possible to configure the SIP state machine via the parameters "Base retransmission timeout for SIP requests", "Maximum number of retransmissions for INVITE requests" and "Maximum number of retransmissions for non-INVITE requests". For better RFC 3261 compliance, the base retransmission timeout defaults to 0.5 seconds, not 1.0 seconds as it used to do. [Tracking IDs: 574, 581]
• The CSeq check for NOTIFY requests was too strict and sometimes rejected some requests that should have been forwarded.
• If an external registrar is used, and either the built-in SIP module or the external registrar lowers the expire timeout, the new timeout was not properly handled by the SIP module. As a result, the client could believe that it was registered, when in fact it no longer was registered. [Tracking ID: 564]
• Sessions were sometimes reused in a way that caused them to fail, for example if you use Hold and then Resume between two clients on the inside of the firewall and have an external record-routing server.
• As required by RFC 3261, the SIP module now uses only the tags of the To and From headers for dialog identification.
• Attempts to use SIP from an IP address that isn't allowed to do so now returns a "403 Forbidden" rather than "404 Not found" to the client. The reason is logged, to aid debugging. [Tracking ID: 805]
• Several log messages from the SIP module have been improved. [Tracking IDs: 482, 517, 563, 612, 622, 669, 707, 805]
• SIP over TCP and SIP over TLS failed in certain common scenarios. [Tracking ID: 787]
• If failover was used, a SIP registration that should have timed out before the failover event could live forever. [Tracking ID: 818]
• If the SIP module forks an INVITE and a provisional response arrives from one party when the call had already been setup with another party, we now send a CANCEL request as we should. [Tracking ID: 570]
• Support for multiple Contact headers has been added. [Tracking ID: 758]
• Two memory leaks have been fixed.
• If all three of the INVITE, the "200 OK" and the ACK SIP messages contain an SDP, the SIP module could crash. Having 3 SDP:s is not supported by the current SIP standard (RFC 3261) but some equipment that follows older versions of SIP use it. Note: this does not mean that we support 3 SDP:s, only that it no longer crashes the SIP module. [Tracking ID: 759]

• It is now possible to reboot the unit or restart the SIP module from the GUI. [Tracking IDs: 136, 784]
• The settings and status of a failover team was not always mirrored properly to the other part of the team. [Tracking ID: 814]
• High-volume logging of messages via email had some severe performance problems. [Tracking ID: 824]
• When somebody pings the firewall, the ICMP echo reply packet is now logged in the same way as the echo request packet.

• Packets with a destination address that belongs to either end of a tunnel will appear to be encrypted in the log, even when they should not be encrypted. This is a problem with the log only. [Tracking ID: 46]
• The local endpoint must be chosen so that it is the address closest to the next-hop router for that peer. This means that mobile clients must always connect via the same interface (typically the interface connected to the Internet). [Tracking ID: 508]

• If you change the maximum number of users or registrations, the new settings won't be active until the SIP module has been restarted. [Tracking ID: 53]
• It isn't possible to use "*" in the user table when authentication is active. You have to add a row for each explicit user and domain for it to work. [Tracking ID: 579]
• If SIP over TLS is used, the SIP module may under some circumstances block while it waits for a response from the remote SIP client or SIP server. Until this is fixed, there is a risk that enabling TLS for SIP opens up the SIP module for a denial-of-service attack. [Tracking ID: 665]
• Presence does not work when NAT isn't used and the SIP clients use a port other than 5060. [Tracking ID: 646]

• Upgrading a failover team is a complex operation. To upgrade it, you must break the team and upgrade each machine in turn. This will require a number of reboots and network outages. See the separate failover upgrade document which is available on the upgrade web. [Tracking ID: 499]

• It is possible to leave the community fields on the SNMP page blank. For SNMP traps this means that the community string "public" will be used in the trap. If the community string is left blank for SNMP v1 and v2c authentication te error message "Error: missing COMMUNITY parameter" will be written in the log during startup, and you will not be able to access the unit using that method. [Tracking ID: 739]