Admin partitions now provide role based authentication for system groups. With this access control mechanism, a NetScaler appliance supports the following actions:

1. Bind an existing partition or all partitions to a system group.

2. Authenticate a user (bound to a system group), using local or external authentication, and allow the user to switch to a partition that is bound to the system group.

3. Bind the system group to a custom command policy.

In a partitioned NetScaler appliance, you can now bind a system group to a specific administrative partition by using the bind system group <grpname>-partitioname <partitioname> command.

As the root administrator of a partitioned NetScaler appliance, you can now designate partition administrators to control user access to entities within specific partitions. A partition administrator can provide granular, role-based access for a partition user and specify a set of permissions and allowed operations. The authorization is specific to the partition. The partition administrator and the users authorized by the partition administrator access the partition through a SNIP address.

A group user associated with a superuser command policy is unable to switch partitions through the NetScaler GUI.

On a partitioned NetScaler appliance in a high availability configuration, the top pane of the NetScaler GUI displays the high availability status of the partitions. This instant visibility helps you monitor the HA configuration efficiently.

You can configure a stream selector and a responder policy to collect statistics at the packet level and identify defective or attack-prone packets flowing through all the connections identified by the selector. If, at any point, the percentage of defective or attack-prone packets exceeds the configured threshold, the policy applies a corrective action (RESET or DROP).

You can now avoid closing a node's connections when you add the node to or remove it from a cluster. Before adding or removing a node, log on to the cluster IP (CLIP) address and set the "retain connections on cluster" option. Then log on to the node's NSIP address and specify a timeout interval for graceful shutdown.

LLDP is a layer 2 protocol that enables a NetScaler appliance to advertise its identity and capabilities to the directly connected (neighbor) devices, and to learn the identity and capabilities of these neighbor devices. In a cluster setup, the NetScaler GUI and NetScaler CLI now display the LLDP neighbour configuration of all or specific cluster nodes when the GUI or CLI is accessed through the Cluster IP address (CLIP). Any change made to the global level LLDP mode is applied to the global level LLDP mode on each of the cluster nodes.

For more information, see https://docs.citrix.com/en-us/netscaler/11-1/networking/interfaces/configuring-link-layer-discovery-protocol.html.

You can now use a wizard to configure the GSLB deployment types (active-active and active-passive) and parent-child topologies. In the NetScaler GUI, navigate to Configuration > Traffic Management > GSLB, and click Get Started.

You can also start the GSLB configuration wizard from the dashboard. The dashboard provides the overall status of the GSLB sites participating in GSLB. You can also synchronize the sites and test the GSLB setup from the dashboard. To access the GSLB dashboard, navigate to Configuration > Traffic Management > GSLB > Dashboard.

When you create or change the GSLB configuration on a master site, you can use the new AutomaticConfigSync option to automatically synchronize the slave sites.

When AutomaticConfigSync option is enabled, you do not have to manually trigger the AutoSync option.

For more information, see http://docs.citrix.com/en-us/netscaler/11-1/gslb/configure-gslb/sync-configuration-gslb-setup.html.

The backup parent site topology is useful in scenarios wherein a large number of child sites are associated with a parent site. If this parent site goes DOWN, all of its child sites become unavailable. To prevent this, you can now configure a backup parent site to which the child sites can connect if the original parent site is DOWN.

For more information, see http://docs.citrix.com/en-us/netscaler/11-1/gslb/gslb-deployment-types/parent-child-topology-deployment.html.

In a GSLB high availability setup, if the status of a Metrics Exchange Protocol (MEP) connection to a remote site changes to DOWN, you can set a delay to allow some time for reestablishment of the MEP connection before the site is marked as DOWN. If the MEP connection is back UP before the delay expires, the services are not affected.

For more information, see http://docs.citrix.com/en-us/netscaler/11-1/gslb/configure-metrics-exchange-protocol.html.

The default root credentials for a NetScaler appliance is "nsroot". However, for security reasons, you might enforce a password change to ensure the credentials are changed to a new value other than the default value. To implement this, a new parameter, "forcePasswordChange" is introduced.

If you, as a root administrator log on with default credentials and set forcePasswordChange to ENABLED, on your next subsequent logon attempt, you will be prompted to change the password, and will not be allowed to log on without doing so. After the password is changed, the prompt no longer appears.

Note: You are prompted to change the current password to a new one only if the ForcePasswordChange parameter is enabled. Otherwise, you can access the appliance with the default login credentials (user name: NSROOT, password: NSROOT).

You now need to accept an End User License Agreement (EULA) to install and use the NetScaler CPX Express.

The End User Licensing Agreement is available at: https://www.microloadbalancer.com/eula.

For more information, see http://docs.citrix.com/en-us/netscaler-cpx/11-1.html.

After you successfully enable FIPS mode on a NetScaler 14000 FIPS appliance, existing configurations that use SNMP versions 1, version 2, and the "noPrivacy" security levels of SNMP version 3, are removed from the appliance and you are not allowed to reconfigure them. This is required for FIPS-140-2 level compliance.

You can now use advanced (PI) expressions for external authentication. PE expressions are also supported.

New StoreFront features are incorporated in the Unified Gateway Wizard.

NetScaler Gateway now supports Microsoft InTune.

The SAML attribute limit has been increased from 256 bytes to 10 KB.

The DNS resolution through NetScaler Gateway or the NetScaler G ateway Plug-in if IPv6 is enabled on the client's adapter and the ISP provides the IPv6 DNS address on the IPv6 stack.

A new VPN license counter for SNMP monitors license issues, and you can add or remove licenses as needed.

The XenApp & XenDesktop Wizard now supports exporting multiple Gateway deployments to supported StoreFront servers. In previous versions, only the first Gateway deployment was exportable. Now up to 32 deployments can be exported. All exported Gateway deployments are included in a single GatewayConfig.zip file.

The NetScaler Gateway appliance now supports the HDX Enlightened Data Transport (EDT) as a data transmission path. EDT provides a high definition in-session user experience of virtual desktops for users running a Citrix Receiver.

You can only enable or disable the X-Forwarded-For feature using the NetScaler appliance's CLI. To enable this feature, at the command prompt, type: "set appflow param httpXForwardedFor ENABLED".

This release includes the support for new NetScaler SDX platform, SDX-25000A.

NetScaler SDX Appliances now support SNMP MIB-2 table interfaces, using which you can get the details of all the interfaces and channels on the NetScaler SDX Appliance.

When configuring SNMP in the Management Service, you can now define the alarm threshold and timeout values.

A NetScaler appliance now uses a 2048-bit default certificate.

Note: Before installing a 2048-bit certificate, you must delete the 1024-bit default certificate and its keys, and then restart the Management Service.

On a NetScaler SDX Appliance, the existing default certificate and keys are at the following locations:

* Default certificate: /var/mps/ssl_certs/

* Default key: /var/mps/ssl_keys

Providing the NetScaler VPX admin account details is now optional when you use the Management Service to provision a NetScaler VPX instance on a NetScaler SDX appliance.

In the Management Service, you can now add up to two additional DNS servers to the network configuration. The additional DNS servers can have either IPv4 or IPv6 addresses.

Note: Make sure that you:

* Add a DNS server IP address or two DNS server IP address as additional DNS server.

* Do not use the same DNS server IP address for the primary DNS server and additional DNS servers.

For more information, see http://docs.citrix.com/en-us/sdx/11-1/hardware-installation/sdx-initial-configuration.html.

Using the Management Service, you can now do a clean install of any NetScaler SDX appliance, regardless of the platform.

Note: Before initiating the clean install, make sure that the factory partition on the appliance has enough space for the extracted single-bundle image.

For more information, see http://docs.citrix.com/en-us/sdx/11-1/configuring-management-service/performing-a-factory-reset.html.

Jumbo frames are now supported on NetScaler virtual appliances running on Amazon Web Services (AWS).

You can send larger data payload through each frame, which makes data transmission more efficient. To enable Jumbo Frames, use NetScaler CLI, GUI, or NITRO API.

You can now configure a NetScaler VPX instance deployed on VMware ESX Server to use PCI passthrough interfaces.

For performance information about PCI passthrough interfaces on ESX Server, see the latest VPX datasheet.

In a cluster setup, for a requirement to advertise spotted SNIP addresses to only the server-side routers, enabling DRADV mode or redistribute connect ZebOS operations cannot be used. This is because these operations send all the connected routes to ZebOS. Also, adding dummy static routes in ZebOS for the required subnets, or adding ACLs in ZebOS to filter unwanted connected routes is a cumbersome and tedious task.

A new option, Network Route, addresses this issue. You can enable this option for only one SNIP address per subnet. The connected route for that SNIP address is sent as a kernel route to ZebOS.

For VIP and SNIP addresses, another new option, Tag, can be assigned an integer from 1 to 4294967295. This parameter can be set only when Host Route or Network Route is enabled for VIP or SNIP addresses. The tag value associated with VIP and SNIP addresses are also sent along with their routes to ZebOS. Tags with different values can be set for VIP and SNIP routes. These tag values can then be matched in routemaps in ZebOS and advertised to selective areas.

For more information, see https://docs.citrix.com/en-us/netscaler/11-1/networking/ip-routing/configuring-dynamic-routes/advertisement-of-snip-and-vip-routes-to-selective-areas.html.

Connection failover helps prevent disruption of access to applications deployed in a distributed environment. In a High Availability (HA) setup, stateful connection failover for RNAT is now supported with TCP proxy.

Connection failover can be enabled per RNAT rule. For enabling connection failover on an RNAT rule, you enable the "connFailover" ("Connection Failover") parameter of that specific RNAT rule. To enable TCP proxy for RNAT, you must enable "tcpproxy" parameter by using the "set rnatparam" command in the NetScaler CLI or select "Enable RNAT Source IP Persistency" (System > Setting > Change Global System Settings) in the NetScaler GUI.

For more information, see https://docs.citrix.com/en-us/netscaler/11-1/networking/ip-addressing/configuring-network-address-translation/configuring-rnat.html.

For a MAC-mode based load balancing configuration, the NetScaler appliance maintains a source MAC table. This table maps the virtual server to the MAC addresses of all the bound services. The appliance uses this table to prevent (loop prevention mechanism) the server traffic from reaching the virtual server.

For a trunk link that is shared by the VLANs of the servers and the VLANs of clients, the appliance also prevents traffic from these clients from reaching the virtual server. To solve this issue, the NetScaler loop prevention mechanism now considers the VLAN ID along with the MAC address, so that the client traffic in a trunk link reaches the virtual server.

A new NetScaler VPX platform, VPX-T, is introduced for Telco operators, to meet their core-network requirements. VPX-T platform licenses are available for different throughput requirements (for example, 100G and 40G). NetScaler Telco software licensing editions (Basic and Advanced) are applicable for VPX-T.

VPX-T is supported on the following virtualization platforms:

* Citrix XenServer

* VMware ESX

* Linux-KVM

For more information about the platform licenses available for VPX-T, recommended interfaces, performance details, and a list of features in different NetScaler Telco software licensing editions, see the VPX-T datasheet.

To avoid unnecessary congestion when each client requests the revocation status of a server certificate during an SSL handshake, the NetScaler appliance now supports OCSP stapling. That is, the appliance can now send the revocation status of a server certificate to a client, at the time of the SSL handshake, after validating the certificate status from an OCSP responder. The revocation status of a server certificate is "stapled" to the response the appliance sends to the client as part of the SSL handshake. To use the OCSP stapling feature, you must enable it on an SSL virtual server and add an OCSP responder on the appliance.

Note: NetScaler appliances support OCSP stapling as defined in RFC 6066.

Important: NetScaler support for OCSP stapling is limited to handshakes using TLS protocol version 1.0 or higher. This feature is not supported in a cluster setup.

For more information, see http://docs.citrix.com/en-us/netscaler/11-1/ssl/ssl-11-1-ocsp-stapling-solution.html.

An SSL handshake is a CPU-intensive operation. If session reuse is enabled, the server/client key exchange operation is skipped for existing clients. They are allowed to resume their sessions. This improves the response time and increases the number of SSL transactions per second that a server can support. However, the server must store details of each session state, which consumes memory and is difficult to share among multiple servers if requests are load balanced across servers.

NetScaler appliances now support the SessionTicket TLS extension. Use of this extension indicates that the session details are stored on the client instead of on the server. The client must indicate that it supports this mechanism by including the session ticket TLS extension in the client Hello message. For new clients, this extension is empty. The server sends a new session ticket in the NewSessionTicket handshake message. The session ticket is encrypted with a key known only to the server. If a server cannot issue a new ticket at this time, it completes a regular handshake.

To resume a session, the client must include the session ticket in the request. If, for any reason, the server does not honor the ticket, it attempts to initiate a full handshake with the client.

For more information, see http://docs.citrix.com/en-us/netscaler/11-1/ssl/customize-ssl-config/support-for-tls-session-ticket-extension.html.

The NetScaler MPX appliances with N3 chips now support the elliptical curve digital signature algorithm (ECDSA) cipher group end-to-end.

ECDSA cipher suites use elliptical curve cryptography (ECC). Because of its smaller size, it is particularly helpful in environments where processing power, storage space, bandwidth, and power consumption are constrained.

Note: if you add an ECDSA certificate-key pair, only the following curves are supported:

-prime256v1

-secp384r1

The following ciphers are supported with ECDSA:

-ECDHE-ECDSA-AES256-GCM-SHA384

-ECDHE-ECDSA-AES256-SHA384

-ECDHE-ECDSA-AES256-SHA

-ECDHE-ECDSA-AES128-GCM-SHA256

-ECDHE-ECDSA-AES128-SHA256

-ECDHE-ECDSA-AES128-SHA

-ECDHE-ECDSA-RC4-SHA

-ECDHE-ECDSA-DES-CBC3-SHA

For more information, see http://docs.citrix.com/en-us/netscaler/11-1/ssl/customize-ssl-config/ecdsa_cipher_suite_support_on_mpx_appliances_with_n3_chips.html.

The NetScaler SDX appliances with N3 chips now support the elliptical curve digital signature algorithm (ECDSA) cipher group end to end.

In ECDHE_ECDSA, the server's certificate must contain an ECDSA-capable public key. For client authentication, an ECDSA CA certificate must be bound to the virtual server.

To support ECDSA cipher suites on a NetScaler SDX appliance, an SSL core must be assigned to the VPX instance.

ECDSA cipher suites use elliptical curve cryptography (ECC). Because of its smaller size, ECC is particularly helpful in environments where processing power, storage space, bandwidth, and power consumption are constrained.

Note: if you add an ECDSA certificate-key pair, only the following curves are supported:

-prime256v1

-secp384r1

The following ciphers are supported with ECDSA:

-ECDHE-ECDSA-AES256-GCM-SHA384

-ECDHE-ECDSA-AES256-SHA384

-ECDHE-ECDSA-AES256-SHA

-ECDHE-ECDSA-AES128-GCM-SHA256

-ECDHE-ECDSA-AES128-SHA256

-ECDHE-ECDSA-AES128-SHA

-ECDHE-ECDSA-RC4-SHA

-ECDHE-ECDSA-DES-CBC3-SHA

For more information, see http://docs.citrix.com/en-us/netscaler/11-1/ssl/customize-ssl-config/ecdsa_cipher_suite_support_on_mpx_appliances_with_n3_chips.html.

This release supports the MPX 14000 FIPS platform, which is a high-end platform containing 63 crypto cores, available in the following models:

Model number System Throughput

MPX 14030 FIPS 30 Gbps

MPX 14060 FIPS 60 Gbps

MPX 14080 FIPS 80 Gbps

For more information, see http://docs.citrix.com/en-us/netscaler/11-1/ssl/configuring-mpx-14000-fips-appliance.html.

NetScaler appliances now support inserting the thumbprint (also called a fingerprint) of a certificate into the header of a request sent to a back-end server. If client authentication is enabled, the appliance computes the thumbprint of the certificate, and uses an SSL policy action to insert the thumbprint into the request. The server searches for the thumbprint, and grants secure access if there is a match.

For more information, see http://docs.citrix.com/en-us/netscaler/11-1/ssl/config-ssl-actions-policies/config-ssl-based-hdr-insertion.html.

You can now configure the DNS security options from the Add DNS Security Profile page in the NetScaler GUI. This page provides a user-friendly graphical user interface for configuring DNS security settings. The Cache Poisoning Protection option is always enabled. The other security options can be applied to all DNS endpoints or to specific DNS virtual server(s) in your deployment.

Two of the security options, Bypass the Cache and Provide root details in the DNS response, can be applied to all DNS endpoints. The following security options can be applied either to all DNS endpoints or to specific DNS virtual servers:

DNS DDoS protection

Manage exceptions - whitelist/blacklist servers

Prevent random subdomain attacks

Enforce DNS transactions over TCP

For more information, see http://docs.citrix.com/en-us/netscaler/11-1/security/dis-security-options.html.

The software licensing editions for NetScaler Telco platforms (NetScaler T1000 series and NetScaler VPX-T) have changed as follows:

Basic edition

* Features added: Content Filtering

* Features removed: None

Advanced edition

* Features added: AAA, Content Optimization, Appflow for ICA, RDP Proxy, RISE, and Internet On Hold (IOH)

* Features removed: None

By default, a NetScaler appliance ignores the non-standard and obsolete "Proxy-Connection" HTTP header. To change this behavior, use the nsamimgr command to set the proxyConnection parameter to 1. This setting prioritizes the Proxy-Connection header over the Connection header.

For example, nsapimgr -ys proxyconnection=1

A static large scale NAT64 mapping entry is usually a one-to-one mapping between a subscriber IPv6 address:port and a NAT IPv4 address:port. A one-to-one static large scale NAT64 mapping entry exposes only one port of the subscriber IP address to the Internet.

Some situations might require exposing all ports (64K - limited to the maximum number of ports of a NAT IPv4 address) of a subscriber IP address to the Internet (for example, a server hosted on an internal network and running a different service on each port). To make these internal services accessible through the Internet, you have to expose all the ports of the server to the Internet.

