Upgrades

Release notice for Ingate Firewall® 4.3.1 and Ingate SIParator® 4.3.1

The new version can be found here

Security improvements

     * Improved stateful inspection to meet ICSA requirements.

          * For each normal packet traversing the Ingate product only a
            single ICMP error packet is allowed back through the product.
            This prevents replay attacks.
          * More thorough TCP packet inspection. Now the sequence numbers as
            well as the TCP window are properly tracked and verified. This
            prevents spoofed packets with invalid sequence numbers from
            traversing the Ingate or modifying the internal state of a TCP
            connection.
          * Better resistance against SYN floods and attacks trying to fill
            up the internal state table with incomplete connections.

       [Tracking ID: 2114]
     * An issue with terminating media sessions has been resolved. Previously
       media ports could remain open after a call had completed. [Tracking
       IDs: 742, 958]

New SIP functionality

     * Handling of media streams has been optimized offering higher
       performance i.e. increased number of simultaneous calls and improved
       call setup time, and minimizing the risk of dropping media packets in
       the beginning of a call. [Tracking ID: 57]
     * A SIP Advanced Routing module is now available. This module allows the
       SIP module to perform advanced SIP routing. The old Static Domain
       Modification table which provided similar but much simpler
       functionality has been removed. The SIP Advanced Routing module
       contains:

          * Matching on From header (username and domain).
          * Matching on Request-URI (username and domain).
          * An option to rewrite the Request-URI when forwarding the message.
          * Additional options to reject or allow SIP requests.
          * The ability to perform ENUM lookup and forward messages.
          * The ability to define various things per registered user:

               * Aliases.
               * Forwarding in sequence or parallel etc.
               * Forwarding to voice mail.
               * Limiting incoming calls to a common white list.

          * And more.

       [Tracking IDs: 390, 473, 1030, 1432, 1580]
     * SIP authentication is somewhat changed. The authentication Group table
       has been removed and authentication is now defined per method in the
       Method table. Additionally a new column is introduced which makes it
       possible to allow or disallow methods. Methods not included in the
       table are not handled by the SIP module. [Tracking ID: 1031]
     * Support for sending RADIUS accounting ticks.
       The SIP module may now be configured to enable sending of start and
       stop ticks (see IETF RFC 2866) to an accounting server. These ticks
       can be used to construct CDRs. Currently ticks are only sent for
       sessions that have media which traverses the Ingate product. [Tracking
       ID: 560]
     * Support for terminating encrypted RTP media streams.
       There is now support for terminating RTP media streams created by
       Microsoft Windows Messenger. The allowed type of media streams
       (encrypted or cleartext) can be configured per interface. [Tracking
       ID: 1036]
     * MIME multipart bodies are now supported. [Tracking IDs: 2023, 2119]
     * Matching users may now be done using both username and domain name.
       Previously only username was used. An interoperability setting has
       been added to enable full matching, but is disabled by default.
       [Tracking IDs: 86, 1172]
     * It is now possible to define a user "*" in the user table when
       authentication is active. [Tracking ID: 579]
     * An interoperability setting has been added to disable that IP
       addresses of the interfaces of the Ingate product are treated as
       locally handled domains. [Tracking ID: 1544]
     * More information about each active media stream is displayed in the
       SIP Active Sessions table in the GUI. [Tracking IDs: 14, 1651]
     * The port that SIP packets are sent to or received from is now logged.
       [Tracking ID: 1894]
     * An interoperability setting has been added to enable removal of
       Record-Route and Contact headers in 180 responses. This was previously
       always done. [Tracking ID: 2057]
     * An interoperability setting has been added that controls if large UDP
       packets should be sent as UDP packets (fragmented) or be sent using
       TCP. [Tracking ID: 1897]
     * An interoperability setting has been added to handle TLS accelerators.
       Enabling this allows the Ingate product to accept incoming TCP
       requests with a Via header indicating TLS. [Tracking ID: 2029]
     * A column for defining the order of SIP proxy rules has been added.
       [Tracking ID: 29]
     * An interoperability setting has been added to allow the Ingate to
       always add a Record-Route header to incoming SIP messages. [Tracking
       ID: 981]

