UpgradesRelease notice for Ingate Firewall® 4.2.1 and Ingate SIParator® 4.2.1
| Release name: |
Ingate Firewall® 4.2.1
Ingate SIParator® 4.2.1 |
The new version can be found here
Security improvements
* TCP packets with both SYN and FIN flags set are now dropped and logged
by the firewall. [Tracking ID: 1486]
* Packets to or from port 0 are now dropped and logged by the firewall.
[Tracking ID: 1658]
New SIP functionality
* A VoIP Survival Module is now available.
Typically the Voip Survival module is used by customers deploying SIP
in a hosted configuration. In case of a broken WAN connection or
server failure the VoIP survival feauture provides support for
site-local SIP and PSTN routing. [Tracking ID: 1037]
* Remote SIP Connectivity Module
The functionality of this module has been improved. Support has been
added for internal and external SIP servers. [Tracking ID: 1183]
* Ingate QoS is now available for Ingate SIParators. [Tracking ID: 252]
* The SIP module may now be configured to do a DNS SRV query instead of
a DNS A query when looking up the IP address of the outbound proxy. If
the outbound proxy port is not set a DNS SRV query is done, otherwise
a DNS A query is done. [Tracking ID: 976]
* The information stored in the additional section of a DNS reply will
now be stored in the local DNS cache. This applies to A records and
SRV records. [Tracking ID: 481]
* A SIP compatibility option has been added that allows the Refer-To
header to include a "?" without being surrounded by angle brackets.
[Tracking ID: 1751]
* A SIP compatibility option has been added that allows IP addresses,
which should never be NATed, to be specified. [Tracking ID: 1762]
* Windows Messenger file transfer can now be supported when NAT is used.
The file transfer function is hardcoded to always use port 6891
instead of the port specified in the SIP message. There is now a
compability option that makes the Ingate always allocate port 6891 for
all file transfers. [Tracking ID: 1662]
New VPN functionality
* The Ingate VPN module is now included by default. After the upgrade, a
unit without VPN will have the Ingate VPN module installed.
* Easier configuration of IPsec tunnels.
It is now possible to configure a road warrior to be allowed to use
"any private address, which is not part of a directly connected or
statically routed network" with a single line in the IPsec tunnels
table. Also the local and remote networks are now selected from a list
of user-defined networks, instead of manually entered for each tunnel.
[Tracking ID: 1464]
New firewall functionality
* Support for PPTP passthrough has been added.
There is now a new firewall type called Dynamic PPTP Management, which
handles stateful inspection and NAT for PPTP connections. [Tracking
ID: 684]
* Support for DynDNS.org dynamic DNS services has been added.
The Ingate Firewall can be configured to automatically update DNS
names handled by DynDNS.org when its IP address changes. [Tracking ID:
449]
Other new functionality
* The web interface is now better protected against brute force attacks.
An increasing delay between consecutive faulty attempts to log in has
been introduced. [Tracking ID: 1766]
* The web server now uses a cookie to store the login token.
If cookie support is detected in the browser when the user first logs
in, a cookie will be used to store the login token instead of storing
it in the HTML code or the URL. The login token is still time limited
as before, and the cookie is deleted either when the browser is closed
or when the user logs out. [Tracking ID: 1637]
* Improved handling of administration interface logins.
The Ingate now keeps track of active and idle logins, and it is
possible to view other administrators logged in to the administration
interface. Administrators with Full Access rights may also force
logout of other administrators. [Tracking ID: 1558]
* It is now possible to explicitly log out from the administration
interface. Previously a generated login token was always valid during
a 10 minute period. Now it is possible to log out so that any token
previously generated for the session is rendered invalid. [Tracking
ID: 1044]
* The active unit in a failover pair now alerts when contact with the
standby unit is lost. [Tracking ID: 628]
* Information about installed patches are now presented in the GUI.
[Tracking ID: 445]
* Logging of various failover events has been added. [Tracking ID: 725]
* Pressing the FD/Config button at boot is now logged. [Tracking ID: 1]
* Boot-time power supply failures are now logged for units with multiple
power supplies. [Tracking ID: 914]
* Log messages regarding administration of the unit now include IP
address.
The IP address from which the administrator is logged in is now
included in administration log messages. [Tracking ID: 1691]
* The order in which DNS and WINS servers are used can now be specified.
[Tracking ID: 1555]
* Information from a failed future upgrade attempt will be displayed on
the Administration/Upgrade page. [Tracking ID: 1579]
Fixed SIP-related problems
* Handling of expires parameters in the Contact header has been changed
so that Windows Messenger can understand them. [Tracking ID: 393]
* Fixed problem with certain configurations with Live Communication
Server using TLS as transport. [Tracking ID: 1374]
* Loop detection has been re-enabled (it was disabled in 4.1.3).
[Tracking ID: 1474]
* The IP address 0.0.0.0 is no longer used in Via headers. This address
was previously used to indicate that an internal address was hidden.
From now on the IP address of the outside interface is used instead.
[Tracking ID: 1478]
* Problems in handling multiple 200 OK related to one INVITE has been
fixed. [Tracking ID: 1509, 1665]
* Static forwarding can now be used to route REGISTER requests which
would otherwise be handled locally. [Tracking ID: 1544]
* Problems that caused certain configurations with Remote SIP
Connectivity and external SIP servers to fail have been fixed.
[Tracking ID: 1566]
* The expires header value is now rewritten using the maximum value of
all expires parameter values. This is an interop fix for several
clients that don't understand the expires parameter. [Tracking ID:
1753]
* A problem related to sending SIP messages using TCP as transport and
certain load conditions has been fixed. [Tracking ID: 1889]
Fixed VPN-related problems
* IPsec peers using dynamic DNS lookup are now always shown on the IPsec
status page. Previously such peers were not shown on the status page
while waiting for the DNS lookup to succeed. [Tracking ID: 1427]
* Spoof protection for IPsec tunnels corrected.
When a directly connected or statically routed network is a subset of
an IPsec remote network, traffic from the subset network used to be
caught by the IPsec spoof protection. Such traffic is now allowed.
[Tracking ID: 1569]
* Better error checking for inconsistent tunnel configurations.
It is now forbidden for remote networks to overlap with directly
connected networks when "allow subsets" is enabled. If such a
configuration is currently used to handle NATed road warriors, those
tunnels must be removed before upgrading. After upgrading the method
described under "Easier configuration of IPsec tunnels" above should
be used for road warriors. It is also now always forbidden for remote
networks to be identical to a directly connected network. [Tracking
ID: 1569]
* The PPTP server now supports Path MTU Discovery.
Previously when the PPTP server received an ICMP "Fragmentation
needed" packet from a router in response to a PPTP GRE packet, it used
to disconnect the corresponding tunnel. It now handles such packets
correctly and will decrease the packet size for subsequent GRE packets
to that peer. [Tracking ID: 1783]
Other fixed problems
* Log searches no longer blocks the web interface for other operations
while in progress. [Tracking ID: 1557]
* For failover pairs, detection of a broken dedicated network has been
added. [Tracking ID: 807]
* Improved error checks for inconsistent configurations.
Known problems
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.
* Active PPTP tunnels to an Ingate Firewall are not terminated when a
PPTP user is disabled or removed.
If a user has an active PPTP connection to an Ingate Firewall, and
that user is disabled on the Firewall, the active PPTP connection is
not disconnected, but lives on unharmed. Any new connection attempts
are however blocked as expected. [Tracking ID: 1826]
Workaround:
When you disable a PPTP user, also turn off the PPTP server and apply
the configuration. This will tear down all PPTP connections. Then
enable the PPTP server and apply the configuration again.
Known SIP-related problems
These problems are only relevant if the SIP module is enabled.
* If you change the maximum number of users or registrations per users,
the new settings won't be active until the SIP module has been
restarted. [Tracking ID: 53]
* 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]
* Active Sessions may under some circumstances not be directly removed.
The session is in such a case not removed at the instant when the call
ends. Instead the session is removed at the configurable session
timeout. This will lead to temporary unnecessary allocations of memory
and in some cases temporary unnecessary media-stream (firewall rules
for media) allocations. [Tracking ID: 1202]
* 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]
* The combination of Remote NAT traversal and static registrations does
not work. Typically this problem may show up calling a SIP user that
sits remotely behind a none-SIP-aware NATing firewall from PSTN.
[Tracking ID: 1859]
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]
|
