# Citrix NetScaler ADC Architecture — nCore, Platforms & Packet Flow Source: https://ai.techclick.in/blog_citrix_netscaler_architecture_packet_flow Markdown: https://ai.techclick.in/blog_citrix_netscaler_architecture_packet_flow.md Publisher: Techclick Infosec Pvt Ltd Master Citrix NetScaler ADC architecture in 2026: nCore packet engine, MPX/VPX/SDX/CPX/BLX platforms, one-arm vs two-arm topologies, NSIP/SNIP/VIP address roles, USIP/USNIP modes, and the full client-to-server packet flow with L4-L7 feature processing. Citrix NetScaler ADC Architecture — nCore, Platforms & Packet Flow student learning map A visual study map for Citrix NetScaler ADC Architecture — nCore, Platforms & Packet Flow showing learning path, evidence, traps, and practice sequence. TECHCLICK STUDY MAP Citrix NetScaler ADC Architecture — nCore, Platforms... Citrix · learn the flow, prove with evidence, avoid unsafe shortcuts 1. Start 🎯 By the end you will be able to 2. Understand Pick where you want to start 3. Prove ① What NetScaler ADC is — full... 4. Practice ② NetScaler platforms — MPX, VPX,... How to use this page First build the mental model, then connect the concept to a realistic production decision. Finish by testing yourself. Techclick Infosec Pvt Ltd | ai.techclick.in | Training Contact: WhatsApp +91 92772 29456 Content-specific feature visual for this lesson: use it as the 60-second map before reading the full detail. Most engineers think… Most people assume NetScaler is 'just a load balancer sitting inline'. That mental model gets you a wrong answer in every architecture or troubleshooting interview question. NetScaler is a full-proxy application delivery controller . It terminates the client's TCP connection on a Virtual IP (VIP) , runs the traffic through its nCore parallel packet engines for L4-L7 inspection — SSL offload, content switching, AppFW, rewrite, compression — and then opens a brand-new TCP connection to the backend using a Subnet IP (SNIP) or, when USIP is enabled, the client's original source IP. Understanding that full-proxy split — and where NSIP, SNIP and VIP each live — is what separates a NetScaler architect from someone who just knows how to add a vserver. ## ① 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. Figure 1 — NetScaler full-proxy feature pipeline Every client packet traverses this ordered pipeline before NetScaler opens a fresh connection to the backend server. - NetScaler full-proxy feature pipeline Client TCP SYN to VIP nCore PPE L4 classify L7 Policies SSL/AppFW/rewrite LB decision pick backend Server TCP SNIP or USIP Every client packet traverses this ordered pipeline before NetScaler opens a fresh connection to the backend server. Quick check · Q1 of 10 · Understand NetScaler ADC is best described as a… a) Transparent L2 bridge that forwards frames without modifying them b) Full proxy that terminates the client TCP, runs L4-L7 features, and opens a new connection to the server c) Stateless router that rewrites destination IPs d) Passive IDS sensor that mirrors traffic Correct: b. NetScaler is a full proxy: it terminates the client TCP on a VIP, applies the nCore PPE feature pipeline (SSL, AppFW, content switch, rewrite), then opens an independent TCP connection to the backend. The client never talks directly to the server. 👉 So far: NetScaler ADC is a full proxy: it terminates client TCP on a VIP, runs traffic through the nCore parallel packet engine (SSL, AppFW, rewrite, LB), and opens a new connection to the backend. ## ② 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. Figure 2 — NetScaler platform comparison Choose the right form factor: hardware throughput vs flexibility vs multi-tenancy vs cloud-native. - NetScaler platform comparison Hardware (MPX / SDX) MPX: dedicated ASICs + crypto SDX: multi-tenant chassis Highest SSL TPS in class Best for large DC workloads Software (VPX / CPX / BLX) VPX: hypervisor or cloud VM CPX: container / Kubernetes BLX: bare-metal Linux NIC Best for cloud & DevOps Choose the right form factor: hardware throughput vs flexibility vs multi-tenancy vs cloud-native. ⚡ nCore tap to flip NetScaler's multi-core parallel packet engine. Distributes flows across all CPU cores so throughput scales linearly with core count. Each core owns its receive queue and PPE context. 🖥️ MPX vs SDX tap to flip MPX is a single-tenant hardware appliance with dedicated ASICs for maximum raw throughput. SDX is a multi-tenant chassis where each tenant gets its own isolated VPX-like instance with reserved CPU and memory. 🌐 VIP tap to flip Virtual IP — the address clients connect to. Bound to a virtual server (LB, gateway, content switch). Floats between HA nodes. The client never knows the real server IP. 🔄 USIP vs USNIP tap to flip USNIP (default): NetScaler opens the backend connection from a SNIP, hiding the client. USIP: NetScaler preserves the client source IP, so the backend sees the real client — but asymmetric routing must be solved. Platform choice in 30 seconds MPX = bare-metal throughput; SDX = multi-tenant hardware; VPX = hypervisor or cloud; CPX = containers or Kubernetes sidecar; BLX = ADC on your own Linux server. In an interview, the moment the question says 'cloud' or 'VM', say VPX. 'Kubernetes sidecar', say CPX. 'Twelve tenants on one chassis', say SDX. Quick check · Q2 of 10 · Apply Your organization runs 12 separate business-unit ADC instances on one physical chassis, each fully isolated with its own CPU, memory and bandwidth. Which platform is this? a) VPX on a hypervisor b) BLX on bare-metal Linux c) CPX in a Kubernetes cluster d) SDX — the multi-tenant hardware chassis Correct: d. SDX is the multi-tenant NetScaler hardware chassis. Each hosted instance is fully isolated with dedicated CPU cores, memory and bandwidth allocation — unlike VPX which shares hypervisor resources. 👉 So far: Five platforms: MPX (hardware ASIC), SDX (multi-tenant chassis), VPX (hypervisor/cloud VM), CPX (container), BLX (bare Linux). Match form factor to deployment context — not just 'whatever is available'. ## ③ 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. Figure 3 — Three NetScaler IP roles in every deployment NSIP manages the box; VIP faces clients; SNIP sources backend connections. Mix them up and nothing works. - Three NetScaler IP roles in every deployment NetScaler ADC nCore PPE NSIP (mgmt) VIP (client-facing) SNIP (backend src) One-arm (same VLAN) Two-arm (DMZ split) NSIP manages the box; VIP faces clients; SNIP sources backend connections. Mix them up and nothing works. Mixing up NSIP and SNIP breaks everything NSIP is management only — it never sources data-plane traffic. SNIP is the source for backend connections and is the address servers must route back to in one-arm mode. If you configure your server's default gateway to the NSIP instead of the SNIP, backend connections fail silently and health monitors go DOWN. ### ▶ Watch an HTTPS request flow end to end through NetScaler Step through a two-arm NetScaler ADC in USNIP mode handling an HTTPS load-balanced request. Press Play for the healthy path, then Break it to see the classic routing failure. ① Client SYN A browser sends a SYN to the VIP (e.g. 203.0.113.10:443). The NetScaler nCore PPE accepts it and completes the TCP handshake with the client. ▼ ② SSL Offload The PPE decrypts the TLS session using the certificate bound to the vserver. The request is now plaintext HTTP inside NetScaler — ready for L7 policy inspection. ▼ ③ LB + Policies Content switching, AppFW and rewrite policies are evaluated. A backend server (e.g. 10.0.1.5:80) is selected using the least-connection LB method. ▼ ④ SNIP Connect NetScaler opens a new TCP connection FROM the SNIP (10.0.1.1) to the selected server. The server responds to the SNIP — it never sees the client address. Press Play to step through the HTTPS request path. Then press Break it to see what happens when server routing is wrong. ▶ Play Next ▶ ⚠ Break it ↺ Reset Quick check · Q3 of 10 · Remember Which NetScaler IP address is used for SSH and GUI management and is NEVER used for data-plane forwarding? a) NSIP — the NetScaler IP (management address) b) SNIP — Subnet IP (backend source address) c) VIP — Virtual IP (client-facing virtual server) d) MIP — Mapped IP (legacy source NAT) Correct: a. NSIP is the single management address of the appliance — SSH, GUI, SNMP, and logs come from it. It is never used in the data path. VIP faces clients; SNIP sources backend connections. 👉 So far: Three IP roles: NSIP = management only; VIP = client-facing virtual server; SNIP = source IP for backend connections. In one-arm mode, servers must route responses back to the SNIP or sessions break. ## ④ 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. Figure 4 — USIP vs USNIP forwarding mode Default is USNIP (NetScaler SNATs to SNIP). Enable USIP only when the backend must see the real client IP. USIP vs USNIP forwarding mode USNIP (default) Source IP = SNIP on backend Server routes to SNIP Simple routing — no tricks Client IP via XFF/insert header USIP mode Source IP = real client IP Server must route via NetScaler Asymmetric routing risk No header insert needed Default is USNIP (NetScaler SNATs to SNIP). Enable USIP only when the backend must see the real client IP. Figure 5 — End-to-end USNIP packet flow — SYN to response Numbered sequence of a healthy HTTPS load-balanced request through a two-arm NetScaler in USNIP mode. End-to-end USNIP packet flow — SYN to response ① Client SYN to VIP:443 ② SSL offload PPE decrypts TLS ③ LB + policy select server ④ SNIP connect new TCP to server ⑤ Response merged & sent Numbered sequence of a healthy HTTPS load-balanced request through a two-arm NetScaler in USNIP mode. Priya at a Pune e-commerce firm faces this After a NetScaler was added in one-arm mode, backend application servers occasionally receive response traffic that bypasses NetScaler, causing RST storms and broken sessions. Likely cause In one-arm mode, backend servers need to route return traffic through the NetScaler SNIP. Some servers have a default gateway pointing directly to the core switch instead of the SNIP. Diagnosis Capture traffic on the server NIC — responses are going to the core switch gateway directly, not back through the SNIP. The NetScaler never sees the server's SYN-ACK and sends a RST. NetScaler CLI ▸ show ip / show route + server-side tcpdump on eth0 Fix On each backend server, set the default gateway to the NetScaler SNIP on that subnet (or add a host route for the VIP subnet pointing to the SNIP). In production, use a routing policy or DHCP option rather than touching each server manually. Verify Re-run tcpdump on the server: server response packets now go to the SNIP. RST storms stop, and session counts in 'show lb vserver' climb normally. Prove USIP is on with a packet capture Run a simultaneous tcpdump on the backend server NIC and on the NetScaler (nsconmsg or Wireshark via NSTRACE). In USNIP mode you see the SNIP as source; in USIP mode you see the client's real IP. Never assume a mode is on — capture and verify. The 'show ns mode' CLI command also lists all enabled modes. Quick check · Q4 of 10 · Analyze A backend web server logs client source IPs as the NetScaler SNIP instead of the real client address. What is the fastest fix that avoids changing routing on every server? a) Switch to USIP mode globally so NetScaler forwards with the real client IP b) Add a second SNIP on the client subnet c) Insert an X-Forwarded-For header via a NetScaler Rewrite policy and read it in the server app d) Disable USNIP and enable IP tunnelling Correct: c. Inserting an X-Forwarded-For (XFF) header with a Rewrite policy is the standard approach: USNIP stays on (simple routing, no asymmetric issues) and the backend app reads the real IP from the header. USIP works too but requires each server to route responses back through NetScaler, which is a heavier routing change. 👉 So far: USNIP (default): backend sees SNIP as source — simple routing, use XFF for real client IP. USIP mode: backend sees the real client IP — powerful but requires asymmetric routing to be solved on every backend server. ### 🤖 Ask the AI Tutor Tap any question — instant, scoped to this lesson. No login, no waiting. What is nCore and why does it matter? What is the difference between NSIP, SNIP, and VIP? When should I use SDX instead of multiple VPX instances? What is USIP mode and when should I enable it? What is the difference between one-arm and two-arm topology? At which stage in the packet flow does SSL decryption happen? Pre-curated from vendor docs + community Q&A, scoped to this lesson. For a live prod issue, paste your export into chat.techclick.in. ## 📝 Wrap-up assessment — six more You've answered 4 inline. Six left. 70% (7 of 10) marks the lesson complete on your profile. Tap Submit all answers at the end. Q5 · Remember Which NetScaler platform is best described as a software ADC that runs directly on a standard Linux server without a hypervisor? a) MPX — bare-metal hardware appliance b) CPX — container-based ADC c) BLX — bare-metal Linux software ADC d) SDX — multi-tenant hardware chassis Correct: c. BLX (Bare metal Linux) is a software NetScaler that runs natively on a Linux OS using standard NIC drivers — no hypervisor or hardware appliance needed. CPX is container-based; MPX is dedicated hardware; SDX is a multi-tenant chassis. Q6 · Understand In USNIP mode, which IP address does the backend server see as the source of incoming connections from NetScaler? a) The VIP (Virtual IP) that clients connect to b) The NSIP (management IP of the appliance) c) The real client source IP address d) A SNIP (Subnet IP) configured on the backend subnet Correct: d. USNIP mode is the default: NetScaler opens backend connections sourced from a SNIP assigned to that subnet. The server responds to the SNIP, and NetScaler bridges the two TCP sessions. The VIP is client-facing; the NSIP is management-only; the real client IP is only preserved in USIP mode. Q7 · Apply You deploy NetScaler in one-arm mode. After go-live, backend servers time out intermittently. What is the most likely cause? a) The VIP has no SSL certificate bound b) Backend servers route their responses to the core switch instead of the NetScaler SNIP c) nCore has only one active PPE d) The NSIP is in the same subnet as the VIP Correct: b. One-arm mode requires that server return traffic flows back through NetScaler. If servers use their default gateway (the core switch) instead of the NetScaler SNIP, their SYN-ACKs never reach NetScaler — NetScaler sends RSTs and sessions break. Fix: set the server default gateway to the NetScaler SNIP. Q8 · Analyze Why does NetScaler's nCore architecture improve throughput compared with a single-core packet engine? a) nCore moves all packet processing to a hardware ASIC that bypasses the OS entirely b) nCore compresses packets before processing to reduce CPU cycles c) nCore distributes flows across multiple CPU cores, each running its own PPE, so throughput scales with core count d) nCore caches repeated flows in RAM and replays them without re-processing Correct: c. nCore's key innovation is parallel-per-core Packet Processing Engines (PPEs). Each core receives its own flow queue and processes packets independently, eliminating the single-core bottleneck. Adding cores adds throughput linearly, which is why MPX hardware appliances can reach very high Gbps ratings. Q9 · Evaluate An interviewer asks: 'A backend app must log real client IPs, but enabling USIP globally would require re-routing 200 servers. What is the better solution?' Best answer? a) Enable USIP anyway — routing 200 servers is a one-time cost b) Insert an X-Forwarded-For header using a NetScaler Rewrite policy; the app reads the real IP from the header while USNIP routing stays simple c) Add a second VIP on the client subnet so servers see the real client network d) Upgrade to SDX which automatically preserves client IPs Correct: b. X-Forwarded-For header insertion via a Rewrite policy is the industry-standard approach. USNIP stays on (routing unchanged, no asymmetric risk), and the app code reads the real client IP from the XFF header. USIP would work but requires touching every server's routing, which is a heavier, riskier change. Q10 · Evaluate You need to run 8 fully isolated ADC instances for 8 different customers on a single physical device, each with its own bandwidth limit, dedicated CPU and memory. Which platform and why? a) VPX on a hypervisor — cheapest and most flexible option b) SDX — purpose-built multi-tenant chassis with per-instance hardware isolation c) CPX — one container per customer in the same Kubernetes namespace d) MPX — one hardware appliance handles all 8 customers transparently Correct: b. SDX is purpose-built for this: each hosted instance gets reserved CPU cores, dedicated memory allocation, and a capped bandwidth slice enforced at the hardware level — true isolation, not shared hypervisor resources. VPX on a hypervisor is cheaper but suffers from noisy-neighbour resource contention; MPX is single-tenant; CPX is for ephemeral container workloads. Submit all answers Try again Lesson complete — saved to your profile. Almost! You need 70% (7 of 10) — re-read the path that tripped you up and tap "Try again". ### 🧠 In your own words Type one line: what happens inside NetScaler between a client sending a SYN and the backend server receiving the first packet? Then compare with the expert version. Compare with expert answer Expert version: NetScaler's nCore PPE accepts the client SYN and completes a full TCP handshake on the VIP, decrypts TLS using the bound certificate, evaluates L7 policies (content switch, AppFW, rewrite), selects a backend server using the LB method, and then opens a brand-new TCP connection from the SNIP (or the client IP in USIP mode) to the server — the client and server TCP sessions are two separate state machines bridged inside the appliance. The server never sees the client directly. ### 🗣 Teach a friend Best way to lock it in — explain it in one line to a teammate. Tap to generate a paste-ready summary. Generate my one-liner 📩 Quiz me on this in 7 days. Opt in and we'll email 3 micro-questions on Citrix NetScaler (ADC) at Day 1, Day 7 and Day 30 — spaced repetition is how this sticks. Un-tick any time. ### 📖 Glossary nCore NetScaler's multi-core parallel packet-processing architecture. Distributes flows across all CPU cores, each running its own PPE, eliminating single-core bottlenecks. PPE (Packet Processing Engine) The per-core processing unit within nCore that handles TCP state, L7 inspection, policy evaluation, and session bridging for each flow. NSIP (NetScaler IP) The single management IP of a NetScaler appliance — used for SSH, GUI, SNMP and logs. Never used in the data plane. SNIP (Subnet IP) The source IP address NetScaler uses when opening outbound TCP connections to backend servers in USNIP mode. One SNIP per backend subnet. VIP (Virtual IP) The client-facing IP address bound to a virtual server (load balancer, SSL gateway, content switch). Clients connect to the VIP; they never know the real server address. USNIP mode Default NetScaler forwarding mode: outbound connections to servers use a SNIP as source. Servers must route responses back to the SNIP. USIP mode Use Source IP — NetScaler forwards with the real client IP to the backend. The backend can log real client addresses but requires asymmetric-routing to be solved. SDX Multi-tenant NetScaler hardware chassis that hosts multiple fully isolated ADC instances, each with dedicated CPU cores, memory, and bandwidth allocation. One-arm topology NetScaler connected to a single VLAN/interface for both client and server traffic. Requires servers to route responses back through the NetScaler SNIP. Two-arm topology NetScaler with separate interfaces for the client-facing (DMZ/public) and server-facing networks. Traffic flows in one leg and out the other — natural routing with clean security zones. #### 📚 Sources Citrix Docs — Common network topologies: one-arm and two-arm (NetScaler 14.1) . docs.netscaler.com/en-us/citrix-adc/current-release/getting-started-with-citrix-adc/network-topologies - Citrix Docs — Architecture and traffic flow: NetScaler CPX 14.1 (nCore PPE, platform comparisons) . docs.netscaler.com/en-us/citrix-adc-cpx/current-release/cpx-architecture-and-traffic-flow - Citrix Support — FAQ: USIP address mode of NetScaler (CTX121974) . support.citrix.com/s/article/CTX121974-faq-usip-address-mode-of-netscaler - Citrix Docs — Best practices for network configurations — SNIP, NSIP, routing . docs.netscaler.com/en-us/citrix-adc/current-release/networking/best-practices-network-configurations - Citrix Docs — Using SNIP (USNIP) mode and configuring subnet IPs for backend connectivity . docs.netscaler.com/en-us/citrix-adc/current-release/networking/ip-addressing - Citrix Community — Reference Architecture: Application Delivery Management — Core ADC use cases . community.citrix.com/articles/netscaler/netscaler-adm ### What's next? Got the architecture and packet flow locked in? Next, go deep on NetScaler SSL offload and content switching policies — learn how SNI-based switching, certificate bindings, and traffic policies work together to route HTTPS traffic to the right backend pool. Next · All interview lessons → Practice on exam.techclick.in → --- Cite this Techclick lesson with the source URL. Do not invent fees, batch dates, or job guarantees. Browse all lessons: https://ai.techclick.in/blogs AI index: https://ai.techclick.in/llms.txt