Jump to content
Welcome to our new Citrix community!

Question about SSL offload with Content Switching


Recommended Posts

Hi,

 

I've thought of asking this many times, but I've always forgot it, well...

 

I'm wondering when we're setting up Content Switching vServers (SSL) and then a bunch of non-addressable LB vServers that can be accessed through the CS vServer. Does it matter if the LB vServer behind the CS vServer is type of HTTP or SSL? I've done the majority of my implementations with SSL LB vServers, but I just noticed that it involves binding certificates to them and also a possibility that the SSL offload needs to be done twice on the NetScaler.

 

So, what's the case with this one? Should I just build the non-addressed vServers as HTTP instead of SSL? Is the only benefit to avoid unnecessary cert bindings or is there also a performance angle here?

 

Facts or links to articles would be appreciated.

 

I know that if I'm creating addressed LB vServers, it's a different game.

Link to comment
Share on other sites

Hi Kari,

 

For non-addressable LBs there is no need for it to be of type SSL, because the SSL is between the Client and CS Vserver. Rest of the communication is internal. 

And even if you have it as SSL type offload DOES NOT happen twice. 

 

Only use case I can think of is when addressable LB is bound to CS and users access the LB directly as well. 

 

Regards,

Sid

Link to comment
Share on other sites

Even if the LB Vserver is addressable, if accessing via CS there is no additional SSL handshake that happens. I don't think there is a document that says precisely that.  But you can open a case to get an official answer. 

 

 

There is an easy way to check that . 

 

Setup:

CS: 1.1.1.1 [ssl:443]  >> CS POL >> CS ACT >> LB: 2.2.2.2 [ssl:443]  >> Service:3.3.3.3 [ss:443l]

 

start NS Trace -size 0

 

Access the CS Vserver (eventually you will access the service)

 

stop NS Trace

 

Open the trace in Wireshark

 

Filter: tcp.port==443

Statistics >> Conversations

Select: Limit to Display Filter

 

At this point you will see all SSL communication that happened on NS when you accessed the CS VIP.

 

You will see the following which are expected and nothing else. (unless of course someone was accessing the LB directly at that time, bit you can always check the source ip)

Client  <> CS

SNIP / MIP <> Service

 

Regards,

Sid

 

 

  • Like 2
Link to comment
Share on other sites

Hi Sid,

 

 

So it seems. It would be rather weird if it would re-encapsulate the traffc now that I think of it because it's all NetScaler internal (non-addressed). Thanks for confirming, now I don't need to start to reconfigure all the environments.

 

I will build the non-addressed LB vServers as HTTP in future though, because that way I can skip binding certificates and applying SSL Profiles to places that are not relevant :)

Link to comment
Share on other sites

3 hours ago, David Birrer1709158361 said:

Tell me if i am wrong but i pretty sure netscaler is doing ssl again to  connect to the backend. There is no real need for that i agree but i got some servers that are behind a cs and they listen only on https.

 

how can Netscaler access these vservers without reancapslulate?

 

cheers David

 

If the back-end server is SSL of course NS will have to perform SSL enc/dec on the back-end. This is regardless of content switching being in place or not.

 

This question was more about if [CS + SSL lb] is in place there "additional" SSL enc/dec happening internally.

Link to comment
Share on other sites

  • 9 months later...
On 6/29/2018 at 8:16 AM, David Birrer1709158361 said:

Tell me if i am wrong but i pretty sure netscaler is doing ssl again to  connect to the backend. There is no real need for that i agree but i got some servers that are behind a cs and they listen only on https.

 

how can Netscaler access these vservers without reancapslulate?

 

cheers David

David,

I would create a separate VIP w/ services or service groups matching the back-end resources (SSL vs. HTTP). 

If you want un-encrypted traffic then simply create a HTTP VIP w/ corresponding services with a type of HTTP that match up with your non-SSL HTTP back-end resources.  You would then adjust the corresponding CS policies to direct HTTP traffic to the correct VIP and therefore the appropriate back-end resource serving HTTP.

 

I personally like my non-addressable VIPs configured as SSL to keep things simple and so I can easily identify what kind of traffic each VIP handles.

 

  • For non-addressable LBs there is no need for it to be of type SSL, because the SSL is between the Client and CS Vserver.

  • The rest of the communication is internal

  • Even if you have it as SSL type offload DOES NOT happen twice. 

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...