One way to meet this requirement is to add 64 thousand one-to-one static mapping entries, one mapping entry for each port. Creating that entries is very cumbersome and a big task. Also, this large number of configuration entries might lead to performance issues in the NetScaler appliance.

A simpler method is to use wildcard ports in a static mapping entry. You just need to create one static mapping entry with NAT-port and subscriber-port parameters set to the wildcard character (*), and the protocol parameter set to ALL, to expose all the ports of a subscriber IP address for all protocols to the Internet.

For a subscriber’s inbound or outbound connections matching a wildcard static mapping entry, the subscriber’s port does not change after the NAT operation. When a subscriber-initiated connection to the Internet matches a wildcard static mapping entry, the NetScaler appliance assigns a NAT port that has the same number as the subscriber port from which the connection is initiated. Similarly, an Internet host gets connected to a subscriber's port by connecting to the NAT port that has the same number as the subscriber's port.

The NetScaler appliance might restart if role-based access is enabled in admin partitions.

The NetScaler appliance fails if all of the following conditions are met:

- The appliance is used as a SAML service provider.

- Multiple load balancing and content switching virtual servers are configured for the same external identity provider (IdP) but with different FQDN.

- SAML login happens on a virtual server with an existing SAML session from the same IdP.

In a multifactor SAML IdP configuration, if a SAML request is resent from the service provider during authentication, the NetScaler appliance sends an assertion before authentication is complete.

If you configure "CLI Accounting" on the NetScaler appliance, the RADIUS server does not send accounting message with Session ID.

The Onhover pattern has been added to the default list of cross-site scripting (XSS) denied patterns that the Application Firewall looks for when scanning traffic.

On a NetScaler Application Firewall appliance in a high availability configuration, learning mode does not work after an upgrade to release 11.0 build 68.10.

Application Firewall uses master-slave communication for processing security checks and retrieves connection information through Protocol Control Block (PCB). In a high availability mode, the NetScaler appliance might fail, if factory reset occurs when PCB variables are cleared before freeing Application Firewall context data when accessing null pointer during processing.

A log message is not generated when the FormFieldConsistency protection is enabled on an Application Firewall profile and the generated hidden field "as_fid" is modified.

With this fix, the NetScaler Application Firewall now generates a log message when the "FormFieldConsistency" protection is enabled and the hidden field "as_fid" is modified in the NetScaler Application Firewall profile.

On a NetScaler Application Firewall appliance in a high availability configuration, learning mode does not work after an upgrade to release 11.0 build 68.10.

A NetScaler appliance might fail when Application Firewall processes a request for SQL injection inspection, if the request has the SQLInjectiontype field set to "SQL Special Char or Keyword" and SQL comment handling is set to "ANSI/Nested".

Executing force sync operation using the nssync -s command from the shell triggers NetScaler appliance reboot and crash. The nsnetsvc crash occurs when the import filename length exceeds MAX_FILE_PATH_LEN.

In a high availability setup, after successful deployment of the Application Firewall learned StartURL rule from the GUI, the rule remains in the learned database and is not removed. Deploying the same startURL rule results in the following error message: "The StartURL check is already in use."

CPU utilization becomes high if you upgrade the NetScaler appliance to release 11.0 build 65 and enable Application Firewall Starturl Closure protection.

NetScaler release 11.0 build 47 or later logs error messages when you enable the Application Firewall feature on a NetScaler appliance in high availability mode.

If the NetScaler Application Firewall learning feature is enabled, Form Field Consistency violations result in blocking URL requests that end with a question mark (?), with no query parameters.

A NetScaler VPX instance becomes unresponsive if a range request is greater than the cached response size. This issue happens if you enable the media classification mode on a NetScaler appliance. While parsing range header and creating range records table, the value for parameter object size is set incorrectly. So when a range request is received, the incorrect value of the stored response causes failure.

The DataStream feature does not work if you use a MySQL database at the back end.

The MEP connection for site metrics goes DOWN if the dynamic RTT and GSLB server persistence features are unused for more than 249 days. In some cases, however, the MEP connection for site metrics remains UP, but the MEP connection for network metrics goes DOWN.

In a GSLB high availability setup, if a node stays in secondary state for more than 249 days, the service state might not be updated on this node after it becomes the primary node.

A NetScaler appliance fails if a Page Tracking session is enabled on the appliance by Appflow or AppQoE modules for partial content responses. This happens only for partial content responses served from Integrated Cache.

The NetScaler appliance dumps core and restarts if all of the following conditions are met:

- You are using Citrix Receiver or a web browser to access the NetScaler Gateway appliance.

- An optimal XenApp/XenDesktop is launched by using determine_services in the policy expression.

- Static proximity is used to create a preferred list of Desktop Delivery Controllers and this information is forwarded to the StoreFront.

- Your connection is terminated or disconnected while the determine_services policy is being evaluated.

If a GSLB service goes DOWN and then returns to the UP state, the configured hash-based load balancing methods might produce incorrect load balancing decisions, because the cache maintained for hash-based load balancing algorithms is not cleared when the GSLB service state is updated through MEP.

If you use "clear ns configuration" command to clear the NetScaler configuration and reset it to factory default, the command policies are restored to the default values.

You cannot unbind a transform policy from a virtual server by using the GUI.

When a partition admin tries to perform the Download, Create, or Create Directory operation on the "Manage Certificate" screen, an "operation not permitted" error appears. The expected behavior is that the buttons must be disabled.

If the features "Force password change for nsroot user when default nsroot password is being used" and "strong password" are enabled, any password is accepted when you change the nsroot password.

If the name of a load balancing virtual server contains a space, the virtual server is not listed by the reporting tool. (Reporting > Counters > System entities statistics > Entities)

If AD/LDAP authentication is configured to communicate on SSL channel in authentication actions, under heavy login load, Gateway portal results in blank pages.

If Client Certificate authentication and Pre-Auth End Point Analysis are both configured, redundant End Point Analysis occurs before the logon page is displayed. This behavior is due to the EPA Session Reset with Cert Two Factor Authentication set to On.

If a VPN virtual server to which a custom RfWebUI portal theme is bound is accessed from a browser that has the language set to German, French, Spanish or Japanese, the log on page does not load.

The TURN service does not start if there are two or more VPN servers with the same IP address but different port numbers.

The NetScaler appliance occasionally dumps core memory during system initialization, because of a VPN module error.

The Connection Proxy" persistence does not work when accessing the NetScaler Gateway GSLB Service if the GSLB services are configured with publicIP different from the service IP.

In some AAA logout sessions, the appliance dumps core memory.

Not all intranet applications are loaded onto the client machine when a large number of intranet applications and CSEC encryption are configured.

Kerberos Authentication fails when Kerberos Traffic is sent through UDP.

A GSLB virtual server using the least connections method always resolves to the same site IP address.

The NetScaler Gateway appliance fails when a user attempts to log on, if the logon page uses the RfWebUI theme and the appliance has insufficient CCU Licenses.

Mac OSX users are unable to sign on to the OSX Receiver client and are denied access to their apps and desktops.

On the LDAP side, if the administrator sets the option to change the user password at the next logon, the X1 Theme is applied to the Password Change page. If the user clicks Submit without entering the password, the "You need to enter the password" prompt is shown in English, even on systems localized for a different language.

If negotiate authentication is the first authentication factor, non-pass-through authentication in the next factor is not supported.

If jumbo frames are enabled on loopback, processing of data sent by AAAd in the packetEngine can cause massive memory corruption. This happens because the TCP data in the jumbo frame exceeds the application maximum segment size (MSS).

The NetScaler appliance becomes unresponsive while processing heavy UDP traffic.

If the AAA subsystem is configured for NTLM authentication, and the backend server is used for NTLM authentication, the server sends a content-length response that spans multiple TCP packets in a Type2 message. The NetScaler appliance then fails to complete NTLM authentication.

A NetScaler appliance might periodically restart after an upgrade if the deployment uses STA servers and, during the upgrade, the administrator's browser is closed while the appliance is communicating with a STA server.

The RADIUS accounting feature does not send an accounting-session-id parameter, which is required (RFC 2866).

NetScaler Gateway is not able to generate URLs for SharePoint 2013 in CVPN format. As a result, SharePoint is inaccessible.

If an iPhone client uses Safari to access Netscaler Gateway, the NetScaler or NetScaler Gateway appliance might dump core memory.

When Session Reliability is disabled on Storefront and Session Reliability on HA Failover is enabled on a NetScaler high availability pair running on 11.1 build 49.16, the passive NetScaler instance might reboot when you launch an application or a virtual desktop.

You can avoid the issue by performing either of the following steps:

* Disable "Session Reliability on HA" feature on the NetScaler instance.

-or-

* Enable Session Reliability on Storefront. (Navigate to Citrix Storefront > NetScaler Gateway > Secure Ticket Authority > Enable Session Reliability.)

The NetScaler appliance fails because it attempts to process a large unexpected value for an Expander variable. This fix adds checks to prevent this condition.

When XenApp/XenDesktop users launch applications/desktops that have the Advanced Encryption policy enabled, memory allocation issues cause high-availability failovers.

The whitelist of Citrix Receiver versions used by HDX Insight now includes version 13.0.2.265571 of Citrix Receiver for Linux.

Upgrading the Management Service to NetScaler SDX release 11.1.50.x fails with the following error message and with error code 10008:

This platform sysid 450088 is not supported

If you configure a large number of channels or interfaces on a NetScaler SDX appliance, Management Service UI screens that display the system interface list or channels load slowly.

On the NetScaler SDX 25000A platform, you cannot create NetScaler VPX instances on the NetScaler SDX appliance after using the clean install option to reset the appliance to a NetScaler SDX 11.1.50.x. image.

A NetScaler VPX instance on a NetScaler SDX appliance might fail because of kernel memory corruption caused by a problem in the error handling path in the kernel. The issue occurs when a user-space process fails and dumps the core file at a time when the value for "sysctl.kern.corefile" points to a nonexistent directory.

You can stack trace this issue by searching for the following message in the /var/log/messages file:

Core dump of pid xxx (yyy) uid zzz could not be done at %s; switching core dump pattern to default: /var/core/%N-%P

Where xxx, yyy, and zzz are specific values.

The NICs of a 14xxx 40G or 25xxx 40G NetScaler SDX appliance are not shown under Configuration > System > Interfaces if, after a factory reset, you use the Platform Upgrade option in the Management Service to upgrade the appliance to NetScaler SDX release 10.5 or 11.1 with 5.04 firmware.

A NetScaler VPX instance might stop responding and dump core memory if you allocate a large disk size for log messages. The higher the rate of log messages, the more quickly the instance runs out of memory and fails.

In an ESX environment, a CLAG channel that includes a VMXNET3 interface might continue to send LACPDUs to its partner even when it is in DETACHED state.

If you add additional SR-IOV or PCI passthrough interfaces to an existing NetScaler virtual appliance configured with SR-IOV or PCI passthrough interfaces, the existing interface names might get corrupted.

Restarting a NetScaler appliance that has a VLAN bound to a traffic domain and is configured as a SYNC VLAN or NSVLAN might cause configuration loss of binding between the VLAN and the traffic domain.

For extended ACL rules that are associated with NAT configurations (for example, RNAT rules and Large Scale NAT configurations), the NetScaler GUI displays the TCP established parameter as enabled even though the parameter is disabled.

In a high availability setup, after a failover, the new primary node does not set the R bit and F bit in BGP open messages that are used to inform the upstream router that the node has restarted gracefully.

In a high availability (HA) setup, after an HA force failover operation, the NetScaler appliance removes (but not properly) static default route6s of all non-default traffic domains from its memory.

Though the "show route6 operation" does not display these route6s but adding them again fails with the following error message: "ERROR: Resource already exist". This is because these route6s were not completely removed from memory.

This issue also happens on a standalone NetScaler appliance when a traffic domain that has default route6s is removed.

In rare cases, a user-mode process failure can cause kernel failure, either at the same time or later. If the kernel fails, the NetScaler appliance dumps core memory. This failure can occur on nCore MPX, VPX, or SDX, appliances, although the most common occurrence is on a NetScaler VPX instance on a NetScaler SDX appliance.

The NetScaler appliance dumps core memory and restarts if all of the following conditions are met:

- SNI feature is enabled.

- Exact server certificate match is unsuccessful.

- The common name field is greater than 253 characters.

If a profile is bound to an SSL virtual server, the NITRO API displays incorrect SSL virtual server settings. The correct settings are displayed in the profile.

If you try to load large certificate files (> 256kB), the NetScaler appliance might dump core and restart, because of insufficient memory.

SSL processing is delayed if the server sends a DES cipher with TLS1.2 protocol in the server_hello message to the NetScaler appliance. Although this combination is deprecated, the appliance tries to process it. The operation fails at the SSL card and blocks the card for a few seconds, causing latency in processing any new requests on the same card.

A NetScaler appliance might dump core and restart repeatedly if the SSL3-EDH-RSA-DES-CBC3-SHA cipher is selected when heavy traffic has exhausted the appliance's memory.

If you upgrade to release 10.5, SSL client authentication fails if it uses a 4096-bit client certificate.

A NetScaler appliance constantly fails and dumps core memory, filling the Var directory with core files.

In an MPTCP connection, a NetScaler appliance sets the TCP PSH flag during retransmission of FastClose and DataFIN packets.

In a MPTCP connection, if a client negotiates a Maximum Segment Size (MSS) value of more than 1460 bytes, and the NetScaler appliance receives an ICMP protocol error message after fragmenting and sending a Data Security Standard (DSS) packet, the appliance fails. This happens because of incorrect handling of DSS packets with a segment sizes.

A NetScaler appliance might crash at a random location and dump a core file unrelated to the actual cause of the problem.

SHA256 digest algorithm is not supported on a NetScaler FIPS appliance configured for SAML authentication or as a SAML IDP. However, an appropriate error message does not appear in the browser.

If a user name containing special characters is prefilled in the login forms, the RfWeb user interface fails to render the form.

Workaround: Escape the angular brackets.

Example:

Username is prefilled in the login forms on the basis of the value of the InitialValue tag in the authentication schema file.

Change

<InitialValue>${http.req.user.name}</InitialValue>

To

<InitialValue><![CDATA[${http.req.user.name}]]></InitialValue>

In a non-default partition, if the network traffic exceeds the partition bandwidth limit, the FTP control connection fails but the data connection remains established.

In the Visualizer, if you use Mozilla Firefox or Internet Explorer, some buttons in the Visualizer might not work.

Workaround: Use a different web browser, such as Google Chrome.

In a cluster setup, after a reboot, tagged VLAN configuration is lost on the vlan 1 interface.

In a cluster setup, if you use an interface on one node to create an LACP channel on another node, the channel is created and runs smoothly, but the system reports a configuration error.

The NetScaler appliance is unable to reuse an existing probe connection if an HTTP wildcard load balancing virtual server is configured in MAC mode with use source IP (USIP) mode enabled and the Use Proxy Port option turned off. As a result, the connection fails and client the receives a TCP reset.

A NetScaler appliance returns error code 0 if the showtechsupport script fails while uploading the collector bundle to the Citrix server.

To identify the failure, search the script's response data for the following string pattern:

Upload of collector archive [] failed

In older versions of Internet Explorer version 7, the browser incompatibility message does not appear for NetScaler build 11.1. The logon page directly appears, and you can log on successfully.

Certificate bundles are not supported in cluster setups.

LDAP configuration failed if the virtual server name started with an underscore ("_").

When using the XenApp and XenDesktop wizard, the Retrieve Stores functionality intermittently fails on the first click.

Workaround: Click the option again.

In a cluster setup, the "show bindings" command does not display Negotiate type authentication policies.

If you use CVPN to edit the home page through CVPN, the embed code becomes corrupt.

RADIUS group extraction fails, although authentication is successful.

In a FIPS deployment with SAML authentication, if the same NetScaler appliance is used for both SAML signing and SAML signature verification, the signature verification fails.

An external group user bound to a number of large groups, those over 1000 on an external LDAP server, is unable to execute any command. in addition, the user will get receive an authorization error for commands the user is authorized to use.

If a user is on the intranet and the location based VPN is set to REMOTE, and the VPN plug-in is terminated or the PC is rebooted, the NetScaler Gateway plug-in displays an authentication prompt.

If a VPN session profile and RfWebUI portal theme are in use, end users cannot log on if the following are set to OFF:

- ICA Proxy

- Clientless VPN Mode

- Transparent Interception and Client Choices

If the Home Page Text labels are lengthy when you customize an RfWebUI based theme, the home-page user interface does not function properly. The following lengthy text labels can cause this problem:

Apps Tab Label

Desktop Tab Label

Favorite Tab Label

If nfactor policies are bound to the AAA virtual server, the logon page of the virtual server is not displayed correctly by an Internet Explorer browser on a Windows mobile device.

Setting the monitor interval for entities configured as NextHOPServers is not supported.

Under the following set of conditions, the wrong error message appears:

A VPN traffic action is configured with SSO OFF.

A samlSSOProfile is configured.

The user tries to set this samlSSOProfile to the VPN traffic action.

After the preauthentication EPA scan completes, the cursor does not return to the index page.

If a Windows user name has non-ASCII characters, the user is unable to collect logfiles by using the Collect Log button.

If the Label node in a LoginSchema configured for an nFactor setup contains text that includes CDATA tags and an ampersand (&) character, text presented to a user is not displayed correctly. No other special characters cause a problem

If installing NetScaler VPX 11.1 for the first time, the /nsconfig/loginschema directory is empty. There are no .xml files present. If the NetScaler appliance is upgraded from any previous version to 11.1, the .xml files are present in the /nsconfig/loginschema directory.

Single sign-on (SSO) to StoreFront fails if the TCP fast open option is enabled for the default TCP profile of a manually created NetScaler Gateway virtual server.

The VPN session sync fails when the NetScaler appliance is upgraded to 11.1.49.11.

