Upgrades

• DoS hole in OpenSSL CA-2003-26. [Tracking ID: 959]
  If SIP TLS, HTTPS configuration, or IPsec RADIUS authentication was enabled, there was a possibility that an attacker could cause one of those functions to crash and restart or stop working.

• Interoperability with Microsoft Live Communication Server.
• Added support for loose routing of SIP messages. [Tracking ID: 454]
  The SIP module now implements loose routing according to RFC 3261.
• It is now possible to have several administration accounts. Each account may have different access rights and password. [Tracking ID: 318, 1046]
• Default administration password removed. [Tracking ID: 823]
  Upon first local access to the firewall/SIParator the administrator is forced to set a password.

• Support multiple senders on a stream. [Tracking ID: 103]
  This is a new setting on the SIP sessions page. It is now possible to configure if the Firewall/SIParator should lock the media stream to the first sender or allow multiple senders.
• Presence did not work right with TLS or TCP in Microsoft Windows Messenger. [Tracking ID: 243]
  Presence now works for both Microsoft Windows Messenger 4.7 and 5.0 when registered locally at an Ingate Firewall®/SIParator.
• When using NAT, record-route headers were removed from messages sent by an internal sip server. [Tracking ID: 837]
  Record route headers are now kept when a SIP message is NATed.
• The SIP port range is now configurable on firewalls also. [Tracking ID: 613]
  It is now possible to configure what ports the SIP module should use when allocating pinholes for SIP media on an Ingate Firewall®.
• Microsoft Windows Messenger did not work without NAT. [Tracking ID: 646]
  If NAT wasn't used and Windows Messenger used a non-default SIP port in the contact header, subsequent requests would be blocked. This is solved by NATing the contact header in those cases.
• All "Static Forward":ed requests were sent using UDP [Tracking ID: 817]
  It is now possible to configure what transport protocol to use when a request is forwarded using the rules from the "Static Forwarding" table on the "External SIP Servers" page. A correct entry would be:
  ingate.com --> 192.168.0.1;transport=tcp
  which would force the SIP module to forward all SIP requests to ingate.com to the IP address 192.168.0.1 using TCP.
• The branch parameter of Via the header did not include the magic cookie. [Tracking ID: 923]
  According to RFC 3261, the branch parameter of the Via header, added by a RFC 3261 compliant proxy, should start with "z9hG4bK". This is now done.
• The parameters of the request URI were dropped after static domain modification has been applied to the request. [Tracking ID: 965]
  Parameters are now kept when "Static Forwarding" is used.
• The entire Contact header was encrypted - including parameters. [Tracking ID: 987]
  When the firewall/SIParator received a SIP message which should be forwarded to a server/client from a NAT:ed network, it encrypted the entire Contact header, including any parameters, such as the Replaces parameter. Parameters and query parameters are now kept.
• Pass-through registrations were not removed. [Tracking ID: 1048]
  Pass-though registrations when registrered on an external registrar are now correctly removed.
• The LCS does not accept more than one Via header when using TLS. [Tracking ID: 1081]
  The Microsoft Live Communication server does not like multiple Via headers in certain scenarios. If the IP of a Server is added to the "Remove Via headers" table on the "External SIP Servers" page all requests sent to that IP will only contain one Via header. When a response gets back to the SIP module the previous Via headers will be reapplied to the SIP message.
• Improved SIP logging [Tracking ID: 612, 780]
  All IP addresses are logged in readable format, not in hex. Encoded SIP-URIs are decrypted and logged.

• MTU for PPTP links was set inappropriately. [Tracking ID: 1010]
  The firewall used to set the MTU for PPTP links to a lower value than what was negotiated with the client. This caused problems with TCP links through devices that block PMTU.
• CRLs could not be imported if the language was set to Swedish. [Tracking ID: 1032]
• It is now possible to change the administration password for the admin account from the serial console. [Tracking ID: 1001]
• HTTP configuration was not enabled after setting factory default. [Tracking ID: 522]
  If the machine was configured to allow HTTPS configuration only, HTTP was not enabled after setting factory default.
• If the network 0.0.0.0/0 was specified as a remote tunneled network, and "Allow subset" was not enabled, the builtin DHCP client would reject all IP addresses. [Tracking ID: 1121]

• 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]
• Running PPTP inside an IPsec tunnel where both tunnels share an Ingate Firewall® as endpoint may fail when a PPTP client leases an IP address of the IPsec tunnel. Always activate or configure the IPsec tunnel prior to the PPTP server. [Tracking ID: 984]
• CRL files are not removed unless the firewall/SIParator is rebooted. [Tracking ID: 1024]
  To remove the CRL file the following procedure should be followed: Remove the CA certificate and apply. Reinstall the CA certificate and reboot.

• 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]
• No Instant Messaging using Microsoft Windows Messenger 5.0 when registered on an Ingate Firewall®. [Tracking ID: 924]
  Instant Messaging between two Microsoft Windows Messenger 5.0 does not work if TLS is not used, when registered locally on an Ingate Firewall®/SIParator.
• DMZ SIParators should not specify networks with disabled interfaces on the surroundings page. Doing so should normally cause the SIParator to ignore that network, but it will currently ignore the specified interface instead and use the IP addresses in the network. This only affects uses of networks on the surroundings page. [Tracking ID: 1128]

• 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 the 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]