Release notice for Ingate Firewall® 4.3.4 and Ingate SIParator® 4.3.4 ingate
 

Upgrades

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

Release name: Ingate Firewall® 4.3.4
Ingate SIParator® 4.3.4

The new version can be found here

Security improvements

     * A kernel deadlock issue has been fixed. [Tracking ID: 2447]

Fixed SIP-related problems

     * A problem related to unsupported URI schemes has been fixed. [Tracking
       ID: 2467]
     * Problems related to setup of media streams between a B2BUA server on
       the Internet and a client on the LAN behind the Ingate have been
       fixed. [Tracking ID: 2412]
     * Problems related to media setup in scenarios with a B2BUA SIP server
       that uses re-INVITE to perform media shuffle have been fixed.
       [Tracking ID: 2468]
     * A bug causing the blacklist interval timer to malfunction has been
       fixed. [Tracking ID: 2419]

Other fixed problems

     * Unnecessary updates of flash memory has been removed. This applies to
       Ingate Firewall 1180, 1200 and 1880 as well as Ingate SIParator 18, 20
       and 88. [Tracking ID: 2452]
     * An issue related to using QoS features together with PPPoE has been
       fixed. [Tracking ID: 872]
     * Applying the configuration is now faster, especially in configurations
       with IPsec tunnels. [Tracking ID: 2409]
     * An issue related to NATing statically routed networks has been fixed.
       [Tracking ID: 2353]
     * An issue preventing import of private certificates in PEM format has
       been fixed. [Tracking ID: 2424]

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]

Support?  |  Helpdesk!
Contact us  |  info@ingate.com
How Ingate uses cookies