by David Brett, CTP
Working in the technology industry lots of us have home labs to test and learn. One of the major pitfalls of this is the fact that many of us only have a single public IP address. This is when hosting multiple internal services required externally can become a bit of an issue and very complex with more than often way too many port forwarding rules in place. This is also the case with many small businesses only having a single entry point to their network.
How to get around this, Citrix NetScaler Content Switching.
The purpose of this article is to provide a guide to setting up a simple Citrix NetScaler Content Switch to host multiple externally facing services from a single IP address.
First – What is the content switch doing in this example?
Essentially we will be setting up a content switch listening on port 443 on a single IP address accessible from the outside world (normally in a DMZ with a NAT rule in place!). We will point 3 external fqdn records to the SAME address, allow port 443 through our firewall and forward traffic to our content switch. Once there we will determine what fqdn the end user is using to get to the content switch and redirect their traffic to the relevant internal service based on the external fqdn.
Now this is by no means everything that can be achieved from a NetScaler Content Switch but it is a great starting point and a common pain point for people running labs at home with 1 entry point.
- This article assumes you already have a NetScaler Gateway built
- The 3 external fqdns we are going to use are mobile.bretty.me.uk, ug.bretty.me.uk and storefront.bretty.me.uk
- ug.bretty.me.uk will redirect the user to a NetScaler Gateway
- mobile.bretty.me.uk will redirect the user to a SSL offloaded Non-Addressable vServer hosted on the NetScaler pointing to a XenMobile 10.3 Appliance in the DMZ
- storefront.bretty.me.uk will redirect the user to a SSL offloaded Addressable vServer hosted on the NetScaler pointing to a StoreFront Server (No Default Store Selected on StoreFront)
Let’s get going.
First add 3 external DNS records to point to the public IP Address of your router. In my case I am using ddns to dynamically update a hosting service with my public IP as it is not static.
Next pick a free internal IP Address (this will be your content switch IP) and add a firewall rule to direct all port 443 traffic to that address
Ping all the external URLs to ensure that all resolve and all go to the same place
Check that your NetScaler Gateway is up and running and verify that the other services you are about to load balance are all working. I cannot tell you the number of times I have been setting up monitors and wondering why they are not working only to find that the actual service itself is down!
So, the first thing we will need to do is set up the load balancers on the NetScaler to handle the traffic for the Web Server and XenMobile. In this example I am going to offload SSL to port 80 for both services.
Navigate to Traffic Management – Load Balancing – Servers
Add a server record for each of the back end services you want to load balance
Next go to Services
Click add and enter the details for the service you want to load balance – make sure to point it to the server you created earlier
Once you click OK you can select a monitor. This is a pretty important step as this is what binds the service you want to load balance and the back end server together. It essentially probes the server in a certain way to ensure that the service you want to load balance is working as expected.
Click to assign a monitor
NOTE: NetScaler assigns a default monitor to the service. Click add to bind a more specific monitor to the service
You will see there are a bunch of built in monitors to choose from
Click on Add to add a specific monitor
From the drop down list select STOREFRONT, click on special parameters and enter the name of your store.
This is a Citrix written monitor to specifically check that StoreFront is working on the server. If you think about it it’s way better than just a standard HTTP(s) probe. The reason for this is that IIS could potentially be running on the server fine but your Store is broken / down / deleted etc. This intelligent monitor will pick up on that and mark the service as down.
If you are monitoring on a secure port be sure to check the Secure box at the bottom of the mail custom monitor page
Bind the monitor to the service
Once bound hit refresh on the Service Monitor binding page – it will show you on the right if the monitor you have configured is working as expected. At this point you can shut down IIS on your web server and make sure the monitor goes down and is therefore doing its job correctly
Click close and Done to add the monitor and service
Create another service on port 80 for XenMobile using the same steps as above. However when setting up the monitor configure a TCP monitor to send a request directly to port 8443 of the XenMobile Appliance. This will ensure that the XenMobile enrollment port is alive and hence XenMobile is working right rather than just checking port 80!
Once finished you will have 2 services now running
Go to Virtual Servers
Click Add to set up your Load Balancer for the Web Server
Give the vServer a name, a free IP Address, select SSL as the protocol
Click on No Load Balancing Service to bind and select your Web Server service from the list provided
Click to bind a certificate (in this case my wildcard certificate) and click Done
You will now see your Virtual Server ready to accept connections
You can test this by going to the server in a browser
Click Add to set up your XenMobile Load Balancer.
NOTE: In this case I am selecting SSL but setting up the Load Balancer as a Non Addressable vServer. The NetScaler will send traffic to this vServer and hence the backend service on the users behalf.
Select the Service to bind and add the certificate then click done.
You will now have both vServers ready and running to accept Traffic.
If you want to automate this then use the commands below to set up your NetScaler Load Balancers. Be Sure to substitute the Server IP Addresses, Certificate Names and Store Names
add server web.bretty.local 192.168.0.108 add server xenmobile.bretty.local 192.168.0.60 add service web_server_port_80 web.bretty.local HTTP 80 -gslb NONE -maxClient 0 -maxReq 0 -cip DISABLED -usip NO -useproxyport YES -sp ON -cltTimeout 180 -svrTimeout 360 -CKA NO -TCPB NO -CMP NO add service xenmobile_port_80 xenmobile.bretty.local HTTP 80 -gslb NONE -maxClient 0 -maxReq 0 -cip DISABLED -usip NO -useproxyport YES -sp ON -cltTimeout 180 -svrTimeout 360 -CKA NO -TCPB NO -CMP NO add ssl certKey wildcard.bretty.me.uk -cert wildcardchain.key -key wildcardchain.key add lb vserver web_vserver_port_443 SSL 192.168.0.65 443 -persistenceType NONE -cltTimeout 180 add lb vserver xenmobile_vserver_port_443 SSL 0.0.0.0 0 -persistenceType NONE -cltTimeout 180 add lb monitor custom-storefront-monitor STOREFRONT -scriptName nssf.pl -dispatcherIP 127.0.0.1 -dispatcherPort 3013 -LRTM DISABLED -storename bretty add lb monitor custon-xenmobile-monitor TCP -LRTM DISABLED -destPort 8443 -secure YES bind service xenmobile_port_80 -monitorName custon-xenmobile-monitor bind service web_server_port_80 -monitorName custom-storefront-monitor bind ssl vserver web_vserver_port_443 -certkeyName wildcard.bretty.me.uk bind ssl vserver xenmobile_vserver_port_443 -certkeyName wildcard.bretty.me.uk bind lb vserver web_vserver_port_443 web_server_port_80 bind lb vserver xenmobile_vserver_port_443 xenmobile_port_80
So, onto the Content Switch, this is where the magic happens.
First Navigate to Traffic Management – Content Switching – Virtual Servers
Click to add a new Content Switch, Select SSL as the protocol to listen on and give it an IP Address. This will be the IP Address that you redirected your HTTPS traffic to on your firewall earlier.
Don’t bind any policies to the Content Switch just yet but DO add a certificate to the vServer
Your Content Switch vServer will now be running waiting for incoming HTTPS connections. We have not told it where to direct the traffic so at this point its pretty useless.
Open the Actions. This is where we will define what to do with the traffic when a policy rule is hit. For example where to send the traffic coming in on the URL ug.bretty.me.uk
Click to add an action for the NetScaler Gateway
Give it a name, select NetScaler Gateway Virtual Server from the drop down list then select your NetScaler Gateway from the Target vServer box then click done
Click again to add an action for the XenMobile Service. This time select Load Balancing Virtual Server from the drop down and select your XenMobile Load Balancing vServer from the Target Load Balancing Virtual Server selection box.
Repeat the XenMobile step for the Web Server. You should then have 3 actions to cater for each of the URLs you will be handling.
Next navigate to policies. This is where we will tell the Content Switch what URLs to listen for and what action to take if that URL is picked up in the incoming request hostname
Click to add a new Policy
Give it a name, select the relevant action, then in the expression add the following:
This is effectively telling the Content switch to redirect all traffic coming in on the URL ug.bretty.me.uk to be directed to the NetScaler Gateway.
Repeat this step for the 3 external URLs editing the expression each time to the URL in question.
Next we need to bind these policies to the content switch so it knows about them. Open the Content Switch and click where it says No Content Switching Policies Bound
Select your new policies to be bound to the Content Switch
Once all 3 are bound select done. Your Content Switch is now listening on port 443 for the 3 URLs you have specified and knows what to do with the traffic once it hits the Content Switch
You are ready to test now. However if you want to automate the Content Switch set up then here is the script to do it, again substitute the IP addresses and names to suit your environment.
add cs vserver content_switch_port_443 SSL 192.168.0.66 443 -cltTimeout 180 add cs action cs_action_netscaler_gateway -targetVserver netscaler_gateway add cs action cs_action_xenmobile -targetLBVserver xenmobile_vserver_port_443 add cs action cs_action_web_server -targetLBVserver web_vserver_port_443 add cs policy cs_policy_netscaler_gateway -rule "HTTP.REQ.HOSTNAME.SET_TEXT_MODE(IGNORECASE).EQ(\"ug.bretty.me.uk\")" -action cs_action_netscaler_gateway add cs policy cs_policy_xenmobile -rule "HTTP.REQ.HOSTNAME.SET_TEXT_MODE(IGNORECASE).EQ(\"mobile.bretty.me.uk\")" -action cs_action_xenmobile add cs policy cs_policy_web_server -rule "HTTP.REQ.HOSTNAME.SET_TEXT_MODE(IGNORECASE).EQ(\"storefront.bretty.me.uk\")" -action cs_action_web_server bind cs vserver content_switch_port_443 -policyName cs_policy_web_server -priority 100 bind cs vserver content_switch_port_443 -policyName cs_policy_xenmobile -priority 110 bind cs vserver content_switch_port_443 -policyName cs_policy_netscaler_gateway -priority 120 bind ssl vserver content_switch_port_443 -certkeyName wildcard.bretty.me.uk
Test the URL StoreFront
If you navigate to Content Switch – Policies you will see what policy is servicing the request
Test NetScaler Gateway
You can see all 3 policies have been used to redirect incoming requests
That’s it, hopefully this helps some of you out with your Single IP Address woes and gives you a basic understanding of Citrix NetScaler Content Switching.