Jump to content
Welcome to our new Citrix community!

Content Switch allowing HTTP connectivity to HTTPs vServer


Recommended Posts

Am after some advice on strange behaviour I am seeing with regards to Content Switching.

 

We have around 70 TM vservers created, some are standard HTTP and others are SSL.   Each VS is named after the URL of the web site being requested.  There is only one VS per service though.

 

I have then created 2 Content Switches, both on same IP but on Ports 80 and 443 to handle both secure and non-secure requests.  I have created a single CS Action and Policy to forward the request to the relevant LB vserver based on the URL being entered.

The strange behavour I am seeing is even though a LB VServer is created as SSL, when going through a CS the user can enter HTTP and the traffic will reach the backend websites on port 80.  I was under the impression, if there was nothing listening on HTTP for that URL the request should be dropped (not doing any HTTP to HTTPs redirection as this time).  Is this normal?  I can see when you create a non-addressable vServer it effectiviely drops the port and shows as port 0.  Does this mean the VS is listening on any port and it ignores the service type?

If I remove the CS out of the equation I get the expected results.  No response on HTTP but HTTPs is fine.

 

We are running the latest v13 firmware.

 

Thanks in advance

 

Chris

Link to comment
Share on other sites

Check and see if on your HTTPS vservers (either cs vserver) or the lb vserver, is someone enabled the new setting (11.1 and later) for -redirectfromport and -httpsredirecturl:

That might not be the exact cli parameter name, but in the GUI, it is under the "Basic Settings > More" node of the SSL vserver.

 

Basically, it creates a HTTP:80 (or other port you designate) listener that redirects traffic to the https://<fqdn> you specify and replaces the older mechanism of having a seperate lb vserver or cs vserver on HTTP:80 in a down state and relying on the -redirecturl.  Property is only present on SSL-based lb/cs vservers. (not on vpn vserver).

 

So it woun't look like that VIP:80 is in use, but it is as kind of an invisible sidecar to your SSL:443 vserver.  When this setting is in use, i tend to name my vserver:

lb_vsrv_<appid>_ssl_w80 to remember that this vip is on 443 and 80 at the same time and handling its own redirection.

 

 

Link to comment
Share on other sites

Hi Rhonda

 

Thanks for the response.  Neither of those parameters are set on the lb vserver.  They are not available on the SSL CS. 

Just a strange one that when the CS is not in the path I am seeing the expected results.  As soon as the CS gets involved we have the issue.  We can obviously put redirection in place to make sure all traffic is sent over HTTPs but I am concerned how this is happening at all.  If an LB vServer is set for SSL only I do not see how it can accept non-SSL traffic.

Link to comment
Share on other sites

Are you sure you don't have any other vserver on that VIP:80 with a responder policy doing the redirect?

You may have to look at your running config, because you have an entity that you aren't expecting either in the cs or lb range.

Do any of your vservers have a listen policy instead?

 

You might just want to search your runningconfig for references to that VIP and see if there were any HTTP:80 entities created that you didn't expect.

Otherwise, share your HTTP/SSL cs vserver configs and see if there is something else going on.

 

What is your HTTP cs vserver doing?  Since you have one, this is what determines what happens to your HTTP traffic.  Maybe there is a misconfiguration on this entity, if its not redirecting traffic to SSL.

Link to comment
Share on other sites

I have been through the config a few times.  I have also tested this in my lab at home.  My Lab at home displays exactly the same issues.  Config is as follows in my lab:

 

Single SSL lb vServer called website1.home.lab with appropriate certificate bound.  This has a single SG configured sg-web-80 on port 80.  The backend server is a simple IIS server with default settings.

In this setup, if I try and hit http://website1.home.lab it fails (as expected) as the lb vsvr is configured for SSL and port 443.

 

I then created 2 CS vservers, one on port 80 and the other on port 443.  The CS Action has a target load balancing vserver expression as HTTP.REQ.HOSTNAME.  I have then created a CS policy for the action which uses the expression HTTP.REQ.HOSTNAME.CONTAINS("home.lab").  This policy is then bound to both CS vservers.

 

With the CS in place, I can use both https://website1.home.lab and http://website1.home.lab and the connection is successful.  My ADC at home is running 12.1 and that is the only config on it.

 