When you run the command "sh icaconnection summary", the columns in the output are misaligned.

Copyright information is not translated from English to another language. The copyright information is displayed only in English.

The primary NetScaler appliance in a high availability (HA) pair might reboot under the following conditions: The MTU of one of the HA interfaces of the primary appliance is modified. ICA sessions are active, and session reliability for the HA feature is enabled.

You cannot configure the portal theme for AAA authentication unless the SSLVPN is also enabled for portal theme configuration.

If an End User License Agreement (EULA) is bound to the VPN virtual server, the EULA checkbox does not appear if the nFactor authentication is enabled for NetScaler Gateway.

For PreAuth and PostAuth Logging, you must use the VPN parameter. If the clientSecurityLog value is modified in a session action whose session policy has a ClientSecurity expression as the rule, the clientSecurityLog value of the session action is not honored.

If a VPN virtual server is bound as the default virtual server to a content switching (CS) virtual server, the "show VPN virtual server" command does not display the details of the CS virtual server to which the VPN virtual server is bound.

If an automatic proxy script is configured on a client machine and split tunnel is ON, establishing a VPN tunnel makes all external websites, including a VPN server, inaccessible from Internet Explorer 11 if they are unreachable without a proxy.

Workaround: Set the following registry to 1 and restart Internet Explorer at least once: HKLMSOFTWAREPoliciesMicrosoftWindowsCurrentVersionInternet SettingsEnableLegacyAutoProxyFeatures

Active user sessions GUI view shows Client IP as 0.0.0.0 and Server IP as 0.0.0.0 in the first row of each active user session.

After a NetScaler HA failover, the Citrix Receiver takes a few seconds to reconnect.

Enhanced Datagram Transport Layer Security (DTLS) is not supported if the key length of a DTLS certificate file is 1024 bit.

Workaround: Use key length 2048 bits or more.

If you access a NetScaler Gateway appliance from a browser set to a non-English language, and the page for changing an expired password uses the RfWebUI theme, the text on the page appears is in English only.

LR channel MTU settings are not supported in the Management Service. You must set the MTU settings in the virtual machine.

You can only assign 22 partition MAC addresses to the following SDX platforms and the virtual machine will not start, if you assign more than 22 partition MAC addresses:

* 11500

* 13500

* 14500

* 16500

* 18500

* 20500

* 115xx series

After you install a new SSL certificate, the Management Service restarts, but the logon screen does not appear. Instead, an error message indicates that the appliance is DOWN. The message is incorrect.

If, the first time you provision a NetScaler VPX appliance, you configure an LA interface for VRID or allowed VLAN, or specify a global base MAC address, the corresponding fields in the Management Service are blank when provisioning is completed.

When you create or delete a 10G LACP or static channel, transmission stalls on the member interfaces of the channel, and therefore those interfaces stop processing traffic.

Workaround: Delete the 10G LACP/static channel that has this issue and create it again.

In some cases, individual flow control (RX and TX) might not work for interfaces on the NetScaler SDX appliance.

The command-line interface or the GUI of a NetScaler instance running on a NetScaler SDX appliance does not display the actual state of the management ports, instead the state is always shown as UP.

Enabling trunkAllowedVlan on an interface with more than 100 VLANs might cause a spike in CPU usage.

The following error messages might appear if you configure more than 100 VLANs in the trunkallowedVlan list on an interface in NetScaler instance:

ERROR: Operation timed out

ERROR: Communication error with the packet engine

If you try to modify the trunkAllowedVlan parameter and the command fails, the existing trunkAllowedVlan list configured for the interface is deleted.

The physical link status of a PCI passthrough interface of a NetScaler VPX appliance is not updated when the state of the link is changed (for example, when the link is enabled, disabled or reset) because of a limitation in the Intel XL710 NIC. As a result, any active traffic over the PCI passthrough interface fails during this time.

In ESX-5.5.0 (Patch-2456374), you cannot restart or shut down the NetScaler VPX instance from the VPX console.

When a remote tagged IP address is accessed through a NetScaler VPX appliance hosted on Linux KVM, the checksum value in each sent packet is incorrect.

In an ESX environment, file transfer from a NetScaler instance to an external connection stalls if the MTU is changed during the file transfer.

In an ESX environment, the Interface HAMON Configuration option is not available in the NetScaler GUI.

If you use the following command to remove an allowed-VLAN list from an SR-10V interface, the list is not removed, and therefore you cannot configure new VLAN settings for the interface.

unset int -trunkallowedVlan

Workaround: Restart the NetScaler virtual appliance.

Certificate-based authentication (SSH key pair) does not work on a NetScaler VPX appliance running on Azure. This happens due to internal logic that uses different keys to encrypt and decrypt certificate data.

Due to a limitation in Linux-KVM and VMware ESX platforms, if you add new PCI passthrough interfaces to an existing NetScaler virtual appliance configured with SR-IOV interface, the PCI passthrough interfaces might take precedence over the existing SR-IOV interfaces.

Enabling trunk mode with tagged VLAN settings on an SR-IOV interface fails with the following error message:

"ERROR: Maximum number of tagged VLANs bound to the interface exceeded or the binding of this VLAN is not allowed on the interface."

However, trunk mode with tagged VLAN settings is shown as enabled in the output of the following command:

show interface summary

The NetScaler virtual appliance might fail to start if you have configured 15 or more SR-IOV and PCI passthrough interfaces.

Due to a limitation in XenServer platform, if NetScaler virtual appliances with different interfaces, such as SR-IOV and Para-virtualized (PV) mode interfaces, use the same physical NIC, traffic between the virtual appliances with different interfaces fails.

When you add custom DNS name server in the NetScaler VPX appliance through NetScaler CLI, DNS lookup fails. This happens due to a default Azure DNS server entry present in /etc/resolv.conf.

Workaround: Follow these steps:

1. Edit the /nsconfig/.AZURE/resolv.conf file to remove the entry "nameserver 168.63.129.16", and save the file.

2. Add the required DNS name server through NetScaler CLI, by using the command "add dns nameserver <dns server IP>".

3. Save the ns config file.

4. Restart the NetScaler VPX appliance.

When a NetScaler appliance processes traffic at line rate, management CPU spike is observed on the appliance while configuring allowed VLAN list.

If an interface and an IP address are bound to a VLAN, binding them to another VLAN fails with the following error message: "ERROR: Either the subnet is not directly connected or subnet already bound to another VLAN." The interface is unbound from its current VLAN and gets bound to the native VLAN.

If a VLAN specified in the allowed VLAN list of a trunk interface overlaps with the native VLAN of another interface, both the interfaces participate in packet processing on that VLAN.

In a high-availability setup, NSVLAN is synchronized to the secondary node as a regular VLAN if the same NSVLAN is not configured on the secondary node.

If you add an NTP time server by specifying the server name (host name), and the ns.conf file is very large, the result is a race condition in which the NTP daemon (NTPD) is started before host name services are ready.

Workaround: Do one of the following:

-Restart the NTP daemon after starting the NetScaler appliance.

-Add the NTP server by specifying the IP address of the server instead of specifying the host name.

A cipher suite bound to a custom cipher group is not saved in the configuration file. If you restart the appliance or upgrade the software, the cipher suite is no longer included in the appliance's configuration.

Workaround: Bind the cipher suite to the custom cipher group again.

All SSL-based policy expressions evaluate to FALSE in HTTP/2 connections.

ECDHE support with SSLv3 protocol on the NetScaler appliance is not compatible with RFC 4492, because SSLv3 does not support extensions and ECDHE needs extension support.

If you restart the SafeNet network HSM, you must also restart the SafeNet gateway daemon.

The output of the "stat ssl vserver" command includes the statistics for non-SSL virtual servers.

In a high availability (HA) setup, if the primary node supports a SafeNet HSM, the HSM configuration is propagated to the secondary node even though the secondary node is not configured to support the SafeNet HSM. For information about configuring an HA setup with SafeNet network HSMs, see the NetScaler documentation for SafeNet network HSM.

If you create a custom cipher group and bind it to an SSL entity, the profile name "SSL_EMBEDDED_PROFILE" incorrectly appears in the output of the "show ciphergroup" command. This error does not occur if you enable the Default profile before creating the custom cipher group and binding it to the SSL entity.

If you have configured two SafeNet HSMs in a high availability setup on a standalone NetScaler appliance, and the primary HSM goes down, the secondary HSM does not serve traffic after a failover.

A NetScaler appliance does not open a new connection to the back-end server if the following set of conditions is met:

- The global maxconn parameter is set to 1.

- The appliance is unable to reuse the connection for probing.

As a result, the transaction fails.

When transmitting a TCP packet, a NetScaler appliance reuses the same IP-ID for packet retransmission. This impacts the customer if a firewall, Intrusion Prevention System (IPS) or Intrusion Detection System (IDS) drops the packet during retransmission.

No Error or Warning is announced if a user tries to set trunk mode on the loopback interface.

In a high availability setup, forcing synchronization does not synchronize Port Control Protocol (PCP) mappings to the secondary node.

The NetScaler appliance now supports OAuth in a multifactor deployment and for cascading authentication. That is, OAuth can be now be used anywhere in a cascade, in first factor or in any of the factors, and as a fallback authentication policy.

In earlier releases, OAuth could be used only for the first factor.

Note: To use OAuth in a factor other than the first, you must register an authentication FQDN with the application because OAuth must start and end on the same virtual server.

This enhancement allows the user to Preview the custom portal themes by binding it to an Authentication virtual server. Earlier this support was only present for Gateway virtual servers.

At present, customization of the Portal pages is only offered for Gateway virtual server. Admins often have the same branding requirements for the Login page that is presented on the Authentication virtual server page - for example, tmindex.html. This enhancement supports Portal Theme binding for the Authentication virtual server.

The NetScaler appliance now supports OAuth in a multifactor deployment and for cascading authentication. That is, OAuth can be now be used anywhere in a cascade, in first factor or in any of the factors, and as a fallback authentication policy.

In earlier releases, OAuth could be used only for the first factor.

Note: To use OAuth in a factor other than the first, you must register an authentication FQDN with the application because OAuth must start and end on the same virtual server.

You can now change the credential default behavior by defining the loginschema so that the desired credentials (username and password) are used for SSO. To use the first factor for the SSO, you configure the loginschema to store the first factor credential at the specified indexes and use attribute expressions for the traffic policies.

Previously, multiple sets of login credentials were required for nFactor authentication. By default, the credentials used for the final factor were the default single sign-on (SSO) user name and password. If the first factor was LDAP (Lightweight Directory Access Protocol) but the second factor OTP (One Time Password) on a non-Active Directory password, the default credentials became OTP. This procedure was complex and affected usability.

Configuration:

> set authentication loginSchema ls1 -SSOCredentials YES Done

> set authentication loginSchema ls1 -SSOCredentials NO Done

With this enhancement, NetScaler now supports GET requests from SAML SPs.

This enhancement provides NetScaler, which acts as a SAML IDP, to pass the SPID value to the SP in an IDP initiated connection.

On a partitioned NetScaler appliance, you can now bind a VLAN as a dedicated VLAN for a particular partition or as a shared VLAN across multiple partitions.

On a partitioned NetScaler appliance, you can now bind a VLAN as a dedicated VLAN for a particular partition or as a shared VLAN across multiple partitions.

If a NetScaler high-availability failover occurs when ICA AppFlow is enabled, the session reliability feature now restores the session. This capability is currently disabled by default and configurable through CLI. The CLI command to enable/disable the feature is:

set ica parameter EnableSRonHAFailover YES/NO

For more information, see http://docs.citrix.com/en-us/netscaler/11-1/ns-ag-appflow-intro-wrapper-con/session-reliablility-on-netscaler-ha-pair.html

Partially striped and spotted policy based routes (PBR) are now supported on a Layer 3 NetScaler cluster.

Partially striped and spotted policy based routes (PBR) are now supported on a Layer 3 NetScaler cluster.

In a cluster setup, you can now configure the SNMP MIB in any node by including the ownerNode parameter in the set snmp mib command. Without this parameter, the set snmp mib command applies only to the cluster coordinator node.

To display the MIB configuration for an individual node other than the cluster coordinator node, include the ownerNode parameter in the show snmp mib command.

The NetScaler appliance now supports the EDNS0 client subnet (ECS) option in deployments that include the NetScaler appliance configured as an ADNS server authoritative for a GSLB domain. In the deployment, if you use static proximity as the load balancing method, you can now use the IP subnet in the ECS option, instead of using the LDNS IP address, to determine the geographical proximity of the client. In the case of proxy mode deployment, the appliance forwards a DNS query with the ECS option as-is to the back-end servers and does not cache DNS responses that include the ECS option.

Note: The EDNS0 client subnet (ECS) option is not applicable for some other deployment modes, such as ADNS mode for non-GSLB domains, resolver mode, and forwarder mode. In such modes, the ECS option is ignored by the NetScaler appliance.

The NetScaler appliance now supports the EDNS0 client subnet (ECS) option in deployments that include the NetScaler appliance configured as an ADNS server authoritative for a GSLB domain. In the deployment, if you use static proximity as the load balancing method, you can now use the IP subnet in the ECS option, instead of using the LDNS IP address, to determine the geographical proximity of the client. In the case of proxy mode deployment, the appliance forwards a DNS query with the ECS option as-is to the back-end servers and does not cache the DNS responses that include ECS option.

Note: The EDNS0 client subnet (ECS) option is not applicable for some other deployment modes, such as ADNS mode for non-GSLB domains, resolver mode, and forwarder mode. In such modes, the ECS option is ignored by the NetScaler appliance.

For more information, see http://docs.citrix.com/en-us/netscaler/11-1/gslb/configure-EDNS0-client-subnet.html.

A parameter named monConnectionClose has been added at the service and service group levels. If this parameter is not set, the monitor connection is closed by using the value set in the global load balancing parameters. If this parameter is set at the service or service group level, the monitor connection is closed by sending a connection termination message, with the FIN or RESET bit set, to the service or service group.

NetScaler appliances now support load balancing virtual servers of type SSL_FIX, which can load balance FIX-protocol requests at the FIX message level and allow FIX-specific session persistence.

You can now configure an HTTPS virtual server to also process all HTTP traffic. That is, if HTTP traffic is received on the HTTPS virtual server, the appliance internally prepends "https://" to the incoming URL or redirects the traffic to another HTTPS URL, depending on the option configured.

For more information about configuring an HTTPS virtual server to accept HTTP traffic, see http://docs.citrix.com/en-us/netscaler/11-1/ssl/config-ssloffloading/ssl-config-https-vserver-to-accept-http-traffic.html.

Accidentally deleting a service or service group that is bound to a virtual server can result in the virtual server going DOWN. With this release, you cannot delete a service or service group that is bound to a virtual server until you first unbind it from the virtual server.

The NetScaler appliance now supports secure FTP monitoring. That is, you can now configure the appliance to send secure FTP probes to your FTP services.

For more information about secure FTP monitoring support, see http://docs.citrix.com/en-us/netscaler/11-1/load-balancing/load-balancing-builtin-monitors/lb-built-in-monitors-secure-monitoring-using-sftp.html.

In certain cases, cores of a NetScaler appliance might not be synchronized, because a core-to-core monitoring or service update has not reached one of the cores. For example, if the core that owns persistency has not received notification that a service is DOWN, that service remains in the persistency table. If a traffic-owner core that has been notified that the service is DOWN finds it in the persistency table, it requests a different service from the persistency-owner core, so that it can redirect the request. Before this enhancement, if the persistency owner returned the same service, the traffic-owner core dropped the user's request. Now, instead of immediately dropping the request, the traffic owner queries the persistency owner a second time. Sending the second query usually gives the persistency owner enough time to have received the update, in which case it returns a different service.

A parameter named monConnectionClose has been added at the service level. If this parameter is not set, the monitor connection is closed by using the value set in the global load balancing parameters. If this parameter is set at the service level, the monitor connection is closed by sending a connection termination message, with the FIN or RESET bit set, to the service.

For more information about closing monitor connections at the service level, see http://docs.citrix.com/en-us/netscaler/11-1/load-balancing/load-balancing-configure-monitors/close-monitor-connection.html.

A parameter named monConnectionClose has been added at the service group level. If this parameter is not set, the monitor connection is closed by using the value set in the global load balancing parameters. If this parameter is set at the service group level, the monitor connection is closed by sending a connection termination message, with the FIN or RESET bit set, to the service group.

For more information about closing monitor connections at the service group level, see http://docs.citrix.com/en-us/netscaler/11-1/load-balancing/load-balancing-configure-monitors/close-monitor-connection.html.

A monitor inherits either the global settings or the settings of the service to which it is bound. If a monitor is bound to a non-SSL or non-SSL_TCP service, such as SSL_BRIDGE, you cannot configure it with SSL settings such as the protocol version or the ciphers to be used. Therefore, in such deployments, SSL-based monitoring of the back-end servers is ineffective.

This enhancement gives you more control over SSL-based monitoring of back-end servers, by enabling you to bind an SSL profile to a monitor. An SSL profile contains SSL parameters, cipher bindings, and ECC bindings. For example, you can set server authentication, ciphers, and protocol version in an SSL profile and bind the profile to a monitor. Note that to perform server authentication, you must also bind a CA certificate to a monitor. To perform client authentication, you must bind a client certificate to the monitor. New parameters for the "bind lb monitor" command enable you to do so.

Note: The SSL settings take effect only if you add a secure monitor. Also, the SSL profile type must be BackEnd.

SSL profiles can be bound to the following monitor types:

- HTTP

- HTTP-ECV

- TCP

- TCP-ECV

- HTTP-INLINE

To specify an SSL profile while adding a monitor by using the command line

At the command prompt, type:

add lb monitor <monitorName> <type> -secure YES -sslprofile <string>

set lb monitor <monitorName> <type> -secure YES -sslprofile <string>

Example:

add ssl profile prof1 -sslProfileType BackEnd

add lb monitor mon1 HTTP -secure YES -sslprofile prof1

