Citrix NetScaler ADC Architecture — nCore, Platforms & Packet Flow

① What NetScaler ADC is — full proxy on a parallel packet engine

NetScaler ADC is a full-proxy, L4-L7 application delivery controller. 'Full proxy' means it completely terminates the client-side TCP connection on a Virtual IP (VIP) and independently establishes a second TCP connection to the real server. The client never talks directly to the backend — every byte passes through NetScaler's feature processing pipeline.

That pipeline runs on nCore, Citrix's multi-core parallel packet-engine architecture. nCore distributes flows across all available CPU cores so that adding cores adds throughput linearly. Classic single-core designs created a bottleneck at one CPU; nCore eliminates that by giving each core its own receive queue and packet-processing context while shared memory ensures consistent policy lookups.

The feature stack applied in that pipeline includes SSL/TLS offload, content switching, application firewall (AppFW), HTTP rewrite and responder, compression, caching, TCP optimisation, and authentication. The same policy engine — nCore + the Packet Processing Engine (PPE) — handles all of them in order per flow.

② NetScaler platforms — MPX, VPX, SDX, CPX, BLX

Citrix ships NetScaler ADC in five distinct form factors, each optimised for a different deployment context:

The five platforms at a glance

• MPX — purpose-built hardware appliance with dedicated ASICs and crypto accelerators; highest throughput and SSL transactions per second; used in large data centres where raw performance matters.
• VPX — a software virtual appliance (OVA/hypervisor image) that runs on VMware, Hyper-V, KVM, XenServer or major clouds (AWS, Azure, GCP); flexible, easy to license, ideal for virtualised and cloud deployments.
• SDX — a multi-tenant hardware chassis that hosts multiple isolated VPX-like instances; each instance has its own dedicated CPU cores, memory, and bandwidth; used by MSPs and enterprises that need to consolidate many ADC tenants on one device.
• CPX — a container-based ADC running as a Docker image or Kubernetes sidecar; designed for microservices and CI/CD pipelines where an ADC must scale and tear down with containers.
• BLX — a software appliance that runs directly on a bare-metal Linux server (no hypervisor layer); it uses standard NIC drivers and is ideal when you want ADC performance on commodity x86 hardware without a dedicated appliance.

The interview rule: if the question involves hardware performance, say MPX; multi-tenant consolidation, say SDX; cloud or VM, say VPX; Kubernetes, say CPX; bare Linux, say BLX.

③ IP address roles and topology — NSIP, SNIP, VIP, one-arm vs two-arm

NetScaler uses three distinct IP address roles, and confusing them is the number one source of misconfiguration:

• NSIP — the appliance management address; one per NetScaler or HA pair; never used for traffic forwarding.
• SNIP — the source IP for backend connections (in USNIP mode); one SNIP per subnet where servers live; servers must be able to route their responses back to this SNIP.
• VIP — the virtual server address clients hit; can float between HA nodes; each service type (LB, gateway, SSL VPN) gets its own VIP.

One-arm vs two-arm topology

In one-arm mode the NetScaler connects to the network through a single VLAN or interface. Clients and servers are on the same network segment, and NetScaler uses the same interface for both directions. It is simple to drop into an existing network without touching routing, but return traffic must come back through NetScaler — usually achieved by setting the server's default gateway to the NetScaler SNIP. In two-arm mode NetScaler sits with one leg in the client-facing network (DMZ or public) and another in the server network. This is the classic 'in-line' model — traffic naturally flows in one side and out the other, security zones are cleanly separated, and there is no need for server gateway tricks.

④ Packet flow and forwarding modes — USIP vs USNIP end to end

Understanding the full packet journey is what interview panels test most. In the default USNIP mode the flow looks like this: (1) a client sends a SYN to a VIP; (2) the NetScaler's PPE accepts the connection and performs TCP handshake on behalf of the server; (3) the PPE classifies the flow, applies L4-L7 policies (SSL handshake, content-switch evaluation, AppFW, rewrite); (4) NetScaler selects a backend server using the configured load-balancing method; (5) it opens a new TCP connection from the SNIP to the server; (6) the server responds to the SNIP; (7) NetScaler merges the two TCP sessions and delivers the response to the client. The client always sees the VIP and never knows about the real server address.

In USIP mode (Use Source IP), step 5 changes: NetScaler forwards with the client's original source IP instead of the SNIP. This is useful when the backend application must log or act on the real client IP and NAT-based approaches (like XFF headers) are not supported. The trade-off is that the server must be able to route responses back through NetScaler, or asymmetric routing breaks the flow.

If both USIP and USNIP are enabled, USIP takes precedence. Modes are enabled globally or per virtual server. Monitoring probes (health checks) always use the NSIP or SNIP, even in USIP mode, so backend monitors are never exposed to client address space.