Citrix NetScaler Traffic Domains ins and outs

Citrix NetScaler Traffic Domains are a way of segmenting network traffic for different applications or even tenants. You are able to use a traffic domain to create fully isolated network environments on a single NetScaler instance. An instance is a single appliance or a HA setup of two appliances.

Citrix NetScaler Traffic Domains were introduced with NetScaler 10.0. At first NetScaler Traffic Domains started as a somewhat hidden feature which you could only configure by CLI. As of version 10.1 Traffic Domains are fully configurable in the NetScaler GUI which makes it a lot simpler to use.

In a way NetScaler Traffic Domains could compete with the NetScaler SDX platform. With Traffic Domains we segment networks on a single NetScaler instance instead of the SDX where we create a virtual appliance per network segment.

A downside of using NetScaler Traffic Domains is the fact that some features are only supported for usage inside of Traffic Domain 0. Traffic Domain 0 is the default Traffic Domain, all services run inside Traffic Domain 0 unless explicitly specified.
An example of non supported features are NetScaler Management and NetScaler Gateway. For a complete list of supported features follow this link.
For non supported features for which you need isolation you have two options, NetScaler SDX or additional NetScaler appliances  (virtual or physical).

My expectations are that we will see more and more  features being supported on NetScaler Traffic Domains. An amazing feature would be to enable management functionality on Traffic Domains where you would only be able to manage or create services assigned to that Traffic Domain. This would be especially useful for multi-tenancy or multi management in situations where for example one team manages Mobility and one team managing a web application.

A few use cases Citrix describes for NetScaler Traffic Domains:

  • Use of duplicate IP addresses
  • Use of duplicate NetScaler entities
  • Multi Tenancy

A use case I’m actually using NetScaler Traffic Domains for is the ability to deliver services in a DMZ as well as an internal network.
Internal Network services like Microsoft Exchange Client Access Services and Microsoft App-V are heavy on traffic and I don’t like those services traversing the firewall in the DMZ. This also works great combined with Direct Server Return (DSR) which is blocked by most firewalls. Check out more on DSR combined with App-V on this article by Ingmar Verheij.

NetScaler Traffic Domains technical background

Before we start with implementing NetScaler Traffic Domains we need to get in to the basics of a Traffic Domain. Each Traffic Domain consists of:

  • vLAN
  • Subnet-IP
  • Routing
  • Services

One of the common mistakes while discussing Traffic Domains is that we also need a network interface per Traffic Domain. Although you can separate traffic by assigning Traffic Domains to interfaces on a one per one basis it’s not a requirement. Just like normal networking you can bind multiple vLANs to a single network interface.

A Traffic Domain is bound to at least one vLAN, a vLAN can only be bound to a single Traffic Domain. This is how a Citrix NetScaler actually isolates the network traffic. As explained, we can bind multiple vLANs to a single network interface. This means that, while binding that vLAN, we bind the Traffic Domain to a network interface.

As we have to configure a Subnet-IP (SNIP) per network a NetScaler connects to directly, we need at least one SNIP per vLAN. Without a SNIP we wouldn’t be able to reach a network gateway or connect to services directly.

As we isolate the network traffic, the routing table has to be configured per Traffic Domain. This is quite logical when you remember that Traffic Domains are isolated and therefore can’t reach a Gateway in a different Traffic Domain. The isolated routing table guarantees security by preventing traffic “accidentally” bypassing a firewall.

How to implement NetScaler Traffic Domains

Lets start with the use case. We want to offer services to internet users from within a DMZ as well as services for internal users. We need to isolate the network traffic for internal services and external services.

Citrix NetScaler Traffic Domain Design


As shown in the design we have the external services in the DMZ (Grey Colour) which routes through an internal and external firewall. The internal services (blue color) route or connect directly to back-end services.

One of the external services is “NetScaler Gateway” and as explained in this article NetScaler Gateway is only supported in Traffic Domain 0. We also know that we can only perform NetScaler management tasks in Traffic Domain 0.

The internal services will be running in Traffic Domain 1.

Implementation of all the services in Traffic Domain 0, like management and NetScaler Gateway, is just like every other NetScaler implementation. To keep things simple I’ll skip this part and we’ll assume everything in Traffic Domain 0 is running.

When we start implementing Traffic Domain 1 (remember the blue colors) we start with creating a vLAN. We’ll just use one vLAN but you can of course implement as many as you want. Well, there are limitations but I would love to see the use case where that becomes an issue;).

Open the Citrix NetScaler vLAN menu

Citrix NetScaler VLAN Menu

Citrix NetScaler VLAN Menu

Create a vLAN

Citrix NetScaler Create VLAN

Citrix NetScaler Create VLAN

The next step is binding this vLAN to Traffic Domain 1. Create the Traffic Domain and bind the vLAN to the created Traffic Domain.

Open the Citrix NetScaler Traffic Domains menu

Citrix NetScaler Traffic Domain Menu

Citrix NetScaler Traffic Domain Menu

Create the Traffic Domain and select the vLAN we just created.

Citrix NetScaler Create Traffic Domain

Citrix NetScaler Create Traffic Domain

Now that the Traffic Domain is in place implement the required Subnet-IP and routing tables.

Open the Citrix NetScaler IP Menu.