To bind a certificate-key pair to a monitor by using the command line

At the command prompt, type:

bind monitor <monitor name> -certkeyName <string> [(-CA [-crlCheck ( Mandatory | Optional ) | -ocspCheck ( Mandatory | Optional )]

A load balancing configuration has a large number of parameters, so setting the same parameters on a number of virtual servers can become tedious. You can now set load balancing parameters in a profile and associate this profile with virtual servers, instead of setting these parameters on each virtual server.

For more information about load balancing profiles, see http://docs.citrix.com/en-us/netscaler/11-1/load-balancing/lb-support-for-load-balancing-profile.html.

NetScaler appliances now support load balancing virtual servers of type SSL_FIX, which can load balance FIX-protocol requests at the FIX message level and allow FIX-specific session persistence.

The NetScaler appliance now supports reverse TCP monitors. A reverse monitor marks the service as DOWN if the probe criteria are satisfied and UP if they are not satisfied.

A direct TCP monitor marks the service as DOWN if it receives a RESET in response to the monitor probe. However, a reverse TCP monitor treats RESET as a successful response and marks the service as UP.

To configure a reverse TCP monitor by using the NetScaler command line

At the command prompt, type:

add lb monitor <monitor-name> tcp -reverse yes -destip <primary-service ip> -destport <primary-service port>

bind service <svc-name> -monitorname <monitor-name>

To configure a reverse TCP monitor by using the NetScaler GUI

1. Navigate to Traffic Management > Load Balancing > Monitors.

2. Create a TCP monitor and select Reverse.

For more information, see http://docs.citrix.com/en-us/netscaler/11-1/load-balancing/load-balancing-custom-monitors/lb_custom_monitor_configuring_reverse_monitoring_for_a_service.html.

A new API, macroapi, can be used to configure a set of homogeneous or heterogeneous objects in a single API request. The query parameter "onerror" specifies the action to be taken if an error is encountered. Possible values for this parameter are exit, continue, and rollback.

For more information about this NITRO API, see http://docs.citrix.com/en-us/netscaler/11-1/nitro-api/nitro-rest/nitro-rest-usage-scenarios/multiple-nitrocalls-single-request.html.

You can use a bulk GET API to fetch bindings of all the entities of a given entity type.

For example, you can fetch bindings of all the load balancing virtual servers in one call instead of by using multiple GET by "name" calls.

For information about this NITRO API, see http://docs.citrix.com/en-us/netscaler/11-1/nitro-api/nitro-rest/nitro-rest-usage-scenarios/retrieve-bindings-bulk.html.

You can add or update resources seamlessly, with a single API, by using the new "idempotent" query parameter. Previously, an attempt to add a resource that was already configured, or to update a resource that was not yet configured, caused an error.

Now, if you include "idempotent=yes" in a POST request, NITRO executes the request in an idempotent manner.

For more information about this API, see http://docs.citrix.com/en-us/netscaler/11-1/nitro-api/nitro-rest/nitro-rest-usage-scenarios/management-operations-idempotentAPI.html.

A new API, install, can be used to upgrade or downgrade a NetScaler appliance. You can specify a local or remote location for the build file used to upgrade or downgrade the appliance.

For more information about this NITRO API, see http://docs.citrix.com/en-us/netscaler/11-1/nitro-api/nitro-rest/nitro-rest-usage-scenarios/automate-upgrade-downgrade.html.

You can now direct ping and traceroute operations to any host, by using the NITRO API through the NetScaler appliance.

1) A new system parameter was added. "totalAuthTimeout" - the default value is 20 seconds, minimum value 5 seconds and maximum 120 seconds. set system parameter - totalAuthTimeout <positive_integer>

2) A new aaa radius param was added. authservRetry - the default value is 3 retries, minimum 1 and maximum 10 retries can be configured.

set aaa radiusParams - authservRetry <positive_integer>

Citrix NetScaler CPX is a container-based application delivery controller that can be provisioned on a Docker host. NetScaler CPX enables customers to leverage Docker engine capabilities and use NetScaler load balancing and traffic management features for container-based applications. You can deploy one or more NetScaler CPX instances as standalone instances on a Docker host. For more information, see About NetScaler CPX: http://docs.citrix.com/en-us/netscaler-cpx/11-1/about-netscaler-cpx.html.

All the open source packages that are used in NetScaler CPX are available in the contrib/cpx/ folder.

Two new icons in the NetScaler GUI display action menus and information menus. If you are in a window with detail-view rows, and the rows have actions, you can now display the action menu by clicking the action icon in that row, rather than right-clicking the row.

Similarly, you can display the info menu by clicking the info icon.

The NetScaler GUI now provides a wizard for easy configuration of a CloudBridge Connector tunnel between the NetScaler appliance and a Virtual Private Gateway on Amazon AWS.

You can now automatically upload the technical support collector archive to Citrix Support servers.

Navigate to System > Diagnostics > Technical Support Tools > Generate support file, and select Upload the Collector Archive. Type your user credentials and click Run.

IPv4 address fields now do not have dot separators, which improve the usability of these fields.

1) Links to the following pages have been removed from the SSL overview page:

- Create RSA Key

- Create DSA Key

- Create CSR

- Create Certificate

To access these pages, navigate to Traffic Management > SSL > SSL Files.

2) Server, client, and CA certificates are now segregated. When you bind a certificate to an SSL end point, only the list of appropriate certificates appears. For example, when you bind a server certificate to an SSL virtual server, only the server certificates are listed. In earlier releases, all the certificates, including client and CA certificates, were listed.

3) You can configure an SNMP trap from the "Install Certificate" page to send a notification when the certificate is about to expire. For a valid certificate in the notification period, status changes to yellow. For an expired certificate, status changes to red.

4) "Certificate format" field has been removed, because the format (PEM/DER/PFX/Bundle) is automatically detected by the software during certificate installation. Also, if the file is not password protected, you are not prompted for a password.

5) The key files, CSR files, and certificate files are segregated onto different tabs for ease of use.

6) The SSL certificate overview page now explains the end-to-end flow of managing certificates on your appliance.

The NetScaler GUI now supports configuration of a node in High Availability (HA) mode even if the Secure Access Only option is enabled for the NetScaler IP (NSIP) address of the other node in the HA pair.

In the load balancing visualizer, you can now seamlessly migrate the configuration of a service to all the services bound to the virtual server. To copy the settings of one service to all the other services, in the visualizer, click "Configuration Sets," select a service, and then click "Migrate Config."

The NetScaler appliance was enhanced so Negotiate Authentication is available for VPN Virtual Servers. The GUI reflects this under the NSG > Policies > Authentication node.

Starting and stopping nstrace are now separate options in the NetScaler GUI. As a result, it is easier to stop a running trace and download the results.

Navigate to System > Diagnostics and select "Start New Trace" or "Stop Running Trace."

The top pane of the NetScaler GUI now displays the High Availability status of the node. This instant visibility of HA status helps you monitor the HA configuration efficiently.

To test connectivity from a subnet IP (SNIP) address to another IP address, you can now select the source address from a list of SNIP addresses instead of typing the SNIP address. If the SNIP address is not in the list, you can add it. To use this feature, navigate to System > Diagnostics. In Utilities, select ping or ping6, and then select "SNIP."

The new, tabular, Application Firewall wizard improves flexibility and accelerates the completion of tasks. You can go back to any page and edit any details about profiles, policies, and signatures, and skip screens that are not mandatory. In addition, all resource-consuming tasks, such as submission and binding, are completed after you click Finish.

For more information about the wizard, see http://docs.citrix.com/en-us/netscaler/11-1/application-firewall/configuring-application-firewall/using-wizard.html

What is added?

The XenApp and XenDesktop wizards provide a new authentication configuration flow, and a new configuration download option to automatically import the NetScaler Gateway configuration required for StoreFront. In addition, all sections in the wizard have been refined to make overall deployment configuration much simpler. The following new configuration options are provided:

1. You can use a FQDN to connect to a virtual server, instead of using the IP address. A Gateway FQDN virtual server can forward traffic to a NetScaler Gateway virtual server IP address.

2. StoreFront FQDN is changed to StoreFront URL ( HTTP / HTTPS ).

3. The Authentication section now supports the following authentication types for StoreFront: Domain, RSA, SMS, Smart Card and RSA+ Domain.

4. XenApp and XenDesktop wizard dashboards provide a button that downloads the configuration file. This file only contains the first NetScaler Gateway successfully created configuration.

The following items have been removed from the XenApp and XenDesktop wizards:

1. Load Balancing configuration section under the StoreFront settings

2. Load Balancing configuration section under the Authentication section

3. XenApp Farm section

4. Advanced configuration options for deploying StoreFront

What is expected in case of an upgrade?

When a NetScaler appliance is upgraded to a build with a new XenApp and XenDesktop wizard, any deployments created in the previous version retain the old wizard view and functionality. New NetScaler Gateway deployment for StoreFront will use the new flow.

This enhancement provides NetScaler the ability to use the FIPS SSL key to perform SAML signing. For all customers looking for FIPS compliant devices and SAML based user identity, this enhancement is very useful.

This enhancement provides the ability to a clear config basic command so it will not erase the TACACS related configuration.

Multi-factor authentication enhances the security of an application by requiring users to provide multiple proofs of identification to gain access. The NetScaler appliance provides an extensible and flexible approach to configuring multi-factor authentication. This approach is called nFactor authentication.

This multi-factor authentication capability is now available for all Gateway use cases as well

This enhancement provides the ability for the end-user to specify the RDP destination instead of the administrator pre-configuring it. The Gateway portal provides the option to provide a field where the user can enter the RDP destination. The user can launch the RDP connection by entering the destination info. This option is administrator-controlled, so that only a specific group of users can be provided with this capability.

This enhancement allows the binding of DNS-based Rewrite or Responder policies to Gateway VPN virtual servers. This enhancement can filter-in or filter-out DNS traffic going through the SSL VPN.

The STA and nextHop VPN parameters can now be configured using FQDN instead of just the IP address. The STA server is used for authorizing ICA connections and NextHop is used for specifying the second-hop in a "double-hop" Gateway deployment.

Non-Blocking LDAP SSL/TLS authentication support added. This enhancement reduces the authentication bottleneck to prevent delayed/denied user logons.

In this release, the UI experience for Windows plugin has been improved. New capabilities like the drop-down list of connected Gateway servers has been added. Also, more status information, like progressive bars during download or VPN connection establishment, has been added.

The RfWeb UI Gateway feature provides users a consistent portal experience when accessing corporate apps and resources from inside corporate network or remotely from Internet. The StoreFront Receiver for the Web User Interface (RfWeb UI) is now available from NetScaler Gateway natively. This UI is provided as a portal theme that can be bound to Gateway virtual server/global to get the exact same UI experience as that of StoreFront.

By using the RfWeb UI theme, customers can consolidate all types of applications - Citrix virtual apps/desktops, Enterprise webapps, SaaS/cloud apps, RDP resources and SSL VPN apps - on the Gateway portal with the same experience as that of StoreFront.

This feature supported from StoreFront 3.6 onwards.

Framehawk technology is used to provide the best end-user experience on Citrix virtual apps/desktops (ICA/HDX connections) on any type of network. NetScaler Gateway now supports ICA/HDX connections based on Framehawk with double STA tickets. This helps to maintain fault tolerance from STA servers.

The AlwaysOn feature enables Gateway plugins to detect the location of the user (intranet/corporate vs. Internet/extranet) and establish the VPN connection automatically. The Administrator controls the plugin behavior to establish the connections to all locations or only from internet. Also, controls are provided to enable/disable the user's ability to logoff from the Gateway and network behavior when the VPN connection has not been established.

This feature is very useful for enhancing the end-user experience by eliminating the manual step of establishing/terminating the VPN connection. It is also very helpful for customers looking to maintain strict security controls on remote access users by tunneling all traffic through the Gateway. The feature is supported on the Windows platform.

This enhancement allows an admin to view the different LoginSchemas present in NetScaler. This is done from the NetScaler admin GUI under LoginSchema Profiles configuration. Use the following path to see the LoginSchemas: Configuration>Security>AAA -Application Traffic>Login Schema>Profiles.

The Unified Gateway Visualizer provides an easy visual representation of the configurations done using the Unified Gateway Wizard. It shows the pre-authentication and authentication policies, Content Switching, NetScaler Gateway and Load Balancing virtual servers, XA/XD apps, Web and SaaS apps.

Along with the visual representation, admins can use this Visualizer for below purposes:

1. Edit the Unified Gateway configuration

2. View various policies, like Session Policy, Rewrite and Responder Policy etc.

3. Add new configuration, like policies, Web apps, SaaS apps.

4. View the state of the Load Balancing, vservers and services, NetScaler Gateway vserver and Content Switching vserver

In this release, RDP Proxy connections use the same IP and port as that of the Gateway vserver. Hence, there is no need to open any new IP or port on the uplink firewalls.

This enhancement supports SAML SP Artifact Binding flows for nfactor.

This enhancement provides NetScaler, which is acting as SAML IDP, the capability to sign the entire SAML response along with the assertion.

This enhancement introduces support for a new key transport algorithm(RSA-V1_5). The RSA-V1_5 can used to encrypt SAML assertions along with RSA-OAEP.

The NetScaler appliance inserts an NS_ESNS cookie for page tracking (for showing a waterfall chart) when AppFlow is enabled. Cookie insertion was controlled by the clientSideMeasurements option in the appflow action in release 10.5, but in release 11.0 the default became to always insert the cookie when appflow is enabled. Android receiver (HTTP client) was not able to handle this cookie. This fix adds the Enable/Disable page tracking (cookie insertion) option to the appflow action.

You can now enable or disable Page tracking feature from NetScaler Insight Center.

To perform this action, navigate to Configuration > System > Appflow > Actions. Edit an AppFlow action name, and select the Page Tracking check box.

During certificate authentication, if only one certificate is present on a client's computer, it is now chosen by default. The user is no longer prompted to select a certificate. However, if two or more certificates are present, the user is prompted to select a certificate. Additionally, if the certificate is successfully authenticated, the certificate preference is automatically saved. The preference is removed if the certificate authentication later fails, or if the user manually clears the saved certificate option by setting NetScaler Gateway Plugin preferences.

You can now extract attributes from Access Control Server (ACS) and Terminal Access Controller Access-Control System (TACACS). The extracted attributes allow the admin to use the NetScaler Group Attribute command to authorize usage.

The global AAA parameter "set aaa param -maxaAAUser <value>" has been enhanced to automatically increase or decrease when new concurrent user (CCU) licenses are added or removed. Previously, adjusting the MaxAAAUser count was a manual adjustment that needed to be done after extra licenses were added. This value represents the maximum number of global AAA sessions that can exist. If you want to restrict the number of AAA sessions to a value lower than the licensed limit, you can set the maxaAAUser parameter on the gateway virtual server.

New CCU packaging and pricing have changed in the following ways:

1. MaxAAA is automatically set to the maximum licensed number.

2. Licenses now use the following scheme:

a. Platinum: Unlimited (formerly 100)

b. Enterprise: 1000 (formerly 5)

c. Standard: 500 (formerly 5)

d. Any other license: 5

e. If additional CCU licenses are present on the system, you add those to the above values

(for example, standard is 500 + any additional CCU licenses).

f. Disregard additional CCUs for the platinum case, since platinum is already unlimited.

In the XenApp/XenDesktpo configuration wizard, the StoreFront Settings Download option is now hidden if StoreFront is not deployed.

Other Opswat EPA scans, such as version match checking, can be configured to verify HP drive encryption.

The NetScaler appliance now allows you to choose an existing domain-server configuration, if available, instead of having to configure a new domain server when the appliance is updated.

Previously, if you configured a domain server, you would not be able to use the existing configuration when the NetScaler appliance was updated, because there was no provision to choose an existing configuration for the XA-XD Wizard.

You can now terminate specified RDP proxy connections.

kill rdpConnection [-userName <string>] [-all]

- userName: Terminates RDP Proxy connections that belong to the specified user.

- all: terminates all active rdp proxy connections.

The Unified Gateway wizard now provides an option to retrieve LDAP attributes when creating an LDAP Action. Also, you can choose an extracted LDAP attribute as an LDAP Login name, and you can evaluate LDAP bind credentials.

You can now assign IPv4, IPv6, or both IP addresses to your NetScaler Insight Center server. To assign a new IP address, navigate to Configuration > System > Network Configuration, and select IPv4, IPv6, and/or both and specify the network parameters.

If you specify both IPv4 and IPv6 addresses, you can access the NetScaler Insight Center by using any one of the IP addresses.

In HDX Insight, you can view a diagrammatic representation of a client's current session details.

Navigate to HDX insight > Users, and in the Current Sessions section, click the Diagram button to display details such as Client IP address, NetScaler IP address, Origin Server IP address, Country, Region, Session ID, and Client Version.

You can now view the client's machine name for any user session in HDX Insight.

You can now view the current session details from the Geomaps section in HDX Insight.

You can now use NetScaler Insight Center to monitor NetScaler integrated caching. Cache Insight enables you to see and monitor the various actions performed by the NetScaler cache.

NetScaler Insight Center can now use the X-Forwarded-For header to display the actual client IP address instead of the IP address of the proxy that forwarded the request.

The following thin clients now support HDX Insight:

-WYSE Windows based thin clients

-WYSE Linux based thin clients

-WYSE ThinOS based thin clients

-10Zig Ubuntu based thin clients

You can now enable, edit, or clear AppFlow on multiple virtual servers simultaneously. To perform these actions, navigate to Configuration > Inventory and open your NetScaler Instance. Select the virtual servers and click Enable AppFlow, Edit AppFlow Settings, or Clear AppFlow Configuration, respectively.

You can now search for a specific application, client, or server by using the Search option in Web Insight.

1)You can now use NetScaler Insight Center to monitor and manage your incoming traffic's IP Reputation.