Other new functionality

     * VLAN IEEE 802.1Q is now supported.
       In the Ingate product GUI, virtual LANs are defined by a physical
       interface and a VLAN tag. These virtual interfaces may then be used or
       selected in addition to physical interfaces. [Tracking ID: 368]
     * Support for redundant default routes. In order to improve
       availability, redundant service providers may be connected and
       multiple default routes may be specified. A working route will be
       selected and monitored. If that route goes down the Ingate product
       will be updated to use a another default route. [Tracking ID: 360]
     * Support for recording PCAP logs is introduced. These logs can be
       downloaded from the Ingate and may be analyzed in e.g. the Ethereal
       program. [Tracking ID: 1794]
     * The Ingate SNMP MIB has been extended with:

          * Unit serial number.
          * Fan speeds (where applicable).
          * SIP registrations.
          * SIP media sessions.

     * The following SNMP traps have been added:

          * Failed sending logs via email.
          * Fan speed goes below the minimum allowed speed (where
            applicable).
          * Malfunctioning power supply (in a machine with multiple PSUs).
          * Malfunctioning log disk (in a machine with both hard disk and
            compact flash).
          * The number of concurrent SIP sessions rises above an
            admin-configurable limit.
          * The number of concurrently registered SIP users rises above an
            admin- configurable limit.
          * The CPU load rises above an admin-configurable limit.
          * The memory utilization rises above an admin-configurable limit.

       [Tracking IDs: 1446, 1668]
     * A new administrator user type, "VPN Renegotiator", is introduced. This
       is a user that is only allowed to renegotiate VPN tunnels. [Tracking
       ID: 1774]
     * The functionality of the LCD display (only available on some models)
       has been augmented. It is possible to assign an initial IP address to
       the machine using the LCD display. The user can enter an interface, IP
       address and netmask. (Configuration (using web interface) will be
       allowed from the whole given network, the password will be cleared,
       and all other interfaces disabled.) It is also possible to become a
       failover slave, and to exit a failover team, using the LCD display.
       The default view of the display now includes current CPU usage and
       current time. [Tracking ID: 1682]
     * Ethernet port status (link/speed/duplex) is now displayed in the GUI.
       [Tracking ID: 400]
     * Ethernet MAC addresses are now displayed in the GUI. [Tracking ID:
       1657]
     * Log time stamps now have millisecond resolution. [Tracking ID: 439]
     * The Ingate GUI now displays all optional modules. The ones lacking a
       proper installed license will not be enabled. [Tracking ID: 1704]

Fixed SIP-related problems

     * The first UDP media packet is no longer dropped. [Tracking ID: 1118]
     * A problem with terminated SIP sessions that under some circumstances
       remained active in the SIP session output in the GUI has been fixed.
       [Tracking ID: 1202]
     * A problem with rewriting the Request-URI in handling of 302 (Moved
       temporarily) messages has been fixed. [Tracking ID: 1664]
     * A problem handling domain names in the Via header has been fixed.
       [Tracking ID: 1852]
     * A problem with Remote SIP Connectivity has been fixed. When Remote SIP
       Connectivity was disabled while NATed clients were registered, the
       Ingate accidentaly flooded the clients with OPTIONS requests.
       [Tracking ID: 1966]
     * Avoid encryption of contact header in some redirection situations.
       [Tracking ID: 2041]
     * A problem causing one way media related to receiving 183 and 200
       responses with differing port allocations in their SDPs has been
       fixed. [Tracking ID: 2118]
     * A problem related to a missing Content-Length header in REGISTER
       messages to local domains/IP addresses has been fixed. [Tracking ID:
       2184]
     * The SIP module is now fully interoperable with the 3Com VCX server
       versions 6 and 7. [Tracking ID: 2247]

Other fixed problems

     * An issue causing periodic performance drops has been fixed. The issue
       is related to using the DHCP client on the Ingate which periodically
       updates its lease. It updated the configuration of the Ingate more
       often than needed. [Tracking ID: 2052]
     * A problem with not logging unrelated ICMP redirects (type 5) has been
       fixed. [Tracking ID: 2060]
     * A problem using RADIUS authentication of users causing randomly chosen
       users not being able to authenticate has been fixed. [Tracking ID:
       2272]
     * PPTP tunnels could crash on bulk data transfers. A fault in the code
       handling out of order packets could cause a PPTP tunnel to crash when
       receiving such packets. This frequently happens when a client sends
       large amounts of data through the tunnel.

Known problems

  Known security problems

     * A vulnerability for XSS exploits have been found.
       The security cookie used for accessing the web interface of the
       product may be stolen and used for logging in to the product from a
       host or network configured to be accepted for configuration.
       The attack requires knowledge about the IP address of the Ingate
       product in use. The administrator must be tricked to follow a link on
       a malicious web site using the same client and browser he or she uses
       for accessing the Ingate product. This may enable the malicious site
       to steal the cookie without the administrators notice. The timing of
       the theft is critical, since the security token has a limited lifetime
       of 10 minutes. The administrator must follow a link on the malicious
       site within 10 minutes after accessing the Ingate product, or the
       attack will fail. [Tracking ID: 2174]
       Workaround:
       To minimize the risk of this happening Ingate recommends that access
       control setup in the Ingate product is kept as tight as possible. Only
       internal networks, trusted VPN tunnels or specific IP addresses should
       be allowed to configure the Ingate product. Additionally it is
       important to always log out before accessing other sites.

  Known VPN-related problems

   These problems are only relevant if IPsec or the built-in PPTP server is
   used.

     * 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]
     * In order to properly remove an IPsec CA the firewall needs to be
       rebooted. [Tracking ID: 1178]
       Workaround:
       Disable all IPsec peers and apply the configuration. This will clear
       all previous IPsec state. Then enable the peers and apply the
       configuration again.

  Known SIP-related problems

   These problems are only relevant if the SIP module is enabled.

     * The SIP module may block while it waits for RADIUS authentication.
       This effectively means that only RADIUS servers located on a LAN
       should be used. Additionally the RADIUS server should preferably not
       enable any brute force attack prevention mechanism that delays the
       response in case of a faulty username/password combination. [Tracking
       ID: 1425]
     * Selecting transport '-' in Static Forwarding should mean that standard
       procedures are followed to determine transport but currently means
       same as selecting 'UDP'. [Tracking ID: 2043]
     * SIP accounts available with the Advanced SIP Routing module do not
       handle media correctly in cases where media passes the Ingate.
       [Tracking ID: 2334]

  Known Failover-related problems

   This problem is only relevant if failover is used.

     * 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]