Citrix NetScaler IP Menu

Citrix NetScaler IP Menu

Create a Subnet-IP.

Citrix NetScaler Create Subnet-IP

Citrix NetScaler Create Subnet-IP

Notice the option where we can select the Traffic Domain. If you have never used Traffic Domains it probably is unnoticed but this is where we bind items to a Traffic Domain.

The screenshot below shows you that the first route for Traffic Domain 2 is automatically created by adding a Subnet-IP. You can create more routes manually, just don’t forget to select Traffic Domain 2.

Citrix NetScaler Create Routes

Citrix NetScaler Create Routes

Now that the Traffic Domain is fully configured and everything is all set up and working we can add some services.

To keep things simple we’ll create an easy service that load balances a webserver on port 80.

Create the server, and again remind selecting the correct Traffic Domain.

Citrix NetScaler Create Server

Citrix NetScaler Create Server

Create the service based on the server we just created.

Citrix NetScaler Create Service 2

Citrix NetScaler Create Service 2

Create the Virtual Server based on the service we just created.

Citrix NetScaler Create vServer

Citrix NetScaler Create vServer

The End

If you have any questions, new use cases or just want to say hi, please feel free to leave me a comment.

A quick community shoutout to Kees Baggerman, Andy Morgan and Ingmar Verheij for their help and reviews.


Tagged , , . Bookmark the permalink.

About Barry Schiffer

Barry is an IT Architect with 15 years of IT experience. He has gained both a broad and deep knowledge in the sphere of IT. Throughout the years, Barry has developed into a specialist in the field of Microsoft Windows, Server Based Computing, desktop and server virtualisation.Barry is co-founder and member of the Board of the Dutch Citrix User Group.Barry is awarded with the Citrix Technology Professional award in 2015 and received the RES Software Valued Professional award in 2012.

11 Responses to Citrix NetScaler Traffic Domains ins and outs

  1. What’s important to add is that it’s crucial to disable Layer 2 mode (bridging), especially when combining DMZ and LAN traffic. If you don’t disable layer 2 mode the NetScaler will step over the firewall (just like in a two-legged setup).


  2. antal says:

    Hey Barry,

    Security officers will have an issue with opening up the network like that I guess, no? I would more seek multitennancy as the use case for traffic domains. Then again, Im only sales 🙁

  3. Matt Stanyon-Tall says:

    When adding the Virtual Server I get the error “Error while binding Services. The binding entities are having uncompatible tds”. Any ideas on why this would be? This is a clean build running I look forward to your reply pointing me in the right direction 🙂

    • Sounds like either the service or the server is not in the traffic domain you try to create the virtual server for.

      • Matt Stanyon-Tall says:

        Actually, the servers were using FQDNs rather than IP addresses….I guess because the DNS lookup would happen in TD 0 this was what was causing the error.

  4. Gavin says:

    Hi and thanks for the insight above – I have been creating traffic domains in practice but each requires a default route (next hop being the SVI of the connected layer 3 switch). I can only do this in the CLI but I wonder if this is the correct method to ensure traffic gets sent back out the correct VLAN interface. Or is some sort of routing table formed when data comes in?

  5. Paul H says:

    I have a similar scenario where I want to implement traffic domains to separate DMZ and internal services. Access Gateway is also in use, mandating domain 0. However, I don’t like the idea of having to put the management interface on the same network as the load-balanced DMZ hosts (to allow management return traffic to follow the same routes to the internal network management hosts). I suppose it could be put on a dedicated DMZ and use policy based routes, but it would have been much nicer if the management interface was in its own isolated domain (like a control plane on a Cisco router with VRFs) and had its own routing table.
    Admin Partitions (to be bundled as standard in the upcoming 11 release) might be an option for some to consider in split zone deployments.

  6. FH says:

    Great article but is there a way to LB the same exchange (or indeed any other service ) separately for internal and external users ? We have only 1 netscaler which sits in the DMZ….lack of finance!

    I have followed this article and setup the vlan, redefined the server objects by ip ( as it doesn’t allow the same fqdn ) recreated the services with new names and bound everything along with the Ssl certs to a new vip in vlan 2…..

  7. ghj says:


    Citrix states that ssl-offloading is not supported in non defalt traffic domain 0. Has any one tried to setup vserver with ssl-offload in non-default doman?

  8. Juan Medina says:

    I’m implementing a pair of HA MPX 5901 running the latest firmware, 12.0 Build 57.19. Has it been any improvement on the Traffic Domain or we still have the limitation that the NSIP as and the NS Gateway have to be on the same TD0?
    Our Network team has issues using the TD0 for Data Traffic and Management Traffic. We had created a channel with multiple vLANs (running on a LACP with 2×10 Gbps) on different Cisco switches in stack mode.
    We created 2 TD. TD1 for Citrix DMZ Publix on one vLAN and Citrix DMZ Private on another vLAN. TD2 was created for internal traffic. We have a L3 switch that is doing all the internal routing should be able to receive traffic from the DMZ Private and all internal traffic and move it accordantly.
    We got it partially running but some traffic was not coming through from the Public DMZ inside. We might have now to go and move the NS Gateway to TD0 as it is the supported implementation by Citrix. .
    Any feedback is greatly appreciated.

Leave a Reply