a device performing Port based Network Address Translation
(PNAT). The ability to turn this feature on/off has been added in both the
"Preferences" tab and in the INI file of the VPNremote Client.
2. Default Policy. Default Policy allows the administrator to create a single
generic VPNremote account that will be used as the basis for all other
accounts when using RADIUS or LDAP as the source of the VPNremote Client
authentication. Once the default policy has been configured in the VSU,
all user accounts can be configured in the RADIUS server, eliminating the
need to create accounts in VPNmanager. The maximum number of characters for
Client usernames is 15 characters when using this feature.
3. Dynamic Assignment of Client Virtual IP, DNS and WINS for VPNremote Client
version 4.1.x. A VSU running VPNos 3.2.15 now can be configured for automatic
assignment of VPNremote Client Virtual IP address, WINS and DNS server IP
addresses. If configured by the VPN administrator, upon authentication the
Client virtual adapter now gets assigned all the required IP addresses to
access secure resources, no longer requiring the user to manually set these
in the TCP/IP properties.
4. High Availability. This new feature offers redundancy between two VSUs of
the same model. When using this feature, the VSUs must not be functioning in
bridging mode; they must be placed in "Block All Non-VPN Traffic" mode.
5. VPNremote Client Authentication message. A VSU running VPNos 3.2.15 now can be
configured to display messages to VPNremote Clients upon authentication.
There are two types of Client messages: forced or display. The administrator
has the ability to choose what type the message should be. This utility can
be used for example to display a legal message regarding company network access
policies (forced) or to inform users of scheduled downtime for network or
server maintenance (display).
5. Additional Troubleshooting tools. Console menu option 36, "Send VSU Info to a file,"
from the VSU Utilities Menu allows an administrator to collect critical VSU data in
one step. The following items have been added to this feature:
Dynamic VPN Display
Address Map Display
Socket Table Display
Reference #2887/2920.
6. A new feature has been added to the VSU console to help force a diagnostic dump for
troubleshooting console lock ups. If the VSU console gets into a state where it
is unresponsive to keyboard input, press Cntl-Break to force a diagnostic dump.
_________________________________________________________________
Section II: Fixes, improvements and changes in Release 3.2.25
_________________________________________________________________
1. The ifOperStatus attribute of each entry in ifTable always reported "up" even when
the associated Ethernet cable was disconnected on a VSU-100 or 2000 (the 5000 and 7500
code was correct). Now ifOperStatus shows "up" when the cable is connected and "down"
when the cable is disconnected. ifLastChange now also contains the sysUpTime value when
the interface in question entered its current ifOperStatus state per RFC 1213.
2. This Service Pack addresses the frequent "IP Address Conflict" messages shown in the
VSU event log. Reference #8627821
The "IP Address Conflicts" were occurring in the following scenario and will no longer
occur with 3.2.25:
1) Several VPNremote users connect (i.e. CCD) to a VSU and start sending and
receiving secure traffic.
2) When users became idle and not actively using their secure connections, VPNremote
retained the IP address assigned by the VSU from the Client IP Address pool.
3) If an administrator made a configuration change, the Client IP Address pool was
re-initialized (i.e. deleting all the dynamic mappings of currently assigned IP
addresses), even though the Client IP Address pool configuration was changed.
4) A new user would connect to the same VSU, the first IP address in the client pool
would be assigned since the client pool was re-initialized due to the configuration
update. This assigned address was the same address assigned to the first user in
step 1 - say user1.
5) Idle user1 would now resume sending secure traffic, using the IP address assigned to
the new user leading to the conflict.
With version 3.2.xx the VSU Client IP Address pool dynamic mapping table is only
re-initialized if the IP address ranges are changed or the dynamic mapping age-out
value is changed.
Note that this code change does NOT address the use case where the unit is rebooted,
consequently re-initializing the Client IP Address pool upon boot up. If the unit is
rebooted rather than getting a configuration update in step 3, the event log and the
VPNremote Alarm window will show the IP Address conflict messages. VPNremote Clients
who see the "IP Address Conflict" messages should click on the "Disconnect" button
and reconnect.
3. Resolved CERT advisory 287771. See http://www.kb.cert.org/vuls/id/287771 for more details.
4. Resolved CERT advisory 459371. See http://www.kb.cert.org/vuls/id/459371 for more details.
5. Resolved CERT advisory 761651. See http://www.kb.cert.org/vuls/id/761651 for more details.
6. Resolved CERT advisory 539363. See http://www.kb.cert.org/vuls/id/539363 for more details.
7. Resolve CERT advisory 464113 by adding logic to support the following firewall
rules that block various illegal combinations of TCP flags. Note that the enforement
of these rules cannot be turned off. When packet filtering is enabled, any packet
matching any of the following rules will be blocked.
# block SYN|FIN and SYN|RST
block in log quick on $ext_if proto tcp from any to any flags SF/SF
block in log quick on $ext_if proto tcp from any to any flags SR/SR
# block any bit combinations used in port scanning and OS fingerprinting
# including the "Xmas" (all bits lit up) scans
block in log quick on $ext_if proto tcp from any to any flags FUP
block in log quick on $ext_if proto tcp from any to any flags FU
block in log quick on $ext_if proto tcp from any to any flags FP
block in log quick on $ext_if proto tcp from any to any flags UP
block in log quick on $ext_if proto tcp from any to any flags F
block in log quick on $ext_if proto tcp from any to any flags U
block in log quick on $ext_if proto tcp from any to any flags P
block in log quick on $ext_if proto tcp from any to any flags SAFRU/SAFRU
# block anything that doesn't have any TCP flags set.
block in log quick on $ext_if proto tcp from any to any flags /SAFRPU
See http://www.kb.cert.org/vuls/id/464113 for more details.
8. CERT Advisory 854315 does not pertain to VSU running 3.x VPNos since this issue pertains to
a vulnerabilty in a DHCP daemon and there are no DHCP daemons in the VPNos 3.x.
9. vpnos will not Display the link UP/DOWN messages IN THE EVENT LOG due to a change in
the Ethernet driver.
11. DOS Attack fix. Any TCP SYN now received by the VSU with it's own IP as the source IP and one of
its well-known listeners as the source port will silently be discarded. Reference #4722
See http://www.linuxsecurity.com/advisories/freebsd_advisory-184.html for more details.
12. The "IP Address assignment from the Client IP Address pool" feature (i.e. when VPNremote actually
is given an IP from the pool and uses it for its clear-text source address rather than having its
source address translated at the VSU to an IP from the pool). This feature was only in VPNos 3.2.
13. Resolved issue where the VPNremote client would detect a IP address conflict
when an IP address Pool was configured by the VPNmanager 3.3 when the ldap is
used for authentication and configuation. Reference #4384.
14. Resolved issue where the error message "tx watchdog" would be displayed
continuously on a VSU 10000 when a large number of packets was queued.
When the queue reached the maximum value of 255, then all packets would
be dropped.
15. When a static route is configured for the same subnet as the public or
private interface and saved, and error message will be displayed and the
route will not be save. Reference #3495.
16. Resolve issue to allow the full 16 byte address to be configured for the
Radius server. Reference #3459
17. The CPU utilization information has been removed from both VSU console and
MIB.
18. The ARP age value (Utilities->Network Tables->Routing Table->Show ARP Table)
is for diagnostic purposes only and should not be changed under normal
operating conditions.
19. Resolved issue when the LDAP is used for configuration causing the VPNremote
client configured for UDP Encapsulation failing to successfully build secure
tunnels.
20. Resolved issue with the interface out counter incrementing for multicast and
broadcast packets when only Unicast packets should increment counter.
21. The ifSpeed MIB variable from MIB-II's ifTable on the VSU-100 and 2000 now
shows the correct interface speed when plugged into a 100 Mbps or 10 Mbps device
(or zero when it is disconnected). Previously, the VSU-100 and VSU-2000 always
reported 100 Mbps as the speed of even when it was disconnected or the interface
was connected to a 10 Mbps device.
3.2.15 Fixes:
1. Changing the default VSU management certificate no longer causes
the VSU to halt with a stackdump. Reference # 2028.
2. The "Appply to Clients only VPN" feature is now functional.
Reference #1765.
3. When trying to import a VSU certificate of the wrong size, the VPNos
no longer will erroneously accept the certificate. Reference # 2012.
4. When viewing statistics, 1 megabyte of data no longer is displayed at
1000 KB. Reference #2367
5. VPNos now correctly allows passing of passive FTP when allowing it via
an activated ACL. Reference #1897
6. The message "CD ERROR: CCD Warning: unrecognized CCD TAG XX" is no longer
Erroneously displayed. Reference # 2391.
7. VPNos now correctly sends the VPNmanager the translated IP address of
VPNremote Client 4.0.X when monitoring active client sessions.
The translated IP address from the Client Pool IP Address is no longer
shown as 0.0.0.0. Reference # 2257.
8. Active VPNremote Client session IP addresses are now correctly sent
via SNMP to a configured SNMP target. The following is the current
functionality:
when an IP pool is configured:
Case 1. a.b.c.d for a 3.x client, where a.b.c.d is the IP address
the 3.x client was assigned from the IP pool (translated at the VSU).
Case 2. a.b.c.d for a 4.0.x client, where a.b.c.d is the IP address
the 4.0.x client was assigned from the pool (translated at the VSU).
Case 3. a.b.c.d for a 4.1.x client, where a.b.c.d is the IP address
the 4.1.x client was assigned from the pool at CCD time.
when an IP pool is *not* configured:
Case 4. 0.0.0.0 for a 3.x client. The functionality is not supported
for the 3.x client.
Case 5. a.b.c.d for a 4.0.x or 4.1.x client, where a.b.c.d is the IP
address the 4.0.x or 4.1.x client was assigned locally at the client machine.
*Note that in case 5, the shown address isn't really translated, but
simply displayed to indicate what address the client is known by on the
private side of the VSU.
Reference # 2257.
8. The following problem has been resolved:
Having the TEP policy turned on (i.e. encrypt traffic to and from the
VSU's IP address) and the non-VPN traffic handling mode set to
"Block all non-VPN traffic," prevents a VSU from initiating any
traffic with a source IP of its secondary IP address
(e.g. used for RADIUS authentication requests) to any host on it's private side.
Reference # 3066.
9. The "out of the box" default for a VSU has been changed to
"BLOCK ALL NON-VPN TRAFFIC." Having this block mode setting to
"Block-All" is essential when using the new "High Availability"
feature which provides redundancy between two VSUs placed in
parallel to each other. This setting prevents any possible
routing/arp loops.
10. Release 3.2 is not supported on the following VSU models:
10e, 1010e, 1100, and 1200.
Section III: Known Issues and caveats in VPNos 3.2.25
1. CERT advisory 886601 where IKE protocol discloses its identity
during Aggessive Mode when using a shared secret for authentication
is a limitation of the protocol and not a VSU/VPNos issue.
2. Feature # 3 referenced in Section "I: New Features in Release
3.2.15" of this document is not supported when using LDAP as the
source of the VPNremote Client configuration. Reference # 2985
3. Features # 1 and 4 referenced in Section "I: New Features in
Release 3.2.15" of this document are currently not operational when
using LDAP as the source of the VPNremote Client configuration.
Reference # 2984
4. When using RADIUS for VPNremote Client authentication and the
new "Default Policy" feature referenced in Section "I: New Features
in Release 3.2.15" of this document,
CCD (Client Configuration Download) will fail if the RADIUS
administrator does not correctly indicate the correct tag in
the RADIUS "class" attribute for a "default VPN." Reference #2863.
5. VPNremote Clients 3.1.x will need to disconnect and reconnect
if the VSU being used as the VPN gateway is rebooted. Reference # 3051.
6. "High Availability" feature limitations:
A. If two VSU-7500s are used as a HA pair, only the primary ethernet
public and private ports may be plugged into the network. The secondary
ports must be left unconnected. The VSU-7500s cannot provide both
Ethernet redundancy via the 4 available ports and HA (VSU to VSU redundancy)
simultaneously.
B. Neither VSU in a HA pair may be deployed in one-arm mode
(connecting only the VSU's private port to the network). The HA implementation
depends on the ability to receive advertisements on both physical interfaces.
Deploying a VSU in one-arm mode prevents any packets from being received on
the public port since only the private port is plugged into the network.
C. NAT on the public interface of a VSU participating in HA is not supported
D. Certificate-based VPNs are not supported on VSUs participating in HA.
E. Both VSUs participating in an HA group must be of the same model.
Reference # 3153.
7. After upgrading firmware on a VSU5000 or VSU7500 a reboot is normally
required. If for any reason the VSU must be rebooted a second time,
there must be at least a five minute period between reboots to prevent
the VSU from reverting back to the original firmware image.
Reference # 2326.
8. The VSU name cannot be resolved by the internal network
DNS in spite of the right DNS address displayed by
the VSU panel. This occurs only in a few configurations.
Reference# 1452
9. When using a single ACE server for authentication (via a
RADIUS proxy) in a multiple VSU topology, the following
authentication/configuration combinations are supported
for environments:
RADIUS authentication/LDAP configuration
RADIUS authentication/Local configuration
The authentication/configuration combination is configured via
the Edit->Preferences, Dyna-Policy Authentication tab of
VPNmanager.
The issue with using local configuration in a multiple VSU
topology with a single ACE server is that every VSU submits
the same User/PIN/Token data to the ACE server (via the RADIUS
proxy) during the Dyna-Policy process. The ACE server
interprets all submissions after the first to be
retransmissions/replays of the first authentication attempt and
discards those subsequent submissions. This appears to the user
as if all VSUs after the first time out. The configuration from
the first VSU is downloaded to the client and the user sees the
"Partial configuration may have been downloaded" message.
10. Flushing the VSU configuration using the VSU console menu
Configuration->Flush Configuration sets the superuser password
to "password". By executing the Quick Setup menu on the VSU console,
the superuser password can be reset.
11. Some VSUs running pre-3.2.25 SP release may erroneously report exceptionally
high CPU utilization percentages (~95%) while the unit is idle.
12. VPNremote Clients using UDP encapsulation of IPSec for PNAT support
may be Unable to successfully login on to an NT domain through Netgear
FR314(6.2.2) and Linksys BEFSR41 (1.42.7) devices. Clients may not be able to
connect to a VSU at all if using UDP encapsulation behind some PNAT devices.
Multiple users behind the same PNAT device will not work properly.
13. VPNremote Client Authentication Message:
Forced message works with VPNremote 4.1.x/4.0.x
(3.1.x clients will be blocked if the forced message is activated)
Display message works with VPNremote 4.1.x/4.0.x/3.1.x
(message only displays on the VPNremote 4.1.x/4.0.x, but the 3.1.x
clients will not be blocked if the forced message is activated)
14. Diagnostic dumps have been observed on a VSU7500 when all four
ports are in use, RIP Listen/Learn is configured and the user
disconnects and reconnects the primary public and private
cables several consecutive times (more than 10).
15. The syslog message:
"a.b.c.d/mask -> w.x.y.z disappeared from kernel"
has been observed on a VSU7500 when all four ports are in use,
RIP Listen/Learn is configured and the user disconnects and
reconnects the primary public and private cables several
consecutive times (more than 10).
16. Diagnostic dumps have been observed when a port NAT rule is
configured with a small enough port range such that the port
resources are exhausted by FTP clients on the private side
of the VSU. It is recommended that the user configure a port
range size of 1000 when configuring a port NAT rule.
Section IV: Upgrading VPNmanager and VPNos to Version 3.2.25