Certainly a weird one.

Link to comment
Share on other sites

So, you have a cs vserver listening on port 80 and then actually handing traffic off to backend lb vservers.  This is therefore handling your port 80 traffic.

Do you want your port 80 traffic to be passed, blocked, or redirected to HTTPS? (Your current config isn't quite doing that last part.)

 

And is your port 80 cs vserver directing traffic to ssl lb vserver or http lb vservers?  (Or do you have lb vservers configured on HTTP:*)

 

 

 

Link to comment
Share on other sites

I am not doing any redirection at the moment whilst testing.  My customer needs both a 443 CS and a 80 CS as they are publishing both types of service.   In my lab, I only have one LB vserver created which is type SSL.  There are no HTTP LB VServer at all.  What I would expect is 443 connectivity to be successful as it will hit the SSL LB vServer and HTTP traffic to hit the CS but go no further.

It appears when the traffic goes through the Content Switch the type of LB Vserver it hits is irrelevant.  It will just pass it based on URL and allow connectivity which seems a flaw to me.  Without the CS in place and hitting the LB Vserver directly the traffic for port 80 drops which is what I would expect.

Link to comment
Share on other sites

That does not make sense.  The traffic from the Netscaler to the backend servers is controlled via the Service Group. You can have an SSL vServer to encrypt client to Netscaler traffic but still use standard HTTP to connect to the servers behind it (SSL Offload)

If I take the CS out of the equation, I am seeing the expected results.  With only the SSL LB vserver created, I cannot connect to the service through HTTP at all, even if I try and force the port to use 443.  The issue only occurs when the CS is in the data path.

Link to comment
Share on other sites

So, what I'm hearing, is that you have a cs vserver on both port 80 and 443.  But your port 80 vserver is in front of SSL:443 services.  While its it is passing port 80 traffic on the vip to your designated backend.  

While http frontend to ssl backend isn't a useful config, it will pass traffic:  I did a trace earlier today of an lb vserver HTTP:80 going to backend services SSL:443. (This is so weird to my brain, that I keep describing it backwards when I try to type it in.)

 

So it sounds like you are receiving traffic on the CS vserver on port 80 and because you don't have it tied to valid HTTP:80 services but instead ssl destinations, it is still passing traffic. (Or your service groups are on a * port instead of port specific).   

 

If you had tied your port 80 cs vserver to your port 80 servicegroups that were down in your lab because they aren't present than your connection should fail. But because you have your port 80 vserver tied to functioning destinations, it is passing traffic to the backend destinations.  Now, if these service/servicegroups are not on port 80, then the backend traffic reaching the servers shouldn't be 80, unless you are doing something else in your config like a service/servicegroup on a * port. 

 

But unless you want to actually show your cs vserver/lb vserver/service group settings (or at least in part), its hard to provide you with any more details. But your port 80 cs vserver is UP, because it is pointing to valid destinations, whether those are on 80 or not.  If they were down it would fail.  

 

Content switching doesn't redirect.  CS vserver becomes the client-to-ns entity, lb is handled internally, and then the service is handled NS to server (backend).

It would help to see how you created the servicegroup to know if there is something else going on. But with a cs vserver on port 80, you are receving 80 traffic (the lb vserver doesn't matter at this point) and you are connecting to its servicegroup on the backend. So the reason why it works with CS vserver, is that you are listening to port 80 requests.

 

Link to comment
Share on other sites

Hi Rhonda


Thanks again for the response.  I am more than happy to share the config of my lab setup as it is only for my use.  I dont have access to it at the moment as on a customer site but will get it uploaded later this evening.  Just to confirm, the LB vServer is running not on a specific port as when creating it as non-addressable there is no option to set the port. 

This may be the same as using an ANY option when creating vServers. It does have the type of SSL though so am expecting standard HTTP traffic to be dropped.

 

Kind Regards

 

Chris

Link to comment
Share on other sites

Hi Rhonda

 

Config from my lab as follows (have only added the relevant lines)

 

add server web01.home.lab web01.home.lab
add serviceGroup sg-web-80 HTTP -maxClient 0 -maxReq 0 -cip DISABLED -usip NO -useproxyport YES -cltTimeout 180 -svrTimeout 360 -CKA NO -TCPB NO -CMP YES
bind serviceGroup sg-web-80 web01.home.lab 80
add lb vserver website1.home.lab SSL 0.0.0.0 0 -persistenceType NONE -cltTimeout 180
bind lb vserver website1.home.lab sg-web-80
bind ssl vserver website1.home.lab -certkeyName websites.home.lab
bind ssl vserver website1.home.lab -eccCurveName P_256
bind ssl vserver website1.home.lab -eccCurveName P_384
bind ssl vserver website1.home.lab -eccCurveName P_224
bind ssl vserver website1.home.lab -eccCurveName P_521
add cs vserver cs-homelab-443 SSL 172.20.10.100 443 -cltTimeout 180
add cs vserver cs-homelab-80 HTTP 172.20.10.100 80 -cltTimeout 180
add cs action csact-main-lb -targetVserverExpr HTTP.REQ.HOSTNAME
add cs policy cspol-main-lb -rule "HTTP.REQ.HOSTNAME.CONTAINS(\"home.lab\")" -action csact-main-lb
bind cs vserver cs-homelab-443 -policyName cspol-main-lb -priority 100
bind cs vserver cs-homelab-80 -policyName cspol-main-lb -priority 100

 

Mihal:  I am not sure how the connection is SSL.  From the client I am able to use standard HTTP over port 80 even though the LB is bound with an SSL cert.  It looks like the LB type is ignored completely so if my LB's are going to be behind a CS then they could all be HTTP as it does not make any difference.

Link to comment
Share on other sites

your config is not right if you ask me.

 

When you use cs vservers on 443 the cert should binded here not on LB side.

Content switch can't be done before ssl decryption.

Netscaler needs  to decrypt the data so it can look in http data. Only after this content switching can take place.

Also the lb should be http not ssl. i never saw an ssl lb with http services before.

If you use a ssl lb then the services should be ssl also. And you don't need a ssl cert for this as the netscaler is connecting to a server. Netscaler is the client.

 

 

 

 

 

Link to comment
Share on other sites

Ideally, your HTTP:80 cs vserver either directs traffic to lb_vserver:HTTP and services/servicegroups of HTTP:80 (whether your lb vserver is addressable or not).

Your SSL:443 cs vserver will then handle all of your SSL:HTTPS traffic and direct it to the lb_vserver:SSL and service/servicegroups of SSL:443 (if doing end-to-end encryption).

Mihal's points are all valid.

 

If you want 80 traffic to redirect to ssl, then you have to use a responder policy  (or one of the other HTTP to SSL redirects) to make the client change from HTTP to HTTPS client side.  You don't pass client-side HTTP traffic to server side SSL.  

If you are using your SSL backend, because you don't have HTTP in this environment, then that's your problem. Use the responder policy to redirect to SSL instead of trying to use the HTTP cs vserver to hit SSL entities.  

 

The bottom line, your HTTP:80 cs vserver should only direct traffic to HTTP:80 lb vserver/services (or a non-addressable lb vserver with only HTTP:80 services behind it).

 

Example:

add lb vserver lb_vsrv_demo http 0.0.0.0 0 #if non-addressable, but still HTTP based

add servicegroup svcg_demo HTTP   # bind service members as appropriate...but only port 80

add cs vserver cs_vsrv_demo http <VIP1> 80

bind cs vserver cs_vsrv_demo -policy cs_pol_appA  -priority 100

# or use a responder policy to redirect to SSL; in which case, you just need the cs vserver in an up state with no other entities bound or an lb vserver on HTTP:80 in an UP state

# no services bound and skip the cs vserver on port 80 all together.  Or use one of the http to port 80 redirect methods.

 

add lb vserver lb_vsrv_demo_ssl SSL 0.0.0.0 0

add servicegroup svcg_demo_ssl SSL   # bind service members of type SSL here

add cs vserver cs_vsrv_demo_ssl ssl <VIP1> 443

bind cs vserver cs_vsrv_demo_ssl -certkey <certkeyname>

bind lb vserver lb_vsrv_demo_ssl -certkey <certkeyname>   # good idea whether addressable or not; though not strictly required in this scenario

bind cs vserver cs_vsrv_demo_ssl -policy cs_pol_appA_ssl -priority 100

# continue with policies...

 

 

 

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...