2)You can now enable/disable AppFlow for Security insight separately from the Enable AppFlow option. To Enable or Disable AppFlow, navigate to Configuration > Inventory and open your NetScaler Instance. Select the virtual servers and click Enable AppFlow and select the Security Insight option.

You can now view USB event reports of a user's active sessions on HDX Insight. You can view details such as USB Status, Number of USB Instances Accepted, Number of USB Instances Rejected, and Number of USB Instances Stopped.

You can now cascade external authentication servers to have a continuous, reliable authentication process in place to authenticate and authorize external users. If authentication fails on the first authentication server, the NetScaler SDX Management Service attempts to authenticate the user by using the second external authentication server, and so on.

You can cascade up to 32 external authentication servers.

For more information, see http://docs.citrix.com/en-us/sdx/11-1/configuring-management-service/cascading_external_authentication_servers.html.

Using the Admin profile, you can now specify whether the Management Service and the NetScaler VPX instance should communicate with each other only over a secure channel or by using HTTP.

For any operations that require NetScaler SDX appliance reboot, Management Service now detects the unsaved configurations on the NetScaler instances and prompts you to save them.

If you are not using any of the physical interfaces on a NetScaler SDX appliance, you can now disable them by using Management Service.

For more information, see http://docs.citrix.com/en-us/sdx/11-1/manage-monitor-appliance-network-configuration/managing-interfaces.html.

Management Service now displays the reason for Out Of Service state of the NetScaler instances when you mouse over on them in the dashboard.

The management service now uses the SHA512 encryption method to encrypt the nsrecover passwords stored on the SDX appliance.

You can now configure a NetScaler SDX appliance to transfer the backup files to an external backup server by using FTP, SFTP, and SCP.

For more information, see http://docs.citrix.com/en-us/sdx/11-1/configuring-management-service/backup-restore.html.

You can now send notifications to communicate with selected groups of users for a number of system-related functions.

The Management Service now provides an option to encrypt the backup files.

For more information, see http://docs.citrix.com/en-us/sdx/11-1/configuring-management-service/backup-restore.html.

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.

SDX Appliances now support IPv6 addresses in the following configurations:

- SDX Network Configuration

- Server Configuration

- Authentication Server

- Syslog Server

- SNMP Server

- Notification Server

- SNMP Interface Configuration

- NetScaler Configuration (If provisioning uses IPv6 address.)

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.

You can now customize the CLI prompt of 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

You can now generate partition MAC addresses on a NetScaler SDX appliance and use them to configure admin partitions on a NetScaler instance on the appliance.

For more information, see http://docs.citrix.com/en-us/sdx/11-1/configuring-managing-netscaler-instance/generate-partition-MAC-addresses.html.

You can now add the network subnet of the SNMP manager instead of specifying the SNMP Manager's IP address or host name. If you do not configure at least one SNMP manager, the appliance accepts and responds to SNMP queries from all IP addresses on the network. If you configure one or more SNMP managers, the appliance accepts and responds only to SNMP queries from those specific IP addresses or IP addresses from that subnet.

For more information, see http://docs.citrix.com/en-us/sdx/11-1/manage-monitor-appliance-network-configuration/configuring-snmp-trap-destination.html.

This release includes the support for new NetScaler SDX platform, SDX-25000A.

40G license is now available for NetScaler VPX appliance on ESX and KVM platforms

For more information about recommended interfaces and performance details, refer to the latest VPX datasheet.

The number of unique IPv6 addresses that you can add to a NetScaler virtual appliance configured with SR-IOV interfaces is limited to 30 on the following platforms:

* XenServer

* Linux-KVM

* VMware ESX

The following licenses are now available for NetScaler VPX appliances on a XenServer platform:

* 25MB

* 5G

* 8G

* 10G

* 15G

* 25G

Also, a 100G license is now available for NetScaler VPX appliances on a KVM platform.

For more information about recommended interfaces and performance details, see the latest VPX datasheet.

Microsoft Direct Access is a technology that enables remote users to seamlessly and securely connect to enterprise's internal networks, without the need to establish a separate VPN connection. Unlike VPN connections, which require user intervention to start and close connections, a Direct Access-enabled client connects automatically to the enterprise's internal networks whenever the client connects to the Internet.

