Table Of Contents
Release Notes for Cisco
VPN 3000 Series Concentrator, Release 3.6 Through 3.6.8.BDowngrading from Release 3.6.x
New Features in Releases 3.6.3 Through 3.6.8
DHCP Relay for Wireless Operation (Includes Microsoft VPN Client Route List via DHCP)
Ratified IPSec/UDP Implementation (NAT Traversal)
Advanced Encryption Standard (AES)
Support for Diffie-Hellman Group 5
Backup CRL Distribution Points
SDI Upgrade (ACE/Agent Enhancements)
Dynamic DNS (DDNS Host Name Population)
L2TP/IPSec Authentication Enhancements (EAP/TLS, EAP/SDI)
LAN-to-LAN Filters on the VPN 3000 Concentrator
Management Interface Enhancements
IPSec Backup Servers Feature Now Applies to the VPN Client
"Username@Group" Can Now Be Sent to Authentication Server When Strip Group Is Disabled
Disable Group Lock When Using SDI or NT Domain Authentication
Password Expiry Does Not Change User Profile for LAN
Browser Interoperability Issues
VPN Client Used with Zone Labs Integrity Agent Uses Port 5054
Administer Sessions Screen Shows Data for Wrong Group
Long Initialization for SNMP Traps in Releases 3.0, 3.5, and 3.5.1
Accessing Online Glossary Requires Connection to Cisco.com
SNMP Traps VRRPNotifications and cipSecMIBNotifications Are Not Supported
RSA Allows a CA to Issue Only One Certificate with any DN
Rebooting after Installing New Hardware
Reauthentication on Rekey Interval
Network Lists for CPP Firewall Policy Source and Destination Are Not Supported
Change to Network List Creation for LAN-to-LAN Configuration
Open Caveats for VPN 3000 Series Concentrator
Caveats Resolved in Release 3.6.8.B
Caveats Resolved in Release 3.6.8.A
Caveats Resolved in Release 3.6.8
Caveats Resolved in Release 3.6.7.H
Caveats Resolved in Release 3.6.7.G
Caveats Resolved in Release 3.6.7.F
Caveats Resolved in Release 3.6.7.E
Caveats Resolved in Release 3.6.7.D
Caveats Resolved in Release 3.6.7.C
Caveats Resolved in Release 3.6.7.B
Caveats Resolved in Release 3.6.7.A
Caveat Resolved in Release 3.6.7
Caveats Resolved in Release 3.6.6
Caveats Resolved in Release 3.6.5
Caveats Resolved in Release 3.6.4
Caveats Resolved in Release 3.6.3
Caveats Resolved in Release 3.6.1
Caveats Resolved in Release 3.6
VPN 3000 Concentrator Documentation Updates
Software Configuration Tips on the Cisco TAC Home Page
Obtaining Technical Assistance
Cisco Technical Support Website
Definitions of Service Request Severity
Obtaining Additional Publications and Information
Release Notes for Cisco
VPN 3000 Series Concentrator, Release 3.6 Through 3.6.8.B
CCO Date: July 22, 2004
Part Number OL-5637-02
Introduction
Note
You can find the most current documentation for released Cisco VPN 3000 products at http://www.cisco.com or http://cco.cisco.com. These electronic documents might contain updates and changes made after the hard-copy documents were printed.
These release notes are for Cisco VPN 3000 Series Concentrator Release 3.6 and for its incremental "point" releases through Release 3.6.8.B software. Please note that product release numbers are not necessarily consecutive. These release notes describe new features, limitations and restrictions, interoperability notes, and related documentation. They also list issues you should be aware of and the procedures you should follow before loading this release. The section, "Usage Notes," describes interoperability considerations and other issues you should be aware of when installing and using the VPN 3000 Series Concentrator. Read these release notes carefully prior to installing this release.
Contents
These release notes describe the following topics:
New Features in Releases 3.6.3 Through 3.6.8
Open Caveats for VPN 3000 Series Concentrator
Caveats Resolved in Release 3.6.8.B
Caveats Resolved in Release 3.6.8.A
Caveats Resolved in Release 3.6.8
Caveats Resolved in Release 3.6.7.H
Caveats Resolved in Release 3.6.7.G
Caveats Resolved in Release 3.6.7.F
Caveats Resolved in Release 3.6.7.E
Caveats Resolved in Release 3.6.7.D
Caveats Resolved in Release 3.6.7.C
Caveats Resolved in Release 3.6.7.B
Caveats Resolved in Release 3.6.7.A
Caveat Resolved in Release 3.6.7
Caveats Resolved in Release 3.6.6
Caveats Resolved in Release 3.6.5
Caveats Resolved in Release 3.6.4
Caveats Resolved in Release 3.6.3
Caveats Resolved in Release 3.6.1
Obtaining Technical Assistance
System Requirements
This section describes the system requirements for Release 3.6.x.
Hardware Supported
Cisco VPN 3000 Series Concentrator software Release 3.6.8 supports the following hardware platforms:
•
•
Platform Files
Release 3.6.8 contains two binary files, one for each of two platforms:
•
•
Caution
If you are using Internet Explorer, use version 5.0, Service Pack 2 or higher.
Upgrading to Release 3.6.x
This section contains information about upgrading from earlier releases to Release 3.6.x.
When upgrading VPN 3000 Concentrator releases, you must clear the cache in your browser to ensure that all new screens display correctly when you are managing the VPN Concentrator.
Note
Upgrading to a new version of the VPN 3000 Concentrator software does not automatically overwrite the existing configuration file. Configuration options for new features (for example, IKE proposals) are not automatically saved to the configuration file on an upgrade. The HTML Manager displays "Save Needed" (rather than "Save") to indicate that the configuration needs to be saved. If the configuration is not saved, then on the next reboot, the new configuration options are added again. If you need to send the configuration file to the TAC, save the running configuration to the configuration file first.
Before You Begin
Before you upgrade to this release, back up your existing configuration to the flash and to an external server. This ensures that you can return to the previous configuration and software if you need to.
Be aware of the following considerations before you upgrade. These are known product behaviors, and your knowing about them at the beginning of the process should expedite your product upgrade experience. Where appropriate, the number of the caveat documenting the issue appears at the end of the item. See Open Caveats for VPN 3000 Series Concentrator for a description of using this number to locate a particular caveat.
Release 3.6.8 of the VPN 3000 Concentrator software contains several features that interact with corresponding new features in the Release 3.6.x versions of the VPN Client and VPN 3002 Hardware Client software. To get the full benefit of this release you should upgrade your client software as well as your concentrator software. The VPN 3000 Concentrator software, Release 3.6.8, does operate with VPN Client and VPN 3002 Hardware Client versions 3.0 and higher, but you should upgrade these, too, to take full advantage of the new features.
•
•
•
Use the following backup procedure to ensure that you have a ready backup configuration.
Backing Up the Existing Configuration to the Flash
1.
2.
3.
You have now backed up the existing configuration to the flash.
Backing Up the Existing Configuration to an External Server
You should also back up the configuration to a server. You can do this in many ways, one of which is to download the file using your Web Browser from the HTML interface (VPN Manager).
You can now upgrade the software with assurance that you can return to your previous firmware using your previous configuration.
Note
Downgrading from Release 3.6.x
If you need to return to a release prior to Release 3.6.x, do the following:
Step 1
Step 2
Step 3
Step 4
Step 5
Your prior firmware and image are restored.
New Features in Releases 3.6.3 Through 3.6.8
These releases update the VPN 3000 Series Concentrator software to resolve several outstanding caveats. Refer to the appropriate "Caveats Resolved in Release 3.6.x" section of these Release Notes for details for each release.
Note
New Features in Release 3.6.1
This section describes the new features in Release 3.6.1 of the VPN 3000 Series Concentrator. For detailed instructions about how to configure and use these features, see VPN 3000 Series Concentrator Reference Volume I: Configuration and VPN 3000 Series Concentrator Reference Volume II: Administration and Management.
Network Extension Per Group
Network extension per group lets a network administrator restrict the use of network extension mode on the VPN 3002 Hardware Client. You enable the use of network extension mode for clients on a group basis.
Bandwidth Management
Bandwidth management provides a throttling mechanism to all tunneled traffic that limits the maximum amount of bandwidth allowed per group/user (policing) or provides a minimum amount of bandwidth allowed per group/user (bandwidth reservation).
•
•
Policies containing both bandwidth reservation and policing apply on the interface and group level. You must create a policy before enabling bandwidth management. For an overview of bandwidth management, see Configuration | Policy Management | Traffic Management | Bandwidth Policies | Add or Modify in the VPN 3000 Series Concentrator Reference Vol. I: Configuration.
To configure bandwidth policies, go to Configuration | Policy Management | Traffic Management | Bandwidth Policies.
To enable bandwidth management on the public interface, go to Configuration | Interfaces | Public Interface and select the Bandwidth Management tab. Check the Bandwidth Management check box, set the Link Rate, and apply a policy to the interface. The policy applied to the public interface is considered the default or global policy for all groups/users that do not have a bandwidth policy applied to their group.
The defined Link Rate must be based on available Internet bandwidth and not on the physical LAN connection rate. For example, if the Internet router in front of the VPN Concentrator has a T1 connection to the Internet, leave the Link Rate set on the VPN Concentrator at the default value of 1544 kbps.
To configure bandwidth policies on a group, go to Configuration | User Management | Groups | Assign Bandwidth Policy. Select the public interface and apply a policy. This page also has an option to reserve a specific amount of bandwidth per group.
To configure a bandwidth policy for a LAN-to-LAN connection, go to Configuration | System | Tunneling Protocols | IPSec LAN-to-LAN and apply a policy.
DHCP Relay for Wireless Operation (Includes Microsoft VPN Client Route List via DHCP)
The DHCP Relay feature lets wireless clients obtain a network configuration from the corporate network before creating a VPN tunnel. This may be used with the VPN Client autoinitiation feature to obtain a network configuration and automatically connect to the secure gateway when a configured wireless LAN (WLAN) is detected.
To add DHCP, go to Configuration | System | IP Routing.
To configure DHCP Relay, go to Configuration | System | IP Routing | DHCP Relay.
To enable DHCP Relay, you must also assign proper rules to filters in the Configuration | Policy Management | Traffic Management | Filters screen
DHCP Intercept
DHCP Intercept uses DHCP to provide a Microsoft L2TP/IPSec Client with a Subnet Mask, Domain Name, and Classless Static Routes.
This feature allows the VPN Concentrator to reply directly to the Microsoft Client DHCP Inform message. This is useful in environments in which using a DHCP server for this purpose is not advantageous.
You configure this feature on a per-group basis on the Client Config tab of either the Configuration | User Management | Base Group screen or the Configuration | User Management | Groups | Add or Modify screen.
Ratified IPSec/UDP Implementation (NAT Traversal)
Release 3.6.1 adds support for NAT Traversal (NAT-T), the new IPSec over UDP encapsulation IETF IPSec Working Group draft standard specification (draft-ietf-ipsec-nat-t-ike-02).
NAT-T lets IPSec peers establish a LAN-to-LAN connection through a NAT device. It does this by encapsulating IPSec traffic in UDP datagrams, thereby providing NAT devices with port information. Multiple IPSec clients behind a NAT/PAT device can connect to the same VPN Concentrator, except Microsoft L2TP/IPSec clients (as noted in the following list). NAT-T auto-detects any NAT devices and encapsulates IPSec traffic only when necessary.
NAT-T has the following limitations and requirements:
•
•
•
To configure NAT-T globally, go to the Configuration | System | Tunneling Protocols | IPSec | NAT Transparency screen and check the IPSec over NAT-T check box.
Note
LAN-to-LAN NAT Traversal
With Release 3.6.1, you can also enable NAT traversal for LAN-to-LAN sessions. For a LAN-to-LAN connection, you must also check the IPSec over NAT-T check box in the Configuration | System | Tunneling Protocols | IPSec LAN-to-LAN | Add or Modify screen.
LAN-to-LAN NAT Traversal has the following limitations and requirements:
•
•
Advanced Encryption Standard (AES)
Release 3.6.1 adds support for Advanced Encryption Standard (AES), which is more secure than DES and more efficient than triple DES. It also adds:
•
•
•
If you configure AES on a VPN 3000 Concentrator group, only clients that support AES (such as the VPN Client, Release 3.6.1) can connect to that group.
To configure AES to the Encryption parameter in Tunneling, go to Configuration | System | Tunneling Protocols | IPSec LAN-to-LAN or Configuration | System | Tunneling Protocols | IPSec LAN-to-LAN.
Note
Support for Diffie-Hellman Group 5
Release 3.6.1 adds support for Diffie-Hellman Group 5 for use with LAN-to-LAN connections or VPN Client connections with digital certificates. You can use DH Group 5 with 3DES.
To configure DH 5 and AES, go to Configuration | System | Tunneling Protocols | IPSec | IKE Proposals.
To add DH 5 and AES to the Perfect Forward Secrecy parameter, go to Configuration | Policy Management | Traffic Management | Security Associations.
CRL over HTTP
You can now configure the VPN Concentrator to use the HTTP protocol to retrieve a certificate revocation list (CRL) from a distribution point. If you choose HTTP, you must assign HTTP rules to the public interface filter if you access your distribution points through the public interface. For example, enabling this feature supports the use of public key interfaces (PKI), such as Verisign, that require the use of HTTP.
To configure CRL over HTTP, go to Configuration | System | Management Protocols | HTTP/HTTPS.
CRL Caching
You can configure the VPN 3000 Concentrator to store certificate revocation list (CRL) information in volatile memory (RAM). CRL caching can potentially speed up the process of verifying the revocation status of certificates. With CRL caching enabled, when the VPN Concentrator needs to check the revocation status of a certificate, it first checks whether the required CRL exists in the cache and has not expired. Then the VPN Concentrator checks the serial number of the certificate against a list of the serial numbers in the CRL. If a match exists, the authentication fails.
To configure CRL caching, go to Administration | Certificate Management | Configure CA Certificate.
Backup CRL Distribution Points
You can now configure the VPN Concentrator to retrieve the CRL from the distribution points specified in the certificate being checked, from a user-specified list of up to five static distribution points, or from a combination of these.During IKE negotiation, if CRL checking is enabled, the VPN Concentrator verifies the revocation status of the IKE peer certificate before allowing the tunnel to be established. CRLs exist on external servers maintained by Certificate Authorities. If you configure retrieval of the CRL from a list of distribution points, the VPN Concentrator tries each in turn until it either finds the relevant CRL or exhausts the list.
To configure backup CRL distribution points, go to Administration | Certificate Management and select the Configure option on the appropriate CA certificate.
SDI Upgrade (ACE/Agent Enhancements)
Release 3.6.1 updates the implementation of the RSA ACE/Agent on the VPN Concentrator to the RSA/ACE Agent 5.0 release. It supports ACE/Server Replicas (a more advanced primary/backup feature than what was in earlier versions), two-step authentication, load balancing, and group-based support for multiple node secrets.
Split DNS
Split DNS lets an internal DNS server resolve a list of centrally-defined Local Domain Names (LDN), while ISP-assigned DNS servers resolve all other DNS requests. This feature is used in a split-tunneling connection. You configure LDNs on a Base Group/Group basis.
Dynamic DNS (DDNS Host Name Population)
Dynamic DNS passes the host name to the central site device, which uses that name in the DHCP address request. This feature allows the DHCP server and DDNS to dynamically populate the DNS records.
L2TP/IPSec Authentication Enhancements (EAP/TLS, EAP/SDI)
Extensible Authentication Protocol (EAP) lets a VPN Concentrator proxy the authentication process to an authentication server. This feature supports additional authentication options for the Microsoft VPN Client (L2TP/IPSec), including CHAP (EAP/MD5), Smartcards (EAP/TLS), and RSA SecurID (SDI).
Supporting EAP pass-through on the VPN Concentrator means that Microsoft native IPSec clients can authenticate users through Smartcards or SDI tokens.
To configure EAP, go to Configuration | User Management | Base Group or Configuration | User Management | Groups.
Note
MTU Interface Configuration
You can now configure the Maximum Transmission Unit (MTU) to be a value in the range from 68 through 1500 bytes. To configure the MTU, go to Configuration | Interface | Ethernet 123, General tab.
Secure Copy (SCP)
You can now do secure file transfers using the SCP (Secure CoPy) function over an SSH session. To enable SCP, go to Configuration | System | Management Protocols | SSH and check "Enable SCP".
LAN-to-LAN Filters on the VPN 3000 Concentrator
Release 3.6.1 lets you configure a filter to apply to the traffic that is tunneled through an IPSec LAN-to-LAN connection. To configure LAN-to-LAN filters, go to Configuration | System| Tunneling Protocols | IPSec LAN-to-LAN.
Management Interface Enhancements
Release 3.6.1 lets you view version and operating system information (when available) for connected clients and connected user session information. You can also sort by any of the columns in the table. To view these enhancements, go to the Administration | Administer Sessions screen and the Monitoring | Sessions screen.
NAT over LAN-to-LAN
Release 3.6.1 allows LANs with overlapping or same IP addresses between VPN 3000 Concentrators using static, dynamic, and PAT rules. To answer the need for hosts to communicate across overlapping LANs, the private address space must be translated (NATed).
IPSec Fragmentation
The IPSec fragmentation policy specifies how to treat packets that exceed the MTU setting when tunneling traffic through the public interface. This feature provides a way to handle cases where a router or NAT device between the VPN Concentrator and the VPN Client rejects or drops IP fragments. There are three options:
•
•
•
To configure this option, go to Configuration | Interface | Ethernet 123 | General tab. VPN 3000 Series Concentrator Reference Volume 1: Configuration explains these options and gives an example of their use.
Certificate DN Group Matching
In release 3.6.1, you can define rules to match a user's certificate to a permission group based on fields in the Distinguished Name (DN). To specify a policy for group matching by rules, you must define the rules and enable each rule for a selected group that already exists in the configuration. For more information, refer to the description of the Configuration | Policy Management | Certificate Group Matching screen in VPN 3000 Series Concentrator Reference Volume 1: Configuration.
IPSec Backup Servers Feature Now Applies to the VPN Client
The description of the IPSec Backup Servers feature in the VPN 3000 Concentrator Series Reference documentation indicates that it applies only to the VPN3002 Hardware Client. The feature now applies to the Software Client as well. For information about this feature and how to configure it, on the VPN Concentrator, see VPN Client Administrator Guide, Chapter 1. For information about how to configure Backup Servers in the VPN Client, see VPN Client User Guide (CSCdy09630).
Online Help Enhancements
Online help is now easier to use. Release 3.6.1 provides a global help Table of Contents that lets you view and navigate all available help topics. It also offers a search engine, an index, and a glossary.
"Username@Group" Can Now Be Sent to Authentication Server When Strip Group Is Disabled
Release 3.6.7.F adds the ability to send a "Group Lookup" username to the authentication server during user authentication. This feature restores the ability that was available as a side effect of having "Strip Realm" disabled and "Group Lookup" enabled with "@" delimiter.
In Release 3.6.7 and earlier releases, the strip realm and group lookup feature overlapped when the group lookup delimiter was set to '@'. A side effect of this overlap was the ability to send "username@group" to the authentication server during user authentication. This later was reported as a caveat (CSCea88995), which now has been fixed. Unfortunately, some customers have been taking advantage of this feature and have requested that the capability be added back.
This restored feature applies only to usernames that are in the group lookup format "user@group", "user#group", or "user!group" and only when "Group Lookup" is enabled.
To use this feature, uncheck the "Strip Group" checkbox on the Configuration | System | General | Authentication screen.
•
•
Usage Notes
This section lists interoperability considerations and other issues to consider before installing and using Release 3.6.8 of the VPN 3000 Series Concentrator software.
Online Documentation
The online documentation might not be accessible when using Internet Explorer with Adobe Acrobat, Version 3.0.1. To resolve this issue, upgrade to Acrobat 4.0 or higher. The latest version of Adobe Acrobat is available at the Adobe web site: http://www.adobe.com.
Disable Group Lock When Using SDI or NT Domain Authentication
Password Expiry Does Not Change User Profile for LAN
You must enable Start Before Logon on the VPN Client and possibly may need to make sure that DNS and WINS servers are properly configured (CSCdv73252).
Browser Interoperability Issues
The following sections describe known behaviors and issues with the indicated Web browsers.
VPN 3000 Concentrator Fully Supports Only Netscape and Internet Explorer
Currently, the VPN 3000 Concentrator fully supports only Netscape and Internet Explorer. If you are using Internet Explorer, use version 5.0, Service Pack 2 or higher. Using other browsers might cause unacceptable behavior; for example, if you attempt to use an unsupported Web browser to manage the VPN 3000 Concentrator, clicking any of the links might return you to the login screen. (CSCdx87630).
Internet Explorer 4.x Browser Issues
The following are known issues with Internet Explorer 4.X and the VPN Concentrator Manager (the HTML management interface). To avoid these problems, use the latest version of Internet Explorer (at least version 5.0).
•
•
•
After adding a new SSL certificate, you might have to restart the browser to use the new certificate.
VPN Client Used with Zone Labs Integrity Agent Uses Port 5054
VPN Clients, when used with the Zone Labs Integrity Agent, are put into a "restricted state" upon connection to the Integrity Server if a port other than 5054 is used. The restricted state simply means the VPN Client is able to communicate only with the Integrity Server; all other traffic is blocked (CSCdw50994).
Workaround:
Do one of the following:
•
•
Administer Sessions Screen Shows Data for Wrong Group
When an L2TP/IPSec connection is established, authentication should behave as follows:
1.
2.
3.
This all works properly, but in the Administration | Administer Sessions screen, the Tunnel Group displays instead of the User's Group (CSCdy00360).
Long Initialization for SNMP Traps in Releases 3.0, 3.5, and 3.5.1
In Releases 3.0, 3.5, and 3.5.1 of the VPN 3000/3002 products, the SNMP task takes 3-5 minutes to complete initialization after a device reboot. Traps being processed during this interval are queued and sent to the SNMP Management station after SNMP task initialization completes.
However, the cold start trap, normally sent as a result of a device rebooting, is never sent.
In Release 2.5.X, the cold start trap is properly sent to the SNMP Manager after a device reboots (CSCdt01583).
Windows NT Authentication Servers Can't Follow Other Server Types in the a Prioritized Authentication Server List
If an Windows NT server follows a non-NT server in the prioritized authentication server list, and the non-NT server becomes unavailable for some reason, the VPN 3000 Concentrator detects this and falls back to the Windows NT server. If the tunnel being established is PPTP or L2TP, the authentication attempt to the Windows NT server also fails.
Therefore, when configuring PPTP or L2TP connections, do not place Windows NT authentication servers behind other types of servers in the applicable authentication server list (CSCdy07226).
Accessing Online Glossary Requires Connection to Cisco.com
The Glossary button at the top of all Help screens tries to contact univercd at www.cisco.com (the Cisco documentation site). This connection requires connectivity to Cisco's main web site. If your PC does not have a corporate Internet connection or your firewall blocks access, the following error appears when you attempt to access the Glossary:
"The page cannot be displayed."
To access the Glossary, you must be connected to www.cisco.com (CSCdy14238).
SNMP Traps VRRPNotifications and cipSecMIBNotifications Are Not Supported
The VPN 3000 Concentrator does not support the VRRPNotifications and cipSecMIBNotifications SNMP traps. You can configure VRRP for these SNMP traps without getting an error message, but the traps themselves are not supported, so no action occurs. The same is true of Cisco IPSec-flow MIB notifications (CSCdx44580).
RSA Allows a CA to Issue Only One Certificate with any DN
The rekey option to renew an SSL certificate from the RSA CA results in a rejection of the request.
The resubmit/renew feature does work with RSA as long as the certificate being rekeyed or renewed is first deleted from the CA database. RSA does not allow a CA to issue more than 1 certificate with any particular DN (CSCdv27743).
Rebooting after Installing New Hardware
Delays of about 3-50 seconds in making a VPN connection have occurred on Windows XP Professional Edition and Windows 2000 Professional Edition after adding a new NIC card. If you see problems of this nature, reboot the PC after the initial installation of the NIC card (CSCdv27743).
Reauthentication on Rekey Interval
If you have enabled the Reauthentication on Rekey feature, the VPN Concentrator prompts you to enter an ID and password during Phase 1 IKE negotiations and also prompts for user authentication whenever a rekey occurs. Reauthentication provides additional security.
If the configured rekey interval is very short, users might find repeated authorization requests inconvenient. In this case, disable reauthentication. To check your VPN Concentrator's configured rekey interval, see the Lifetime Measurement, Data Lifetime, and Time Lifetime fields on the Configuration | System | Tunneling Protocols | IPSec | IKE Proposals | Add or Modify screen.
Note
Network Lists for CPP Firewall Policy Source and Destination Are Not Supported
The VPN 3000 Concentrator does not support selecting source and destination network lists when defining rules for CPP firewall policy. Instead, you must define the source and destination address in the rule definition (CSCea14152).
Change to Network List Creation for LAN-to-LAN Configuration
The functionality that allows the administrator to create a network list from within a LAN-to-LAN configuration page has changed.
In previous releases, the administrator could create a network list from within the LAN-to-LAN configuration page. The new method for creating a network list uses a link on the LAN-to-LAN index page to the network list configuration page.
This change was resolves a problem with Reverse Route Injection when the network lists are added from within the LAN-to-LAN page. With the previous method, the routes, corresponding to the network lists that were added via the LAN-to-LAN page, were not present in the routing table (CSCea13002, CSCdz87573).
Open Caveats for VPN 3000 Series Concentrator
Caveats describe unexpected behavior or defects in Cisco software releases. The following list is sorted by identifier number.
Note
The following problems exist with the VPN 3000 Series Concentrator, Release 3.6.8.
•
L2TP over IPSec connections fail if going through a NAT device. During the connection establishment, the VPN Client and the VPN 3000 Concentrator exchange IP addresses. When the client sends what it believes to be the VPN 3000 Concentrator's address (really the NATed address), the VPN 3000 Concentrator releases the connection.
This is because the address assigned to the interface does not match the address coming in from the client. The same issue exists on the client side. This will not be resolved until the Windows 2000 MS client supports UDP encapsulation.
•
When configuring a LAN-to-LAN connection with IOS or PIX, it is important to match the keepalive configuration (both "ON" or both "OFF"). If the keepalive configuration is OFF for the VPN 3000 Concentrator and ON for the IOS device, the tunnel will be established with data.
IOS tears down the tunnel because the VPN 3000 Concentrator does not respond to IOS style keepalives if keepalives are configured to be OFF for the VPN 3000 Concentrator.
•
Multiple simultaneous connections from users behind a PAT (Port Address Translation) device can work, but only if the PAT device uses a unique source port for each simultaneous user's IKE session.
Some PAT devices use UDP source = 500 for all IKE sessions even if there are multiple simultaneous sessions. This will only allow 1 session to work since the second connection brought up from behind this PAT device will cause the first session to be torn down.
This is unrelated to whether a PAT device supports "ESP" PAT or whether you are using the IPSec/UDP (NAT) functionality.
Workaround:
–
–
–
•
If the phase 2 SA has a lifetime set to 60 - 119 seconds, the VPN Client connection is automatically disconnected. A phase 2 SA lifetime of 120 seconds and higher rekeys properly. This is an issue in the SW client. LAN-to-LAN and hardware Clients work fine.
•
In some cases, the Zone Labs Integrity Agent may not properly update on the Windows NT version 4.0 operating system while the VPN Client is connected, policy is changed and re-deployed, and the connection is up. Specifically, if you "Block Internet Servers" under the Firewall Security Rules in the Policy and then Deploy that new policy, a PC running Windows NT version 4.0 receives the updated policy, but it might not put the "Block Internet Servers" setting of that policy into effect.
Workaround:
Reboot the operating system.
•
You cannot reserve group bandwidth based on a percentage.
•
Due to a Microsoft bug, Windows XP PCs are not capable of receiving a large number of Classless Static Routes (CSR). The VPN 3000 Concentrator limits the number of CSRs that are inserted into a DHCP INFORM message response when configured to do so.
The VPN 3000 Concentrator limits the number of routes to 28-42, depending on the class.
•
The Concentrator may display the following events during a VPN Client connection. These events were found to be due to the client being behind a Linksys Cable/DSL router that was incorrectly modifying the Client's packets, causing them to fail authentication when received by the VPN Concentrator. The problem is more prominent if LZS compression is used.
Events:
131500 06/20/2002 17:08:34.300 SEV=4 IPSEC/4 RPT=4632
IPSec ESP Tunnel Inb: Packet authentication failed, username: gray, SPI:
4e01db67, Seq Num: 0000850f. Dump of failed hash follows.
Linksys has been notified about the problem.
Workaround:
Although no workaround currently exists, disabling LZS compression on the Concentrator helps reduce the number of events. To disable LZS compression on the Concentrator set the "IPComp" setting on the IPSec tab of the group configuration to "none".
•
The Microsoft L2TP/IPSec client for Windows 98, Windows ME, and Windows NT does not connect to the VPN 3000 Concentrator using digital certificates.
Workaround:
Use preshared keys.
•
When specifying the link rate for bandwidth management on an interface, the VPN 3000 Concentrator only permits specifying the range 1544000 - 100000000 bps.
This renders the feature difficult to use properly when the Internet link is less than T1 speed. We should permit the full range of speeds to allow this feature to be deployed in all environments.
•
On the VPN 3000 Concentrator running version 3.6 code, a bandwidth management policy is created with a reservation included, and this is applied to a group. No aggregation is applied to the group (left at 0). Interface bandwidth management is enabled and link rate is set to 1.544 Mbs, and a different group is applied for default users with a reservation only.
If the reservation amount is then changed on the policy the following error occurs in the log:
31 11/27/2000 15:43:48.360 SEV=4 BMGT/47 RPT=7
The Policy [ ADCUsers ] with Reservation [ 102000 bps ] being applied to Group [ ADC ] on
Interface [ 1 ] exceeds the Aggregate Reservation [ 0 bps ] configured for that group.
This error does not occur if the policy is first removed from the group, then the reservation is changed and the policy re-applied. No users are connected at the time of the error.
The reservation should be checked against the aggregate only if aggregation is enabled.
•
On a VPN 3000 Concentrator running Release 3.6 code, a bandwidth management policy is created and applied to a group reserving some portion of the link bandwidth using an aggregate reservation. If this reservation is then changed, the previous committed bandwidth is not freed up first when calculating whether enough bandwidth is available for use.
So, if 600 kbps is reserved from a link of 1544 kbps to start with, and this is then modified to reserve 1000 kbps, an error is generated and the modification is refused. The error shown is as follows:
83 11/27/2000 16:30:44.620 SEV=4 BMGT/31 RPT=7
Attempting to specify an Aggregate Group reservation [ 1000000 bps ] on Group [ ADC ] Interface [ 1 ] which added to the current reservation of the interface [ 600000 bps ] exceeds the link rate [ 1544000 bps ] to which it is being applied.
No bandwidth is reserved by any other policy.
Workaround:
Remove the aggregate reservation from the group first, and then to apply the new setting.
•
When a customer who is using the NT domain for user authentication and has the group name that is defined in the Concentrator the same as the user name in the NT domain server, the VPN Client can no longer connect to the Concentrator after upgrading the Concentrator to Release 3.6.1.
•
Cannot perform xauth with a PDC emulator in an Active Directory (AD) environment, when NT is the authentication method from a VPN 30000 Concentrator. In a MIXED MODE environment for Windows 2000 AD setup, using a PDC emulator in the domain for authentication from a VPN 3000 Concentrator does not allow a user to authenticate from a PDC emulator if the length of password is more than 14 characters.
Workaround:
Do one of the following:
–
–
•
The LAN-to-LAN tunnel might drop and get re-established, but the IKE session doesn't get cleared out of the administer sessions screen.
•
The VPN 3000 Concentrator does not send the ZoneLabs Integrity Server properly formed markup characters. Ampersands - as well as angle brackets (<,>), apostrophes ('), and double-quotes (") - should be escaped, because they are markup characters. For example: The "&" is not escaped. The result is that a login name of "L&nc&" is sent included in all messages the VPN Concentrator sends Integrity. (The username should be sent as "L&nc&".) Integrity rejects the session, and the VPN Concentrator drops the tunnel.
•
Attempting to delete a file from an ftp session into the VPN3000 fails and terminates the ftp session.
Workaround:
The file can be deleted from the VPN3000 Web Management screen at Administration | File Management.
•
After setting up the "config" user in Administration | Access Rights | Administrators | Modify Properties as being able to Read/Write File, this user can't access Administration | File Management. The following message appears:
You do not have sufficient authorization to access the specified page.
•
In all versions prior to Release 3.6, the Concentrator asked the Client to provide a Domain Name field for Native NT Domain authentication. Since it was believed that this field was not used for anything, this field was removed in Release 3.6.
To establish a connection in Release 3.6, use:
DOMAIN\username
passwordinstead of the construction used in earlier releases:
username
password
DOMAIN•
The Client might fail to establish an IPsec session if the Concentrator has a larger certificate. TCP encapsulation is used and there is a PAT router between the Concentrator and the Client.
•
If CPP, which allows local LAN access, is pushed from Concentrator, the Client allows any traffic from/to the Internet.
•
With multiple authentication servers defined, if any are defined by DNS name, and the system fails to resolve any of the servers, all incoming authentication requests will be held off for approximately 45 seconds. For example, the first server in the list was defined as an IP address and was working, the second and third servers were defined as DNS names and did not exist on my network (testing with a customer config). When trying to make a VPN Client IPSec connection, the first and second connection attempts time out, the next 10 or so work, then repeat the time out cycle.
Testing with servers only defined by IP address did not exhibit this behavior. In fact, servers defined by IP address that did not exist were recorded as being on-line in the event log
Workaround:
Remove the servers defined by DNS name.
•
VPN 3000 Concentrator version 3.6.3 sometimes leaves the RRI route in the Concentrator's routing table, even though the client is no longer connected.
•
When connecting a VPN 3015 Concentrator with Cisco VPN Client Software, the VPN connection fails.
•
Windows XP becomes unreachable over IP after returning from standby mode if the "Stateful Failover (Always On)" is enabled.
Workaround:
Disable "Stateful Failover (Always On)".
•
There is a problem with IPSEC SAs reestablishing after checkpoint initiates a soft reset.
•
After the public IP address and default gateway have been changed, the VPN 3000 Concentrator does not allow incoming data packets encapsulated by UDP(10000), even if an IPsec session is being established correctly. If you use TCP encapsulation or no encapsulation the problem does not occur.
Workaround:
Reload the VPN 3000 Concentrator after IP address modification.
•
Many "IPSEC ESP bad pad length (8) >= buffer length (8)" messages were logged in a syslog.
Using VPN3000 and PIX EzVPN:
–
–
•
A VPN 3000 Concentrator fails rekey with Microsoft's L2TP/IPSec client for Windows 95 or Windows 98 (oem'd from Safenet).
Note
This was determined to be a bug in the Microsoft client. The Concentrator always initiates rekeys. When phase 1 rekeys, we send the first main mode packet to the MS client. The Microsoft client responds with a malformed main mode packet.
The packet that Microsoft sends contains a final payload that has the Next Payload fields set to "vendor-id". Since the packet does not actually contain a next payload, we fail on the packet and thus fail the rekey. This caveat is a placeholder to track the issue.
Workaround:
The only workaround is currently to increase phase 1 rekey time(s) to a value that will not be hit. Because IKE will negotiate the lower of the proposed rekey times, this requires a registry change on the client PC(s), as well as a change on the concentrator.
The registry key is:
HKLM\Software\IRE\Safenet\Soft-PK\ACL\1\PH1PROPOSAL_xx, where "xx" is the number of the proposal. The default value of these keys is 28800 (seconds) or 8 hours. This value should be changed to a value that is high enough that users will not run into it.
•
After working for 2 weeks, the following messages can appear on the Concentrator:
Concentrator memory resources are critical
It might fail, or you might have to reload the Concentrator manually to free the memory.
•
The VPN3000 Concentrator will transmit data to exceed the negotiated Max Window Size. If going through a PIX edge firewall, the PIX shuts down the session when the window size is exceeded.
This occurs only when the ACKs coming back are delayed in transit.
The default window size for cTCP is 64K. The VPN Client and VPN3002 Hardware Client both generate ACKs at 8K intervals to avoid window issues. In this case the delays in ACK transport are significant enough that the window size is exceeded.
•
When split-tunnel configured, Windows XP machines with firewall enabled are not able to pass VPN traffic to the central-site concentrator, even though Internet traffic is passing through.
The Internet Connection Firewall is incompatible because the firewall blocks IPC communication from the VPN Client to the VPN Device Driver. In the firewall log, the log consistently blocks UDP 62515; this is the port used to establish the IPSEC SA.
•
With the Release 3.6.3.C VPN Client connected to a Release 3.6.7.B VPN 3000 Concentrator, a static route pointing to the exit interface (Ethernet) does not route IPSec traffic to the connected VPN Clients, although it can route cleartext traffic just fine. The route has to point to an exit interface instead of a next-hop router.
•
A VPN 3060 Concentrator running software Release 3.6(7)Rel:
failed with Exception Type: 0x00000300/DSI.
The Concentrator recovered itself after a while with no intervention.
•
You can access the web admin GUI interface using a MAC OSX machine running IE 5.5 with all updates and java installed. You can get around and configure the device as usual; however, when you click on the live event log link from the left-hand menu options | Monitoring | Filterable Event Log | Live Event Log, the following error appears:
java.lang.ClassNotFoundException eventlog.class
•
The VPN Client can connect to the VPN 3005 Concentrator, but cannot reach to a network when the packet matches "tunnel default gateway" route. But when the packet matches "static" route, the VPN Client can reach to the network.
•
When applying a filter to a vpn group the filter settings don't apply to users of this group when connected.
Workaround:
Apply the filter to the individual user.
•
A VPN3005 fails frequently.
•
A VPN 3000 Concentrator running Release 3.6.7.C fails to generate a full XML file if the Concentrator has more than 15 LAN-to-LAN tunnels configured.
•
Network Autodiscovery does not work if the VPN 3000 Concentrator is behind a NAT device and the NAT-T feature is in place.
Workaround:
On the VPN 3000 Concentrator behind the NAT device, do the following steps:
Step 1
Step 2
Step 3
where 'public' is public IP of the Concentrator behind NAT device, 'NAT' is the public address of the NAT device and 'peer' is the public address of the remote Concentrator.
Explanation of Workaround:
Step 1 updates the filter rules that are used to establish the Public-To-Public IPSec SA. The addressing in the rules must be consistent on each side of the tunnel.
This tunnel is used to sent the autodiscovered networks (via RIP). Steps 2 and 3 tell the Concentrator to NAT packets (to the NAT device's public interface) between the peer's public to its public. This is necessary because the peer directs its RIP packets to what the peer believes to be its peer (the NAT device).
Since the filter rule was modified, the NATed Concentrator needs to NAT its RIP packet to match the modified filter rule.
•
The VPN Concentrator is not accepting client connections.
After re-booting the VPN 3000 Concentrator, it accepts client connections for some time, then stops accepting client connections.
Workaround:
Re-boot the VPN concentrator.
•
You cannot use Split Tunnel with ICF on Windows XP. Microsoft does not allow adding an appropriate filter rule to allow the specific ports needed to use for VPN Client communications.
•
The VPN 3000 Series Concentrator mibs are improperly posted and do not conform to Cisco standards.
•
With Cisco Integrated Client Firewall and CPP, when you define (on the Concentrator) a filter with "Default Action" set to "Drop & Log", the policy looks good on the VPN Client "Firewall" tab, but the default action (drop) is not correctly enforced.
Workaround:
Choose "drop" as the default action.
•
Using VPN 3000 Concentrator software Release 3.6.5 or 3.6.7.A, a CRL check fails if the received CRL is empty.
•
A VPN 3030 Concentrator froze when telnetting on it. Then it rebooted.
•
The circumstances initiating this set of failures are unclear and at this point unreproducible. The customer network had been running for some time without incident. Suddenly, the system crashed several times within a few days. The initial failure occurred when running Release 3.6.7.A, but upgrading to Release 3.6.7.D made no improvements. The customer environment requires tunnels to be terminate on all three interfaces. At some point IPSec compression was enabled for all groups. It's unclear whether this configuration change was made at the time of the crashes. It is clear that disabling IPSec compression restored stability in the customer network.
•
A VPN 3000 Concentrator using EAP-TLS and L2TP compression stops encrypting traffic after 2-3 hours, connection stays up.
The user can connect to the VPN 3000 Concentrator (running Release 3.6.7.Rel) without any problem, using L2TP over IPSec /w EAP-TLS authentication, but after 2-3 hours of traffic passage, the VPN 3000 Concentrator stops encrypting traffic, but doesn't drop the connection.
Workaround:
Disable L2TP compression and/or EAP-TLS Auth.
•
Clicking apply on any LAN-to-LAN SA causes all LAN-to-LAN sessions to drop.
•
If you have a client user and an admin user with the same name, the client user might not be able to connect when the admin user is logged in and the client user has a simultaneous logins set to 1.
This caveat has been closed because the VPN 3000 Concentrator has a flat namespace. The administrator names should be different from the username for security reasons.
Workaround:
Do one of the following:
–
–
–
•
In the LAN-to-LAN NAT rules, the VPN Concentrator accepts network/mask rules such as 192.168.1.0/255.255.0.0.
It should consider this as a typo and either modify it to be 192.168.0.0/255.255.0.0 or it should reject it and warn the user.
•
After some period of time the concentrator will fail to take any new connections. Each new incoming connection fails with a time-out in building IKE Main Mode Message 6.
Workaround:
Reboot the Concentrator.
•
VPN3000 crash due to a malformed PPP IP Control Protocol message.
Caveats Resolved in Release 3.6.8.B
Release 3.6.8.B resolves the following issues:
•
The following message is shown on the Primary box:
269 10/09/2002 12:20:58.640 SEV=2 IP/25 RPT=32
A device with MAC address 00005E000101 is attempting to use the IP Address of Interface 1 (10.100.1.195)Although this is not really causing the Secondary to takeover, it is filling up the logs. The Severity to Log is set to General 1-5 (the Default).
Customer wants to know how we can change the message to something which seems less threatening and doesn't seem to show something is wrong. Also, do not show it in the log every time.
•
After the public IP address and default gateway have been changed, the VPN Concentrator does not allow incoming data packets encapsulated by UDP (10000) even if an IPsec session is being established correctly. If you use TCP encapsulation or no encapsulation the problem does not occur.
•
Netscape 7.x E-Mail Client is unable to send mail via SMTPS E-Mail Proxy.
•
The VPN 3000 sends a gratuitous ARP with the real MAC address and its own IP address, which is also VRRP address, after you reboot it.
Caveats Resolved in Release 3.6.8.A
Release 3.6.8.A resolves the following issues:
•
L2TP and PPTP connections to VPN 3000 running Release 3.6.8 or Release 4.0.2 cause the device to fail.
•
The following problem occurred on both Release 3.6.8 and Release 4.0.1.C. The primary VPN 3000 Concentrator's interfaces are still primary after being rebooted, even though one of the interfaces is Down.
Caveats Resolved in Release 3.6.8
Release 3.6.8 resolves the following issues:
•
HTTP Software Updates sometimes fail with "Software Update Error". Retrying the operation does not update the image.
•
Using a VPN 3060 Concentrator running Release 3.5.5 or 3.6.7.F, when we set VRRP and Master VPN's private interface fails, switchover delay happens at Backup VPN, hence we cannot communicate end-to-end.
•
The VPN 3000 Concentrator has a minimum password requirement of 8 characters. This requirement can be bypassed and a local user password can be set to blank by editing the username and removing the password at the same time on the VPN 3000 Concentrator, despite the error about the password not meeting minimum length requirements.
Caveats Resolved in Release 3.6.7.H
Release 3.6.7.H resolves the following issues:
•
A customer is connecting from a 3002 hardware client configured as a PPPoE client to a VPN 3000 Concentrator using an Internet Service Provider. According to the customer, this configuration was working fine until recently when ISP made a change on their side to use PAP instead of MS-CHAP v1 for PPPoE authentication. The customer sees same behavior whether they use 3.6.3, 3.6.1 or 3.5.5.
•
VPN Client can't connect using cTCP to the virtual address in the VPN 3000 Series Concentrator using load balancing following a reboot. This issue occurs only in Releases 3.6.7.F, 3.6.7.G, 4.0.1.Rel and 4.0.1.A
•
VRRP and IPSec over TCP might not work in Releases 3.6.7.F and 4.0.1., but they work in release 3.6.3.
Caveats Resolved in Release 3.6.7.G
Release 3.6.7.G resolves the following issues:
•
A VPN 3000 Concentrator might leak message buffers under the following conditions. This could prevent new connections and possibly cause the device to fail.
Conditions:
–
–
–
•
When using multiple static CRL servers, if the first server fails without being taken off-line, the subsequent searches also fail.
•
With authentication set to Radius with Expiry, the user is prompted for username, password and domain name when connecting. The ACS authentication report shows "domain\username", but the ACS accounting report page shows only the "username".
•
The VPN 3000 Concentrator, Releases 3.6.7C, 3.6.7D, and 4.0, sends VRRP messages on the public interface after system shutdown.
Caveats Resolved in Release 3.6.7.F
Release 3.6.7.F resolves the following issues:
•
VPN 3002 Ethernet ports might hang intermittently when connected to a Centercom hub.
•
Changing from DHCP to STATIC on an interface will not stop IP event logs 29 and 34 from showing in the filterable event log.
Caveats Resolved in Release 3.6.7.E
Release 3.6.7.E resolves the following issue:
•
The User [user], Group [group] event log message for a VPN Client disconnect is now separated by comma in Release 3.6.7 and later code. In the code before 3.6.7, this comma was not present and the User [user] Group [group] event log message was separated with a space tab format.
Caveats Resolved in Release 3.6.7.D
Release 3.6.7.D resolves the following issues:
•
Autoupdate continues to retry even when tunnel fails.
•
The IPSec terminating interface is the External Interface, and the Inside Interface is the Private Interface. The Ethernet 2 (Public) interface has the Public Interface checkbox checked. but the Interface is set to "NOT CONFIGURED". When this happens, all the IPSec/NAT connections fail by giving the error:
Could not register UDP port for NAT enabled IPSec!
Unchecking the public Interface checkbox when its not configured or giving it any bogus IP Address resolves the issue, and IPSec/NAT starts working fine.
•
The load balance notify packet arrives at the VPN Client before the certificate packet, and this results in a failed connection attempt. The VPN Client sees this as a malformed packet, and the entire negotiation fails.
The VPN Client does not have the ability to inspect the certificate when it arrives after the load balanced notify packet from the VPN Concentrator. This causes the phase 1 main mode negotiations to fail.
•
The VPN 3000 Concentrator running 3.6.7 randomly fails after changing LAN-to-LAN rules.
•
A VPN 3000 Concentrator running Release 3.6.7 is not able to decode the objects in the CA certificate or in the VPN Client certificate.
The VPN 3000 Concentrator accepts the CA certificate and the certificate for the Concentrator, but in Subject and Issuer, it shows Unknown. When the VPN Client connects, it always ends up in the base group, not in the group matching the OU or group match config.
•
If the DHCP Server address pool on the VPN 3002 is modified, it will still renew IP Address from the previous address pool.
•
After upgrading to Release 3.6.7.A from 3.6.7 Rel, a VPN 3000 Concentrator does not redirect any traffic coming in from a VPN Client to across LAN-to-LAN tunnel.
•
PIX-to-PIX spoke connectivity when each PIX is connected LAN-to-LAN to a VPN 3015 Concentrator running Release 3.6.7.A is broken.
Caveats Resolved in Release 3.6.7.C
Release 3.6.7.C resolves the following issues:
•
An administrative user who has "Stats Only" permission and who attempts to view users filtered by "Group" on the Monitor | Sessions screen, sees all logged-in users instead of a filtered list.
•
If a L2L tunnel is initially configured with Auto Discovery then the routing field in the tunnel configuration is changed to 'none' the L2L:AutoDiscovery stays in the network list. If you attempt to remove the entry from the network list, the concentrator goes to 100% CPU.
The following error message appears in the log file:
564520 09/06/2002 12:05:47.830 SEV=1 L2TP/60 RPT=3 pSOS q_send failed
•
A stable system suddenly started to crash - when removed from the network, the system no longer crashed. The crash dump seems to lead to autodiscovery for LAN-to-LAN tunnels. When autodiscovery is used, each route learned eats up memory by having to create custom (hidden) filters.
•
When configuring a load balanced configuration, the shared secret can be set to cisco123. Under the VCA L2L, session a preshared key of ALTIGA is listed. Changing this preshared key results in an error:
Error updating group for LAN-to-LAN connection (Not Writable Error).
•
Cisco 3030 VPN Concentrator running 3.6.1 fails when SDI sockets are depleted. The Concentrator is leaking sockets when the SDI server responses time out (see CSCea08807). This failure is another symptom of that problem.
•
Even when the master Concentrator is shutdown, VRRP messages are still sent out. As a result, the backup Concentrator never assumes the master role.
•
The following code Assertion might occur on a system using the SEP-E as tunnels are connecting and disconnecting.
Assertion: "sa->refCnt >= 0" failed, in file fsmact.c, line 4462
•
Cisco 501 with Individual User Authentication to Cisco ACS fails. The log message on the VPN 3005 Concentrator is:
56 01/16/2003 18:55:24.480 SEV=4 AUTH/9 RPT=52
Authentication failed: Reason = No active server found
handle = 232, server = (none), user = user•
The VPN 3000 Concentrator might fail if you are viewing bandwidth management statistics from the HTML management interface.
•
If RRI (Client and/or Net extension mode) is enabled or disabled in configuration/system/ip routing/reverse route injection, and generate hold down routes is clicked before apply, the enable/disable changes that were made fail to survive. The changes revert back t
