Domain Controller (LDAPS) Load Balancing – NetScaler 11.1

July 2, 2016, 5:25 am

≫ Next: NetScaler Gateway 11.1 LDAP Authentication

≪ Previous: StoreFront Load Balancing – NetScaler 11.1

Navigation

Overview

If you plan to use LDAP (Active Directory) for NetScaler Gateway or NetScaler management authentication, load balance the Domain Controllers that are used for authentication.

An alternative to load balancing is to configure NetScaler Gateway and NetScaler management authentication with multiple authentication policies, each pointing to a single Domain Controller. However, NetScaler will try each authentication policy until it finds one that works. If the user enters a wrong password and if you have three authentication policies pointing to different Domain Controllers in the same domain then three different failure attempts will be recorded thus causing premature account lockout. Use Load Balancing to avoid this behavior.

This page details LDAPS, aka Secure LDAP. This protocol requires certificates to be installed on the Domain Controllers. When a user’s password expires, Active Directory does not allow password changes over clear text LDAP so LDAPS must be used instead. Make sure you have certificates installed on your Domain Controllers. The easiest way to accomplish that is to deploy a Microsoft Certificate Authority. Once that’s done the Domain Controllers will request certificates automatically.

An ldaps monitor can be used to verify that the Domain Controller is functional. The ldaps monitor will login as an account, perform an LDAP query, and look for a successful response. The ldaps monitor uses a service account to login. Make sure the service account’s password does not expire. Domain User permissions are sufficient. Since this monitor is a Perl script, it uses NSIP as the source IP.

If you have Domain Controllers in multiple datacenters, you can create multiple load balancing Virtual Servers and cascade them so that the local Domain Controllers are used first, and if they’re not available, then the Virtual Server fails over to Domain Controllers in remote datacenters.

The Load Balancing Virtual Server for LDAPS can be TCP or SSL_TCP:

If the protocol is TCP, then SSL-encrypted LDAP traffic is not terminated on the NetScaler, and is simply forwarded to the LDAP servers. If your LDAP client needs to verify the LDAP server certificate, then this Load Balancing configuration will not work, since each back-end LDAP server will have a different certificate.
If your Load Balancing Virtual Server is protocol SSL_TCP, then a certificate must be installed on the NetScaler and bound to the Load Balancing Virtual Server. SSL is terminated at the NetScaler and re-encrypted before sending it to the destination Domain Controller. The primary benefit of NetScaler SSL termination is that your LDAP clients can verify the Virtual Server SSL certificate.

When NetScaler uses a local (same appliance) load balanced Virtual Server for LDAPS authentication, the traffic is sourced from the NetScaler SNIP (Subnet IP). When NetScaler uses a direct connection to a Domain Controller without going through a local Load Balancing Virtual Server, or if NetScaler uses a remote (different appliance) Load Balancing VIP, then the traffic is sourced from the NetScaler NSIP (NetScaler IP). Adjust firewall rules accordingly.

LDAPS Monitor

Note: Perl monitor uses NSIP as the source IP.

In the NetScaler Configuration Utility, expand Traffic Management, expand Load Balancing, and click Monitors.
On the right, click Add.
Name the monitor ldaps-Corp or similar. The ldaps monitor logs into Active Directory, performs an LDAP query, and looks for a successful response. The monitor configuration has domain specific information so if you have multiple Active Directory domains, then you will need multiple ldaps monitors. Include the domain name in the monitor name.
Change the Type to LDAP.
Scroll down and check the box next to Secure.
Scroll back up and switch to the Special Parameters tab.
On the Special Parameters tab, use the Script Name drop-down list to select the nsldap.pl file.
In the Base DN field, enter your domain name in LDAP format (e.g. dc=company,dc=com)
In the Bind DN field, enter the UPN login (e.g. ctxsvc@company.com) of a service account in the domain that can browse all objects. Any normal Domain User should be sufficient. Just make sure the password doesn’t expire.
In the Filter field, enter cn=builtin. This limits the search results.
In the Password field, enter the password for the service account. Make sure there is no semicolon in the password or the script will be unable to parse the parameters.

Click Create.

add lb monitor LDAP-Corp LDAP -scriptName nsldap.pl -dispatcherIP 127.0.0.1 -dispatcherPort 3013 -password Passw0rd -secure YES -baseDN "dc=corp,dc=local" -bindDN "corp\\ctxsvc" -filter cn=builtin

If you have multiple domains then create additional monitors: one for each domain.

Servers

On the left, expand Traffic Management, expand Load Balancing, and click Servers.
On the right, click Add.
Enter a descriptive server name, usually it matches the actual server name.
Enter the IP address of the server.

Enter comments to describe the server. Click Create.

add server AD01 10.2.2.11
add server AD01 10.2.2.12

Continue adding Domain Controllers.

Service Groups

On the left, expand Traffic Management, expand Load Balancing, and click Service Groups.
On the right click Add
.
You will create one Service Group per datacenter. Enter a name reflecting the name of the data center. Also, you will create a set of service groups per Active Directory domain so include the domain name.
Change the Protocol to SSL_TCP. Scroll down and click OK.
On the left, in the Service Group Members section, click where it says No Service Group Member.
If you did not create server objects, then enter the IP address of a Domain Controller in this datacenter. If you previously created a server object, then change the selection to Server Based, and select the server object. In the Port field, enter 636 (LDAPS).
1. Note: Any Domain Controller you add to this list must have an SSL certificate installed. The easiest way to install SSL certificates on the Domain Controllers is with Active Directory Certificate Services since it installs the certificates automatically.
Click Create.
Click OK.
On the right, in the Advanced Settings column, click Monitors.
On the left, in the Monitors section, click where it says No Service Group to Monitor Binding.
Click the arrow next to Click to select.
Select your new LDAPS monitor and click Select.
Click Bind.
To verify the member is up, click in the Service Group Members section.
Click the ellipsis next to a member and click Monitor Details.
It should say Success – Probe succeeded. Click Close.
If the monitor doesn’t work, use ldp.exe to verify the Domain Controller certificate.

Click Close and Done to finish creating the Service Group.

add serviceGroup svcgrp-LDAP-Corp SSL_TCP
bind serviceGroup svcgrp-LDAP-Corp AD01 636
bind serviceGroup svcgrp-LDAP-Corp AD02 636
bind serviceGroup svcgrp-LDAP-Corp -monitorName LDAP-Corp

Add additional service groups for Domain Controllers in each data center.

Virtual Server

Create or import a certificate that matches the FQDN that resolves to the new Load Balancing VIP for LDAPS.
On the left, expand Traffic Management, expand Load Balancing, and click Virtual Servers.
On the right, click Add.
Name it LDAPS-Corp-HQ-LB or similar. You will create one Virtual Server per datacenter so include the datacenter name. Also, each domain has a separate set of Virtual Servers so include the domain name.
Change the Protocol drop-down to SSL_TCP.
Enter a Virtual IP. This VIP cannot conflict with any other IP + Port already being used. You can use an existing VIP that is not already listening on TCP 636.
Enter 636 as the Port. Click OK.
On the left, in the Service Group section, click where it says No Load Balancing Virtual Server ServiceGroup Binding.
Click the arrow next to Click to select.
Select the previously created Service Group and click Select.
Click Bind.
Click Continue.
On the left, in the Certificates section, click where it says No Server Certificate.
Click the arrow next to Click to select.
Select a certificate that matches the FQDN that will resolve to this VIP. Click Select.
Click Bind.

Click Continue.

add lb vserver lbvip-LDAP-Corp SSL_TCP 10.2.2.210 636 -persistenceType NONE -cltTimeout 9000

bind lb vserver lbvip-LDAP-Corp svcgrp-LDAP-Corp

If you haven’t enabled the Default SSL Profile, then perform other normal SSL configuration including: disable SSLv3, and bind a Modern Cipher Group.

bind ssl vserver MyvServer -certkeyName MyCert

set ssl vserver MyvServer -ssl3 DISABLED -tls11 ENABLED -tls12 ENABLED

unbind ssl vserver MyvServer -cipherName ALL

bind ssl vserver MyvServer -cipherName Modern

bind ssl vserver MyvServer -eccCurveName ALL

Click Done to finish creating the Virtual Server.
The new Virtual Server should show as Up.
Create additional Virtual Servers for each datacenter. These additional Virtual Servers do not need a VIP so change the IP Address Type to Non Addressable. Only the first Virtual Server will be directly accessible.
```
add lb vserver lbvip-LDAP-Corp-Backup SSL_TCP 0.0.0.0 0
```
Notice that the additional datacenter Virtual Servers show up with an IP Address of 0.0.0.0 and port of 0.
After you are done creating a Virtual Server for each datacenter, click the ellipsis next to the primary datacenter’s Virtual Server and click Edit.
On the right, in the Advanced Settings column, click Protection.
On the left, in the Protection section, change the Backup Virtual Server to one of the other datacenter Virtual Servers. If all of the services in this datacenter are DOWN, the backup Virtual Server will be used instead. You can cascade multiple Virtual Servers using this method. Click OK and Done.
```
set lb vserver lbvip-LDAP-Corp -backupVServer lbvip-LDAP-Corp-Backup
```

Next Steps

You may now use this Virtual IP in your LDAP authentication policies for NetScaler Gateway or NetScaler management login.

↧

NetScaler Gateway 11.1 LDAP Authentication

July 2, 2016, 5:55 am

≫ Next: NetScaler Gateway 11.1 Virtual Server

≪ Previous: Domain Controller (LDAPS) Load Balancing – NetScaler 11.1

Navigation

LDAP Load Balancing

Before you create an LDAP authentication policy, load balance the Domain Controllers. If you don’t load balance your Domain Controllers, then when users enter an incorrect password, the user account will be prematurely locked out.

If you have multiple domains, create different Load Balancing Virtual Servers for each domain. These multiple Load Balancing Virtual Servers can share the same VIP if their port numbers are different. Or you can use a different VIP for each domain.

LDAP Authentication Server

To create the LDAP Authentication Server, do the following:

On the left, expand Authentication and click Dashboard.
On the right, click Add.
In the Choose Server Type drop-down, select LDAP.
Enter LDAP-Corp as the name. If you have multiple domains, you’ll need a separate LDAP Server per domain so make sure you include the domain name.
Change the selection to Server IP. Enter the VIP of the load balancing vServer for LDAP.
Change the Security Type to SSL.
Enter 636 as the Port. Scroll down.
In the Connection Settings section, in the Base DN field, enter your Active Directory DNS domain name in LDAP format.
In the Administrator Bind DN field, enter the credentials of the LDAP bind account in userPrincipalName format. Domain\Username also works.
Enter the Administrator password.
Click Test Connection. NetScaler will attempt to login to the LDAP IP. Scroll down.
In the Other Settings section, use the drop-down next to Server Logon Name Attribute, Group Attribute, and Sub Attribute Name to select the default fields for Active Directory.
On the right, check the box next to Allow Password Change.
Note: there is a checkbox for Validate LDAP Server Certificate. If you want to do this, see Citrix Discussions for instructions for loading the root certificate to /nsconfig/truststore.
If you want to restrict access to only members of a specific group, in the Search Filter field, enter memberOf=<GroupDN>. See the example below:
memberOf=CN=CitrixRemote,OU=Citrix,DC=corp,DC=local

You can add :1.2.840.113556.1.4.1941: to the query so it searches through nested groups. Without this users will need to be direct members of the filtered group.

memberOf:1.2.840.113556.1.4.1941:=CN=CitrixRemote,OU=Citrix,DC=corp,DC=local

Citrix CTX132802 How to Use the ldapsearch Utility on the NetScaler Gateway Enterprise Edition Appliance to Validate a Search Filter
1. An easy way to get the full distinguished name of the group is through Active Directory Administrative Center. Double-click the group object and switch to the Extensions page. On the right, switch to the Attribute Editor tab.
2. Or in Active Directory Users & Computers, enable Advanced view, browse to the object (don’t use Find), double-click the object, and switch to the Attribute Editor tab.
3. Scroll down to distinguishedName, double-click it and then copy it to the clipboard.
4. Back on the NetScaler, in the Search Filter field, type in memberOf= and then paste the Distinguished Name right after the equals sign. Don’t worry about spaces.
Scroll down and click More.
For Nested Group Extraction, if desired, change the selection to Enabled.
Set Group Name Identifier to samAccountName.
Set Group Search Attribute to memberOf. Select << New >> first.
Set Group Search Sub-Attribute to CN. Select << New >> first.
For the Group Search Filter field, see CTX123795 Example of LDAP Nested Group Search Filter Syntax.

Scroll down and click Create.

add authentication ldapAction Corp-Gateway -serverIP 10.2.2.210 -serverPort 636 -ldapBase "dc=corp,dc=local" -ldapBindDn "corp\\ctxsvc" -ldapBindDnPassword Passw0rd -ldapLoginName samaccountname -searchFilter "memberOf=CN=Citrix Remote,CN=Users,DC=corp,DC=local" -groupAttrName memberOf -subAttributeName CN -secType SSL -passwdChange ENABLED

The status of the LDAP Server should be Up.

LDAP Policy Expression

The Authentication Dashboard doesn’t allow you to create the LDAP Policy so you must create it elsewhere.

You can create the LDAP policy now. Or you can wait and create it later when you bind the LDAP Server to the NetScaler Gateway vServer.

To create it now:

Go to NetScaler Gateway > Policies > Authentication > LDAP.
On the right, in the Policies tab, click Add.
Change the Server drop-down to the LDAP Server you created earlier.
Give the LDAP Policy a name (one for each domain).
In the Expression box, enter ns_true.
Click Create.

Gateway Authentication Feedback and Licenses

On the left, under NetScaler Gateway, click Global Settings.
On the right, in the right column, click Change authentication AAA settings.
If you are using Gateway features that require Gateway Universal licenses, then change the Maximum Number of Users to the number of Gateway Universal licenses you have installed on this appliance. This field has a default value of 5 and administrators frequently forget to change it thus only allowing 5 users to connect.
If desired, check the box for Enable Enhanced Authentication Feedback. This feature provides a message to users if authentication fails. The message users receive include password errors, account disabled or locked, or the user is not found, to name a few. Click OK.
```
set aaa parameter -enableEnhancedAuthFeedback YES -maxAAAUsers 200
```

Next Step

For two-factor, configure RADIUS Authentication
Otherwise, Configure NetScaler Gateway Session Policies

Multiple Domains

To support multiple Active Directory domains on a NetScaler Gateway, you create multiple LDAP authentication policies, one for each Active Directory domain, and bind all of the LDAP policies to the NetScaler Gateway Virtual Server. When the user logs into NetScaler Gateway, only the username and password are entered. The NetScaler will then loop through each of the LDAP policies in priority order until it finds one that contains the entered username/password.

What if the same username is present in multiple domains? As NetScaler loops through the LDAP policies, as soon as it finds one with the specified username, it will try to authenticate with that particular LDAP policy. If the password doesn’t match the user account for the attempted domain then a failed logon attempt will be logged in that domain and NetScaler will try the next domain.

Unfortunately, the only way to enter a realm/domain name during user authentication is to require users to login using userPrincipalNames. To use userPrincipalName, set the LDAP Policy/Server with the Server Logon Name Attribute set to userPrincipalName.

You can even do a combination of policies: some with samAccountName and some with userPrincipalName. The samAccountName policies would be searched in priority order and the userPrincipalName policies can be used to override the search order. Bind the userPrincipalName policies higher (lower priority number) than the samAccountName policies.

NetScaler 11.1 supports adding a domain name drop-down list to the logon page. Then use Cookie expressions in the auth policies and session policies. However, this probably doesn’t work for Receivers. See CTX203873 How to Add Drop-Down Menu with Domain Names on Logon Page for NetScaler Gateway 11.0 64.x and later releases for details.
User-added image

Another option for a domain drop-down is nFactor Authentication for Gateway. This also doesn’t work with Receiver Self-service.

After authentication is complete, a Session Policy will be applied that has the StoreFront URL. The NetScaler Gateway will attempt to log into StoreFront using Single Sign-on so the user doesn’t have to login again. When logging into NetScaler Gateway, only two fields are required: username and password. However, when logging in to StoreFront, a third field is required: domain name. So how does NetScaler specify the domain name while logging in to StoreFront?

There are two methods of specifying the domain:

AAA Group – Configure multiple session policies with unique Single Sign-on Domains. Inside the Session Policy is a field called Single Sign-on Domain for specifying the domain name. If there is only one Active Directory domain, then you can use the same Session Policy for all users. However, if there are multiple domains, then you would need multiple Session Policies, one for each Active Directory domain. But as the NetScaler loops through the LDAP policies during authentication, once a successful LDAP policy is found, you need a method of linking an LDAP policy with a Session Policy that has the corresponding SSO Domain. This is typically done using AAA groups. This method is not detailed here but the general steps are: In the LDAP policy/server, specify a Default Authentication Group. Create a AAA Group that matches it. Then bind the corresponding Session Policy to that AAA group.
userPrincipalName – Alternatively, configure the LDAP policy/server to extract the user’s UPN, and then authenticate to StoreFront using UPN. This is the easiest method but some domains don’t have userPrincipalNames configured correctly.

The userPrincipalName method is detailed below:

In each of your NetScaler LDAP policies/servers, in the Other Settings section, in the SSO Name Attribute field, enter userPrincipalName (select –<< New >>– first). Make sure there are no spaces after this attribute name. NetScaler will use this pull this attribute from AD, and use it to Single Sign-on the user to StoreFront.
In StoreFront Console, right-click the Store, and click Manage Authentication Methods.
On the right, click the gear icon, and then click Configure Trusted Domains.
In the Trusted domains box, select Any domain.
Or add your domains in DNS format. The advantage of entering domain names is that you can select a default domain if internal users forget to enter a domain name during login. The DNS format is required for UPN logins (e.g. SSO from NetScaler Gateway).
On the NetScaler Gateway Virtual Server, bind LDAP authentication polices in priority order. It will search them in order until it finds a match.
In your Session Policies/Profiles, in the Published Applications tab, make sure Single Sign-on Domain is not configured. Since NetScaler is using the userPrincipalName there’s no need to specify a domain. If Single Sign-on Domain is configured then Single Sign-on authentication will fail.

↧

NetScaler Gateway 11.1 Virtual Server

July 2, 2016, 3:19 pm

≫ Next: RADIUS Load Balancing – NetScaler 11.1

≪ Previous: NetScaler Gateway 11.1 LDAP Authentication

Navigation

= Recently Updated

NetScaler Gateway Universal Licenses

For basic ICA Proxy connectivity to XenApp/XenDesktop, you don’t need to install any NetScaler Gateway Universal licenses on the NetScaler appliance.

However, if you need SmartAccess features (e.g. EPA scans), or VPN, then you must install NetScaler Gateway Universal licenses. These licenses are included with the Platinum editions of XenApp / XenDesktop, Advanced or Enterprise editions of XenMobile, and the Platinum edition of NetScaler.

When you create a NetScaler Gateway Virtual Server, the ICA Only setting determines if you need NetScaler Gateway Universal licenses or not. If the Virtual Server is set to ICA Only, then you don’t need licenses. But if ICA Only is set to false then you need a NetScaler Gateway Universal license for every user that connects to this NetScaler Gateway Virtual Server. Enabling ICA Only disables all non-ICA Proxy features, including: SmartAccess, SmartControl, and VPN.

If you don’t need any non-ICA Proxy features, then you don’t need any Gateway Universal licenses, and you can skip to the next section.

The Gateway Universal licenses are allocated to the case sensitive hostname of each appliance. If you have an HA pair, and if each node has a different hostname, allocate the Gateway Universal licenses to the first hostname, and then reallocate the same licenses to the other hostname.

To see the hostname, click your username on the top right.

To change the hostname, click the gear icon on the top right.

To upload the allocated Gateway Universal licenses to the appliance, go to System > Licenses. A reboot is required.

After NetScaler Gateway Universal licenses are installed on the appliance, they won’t necessarily be available for usage until you make a configuration change as detailed below:

On the left, expand System, and click Licenses.
On the right, in the Maximum NetScaler Gateway Users Allowed field is the number of licensed users for NetScaler Gateway Virtual Servers that are not set to ICA Only.
On the left, under NetScaler Gateway, click Global Settings.
In the right column of the right pane, click Change authentication AAA settings.
Change the Maximum Number of Users to your licensed limit. This field has a default value of 5 and administrators frequently forget to change it, thus only allowing 5 users to connect.
If desired, check the box for Enable Enhanced Authentication Feedback. Click OK.
```
set aaa parameter -enableEnhancedAuthFeedback YES -maxAAAUsers 200
```

Create Gateway Virtual Server

Create a certificate for the NetScaler Gateway Virtual Server. The certificate must match the name users will use to access the Gateway.
For email discovery in Citrix Receiver, the certificate must have subject alternative names (SAN) for discoverReceiver.email.suffix (use your email suffix domain name). If you have multiple email domains then you’ll need a SAN for each one.
On the left, right-click NetScaler Gateway and click Enable Feature.
On the left, expand NetScaler Gateway and click Virtual Servers.
On the right, click Add.
Name it gateway.corp.com or similar.
Enter a new VIP that will be exposed to the Internet. Note: you can also set it to Non Addressable, which means you can place the Gateway behind a Content Switching Virtual Server.
Click More.
Check the box next to ICA Only. This option disables SmartAccess and VPN features but does not require any additional licenses.
Check the box next to DTLS and click OK. DTLS enables UDP Audio and Framehawk. Note: DTLS is not yet supported for double-hop ICA.
In the Certificates section, click where it says No Server Certificate.
Click the arrow next to Click to select.
Select a previously created certificate that matches the NetScaler Gateway DNS name and click Select.
Click Bind.
If you see a warning about No usable ciphers, click OK.
Click Continue.
In the Basic Authentication section, click the plus icon in the top right.
Select LDAP, select Primary and click Continue.
If you used the authentication dashboard to create the LDAP server then you probably haven’t created the corresponding policy yet. Click the plus icon to create a new policy.
Use the Server drop-down to select the previously created LDAP server.
Give the policy a name. The policy name can match the Server name.
In the Expression box, enter ns_true, or select it from the Saved Policy Expressions drop-down. Click Create.
Click Bind.
Or for two-factor authentication, you will need to bind two policies to Primary and two polices to Secondary:
- Primary = LDAP for Browsers (User-Agent does not contain CitrixReceiver)
- Primary = RADIUS for Receiver Self-Service (User-Agent contains CitrixReceiver)
- Secondary = RADIUS for Browsers (User-Agent does not contain CitrixReceiver)
- Secondary = LDAP for Receiver Self-Service (User-Agent contains CitrixReceiver)
Click Continue.
Scroll down to the Profiles section and click the pencil icon.
In the TCP Profile drop-down select nstcp_default_XA_XD_profile and click OK.
In the Policies section, click the plus icon near the top right.
Select Session, select Request and click Continue.
Click the arrow next to Click to select.
Select one of the Receiver session policies and click Select. It doesn’t matter in which order you bind them.
There’s no need to change the priority number. Click Bind.
Repeat these steps to bind the second policy. In the Policies section, click the plus icon near the top right.
Select Session, select Request and click Continue.
Click Add Binding.
Click the arrow next to Click to select.
Select the other Receiver session policy and click Select.
There’s no need to change the priority number. Click Bind.
The two policies are mutually exclusive so there’s no need to adjust priority. Click Close.
On the right, in the Advanced Settings section, click Published Applications.
Click where it says No STA Server.
Add a Delivery Controller in the https://<Controller_FQDN> or http://<Controller_FQDN> format, depending on if SSL is enabled on the Delivery Controller or not. This must be a FQDN or IP address. Short names don’t work.
Click Bind.
To bind another Secure Ticket Authority server, on the left, in the Published Applications section, click where it says 1 STA Server.
Click Add Binding.
Enter the URL for the second Controller and click Bind.

This view shows if the STAs are reachable or not. To refresh the view, close the STA Bindings list and reopen it.

add vpn vserver gateway.corp.com SSL 10.2.2.200 443 -icaOnly ON -dtls ON -tcpProfileName nstcp_default_XA_XD_profile

bind vpn vserver gateway.corp.com -policy "Receiver Self-Service" -priority 100

bind vpn vserver gateway.corp.com -policy "Receiver for Web" -priority 110

bind vpn vserver gateway.corp.com -policy Corp-Gateway -priority 100

bind vpn vserver gateway.corp.com -staServer "http://xdc01.corp.local"
bind vpn vserver gateway.corp.com -staServer "http://xdc02.corp.local"

bind vpn vserver gateway.corp.com -portaltheme RfWebUI

If you haven’t enabled the Default SSL Profile, then perform other normal SSL configuration including: disable SSLv3, bind a Modern Cipher Group, and enable Strict Transport Security.

bind ssl vserver MyvServer -certkeyName MyCert

set ssl vserver MyvServer -ssl3 DISABLED -tls11 ENABLED -tls12 ENABLED

unbind ssl vserver MyvServer -cipherName ALL

bind ssl vserver MyvServer -cipherName Modern

bind ssl vserver MyvServer -eccCurveName ALL

bind vpn vserver MyvServer -policy insert_STS_header -priority 100 -gotoPriorityExpression END -type RESPONSE

Verify SSL Settings

After you’ve created the Gateway Virtual Server, run the following tests:

Citrix CTX200890 – Error: “1110” When Launching Desktop and “SSL Error” While Launching an Application Through NetScaler Gateway: You can use OpenSSL to verify the certificate. Run the command: openssl s_client -connect gateway.corp.com:443. Replace the FQDN with your FQDN. OpenSSL is installed on the NetScaler or you can download and install it on any machine.
Go to https://www.ssllabs.com/ssltest/ and check the security settings of the website. Citrix Blogs – Scoring an A+ at SSLlabs.com with Citrix NetScaler – 2016 update.

Gateway Portal Theme

Citrix Blog Post Branding your Deployment Part 2: Matching NetScaler to StoreFront explains NetScaler Gateway Portal Themes, how to edit the Portal Theme CSS, and warns about GUI changes overwriting CSS file changes.

If you want the logon page for NetScaler Gateway to look more like StoreFront 3.0 and newer, enable the built-in RfWebUI or X1 theme. RfWebUI is optimized for Unified Gateway (Clientless VPN) since it provides the exact same appearance and user experience as StoreFront 3.x. The Unified Gateway RfWebUI theme can display RDP Links and Web Links (bookmarks) along with the familiar StoreFront apps and desktops.

Go to NetScaler Gateway > Virtual Servers and edit an existing Virtual Server.
On the right, in the Advanced Settings section, click Portal Themes.
On the left, Change the Portal Theme drop-down to RfWebUI. Click OK.

Click Done.

bind vpn vserver gateway.corp.com -portaltheme RfWebUI

When you access the NetScaler Gateway login page you’ll see the theme.

Custom Theme

You can also create your own theme by starting from one of the built-in themes:

Go to NetScaler Gateway > Portal Themes.
On the right, click Add.
Give the theme a name, and select RfWebUI as the Template Theme. Click OK.
In the Look and Feel section, there are two sub-sections: one for Home Page and one for Common Attributes.
The Home Page is for Unified Gateway (aka VPN Clientless Access). Notice that the Websites Sections can be disabled.
The Help Legend link shows you what the other fields modify.
If you want to modify the logon page, use the Common Attributes sub-section.
The Help Legend link shows you what the fields modify.
Make changes as desired and click OK.
After you click OK, the Language section appears.
In the Language section, select a language and click OK.
On the right, in the Advanced Settings section, click Login Page.
Make changes as desired (e.g. Password Field Titles) and click OK.
At the top of the screen, click the link to Click to Bind and View Configured Theme.
Select a Gateway Virtual Server and click Bind and Preview.
The logon page is displayed.
You could go to /var/netscaler/logon/themes/MyTheme/css and make more changes to custom.css, but this file gets overwritten any time you make a change in the Portal Themes section of the NetScaler GUI.

SSL Redirect

Use one of the following procedures to configure a redirect from http to https. Responder method is preferred.

Public DNS SRV Records

For email-based discovery, add a SRV record to each public email suffix DNS zone. Here are sample instructions for a Windows DNS server:

In Server Manager, click Tools > DNS Manager
In the left pane of DNS Manager, select your DNS domain in the forward or reverse lookup zones. Right-click the domain and select Other New Records.
In the Resource Record Type dialog box, select Service Location (SRV) and then click Create Record.
In the New Resource Record dialog box, click in the Service box and enter the host value _citrixreceiver.
Click in the Protocol box and enter the value _tcp.
In the Port number box, enter 443.
In the Host offering this service box, specify the fully qualified domain name (FQDN) for your NetScaler Gateway Virtual Server in the form servername.domain (e.g. gateway.company.com)

Block Citrix VPN for iOS

Andrew Morgan Blocking the new Citrix VPN iOS connection to Netscaler gateway and Citrix CTX201129 Configuration for Controlled Access to Different VPN Plugin Through NetScaler Gateway for XenMobile Deployments: do one or both of the following:

Create an AppExpert > Responder > Policy with Action = DROP and Expression = HTTP.REQ.HEADER("User-Agent").CONTAINS("CitrixReceiver/NSGiOSplugin"). Either bind the Responder Policy Globally, or bind it to the Gateway vServers.
In your Gateway Session Policies, on the Client Experience tab, set the Plug-in Type to Java. If any of them are set to Windows/MAC OS X, then VPN for iOS is allowed.

View ICA Sessions

To view active ICA sessions, click the NetScaler Gateway node on the left, and then click ICA Connections on the right.

show vpn icaconnection

Customize Logon Page

Logon Page Labels

When two factor authentication is configured on NetScaler Gateway, the user is prompted for User name, Password, and Password 2.

The Password field labels can be changed to something more descriptive, such as Active Directory or RSA:

To change the labels, edit a Portal Theme:

Go to NetScaler Gateway > Portal Themes and edit an existing theme. You can’t edit the built-in themes so you’ll have to create one if you haven’t already.
On the right, in the Advanced Settings column, click Login Page.
In the Login Page section, change the two Password fields to your desired text. Click OK.
If using the RfWebUI theme, the default text size for the form field labels is 17px. However, the Portal Themes editor defaults to 12px. You can change it back to 16px or 18px by editing Form Font Size in the Look and Feel > Common Attributes section.
In the Portal Theme section at the top of the page, you can Click to bind and View Configured Theme to Preview your changes.
On Platinum Edition appliances, you might have to invalidate the loginstaticobjects Content Group (Optimization > Integrated Caching > Content Groups) before the changes appear. This seems to be true even if Integrated Caching is disabled.

Logon Security Message (Disclaimer, EULA)

You can force users to agree to a EULA before they are allowed to login.

Clicking the Terms & Conditions link allows the user to view the EULA text that you have entered.

Do the following to configure the EULA:

Go to NetScaler Gateway > Resources > EULA.
On the right, click Add.
Give the EULA a name and enter some text. You can even enter HTML code. See the example posted by Chris Doran at Citrix Discussions.
Click Create.
Edit a Gateway Virtual Server.
On the right, in the Advanced Settings column, click EULA.
Click where it says No EULA.
Click the arrow next to Click to select.
Select the EULA and click Select.
Click Bind.

Theme File Customization

The original themes (Default, Green Bubble, and X1) use files from /netscaler/ns_gui/vpn/js and /var/netscaler/logon/themes. A commonly edited file is /netscaler/ns_gui/vpn/js/gateway_login_form_view.js since this file is responsible for rendering the logon form.

The new RfWebUI theme is different than the original themes, because it pulls files from /var/netscaler/logon/LogonPoint/receiver. This means the customizations for NetScaler 11.0 won’t work with the new RfWebUI theme. When reviewing customization guides for NetScaler 11, be aware that most of them won’t work for the RfWebUI theme.

Logon Page Links

Citrix CTX202444 How to Customize NetScaler Gateway 11 logon Page with Links shows how to add links to the NetScaler Gateway 11 logon page. This only works in the Default, Green Bubble, and X1 themes (no RfWebUI theme).

Other Customizations

Mike Roselli at Netscaler 11 Theme Customization – How to Add Links and Verbiage at discussions.citrix.com has sample rewrite policies to customize the NetScaler Gateway logon page with additional HTML.

Craig Tolley Customising the NetScaler 11 User Interface – Adding Extra Content: add new sections to login page. These sections pull content from local HTML files.

Daniel Ruiz Set up a maintenance page on Netscaler Gateway: configure a Responder policy (see the blog post for sample HTML code). During maintenance, manually bind the Responder policy to the Gateway. Manually remove the policy after maintenance is complete.

UDP Audio Through Gateway

From John Crawford at Citrix Discussions and Marius Sandbu Enabling Citrix Receiver audio over Netscaler Gateway with DTLS

Note: Enabling DTLS on the Gateway also enables Framehawk. See Citrix Policy Settings for Framehawk configuration.

Requirements for UDP Audio:

Citrix Receiver 4.2 or newer
NetScaler Gateway 10.5.e (enhancement build) or NetScaler 11 or newer
UDP 443 allowed to NetScaler Gateway Virtual Server
UDP 16500-16509 allowed from NetScaler SNIP to VDAs

To enable UDP Audio through Gateway, make changes on both the NetScaler Gateway Virtual Server and in Receiver:

Edit the NetScaler Gateway Virtual Server. In the Basic Settings section click the edit (pencil) icon.
Click More.
Enable the DTLS option and click OK.
After enabling DTLS, it probably won’t work until you unbind the Gateway certificate and rebind it.

Client-side configuration

There are two methods of enabling RTP on the client side:

Edit default.ica on the StoreFront server
Use GPO to modify the client-side config

To edit the default.ica file on the StoreFront server (h/t Vipin Borkar): Edit the file C:\inetpub\wwwroot\Citrix\Store\App_Data\default.ica and add the following lines to the Application section:

EnableRtpAudio=true
EnableUDPThroughGateway=true
AudioBandwidthLimit=1

To use GPO to modify the client-side config:

Copy the receiver.admx (and .adml) policy template into PolicyDefinitions if you haven’t already.
Edit a GPO that applies to Receiver machines. You can also edit the local GPO on a Receiver machine.
Go to Computer Configuration > Policies > Administrative Templates > Citrix Components > Citrix Receiver.
Edit the setting Client audio settings.
Enable the setting.
Set audio quality as desired. Higher quality = higher bandwidth.
Check to Enable Real-Time Transport.
Check to Allow Real-Time Transport through Gateway. Click OK.

Next step

Configure StoreFront to use NetScaler Gateway

StoreFront – Rewrite X-Citrix-Via

When NetScaler Gateway communicates with StoreFront, it adds a header called X-Citrix-Via that contains the FQDN entered in the user’s address bar. StoreFront uses this header to find a matching Gateway object so StoreFront knows how to handle the authentication. In NetScaler 11.0 and newer, you can create a rewrite policy to change this header. This is useful when changing URLs or using DNS aliases for Gateways. See CTX202442 FAQ: Modify HTTP Header X-Citrix-Via on NetScaler for more details.

Here’s a sample rewrite policy for this header:

enable ns feature REWRITE

add rewrite action rwact_storefront replace "HTTP.REQ.HEADER(\"X-Citrix-Via\")" "\"mystorefront.mydomain.com\""

add rewrite policy rwpol_storefront "HTTP.REQ.HEADER(\"X-Citrix-Via\").NE(\"mystorefront.mydomain.com\")" rwact_storefront

bind vpn vserver mygateway-vs -policy rwpol_storefront -priority 100 -type REQUEST

↧

RADIUS Load Balancing – NetScaler 11.1

July 3, 2016, 7:55 am

≫ Next: NetScaler Gateway 11.1 RADIUS Authentication

≪ Previous: NetScaler Gateway 11.1 Virtual Server

Navigation

RADIUS Load Balancing Overview

Two-factor authentication to NetScaler Gateway requires the RADIUS protocol to be enabled on the two-factor authentication product.

On your RADIUS servers, you’ll need to add the NetScaler appliances as RADIUS Clients. When NetScaler uses a local (same appliance) load balanced Virtual Server for RADIUS authentication, the traffic is sourced from the NetScaler SNIP (Subnet IP). When NetScaler uses a direct connection to a RADIUS Server without going through a load balancing Virtual Server, or uses a remote (different appliance) Load Balancing Virtual Server, the traffic is sourced from the NetScaler NSIP (NetScaler IP). Use the correct IP(s) when adding the NetScaler appliances as RADIUS Clients. And adjust firewall rules accordingly.

For High Availability pairs, if you locally load balance RADIUS, then you only need to add the SNIP as a RADIUS Client since the SNIP floats between the two appliances. However, if you are not locally load balancing RADIUS, then you’ll need to add the NSIP of both appliances as RADIUS Clients. Use the same RADIUS Secret for both appliances.

When load balancing RADIUS, you’ll want a monitor that verifies that the RADIUS server is functional. The RADIUS monitor will login to the RADIUS server and look for a response. You will need static credentials that the RADIUS monitor can use to login to the RADIUS server.

If you don’t want your monitor to login to RADIUS, then the only other monitoring option is Ping. Adjust the firewall accordingly.

If you have RADIUS Servers in multiple datacenters, you can create multiple load balancing Virtual Servers and cascade them so that the local RADIUS Servers are used first, and if they’re not available, then the Virtual Server fails over to RADIUS Servers in remote datacenters.

RADIUS Monitor

The RADIUS Monitor attempts to successfully log into the RADIUS server. For RSA, create an account on RSA with the following parameters as mentioned by Jonathan Pitre:

Setup a user with a fixed passcode in your RSA console.
Ensure you login with that user at least once to the RSA console because you’ll be asked to change it the first time.
There is no need to assign a token to your monitor user as long as you are using a fixed passcode. You don’t want to waste a token on a user just for monitoring.

Henny Louwers – Configure RSA RADIUS monitoring on NetScaler:

In the NetScaler Configuration Utility, on the left under Traffic Management > Load Balancing, click Monitors.
On the right, click Add.
Name the monitor RSA or similar. Change the Type drop-down to RADIUS.
On the Standard Parameters tab, you might have to increase the Response Time-out to 4.
On the Special Parameters tab, enter valid RADIUS credentials. Make sure these credentials do not change or expire. For RSA, in the Password field, enter the fixed passcode.
Also enter the RADIUS key configured on the RADIUS server for the NetScaler as RADIUS client.
For Response Codes, add both 2 and 3. 2 means success, while 3 indicates some kind of failure. Either result means that the RADIUS server is responding, and thus is probably functional. But 2 is the ideal response.

Click Create when done.

add lb monitor RSA RADIUS -respCode 2-3 -userName ctxsvc -password Passw0rd -radKey Passw0rd -resptimeout 4

Servers

On the left, expand Traffic Management, expand Load Balancing, and click Servers.
On the right, click Add.
Enter a descriptive server name; usually it matches the actual server name.
Enter the IP address of the server.

Enter comments to describe the server. Click Create.

add server RSA01 10.2.2.42
add server RSA02 10.2.2.43

Continue adding RADIUS servers.

Service Groups

On the left, expand Traffic Management, expand Load Balancing, and click Service Groups.
On the right, click Add.
You will create one Service Group per datacenter. Enter a name reflecting the name of the datacenter.
Change the Protocol to RADIUS.
Click OK.
On the left, in the Service Group Members section, click where it says No Service Group Member.
If you did not create server objects, then enter the IP address of a RADIUS Server in this datacenter. If you previously created a server object, then change the selection to Server Based, and select the server object(s).
In the Port field, enter 1812 (RADIUS).
Click Create.
Click OK when done adding members.
On the right, in the Advanced Settings column, click Monitors.
On the left, in the Monitors section, click where it says No Service Group to Monitor Binding.
Click the arrow next to Click to select.
Select your new RADIUS monitor and click Select.
Click Bind.
To verify the member is up, click in the Service Group Members section.
Highlight a member and click Monitor Details.
It should say Radius response code 2 (or 3) received. Click OK.

Click Done to finish creating the Service Group.

add serviceGroup svcgrp-RSA RADIUS
bind serviceGroup svcgrp-RSA RSA01 1812
bind serviceGroup svcgrp-RSA -monitorName RSA

The Service Group is displayed as UP.
Add additional service groups for Radius servers in each data center.

Virtual Server

On the left, expand Traffic Management, expand Load Balancing, and click Virtual Servers.
On the right, click Add.
Name it lbvip-RADIUS-HQ or similar. You will create one Virtual Server per datacenter so include the datacenter name.
Change the Protocol drop-down to RADIUS.
Enter a Virtual IP. This VIP cannot conflict with any other IP + Port already being used. You can use an existing VIP if the VIP is not already listening on UDP 1812.
Enter 1812 as the Port. Click OK.
In the Services and Service Groups section, click where it says No Load Balancing Virtual Server ServiceGroup Binding.
Click the arrow next to Click to select.
Select a previously created Service Group and click Select.
Click Bind.
Click Continue.
On the right, in the Advanced Settings section, click Method.
On the left, change the Load Balancing Method to TOKEN.
In the Expression box, enter CLIENT.UDP.RADIUS.USERNAME.
Click OK.
On the right, in the Advanced Settings section, click Persistence.
On the left, change Persistence to RULE.
In the Expression box, enter CLIENT.UDP.RADIUS.USERNAME.
Click OK.
Click Done to finish creating the Virtual Server.
If you are configuring this RADIUS Load Balancer for more than just NetScaler Gateway, you can add another Load Balancer on port 1813 for RADIUS Accounting. Then you need a Persistency Group to tie the two load balancers together. See Configuring RADIUS Load Balancing with Persistence at Citrix Docs.
```
add lb vserver lbvip-RSA RADIUS 10.2.2.210 1812 -persistenceType RULE -lbMethod TOKEN -rule CLIENT.UDP.RADIUS.USERNAME
bind lb vserver lbvip-RSA svcgrp-RSA
```
The new Virtual Server should show as Up. If not, click the Refresh icon.
Create additional Virtual Servers for each datacenter. These additional Virtual Servers do not need a VIP. so change the IP Address Type to Non Addressable. Only the first Virtual Server will be directly accessible.
```
add lb vserver lbvip-RSA-Backup RADIUS 0.0.0.0 0 -persistenceType NONE -cltTimeout 120
```
Notice that the additional datacenter Virtual Servers have an IP Address of 0.0.0.0 and port of 0.
After you are done creating a Virtual Server for each datacenter, click the ellipsis next to the primary datacenter’s Virtual Server, and click Edit.
On the right, in the Advanced Settings column, click Protection.
On the left, in the Protection section, change the Backup Virtual Server to one of the other datacenter Virtual Servers. If all of the services in this datacenter are DOWN, the backup Virtual Server will be used instead. You can cascade multiple Virtual Servers using this method. Click OK and Done.
```
set lb vserver lbvip-RSA -backupVServer lbvip-RSA-Backup
```
You may now use this Virtual IP in your RADIUS authentication policies for NetScaler Gateway or NetScaler management login.

↧

NetScaler Gateway 11.1 RADIUS Authentication

July 3, 2016, 8:59 am

≫ Next: Global Server Load Balancing (GSLB) – NetScaler 11.1

≪ Previous: RADIUS Load Balancing – NetScaler 11.1

Navigation

RADIUS Overview

For two-factor authentication using Azure Multi-factor Authentication, see Jason Samuel How to deploy Microsoft Azure MFA & AD Connect with Citrix NetScaler Gateway

Citrix CTX125364 How to Configure Dual Authentication on NetScaler Gateway Enterprise Edition for Use with iPhone and iPad.

Some two-factor products (e.g. SMS Passcode) require you to hide the 2nd password field. Receiver 4.4 and newer supports hiding the 2nd field if you configure a Meta tag in index.html. See CTX205907 Dual-Password Field Shows in First Authentication When Connecting to NetScaler Gateway from Windows Receiver for instructions.

Two-factor authentication to NetScaler Gateway requires the RADIUS protocol to be enabled on the two-factor authentication product.

On your RADIUS servers, you’ll need to add the NetScaler appliances as RADIUS Clients. When NetScaler uses a local (same appliance) load balanced Virtual Server for RADIUS authentication, the traffic is sourced from the NetScaler SNIP (Subnet IP). When NetScaler uses a direct connection to a RADIUS Server without going through a load balancing Virtual Server, or uses a remote (different appliance) Load Balancing Virtual Server, the traffic is sourced from the NetScaler NSIP (NetScaler IP). Use the correct IP(s) when adding the appliances as RADIUS Clients. And adjust firewall rules accordingly.

For High Availability pairs, if you locally load balance RADIUS, then you only need to add the SNIP as a RADIUS Client, since the SNIP floats between the two appliances. However, if you are not locally load balancing RADIUS, then you’ll need to add the NSIP of both appliances as RADIUS Clients. Use the same RADIUS Secret for both appliances.

Two-factor Policies Summary

When configuring the NetScaler Gateway Virtual Server, you can specify both a Primary authentication policy, and a Secondary authentication policy. Users are required to successfully authenticate against both policies before being authorized for NetScaler Gateway.

For browser-based StoreFront, you need two authentication policies:

Primary = LDAPS authentication policy pointing to Active Directory Domain Controllers.
Secondary = RADIUS authentication policy pointing to RSA servers with RADIUS enabled.

For Receiver Self-service (native Receiver on mobile, Windows, and Mac), the authentication policies are swapped:

Primary = RADIUS authentication policy pointing to RSA servers with RADIUS enabled.
Secondary = LDAPS authentication policy pointing to Active Directory Domain Controllers.

If you need to support two-factor authentication from both web browsers and Receiver Self-Service, then you’ll need at least four authentication policies as shown below.

Primary:

Priority 90 = RADIUS policy. Expression = REQ.HTTP..HEADER User-Agent CONTAINS CitrixReceiver
Priority 100 = LDAP policy. Expression = REQ.HTTP..HEADER User-Agent NOTCONTAINS CitrixReceiver

Secondary:

Priority 90 = LDAP policy. Expression = REQ.HTTP..HEADER User-Agent CONTAINS CitrixReceiver
Priority 100 = RADIUS policy. Expression = REQ.HTTP..HEADER User-Agent NOTCONTAINS CitrixReceiver

Create Two-factor Policies

Do the following to create the Two-factor policies:

Create an LDAP server.
For RADIUS, on the left, expand Authentication, and click Dashboard.
On the right, click Add.
Change Choose Server Type to RADIUS.
Give the server a name.
Specify the IP address of the RADIUS load balancing Virtual Server.
Enter the secret key specified when you added the NetScalers as RADIUS clients on the RADIUS server. Click Test Connection.

Scroll down and click Create.

add authentication radiusAction RSA -serverIP 10.2.2.210 -serverPort 1812 -radKey Passw0rd

Since you can’t create authentication policies from the authentication dashboard, go to NetScaler Gateway > Policies > Authentication > RADIUS.
On the right, in the Policies tab, click Add.
Name it RSA-ReceiverSelfService or similar.
Select the RADIUS server created earlier.
Enter an expression. You will need two policies with different expressions. The expression for Receiver Self-Service is REQ.HTTP.HEADER User-Agent CONTAINS CitrixReceiver.

Click Create.

add authentication radiusPolicy RSA-ReceiverForWeb "REQ.HTTP.HEADER User-Agent NOTCONTAINS CitrixReceiver" RSA

add authentication radiusPolicy RSA-ReceiverSelfService "REQ.HTTP.HEADER User-Agent CONTAINS CitrixReceiver" RSA

add authentication ldapPolicy Corp-Gateway-ReceiverForWeb "REQ.HTTP.HEADER User-Agent NOTCONTAINS CitrixReceiver" Corp-Gateway

add authentication ldapPolicy Corp-Gateway-ReceiverSelfService "REQ.HTTP.HEADER User-Agent CONTAINS CitrixReceiver" Corp-Gateway

Create another policy to match the ones shown below. Both RADIUS policies are configured with the same RADIUS server. The only difference between them is the expression (CONTAINS vs NOTCONTAINS):

Name Expression Server

RSA-ReceiverSelfService REQ.HTTP.HEADER User-Agent CONTAINS CitrixReceiver RSA

RSA-ReceiverForWeb REQ.HTTP.HEADER User-Agent NOTCONTAINS CitrixReceiver RSA
Go to the NetScaler Gateway\Policies\Authentication\LDAP node.

On the Policies tab, create two policies with the expressions shown below. Both LDAP policies are configured with the same LDAP server. The only difference between them is the expression (CONTAINS vs NOTCONTAINS).

Name	Expression	Server
LDAP-Corp-ReceiverSelfService	REQ.HTTP.HEADER User-Agent CONTAINS CitrixReceiver	LDAP-Corp
LDAP-Corp-ReceiverForWeb	REQ.HTTP.HEADER User-Agent NOTCONTAINS CitrixReceiver	LDAP-Corp

Bind Two-factor Policies to Gateway

When you create or edit a NetScaler Gateway Virtual Server, bind the policies as shown in the following table. Priority doesn’t matter because they are mutually exclusive.

Policy Name	Type	Bind Point
LDAP-Corp-ReceiverForWeb	LDAP	Primary
RSA-ReceiverSelfService	RADIUS	Primary
LDAP-Corp-ReceiverSelfService	LDAP	Secondary
RSA-ReceiverForWeb	RADIUS	Secondary

bind vpn vserver gateway.corp.com -policy Corp-Gateway-ReceiverForWeb -priority 100

bind vpn vserver gateway.corp.com -policy RSA-ReceiverSelfService -priority 110

bind vpn vserver gateway.corp.com -policy RSA-ReceiverForWeb -priority 100 -secondary

bind vpn vserver gateway.corp.com -policy Corp-Gateway-ReceiverSelfService -priority 110 -secondary

The session policy for Receiver Self-Service needs to be adjusted to indicate which authentication field contains the Active Directory password. On the Client Experience tab is Credential Index. This needs to be changed to SECONDARY. Leave the session policy for Web Browsers set to Primary.
```
set vpn sessionAction "Receiver Self-Service" -ssoCredential SECONDARY
```
On the StoreFront server, when creating the NetScaler Gateway object, change the Logon type to Domain and security token.

↧

Global Server Load Balancing (GSLB) – NetScaler 11.1

June 21, 2016, 5:28 am

≫ Next: NetScaler Gateway 11.1 – RDP Proxy

≪ Previous: NetScaler Gateway 11.1 RADIUS Authentication

Navigation

= Recently Updated

GSLB Planning

GSLB is nothing more than DNS. GSLB is not in the data path. GSLB receives a DNS query, and GSLB sends back an IP address, which is exactly how a DNS server works. However, GSLB can do some things that DNS servers can’t do:

Don’t give out an IP address unless it is UP (monitoring)
- If active IP address is down, give out the passive IP address (active/passive)
Give out the IP address that is closest to the user (proximity load balancing)
Give out different IPs for internal vs external (DNS View)

GSLB is only useful if you have a single DNS name that could resolve to two or more IP addresses. If there’s only one IP address, then use normal DNS instead.

Citrix Blog Post Global Server Load Balancing: Part 1 explains how DNS queries work and how GSLB fits in.

Citrix has a good DNS and GSLB Primer.

When configuring GSLB, don’t forget to ask “where is the data?”. For XenApp/XenDesktop, DFS multi-master replication of user profiles is not supported, so configure “home” sites for users. More information at Citrix Blog Post XenDesktop, GSLB & DR – Everything you think you know is probably wrong!

GSLB can be enabled both externally and internally. For external GSLB, configure it on the DMZ NetScaler appliances and expose it to the Internet. For internal GSLB, configure it on internal NetScaler appliances. Note: Each NetScaler appliance only has one DNS table, so if you try to use one NetScaler for both public and internal, then be aware that external users can query for internal GSLB-enabled DNS names.

For internal and external GSLB of the same DNS name on the same appliance, you can use DNS Policies and DNS Views to return different IP addresses depending on where users are connecting from. Citrix CTX130163 How to Configure a GSLB Setup for Internal and External Users Using the Same Host Name.

However, GSLB monitoring applies to the entire GSLB Service, so it would take down both internal and external GSLB. If you need different GSLB monitoring for internal and external of the same DNS name, try CNAME:

External citrix.company.com:
- Configure NetScaler GSLB for citrix.company.com.
- On public DNS, delegate citrix.company.com to the NetScaler DMZ ADNS services.
Internal citrix.company.com:
- Configure NetScaler GSLB for citrixinternal.company.com or something like that.
- On internal DNS, create CNAME for citrix.company.com to citrixinternal.company.com
- On internal DNS, delegate citrixinternal.company.com to NetScaler internal ADNS services.

Some IP Addresses are needed on each NetScaler pair:

ADNS IP: An IP that will listen for ADNS queries. For external, create a public IP for the ADNS IP and open UDP 53 so Internet-based DNS servers can access it. This can be an existing SNIP on the appliance.
GSLB Site IP / MEP IP: A GSLB Site IP that will be used for NetScaler-to-NetScaler communication, which is called MEP or Metric Exchange Protocol. The IP for ADNS can also be used for MEP / GSLB Site.
- RPC Source IP: The GSLB Site IP can be anything, and RPC traffic (MEP) can be sourced from the GSLB IP. For older NetScaler builds, RPC traffic is sourced from a SNIP, even if this is different than the GSLB Site IP. In older builds, it’s less confusing if you use a SNIP as the GSLB Site IP.
- Public IP: For external GSLB, create public IPs that are NAT’d to the GSLB Site IPs. The same public IP used for ADNS can also be used for MEP. MEP should be routed across the Internet so NetScaler can determine if the remote datacenter has Internet connectivity or not.
- MEP Port: Open port TCP 3009 between the two NetScaler GSLB Site IPs. Make sure only the NetScalers can access this port on the other NetScaler. Do not allow any other device on the Internet to access this port. This port is encrypted.
- GSLB Sync Ports: To use GSLB Configuration Sync, open ports TCP 22 and TCP 3008 from the NSIP (management IP) to the remote public IP that is NAT’d to the GSLB Site IP. The GSLB Sync command runs a script in BSD shell and thus NSIP is always the Source IP.
DNS Queries: The purpose of GSLB is to resolve a DNS name to one of several potential IP addresses. These IP addresses are usually public IPs that are NAT’d to existing Load Balancing, SSL Offload, Content Switching, or NetScaler Gateway VIPs in each datacenter.
IP Summary: In summary, for external GSLB, you will need a minimum of two public IPs in each datacenter:
- One public IP that is NAT’d to the IP that is used for ADNS and MEP (GSLB Site IP). You only need one IP for ADNS / MEP no matter how many GSLB names are configured. MEP (GSLB Site IP) can be a different IP, if desired.
- One public IP that is NAT’d to a Load Balancing, SSL Offload, Content Switching, or NetScaler Gateway VIP.
- If you GSLB-enable multiple DNS names, each DNS name usually resolves to different IPs. This usually means that you will need additional public IPs NAT’d to additional VIPs.

ADNS

Identify a NetScaler-owned IP that you will use for ADNS. This is typically a SNIP.
Configure a public IP for the ADNS Service IP and configure firewall rules.
On the left, expand Traffic Management > Load Balancing, and click Services.
On the right, click Add.
Name the service ADNS or similar.
In the IP Address field, enter an appliance SNIP.
In the Protocol field, select ADNS. Then click OK.
Scroll down and click Done.
On the left of the console, expand System, expand Network, and then click IPs.
On the right, you’ll see the SNIP is now marked as the ADNS svc IP. If you don’t see this yet, click the Refresh icon.
Repeat on the other appliance in the other datacenter.
Your NetScaler appliances are now DNS servers.

Metric Exchange Protocol

This can be any IP. Or you can use the same SNIP and same public IP used for ADNS.
Open the firewall rules for Metric Exchange Protocol.
On the left, expand Traffic Management, right-click GSLB, and enable the feature.
Expand GSLB, and click Sites.
On the right, click Add.
Add the local site first. Enter a descriptive name.
In the Site Type drop-down, select LOCAL.
In the Site IP Address field, enter an IP that this appliance will listen for MEP traffic.
For Internet-routed GSLB MEP, in the Public IP Address field, enter the public IP that is NAT’d to the GSLB Site IP. For internal GSLB MEP, there is no need to enter anything in the Public IP field. Click Create.
Go back to System > Network > IPs and verify that the IP is now marked as a GSLB site IP. If you don’t see it yet, click the Refresh button.
If you want to use the GSLB Sync Config feature, then you’ll need to edit the GSLB site IP, and enable Management Access.
Scroll down and enable Management Access. SSH is all you need.
Go to the other appliance and also create the local GSLB site using its GSLB site IP and its public IP that is NAT’d to the GSLB site IP.
In System > Network > IPs on the remote appliance, there should now be a GSLB site IP. This could be a SNIP. If GSLB Sync is desired, enable management access on that IP and ensure SSH is enabled.
Now on each appliance add another GSLB Site, which will be the remote GSLB site.
Enter a descriptive name and select REMOTE as the Site Type.
Enter the other appliance’s actual GSLB Site IP as configured on the appliance. This IP does not need to be reachable.
In the Public IP field, enter the public IP that is NAT’d to the GSLB Site IP on the other appliance. For MEP, TCP 3009 must be open from the local GSLB Site IP to the remote public Site IP. For GSLB sync, TCP 22, and TCP 3008 must be open from the local NSIP to the remote public Site IP. Click Create.
Repeat on the other appliance.
MEP will not function yet since the NetScaler appliances are currently configured to communicate unencrypted on TCP 3011. To fix that, on the left, expand System, expand Network, and click RPC.
On the right, edit the new RPC address (the other site’s GSLB Site IP) and click Edit.
On the bottom, check the box next to Secure.
If your local GSLB Site IP is not a SNIP, then you’ll need to change the RPC Node to use the local GSLB Site IP as the source IP. In the Source IP Address field, enter the local GSLB Site IP. Click OK when done.
Do the same thing on the other appliance.
If you go back to GSLB > Sites, you should see it as active.

GSLB Services

GSLB Services represent the IP addresses that are returned in DNS Responses. DNS Query = DNS name. DNS Response = IP address.

GSLB should be configured identically on both NetScalers. Since you have no control over which NetScaler will receive the DNS query, you must ensure that both NetScalers are giving out the same DNS responses.

Create the same GSLB Services on both NetScalers:

Start on the appliance in the primary data center. This appliance should already have a traffic Virtual Server (NetScaler Gateway, Load Balancing, or Content Switching) for the DNS name that you are trying to GSLB enable.
On the left, expand Traffic Management > GSLB, and click Services.
On the right, click Add.
The service name should be similar to the DNS name that you are trying to GSLB. Include the site name in the service name.
Select the LOCAL Site.
On the bottom part, select Virtual Servers, and then select a Virtual Server that is already defined on this appliance. It should automatically fill in the other fields. If you see a message asking if you wish to create a service object, click Yes.
Scroll up and make sure the Service Type is SSL. It’s annoying that NetScaler doesn’t set this drop-down correctly.
The Public IP field contains the actual IP Address that the GSLB ADNS service will hand out. Make sure this Public IP is user accessible. It doesn’t even need to be a NetScaler owned IP.
Scroll down and click OK.
If the GSLB Service IP is a VIP on the local appliance, then GSLB will simply use the state of the local traffic Virtual Server (Load Balancing, Content Switching, or Gateway). If the GSLB Service IP is a VIP on a remote appliance, then GSLB will use MEP to ask the other appliance for the state of the remote traffic Virtual Server. In both cases, there’s no need to bind a monitor to the GSLB Service.
However, you can also bind monitors directly to the GSLB Service. Here are some reasons for doing so:
- If the GSLB Service IP is a NetScaler-owned traffic VIP, but the monitors bound the traffic Virtual Server are not the same ones you want to use for GSLB. When you bind monitors to the GSLB Services, the monitors bound to the traffic Virtual Server are ignored.
- If the GSLB Service IP is in a non-default Traffic Domain, then you will need to attach a monitor since GSLB cannot determine the state of Virtual Servers in non-default Traffic Domains.
- If the GSLB Service IP is not hosted on a NetScaler, then only GSLB Service monitors can determine if the Service IP is up or not.
If you intend to do GSLB active/active, and if you need site persistence, then you can configure your GSLB Services to use Connection Proxy or HTTP Redirect. See Citrix Blog Post Troubleshooting GSLB Persistence with Fiddler for more details.
Click Done.
On the other datacenter NetScaler, create a GSLB Service.
Select the REMOTE site that is hosting the service.
Since the service is on a different appliance and not this one, you won’t be able to select it using the Virtual Servers option. Instead, selectNew Server.
For the Server IP, enter the actual VIP configured on the other appliance. This local NetScaler will use GSLB MEP to communicate with the remote NetScaler to find a traffic Virtual Server with this VIP. The remote NetScaler respond if the remote traffic Virtual Server is up or not. The remote Server IP configured here does not need to be directly reachable by this local appliance. If the Server IP is not owned by either NetScaler, then you will need to bind monitors to your GSLB Service.
In the Public IP field, enter the IP address that will be handed out to clients. This is the IP address that users will use to connect to the service. For Public DNS, you enter a Public IP that is usually NAT’d to the traffic VIP. For internal DNS, the Public IP and the Server IP are usually the same.
Scroll up and change the Service Type to match the Virtual Server defined on the other appliance.
Click OK.
Just like the other appliance, you can also configure Site Persistence and GSLB Service Monitors. Click Done when done.
Create more GSLB Services, one for each traffic VIP. GSLB is useless if there’s only one IP address to return. You should have multiple IP addresses (VIPs) through which a web service (e.g. NetScaler Gateway) can be accessed. Each of these VIPs is typically in different datacenters, or on different Internet circuits. The mapping between DNS name and IP addresses is configured in the GSLB vServer, as detailed in the next section.

GSLB Virtual Server

The GSLB Virtual Server is the entity that the DNS name is bound to. GSLB vServer then gives out the IP address of one of the GSLB Services that is bound to it.

Configure the GSLB vServer identically on both appliances:

On the left, expand Traffic Management > GLSB, and click Virtual Servers.
On the right, click Add.
Give the GSLB vServer a descriptive name. For active/active, you can name it the same as your DNS name. For active/passive, you will create two GSLB Virtual Servers, one for each datacenter, so include Active or Passive in the Virtual Server name.
If you intend to bind multiple GSLB Services to this GSLB vServer, then you can optionally check the box for Send all “active” service IPs. By default, GSLB only gives out one IP per DNS query. This checkbox always returns all IPs, but the IPs are ordered based on the GSLB Load Balancing Method and/or GSLB Persistence.
If you configure GSLB to use Static Proximity Load Balancing Method, a new DNS feature called ECS will contain the actual DNS client IP. This dramatically improves the accuracy of determining a user’s location. Without this setting, GSLB can only see the IP address of the user’s configured DNS server instead of the real client IP.
Click OK.
On the left, click where it says No GSLB Virtual Server to GSLBService Binding.
Click the arrow next to Click to select.
Check the box next to an existing GSLB Service and click Select. If your GSLB is active/passive then only bind one service.
If your GSLB is active/active then bind multiple GSLB Services. Also, you’d probably need to configure GSLB persistence (Source IP or cookies).
Click Bind.
Click OK.
On the left, click where it says No GSLB Virtual Server Domain Binding.
Enter the FQDN that GSLB will resolve.
If this GSLB is active/passive, there are two options:
- Use the Backup IP field to specify the IP address that will be handed out if the primary NetScaler is inaccessible or if the VIP on the primary appliance is marked down for any reason.
- Or, create a second GSLB Virtual Server that has the passive GSLB service bound to it. Don’t bind a Domain to the second GSLB Virtual Server. Then edit the Active GSLB Virtual Server and use the Backup Virtual Server section to select the second GSLB Virtual Server.
Click Bind.
Click OK.
In the ADNS Service section, click OK.
If this is active/active GSLB, you can edit the Method section to enable Static Proximity. This assumes the Geo Location database has already been installed on the appliance.
Also for active/active, if you don’t want to use Cookie-based persistence, then you can use the Persistence section to configure Source IP persistence.
Click Done when done.
If you are configuring active/passive using the backup GSLB Virtual Server method, create a second GSLB Virtual Server that has the passive GSLB service bound to it. Don’t bind a Domain to the second GSLB Virtual Server.
Then edit the Active GSLB Virtual Server and use the Backup Virtual Server section to select the second GSLB Virtual Server.
On the left, if you expand Traffic Management > DNS, expand Records, and click Address Records, you’ll see a new DNS record for the GSLB domain you just configured. Notice it is marked as GSLB DOMAIN.
Configure identical GSLB Virtual Servers on the other NetScaler appliance. Both NetScalers must be configured identically.
You can also synchronize the GSLB configuration with the remote appliance by going to Traffic Management > GSLB.
On the right, click Synchronize configuration on remote sites.
Use the check boxes on the top, if desired. It’s usually a good idea to Preview the changes before applying them. Then click OK to begin synchronization.

Some notes regarding GSLB Sync:

It’s probably more reliable to do it from the CLI by running sync gslb config and one of the config options (e.g. -preview).
GSLB Sync runs as a script on the BSD shell and thus always uses the NSIP as the source IP.
GSLB Sync connects to the remote GSLB Site IP on TCP 3008 (if RPC is Secure) and TCP 22.

Test GSLB

To test GSLB, simply point nslookup to the ADNS services and submit a DNS query for one of the DNS names bound to a GSLB vServer. Run the query multiple times to make sure you’re getting the response you expect.
Both NetScaler ADNS services should be giving the same response.
To simulate a failure, disable the traffic Virtual Server.
Then the responses should change. Verify on both ADNS services.
Re-enable the traffic Virtual Server, and the responses should return to normal.

DNS Delegation

If you are enabling GSLB for the domain gateway.corp.com, you’ll need to create a delegation at the server that is hosting the corp.com DNS zone. For public GSLB, you need to edit the public DNS zone for corp.com.

DNS Delegation instructions will vary depending on what product host’s the public DNS zone. This section details Microsoft DNS, but it should be similar in BIND or web-based DNS products.

There are two ways to delegate GSLB-enabled DNS names to NetScaler ADNS:

Delegate the individual record. For example, delegate gateway.corp.com to the two NetScaler ADNS services (gslb1.corp.com and gslb2.corp.com).
Delegate an entire subzone. For example, delegate the subzone gslb.corp.com to the two NetScaler ADNS services. Then create a CNAME record in the parent DNS zone for gateway.corp.com that is aliased to gateway.gslb.corp.com. When DNS queries make it to NetScaler, they will be for gateway.gslb.corp.com and thus gateway.gslb.corp.com needs to be bound to the GSLB Virtual Server instead of gateway.corp.com. For additional delegations, simply create more CNAME records.

This section covers the first method – delegating an individual DNS record:

Run DNS Manager.
First, create Host Records pointing to the ADNS services running on the NetScalers in each data center. These host records for ADNS are used for all GSLB delegations no matter how many GSLB delegations you need to create.
The first Host record is gslb1 (or similar) and should point to the ADNS service (Public IP) on one of the NetScaler appliances.
The second Host record is gslb2 and should point to the ADNS Service (public IP) on the other NetScaler appliance.
If you currently have a host record for the service that you are delegating to GSLB (gateway.corp.com), delete it.
Right-click the parent DNS zone and click New Delegation.
In the Welcome to the New Delegation Wizard page, click Next.
In the Delegated Domain Name page, enter the left part of the DNS record that you are delegating (e.g. gateway). Click Next.
In the Name Servers page, click Add.
This is where you specify gslb1.corp.com and gslb2.corp.com. Enter gslb1.corp.com and click Resolve. Then click OK. If you see a message about the server not being authoritative for the zone, ignore the message.
Then click Add to add the other GSLB ADNS server.
Once both ADNS servers are added to the list, click Next.
In the Completing the New Delegation Wizard page, click Finish.
If you run nslookup against your Microsoft DNS server, it will respond with Non-authoritative answer. That’s because it got the response from NetScaler and not from itself.

That’s all there is to it. Your NetScalers are now DNS servers. For active/passive, the NetScalers will hand out the public IP address of the primary data center. When the primary data center is not accessible, GSLB will hand out the GSLB Service IP bound to the Backup GSLB vServer.

Geo Location Database

If you want to use DNS Policies or Static Proximity GSLB Load Balancing or Responders based on user’s location, import a geo location database.

NetScaler has a built-in database at /var/netscaler/inbuilt_db/ that you can use. Or you can download a database. Common free databases are:

GeoLite Legacy – http://dev.maxmind.com/geoip/legacy/geolite/
IP2Location Lite – http://lite.ip2location.com/

For IP2Location, see the blog post Add IP2Location Database as NetScaler’s Location File for instructions on how to import.

To Download GeoLite Legacy:

Download the GeoLite Country database CSV from http://dev.maxmind.com/geoip/legacy/geolite/.
Note: GeoLite City is actually two files that must be merged as detailed at Citrix Blog Post GeoLite City as NetScaler location database. GeoLite Country doesn’t need any preparation.
Upload the extracted database (.csv file) to the NetScaler appliance at /var/netscaler/locdb.

To import the Geo database (including the built-in database):

In the NetScaler GUI, on the left, expand AppExpert, expand Location, and click Static Databases.
On the right, click Add.
Change the Import From selection to File.
Click Choose File.
For the built-in database, browse to /var/netscaler/inbuilt_db/ and open Citrix_NetScaler_InBuilt_GeoIP_DB.csv. To browse to the directory, select var and then click Open. Repeat for each directory until you reach /var/netscaler/inbuilt_db.
Or browse to the Geo Location database file you uploaded and open it.
In the Location Format field, if using the built-in database, select netscaler and click Create.
If using GeoLite Country, select geoip-country and click Create.
When you open a GSLB Service, the public IP will be translated to a location.

You can use the Geo locations in a DNS Policy, static proximity GSLB Load Balancing, or Responders:

Citrix Knowledgebase article CTX130701 – How to Block Access to a Website Using a Location Database Based on User’s Country
Neil Spellings blog post – Using Netscaler HTTP callouts for real-time GeoIP and anonymous proxy detection
Citrix Docs – Overriding Static Proximity Behavior by Configuring Preferred Locations

↧

NetScaler Gateway 11.1 – RDP Proxy

July 4, 2016, 11:24 am

≫ Next: SmartAccess / SmartControl – NetScaler 11.1

≪ Previous: Global Server Load Balancing (GSLB) – NetScaler 11.1

RDP Proxy

NetScaler supports RDP Proxy through NetScaler Gateway. No VPN required. In 11.1 and newer, RDP can connect to Gateway on 443. In older NetScaler, RDP connects on 3389.

There are several ways of launching RDP sessions through NetScaler Gateway RDP Proxy:

Bookmarks on the Clientless Access portal page.
- Bookmarks can be defined by the administrator.
- Or users can add their own RDP bookmarks.
After logging in, change the URL in the browser to /rdpproxy/MyRDPServer. MyRDPServer can be IP or DNS.
In the RfWebUI Portal Theme, the Add Bookmark link lets users enter an RDP address, and click Go.

The easy configuration is for one Gateway to do both authentication and RDP Proxy. Alternatively, you can have one Gateway vServer that authenticates the user and a different Gateway vServer to proxy the RDP connection. The Gateways use Secure Ticket Authority (STA) for mutual authentication. See Stateless RDP Proxy at docs.citrix.com for more information.

Links:

RDP Proxy at Citrix Docs
Kenny Baldwin blog post RDP-Proxy on NetScaler!
Citrix Blog Post RDP Gateway on a NetScaler SSLVPN Virtual Server
Citrix CTX200853 How to Configure RDP Profile on NetScaler Gateway
RDP Proxy section in Unified Gateway FAQ at docs.citrix.com
Anton van Pelt NetScaler Gateway = RD Gateway

Here are some requirements for RDP Proxy:

NetScaler Enterprise Edition or Platinum Edition.
NetScaler Gateway Universal Licenses for each user.
TCP 443 opened to the NetScaler Gateway Virtual Server. If older NetScaler, open TCP 3389 to the Gateway.
TCP 3389 opened from the NetScaler SNIP to the RDP Servers.

Do the following to configure RDP Proxy:

Go to System > Settings, and click Configure Advanced Features.
Check the box for RDP Proxy, and click OK.
Expand NetScaler Gateway, expand Policies, and click RDP.
On the right, switch to the Client Profiles tab, and click Add.
Give the Client Profile a name, and configure it as desired. Scroll down.
It is no longer necessary to configure a Pre shared key or RDP Host. Just click Create.
It is no longer necessary to create a RDP Server Profile.
If you want to put RDP bookmarks on the Clientless Access portal page, on the left, expand NetScaler Gateway, expand Resources, and click Bookmarks.
Alternatively, Simon Gottschlag Publish RDP Proxy Link via StoreFront shows how NetScaler Rewrite can insert an RDP Proxy link into a StoreFront web page.
On the right, click Add.
Give the Bookmark a name.
For the URL, enter rdp://MyRDPServer using IP or DNS.
Check the box next to Use NetScaler Gateway As a Reverse Proxy, and click Create.
Create more bookmarks as desired.
Create or edit a Session Profile/Policy.
On the Security tab, set Default Authorization Action to ALLOW. Or you can use Authorization policies to control access.
On the Remote Desktop tab, Override Global and select the RDP Client Profile you created earlier.
If you want to use Bookmarks, on the Client Experience tab, set Clientless Access to On.
On the Published Applications tab, make sure ICA Proxy is OFF.
Edit or Create your Gateway Virtual Server.
In the Basic Settings section, click More.
It is no longer necessary to bind a RDP Server Profile. Instead, RDP is proxied through 443 on the Gateway.
Scroll down. Make sure ICA Only is not checked. This means you’ll need NetScaler Gateway Universal licenses for each user that connects through this Gateway.
Bind a certificate.
Bind authentication policies.
Bind the session policy/profile that has the RDP Client Profile configured.
You can bind Bookmarks to either the NetScaler Gateway Virtual Server, or to a AAA group. To bind to the NetScaler Gateway Virtual Server, on the right, in the Advanced Settings section, click Published Applications.
On the left, in the Published Applications section, click where it says No Url.
While editing your Gateway vServer, you can also enable the new RfWebUI Portal Theme. This requires StoreFront to be 3.6 or newer.
Bind your Bookmarks.
Since this NetScaler Gateway Virtual Server has ICA Only unchecked, make sure your NetScaler Gateway Universal licenses are configured correctly. On the left, expand NetScaler Gateway and click Global Settings.
On the right, click Change authentication AAA settings.
Change the Maximum Number of Users to your licensed limit.
If you want to connect to RDP servers using DNS, make sure DNS servers are configured on the appliance (Traffic Management > DNS > Name Servers).
If you want to use the short names instead of FQDNs, add a DNS Suffix (Traffic Management > DNS > DNS Suffix).
Connect to your Gateway and login.
If you configured Bookmarks, if RfWebUI theme, on the Apps tab, click Web and SaaS Apps.
If X1 theme, the bookmarks are on the Web Apps page.
Then click the Bookmark. If RfWebUI theme, you can also click Details to mark the Bookmark as a Favorite.
Or you can change the address bar to /rdpproxy/MyRDPServer. You can enter an IP address (e.g. rdpproxy/192.168.1.50) or a DNS name (/rdpproxy/myserver).
If you edit the downloaded .rdp file, notice that it’s connecting on port 443.
Then open the downloaded .rdp file.
You can view the currently connected users by going to NetScaler Gateway > Policies > RDP, and on the right is the Connections tab.
If using the RfWebUI theme, another way to launch RDP sessions is to click the Add Bookmark link, enter a destination DNS/IP, check the box next to RDP Link, and click Go.
You can also Save the bookmark.
Then access the saved bookmark from Apps > Personal Bookmarks.
The X1 theme has an Add button on the Web Apps page.
But there is no Go button. Instead, you save the Bookmark and launch it from the list.

↧

SmartAccess / SmartControl – NetScaler 11.1

July 4, 2016, 3:57 pm

≫ Next: Director Load Balancing – NetScaler 11.1

≪ Previous: NetScaler Gateway 11.1 – RDP Proxy

Navigation

= Recently Updated

SmartAccess / SmartControl

SmartAccess and SmartControl let you change ICA connection behavior (e.g. disable client device mappings) based on how users connect. Decisions are based on NetScaler Gateway Virtual Server name, Session Policy name, and Endpoint Analysis scan success or failure.

SmartAccess can also control application/desktop icon visibility.

Prerequisites

Both SmartAccess and SmartControl have the same prerequisites. You can configure SmartAccess in XenApp/XenDesktop at any time, but it won’t work, until you do the following:

On the NetScaler, go to System > Licenses and make sure you have NetScaler Gateway Universal Licenses allocated to the appliance. The Universal licenses are allocated to the hostname of the appliance (click the gear icon), not the MAC address. In a High Availability pair, if each node has a different hostname then you can allocate the licenses to one hostname, then reallocate to the other hostname.
After installing licenses, go to NetScaler Gateway > Global Settings.
On the top right, click Change authentication AAA settings.
At the top of the page, change the Maximum Number of Users to match your installed license count. Then click OK. This setting is commonly missed, and if not configured, it defaults to only 5 concurrent connections.
On a XenApp/XenDesktop Controller, run PowerShell as Administrator.
Run asnp citrix.* to load the snapins.
Run Set-BrokerSite -TrustRequestsSentToTheXmlServicePort $true to enable Trust XML.
In StoreFront Console, edit the existing Gateway object.
Make sure a Callback URL is configured. The Callback URL must resolve to a NetScaler Gateway VIP on the same appliance that authenticated the user. The Callback Gateway’s certificate must match the FQDN entered here. If you are configuring Single FQDN for internal and external, then the Callback FQDN must be different than the Single FQDN.
On the NetScaler, go to NetScaler Gateway > Virtual Servers, and edit your Gateway Virtual Server.
In the Basic Settings section, click the pencil icon.
Click More.
Uncheck the box next to ICA Only, and click OK. This tells NetScaler Gateway to start using Universal licenses, and enables the SmartAccess and SmartControl features.

Once the prerequisites are in place, do the following as detailed below:

Optionally, configure Endpoint Analysis.
Configure either SmartControl or SmartAccess.

Endpoint Analysis

Endpoint Analysis scans are completely optional. You can configure SmartControl and SmartAccess without implementing any Endpoint Analysis.

Endpoint Analysis is supported on Windows and Mac devices. Other devices, like iOS and Android, do not support Endpoint Analysis. If you want to allow mobile device connectivity, then make sure you have an access mechanism (e.g. ICA Proxy) that works if the Endpoint Analysis scan fails.

There are two methods of Endpoint Analysis: pre-authentication and post-authentication. For pre-authentication, configure an Endpoint Analysis expression in a Preauthentication Policy. For post-authentication, configure the Endpoint Analysis expression on one or more Session Policies.

With a Preauthentication Policy, if the Endpoint Analysis scan fails, then users can’t login.
With a Postauthentication Policy, Endpoint Analysis doesn’t run until after the user logs in. Typically, you create multiple Session Policies. One or more Session Policies has Endpoint Analysis expressions. Leave one policy without an Endpoint Analysis expression so there’s a fallback in case the client device doesn’t support Endpoint Analysis (e.g. mobile devices). The name of the Session Policy is then used later in Citrix Policies and Citrix Delivery Groups.

NetScaler has two Endpoint Analysis engines: the classic Client Security engine, and the newer OPSWAT Advanced EPA engine.

To configure OPSWAT Advanced EPA expressions:

When creating a Preauthentication Policy or Session Policy, click the OPSWAT EPA Editor link.
Use the drop-down menus to select the scan criteria. Then click Done.

See the following links for more Advanced EPA information:

Advanced Endpoint Analysis Policy Expression Reference at Citrix Docs
Citrix Blog Post Patch Management Endpoint Analysis on NetScaler Gateway

To configure Client Security expressions:

When creating a Preauthentication Policy or Session Policy, click the Expression Editor link.
Change the Expression Type to Client Security.
Use the Component drop-down to select a component. A common configuration is to check for domain membership as detailed at CTX128040 How to Configure a Registry-Based Scan Expression to Look for Domain Membership.

You can also use EPA expressions when configuring a Quarantine Group.

Once the Preauthentication and/or Session Policies are created, bind them to your NetScaler Gateway Virtual Server:

Edit a NetScaler Gateway Virtual Server.
Scroll down to the Policies section, and click the plus icon.
Select either Preauthentication or Session, and select the policy you already created. Then click Bind.

EPA Troubleshooting

Citrix CTX209148 Understanding/Configuring EPA Verbose Logging Feature:

Go to NetScaler Gateway > Global Settings.
On the right, click Change Global Settings.
On the Security tab, click Advanced Settings.
Scroll down, check the box next to Enable Client Security Logging, and click OK.
When the scan fails, the user is presented with a Case ID.
You can then grep /var/log/ns.log for the Case ID. Or search your syslog.

To determine why your EPA scans fail, on the client machine, go to HKEY_LOCAL_MACHINE\SOFTWARE\Citrix\Secure Access Client.
Make a DWORD value named “EnableEPALogging“, and set the value to 1.

After attempting the scan again, you’ll find the file %localappdata%\Citrix\AGEE\epaHelper_epa_plugin.txt with details for each scan expression.

NetscalerAssasin EPA OPSWAT Packet flow and Troubleshooting shows a Wireshark trace of an EPA scan.

SmartControl

The SmartControl feature lets you configure some of the SmartAccess functionality directly on the appliance. See Configuring SmartControl at Citrix Docs for detailed instructions.

If you are using a Preauthentication Policy to run an Endpoint Analysis scan, edit the Preauthentication Profile.
Configure the Default EPA Group with a new group name. You’ll use this group name later.
If you are instead using a Session Policy/Profile to run the post-authentication Endpoint Analysis scan, edit the Session Profile, on the Security tab, use the Smartgroup field to define a group name for users that pass the scan. You’ll use this group name later.
On the left, expand NetScaler Gateway, expand Policies, and click ICA.
On the right, switch to the Access Profiles tab, and click Add.
Configure the restrictions as desired, and click Create.
Switch to the ICA Action tab, and click Add.
Give the Action a name. Select the ICA Access Profile. Click Create.
Switch to the ICA Policies tab, and click Add.
Select the previously created ICA Action.
Enter an expression. You can use HTTP.REQ.USER.IS_MEMBER_OF(“MyGroup”).NOT where MyGroup is the name of the SmartGroup you configured in the session profile or preauth scan. Click Create when done.
Edit your Gateway Virtual Server.
Scroll down to the Policies section, and click the plus icon.
Change the Policy Type to ICA, and click Continue.
Select the SmartControl policy you created earlier, and click Bind.

SmartAccess

CTX138110 How to Configure the SmartAccess feature on Access Gateway Enterprise Edition Appliance

In XenApp/XenDesktop, edit a Citrix policy, and add the Access Control filter. If you are using GPO to deliver Citrix Policies, then only Citrix Policies in the user half of the GPO support Access Control filters.

You can leave the default wildcards for farm name and condition to match all NetScaler Gateway connections. Or you can match specific NetScaler Gateway / Session Policy connections:

AG farm name = name of the NetScaler Gateway Virtual Server.
Access condition = name of the NetScaler Gateway Session Policy.

You typically create a Citrix policy to turn off all client device mappings for all external users. Then you create a higher priority Citrix policy that re-enables client device mappings for those users that passed the Endpoint Analysis scan expression on a particular Session Policy.

If you edit a Delivery Group, there’s an Access Policy page where you can hide or show the Delivery Group for all NetScaler Gateway connections, or for specific NetScaler Gateway Virtual Server / Session Policy connections.

Site or Farm name = NetScaler Gateway Virtual Server name
Filter = NetScaler Gateway Session Policy name

This configuration is only available at the entire Delivery Group. It is not possible to perform this configuration for only specific published applications, unless they are on different Delivery Groups.

↧

Director Load Balancing – NetScaler 11.1

July 5, 2016, 4:57 am

≫ Next: NetScaler Insight Center 11.1

≪ Previous: SmartAccess / SmartControl – NetScaler 11.1

Navigation

Monitor

On the left, expand Traffic Management, expand Load Balancing, and click Monitors.
On the right, click Add.
Name it Director or similar.
Change the Type drop-down to HTTP.
If you will use SSL to communicate with the Director servers, then scroll down and check the box next to Secure.
Switch to the Special Parameters tab.
In the HTTP Request field, enter GET /Director/LogOn.aspx?cc=true
Click Create.

Servers

On the left, expand Traffic Management, expand Load Balancing, and click Servers.
On the right, click Add.
Enter a descriptive server name. Usually it matches the actual server name.
Enter the IP address of the server.
Enter comments to describe the server. Click Create.
Continue adding Director servers.

Service Group

On the left, expand Traffic Management, expand Load Balancing, and click Service Groups.
On the right, click Add.
Give the Service Group a descriptive name (e.g. svcgrp-Director-SSL).
Change the Protocol to HTTP or SSL. If the protocol is SSL, ensure the Director Monitor has Secure enabled.
Scroll down, and click OK.
Click where it says No Service Group Member.
If you did not previously create server objects, then enter the IP address of a Director Server. If you previously created server objects, then change the selection to Server Based, and select the server objects.
Enter 80 or 443 as the port. Then click Create.
Click OK.
On the right, under Advanced Settings, click Monitors.
On the left, in the Monitors section, click where it says No Service Group to Monitor Binding.
Click the arrow next to Click to select.
Select the Director monitor, and click Select.
Then click Bind.
To verify that the monitor is working, on the left, in the Service Group Members section, click the Service Group Members line.
Highlight a member, and click Monitor Details.
The Last Response should be Success – HTTP response code 200 received. Click Close twice.
Then click Done.

Responder

Create a Responder policy to redirect users from the root page to /Director.

Go to AppExpert > Responder, and enable the feature if it isn’t already enabled.
Go to AppExpert > Responder > Actions.
On the right, click Add.
Give the Action a name (e.g. Director_Redirect).
Change the Type to Redirect.
In the Expression box, enter "/Director", including the quotes.
Click Create.
Go to AppExpert > Responder > Policies.
On the right, click Add.
Give the Policy a name (e.g. Director_Redirect).
Select the previously created Action.
In the Expression box, enter HTTP.REQ.URL.PATH.EQ("/")
Click Create.

Load Balancing Virtual Server

Create or install a certificate that will be used by the SSL Virtual Server. This certificate must match the DNS name for the load balanced Director servers.
On the left, under Traffic Management > Load Balancing, click Virtual Servers.
On the right, click Add.
Name it lbvip-Director-SSL or similar.
Change the Protocol to SSL.
Specify a new internal VIP.
Enter 443 as the Port.
Click OK.
On the left, in the Services and Service Groups section, click where it says No Load Balancing Virtual Server ServiceGroup Binding.
Click the arrow next to Click to select.
Select your Director Service Group, and click Select.
Click Bind.
Click Continue.
Click where it says No Server Certificate.
Click the arrow next to Click to select.
Select the certificate for this Director Load Balancing Virtual Server, and click Select.
Click Bind.
Click Continue.
On the right, in the Advanced Settings column, click Persistence.
Select COOKIEINSERT persistence.
Set the Time-out to 0 minutes. This makes it a session cookie.
Set the Backup Persistence to SOURCEIP.
Set the Backup Time-out to match the timeout of Director. The default timeout for Director is 245 minutes.
The IPv4 Netmask should default to 32 bits.
Click OK.
On the right, in the Advanced Settings section, add the Policies section.
On the left, in the Policies section, click the plus icon.
Select Responder in the Choose Policy drop-down, and click Continue.
Select the previously created Director_Redirect policy, and click Bind.

If you haven’t enabled the Default SSL Profile, then perform other normal SSL configuration including: disable SSLv3, bind a Modern Cipher Group, and enable Strict Transport Security.

bind ssl vserver MyvServer -certkeyName MyCert

set ssl vserver MyvServer -ssl3 DISABLED -tls11 ENABLED -tls12 ENABLED

unbind ssl vserver MyvServer -cipherName ALL

bind ssl vserver MyvServer -cipherName Modern

bind ssl vserver MyvServer -eccCurveName ALL

bind lb vserver MyvServer -policyName insert_STS_header -priority 100 -gotoPriorityExpression END -type RESPONSE

SSL Redirect

Do one of the following to configure a redirect from HTTP to HTTPS:

Add a new HTTP load balancer on port 80 and use Responder to redirect.
Edit the existing SSL vServer and enable Redirect.
Add a new HTTP load balancer on port 80 and configure the Redirect URL.

SSL Warning

If you are doing SSL Offload (SSL on front end, HTTP on back end), when connecting to Director, it might complain about “You are not using a secure connection”.
To turn off this warning, login to the Director servers, and run IIS Manager.
On the left, navigate to Server > Sites > Default Web Site > Director.
In the middle, double-click Application Settings.
Change UI.EnableSslCheck to false.

CLI Commands

Here is a list of NetScaler CLI commands for Director Load Balancing:

add server Director01 10.2.2.18
add server Director02 10.2.2.100
add server 127.0.0.1 127.0.0.1
add service AlwaysUp 127.0.0.1 HTTP 80
add serviceGroup svcgrp-Director-HTTP HTTP
add ssl certKey wildcom -cert WildcardCorpCom_pem -key WildcardCorpCom_pem
add lb vserver lbvip-Director-SSL SSL 10.2.2.210 443 -persistenceType SOURCEIP -timeout 245
add lb vserver lbvip-Director-HTTP-SSLRedirect HTTP 10.2.2.210 80 -persistenceType NONE
add responder action Director_Redirect redirect "\"/Director\"" -responseStatusCode 302
add responder action http_to_ssl_redirect_responderact redirect "\"https://\" + HTTP.REQ.HOSTNAME.HTTP_URL_SAFE + HTTP.REQ.URL.PATH_AND_QUERY.HTTP_URL_SAFE" -responseStatusCode 302
add responder policy Director_Redirect "http.REQ.URL.PATH.EQ(\"/\")" Director_Redirect
add responder policy http_to_ssl_redirect_responderpol HTTP.REQ.IS_VALID http_to_ssl_redirect_responderact
bind lb vserver lbvip-Director-HTTP-SSLRedirect AlwaysUp
bind lb vserver lbvip-Director-SSL svcgrp-Director-SSL
bind lb vserver lbvip-Director-SSL -policyName Director_Redirect -priority 100 -gotoPriorityExpression END -type REQUEST
bind lb vserver lbvip-Director-HTTP-SSLRedirect -policyName http_to_ssl_redirect_responderpol -priority 100 -gotoPriorityExpression END -type REQUEST
add lb monitor Director HTTP -respCode 200 -httpRequest "GET /Director/LogOn.aspx?cc=true" -LRTM DISABLED -secure YES
bind serviceGroup svcgrp-Director-SSL Director01 443
bind serviceGroup svcgrp-Director-SSL Director02 443
bind serviceGroup svcgrp-Director-SSL -monitorName Director
set ssl serviceGroup svcgrp-Director-SSL -tls11 DISABLED -tls12 DISABLED
bind ssl vserver lbvip-Director-SSL -certkeyName wildcom
bind ssl vserver lbvip-Director-SSL -eccCurveName P_256
bind ssl vserver lbvip-Director-SSL -eccCurveName P_384
bind ssl vserver lbvip-Director-SSL -eccCurveName P_224
bind ssl vserver lbvip-Director-SSL -eccCurveName P_521

↧

NetScaler Insight Center 11.1

July 5, 2016, 9:29 am

≫ Next: nFactor Authentication for NetScaler Gateway 11.1

≪ Previous: Director Load Balancing – NetScaler 11.1

Navigation

This page contains the following topics:

Planning
Import Appliance into vSphere
IP Configuration and Multi-Node
Initial Web Configuration
NSroot Password
Management Certificate
System Configuration
Email Notifications
Authentication
Thresholds
Geo Map
Director Integration
Use Insight Center – HDX Insight, Gateway Insight, Security Insight
Troubleshooting
Upgrade Insight Center

= Recently Updated

Planning

Note: HDX Insight only works with Session Reliability on NetScaler 10.5 build 54 or newer. Older builds, including NetScaler 10.1, do not support Session Reliability with HDX Insight. Read the release notes for your NetScaler firmware build to see the latest known issues with AppFlow, Session Reliability, and High Availability.

Requirements for HDX Insight:

Your NetScaler appliance must be running Enterprise Edition or Platinum Edition.
NetScaler must be 10.1 or newer. Insight Center 11.1 does work with NetScaler 10.5 and NetScaler 11.0.
HDX Insight works with the following Receivers:
- Receiver for Windows must be 3.4 or newer.
- Receiver for Mac must be 11.8 or newer.
- Receiver for Linux must be 13 or newer.
- Notice no mobile Receivers. See the Citrix Receiver Feature Matrix for the latest details.
ICA traffic must flow through a NetScaler appliance:
- One method is to implement ICA Proxy through NetScaler Gateway. You can even do this internally. However Single Sign-on does not work through NetScaler Gateway. To use ICA Proxy without authenticating at NetScaler Gateway, see CTX200129 – How to Force Connections through NetScaler Gateway Using Optimal Gateways Feature of StoreFront.
- Another method is to route ICA traffic through a NetScaler SNIP and use the NetScaler as a router. Citrix Blog Post – How to Deploy NetScaler Insight Center with Policy Based Routing
- Citrix Docs How NetScaler Insight Center is Deployed in a Network – Transparent Mode, NetScaler Gateway Single-Hop and Double-Hop, LAN User Mode (NetScaler as SOCKS Proxy), CloudBridge, Multi-Hop (NetScaler and CloudBridge with connection chaining)
- New in NetScaler 11 is the ability to use SOCKS proxy (Cache Redirection) for ICA traffic without requiring users to use NetScaler Gateway and without making any routing changes. You configure this on the NetScaler appliance. See Citrix Blog Post Gathering HDX Insight Analytics for LAN Users with NetScaler Using SOCKS for more information.

For ICA round trip time calculations, in a Citrix Policy, enable the following settings:

ICA > End User Monitoring > ICA Round Trip Calculation
ICA > End User Monitoring > ICA Round Trip Calculation Interval
ICA > End User Monitoring > ICA Round Trip Calculation for Idle Connections

Citrix CTX204274 How ICA RTT is calculated on NetScaler Insight: ICA RTT constitutes the actual application delay. ICA_RTT = 1 + 2 + 3 + 4 +5 +6:

Client OS introduced delay
Client to NS introduced network delay (Wan Latency)
NS introduced delay in processing client to NS traffic (Client Side Device Latency)
NS introduced delay in processing NS to Server (XA/XD) traffic (Server Side Device Latency)
NS to Server network delay (DC Latency)
Server (XA/XD) OS introduced delay (Host Delay)

The version/build of Insight Center must be the same or newer than the version/build of the NetScaler appliances.

Citrix whitepaper – NetScaler Insight Center Deployment & Sizing Guide: virtual machine sizing, firewall rules, licensing, Receiver versions, etc.

Import Appliance

You can use either the vSphere Client or the vSphere Web Client to import the appliance. In vSphere Client, open the File menu and click Deploy OVF Template. vSphere Web Client instructions are shown below.

You might see this operating system error when not using the vSphere Web Client. Click Yes and proceed. It seems to work.

Download Insight Center for ESX, and then extract the .zip file.
In vSphere Web Client, right-click a cluster, and click Deploy OVF Template.
In the Select source page, if you see a message regarding the Client Integration Plug-in, download the installer, run it, and then return to this wizard.
In the Select source page, select Local file, and browse to the NetScaler Insight .ovf file. Click Next.
In the Review details page, click Next.
In the Select name and folder page, enter a name for the virtual machine and select an inventory folder. Then click Next.
In the Select a resource page, select a cluster or resource pool and click Next.
In the Select storage page, change it to Thin Provision.
Select a datastore and click Next.
In the Setup networks page, choose the same valid port group for both NICs. Click Finish.
In the Ready to Complete page, click Finish.
View the progress of the import in the Recent Tasks pane at the top-right of the window.
After the appliance is imported, power it on.

IP Configuration and Multi-Node

Open the console of the virtual machine and configure an IP address.
Enter 7 when done.
When prompted for Insight Deployment Type, enter 1 for NetScaler Insight Server. The first appliance must always be NetScaler Insight Server.
Enter Yes to reboot.

Initial Web Configuration – Add Devices

Point your browser to the Insight IP address and login as nsroot/nsroot.
If you see the Customer User Experience Improvement Program, click Skip or Enable.
Click Get Started
Enter the IP address and credentials of a NetScaler appliance.
Check the box next to NetScaler Gateway, and click Add. Note: Insight Center 11.1 defaults to using https for the NSIP communication.
At the top of the page, if desired, check the box next to Enable Geo data collection for Web and HDX Insight.
With Load Balancing selected in the View list, click the ellipsis next to your StoreFront load balancer, and click Enable AppFlow.
Type in true, and click OK.
Note: if your StoreFront Load Balancing vServer uses Service Groups, you might need to enable AppFlow logging on the Service Group. In the NetScaler GUI, edit the Service Group. In the Basic Settings section, check the box next to AppFlow Logging.
Back in Insight Center, use the View drop-down to select VPN.
Click the ellipsis next to a NetScaler Gateway Virtual Server, and click Enable AppFlow.
In the Select Expression drop-down, select true.
For Export Option, select ICA, HTTP, and click OK. The HTTP option is for Gateway Insight.
The TCP option is for the second appliance in double-hop ICA. If you need double-hop, then you’ll also need to run set appflow param -connectionChaining ENABLED on both appliances. See Enabling Data Collection for NetScaler Gateway Appliances Deployed in Double-Hop Mode at Citrix Docs for more information.
New in NetScaler 11 is the ability to use SOCKS proxy (Cache Redirection) for ICA traffic without requiring users to use NetScaler Gateway and without making any routing changes. You configure this on the NetScaler appliance. See Enabling Data Collection for Monitoring NetScaler ADCs Deployed in LAN User Mode at Citrix Docs for more information.
If you want to add more appliances, click the Configuration tab. The Inventory node will be selected by default.
On the right, click Add.

Citrix Blog Post – NetScaler Insight Center – Tips, Troubleshooting and Upgrade

Nsroot Password

On the Configuration tab, expand System, expand User Administration, and click Users.
On the right, highlight the nsroot account, and click Edit.
Enter a new password.
You can also specify a session timeout. Click OK.

Management Certificate

The certificate to upload must already be in PEM format. If you have a .pfx, you must convert it to PEM (separate certificate and key files). You can use NetScaler to convert the .pfx, and then download the converted certificate from the appliance.

On the left, switch to the System node.
In the right pane, in the left column, click Install SSL Certificate.
Browse to the PEM format certificate and key files. If the keyfile is encyrpted, enter the password. Click OK.
Click Yes to reboot the system.

System Configuration

Click the Configuration tab on the top of the page.
On the left, click the System node.
On the right, modify settings as desired. Start with Configure Global Settings.
At the top of the page, configure the Time Zone.
If you scroll down, there’s a Enable Session Timeout option. Click OK when done.
The ICA Session Timeout can be configured by clicking the link. Two minutes of non-existent traffic must occur before the session is considered idle. Then this idle timer starts. See Managing ICA Sessions at Citrix Docs for more information
On the left, expand System, and click NTP Servers.
On the right, click Add.
Enter an NTP address, and click Create.
Click Yes to confirm.
After adding NTP servers, click NTP Synchronization.
Check the box next to Enable NTP Sync, and click OK.
Click Yes to restart.
On the left, expand Auditing, and click Syslog Servers.
On the right, click Add.
Enter the syslog server IP address, and select Log Levels. Click Create.
On the right, you can click Syslog Parameters to change the timezone and date format.

Email Notifications

On the left, expand System, expand Notifications, and click Email.
On the right, on the Email Servers tab, click Add.
Enter the SMTP server address, and click Create.
On the right, switch to the Email Distribution List tab, and click Add.
Enter an address for a destination distribution list, and click Create.
If you click Notifications on the left, on the right, there’s Change Notification Settings.
Choose the notifications you wish to receive by moving them from left to right.
In the Email drop-down, select the Distribution List you created earlier.
Click OK when done.

Authentication

On the left, expand System¸ expand Authentication, and click LDAP.
On the right, click Add.
This is configured identically to NetScaler. Enter a Load Balancing VIP for LDAP. Change the Security Type to SSL, and Port to 636. Scroll down.
Enter the bind account.
Check the box for Enable Change Password.
Click Retrieve Attributes and scroll down.
For Server Logon Attribute, select sAMAccountName.
For Group Attribute, select memberOf.
For Sub Attribute Name, select cn.
To prevent unauthorized users from logging in, configure a Search Filter. Scroll down.
If desired, configure Nested Group Extraction.
Click Create.
On the left, expand User Administration, and click Groups.
On the right, click Add.
Enter the case sensitive name of your NetScaler Admins group.
Select the admin Permission.
If desired, configure a Session Timeout. Click Create.
On the left, under System, click User Administration.
On the right, click User Lockout Configuration.
If desired, check the box next to Enable User Lockout, and configure the maximum logon attempts. Click OK.
On the left, under System, click Authentication.
On the right, click Authentication Configuration.
Change the Server Type to EXTERNAL, and click Insert.
Select the LDAP server you created earlier, and click OK.
Click OK.

Thresholds

Go to NetScaler Insight Center > Thresholds.
On the right, click Add.
Enter a name.
For Traffic Type, select HDX.
In the Entity drop-down, select a category of alerts. What you choose here determines what’s available in the Rule section.
Check the box to Enable Alert.
Check the box to Notify through Email.
In the Rule section, select a rule, and enter threshold values. Click Create.

Geo Map

Download the Maxmind database from http://geolite.maxmind.com/download/geoip/database/GeoLiteCity.dat.gz.
Extract the .gz file.
On the Configuration tab, expand NetScaler Insight Center, and click Geo Database Files.
On the right, click Upload.
Browse to the extracted GeoLiteCity.dat file and click Open.
Click the Inventory node.
Click the IP address for a device in the inventory.
Check the box to Enable Geo data collection for Web and HDX Insight.
You can define Geo locations for internal subnets. Go to NetScaler Insight Center > Private IP Block.
On the right, click Add.
Enter a name.
Enter the starting and ending IP address.
Select a Geo Location. Note that these are not necessarily alphabetical.
Click Create.

Director Integration

Integrating Insight Center with Director requires XenApp/XenDesktop to be licensed for Platinum Edition. The integration adds Network tabs to the Trends and Machine Details views.

If using HTTPS to connect to Insight Center, then the Insight Center certificate must be valid and trusted by both the Director Server and the Director user’s browser.

To link Citrix Director with NetScaler HDX Insight, on the Director server run C:\inetpub\wwwroot\Director\tools\DirectorConfig.exe /confignetscaler. Do this on both Director servers.

Use Insight Center

HDX Insight

HDX Insight Dashboard displays ICA session details including the following:

WAN Latency
DC Latency
RTT (round trip time)
Retransmits
Application Launch Duration
Client Type/Version
Bandwidth
Licenses in use

HDX Insight can also display Geo Maps. Configure Insight Center with Private IP Blocks.

More info at HDX Insight Reports and Use Cases: HDX Insight at Citrix Docs.

Gateway Insight

Insight Center has a new Gateway Insight dashboard.

This feature displays the following details:

Gateway connection failures due to failed EPA scans, failed authentication, failed SSON, or failed application launches.
Bandwidth and Bytes Consumed for ICA and other applications accessed through Gateway.
# of users
Session Modes (clientless, VPN, ICA)
Client Operating Systems
Client Browsers

More details at Gateway Insight at Citrix Docs.

Security Insight

The new Security Insight dashboard uses data from Application Firewall to display Threat Index (criticality of attack), Safety Index (how securely NetScaler is configured), and Actionable Information. More info at Security Insight at Citrix Docs.

Troubleshooting

Citrix Blog Post – NetScaler Insight Center – Tips, Troubleshooting and Upgrade

See Troubleshooting Tips at Citrix Docs. Here are sample issues covered in Citrix Docs:

Can’t see records on Insight Center dashboard
ICA RTT metrics are incorrect
Can’t add NetScaler appliance to inventory
Geo maps not displaying

Upgrade Insight Center

Download the latest Upgrade Pack for Insight Center.
Login to Insight Center.
If you are running Insight Center 10.5 or older, on the Configuration tab, go to NetScaler Insight Center > Software Images, and upload the file. If running Insight Center 11.0 or newer, you can skip this step.
On the Configuration tab, on the left, click the System node.
On the right, in the right pane, click Upgrade NetScaler Insight Center.
Browse to the build-analytics-11.1.tgz Software Image Upgrade Pack, and click OK.
Click Yes to reboot the appliance.
After it reboots, login. The new firmware version will be displayed in the top right corner.

↧

nFactor Authentication for NetScaler Gateway 11.1

July 6, 2016, 5:20 am

≫ Next: Horizon View Load Balancing – NetScaler 11.1

≪ Previous: NetScaler Insight Center 11.1

Navigation

Overview

nFactor lets you configure an unlimited number of authentication factors. You are no longer limited to just two factors. Each authentication factor performs the following tasks:

nFactor requests credentials from the user. These credentials can be anything supported by NetScaler including:
- SAML
- Certificate
- oAuth
- Kerberos
- Forms-based authentication (traditional web-based logon page) for LDAP, RADIUS, etc.
  - Multiple passwords can be collected with one form.
  - Or prompt the user multiple times throughout the authentication chain.
  - The logon page can contain a domain drop-down.
nFactor evaluates the credentials. The results can be:
- Authentication success
- Authentication failure
- Group extraction
- Attribute extraction from SAML, Certificate, etc.
Based on the evaluation results, do one of the following:
- Allow access
- Use authentication evaluation results to select next factor
- Deny access
Multiple factor evaluations can be chained together. The chosen next factor is based on the results of the prior factor. This can continue indefinitely. The next factor can do one of the following:
- Prompt the user for more credentials
- Evaluate the already entered next set of credentials
- Use policy expression to select another next factor (no authentication). This is typically used with group extraction so that groups determine the next factor.

Here are some nFactor use cases, but the combinations are almost limitless:

Authentication method based on Active Directory group: Logon screen asks for user name only. Extract user’s groups from Active Directory. Based on user’s Active Directory groups, either ask user for certificate, or ask user for LDAP password. If LDAP, the username doesn’t need to be entered again.
Ask for Certificate first:
- If certificate, perform LDAP
- If no certificate, perform LDAP + RADIUS
Two-factor with passwords checked in specific order: Logon screen with two password fields. Check the first password. If the first password succeeds, then check the second password. This lets you check RADIUS before LDAP.

You configure nFactor in the AAA feature, and then bind it to NetScaler Gateway Virtual Servers. Because of AAA, NetScaler Enterprise Edition is required.

Note: nFactor works with browser clients, but it does not work with Receiver Self-Service (native Receiver).

nFactor configuration summary (detailed instructions below):

The first factor (Advanced Authentication Policy and Login Schema) is bound directly to a AAA Virtual Server.
Next factors are Authentication Policy Labels that are chained to Advanced Authentication Policies in prior factors.
Authentication Profile links AAA nFactor with NetScaler Gateway.

AAA Virtual Server

Create AAA Virtual Server

To use nFactor with NetScaler Gateway, you first configure it on a AAA Virtual Server. Then you later bind the AAA Virtual Server to the NetScaler Gateway Virtual Server.

If AAA feature is not already enabled, go to Security > AAA, right-click AAA, and Enable Feature.
Go to Security > AAA > Virtual Servers.
On the right, click Add.
Give the Virtual Server a name.
If you are only using this AAA Virtual Server for NetScaler Gateway, then you can change the IP address Type to Non Addressable. It’s also possible to content switch to AAA.
Click OK.
In the Certificates section, click where it says No Server Certificate.
Click to select.
Select a certificate for the AAA Virtual Server, and click Select. Since this AAA Virtual Server is not directly addressable, the chosen certificate doesn’t matter.
Click Bind.
Click Continue.
You probably don’t have any Advanced Authentication Policies yet, so just click Continue.

AAA Portal Theme

If this AAA Virtual Server is used not just for NetScaler Gateway, but also for traffic management (Load Balancing, Content Switching), then you might want to change the AAA Portal theme.

Go to NetScaler Gateway > Portal Themes and add a theme.
After adjusting it as desired, at the top of the portal theme editing page, Click to Bind and View Configured Theme.
Change the selection to Authentication.
Use the Authentication Virtual Server Name drop-down to select the AAA Virtual Server, and click Bind and Preview.

Client Certificate Authentication

If one of your authentication Factors is certificate, then you must perform some SSL configuration on the AAA Virtual Server:

Go to Traffic Management > SSL > Certificates > CA Certificates, and install the root certificate for the issuer of the client certificates. Root certificates do not have a key file.
Go to Security > AAA > Virtual Servers, and edit an existing AAA Virtual Server.
On the left, in the SSL Parameters section, click the pencil icon.
If you don’t see this section, then Default SSL Profiles are probably enabled. You’ll need to create a custom SSL Profile at System > Profiles > SSL Profile. Unfortunately, it’s not possible to bind the custom SSL Profile to AAA vServer using the GUI, but you can do it using the CLI (set ssl vserver MyAAAvServerName -sslProfile MySSLProfileName)
Check the box next to Client Authentication.
Make sure Client Certificate drop-down is set to Optional, and click OK.
On the left, in the Certificates section, click where it says No CA Certificate.
Click to select.
Select the root certificate for the issuer of the client certificates, and click Select.
Click Bind.

Login Schema

Login Schema XML File

Login Schema is an XML file providing the structure of forms-based authentication logon pages.

nFactor implies multiple authentication Factors that are chained together. Each Factor can have different Login Schema pages/files. In some authentication scenarios, users could be presented with multiple logon screens.

Or you can have one Factor gather information that can be passed on to later Factors, so that the later Factors don’t need to display another Login Schema. This is particularly useful for traditional two-password logon screens (LDAP + RADIUS), since each password is evaluated in a separate Factor:

The first password is evaluated in the first factor (e.g. LDAP). If successful, then proceed to the second factor.
The second factor (e.g. RADIUS) evaluates the second password. However, the second password has already been entered, so there’s no need to ask the user for it again. To prevent a Login Schema from being shown to the user, select noschema (LSCHEMA_INT) in the Authentication Policy Label.

Several Login Schema .xml files are included with NetScaler under /nsconfig/loginschema/LoginSchema.

Note: Login Schemas seem to be missing from a fresh deployment of NetScaler 11.1. You can copy them from a NetScaler 11.0 appliance, or download them from the nFactor articles at support.citrix.com.

NetScaler 11.1 lets you edit the labels from within the GUI. When the labels are changed, NetScaler copies the Login Schema to a new .xml file.

Or you can use WinSCP to connect to the appliance, duplicate one of the existing .xml files, and edit it as desired. For example, you can configure fields (InitialValue tag) to pre-fill information from previous Factors, as shown below:

The login schema can also contain a domain drop-down. See CTX201760 nFactor – Domain Drop-Down in First Factor then Different Policy Evaluations Based on Groups for a sample configuration.

Login Schema Profile

To configure a Login Schema Profile:

Create or Edit a Login Schema .XML file based on your nFactor design.
Go to Security > AAA > Login Schema.
On the right, switch to the Profiles tab, and click Add.
In the Authentication Schema field, click the pencil icon.
Click the LoginSchema folder to see the files in it.
Select one of the files. You can see a preview on the right. The labels can be changed by clicking the Edit button on the top right.
When you Save the changes, a new file is created under /nsconfig/LoginSchema.
On the top right, click Select.
Give the Login Schema a name, and click More.
You typically need to use the entered credentials elsewhere. For example, you might need to use the username and one of the passwords to later Single Sign-on to StoreFront. Near the bottom of the Login Schema Profile, enter unique values for the indexes. These values can be between 1 and 16.
You can also configure these values on your noschema profiles so that passwords received from a previous factor can be put into a different Index.
Later you reference these index values in a Traffic Policy/Profile by using the expression HTTP.REQ.USER.ATTRIBUTE(#).
Click Create.
Note: if you later edit the Login Schema .xml file, the changes might not be reflected until you edit the Login Schema Profile and select the .xml file again

Login Schema Policy

Login Schemas can be bound directly to a AAA Virtual Server. If one of the Advanced Authentication policies bound directly to the AAA Virtual Server is forms-based, then bind the Login Schema directly to the AAA Virtual Server. If you are binding the Login Schema directly to a AAA Virtual Server, then you must first create a Login Schema Policy expression that is linked to the Login Schema Profile.

Or Login Schemas can be bound to an Authentication Policy Label (described later). If you are binding a Login Schema to an Authentication Policy Label, then there’s no need to create a Login Schema policy expression.

To create and bind a Login Schema Policy:

On the left, go to Security > AAA > Login Schema.
On the right, switch to the Policies tab, and click Add.
Use the Profile drop-down to select the Login Schema Profile you already created.
Enter a Default Syntax expression in the Rule box, and click Create.
On the left, go to Security > AAA > Virtual Servers, and edit an existing AAA Virtual Server.
On the right, in the Advanced Settings column, click Login Schemas.
On the left, in the Login Schemas section, click where it says No Login Schemas.
Click to select.
Select the Login Schema policy, and click Select. Only Login Schema Policies appear in this list. Login Schema Profiles (without a policy) do not appear.
Click Bind.

Advanced Authentication Policies

Authentication policies are a combination of policy expression and policy action. If the expression is true, then evaluate the action.

The Action is always an authentication server (LDAP, RADIUS, etc.).

The policy expression can be either in classic syntax, or in the newer default syntax.

The policy type is either Basic or Advanced. Basic policies can only use classic syntax. Advanced policies only use the newer default syntax. Both types of policies use the same Actions (authentication servers).

nFactor requires Advanced Authentication Policies; Basic policies won’t work.

Create Advanced Authentication Policy

You will need Authentication Actions/Servers (e.g. LDAP, RADIUS, CERT, SAML, etc.)

When creating an Advanced Authentication Policy, there’s a plus icon that lets you create Authentication Actions/Servers.

Or you can create Authentication Actions prior to creating the Advanced Authentication Policy. The Authentication Actions are located under the Security > AAA > Policies > Basic Policies > <Action Type> node. On the right, switch to the Servers tab to create the Actions/Servers. Once the Actions are created, use the instructions below to create the Advanced Authentication Policy. There’s no need to create a Basic Authentication Policy.

To create an Advanced Authentication Policy:

Go to Security > AAA > Authentication > Advanced Policies > Policy.
On the right, click Add. You typically create at least one Authentication Policy for each Factor. When you create multiple Authentication Policies for one Factor, NetScaler checks each policy in priority order until one of them succeeds.
Use the Action Type drop-down to select the Action Type (e.g. LDAP). The Action Type depends on your nFactor flow design.
If you don’t currently have any Actions configured, of if you want to create a new one, click the plus icon next to the Action drop-down. The Actions/Servers are created in the normal fashion.
In the Expression box, enter an expression using the Default Syntax. ns_true won’t work because that’s Classic syntax. There’s an Expression Editor link on the right. Or hit Ctrl+Space to see your options. true is a valid Default expression. Click Create when done.
Create more Advanced Authentication Policies as needed for your nFactor design.

Bind Advanced Authentication Policy to AAA

Only the Advanced Authentication Policies for the first Factor are bound directly to the AAA Virtual Server. The Advanced Authentication Policies for the remaining Factors are bound to Authentication Policy Labels as detailed in the next section.

Go to Security > AAA > Virtual Servers.
Edit an existing AAA Virtual Server.
On the left, in the Advanced Authentication Policies section, click where it says No Authentication Policy.
Click to select.
Select the Advanced Authentication Policy, and click Select.
The Select Next Factor field can optionally point to an Authentication Policy Label as detailed in the next section. The Next Factor is only evaluated if this Advanced Authentication Policy succeeds.
If this Advanced Authentication Policy fails, then the Goto Expression determines what happens next. If it is set to NEXT, then the next Advanced Authentication Policy bound to this Factor is evaluated. If it is set to END, of if there are no more Advanced Authentication Policies bound to this Factor, then authentication is finished and marked as failed.
Click Bind.

LDAP Group Extraction

Sometimes you only want to extract a user’s groups from Active Directory, but have don’t actually want to authenticate with LDAP. These groups can then be used to select the next authentication Factor.

To configure an LDAP Action/Server for only group extraction:

When creating or editing an LDAP Server, make sure Authentication is unchecked.
Make sure Group Attribute and Sub Attribute Name are filled in.

Authentication Policy Label

When configuring the first Factor, you bind two objects to the AAA Virtual Server:

Login schema – for forms-based authentication
Advanced Authentication Policy

When binding the Advanced Authentication Policy to the AAA Virtual Server, there’s a field to Select Next Factor. If the Advanced Authentication Policy succeeds, then the Next Factor is evaluated.

The Next Factor is actually an Authentication Policy Label.

Authentication Policy Labels contain three objects:

Login Schema
Advanced Authentication Policies
Next Factor – the next Authentication Policy Label

Here’s the flow:

User connects to AAA or NetScaler Gateway Virtual Server.
If forms-based authentication, the Login Schema bound to the AAA Virtual Server is displayed.
Advanced Authentication Policies bound to the AAA Virtual Server are evaluated.
1. If the Advanced Authentication Policy is successful, go to the configured Next Factor, which is an Authentication Policy Label.
  1. If Next Factor is not configured, then authentication is complete and successful.
2. If the Advanced Authentication Policy fails, and if Goto Expression is Next, then evaluate the next bound Advanced Authentication Policy.
3. If none of the Advanced Authentication Policies are successful, then authentication failed.
If the Next Factor Authentication Policy Label has a Login Schema bound to it, display it to the user.
Evaluate the Advanced Authentication Policies bound to the Next Factor Authentication Policy Label.
1. If the Advanced Authentication Policy is successful, go to the configured Next Factor, which is an Authentication Policy Label.
  1. If Next Factor is not configured, then authentication is complete and successful.
2. If the Advanced Authentication Policy fails, and if Goto Expression is Next, then evaluate the next bound Advanced Authentication Policy.
3. If none of the Advanced Authentication Policies are successful, then authentication failed.
Continue evaluating the Next Factor Authentication Policy Label until authentication succeeds or fails. You can chain together an unlimited number of Authentication Policy Labels.

If you are binding a Login Schema to an Authentication Policy Label, then you only need the Login Schema Profile. There’s no need to create a Login Schema Policy.

Not every Factor needs a Login Schema (logon page). It’s possible for a prior Factor to gather all of the credential information and simply pass it on to the next Factor. If you don’t need a Login Schema for a particular Authentication Policy Label, simply select LSCHEMA_INT, which is mapped to noschema. Or create a new Login Schema Profile based on noschema.

Create Authentication Policy Label

To create an Authentication Policy Label:

Authentication Policy Labels are configured at Security > AAA > Policies > Authentication > Advanced Policies > PolicyLabel.
On the right, click Add.
Give the Policy Label a name.
Select a Login Schema Profile. This can be one that is set to noschema if you don’t actually want to display anything to the user. Then click Continue.
In the Policy Binding section, Click to select.
Select an Advanced Authentication Policy that evaluates this Factor. Click Select.
Use the Goto Expression drop-down to select NEXT or END. If you want to bind more Advanced Authentication Policies to this Factor, then select NEXT.
In the Select Next Factor field, if you chain another Factor, Click to select, and bind the next Authentication Policy Label (Next Factor).
Or don’t select anything, and if this Advanced Authentication Policy succeeds, then authentication is successful and complete. This ends the chaining.
Click Bind when done.
You can click Add Binding to add more Advanced Authentication Policies to this Policy Label (Factor). Or you can bind Advanced Authentication Policies to the next Policy Label (Next Factor). Click Done.

Bind Authentication Policy Label

Once the Policy Label (Factor) is created, you bind it to an existing Advanced Authentication Policy binding. This is how you chain Factors together.

Either edit an existing AAA Virtual Server that has an Advanced Authentication Policy already bound to it.
Or edit a different Authentication Policy Label.
On the left, in the Advanced Authentication Policies section, click the bindings.
Click the ellipsis next to an existing binding, and click Edit Binding.
In the Select Next Factor field, Click to select.
Select the Policy Label for the Next Factor, and click Select.
Click Bind.
Click Close.

nFactor for NetScaler Gateway

AAA Authentication Profile

Authentication Profile lets you bind a AAA Virtual Server to NetScaler Gateway. This is what enables nFactor on NetScaler Gateway.

Go to Security > AAA > Authentication Profile.
On the right, click Add.
Give the Authentication Profile a name.
In the Authentication Host field, it wants a URL to redirect users to your AAA Virtual Server. If you do this configuration from the CLI, then this field is optional. But in the GUI it is required. NetScaler Gateway does not need to redirect so it doesn’t matter what you enter here.
In the Authentication Virtual Server field, Click to select.
Select the AAA Virtual Server that has Login Schema, Advanced Authentication Policy, and Authentication Policy Labels configured. The AAA Virtual Server does not need an IP address. Click Select.
Then click Create.
Go to NetScaler Gateway > Virtual Servers.
On the right, edit an existing Gateway Virtual Server.
Note: the new RfWebUI theme seems to interfere with Login Schema rendering. Consider changing your Gateway Portal Theme to X1 instead.
On the right, in the Advanced Settings section, click Authentication Profile.
On the left, use the Authentication Profile drop-down to select the Authentication Profile you just created.
If one of your Factors is client certificates, then you’ll need to configure SSL Parameters and CA certificate as detailed in the next section.
When you browse to your Gateway, you’ll see the nFactor authentication screens.

Gateway Client Certificate Authentication

If one of your authentication Factors is certificate, then you must perform some SSL configuration on the NetScaler Gateway Virtual Server:

Go to Traffic Management > SSL > Certificates > CA Certificates, and install the root certificate for the issuer of the client certificates. Certificate Authority certificates do not need key files.
Go to NetScaler Gateway > Virtual Servers, and edit an existing NetScaler Gateway Virtual Server that is enabled for nFactor.
On the left, in the SSL Parameters section, click the pencil icon.
Check the box next to Client Authentication.
Make sure Client Certificate drop-down is set to Optional, and click OK.
On the left, in the Certificates section, click where it says No CA Certificate.
Click to select.
Select the root certificate for the issuer of the client certificates, and click Select.
Click Bind.

nFactor Single Sign-on to StoreFront

When performing Single Sign-on to StoreFront, nFactor defaults to using the last entered password. If LDAP is not the last entered password, then you need to create a Traffic Policy/Profile to override the default nFactor behavior.

Go to NetScaler Gateway > Policies > Traffic.
On the right, switch to the Traffic Profiles tab.
Click Add.
Give the Traffic Profile a name.
In the Protocol section, select HTTP.
Enable Single Sign-on. Scroll down.
In the SSO Expression fields, enter an HTTP.REQ.USER.ATTRIBUTE(#) expression that matches the indexes specified in the Login Schema.
Click Create.
On the right, switch to the Traffic Policies tab, and click Add.
Give the policy a name.
Select the previously created Traffic Profile.
Enter a classic expression (e.g. ns_true) and click Create.
Edit an existing NetScaler Gateway Virtual Server.
Scroll down to the Policies section and click the plus icon.
Select Traffic > Request, and click Continue.
Select the previously created Traffic Policy and click Bind.

Sample Configurations

From Citrix Docs: Sample deployments using nFactor authentication:

Getting two passwords up-front, pass-through in next factor. Read
Group extraction followed by certificate or LDAP authentication, based on group membership. Read
SAML followed by LDAP or certificate authentication, based on attributes extracted during SAML.Read
SAML in first factor, followed by group extraction, and then LDAP or certificate authentication, based on groups extracted. Read
Prefilling user name from certificate. Read
Certificate authentication followed by group extraction for 401 enabled traffic management virtual servers. Read
Username and 2 passwords with group extraction in third factor.Read
Certificate fallback to LDAP in same cascade; one virtual server for both certificate and LDAP authentication. Read
LDAP in first factor and WebAuth in second factor.Read
Domain drop down in first factor, then different policy evaluations based on group.Read

Certificate auth: If Successful, LDAP only. If Failure, LDAP+RADIUS

This scenario is described in Citrix Blog Post Configuration Notes on nFactor

The authentication process flows like this:

User connects to NetScaler Gateway.
NetScaler Gateway asks user for certificate.
If user selects a certificate, NetScaler Gateway compares certificate signature to the CA certificate that is bound to the NetScaler Gateway. If it doesn’t match, then user certificate is ignored.
Bound to the NetScaler Gateway Virtual Server is an Authentication Profile, which links NetScaler Gateway to AAA nFactor.
Certificate authentication: The lowest priority number authentication policy on the AAA Virtual Server is Certificate. If there’s a valid user certificate:
1. Extract the user’s userPrincipalName from the certificate.
2. Next Factor = policy label that displays a logon screen (Single-factor Login Schema)
3. The username field is pre-populated with the userPrincipalName attribute extracted from the certificate.
4. User is prompted to enter the LDAP password only.
5. LDAP policy/server is configured to use userPrincipalName to login to LDAP.
6. If successful, NetScaler Gateway authentication is complete. Next step is to Single Sign-on to StoreFront.
7. If LDAP authentication fails, then NetScaler Gateway authentication fails, and the user is prompted to try LDAP-only authentication again.
LDAP authentication: If certificate authentication fails, try next authentication policy bound to the AAA Virtual Server, which is a different LDAP Policy.
1. Bound to the AAA Virtual Server is a Dual Factor Login Schema that asks for username, LDAP password, and RADIUS password.
2. LDAP policy/server is configured to use sAMAccountName to login to LDAP. SAMAccountName means users don’t have to enter full userPrincipalName.
3. If LDAP authentication is successful:
  1. Put username in Credential Index 1 and put password in Credential Index 2. These will later be used by a Traffic Policy to Single Sign-on to StoreFront.
  2. Proceed to next factor (Policy Label), which is RADIUS.
4. If LDAP authentication fails, NetScaler Gateway login fails, and the user is prompted to try two-factor authentication again.
RADIUS authentication: the second factor Policy Label is configured with Noschema. This means no additional logon form is displayed because the RADIUS password was already collected in the previous factor.
1. When multiple passwords are collected, they are tried in order. The first password was used by the previous factor. The second password is tried by this factor (Policy Label).
2. RADIUS policy/profile attempts authentication.
3. If RADIUS authentication is successful, NetScaler Gateway authentication is complete. Next step is Single Sign-on to StoreFront.
4. If RADIUS authentication fails, NetScaler Gateway login fails, and the user is prompted to try two-factor authentication again.
Single Sign-on to StoreFront: NetScaler Gateway uses the last password collected by nFactor to Single Sign-on with StoreFront. If the last password is LDAP, then no additional configuration is needed. If the last password is not LDAP, then a Traffic Policy/Profile is needed.
1. Bound to the NetScaler Gateway Virtual Server is a Traffic Policy.
2. The Traffic Policy/Profile users Credential Index 1 for username and Credential Index 2 for Password. These are the same indexes configured in the Dual Factor Login Schema.

The order of configuration doesn’t match the authentication flow because some objects have to be created before others.

# Create Auth vServer, bind server cert, bind CA cert for client certificates
# Enable Optional client certificates
add authentication vserver nFactorAAA SSL 0.0.0.0 443
bind ssl vserver nFactorAAA -certkeyName WildCorpCom
bind ssl vserver nFactorAAA -certkeyName CorpRoot -CA -ocspCheck Optional
set ssl vserver nFactorAAA -clientAuth ENABLED -clientCert Optional -ssl3 DISABLED

# Create auth policy for LDAP-UPN. UPN is extracted from certificate.
add authentication ldapAction Corp-UserPrincipalName -serverIP 10.2.2.220 -serverPort 636 -ldapBase "dc=corp,dc=local" -ldapBindDn "corp\\ctxsvc" -ldapBindDnPassword "MyPassword" -ldapLoginName userPrincipalName -groupAttrName memberOf -subAttributeName CN -secType SSL -passwdChange ENABLED
add authentication Policy Corp-UserPrincipalName -rule true -action Corp-UserPrincipalName

# Create PolicyLabel LDAPPasswordOnly with Single-factor Login Schema
# Login Schema has InitialValue with username from certificate.
add authentication loginSchema SingleAuth -authenticationSchema "/nsconfig/loginschema/LoginSchema/SingleAuth-Corp.xml"
add authentication policylabel LDAPPasswordOnly -loginSchema SingleAuth
bind authentication policylabel LDAPPasswordOnly -policyName Corp-UserPrincipalName -priority 100 -gotoPriorityExpression NEXT

# Create Cert policy and bind to AAA vServer with LDAPPasswordOnly PolicyLabel as Next Factor
# Cert policy must have lower priority number (higher priority) than LDAP-SAM policy
# Cert is evaluated first. If succeed, ask for LDAP password. If fails, ask for two factor.
add authentication certAction Cert_Auth_Profile -userNameField SubjectAltName:PrincipalName
add authentication Policy Cert_Auth_Policy -rule true -action Cert_Auth_Profile
bind authentication vserver nFactorAAA -policy Cert_Auth_Policy -priority 100 -nextFactor LDAPPasswordOnly -gotoPriorityExpression NEXT

# Create LDAP-SAM Auth Policy for two-factor
# Only evaluated if cert auth fails. Login Schema asks for user, password, and passcode.
add authentication ldapAction Corp-Gateway -serverIP 10.2.2.220 -serverPort 636 -ldapBase "dc=corp,dc=local" -ldapBindDn "corp\\ctxsvc" -ldapBindDnPassword "MyPassword" -ldapLoginName samaccountname -groupAttrName memberOf -subAttributeName CN -secType SSL -passwdChange ENABLED
add authentication Policy Corp-SAMAccountName -rule true -action Corp-Gateway

# Create RADIUS Auth Policy for two-factor
add authentication radiusAction RADIUS-Action -serverIP 10.2.2.42 -serverPort 1812 -radKey MyKey
add authentication Policy RADIUS-Policy -rule true -action RADIUS-Action

# Create Dual-factor Login Schema and bind directly to AAA vServer
# This Login Schema is only shown if Cert auth fails
add authentication loginSchema DualAuth -authenticationSchema "/nsconfig/loginschema/LoginSchema/DualAuth.xml" -userCredentialIndex 1 -passwordCredentialIndex 2
add authentication loginSchemaPolicy DualAuth -rule true -action DualAuth
bind authentication vserver nFactorAAA -policy DualAuth -priority 100 -gotoPriorityExpression END

# Create RADIUS Policy Label with noschema and RADIUS Auth Policy
# Already got passcode from previous factor so don't show Login Schema again
add authentication loginSchema Noschema -authenticationSchema noschema
add authentication policylabel NoSchema-RADIUS -loginSchema Noschema
bind authentication policylabel NoSchema-RADIUS -policyName RADIUS-Policy -priority 100 -gotoPriorityExpression NEXT

# Bind LDAP-SAM Auth Policy to AAA vServer with RADIUS as next factor
# LDAP-SAM Auth Policy must have higher priority number (lower priority) than Cert Policy
bind authentication vserver nFactorAAA -policy Corp-SAMAccountName -priority 110 -nextFactor NoSchema-RADIUS -gotoPriorityExpression NEXT

# Create Authentication Profile to link AAA with Gateway. Bind to Gateway.
add authentication authnProfile nFactor -authnVsName nFactorAAA -AuthenticationHost aaa.corp.com
add vpn vserver gateway.corp.com SSL 10.2.2.220 443 -icaOnly ON -dtls ON -Listenpolicy NONE -tcpProfileName nstcp_default_XA_XD_profile -appflowLog ENABLED -authnProfile nFactor

# Enable Optional Client certs on Gateway
set ssl vserver gateway.corp.com -clientAuth ENABLED -clientCert Optional -ssl3 DISABLED
bind ssl vserver gateway.corp.com -certkeyName CorpRoot -CA -ocspCheck Optional

# Create Traffic Policy to SSON to StoreFront. Bind to Gateway.
add vpn trafficAction nFactorSSO http -kcdAccount NONE -userExpression "http.req.user.attribute(1)" -passwdExpression "http.req.user.attribute(2)"
add vpn trafficPolicy nFactorSSO ns_true nFactorSSO
bind vpn vserver gateway.corp.com -policy nFactorSSO -priority 100

↧

Horizon View Load Balancing – NetScaler 11.1

July 6, 2016, 2:53 pm

≫ Next: NetScaler SDX 11.1

≪ Previous: nFactor Authentication for NetScaler Gateway 11.1

Navigation

Use this procedure to load balance Horizon View Connection Servers, Horizon View Security Servers, and/or VMware Access Points.

Overview

Servers/Appliances

There are two VMware-provided remote access solutions for Horizon View:

Access Points are preferred over Security Servers for the following reasons:

No need to pair with internal Connection Servers. This simplifies the configuration.
Linux appliance instead of Windows server.
Authentication can be offloaded to Access Point. This includes: Smart Cards, RSA, and RADIUS.

If you are using Access Points instead of Security Servers, then you’ll have the following machines in a highly available Horizon infrastructure:

Two Internal Connection Servers – these need to be load balanced on an internal VIP
Two DMZ Access Point appliances – these need to be load balanced on a DMZ VIP. Access Point connects to the Connection Server internal VIP.

With Security Servers instead of Access Points, a typical Horizon Infrastructure will have at least six connection servers:

Two Internal Connection Servers – these need to be load balanced on an internal VIP
Two DMZ Security Servers – these need to be load balanced on a DMZ VIP
The DMZ Security Servers are paired with two additional internal Connection Servers. There is no need to load balance the internal Paired Connection Servers. However, we do need to monitor them.

Since Security Servers are paired with Connection Servers, you need to configure load balancing monitors to disable the Security Server if the paired Connection Server is not accessible. Since Access Points are not paired with Connection Servers, you don’t need this special monitoring configuration.

Protocols/Ports

Horizon 7 introduces a new Blast Extreme protocol that runs on TCP and UDP 443. HTML Access in Horizon 7 also uses Blast Extreme protocol (TCP/UDP 443). If you use Blast Extreme exclusively, then the number of ports is reduced, and load balancing configuration is simplified. Here are typical load balancing port requirements for Blast Extreme only:

TCP 443
UDP 443

Note: UDP 443 is disabled by default, but it can be enabled using a Blast GPO setting.

If you need PCoIP, or if you need HTML Access in Horizon 6 or older, then several more load balancing ports are needed:

TCP 443
TCP 4172
UDP 4172
TCP 8443

For all versions of Horizon, if you are load balancing internal Connection Servers, and if the Secure Gateways are disabled, then the only port you need to load balance is:

TCP 443

VMware requires server persistence to apply across multiple load balanced port numbers. If using PCoIP, if a user is load balanced to a particular View Connection Server on TCP 443, then the connection on UDP 4172 must go the same View Connection Server. Normally load balancing persistence only applies to a single port number, so whatever sever was selected on 443 won’t be considered for the 4172 connection. But in NetScaler, you can configure a Persistency Group to use a single persistency across multiple load balancing vServers (different port numbers). In F5, you configure Match Across.

This topic primarily focuses on NetScaler GUI configuration. Alternatively, you can skip directly to the CLI commands.

Horizon 7 Origin Check

Horizon 7 might not accept your load balanced DNS name unless it’s the same name configured in the Connection Server’s Secure Tunnel configuration. You can change this behavior by disabling Origin Check as detailed at VMware 2144768 Accessing the Horizon View Administrator page displays a blank error window in Horizon 7. Note: this configuration is almost mandatory for Access Points, since Secure Tunnel is disabled on the Connection Servers.

Load Balancing Monitors

Users connect to Connection Servers, Security Servers, and Access Point appliances on multiple ports: TCP 443, UDP 443, TCP 8443, UDP 8443, TCP 4172, and UDP 4172. Users will initially connect to TCP port 443, and then be redirected to one of the other ports on the same server/appliance initially used for the TCP 443 connection. If TCP 443 is up, but UDP 4172 is down on the same server/appliance, then you probably wan’t to take TCP 443 down too. To facilitate this, create a monitor for each of the ports, and bind all of the monitors to the TCP 443 service. If any of the monitors goes down, then TCP 443 is also taken down.

SSL (443) Monitor

On the left, expand Traffic Management, expand Load Balancing, and click Monitors.
On the right, click Add.
Name it Horizon-SSL or similar.
Change the Type drop-down to HTTP-ECV.
On the Standard Parameters tab, in the Destination Port field, enter 443.
Scroll down and check the box next to Secure.
On the Special Parameters tab, in the Send String section, enter GET /broker/xml
In the Receive String section, enter clientlaunch-default
Scroll down, and click Create.

PCoIP (4172) Monitor

On the right, click Add.
Name it Horizon-PCoIP or similar.
Change the Type drop-down to TCP.
On the Standard Parameters tab, in the Destination Port field, enter 4172.
Scroll down and click Create.

Blast (8443) Monitor

On the right, click Add.
Name it Horizon-Blast or similar.
Change the Type drop-down to TCP.
On the Standard Parameters tab, in the Destination Port field, enter 8443.
Scroll down and click Create.

Paired Connection Server Monitor

Note: the steps in this section do not apply to Access Points or internal Connection Servers.

View Security Servers are paired with View Connection Servers. If the paired View Connection Server is down, then we should probably stop sending users to the corresponding View Security Server. Let’s create a monitor that has a specific IP address in it.

Click the ellipsis next to the existing Horizon-SSL monitor, and click Add.
Normally a monitor does not have any Destination IP defined, which means it uses the IP address of the service that it is bound to. However, we intend to bind this monitor to the View Security Server, but we need it to monitor the paired View Connection Server, which is a different IP address. Type in the IP address of the paired View Connection Server. Then rename the monitor so it includes the paired View Connection Server name. Click Create.
Since we are embedding an IP address into the monitor, you have to create a separate monitor for each paired Connection Server IP. Create another monitor. Specify the IP of the other paired Connection Server. Click Create.

Load Balancing Servers

Create Server Objects for the DMZ Security Servers, DMZ Access Point appliances, and the internal non-paired Connection Servers. Do not create Server Objects for the Paired Connection Servers.

On the left, expand Traffic Management, expand Load Balancing, and click Servers.
On the right, click Add.
Enter a descriptive server name, usually it matches the actual server name.
Enter the IP address of the Access Point, Horizon Connection Server, or Horizon Security Server.
Enter comments to describe the server. Click Create.
Continue adding Access Points, Horizon Connection Servers, and/or Horizon Security Servers.

Load Balancing Services

Overview

Services vs Service Groups:

For Security Servers, if the paired Connection Server is down, then we need the Security Server to go down too. One of the monitors bound to the Security Server contains the IP address of the paired Connection Server. Since each Security Server is paired with a different Connection Server, that means each Security Server will have a unique monitoring configuration. This precludes us from adding multiple Security Servers to a single Service Group since you can only have one monitor configuration for the entire Service Group. Instead, create separate Services (multiple port numbers) for each Security Server.
- Individual services per server are only needed for TCP 443. The other ports can be service groups.
For Access Points, there is no special monitoring configuration, and thus these appliances could be added to Service Groups (one for each port number).
For internal Connection Servers (non-paired), there is no special monitoring configuration, and thus these appliances could be added to one Service Group. Internal Connection Servers usually only need TCP 443 load balanced.

For Internal Connection Servers (not the paired servers), load balancing monitoring is very simple:

Create a service group for SSL 443.
To verify server availability, monitor port TCP 443 on the same server.
If tunneling is disabled then internal users connect directly to View Agents and UDP/TCP 4172 and TCP 8443 are not used on Internal Connection Servers. There’s no need to create service groups and monitors for these ports.

Security Servers and Access Point appliances are more complex:

For Blast Extreme protocol, if UDP is not enabled, then you only need services for TCP 443. If UDP is enabled, then you also need load balancing services for UDP 443.
For PCoIP protocol, all traffic initially connects on TCP 443. The Horizon clients then connect to UDP 4172 or TCP 8443 on the same Security Server or Access Point. If 4172 is down, then 443 should be taken down. Bind monitors for each port to the TCP 443 service. If any of the monitors fails (e.g. 4172 is down), then TCP 443 is taken down and NetScaler will no longer forward traffic to TCP 443 on that particular server/appliance.
Each Security Server is paired with an internal Connection Server. If the internal Connection Server is down then the Security Server should be taken down. This requires custom monitors for each Security Server. This is not a problem for Access Points.

Configuration Summary

If you have two Security Servers named VSS01 and VSS02, the load balancing service configuration for PCoIP is summarized as follows (scroll down for detailed configuration):

Server = VSS01, Protocol = SSL_BRIDGE, Port = 443
- Monitors = PCoIP (TCP 4172), SSL (443), and Blast (8443)
- Monitor = SSL (443) for paired View Connection Server VCS01.
Server = VSS02, Protocol = SSL_BRIDGE, Port = 443
- Monitors = PCoIP (TCP 4172), SSL (443), and Blast (8443)
- Monitor = SSL (443) for paired View Connection Server VCS02.
Service Group, Protocol = UDP
- Members = VSS01 and VSS02
- Port = 443
- Monitor = SSL (443) or ping
Service Group, Protocol = TCP
- Members = VSS01 and VSS02
- Port = 4172
- Monitor = PCoIP (TCP 4172)
Service Group, Protocol = UDP
- Members = VSS01 and VSS02
- Port = 4172
- Monitor = PCoIP (TCP 4172)
Service Group, Protocol = SSL_BRIDGE
- Members = VSS01 and VSS02
- Port = 8443
- Monitor = Blast (8443)
Service Group, Portocol = UDP
- Members = VSS01 and VSS02
- Port = 8443
- Monitor = Blast (8443)

If you have two Security Servers named VSS01 and VSS02, the load balancing service configuration for Blast Extreme in Horizon 7 (no PCoIP) is summarized as follows (scroll down for detailed configuration):

Service Group, Protocol = SSL_BRIDGE
- Members = VSS01 and VSS02
- Port = 443
- Monitor = SSL (443)
Service Group, Protocol = UDP
- Members = VSS01 and VSS02
- Port = 443
- Monitor = SSL (443) or ping

If you have two Access Points named VAP01 and VAP02, the load balancing service configuration for PCoIP is summarized as follows (scroll down for detailed configuration):

Service Group, Protocol = TCP
- Members = VAP01 and VAP02
- Port = 443
- Monitor = SSL (443)
Service Group, Protocol = UDP
- Members = VAP01 and VAP02
- Port = 443
- Monitor = SSL (443) or ping
Service Group, Protocol = TCP
- Members = VAP01 and VAP02
- Port = 4172
- Monitor = PCoIP (TCP 4172)
Service Group, Protocol = UDP
- Members = VAP01 and VAP02
- Port = 4172
- Monitor = PCoIP (TCP 4172)
Service Group, Protocol = SSL_BRIDGE
- Members = VAP01 and VAP02
- Port = 8443
- Monitor = Blast (8443)
Service Group, Portocol = UDP
- Members = VAP01 and VAP02
- Port = 8443
- Monitor = Blast (8443)

If you have two Access Points named VAP01 and VAP02, the load balancing service configuration for Blast Extreme in Horizon 7 (no PCoIP) is summarized as follows (scroll down for detailed configuration):

Service Group, Protocol = SSL_BRIDGE
- Members = VAP01 and VAP02
- Port = 443
- Monitor = SSL (443)
Service Group, Protocol = UDP
- Members = VAP01 and VAP02
- Port = 443
- Monitor = SSL (443) or ping

TCP 443

Here are general instructions for the TCP 443 Horizon services. These instructions detail the more complicated Security Server configuration. If Access Point or internal Connection Servers, you could configure a service group instead of individual services. See the above configuration summaries for your specific configuration.

On the left, expand Traffic Management, expand Load Balancing, and click Services.
On the right, click Add.
Give the Service a descriptive name (e.g. svc-VSS01-SSL).
Change the selection to Existing Server and select the Access Point, Security Server or internal (non-paired) Connection Server you created earlier.
Change the Protocol to SSL_BRIDGE, and click OK.
On the left, in the Monitors section, click where it says 1 Service to Load Balancing Monitor Binding.
Ignore the current monitor, and click Add Binding.
Click the arrow next to Click to select.
Select the Horizon-SSL monitor, and click Select.
Then click Bind.
If this server will host PCoIP Secure Gateway and/or Blast Secure Gateway, add monitors for them too. If any of those services fails, then 443 needs to be marked DOWN.
If this is a Security Server, also add a monitor that has the IP address of the paired Connection Server. If the paired Connection Server is down, then stop sending connections to this Security Server.
The Last Response should indicate Success. If you bound multiple monitors to the Service, then the member will only be UP if all monitors succeed. There’s a refresh button on the top-right. Click Close when done.
Then click Done.
Selec the first service, and click Add.
Change the name to match the second Horizon Server.
Select Existing Server and use the Server drop-down to select to the second Horizon Server.
The remaining configuration is identical to the first server. Click OK.
You will need to configure the monitors again. They will be identical to the first server except for the monitoring of the paired View Connection Server. Click Done when done.

Other Ports

Here are general instructions for the remaining Horizon services. These instructions use Service Groups, but you could just as easily add Services instead. See the above summaries for your specific configuration.

On the left, go to Traffic Mgmt > Load Balancing > Service Groups.
On the right, click Add.
Name it svcgrp-Horizon-UDP443 or similar. UDP 443 is for Blast Extreme in Horizon 7.
Change the Protocol to UDP. Click OK.
Click where it says No Service Group Member.
Change the selection to Server Based and then click Click to select.
Select your multiple Security Servers or multiple Access Points and click Select.
Enter 443 as the Port and click Create.
Click OK.
On the right, in the Advanced Settings column, add the Monitors section.
Click where it says No Service Group to Monitor Binding.
Click to select.
Select the Horizon-SSL monitor, click Select, and then click Bind.
Click Done.
Add another Service Group for PCoIP on TCP 4172.
1. Name = svcgrp-Horizon-PCoIPTCP or similar.
2. Protocol = TCP
3. Members = multiple Security Servers or multiple Access Points.
4. Port = 4172.
5. Monitors = Horizon-PCoIP. You can add the other monitors if desired.
Add another Service Group for PCoIP on UDP 4172.
1. Name = svcgrp-Horizon-PCoIPUDP or similar.
2. Protocol = UDP
3. Members = multiple Security Servers or multiple Access Points
4. Port = 4172.
5. Monitors = Horizon-PCoIP. You can add the other monitors if desired.
Add another Service Group for TCP 8443 on SSL_BRIDGE 8443.
1. Name = svcgrp-Horizon-TCP8443 or similar.
2. Protocol = SSL_BRIDGE
3. Members = multiple Security Servers or multiple Access Points
4. Port = 8443.
5. Monitors = Horizon-Blast. You can add the other monitors if desired.
Add another Service Group for UDP 8443 (Blast Extreme in Horizon 7).
1. Name = svcgrp-Horizon-UDP8443 or similar.
2. Protocol = UDP
3. Members = multiple Security Servers or multiple Access Points
4. Port = 8443.
5. Monitors = Horizon-Blast. You can add the other monitors if desired.
The five service groups should look something like this:

Load Balancing Virtual Servers

Create separate load balancing vServers for internal and DMZ.

Internal VIP load balances the non-paired Internal Connections Servers. Access Point appliances also connect to this VIP.
DMZ VIP load balances the Security Servers or Access Point appliances.

The paired View Connection Servers do not need to be load balanced.

For the internal Connection Servers you only need a load balancer for SSL_BRIDGE 443. If tunneling is disabled, then you don’t need load balancers for the other ports (UDP/TCP 4172 and SSL_BRIDGE 8443).

However, tunneling is enabled on the Security Servers and Access Points so you will need separate load balancers for each port number. Here is a summary of the Virtual Servers, all listening on the same IP address:

Virtual Server on SSL_BRIDGE 443 – bind both Horizon SSL 443 Services.
Virtual Server on UDP 443 (Horizon 7) – bind the UDP 443 service group.
Virtual Server on UDP 4172 – bind the PCoIPUDP service group.
Virtual Server on TCP 4172 – bind the PCoIPTCP service group.
Virtual Server on SSL_BRIDGE 8443 – bind the SSL_BRIDGE 8443 service group.
Virtual Server on UDP 8443 (Horizon 7) – bind the UDP 8443 service group.

Do the following to create the Virtual Servers:

On the left, under Traffic Management > Load Balancing, click Virtual Servers.
On the right, click Add.
Name it lbvip-Horizon-SSL or similar.
Change the Protocol to SSL_BRIDGE.
Specify a new VIP. This one VIP will be used for all of the Virtual Servers.
Enter 443 as the Port.
Click OK.
On the left, in the Services and Service Groups section, click where it says No Load Balancing Virtual Server Service Binding.
Click the arrow next to Click to select.
Select the two Horizon-SSL Services and click Select.
Click Bind.
Click Continue.
Then click Done. Persistency will be configured later.
If this Horizon 7, and if this is a Security Server or Access Point, then create another Load Balancing Virtual Server for UDP 443:
1. Same VIP as the TCP 443 Load Balancer.
2. Protocol = UDP, Port = 443
3. Service Group Binding = the UDP 443 Service Group
If this is a Security Server or Access Point, then create another Load Balancing Virtual Server for PCoIP UDP 4172:
1. Same VIP as the 443 Load Balancer.
2. Protocol = UDP, Port = 4172
3. Service Group Binding = the PCoIP UDP Service Group.
If this is a Security Server or Access Point, then create another Load Balancing Virtual Server for PCoIP TCP 4172:
1. Same VIP as the 443 Load Balancer.
2. Protocol = TCP, Port = 4172
3. Service Group Binding = the PCoIP TCP Service Group
If this is a Security Server or Access Point, then create another Load Balancing Virtual Server for SSL_BRIDGE 8443:
1. Same VIP as the 443 Load Balancer.
2. Protocol = SSL_BRIDGE, Port = 8443
3. Service Group Binding = the TCP 8443 SSL_BRIDGE Service Group
If this is a Security Server or Access Point, then create another Load Balancing Virtual Server for UDP 8443:
1. Same VIP as the 443 Load Balancer.
2. Protocol = UDP, Port = 8443
3. Service Group Binding = the UDP 8443 SSL_BRIDGE Service Group
This gives you six Virtual Servers on the same VIP, but different protocols and port numbers.

Persistency Group

For Security Servers and Access Points, users will first connect to SSL_BRIDGE 443 and be load balanced. Subsequent connections to the other port numbers must go to the same load balanced server. Create a Persistency Group to facilitate this.

If tunneling is disabled on the internal View Connection Servers, then you probably only have one load balancer for those servers, and thus you could configure persistence directly on that one load balancing vServer instead of creating a Persistency Group. However, since the Security Servers and Access Points have multiple load balancing vServers, then you need to bind them together into a Persistency Group.

On the left, under Traffic Management, expand Load Balancing, and click Persistency Groups.
On the right, click Add.
Give the Persistency Group a name (e.g. Horizon).
Change the Persistence to SOURCEIP.
Enter a timeout that is equal to or greater than the timeout in Horizon View Administrator, which defaults to 10 hours (600 minutes).
In the Virtual Server Name section, click Add.
Move all six Security Server / Access Point Load Balancing Virtual Servers to the right. Click Create.

CLI Commands

Here’s a list of CLI commands for the most basic configuration of two Access Points with Blast Extreme only (no PCoIP):

add server VAP01 10.2.2.187
add server VAP02 10.2.2.24
add lb monitor Horizon-SSL HTTP-ECV -send "GET /broker/xml" -recv clientlaunch-default -secure YES
add serviceGroup svcgrp-Horizon-SSL SSL_BRIDGE
add serviceGroup svcgrp-Horizon-UDP443 UDP
bind serviceGroup svcgrp-Horizon-SSL VAP01 443
bind serviceGroup svcgrp-Horizon-SSL VAP02 443
bind serviceGroup svcgrp-Horizon-SSL -monitorName Horizon-SSL
bind serviceGroup svcgrp-Horizon-UDP443 VAP01 443
bind serviceGroup svcgrp-Horizon-UDP443 VAP02 443
bind serviceGroup svcgrp-Horizon-UDP443 -monitorName Horizon-SSL
add lb vserver lbvip-Horizon-SSL SSL_BRIDGE 10.2.2.204 443
add lb vserver lbvip-Horizon-UDP443 UDP 10.2.2.204 443
bind lb vserver lbvip-Horizon-SSL svcgrp-Horizon-SSL
bind lb vserver lbvip-Horizon-UDP443 svcgrp-Horizon-UDP443
bind lb group Horizon lbvip-Horizon-SSL
bind lb group Horizon lbvip-Horizon-UDP443
set lb group Horizon -persistenceType SOURCEIP -timeout 600

Here’s a list of CLI commands for the more complicated Security Server configuration:

add server VSS01 10.2.2.187
add server VSS02 10.2.2.24
add lb monitor Horizon-PCoIP TCP -destPort 4172
add lb monitor Horizon-Blast TCP -destPort 8443
add lb monitor Horizon-SSL HTTP-ECV -send "GET /broker/xml" -recv clientlaunch-default -secure YES
add lb monitor Horizon-SSL-VCS01 HTTP-ECV -send "GET /broker/xml" -recv clientlaunch-default -destIP 10.2.2.19 -destPort 443 -secure YES
add lb monitor Horizon-SSL-VCS02 HTTP-ECV -send "GET /broker/xml" -recv clientlaunch-default -destIP 10.2.2.20 -destPort 443 -secure YES
add service svc-VSS01-SSL VSS01 SSL_BRIDGE 443
add service svc-VSS02-SSL VSS02 SSL_BRIDGE 443
bind service svc-VSS02-SSL -monitorName Horizon-SSL-VCS02
bind service svc-VSS02-SSL -monitorName Horizon-SSL
bind service svc-VSS02-SSL -monitorName Horizon-Blast
bind service svc-VSS02-SSL -monitorName Horizon-PCoIP
bind service svc-VSS01-SSL -monitorName Horizon-SSL-VCS01
bind service svc-VSS01-SSL -monitorName Horizon-Blast
bind service svc-VSS01-SSL -monitorName Horizon-PCoIP
bind service svc-VSS01-SSL -monitorName Horizon-SSL
add serviceGroup svcgrp-Horizon-UDP443 UDP
add serviceGroup svcgrp-Horizon-PCoIPTCP TCP
add serviceGroup svcgrp-Horizon-PCoIPUDP UDP
add serviceGroup svcgrp-Horizon-TCP8443 SSL_BRIDGE
add serviceGroup svcgrp-Horizon-UDP8443 UDP
bind serviceGroup svcgrp-Horizon-UDP443 VSS01 443
bind serviceGroup svcgrp-Horizon-UDP443 VSS02 443
bind serviceGroup svcgrp-Horizon-UDP443 -monitorName Horizon-SSL
bind serviceGroup svcgrp-Horizon-PCoIPTCP VSS01 4172
bind serviceGroup svcgrp-Horizon-PCoIPTCP VSS02 4172
bind serviceGroup svcgrp-Horizon-PCoIPTCP -monitorName Horizon-PCoIP
bind serviceGroup svcgrp-Horizon-PCoIPUDP VSS01 4172
bind serviceGroup svcgrp-Horizon-PCoIPUDP VSS02 4172
bind serviceGroup svcgrp-Horizon-PCoIPUDP -monitorName Horizon-PCoIP
bind serviceGroup svcgrp-Horizon-TCP8443 VSS01 8443
bind serviceGroup svcgrp-Horizon-TCP8443 VSS02 8443
bind serviceGroup svcgrp-Horizon-TCP8443 -monitorName Horizon-Blast
bind serviceGroup svcgrp-Horizon-UDP8443 VSS01 8443
bind serviceGroup svcgrp-Horizon-UDP8443 VSS02 8443
bind serviceGroup svcgrp-Horizon-UDP8443 -monitorName Horizon-Blast
add lb vserver lbvip-Horizon-SSL SSL_BRIDGE 10.2.2.204 443
add lb vserver lbvip-Horizon-UDP443 UDP 10.2.2.204 443
add lb vserver lbvip-Horizon-PCoIPUDP UDP 10.2.2.204 4172
add lb vserver lbvip-Horizon-PCoIPTCP TCP 10.2.2.204 1472
add lb vserver lbvip-Horizon-8443TCP SSL_BRIDGE 10.2.2.204 8443
add lb vserver lbvip-Horizon-8443UDP UDP 10.2.2.204 8443
bind lb vserver lbvip-Horizon-SSL svc-VSS01-SSL
bind lb vserver lbvip-Horizon-SSL svc-VSS02-SSL
bind lb vserver lbvip-Horizon-UDP443 svcgrp-Horizon-UDP443
bind lb vserver lbvip-Horizon-PCoIPTCP svcgrp-Horizon-PCoIPTCP
bind lb vserver lbvip-Horizon-PCoIPUDP svcgrp-Horizon-PCoIPUDP
bind lb vserver lbvip-Horizon-8443TCP svcgrp-Horizon-TCP8443
bind lb vserver lbvip-Horizon-8443UDP svcgrp-Horizon-UDP8443
bind lb group Horizon lbvip-Horizon-SSL
bind lb group Horizon lbvip-Horizon-UDP443
bind lb group Horizon lbvip-Horizon-PCoIPUDP
bind lb group Horizon lbvip-Horizon-PCoIPTCP
bind lb group Horizon lbvip-Horizon-8443TCP
bind lb group Horizon lbvip-Horizon-8443UDP
set lb group Horizon -persistenceType SOURCEIP -timeout 600

Horizon View Configuration – Security Servers

This section is not needed for Access Points. For Access Points, the secure gateways should be disabled, not enabled.

On the Security Servers (or Connection Servers), request a certificate that matches the FQDN that resolves to the Load Balancing VIP.
Make sure the private key is exportable.
Set the Friendly Name to vdm and restart the View Security Server services.
In View Administrator, go to View Configuration > Servers.
On the right, switch to the Security Servers tab.
Highlight a server and click Edit.
Change the URLs to the FQDN that resolves to the load balancing VIP.
Change the PCoIP URL to the VIP. For View Security Servers, this is typically a public IP that is NAT’d to the DMZ Load Balancing VIP.

↧

NetScaler SDX 11.1

July 7, 2016, 7:38 am

≫ Next: Detailed Change Log

≪ Previous: Horizon View Load Balancing – NetScaler 11.1

Navigation

Lights Out Module (LOM)
- LOM IP Configuration
- LOM Firmware Upgrade
SDX IP Configuration
Management Service Firmware – Upgrade to 11.0 build 55
SDX Software Bundle Upgrade – Upgrade beyond 11.0 build 55
Management Service NTP
Licensing
Management Service Alerting
Management Service nsroot Password and AAA
SSL Certificate and Encryption
SDX/XenServer LACP Channels
VPX Instances:
Management Service Monitoring
Management Service Backup

LOM IP Configuration

There are two ways to set the IP address of the Lights Out Module (LOM):

Crossover Ethernet cable from a laptop with an IP address in the 192.168.1.0 network.
ipmitool from the NetScaler SDX XenServer command line

Ipmitool Method:

On NetScaler SDX appliance, SSH to the XenServer IP address (this is not the Service VM IP). On NetScaler MPX appliance, SSH to the NetScaler NSIP.
Default XenServer credentials are root/nsroot. Default MPX credentials are nsroot/nsroot.
If MPX, run shell. XenServer is already in the shell.

Run the following:

ipmitool lan set 1 ipaddr x.x.x.x
ipmitool lan set 1 netmask 255.255.255.0
ipmitool lan set 1 defgw ipaddr x.x.x.x

You should now be able to connect to the LOM using a browser.

Laptop method:

Configure a laptop with static IP address 192.168.1.10 and connect it to the Lights Out Module port.
In a Web browser, type the IP address of the LOM port. For initial configuration, type the port’s default address: http://192.168.1.3
In the User Name and Password boxes, type the administrator credentials. The default username and password are nsroot/nsroot.
In the Menu bar, click Configuration and then click Network.
Under Options, click Network and type values for the following parameters:
1. IP Address—The IP address of the LOM port.
2. Subnet Mask—The mask used to define the subnet of the LOM port.
3. Default Gateway—The IP address of the router that connects the appliance to the network.
Click Save.
Disconnect the laptop and instead connect a cable from a switch to the Lights Out Module.

LOM Firmware Upgrade

The LOM firmware at https://www.citrix.com/downloads/netscaler-adc/components/lom-firmware-upgrade differs depending on the hardware platform. The LOM firmware for the 8000 series is different than the 11000 series. Do not mix them up.

Note: the SDX Update Bundle does not include LOM firmware update so you must update it separately.

Determine which firmware level you are currently running. You can point your browser to the LOM and login to the see the firmware level. Or you can run ipmitool mc info from the XenServer shell.
If your LOM firmware is older than 3.0.2, follow the instructions at http://support.citrix.com/article/CTX137970 to upgrade the firmware.
If your LOM firmware is version 3.02 or later, follow the instructions at http://support.citrix.com/article/CTX140270 to upgrade the firmware. This procedure is shown below.
Now that the firmware is version 3.0.2 or later, you can upgrade to 3.39. Click the Maintenance menu and then click Firmware Update.
On the right, click Enter Update Mode.
Click OK when prompted to enter update mode.
Click Choose File and browse to the extracted bin file.
After the file is uploaded, click Upload Firmware.
Click Start Upgrade.
The Upgrade progress will be displayed.
After upgrade is complete, click OK to acknowledge the 1 minute message.
The LOM will reboot.
After the reboot, login and notice that the LOM firmware is now 3.39.

SDX IP Configuration

Default IP for Management Service is 192.168.100.1/16 bound to interface 0/1. Use laptop with crossover cable to reconfigure. Point browser to http://192.168.100.1. Default login is nsroot/nsroot.

Default IP for XenServer is 192.168.100.2/16. Default login is root/nsroot. Note: XenServer IP and Management Service IP must be on the same subnet.

There should be no need to connect to XenServer directly. Instead, all XenServer configuration (e.g. create new VM) is performed through the Management Service (SVM). To change the XenServer IP, make the change through the Management Service as detailed below:

Point a browser to http://192.168.100.1 and login as nsroot/nsroot.
When you first login to the SDX Management Service, the Welcome! Wizard appears. Click Management Network.
Configure the IP addresses. Management Service IP Address and XenServer IP Address must be different, but on the same subnet.
You can change the password at this time or later. Click Done.
Click the System Settings box.
Enter a Host Name.
Select the time zone and click Continue.
Click the Licenses box.
Click Add New License.
Allocate licenses normally. After uploading, click Finish and it should apply automatically.
Or you can click Apply Licenses.
Then click Continue.

Another way to login to the Management Service virtual machine is through the serial port. This is actually the XenServer Dom0 console. Once logged in to XenServer, run ssh 169.254.0.10 to access the Management Service virtual machine. Then follow instructions at http://support.citrix.com/article/CTX130496 to change the IP.

The console of the Management Service virtual machine can be reached by running the following command in the XenServer Dom0 shell (SSH or console):

xe vm-list params=name-label,dom-id name-label="Management Service VM"

Then run /usr/lib/xen/bin/xenconsole <dom-id>

Or if 11.0 build 64 or newer, run /usr/lib64/xen/bin/xenconsole <dom-id>

Management Service Firmware – Upgrade to 11.0

NetScaler SDX 11.0 and newer now bundle all updates in a single package. To take advantage of this improved installation experience, you must first upgrade the Service VM to 11.0. Once it’s 11.0 you no longer need to upgrade the Service VM separately from the rest of the appliance.

If your SDX SVM (Management Service) is running 10.5 build 57 or newer, then you can skip this section and proceed with installing the SDX Bundle.
NetScaler SDX 11.0 build 55 contains a separate installer for just the Management Service (SVM Upgrade Package). The newer builds of NetScaler SDX 11.0 don’t seem to have a separate SVM Upgrade Package, so you’ll need to upgrade SVM to 11.0 build 55 first. Then use the Software Bundle method to upgrade to 11.1 as detailed in the next section.
If the webpage says NetScaler SDX on top then you are connected to the Service VM.
Switch to the Configuration tab.
In the navigation pane, expand Management Service, and then click Software Images.
In the right pane, click Upload.
In the Upload Management Service Software Image dialog box, click Browse, navigate to the folder that contains the build-svm file, and then double-click the build file.
Click Upload.

To upgrade the Management Service:

In the navigation pane, click System.
In the System pane, under System Administration, click Upgrade Management Service.
In the Upgrade Management Service dialog box, in Build File, select the file of the build to which you want to upgrade the Management Service.
If you see a Documentation File field, ignore it.
Click OK.
Click Yes if asked to continue.
If desired, go back to the Software Images node and delete older firmware files.

SDX Platform Software Bundle

Starting with SDX 11.0, all updates are bundled together and installed at once.

Make sure your Management Service (SVM) is running SDX 10.5 build 57 or newer. If not, see the separate SVM upgrade procedure in the previous section.
Download the latest SDX Platform Software bundle from Downloads > NetScaler ADC > Service Delivery Appliances.
Login to the SDX Management Service, go to Configuration > System.
On the right, in the right column, click Upgrade Appliance.
Browse to the build-sdx-11.1.tgz software bundle, and click OK.
It should show you the estimated installation time. Check boxes next to the instances that need configs saved. Click Upgrade.
Click Yes to continue with the upgrade.
The Management Service displays installation progress.
Once the upgrade is complete, click Login.
The Information page will be displayed showing the version of XenServer, Management Service (Build), etc.

Management Service NTP

On the Configuration tab, in the navigation pane, expand System, and then click NTP Servers.
To add a new NTP server, in the right pane, click Add.
In the Create NTP Server dialog box enter the NTP server name (e.g. pool.ntp.org) and click Create.
In the right pane, click NTP Synchronization.
In the NTP Synchronization dialog box, select Enable NTP Sync. Click OK.

Management Service Alerting

Syslog

On the Configuration tab, expand System > Auditing, and click Syslog Servers.
In the right pane, click the Add button.
Enter a name for the server.
Enter the IP address of the Syslog server.
Select log levels and click Create.
On the right is Syslog Parameters.
You can configure the Date Format and Time Zone. Click OK.

Mail Notification

On the Configuration tab, expand System > Notifications, and click Email.
In the right pane, on the Email Servers tab, click Add.
Enter the DNS name of the mail server, and click Create.
In the right pane, switch to the Email Distribution List tab, and click Add.
Enter a name for the mail profile.
Enter the destination email address, and click Create.

System SNMP

Go to System > SNMP.
On the right, click Configure SNMP MIB.
Enter information as desired and click OK. Your SNMP management software will read this information.
Under the SNMP node, configure normal SNMP including: Trap Destinations, Managers, Alarms, etc.
MIBs can be downloaded from the Downloads tab.

Instance SNMP

The instances will send SNMP traps to the Service VM. To get alerted for these traps, in the Configuration page, in the navigation pane, expand NetScaler, expand Events, and click Event Rules.
On the right, click Add.
Give the rule a name.
Select the Major and Critical severities, and move them to the right. Scroll down.
For the other sections, if you don’t configure anything then you will receive alerts for all of the devices, categories, and failure objects. If you configure any of them then only the configured entities will be alerted. Scroll down.
Click Save.
Select an Email Distribution List and click Done.

Management Service nsroot Password and AAA

To change the password of the default user account

On the Configuration tab, in the navigation pane, expand System, expand User Administration, and then click Users.
In the Users pane, click the default user account, and then click Edit.
In the Configure System User dialog box, in Password and Confirm Password, enter the password of your choice. Click OK.

AAA Authentication

If you would like to enable LDAP authentication for the Service VM, do that under Configuration > System > Authentication > LDAP.
In the right pane, click Add.
This is configured identically to NetScaler. Enter a Load Balancing VIP for LDAP. Change the Security Type to SSL and Port to 636. Scroll down.
Enter the Base DN in LDAP format.
Enter the bind account.
Check the box for Enable Change Password.
Click Retrieve Attributes and scroll down.
For Server Logon Attribute, select sAMAccountName.
For Group Attribute, select memberOf.
For Sub Attribute Name, select cn.
To prevent unauthorized users from logging in, configure a Search Filter. Scroll down.
If desired configure Nested Group Extraction
Click Create.
Expand System, expand User Administration, and click Groups.
On the right, click Add.
Enter the case sensitive name of the Active Directory group.
Select the admin permission.
Configure the Session Timeout. Click Create.
On the left, under System, click User Administration.
On the right, click User Lockout Configuration.
If desired, check the box next to Enable User Lockout, and configure the maximum logon attempts. Click OK.
On the left, under System, click Authentication.
On the right, click Authentication Configuration.
Change the Server Type to EXTERNAL and click Insert.
Select the LDAP server you created, and click OK.
Make sure Enable fallback is enabled, and click OK.

SSL Certificate and Encryption

Replace SDX Management Service Certificate

Before enabling secure access to the Management Service web console, you probably want to replace the Management Service certificate.

PEM format: The certificate must be in PEM format. The Management Service does not provide any mechanism for converting a PFX file to PEM. You can convert from PFX to PEM by using the Import PKCS#12 task in a NetScaler instance.
On the left, click System.
On the right, click Install SSL Certificate.
Select the certificate and key files in PEM format. If the key file is encrypted, enter the password. Then click OK. The Management Service will restart so there will be an interruption.
After the Management Service restarts, connect to it using HTTPS. You can’t make this change if you are connected using HTTP.
On the Configuration tab, click System.
On the right, click Change System Settings.
Check the box next to Secure Access Only, and click OK. This forces you to use HTTPS to connect to the Management Service.

SSL Encrypt Management Service to NetScaler Communication

From http://support.citrix.com/article/CTX134973: Communication from the Management Service to the NetScaler VPX instances is HTTP by default. If you want to configure HTTPS access for the NetScaler VPX instances, then you have to secure the network traffic between the Management Service and NetScaler VPX instances. If you do not secure the network traffic from the Management Service configuration, then the NetScaler VPX Instance State appears as Out of Service and the Status shows Inventory from instance failed.

Log on to the Management Service .
On the Configuration tab, click System.
On the right, click Change System Settings.
Change Communication with NetScaler Instance to https, as shown in the following screen shot:
Run the following command on the NetScaler VPX instance, to change the Management Access (-gui) to SECUREONLY:

set ns ip ipaddress -netmask netmask -arp ENABLED -icmp ENABLED -vServer DISABLED -telnet ENABLED -ftp ENABLED -gui SECUREONLY -ssh ENABLED -snmp ENABLED - mgmtAccess ENABLED -restrictAccess DISABLED -dynamicRouting ENABLED -ospf DISABLED -bgp DISABLED -rip DISABLED -hostRoute DISABLED -vrID 0

Or in the NetScaler instance management GUI go to Network > IPs, open the NSIP, and then check the box next to Secure access only.

SDX/XenServer LACP Channels

To use LACP, configure Channels in the Management Service, which creates them in XenServer. Then when provisioning an instance, connect it to the Channel.

In the Management Service, on the Configuration tab, expand System, and click Channels.
On the right, click Add.
Select a Channel ID.
For Type, select LACP or STATIC. If using Cisco vPC, then LACP is required. The other two options are for switch independent load balancing.
In the Interfaces section, move the Channel Member interfaces to the right by clicking the plus icon.
In the Settings section, for LACP you can select Long or Short, depending on switch configuration. Long is the default.
Click Create when done.
Click Yes when asked to proceed.
The channel will then be created on XenServer.

VPX Instances – Provision

To create an admin profile

Admin profiles specify the user credentials that are used by the Management Service when provisioning the NetScaler instances, and later when communicating with the instances to retrieve configuration data. The user credentials specified in an admin profile are also used by the client when logging on to the NetScaler instances through the CLI or the configuration utility.

The default admin profile for an instance specifies a user name of nsroot, and the password is also nsroot. This profile cannot be modified or deleted. However, you should override the default profile by creating a user-defined admin profile and attaching it to the instance when you provision the instance. The Management Service administrator can delete a user-defined admin profile if it is not attached to any NetScaler instance.

Important: Do not change the password directly on the NetScaler VPX instance. If you do so, the instance becomes unreachable from the Management Service. To change a password, first create a new admin profile, and then modify the NetScaler instance, selecting this profile from the Admin Profile list.

On the Configuration tab, in the navigation pane, expand NetScaler Configuration, and then click Admin Profiles.
In the Admin Profiles pane, click Add.
In the Create Admin Profile dialog box, set the following parameters:
- Profile Name*—Name of the admin profile. The default profile name is nsroot. You can create user-defined profile names.
- User Name—User name used to log on to the NetScaler instances. The user name of the default profile is nsroot and cannot be changed.
- Password*—The password used to log on to the NetScaler instance. Maximum length: 31 characters.
- Confirm Password*—The password used to log on to the NetScaler instance.
- Use global settings for NetScaler communication – you can uncheck this box and change the protocol to https.
Click Create. The admin profile you created appears in the Admin Profiles pane.

To upload a NetScaler VPX .xva file

You must upload a NetScaler VPX .xva file to the SDX appliance before provisioning the NetScaler VPX instances.

Download the NetScaler XVA (for XenServer) from the SDX Software Bundle Download Page. It’s in the Virtual Appliance section.
On the Configuration tab, in the navigation pane, expand NetScaler Configuration, and then click Software Images.
On the right, switch to the XVA Files tab, and then click Upload.
In the Upload NetScaler Instance XVA dialog box, click Browse, and select the XVA image file that you want to upload. Click Upload. The XVA image file appears in the NetScaler XVA Files pane after it is uploaded.

To provision a NetScaler instance

On the Configuration tab, in the navigation pane, expand NetScaler Configuration, and then click Instances.
In the NetScaler Instances pane, click Add.
In the Provision NetScaler Wizard follow the instructions in the wizard.
Click Create. The NetScaler instance you provisioned appears in the NetScaler Instances pane.

The wizard will ask for the following info:

Name* – The host name assigned to the NetScaler instance.
IP Address* – The NetScaler IP (NSIP) address at which you access a NetScaler instance for management purposes. A NetScaler instance can have only one NSIP. You cannot remove an NSIP address.
Netmask* – The subnet mask associated with the NSIP address.
Gateway* – The default gateway that you must add on the NetScaler instance if you want access through SSH or the configuration utility from an administrative workstation or laptop that is on a different network.
Nexthop to Management Service – Adds a static route on the NSIP network so SDX Management Service can communicate with the instance NSIP. Only needed if instance default gateway and instance NSIP are on separate networks.
XVA File* – The .xva image file that you need to provision. This file is required only when you add a NetScaler instance.
Feature License* – Specifies the license you have procured for the NetScaler. The license could be Standard, Enterprise, and Platinum.
Admin Profile* – The profile you want to attach to the NetScaler instance. This profile specifies the user credentials that are used by the Management Service to provision the NetScaler instance and later, to communicate with the instance to retrieve configuration data. The user credentials used in this profile are also used while logging on to the NetScaler instance by using the GUI or the CLI. It is recommended that you change the default password of the admin profile. This is done by creating a new profile with a user-defined password. For more information, see Configuring Admin Profiles.
Total Memory (MB)* – The total memory allocated to the NetScaler instance.
#SSL Cores* – Number of SSL cores assigned to the NetScaler instance. SSL cores cannot be shared. The instance is restarted if you modify this value.
Throughput (Mbps)* – The total throughput allocated to the NetScaler instance. The total used throughput should be less than or equal to the maximum throughput allocated in the SDX license. If the administrator has already allocated full throughput to multiple instances, no further throughput can be assigned to any new instance.
Packets per second* – The total number of packets received on the interface every second.
CPU – Assign a dedicated core or cores to the instance or the instance shares a core with other instance(s).
User Name* – The root user name for the NetScaler instance administrator. This user has superuser access, but does not have access to networking commands to configure VLANs and interfaces. (List of non-accessible commands will be listed here in later versions of this document)
Password* – The password for the root user.
Shell/Sftp/Scp Access* – The access allowed to the NetScaler instance administrator.
Interface Settings – This specifies the network interfaces assigned to a NetScaler instance. You can assign interfaces to an instance. For each interface, if you select Tagged, specify a VLAN ID.
- Important:The interface ID numbers of interfaces that you add to an instance do not necessarily correspond to the physical interface numbering on the SDX appliance. For example, if the first interface that you associate with instance 1 is SDX interface 1/4, it appears as interface 1/1 when you log on to the instance and view the interface settings, because it is the first interface that you associated with instance 1.
- If a non-zero VLAN ID is specified for a NetScaler instance interface, all the packets transmitted from the NetScaler instance through that interface will be tagged with the specified VLAN ID. If you want incoming packets meant for the NetScaler instance that you are configuring to be forwarded to the instance through a particular interface, you must tag that interface with the VLAN ID you want and ensure that the incoming packets specify the same VLAN ID.
- For an interface to receive packets with several VLAN tags, you must specify a VLAN ID of 0 for the interface, and you must specify the required VLAN IDs for the NetScaler instance interface.
NSVLAN ID – An integer that uniquely identifies the NSVLAN. Minimum value: 2. Maximum value: 4095.
Tagged – Designate all interfaces associated with the NSVLAN as 802.1q tagged interfaces.
Interfaces – Bind the selected interfaces to the NSVLAN.

Here are screenshots from the wizard:

In the Provision NetScaler section, enter a name for the instance.
Enter the NSIP, mask, and Gateway.
Nexthop to Management Service is new in 11.0 build 64 and newer. If the default gateway is on a different network than the NSIP, then enter a next hop router address on the NSIP network so the SDX Management Service can communicate with the NSIP.
In the XVA File field, you can Browse > Local to select an XVA file on your file system. Or you can Browse > Appliance, and select an XVA file that has already been uploaded.
Select an Admin Profile created earlier.
Enter a Description. Scroll down.
In the License Allocation section, change the Feature License to Platinum.
For Throughput, partition your licensed bandwidth. If you are licensed for 8 Gbps, make sure the total of all VPX instances does not exceed that number.
For Allocation Mode, Burstable is also an option. Fixed bandwidth can’t be shared with other instances. Burstable can be shared. See Bandwidth Metering in NetScaler SDX at Citrix Docs.
In the Resource Allocation section, change the Total Memory to 4096.
For SSL Chips, specify between 1 and 16. Some SSL/TLS features require at least one chip.
For CPU, select one of the Dedicated options. Then scroll down.
In the Instance Administration section, enter a new local account that will be created on the VPX. This is in addition to the nsroot user. Note, not all functionality is available to this account. Scroll down.
In the Network Settings section, leave 0/1 selected, and deselect 0/2.
Click Add to connect the VPX to more interfaces.
If you have Port Channels, select one of the LA interfaces.
Try not configure any VLAN settings here. If you do, XenServer filters the VLANs available to the VPX instance. Changing the VLAN filtering settings later probably requires a reboot. Click Add.
In the Management VLAN Settings section, do not configure anything in this section unless you need to tag the NSIP VLAN. Click Done.
After a couple minutes the instance will be created. Click Close.
In your Instances list, click the IP address to launch the VPX management console. Do the following at a minimum (instructions in the NetScaler System Configuration page):
1. Enable MAC Based Forwarding – System > Settings > Configure Modes > MAC Based Forwarding
2. Add SNIPs for each VLAN – System > Network > IPs
3. Add VLANs and bind to SNIPs – System > Network > VLANs
4. Change default gateway – System > Network > Routes > 0.0.0.0
5. Create another instance on a different SDX and High Availability pair them together – System > High Availability

Applying the Administration Configuration

At the time of provisioning a NetScaler VPX instance, the Management Service creates some policies, instance administration (admin) profile, and other configuration on the VPX instance. If the Management Service fails to apply the admin configuration at this time due to any reason (for example, the Management Service and the NetScaler VPX instance are on different subnetworks and the router is down or if the Management Service and NetScaler VPX instance are on the same subnet but traffic has to pass through an external switch and one of the required links is down), you can explicitly push the admin configuration from the Management Service to the NetScaler VPX instance at any time.

On the Configuration tab, in the navigation pane, click NetScaler.
In the NetScaler Configuration pane, click Apply Admin Configuration.
In the Apply Admin Configuration dialog box, in Instance IP Address, select the IP address of the NetScaler VPX instance on which you want to apply the admin configuration.
Click OK.

VPX Instances – Manage

You may login to the VPX instance and configure everything normally. SDX also offers the ability to manage IP address and SSL certificates from SDX rather than from inside the VPX instance. The SDX Management Service does not have the ability to create certificates so it’s probably best to do that from within the VPX instance.

To view the console of a NetScaler instance

Connect to the Management Service using https.
Viewing the console might not work unless you replace the Management Service certificate.
In the Management Service, go to Configuration > NetScaler > Instances.
On the right, click the ellipsis next to an instance, and click Console.
The instance console then appears.
Another option is to use the Lights Out Module and the xl console command as detailed at Citrix Blog Post SDX Remote Console Access of VIs.

To start, stop, delete, or restart a NetScaler instance

On the Configuration tab, in the navigation pane, expand NetScaler, and click Instances.
In the Instances pane, right-click the NetScaler instance on which you want to perform the operation, and then click Start or Shut Down or Delete or Reboot.
In the Confirm message box, click Yes.

Creating a Subnet IP Address on a NetScaler Instance

You can create or delete a SNIP during runtime without restarting the NetScaler instance.

On the Configuration tab, in the navigation pane, click NetScaler.
In the NetScaler Configuration pane, click Create IP.
In the Create NetScaler IP dialog box, specify values for the following parameters.
- IP Address* – Specify the IP address assigned as the SNIP or the MIP address.
- Netmask* – Specify the subnet mask associated with the SNIP or MIP address.
- Type* – Specify the type of IP address. Possible values: SNIP.
- Save Configuration* – Specify whether the configuration should be saved on the NetScaler. Default value is false.
- Instance IP Address* – Specify the IP address of the NetScaler instance.
Click Create.

Create a VLAN on a NetScaler instance

Go to NetScaler > Instances.
Select an instance, and click VLAN Bindings.
Click Add.
Enter a VLAN ID and select an interface.
Check the box for Tagged if needed.
Notice there’s no way to bind a SNIP. You do that inside the instance. Click Create.

To save the configuration on a NetScaler instance

On the Configuration tab, in the navigation pane, click NetScaler.
In the NetScaler pane, click Save Configuration.
In the Save Configuration dialog box, in Instance IP Address, select the IP addresses of the NetScaler instances whose configuration you want to save.
Click OK.

Change NSIP of VPX Instance

The best way to change the NSIP is to edit the instance.

If you change NSIP inside of VPX instead of using the Edit Instance wizard in the Management Service, see article http://support.citrix.com/article/CTX139206 to adjust the XenServer settings.

Enable Call Home

On the Configuration tab, in the navigation pane, click the NetScaler node.
On the right, click Call Home.
Enter an email address to receive communications regarding NetScaler Call Home.
Check the box next to Enable Call Home.
Select the instances to enable Call Home, and click OK.
You can view the status of Call Home by expanding NetScaler, and clicking Call Home.
The right pane indicates if it’s enabled or not. You can also configure Call Home from here.

VPX Instance – Firmware Upgrade

Upload NetScaler Firmware Build Files

To upgrade a VPX instance from the Management Service, first upload the firmware build file.

Download the NetScaler firmware using the normal method. It’s in the Build section.
On the SDX, in the Configuration tab, on the left, expand NetScaler, and click Software Images.
On the right, in the Software Images tab, click Upload.
Browse to the build…tgz file and click Open.

Upgrading Multiple NetScaler VPX Instances

You can upgrade multiple instances at the same time.

To prevent any loss of the configuration running on the instance that you want to upgrade, save the configuration on the instance before you upgrade the instance.
On the Configuration tab, in the navigation pane, expand NetScaler and click Instances.
Select an instance, and click Upgrade.
In the Upgrade NetScaler dialog box, in Build File, select the NetScaler upgrade build file of the version you want to upgrade to. Ignore the Documentation File. Click OK.

Management Service Monitoring

To view syslog, in the navigation pane, expand System, click Auditing, and then click Syslog Message in the right pane.
To view the task log, in the navigation pane, expand Diagnostics, and then click Task Log.
To view Management Service events, on the Configuration tab, in the expand System and click Events.
NetScaler > Entities lets you see the various Load Balancing entities configured on the instances. You might have to click Poll Now to get them to show up.
To view instance alerts, go to NetScaler > Events > All Events.
There is also event reporting.

Management Service Backups

The SDX appliance automatically keeps three backups of the Management Service configuration that are taken daily at 12:30 am.

Backups in NetScaler SDX contain the following:

Single bundle image
NetScaler XVA image
NetScaler upgrade image
Management Service image
Management Service configuration
NetScaler SDX configuration
NetScaler configuration

You can go to Management Service > Backup Files to backup or restore the appliance’s configuration. And you can download the backup files.

You can configure the number of retained backups by clicking System on the left, and then clicking Backup Policy in the right pane.

↧

Detailed Change Log

November 20, 2016, 2:56 pm

≫ Next: NetScaler Management and Analytics System (MAS) 12

≪ Previous: NetScaler SDX 11.1

This post lists all minor and major changes made to carlstalhood.com.

2016-12-26
- VMware UEM > Additional Config – links to Fabian Lenz’s Predefined Settings articles
- Delivery Controller 7.6.2000 – link to Controller Hotfix 1
- Delivery Controller 7.12 > Database Maintenance – link to article to groom configuration logging database
2016-12-25
- VMware Horizon > Master RDS Host – Windows 2016 screenshots
- vROps Horizon > Planning – link to webinar on what’s new in 6.4
2016-12-23
- vROps Horizon > Configure Broker Agent – updated for 6.4
- Published Apps > App-V – ensure App-V components installed on VDA, Enable-Appv
2016-12-22
- VMware UEM > Policy – UEM can run without group policy (NoAD mode)
- Horizon View Load Balancing > Overview – added Visio drawings
- VMware Identity Manager > Planning – link to multi-datacenter Tech Paper
- NetScaler Gateway VPN > IP Pool – limit users to one VPN session
- Receiver > Skype – brief new section on the HDX Media Engine
- SmartAccess > EPA Config – link to article on registry scan
- SmartAccess – screenshot of Director showing SmartAccess Filters (h/t Steve Noel)
2016-12-20
- NetScaler VPX – use machine.id to set NSIP
- WEM > Broker – Link to article on throttling connections
- SmartAccess > EPA Config – link to article on generic Antivirus/Firewall scans
- SCOM > New Reports – new reports in XAXD SCOM Pack 3.9
2016-12-19
- nFactor > Login Schema – how to add label with custom HTML
- Published Apps > App-V – link to latest App-V 5.1 hotfix
2016-12-18
- StoreFront > Authentication – link to SSPR Central Store creation tool
- StoreFront > Gateway Config – link to Blog Post on simplified config in NetScaler 11.1
- Delivery Controller > vCenter connection – link to article on updating certificate thumbprint in database
- SmartAccess > EPA Config – links to EPA configuration articles
- SCOM Pack > Machine Agent – link to article on optimizing for large Citrix environments
- Gateway 11.1 > Customize – link to Sam Jacob’s RfWebUI article
- Access Point 2.8 > Admin Interface – new section
- VMware Horizon 7 – updated download links to latest versions
2016-12-17
- PvS > Update vDisk – Windows 2016 screenshots
- PvS > Create Devices – Windows 2016 screenshots, new section on PvS Catalog
- PvS > Convert to vDisk – Windows 2016 screenshots
2016-12-15
- Remote PC – VDA 7.12 Core Services, Windows 2016 screenshots
2016-12-14
- PvS > Server Install – PvS 7.12, Windows 2016 screenshots
- Citrix SCOM Management Packs – XenApp/XenDesktop (2016_11_17) – Windows 2016 screenshots
2016-12-13
- NetScaler MAS > Import – updated screenshots for 11.1-50
- VDA 7.6.2000 – Receiver 4.4.3000
- WEM > Assignments – clarified drive letter for network drive mapping
2016-12-12
- Citrix Policy > Graphics – new section on EDT in 7.12
- NetScaler Firewall Rules – UDP 1494/2598 for EDT
2016-12-11
- Session Recording 7.12 – Window 2016 screenshots, IP Range policy criteria
- StoreFront 3.8 Basic Config – Windows 2016 screenshots
- Receiver 4.6 – Windows 2016 screenshots
- VDA Cleanup – how to run silently
- Citrix Profile Management 5.6 – Windows 2016 screenshots
2016-12-10
- WEM 4.1 – Windows 2016 screesnshots, Transformer, app maintenance mode
2016-12-8
- Catalogs > Tags – publish on subset of Delivery Group
- VDA 7.12 – Windows 2016 screenshots
2016-12-7
- Zones > Caveats – added Local Host Cache and general design guidance
2016-12-6
- Director 7.12 – Custom Reports, SNMP Alerts
- Delivery Controller 7.12 – Local Host Cache is new feature
- Controller > Health Check – link to Matt Bodholdt XenDesktop 7.x Controller Service Status Script at CUGC
2016-12-2
- VDA User Policy > Runonce – alternative script to only run IE Active setup
- VDA > Graphics – link to Citrix Session Graphics Memory Reference
- VDA > Antivirus – link to new Citrix Antivirus Recommendations Blog Post
2016-11-30
- Catalogs > MCS > Image Prep – updated with info from CTX217456
2016-11-29
- Receiver > Prefer Template Directory – Jan Handrik’s script to create shortcuts
2016-11-25
- GSLB > Planning – Phil Bossman’s Responder to block external users from querying internal FQDNs
- NetScaler Gateway 11.1 > Other Customizations – link to CTP Sam Jacob’s CUGC article on adding text to logon page
- WEM > Install Agent – link to KB article on vuemlocaluser long password
2016-11-24
- StoreFront Tweaks > PNAgent – how to set default store so /Citrix/PNAgent/config.xml works
- StoreFront > Auth config – added link to RFWeb Auth config
2016-11-23
- NetScaler Firewall Rules – added Ping from SDX SVM to instances
- VDA 7.11 – how to find the standalone VDA installers
2016-11-22
- Computer Group Policy – modified settings list to hopefully improve readability
- MCS > Image Prep – increase Services Timeout
2016-11-21
- VDA – removed links to Windows 8 Optimization Guide at Citrix Blogs
- StoreFront > Export/Import – changed link from Citrix Blog to Citrix Docs
- MCS – link to CTP Aaron Parker’s Hyper-V Storage Sizing article
- Receiver > Install – command lines to remove Account and add a new one
2016-11-20
- Controller > Studio Administrators and RDS Licensing – updated some screenshots with Windows 2016
- Citrix Policies > Graphics Tools – link to GPUPerf 3.0
- VDA 7.11 > Antivirus – removed copied Symantec text; use the Symantec links instead. Added link to Trend Micro slow logins article.
- StoreFront > Logon Simulator – link to ControlUp’s free Logon Simulator
2016-11-17
- Receiver Logging – new section containing .reg file from Wolfgang Thürr
- WEM Agent – added screenshot of registry entries, and vuemLocalUser password switch for long/complex password
2016-11-16
- Horizon View Load Balancing – fixed a port number typo
2016-11-15
- SmartControl requires NetScaler Platinum Edition
- About Carl Stalhood – added Varrow awards (acquired by Sirius), and NetScaler Rocks Slack link
2016-11-14
- Zones – added info on zoned Delivery Controllers in StoreFront (h/t Citrix Mark Dear)
- StoreFront 3.7 – Related Pages – cross-linked Basic Settings and Tweaks pages
- Session Recording Player – link to article on incompatible Citrix Client
- NetScaler MAS – add instances – link to Docs article on the discovery process
2016-11-12
- Director Saved Filters – how to store on UNC path (h/t CTP Jarian Gibson)
2016-11-11
- Cloud Pod – Link to Horizon 7 multi-datacenter guide
- StoreFront 3.0.2000 – fix for Console missing root certificate
2016-11-10
- Non-persistent VDAs – added note that Connection Leasing isn’t supported with pooled machines.
- Delivery Controller 7.6.2000 – license server should be 11.14.0.1, not 11.13.1.2
2016-11-09
- Director 7.11 > Configuration – added note about Director discovering all Controllers and failing over automatically
- StoreFront 3 menu page – renamed to 3.0.2000
- StoreFront 3 Basic Config – forgot to update to 3.0.2000. Updated HTML5 Receiver to 2.2. Updated Receiver versions.
- StoreFront Single FQDN – link to Internal Beacon Citrix KB article
2016-11-08
- Profile Management – added a note about Credentials Roaming.
2016-11-07
- smaZones – added a Caveats section, and how to change Primary Site
2016-11-06:
- RDSH Application Testing Considerations
- New section on Persistent vs Non-persistent VDAs
2016-11-05:
- Runonce /AlternateShellStartup – Black borders, and Run registry key (e.g. VMware Tools icon)
2016-11-04:
- Workspace Environment Manager – Link to XenTegra overview video
2016-10-25:
- XA/XD menu pages – changed Design Handbook link to new Best Practices guide

↧

NetScaler Management and Analytics System (MAS) 12

May 6, 2017, 8:44 am

≫ Next: NetScaler Essential Concepts: Part 1 – Request-Response, HTTP Basics, and Networking

≪ Previous: Detailed Change Log

Navigation

Planning
Import Appliance into vSphere
IP Configuration and High Availability
Add Instances
Licensing
Enable AppFlow
Enable Syslog on Instances
NSroot Password
Management Certificate
System Configuration
System Email Notifications
Authentication
Analytics (Insight) Thresholds and Alerts
Geo Map
Instance Email Alerts (SNMP Traps)
Director Integration
Use NetScaler MAS – HDX Insight, Gateway Insight, Security Insight
Troubleshooting
Upgrade NetScaler MAS

= Recently Updated

Planning

NetScaler MAS is a replacement for NetScaler Insight Center, Command Center, and Control Center. It’s a combination of these three different tools.

MAS Licensing – appliance instance management is free (unlimited). Analytics and Application monitoring are free for up to 30 vServers. Beyond 30 vServers, licenses can be purchased in 100 vServer packs. See NetScaler MAS Licensing at Citrix Docs.

MAS version – The version/build of NetScaler MAS must be the same or newer than the version/build of the NetScaler appliances being monitored.

HDX Insight Requirements (AppFlow Analytics for ICA traffic):

Your NetScaler appliance must be running Enterprise Edition or Platinum Edition.
NetScaler must be 10.1 or newer.
HDX Insight works with the following Receivers:
- Receiver for Windows must be 3.4 or newer.
- Receiver for Mac must be 11.8 or newer.
- Receiver for Linux must be 13 or newer.
- Notice no mobile Receivers. See the Citrix Receiver Feature Matrix for the latest details.
For ICA Session Reliability with AppFlow: NetScaler 10.5 build 54 and newer.
- For ICA Session Reliability, AppFlow, and NetScaler High Availability: NetScaler 11.1 build 49 and newer.
Internally, when a user clicks an icon from StoreFront, an ICA connection is established directly from Receiver to the VDA, thus bypassing the internal NetScaler. To produce AppFlow statistics, here are some methods of getting ICA traffic to flow through an internal NetScaler:
- Implement NetScaler Gateway ICA Proxy (SSL) internally. However, Single Sign-on (pass-through authentication) does not work through NetScaler Gateway. To use SSL ICA Proxy without authenticating at NetScaler Gateway, see CTX200129 – How to Force Connections through NetScaler Gateway Using Optimal Gateways Feature of StoreFront.
- Route ICA traffic (TCP/UDP 1494 and TCP/UDP 2598) through a NetScaler SNIP, and NetScaler routes it to the VDAs. Citrix Blog Post – How to Deploy NetScaler Insight Center with Policy Based Routing
- NetScaler 11 and newer can proxy ICA traffic through a SOCKS protocol Cache Redirection vServer. Advantages: no need to authenticate at NetScaler Gateway, and no routing changes. See Citrix Blog Post Gathering HDX Insight Analytics for LAN Users with NetScaler Using SOCKS for more information.
- Citrix Docs How NetScaler Insight Center is Deployed in a Network and Enabling HDX Insight Data Collection detail additional ICA routing/proxy considerations – Transparent Mode, NetScaler Gateway Single-Hop and Double-Hop, LAN User Mode (NetScaler as SOCKS Proxy), CloudBridge, Multi-Hop (NetScaler and CloudBridge with connection chaining)
For ICA round trip time calculations, in a Citrix Policy, enable the following settings:
- ICA > End User Monitoring > ICA Round Trip Calculation
- ICA > End User Monitoring > ICA Round Trip Calculation Interval
- ICA > End User Monitoring > ICA Round Trip Calculation for Idle Connections

Citrix CTX204274 How ICA RTT is calculated on NetScaler Insight: ICA RTT constitutes the actual application delay. ICA_RTT = 1 + 2 + 3 + 4 +5 +6:

Client OS introduced delay
Client to NS introduced network delay (Wan Latency)
NS introduced delay in processing client to NS traffic (Client Side Device Latency)
NS introduced delay in processing NS to Server (XA/XD) traffic (Server Side Device Latency)
NS to Server network delay (DC Latency)
Server (XA/XD) OS introduced delay (Host Delay)

Import MAS Appliance

You can use either the vSphere Client, or the vSphere Web Client, to import the appliance. In vSphere Client, open the File menu, and click Deploy OVF Template. vSphere Web Client instructions are shown below.

Download NetScaler MAS for ESX, and then extract the .zip file.
In vSphere Web Client, right-click a cluster, and click Deploy OVF Template.
In the Select source page, select Local file, and browse to the NetScaler MAS .ovf files. If vCenter 6.5+, select all three files. Click Next.
In the Review details page, click Next.
In the Select name and folder page, enter a name for the virtual machine, and select an inventory folder. Then click Next.
In the Select a resource page, select a cluster or resource pool, and click Next.
In the Select storage page, select a datastore. If a single appliance, or if a database appliance, due to high IOPS, SSD or Flash is recommended.
Change the virtual disk format to Thin Provision. Click Next.
In the Setup networks page, choose a valid port group, and click Finish.
In the Ready to Complete page, check the box next to Power on after deployment, and click Finish.
Before powering on the appliance, you can review its specs.
If you see a message about Invalid guestid in Configinfo, then you’ll have to upgrade the VM hardware version first. VM hardware version 4 seems to be too old.
1. Right-click the NetScaler MAS appliance, expand Compatibility, and click Upgrade VM Compatibility.
2. Select at least hardware version 7.
Now you can review the default specs.
Citrix Docs How to Attach an Additional Disk to NetScaler MAS: power off appliance, add a second disk that’s larger than the first, then power on the appliance. Note: you can only add one disk. Use the MAS storage calculator to determine the recommended size of the disk.
- Enabling more features on MAS means more disk space. MAS features that consume large amounts of disk space include:Web/SSL Insight, and Advanced Analytics. SNMP/Syslog/Network Reports have a configurable purge interval.
Power on the VM if it’s not running already.
If you see a message about freeBSD not being supported, then you might have to upgrade the VM Hardware Compatibility Level. VM hardware version 4 seems to be too old.
1. Right-click the NetScaler MAS appliance, expand Compatibility and click Upgrade VM Compatibility.
2. Select at least hardware version 7.

Appliance IP Configuration and Deployment Modes

Open the console of the virtual machine.
Configure an IP address.
Enter 7 when done.
When prompted for Deployment Type, enter 1 for NetScaler MAS Server. The first appliance must always be NetScaler MAS Server.
Other deployment options:
1. Notice the option for Remote Backup Node.
2. Also notice the new Telemetry Node for Advanced Analytics. For the telemetry node, the root password for this system is freebsd. Advanced Analytics requires NetScaler 12.
3. Scale-out mode is currently not supported, so don’t select Connector Node, Database Node, or MAS Agent.
4. For Advanced Analytics (Telemetry Node), when enabling AppFlow on a vServer, select Logstream.
5. On the NetScaler instance, this adds the telemetry node as a logstream AppFlow collector.

MAS High Availability

For the initial release of MAS 12.0, Citrix does not recommend enabling HA mode due to increased resource usage. This issue should be resolved in the next MAS version released around June 2017. An alternative to HA is the Remote Backup Node.

If you want to deploy two NetScaler MAS appliances and HA pair them, enter no for Standalone, and yes for First Server Node.
1. Note: HA is only for database redundancy. All other traffic (SNMP, AppFlow) only goes to one node.
Enter Yes to reboot.
Deploy another appliance.
This time, when asked if First Server Node, enter no. You will then be asked for the IP address of the first node. Enter the nsroot password.

MAS Maintenance

From CTX220000 How to reboot or shutdown NetScaler MAS using CLI: when using the MAS CLI, do not use the reboot command since it will cause data corruption. Instead, run shutdown -r now.
If you need to add a static route to NetScaler MAS, then see CTX223282 How to Add a Static Route on NetScaler MAS.

Getting Started

Once you’ve built all of the nodes, point your browser to the primary NetScaler MAS IP address, and login as nsroot/nsroot.
If you see CUXIP, either Skip or Enable the Customer User Experience Improvement Program.
Click Get Started
If you did a standalone deployment, select Single Server Deployment, click Next, and skip to the next section to Add Instances.
If you deployed high availability appliances, select Two servers deployed in High Availability Mode, and click Next.
It should show both nodes. Click Deploy on the top right.
Click Yes to reboot the appliances.
If you login to one of the appliances, at System > Deployment, you’ll see the performance of each node. Notice the Break HA icon on the top right.
You can manage the pair by logging in to either node.
Or you can load balance the pair. Load Balancing is only useful for administration. All other communications (e.g. SNMP, AppFlow) go directly to one of the nodes. See High Availability Deployment at Citrix Docs for load balancing instructions.

Add Instances

NetScaler MAS must discover NetScaler instances before they can be managed. Citrix Docs How NetScaler MAS Discovers Instances.

On the Add New Instances page, click + New near the top right.
Enter the NSIP address of a NetScaler appliance.
Click the pencil next to ns_nsroot_profile.
Enter the password for the nsroot account.
Enter an SNMP v2 community string or SNMP v3 Security Name that NetScaler MAS will configure on the appliance.
The NetScaler Profile defaults to using https for instance communication. You can change it by unclicking Use global settings for NetScaler communication. Click OK.
Then click OK to add the instance.
A progress window will appear.
You can add more instances, or just click Finish.
To add more instances later, click the top left hamburger icon, go to Networks > Instances, select the Instance type, and on the right, click Add.

Licenses

Virtual Server License Packs

Without licenses, you can enable analytics features on only 30 Virtual Servers. You can install additional licenses in 100 Virtual Server packs. More info at NetScaler MAS Licensing at Citrix Docs.

Go to Networks> Licenses > System Licenses to see the number of currently installed licenses, and the number of managed virtual servers.
On the left, go to Networks > Licenses.
On the right, notice the Host ID.
At mycitrix.com, allocate your NetScaler MAS licenses to this Host ID.
Then use the Browse button to upload the allocated license file.
Click Finish after uploading the license file to apply it.
The License Expiry Information section shows you the number of installed licenses and when they expire.
You can use the Notification Settings section to email you when licenses are almost fully consumed or about to expire.

Allocate licenses to Virtual Servers

You can manually unassign a MAS Virtual Server license and reassign it to a different Virtual Server.

Go to Networks > Licenses > System Licenses to see the number of Allowed Virtual Servers.
On the top right, click Modify licensed Virtual Servers.
In the top row, select the type of Virtual Server you want to unlicense or license.
Select one or more Virtual Servers, and click the Mark Unlicensed button. Only the licensed Virtual Servers are listed.
Click Yes when asked to mark unlicensed.
The unlicensed Virtual Servers won’t be removed from the list until you click the Finish button.
Back in Modify licensed Virtual Servers, to allocate a license to a Virtual Server, click the Add Virtual Servers button.
Select the Virtual Server(s) you want to allocate, and click Select.
Click Finish when done.

Enable AppFlow / Insight

Go to Networks > Instances > Instance type (e.g. NetScaler VPX).
Right-click an instance, and then click Enable/Disable Insight.
At the top of the page are boxes you can check.
With Load Balancing selected in the View list, right-click your StoreFront load balancer, and click Enable AppFlow.
Type in true.
if you want Advanced Analytics, change the Transport Mode selection to Logstream instead of IPFIX. This assumes you have a MAS Telemetry Node.
Select Web Insight.
If App Firewall is enabled on the vServer, then also select Security Insight.
HTML Injection injects JavaScript in HTTP responses to measure page load times.
Click OK.
Use the View drop-down to select VPN.
Right-click a NetScaler Gateway Virtual Server, and click Enable AppFlow.
In the Select Expression drop-down, select true.
For Export Option, select ICA and HTTP, and click OK. The HTTP option is for Gateway Insight.
The TCP option is for the second appliance in double-hop ICA. If you need double-hop, then you’ll also need to run set appflow param -connectionChaining ENABLED on both appliances. See Enabling Data Collection for NetScaler Gateway Appliances Deployed in Double-Hop Mode at Citrix Docs for more information.
By default, with AppFlow enabled, if a NetScaler High Availability pair fails over, all Citrix connections will drop, and users must reconnect manually. NetScaler 11.1 build 49 adds a new feature to replicate Session Reliability state between both HA nodes.
1. From Session Reliability on NetScaler High Availability Pair at Citrix Docs: Enabling this feature will result in increased bandwidth consumption, which is due to ICA compression being turned off by the feature, and the extra traffic between the primary and secondary nodes to keep them in sync.
2. If you still want this feature, on a NetScaler 11.1 build 49 and newer appliance, go to System > Settings.
3. On the right, in the Settings section, click Change ICA Parameters.
4. Check the box next to Session Reliability on HA Failover, and click OK.
AppFlow (e.g. HDX Insight) information can be viewed in NetScaler MAS under the Analytics node.

Citrix Blog Post – NetScaler Insight Center – Tips, Troubleshooting and Upgrade

Enable Syslog on Instance

MAS can configure Syslog on the NetScaler instances, including sending Syslog to MAS.

Go to Networks > Configuration Jobs.
On the right, click Create Job.
Give the job a name.
Change the Configuration Source drop-down to Inbuilt Template.
On the left, drag the NSConfigureSyslogServer blue text to the right side of the screen. Notice that this job uses variables.
On the bottom, click Next.
On the Select Instances page, click Add Instances.
Select one or more instances, and click OK.
Click Next.
In the Specify Variable Values page, switch to the Common Variable Values for all instances tab.
Enter the Syslog server IP address (e.g. MAS IP address). Click Next.
In the Job Preview page, review the commands it’s going to run, and click Next.
In the Execute page, click Finish.
The job will eventually say Completed.

Nsroot Password

In MAS, go to Users > User Administration > Users.
On the right, right-click the nsroot account, and click Edit.
Enter a new password.
You can also specify a session timeout. Click OK.

Management Certificate

The certificate to upload must already be in PEM format. If you have a .pfx, you must first convert it to PEM (separate certificate and key files). You can use NetScaler to convert the .pfx, and then download the converted certificate from the appliance.

Go to System > System Administration.
On the right, in the Set Up NetScaler MAS section, click Install SSL Certificate.
Click Choose File to browse to the PEM format certificate and key files. If the keyfile is encrypted, enter the password. Click OK.
Click Yes to reboot the system.

System Configuration

Go to System > System Administration.
On the right, modify settings (e.g.Change Time Zone) as desired.
To change the Session Timeout, click Change System Settings.
Configure SSL Settings lets you disable TLS 1 and TLS 1.1 by clicking the Protocol Settings section in the Edit Settings section on the right side of the screen.
In the right column, under Policy Administration, are additional settings. For example, System Prune Settings, which defaults to deleting system events, Audit Logs, and Task Logs after 15 days. System events are generated by the MAS appliance, which contrasts with Instance events (SNMP traps) that are generated by NetScaler appliances.
System Backup Settings lets you export MAS backups to an external file server.
On the left are Instance Settings.
Events prune Settings controls when instance SNMP traps are pruned, which defaults to 40 days.
Instances Backup Settings lets you configure the number of backup files to retain for each instance. There’s also an option to backup the NetScaler config whenever the configuration is saved.
If you are sending Syslog from instances to MAS, Syslog Purge Settings controls when the log entries are purged. You can even configure different purge intervals for different types of NetScaler Gateway log entries.
There are more settings under System > Analytics Settings.
ICA Session Timeout can be configured by clicking the link. Two minutes of non-existent traffic must occur before the session is considered idle. Then this idle timer starts.
On the left, click System > NTP Servers.
On the right, click Add.
Enter an NTP server, and click Create.
After adding NTP servers, click NTP Synchronization.
Check the box next to Enable NTP Synchronization, and click OK.
Click Yes to restart.
Go to System > Auditing > Syslog Servers.
On the right, click Add.
Enter the syslog server IP address, and select Log Levels. Click Create.
You can click Syslog Parameters to change the timezone and date format.

System Email Notifications

Go to System > Notifications > Email.
On the right, on the Email Servers tab, click Add.
Enter the SMTP server address, and click Create.
On the right, switch to the Email Distribution List tab, and click Add.
Enter an address for a destination distribution list, and click Create.
On the left, click System > Notifications.
On the right, click Change Notification Settings.
Move notification categories (e.g. UserLogin) to the right.
Check the box next to Send Email. Select a notification distribution list. Then click OK.

Authentication

Go to System > Authentication > LDAP.
On the right, click Add.
This is configured identically to NetScaler. Enter a Load Balancing VIP for LDAP. Change the Security Type to SSL, and Port to 636. Scroll down.
Enter the Base DN in LDAP format.
Enter the bind account credentials.
Check the box for Enable Change Password.
Click Retrieve Attributes, and scroll down.
For Server Logon Attribute, select sAMAccountName.
For Group Attribute, select memberOf.
For Sub Attribute Name, select cn.
To prevent unauthorized users from logging in, configure a Search Filter. Scroll down.
If desired, configure Nested Group Extraction.
Click Create.
On the left, go to System > User Administration > Groups.
On the right, click Add.
Enter the case sensitive name of your NetScaler Admins AD group.
Move the admin Permission to the right. Click Next.
On the Select Applications page, click Next.
You can optionally configure a session timeout, which defaults to 15 minutes. Click Finish.
On the left, go to System > User Administration.
On the right, click User Lockout Configuration.
If desired, check the box next to Enable User Lockout, and configure the maximum logon attempts. Click OK.
On the left, go to System > Authentication.
On the right, click Authentication Configuration.
Change the Server Type to EXTERNAL, and click Insert.
Select the LDAP server you created, and click OK.
Make sure Enable fallback local authentication is checked, and click OK.

Analytics Thresholds

Go to System > Analytics Settings > Thresholds.
On the right, click Add.
Enter a name.
Use the Traffic Type drop-down to select HDX, Web, or Security.
Use the Entity drop-down to select a category of alerts. What you choose here determines what’s available in the Rule section.
Check the box to Enable Alert.
Check the box to Notify through Email.
In the Rule section, select a rule, and enter threshold values. Click Create.

Geo Map

Download the Maxmind database from http://geolite.maxmind.com/download/geoip/database/GeoLiteCity.dat.gz.
Extract the .gz file.
On the left, go to System > Advanced Settings, and click Geo Database Files.
On the right, click Upload.
Browse to the extracted GeoLiteCity.dat file, and click Open.
You can also define Geo locations for internal subnets. Go to Networks > Sites > Private IP Blocks.
On the right, click Add.
Enter a name for the subnet.
Enter the starting and ending IP address.
Select a Geo Location (Country, Region, City).
Click Create.
On the left, go to Networks > Sites.
On the right, click Add.
Give the site a name.
Click Add IP Block.
Select one or more IP Blocks and click Select.
Click Create.

Instance Email Alerts (SNMP Traps)

You can receive email alerts whenever a NetScaler appliance sends a critical SNMP trap.

On the left, go to Networks > Events > Rules.
On the right, click Add.
Give the rule a name.
Move Severity filters (e.g. Major, Critical) to the right by clicking the plus icon next to each Severity.
While scrolling down, you can configure additional alert filters.
On the bottom of the page, click Add Action.
Select an Action Type (e.g. Send e-mail Action).
Select the recipients (or click the plus icon to add recipients).
Optionally, enter a Subject and/or Message.
Emails can be repeated by selecting Repeat Email Notification until the event is cleared.
Click OK.
Then click Create.
See the Event Management section at MAS How-to articles at Citrix Docs.

Director Integration

Integrating NetScaler MAS with Director adds Network tabs to Director’s Trends and Machine Details views. Citrix Blog Post Configure Director with Netscaler Management & Analytics System (MAS)

Requirements:

XenApp/XenDesktop must be licensed for Platinum Edition. This is only required for the Director integration. Without Platinum, you can still access the HDX Insight data by going visiting the NetScaler MAS website.
Director must be 7.11 or newer for NetScaler MAS support.
NetScaler MAS must be 11.1 build 49 or newer.

To link Citrix Director with NetScaler MAS:

On the Director server, run C:\inetpub\wwwroot\Director\tools\DirectorConfig.exe /confignetscaler.
Enter the NetScaler MAS nsroot credentials.
If HTTPS Connection (recommended), the NetScaler MAS certificate must be valid and trusted by both the Director Server and the Director user’s browser.
Enter 1 for NetScaler MAS.
Do this on both Director servers.

Use NetScaler MAS

The AppFlow Analysis tools (e.g. HDX Insight) are located under the Analytics node.

NetScaler MAS also includes all previous Command Center functionality, which you can find on the Networks nodes. For example, at Networks > Instances, select an instance, and view its Dashboard.

Backups are available by right-clicking an instance and clicking View Backup.

Networks > Network Reporting > NetScaler let you view Instance performance data.

Dave Bretty Automating Your Netscaler 11.1 Vserver Config Using Netscaler Management and Analytics System: use a Configuration Job to deploy StoreFront load balancing configuration to an instance.

Applications > Dashboard automatically includes all licensed vServers in the Others section. On the top right, click Define Custom App to group vServers together into an application. The grouped vServers are removed from the Others list.

The Applications Node has quite a bit of functionality. See Application Analytics and Management at Citrix Docs for details.

Links:

Citrix CTX220158 Various Enhancements and Newly Added Features in NetScaler MAS release 11.1 51.21
NetScaler MAS How-to Articles at Citrix Docs.

HDX Insight

HDX Insight Dashboard displays ICA session details including the following:

WAN Latency
DC Latency
RTT (round trip time)
Retransmits
Application Launch Duration
Client Type/Version
Bandwidth
Licenses in use

HDX Insight can also display Geo Maps. Configure NetScaler MAS with Data Center definitions (private IP blocks). More info at Geo Maps for HDX Insight at Citrix Docs.

Gateway Insight

In the Analytics node is Gateway Insight.

This feature displays the following details:

Gateway connection failures due to failed EPA scans, failed authentication, failed SSON, or failed application launches.
Bandwidth and Bytes Consumed for ICA and other applications accessed through Gateway.
# of users
Session Modes (clientless, VPN, ICA)
Client Operating Systems
Client Browsers

More details at Gateway Insight at Citrix Docs.

Security Insight

The Security Insight dashboard uses data from Application Firewall to display Threat Index (criticality of attack), Safety Index (how securely NetScaler is configured), and Actionable Information. More info at Security Insight at Citrix Docs.

Troubleshooting

Citrix CTX215130 HDX Insight Diagnostics and Troubleshooting Guide: Syslog messages; Error counters; Troubleshooting checklist, Logs

Citrix Blog Post NetScaler Insight Center – Tips, Troubleshooting and Upgrade

See Citrix Docs Troubleshooting Tips. Here are sample issues covered in Citrix Docs:

Can’t see records on Insight Center dashboard
ICA RTT metrics are incorrect
Can’t add NetScaler appliance to inventory
Geo maps not displaying

Upgrade NetScaler MAS

Download the latest Upgrade Pack for NetScaler Management and Analytics System.
Login to NetScaler MAS.
Go to System > System Administration.
On the right, in the right pane, click Upgrade NetScaler MAS.
Browse to the Software Image Upgrade Pack .tgz file, and click OK.
Click Yes to reboot the appliance.
After it reboots, login. The new firmware version will be displayed in the top right corner.

↧

NetScaler Essential Concepts: Part 1 – Request-Response, HTTP Basics, and Networking

June 19, 2017, 4:56 pm

≫ Next: NetScaler Essential Concepts: Part 2 – Certificates/SSL, Authentication, HTTP, VPN Networking, PXE, GSLB

≪ Previous: NetScaler Management and Analytics System (MAS) 12

Navigation

Introduction

Many NetScalers are managed by server admins and/or security people that do not have extensive networking experience. This topic will introduce you to important networking concepts to aid you in successful configuration of NetScalers. Most of the following concepts apply to all networks, but this topic will take a NetScaler perspective.

The content is intended to be introductory only. Search Google for more detail on each topic.

Request-Response

Request-Response Overview

Request/Response – fundamentally, a Client sends a Request to a Server. The Server processes the Request, and sends back a successful Response, or sends back an Error. Request-Response describes almost all client-server networking.

Clients send Requests – For NetScaler, Clients are usually web browsers. But it can be any client-side program that requests something from a server.

Servers Respond to Requests – For NetScaler, Servers are usually web servers. These machines receive HTTP requests from clients, perform the HTTP Method (command) contained in the request, and send back the response.

What’s in a Request?

Request are sent to Web Servers using the HTTP protocol – Web Browsers use the HTTP protocol to send Requests to Web Servers. Web Servers use the HTTP protocol to send Responses back to Web Browsers.

Protocol – A protocol defines a vocabulary for how machines communicate with each other. Since web browsers and web servers use the same protocol, they can understand each other.

HTTP is an OSI Layer 7 protocol – HTTP is defined by the OSI Model as a Layer 7, or application layer, protocol. Layer 7 protocols run on top of (encapsulated in) other lower layer protocols, as detailed later.

HTTP Request Commands – HTTP Requests contain commands for the web server. The web server is intended to carry out the requested command. In the HTTP Protocol, Request Commands are also known as Request Methods.

HTTP GET Method – The most common Command in an HTTP Request is GET. This Command asks the web server to send back a file. In other words, web servers are essentially nothing more than file servers.

Additional HTTP Request Commands/Methods beyond GET will be detailed in Part 2.

HTTP Path – attached to the GET Command is the path to the requested file. Web servers can host thousands of files. The client needs some method of requesting a particular file. In HTTP, the format is something like /directory/directory/file.html. On NetScaler, you can access the HTTP path in a policy expression by entering HTTP.REQ.URL.PATH.

More info on URLs will be provided later in Part 2

Addresses Overview

Unique addresses – Every machine (including clients and servers) has at least one address. Addresses are unique across the whole Internet; only one machine can own a particular address. If you have two machines with the same address, which machine receives the Request or Response?

Requests are sent to a Destination Address – when the client sends a request to a web server, it sends it to the server’s address. This is similar to email: you enter the address of the recipient. The server’s address is put in the Destination Address field of the Request Packet.

Requests are placed on a Network, which gets it to the destination – The client puts the Request Packet on the network. The network uses the Destination Address in the packet to get the packet to the web server. This process is detailed later.

Web Servers reply to the Source Address – when the Request Packet is put on the network, the client machine inserts its own address as the Source Address. The web server receives the Request and performs its processing. The web server then needs to send the Response back to the Client. It extracts the Source Address from the Request Packet, and puts that in the Destination Address of the Response Packet. If the original Source Address is wrong or missing, then the response will never make it back to the client.

Sometimes, Requests get to Servers successfully, but Responses fail to come back – If you don’t receive a Response to your Request, then either the Request didn’t make it to the Server, or the Response never made it from the Server back to the Client. The key point is that there are two communication paths: the first is from Client to Server, and the second is from Server to Client. Either one of those paths could fail.

Numeric-based addresses – All network addresses are ultimately numeric, because that’s the language that machines understand. Network packets contain Source and Destination addresses in numeric form. Routers and other networking equipment read the numeric addresses, perform a table lookup to find the next hop to reach the destination, and quickly place the packet on the next interface to reach the destination. This is much quicker if addresses are numbers instead of words.

IP Addresses are one type of address – Different OSI layers have different addresses. Layer 3 IP Addresses are how the network (Internet) gets the packet from the Source to the Destination and back again. Clients and Servers have unique IP Addresses. Layer 3 networking will be detailed later.
IP Address format – Each IP address is four numbers separated by three periods (e.g. 216.58.194.132). Each of the four numbers must be in the range from 0 to 255. Most network training guides cover IP addressing in excruciating detail so I won’t repeat it here.

Human-readable addresses – When a human enters the destination address of a Web Server, humans much prefer to enter words instead of numbers. So there needs to be a method to convert word-based addresses into numeric-based addresses. This method is called DNS (Domain Name System), which will be detailed later.

Web Servers and File Transfer

Web Servers are File Servers – essentially, Web Servers are not much more than file servers. A Web Client requests the Web Server to send it a file.

Web Clients use the HTTP Protocol to download files from a Web Server.

Web Clients are responsible for doing something meaningful with the files downloaded from Web Servers – The files downloaded from a Web Server can be: displayed to the user, processed by a program, or stored.

Web Browsers – Web Browsers are a type of Web Client that usually want to display the files that are downloaded from Web Servers. If the file contains HTML tags, then the Browser will render the HTML tags and display them to the user.
API Web Clients – Web Clients can use an HTTP-based API to download data files from a web server. These data files are typcially processed by a client-side script or program, and aren’t displayed directly to the user.
Downloaders – some Web Clients are simply Downloaders, meaning all they do is use HTTP to download files and store them on the hard drive. Later, the user can do something with those downloaded files.

Web Server and Web Client Scripting

Web Server Script Processing – web servers can do more than just file serving: they can also run server-side scripts that dynamically modify the files before the files are downloaded to the web client.

Web Server Script Languages – different web server programs support different server-side script languages. These server-side script languages include: Java, ASP.NET, Ruby, PHP, Node.js, etc.

Web Server Data – Server-side scripts use data to dynamically modify the HTML pages. The data can be retrieved from a database. And the data can be provided by the Web Client.

Web Browser Scripting – all Web Browsers use Javascript for client-side scripting. Client-side scripts (JavaScript) add animations and other dynamic features to web pages.

Web Browser Plug-ins – Additional client-side scripting languages can be added to web browsers by installing plug-ins, like Flash and Java. But today these plug-ins are becoming more rare because JavaScript can do almost everything that Flash and Java can do.

Other Client-side programs – Non-browser Client-side programs can use any language (including PowerShell) that supports sending HTTP Requests and processing the HTTP Responses.

Server Services and Server Port Numbers

Web Server Software – there are many web server programs like IIS, Apache, NGINX, Ember (Node.js), WebLogic, etc. Some are built into the operating system (e.g. IIS is built into Windows Server), others must be downloaded and installed.

Web Server Software runs as a Service – The Web Server Software installation process creates a Service (or UNIX/Linux Daemon) that launches automatically every time the Server reboots. Services can be stopped and restarted. Server admins should be familiar with Server Services.

Servers can run multiple Services at the same time – A single Server can run many Services at the same time: an Email Server Service, a FTP Server Service, a SSH Server Service, a Web Server Service, etc. There needs to be some way for the Client to tell the Server that the Request is to be sent to the Web Server Service and not to the SSH Service.

Services listen on a Port Number – when the Web Server Service starts, it begins listening for requests on a particular Port Number (typically port 80 for unencrypted HTTP traffic, and port 443 for encrypted SSL/TLS traffic). Other Services listen on different port numbers. It’s not possible for two Services to listen on the same port number.

Clients send packets to a Destination Port Number – When a Client wants to send a HTTP Request to a Web Server Service, it needs to add the Destination Port Number to the packet. If you open a browser and type a DNS name into the browser’s address bar, by default, the browser will send the packet to Port 80, which is usually the port number that Web Server Services are listening on.

Client Programs and Client Ports

Multiple Client Programs – multiple programs can be running at the same time on a single Client; for example: Outlook, Internet Explorer, Chrome, Slack, etc. When the Response is sent from the Server back to the Client, which client-side program should receive the Response?

Client Ephemeral Ports – whenever a client program sends a request to a Server, the operating system assigns a random port number between 1024 and 65535 to the client process. The range of ephemeral port numbers varies for different client operating systems.

Servers send Response to Client Emphemeral Port – The Server sends the Response to the Client’s Ephemeral Port, also known as the Source Port. This is how a client NIC matches the Response with the client program that initiated it.

Source Port in Network Packet – In order for a Server to know the Client’s Ephemeral Port, the Source Port number must be included in the Request packet.

Each Client Request can use a different Ephemeral Port – A client program can send multiple requests to multiple server machines, and each of these outstanding requests usually has a unique Client Ephemeral port.

Summary of the Network Packet Fields discussed so far – In order for Packets to reach the Server Service and return to the Client Program, every network packet must contains the following fields:

Destination Address – the Server’s IP address
Destination Port – port 80 for Web Server Services
Source Address – the Client’s IP address
Source Port – the ephemeral port assigned by the operating system

Sessions

Sessions Overview

Sessions and the OSI network model – A session is a longer-lived connection between two endpoints. Each layer of the OSI network model has a different conception of sessions. (Note: the OSI model is detailed in every network training book/video/class).

Layer 4 – TCP Connection
Layer 6 – SSL/TLS Session
Layer 7 – HTTP Session
Web Server Session – doesn’t map to the OSI Model. Think “shopping carts”

Higher layer sessions require lower layer sessions – Sessions at higher layers require Sessions (or Connections) at lower layers to be established first. For example, HTTP Requests can’t be sent unless a TCP Connection is established first.

A single Server Service can handle Requests from multiple Clients at the same time – When a Client connects to a Service’s Port Number, the Server Service creates a session for the the Client IP and Client Port Number. Each combination of Client IP and Client Port Number is a different session.

Session duration – Sessions at higher layers can live beyond a single lower layer session. For example, a Web Server Session might exist for days, while each HTTP Request might only live for a few seconds.

Session multiplexing – A single lower layer session might be used for multiple higher level sessions. For example, NetScaler appliances multiplex multiple HTTP Requests onto a single TCP Connection.

Network Sessions

Application Data can exceed the maximum size of a Network Packet – Requests and Responses (especially responses) can be too big for a single packet. Thus the Request and/or Response must be broken up into multiple packets. These multiple packets must then be reassembled after they arrive at the destination.

Packets can arrive out of Order – when a Request or Response is broken into multiple packets, the destination needs to reassemble the packets in the correct order. Each packet contains a Sequence Number. The first packet might have Sequence Number 1, while the second packet might have Sequence Number 2, etc. These Sequence Numbers are used to reassemble the packet in the correct order.

Packet Loss – Some packets might not make it to the destination machine. TCP uses the Sequence Numbers to determine if it received all of the packets from the source machine. If one of the sequences is missing, then TCP asks the source to resend the packet. Packet resend is also known as retransmission.

TCP and UDP Overview – there are two Layer 4 Session protocols – TCP, and UDP. TCP handles many of the Network Session services (reassembly, retransmission, etc.) mentioned above. UDP does not do any of these services, and instead requires higher layer protocols to handle them.

TCP Port Numbers and UDP Port Numbers are different – Each Layer 4 protocol has its own set of port numbers. TCP port numbers are different from UDP port numbers. A Server Service listening on TCP 80 does not mean it is listening on UDP 80. When talking about port numbers, you must indicate if the port number is TCP or UDP, especially when asking to firewall teams to open ports. Most of the common ports are TCP, but some (e.g. Voice) are UDP.

TCP Protocol (Layer 4)

TCP Three-way handshake – Before two machines can communicate using TCP, a three-way handshake must be performed:

The TCP Client initiates the TCP connection by sending a TCP SYN packet (connection request) to the Server Service Port Number.
The Server creates a TCP Session in its memory, and sends a SYN+ACK packet (acknowledgement) back to the TCP client.
The TCP Client receives the SYN+ACK packet and then sends an ACK back to the TCP Server, which finishes the establishment of the TCP connection. HTTP Requests and Responses can now be sent across this established TCP connection.

TCP Connections are established between Port Numbers – The TCP Connection is established between the Client’s TCP Port (ephemeral port), and the Server’s TCP Port (e.g. port 80 for web servers).

Multiple Clients to one Server Port – A single Server TCP Port can have many TCP Connections with many clients. Each combination of Client Port/Client IP with the Server Port is considered a separate TCP Connection. You can view these TCP Connections by running netstat on the server.

Netstat shows Layer 4 only – netstat command shows TCP connections (Layer 4) only, not HTTP Requests (Layer 7).

HTTP requires a TCP Connection to be established first – When an HTTP Client wants to send an HTTP Request to a web server, a TCP Connection must be established first. The Client and the Server do the three-way TCP handshake on TCP Port 80. Then the HTTP Request and HTTP Response is sent over this TCP connection. HTTP is a Layer 7 protocol, while TCP is a Layer 4 protocol. Higher layer protocols run on top of lower layer protocols. It is impossible to send a Layer 7 Request (HTTP Request) without first establishing a Layer 4 session/connection.

Use Telnet to verify that a Service is listening on a TCP Port number – when you telnet to a server machine on a particular port number, you are essentially completing the three-way TCP handshake with a particular Server Service. This is an easy method to determine if a Server machine has a Service listening on a particular port number, and that you’re able to communicate with that port number.

UDP Protocol (Layer 4)

UDP is Sessionless – UDP is a much simpler protocol than TCP. For example, there’s no three-way handshake like TCP. Since there’s no handshake, there’s no UDP session.

No Sequence Numbers – UDP packets do not contain sequence numbers. If a packet is lost, UDP does not request a resend like TCP does. If packets arrive out of order, UDP cannot determine this, and cannot reassemble them in the correct order. If these features are desirable, then the application (Layer 7) needs to do these features instead of relying on UDP to do it.

Why UDP over TCP? – TCP session information is contained in every TCP packet, thus making every TCP packet (20 byte header) bigger than a UDP packet (8 byte header). Also, TCP retransmissions are not as fast or efficient as other methods of recovering from packet loss. For example, Citrix has recently reconfigured HDX/ICA so it can use UDP instead of TCP. They did this by essentially creating their own version of TCP sessions. Citrix’s version of network sessions over UDP is more efficient (smaller packets, quicker recovery) than TCP’s version.

Audio uses UDP – For audio traffic, there’s usually no point in resending lost packets. Getting rid of retransmissions makes UDP more efficient (less bandwidth, less latency) than TCP.

You can’t use Telnet to troubleshoot UDP – since there’s no three-way handshake in UDP, it’s impossible to use telnet to determine if a Server Service is listening on a UDP port or not. With UDP, the UDP Client machine sends a Request to the UDP Server. The UDP Server does not send any acknowledgment that it received the UDP Request. Thus all a UDP Client can do is wait for a response from the server. If the server doesn’t respond, it doesn’t necessarily mean that the server isn’t listening on the UDP port.

You can’t use netstat to see UDP sessions – since there’s no UDP session, if you run netstat on a machine, you won’t see any UDP sessions. To really see UDP traffic, use a packet capture program like Wireshark.

Application Sessions – web servers typically have their own application session mechanism. Application sessions usually extend beyond a single TCP session to encompass multiple TCP sessions, Web Server sessions are detailed in Part 2.

HTTP Basics

HTTP Protocol Overview

URLs – users enter a URL into a browser’s address bar. An example URL is https://en.wikipedia.org/wiki/URL

https:// or http:// – the first part of the URL specifies the Layer 7 protocol that the browser will use to connect to the web server.
en.wikipedia.org – the second part of the URL is the human-readable DNS name that translates to the web server’s IP address.
/wiki/URL – the remaining part of the URL is the Path and Query. The Path indicates the path to the file you want to download.

Why forward slashes in URLs? – Web Server programs were originally developed for UNIX and Linux. Thus they share some of the Linux characteristics. For example, file paths in HTTP requests use forward slash (/) instead of backslash (\).

Some URLs are case sensitive – Since UNIX/Linux is case sensitive, file paths in HTTP requests are sometimes case sensitive.

HTTP vs HTML – Web Browsers use the HTTP protocol to download HTML files from a web server. HTTP is the communication protocol to get a file. HTML defines how a web browser displays a web page (HTML file) to a user. There are many books and videos that explain HTML, but not many explain HTTP.

HTTP Packet

HTTP Request Command (Method) – at the top of every HTTP Request packet is the HTTP command. This command might be something like this: GET /Citrix/StoreWeb/login.aspx HTTP/1.1

HTTP Response Code – at the top of every HTTP Response is a code like this: HTTP/1.1 200 OK. Different codes mean success or error. Code 200 means success. You’ll need to memorize many of these codes.

Header and body – HTTP Packets are split into two sections: header, and body.

HTTP Headers – Below the Request Command (Method), are a series of Headers. Web Browsers insert Headers into requests. Web Servers insert Headers into responses. Request Headers and Response Headers are totally different. You’ll need to memorize most of these Headers.
HTTP Body – Below the Headers is the Body. Not every HTTP Packet has a Body. In a HTTP Response, the HTTP Body contains the actual downloaded file (e.g. HTML file). In an HTTP Request, the HTTP Body contains data (parameters) that is uploaded with the Request.

Raw HTTP packets – To view a raw HTTP packet, use your browser’s developer tools (F12 key), or use a proxy program like Fiddler. In a Browser’s Developer Tools, switch to the Network tab to see the HTTP Requests and HTTP Responses.

Multiple HTTP requests – A single webpage requires multiple HTTP requests. When an HTML file is processed by a Web Browser, the HTML file contains links to supporting files (CSS, JavaScript, images) that must be downloaded from the web server. Each of these file downloads is a separate HTTP Request.

HTTP and TCP Connections – Every HTTP Request requires a TCP Connection to be established first. Older Web Servers tear down the TCP Connection after every single HTTP Request. This means that if a web page needs 20 downloads, then 20 TCP Connections, including 20 three-way handshakes, are required. Newer Web Servers keep the TCP Connection established for a period of time, allowing each of the 20 HTTP Requests to be sent across the existing TCP Connection.

HTTP Redirects – one HTTP Response Code that you must understand is the HTTP Redirect. These HTTP Response packets have response code 301 or 302. The HTTP Response Header named Location identifies the new URL that the browser is expected to navigate to.

Redirect Traffic flow:

1. User’s Web Browser sends an HTTP Request to a Web Server
2. Web Server sends back an HTTP Response with a 301/302 response code and Location header.
3. User’s Web Browser navigates to the URL contained in the Location header. Note that the Web Server tells the Web Browser where to go. But it’s the browser that actually goes there.

Redirect usage – Redirects are used extensively by web applications. Most web-based applications would not function without redirects. A common usage of Redirects is in authenticated websites where an unauthenticated user is redirected to a login page, and after login, the user is redirected back to the original webpage.
Not all Web Clients support HTTP Redirects – Web Browsers certainly can perform a redirect. However, other Web Clients (e.g. Citrix Receiver) do not follow Redirects.

Additional HTTP concepts will be detailed in Part 2.

Networking

Layer 2 (Ethernet) and Layer 3 (Routing) Networking

Subnet – all machines connected to a single “wire” are considered to be on the same subnet. Machines on the subnet can communicate directly with other machines on the same subnet.

Routers – If two machines are on different subnets, then those two machines can only communicate with each other by using an intermediary device that is connected to both subnets. This intermediary device is called a router. The router is connected to both subnets (wires) and can take packets from one subnet and put them on the other subnet.

Layer 2 – When machines on the same subnet want to communicate with each other, they use a Layer 2 protocol, like Ethernet.

Layer 3 – When machines on different subnets want to communicate with each other, they use a Layer 3 protocol, like IP (Internet Protocol).

Local IP address vs remote IP address

Local vs Remote – since different protocols are used for intra-subnet (Layer 2) and inter-subnet (Layer 3), the machines need to know which other machines on are on the local subnet, and which machines are on a remote subnet.

Subnet Mask – all machines have an IP address. All machines are configured with a subnet mask. The subnet mask defines which bits of the IP address are on the same subnet. For example, if a machine with address 10.1.0.1 wants to talk to a machine with address 10.1.0.2, and if the subnet mask is 255.255.0.0, when both addresses are compared to the subnet mask, the results are the same, and thus both machines are on the same subnet, and Ethernet is used. If the results are different, then the other machine is on a different subnet, and IP Routing is used. There is a considerable amount of training material on subnet masks so I won’t repeat that material here.

Wrong Subnet Mask – If either machine is configured with the wrong subnet mask, then one of the machines might think the other machine is on a different subnet, when actually it’s on the same subnet. Or one of the machines might think the other machine in on the same subnet, when actually it’s on a different subnet. Remember, same subnet communication uses a different communication protocol than between subnets. Thus it’s important that the subnet mask is configured correctly.

Layer 2 Ethernet communication

Every machine sees every packet – A characteristic of Layer 2 (Ethernet) is that every machine sees traffic from every other machine on the same subnet.

MAC addresses – When two machines on the same subnet talk to each other, they use a Layer 2 address. In Ethernet, this is called the MAC address. Every Ethernet NIC (network card) in every machine has a unique MAC address.

NICs Listen for their MAC address – The Ethernet packet put on the wire contains the MAC address of the destination machine. All machines on the same subnet see the packet. If the listening NIC has a MAC address that matches the packet, then the listening NIC processes the rest of the packet. If the listening NIC doesn’t have a matching MAC address, then the packet is ignored. You can override this ignoring of packets by turning on promiscuous mode, which is useful for packet capture programs (e.g. Wireshark).

Source MAC address – When a Ethernet packet reaches a machine, the machine needs to know where to send the reply. Thus both the destination MAC address, and the source MAC address, are included in the Ethernet packet.

Ethernet Packet Fields – In summary, a typical Ethernet packet contains the following fields:

Destination MAC address
Source MAC address
Destination IP address
Source IP address
Destination TCP/UDP port number
Source TCP/UDP port number

Other Layer 2 technologies – another common Layer 2 technology seen in datacenters is Fibre Channel for storage area networking (SAN). Fibre Channel has its own Layer 2 addresses called the World Wide Name (WWN). Fibre Channel does not use IP in Layer 3, and instead has its own Layer 3 protocol, and its own Layer 3 addresses (FCID).

ARP (Address Resolution Protocol)

Users enter IP Address, not MAC Address – when a user wants to talk to another machine, the user enters a DNS name, which is translated to an IP address. If the destination IP address is on a remote subnet, then the Layer 3 protocol IP Routing will get the packet to the destination. But if the destination IP address is on the same subnet as the source machine, then the destination IP address first needs to be converted to a MAC address. Machines use Address Resolution Protocol (ARP) to find the MAC address that’s associated with an IP address that’s on the same subnet.

Remember, machines use the Subnet Mask to determine if the destination is local or remote.

ARP Process – The source machine sends out an Ethernet broadcast with the ARP message “who has IP address 10.1.0.2”. Every machine on the same subnet sees the message. If one of the machines is configured with IP address 10.1.0.2, then that machine replies to the source machine, and includes its MAC address in the response. The source machine can now send a packet directly to the destination machine’s Ethernet MAC address.

ARP Cache – after the ARP protocol resolves an IP address to a MAC address, the MAC address is cached on the machine for a period of time (e.g. 30 seconds). If another IP packet needs to be sent to the same destination IP address, then there’s no need to perform ARP again, since the source machine already knows the destination machine’s MAC address. When the cache entry expires, then ARP needs to be performed again.

IP Conflict – Remember, a particular IP address can only be assigned to one machine. If two machines have the same IP address, then both machines will respond to the ARP request. Sometimes the ARP response will be one machine’s MAC address, and sometimes it will be the other machine’s MAC address. This behavior is typically logged as a “MAC move” or an “IP conflict”. Since only half the packets are reaching each machine, both machines will stop working.

Layer 3 on top of Layer 2

Routing to other subnets – When a machine wants to talk to a machine on a different subnet, the source machine needs to send the packet to a router. The router will then forward the packet to the destination machine on the other subnet.

Default gateway – Every client machine is configured with a default gateway, which is the IP address of a router on the same subnet as the client machine. The client machine assumes that the default gateway (router) can reach every other subnet.

On a NetScaler or UNIX/Linux device, the default route (default gateway) is shown as route 0.0.0.0/0.0.0.0.

Router’s MAC address – Since the router and the source machine are on the same Ethernet subnet, they use Ethernet MAC addresses to communicate. The source machine first ARP’s the router’s IP address to find the router’s MAC address. The source machine then puts the packet on the wire with the destination IP address and the router’s MAC address.

The Destination IP Address is the final destination’s (the web server’s) IP address, and not Router’s IP address. However, the MAC Address is the Router’s MAC address, and not the final destination’s MAC Address.
ARP across subnet boundaries – It’s not possible for a source machine to find the MAC address of a machine on a remote subnet. If you ping an IP address on a remote subnet, and if you look in the ARP cache, you might see the router’s MAC address instead of the destination machine’s MAC address. That’s because routers do not forward Ethernet broadcasts to other subnets.
Router must be on same subnet as client machine – since client machines use Ethernet, ARP, and MAC addresses to talk to routers, the router (default gateway) and the client machine must be on the same subnet. More specifically, the router must have an IP address on the same IP subnet as the client machine. When the client machine’s IP address and the router’s IP address are compared to the subnet mask, the results must match. You cannot configure a default gateway that is on a different subnet than the client machine.

Routing table lookup – When the router receives the packet on its NIC’s MAC address, it sees that the destination IP address is not one of the router’s IP addresses, so it looks in its memory (routing table) to determine what network interface it needs to put the packet on. The router has a list of which IP subnet is on which router interface. IP Subnets are defined by the address prefix and the subnet mask.

Router ARP’s the destination machine on other subnet – If the destination IP address is on one of the subnets/interfaces that the router is connected to, then the router will perform an ARP on that subnet/interface to get the destination machine’s MAC address.

Router puts the original packet on the destination interface, but with some changes:

The destination MAC address is changed to the destination machine’s MAC address instead of the router’s MAC address.
The source MAC address in the packet is now the router’s MAC address, thus making it easier for the destination machine to reply.
The IP Addresses in the packet do not change. Only the MAC addresses change.

There can only be one default route on a machine, which impacts multi-NIC machines – Some machines (e.g. NetScaler appliances) might be configured with multiple IP addresses on multiple subnets. Only one router can be specified as the default gateway (default route). This default gateway must be on one of the subnets that the client machine is connected to. See the NetScaler networking sections below for details on how to handle the limitation of only a single default route.

Multiple Routers and Routing Protocols

Router-to-router communication– When a router receives a packet that is destined to a remote IP subnet, the router might not be Layer 2 (Ethernet) connected to the remote IP subnet. In that case, the router needs to send the packet to another router. It does this by changing the destination MAC address of the packet to a different router’s MAC address. Both routers need to be connected to the same Ethernet subnet.

Routing Protocols – Routers communicate with each other to build a topology of the shortest path or quickest path to reach a destination. Most of the CCNA/CCNP/CCIE training material details how the routers perform this path selection.

Ethernet Switches

Ethernet Subnet = Single wire – All machines on the same Ethernet subnet share a single “wire”. Or at least that’s how it used to work.

Switch backplane – Today, each machine connects a cable to a port on a switch. The switch merges the switch ports into a shared backplane. The machines communicate with each other across the backplane instead of a single “wire”.

MAC address learning – The switch learns which MAC addresses are on which switch ports.

Switches switch known MAC addresses to only known switch ports – If the switch knows which switch port connects to the destination MAC address of an Ethernet packet, then the switch only puts the Ethernet packet on the one switch port. This means that Ethernet packets are no longer seen by every machine on the wire. This improves security by preventing network capture tools from seeing every packet on the Ethernet subnet.

Switches flood unknown MAC addresses to all switch ports – If the switch doesn’t know which switch port connects to a destination MAC address, then the switch floods the packet to every switch port on the subnet. If one of the switch ports replies, then the switch learns the MAC address on that switch port.

Switches flood broadcast packets – The switch also floods broadcast packets to every switch port in the Ethernet subnet.

Switches and VLANs

VLANs – A single Ethernet Switch can have different switch ports in different Ethernet Subnets. Each Ethernet Subnet is called a VLAN (Virtual Local Area Network). All switch ports in the same Ethernet Subnet are in the same VLAN.

VLAN ID – Each VLAN has an ID, which is a number between 1 and 4095. Thus a Switch can have Switch Ports in up to 4095 different Ethernet Subnets.

Switch Port VLAN configuration – a Switch administrator assigns each switch port to a VLAN ID. By default, Switch Ports are in VLAN 1 and shutdown. The Switch administrator must specify the VLAN ID and enable (unshut) the Switch Port.

Pure Layer 2 Switches don’t route – When a Switch receives a packet for a port in VLAN 10, it only switches the packet to other Switch Ports that are also in VLAN 10. Pure Layer 2 Switches do not route (forward) packets between VLANs.

Some Switches can route – Some Switches have routing functionality (Layer 3). The Layer 3 Switch has IP addresses on multiple Ethernet subnets (one IP address with MAC address for each subnet). The client machine has the Default Gateway set to the Switch’s IP address. When Ethernet packets are sent to the Switch’s MAC address, the Layer 3 Switch forwards (routes) the packets to a different IP subnet.

DHCP (Dynamic Host Configuration Protocol)

Static IP Addresses or DHCP (Dynamic) IP Addresses – Before a machine can communicate on a network, the machine needs an IP address. The IP address can be assigned statically by the administrator, or the machine can get an IP address from a DHCP Server. Most client machines use DHCP by default. DHCP is usually required for virtual desktops and non-persistent XenApp servers.

DHCP Process – When a DHCP-enabled machine boots, it sends a DHCP Request broadcast packet asking for an IP address. A DHCP server sees the DHCP IP address request, and sends back a DHCP reply with an IP address in it. DHCP servers keep track of which IP addresses are available and try to avoid IP conflicts.

DHCP Request doesn’t cross routers – The DHCP Request broadcast is Layer 2 (Ethernet) only, and won’t cross Layer 3 boundaries (routers).

DHCP Server on same subnet – If the DHCP server is on the same subnet as the DHCP client, then no problem. But this is rarely the case.

DHCP Server on remote subnet – If the DHCP server is on a different subnet, then the local router needs to forward the DHCP request to the remote DHCP server. The local router must be configured to listen for DHCP requests. To enable DHCP forwarding on a subnet, ask the networking team to configure the subnet’s router (default gateway) with IP Helper Address or DHCP Proxy/Fowarder.

DHCP Server provides the Default Gateway – When a DHCP server sends an IP address to the client, the DHCP server also sends the Default Gateway IP address. This allows the client machine to communicate both Layer 2 and Layer 3.

DHCP Scopes – A single DHCP server can hand out IP addresses to multiple subnets. Each subnet is a different DHCP Scope. The scope configuration and list of issued IP addresses are stored in a database.

DHCP Server Redundancy – If the DHCP Server is down, then DHCP Clients cannot get an IP address when they boot, and thus can’t communicate on the network. You typically need at least two DHCP Servers. However, the DHCP database is usually stored locally on each DHCP Server, so you need some mechanism to replicate the database to each DHCP Server. Windows Server 2012 and newer have a DHCP Database replication capability. As do other DHCP servers like Infoblox.

DNS (Domain Name Server)

DNS converts words to numbers – When users use a browser to visit a website, the user enters a human-readable, word-based address. However, machines can’t communicate using words, so these words must first be converted to a numeric address. That’s the role of DNS.

DNS Client – Every client machine has a DNS Client. The DNS Client talks to DNS Servers to convert word-based addresses (DNS names) into number-based addresses (IP addresses).

DNS Query – The DNS Client sends a DNS Query, which is a word-based address, to a DNS Server. The DNS Server sends back an IP Address.

DNS Servers configured on client machine – On every client machine, you specify which DNS Servers the DNS Client should use to resolve DNS names into IP addresses. You enter the IP addresses of two or more DNS Servers.

DHCP can deliver DNS Server addresses – These DNS Server IP addresses can also be delivered by the DHCP Server when the DHCP Client requests an IP address.

DNS scalability – The Internet has billions of IP addresses. Each of these IP addresses has a unique DNS name associated with it. It would be impossible for a single DNS server to have a single database with every DNS name contained within it. To handle this scalability problem, DNS names are split into a hierarchy, with different DNS servers handling different portions of the hierarchy. The DNS hierarchy is a tree structure, with the root on top, and leaves (DNS records) on the bottom.

DNS names and DNS hierarchy – A typical DNS name has multiple words separated by periods. For example, www.google.com. Each word is handled by a different portion of the DNS hierarchy.

Root of the DNS tree – The root portion of the DNS tree is handled by many DNS servers hosted worldwide. The root DNS servers are usually owned and operated by government agencies, or large service providers.

DNS Root Hints – The list of IP Addresses for the root DNS servers is hard coded into every DNS server. This list of root DNS servers is sometimes called Root Hints.

Walk the DNS tree – it’s critical that you understand this process:

Implicit period (root) – DNS names are read from right to left. At the end of www.google.com is an implicit period. So the last character of every DNS name is a period, which represents the top (root) of the DNS tree.
Next is .com. The root DNS Servers have a link to the .com DNS Servers. When a .com DNS name needs to be resolved, you first ask the root servers for the IP addresses of the DNS Servers that know about .com addresses. These .com DNS Servers are usually owned and maintained by the Internet Domain Registrars.
Next is google.com. The .com servers have a link to the google.com DNS Servers. When a google.com DNS name needs to be resolved, you ask a .com DNS server for the IP addresses of the DNS servers that know about google.com addresses.
Finally, you ask the google.com DNS Servers to resolve www.google.com into an IP address. The google.com DNS Servers can resolve www.google.com directly without linking to any other DNS Server.

Local DNS Servers – DNS Clients do not resolve DNS names themselves. Instead, they send the DNS Query to one of its configured DNS Servers, and the DNS Server resolves the DNS Name into an IP address. The DNS Server IP addresses configured on the DNS Client are sometimes called Local DNS Servers and/or Resolvers.

Recursive queries – A DNS Server can be configured to perform recursive queries. When a DNS Client sends a DNS Query to a DNS Server, if the DNS Server can’t resolve the address using it’s local database, then the recursive DNS Server will walk the DNS tree to get the answer. If Recursion was not enabled, then the DNS server would simply send back an error (or a link) to the DNS client.

DNS Caching – Resolved DNS queries are cached for a configurable period of time. This DNS cache exists on both the Resolver/Recursive DNS Server, and on the DNS Client. The caching time is defined by the TTL (Time-to-live) field of the DNS record. When a DNS Client needs to resolve the same DNS name again, it simply looks in its cache for the IP address, and thus doesn’t need to ask the DNS Resolver Server again. If two DNS Clients are configured to use the same Local DNS Servers/Resolvers, when a second DNS Client needs to resolve the same DNS name that the first DNS Client already resolved, the DNS Resolver Server simply looks in its cache and sends back the response, and there’s no reason to walk the DNS tree again, at least not until the TTL expires.

DNS is not in the data path – Once a DNS name has been resolved into an IP Address, DNS is done. The traffic is now between the user’s client software (e.g. web browser), and the IP address. DNS is not in the data path. It’s critical that you understand this, because this is the source of much confusion when configuring NetScaler GSLB.

FQDN – When a DNS name is shown as multiple words separated by periods, this is called a Fully Qualified Domain Name (FQDN).

DNS Suffixes – But you can also sometimes just enter the left word of a DNS name and leave off the rest. In this case, the DNS Client will append a DNS Suffix to the single word, thus creating a FQDN, and send the FQDN to the DNS Resolver to get an IP address. A DNS Client can be configured with multiple DNS Suffixes, and the DNS Client will try each of the suffixes in order until it finds one that works. When you ping the single word address, ping will show you the FQDN that it used to get an IP address.

Authoritative DNS Servers – A small portion of the DNS hierarchy/tree is stored on one or more DNS servers. These DNS servers are considered “authoritative” for this portion of the DNS tree. When you send a DNS Query to a DNS Server that has the actual DNS records in its configuration, the DNS Server will send back the IP Address, and flag the response as “authoritative”. But when you send a DNS query to a DNS Resolver that doesn’t have google.com‘s DNS records in its local database, the DNS Resolver will get the answer from google.com‘s DNS servers, and flags the IP Address response as “non-authoritative”. The only way to get an “authoritative” response for www.google.com is to ask the google.com‘s DNS servers directly.

DNS Zones – The portion of the DNS tree hosted on an authoritative DNS server is called the DNS Zone. A single DNS server can host multiple DNS Zones. DNS Zones typically contain only a single domain name (e.g. google.com). If DNS records for both company.com and corp.com are hosted on the same DNS server, then these are two separate zones.
Zone Files – DNS records need to be stored somewhere. On UNIX/Linux DNS servers, DNS records are stored in text files, which are called Zone Files. Microsoft DNS servers might store DNS records inside of Active Directory instead of in files.

DNS records – Different types of DNS records can be created on authoritative DNS servers:

A (host) – this is the most common type of record. It’s simply a mapping of one FQDN to one IP address. If you create multiple Host records (A records) with the same FQDN, but different IP addresses, then you are essentially configuring DNS Round Robin load balancing.
CNAME (alias) – this record maps (aliases) one FQDN into another FQDN. CNAMEs allows you to put the IP address into one A record, and have other CNAME records that map to the one A record. Then whenever you update the IP address in the A record, all of the CNAMEs start resolving to the new IP address. Otherwise, if you had multiple A records for each FQDN pointing to the same IP address, you’d have to update the IP address in each of the A records.
NS (name server, for delegation) – DNS Resolvers use NS records to enumerate every DNS server that is authoritative for a DNS Zone. This record is important for GSLB configurations.

Resolving a CNAME – While the DNS Resolver is walking the tree, a CNAME might be returned instead of an IP address. However, the DNS Resolver’s job is to return an IP address, not a CNAME, so the Resolver has to start over again with walking the DNS tree to resolve the CNAME into an IP address. If the DNS Resolver gets another CNAME, then it starts over again until it finally gets an IP Address.

CNAME is not a redirect – The FQDN in the user’s address bar doesn’t change. The ultimate response from the DNS Resolver is still just an IP address.
CNAMEs and NetScaler GSLB – CNAMEs are typically used in NetScaler GSLB configurations. CNAMEs are one method of delegating resolution of a FQDN to a NetScaler.

NS records and DNS delegation – NS records can also be used to delegate sub-trees to other DNS servers. For example, google.com can delegate gslb.google.com to other DNS servers. In that case, in google.com, you create NS records named gslb.google.com that point to the IP addresses of two or more other DNS servers (or NetScaler appliances running GSLB).

Physical Networking

Layer 1 (Physical cables)

NetScalers connect to network switches using several types of media (cables).

Gigabit cables are usually copper CAT6 twisted pair with 8-wire RJ-45 connectors on both sides

10 Gigabit or higher cables are usually fiber optic cables with SC connectors on both sides.

Transceivers (SFP, SFP+)

Transceivers convert optical to electrical and vice versa – To connect a fiber optic cable between two network ports, you must first insert a transceiver into the switch ports. The transceiver converts the electrical signals from the switch or NetScaler into optical (laser) signals. The transceiver then converts the laser signals to electrical signals on the other side.
Transceivers are pluggable – just insert them. Because they are pluggable, you can insert different types of transceivers into different switch/NIC ports. Some switch ports might be fiber, while others might be copper.
Different types of transceiver – SFP transceivers only work up to gigabit speeds. For 10 Gig, you need SFP+ transceivers.

For cheaper 10 Gig connections, Cisco offers Direct Attach Copper (DAC) cables:

Transceivers are built into both sides of the cable so you don’t have to buy them separately.
The cables are based on Copper Twinax. Copper means cheaper metal, and cheaper transceivers, than optical fiber.
The cables are short distance (e.g. 5 meters). For longer than 10 meters, you must use optical fiber instead.

Port Channel (cable bonds)

Bonding – Two or more cables can be bound together to look like one cable. This increases bandwidth, and increases reliability. If you bond 4 Gigabit cables together, you get 4 Gigabit of bandwidth instead of just 1 Gigabit of bandwidth. If one of those cables stops working for any reason, then traffic can use the other 3 cables.

Network impact of Cable Bonding – Cable bonding does not affect networking in any way. Ethernet and IP routing don’t care if there’s one cable, or if there are multiple cables bonded into a single link. However, if you connect multiple cables to the same VLAN without bonding, then that definitely impacts both Ethernet and IP routing. Don’t connect multiple cables to one VLAN unless you bond those cables.

Various Names for Cable Bonding – On Cisco switches, cable bonding functionality has several names. Probably the most common name is “port channel”. Other names include: “link aggregation”, “port aggregation”, “switch-assisted teaming”, and “Etherchannel”.

Bonding Configuration – to bond cables together, you must configure both sides of the connection identically. You configure the switch to bond cables. And you configure the NetScaler (or server) to bond cables. On NetScaler, the feature is called Channel. On NetScaler, a Channel is represented by a new interface called LA/1 or something like that. LA = Link Aggregate. If you want to bond cables on a NetScaler, then ask the switch administrator to configure the switch side first.

ARP to a single MAC on multiple NICs – Each cable is plugged into a NIC. Each NIC has its own MAC Address. An IP Address can only be ARP’d to a single MAC address, which means the incoming traffic only goes to one of the cables. To get around this problem, when a port channel (bond) is configured, a single MAC address is shared by all of the cables in the bond, and both sides of the cable bond know that the single MAC address is reachable on all members of the cable bond.

Load Balancing across the bond members – The Ethernet switch and the Netscaler will essentially load balance traffic across all members of the bond. There are several port channel load balancing algorithms. But the most common algorithm is based on source IP and destination IP. All packets that match the same source and destination will go down the same cable. Packets with other combinations of source and destination might go down a different cable. If you are bonding Gigabit cables, since a single source/destination connection only goes down one cable, it can only use up to 1 Gigabit of throughput. Bonds only provide increased bandwidth if there are many source/destination combinations.

LACP – Cables can be bonded together manually, or automatically. LACP is a protocol that allows the two sides (switch and NetScaler) of the bonded connection to negotiate which cables are in the bond, and which cables aren’t. LACP is not the actual bonding feature; instead, LACP is merely a negotiation protocol to make bonding configuration easier.

Multi-switch Port Channels – Port Channels (bonds) are usually only supported between one switch and one NetScaler. To bond ports from one NetScaler to multiple switches, you configure something called Multi-chassis Port Channel. Multi-chassis refers to the multiple switches. You almost always want multi-chassis since that lets you survive a switch failure.

Virtual Port Channel – On Cisco NX-OS switches, the multi-chassis port channel feature is called “virtual port channel”, or vPC for short. vPC requires LACP to be configured on both sides. When connecting a single Port Channel to multiple Nexus switches, ask the network team to create a “virtual port channel”.
Stacked Switches – Other switches support a “stacked” configuration where multiple switches look like one switch. There are usually cables in the back of the switches that connects them together. This multi-Chassis port channel doesn’t usually need LACP, but there’s no harm in enabling LACP.

Configure Manual Channel On NetScaler – to create a “manual” channel, you go to System > Network > Channels, create a channel, select the channel interface name (e.g. LA/2), and add the interfaces.

Configure LACP Channel on NetScaler – To create a LACP channel, go to System > Network > Interfaces, double-click a member interface, scroll down, check the box to enable LACP, and enter a “key” (e.g. 1). All members of the same channel must have the same key. If you enter “1” as the key, then a new interface named LA/1 is created, where the “1” = the LACP key.

Channel Number on NetScaler can be different than the Channel Number on the Switch – The LACP “key” configured on the NetScaler does not need to match the port channel number on the switch side. NetScalers typically have Channels named LA/1, LA/2, etc., while Switches can have port channel interfaces named po281, po282, etc.

VLAN tagging

VLAN review – Earlier, I mentioned that switches can support multiple Ethernet subnets, and each of these Ethernet subnets is a different VLAN. Each switch port is configured to belong to a particular VLAN. Ports in the same VLAN use Ethernet to communicate with each other. Ports in separate VLANs use routers to communicate with each other.

Multiple VLANs on one port – Switches can also be configured to allow a single switch port to be connected to multiple VLANs. A NetScaler usually needs to be connected to multiple subnets (VLANs), as detailed later. You can either assign each VLAN to a separate cable, or you can combine multiple VLANs/subnets onto a single cable.

VLAN tagging – If a switch port supports multiple VLANs, when a packet is received by the switch port, the switch needs some sort of identifier to know which VLAN the packet is on. A VLAN tag is added to the Ethernet packet, where the VLAN tag matches the VLAN ID configured on the switch.

Tags are added and removed on both sides of the switch cable – The NetScaler adds the VLAN tag to packets sent to the switch. The switch removes the tag and switches the packet to other switch ports in the same VLAN. When packets are switched to the NetScaler, the switch adds the VLAN tag so NetScaler knows which VLAN the packet came from.

Trunk Port vs Access Port – When multiple VLANs are configured on a single switch port, this is called a Trunk Port. When a single switch port only allows one VLAN (without tagging), this is called an Access Port. Switch ports default as Access Ports, unless a switch administrator specifically configures it as a Trunk Port. Access Ports don’t need VLAN tagging, but Trunk Ports do need VLAN tagging. When you want multiple VLANs on a single switch port, ask the networking team to configure a trunk port.

Trunk Ports and VLAN ID tagging – when a switch port is configured as a Trunk Port, by default, every VLAN assigned to that Trunk Port requires VLAN ID tagging. The NetScaler must be configured to add and remove the same VLAN ID tags that the switch is expecting.
Trunk Ports and Native VLAN – One of the VLANs assigned to the Trunk Port can be untagged. This untagged VLAN is called the native VLAN. Only one VLAN can be untagged. Native VLAN is an optional configuration. Some switch administrators, for security reasons, will not configure an untagged VLAN (native VLAN) on a Trunk Port. If untagged VLANs are not allowed on the switch, then you must configure the NetScaler to tag every packet, as detailed later. If there’s a native VLAN, then some NetScaler configuration (e.g. NSIP) is simplified, as detailed later.

Trunk Ports reduce the number of cables – if you had to connect a different cable (or Port Channel) from NetScaler for each VLAN, then the number of cables (and switch ports) can quickly get out of hand. The purpose of Trunk Ports is to reduce the number of cables.

Trunk Ports and Port Channels are separate features – If you want to bond multiple cables together, then you configure a Port Channel. If you want multiple VLANs on a single cable or Port Channel, then you configure a Trunk Port. These are two completely separate features.

Trunk Ports and Routing are separate features – Configuring a Trunk port with multiple VLANs does not automatically enable routing between those VLANs. Each VLAN on the Trunk Port is a separate Layer 2 Ethernet broadcast domain, and they can’t communicate with each other without routing. Routing is configured in a separate part of the Layer 3 switch, or on a separate router device. In other words, Trunk Ports are unrelated to routing.

Multiple NICs in one machine

A single machine (e.g. NetScaler) can have multiple NICs, which means multiple cables.

Single VLAN/subnet does not need VLAN configuration on the NetScaler – if the NetScaler is only connected to one subnet/VLAN, then no special configuration is needed. Just create the NSIP, SNIP, and VIPs in the same IP subnet. You can optionally bond multiple cables into a Port Channel for redundancy and increased bandwidth.

Two or more NICs to one VLAN requires bonding – If two or more NICs are connected to the same VLAN, then the NICs must be bonded together into a Port Channel. Port Channels require identical configuration on the switch side and on the NetScaler side. If you don’t bond them together, then you run the risk of bridging loops and/or MAC moves.

Multiple VLANs/subnets requires VLAN configuration on the NetScaler – if a NetScaler is connected to multiple IP subnets, then the NetScaler must be configured to identify which subnet is on which NIC. On the NetScaler, for each IP subnet, you create a Subnet IP address (SNIP). Then you create a VLAN object, bind it to an interface (or Port Channel), and bind a subnet IP address (SNIP) to the VLAN object, so NetScaler knows which IP addresses are on which VLAN and interface.

- VLAN objects are required on a multi-homed NetScaler, even if VLAN tagging is not needed – If a NetScaler is connected to two subnets, it doesn’t matter if VLAN tagging is required or not; the VLAN objects still must be defined on the NetScaler, so the NetScaler can link IP subnets with interfaces.
- VLAN Tagging – You specify the VLAN ID when creating the VLAN object. If the switch port is a Trunk Port, then there’s a checkbox in the VLAN object to enable tagging. If the switch Trunk Port is configured with a native VLAN, then one of the VLANs bound to the Interface/Channel can be untagged.
- If VLAN tagging is not needed, then the VLAN ID configured on the NetScaler doesn’t have to match the switch’s VLAN ID – If the VLAN is not tagged, then the entered VLAN ID on NetScaler is only locally significant, and doesn’t have to match the switch’s VLAN ID. However, it’s easier to troubleshoot if the VLAN ID’s match.

Routing table – When you create a SNIP/VLAN on a NetScaler, a “direct” connection is added to the routing table. You can view the routing table at System > Network > Routes. “Direct” means the NetScaler has a Layer 2 connection to the IP Subnet.

One Default Route – the routing table usually has a route 0.0.0.0 that points to the Default Gateway/Router. There can only be one default route on a device. The NetScaler can send Layer 2 packets out any directly connected interface/VLAN, but Layer 3 packets only go out the one default route, which is on only one VLAN.

Static Routes to override Default Route – To use routers on a different subnet than the default route, you add static routes to the routing table. To add a static route, you specify the destination subnet you are trying to reach, and the router (Next Hop or Gateway) you want to use to reach that destination. The Next Hop address must be on one of the VLANs that the NetScaler is connected to.

How Source IP is chosen – when the multi-VLAN NetScaler wants to send a packet to a remote subnet (not directly connected) through a router, the NetScaler first looks in its routing table for the next hop address. The NetScaler must have a SNIP address on the same subnet as the next hop address. This subnet-specific IP address is used as the Source IP for the Layer 3 packet. The destination machine sends the reply to this subnet-specific Source IP.

NetScaler Networking

Traffic flow through NetScaler

VIPs (Virtual IP) – VIPs receive traffic. When you create a Virtual Server (e.g. Load Balancing Virtual Server), you specify a Virtual IP address (VIP). This VIP listens for traffic from clients. You also specify a port number to listen on.

SNIPs (Subnet IP) – SNIPs are the Source IP when NetScaler sends traffic to a web server. When NetScalers need to send a packet, they look in the routing table for the next hop address, and select a SNIP on the same subnet as the next hop. This SNIP is inserted into the packet as the Source IP. The web servers reply to the SNIP.

Load Balancing traffic – simplified

VIP/Virtual Server – Clients send traffic to a VIP.
Services – Bound to the Load Balancing Virtual Server are one or more Load Balancing Services (or Service Group). These Load Balancing Services define the web server IP address and the web server port number. NetScaler chooses one of the Load Balancing services, and forwards the HTTP request to it.
Monitors – NetScaler should not send traffic to a web server unless that web server is healthy. Monitors periodically send health check probes to web servers.

NetScaler Source IP

SNIP replaces Client IP – When NetScaler communicates with a back-end web server, the source IP is a SNIP. The web server does not see the original Client IP address. Essentially, the source IP address in the original HTTP packet was changed from the Client IP to the SNIP. On other load balancers, this is sometimes called Source NAT.

If SNIP is the source IP, how to log the original Client IP? – Since web servers behind a NetScaler only see the SNIP, the HTTP entries in the web server access logs (e.g. IIS log) all come from the same SNIP. If the web server needs to see the real Client IP, then NetScaler has two options: insert the Client IP into a HTTP Request Header, or configure NetScaler to not use a SNIP.

Client IP Header Insertion – when you create a Load Balancing Service, there’s a checkbox to insert the real client IP into a user-defined HTTP Header. This Header is typically named X-Forwarded-For, or Real IP, or Client IP, or something like that. The web server then needs to be configured to extract the custom HTTP header and log it. The packets on the wire still have a SNIP as the Source IP.

USIP – The default mode for NetScaler is Use Subnet IP (USNIP). This can be changed to Use Source IP (USIP), which leaves the original Source IP (Client IP) in the packets. When web servers respond, they send the reply to the Client IP, and not the SNIP. If the Response does not go through the NetScaler, then NetScaler is only seeing half of the conversation, which breaks many NetScaler features. If you need USIP mode, then reconfigure the default gateway on the web servers to point to a NetScaler SNIP. When the web server replies to the Client IP, it will send the reply packet to its default gateway, which is a NetScaler SNIP, thus allowing NetScaler to see the entire conversation. USIP can be enabled globally for all new Load Balancing Services, or can be enabled on specific Load Balancing Services, so you can use SNIP for some web servers and USIP for others.

NetScaler networking design questions

Dedicated management VLAN? – Do you want to put the NetScaler Management IP (NSIP) on a dedicated Management VLAN? If so, then the NetScaler needs to be connected to the Management VLAN.

Dedicated cable? – Is the management VLAN on its own cable? Or is it on a Trunk Port with other VLANs?
Access Port – If the management VLAN is on a dedicated cable, then configure that switch port as an Access Port so the NSIP VLAN is not tagged.
Native VLAN on Trunk Port – If the management VLAN is on a Trunk Port, it’s easiest if the NSIP VLAN is untagged, so configure the NSIP VLAN as the native VLAN
Tagged management VLAN? – Or does the network team require the management VLAN to be tagged? If so, then NetScaler will need special NSVLAN configuration.

Interface 0/1 is only for management – Dedicated management VLANs are usually connected to interface 0/1 on the NetScaler. If you don’t have a dedicated management VLAN, then don’t use interface 0/1 on physical NetScalers and instead, use interfaces 1/1 and higher. That’s because interface 0/1 is not optimized for high-throughput traffic.

What VLAN do you want the VIPs to be on? – one VLAN? Multiple VLANs? Clients send traffic to VIPs. For public-facing VIPs, they are typically created on a DMZ VLAN. You must connect the NetScalers to all VLANs that host NetScaler VIPs. In other words, the NetScaler must be Layer 2 connected to any VLAN where you want to create a NetScaler VIP.

Do you want the NetScaler to be Layer 2 connected to the web server VLANs? – there usually is no requirement for NetScaler to be Layer 2 connected to the web servers, since NetScaler can use a router to reach the web servers on remote subnets.

Web Servers reply to SNIP – In USNIP mode (the default), Web Servers reply to the packet’s Source IP, which is a NetScaler SNIP. This is sometimes called one-arm mode, because there’s no need to change any of the networking on the web servers. The Default Gateway on the Web Servers does not need to be changed. The Web Severs do not need to be moved to any other VLAN.
SNIP as Web Server Default Gateway – Some load balancing architectures require the web servers to use a NetScaler SNIP as their default gateway. This is either an older architecture, or an advanced architecture. In this case, the NetScaler SNIP would need to be on the same subnet as the web servers, and thus the NetScaler needs to be connected to the web server VLAN. This is sometimes called two-arm mode.
One-arm vs two-arm is unrelated to the number of VLANs – One-arm and two-arm has nothing to do with the number of VLANs a NetScaler is connected to. With one-arm, the Source IP of the packets is changed to a NetScaler SNIP, thus no networking changes are needed on the web servers. With two-arm, the source IP of the packets is not changed, but the web server replies need to get to the NetScaler, so the web server Default Gateway is changed to a NetScaler SNIP.

Which networking connections need redundancy? – plug in two or more cables and bond them (Port Channel)

Port Channel across multiple switches? – on Cisco NX-OS, configure “virtual port channel”. LACP is required on the NetScaler.

Will you combine multiple VLANs onto a single Interface/Channel? – if so, then configure the switch port or channel as a Trunk Port.

Which VLAN will host the default route (default gateway)? – The default route is usually through a router on the DMZ VLAN, which allows the NetScaler to send replies to any Internet IP address.

Static routes for internal subnets – for internal subnets, create static routes that use an internal router as next hop address. Instead of adding a static route for every single internal subnet (e.g. 10.10.5.0/24, 10.10.6.0/24, etc.), can you summarize the internal networks (e.g. 10.0.0.0/8)? Ask the networking team for assistance.
PBR for dedicated management interface – When an internal machine connects to the NSIP, it sends a packet that eventually goes through a router that is connected to the dedicated management VLAN. When the NSIP replies, it should send that reply back to the same management router. However, your default route is probably on the DMZ network, and you probably have static routes for internal subnets that use a router on a different data VLAN. To send the replies correctly, configure the NetScaler with a Policy Based Route that causes all packets with Source IP = NSIP to use a management VLAN router as the next hop address. PBR also fixes routing issues for traffic that is sourced from the NSIP (LDAP, NTP, Syslog, etc.)
MBF? – Another option for the management network is Mac Based Forwarding, which keeps track of which interface a packet came in on, and replies out the same interface. This works for replies from the NSIP, but doesn’t do anything for traffic that is sourced by the NSIP (LDAP, NTP, Syslog, etc.)
Multiple Internet Circuits – If clients connect to the NetScaler VIPs through multiple Internet circuits, then you probably want replies to go back out the same way they came in. This won’t work if you only have a single default route. The easiest way to enable this is to enable Mac Based Forwarding (MBF), which keeps track of which interface/router a client request came in on, and replies out the same interface/router. You can combine MBF with PBR for the NSIP-sourced traffic.

Is the NetScaler connected to multiple VLANs/Subnets? – if so, then you must configure VLANs on the NetScaler. VLAN objects are required on the NetScaler whether you need VLAN tagging or not.

A NetScaler might be connected to a single VLAN – this is the easiest configuration. Just create NSIP, SNIP, and VIPs in the same IP subnet. No special NetScaler networking configuration required.

NetScaler Forwarding Tables

NetScaler has at least three tables for choosing how to forward a packet. They are listed below in priority order (MBF overrides PBR, which overrides routing table)

Mac Based Forwarding (MBF) – keeps track of which interface/router a client request came in on, and replies out the same interface/router. Only works for replies. Since it overrides routing tables, MBF is usually discouraged unless absolutely necessary.
Policy Based Route (PBR) – chooses a next hop address based on information in the packet (e.g. source IP, source port, destination port). Normal routing only chooses next hop based on destination IP, while PBR can use additional packet fields. PBRs are difficult to maintain, and thus most networking people try to avoid them. But they are sometimes necessary (e.g. dedicated management network).
Routing Table – the routes in the routing table come from three sources: SNIPs (directly connected subnets), manually-configured Static Routes (including default route), and Dynamic Routing (OSPF, BGP).

NetScaler networking configuration

NetScaler networking configuration vs Server networking configuration – NetScaler networking is completely different than server networking. NetScaler is configured like a switch, not like a server.

- Servers assign IPs to NICs – On servers, you configure an IP address directly on each NIC. Most servers only have one NIC.
- NetScalers are configured like a Layer 3 Switch – On NetScalers, you assign VLANs to interfaces, just like a switch. Then you put NetScaler-owned IP addresses into each of those VLANs, which again, is just like a Layer 3 switch. More specifically, you create VLAN objects, bind the VLAN to the interface/channel, and bind a SNIP to the VLAN.

Disable unused Interfaces – if a NetScaler interface (NIC) does not have a cable, then disable the interface (System > Network > Interfaces, right-click an interface, and Disable). If you don’t disable the unused interfaces, then High Availability (HA) will think the interfaces are down and thus failover.

LACP – if your port channels have LACP enabled, go to System > Network > Interfaces, edit two or more member interfaces, check the box for LACP, and enter the same LACP Key. If you enter 1 as the key, then a channel named LA/1 is created.

For manual port channels, go to System > Network > Channels, add a channel, select LA/1 or similar, and bind the member interfaces.

NSIP is special – NSIP lives in VLAN 1. If you don’t need to tag the management VLAN, then leave NSIP in VLAN 1. VLAN 1 on the NetScaler does not need to match the switch because you’re not tagging the packets with the VLAN ID. When you bind VLANs to the other interfaces, those interfaces are removed from VLAN 1 and put in other VLANs. The remaining interface in VLAN 1 is your management interface.

- NSVLAN – if your management VLAN is tagged, then normal VLAN tagging configuration won’t work. Instead, you must configure NSVLAN to tag the NSIP/management packets with the VLAN ID. All other VLANs are configured normally as shown next.
- PBR – if you connected to a dedicated management VLAN/subnet, configure a Policy Based Route (PBR) based on NSIP as Source IPs, and a management VLAN router as the next hop.

VLANs – If the NetScaler is connected to multiple VLANs:

1. Create a SNIP for each VLAN (except the dedicated management VLAN).
2. Create a VLAN object for each VLAN, and specify the VLAN ID (same as switch). It doesn’t matter if the VLAN is tagged or not, you still must create a separate VLAN object on NetScaler for each subnet.
3. Bind the VLAN object to the interface or channel. If the switch needs the VLAN to be tagged, then check the box to tag the packets with the specified VLAN ID.
4. Bind the VLAN object to the SNIP for that VLAN.

Static Routes – Add static routes for internal subnets through an internal router on a “data” network. The “data” network is usually a high bandwidth connection that is different than the management network.

Change Default Route to DMZ router – now that PBR and Static Routes are configured, you can probably safely delete the default route (0.0.0.0) and recreate it without you losing connection to the NSIP.

Layer 2 Troubleshooting – To verify VLAN connectivity, log into another device on the same VLAN (e.g. router/firewall) and ping the NetScaler SNIP or NSIP. Immediately check the ARP cache to see if the IP address was converted to a MAC address. If not, then layer 2 is not configured correctly somewhere (e.g. VLAN configuration), or there’s a hardware failure (e.g. bad switch port).

Layer 3 Troubleshooting – There are many potential causes of Layer 3 routing issues. A common problem is incorrect Source IP chosen by the NetScaler. To see the Source IP, SSH to the NetScaler, run shell, then run nstcpdump.sh host <Destination_IP>. You should see a list of packets with Source IP/Port and Destination IP/Port. Then work with the firewall and routing teams to troubleshoot packet routing.

NetScaler High Availability (HA)

Disable unused interfaces – All network interfaces on NetScaler by default have HA monitoring enabled. If any enabled interface is down (e.g. cable not connected), then HA will failover. Disable the unused interfaces so HA won’t monitor them any more.

HA heartbeat packets are untagged – Two nodes in a HA pair send heartbeat packets out all interfaces. These heartbeat packets are untagged. If the switch does not allow untagged packets (no native VLAN on a Trunk Port), then some special configuration is required.

On NetScaler, for each Trunk interface/channel, turn off tagging for one VLAN. Don’t worry about the switch configuration. Just do this on the NetScaler side.
On NetScaler, go to System > Network > Interfaces (or Channels), double-click the interface/channel, and enable Tag All VLANs. The VLAN you untagged in step 1 will now be tagged again. As a bonus, HA heartbeat packets will also be tagged with the same VLAN ID you untagged in step 1.
To verify that HA heartbeats are working across all interfaces, SSH to each NetScaler node, and run show ha node. Look for “interfaces on which HA heartbeat packets are not seen”. There should be nothing in the list.

GARP – When an HA pair fails over, the new primary appliance performs a Gratuitous ARP. For two devices on the same subnet (e.g. router and NetScaler) to talk each other, they first perform ARP to convert the IP addresses to MAC addresses. The IP address to MAC address mappings are cached (ARP cache). Each HA NetScaler node has different MAC Addresses. After a failover, the new appliance needs to tell the router to start sending traffic to the new node’s MAC addresses instead of the old node’s MAC addresses. A GARP packet is intended to inform a router to update it’s ARP cache with the new MAC address information. Some routing devices (e.g. firewalls) will not accept GARP packets, and instead will wait for the ARP cache entry to time out. Or the router/firewall might not allow the IP address to move to a different MAC address. If HA failover stops all traffic, work with the router/firewall admin to troubleshoot GARP.

Port Channels and HA failover – A port channel has two or more member interfaces. If one of the member interfaces is down, should the appliance failover? How many member interfaces must fail before HA failover should occur? On NetScaler, double-click the channel, and you can specify a minimum throughput. If bonded throughput falls below this number due to member interface failure, then HA fails over.

Fail Safe – If at least one interface is down on both HA nodes, then HA will be unhealthy, and both nodes will stop responding. You can configure one of the HA nodes as the Fail Safe node so that at least one of the HA nodes will be up, even if not every interface is functional.

Firewalls

DMZ – public facing NetScaler VIPs should be on a DMZ VLAN that is sandwiched between two firewalls. That means the NetScaler must be connected to the DMZ.

Firewalls can route – When you connect a NetScaler to a DMZ, the firewall is usually the router.
NAT – Most DMZ VLANs use private IPs (10.0.0.0/8, 172.16.0.0/20, 192.168.0.0/16) instead of public IPs. These private IP addresses are not routable across the Internet. To make them accessible, you NAT a company-owned public IP to the private DMZ IP. Ask the firewall administrator to configure the NAT translations for each publicly-accessible DMZ VIP.

Internal VIPs – internal VIPs (accessed by internal users) should be on an internal VLAN (not in the DMZ).

Multiple security zones – If you connect a single NetScaler to both DMZ and Internal, here’s how the traffic flows:

Client connects to DMZ VIP, which goes through the firewall that separates the Internet from the DMZ.
NetScaler internal SNIP connects to internal server. Since the NetScaler is connected to the Internal network, NetScaler will use an internal SNIP for this traffic. If you have a firewall between DMZ and internal, that firewall has now been bypassed.

Separate NetScaler appliances for DMZ and internal – Bypassing the DMZ-to-internal firewall is usually not what security teams want. Ask Security for their opinion on this architecture. A more secure approach is to have different NetScaler appliances for DMZ and internal. The DMZ appliance is connected only to DMZ (except dedicated management VLAN). When the DMZ NetScaler needs to communicate with an internal server, the DMZ NetScaler uses a DMZ SNIP to send the packet to the DMZ-to-internal firewall. The DMZ-to-internal firewall inspects the traffic, and forwards it if the firewall rules allow. The firewall rule allows the DMZ SNIP to talk to the web server, but the firewall does not allow client IPs (on the Internet) to talk directly to the web server.

Traffic Isolation – NetScaler has some features that can isolate traffic on a single appliance:

Net Profiles – allows you to specify a particular SNIP to be used by a vServer, or Service. Firewalls can allow different SNIPs to access different web servers.
Traffic Domains – each Traffic Domain is a different routing table. Put different NetScaler objects in different Traffic Domains. Not all NetScaler features are supported.
Partitions – carve up an MPX/VPX appliance into different partitions, with each partition having access to a subset of the hardware. Each partition is essentially a separate NetScaler config, which means separate routing tables. However, not all NetScaler features work in a partition.
NetScaler SDX – carve up physical hardware into multiple virtual machines. Each VM is a full NetScaler VPX, each with its own configuration. No feature limitations.

Network firewall (Layer 4) vs NetScaler Web App Firewall (Layer 7) – Most network firewalls only filter on port numbers and IP addresses. A few of them can filter on HTTP packet contents.

NetScaler WAF vs next-gen network firewalls – NetScaler has a security feature called Web App Firewall (WAF), which does HTTP inspection/filtering. HTTP packet inspection on next-gen network firewalls is usually signature based, but NetScaler WAF can also be configured with a whitelist to only allow HTTP packets that match the whitelist.
Put network firewalls in front of NetScalers – NetScaler is not a layer 4 firewall like a Cisco ASA or Palo Alto. Thus you should always put a network firewall in front of your NetScaler, even if you enabled the NetScaler WAF feature.

Next Step

NetScaler Essential Concepts: Part 2 – Certificates/SSL, Authentication, HTTP, VPN Networking, PXE, GSLB

↧

NetScaler Essential Concepts: Part 2 – Certificates/SSL, Authentication, HTTP, VPN Networking, PXE, GSLB

June 20, 2017, 1:41 pm

≫ Next: NetScaler Gateway 12 Native One Time Passwords (OTP)

≪ Previous: NetScaler Essential Concepts: Part 1 – Request-Response, HTTP Basics, and Networking

Navigation

HTTP Encryption

SSL Protocol, and Keys

SSL/TLS Protocol – SSL (Secure Sockets Layer) and TLS (Transport Layer Security) are two names for encrypted HTTP. SSL is the older, more well-known name, and TLS is the newer, less well-known name. The names can usually be used interchangeably, although pedantic people will insist on TLS instead of SSL. In NetScaler, you’ll mostly see the term SSL instead of TLS.

Port 443 – Web Servers that support SSL/TLS protocol listen for encrypted HTTP on TCP 443. Enabling SSL/TLS on a web server requires creation of keys/certificate, and binding them to a TCP 443 listener.
https protocol – Users enter https://FQDN into a web browser to connect to a web server using SSL/TLS protocol on TCP 443. Technically, https = HTTP on top of SSL/TLS.
Disable http? – You can optionally disable clear-text HTTP over TCP 80. Or you can leave the TCP 80 listener and configure it to redirect TCP 80 connections to TCP (https) 443.

SSL/TLS version – There are several versions of the SSL/TLS protocol. TLS v1.2 is the newest, but TLS v1.3 is coming soon. PCI compliance dictates that TLS v1.0 and v1.1 should be disabled, but not all software is compatible with TLS v1.2 yet. SSL v3 is the older protocol, and must be disabled on all SSL vServers. All versions of TLS are newer than SSL v3.

SSLLabs.com can check your SSL Listener to make sure it adheres to the latest SSL security standards.

SSL Session – HTTP is transmitted on top of SSL/TLS. First, the SSL Client and SSL Server create an encrypted SSL Session. Then HTTP is transmitted across this SSL Session.

SSL Handshake is expensive – Establishing the SSL session (SSL Handshake) is an expensive (CPU) operation, and modern web servers and web browsers try to minimize how often it occurs, preferably without compromising security.
Bulk encryption – The traffic on top of the established SSL Session is bulk encrypted, which is far less impactful than initial SSL Session establishment.
SSL Specs – The NetScaler data sheets provide different numbers for SSL Transactions/sec (initial session establishment) and SSL Throughput (bulk encryption).

Public/Private key pair – The SSL vServer needs a public/privatekey pair. The Public Key and Private Key are linked together. Data encrypted by Public Key can only be decrypted by one Private Key. Data encrypted by the Private Key can only be decrypted by one Public Key.

Private key – The Private Key is called private because it needs to remain private. You must make sure that the Private Key is never revealed to any unauthorized individual. If that were to occur, the unauthorized person could use the Private Key to emulate the web server, and unsuspecting users might submit private data, including passwords, to the hacker.
Public key – The Public Key is called public because it doesn’t matter who has it. The public key is worthless without also having access to the private key.

Key size – When you create a public/private key pair, you specify a key size in bits (e.g. 2048 bits). The higher the bit size, the harder it is to crack. However, larger key sizes mean exponentially more processing power required. 2048 is the current recommended key size, even for Certificate Authorities. 2048 balances security with performance.

Private/Public Key vs Session Key – The Public/Private key pair is only used during initial SSL session establishment. The bulk of the encryption is performed using a new Session Key instead of the Public/Private key pair. The Session Key is generated by the SSL Client and sent to the SSL Server so both parties know the Session Key. Traffic encrypted by the Session Key can only be decrypted by the Session Key.

Session Keys are Symmetric Encryption – Since only one Session Key is used to both encrypt and decrypt, this is called Symmetric Encryption.
Public/Private Keys are Asymmetric Encryption – In a public/private key pair, different keys are used for encryption and decryption. This is called Asymmetric Encryption.

How the SSL Session Key is generated

The SSL Client initiates the SSL Connection with the SSL Server.
The SSL Server sends its Public Key to the SSL Client, usually in a certificate.
The SSL Client generates a random SSL Session Key.
The SSL Client, encrypts the Session Key using the SSL Server’s Public Key, and sends the encrypted Session Key to the SSL Server.
The SSL Sever uses its Private Key to decrypt the SSL Session key.
Now both sides know the Session Key and can use that Session Key to perform bulk encryption.

Session Key size – the Session Key is much shorter than the private/public keys. For example, the Session Key can be 256 or 384 bits, while the public/private keys are 2048 bits. Because of their shorter size, Session Keys are thus much faster than public/private keys. The length of the Session Key depends on the negotiated cipher, as detailed later.

Renegotiation – SSL Clients and SSL Servers will sometimes want to redo the SSL Handshake while in the middle of an SSL Session. This is called Renegotation.

Forward Secrecy:

Without Forward Secrecy, if you take a packet trace, you can use the SSL Server’s Private Key to decrypt Session Keys in the packet trace, and use that decrypted Session Keys to decrypt the rest of the packet trace.
With Forward Secrecy, the public/private key pair are generated every time a new SSL Session is established. Thus every session has a different private key. It’s not possible to find the per-session private key, and use it to decrypt the Session Key.
DH vs RSA – Diffie-Hellman (DH) Key Exchange algorithm enables Forward Secrecy. RSA Key Exchange does not. ECDHE is the modern version of DH Key Exchange that is preferred by security professionals.

Certificates

Public Key in Server Certificate – The SSL Server’s Public Key is included in the SSL Sever’s Certificate, which is transmitted to the SSL Client when the SSL Client initially connects. The certificate contains the public key, plus additional fields like: Subject, Issuer, Validity Dates, CA Signature, Certificate Revocation Location, etc.

Keys and certificates are different things – The public/private key pair, and the certificate, are two different things. First, you create a public/private key pair. Then you create a certificate that contains the public key. Windows hides this operation from you so many Windows admins are not aware that keys are separate from the certificate. However, NetScaler is UNIX-based, which stores the keys and certificate in separate files.

Certificates provide a form of authentication – The SSL Client needs to authenticate the SSL-enabled web server so that the SSL Client only sends confidential data to trusted web servers. There are several fields in the SSL Server’s certificate that clients use to verify web server authenticity. Each of these is detailed later in this section.

FQDN – the hostname entered in the browser’s address bar must match the FQDN in the server’s certificate.
CA Signature – the server’s certificate must be signed a trusted Certificate Authority that has verified the owner of the website.
Validity Dates – the certificate must not be expired.
Revocation – the certificate must not be revoked.

Types of certificates – there are different types of certificates for different use cases. All certificates are essentially the same, but some of the certificate fields control how a certificate can be used:

Server Certificates – when linked to a private key, these certificates enable encrypted HTTP.
CA Certificates – used by a SSL client to verify the CA signatures contained within a Server Certificate.
Client Certificates – used by clients to authenticate the client machine or user to the web server. Requires a private key on the client side.
SAML Certificate – self-signed certificate exchanged to a different organization to authenticate SAML Messages (federation).
Code Signing Certificate – developers use this certificate to sign the applications they developed.

Digital Signatures – Signatures are used to verify that a file has not been modified in any way. A Hashing Algorithm (e.g. SHA256) produces a hash of the file. A Private Key encrypts the hash. When a machine receives the signed file, the receiving machine generates its own hash of the file. Then it decrypts the file’s signature using the Public Key that is linked with the Private Key that encrypted it, and compares the hash in the file with the hash that the receiving machine generated. If a third party used it’s Private Key to encrypt the hash, then the receiving machine needs a copy of the third-party’s Public Key to decrypt the hash.

Third party Signatures – A file can be hashed and signed by the same organization that created the file. Or the file can be hashed and signed by a different organization (third party). When a third party signs a file that it did not generate, the assumption is that the 3rd party verified the authenticity of the file. Only the third party’s Public Key can be used to verify the signature.

Certificate Signature – Certificates are usually digitally signed by a trusted third party, formally known as the Certificate Authority. This third party verifies that the organization that produced the certificate actually owns the server that is hosting the certificate. The name of the Certificate Authority is contained in the Issuer field of the certificate.

CAs use the CA’s Private Key to sign a certificate – The CA generates a hash of the certificate and signs the hash using the CA’s Private Key. Later, the client machine will use the CA’s Public Key to verify the hash.
- Self-signed certificate – Instead of using a third party’s private key to encrypt the hash, it’s also possible for a certificate to use its own key pair to sign its own certificate. In this case, the Issuer of the certificate and the Subject of the certificate are the same. Most browsers will not accept self-signed certificates.
CA Chain – The CA Certificate (with private key) that signed the Server Certificate can itself be signed by a different CA Issuer with its own private key. In this case, the Issuer of the CA’s certificate is a different CA certificate. For example: Intermediate CA 2 signs your Server Certificate. Intermediate CA 1 signs Intermediate CA 2’s certificate. Root CA signs Intermediate CA 1’s certificate.
- Root CA certificates are self-signed– As you go up the CA certificate chain, you’ll eventually reach a Root CA certificate that is signed by itself, and not by a different CA certificate. Thus all CA Root Certificates are self-signed.
Root CA certs are installed on SSL clients. CA’s pay Microsoft, Chrome, Mozilla, Apple, etc. to install their Root CA Certificates on client machines. The Root CA certificates contain the Public Keys that clients use to verify CA signatures on certificates.
Intermediate CA certificates – In the CA Signature Chain, between the Server Certificate and the Root CA Certificate are Intermediate CA Certificates. These Intermediate CA certificates are not installed on client machines. Instead, they must be transmitted to the SSL Client by the SSL Server. On a NetScaler, you link Intermediate CA Certificates to the Server Certificate, which causes the NetScaler to transmit multiple certificates during the SSL Handshake. On IIS, you simply install the Intermediate Certificate in the web server computer’s Intermediate CA certificate store.
The Root CA certificate must never be transmitted by the SSL Server; only the Intermediate CA certificates must be transmitted. The Root CA certificate is already installed on the client machine through an out-of-band operation (e.g. included with the operating system). If the Root CA certificate could be transmitted by the SSL Server, then the entire third party trust model is broken. (SSL Labs will report this as “Chain issues: Contains anchor”.)
Internal Certificate Authority – you could build your own internal Certificate Authority and use it to sign your certificates. This can be a Microsoft CA server. Or you can use your NetScaler as a CA.
- Internal CA Root Cert certificate distribution – Since your CA’s Root Certificate is not installed on the client devices, your internally-signed certificates won’t be trusted. You must find some out-of-band mechanism for distributing the CA Root Certificate. Typically this distribution is performed using Group Policy.
Self-signed certificates, and internally-signed certificates, are two different things. If you build your own Certificate Authority, and use it to sign your certificates, that is not self-signed, because the Issuer and Subject are different. Self-signed only occurs when the Issuer and the Subject are the same.

To create a certificate – The process to create a certificate is as follows:

Create keyfile – Use OpenSSL or similar to create a public/private key pair file.
Create CSR – Use OpenSSL or similar to create a Certificate Signing Request (CSR). The CSR contains the public key, and several other fields, including: server’s DNS name, and name of the Organization that owns the server.
Send CSR to CA – The CSR is sent to a Certificate Authority (CA) to get a signature. Public CAs usually charge a fee for this service.
CA verifies ownership – The CA verifies that the Organization Name specified in the CSR actually owns the server’s DNS name. One method is to email somebody at the same organization. More stringent verifications include background checks for the DUNS name. Higher verification usually requires a higher fee.
CA signs the certificate – If owner verification is successful, then the CA signs the certificate and sends it back to the administrator. The CA can use multiple chained CA Certificates to sign your Server certificate.
Complete certificate request – The administrator links the signed certificate with the keyfile. In IIS, this is called “Complete Certificate Request”. In NetScaler, when installing a cert-key pair, you browse to both the certificate file, and the key file.
Create a TCP/SSL 443 listener and bind the certificate to it – Configure the web server to use the certificate. In IIS, add a https binding to the Default Web Site and select the certificate. In NetScaler, create a SSL vServer, and bind the certificate to it.

Keys and Certificates are stored in separate files – On UNIX/Linux, certificates/keys are stored in two files – a key file (.key extension), and a certificate file (.pem, .cer, .cert extension). Both are Base64 encoded, which is also known as PEM. PEM is the native format that NetScaler uses.

Private Keys on Windows – On Windows, the keys are stored in a hidden portion of the file system that is not intended to be accessed by users. Instead, you can export a certificate and keys to a password-encrypted PFX file, which is also known as PKCS#12. Newer versions of NetScaler can directly import PFX files, while older versions of NetScaler require the PFX files to be converted to PEM format first.
Private key linked to certificate? – On Windows, when you double-click a certificate in the IIS Console, or the Certificate MMC snap-in, the bottom of the first General page indicates if there’s a private key linked to this certificate. Only certificates with private keys can be used with IIS website hosting. Certificates without private keys are usually CA certificates (root or intermediate).
DER Format – On Windows, if your certificate doesn’t have a private key associated with it, then you can save the certificate to a file in DER format, or in Base64 (PEM) format. Newer versions of NetScaler can directly import DER files automatically, while older versions of NetScaler require you to specify DER format manually while importing the certificate file.
Certificate/key file storage on NetScaler – On NetScaler, certificate files and key files are stored in /nsconfig/ssl. The NetScaler configuration for SSL certificates points to files in this directory.

Private Keys should be encrypted – the key file that contains the Private Key should be encrypted, usually with a password. On NetScaler, when creating a key pair, you specify PEM Encoding, and set it to 3DES (Triple DES) encryption. You enter a permanent password, which is used to encrypt the private key.

When converting a PFX file to PEM, the new private key in the PEM file should be encrypted. Specify a 3DES password when performing this conversion.
Hardware Security Module (HSM) – Another storage option for private keys is a Hardware Security Module (HSM). HSMs are physical devices that can’t be physically compromised. The NetScaler FIPS appliances include a HSM module inside the appliance. Or, you can connect a NetScaler to a network-addressable HSM appliance. The HSM performs all private key operations so that the private key never leaves the HSM device.
Smart Card – Another storage option for private keys is a Smart Card. Smart Cards require the user to enter a PIN to unlock the smart card to use the private key, similar to an HSM. Smart Cards are typically used with Client Certificates, which are detailed later.

Certificate Fields

Subject field – One of the fields in the Server Certificate is called Subject. On the far right of the subject is CN=, which means Common Name, which might be familiar to LDAP (e.g. Active Directory) administrators. The Common Name is the DNS name of the web server.

User enters FQDN in browser address bar – User opens a browser and enters https://FQDN in the browser’s address bar to connect to the web server.
FQDN in browser’s address bar is matched to Certificate Subject Name – The Server Certificate is downloaded from the web server. The Common Name of the certificate is then checked to make sure it matches what the user entered in the browser’s address bar. If they don’t match, then a certificate error is displayed.

Subject Alternative Names – Another related Certificate field is called Subject Alternative Names (SAN). The Subject field (Common Name) only supports a single DNS name. SAN can support as many DNS names as desired.

Public CAs charge extra for each additional SAN name. And there are restrictions on the names can be added to the SAN field.
Common Name must be added to SAN list – When you create a CSR and specify a Common Name, Public CAs always add this Common Name to the SAN list. Chrome recently started requiring that the FQDN in the browser’s address bar to be in the Server Certificate’s SAN list. For Public CA-issued certificates, this is not a problem, since they automatically add the name to the SAN list. However, if you issued certificates from an internal CA, then the FQDN might be missing from the SAN List.

Wildcard certificate – The Certificate Common Name can be a wildcard (e.g. *.company.com) instead of a single DNS name. This wildcard matches all FQDNs that end in .company.com. The wildcard only matches one word and no periods to the left of .company.com. It will match www.company.com, but it will not match www.gslb.company.com, because there’s two words instead of one. It will also not match company.com because it requires one word where the * is located.

Wildcard certificates cost more from Public CAs than single name certificates and SAN certificates.
Wildcard certificates are less secure than single name certificates, because you typically use the same wildcard certificate on multiple web servers, and if one of the servers is compromised, then all are compromised.

CA Signature verification – In addition to verifying the certificate Common Name, the browser also verifies that it trusts the CA signatures. On every client machine is a pre-installed list of CA root certificates. These root certificates are used to verify the CA signatures on the certificate. The signature is created with the CA’s private key, and the signature is verified using the CA’s public key, which is in the CA’s root certificate.

Certificate chain – The SSL server’s certificate might be signed by more than one CA certificate, which are linked together in a chain. The SSL cert is signed by one of more intermediate certificates, which are signed by a root certificate.
Intermediate certificates – The NetScaler must be configured to send both the SSL cert and the intermediate certificates (usually only one intermediate certificate). The root certificate is already on the client machine so the NetScaler must not send the root. To send both SSL cert and intermediate, you install the intermediate certificate on the NetScaler, and Link them together.

Validity Dates – Another field in the certificate is expiration date. If the date is expired, then the client’s browser will show a certificate error. When you purchase a certificate, it’s only valid between 1 year and 5 years, with CAs charging more for longer terms.

Expiration Warning – NetScaler MAS can alert you when a certificate is about to expire. The CA will also remind you to renew it.
Renew with existing keys? – When renewing the certificate, you can create a new SSL key pair, or you can use the existing key pair. If you create a new key pair, then you need to create a new CSR and submit it to the CSR. If you intend to use the existing keys, then simply download the updated certificate from the CA after paying for the later expiration date.

Certificate Revocation – certificates can be revoked by a CA. The list of revoked certificates is stored at a CA-maintained URL. Inside each SSL certificate is a field called CRL Distribution Points, which contains the URL to the Certificate Revocation List (CRL). Client browsers will connect to the CRL to verify that the SSL server’s certificate has not been revoked. Revoking is usually necessary when the web server’s private key has been compromised.

CAs might revoke a certificate when Rekey – if you rekey a certificate, the certificate with the former keys might be revoked. This can be problematic for wildcard certificates that are installed on multiple machines, since you only have a limited time to replace all of them. Pay attention to the CA’s order form to determine how long before the prior certificate is revoked.
Online Certificate Status Protocol – An alternative form of revocation checking is Online Certificate Status Protocol. The address for the OCSP server can be found in the certificate’s Authority Information Access field.

Client Certificate – Another type of certificate is Client Certificate. This is a certificate with private key, just like a Server Certificate. Client Certificates are installed on client machines, and usually are not portable (the private key can’t be exported). Client machines use the Client Certificate to authenticate with web servers. This client certificate authentication can simply verify the presence of the certificate on a corporate managed device. Or the user’s username can be extracted from the client certificate and used to authenticate the user.

Smart cards have client certificates with private key installed on them. The client certificate on the smart card authenticates the user to the web server (or NetScaler). Users enter a PIN number to unlock the smart card to use the client certificate’s private key. Smart Cards eliminate needing to enter a password to authenticate with a web server.
Virtual Smart Cards – There are also virtual smart cards, which use hardware features of the client device to protect the client certificate. The client’s TPM (Trusted Platform Module) encrypts the private key. If the client certificate were moved to a different device, then the new device’s TPM wouldn’t be able to decrypt the private key. Windows Hello for Business is an example of this technology.

SSL Ciphers

Cipher Suites are negotiated – During the SSL Handshake, the SSL Client and the SSL Server negotiate which cipher algorithms to use. A detailed explanation of ciphers would require advanced mathematics, but here are some talking points:

Recommended list of ciphers – Security professionals (e.g. OWASP, NIST) publish a list of the recommended, adequately secure, cipher suites. These ciphers are chosen because of their very low likelihood of being brute force decrypted within a reasonable amount of time.
Higher security means higher cost. For SSL, this means more CPU on both the web server (NetScaler), and SSL Client. You could go with high bit-size ciphers, but they require exponentially more hardware.
Each cipher suite is a combination of cipher technologies. There’s a cipher for key exchange. There’s a cipher for bulk encryption. And there’s a cipher for message authentication. So when somebody says “cipher”, they really mean a suite of ciphers.

Ephemeral keys and Forward Secrecy – ECDHE ciphers are ephemeral, meaning that if you took a network trace, and if you had a the web server’s private key, it still isn’t possible to decrypt the traffic. This is also called Forward Secrecy.

DHE = Ephemeral Diffie Hellman, which provides Forward Secrecy.
EC = Elliptical Curve, which is a formula that allows smaller key sizes, and thus faster computation.
How to trace when Forward Secrecy is enabled? – Since Forward Secrecy packet traces can’t be decrypted, when you want to trace SSL traffic for troubleshooting, you must first disable all ECDHE cipher suites.

Ciphers in priority order – The SSL server is configured with a list of supported cipher suites in priority order. The top cipher suite is preferred over lower cipher suites.

The highest common cipher between SSL Server and SSL Client is chosen – When the SSL Client starts an SSL connection to an SSL Server, the SSL Client transmits the list of cipher suites that it supports. The SSL Server then chooses the highest matching cipher suite. If neither side supports any of the same cipher suites, then the SSL connection is rejected.

Citrix-recommended cipher suites – See https://www.citrix.com/blogs/2016/06/09/scoring-an-a-at-ssllabs-com-with-citrix-netscaler-2016-update/ for the list of cipher suites that Citrix currently recommends. Every SSL vServer created on the NetScaler should be configured with this list of cipher suites in the order listed.

GCM ciphers seem to be preferred over CBC ciphers.
EC (Elliptical Curve) ciphers seem to be preferred over non-EC ciphers.
Ephemeral ciphers seem to be preferred over non-Ephemeral ciphers.

Authentication

NetScaler Authentication Overview

NetScaler supports several different authentication mechanisms.

Single Sign-on – Once a user has been authenticated by NetScaler, NetScaler can usually perform Single Sign-on to the back-end resource (webpage, Citrix StoreFront, etc.).

Different authentication methods for client and server – The authentication method used to authenticate the user doesn’t have to match the authentication method used for Single Sign-on. For example, NetScaler can use LDAP+RADIUS on the client side, and convert it to Kerberos on the server side.

LDAP for Active Directory authentication – LDAP is just one of the authentication mechanisms supported by Active Directory. Another common authentication mechanism is Kerberos. Kerberos and LDAP are completely different technologies.

HTML logon page – LDAP credentials are typically entered in a HTML Form logon page.

RADIUS is typically used for two-factor authentication (e.g. passcodes).

Enable RADIUS in the two-factor product – To integrate a two-factor authentication product with NetScaler, you typically enable RADIUS protocol in the two-factor authentication product.

RADIUS is typically combined with LDAP.

A single HTML logon page can request the AD password and two-factor passcode at the same time.
NetScaler logs the user into Active Directory using LDAP.
Two-factor passcodes are verified using RADIUS.

SAML is primarily used to federate authentication between two or more organizations. The resources the user is trying to access (web sites) is in one organization, but authentication is handled in a different organization.

With SAML, the user’s password stays at the authenticating organization. The resource organization never sees the user’s password.
Trust between the two organizations is provided by certificates. The two organizations share certificates with each other to verify each other’s identity (signatures).

Kerberos is another method of authenticating with Active Directory.

Kerberos and LDAP authentication are completely different authentication methods.
To perform Kerberos authentication, the client machine must be able to communicate with a Domain Controller. This means Kerberos usually doesn’t work on the Internet, at least not without a VPN connection.
If NetScaler uses Kerberos to Single Sign-on to the back-end web servers, then NetScaler needs connectivity to internal DNS and internal Domain Controllers.

OAUTH allows a user to delegate credentials to a program. The program can log into a different Service using the user’s credentials. For example, Outlook with ShareFile Plug-in can automatically log into ShareFile without prompting the user for ShareFile credentials every time Outlook communicates with ShareFile.

OpenID Connect is an authentication mechanism for OAUTH. It’s very similar to SAML, except it uses JavaScript Web Tokens (JWT) instead of SAML Tokens (XML-based).

NSIP is Source IP – By default, NetScaler uses its NSIP (management IP) as the Source IP when communicating with authentication servers.

To use SNIP, load balance – You can force authentication to use SNIP by load balancing the authentication servers, even if there’s only one authentication server.

LDAP (Lightweight Directory Access Protocol)

LDAP authentication process:

HTML Form to gather credentials – NetScaler prompts user to enter a username and password, typically from an HTML Form.
Connect to LDAP Server – NetScaler connects to the LDAP Server on TCP 389 or TCP 636, depending on if encryption is enabled or not.
NetScaler logs into LDAP using a Bind account. This LDAP Bind account is an Active Directory service account whose password never expires. The only permissions it needs is to be able to search the LDAP directory, which is provided by being a member of the Domain Users group.
NetScaler sends an LDAP Query to the LDAP Server. The LDAP Query asks the LDAP Server to find the username that was entered in step 1. The LDAP Server returns the user’s full Distinguished Name (DN), which is the full path to the user’s account in the directory.
- NetScaler’s LDAP Search Filter controls the LDAP Query that is sent in step 4. A common usage is to only return users that are members of a specific AD Group.
Login as user’s DN – NetScaler reconnects to the LDAP Server but this time logs in as the user’s DN (from step 4), and the user’s password (from step 1).
Extract attributes – After authentication, NetScaler can be configured to extract attributes from the user’s LDAP account. A common configuration is to extract the user’s group membership. Another is to get the user’s userPrincipalName so it can be used during Single Sign-on to back-end web servers.

Password expiration requires LDAP encryption – If the user’s password has expired, then NetScaler can prompt the user to change the password. However, the user’s password can only be changed if the LDAP connection is encrypted, which means certificates must be installed on the LDAP servers (Active Directory Domain Controllers).

NetScaler does not inform the user how long before the user’s password expires.

LDAP Communication Protocols:

Clear text LDAP connects to the LDAP Server on TCP 389.
Two encrypted LDAP protocols – If the LDAP server has a certificate, then you can use one of two different protocols to connect to the LDAP Server. NetScaler supports both encrypted connection methods.
- LDAPS – this is encrypted LDAP. It’s a different port than LDAP, just like HTTPS is a different port than HTTP. LDAPS is typically TCP 636 on the LDAP Server.
- LDAP TLS – it starts as a clear text connection to the LDAP Server on TCP 389. Then both sides of the connection negotiate encryption parameters, and switch to encrypted communication on TCP 389.

RADIUS (Remote Authentication Dial-In User Service)

RADIUS authentication process:

HTML Form to gather credentials – NetScaler prompts user to enter username and passcode, typically from an HTML Form.
Send login request to RADIUS server – NetScaler sends a login request (Access-Request) to the RADIUS Server on UDP 1812. Since it’s UDP, there’s no acknowledgment from the Server.
1. Passcode encryption using shared secret – The user’s passcode in the RADIUS packet is encrypted using a shared secret key that is configured on the NetScaler and RADIUS Server. The secret key entered on NetScaler must match the secret key configured on the RADIUS Server. Each RADIUS Client usually has a different secret key.
2. RADIUS Attributes – The RADIUS Client (NetScaler) adds RADIUS attributes to the packet to help the RADIUS Server identify how the user is connecting.
RADIUS Server:
1. RADIUS Clients configured on RADIUS Server – The RADIUS Server first verifies that the RADIUS Client (NetScaler) is authorized to perform authentication. The NAS IP (NetScaler Source IP) of the RADIUS Access-Request packet is compared to the list of RADIUS Clients configured on the RADIUS Server. If there’s no match, RADIUS does not respond.
2. Shared secret – The RADIUS server finds the RADIUS Client and looks up the shared secret key. The secret key decrypts the passcode in the RADIUS Access-Request packet.
3. Verify RADIUS Attributes – RADIUS Server uses the RADIUS Attributes in the Access-Request packet to determine if authentication should be allowed or not.
4. Authenticate the user – RADIUS authenticates the user. Most RADIUS Server products have a local database of usernames and passwords. Some can authenticate with other authentication providers, like Active Directory.
5. Access-Accept and Attributes – RADIUS sends back a Access-Accept message. This response message can include RADIUS Attributes, like a user’s group membership.
RADIUS Challenge – RADIUS Servers can send back an Access-Challenge, which asks the user for more information. NetScaler displays the RADIUS-provided Challenge message to the user, and sends back to the RADIUS Server whatever the user entered.
1. SMS authentication uses RADIUS Challenge. The RADIUS server might send a SMS passcode to a user’s phone using SMS. Then RADIUS Challenge prompts the user to enter the SMS passcode.
Extract RADIUS Attributes – NetScaler can be configured to extract the returned RADIUS Attributes and use them for authorization (e.g. AAA Groups).

RADIUS Client – RADIUS will not work unless you ask the RADIUS administrator to add NetScaler NSIP (or SNIP if load balancing) as a RADIUS Client.

Secret key – The RADIUS administrator then gives you the secret key that was configured for the RADIUS Client. You enter this secret key in NetScaler when configuring RADIUS authentication.

SAML (Security Assertion Markup Language)

SAML uses HTTP Redirects to perform its authentication process. This means that Web Clients that don’t support Redirects (e.g. Citrix Receiver) won’t work with SAML.

SAML SP – The resource (webpage) the user is trying to access is called the SAML SP (Service Provider). No passwords are stored here.

SAML iDP – The authentication provider is called the SAML iDP (Identity Provider). This is where the usernames and passwords are stored.

SAML SP Authentication Process:

User tries to access a NetScaler VIP (NetScaler Gateway, or Load Balancing/AAA) that is configured for SAML SP Authentication.
NetScaler creates a SAML Authentication Request and signs it using its certificate (with private key).
NetScaler sends to the user’s browser the SAML Authentication Request, and a HTTP Redirect (301) that tells the user’s browser to go to the SAML iDP’s authentication Sign-on URL.
The user’s browser redirects to the iDP’s Sign-on URL and gives it the SAML Authentication Request that was provided by the NetScaler.
The SAML iDP verifies that the SAML Authentication Request was signed by the NetScaler’s certificate.
The SAML iDP authenticates the user. This can be a webpage that asks for two-factor authentication. Or it can be Kerberos Single Sign-on. It can be pretty much anything.
The SAML iDP creates a SAML Token (aka SAML Assertion) containing SAML Attributes. At least one of the attributes is Name ID, which usually matches the user’s email address. The SAML iDP can be configured to send additional attributes (e.g. group membership).
The SAML iDP signs the SAML Token using its certificate (with private key).
The SAML iDP sends the SAML Token to the user’s browser and asks the browser to Redirect (301) back to the SAML SP’s Assertion Consumer Service (ACS) URL, which is different from the original URL that the user requested.
The user’s browser redirects to the ACS URL and submits the SAML Token.
The SAML SP verifies that the SAML Token was signed by the SAML iDP’s certificate.
The SAML SP extracts the Name ID (email address) from the SAML Token. Note that the SAML SP does not have the user’s password; it only has the user’s email address.
The SAML SP sends back to the user’s browser a cookie that indicates that the user has now been authenticated.
The SAML SP sends back to the user’s browser a 301 Redirect, which redirects the browser to the original webpage that the user was trying to access in step 1.
The user’s browser submits the cookie to the website. The website uses the cookie to recognize that the user has already been authenticated, and lets the user in.

Multiple SAML SPs to one SAML iDP – The SAML iDP could support connections from many different SAML SPs, so the SAML iDP needs some method of determining which SAML SP sent the SAML Authentication Request. One method is to have a unique Sign On URL for each SAML SP. Another method is to require the SAML SP to include an Issuer Name in the SAML Authentication Request. In either case, the SAML iDP looks up the SAML SP’s information to find the SAML SP’s certificate (without private key), and other SP-specific information.

SAML Certificates:

SP Certificate – NetScaler uses a certificate to sign the SAML Authentication Request. This NetScaler certificate must be copied to the iDP.
iDP Certificate – The iDP uses a certificate to sign the SAML Token. The iDP certificate must be installed on the NetScaler.

Shadow Accounts – The SAML iDP sends the user’s email address to the SAML SP. The SAML SP has its own authentication directory. The email address provided by the SAML iDP is matched with a user account at the SAML SP. Even though the user’s password is never seen by the SAML SP, you still need to create user accounts for each user at the SAML SP. These SAML SP user accounts can have fake passwords. The SAML SP user accounts are sometimes called shadow accounts.

SAML Token can be converted to other authentication methods – It is often desirable to convert a SAML Token to another form of authentication. For example, the SAML SP can use the Name ID from the SAML Token to perform a database lookup to retrieve the user’s authorizations..

No passwords – Not having access to passwords limits the authentication options at the SAML SP. Without a password, you can’t authenticate to Active Directory using LDAP or NTLM. It’s also not possible to request a Kerberos ticket for the user since NetScaler doesn’t have the user’s password.
SAML Token and SSON to Citrix XenDesktop – Kerberos can use User Certificates to authenticate to Active Directory without a password. Citrix Federated Authentication Service takes advantage of this by requesting a User Certificate for each SAML Name ID, and then using the User Certificate to login to XenDesktop using Kerberos. Each SAML Name ID needs a matching shadow account.

Kerberos

Kerberos authentication process (simplified):

User tries to access a web page that is configured with Negotiate authentication.
To authenticate to the web page, the user must provide a Kerberos Service ticket. The Kerberos Service ticket is requested from a Domain Controller.
1. The Kerberos Service ticket is limited to the specific Service that the user is trying to access. In Kerberos parlance, the resource the user is trying to access is called the Service Principal Name (SPN). User asks a Domain Controller to give it a ticket for the SPN.
2. Web Site SPNs are usually named something like HTTP/www.company.com. It looks like a URL, but actually it’s not. There’s only one slash, and there’s no colon. The text before the slash is the service type. The text after the slash is the DNS name of the server running the service that the user is trying to access.
If the user has not already been authenticated with a Domain Controller, then the Domain Controller will prompt the user for username and password. The Domain Controller returns a Ticket Granting Ticket (TGT).
The user presents the TGT to a Domain Controller and asks for a Service Ticket for the Target SPN. The Domain Controller returns a Service Ticket.
The user presents the Service Ticket to the web page the user originally tried to access in step 1. The web page verifies the ticket and lets the user in.

The Service and the Domain Controller do not communicate directly with each other. Instead, the Kerberos Client talks to both of them to get and exchange Tickets.

Kerberos Delegation – The Kerberos Service Ticket only works with the Service listed in the Ticket. If that Service needs to talk to another Service on the user’s behalf, this is called Delegation. By default, Kerberos will not allow this Delegation. You can selectively enable Delegation by configuring Kerberos Constrained Delegation in Active Directory.

- In Active Directory Users & Computers, edit the AD Computer Account for the First Service. On the Delegation tab, specify the Second Service. This allows the first Service to delegate user credentials to the Second Service. Delegation will not be allowed from the First Service to any other Service.

Kerberos Impersonation – If NetScaler has the user’s password (maybe from LDAP authentication), then NetScaler can simply use those credentials to request a Kerberos Service Ticket for the user from a Domain Controller. This is called Kerberos Impersonation.

Kerberos Constrained Delegation – If the NetScaler does not have the user’s password, then NetScaler uses its own AD service account to request a Kerberos Service Ticket for the back-end service. The service account then delegates the user’s account to the back-end service. In other words, this is Kerberos Constrained Delegation. On NetScaler, the service account is called a KCD Account.

The KCD Account is just a regular user account in AD.
Use setspn.exe to assign a Kerberos SPN to the user account. This action unlocks the Delegation tab in Active Directory Users & Computers.
Then use Active Directory Users & Computers to authorize Kerberos Delegation to back-end Services.

Negotiate – Kerberos and NTLM – Web Servers are configured with an authentication protocol called Negotiate (SPNEGO). This means Web Servers will prefer that users login using Kerberos Tickets. If the client machine is not able to provide a Kerberos ticket (usually because the client machine can’t communicate with a Domain Controller), then the Web Sever will instead try to do NTLM authentication.

NTLM is a challenge-based authentication method. NTLM sends a challenge to the client, and the client uses the user’s Active Directory password to encrypt the challenge. The web server then verifies the encrypted challenge with a Domain Controller.
Negotiate on client-side with NTLM Web Server fallback – NetScalers can use Negotiate authentication protocol on the client side (AAA or NetScaler Gateway). Negotiate will prefer Kerberos tickets. If Kerberos tickets are not available, then Negotiate can use NTLM as a fallback mechanism. In the NTLM scenario, NetScaler can be configured to connect to a domain-joined web server for the NTLM challenge process. By using a separate web server for the NTLM challenge, there’s no need to join the NetScaler to the domain.

HTTP

URLs

HTTP URL format: e.g. https://www.corp.com:444/path/page.html?a=1&key=value

https:// = the scheme. Essentially, it’s the protocol the browser will use to access the web server. Either http (clear-text) or https (SSL/TLS).
www.corp.com = the hostname. It’s the DNS name that the browser will resolve to an IP address. The browser then connects to the IP address using the specified protocol.
:444 = port number. If not specified, then it defaults to port 80 or port 443, depending on the protocol. Specifying the port number lets you connect to a non-standard port number, but firewalls might not allow it.
/path/page.html = the path to the file that the Browser is requesting.
?a=1&key=value = query parameters to the file. The query clause beings with a ? immediately following the file name. Multiple parameters (key=value pairs) are separated by &. These parameters are typically generated using HTML forms. Query parameters are method for the HTTP Client to upload a small amount of data to the Web Server. There can be many parameters, or just one parameter.

URLs must be safe encoded (Percent encoded), meaning special characters are replaced by numeric codes (e.g. # is replaced by %23). See https://en.m.wikipedia.org/wiki/Percent-encoding.

HOST Header – one of the HTTP headers inserted into the HTTP Request Packet is named Host. The value of this header is based on whatever hostname the user typed into the browser’s address bar. It’s the part of the URL after the scheme (http://), and before the port number (:81) or path (/).

Web Servers use the Host Header to determine which website content should be served. This allows a Web Server to host multiple websites on one IP address. In this configuration, if the Host Header is not set correctly, then you might not see the website content you were hoping for. If the Web Server requires the Host Header to be set to a particular DNS Name, and if you enter the IP address into your browser’s address bar, then you won’t see the website.
NetScaler Load Balancing Monitors do not include the Host Header by default. If the Web Server requires the Host Header, then you must modify the NetScaler Monitor configuration to specify the Host header.

HTTP Body – The HTTP Body is the content you are transporting across the network. The HTTP body of an HTTP Request or HTTP Response can contain data, or a file.

Data can be HTML Form Parameters, JSON object, XML document, etc. These are detailed below.
File can be HTML file, .iso file, .png file, etc.
HTTP Body vs HTML Body – HTTP Body and HTML Body are completely different. An HTTP Body can contain an entire HTML file, which has a HTML Header and HTML Body. Or an HTTP Body can contain non-HTML file or data. HTML is just one of the file types that an HTTP Body can transport.

Cookies

Client-side Data Storage – Web Servers sometimes need to store small pieces of data in a user’s web browser. The user’s browser is then required to send the data back to the web server with every HTTP Request.

Set-Cookie – Web Servers add a Set-Cookie header to the HTTP Response. This Response Header contains a list of Cookie Names and Cookie Values.

Cookies are linked to domains – The Web Browser stores the Cookies in a place that is associated with the DNS name (host name) that was used to access the web site. The next time the user submits an HTTP Request to that DNS name, all Cookies associated with that host name are sent in the HTTP Request using the Cookie Request header.

Notice that the two headers have different names. HTTP Response has a Set-Cookie header, while HTTP Request has a Cookie header.

Cookie security – Cookies from other domains (other DNS names, other web servers) are not sent. Cookies usually contain sensitive data (e.g. session IDs) and must not be sent to the wrong web server. Hackers will try to steal Cookies so they can impersonate the user.

Cookie lifetimes are either Session Cookies, or Persistent Cookies. Session Cookies are stored in the browser’s memory and are deleted when the browser is closed. Persistent Cookies are stored on disk and available the next time the browser is launched.

Expiration date/time – Persistent Cookies are sent from the Web Server with an expiration date/time. This can be an absolute time, or a relative time.

NetScaler Cookie for Load Balancing persistence – NetScaler can use a Cookie to maintain load balancing persistence. The name of the Cookie is configurable. The Cookie lifetime can be Session or Persistent.

Web Server Sessions

Web Server Sessions preserve user data for a period of time – When users log into a web site, or if the data entered by a user (e.g. shopping cart) needs to be preserved for a period of time, then a Web Server Session needs to be created for each user.

Web Server Sessions are longer than TCP Connections – Web Server Sessions live much longer than a single TCP Connection, so TCP Connections cannot delineate a session boundary.

Each HTTP Request is singular – There’s nothing built into HTTP to link one HTTP Request to another HTTP Request. Various fields in the HTTP Request can be used to simulate a Web Server Session, but technically, each HTTP Request is completely separate from other HTTP Requests, even if they are from the same user/client.

Server-side Session data, and Client-side Session ID – Web Server Sessions have two components – server-side session data, and some kind of client-side indicator so the web server can link multiple HTTP Requests to the same server-side session.

A Cookie stores the Session ID – On the client-side, a session identifier is usually stored in a Cookie. Every HTTP Request performed by the client includes the Cookie, so the web server can easily associate all of these HTTP Requests with a Server-side session.

Server-side data storage – On the server-side, session data can be stored in several places:

Memory of one web server – this method is the easiest, but requires load balancing persistence
Multiple web servers accessing a shared memory cache (e.g. memcached)
Shared Database – each load balanced web server can pull session data from the database. This is typically slower than memory caches

Load Balancing Persistence and Web Server Sessions – some web servers store session data on the same web server the user initially connected to. If the user connects to a different web server, then the old session data can’t be retrieved, thus causing a new session. When load balancing multiple identical web servers, to ensure the user always connects to the same web server that was initially chosen by the user, configure Persistence on the load balancer.

Persistence Methods – When the user first connects to a VIP, NetScaler uses its load balancing algorithm to select a web server. NetScaler then needs to store the chosen server’s identifier somewhere. Here are common storage methods:

Cookie – the chosen server’s identifier is saved on the client in a Cookie. The client includes the persistence Cookie in the next HTTP request, which lets NetScaler send the next HTTP Request to the same web server as before. Pros/Cons:
- No memory consumption on NetScaler
- Cookie can expire when the user’s browser is closed
- Each client gets a different Cookie, even if multiple clients are behind a common proxy.
- However, not all web clients support Cookies.
Source IP – NetScaler records the client’s Source IP into its memory along with the web server it chose using its load balancing algorithm. Pros/Cons:
- Uses NetScaler Memory
- If multiple clients are behind a proxy (or common outgoing NAT), then all of these clients go to the same web server. That’s because all of them appear to be coming from one IP address.
- Works with all web clients.
Rule-based persistence – use a NetScaler Policy Expression to extract a portion of the HTTP Request and use that for persistence. Ultimately, it works the same as Source IP, but it helps for proxy scenarios if the proxy includes the Real Client IP in one of the HTTP Request Headers (e.g. X-Forwarded-For).
Server Identifier – the HTTP Response from a web server instructs the web client to append a Server ID to every URL request. The NetScaler can match the Server ID in the URL with the web server. XenMobile uses this method.

Authentication and Cookie Security – If a web site requires authentication, it would be annoying if the user had to login again with every HTTP Request. Instead, most authenticated web sites return a Cookie, and that Cookie is used to authorize subsequent HTTP Requests from the same user/client/browser.

WAF Cookie Protection – Since the Web Session Cookie essentially grants permission, security of this Cookie is paramount. NetScaler Web App Firewall has several protections for Cookies.

HTML Forms

Get Data from user – if the web site developer wants to collect any data from a user (e.g. Search term, account login, shopping cart item quantity, etc.), then the web developer creates HTML code that contains a <form> element.

Form fields – Inside the <form> element are one or more form fields that let users enter data (e.g. Name, Quantity), or let users select an option (drop-down box).

Submit button – The last field is usually a Submit button.

Field names – Each of the fields in the form has its own name.

Field values – When a user clicks Submit, typically JavaScript on the client side ensures that the data was entered correctly. This is more about convenience than security. If users enter letters into a zip code field, JavaScript can immediately prompt the user for the correct format.

GET and POST – The data is then submitted to the web server using one of two methods: GET or POST.

With GET, each of the field names and field values is put in the Query Parameters portion of the URL (e.g. ?field1=value1&field2=value2), which is after the path and file name.
With POST, the HTTP Request Method (HTTP Command) is set to POST, and the field names and field values are placed in the Body of the HTTP Request.
The POST method is typically more secure because you can encrypt the Body using SSL/TLS. GET method puts the field values in the clear text URL and thus can’t be encrypted.

Web server validates HTML form data – When the web server receives the HTML form data, the web server must validate the input. Do not rely on client-side Javascript to validate the data. Instead, all HTML form data must be inspected by the web server for SQL Injection, Cross-site Scripting, etc.

NetScaler Web App Firewall (WAF) can do this inspection before the form data reaches the web server.
WAF can also validate the form fields. For example, NetScaler WAF can ensure that only numeric characters can be entered in a zip code field.

Web App Firewalls for HTML Forms – HTML Forms are the most sensitive feature in any web application. Web Developers must write their web server code in a secure manner. Use features like NetScaler Web App Firewall to provide additional protection.

WAF for JSON, XML – Other forms of submitting data to web servers, like JSON objects, XML documents, etc. should also be inspected. NetScaler Web App Firewall can do this too.

AJAX

AJAX – Another method Browsers use to communicate with Web Servers is AJAX (Asynchronous JavaScript)

JavaScript AJAX – JavaScript on the client side can send HTTP Requests to Web Servers. Web Servers send back a response in JSON or XML format.

JSON is JavaScript Object Notation – JavaScript scripts can create objects (similar to hash tables) using JSON notation. Curly braces surround the object. Each element is “name”:”value” pair. The values can be more JSONs. And values can be an array of values, including more JSONs. JSONs can be embedded within other JSONs. JSONs are very familiar to any JavaScript developer.

JSON vs XML –

JSON is smaller than XML. XML is marked up with human-readable tags, bloating the size. JSON contains data, curly braces, colons, quotes, and square brackets. That’s it. Very little of it is dedicated to markup so most of it is pure data.
Familiarity – Since JavaScript developers already know how to create JSONs, there’s nothing new to learn, unlike XML.

AJAX enables Single Page Applications (SPA) – JavaScript reads the contents of the response and uses it for any purpose. For example, JavaScript can use the data in the response to build a table in the webpage and display it to the user. This allows data on the page to change dynamically without requiring a full page reload.

REST API

Commercial systems have a programmatically-accessible API (Application Programming Interface) that allows programs to control a remote system. Some API commands retrieve information from the system. Other API commands invoke actions (e.g. create object) in the system.

Use HTTP to call API functions – Modern APIs can be activated using the HTTP Protocol. Create a specially-crafted HTTP Request and send it to an HTTP endpoint that is listening for API requests.

SOAP Protocol – Older HTTP-based APIs operate by exchanging XML documents. This is called SOAP (Simple Object Access Protocol). However, XML documents are difficult to program, and the XML tags consume bandwidth.

REST API – Another newer HTTP-based architecture is to use all of the HTTP Methods (GET, POST, PUT, DELETE), and exchange JSON documents. JSON is leaner than XML.

NetScaler Nitro API is a REST API.

REST is stateless. All information needed to invoke the API must be included in one HTTP Request.

Web Browsers typically only use GET and POST in their HTTP Requests. But there are other HTTP Methods like PUT and DELETE.

Programs other than browsers can use the HTTP protocol – Web Browsers are not the only programs that can make HTTP Requests. Every computer language has some mechanism for creating a HTTP Request and processing the HTTP Response. Non-browser Programs can use the HTTP Methods PUT and DELETE.

REST is HTTP.

A REST-capable client is any client that can send HTTP Requests and process HTTP Responses. Some languages/clients have REST-specific functions. Others have only lower level functions for creating raw HTTP Requests.
On Linux, use curl to send HTTP Requests to an HTTP-based API.
In PowerShell, use Invoke-RestMethod to send an HTTP Request to an HTTP-based API.
Inside a browser, use Postman or other REST plug-in to craft HTTP Requests and send them to an HTTP-based API.

To invoke an HTTP REST-based API:

HTTP Request to login – Send an HTTP Request with user credentials. The exact login URL or session creation URL is in the API documentation.
Session Cookie – The REST API server sends back a Session Cookie that can be used for authorization of subsequent REST/HTTP Requests. The REST Client saves the cookie, and adds it to every subsequent REST/HTTP Request.
Read API Documentation – Use the API’s documentation to find the URLs and HTTP Methods (Commands) to invoke the API.
Content-Type – Some REST API Requests require a specific Content-Type to be specified in the HTTP Request Header. Add it to the HTTP Request that you’re creating.
JSON Object in Request – Most REST API Requests require a JSON object to be submitted in the HTTP Body. Use the language’s functions to craft a JSON object that contains the parameters that need to be sent to the API Call.
URL Query portion – Some REST API Requests require parameters to be specified in the query portion of the URL.
Send HTTP Request – Create the full HTTP Request with HTTP Method, URL, URL Parameters, Content-Type Header, Cookie Header, and JSON Body. Send it to the HTTP REST server endpoint.
Process Response, including JSON – The REST API sends back a HTTP 200 success message with a JSON document. Or it sends back an error message, typically with error details in an attached JSON document.

NetScaler VPN Networking

IP Pools

SNIP vs IP Pool (Intranet IPs) – By default, when a NetScaler VPN Tunnel is established, a NetScaler SNIP is used as the Source IP for all traffic that leaves the NetScaler to internal Servers. The internal Servers then simply reply to the SNIP. Instead of all VPN Clients sharing a single SNIP, you can configure IP Pools (aka Intranet IPs), where each VPN Client gets its own IP address.

Use IP Pools if Servers initiate communication to clients – if servers initiate communication to VPN Clients (IP Phones, SCCM, etc.), then each VPN Client needs its own IP address. This won’t work if all VPN Clients are sharing a single SNIP.

Intranet IPs assignment – Intranet IPs can be assigned to the Gateway vServer, which applies to all users connected to that Gateway vServer. Or you can apply a pool of IPs to a AAA Group, which allows you to assign different IP Pools (IP subnets) to different AAA Groups.

IP Pools and Network Firewall – If different Pools for different AAA Groups, then a network firewall can control which destinations can be reached from each of those IP Pools.

Intranet IP Subnet can be brand new – the IP subnets chosen for VPN Clients can be brand new IP Subnets that the NetScaler is not connected to. NetScaler is a router, so there’s no requirement that the IP addresses assigned to the VPN Clients be on one of the NetScaler’s data (VIP/SNIP) interfaces.

Reply traffic from Servers to Intranet IPs – If the Intranet IP Pool is a new IP Subnet, then on the internal network (core router), create a static route with the IP Pool as destination, and a NetScaler SNIP as Next Hop. Any SNIP on the NetScaler can reach any VPN Client IP address.

IP Spillover – if there are no Intranet IPs (IP Pool) available, then a VPN Client can be configured to do one of the following: use the SNIP, or transfer an existing session’s IP. This means that a single user can only have a single Intranet IP from a single client machine.

Split Tunnel

Split Tunnel – by default, all traffic from the VPN Client is sent across the VPN Tunnel. For high security environments, this is usually what you want, so the datacenter security devices can inspect the client traffic. Alternatively, Split Tunnel lets you choose which traffic goes across the tunnel, while all other client traffic goes out the client’s normal network connection (directly to the Internet).

Split Tunnel is enabled in a Session Policy/Profile – the Session Policy/Profile can be bound to the Gateway vServer, which affects all VPN users, or it can be bound to a AAA Group.

Intranet Applications define traffic that goes across the Tunnel – If Split Tunnel is enabled, then you must inform the VPN Client which traffic goes across the Tunnel, and which traffic stays local. Intranet Applications define the subnets and port numbers that go across the Tunnel. The Intranet Applications configuration is downloaded to the VPN Client when the Tunnel is established.

Intranet Applications – Route Summarization – If Split Tunnel is enabled, a typical configuration is to use a summarized address for the Intranet Applications. Ask your network team for the smallest number of network prefixes that matches all internal IP addresses. For example, every private IP address (RFC 1918) can be summarized by three route prefixes. The summarized Intranet Applications can then be assigned to all VPN Clients. Most networking training guides explain route summarization in detail.

Intranet Applications – Specific Destinations – Alternatively, you can define an Intranet Application for every single destination Server IP and Port. Then bind different “specific” Intranet Applications to different users (AAA Groups). Note: this option obviously requires more administrative effort.

Split DNS – If Split Tunnel is enabled, then Split DNS can be set to Remote, Local, or Both. Local means use the DNS servers configured on the Client. Remote means use the DNS Servers defined on the NetScaler. Both will check both sets of DNS Servers.

VPN Authorization

There are three methods of controlling access to internal Servers across the VPN Tunnel – Authorization Policies, Network Firewall (usually with Intranet IPs), and Intranet Applications (Split Tunnel).

Authorization Policies control access no matter how the VPN Tunnel is established. These Policies use NetScaler Policy Expressions to select specific destinations and either Allow or Deny. In NetScaler 11.1 and older, Authorization Policies use Classic Policy Expressions only, which has a limited syntax. In NetScaler 12 and newer, Authorization Policies can use Default Syntax Policy Expressions, allowing matching of traffic based on a much broader range of conditions.

Intranet Applications – If Split Tunnel is enabled, then Intranet Applications can be used to limit which traffic goes across the Tunnel. If the Intranet Applications are “specific”, then they essentially perform the same role as Authorization Policies. If the Intranet Applications are “summarized”, then you typically combine them with Authorization Policies.

Network firewall (IP Pools) – If Intranet IPs (IP Pools) are defined, then a network firewall can control access to destinations from the VPN Client IPs. If Intranet IPs are not defined, then the firewall rules apply to the SNIP, which means every VPN Client has the same firewall rules.

VPN Tunnel Summary

In Summary, to send traffic across a VPN Tunnel to internal servers, the following must happen:

If Split Tunnel is enabled, then Intranet Applications identify traffic that goes over the VPN tunnel. Based on Destination IP/Port.
Authorization Policies define what traffic is allowed to exit the VPN Tunnel to the internal network.
Static Routes for internal subnets – to send traffic to a server, the NetScaler needs a route to the destination IP. For VPN, NetScaler is usually connected to both DMZ and Internal, with the default route (default gateway) on the DMZ. To reach remote internal subnets, you need static routes.
Network Firewall must allow the traffic from the VPN Client IP – either SNIP, or Intranet IP (IP Pool).
Reply traffic – If the VPN Client is assigned an IP address (Intranet IPs aka IP Pool), then server reply traffic needs to route to a NetScaler SNIP. On the internal network, create a default route with IP Pool as destination, and a NetScaler SNIP as Next Hop.

PXE

Network Boot and PXE

Network Boot – Network Boot allows machines to download a bootstrap from a TFTP server while the machine is still in BIOS boot mode. No Operating System needed on the local hard drives.

PXE (Pre-boot Execution Environment) – PXE is a mechanism for Network Boot machines to discover the location of the bootstrap file. PXE is based on the DHCP protocol.

Get IP from DHCP – Before a machine can perform a Network Boot, it needs an IP address, which is provided by DHCP.
Discover TFTP Server address – Then the machine needs to discover the IP address of the TFTP Server, and the name of the bootstrap file that should be downloaded from the TFTP Server. PXE uses DHCP Protocol to perform this discovery.

Network Boot without PXE – You can also Network Boot without PXE by booting from an ISO file or local hard drive that has just enough code on it to get the rest of the bootstrap from the TFTP server. DHCP is still usually used to get an IP address, but the IP address of the TFTP server is usually burned into this locally accessible code.

NICs and PXE – Network cards (NICs) need Network Boot capability built into their BIOS. Almost every NIC, including virtual machine NICs, has this capability. A notable exception is Hyper-V Synthetic NICs; Hyper-V Legacy NIC can Network Boot, but Hyper-V Synthetic NICs cannot.

PXE works as follows:

Boot from network – A machine’s BIOS is configured to boot from the Network.
DHCP Request to get IP – The NIC performs a DHCP Request to get an IP address.
PXE Request to get TFTP info – The NIC performs a PXE Request to get the TFTP IP address and file name.
Download from TFTP – The NIC downloads the bootstrap file from the TFTP server and runs it.
Run the bootstrap – The bootstrap file usually downloads additional files from a server machine (e.g. Citrix Provisioning Server) and runs them.

PXE vs DHCP

DHCP Options 66 and 67 – During step 2, if the NIC receives DHCP Options 66 and 67, which contain the TFTP Server’s IP address and file name, then there’s no need to perform step 3.

PXE Request to UDP 4011 – During step 3, the NIC performs another DHCP Request, but this time on port UDP 4011. A PXE Service listening on UDP 4011 responds with DHCP Options 66/67.

DHCP and PXE are different port numbers – A PXE Service can run on the same server that is running a DHCP Service because they listen on different port numbers. But typically, PXE Service and DHCP Service are on different servers.

PXE = DHCP Protocol – PXE Service uses the DHCP Protocol, which means the NIC performs a Layer 2 Broadcast, which does not cross a router. Many routers do not forward UDP 4011 to a remote PXE Service.

PXE Request does not cross routers – Thus Step 3 usuallly only works in the Network Boot client and the PXE Service are on the same subnet. If they are on different subnets, then use DHCP Options 66/67 instead.

TFTP Redundancy

DHCP Option 66 can only point to a single TFTP Server IP Address. You usually want redundancy.

NetScaler Load Balancing of TFTP – Use NetScaler to load balance two or more TFTP Servers and configure DHCP Option 66 to point to the NetScaler Load Balancing VIP.

DNS Round-Robin – Option 66 can point to a DNS Round Robin-enabled DNS name, where the single DNS name resolves to both TFTP Servers’ IP addresses. This assumes the DHCP Client receives DNS Server information from the DHCP Server.

Separate Option 66 configured on each DHCP Server – If you have multiple DHCP Servers, each DHCP Server can send back a different Option 66 TFTP Server IP address.

Network Boot Clients and PXE on same subnet – If Network Boot clients and PXE Services are on the same subnet, then each PXE Service can send back a different TFTP Server IP address. Either PXE Service can respond to the PXE Request, so if one is down, the other will respond.

Citrix Provisioning Services and PXE

How Citrix Provisioning Services (PvS) uses PXE:

TFTP Server is installed on each PvS server.
PXE Service can be enabled on each PvS server.
PvS can create a Boot ISO that has the TFTP Server IP addresses built into them.
- Note: The Boot ISO uses a different TFTP Service than normal PXE. Normal TFTP is UDP 69, while the Boot ISO connects a TFTP service called Two-stage Boot TFTP Service that is listening on UDP 6969.
PvS can burn boot code into a hard disk attached to a Network Boot machine. This works the same as the Boot ISO method.
A DHCP Service (typically Microsoft) can be installed on the PvS servers. DHCP Service and PXE Service are two different things.

NetScaler GSLB

GLSB Overview

GSLB is only useful if a single DNS name can resolve to multiple IP addresses. If this is not the case, then it would be easier to just leave the single DNS name / single IP on regular DNS.

Limitations of DNS Servers when a single DNS name resolves to multiple IP addresses:

The DNS Server doesn’t care if the IP address is reachable or not. There’s no monitoring.
The DNS Server doesn’t know which IP address is closest to the user. There’s no proximity load balancing.
The DNS Server can’t do site persistence, so you could get a different IP address every time you perform the DNS Query.

NetScaler GSLB is a DNS Technology that addresses these limitations. When you enable NetScaler GSLB, you enable your NetScaler appliances to resolve DNS Names. In other words, NetScaler appliances are essentially DNS Servers.

DNS names must be delegated to NetScaler DNS listeners. There are a few methods of doing this delegation:

In the existing DNS zone, delegate specific DNS names to NetScaler DNS. Each DNS name needs a separate delegation.
In the existing DNS zone, delegate an entire sub-zone (e.g. gslb.company.com) to NetScaler DNS. Then create CNAMEs for each DNS name that are alias’d to an equivalent DNS name in the sub-zone. For example: www.company.com is CNAME’d to www.gslb.company.com. Since the gslb.company.com sub-zone is delegated to NetScaler DNS, NetScaler will resolve this DNS name.
Move the entire existing DNS zone to NetScaler. Note: NetScaler was never designed as a full-fledged DNS Service, so you might find limitations when choosing this option.

For redundancy, configure multiple NetScaler appliances/pairs for DNS delegation – At least two NetScaler appliances/pairs should be configured for DNS services. Delegate DNS names or subzones to two different NetScaler appliances/pairs.

GSLB Configuration must be identical – Since it’s not possible to control which NetScaler appliance/pair resolves the DNS name, all NetScaler appliance/pairs must have identical GSLB configuration, so the DNS responses are always the same no matter which NetScaler appliance/pair resolves the DNS name.
GSLB Sync – One NetScaler appliance/pair can replicate its GSLB configuration to another NetScaler appliance/pair. The sync communication protocol is SSH.
GSLB Metric Exchange Protocol (MEP) – multiple GSLB-enabled appliances/pairs are configured to communicate with each other using a proprietary Metric Exchange Protocol. This communication is used for several purposes: Dynamic Proximity load balancing, Monitoring, and Persistence. These are detailed below.

Active/Passive – NetScaler GSLB can do active/passive, where the Active IP is given out if it is UP, and the Passive IP is given out if the Active IP is down. NetScaler needs to monitor the Active IP to verify it is reachable.

Active/Active – NetScaler GSLB can do active/active, where it load balances users across multiple Active IPs. A common load balancing algorithm is based on the client’s proximity to the Active IP; give out the Active IP that is closest to the user.

Active/Active can be combined with Passive so that if all Active IPs are down, then give out the Passive IP.

Proximity Load Balancing Methods – there are two Proximity Methods:

Static Proximity uses a location database stored on the appliance. The Source IP of the DNS Query is looked up in the location database to determine coordinates. The Active IPs are also looked up in the location database to determine coordinates. The coordinates are compared to determine which Active IP is closer to the Source IP. NetScaler has a built-in static proximity location database that you can use.
Dynamic Proximity asks each NetScaler (through MEP) to ping the Source IP of the DNS Query to determine which ping is fastest.

Recursive DNS and Client IP – DNS Clients use Recursive DNS Servers to resolve DNS names. The Source IP of a DNS Query sent to NetScaler is the Recursive DNS Server’s IP Address, and not the actual DNS Client’s IP Address. Thus all proximity calculations are based on the IP address of the Recursive DNS Server and not the actual client. The Recursive DNS Servers are sometimes called Local DNS Servers (LDNS).

ECS (EDNS-Client-Subnet) – Recursive DNS Servers can use the EDNS0 field on a DNS Request to include the client’s subnet. GSLB can then perform proximity calculations against ECS instead of against the Recursive DNS Server’s IP Address, thus improving accuracy. ECS functionality for GSLB is available in NetScaler 11.1 and newer.

GSLB Monitoring – GSLB has two methods of determining if an Active IP is up or not:

MEP Monitoring – If the Active IP is a VIP on one of the NetScalers connected by MEP, then use MEP to ask the NetScaler for the UP/DOWN status of the VIP.
Use regular Load Balancing Monitors – bind Load Balancing Monitors to the GSLB Service (Active IP). Monitors bound to a GSLB Service override MEP monitoring.

Monitoring of Internet circuits – If your Active IPs are Public IPs, then you don’t want to give out a Public IP if the IP is not reachable because the Internet circuit is down. There are a couple methods of monitoring the accessibility of an Internet circuit:

Route MEP through the Internet – If the remote site’s Internet goes down, then MEP goes down, and the Active IPs in that remote site go down.
Monitor a site-specific public IP address – Attach a monitor to the GSLB Service that monitors a public IP in the remote site. You probably have to specify the public IP inside the monitor configuration.
Monitor local Internet? – If the appliance’s local Internet goes down, then it’s probably not a problem, because DNS Requests/Queries aren’t making it to this appliance anyways. It’s more important for the other NetScalers to determine Internet accessibility in this datacenter.

GSLB DNS TTL – TTLs (time-to-live) for GSLB DNS Responses is usually 5 seconds. Thus every 5 seconds, a DNS Client needs to resolve the GSLB DNS Name again. This allows for quick changes if an Active IP address is no longer reachable.

Browsers have their own DNS cache that ignores the DNS TTL. For example, Internet Explorer tends to cache DNS responses for 30 minutes. In a GSLB failover scenario (Active IP is down), then the users will have to close all IE windows to clear the browser’s DNS cache.

Site Persistence – because of the low TTL, it’s quite possible that a new DNS Query can return a different IP than the initial DNS Query. Some applications require you to always get the same IP address for a period of time. This is similar to Load Balancing Persistence needed for Web Sessions.

GSLB Site Persistence – GSLB has three methods of Site Persistence:

Source IP – records DNS Query’s Source IP to GSLB Active IP in the NetScaler’s memory. If Source IP is the Recursive DNS Server, then many clients might end up with the same Active IP response. Accordingly, Source IP persistence is usually not recommended unless Cookie Persistence is not an option. Note: ECS in NetScaler 11.1 can be used for Source IP persistence.
Cookie Persistence – For Active IPs that are HTTP VIPs on one of the NetScaler appliance/pairs connected by MEP, the first HTTP Response from the NetScaler VIP will include a cookie indicating which GSLB Site the Response came from. The HTTP Client will include this Site Cookie in the next HTTP Request to the VIP. If the DNS TTL expires (5 seconds), then DNS Query must be performed again. If the client gets a different IP address in a different GSLB Site, then the Site Cookie sent to that NetScaler will be for a different GSLB Site than the VIP it’s now trying to access. NetScaler has two options for getting the HTTP Request from the wrong VIP to the correct VIP:
- Redirect – redirect the user to a different DNS name that is site-specific (a Site Prefix is added to the original DNS name). This requires the certificate to match the original GSLB-enabled DNS name, plus the new site-specific DNS name.
- Proxy – proxy the HTTP Request to the correct GSLB Site. This means that NetScaler in the wrong GSLB Site must be able to forward the HTTP Request to the VIP in the correct GSLB Site.

GSLB is not in the data path – GSLB is nothing more than DNS: it resolves DNS names to IP addresses. Once the Client has the IP address, it creates a TCP connection directly to that IP address, and GSLB is no longer involved.

GSLB Site Persistence cookies – since GSLB = DNS, and not HTTP, it’s not possible to include an HTTP Cookie in the DNS Response. The HTTP Cookie isn’t added until the the HTTP Client makes its first request to an HTTP/SSL VIP on one of the NetScaler appliances/pairs that is participating in GSLB.

Other GLSB Use Cases

GSLB and Multiple Internet Circuits – a common use case for GSLB is if you have multiple Internet circuits connected to a single datacenter and each Internet circuit has a different public IP subnet. In this scenario, you have one DNS name, and multiple public IP addresses, which is exactly the scenario that GSLB is designed for.

Local Internet Circuit Monitoring – GSLB Services need a monitor that can determine if the local Internet is up or not. You don’t want to give out a Public IP on a particular Internet circuit if the local Internet circuit is down. You typically configure the GSLB Monitor to ping a circuit-specific IP address (router).

Internal GSLB – GSLB can also be used internally to give out internal IPs to DNS queries. However, there are a couple differences when compared to public IPs:

Private IPs are not in the location database. If doing static proximity load balancing, you must manually add each internal subnet to the location database.
Internal IPs are not affected by Internet outage. Thus GSLB monitoring for internal Active IPs is usually configured differently than GSLB monitoring for public Active IPs.

Mix internal and public GSLB on the same appliance? – Since internal and public have different GSLB monitoring configurations, you need separate GSLB configurations for internal and public. However, you can’t assign the same DNS name to two different GSLB configurations. Here are three options:

Use different DNS names for public and internal.
Don’t use the same NetScaler for both public and internal.
Configure internal DNS to CNAME to a different internal DNS name.

↧

NetScaler Gateway 12 Native One Time Passwords (OTP)

July 27, 2017, 1:16 pm

≫ Next: NetScaler Gateway 12 – PCoIP Proxy

≪ Previous: NetScaler Essential Concepts: Part 2 – Certificates/SSL, Authentication, HTTP, VPN Networking, PXE, GSLB

Navigation

Overview

NetScaler 12 Native OTP lets you enable two-factor authentication without purchasing any other authentication product. A typical configuration uses Google Authenticator to generate Passcodes. See the following for an overview:

YouTube video NetScaler Unified Gateway One Time Password
Citrix Blog Post NetScaler Unified Gateway Provides One Time Password (OTP), Natively

Here are some notes:

NetScaler Native OTP is part of nFactor, and thus requires NetScaler Enterprise Edition or NetScaler Platinum Edition licensing.
- Receiver currently does not support nFactor authentication. Thus only web browsers can authenticate using Native OTP.
nFactor requires a AAA vServer, which can be non-addressable – you don’t need any additional public IPs.
OTP stores device enrollment secrets in an Active Directory attribute that accepts Strings. Citrix’s documentation uses the userParameters Active Directory attribute.
- The LDAP bind account must have permission to modify this attribute on every user.
Users can enroll multiple devices. There’s no way to prevent this.
The manageotp website is usually only protected by single factor authentication. Since users can add multiple devices, the manageotp website must be protected from external access.

Here are the OTP configuration objects:

An LDAP Policy/Server with authentication disabled and OTP Secret configured. This one OTP-specific LDAP Policy/Server can be used for two scenarios:
- manageotp device enrollment
- Two-factor authentication to NetScaler Gateway after a device has been enrolled. This LDAP Policy/Server verifies that the entered passcode.
An LDAP Policy/Server with authentication enabled. This one policy is used for two scenarios:
- Single-factor authentication to the manageotp authenticator/device enrollment website.
- Two-factor authentication to NetScaler Gateway after a device has been enrolled.
A single non-addressable AAA vServer with two Login Schemas for the following scenarios:
- A single-factor Login Schema for manageotp.
- A dual-factor Login Schema for NetScaler Gateway authentication.
An Authentication Profile to link the AAA vServer to the NetScaler Gateway vServer.

LDAP Policies/Actions

Go to Security > AAA – Application Traffic > Polices > Authentication > Advanced Policies > Actions > LDAP.
On the right, click Add.
Create a normal LDAP Server if you don’t have one already. This one has Authentication enabled. This LDAP Policy/Server will be used for single-factor authentication to the manageotp website, and for dual-factor authentication to NetScaler Gateway. There are no special instructions for this LDAP Server.
Create another LDAP Action.
This one will be for OTP management and authentication so name it accordingly.
On the right, uncheck the box next to Authentication. If you don’t uncheck it, you will see an error message after configuring the OTP Secret.
Make sure the Administrator Bind DN has permissions to modify the OTP Secret Active Directory attribute for all users.
Configure the Server Logon Name Attribute to match the one you configured in the normal authentication LDAP Server.
In the Other Settings section, on the bottom right, find the OTP Secret field. Enter the name of the Active Directory attribute where NetScaler will store the user’s OTP secret. You can use the userParameters attribute if that attribute isn’t being used for anything else.
Click Create when done.
Go to Security > AAA – Application Traffic > Policies > Authentication > Advanced Policies > Policy.
On the right, click Add.
You probably don’t already have an Advanced Authentication Policy for your normal LDAP server.
Change the Action Type to LDAP.
Select your normal LDAP server, which is the one that has Authentication enabled.
Enter true as the expression. This uses Default Syntax instead of Classic Syntax.
Click Create.
Create another Authentication Policy.
This policy is for OTP so name it accordingly.
Change the Action Type to LDAP.
Select the LDAP Server that has Authentication disabled and OTP Secret configured.
Enter true in the Expression box, and click Create.

Login Schemas

Go to Security > AAA – Application Traffic > Login Schema.
On the right, switch to the Profiles tab, and click Add.
This is the single factor Login Schema for manageotp so name the Schema accordingly.
Click the Edit icon.
On the left, click the LoginSchema folder to open it.
Scroll down, and click SingleAuthManageOTP.xml to highlight it.
On the top right, click Select.
Click Create.
Add another Login Schema profile.
This Login Schema is for two-factor authentication to NetScaler Gateway so name it accordingly.
Click the edit icon. Follow the same procedure as above, but this time select /LoginSchema/DualAuth.xml.
Click More to reveal more options.
Scroll down. In the Password Credential Index field, enter 1. This causes nFactor to save the user’s password into Attribute #1, which we’ll use later in a Traffic Policy to Single Sign-on to StoreFront. If you don’t do this, then NetScaler Gateway will try to use the Passcode to authenticate to StoreFront, which obviously won’t work.
Click Create.
On the right, switch to the Policies tab.
In the Profile field, select the Single Factor Manage OTP Login Schema Profile.
Name the Login Schema Policy for OTP management.
In the Rule field, enter the following. This ensures that this single factor Login Schema is only used if the user enters /manageotp, and if the user is on the internal network. You don’t want manageotp to be accessible externally, because it’s only protected by single factor authentication, and it’s too easy to add multiple devices.
```
http.req.cookie.value("NSC_TASS").eq("manageotp") && client.IP.SRC.IN_SUBNET(10.2.0.0/16)
```
Click Create.
Create another Login Schema Policy.
In the Profile field, select the dual factor Login Schema.
Name the Login Schema to indicate dual factor authentication.
In the Rule box, enter true.
Click Create.

Authentication PolicyLabel

Go to Security > AAA – Application Traffic > Policies > Authentication > Advanced Policies > PolicyLabel.
On the right, click Add.
This PolicyLabel is for OTP management, and OTP authentication, so name it accordingly.
In the Login Schema field, select LSCHEMA_INT, which means noschema.
Click Continue.
In the Policy Binding section, Click to select.
Click the circle button next to the LDAP Policy that has authentication disabled, and OTP Secret configured. Click Select.
Click Bind.
Click Done.

AAA vServer

Go to Security > AAA – Application Traffic.
If the AAA feature is not enabled, then right-click the AAA node, and click Enable Feature.
Go to Security > AAA – Application Traffic > Virtual Servers.
On the right, click Add.
This AAA vServer is for OTP so name it accordingly.
Change the IP Address Type to Non Addressable.
Click OK.
Click where it says No Server Certificate.
Click to Select.
Click the circle next to a certificate, and click Select. You can use the same certificate as NetScaler Gateway.
Click Bind.
Click Continue.
Click where it says No Authentication Policy.
Click to select.
Click the circle next to the normal LDAP Policy that has authentication enabled. Then click Select.
In the Select Next Factor field, Click to select.
Click the circle next to the OTP PolicyLabel, and click Select.
Click Bind.
In the Advanced Authentication Policies section, click Continue.
On the right, in the Advanced Settings column, click Login Schemas.
On the left, scroll down, and click where it says No Login Schema.
Click to select.
Click the circle next to the Manage OTP Login Schema, and click Select.
Click Bind.
Click where it says 1 Login Schema.
Click Add Binding.
Click to select.
Click the circle next to the dual factor Login Schema, and click Select.
Click Bind.
Make sure the single factor Manage OTP Login Schema is higher in the list than the dual factor Login Schema. Click Close.
On the right, in the Advanced Settings column, click Portal Themes.
On the left, scroll down, select RfWebUI as the Portal Theme, and click OK.
Click Done.

Traffic Policy for Single Sign-on

On the left, go to NetScaler Gateway > Policies > Traffic.
On the right, switch to the Traffic Profiles tab, and click Add.
This Traffic Profile is for OTP and/or nFactor. Name it accordingly.
Scroll down.
In the SSO Password Expression box, enter the following. This is where we use the Login Schema Password Attribute specified earlier.
```
http.REQ.USER.ATTRIBUTE(1)
```
Click Create.
On the right, switch to the Traffic Policies tab, and click Add.
Click the blue link to Switch to Default Syntax.
In the Request Profile field, select the Traffic Profile you just created.
Name the Traffic Policy.
In the Expression box, enter true.
Click Create.

NetScaler Gateway and Authentication Profile

Go to NetScaler Gateway > Virtual Servers.
Edit an existing Gateway vServer. If you don’t have one, see the other NetScaler Gateway topics on this site.
Scroll down to the Policies section, and click the plus icon.
Change the Choose Policy drop-down to Traffic, and click Continue.
Click to select.
Click the circle next to the Traffic Policy you created earlier, and click Select.
Click Bind.
On the right, in the Advanced Settings column, click Authentication Profile.
On the left, scroll down to the Authentication Profile section.
Click the plus icon to create one.
Authentication Profile links the NetScaler Gateway vServer with the OTP AAA vServer, so name it accordingly.
In the Authentication Virtual Server section, Click to select.
Click the circle next to the OTP AAA vServer, and click Select.
Click Create.
Scroll down again to the Authentication Profile section, and click OK.
The Portal Theme bound to the Gateway vServer should be RfWebUI, or a derivative.
Go to System > Profiles.
On the right, switch to the SSL Profile tab.
Edit the ns_default_ssl_profile_frontend profile.
Make sure HSTS is not enabled in the profile, or RfWebUI, and manageotp won’t work correctly. This is probably a bug. Note: the Rewrite method of enabling HSTS should work.

Manageotp

Point your browser to https://mygateway.corp.com/manageotp or similar. Simply add /manageotp to the end of your Gateway URL.
Notice it’s only single-factor authentication. Login using normal LDAP credentials.
Click Add Device.
Enter a device name, and click Go.
Launch the Google Authenticator application on your phone. Click the plus icon in Google Authenticator, and scan the QRCode that is shown on the screen.
Click Test.
Enter the passcode shown in Google Authenticator, and click Go.
If you logoff of manageotp, and access your Gateway URL normally, you’ll be prompted for two-factor authentication. Use the passcodes shown in your Google Authenticator application.
It should Single Sign-on into StoreFront.

CLI Commands

Here’s a complete CLI configuration.

add ssl certKey WildcardCorpCom -cert WildcardCorpCom.pfx -key WildcardCorpCom.pfx -inform PFX -passcrypt "abc"
add authentication ldapAction LDAP-Corp -serverIP 10.2.2.11 -serverPort 636 -ldapBase "dc=corp,dc=local" -ldapBindDn ctxsvc@corp.local -ldapBindDnPassword 8f689826 -encrypted -encryptmethod ENCMTHD_3 -ldapLoginName sAMAccountName -groupAttrName memberOf -subAttributeName cn -secType SSL -passwdChange ENABLED
add authentication ldapAction LDAP_OTP_no_auth -serverIP 10.2.2.11 -serverPort 636 -ldapBase "dc=corp,dc=local" -ldapBindDn admin@corp.local -ldapBindDnPassword cab1f2ef -encrypted -encryptmethod ENCMTHD_3 -ldapLoginName sAMAccountName -groupAttrName memberOf -subAttributeName cn -secType SSL -authentication DISABLED -OTPSecret UserParameters
add authentication Policy Corp-Adv -rule true -action LDAP-Corp
add authentication Policy LDAP_Manage_OTP-pol -rule true -action LDAP_OTP_no_auth

add authentication loginSchema Dual_OTP-lschema -authenticationSchema "/nsconfig/loginschema/LoginSchema/DualAuth.xml" -passwordCredentialIndex 1
add authentication loginSchema Single_Manage_OTP-lschema -authenticationSchema "/nsconfig/loginschema/LoginSchema/SingleAuthManageOTP.xml"
add authentication loginSchemaPolicy Single_Manage_OTP-lschemapol -rule "http.req.cookie.value(\"NSC_TASS\").eq(\"manageotp\") && client.IP.SRC.IN_SUBNET(10.3.0.0/16)" -action Single_Manage_OTP-lschema
add authentication loginSchemaPolicy Dual_OTP-lschemapol -rule true -action Dual_OTP-lschema

add authentication policylabel OTP_pollabel -loginSchema LSCHEMA_INT
bind authentication policylabel OTP_pollabel -policyName LDAP_Manage_OTP-pol -priority 100 -gotoPriorityExpression NEXT 

add authentication vserver OTP-AAA SSL 0.0.0.0
bind ssl vserver OTP-AAA -certkeyName WildcardCorpCom

bind authentication vserver OTP-AAA -portaltheme RfWebUI
bind authentication vserver OTP-AAA -policy Single_Manage_OTP-lschemapol -priority 100 -gotoPriorityExpression END
bind authentication vserver OTP-AAA -policy Dual_OTP-lschemapol -priority 110 -gotoPriorityExpression END
bind authentication vserver OTP-AAA -policy Corp-Adv -priority 100 -nextFactor OTP_pollabel -gotoPriorityExpression NEXT

add vpn trafficAction OTP-trafficprofile http -passwdExpression "http.REQ.USER.ATTRIBUTE(1)"
add vpn trafficPolicy OTP-trafficpol true OTP-trafficprofile

add authentication authnProfile OTP-authnprofile -authnVsName OTP-AAA

add vpn vserver Gateway.corp.com SSL 10.2.5.220 443 -downStateFlush DISABLED -Listenpolicy NONE -authnProfile OTP-authnprofile
set ssl vserver Gateway.corp.com -sslProfile ns_default_ssl_profile_frontend
add vpn sessionAction "Receiver For Web" -transparentInterception OFF -defaultAuthorizationAction ALLOW -SSO ON -icaProxy ON -wihome "https://storefront2.corp.com/Citrix/StoreWeb" -ntDomain corp.local -clientlessVpnMode OFF -storefronturl "https://storefront2.corp.com"
add vpn sessionPolicy "Receiver For Web" "HTTP.REQ.HEADER(\"User-Agent\").CONTAINS(\"CitrixReceiver\").NOT" "Receiver For Web"
bind vpn vserver Gateway.corp.com -portaltheme RfWebUI
bind vpn vserver Gateway.corp.com -policy "Receiver For Web" -priority 100 -gotoPriorityExpression NEXT -type REQUEST
bind vpn vserver Gateway.corp.com -policy OTP-trafficpol -priority 100 -gotoPriorityExpression END -type REQUEST
bind ssl vserver Gateway.corp.com -certkeyName WildcardCorpCom

↧

NetScaler Gateway 12 – PCoIP Proxy

July 30, 2017, 8:45 am

≫ Next: NetScaler Gateway 12 – StoreFrontAuth, and XenDesktop Wizard

≪ Previous: NetScaler Gateway 12 Native One Time Passwords (OTP)

Navigation

Overview

NetScaler Gateway 12.0 supports the PC-over-IP (PCoIP) protocol, which is the remote display protocol for several non-Citrix VDI solutions, including VMware Horizon View. PCoIP is analogous to Citrix HDX/ICA protocol, and Microsoft RDP protocol. PCoIP uses UDP port 4172.

VMware Blast is currently not supported

When PCoIP is proxied through NetScaler Gateway, NetScaler Gateway can replace the traditional PCoIP remote access solutions, like View Security Server, or VMware Access Point.

Prerequisites

NetScaler Version – NetScaler 12.0 or newer.
- Build 51 and newer for NAT
NetScaler Edition – PCoIP Proxy is available in all NetScaler Editions
Universal Licenses – PCoIP Proxy uses the Clientless Access feature of NetScaler Gateway, which means every NetScaler Gateway connection must be licensed for NetScaler Gateway Universal. On the NetScaler Gateway Virtual Server, ensure ICA Only is unchecked.
Horizon View infrastructure – A functioning internal Horizon View infrastructure. Ensure you can connect to Horizon View Agents internally without NetScaler Gateway.
- Ensure that the Horizon View HTTP(S) Secure Tunnel and PCoIP Secure Gateway are not enabled on the Horizon View Connection Servers that NetScaler will proxy connections to.
- Configure Desktop Pools and RDS Farms to use PCoIP as the default protocol.
Firewall Ports:
- TCP 4172, UDP 4172, and TCP 443 open from Horizon View Clients to the NetScaler Gateway VIP.
- TCP 4172, and UDP 4172 open from the NetScaler SNIP to all internal Horizon View Agents.
Certificate – A valid certificate for the NetScaler Gateway Virtual Server.
Authentication – An LDAP authentication policy/server.
Unified Gateway (optional) – If Unified Gateway, create the Unified Gateway before adding PCoIP functionality.
RfWebUI Portal Theme – For web browser access to Horizon View, the NetScaler Gateway Virtual Server must be configured with the RfWebUI theme.
Horizon View Client – The Horizon View Client must be installed on the client device, even if accessing Horizon published icons using the NetScaler RfWebUI portal.

PCoIP Profile

To create the PCoIP Profile:

In the NetScaler management GUI, navigate to Configuration> NetScaler Gateway> Policies> PCoIP.
On the right, in the PCoIP Profiles and Connections pane, you will create a VServer profile and a PCoIP profile.
To create a VServer profile, on the VServer Profiles tab, click Add.
1. Enter a name for the VServer profile. The only point of the VServer Profile is to specify the Active Directory domain name so name it accordingly.
2. Enter an Active Directory Domain Name that will be used for Single Sign-on to Horizon View Connection Server, and then click on Create.
3. Note: only a single Active Directory domain is supported per NetScaler Gateway Virtual Server. Also, the domain name specified here is displayed in the Horizon View Client.
To create a PCoIP profile, on the Profiles tab, click Add.
1. Enter a name for the PCoIP Profile. The PCoIP Profile specifies the internal DNS name for Horizon so name it accordingly.
2. Enter the internal connection URL for the internal VMware Horizon View Connection Servers, and then click on Create. NetScaler SNIP needs to be able to connect to this URL.

Session Policy/Profile

To create or edit a Session Policy/Profile that has PCoIP Proxy enabled:

Navigate to Configuration> NetScaler Gateway> Policies> Session.
On the right, select the Session Profiles tab.
On the NetScaler Gateway Session Policies and Profiles page, create or edit a NetScaler Gateway Session Profile.
1. To create a NetScaler Gateway session profile, click Add, and provide a name.
2. To edit a NetScaler Gateway session profile, select the profile, and click Edit.
On the Client Experience tab, ensure that the Clientless Access value is set to On.
On the Security tab, ensure that the Default Authorization Action value is set to ALLOW.
On the PCoIP tab, select the required PCoIP profile. Note: you can also create or edit PCoIP Profiles from this tab.
Click Create or OK to finish creating or editing the Session Profile.
If you created a new Session Profile, then you must also create a corresponding Session Policy.
1. Navigate to Configuration> NetScaler Gateway> Policies> Session.
2. On the right, select the Session Policies tab.
3. Click Add.
4. Provide a name for the Session Policy, and select the required session profile name from the Profile drop-down.
5. If you are creating the Session Policy using Default Syntax, first click Switch to Default Syntax, in the Expression area, type true, and then click on Create.
6. If you are creating the Session Policy using Classic Syntax. Then in the Expression area, type ns_true, and then click on Create.

Gateway Virtual Server

Bind the created PCoIP VServer profile and Session Policy to a NetScaler Gateway Virtual Server:

Go to NetScaler Gateway > Virtual Servers.
On the right, either Add a new NetScaler Gateway Virtual Server, or Edit an existing NetScaler Gateway Virtual Server.
If you are editing an existing NetScaler Gateway Virtual Server, in the Basic Settings section, click the pencil icon.
For both adding and editing, in the Basic Settings section, click More.
Use the PCoIP VServer Profile drop-down to select the required PCoIP VServer Profile.
Scroll down and ensure that ICA Only is unchecked. Then click OK to close the Basic Settings section.
If you are creating a new NetScaler Gateway Virtual Server, bind a certificate, and bind an LDAP authentication policy.
Scroll down to the Policies section and click the plus icon.
The Choose Type page defaults to Session and Request. Click Continue.
In the Policy Binding section, click on Click to select.
Click the circle next to the required Session Policy that has the PCoIP Profile configured, and click on Select.
Back in the Policy Binding page, click Bind.
If you want to use a web browser to connect to VMware Horizon View, then on the right, under Advanced Settings, add the Portal Themes section. If you are only using Horizon View Client to connect to NetScaler Gateway, then you don’t need to perform this step.
1. Use the Portal Theme drop-down to select RfWebUI, and click OK.
2. Horizon View published icons are added to the RfWebUI portal.
To enable support for NAT, SSH to the NetScaler to access the CLI.
1. Run the command set vpn vserver MyVserverName -vserverFqdn MyFQDN. This causes NetScaler to send the FQDN back to the Horizon Client, which enables it to connect to the public IP instead of the DMZ private IP address. Unfortunately, this setting is not available in the NetScaler GUI.

Horizon Configuration

In Horizon Administrator, go to View Configuration > Servers. Edit the Horizon View Connection Server that NetScaler Gateway connects to.
1. On the General tab, uncheck the HTTP(S) Secure Tunnel and PCoIP Secure Gateway.
At Resources > Farms, edit your RDS Farms.
1. Set the Default display protocol to PCoIP.

Update Content Switching Expression for Unified Gateway

If your NetScaler Gateway Virtual Server is behind a Unified Gateway (Content Switching Virtual Server), then you must update the Content Switching Expression to include the PCoIP URL paths.

In the NetScaler GUI, navigate to Configuration> Traffic Management > Content Switching > Policies.
On the right, select the Unified Gateway Content Switching Policy, and then click Edit.

Append the following expression under the Expression area, and then click OK.

|| http.req.url.path.eq("/broker/xml") || http.req.url.path.eq("/broker/resources") || http.req.url.path.eq("/pcoip-client")

Use NetScaler Gateway PCoIP Proxy

To connect, you must have Horizon View Client installed on the client device. Once installed, you can either use the Horizon View Client’s User Interface to connect to NetScaler Gateway, or you can use the NetScaler Gateway RfWebUI portal page to view the icons published from Horizon.
To view the active PCoIP connections, in NetScaler, go to NetScaler Gateway > Policies > PCoIP.
On the right, switch to the Connections tab. The active sessions are displayed with the following data: user name, Horizon View Client IP, and Horizon View Agent Destination IP.
To terminate a connection, right-click the connection, and click Kill Connection. Or click Kill All Connnections to terminate all PCoIP connections.

↧

NetScaler Gateway 12 – StoreFrontAuth, and XenDesktop Wizard

August 1, 2017, 8:48 am

≫ Next: NetScaler 12 System Configuration

≪ Previous: NetScaler Gateway 12 – PCoIP Proxy

Navigation

Overview

NetScaler Gateway 12 supports a new form of authentication called StoreFrontAuth, which delegates Active Directory authentication to a StoreFront server. StoreFrontAuth replaces LDAP on NetScaler Gateway. You usually don’t need both.

StoreFrontAuth uses nFactor, which means NetScaler must be licensed for Enterprise Edition or Platinum Edition.

The easiest method of enabling StoreFrontAuth is to use the XenApp and XenDesktop Wizard. The Wizard lets you select from several different authentication methods, including multi-factor.

Or, you can manually configure StoreFrontAuth in nFactor, and bind the AAA vServer to a Gateway vServer. See George Spiers NetScaler Gateway authentication direct to StoreFront for manual nFactor configuration.

Prerequisites

License – make sure the appliance is licensed for Enterprise Edition or Platinum Edition.

DNS Servers – make sure DNS Servers are configured on the NetScaler.

The Wizard creates a whole new Gateway vServer. You’ll need the following:

DNS name for the Gateway
VIP for the Gateway
Certificate for the Gateway

URL to the StoreFront servers – must be reachable from NetScaler SNIP

To retrieve the list of stores, NSIP must be able to reach the StoreFront URL

RADIUS – If you are doing multi-factor authentication, then you’ll need RADIUS information, including adding NetScaler NSIP and/or SNIP as RADIUS Clients.

XenApp and XenDesktop Wizard

In NetScaler, click XenApp and XenDesktop on the bottom left.
On the right, click Get Started.
In the NetScaler Gateway section, enter the FQDN for the new Gateway.
Enter the VIP for the new Gateway.
Check the box next to Redirect requests from port 80 to secure port, and click Continue.
In the Server Certificate section, if you already have a certificate on this appliance that matches the new Gateway FQDN, then select it. Or, change the selection to Install Certificate, and import a .pfx file. Click Continue when done.
In the StoreFront section, enter the URL to StoreFront, and click Retrieve Stores.
In the Receiver for Web Path drop-down, select a RfWeb Path.
Enter a Secure Ticket Authority URL, including http:// or https://.
1. Use the plus icon to add more than one STA server. STAs are usually your XenDesktop Controllers.
Check the box next to Use this StoreFront for Authentication, and click Continue.
In the Authentication section, in the Choose Authentication Type drop-down, notice that there are several options. Multi-factor will be detailed later.
Click the button to Retrieve Auth Enabled Stores.
Use the Authentication Service URI drop-down to select a store.
The Domain field can be used to enter a default domain. Note: the domain name entered here must match one of the domain names permitted by StoreFront. This will be explained below in the Multiple Domains section.
Click Continue
Review the summary screen, and click Done.
If Default SSL Profiles are not enabled, then edit the Gateway vServer, and configure standard SSL vServer Settings.

Portal Theme and Login Schema

If you point your browser to the Gateway URL, notice it’s an old theme.
On the left, go to NetScaler Gateway > Virtual Servers.
On the right, edit the Gateway that was created by the wizard.
On the right, in the Advanced Settings column, click Portal Themes.
On the left, scroll down, and change the Portal Theme selection to RfWebUI, or one of its derivatives. Click OK.
Now when you visit the Gateway URL, it’s shown using a newer theme. However, there’s a “First Factor” text in the middle of the page. We can fix that.
Back in your NetScaler Gateway, scroll down and find the Authentication Profile section. Click the pencil icon. This object enables nFactor.
Click the pencil icon to edit the Authentication Profile.
Note the name of the AAA vServer.
Go back to the main NetScaler navigation, and go to Security > AAA – Application Traffic > Virtual Servers.
You’ll see a new AAA vServer in the list. It’s down because there’s no certificate bound to it, but it still works. If the red icon bothers you, you’re welcome to bind a certificate to it.
Edit the AAA vServer.
Scroll down, and click where it says 1 Login Schema.
Right-click the Login Schema, and click Edit.
Click the pencil next to the Profile field.
Click the pencil in the Authentication Schema field.
On the left, click the LoginSchema folder to open it.
Move your mouse over the SingleAuth.xml file, and click the download icon. Save it somewhere.
Edit the downloaded .xml file.
Find the line containing the First factor text and delete the line. Save the file with a new name.
Go back to the Login Schema dialog box. In the Authentication Schema field, click the upload icon. Select the edited file to upload it.
Unfortunately, uploading a new Login Schema .xml file does not actually select the uploaded file. Click the pencil icon.
On the left, click the new file to highlight it. On the right, click the blue Select icon.
Notice that the file name has now changed to the new file. Click OK.
Click OK again.
Click Close.
If you point your browser to the Gateway FQDN again, the extra text is gone. You’re welcome to make additional changes to the .xml file.

StoreFront Configuration for Gateway

In NetScaler, on the bottom left, click XenApp and XenDesktop.
On the top right, click Download file.
In the Download StoreFront Settings page, you can either export all virtual servers, or just one of them. Click OK.
Save the GatewayConfig.zip file somewhere.
In StoreFront console, on the left, right-click the Stores node, and click Manage NetScaler Gateways.
At the top of the window, click the blue link imported from file.
Click the Browse button, and select the GatewayConfig.zip file you saved earlier.
Click the Import button next to the Gateway vServer you want to import.
In the Select Logon Type page, you can optionally enter a SmartAccess Callback URL that resolves to any NetScaler Gateway on the same appliance that authenticated the user. Click Verify.
Click Next.
In the Secure Ticket Authorities page, review the list of STAs, and click Next.
In the Review Changes page, click Import.
In the Summary page, click Finish.
Click Close.
The new Gateway is shown in the list. Notice that the new Gateway is already Used by Store, so there’s no need to enable Remote Access on the Store yourself. Click Close.

StoreFrontAuth and Multiple Domains

The wizard configures Session Profiles with a default domain name. Multiple domains won’t work until you remove this SSON Domain.

At NetScaler Gateway > Virtual Servers, edit the Gateway Virtual Server created by the wizard.
Scroll down, and click where it says 2 Session Policies.
Right-click each Session Policy, and click Edit Profile.
On the Published Applications tab, uncheck the box next to Single Sign-on Domain. Click OK.
Repeat for the other Session Profile.

StoreFrontAuth authenticates users to StoreFront using normal StoreFront username syntax:

username only
Domain\username
username@domain.suffix (aka userPrincipalName)

If no domain name is specified, StoreFrontAuth can be configured with a default domain name.

Go to Security > AAA > Virtual Servers, right-click the AAA vServer that has StoreFrontAuth enabled, and click Edit.
Scroll down, and click where it says 1 Authentication Policy.
Right-click the StoreFrontAuth policy, and click Edit Policy. Unfortunately, Edit Action doesn’t seem to work.
Click the pencil icon next to the Action.
In the Domain field, enter a default domain name that will be used if the user does not specify a domain. Click OK.

Notes on domain names:

The domain names entered by users (domain\username, or username@domain.suffix), must be accepted by StoreFront.
The default domain name entered in the StoreFrontAuth Action must be accepted by StoreFront.
After StoreFrontAuth authenticates the user, it sends back the user’s UPN. NetScaler Gateway then uses the UPN to Single Sign-on to StoreFront. Thus, the UPN suffixes must be accepted by StoreFront.

To configure the domain names accepted by StoreFront:

In StoreFront Console, right-click your store, and click Manage Authentication Methods.
Click the top gear icon, and click Configure Trusted Domains.
If the selection is Any domain, then you’re good, and you don’t need to change anything.
If it’s set to Trusted domains only, then make sure that UPN domain suffixes are in the list.
To make it easier for users, add the NetBIOS domain names too. However, if you checked the box for Show domains list in logon page, then internal users will see both the NetBIOS domain names, and the UPN domain suffixes.
Notice that there’s a drop-down to select the Default domain. This default domain is only used if the user does not specify a domain name, and if no domain name is configured in the StoreFrontAuth action.

Depending on how you configured the StoreFront trusted domains, users have several options for logging into NetScaler Gateway:

Username only – the default domain name configured in the StoreFrontAuth action is used. If StoreFrontAuth default domain is not configured, then it uses the default domain name configured in StoreFront.
Domain\username – requires the short domain name (NetBIOS) to be included in StoreFront’s list of trusted domains.
UPN.suffix\username – this should always work, since you always need to add UPN suffixes to the StoreFront trusted domains list.
username@UPN.suffix – this should always work, since you always need to add UPN suffixes to the StoreFront trusted domains list.

Multi-factor authentication

The XenApp and XenDesktop Wizard supports several authentication configurations:

On the bottom left, click XenApp and XenDesktop.
On the top right, move your cursor over the existing Gateway, and click click the pencil icon to edit it.
If you earlier removed the Single Sign-On Domain to support multiple AD domains, then the wizard will prompt you to re-enter a Default Active Directory Domain. Unfortunately, this field is not optional. After entering a domain name, and completing the steps shown in this section, you can follow the above instructions to remove it again.
In the Authentication section, click the pencil icon.
At the top of the Authentication section, there’s a drop-down for Choose Authentication Type. There are several options. Since this article is focused on StoreFront Auth, only RSA + StoreFront Auth will be detailed below.
1. Note: the RSA + Domain option is equivalent to NetScaler Gateway RADIUS + LDAP. The RADIUS + LDAP authentication is performed directly by NetScaler Gateway, which means it doesn’t use nFactor or a AAA vServer. Unfortunately, the wizard does not configure NetScaler Gateway correctly. See my NetScaler Gateway RADIUS Authentication article to fix the authentication policies and Gateway binding configuration.

The RSA + StoreFront Auth option will ask you for RADIUS authentication information.

Change the Choose Authentication Type drop-down to RSA + StoreFront Auth.
Enter the RADIUS information, and click Test Connection.
StoreFront Auth should already be configured, so just click Continue.
Note, if you see any error messages, you might have to completely delete the Gateway, and run the wizard from scratch. Unfortunately, the XenApp and XenDesktop wizard seems to be quite buggy.
After changing the Gateway authentication, download the configuration file again, and import to StoreFront.
When you import to StoreFront, you can select an existing Gateway to overwrite.
The Gateway that it imports to StoreFront is automatically configured with Domain and security token, so you don’t have to configure this yourself.

If you point your browser to the Gateway URL, you will see two password fields. You would think that the first password field is where you enter the AD Password, but that’s incorrect. Actually, it wants Passcode in the first field, and AD Password in the second field.

To swap the fields, do the following:

Go to Security > AAA – Application Traffic > Virtual Servers.
Edit the AAA vServer that is linked to the Gateway vServer.
Scroll down, and click where it says 1 Login Schema.
Right-click the Login Schema, and click Edit.
Click the pencil next to the Profile field.
Notice the DualAuth.xml file selection. Click the pencil in the Authentication Schema field.
On the left, click the LoginSchema folder to open it.
Move your mouse over the DualAuth.xml file, and click the download icon. Save it somewhere.
Edit the downloaded .xml file.
Look for the two lines containing passwd. Swap the passwd1 and passwd IDs. In other words, remove the 1 from passwd in line 27, and add it to the passwd in line 22. There are two ID tags in each line. Save the file with a new name.
Go back to the Login Schema dialog box. In the Authentication Schema field, click the upload icon. Select the new file to upload it.
Unfortunately, uploading a new Login Schema .xml file does not actually select the uploaded file. Click the pencil icon.
On the left, click the new file to highlight it. On the top right, click the blue Select icon.
Notice that the file name has now changed to the new file. Click OK.
Click OK again.
Click Close.
Now when you go to the Gateway URL, the fields should work as expected.