The enhancements and changes that were available in NetScaler 11.0 releases prior to Build 65.31. The build number provided below the issue description indicates the build in which this enhancement or change was provided.
AAA-TM | AAA-TM/NetScaler Gateway | Admin Partitions | Application Firewall | Cache Redirection | CloudBridge Connector | Cluster | Command Line Interface | DNS | GSLB | HDX Insight | Load Balancing | NetScaler Gateway | NetScaler Insight Center | NetScaler SDX Appliance | Networking | Optimization | Platform | Policies | SSL | System | Telco
OAuth/OpenID-Connect Mechanisms for AAA-TM
The NetScaler AAA-TM feature now supports OAuth and OpenID-Connect mechanisms for authenticating and authorizing users to applications that are hosted on applications such as Google, Facebook, and Twitter.
Note: OAuth on NetScaler is currently qualified only for Google applications.
A major advantage is that user's information is not sent to the hosted applications and therefore the risk of identity theft is considerably reduced.
In the NetScaler implementation, the application to be accessed is represented by the AAA-TM virtual server. So, to configure OAuth, an action must be configured and associated with a AAA-TM policy which is then associated with a AAA-TM virtual server. The configuration to define a OAuth action is as follows:
> add authentication OAuthAction <name> -authorizationEndpoint <URL> -tokenEndpoint <URL> [-idtokenDecryptEndpoint <URL>] -clientID <string> -clientSecret <string> [-defaultAuthenticationGroup <string>] [-Attribute1 <string>] [-Attribute2 <string>] [-Attribute3 <string>] ....
- Refer to the man page for information on the parameters.
- Attributes (1 to 16) are attributes that can be extracted in OAuth response. Currently, these are not evaluated. They are added for future reference.
[From Build 55.23] [#491920]
Using Certificates to Log on to a SAML IdP
When used as a SAML IdP (identity provider), the NetScaler appliance now allows logon using certificates.
[From Build 55.23] [#512125]
Logging Errors in NetScaler Log Files
The NetScaler appliance now stores AAA authentication logs.
- Errors and warnings are logged in the /var/nslog/ns.log file
- Information and debug level logs are logged in the /var/log/nsvpn.log file.
[From Build 55.23] [#482228, 479557]
Including Additional Attributes in SAML IdP Assertion
When used as a SAML IdP (identity provider), the NetScaler appliance can now be configured to send 16 additional attributes in addition to the NameId attribute. These attributes must be extracted from the appropriate authentication server. For each of them, you can specify the name, the expression, the format, and a friendly name.
These attributes must be specified in the SAML IdP profile as follows:
From the CLI:
> set authentication samlIdPProfile <name> [-Attribute1 <string> -Attribute1Expr <string> [-Attribute1FriendlyName <string>] [-Attribute1Format ( URI | Basic )]] [-Attribute2 <string> -Attribute2Expr <string> [-Attribute2FriendlyName <string>] [-Attribute2Format ( URI | Basic )]]
For example, the following command adds the attribute "MyName":
> add authentication samlIdPProfile ns-saml-idp -samlSPCertName nssp -samlIdPCertName nssp -assertionConsumerServiceURL "http://nssp.nsi-test.com/cgi/samlauth" -Attribute1 MyName -Attribute1Expr http.req.user.name -Attribute1FriendlyName Username -Attribute1Format URI
From the GUI:
Navigate to the screen where you configure the SAML IdP profile, and specify the additional attributes as required.
[From Build 55.23] [#460680, 504703]
Using the SHA256 Algorithm to Sign SAML IdP Assertions
When used as a SAML IdP (identity provider), the NetScaler appliance can now be configured to digitally sign assertions by using the SHA256 algorithm. Additionally, you can configure the appliance to accept only digitally signed requests from the SAML SP (service provider).
These configurations must be specified in the SAML IdP profile as follows:
From the CLI:
> set authentication samlIdPProfile <name> [-rejectUnsignedRequests ( ON | OFF )] [-signatureAlg ( RSA-SHA1 | RSA-SHA256 )] [-digestMethod ( SHA1 | SHA256 )]
From the GUI:
Navigate to the screen where you configure the SAML IdP profile, and specify the corresponding parameters.
[From Build 55.23] [#474977]
Supporting Encrypted Assertions on SAML SP
When used as a SAML SP (service provider), the NetScaler appliance can now decrypt the encrypted tokens that it receives from the a SAML IdP. No configuration is required on the NetScaler.
[From Build 55.23] [#291693]
Using 401-based Authentication to Log on to a SAML IdP
When used as a SAML IdP (identity provider), the NetScaler appliance now allows logon using the following 401-based authentication mechanisms: Negotiate, NTLM, and Certificate.
[From Build 55.23] [#496725, 508689]
The output of "show ns ip" now also includes the aaadnatIp address.
[From Build 55.23] [#472912]
Fallback from Certificate to Other Authentication Mechanisms
When authentication is configured to be done by using certificates and then followed by LDAP or other authentication mechanisms, the following behavior holds true:
- In previous releases: If certificate authentication fails (or was skipped), the other authentication mechanism is not processed.
- From this release onwards: Even if certificate authentication is not done, the other authentication mechanism is processed.
[From Build 55.23] [#550946]
The configuration of a AAA-TM virtual server in the NetScaler GUI is simplified for ease of configuring the required authentication mechanism.
[From Build 55.23] [#524386]
Using Cookies to Track SAML Sessions
In a deployment where a NetScaler appliance is configured as a SAML IdP (identity provider) for multiple SAML SPs (service provider), the appliance allows a user to access multiple SPs without explicitly authenticating every time.The appliance creates a session cookie for the first authentication and every subsequent request uses this cookie for authentication.
[From Build 55.23] [#503882]
Fallback to NTLM Authentication
When the NetScaler appliance is configured for Negotiate authentication and sends a 401 Negotiate response to client, if client is not able to reach domain controller or is not domain joined, then it automatically falls back to NTLM authentication and the client starts NTLM handshake. The NetScaler appliance is able to verify the credentials presented as part of NTLM authentication.
This feature allows user logins locally or remotely.
[From Build 55.23] [#509829]
Support for Redirect Binding for SAML SP
When used as a SAML SP (service provider), in addition to POST bindings, the NetScaler appliance now supports redirect bindings. In redirect bindings, SAML assertions are in the URL, as against POST bindings where the assertions are in the POST body.
Using the CLI:
> add authentication samlAction <name> . . . [-samlBinding ( REDIRECT | POST )]
[From Build 55.23] [#493220, 462777, 493224]
The NetScaler appliance now supports the SiteMinder SAML SP.
[From Build 55.23] [#488077]
Encrypting SAML IdP Assertion
When used as a SAML IdP (identity provider), the NetScaler appliance can now be configured to encrypt the assertions by using the public key of the SAML SP (service provider).
- Make sure the SAML SP certificate is specified.
- For enhanced security, it is recommended that you encrypt assertions that contain sensitive information.
This configuration must be specified on the SAML IdP profile as follows:
On the CLI:
> set authentication samlIdPProfile <name> [-encryptAssertion ( ON | OFF )] [-encryptionAlgorithm <encryptionAlgorithm>]
On the GUI:
Navigate to the screen where you configure the SAML IdP profile and specify the corresponding parameters.
[From Build 55.23] [#482185]
Multi-Factor (nFactor) Authentication
The NetScaler appliance now supports a new approach to configuring multi-factor authentication. With this approach, you can configure any number of authentication factors. You can also customize the login form as required.
In NetScaler terminology, this feature is called "nFactor Authentication." For more information, see http://docs.citrix.com/en-us/netscaler/11/security/ns-aaa-app-trafc-wrapper-con-10/multi-factor-nfactor-authentication.html.
[From Build 62.10] [#482250, 451913, 549966]
Configuring Validity for SAML Assertions
A NetScaler appliance can be configured to provide SAML authentication to an application by playing the role of the SAML Identity Provider (IdP) and/or the SAML Service Provider (SP). If the system time on NetScaler SAML IdP and the peer SAML SP is not in sync, the messages might get invalidated by either party.
To avoid such cases, you can now configure the time duration for which the assertions will be valid. This duration, called the "skew time," specifies the number of minutes for which the message should be accepted. The skew time can be configured on the SAML SP and the SAML IdP.
- When the NetScaler is used as a SAML IdP, configure the skew time on the SAML IdP profile, to accept incoming requests from SP and to send assertions.
--- Using the CLI: > set samlidpProfile <name> -skewTime 30
--- Using the GUI: Navigate to Security > AAA - Application Traffic > Policies > Authentication > Advanced Policies > Policy, and in the required SAML IdP policy, configure the skew time for the SAML IdP profile.
- When the NetScaler is used as a SAML SP, configure the skew time on the SAML action.
--- Using the CLI: > set samlaction <name> -skewTime 30
--- Using the GUI: Navigate to Security > AAA - Application Traffic > Policies > Authentication > Advanced Policies > Policy, and in the required SAML SP policy, configure the skew time for the SAML action.
[From Build 64.34] [#582266]
Increased Length of SAML Attributes for Extraction
In the SAML Service Provider (SP) module, names of the attributes that can be extracted from an incoming SAML assertion can be up to 127 bytes long. The previous limit was 63 bytes.
[From Build 64.34] [#581644]
When used as a SAML SP, the NetScaler appliance can now extract multi-valued attributes from a SAML assertion. These attributes are sent is nested XML tags such as:
<saml:Attribute FriendlyName="groups" Name="groups" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified?>
<saml:AttributeValue xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:string?>
[From Build 64.34] [#577853]
SAML IdP Validating the SAML SP
When used as a SAML Identity Provider (IdP), the NetScaler appliance can be configured to serve assertions only to SAML Service Providers (SP) that are pre-configured on or trusted by the IdP. For this configuration, the SAML IdP must have the service provider ID (or issuer name) of the relevant SAML SPs.
Using the CLI:
> set samlidpProfile <name> -serviceProviderID <string>
Using the GUI:
Navigate to Security > AAA - Application Traffic > Policies > Authentication > Advanced Policies > Policy, and in the required SAML IdP policy, configure the SP ID for the SAML IdP profile.
[From Build 64.34] [#582265]
When used as a SAML IdP, the NetScaler appliance can now send multi-valued attributes in a SAML assertion.
[From Build 64.34] [#588125]
Support for Redirect Binding for SAML IdP
When used as a SAML Identity Provider (IdP), the NetScaler appliance now supports redirect bindings (in addition to POST binding).
Using the CLI:
> set authentication samlIdPProfile <name> -samlBinding REDIRECT
Using the GUI:
Navigate to Security > AAA - Application Traffic > Policies > Authentication > Advanced Policies > Policy, and in the required SAML IdP policy, configure the SAML binding as "Redirect" for the SAML IdP profile.
[From Build 64.34] [#564947, 590768]
Scriptable monitors can now be configured on the admin partitions that are available on a NetScaler appliance.
[From Build 55.23] [#535494]
Getting NetScaler Trace for Specific Partitions
You can now generate the NetScaler trace for a specific admin partition. To do so, you must access that admin partition and run the "nstrace" operation. The trace files for the admin partition will be stored in the /var/partitions/<partitionName>/nstrace/ directory.
[From Build 55.23] [#496937, 515294]
Setting L2 and L3 parameters in Admin Partitions
On a partitioned NetScaler appliance, the scope of updating the L2 and L3 parameters is as follows:
- For L2 parameters that are set by using the "set L2Param" command, the following parameters can be updated only from the default partition, and their values are applicable to all the admin partitions: maxBridgeCollision, bdgSetting, garpOnVridIntf, garpReply, proxyArp, resetInterfaceOnHAfailover, and skip_proxying_bsd_traffic. The other L2 parameters can be updated in specific admin partitions, and their values are local to those partitions.
- For L3 parameters that are set by using the "set L3Param" command, all parameters can be updated in specific admin partitions, and their values are local to those partitions. Similarly, the values that are updated in the default partition are applicable only to the default partition.
[From Build 55.23] [#513564]
Getting Web Logs for Specific Partitions/Users
Using the NetScaler Web Logging (NSWL) client, the NetScaler can now retrieve the web logs for all the partitions with which the logged in user is associated. To view the partition for each log entry, customize the log format to include the %P option. You can then filter the logs to view the logs for a specific partition.
[From Build 55.23] [#534986]
Supporting Dynamic Routing in Admin Partitions
While dynamic routing (OSPF, RIP, BGP, ISIS, BGP+) is by default enabled on the default partition, in an admin partition, it must be enabled by using the following command:
> set L3Param -dynamicRouting ENABLED
Note: A maximum of 63 partitions can run dynamic routing (62 admin partitions and 1 default partition).
[From Build 55.23] [#514848]
Configuring Integrated Caching on a Partitioned NetScaler
Integrated caching (IC) can now be configured for admin partitions. After defining the IC memory on the default partition, the superuser can configure the IC memory on each admin partition such that the total IC memory allocated to all admin partitions does not exceed the IC memory defined on the default partition. The memory that is not configured for the admin partitions remains available for the default partition.
For example, if a NetScaler appliance with two admin partitions has 10 GB of IC memory allocated to the default partition, and IC memory allocation for the two admin partitions is as follows:
- Partition1: 4 GB
- Partition2: 3 GB
Then, the default partition has 10 - (4 + 3) = 3 GB of IC memory available for use.
Note: If all IC memory is used by the admin partitions, no IC memory is available for the default partition.
[From Build 55.23] [#481444, 484618]
Partition Specific Load Balancing Parameters
When you update load balancing parameters in an admin partition, the updates now apply to that partition only. You can have different load balancing parameter settings in different partitions.
- In previous releases, any updates to these parameters were applied across all partitions, regardless of the partition in which the changes were made.
- These parameters are set in the CLI by using the "set lb parameter" command or in the GUI by navigating to Traffic Management > Load Balancing.
[From Build 62.10] [#563004]
The following load balancing features can now be configured in admin partitions:
- DBS autoscale
- Stateless connection mirroring
- Graceful shutdown
For the detailed list of NetScaler feature support on admin partitions, see http://docs.citrix.com/en-us/netscaler/11/system/admin-partition/admin-partition-config-types.html.
[From Build 64.34] [#588406]
The NetScaler appliance now supports FTP load balancing in admin partitions.
[From Build 64.34] [#568811]
All application firewall graphical user interface (GUI) dialog boxes, including the ones for signatures, visualizer, and syslog viewer, are now completely free from any java dependencies and show a significant improvement in the overall performance. The HTML based GUI dialogues have been re-organized for enhanced user experience and intuitive workflow of information. Instead appearing in of pop-up dialog boxes with tabs, the information is now displayed as an in-line expansion. You can expand all the configuration sections and scroll up and down for a comprehensive view.
[From Build 55.23] [#506157]
All application firewall graphical user interface (GUI) dialog boxes, including the ones for signatures, visualizer, and syslog viewer, are now completely free from any java dependencies and show a significant improvement in the overall performance. The HTML based GUI dialogues have been re-organized for enhanced user experience and intuitive workflow of information. Instead appearing in of pop-up dialog boxes with tabs, the information is now displayed as an in-line expansion. You can expand all the configuration sections and scroll up and down for a comprehensive view.
[From Build 55.23] [#520048]
The application firewall is fully supported in striped, partially striped, or spotted configurations. The two main advantages of striped and partially striped virtual server support in cluster configurations are the following:
- Session failover support: Striped and partially striped virtual server configurations support session failover. The advanced application firewall security features, such as Start URL Closure and the Form Field Consistency check, maintain and use sessions during transaction processing. In ordinary high availability configurations, or in spotted cluster configurations, when the node that is processing the application firewall traffic fails, all the session information is lost and the user has to reestablish the session. In striped virtual server configurations, user sessions are replicated across multiple nodes. If a node goes down, a node running the replica becomes the owner. Session information is maintained without any visible impact to the user.
- Scalability: Any node in the cluster can process the traffic. Multiple nodes of the cluster can process the incoming requests served by the striped virtual server. This improves the application firewall's ability to handle multiple simultaneous requests, thereby improving the overall performance.
Security checks and signature protections can be deployed without the need for any additional cluster-specific application firewall configuration. You just do the usual application firewall configuration on the configuration coordinator (CCO) node for propagation to all the nodes.
Cluster details are available at http://docs.citrix.com/en-us/netscaler/11/system/clustering.html.
[From Build 55.23] [#408831, 403780]
Geolocation, which identifies the geographic location from which requests originate, can help you configure the application firewall for the optimal level of security. For example, if an excessively large number of requests are received from a specific area, it is easy to determine whether they are being sent by users or a rogue machine. The application firewall offers you the convenience of using the built-in NetScaler database or any other geolocation based database to identify the source of origin of coordinated attacks launched from a country. This information can be quite useful for enforcing the optimal level of security for your application to block malicious requests originating from a specific geographical region. Geolocation logging uses the Common Event Format (CEF).
To use Geolocation Logging
1. Enable CEFLogging and GeoLocationLogging.
>set appfw settings GeoLocationLogging ON CEFLogging ON
2. Specify the database
>add locationfile /var/netscaler/inbuilt_db/Citrix_Netscaler_InBuilt_GeoIP_DB.csv
add locationfile <path to database file>
[From Build 55.23] [#483703]
The NetScaler application firewall module offers data leak prevention and supports credit card protection. It can examines the credit card numbers in the response and takes the specified action if a match is found. In some scenarios, it might be desirable to exclude a specific set of numbers from the credit card security check inspection. For example, server responses for some internet applications might include a string of digits that is not a credit card number but matches the pattern of a credit card number. These responses can trigger false positives and therefore get blocked by the application firewall's Credit Card security check. The application firewall now offers the ability to learn and deploy relaxations for the credit card numbers. The credit card relaxation rule provides the flexibility to exclude a specific string of numbers from the safe commerce check without compromising credit card security. These numbers are not examined in the responses even if the credit card check is ON.
Examples of CLI Commands:
1. Bind the credit card number to profile:
bind appfw profile <profile-name> -creditCardNumber <any number/regex> "<url>"
2. Unbind credit card number from profile:
unbind appfw profile <profile-name> -creditCardNumber <credit card number> "<url>"
3. Log: Enable Logging of credit card Numbers
add appfw profile <profilename> - doSecureCreditCardLogging <ON/OFF>
set appfw profile <profilename> - doSecureCreditCardLogging <ON/OFF>
show appfw learningdata <profilename> creditCardNumber
rm appfw learningdata <profilename> -creditcardNumber <credit card number> "<url>"
export appfw learningdata <profilename> creditCardNumber
[From Build 55.23] [#383298]
The NetScaler application firewall offers SQL/XSS security check protections to detect and block possible attacks against the applications. You now have much tighter security control when configuring SQL/XSS protections. Instead of deploying relaxation rules that completely bypass the security check inspection for a field, you now have an option to relax a specific subset of violation patterns. You can continue to inspect the relaxed field in the incoming requests to detect and block the rest of the SQL/XSS violation patterns. The commands used in relaxations and learning now have optional parameters for value type and value expression. You can specify whether the value expression is a regular expression or a literal string.
Command Line Interface:
bind appfw profile <name> -SQLInjection <String> [isNameRegex (REGEX | NOTREGEX)] <formActionURL> [-location <location>] [-valueType (Keyword| SpecialString|Wildchar) [<valueExpression>][-isValueRegex (REGEX | NOTREGEX) ]]
unbind appfw profile <name> -SQLInjection <String><formActionURL> [-location <location>][-valueType (Keyword|SpecialString|Wildchar) [<valueExpression>]]
bind appfw profile <name> -crossSiteScripting <String> [isNameRegex (REGEX | NOTREGEX)] <formActionURL> [-location <location>] [-valueType (Tag| Attribute|Pattern) [<valueExpression>][-isValueRegex (REGEX | NOTREGEX) ]]
unbind appfw profile <name> -crossSiteScripting <String> <formActionURL> [-location <location>] [-valueType (Tag|Attribute|Pattern) [<valueExpression>]]
[From Build 55.23] [#450324, 483683]
The field format rules specify the inputs that are allowed in the target form fields. You can also limit the minimum and the maximum allowed length for the inputs. The application firewall learning engine monitors the traffic and provides field format recommendations based on the observed values. If the initial field format learned rules are based on a small sample of data, a few non typical values might possibly result in a recommendation that is too lenient for the target field. Updates to the application firewall have now decoupled violations and learning for the field formats. The firewall learns the field formats regardless of the violations. The learning engine monitors and evaluates all the incoming new data points to recommend new rules. This allows fine tuning the configuration to specify optimal input formats with adequate min/max range values. If a rule has already been deployed for a field/URL combination, the GUI allows the user to update the field format. A dialog box asks for confirmation to replace the existing rule. If you are using the command line interface, you have to explicitly unbind the previous binding and then bind the new rule.
[From Build 55.23] [#450326, 483677, 513927]
Support for default syntax expressions
You can now use default syntax expressions in cache redirection policies. The NetScaler appliance provides built-in cache redirection policies based on default syntax expressions, or you can create custom cache redirection policies to handle typical cache requests. In addition to the same types of evaluations done by classic cache redirection policies, the default syntax policies enable you to analyze more data (for example, the body of an HTTP request) and to configure more operations in the policy rule (for example, directing requests to either cache or origin server).
[From Build 55.23] [#490297, 495915, 536986, 536992, 537010, 537014, 538269]
Support for IPv6 Traffic through IPV4 Tunnels
The NetScaler appliance now supports transferring IPv6 traffic through a IPV4 GRE tunnel. This feature can be used for enabling communication between Isolated IPv6 networks without upgrading the IPv4 infrastructure between them.
For configuring this feature, you associate an PBR6 rule with the configured IPv4 GRE tunnel through which you want the NetScaler to send and receive IPv6 traffic. The source IPv6 address and destination IPv6 address parameters of the PBR6 rule specify the IPv6 networks whose traffic is to traverse the IPv4 GRE tunnel.
[From Build 55.23] [#497414]
Disabling Steering on the Cluster Backplane
By default, a NetScaler cluster steers traffic over the cluster backplane, from the flow receiver node to the flow processor node. You can disable steering so that the process becomes local to the flow receiver and thereby ensure that the flow receiver also becomes the flow processor. Such a configuration can come in handy when you have a high latency link.
Note: This configuration is applicable only for striped virtual servers.
Steering can be disabled at the global NetScaler level or at the individual virtual server level. The global configuration takes precedence over the virtual server setting.
- At the global level, steering can be disabled for all striped virtual servers. It is configured at cluster instance level. Traffic meant for any striped virtual server will not be steered on cluster backplane. The command is:
> add cluster instance <clId> -processLocal ENABLED
- At a virtual server level, you can disable steering for a specific striped virtual server. It is configured on a striped virtual server. Traffic meant for that virtual server will not be steered on cluster backplane. The command is:
> add lb vserver <name> <serviceType> -processLocal ENABLED
For more information, see http://docs.citrix.com/en-us/netscaler/11/system/clustering/cluster-managing/cluster-steering-disable.html.
[From Build 55.23] [#539136]
Link Redundancy based on Minimum Throughput
In a dynamic cluster link aggregation (LA) deployment that has link redundancy enabled, you can configure the cluster to select the partner channel or interface on the basis of its throughput. To do this, configure a threshold throughput on the channel or interface as follows:
> set channel CLA/1 -linkRedundancy ON -lrMinThroughput <positive_integer>
The throughput of the partner channels is checked against the configured threshold throughput. The partner channel that satisfies the threshold throughput is selected in FIFO manner. If none of the partner channel meets the threshold, or if threshold throughput is not configured, the partner channel with the maximum number of links is selected.
[From Build 55.23] [#508993]
Nodegroup for Datacenter Redundancy
A cluster nodegroup can now be configured to provide datacenter redundancy. In this use case, nodegroups are created by logically grouping the cluster nodes. You must create active and spare nodegroups. When the active nodegroup goes down, the spare nodegroup which has the highest priority (the lower priority number) is made active and it starts serving traffic.
For more information, see http://docs.citrix.com/en-us/netscaler/11/system/clustering/cluster-managing/cluster-nodegroups-datacenter-redundancy.html.
[From Build 55.23] [#495019]
Routing in a L3 Cluster
In a L3 cluster, different nodegroups can have different VLANs and subnets associated with them. This can result in a VLAN getting exposed only in some nodes. Therefore, you can now configure dynamic routing on a VLAN to expose the VLAN to ZebOS even when there are no IP addresses with dynamic routing that are bound to it. The command to configure this is:
> add/set vlan <id> -dynamicRouting (ENABLED | DISABLED)
- This option is also available for VXLAN and BridgeGroups.
- This configuration can also be used for L2 clusters.
[From Build 55.23] [#531868]
BridgeGroups are now supported in a NetScaler cluster deployment.
[From Build 55.23] [#494991]
Routing on Striped SNIP addresses
You can now run dynamic routing on a striped SNIP address in a NetScaler cluster. The routes advertised by the cluster have the striped SNIP as the next hop. There is just one adjacency with the cluster. Internally, the cluster picks one of the active nodes as the routing leader. When the current routing leader goes down, the routing ownership moves to an active node.
- Striped SNIP addresses are useful mainly for cluster LA (link aggregation) deployments. They can also be used for ECMP, but the multipath routing functionality is unavailable.
- Striped SNIP addresses can also be used in asymmetrical topologies.
- Routing on striped SNIPs and routing on spotted SNIPs can coexist in a cluster.
To specify leader node configurations, in the VTYSH shell, use the "owner-node leader" command.
[From Build 55.23] [#329439]
Reduce Backplane Steering for Spotted and Partially-striped Virtual Serves when Using ECMP
With the Equal Cost Multiple Path (ECMP) mechanism, virtual server IP addresses are advertised by all active cluster nodes. This means that traffic can be received by any cluster node, which then steers the traffic to the node that must process the traffic. While there are no hassles in this approach, there can be a lot of redundant steering in case of spotted and partially striped virtual servers. Therefore, from NetScaler 11 onwards, spotted and partially striped virtual server IP addresses are advertised only by the owner nodes. This reduces the redundant steering.
You can override this default behavior, by entering the following command in the VTYSH shell:
ns(config)# ns spotted-vip-adv all-nodes
[From Build 55.23] [#317706]
Cluster to Include Nodes from Different Networks (L3 Cluster)
You can now create a cluster that includes nodes from different networks. To configure a cluster over L3, you must add the nodes of different networks to different nodegroups. For more information, see http://docs.citrix.com/en-us/netscaler/11/system/clustering/cluster-setup.html.
You can transition an existing L2 cluster to an L3 cluster. For instructions, see http://docs.citrix.com/en-us/netscaler/11/system/clustering/cluster-usage-scenarios/cluster-migrate-between-l2-l3.html.
[From Build 55.23] [#374289, 317257]
Web Interface on NetScaler (WIonNS) Support on a Cluster
WIonNS can now be configured on a NetScaler cluster deployment. To use WIonNS on a cluster, you must do the following:
1. Make sure that the Java package and the WI package are installed in the same directory on all the cluster nodes.
2. Create a load balancing virtual server that has persistency configured.
3. Create services with IP addresses as the NSIP address of each of the cluster nodes that you want to serve WI traffic.
4. Bind the services to the load balancing virtual server.
Note: If you are using WIonNS over a VPN connection, make sure that the load balancing virtual server is set as WIHOME.
[From Build 62.10] [#498295, 489463]
FTP Load Balancing Support on a Cluster
FTP load balancing is now supported in a NetScaler cluster deployment.
[From Build 62.10] [#513612]
When you are upgrading a cluster to NetScaler 11.0 build 64.x from an earlier NetScaler 11.0 build, cluster configuration propagation is disabled.
Traditionally, this issue occurred only during an upgrade of a cluster to a different NetScaler version (for example, from 10.5 to 11.0). This exception arises because the cluster version in build 64.x is different from the one in previous NetScaler 11.0 builds.
Note: Normally, the cluster version matches the NetScaler version.
Configuration propagation remains disabled until all the cluster nodes are upgraded to Build 64.x.
[From Build 64.34] [#591877]
Reducing the Minimum Value for the Dead Interval
You can now set the dead interval for a cluster instance to a minimum value of 1 second.
Note: If the dead interval value is less than 3 seconds, set the hello interval parameter to 200 ms.
[From Build 64.34] [#573218]
The NetScaler administrator can now specify the maximum number of concurrent sessions a user can log on to the CLI. Although logons to the configuration utility do not count against the limit, all logon attempts are denied after the limit is reached. For example, if the maximum number of concurrent sessions is set to 20, a user can log on to the CLI 19 times and can log on to the configuration utility any number of times. Once the user logs on to the CLI for the 20th time, he or she can no longer log on to the CLI or the configuration utility. Any logon attempt then results in a system error message.
[From Build 64.34] [#491778]
Rewrite and responder support for DNS
The rewrite and responder features now support DNS. You can now configure rewrite and responder functionalities to modify DNS requests and responses as you would for HTTP or TCP requests and responses.
[From Build 55.23] [#405769]
Support for DNS Logging
You can now configure a NetScaler appliance to log DNS requests and responses. The logs are in SYSLOG format. You can use these logs to:
- Audit the DNS responses to the client
- Audit DNS clients
- Detect and prevent DNS attacks
[From Build 55.23] [#419632, 561291]
Enable or disable negative caching of DNS records
The NetScaler appliance supports caching of negative responses for a domain. You can enable or disable negative caching from the command line, by setting cacheNegativeResponses with the set dns parameter command, or in the configuration utility, in the Configure DNS Parameters dialog box.
Note: You can enable or disable negative caching independent of global caching. By default, negative caching is enabled.
[From Build 55.23] [#391254]
Support for binding a single Virtual Server as a backup for multiple GSLB Virtual servers
In a GSLB site deployment, you can now bind a single virtual server as a backup virtual server for multiple GSLB virtual servers in the deployment.
[From Build 55.23] [#373061]
GSLB Service Selection using Content Switching
Description: You can now configure a content switching (CS) policy to customize a GSLB deployment so that you can:
* Restrict the selection of a GSLB service to a subset of GSLB services bound to a GSLB virtual server for the given domain.
* Apply different Load Balancing methods on the different subsets of GSLB services in the deployment.
* Apply spillover policies on a subset of GSLB services, and you can have a backup for a subset of GSLB services.
* Configure a subset of GSLB services to serve a specific type of content.
* Define a subset GSLB services with different priorities, and define the order in which the services in the subset are applied to a request.
For more information, see Configuring GSLB Service Selection Using Content Switching.
[From Build 63.16] [#503588]
NetScaler GSLB deployments support NAPTR records
In GSLB deployments, the NetScaler appliance now supports DNS queries with NAPTR records. You can now configure a NetScaler appliance to receive DNS queries with NAPTR records from clients (for example, Mobile Management Entity (MME))and respond with the list of services configured for a domain. Also, the NetScaler appliance monitors the health of the services and in the response it provides only the list of services that are up.
[From Build 64.34] [#468647]
Ability to specify GSLB Site IP address as source IP address for an RPC node
You can now configure the NetScaler appliance to use GSLB Site IP address as the source IP address for an RPC node.
[From Build 64.34] [#531395]
HDX Insight now supports displaying of Appflow records from Netscaler cluster.
[From Build 62.10] [#525758]
Support for Secure LDAP Monitor
You can now monitor LDAP services over SSL. To monitor the LDAP services over SSL, use the built-in LDAP monitor or create a user monitor and enable the "secure" option.
[From Build 55.23] [#418061, 556530]
IPv6 Support for HTTP based User Monitors
You can now use IPv6 addresses in the following monitors:
Note: The monitor for MySQL does not support IPv6 addresses.
[From Build 55.23] [#510111]
If you have set the persistence type to COOKIEINSERT, you can now encrypt the cookie in addition to any existing SSL encryption by using the NetScaler command line and configuration utility.
At the NetScaler command prompt, type:
set lb parameter -useSecuredPersistenceCookie Enabled-cookiePassphrase test
In the configuration utility, navigate to Traffic Management > Load Balancing > Change Load Balancing Parameters and select Use Secured Persistence Cookie and Cookie Passphrase and enter a passphrase.
[From Build 55.23] [#347108, 323325, 348588]
New Trap for Spillover
If you have configured spillover on a virtual server and also configured a trap listener on the appliance, an SNMP trap is now sent to the trap listener when the virtual server experiences spillover. The trap message displays the name of the virtual server that experienced the spillover, the spillover method, the spillover threshold, and the current spillover value. If the spillover is policy based, the rule causing it appears in the Spillover Threshold field. If the virtual server is DOWN or disabled, the status message "vserver not up" appears in the trap message.
[From Build 55.23] [#486268, 475400]
Setting the Maintenance State for your Server with Minimal Interruption
You can now set the maintenance state for your server with minimal interruption and without changing any configuration on the NetScaler appliance. In the maintenance state, the server continues to accept persistent client connections while new connections are load balanced among the active servers. On the NetScaler appliance, configure a transition out of service (TROFS)-enabled monitor and bind it to a service representing the server. Specify a trofsCode or trofsString in the monitor. Upon receipt of a matching code or string from the server in response to a monitor probe, the appliance places the service in the TROFS state. During this time, it continues to honor persistent client connections.
To avoid disrupting established sessions, you can place a service in the TROFS state by doing one of the following:
- Adding a TROFS code or string to the monitor: Configure the server to send a specific code or string in response to a monitor probe.
- Explicitly disable the service and:
- Set a delay (in seconds).
- Enable graceful shut down.
Adding a TROFS Code or String
Note: This enhancement is not applicable to GSLB services.
From release 11, if you bind only one monitor to a service, and the monitor is a TROFS-enabled monitor, it can place the service in the TROFS state on the basis of the server's response to a monitor probe. This response is compared with the value in the trofsCode parameter for an HTTP monitor or the trofsString parameter for an HTTP-ECV or TCP-ECV monitor. If the code matches, the service is placed in the TROFS state. In this state, it continues to honor the persistent connections.
If multiple monitors are bound to a service, the effective state of the service is calculated on the basis of the state of all the monitors that are bound to the service. Upon receiving a TROFS response, the state of the TROFS-enabled monitor is considered as UP for the purpose of this calculation. For more information about how a NetScaler appliance designates a service as UP, see http://docs.citrix.com/en-us/netscaler/10-5/ns-tmg-wrapper-10-con/ns-lb-wrapper-con-10/ns-lb-clienttraffic-con/ns-lb-clienttraffic-gracefulshutdown-tsk.html.
- You can bind multiple monitors to a service, but only one monitor must be TROFS-enabled.
- You can convert a TROFS-enabled monitor to a monitor that is not TROFS-enabled, but not vice versa.
[From Build 55.23] [#408103]
Automatic Restart of the Internal Dispatcher
In earlier releases, if the internal dispatcher failed, the services that used scriptable monitors also went down and the appliance had to be restarted. From release 11, if the internal dispatcher fails, the pitboss process restarts it. As a result, you no longer have to restart the appliance. For information about user monitors, see http://docs.citrix.com/en-us/netscaler/11/traffic-management/load-balancing/load-balancing-custom-monitors/understand-user-monitors.html.
[From Build 55.23] [#368128]
The following global timeouts has been introduced for TCP sessions on a NetScaler appliance related to RNAT rules, forwarding sessions, or load balancing configuration of type ANY:
* Any TCP Client. Global idle timeout, in seconds, for TCP client connections. Client timeout set for an entity overrides the global timeout setting.
* Any TCP Server. Global idle timeout, in seconds, for TCP server connections. Server timeout set for an entity overrides the global timeout setting.
These timeout can be set either from the NetScaler command line (set ns timeout command) or from the configuration utility (System > Settings > Change Timeout Values page).
Note: For applying these timeouts to a virtual server or service of type ANY, set these timeouts before adding the virtual server or the service.
[From Build 55.23] [#507701]
If you configure cookie persistence and custom cookie on a virtual server, and later change the name or IP address of the virtual server, persistence is not honored.
[From Build 55.23] [#524079, 559022]
With the following new OID, you can use SNMP to learn the current number of server connections per service.
[From Build 64.34] [#548470]
Retaining the Original State of a Service Group Member after Disabling and Enabling a Virtual Server
A new global option, -retainDisableServer, enables you to retain a service-group member's state when a server is disabled and reenabled.
Previously, a member's state would change from DISABLED to ENABLED under the following set of conditions:
- Two applications are deployed on the same port on a virtual server.
- Two service groups with a common member are bound to this virtual server, and the common member is enabled in one group and disabled in the other.
- The server is disabled and then reenabled.
Under these conditions, disabling the server disables all the service group members, and reenabling the server enables all the members, by default, regardless of their earlier states. To bring the members back to the original states, you must manually disable those member(s) in the service group. This is a cumbersome task and prone to errors.
[From Build 64.34] [#493692]
With the following new OID, you can use SNMP to learn the effective state of a virtual server.
[From Build 64.34] [#538499]
Support for Unauthenticated Stores
In earlier releases, the StoreFront monitor tried to authenticate anonymous stores. As a result, a service could be marked as DOWN and you could not launch XenApp or XenDesktop by using the URL of the load balancing virtual server.
The probe order has changed. The monitor now determines the state of the StoreFront store by successively probing the account service, the discovery document, and then the authentication service, and skips authentication for anonymous stores.
[From Build 64.34] [#575549]
Striped Cluster for NetScaler Gateway in ICA Proxy Mode
This feature allows administrators to deploy NetScaler Gateway with XenApp and XenDesktop in a striped style cluster where all nodes in the cluster serve traffic. Administrators can use existing Gateway configurations and scale seamlessly in a cluster deployment without having to restrict the VPN configuration to a single node.
Note that this feature is limited to ICA Proxy basic mode virtual servers and does not support SmartAccess.
[From Build 55.23] [#490329, 503332]
This enhancement adds support for cross-domain Kerberos constrained delegation when both the user and the service realm have a two-way shortcut trust. That is, if the user and service belong to different domains/realms, constrained delegation fails. However, if a user logs on with a user name and password, Kerberos Single Sign-On works for cross-domain access, because the NetScaler Gateway appliance does Kerberos impersonation with the user password. NetScaler Gateway currently does not otherwise support cross-domain constrained delegation.
[From Build 55.23] [#444387]
SharePoint 2013 and Outlook Web Access 2013 are supported with clientless VPN access mode.
[From Build 55.23] [#494995]
NetScaler now uses SPNEGO encapsulation on Kerberos tickets that are sent to backend web applications and servers.
[From Build 55.23] [#404899]
The Portal Customization options have been expanded to allow end-to-end customization of the VPN user portal. Administrators can apply themes to their VPN portal design or use them as a foundation for their own customization or branding. An option to present VPN users an End User License Agreement (EULA) has also been added to the portal design. Portal themes and EULAs can be bound to a VPN virtual server or specified as global VPN parameters.
[From Build 55.23] [#489467]
Plug-in Icon Decoupling from Citrix Receiver
The desktop client plug-ins icons can now be configured to operate independently from Native Citrix Receiver clients. Settings to manage Receiver integration with the NetScaler Gateway Plug-ins can be configured globally and within session policies.
[From Build 55.23] [#406312]
WebFront is an alternative integration point for XenApp and XenDesktop deployments served by StoreFront. Resident on NetScaler, WebFront uses caching and packet flow optimization in the distribution of user stores. These techniques improve end user experience for Receiver for Web users and speeds up single sign-on for native Receiver users. In the NetScaler configuration utility, the WebFront feature is on the Configuration tab at System --> WebFront.
[From Build 55.23] [#497619]
NetScaler Gateway now has a full Linux VPN client plug-in. The plug-in is supported on Ubuntu 12.04 and 14.04 distributions.
[From Build 55.23] [#495767]
The Unified Gateway Wizard for XenDesktop/Xenapp Application creates wrong configurations with the Storefront option. The client launches the Java plug-in instead of Win/Mac/iOS/Android plug-in.
[From Build 55.23] [#576275]
The WebFront enhancement supports the transparent SSO feature when accessed from the Citrix Receiver. WebFront optimizes packet flow and improves performance for users accessing StoreFront through Gateway using Citrix Receivers. Data transferred over WAN is reduced by 41%.
[From Build 55.23] [#497625]
NetScaler Gateway now has an Android client plug-in that supports full VPN capabilities. The plug-in supports Android versions 4.1 and later.
[From Build 55.23] [#520483]
The SmartControl feature allows administrators to apply access policies for various XenApp and XenDesktop attributes through NetScaler Gateway without the need for identical policy duplication on the XenApp or XenDesktop servers.
[From Build 55.23] [#525947]
Automatic session timeout can be enabled for ICA connections as a VPN parameter. Enabling this parameter forces active ICA connections to time out when a VPN session closes.
[From Build 55.23] [#358672, 527884]
If a StoreFront application is created using the Unified Gateway Wizard, the configuration of the following session actions need to be updated.
If a configured wihome ends with "web", then update the wihome.
For example, if wihome is "/citrix/storeweb
set vpnsessionAction AC_WB_<UG_IPADDRESS> -wihome ?/citrix/storeweb?
set vpnsessionAction AC_OS_<UG_IPADDRESS> -wihome ?/citrix/storeweb?
Also, initiate the following commands before to update the "client choices" and "transparent" interception options.
set vpnsessionAction AC_WB_<UG_IPADDRESS> -clientchoices ON ?transparentinterception ON
set vpnsessionAction AC_OS_<UG_IPADDRESS> -clientchoices OFF ?transparentinterception OFF
These steps must be manually performed using the CLI or the NeScaler configuration utility.
1. Using the configuration utility, navigate to "NetScaler Gateway -> Policies -> Session -> Session Profiles and edit the relevant profile.
2. Navigate to "Published Application Tab" and update the "Web Interface Address" field ( this corresponds to the wihome setting mentioned above ).
3. Go to the "Client Experience" tab and then click to the "General" tab and update client choices as mentioned above for the corresponding actions.
4. On the "Client Experience" tab set the "plugin type" field as "Windows/ MAC OS X" for the relevant profiles as mentioned above.
[From Build 55.23] [#576101, 576304]
Support for Common Gateway Protocol (CGP) over WebSockets
NetScaler Gateway virtual servers have improved intelligence for handling CGP traffic destined for the common CGP port, 2598, over WebSockets. This enhancement allows Receiver for HTML5 user sessions through NetScaler Gateway to support Session Reliability.
[From Build 55.23] [#519899]
NetScaler Gateway now has a full iOS VPN client plug-in. The plug-in is supported on iOS 7 and later releases.
[From Build 55.23] [#587571]
This enhancement adds support to disable Autoupdate for NetScaler Gateway Endpoint Analysis and VPN plug-in.
[From Build 55.23] [#236620]
NetScaler with Unified Gateway
This feature extends NetScaler Gateway connectivity with access to any web application through a single URL, along with seamless single sign-on and sign-off. Single URL access can be configured for:
- Internal organizational web applications
- Software as a Service applications, including SAML based single sign-on when available
- Outlook Web Access and SharePoint as clientless applications
- Load balanced applications served through NetScaler load balancing virtual servers
- XenApp and XenDesktop published resources.
The feature can be configured and managed with the Unified Gateway wizard in the NetScaler configuration utility.
[From Build 55.23] [#519875]
NetScaler Gateway now supports Windows 10.
[From Build 62.10] [#579428]
NetScaler Gateway now supports the new UDP-based Framehawk virtual channel.
[From Build 62.10] [#587560]
For Linux Clients, support for binding Intranet IPv6 to VPN Virtual Server is introduced.
IPv6 binding with VPN Global support is also introduced with the same.
[From Build 63.16] [#556101]
The NetScaler appliance was enhanced so the Portal Theme can be added using the NetScaler Gateway Wizard.
[From Build 63.16] [#591427]
DTLS-TURN support for Unified Gateway was added. For Unified Gateway, the CS virtual server is the end-point that users connect. The VPN virtual server has to be bound as the target virtual server. This functionality enables support for secure external access using Framehawk display channel with XenApp and XenDesktop.
[From Build 64.34] [#593568]
The VPN plugin was enhanced to acknowledge the intranet application protocol flag. ICMP blocking can be achieved by configuring separate intranet applications for UDP and TCP.
[From Build 64.34] [#589202]
NetScaler Gateway provides an RDP enforcement feature. NetScaler administrators can disable RDP capabilities through the NetScaler Gateway configuration.
The following are configurable as part of the RDP client profile.
- Redirection of ClipBoard
- Redirection of Printers
- Redirection of Disk Drives
[From Build 64.34] [#581578]
Support for EPA verbose logging was added.
[From Build 64.34] [#590932, 591183]
The Dual-Hop enhancement enables next-hop requests to be distributed among several available NetScalers. The Dual-Hop feature expands the capability to load balance across any next-hop server, so that if one next-hop server is unavailable, connections can be re-established using another available server.
This enhancement supports the below configurations:
- Create a LB Vserver on DMZ NetScaler for the next-hop targets, and allow this LB to be added as a Next-Hop Server.
- Specify a next-hop server as an FQDN name so a GSLB solution could be used
[From Build 64.34] [#524991]
Unified Gateway now supports the same cluster functionality as supported by the NetScaler Gateway. Earlier Unified Gateway did not support a cluster environment.
[From Build 64.34] [#593064]
The default value for the VPN parameter "transparentInterception" is now set to OFF. You must set it to ON when full tunnel access is needed. For more information, see https://www.citrix.com/blogs/2015/12/11/new-vpn-default-in-netscaler-11-0.
[From Build 64.34] [#560267, 564572]
You can now configure NetScaler Insight Center to display the reports in your local time or GMT time.
[From Build 55.23] [#491073]
You can now save the Web Insight reports or HDX Insight reports in PDF, JPEG, PNG , or CSV format on your local computer. You can also schedule the export of the reports to specified email addresses at various intervals.
For more information, see http://docs.citrix.com/en-us/netscaler-insight/11-0/viewing-reports/ni-export-report-con.html.
[From Build 55.23] [#320860]
You can now identify the root cause of a terminated ICA session by viewing the session termination reason on the HDX Insight node. Along with the termination reason, it also displays the session TCP metrics such as ICA RTT and WAN Latency.
[From Build 55.23] [#488279]
You can now configure a DNS server when you set up NetScaler Insight Center. Configuring a DNS server helps resolve the host name of a server into its IP address.
For example, while creating an email server, you now have an option to specify the server name of the server rather than the IP address.
[From Build 55.23] [#514612]
Insight Deployment Management
You can now improve the processing power of and increase storage space in your NetScaler Insight Center deployment by adding agents, connectors, and databases. An agent processes HTTP traffic and sends the data to the connectors that distribute this data across databases. You can add multiple agents, connectors, and databases to scale your deployment. In this deployment, you can also the decide the number of resources you have to allocate and determine the elements you need in the database architecture, on the basis of the number of HTTP requests per second, number of ICA sessions, and number of active WAN connections.
[From Build 55.23] [#404919]
You can configure NetScaler Insight Center to display the geo maps for a particular geographical location or LAN by specifying the private IP range (start and end IP address) for the location.
[From Build 55.23] [#502478]
The WAN Insight feature of NetScaler Insight Center gives CloudBridge administrators an easy way to monitor the accelerated and unaccelarted WAN traffic that flows through CloudBridge datacenter and CloudBridge branch appliances, and it provides end-to-end visibility that includes client-specific data, application-specific data, and branch- specific data. With the ability to identify and monitor all the applications, clients, and branches on the network, you can effectively deal with the issues that degrade performance.
[From Build 55.23] [#430882]
After an ICA connection is established between a client and a NetScaler Gateway appliance, errors or old receiver or server versions, can prevent the appliance from exporting the AppFlow records to NetScaler Insight Center.
In such cases, the NetScaler Insight Center dashboard now displays the reasons for which the NetScaler appliance does not export the AppFlow records.
[From Build 55.23] [#504954]
NetScaler Insight Center now supports monitoring NetScaler appliances deployed in LAN user mode. The dashboard now displays the following user access types, depending on the NetScaler deployment:
- Remote user: User connected to XenApp or XenDesktop server through a NetScaler Gateway.
- Transparent mode user: User connected to XenApp or XenDesktop server directly, with no intervening virtual server.
- LAN user: Internal user connected to XenApp or XenDesktop server directly, without configuring the routing rules on a NetScaler ADC.
[From Build 55.23] [#490147, 482900]
Hop Diagram Support
The HDX Insight reports now support hop diagrams, which provide complete details about the client, NetScaler ADC, and server in an active session.
To display the hop diagram, on the dashboard tab, navigate to HDX Insight > Users >, click on a user name and, in the Current Application Sessions table, click on the session diagram icon.
[From Build 55.23] [#443824]
You can now increase the storage space of NetScaler Insight Center to 512 GB.
[From Build 55.23] [#425761, 553254]
Multi-Hop support for NetScaler Insight Center enables Insight Center to detect which Citrix appliances a connection passes through (CloudBridge, NetScaler, NetScaler Gateway), and in which order, for improved reporting.
[From Build 55.23] [#383172]
The NetScaler Insight Center configuration utility now displays the progress of the upgrade process.
[From Build 55.23] [#519788, 522021]
Appliance Reboot Progress Status
NetScaler SDX Appliance now displays the reboot progress. This helps in keeping the user informed about the various stages of the appliance reboot.
[From Build 55.23] [#454093]
Management service now provides support for SNMP v3 traps in addition to the already existing support for SNMP v2 traps. SNMP v3 provides better administration and security capabilities through better encryption, authentication and data integrity mechanisms.
[From Build 55.23] [#431687]
You can now partially allocate licenses as required for your deployment. For example, if your license file contains ten licenses, but your current requirement is for only six licenses, you can allocate six licenses now, and allocate additional licenses later. You cannot allocate more than the total number of licenses present in your license file.
[From Build 55.23] [#519771]
Management service now provides support for XenServer 6.5.
[From Build 55.23] [#538641]
The Initiate Virtual-NMI generates a core dump of a VPX instance. Initiating a virtual NMI is useful when your NetScaler instance has stopped responding. To generate a virtual NMI, click on Configuration > Diagnostics. Click Initiate NMI under Non-Maskable Interrupt.
[From Build 55.23] [#475027]
NetScaler SDX supports cluster with three tuple notation.
[From Build 55.23] [#470894]
Retrieve LDAP Server Attributes
When you configure an LDAP server and provide the IP address of the LDAP server, the management service automatically fetches the attributes like Server Logon Name Attribute, Search Filter, Group Attribute, Sub Attribute Name. This helps in reducing the error during filling these details for LDAP configuration.
[From Build 55.23] [#491661]
In the Management Service, the user interface for licensing the NetScaler SDX appliances is now identical to the user interface for licensing the NetScaler MPX and NetScaler VPX appliances.
[From Build 55.23] [#479628, 517234]
If you create channels on SDX and use these channels in VPXs and then take a backup of the appliance to restore either the complete appliance or selected instances, then channels are not restored and instances may fail.
[From Build 55.23] [#432899, 435206]
Syslog Viewer helps you in searching through the syslog messages based on various filters. You can narrow your search based on module like API, CLI, CONFIG, EVENT etc. You can further choose the type of message that you want to search through, like, ALERT, CRITICAL etc. Syslog Viewer also provides the option to search through regular expression or based on case sensitive text
[From Build 55.23] [#478512]
When you use the NetScaler provisioning wizard, the option to upload the XVA file has been added to the wizard. To use the XVA file to create a NetScaler instance, you need to first upload the XVA file.
[From Build 55.23] [#476695]
Support for SNMP MIB Configuration
NetScaler SDX appliance now supports SNMP MIB configuration. You can configure SNMP MIB from Management Service by navigating to Configuration > System > SNMP > Settings > Configure SNMP MIB
[From Build 55.23] [#523926]
Options to disable and enable TLSv1, TLSv1.1, and TLSv1.2 has been added in the Management Service. To enable or disable TLS, navigate to Configuration > System. In the System Settings group, click on Change SSL Settings link.
[From Build 55.23] [#540347]
You can use the Setup Wizard to complete all the first time configurations in a single flow. You can use the wizard to assign various management network IP addresses, configure system settings, change the default admin password, manage and update licenses.
You can also use this wizard to modify the network configuration details that you provided for the NetScaler SDX appliance during initial configuration.
To access the wizard, navigate to Configuration > System, under Setup Appliance, click Setup Wizard.
[From Build 55.23] [#498284]
Default time zone
The default timezone when management service creates NetScaler instances is the NTP timezone. When this default timezone is modified using the management service, then the update is synchronized across the NetScaler instances
[From Build 55.23] [#451866, 492929]
You can use the clean install feature to downgrade the software version of a NetScaler SDX appliance without losing the IP addresses or passwords. Clean install is different than factory reset in the manner that you can choose the SDX version to which you want to downgrade the appliance.
To perform a clean install, navigate to Configuration > System > System Administration. In the System Administration Group, click Appliance Reset and follow the prompts.
[From Build 62.10] [#519772]
Static Routes Support for Management Service
You can now specify an IP address as a static route when provisioning a NetScaler instance. The instance then uses this address, instead of the default route, to connect to the Management Service.
[From Build 64.34] [#498445]
Support to Encrypt Backup Files
The Management Service now provides an option to encrypt the backup files.
[From Build 64.34] [#576381]
Option to Disable nsrecover Login Account
Using the Management Service interface, you can now disable the nsrecover login account. To disable the nsrecover login account, navigate to "Configuration > System > Configure System Settings" and clear the "Enable nsrecover Login" check box.
[From Build 64.34] [#576375]
Ability to configure SSL Ciphers to Securely Access the Management Service
You can select SSL cipher suites from a list of SSL ciphers supported by SDX appliances, and bind any combination of the SSL ciphers to access the Management Service securely through HTTPS
[From Build 64.34] [#530232]
Redundant Interface Sets
A redundant interface set is a set of interfaces in which one interface is active and the others are on standby. If the active interface fails, one of the standby interfaces takes over and becomes active.
Following are the main benefits of using redundant interface sets:
- The back-up links between the NetScaler appliance and a peer device ensure connection reliability.
- Unlike link redundancy using LACP, no configuration is required on the peer device for a redundant interface set. To the peer device, a redundant interface set appears as individual interfaces, not as a set or collection.
- In a high availability (HA) configuration, redundant interface sets can minimize the number the HA failovers.
A redundant interface set is specified in LR/X notation, where X can range from 1 to 4. For example, LR/1.
[From Build 55.23] [#355237, 186503, 249551]
Logging HTTP Header Information
The NetScaler appliance can now log header information of HTTP requests related to an LSN configuration. The following header information of an HTTP request packet can be logged:
- URL that the HTTP request is destined to.
- HTTP Method specified in the HTTP request.
- HTTP version used in the HTTP request.
- IP address of the subscriber that sent the HTTP request.
An HTTP header log profile is a collection of HTTP header attributes (for example, URL and HTTP method) that can be enabled or disabled for logging. The HTTP header log profile is then bound to an LSN group. The NetScaler appliance then logs HTTP header attributes, which are enabled in the bound HTTP header log profile for logging, of any HTTP requests related to the LSN group.
An HTTP header log profile can be bound to multiple LSN groups but an LSN group can have only one HTTP header log profile.
[From Build 55.23] [#496835]
Layer 2 PBR Support for Forwarding Sessions
In earlier releases, Layer 2 information (for example, destination MAC address, source VLAN, and Interface ID) about packets related to forwarding sessions were ignored during a PBR lookup. In other words, any packet related to a forwarding session was not considered for matching against a PBR having Layer 2 parameters as its condition.
Now, layer 2 information about a packet related to a forwarding session is matched against layer 2 parameters in the configured PBRs.
This feature is useful in a scenario where packets related to a forwarding session must be processed by another device before being sent to their destination.
Following are the benefits of this support:
- Instead of defining new PBRs that are based on Layer 3 parameters, you can use existing PBRs based on Layer 2 parameters for sending the packets related to forwarding sessions to the desired next hop device.
- In a deployment that includes NetScaler appliances and optimization devices (for example, Citrix ByteMobile and Citrix CloudBridge appliances), PBRs based on Layer 2 parameters can be very handy compared to other, complex configuration for identifying the forwarding session related packets for PBR processing.
- Identifying forwarding session related Ingress packets for sending them to the optimization device.
- Identifying egress packets, which also matched a forwarding session rule, from the optimization device for sending the packets to the desired next hop device.
[From Build 55.23] [#484458]
MAC Address Wildcard Mask for Extended ACLs
A new wildcard mask parameter for extended ACLs and ACL6s can be used with the source MAC address parameter to define a range of MAC addresses to match against the source MAC address of incoming packets.
MAC Address Wildcard Mask for PBRs
A new wildcard mask parameter for PBRs and PBR6s can be used with the source MAC address parameter to define a range of MAC addresses to match against the source MAC address of outgoing packets.
[From Build 55.23] [#391630]
Client Source Port for Server Side Connections?related to INAT and RNAT Rules
The NetScaler appliance, for INAT and RNAT rules, now supports using client port as the source port for server side connections. A parameter Use Proxy Port has been added to the INAT and RNAT command set. When?Use Proxy Port is disabled?for an INAT rule or a RNAT rule, the NetScaler appliance retains the source port of the client's request?for the server side connection. When the option is enabled (default), the NetScaler appliance uses a random port as the source port for the server side connection.??
You must disable this?parameter?for proper functioning of certain protocols that require?a specific?source port in the request packet.
[From Build 55.23] [#399821]
Blocking Traffic on Internal Ports
The NetScaler appliance does not block traffic that matches an ACL rule if the traffic is destined to the appliance's NSIP address, or one of its SNIP addresses, and a port in the 3008-3011 range.
This behavior is now specified by the default setting of the new Implicit ACL Allow (implicitACLAllow) parameter (of the L3 param command). You can disable this parameter if you want to block traffic to ports in the 3008-3011 range. An appliance in a high availability configuration makes an exception for its partner (primary or secondary) node. It does not block traffic from that node.
To disable or enable this parameter by using the command line interface
At the command prompt, type:
> set l3param -implicitACLAllow [ENABLED|DISABLED]
Note: The parameter implicitACLAllow is enabled by default.
> set l3param -implicitACLAllow DISABLED
[From Build 55.23] [#529317]
GRE Payload Options in a GRE IP Tunnel
For a configured GRE IP tunnel, the NetScaler appliance encapsulates the entire Layer 2 packet, including the Ethernet header and the VLAN header (dot1q VLAN tag). IP GRE tunnels between NetScaler appliances and some 3rd party devices might not be stable, because these 3rd party devices are not programmed to process some or the Layer 2 packet headers.
To configure a stable IP GRE tunnel between a NetScaler appliance and a 3rd party device, you can use a new parameter with the GRE IP tunnel command set. You can set the GRE payload parameter to do one of the following before the packet is sent through the GRE tunnel:
- Carry the Ethernet header but drop the VLAN header
- Drop the Ethernet header as well as the VLAN header
- Carry the Ethernet header as well the VLAN header
[From Build 55.23] [#518397]
Changing the Priority of a VIP Address Automatically in an Active-Active Deployment
To ensure that a backup VIP address takes over as the master VIP before the node of the current master VIP address goes down completely, you can configure a node to change the priority of a VIP address on the basis of the states of the interfaces on that node. For example, the node reduces the priority of a VIP address when the state of an interface changes to DOWN, and increases the priority when the state of the interface changes to UP. This feature is configured on each node. It applies to the specified VIP addresses on the node.
To configure this feature on a node, you set the Reduced Priority (trackifNumPriority) parameter, and then associate the interfaces whose state is to be tracked for changing the priority of the VIP address. When any associated interface's state changes to DOWN or UP, the node reduces or increases the priority of the VIP address by the configured Reduced Priority (trackifNumPriority) value.
[From Build 55.23] [#512848]
Configuring Communication Intervals for an Active-Active Deployment
In an active-active deployment, all NetScaler nodes use the Virtual Router Redundancy Protocol (VRRP) to advertise their master VIP addresses and the corresponding priorities in VRRP advertisement packets (hello messages) at regular intervals.
VRRP uses the following communication intervals:
* Hello Interval?Interval between successive VRRP hello messages that a node sends, for all of its active (master) VIP addresses, to the other nodes of the VRRP deployment. For a VIP address, nodes on which the VIP address is in the inactive state use the hello messages as verification that the master VIP address is still UP.
* Dead Interval?Time after which a node of a backup VIP address considers the state of the master VIP address to be DOWN if VRRP hello messages are not received from the node that has the master VIP address. After the dead interval, the backup VIP address takes over and becomes the master VIP address.
You can change these intervals to a desired value on each node. They apply to all VIP addresses on that node.
[From Build 55.23] [#512843]
For ensuring the integrity, data origin authentication, and data confidentiality of OSPFv3 packets, OSPFv3 authentication must be configured on OSPFv3 peers.
The NetScaler appliance supports OSPFv3 authentication and is partially compliant with RFC 4552. OSPFv3 authentication is based on the two IPSec protocols: Authentication Header (AH) and Encapsulating Security Payload (ESP). The NetScaler supports only the AH protocol for OSPFv3 authentication.
OSPFv3 authentication use manually defined IPSec Security Associations (SAs) between the OSPFv3 peers and does not rely on IKE protocol for forming dynamic SAs. Manual SAs define the security parameter Index (SPI) values, algorithms, and keys to be used between the peers. Manual SAs require no negotiation between the peers; therefore, same SA must be defined on both the peers.
You can configure OSPFv3 authentication on a VLAN or for an OSPFv3 area. When you configure for a VLAN, the settings are applied to all the interfaces that are member of the VLAN. When you configure OSPFv3 authentication for an OSPF area, the settings are applied to all the VLANs in that area. The settings are in turn applied to all the interfaces that are members of these VLANs. These settings do not apply to member VLANs on which you have configured OSPFv3 authentication directly.
[From Build 55.23] [#471703]
Jumbo Frames Support for NetScaler VPX Appliances
NetScaler VPX appliances now support receiving and transmitting jumbo frames containing up to 9216 bytes of IP data. Jumbo frames can transfer large files more efficiently than is possible with the standard IP MTU size of 1500 bytes.
A NetScaler appliance can use jumbo frames in the following deployment scenarios:
- Jumbo to Jumbo. The appliance receives data as jumbo frames and sends it as jumbo frames.
- Non-Jumbo to Jumbo. The appliance receives data as regular frames and sends it as jumbo frames.
- Jumbo to Non-Jumbo. The appliance receives data as jumbo frames and sends it as regular frames.
Jumbo Frames support is available on NetScaler VPX appliances running on the following virtualization platforms:
- VMware ESX (Note that NetScaler VPX appliances running on VMware ESX support receiving and transmitting jumbo frames containing up to only 9000 bytes of IP data.)
For configuring Jumbo Frames on a NetScaler VPX appliance, you must:
- Set the MTU of the interface or channel of the VPX appliance to a value in the range 1501-9216. Use the NetScaler command line interface or the configuration utility of the VPX appliance to set the MTU size.
- Set the same MTU size on the corresponding physical interfaces of the virtualization host by using its management applications.
[From Build 55.23] [#464830, 478103, 485905]
The NetScaler appliance supports sending static IPv6 routes through a VXLAN. You can enable the NetScaler appliance to send an IPv6 route through either a VXLAN or a VLAN. A VXLAN parameter is added to the static IPv6 route command set.
[From Build 55.23] [#472443]
Support of IPv6 Dynamic Routing Protocols on VXLANs
The NetScaler appliance supports IPv6 dynamic routing protocols for VXLANs. You can configure various IPv6 Dynamic Routing protocols (for example, OSPFv3, RIPng, BGP) on VXLANs from the VTYSH command line. An option IPv6 Dynamic Routing Protocol has been added to VXLAN command set for enabling or disabling IPv6 dynamic routing protocols on a VXLAN. After enabling IPv6 dynamic routing protocols on a VXLAN, processes related to the IPv6 dynamic routing protocols are required to be started on the VXLAN by using the VTYSH command line.
[From Build 55.23] [#472432]
Specifying a VLAN in a Static ARP Entry
In a static ARP entry, you can specify the VLAN through which the destination device is accessible. This feature is useful when the interface specified in the static ARP entry is part of multiple tagged VLANs and the destination is accessible through one of the VLANs. The NetScaler appliance includes the specified VLAN ID in the outgoing packets matching the static ARP entry. If you don't specify a VLAN ID in an ARP entry, and the specified interface is part of multiple tagged VLANs, the appliance assigns the interface's native VLAN to the ARP entry.
For example, say NetScaler interface 1/2 is part of native VLAN 2 and of tagged VLANs 3 and 4, and you add a static ARP entry for network device A, which is part of VLAN 3 and is accessible through interface 1/2. You must specify VLAN 3 in the ARP entry for network device A. The NetScaler appliance then includes tagged VLAN 3 in all the packets destined to network device A, and sends them from interface 1/2.
If you don't specify a VLAN ID, the NetScaler appliance assigns native VLAN 2 for the ARP entry. Packets destined to device A are dropped in the network path, because they do not specify tagged VLAN 3, which is the VLAN for device A.
[From Build 55.23] [#520355]
As-Override Support in Border Gateway Protocol
As a part of BGP loop prevention functionality, if a router receives a BGP packet containing the router's Autonomous System Number (ASN) in the Autonomous Systems (AS) path, the router drops the packet. The assumption is that the packet originated from the router and has reached the place from where it originated.
If an enterprise has several sites with a same ASN, BGP loop prevention causes the sites with an identical ASN to not get linked by another ASN. Routing updates (BGP packets) are dropped when another site receives them.
To solve this issue, BGP AS-Override functionality has been added to the ZebOS BGP routing module of the NetScaler.
With AS-Override enabled for a peer device, when the NetScaler appliance receives a BGP packet for forwarding to the peer, and the ASN of the packet matches that of the peer, the appliance replaces the ASN of the BGP packet with its own ASN number before forwarding the packet.
[From Build 55.23] [#503566]
Keeping a VIP address in the Backup State
By default, for configurations with USIP option disabled or with USIP and use proxy port options enabled, the NetScaler appliance communicates to the servers from a random source port (greater than 1024).
The NetScaler supports using a source port from a specified port range for communicating to the servers. One of the use case of this feature is for servers that are configured to identify received traffic belonging to a specific set on the basis of source port for logging and monitoring purposes. For example, identifying internal and external traffic for logging purpose.
For more information, see http://docs.citrix.com/en-us/netscaler/11/traffic-management/load-balancing/load-balancing-manage-clienttraffic/use-specified-sourceport.html.
[From Build 64.34] [#420067, 420039]
Keeping a VIP address in the Backup State
You can force a VIP address to always stay in backup state in a VRRP deployment. This operation is helpful in maintenance or testing of the deployment.
When a VIP address is forced to stay in backup state, it does not participate in VRRP state transitions. Also, it cannot become master even if all other nodes go down.
To force a VIP address to stay in backup state, you set the priority of the associated VMAC address to zero. To ensure that none of the VIP addresses of a node handle traffic during a maintenance process on the node, set all the priorities to zero.
For more information, see http://docs.citrix.com/en-us/netscaler/11/networking/interfaces/configuring-active-active-mode.html.
[From Build 64.34] [#553311]
By default, a backup VIP address preempts the master VIP address immediately after its priority becomes higher than that of the master VIP. When configuring a backup VIP address, you can specify an amount of time by which to delay the preemption. Preemption delay time is a per-node setting for each backup VIP address.
The preemption delay setting for a backup VIP does not apply in the following conditions:
* The node of the master VIP goes down. In this case, the backup VIP takes over as the master VIP after the dead interval set on the backup VIP's node.
* The priority of the master VIP is set to zero. The backup VIP takes over as the master VIP after the dead interval set on the backup VIP's node.
For more information, see http://docs.citrix.com/en-us/netscaler/11/networking/interfaces/configuring-active-active-mode.html.
[From Build 64.34] [#553246]
Support for JPEG-XR image format in Front End Optimization (FEO)
The front end optimization feature now supports the conversion of GIF, JPEG, TIFF, and PNG images to JPEG-XR format as part of the image optimization functionality.
[From Build 55.23] [#504044]
Support for WebP image format in Front End Optimization (FEO)
The front end optimization feature now supports the conversion of GIF, JPEG, and PNG images to WEBP format as part of the image optimization functionality.
[From Build 55.23] [#509338]
Media classification support on the NetScaler appliance
You can now monitor and display the statistics of the media traffic going through the NetScaler appliance.
[From Build 55.23] [#493103]
Support for New Hardware Platforms
The MPX 25100T and MPX 25160T platforms are now supported in this release. For more information about these platforms, see http://docs.citrix.com/en-us/netscaler/11/netscaler-hardware-installation/netscaler-hardware-platforms/mpx-25100t-25160t.html.
[From Build 55.23] [#486703, 495591, 552218]
Policy extensions support on NetScaler appliance
The NetScaler appliance now supports policy extensions, which you can use to add customized functions to default syntax policy expressions. An extension function can accept text, double, Boolean or number values as input, perform a computation, and produce a text, double, Boolean or number result.
[From Build 55.23] [#248822]
Transaction Scope Variables
Transaction scope variables are added to variables feature. You can now use transaction scope variables to specify separate instances with values for each transaction processed by the NetScaler appliance. Transaction variables are useful for passing information from one phase of the transaction to another. For example, you can use a transaction variable to pass information about the request onto the response processing.
[From Build 55.23] [#444109]
Support for Displaying the Hex Code of a CIpher
The show ciphersuite command now displays the IETF standard hexadecimal code of the cipher. It is helpful in debugging, because a hex code is unique to a cipher but the cipher name might differ on the NetScaler appliance, OpenSSL, and Wireshark.
At the NetScaler command line, type:
In the configuration utility, navigate to Traffic Management > SSL > Cipher Groups.
[From Build 55.23] [#491286]
Stricter Control on Client Certificate Validation
You can configure the SSL virtual server to accept only client certificates that are signed by a CA certificate bound to the virtual server. To do so, enable the ClientAuthUseBoundCAChain setting in the SSL profile bound to the virtual server.
For more information, see http://docs.citrix.com/en-us/netscaler/11/traffic-management/ssl/config-ssloffloading/ssl-profiles.html.
[From Build 55.23] [#533241]
Support for TLS Protocol Version 1.1 and 1.2 on the backend on the NetScaler MPX, MPX-FIPS, and SDX Appliances
The NetScaler MPX appliance now supports TLS protocol versions 1.1 and 1.2 on the backend. MPX-FIPS appliances running firmware version 2.2 also support TLSv1.1/1.2 on the backend. On an SDX appliance, TLSv1.1/1.2 is supported on the backend only if an SSL chip is assigned to the VPX instance.
[From Build 55.23] [#494082, 566364]
Changes to the Default Cipher Suite
If user-defined ciphers or cipher groups are not bound to an SSL virtual server, the DEFAULT cipher group is used for cipher selection at the front end and the ALL cipher group is used for cipher selection at the back end. In this release, the predefined cipher suites, such as DEFAULT and ALL, are modified to give strong ciphers a higher priority. For example, earlier RC4-MD5 was given a higher priority but it is deprioritized in the new list because it is a weak cipher.
[From Build 55.23] [#226713, 258311, 384491]
Support for TLS Protocol Version 1.1 and 1.2 on the front end on the NetScaler VPX and SDX Appliances
The NetScaler VPX appliance now supports TLS protocol versions 1.1 and 1.2 on the front end. On an SDX appliance, TLSv1.1/1.2 are supported on the front end even if an SSL chip is not assigned to the VPX instance.
[From Build 55.23] [#424463, 481970]
Support for Checking the Subject Alternative Name in addition to the Common Name in a Server Certificate
If you configure a common name on an SSL service or service group for server certificate authentication, the subject alternative name (SAN), if specified, is matched in addition to the common name. Therefore, if the common name does not match, the name that you specify is compared to the values in the SAN field in the certificate. If it matches one of those values, the handshake is successful. Note that in the SAN field, only DNS names are matched.
[From Build 55.23] [#439161]
2048-bit Default Certificates on the NetScaler Appliance
With this release, the default certificate on a NetScaler appliance is 2048-bits. In earlier builds, the default certificate was 512-bits or 1024-bits. After upgrading to release 11.0, you must delete all your old certificate-key pairs starting with "ns-", and then restart the appliance to automatically generate a 2048-bit default certificate.
[From Build 55.23, 64.34] [#451441, 405363, 458905, 465280, 540467, 551603, 559154, 547106, 584335, 588128]
Support for SNI with a SAN Extension Certificate
The NetScaler appliance now supports SNI with a SAN extension certificate. During handshake initiation, the host name provided by the client is first compared to the common name and then to the subject alternative name. If the name matches, the corresponding certificate is presented to the client.
[From Build 55.23] [#250573]
DH Key Performance Optimization
DH key generation is optimized on a VPX appliance by adding a new parameter dhKeyExpSizeLimit. You can set this parameter on an SSL virtual server or on an SSL profile and bind the profile to the SSL virtual server. The key generation is optimized as defined by NIST in http://csrc.nist.gov/publications/nistpubs/800-56A/SP800-56A_Revision1_Mar08-2007.pdf. Additionally, the minimum DH count is set to zero. As a result, you can now generate a DH key for each transaction as opposed to a minimum of 500 transactions earlier. This helps to achieve perfect forward secrecy (PFS).
[From Build 55.23] [#498162, 512637]
Support for TLS_FALLBACK_SCSV signaling cipher suite value
The NetScaler appliance now supports the TLS_FALLBACK_SCSV signaling cipher suite value. The presence of this SCSV extension in the Client Hello indicates that the client is retrying to connect to the server by using a lower SSL version, after its previous attempt to communicate with a higher version failed. Therefore, if the server finds this extension in Client Hello and also finds that the client is proposing a version that is lower than the maximum version supported by the server, it is a likely indication of a "man in the middle attack." The server drops these handshakes.
For more information, see http://docs.citrix.com/en-us/netscaler/11/traffic-management/ssl/customize-ssl-config/config-protocol-settings.html.
[From Build 55.23] [#509666, 573528]
Support for Additional Ciphers on a DTLS Virtual Server
EDH, DHE, ADH, EXP, and ECDHE ciphers are now supported on a DTLS virtual server.
[From Build 55.23] [#508440, 483391]
Support for Auto-Detection of the Certificate-Key Pair Format
The NetScaler software has been enhanced to automatically detect the format of the certificate-key pair. To do so, the format of the certificate and key file should be the same. If you specify the format in the inform parameter, it is ignored by the software. Supported formats are PEM, DER, and PFX.
[From Build 55.23] [#209047, 432330, 481660]
New SNMP OIDs for SSL transactions per second
The following SNMP OIDs have been added to the display the SSL transactions per second:
NS-ROOT-MIB::sslTotTransactionsRate.0 = Gauge32: 0
NS-ROOT-MIB::sslTotSSLv2TransactionsRate.0 = Gauge32: 0
NS-ROOT-MIB::sslTotSSLv3TransactionsRate.0 = Gauge32: 0
NS-ROOT-MIB::sslTotTLSv1TransactionsRate.0 = Gauge32: 0
[From Build 55.23] [#449923]
Support for ECDHE Ciphers at the Back End
The NetScaler appliance now supports the following ECDHE ciphers at the back end:
Note: This feature is available only for NetScaler MPX platforms.
[From Build 55.23] [#523464]
Support for Thales nShield(R) HSM
All NetScaler MPX, SDX, and VPX appliances except the MPX 9700/10500/12500/15500 appliances now support the Thales nShield(R) Connect external Hardware Security Module (HSM). With a Thales HSM, the keys are securely stored as application key tokens on a remote file server and can be reconstituted only inside the Thales HSM. Thales HSMs comply with FIPS 140-2 Level 3 specifications.
Thales integration with the ADC is supported for TLS versions 1.0, 1.1, and 1.2.
For more information about support for Thales nShield(R) HSM, see http://docs.citrix.com/en-us/netscaler/11/traffic-management/ssl/support_for_thales.html.
[From Build 62.10] [#440351, 477544]
If you downgrade the software on your NetScaler appliance that does not have a license to release 9.3 build 61.66 or earlier, some commands related to the default server certificate might not be saved in the running configuration. As a result, after restarting, secure access (HTTPS) to the appliance fails.
[From Build 64.34] [#551603, 559154]
Using the SSL Chip Utilization Percentage Counter for Capacity Planning on MPX Appliances that use N3 Chips
Knowing the percentage utilization of all the SSL chips in an appliance over a period of time helps in capacity planning. The counter increments every 7 seconds and therefore provides real-time data, which can help you predict when an appliance is likely to reach capacity.
Note: This feature is available on only the MPX appliances that use N3 chips, which include MPX 11515/11520/11530/11540/11542 and MPX 220140/22060/22080/22100/22120/24100/24150 appliances.
Some models of MPX 14020/14030/14040/14060/14080/14100 and MPX 25100/25160/25200, which use N3 chips, also support this feature.
[From Build 64.34] [#416807, 197702]
New Counters in SSL Statistics
Because TLS 1.1 and 1.2 are becoming the primary security protocols, the transaction and session statistics for these protocols are now included in the SSL statistics.
[From Build 64.34] [#336395, 559165, 560353]
Graceful Cleanup of SSL sessions after change in any SSL entity parameter
Some operations - for example, updating a certificate to replace a potentially exposed certificate, using a stronger key (2048-bit instead of 1024-bit), adding/removing a certificate from a certificate chain, or changing any of the SSL parameters - should clean the SSL sessions gracefully instead of abruptly terminating existing sessions. With this enhancement, existing connections continue to use the current settings but all new connections use the new certificate or settings. However, connections that are in the middle of a handshake or sessions that are renegotiating are terminated, and session reuse is not allowed. To clear the sessions immediately after a configuration change, you must disable and reenable each entity.
[From Build 64.34] [#529979]
Enhanced SSL Profile
The SSL infrastructure on the NetScaler appliance is continually updated to address the ever growing requirements for security and performance. Vulnerabilities in SSLv3 and RC4 implementation have emphasized the need to use the latest ciphers and protocols to negotiate the security settings for a network connection. Implementing any changes to the configuration, such as disabling SSLv3, across thousands of SSL end points is a cumbersome process. Therefore, settings that were part of the SSL end points configuration have been moved to the SSL profile, along with the default ciphers. To implement any change in the configuration, including cipher support, you need only modify the profile. If the profile is enabled, the change is immediately reflected in all the end points that the profile is bound to.
Important: After the upgrade, if you enable the profile, you cannot reverse the changes. That is, the profile cannot be disabled.
[From Build 64.34] [#533640]
During the execution of the "nstrace.sh" script (from shell) or the "start nstrace" command (from CLI), when the trace file is rolled over, some packets might not be available in the trace. The number of packets that will be dropped from the trace is directly proportional to the traffic rate.
[From Build 55.23] [#480258, 494482, 523853]
One Perl script to support both call home and regular uploads
The script used to upload collector archives to Citrix servers is now packaged as part of the official NetScaler build (collector_upload.pl). However, using this script directly is not recommended. Instead, use the -upload option in showtechsupport utility to upload the archives.
[From Build 55.23] [#525332]
Support for milliseconds, microseconds, and nanoseconds in Time Format Definition table
You can now configure NetScaler web logging clients to capture transaction times in milliseconds, microseconds, and nanoseconds for logging on the NetScaler appliance.
[From Build 55.23] [#505840, 505377]
Maintaining minimum number of reuse pool connections in HTTP Profiles
You can now specify the minimum number of reuse pool connections to be opened from the NetScaler appliance to a particular server. This setting helps in optimal memory utilization and reduces the number of idle connections to the server.
[From Build 55.23] [#397478]
User configurable congestion window for TCP profile
You can now set the maximum congestion window size for a TCP profile on the NetScaler appliance.
[From Build 55.23] [#248711]
Call home support for NetScaler VPX models
Call home support has been added to NetScaler VPX models 1000 and higher.
[From Build 55.23] [#311620]
The NetScaler Web Logging (NSWL) client logs a hyphen (-) instead of a user name when %u is specified in the log format.
[From Build 55.23] [#238440, 239481, 247372, 422873]
Showtechsupport utility enhancement
If your NetScaler appliance has Internet connectivity, you can now directly upload the newly generated collector archive to the Citrix technical support server from the appliance.
[From Build 55.23] [#480797]
Support for FACK on TCP profiles
The TCP profiles on a NetScaler appliance now support forward acknowledgement (FACK). FACK avoids TCP congestion by explicitly measuring the total number of data bytes outstanding in the network, and helping the sender (either a NetScaler ADC or a client) control the amount of data injected into the network during retransmission timeouts.
[From Build 55.23] [#439130]
NTP Version Update
In NetScaler release 11, the NTP version has been updated from 4.2.6p3 to 4.2.8p2.
If you upgrade your NetScaler appliance from any earlier release to release 11, the NTP configuration is automatically upgraded with additional security policies. For more information about configuring an NTP server, see http://docs.citrix.com/en-us/netscaler/11/system/basic-operations/configuring-clock-sychronization.html.
[From Build 55.23] [#440375, 440591]
The NetScaler appliance fails intermittently when trace is started in 'RX' mode.
[From Build 55.23] [#576067]
The NetScaler introduces a new role called sysadmin. A sysadmin is lower than a superuser is terms of access allowed on the appliance. A sysadmin user can perform all NetScaler operations with the following exceptions: no access to the NetScaler shell, cannot perform user configurations, cannot perform partition configurations, and some other configurations as stated in the sysadmin command policy.
[From Build 55.23] [#548516]
Support for HTTP/2 on the NetScaler Appliance
The NetScaler appliance supports HTTP/2 connections with clients supporting HTTP/2 protocol.
[From Build 55.23] [#490096, 505747]
The NetScaler appliance generates SNMP clear alarm traps for successful cases of haVersionMismatch, haNoHeartbeats, haBadSecState, haSyncFailure, and haPropFailure error events in an HA configuration.
[From Build 55.23] [#368832]
Specifying a domain name for a logging server
When configuring an auditlog action, you can specify the domain name of a syslog or nslog server instead of its IP address. Then, if the server's IP address changes, you do not have to change it on the NetScaler appliance.
[From Build 64.34] [#314438]
Support restore operation on the NetScaler Appliance by using a remotely stored backup
You can now use a remotely saved backup to restore a NetScaler appliance through the "add system backup <filename>", that adds the metadata to the remote backup package, so that the restore operation can successfully use the backup package.
[From Build 64.34] [#569974]
Support for Configuring a Proxy Server to Install Licenses
You no longer have to configure internet connectivity on the NetScaler appliance in order to use a hardware serial number or license activation code to allocate a NetScaler license. Instead, you can use a proxy server.
On the NetScaler GUI, navigate to Configuration > System > Licenses > Manage Licenses > Add a New License, select the Connect through Proxy Server check box, and specify the IP address and port of your proxy server.
[From Build 64.34] [#541474]
Support for MPTCP Version Negotiation
A client can now establish an MPTCP connection with NetScaler appliance even if the client's and the NetScaler appliance's MPTCP versions does not match. If the MPTCP version of the client is higher than the one supported on the appliance, the client falls back to a lower or equal version. If the appliance supports that version, the MPTCP session continues. Otherwise, the appliance falls back to a normal TCP session.
[From Build 64.34] [#529883]
The tech support bundle that is generated for a NetScaler MPX appliance that has a LOM port, generates a list of LOM sensors and stores this list in the support bundle in the "shell/ipmitool_sensor_list.out" file.
[From Build 64.34] [#596315]
Subscriber-Aware Service Chaining
Service chaining is determining the set of services through which the outbound traffic from a subscriber must pass before going to the Internet. Multiple services, such as antivirus services, parental control services, firewalls, and web filter, are running in a Telco network. Different subscribers have different plans and each plan has specific services associated with it. The decision to direct a subscriber's request to a service is based on the subscriber information. Instead of sending all the traffic to all the services, the NetScaler appliance intelligently routes all requests from a subscriber to a specific set of services on the basis of the policy defined for that subscriber. The appliance receives the subscriber information from the PCRF over a Gx interface.
For more information about subscriber-aware service chaining, see http://docs.citrix.com/en-us/netscaler/11/solutions/netscaler-support-for-telecom-service-providers/lsn-telco-subscriber-management.html.
[From Build 62.10] [#561747]
Support for RADIUS Accounting Message
The NetScaler appliance can now dynamically receive the subscriber information through a RADIUS accounting message. It receives the subscriber IP address and MSISDN and uses this information to retrieve the subscriber rules from the PCRF server.
For more information about RADIUS Accounting Message, see http://docs.citrix.com/en-us/netscaler/11/solutions/netscaler-support-for-telecom-service-providers/lsn-telco-subscriber-management.html.
[From Build 62.10] [#526981]
Support for Gx Interface
The NetScaler appliance can now dynamically receive the subscriber information over a Gx interface. The appliance communicates with the PCRF server over the Gx interface, receives the subscriber information, and uses this information to direct the flow of traffic. The PCRF server can send updates over this interface at any point during the subscriber session.
For more information about Gx interface, see http://docs.citrix.com/en-us/netscaler/11/solutions/netscaler-support-for-telecom-service-providers/lsn-telco-subscriber-management.html.
[From Build 62.10] [#402469]
Provide Internet Access to IPv4 Subscribers Through the IPv6 Core Network of a Telecom Service Provider (Dual-Stack Lite)
Because of the shortage of IPv4 addresses, and the advantages of IPv6 over IPv4, many ISPs have started transitioning to IPv6 infrastructure. But during this transitioning, ISPs must continue to support IPv4 along with IPv6 because most of the public Internet still uses only IPv4, and many subscribers do not support IPv6.
Dual-Stack Lite (DS-Lite) is an IPv6 transition solution for ISPs with IPv6 infrastructure to connect their IPv4 subscribers to the Internet. DS-Lite uses IPv6 tunneling to send a subscriber's IPv4 packet over a tunnel on the IPv6 access network to the ISP. The IPv6 packet is de capsulated to recover the subscriber's IPv4 packet and is then sent to the Internet after NAT address and port translation other LSN related processing. The response packets traverse through the same path to the subscriber.
The NetScaler appliance implements the AFTR component of a DS-Lite deployment and is compliant with RFC 6333.
For more information about the DS-Lite feature, see http://docs.citrix.com/en-us/netscaler/11/solutions/netscaler-support-for-telecom-service-providers/dual-stack-lite.html.
[From Build 62.10] [#407162]
Subscriber-Aware Traffic Steering
Traffic steering is directing subscriber traffic from one point to another based on subscriber information. When a subscriber connects to the network, the packet gateway associates an IP address with the subscriber and forwards the data packet to the NetScaler appliance. The appliance communicates with the PCRF server over the Gx interface to get the policy information. Based on the policy information, the appliance performs one of the following actions:
- Forwards the data packet to another set of services
- Drops the packet
- Performs LSN if configured on the appliance
For more information about subscriber-aware traffic steering, see http://docs.citrix.com/en-us/netscaler/11/solutions/netscaler-support-for-telecom-service-providers/lsn-telco-subscriber-management.html.
[From Build 62.10] [#402473]
Provide Internet Access to a Large Number of Private IPv4 Subscribers of a Telecom Service Provider (Large Scale NAT)
The Internet's phenomenal growth has resulted in a shortage of public IPv4 addresses. Large Scale NAT (LSN/CGNAT) provides a solution to this issue, maximizing the use of available public IPv4 addresses by sharing a few public IPv4 addresses among a large pool of Internet users. LSN translates private IPv4 addresses into public IPv4 addresses. It includes network address and port translation methods to aggregate many private IP addresses into fewer public IPv4 addresses. LSN is designed to handle NAT on a large scale.
The NetScaler supports LSN and is compliant with RFC 6888, 5382, 5508, and 4787. The NetScaler LSN feature is very useful for Internet Service Providers (ISPs) and carriers providing millions of translations to support a large number of users (subscribers) and at very high throughput. The LSN architecture of an ISP using Citrix products consists of subscribers (Internet users) in private address spaces accessing the Internet through a NetScaler appliance deployed in ISP's core network.
The following lists some of the LSN features supported on a NetScaler appliance:
* ALGs: Support of application Layer Gateway (ALG) for SIP, PPTP, RTSP, FTP, ICMP, and TFTP protocols.
* Deterministic/ Fixed NAT: Support for pre-allocation of block of ports to subscribers for minimizing logging.
* Mapping: Support of Endpoint-independent mapping (EIM), Address-dependent mapping ( ADM), and Address-Port dependent mapping.
* Filtering: Support of Endpoint-independent filtering (EIF), Address-dependent filtering, and Address-Port-dependent filtering.
* Quotas: Configurable limits on number of ports and sessions per subscriber.
* Static Mapping: Support of manually defining an LSN mapping.
* Hairpin Flow: Support for communication between subscribers or internal hosts using public IP addresses.
* LSN Clients: Support for specifying or identifying subscribers for LSN NAT by using IPv4 addresses and extended ACL rules.
* Logging: Support for logging LSN session for law enforcement. In addition, the following are also supported for logging:
** Reliable SYSLOG: Support of sending SYSLOG messages over TCP to external log servers for a more reliable transport mechanism.
** Load balancing of Log Servers. Support for load balancing of external log servers for preventing storage of redundant log messages.
** Minimal Logging: Deterministic LSN configurations or Dynamic LSN configurations with port block significantly reduces the LSN log volume.
For more information about the Large Scale NAT feature, see http://docs.citrix.com/en-us/netscaler/11/solutions/netscaler-support-for-telecom-service-providers/lsn-introduction.html.
[From Build 62.10] [#316909]
Provide Visibility into SLA Reports
An ISP often purchases international bandwidth from upstream ISPs, who then become layer 2 ISPs. To provide the redundancy required for reliable service to its customers, the purchasing ISP negotiates Service Level Agreements with multiple layer 2 ISPs. The SLAs stipulate a penalty in the event that the layer 2 ISP fails to maintain a specified level of service.
NetScaler Insight Center and the NetScaler cache redirection feature can now be used to monitor the traffic flowing through the NetScaler appliances and calculate SLA breaches. The NetScaler cache redirection feature helps save bandwidth over international links. NetScaler Insight Center works with the NetScaler cache redirection feature to calculate, and provide visibility into, the percentage of bandwidth saved and any breaches of the SLA. ISP administrators are alerted whenever there is a breach for response time, hit rate/sec, or bandwidth.
For a specific domain, NetScaler calculates the following SLA breaches and forwards the data to NetScaler Insight Center:
* SLA Breach. A breach that occurs when a metric (response time, hits, or bandwidth) crosses the defined threshold value. For example, SLA breach is considered if the response time for a specific domain crosses 100 ms.
* SLA Breach Duration. Time period in which a SLA breach lasted. For example, SLA Breach Duration is considered 5 mins, if the response time for a domain is greater than 100 ms consistently for 5 mins.
* Breached Request Percentage. Percentage of requests whose response time is not within the minimum response time and maximum response time range. For example, if you configure this value as 10%, then among 100 requests, the response time of 10 requests are not within the minimum response time and maximum response time.
NetScaler Insight Center then calculates the following SLA breaches:
* SLA Breach Frequency- SLA Breach Frequency is the defined as the number of times the SLA breach occurs for the SLA Breach Duration. For example, SLA Breach Frequency is considered 1, if the response time for a domain is greater than 100 ms consistently for 5 mins.
All of these metrics are calculated for a SLA group, which contains a list of domains defined by the ISP administrator.
[From Build 62.10] [#495288, 501269, 501277, 501278, 501279, 501280]
High Availability Support for Dynamic Subscriber Sessions
In the absence of a high availability (HA) setup, the subscriber information that is received from the RADIUS client is lost if the appliance fails. With HA support, the subscriber sessions are continually synchronized on the secondary node. In the event of a failover, the subscriber information is still available on the secondary node.
[From Build 63.16] [#574838]
Subscriber Session Event Logging
The NetScaler appliance currently maintains millions of subscriber sessions in its database (subscriber store) but does not log these messages. Telco administrators need reliable log messages to track the control plane messages specific to a subscriber. They also need historical data to analyze subscriber activities. The appliance now supports logging of RADIUS control plane accounting messages and Gx control plane logging messages. Some of the key attributes are MSISDN and time stamp. By using these logs, you can track a user by using the IP address, and the MSISDN if available.
[From Build 64.34] [#575621, 575623]
IPv6 Prefix based Subscriber Sessions
A telco user can be uniquely identified by the IPv6 prefix rather than the complete IPv6 address. The NetScaler appliance now uses the prefix instead of the complete IPv6 address (/128) to identify a subscriber in the database (subscriber store). For communicating with the PCRF server (for example, in a CCR-I message), the appliance now uses the framed-IPv6-Prefix AVP instead of the complete IPv6 address. The default prefix length is /64, but you can configure the appliance to use a different value.
[From Build 64.34] [#574135]
Logging MSISDN Information for a Large Scale NAT configuration
A Mobile Station Integrated Subscriber Directory Number (MSISDN) is a telephone number uniquely identifying a subscriber across multiple mobile networks. The MSISDN is associated with a country code and a national destination code identifying the subscriber's operator.
You can configure a NetScaler appliance to include MSISDNs in LSN log entries for subscribers in mobile networks. The presence of MSISDNs in the LSN logs helps the administrator in faster and accurate back tracing of a mobile subscriber who has violated a policy or law, or whose information is required by lawful interception agencies.
For more information, see http://docs.citrix.com/en-us/netscaler/11/solutions/netscaler-support-for-telecom-service-providers/lsn-introduction/lsn-monitoring.html.
[From Build 64.34] [#581315, 502083]
Deterministic NAT Allocation for DS-Lite
Deterministic NAT allocation for DS-Lite LSN deployments is a type of NAT resource allocation in which the NetScaler appliance pre-allocates, from the LSN NAT IP pool and on the basis of the specified port block size, an LSN NAT IP address and a block of ports to each subscriber (subscriber behind B4 device).
The appliance sequentially allocates NAT resources to these subscribers. It assigns the first block of ports on the beginning NAT IP address to the beginning subscriber IP address. The next range of ports is assigned to the next subscriber, and so on, until the NAT address does not have enough ports for the next subscriber. At that point, the first port block on the next NAT address is assigned to the subscriber, and so on.
The NetScaler appliance logs the allocated NAT IP address and the port block for a subscriber. For a connection, a subscriber can be identified by just its mapped NAT IP address and port block. For this reason, the NetScaler appliance does not log the creation or deletion of an LSN session.
For more information, see http://docs.citrix.com/en-us/netscaler/11/solutions/netscaler-support-for-telecom-service-providers/dual-stack-lite.html.
[From Build 64.34] [#582325]
Port Block Size in a Large Scale NAT Configuration
Deterministic NAT and Dynamic NAT with port block allocation significantly reduce the LSN log volume. For these two types of configuration, the NetScaler appliance allocates a NAT IP address and a block of ports to a subscriber.
The minimum port block size for deterministic LSN configuration and dynamic LSN configuration with port block has been reduced from 512 ports to 256. This reduction of the minimum port block doubles the maximum number of subscribers for a NAT IP address in an LSN configuration. It also reduces the number of unused ports assigned to subscribers who do not need more than 256 ports at a time.
The port block size parameter can be set while adding or modifying an LSN group as part of an LSN configuration. A value of 256 (default) or a multiple of 256 can be set to the port block size parameter.
For instructions on configuring Large Scale NAT, see http://docs.citrix.com/en-us/netscaler/11/solutions/netscaler-support-for-telecom-service-providers/lsn-introduction/configuration-steps-lsn.html.
For sample LSN configurations, see http://docs.citrix.com/en-us/netscaler/11/solutions/netscaler-support-for-telecom-service-providers/lsn-introduction/lsn-sample-configurations.html.
[From Build 64.34] [#581285]
Configuring DS-Lite Static LSN Maps
The NetScaler appliance supports manual creation of DS-Lite LSN mappings, which contain the mapping between the following information:
* Subscriber's IP address and port, and IPv6 address of B4 device or component
* NAT IP address and port
Static DS-Lite LSN mappings are useful in cases where you want to ensure that the connections initiated to a NAT IP address and port map to the subscriber IP address and port through the specified B4 device (for example, web servers located in the internal network).
For more information, see http://docs.citrix.com/en-us/netscaler/11/solutions/netscaler-support-for-telecom-service-providers/dual-stack-lite.html.
[From Build 64.34] [#558406]
IP Prefix NAT
The NetScaler appliance supports translating a part of the source IP address instead of the complete address of packets received on the appliance. IP prefix NAT includes changing one or more octets or bits of the source IP address.
The NetScaler appliance supports IP prefix NAT for traffic related to virtual servers and services for which the NetScaler does not maintain any session information. For example, virtual servers and services of type ANY, UDP, and DNS.
IP prefix NAT is useful in a deployment of NetScaler appliances and optimization devices (for example, Citrix ByteMobile) for identifying traffic from different client networks, which share the same network address, for meeting different optimization needs for traffic from each client network.
For more information, see http://docs.citrix.com/en-us/netscaler/11/networking/ip-addressing/configuring-network-address-translation/Partial-Nat.html
[From Build 64.34] [#590571]
Idle Session Management of Subscriber Sessions in a Telco Network
Subscriber-session cleanup on the NetScaler appliance is based on control plane events, such as a RADIUS Accounting Stop message, a Diameter RAR (session release) message, or a "clear subscriber session" command. In some deployments, the messages from a RADIUS client or a PCRF server might not reach the appliance. Additionally, during heavy traffic, the messages might be lost. A subscriber session that is idle for a long time continues to consume memory and IP resources on the appliance. The idle session management feature provides configurable timers to identify idle sessions, and cleans up these sessions on the basis of the specified action.
[From Build 64.34] [#574138]