Manage-Out is a Microsoft Direct Access feature that allows administrators inside the enterprise network to connect to Direct Access clients outside the network and manage them (for example, performing administration tasks, such as scheduling service updates, and providing remote support.

In a Direct Access deployment, NetScaler appliances provide high availability, scalability, high performance, and security. NetScaler load balancing functionality sends client traffic through the most appropriate server. The appliances can also forward the Manage-Out traffic through the right path to reach the client.

In a non-INC high availability (HA) setup in which a routing protocol is configured, after a failover, routing protocol is converged and routes between the new primary node and the adjacent neighbor routers are learned. Route learning take some time to complete. During this time, forwarding of packets is delayed, network performance might get disrupted, and packets might get dropped.

Graceful restart enables an HA setup during a failover to direct its adjacent routers to not remove the old primary node's learned routes from their routing databases. Using the old primary node's routing information, the new primary node and the adjacent routers immediately start forwarding packets, without disrupting network performance.

The following routing protocols support graceful restart in a non-INC high availability setup:

- Border Gateway Protocol (BGP)

- IPv6 Border Gateway protocol (IPv6 BGP)

- Open Shortest Path First (OSPF)

- IPv6 Open Shortest Path First (OSPFv3)

NetScaler Appliances Support VIP6 Addresses in Active-Active Deployments.

An active-active deployment, in addition to preventing downtime, makes efficient use of all the NetScaler appliances in the deployment. In an IPv6 active-active deployment mode, the same VIP6 address is assigned to every NetScaler appliance in the configuration, but with different priorities, so that a given VIP6 can be active on only one appliance at a time.

The active VIP6 address is called the master VIP6, and the corresponding VIP6s on the other NetScaler appliances are called the backup VIP6s. If a master VIP6 fails, the backup VIP6 with the highest priority takes over and becomes the master VIP6. All the NetScaler appliances in an active-active deployment use the Virtual Router Redundancy Protocol (VRRP) to advertise their VIP6s and the corresponding priorities at regular intervals.

NetScaler appliances in active-active mode can be configured so that no appliance is idle. In this configuration, different sets of VIPs are active on each appliance.

The following features of IPv4 active-active configuration are also supported for IPv6 active-active configuration:

* Preemption

* Delaying preemption

* Sharing

* Changing VIP address priority automatically

Network Services Header (NSH) is a new standard that enables the Service Function Chaining (SFC) architecture. NSH enables you to define the service chain paths and forward the data-plane traffic through multiple service nodes in a dynamic and fail-proof manner.

A NetScaler appliance can now play the service-function role in a SFC architecture. The NetScaler appliance receives packets with Network Service headers and, upon performing the service, modifies the NSH bits in the response packet to indicate that the service has been performed. In that role, the appliance supports symmetric service chaining with features (for example, INAT, TCP and UDP load balancing services, and routing). The NetScaler appliance as service-function does not support IPv6 and Reclassification.

NetScaler appliances now support NITRO API for configuring dynamic routing protocols.

In a non-INC high availability (HA) setup in which a routing protocol is configured, after a failover, routing protocol is converged and routes between the new primary node and the adjacent neighbor routers are learned. Route learning take some time to complete. During this time, forwarding of packets is delayed, network performance might get disrupted, and packets might get dropped.

Graceful restart enables an HA setup during a failover to direct its adjacent routers to not remove the old primary node's learned routes from their routing databases. Using the old primary node's routing information, the new primary node and the adjacent routers immediately start forwarding packets, without disrupting network performance.

The following routing protocols support graceful restart in a non-INC high availability setup:

- Border Gateway Protocol (BGP)

- IPv6 Border Gateway protocol (IPv6 BGP)

- Open Shortest Path First (OSPF)

- IPv6 Open Shortest Path First (OSPFv3)

For more information, see:

- http://docs.citrix.com/en-us/netscaler/11-1/networking/ip-routing/configuring-dynamic-routes/configuring-ospf.html

- http://docs.citrix.com/en-us/netscaler/11-1/networking/ip-routing/configuring-dynamic-routes/configuring-ipv6-ospf.html

- http://docs.citrix.com/en-us/netscaler/11-1/networking/ip-routing/configuring-dynamic-routes/configuring-bgp.html

Some situations might demand that the NetScaler appliance drops specific outgoing packets instead of routing them, for example, in testing cases and during deployment migration. NULL policy based routes can be used to drop specific outgoing packets. A NULL PBR is a type of PBR that has the nexthop parameter set to NULL. The NetScaler appliance drops outgoing packets that match a NULL PBR. For more information, see http://docs.citrix.com/en-us/netscaler/11-1/networking/ip-routing/configuring-policy-based-routes/null-policy-based-routes-drop-outgoing-packets.html.

Microsoft Direct Access is a technology that enables remote users to seamlessly and securely connect to enterprise's internal networks, without the need to establish a separate VPN connection. Unlike VPN connections, which require user intervention to start and close connections, a Direct Access-enabled client connects automatically to the enterprise's internal networks whenever the client connects to the Internet.

Manage-Out is a Microsoft Direct Access feature that allows administrators inside the enterprise network to connect to Direct Access clients outside the network and manage them (for example, performing administration tasks, such as scheduling service updates, and providing remote support).

In a Direct Access deployment, NetScaler appliances provide high availability, scalability, high performance, and security. NetScaler load balancing functionality sends client traffic through the most appropriate server. The appliances can also forward the Manage-Out traffic through the right path to reach the client. For more information, see http://docs.citrix.com/en-us/netscaler/11-1/networking/interfaces/netscaler-support-microsoft-direct-access-deployment.html.

For diagnosing or troubleshooting problems related to RNAT connections, the NetScaler appliance now logs the following additional information:

- Start time of the RNAT session.

- Reason for closure of the RNAT session. The NetScaler appliance logs closure reason for TCP RNAT sessions that do not use the TCP proxy (TCP proxy disabled) of the appliance. The following are the type of closure reasons that are logged for TCP RNAT sessions:

-- TCP FIN. The RNAT session was closed because of a TCP FIN sent by either the source or destination device.

-- TCP RST. The RNAT session was closed because of a TCP Reset that was sent by either the source or destination device.

-- TIMEOUT. The RNAT session timed out.

For more information, see http://docs.citrix.com/en-us/netscaler/11-1/networking/ip-addressing/configuring-network-address-translation/configuring-rnat.html.

NetScaler appliances now support dynamic routing on a link-local Subnet IPv6 (SNIP6) address for a VLAN. In a default admin partition, link-local SNIP6 address takes precedence over the link-local NSIP6 address for running dynamic routing on a VLAN. In a non-default partition, the NetScaler appliance does not support dynamic routing on link-local NSIP6 address for a VLAN. Link-local SNIP6 address can now be used for running dynamic routing on the VLAN.

NetScaler accepts and sends tagged packets of a VLAN on an interface if the VLAN is explicitly configured on the NetScaler appliance and the interface is bound to the VLAN. Some deployments (for example, Bump in the wire) require the NetScaler appliance to function as a transparent device to accept and forward tagged packets related to a large number of VLANs. For this requirement, configuring and managing a large number of VLANs is not a feasible solution.

Allowed VLAN list on an interface specifies a list of VLANs. The interface transparently accepts and sends tagged packets related to the specified VLANs without the need for explicitly configuring these VLANs on the appliance. For more information, see http://docs.citrix.com/en-us/netscaler/11-1/networking/interfaces/configure-allowed-VLAN-list.html.

By default, the MTU of the NSVLAN is set to 1500 bytes. You can now modify this setting to optimize throughput and network performance. For example, you can configure the NSVLAN to process jumbo frames. For more information, see http://docs.citrix.com/en-us/netscaler/11-1/networking/interfaces/configuring-nsvlan.html.

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, http://docs.citrix.com/en-us/netscaler/11-1/load-balancing/load-balancing-manage-clienttraffic/use-specified-sourceport.html.

NetScaler Appliances Support VIP6 Addresses in Active-Active Deployments.

An active-active deployment, in addition to preventing downtime, makes efficient use of all the NetScaler appliances in the deployment. In an IPv6 active-active deployment mode, the same VIP6 address is assigned to every NetScaler appliance in the configuration, but with different priorities, so that a given VIP6 can be active on only one appliance at a time.

The active VIP6 address is called the master VIP6, and the corresponding VIP6s on the other NetScaler appliances are called the backup VIP6s. If a master VIP6 fails, the backup VIP6 with the highest priority takes over and becomes the master VIP6. All the NetScaler appliances in an active-active deployment use the Virtual Router Redundancy Protocol (VRRP) to advertise their VIP6s and the corresponding priorities at regular intervals.

NetScaler appliances in active-active mode can be configured so that no appliance is idle. In this configuration, different sets of VIPs are active on each appliance.

The following features of IPv4 active-active configuration are also supported for IPv6 active-active configuration:

* Preemption

* Delaying preemption

* Sharing

* Changing VIP address priority automatically

For more information, see http://docs.citrix.com/en-us/netscaler/11-1/networking/interfaces/active-active-mode-using-vrrp.html.

CloudBridge Connector tunnels can now be used to extend an enterprise's VLAN to a cloud. VLANs extended from multiple enterprises can have overlapping VLAN ID. You can now isolate each enterprise's VLANs, by mapping them to a unique VXLAN in the cloud. On a NetScaler appliance, which is the CloudBridge connector endpoint in the cloud, you can configure a VXLAN-VLAN map that links an enterprise's VLANs to a unique VXLAN in the cloud. VXLANs now support VLAN tagging for extending multiple VLANs of an enterprise from CloudBridge Connector to the same VXLAN.

If you change the NSIP address of a NetScaler appliance, you can now add a default route to the new address's subnet before restarting the NetScaler appliance. This change makes the new NSIP address accessible from other networks after the appliance is restarted.

In previous releases, if the subnet address of the new NSIP address is different from the previous one, you cannot add a default route for this new subnet until you restart the appliance. Because of this restriction, the new NSIP address is unreachable from other networks after a restart.

For more information, see http://docs.citrix.com/en-us/netscaler/11-1/networking/ip-addressing/configuring-netscaler-owned-ip-addresses/configuring-netscaler-ip-address.html.

By default, for a load balancing configuration with the USIP option disabled and a net profile bound to a virtual server or services or service groups, the NetScaler appliance uses the round-robin algorithm to select an IP address from the net profile for communicating with the servers. Because of this selection method, the IP address selected can be different for different sessions of a specific client.

Some situations require that the NetScaler appliance sends all of a specific client's traffic from the same IP address when sending the traffic to servers. The servers can then, for example, identify traffic belonging to a specific set for logging and monitoring purposes.

The source IP persistency option of a net profile enables the NetScaler appliance to use the same address, specified in the net profile, to communicate with servers for all sessions initiated from a specific client to a virtual server. For more information, http://docs.citrix.com/en-us/netscaler/11-1/load-balancing/load-balancing-manage-clienttraffic/configure-source-IP-persistency-backend-communication.html.

Connection failover helps prevent disruption of access to applications deployed in a distributed environment. The NetScaler appliance now supports stateful connection failover for connections related to RNAT rules in a NetScaler High Availability (HA) setup.

In an HA setup, connection failover (or connection mirroring) refers to the process of keeping an established TCP or UDP connection active when a failover occurs. The primary appliance sends messages to the secondary appliance to synchronize current information about the RNAT connections. The secondary appliance uses this connection information only in the event of a failover. When a failover occurs, the new primary NetScaler appliance has information about the connections established before the failover and hence continues to serve those connections even after the failover. From the client's perspective this failover is transparent. During the transition period, the client and server may experience a brief disruption and retransmissions.

Connection failover can be enabled per RNAT rule. For enabling connection failover on an RNAT rule, you enable the connFailover (Connection Failover) parameter of that specific RNAT rule by using either NetScaler command line or configuration utility. Also, you must disable the tcpproxy (TCP Proxy) parameter globally for all RNAT rules in order for connection failover to work properly for TCP connections.

For more information, see http://docs.citrix.com/en-us/netscaler/11-1/networking/ip-addressing/configuring-network-address-translation/configuring-rnat.html.

The two nodes in a high availability configuration send and receive heartbeat messages to and from each other on all interfaces that are enabled. The heartbeat messages flow regardless of the HA MON setting on these interfaces. If NSVLAN or SYNCVLAN or both are configured on an appliance, the heartbeat messages flow only through the enabled interfaces that are part of the NSVLAN and SYNCVLAN.

If a node does not receive the heartbeat messages on an enabled interface, it sends critical alerts to the specified Command Center and SNMP managers. These critical alerts give false alarms and draw unnecessary attention from the administrators for interfaces that are not configured as part of the connections to the peer node.

To resolve this issue, the HAHeartBeat option for interfaces and channels is used for enabling or disabling HA heartbeat-message flow on them.

For more information, see http://docs.citrix.com/en-us/netscaler/11-1/system/high-availability-introduction/managing-ha-heartbeat-messages.html.

In a load balancing configuration in DSR mode using TOS field, monitoring its services requires a TOS monitor to be created and bound to these services. A separate TOS monitor is required for each load balancing configuration in DSR mode using TOS field, because a TOS monitor requires the VIP address and the TOS ID to create an encoded value of the VIP address. The monitor creates probe packets in which the TOS field is set to the encoded value of the VIP address. It then sends the probe packets to the servers represented by the services of a load balancing configuration. With a large number of load balancing configurations, creating a separate custom TOS monitor for each configuration is a big, cumbersome task. Managing these TOS monitors is also a big task. Now, you can create wildcard TOS monitors. You need to create only one wildcard TOS monitor for all load balancing configurations that use the same protocol (for example, TCP or UDP).

A wildcard TOS monitor has the following mandatory settings:

-Type = <protocol>

-TOS = Yes

The following parameters can be set to a value or can be left blank:

-Destination IP

-Destination Port

-TOS ID

A wildcard TOS monitor (with destination IP, Destination port, and TOS ID not set) bound to a DSR service automatically learns the TOS ID and the VIP address of the load balancing virtual server. The monitor creates probe packets with TOS field set to the encoded VIP address and then sends the probe packets to the server represented by the DSR service.

In a cluster deployment of NetScaler appliances, you can use the new command "show prop status" for faster monitoring and troubleshooting of issues related to command-propagation failure on non-CCO nodes. This command displays up to 20 of the most recent command propagation failures on all non-CCO nodes. You can use either the NetScaler command line or the NetScaler GUI to perform this operation after accessing them through the CLIP address or through the NSIP address of any node in the cluster deployment.

To know more information about this feature, see http://docs.citrix.com/en-us/netscaler/11-1/clustering/cluster-managing/Monitoring-Command-Propagation-Failures-in-cluster-deployment.html

You can now configure a NetScaler appliance to send response traffic through an IP-IP tunnel instead of routing it back to the source. Previously, when the appliance received a request from another NetScaler or a third-party device through an IP-IP tunnel, it had to route the response traffic instead of sending it through the tunnel. You can now use policy based routes (PBRs) or enable MAC-Based Forwarding (MBF) to send the response through the tunnel.

In a PBR rule, specify the subnets at both end points whose traffic is to traverse the tunnel. Also set the next hop as the tunnel name. When response traffic matches the PBR rule, the NetScaler appliance sends the traffic through the tunnel.

Alternatively, you can enable MBF to meet this requirement, but the functionality is limited to traffic for which the NetScaler appliance stores session information (for example, traffic related to load balancing or RNAT configurations). The appliance uses the session information to send the response traffic through the tunnel.

Previously, a cluster node did not reset its existing TCP connections (to clients and servers) when its state became Inactive. As a result, the states of the client and server connections became undefined. Now, a node resets all its TCP connections before entering the Inactive state.

In a cluster deployment, when the client-side or server side-link to a node goes down, traffic is steered to this node through the peer nodes for processing. Previously, the steering of traffic was implemented on all nodes by configuring dynamic routing and adding static ARP entries pointing to the special MAC address of each node. If there are a large number of nodes in a cluster deployment, adding and managing static ARP entries with special MAC addresses on all the nodes is a cumbersome task. Now, nodes implicitly use special MAC addresses for steering packets. Therefore, static ARP entries pointing to special MAC addresses no longer have to be added to the cluster nodes.

The T1120 and T1300-40G platforms with NIC firmware 4.53 are now supported in this release.

Note: T1300-40G platform with NIC firmware 4.26 has backward compatibility.

You can now configure NetScaler VPX appliance deployed on VMware ESX 6.0 or ESX 5.5 to use VMXNET3 network interfaces. The NetScaler VPX appliance now supports Intel 82599 10g Network Interface Card (NIC).

For performance information of VMXNET3 interface on ESX, refer the latest VPX datasheet.

For information on how to configure VMXNET3 interfaces on NetScaler VPX appliance, see http://docs.citrix.com/en-us/netscaler/11-1/deploying-vpx/install-vpx-on-esx/configure-vmxnet3.html.

You can now configure NetScaler VPX appliance deployed on VMware ESX 6.0 or ESX 5.5 to use SR-IOV network interfaces. The NetScaler VPX appliance now supports Intel 82599 10g Network Interface Card (NIC).

For performance information of SR-IOV interface on ESX, refer the latest VPX datasheet.

For information on how to configure SR-IOV interfaces on NetScaler VPX Appliance, see http://docs.citrix.com/en-us/netscaler/11-1/deploying-vpx/install-vpx-on-esx/configure-sr-iov.html.

You can now configure NetScaler VPX appliance deployed on Linux-KVM to use SR-IOV network interfaces.

For performance information of SR-IOV interface on KVM, refer the latest VPX datasheet.

For information on how to configure SR-IOV interfaces on NetScaler VPX Appliance in Linux-KVM, see http://docs.citrix.com/en-us/netscaler/11-1/deploying-vpx/install-vpx-on-kvm/configure-SR-IOV-KVM.html.

The T1120 and T1300-40G platforms with NIC firmware 4.53 are now supported.

Note: T1300-40G platform with NIC firmware 4.26 is backward compatible.

NetScaler VPX on AWS cloud now supports IAM roles. IAM roles are designed for AWS applications to securely make API requests from their instances, without requiring users to manage the security credentials that the applications use. The user can define which accounts or AWS services can assume the roles. The application is granted the permissions for the actions and resources that the user has defined for the role through the security credentials associated with the role. An application on the instance retrieves the security credentials provided by the role from instance metadata item iam/security-credentials/role-name. These security credentials are temporary and are renewed automatically. New credentials are available at least five minutes before the expiration of the old credentials.

You can now configure a NetScaler VPX instance deployed on Linux-KVM to use PCI passthrough interfaces.

For performance information about PCI passthrough interfaces on KVM, see the latest VPX datasheet.

You can now configure a NetScaler VPX appliance deployed on XenServer to use SR-IOV network interfaces.

For performance information about SR-IOV interfaces on XenServer, see the latest VPX datasheet.

NetScaler SDX provides the latest XL710 v5.04 firmware for the following platforms:

* SDX Model: 14xxx 40G

* SDX Model: 25xxx 40G

The XL710 v5.04 firmware includes a tool to automatically upgrade the XL710 firmware from the previous version to v5.04.

For more information, see https://support.citrix.com/article/CTX218219.

The NetScaler MPX appliances with N3 chips now support the elliptical curve digital signature algorithm (ECDSA) cipher group. The ECDHE_ECDSA key exchange mechanism provides forward secrecy. In ECDHE_ECDSA, the server's certificate must contain an ECDSA-capable public key. For client authentication, an ECDSA CA certificate must be bound to the virtual server.

ECDSA cipher suites use elliptical curve cryptography (ECC). Because of its smaller size, it is particularly helpful in environments where processing power, storage space, bandwidth, and power consumption are constrained.

Note: if you add an ECDSA certificate-key pair, only the following curves are supported:

-prime256v1

-secp384r1

The NetScaler VPX appliance now supports AES-GCM/SHA2 ciphers on the front end.

Citrix NetScaler MPX 9700/10500/12500/15500 FIPS appliances running firmware version 2.2 now support the ECDHE cipher group on the back end. This group contains the following ciphers:

- TLS1_TXT_ECDHE_RSA_WITH_DES_192_CBC3_SHA 0xc012

- TLS1_TXT_ECDHE_RSA_WITH_AES_256_CBC_SHA 0xc014

- TLS1_TXT_ECDHE_RSA_WITH_AES_128_SHA256 0xc027

- TLS1_TXT_ECDHE_RSA_WITH_AES_128_CBC_SHA 0xc013

Because of its smaller key size, Elliptic Curve Cryptography (ECC) is especially useful in a mobile (wireless) environment and in an interactive voice response environment, where every millisecond is important. Smaller key sizes result in power, memory, bandwidth, and computational cost savings.

The following ECC curves are supported: P_256, P_384, P_224, and P_521.

By default, all four curves are bound to an SSL virtual server.

The NetScaler appliance now supports Server Name Indication (SNI) at the back end. That is, the common name is sent as the server name in the client hello to the back-end server for successful completion of the handshake. In addition to helping meet federal system integrator customer security requirements, this enhancement provides the advantage of using only one port instead of opening hundreds of different IP addresses and ports on a firewall.

Federal system integrator customer security requirements include support for Active Directory Federation Services (ADFS) 3.0 in 2012R2 and WAP servers. This requires supporting SNI at the back end on a NetScaler appliance.

To facilitate certificate selection, certificates are now segregated according to type, such as server certificate, client certificate, and CA certificate.

To view the certificates in the GUI, navigate to Traffic Management > SSL > Certificates.

To view the certificates in the CLI, type "show ssl certkey"

The NetScaler MPX appliances with N3 chips now support the elliptical curve digital signature algorithm (ECDSA) cipher group end to end. ECDSA cipher suites use elliptical curve cryptography (ECC). Because of its smaller size, it is particularly helpful in environments where processing power, storage space, bandwidth, and power consumption are constrained.

Note: if you add an ECDSA certificate-key pair, only the following curves are supported:

-prime256v1

-secp384r1

The following ciphers are supported with ECDSA:

-ECDHE-ECDSA-AES256-GCM-SHA384

-ECDHE-ECDSA-AES256-SHA384

-ECDHE-ECDSA-AES256-SHA

-ECDHE-ECDSA-AES128-GCM-SHA256

-ECDHE-ECDSA-AES128-SHA256

-ECDHE-ECDSA-AES128-SHA

-ECDHE-ECDSA-RC4-SHA

-ECDHE-ECDSA-DES-CBC3-SHA

For more information about ECDSA cipher suites, see http://docs.citrix.com/en-us/netscaler/11-1/ssl/customize-ssl-config/ecdsa_cipher_suite_support_on_mpx_appliances_with_n3_chips.html.

All NetScaler MPX, SDX, and VPX appliances except the MPX 9700/10500/12500/15500 FIPS appliances now support the SafeNet network hardware security module (HSM). A NetScaler ADC used with a SafeNet Network HSM provides FIPS 140-2 Level 2 and FIPS 140-2 Level 3 protection, depending on which SafeNet HSM is being used.

SafeNet HSM integration with the ADC is supported for TLS versions 1.0, 1.1, and 1.2.

For more information about configuring SafeNet network HSM, see http://docs.citrix.com/en-us/netscaler/11-1/ssl/ssl-support-safenet-hsm.html.

The NetScaler appliance now supports Server Name Indication (SNI) at the back end. That is, the common name is sent as the server name in the client hello to the back-end server for successful completion of the handshake. In addition to helping meet federal system integrator customer security requirements, this enhancement provides the advantage of using only one port instead of opening hundreds of different IP addresses and ports on a firewall.

Federal system integrator customer security requirements include support for Active Directory Federation Services (ADFS) 3.0 in 2012R2 and WAP servers. This requires supporting SNI at the back end on a NetScaler appliance.

For more information about SNI support on the back-end service, see http://docs.citrix.com/en-us/netscaler/11-1/ssl/config-ssloffloading/support_for_sni_on_backend_service.html.

The RC4-MD5 cipher is removed from the list of default ciphers that are supported on a NetScaler appliance.

For the updated list of ciphers supported by the NetScaler appliance, see http://docs.citrix.com/en-us/netscaler/11-1/ssl/supported-ciphers-list-release-11.html.

Citrix NetScaler MPX 9700/10500/12500/15500 FIPS appliances running firmware version 2.2 now support the ECDHE cipher group on the frontend and backend. This group contains the following ciphers:

- TLS1-ECDHE-RSA-DES-CBC3-SHA 0xc012

- TLS1-ECDHE-RSA-AES256-SHA 0xc014

- TLS1.2-ECDHE-RSA-AES-128-SHA256 0xc027

- TLS1-ECDHE-RSA-AES128-SHA 0xc013

Because of its smaller key size, Elliptic Curve Cryptography (ECC) is especially useful in a mobile (wireless) environment and in an interactive voice response environment, where every millisecond is important. Smaller key sizes result in power, memory, bandwidth, and computational cost savings.

The following ECC curves are supported: P_256, P_384, P_224, and P_521.

By default, all four curves are bound to an SSL virtual server.

For the updated cipher/protocol support matrix, see http://docs.citrix.com/en-us/netscaler/11-1/ssl/cipher_protocl_support_matrix.html.

The NetScaler appliance supports creating a CSR signed with the SHA256 digest algorithm. The encryption hash algorithm used in SHA256 makes it stronger than SHA1.

For more information about creating a CSR signed with the SHA256 digest algorithm, see http://docs.citrix.com/en-us/netscaler/11-1/ssl/manage-certs/obtain-cert-frm-cert-auth.html.

The NetScaler VPX appliance now supports AES-GCM/SHA2 ciphers on the front end.

For the updated cipher/protocol support matrix, see http://docs.citrix.com/en-us/netscaler/11-1/ssl/cipher_protocl_support_matrix.html.

The NetScaler MPX appliance now supports AES-GCM/SHA2 ciphers on the back end.

For the updated cipher/protocol support matrix, see http://docs.citrix.com/en-us/netscaler/11-1/ssl/cipher_protocl_support_matrix.html.

You can now bind ECC curves to back-end service groups by using the NetScaler command line.

At the command prompt, type:

bind ssl serviceGroup <serviceGroupName> -eccCurveName <eccCurveName>

Six counters have been added to the output of the "stat ssl vserver" command, as follows:

1. ssl_ctx_tot_enc_bytes: Tracks the number of encrypted bytes.

2. ssl_ctx_tot_dec_bytes: Tracks the number of decrypted bytes.

3. ssl_ctx_tot_hw_enc_bytes: Tracks the number of hardware encrypted bytes.

4. ssl_ctx_tot_hw_dec_bytes: Tracks the number of hardware decrypted bytes.

5. ssl_ctx_tot_session_new: Tracks the number of new sessions created.

6. ssl_ctx_tot_session_hits: Tracks the number of session hits.

Five counters have been added to the output of the "stat ssl -detail" command, as follows:

1. ssl_tot_sslServerInRecords: Tracks the number of SSL records processed by the appliance.

2. ssl_cur_sslInfo_SPCBInUseCount: Tracks the number of SSL protocol control blocks (SPCBs) used at any given point.

2. ssl_cur_session_inuse: Tracks the number of active SSL sessions.

4. ssl_cur_sslInfo_cardinBlkQ: Tracks the number of bulk encryption and decryption operations that are pending for card.

5. ssl_cur_sslInfo_cardinKeyQ: Tracks the number of handshake-related operations that are pending for card.

ECDHE-RSA computation has been optimized by using a combination of software and hardware offload capabilities.

For more information, see http://docs.citrix.com/en-us/netscaler/11-1/ssl/customize-ssl-config/ssl-hybrid-ecdhe-optimization.html.

The "start nstrace" command has a new parameter, -capsslkeys, with which you can capture the SSL master keys for all SSL sessions. If the capsslkeys option is enabled, a file named nstrace.sslkeys is generated along with the packet trace and imported into Wireshark to decrypt the SSL traffic in the trace file.

A new slow-start algorithm, Hybrid Start (Hystart) is configured as a TCP option in the relevant TCP profile bound to a virtual server. This algorithm dynamically determines a safe point at which to terminate (ssthresh) and enables a transition to avoid congestion with heavy packet losses. This option is disabled by default.

TCP Fast Open (TFO) is a TCP mechanism that enables speedy and safe data exchange between a client and a server during TCP's initial handshake. This feature is available as a TCP option in the TCP profile bound to a virtual server of a NetScaler appliance. TFO uses a TCP Fast Open Cookie (a security cookie) that the NetScaler appliance generates to validate and authenticate the client initiating a TFO connection to the virtual server. By using the TFO mechanism, you can reduce an application's network latency and the delay experienced in short TCP transfers.

In the NetScaler GUI, if you skip a mandatory field or make an invalid entry, an error message appears beside the field or in the page header, depending on the type of error, and remains until you enter a valid value. For example, on the Add Virtual Server page, if you enter an invalid server IP address or port number, an error message appears beside the IP Address or Port field, and you cannot submit the page until you correct the error.

You can now enable auto-bootstrapping on a NetScaler VPX or NetScaler 1000v instance running on Hyper-V, by attaching a DVD ROM with an appropriate ISO file to the instance before booting it up.

Bridge Group functionality is now supported on a Layer 3 NetScaler cluster.

The Citrix Call Home service automatically generates a support case and uploads the system data to the Technical Support server if a critical hardware error, such as failure of a hard disk drive (HDD), Compact Flash (CF) device, SSL card, or power supply unit (PSU), occurs in a NetScaler appliance on which the Call Home feature is enabled.

The Proportional Rate Recovery (PRR) algorithm is a fast recovery algorithm that evaluates TCP data during a loss recovery. It is patterned after Rate-Halving, by using the fraction that is appropriate for the target window chosen by the congestion control algorithm. It minimizes window adjustment, so that the actual window size at the end of recovery is close to the Slow-Start threshold (ssthresh).

The NetScaler GUI displays a Save icon with a red dot when a running configuration is not saved. A unsaved configuration could be lost if a power outage or restart occurs.

To save the configuration(s), you can click the Save icon and then click Yes at the configuration prompt. When you return to the main screen by clicking OK, the icon is white.

Note: In some cases, the red dot might appear even though there is no unsaved configuration. In that case, if you click the Save icon, the following message appears: "The running configuration has not changed."

After you enable the SNMP trap logging option, a NetScaler appliance on which at least one trap listener is configured can log SNMP trap messages (for SNMP alarms in which logging capability is enabled). Now, you can specify the audit log level of trap messages sent to an external log server. The default log level is Informational. Possible values are Emergency, Alert, Critical, Error, Warning, Debug, and Notice.

For example, you can set the audit log level to Critical for an SNMP trap message generated by a logon failure. That information is then available on the NSLOG or SYSLOG server for troubleshooting.

When you enable the Dynamic Receive Buffer option in a TCP profile, the NetScaler appliance can dynamically adjust the TCP receive buffer size for optimized memory usage based on the congestion window.

A new slow-start algorithm, Hybrid Start (Hystart) is configured as a TCP option in the relevant TCP profile bound to a virtual server. This algorithm dynamically determines a safe point at which to terminate (ssthresh) and enables a transition to avoid congestion with heavy packet losses. This option is disabled by default.

The "start nstrace" command has a new parameter, -capsslkeys, with which you can capture the SSL master keys for all SSL sessions. If the capsslkeys option is enabled, a file named nstrace.sslkeys is generated along with the packet trace and imported into Wireshark to decrypt the SSL traffic in the trace file.

An SNMP trap that is sent as a result of an IP address conflict now contains the MAC address of the device. You can therefore identify the device by its MAC address. Previously, identifying the device was not possible, because the conflict lasts for only a short time.

TCP Fast Open (TFO) is a TCP mechanism that enables speedy and safe data exchange between a client and a server during TCP's initial handshake. This feature is available as a TCP option in the TCP profile bound to a virtual server of a NetScaler appliance. TFO uses a TCP Fast Open Cookie (a cryptographic cookie) that the NetScaler appliance generates to validate the client initiating a TFO connection to the virtual server. By using the TFO mechanism, you can reduce an application's network latency and the delay experienced in short TCP transfers.

In a NetScaler appliance, if the Ring Receive buffer is full, the appliance starts to discard data packets at the Network Interface Card (NIC). As a result, the appliance drops packets leading to a probe failure.

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.

A NetScaler appliance now uses a technique called "TCP Burst Rate Control" for burst management in a high speed mobile network. This technique evenly spaces the flow of data into the network, avoiding bursts by waiting for a period of time before sending the next group of packets. By using this technique, you can achieve better throughput and lower packet drop rates. This feature is available as a TCP option in the TCP profile bound to a virtual server on a NetScaler appliance.

Audit log actions now support advance policies and expressions. Advance policy expressions are very powerful and provide endless use cases to work with. Previously, the audit module supported only classic policies. You can now bind advanced audit-log policies to the syslog and nslog global entities.

The TCP timestamp is now an interoperable parameter for TCP and Multipath TCP (MPTCP) data transmission.

Half-closed or established TCP connections, between clients and a NetScaler appliance, cleaned up by the NetScaler zombie process can now be dropped silently, that is, without sending RST packets to the clients.

To configure this feature, run the following commands at the NetScaler shell prompt:

- nsapimgr_wr.sh -ys tcp_hc_zombie_silent_drop=1

- nsapimgr_wr.sh -ys tcp_est_zombie_silent_drop=1

Logging LSN information is one of the important functions needed by ISPs to meet legal requirements and be able to identify the source of traffic at any given time. This eventually results in a huge volume of log data, requiring the ISPs to make large investments to maintain the logging infrastructure.

Compact logging is a technique for reducing the log size by using a notational change involving short codes for event and protocol names. For example, C for client, SC for session created, and T for TCP. Compact logging results in an average of 40 percent reduction in log size.

Compact logging is supported for NAT44, DS-Lite, and NAT64.

Currently, if a subscriber session is deleted when a RADIUS Accounting STOP or a PCRF-RAR message is received, or as a result of any other event, such as TTL expiry or flush, the corresponding LSN sessions of the subscriber are removed only after the configured LSN timeout period. LSN sessions that are kept open until this timeout expires continue to consume resources on the appliance.

This enhancement adds a new parameter (subscrSessionRemoval). If this parameter is enabled, and the subscriber information is deleted from the subscriber database, LSN sessions corresponding to that subscriber are also removed. If this parameter is disabled, the subscriber sessions are timed out as specified by the LSN timeout settings.

A static mapping entry is usually a one-to-one LSN mapping between a subscriber IP address:port and a NAT IP address:port. A one-to-one static LSN mapping entry exposes only one port of the subscriber to the Internet.

Some situations might require exposing all ports (64K) of a subscriber to the Internet (for example, a server hosted on an internal network and running a different service on each port). To make these internal services accessible through the Internet, you have to expose all the ports of the server to the Internet.

One way to meet this requirement is to add 64K one-to-one static mapping entries, one mapping entry for each port. Creating 64K entries is very cumbersome and a big task. Also, this large number of configuration entries might lead to performance issues in the NetScaler appliance.

Another simple method is to use wildcard ports in a static mapping entry. You just need to create one static mapping entry with NAT-port and subscriber-port parameters set to the wildcard character (*), and the protocol parameter set to ALL, to expose all the ports of a subscriber to the Internet. For a subscriber's inbound or outbound connections matching a wildcard static mapping entry, the subscriber's port does not change after the NAT operation.

Because of the imminent exhaustion of IPv4 addresses, ISPs have started transitioning to IPv6 infrastructure. But during the transition, ISPs must continue to support IPv4 along with IPv6, because most of the public Internet still uses IPv4. Large scale NAT64 is an IPv6 transition solution for ISPs with IPv6 infrastructure to connect their IPv6-only subscribers to the IPv4 Internet. DNS64 is a solution for enabling discovery of IPv4-only domains by IPv6-only clients. DNS64 is used with large scale NAT64 to enable seamless communication between IPv6-only clients and IPv4-only servers.

A NetScaler appliance implements large scale NAT64 and DNS64 and is compliant with RFCs 6145, 6146, 6147, 6052, 3022, 2373, 2765, and 2464.

The following lists some of the large scale NAT64 features supported on NetScaler appliance:

- ALGs. Support of application Layer Gateway (ALG) for SIP, RTSP, FTP, ICMP, and TFTP protocols.

- Deterministic/Fixed NAT. Support for pre-allocation of blocks of ports to subscribers to minimize logging.

- Mapping. Support of Endpoint-independent mapping (EIM), Address-dependent mapping (ADM), and Address-Port dependent mapping (APDM).

- Filtering. Support of Endpoint-Independent Filtering (EIF), Address-Dependent Filtering (ADF), and Address-Port-Dependent Filtering (APDF).

- Quotas. Configurable limits on number of ports, sessions per subscriber, and sessions per LSN group.

- Static Mapping. Support for manually defining a large scale NAT64 mapping.

- Hairpin Flow. Support for communication between subscribers or internal hosts using NAT IP addresses.

- 464XLAT connections. Support for communication between IPv4-only aware applications on IPv6 subscriber hosts and IPv4 hosts on the Internet through IPv6 network.

- Variable length NAT64 and DNS64 prefixes. The NetScaler appliance supports defining NAT64 and DNS64 prefixes of lengths of 32, 40, 48, 56, 64, and 96.

- Multiple NAT64 and DNS64 prefix. The NetScaler appliance supports multiple NAT64 and DNS64 prefixes.

- LSN Clients. Support for specifying or identifying subscribers for large scale NAT64 by using IPv6 prefixes and extended ACL6 rules.

- Logging. Support for logging NAT64 sessions for law enforcement. In addition, the following are also supported for logging.

-- Reliable SYSLOG. Support for 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 reduce the large scale NAT64 log volume.

-- Logging MSISDN information. Support for including subscribers' MSISDN information in large scale NAT64 logs to identify and track subscriber activity over the Internet.

NetScaler appliances now support Port Control Protocol (PCP) for large scale NAT (LSN). Many of an ISP's subscriber applications must be accessible from Internet (for example, Internet of Things (IOT) devices, such as an IP camera that provides surveillance over the Internet). One way to meet this requirement is to create static large scale NAT (LSN) maps. But for a very large number of subscribers, creating static LSN NAT maps is not a feasible solution.

Port Control Protocol (PCP) enables a subscriber to request specific LSN NAT mappings for itself and/or for other 3rd party devices. The large scale NAT device creates an LSN map and sends it to the subscriber. The subscriber sends the remote devices on the Internet the NAT IP address:NAT port at which they can connect to the subscriber.

Applications usually send frequent keep-alive messages to the large scale NAT device so that their LSN mappings do not time out. PCP helps reduce the frequency of such keep-alive messages by enabling the applications to learn the timeout settings of the LSN mappings. This helps reduce bandwidth consumption on the ISP's access network and battery consumption on mobile devices.

PCP is a client-server model and runs over the UDP transport protocol. A NetScaler appliance implements the PCP server component and is compliant with RFC 6887. Port Control Protocol is supported for NAT44, DS-Lite and NAT64 on the NetScaler appliance.

Currently, if a subscriber session is deleted when a RADIUS Accounting STOP or a PCRF-RAR message is received, or as a result of any other event, such as TTL expiry or flush, the corresponding LSN sessions of the subscriber are removed only after the configured LSN timeout period. LSN sessions that are kept open until this timeout expires continue to consume resources on the appliance.

This enhancement adds a new parameter (subscrSessionRemoval). If this parameter is enabled, and the subscriber information is deleted from the subscriber database, LSN sessions corresponding to that subscriber are also removed. If this parameter is disabled, the subscriber sessions are timed out as specified by the LSN timeout settings.

For more information about subscriber aware LSN session termination, see http://docs.citrix.com/en-us/netscaler/11-1/netscaler-support-for-telecom-service-providers/lsn-telco-subscriber-management.html.

A static mapping entry is usually a one-to-one LSN mapping between a subscriber IP address:port and a NAT IP address:port. A one-to-one static LSN mapping entry exposes only one port of the subscriber to the Internet.

Some situations might require exposing all ports (64K) of a subscriber to the Internet (for example, a server hosted on an internal network and running a different service on each port). To make these internal services accessible through the Internet, you have to expose all the ports of the server to the Internet.

One way to meet this requirement is to add 64K one-to-one static mapping entries, one mapping entry for each port. Creating 64K entries is very cumbersome and a big task. Also, this large number of configuration entries might lead to performance issues in the NetScaler appliance.

Another simple method is to use wildcard ports in a static mapping entry. You just need to create one static mapping entry with NAT-port and subscriber-port parameters set to the wildcard character (*), and the protocol parameter set to ALL, to expose all the ports of a subscriber to the Internet. For a subscriber's inbound or outbound connections matching a wildcard static mapping entry, the subscriber's port does not change after the NAT operation. For more information, see http://docs.citrix.com/en-us/netscaler/11-1/netscaler-support-for-telecom-service-providers/lsn-introduction/configuring-static-lsn-maps.html.

Logging LSN information is one of the important functions needed by ISPs to meet legal requirements and be able to identify the source of traffic at any given time. This eventually results in a huge volume of log data, requiring the ISPs to make large investments to maintain the logging infrastructure.

Compact logging is a technique for reducing the log size by using a notational change involving short codes for event and protocol names. For example, C for client, SC for session created, and T for TCP. Compact logging results in an average of 40 percent reduction in log size. Compact logging is supported for NAT44, DS-Lite, and NAT64. For more information, see:

- http://docs.citrix.com/en-us/netscaler/11-1/netscaler-support-for-telecom-service-providers/lsn-nat-64/log-monitor-largescale-nat64.html

- http://docs.citrix.com/en-us/netscaler/11-1/netscaler-support-for-telecom-service-providers/dual-stack-lite/logging-monitoring-DS-Lite.html

- http://docs.citrix.com/en-us/netscaler/11-1/netscaler-support-for-telecom-service-providers/lsn-introduction/lsn-logging-monitoring.html

NetScaler appliances now support Port Control Protocol (PCP) for large scale NAT (LSN). Many of an ISP's subscriber applications must be accessible from Internet (for example, Internet of Things (IOT) devices, such as an IP camera that provides surveillance over the Internet). One way to meet this requirement is to create static large scale NAT (LSN) maps. But for a very large number of subscribers, creating static LSN NAT maps is not a feasible solution.

Port Control Protocol (PCP) enables a subscriber to request specific LSN NAT mappings for itself and/or for other 3rd party devices. The large scale NAT device creates an LSN map and sends it to the subscriber. The subscriber sends the remote devices on the Internet the NAT IP address:NAT port at which they can connect to the subscriber.

Applications usually send frequent keep-alive messages to the large scale NAT device so that their LSN mappings do not time out. PCP helps reduce the frequency of such keep-alive messages by enabling the applications to learn the timeout settings of the LSN mappings. This helps reduce bandwidth consumption on the ISP's access network and battery consumption on mobile devices.

PCP is a client-server model and runs over the UDP transport protocol. A NetScaler appliance implements the PCP server component and is compliant with RFC 6887. Port Control Protocol is supported for NAT44, DS-Lite and NAT64 on the NetScaler appliance. For more information, see:

- http://docs.citrix.com/en-us/netscaler/11-1/netscaler-support-for-telecom-service-providers/lsn-introduction/port-control-protocol-large-scale-NAT.html

- http://docs.citrix.com/en-us/netscaler/11-1/netscaler-support-for-telecom-service-providers/dual-stack-lite/port-control-protocol-DS-Lite.html

- http://docs.citrix.com/en-us/netscaler/11-1/netscaler-support-for-telecom-service-providers/lsn-nat-64/port-control-protocol-largescale-nat64.html

The global override LSN parameter has been removed from L3 parameters. To override LSN, you must now create a net profile with the overrideLsn parameter enabled and bind this profile to all the load balancing virtual servers that are configured for value added services. For more information, see http://docs.citrix.com/en-us/netscaler/11-1/netscaler-support-for-telecom-service-providers/lsn-introduction/override-lsn-configuration-lb-configuration.html.

You can now configure the NetScaler appliance to perform TCP optimization based on subscriber attributes. For example, the appliance can now select different TCP profiles at run time, based on the network to which the user equipment (UE) is connected. As a result, you can improve a mobile user's experience by setting some parameters in the TCP profiles and then using policies to select the appropriate profile.

For more information about policy-based TCP profile, see http://docs.citrix.com/en-us/netscaler/11-1/netscaler-support-for-telecom-service-providers/lsn-telco-subscriber-management.html.

The NetScaler appliance now supports SIP and RTSP application layer gateways (ALGs) for DS-Lite. For more information, see:

- http://docs.citrix.com/en-us/netscaler/11-1/netscaler-support-for-telecom-service-providers/dual-stack-lite/AGL-DS-Lite.html

- http://docs.citrix.com/en-us/netscaler/11-1/netscaler-support-for-telecom-service-providers/lsn-nat-64/configuring-agl-large-scale-NAT64.html

Because of the imminent exhaustion of IPv4 addresses, ISPs have started transitioning to IPv6 infrastructure. But during the transition, ISPs must continue to support IPv4 along with IPv6, because most of the public Internet still uses IPv4. Large scale NAT64 is an IPv6 transition solution for ISPs with IPv6 infrastructure to connect their IPv6-only subscribers to the IPv4 Internet. DNS64 is a solution for enabling discovery of IPv4-only domains by IPv6-only clients. DNS64 is used with large scale NAT64 to enable seamless communication between IPv6-only clients and IPv4-only servers.

A NetScaler appliance implements large scale NAT64 and DNS64 and is compliant with RFCs 6145, 6146, 6147, 6052, 3022, 2373, 2765, and 2464.

The following lists some of the large scale NAT64 features supported on NetScaler appliance:

- ALGs: Support of application Layer Gateway (ALG) for SIP, RTSP, FTP, ICMP, and TFTP protocols.

- Deterministic/Fixed NAT: Support for pre-allocation of blocks of ports to subscribers to minimize logging.

- Mapping: Support of Endpoint-independent mapping (EIM), Address-dependent mapping (ADM), and Address-Port dependent mapping (APDM).

- Filtering: Support of Endpoint-Independent Filtering (EIF), Address-Dependent Filtering (ADF), and Address-Port-Dependent Filtering (APDF).

- Quotas: Configurable limits on number of ports, sessions per subscriber, and sessions per LSN group.

- Static Mapping: Support for manually defining a large scale NAT64 mapping.

- Hairpinning Flow: Support for communication between subscribers or internal hosts using NAT IP addresses.

- 464XLAT connections: Support for communication between IPv4-only aware applications on IPv6 subscriber hosts and IPv4 hosts on the Internet through IPv6 network.

- Variable length NAT64 and DNS64 prefixes: The NetScaler appliance supports defining NAT64 and DNS64 prefixes of lengths of 32, 40, 48, 56, 64, and 96.

- Multiple NAT64 and DNS64 prefix: The NetScaler appliance supports multiple NAT64 and DNS64 prefixes.

- LSN Clients: Support for specifying or identifying subscribers for large scale NAT64 by using IPv6 prefixes and extended ACL6 rules.

- Logging: Support for logging NAT64 sessions for law enforcement. In addition, the following are also supported for logging.

-- Reliable SYSLOG: Support for 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 reduce the large scale NAT64 log volume.

-- Logging MSISDN information: Support for including subscribers' MSISDN information in large scale NAT64 logs to identify and track subscriber activity over the Internet.

For more information, see http://docs.citrix.com/en-us/netscaler/11-1/netscaler-support-for-telecom-service-providers/lsn-nat-64.html

The NetScaler appliance can now log request header information of an HTTP connection that is using the NetScaler's DS-Lite functionality. The HTTP header logs can be used by ISPs to see the trends related to the HTTP protocol among a set of subscribers. For example, an ISP can use this feature to find out the most popular website among a set of subscribers. For more information, see http://docs.citrix.com/en-us/netscaler/11-1/netscaler-support-for-telecom-service-providers/dual-stack-lite/logging-monitoring-DS-Lite.html.

In a high availability setup, a session does not time out even if a force timeout is configured on a traffic action that is bound to a load balancing or content switching virtual server and a force fail over is performed.

The StoreFront FQDN is not accepted as valid when a user uses it for the Test Connection function in the XA/XD Wizard. After the StoreFront FQDN is entered, the XA/XD Wizard displays an error when the user clicks Continue.

In a multi-core NetScaler environment, user sessions sometimes do not get terminated if the decision to terminate is based on a force timeout value that is configured on a TM traffic action.

SNMP profiles have been modified to avoid dropping SNMP responses intended for non-default partitions. An SNMP agent can now track each SNMP request and send a response to a non-default partition. Previously, if a non-default partition received an SNMP request through a subnet IP address, the SNMP agent on the partition responded to the default partition, because the SNIP address was defined on the default partition.

If you have configured NetScaler Gateway in a double-hop setup, HDX virtual desktops might become unresponsive when you perform the following sequence of actions: connect, disconnect and reconnect.

If HDX Insight is enabled on a NetScaler appliances in high-availability mode, and if the nodes are set to STAY PRIMARY or STAY SECONDARY, session reliability fails when a failover happens.

ICA parsing uses a lot of memory, so the NetScaler appliance reaches its memory limit with a lower than expected number of connections.

If AppFlow for ICA is enabled on a NetScaler appliance, the appliance might become unresponsive under certain circumstances during ICA capability negotiation in ICA PROXY mode.

When AppFlow for ICA is enabled on a NetScaler appliance in a multicore environment, the Netscaler appliance might become unresponsive.

If AppFlow clientside measurements are enabled, NetScaler instance does not buffer the response packets even though it acknowledges the packet to the server. This will cause page load issues if the packets are lost.

Applications do not launch when AppFlow is enabled and connection chaining is disabled. This is because when a full sized packet is received, the connection chain ID is added to the packet resulting in the size of packet going beyond the maximum transmission unit (MTU). So, the packet gets dropped and the application fails to launch.

If AppFlow clientside measurements and AppFirewall are enabled, due to incomplete and incorrect order of the restore/cleanup of AppFlow and AppFirewall feature, NetScaler might become unresponsive.

A NetScaler load balanced server responds with a 411 error code for a corrupted HTTP request.

Automatic client reconnection (ACR) for Linux VDA clients fails if the NetScaler appliance is in the path and ICA AppFlow is enabled for the appliance.

When Web Insight is enabled, and if the configuration has wild card virtual servers, the NetScaler appliance might become unresponsive when writing the appflow records.

The NetScaler appliance fails if the signature match function accesses invalid memory while matching signature rules.

The exported, learned data for field formats does not match the output of the following command: sh appfw learning data.

Sites that use the NetScaler application firewall have excessive high availability failovers because of a faulty error-handling routine related to memory allocation.

Applications might not load properly when the memory_max_allowed value for the AppFW pool is low. This low memory condition can also cause memory allocation errors that result in numerous connection resets.

If the HTML response page contains a pair of hyphens (--) in the comment tag, the NetScaler appliance might parse the response page incorrectly and not add the URLs to starturl closure. This could result in some starturl violations.

The name of a user defined signature objects must not contain a hash character (#), even though the feedback message inaccurately lists it as an allowed character.

The NetScaler appliance might fail if both of the following conditions are met:

- The application firewall and compression modules are both active for a connection.

- The connection is aborted for any reason, such as connection failure on the client or server, or invalid HTTP content is received from the client or server.

Typically, the application firewall and compression modules free the resources, including references to the connection. However, in rare cases, freeing a connection results in a dangling connection structure pointer or duplicate freeing of the structure pointer. In either of these cases, the appliance might fail.

If the NetScaler appliance sends AppFlow data with application firewall records to the Security Insight collector, the appliance might fail. This might occur if the built-in NOPOLICY policy, which does not have any specified action, is configured as a global policy.

A NetScaler AppFirewall appliance might run out of memory, because firewall sessions might not get cleaned up in a high availability environment if sync or propagation is disabled or the software versions running on a pair of nodes do not match. This is due to DHT not being able to clean up entries properly.

A NetScaler appliance fails under the following set of conditions:

- The appliance is configured to log for parsing errors in XML responses, and the configuration includes a confidential field. Webform fields can be designated as confidential fields to protect the information that users type into them.

- The appliance receives a request in which query parameters are set.

- A parsing error occurs during processing of the XML response.

If the NetScaler appliance sends AppFlow data with application firewall records to the Security Insight collector, the appliance might fail. This might occur if the built-in NOPOLICY policy, which does not have any specified action, is configured as a global policy.

A NetScaler appliance in a high availability configuration might fail when the Application Firewall HTTP request is chunked or the chunk-header information is split across the packet and the content-type is "application/x-www-form-urlencoded" and "multipart/form-data".

If a load balancing server is trying to synchronize its states, occasionally one or more cluster nodes might get stuck in a Service state. As a result, the other nodes in the cluster might be unavailable, which leads to an improper cluster formation.

The NetScaler appliance might fail if you change the target of a content switching policy action from virtual server based to expression based.

A clear config operation in a Cluster deployment does not set non-CCO nodes to the default value for the "max pipeline" parameter.

A NetScaler appliance configured as an DNS end resolver sometimes fails to respond to DNS queries. When the appliance is configured as an end resolver, it generates iterative DNS queries to name servers on behalf of the client and returns the final responses. If a DNS zone has multiple NS records, the appliance queries the first name server in the NS record. If this resolution fails, the appliance does not retry with other name servers in the NS records, and it does not send any response to the client.

In a GSLB setup, if you have configured static proximity as the primary load balancing method and RTT as the backup load balancing method, the NetScaler appliance might intermittently send an empty response to a DNS query requesting the GSLB domain.

The NetScaler appliance fails to send an assertion back to the service provider when the SAML request comes without an ID field. When behaving as a samlidp, the ID field from the authnReq is remembered, so it can be sent back in the assertion. If service providers don't send IDs, we fail due to logic error. The logic was revised so if we don not get an ID, we don't send it back.

In the SAML response, the RelayState field is truncated. When the samlidp feature is processed, the URL decodes the entire content before parsing for individual elements. The customer's service provider sends the RelayState that was encoded. When the service provider posts the assertion back, the RelayState is truncated resulting in an SP failure.

A secure HTTP-ECV monitor might time out if the back-end server sends a large certificate.

In a high availability (HA) setup, after a forced HA synchronization, the configuration is first cleared and then reapplied on the secondary node. As part of the synchronization operation, the service state changes are logged in the ns.log file. Repeated forced synchronizations can flood the ns.log file. However, the service state messages are applicable only to the primary node and not relevant to the secondary node. Therefore, these messages are not logged in the ns.log file on the secondary node.

If the same IP address is assigned to both a GSLB service and a load balancing virtual server, the NetScaler appliance dumps core and restarts, because the internal service weight is set to zero.

AppFlow for ICA, Integrated Disk Caching, Delta Compression features should not be listed under "System->Licenses" section in the NetScaler Configuration Utility.

When creating a cluster node group, you no longer have to specify a node state. The "Add Node Group" page in the NetScaler GUI displays "state" as optional, not as a required field.

Page Navigation: Configuration > System >Cluster > NodeGroup > Add Node Group

If you have configured static proximity as the load balancing method on a load balancing virtual server, you cannot set a backup method by using the GUI.

On a NetScaler SDX appliance, the selected order of external authentication servers for cascading authentication might change in the NetScaler GUI if you randomly switch views. This is a display issue.

In Security > AAA > Virtual Servers, you can now bind an SSL profile to a virtual server.

In NetScaler Gateway > Policies > RDP, an attempt to enable and disable the RDP feature now succeeds.

The NetScaler GUI displays exponent 3 and key size 1024 when you try to create a FIPS key, but these options are not supported.

Also, you cannot create a key of size 3072 from the GUI.

In NetScaler Gateway > Policies > RDP, you can now enable and disable the RDP feature. A regression caused this option to break. This issue is fixed now.

SSL GSLB services are configured on port 443. However, if you try to edit the service by using the NetScaler GUI, port 80 appears instead of 443. This was a display issue and is fixed.

The field value for X-Forwarded-For HTTP header is not displayed as client IP in NetScaler Security Insight violation logs.

If you try to bind a default load balancing virtual server to a content switching virtual server in an admin partition, the following error message appears:

Operation not permitted.

If a client machine with the following configuration is on the Internet when it enters the logged-off state, its network access remains blocked if it is moved to an intranet:

*A location-based VPN is set to REMOTE.

*Network access upon VPN failure is set to onlyToGateway.

If the LDAP bind account password used on NetScaler contains a pair of dollar signs"$$", the authentication for the bind account fails, and the dashboard shows that the LDAP server is down.

Single sign-on (SSO) users connected to a VPN virtual server configured for SAML authentication cannot log off if Shibboleth is the SAML identity provider (IDP). Instead of the logoff page, an HTTP error message appears. This failure occurs with the following configuration:

* VPN virtual server is configured for SAML authentication.

* Shibboleth is the SAML identity provider (IDP).

For Windows 7 in English, Espanol, or Francaise, the NetScaler Gateway plug-in truncates the Add button on the Connection tab if the browser is Internet Explorer 8.

Build 47.14 of the Enterprise Edition does not support the RDP Proxy feature. (This issue does not apply to the Platinum Edition).

If DNS Truncate configuration is used, all the DNS suffixes are pushed from the NetScaler appliance, but not all of the DNS suffixes are used by the AGEE Client.

Functionality issues were present if the following do not have a trailing slash:

- The VPN URLs are of the Selfauth/Samlauth type

- The relay state is evaluated from the SAMLSSO Profile

- The relay state is sent from the IDP to the SAML SP case

User access to servers might be erratic, and users might lose information if step-up authentication is configured to begin or end with a SAML action.

If the NetScaler Gateway appliance is configured for End Point Analysis (EPA) and the user has bookmarked the advanced login page (/logon/LogonPoint/tmindex.html), attempts to log on fail.

Users cannot access the RfWebUI homepage if wiHome in the session action points to a load balancing virtual server.

If RfWebUI or a VPN portal theme with RfWebUI as the base theme is bound at the VPN Global level, users cannot connect to VPN virtual servers that are configured with a non-RfWebUI theme.

Kerberos authentication can fail, and the connection might be dropped, if consumption of AAA session memory is very high. In a high availability setup, a failover might occur.

The NetScaler appliance fails whenever a Content Switching VIP is accessed with IP 154.2.78.13.

If Certificate Authentication with Two Factor ON is chosen, and username extraction from Certificate has been configured, the username field is editable with old Portal Themes (Default, Greenbubble, X1).

The console shows many IPv4 Socks errors that are constantly being generated.

POST EPA scans fail on Windows 8 and 8.1 machines. This problem no longer occurs, because OPSWAT revised the OESIS 3 library.

A control channel between a NetScaler Gateway Plug-in and a NetScaler appliance is terminated if multicast IP packets are tunneled over the control channel.

The Citrix virtual adapter is not enabled on a Windows 7 64-bit machine, and its driver is shown as unsigned in the device manager.

Note: If a Windows 7 64-bit user is logged out immediately after logging in, install security patch KB3033929 on that user's Windows machine.

If only nFactor certificate authentication is configured for NetScaler Gateway, a VPN session is created instead of a traffic management (TM) session for access to a load balancing virtual server.

A safety check was created for incomplete/invalid homepage URLs. The safety check redirects the user to the correct homepage based on the Portal theme. The URL redirects to the correct homepage only when a valid homepage request is received; otherwise, the server sends back a 404 error message.

If SSO is enabled on an AAA-TM or Gateway configuration, the NetScaler appliance might fail.

Mac OSX users are unable to sign on to the OSX Receiver client and are denied access to their apps and desktops.

The NetScaler appliance fails because of a NetScaler packet processing engine (PPE) error.

For SmartControl to work, the Gateway login is required on the NetScaler appliance enforcing SmartControl. Storefront's session timeout causes automatic disconnections of ICA sessions launched through NetScaler Gateway if the ICA Smart Control policy is bound to the VPN virtual server. This requirement is now relaxed.

If you connect to NetScaler Gateway by using full tunnel VPN and attempt to access an internal URL that has Kerberos authentication enabled, the authentication fails. You are directed to the authentication screen and prompted for username and password.

When used for debugging, Internet Explorer issues 404 errors related to fonts because the NetScaler 11.1 landing page uses the Times New Roman font instead of Citrix Sans in the area where user name and password are displayed.

The NetScaler appliance fails if it tries to clean up the control channel between the NetScaler Gateway plugin and the NetScaler appliance at a time when memory usage is high.

Global Server Load Balancing (GSLB) HTTP cookie based persistence does not work with NetScaler Gateway SSL VPN clients when the site prefix is a substring of a GSLB domain.

The NetScaler appliance fails when it attempts to send traffic to an SSL back end through a forward proxy in cvpn/securebrowse mode.

If a NetScaler appliance is used to load balance SharePoint servers with AAA-TM, then an upgrade to the office 2016 suite on the client device causes failures during inline editing of the documents.

A NetScaler appliance might periodically restart after an upgrade if the deployment uses STA servers and, during the upgrade, the administrator's browser is closed while the appliance is communicating with a STA server.

Processing IPv6 packets on a MUX channel while the feature is disabled leads to a device failure.

The Citrix virtual adapter is not enabled on a Windows 7 64-bit machine, and its driver is shown as unsigned in the device manager.

Note: If a Windows 7 64-bit user is logged out immediately after logging in, install security patch KB3033929 on that user's Windows machine.

If AD/LDAP authentication is configured to communicate on SSL channel in authentication actions, under heavy login load, Gateway portal results in blank pages.

After an upgrade to NetScaler release 11.0 build 66.11nc, Microsoft Surface PRO 4 Laptops users connected to a WI-FI network have issues when connecting to NetScaler Gateway.

Microsoft Office 2016 documents trigger authentication prompts when using SSO Sharepoint with the NetScaler Gateway appliance.

If the NetScaler appliance is used as a SAML Service Provider to support the IBM Tivoli Identity Provider, the SAML assertion verification fails. SAML assertion verification failures occur after upgrading to version 11.0.

System groups cannot be created in the NetScaler Insight Center GUI.

AppFlow configuration fails if you use the NetScaler Insight Center FQDN instead of the NetScaler Insight Center IP address.

For a NetScaler appliance in multicore setup, reports from all cores were not getting generated except "0" core.

When you use LDAP for external authentication, you will receive a "Error: Resource does not exist" error message when you click Configuration tab.

If the RelayState value in a SAML Authentication request is more than 512 bytes but less than 1024 bytes, the SAML IdP server causes buffer overrun when sending an assertion after successful authentication.

If you deploy NetScaler VPX on Azure in HA mode, the VPN virtual servers on the secondary node are not reachable after a failover. This is because, during a synchronization operation, the NSIP address of the primary node is used to create the virtual server on the secondary node. After a failover, when the secondary node becomes the new primary, the VPN virtual server has the NSIP address of the old primary.

In a KVM environment, a NetScaler VPX instance fails to start if you have configured more than 11 vCPUs.

A NetScaler VPX instance might stop responding and dump core memory if you allocate a large disk size for log messages. The higher the rate of log messages, the more quickly the instance runs out of memory and fails.

A NetScaler appliance with OSPFv3 dynamic routing protocol configured might measure the length of OSPFv3 LSA packets in Network Byte Order instead of Host Byte Order for comparison with the minimum required packet length. As a result, the NetScaler appliance becomes unresponsive.

During a "force sync" operation in a cluster deployment, performing a "save config" operation on a node might lead to a full or partial configuration loss on that node. With this fix, the "save config" operation is not permitted during a "force sync" operation.

You can bind ECDSA ciphers to an SSL virtual server on a platform that does not have N3 chips even though ECDSA ciphers are supported only on platforms with N3 chips.

Adding a certificate revocation list (CRL) on the NetScaler appliance fails with the error message "Certificate Issuer Mismatch" for a DER certificate, and with the error message "Invalid CRL" for a PEM certificate. This issue occurs because the attribute type of the common name field is different for the CA certificate than for the CRL.

A certificate-key pair bound to a secure monitor is not saved in the configuration file (ns.conf). As a result, the binding is lost after you restart the appliance.

Client authentication causes memory leak if a client sends a certificate that includes its intermediate CA certificates. This exhausts memory on the NetScaler appliance.

A NetScaler virtual appliance sometimes fails because of a memory leak if you use GCM-based ciphers on a VPX appliance. The ciphers can eventually exhaust memory, causing the appliance to fail if the memory exhaustion error is not gracefully handled.

TLS handshake fails if client authentication is set to mandatory.

In a cluster setup, if you rename a load balancing virtual server of type SSL, the local database table that is used for all GET operations is not updated.

On a NetScaler MPX appliance, an SSL handshake that uses NULL ciphers fails on both the front end and the back end.

The CPU parameter value on the LCD panel does not match the value reported by the NetScaler CLI or GUI.

Heavy traffic through a NetScaler appliance can result in a web log buffer overrun, causing a NetScaler Web logging (NSWL) client to reconnect. When the client reconnects, the use of surplus connections results in omission of the PCB's user-name information (part of connection related information) during cloning. This leads to a loss of log data.

Memory allocation failures occur, because the NetScaler appliance does not allocate sufficient memory for packet engines.

If NetScaler appliance is setup with Web Log feature and weblog clients are connected then under traffic stress, a buffer overrun can cause the weblog client to reconnect. When the clients reconnect, we lose part of the data on connections where reconnect was triggered and hence log data is not complete.

The Configd daemon fails if the number of session IDs exceeds the preset limit and existing client sessions are renumbered.

On a NetScaler appliance, if a FIN packet is held back by the forwarding interface and in the meantime, if Selective Acknowledgement (SACK) blocks are generated for the previous packet, the appliance fails.

A NetScaler appliance might become unresponsive if it has a TCP profile with the TCP keepalive option enabled and is bound to a load balancing virtual server. The cause is an interoperability issue between the TCP keepalive and TCP packet retransmission functionalities.

On a NetScaler appliance, if a FIN packet is held back by the forwarding interface and in the meantime, if Selective Acknowledgement (SACK) blocks are generated for the previous packet, the appliance fails.

NetScaler appliance crashes when a large host-name header is received and AppFlow logging for host-name and domain-name is enabled.

A NetScaler appliance fails if a TCP/IP session is simultaneously reused for TCP and Multipath TCP (MPTCP) operation and not mutually exclusive with TCP KeepAlive enabled for MPTCP subflows.

Syslog analysis is affected if the date/month format in a syslog message is not a user configured timestamp. This issue occurs if the Syslogaction uses the default date format (MM/DD/YYYY) instead of a user defined data format.

In a NetScaler appliance, if there is an incoming TCP traffic from Wireless VLANs, the appliance routes the data packets to an IP router but now the appliance performs Policy Based Routing (PBR) to route the data packets based on incoming packet parameters, such as VLAN, MAC address, Interface, SRCIP, SRCPort, destination IP address, and destination port, to different routers through configured VLANs.

The initial probe connection that a NetScaler appliance makes with the back-end internet server to check for server availability is now reusable for actual server connection with internet server.

If a FASTCLOSE packet from a NetScaler appliance to a client is lost, the multipath TCP (MPTCP) session does not notify the application about the abrupt connection closure and close the socket. As a result, the appliance does not retransmit the lost packet.

When page tracking is enabled on an AppFlow, the NS_ESNS cookie is inserted into the response being served from the cache. The extra bytes added to the response are not accounted internally and so, when the ACK is received for those extra bytes, NetScaler crashes.