Jump to content


Settings on non-addressable LB VS used by CS VS

Started by Evan Mann , 21 April 2017 - 11:15 AM
4 replies to this topic

Evan Mann Members

Evan Mann
  • 46 posts

Posted 21 April 2017 - 11:15 AM

When directing traffic to a content switching virtual server that has policy bindings targeting non-addressable load balancing virtual servers, how relevant are all of the settings on a LB VS? 


Here's a specific example, SSL related

All of my externally facing websites point to a single SSL CS VS.   All of the CS policies have bindings that target SSL LB VS's.  The services associated with the SSL LB VS's are a mix of HTTP and SSL.


The CS VS and various LB VS's have had identical configuration for SSL Ciphers, ECC Curves and SSL Parameters.  This existing configuration lead to a B on ssllabs.com tests.


I made changes only to the CS VS and was able to improve my ssllabs.com score to an A- with the initial changes.  


What impact does not changing these SSL related settings on the LB VS have in this configuration?


Is there any particular reasoning on why I'd want to keep settings consistent, or non-consistent between the CS VS and the LB VS?

Outside of this SSL example, are there any other "rules" to follow as it relates to this?

Paul Blitz Members

Paul Blitz
  • 4,004 posts

Posted 21 April 2017 - 12:34 PM

When you have a CSVS, then it's the CSVS settings that affect the front end connection (and the service settings that affect the backend connection)


When you have an SSL CSVS, then it doesn't really matter whether the LBVS is SSL or HTTP, as the SSL gets offloaded at the CS; what is more important is whether the services are SSL or HTTP, as that determines if you are re-encrypting the backend traffic or not.


there's several blogs around that give details of what to do to get an A+, but I put them all together recently in a doc:




Enable the default profiles - this assigns the default front-end profile to all SSL vServers and you'll lose any existing SSL parameters and/or ciphers assigned to the vServer - they will be replaced with the default profile settings (which now in 11.1 should be sufficient to give you a grade C or so)


set ssl parameter -defaultprofile enabled


Next, we need to create a DH Parameters file, needed in the next step:


create ssl dhParam /nsconfig/ssl/DH_Params_2048.key 2048


Then create a custom profile which you'll use to define your customisations - in this case we're enabling DHE by specifying a Parameters file and also denying insecure client initiated SSL renegotiation.  Note SSLv3 is disabled by default now.


add ssl profile Custom_SSL_Profile -dh ENABLED -dhFile "/nsconfig/ssl/DH_Params_2048.key" -denySSLReneg NONSECURE


Now associate your ciphers with the profile - this list is probably more extensive that it needs to be but gets an A+ at SSLLabs, whilst still providing a wide range of browser support.  Essentially we aim to prioritise cipher suites combining ECDHE_RSA,  AES_GCM and SHA2 as these standards provide a very high degree of security and are supported by modern browsers - those further down the list are provided for backward compatibility with clients which don't support them.  The last one provides support for legacy IE8 on WinXP clients based on TLS 1.0; the SSL3 name is counter-intuitive (these all work fine on VPX 11.1)


bind ssl profile Custom_SSL_Profile -cipherName TLS1.2-ECDHE-RSA-AES256-GCM-SHA384 -cipherPriority 1

bind ssl profile Custom_SSL_Profile -cipherName TLS1.2-ECDHE-RSA-AES128-GCM-SHA256 -cipherPriority 2

bind ssl profile Custom_SSL_Profile -cipherName TLS1.2-ECDHE-RSA-AES-256-SHA384 -cipherPriority 3

bind ssl profile Custom_SSL_Profile -cipherName TLS1.2-ECDHE-RSA-AES-128-SHA256 -cipherPriority 4

bind ssl profile Custom_SSL_Profile -cipherName TLS1-ECDHE-RSA-AES256-SHA -cipherPriority 5

bind ssl profile Custom_SSL_Profile -cipherName TLS1-ECDHE-RSA-AES128-SHA -cipherPriority 6

bind ssl profile Custom_SSL_Profile -cipherName TLS1.2-DHE-RSA-AES256-GCM-SHA384 -cipherPriority 7

bind ssl profile Custom_SSL_Profile -cipherName TLS1.2-DHE-RSA-AES128-GCM-SHA256 -cipherPriority 8

bind ssl profile Custom_SSL_Profile -cipherName TLS1.2-DHE-RSA-AES-256-SHA256 -cipherPriority 9

bind ssl profile Custom_SSL_Profile -cipherName TLS1.2-DHE-RSA-AES-128-SHA256 -cipherPriority 10

bind ssl profile Custom_SSL_Profile -cipherName TLS1.2-AES256-GCM-SHA384 -cipherPriority 11

bind ssl profile Custom_SSL_Profile -cipherName TLS1.2-AES128-GCM-SHA256 -cipherPriority 12

bind ssl profile Custom_SSL_Profile -cipherName TLS1.2-AES-256-SHA256 -cipherPriority 13

bind ssl profile Custom_SSL_Profile -cipherName TLS1.2-AES-128-SHA256 -cipherPriority 14

bind ssl profile Custom_SSL_Profile -cipherName TLS1-AES-256-CBC-SHA -cipherPriority 15

bind ssl profile Custom_SSL_Profile -cipherName TLS1-AES-128-CBC-SHA -cipherPriority 16

bind ssl profile Custom_SSL_Profile -cipherName SSL3-DES-CBC3-SHA -cipherPriority 17


Cipher order IS important: the above ordering will try and use the better quality ciphers first, and only use the ones lower on the list if the browser can’t support the better ones (eg IE8 on XP)


Note the DEFAULT cipher group will still be bound, this needs to be removed.


unbind ssl profile Custom_SSL_Profile -ciphername DEFAULT


Then assign to your vServer:


set ssl vserver [vServer name] -sslProfile Custom_SSL_Profile



Finally, we should enable STS (Strict Transport Security), which is done with a rewrite policy:


add rewrite action insert_STS_header insert_http_header Strict-Transport-Security "\"max-age=157680000\""

add rewrite policy enforce_STS true insert_STS_header -comment "enforces Strict Transport Security"


… and bind it – I bound it globally:

bind rewrite global enforce_STS 100 NEXT -type RES_OVERRIDE




I'm using the above with a Netscaler gateway Vserver, but it applies to any SSL vserver



Evan Mann Members

Evan Mann
  • 46 posts

Posted 21 April 2017 - 03:27 PM

I'm aware that the back-end Service setting being HTTP or SSL would determine if I'm re-encrypting.  I just want to focus on the CS VS / LB VS relatonship on the front-end.


Outside of my specific example, in general, when using a CS VS, do all of the settings in the non-addressable LB VS being refrence by the CS VS, simply not matter whatsoever?  Or is there some rules I need to follow on how I set LB VS in these situations?  What if I set the protocol on the LB VS totally wrong relative to the actual traffic type on the CS VS (ie. the CS VS is set HTTP and the LB VS is set DNS)

Joe Brozzetti Members

Joe Brozzetti
  • 180 posts

Posted 21 April 2017 - 07:13 PM

You can have an HTTP LBVS off of an HTTPS CSVS.  


A user can type https://somesite.com/app and hit an HTTPS CSVS which then evaluates for /apps and sends to an HTTP LBVS on Port 8989 or whatever.  

Ross Bender Members

Ross Bender
  • 142 posts

Posted 24 April 2017 - 10:11 PM

I've found it easiest to use an HTTP non-addressable LBVS for this very reason. If you use an SSL LBVS it is confusing as the SSL settings are required yet not used.