NetScalers

Every HA pair as one unit, from the first poll. Reading over SSH and NITRO, state changes from the syslog in seconds; changes over NITRO, where you license them.

HA pairs

as one unit

primary and peer, both nodes' clocks

State changes

seconds

the syslog detects, the appliance confirms

Virtual servers

24 up

in the estate shown here

Analyses

restart, failover, HA, health, crash history, SAML, capture

Forensics

bundles

crash, resources, compromise

One page for every appliance

The head names both HA nodes with their roles and two clocks each, so a software restart shows apart from a reboot. Under it: the figures that matter, the resources card, and the topology drawn in state colours — green up, orange disabled, red down, amber partly up — with a legend that names only the kinds drawn. What needs attention and what changed sit beside the diagram. The sidebar unfolds the appliance, as a XenServer pool does, into its sections with each kind’s total and what is down, and a kind picked there opens as a tab that stays; the tabs are remembered for each person. The top of the page is kept to two short rows so the topology has the window; its head folds to one line and the diagram stays. Open GUI and SSH in the browser (a terminal in the page, the host key pinned, administrators only) sit in the More menu, and both work through the cloud management console too. Right-click any object for its actions, a service group member to enable or disable it, or the appliance itself for its HA configuration and a forced failover — offered only when the last reading shows one Primary and one Secondary. Poll now reads that appliance alone, and the page stays where it was.

Vantage — an appliance page: both HA nodes in the head, the resources card, the topology in state colours

Click to zoom

Vantage — theater mode with a service group picked: its members and what binds it

Click to zoom

Vantage — the appliance's own menu: HA configuration and Force failover

Click to zoom

Vantage — every kind opened stays open as a tab

Click to zoom

The live demo opens the same appliance: the appliance page.

Where the traffic goes

The topology shows what is configured; the traffic flow beside it shows where the packets would go. Each virtual server is followed to the servers it reaches, and each server to the path the appliance would take — a PBR, a route or a subnet it is on — with the next hop and the SNIP, VLAN and interface it leaves by. It is worked out from the running configuration and the routing, ARP and PBR tables the last poll read, in the appliance’s own order of decision, and whether a server answers is only what the appliance’s monitors said. GSLB gets a diagram of its own, as what it is: a DNS answer. Both diagrams open in a new tab or download as one interactive HTML file, to attach to a change request or hand to a colleague; nothing in the copy contacts anything.

Vantage — the traffic flow: one virtual server followed to its servers, the subnet that reaches them and the SNIPs they leave by

Click to zoom

Vantage — the appliance topology with every member shown

Click to zoom

Vantage — focus on one virtual server's path: appliance, virtual server, service group, members

Click to zoom

Vantage — the topology downloaded as one interactive HTML file

Click to zoom

State in seconds, and confirmed

A poll every five minutes means a service can be down for five minutes before anyone sees it. Vantage reads the appliance’s own syslog as it arrives: a DEVICEDOWN or DEVICEUP line is a hint, never an alert, because a UDP datagram can be lost or forged. Vantage asks the appliance at once — over NITRO for that one service where NITRO is on, otherwise by polling that appliance — and the answer is what is stored and alerted on, and what the page draws within seconds. A configuration command in the syslog has the appliance read again, so the lists and the diagram follow a change made anywhere. Appliances whose syslog carries state changes are polled for states every 15 minutes and for the full inventory hourly; one that goes quiet falls back to polling and says so. Event channels shows what each appliance actually sends before you rely on it. The same syslog carries the warning signs of a crash: the watchdog reaching a daemon’s restart limit, the authentication daemon nsaaad dying again and again, a sign-in line carrying shell commands — each becomes one notification as it arrives, and every poll lists the crash-dump folders on both nodes, so a new dump is a notification even when no line came.

Vantage — the syslog fast path: each hint with what became of it, and how each appliance is polled

Click to zoom

Event channels: the watchdog giving up on nsaaad and a sign-in carrying shell commands, each one notification as the lines arrive

Click to zoom

Vantage — Event channels: what each appliance sent over the last seven days, state-change lines counted apart

Click to zoom

Vantage — Appliance management: a row per HA pair with connection, collection, access and last poll

Click to zoom

Vantage — editing an appliance in the panel beside the list

Click to zoom

Analyze: a verdict, not a log

Ask why an appliance restarted and get an answer with its confidence and evidence, from both nodes' clocks, the syslog held on Vantage, the appliance's own audit log, crash dumps and the previous run's event log. Pick a scenario.

When something went wrong: forensics

Upload the bundles show techsupport writes — one appliance, both nodes of a pair, or several bundles of one appliance taken days apart — and get three answers with the lines that support them: why it crashed or restarted, what was using its resources, and whether anything points at a compromise. Each is a conclusion that is never stronger than its evidence, with what it cannot tell you said beside it. Every address in the logs is one record with what it did and the tools it likely used; every command typed at the CLI or the shell is listed with what it likely does; a gap in the logs is said as a gap, not read as quiet. The bundles are not kept: they are read and deleted, and the analysis is what stays. For an appliance Vantage is already connected to, no bundle is needed: the Appliance analysis workflow reads each node live over SSH and runs the same analysis, on demand or every week, and sends the report only when something needs review if you prefer. The integrity check reads the appliances themselves, and runs inside a report too.

Checked against what attackers actually did. The Google Threat Intelligence Group’s advisory of 29 September 2026 (CVE-2026-88772, fixed in 14.1-73.37 and 13.1-64.23) found web shells in the gateway’s plug-in folders, an httpd.conf alias serving one behind an icon’s address, answers disguised as 404 pages, a Python tunneler, a setuid shell and a failed DTLS handshake just before the packet engine crashed. Vantage looks for every one of them, in a bundle, live and in the integrity check, and says two or more together as that campaign. A build below the fix is said as exposure, apart from the signs.

And what Citrix’s own scanner looks for. A guard in httpd.conf switched off by commenting it out, the web server’s account running anything but the web server, crash dumps deleted, and memory leaked into ns.log past a buffer. What the firmware does on its own is told apart and never raised: an upgrade’s writes, the GUI’s hourly job, a restart you asked for, and any change window you name. Vantage is not a replacement for Citrix’s script: run both.

Vantage — Support bundle analysis: the analysis summary

Click to zoom

Vantage — findings grouped by rule with severity, confidence and review status

Click to zoom

Vantage — every address in the bundle with what it did and its likely tools

Click to zoom

Vantage — the traffic flow drawn from the bundle

Click to zoom

Vantage — a support bundle of the September 2026 campaign's shape: the verdict and the next steps

Click to zoom

Vantage — the integrity check: the campaign's signs named on the node that has them, the build below the fix said apart

Click to zoom

Vantage — the Appliance analysis workflow: every node read live, no bundle collected

Click to zoom

The bundles shown here are synthetic, built with the line shapes of real ones; the screens are the product’s own.

Stopping attackers on the appliance itself

Seeing an attack is half the job. Vantage writes the block onto the NetScalers you choose, as rules: each rule covers whole appliances or chosen virtual servers, picks how it drops a source address, and can be switched off, rolled back or deleted — the objects it made are removed from the appliances it covers, read live. Before anything is written you see the exact NITRO commands it will send; a Save is applied in the background and shown as a task, with the appliances it reaches and how far it has got. An HA pair is one unit: the primary is written, the peer follows. Writing to the appliances needs NetScaler Configuration.

A block list you keep. A Manual rule holds its own hand-added addresses, each with a note saying why — typed, pasted or imported from a file. They are written to a data set on the appliance with one global drop policy, so the block holds even while Vantage is down. Remove an address in the rule and Save: the change goes only to the appliances that rule reaches.

A list Vantage learns. An Automatic rule blocks the addresses Vantage learns from the gateways’ own syslog, and you choose what it blocks for: repeated failed sign-ins, password spraying across accounts, Application Firewall blocks, and forged SAML sign-ins (a SAML response in the address). The appliance does not hold these addresses; it asks Vantage about each client through an HTTP callout to a port of Vantage’s own, reached through a monitored virtual server. If Vantage stops answering, the monitor marks it down and requests are let through: the callout fails open, by design. Where Integrated Caching is licensed, each answer can be kept on the appliance for a set time.

NetScaler’s own IP Reputation. A Webroot rule turns on the appliance’s built-in IP Reputation (included with NetScaler) and drops the threat categories you tick. An appliance that cannot reach the internet downloads the reputation database through a proxy Vantage runs: it relays only to Webroot’s download servers, cannot read what it carries, and its health and the appliance’s own iprep.log are shown beside it.

The shared reputation list. A callout rule asks Vantage whether an address is on its shared block list — what the Windows servers and the gateways blocked, and any reputation database you subscribe to in Block mode, such as the list the Vantage licensing portal publishes. Trusted and internal addresses are never on it.

Named NetScaler policies. Each rule’s drop is a responder policy, and the parts are yours: drop or reset, priority, bind point, and conditions on the request — URL path, query, method, host, a header, the user agent or the virtual server’s port, matched all or any, each one negatable. Make several policies per method and pick one per rule. A condition can only narrow what is dropped, never widen it, and every value is checked before it reaches the appliance.

What was dropped, from where, at which VIP. Turn drop logging on and every dropped request is attributed to the rule that dropped it, its source address and the virtual server it was aimed at. The Security page lists each rule as a card — what it holds, what it dropped, the busiest sources first — and falls back to each policy’s own hit counter on the appliance where nothing was logged. Whether each appliance’s callouts are actually being answered is shown per appliance, never assumed from silence.

Vantage — the enforcement rules, with one open in its editor: method, targets and what it blocks for

Click to zoom

Vantage — named NetScaler policies with their request conditions, action, priority and bind point

Click to zoom

Vantage — Security integrations: the Webroot download proxy, the IP lookup and the reputation databases, Vantage's own self-learned and hand-added lists first

Click to zoom

NetScaler / ADC

NetScaler Monitoring

Every NetScaler you run, HA pairs as one unit, read over SSH and NITRO REST. Fleet totals open the objects they count, and each appliance has one page: both nodes’ roles and clocks in its head (a software restart shows apart from a reboot), the resources card, what needs attention and what changed beside a topology drawn in state colours — green up, orange disabled, red down, amber partly up, with a legend — and every kind you open kept as a tab, remembered for each person. Right-click any object for its actions, or the appliance for its HA configuration and a forced failover. Beside the topology, the traffic flow shows which servers each virtual server reaches and by which PBR or route, and either diagram opens in a new tab or downloads as one interactive HTML file. State is event-driven: a DEVICEDOWN or DEVICEUP in the appliance’s syslog is confirmed over NITRO or by a poll and on the page within seconds, while an appliance whose syslog goes quiet falls back to polling and says so.

Fleet totals and a sortable appliance table grouped by site or category; any fleet row opens with the appliance page’s own detail and right-click menu
Poll now reads that appliance alone and the page stays where it was: the same tabs, zoom, picked object and scroll
Topology in state colours, the traffic flow beside it, both exportable as interactive HTML
A syslog line is a hint, never an alert, until the appliance confirms it; the confirmation raises the one event
Appliance management: a row per HA pair, pause and resume collection, an edit panel beside the list, and what each appliance sends as syslog events and SNMP traps
Certificates across every appliance, expiry first; notifications for state changes, HA role changes and failed polls

An appliance page: both nodes' roles and clocks in the head, the resources card, the topology in state colours with what needs attention and recent activity beside it, and the appliance unfolded in the sidebar into its sections

Click to zoom

The traffic flow beside the topology: one virtual server followed to its servers, the connected subnet that reaches them and the SNIP and VLAN they leave by, from the last poll

Click to zoom

Theater mode with a service group picked: its members, what binds it, and Capture & analyze in the box over the graph

Click to zoom

The appliance's own menu: HA configuration and Force failover, offered only when the last reading shows one Primary and one Secondary

Click to zoom

Every kind opened from the tree or a card stays open as a tab, remembered for each person

Click to zoom

The topology downloaded as one interactive HTML file: pan, zoom, search, and a click shows what an object binds and is bound under

Click to zoom

The fleet overview: a virtual server opened in place with the appliance page's own drill-down, history, path and config, and the same right-click menu

Click to zoom

Appliance management: a row per HA pair with its connection, collection mode, access and last poll

Click to zoom

The Explore grid opens each tile in place: here the Certificates tile with the SSL cert diagnostics run (expiry, chain, bindings, orphans)

Click to zoom

Certificates across the estate: expiry buckets, trust, key strength and a renewal calendar

Click to zoom

Verdicts

Analyze

Ask the question you actually have. Restart analysis reads both nodes’ clocks, the syslog held on Vantage, the appliance’s own audit log, crash dumps and the previous run’s event log, and says what most likely happened — an upgrade, an operator command, a crash the watchdog recovered — with a confidence and the evidence. Failover analysis explains every role change over the last 90 days. HA analysis and Health and capacity judge the pair and what is climbing over 7, 30 or 90 days. Crash history lists every crash dump found on both nodes — which program died, how often, crash loops, the firmware it ran — and SAML protection checks every authentication and VPN virtual server with SAML against Citrix’s PrefixList responder policy, with the commands for the ones that are not protected and a way for administrators to apply them.

A verdict first, the records behind one button
Firmware compared before and after every event
Run across many pairs at once from the Analyze view
Capture & analyze: a packet trace started, stopped, read and deleted on the appliance over NITRO, scoped to the virtual server you picked, with a verdict that tells the client side from the server side

Click to zoom

Restart analysis: an operator ran reboot, found in the syslog the appliance sent

Click to zoom

Restart analysis: an upgrade, from the firmware history before and after the start

Click to zoom

Crash history: nsaaad in a crash loop on both nodes, with the dumps and the firmware

Click to zoom

SAML protection: which front ends with SAML have Citrix's PrefixList policy bound, and the commands for the rest

Click to zoom

Capture & analyze: a trace taken on the appliance over NITRO for one virtual server, deleted from the appliance afterwards, and its verdict telling the client side from the server side

Click to zoom

Forensics · Utilities

NetScaler Forensics

Support bundle analysis reads the bundles show techsupport writes — whole or in parts, one appliance or both nodes of a pair, several of one appliance read as a timeline — and answers three questions with the lines quoted: why it crashed or restarted, what was using its resources, and whether anything points at a compromise. Every address in the logs is one record with what it did, where it is, its reverse name and the tools it likely used; every command and every shell command is listed with what it likely does; the firmware before and after an upgrade is read from the appliance’s own install records, and the traffic flow is drawn from the bundle. For an appliance Vantage is connected to, no bundle is needed: the Appliance analysis workflow reads every node live over SSH, runs the same analysis on demand or on a schedule, and sends the report every time or only when something needs review. The integrity check reads every node of the appliances you pick for the signs found on compromised NetScalers and compares nodes of the same build.

A verdict per question, never stronger than the evidence, and the gaps in the logs said as gaps
Checked against the September 2026 exploitation of NetScaler Gateway (CVE-2026-88772): web shells in the plug-in folders, the aliases and handlers that serve them, disguised 404s, the published addresses, the tunneler, a failed DTLS handshake followed by a crash; two or more together are said as that campaign
Four checks Citrix’s own IOC scanner also makes: a web server guard commented out, the web server’s account running other programs, crash dumps deleted, memory written into ns.log past a buffer
What you changed is told apart: an upgrade’s own writes, the GUI’s hourly job, a restart you asked for, and a change window you name
Findings numbered and grouped by rule, with severity, confidence and your own review status
A report with a one-page assessment first and the evidence appendix after, and CSV of every address and command
The bundles are not kept: they are read and deleted, and the analysis is what stays

Support bundle analysis: security, restarts, resources and evidence coverage, each a conclusion with its limitation and next step

Click to zoom

Findings numbered and grouped by rule, with severity, confidence and your own review status

Click to zoom

Every address in the bundle's logs: what it did, whether it was answered, and the tools it likely used

Click to zoom

The traffic flow drawn from the bundle itself: which servers each front end reaches and by which path

Click to zoom

A support bundle of the September 2026 campaign's shape: the web shell, the alias that serves it, the named address and the crash after a failed DTLS handshake, said as that campaign

Click to zoom

The integrity check: every node read over SSH, the signs of a compromised NetScaler named with their evidence, and the build below the fix said as exposure apart

Click to zoom

Management · licensed separately

NetScaler Configuration

The changes you make in the appliance’s GUI, from the Vantage tile instead. Right-click a virtual server, content switch, gateway, service or service group for enable, disable, bind and unbind, save config, and a property editor drawn from the appliance’s own object model — the GUI’s sections, the SSL side, every binding list, policies, actions and profiles. Apply sends only what differs from a fresh read.

Over NITRO, the appliance’s own API — a firmware update moves the object model, not text parsers
A separate read-write account, used only for explicit actions, never for collection
Certificate upload, gateway sign-in blocking, AppFlow setup from the same place
Enable or disable a service or a service group member from the topology; the diagram shows the change as soon as the appliance confirms it
Every change is a log row and an audit line

The object editor on a load balancing virtual server

Click to zoom

A gateway's running-config lines as the appliance printed them

Click to zoom

Protection

NetScaler Security

The gateways’ side of the Security page, under Data analytics: the same investigation page the Windows servers have, read from what the appliances already send. It answers four questions first — are we under attack, are the protections stopping it, has a sign-in got through after failing, and are the appliances enforcing — then the attack map, the attack sources with the accounts they tried and the syslog lines behind them, the block list and an event explorer. Under it, what each enforcement rule holds and what it dropped, from which source, at which virtual server.

Where attacks come from, placed by the geolocation database installed with Vantage
Addresses the Application Firewall blocked, and SAML responses sent in the address, counted beside failed sign-ins
Block or trust an address by hand, with a reason; the rule, the commands and the configuration changes are on the same page
A shell command typed into a sign-in field is raised as an attack, with where its source address can be found

Vantage — Data analytics › Security for the gateways: a card per rule with what it holds and dropped, by source address and virtual server

Click to zoom

Automation · licensed separately

Application Firewall workflow

Put NetScaler’s Application Firewall in front of the virtual servers you choose without writing the profile by hand. Pick the checks — SQL injection, cross-site scripting, command injection, buffer overflow, deny URL — and start in detect mode, which logs and changes no traffic, then move to block. The appliance’s own defaults block several checks the moment a profile is made; the workflow turns the checks you did not choose off, reads the profile back, and binds it only when it holds what you asked for.

Chosen LB virtual servers, content switches, gateways, or every HTTP and SSL virtual server; anything else is named and skipped
Each appliance’s profiles as it holds them, from the More menu: every check and its action
Roll back: unbind and remove, or unbind only, with a preview first
A run report of every step, in the appliance’s own words

Vantage — the Application Firewall workflow: the checks, detect or block, and the virtual servers it binds to

Click to zoom

Also on the NetScaler side

Documentation & reporting. Turn live state into shareable documents. Generate a standalone document for an appliance — topology diagram plus full text and tables — as HTML or PDF, from a live collection or an imported ns.conf. Build operations reports across one or more appliances for any date window; reports run as background jobs, so a month across a busy fleet finishes instead of timing out, and an optional AI pass adds prose summaries and findings. The operations report can list every enabled virtual server — load balancing, content switching and gateways — with its backends, each backend’s state and the SNIP the appliance uses to reach it; filter it inside the report by External or Internal VIP, type, protocol and state, or hide the backends for a plain list of VIPs. A gateway sign-in attacks section carries the attack map.

Config compare and migrate. Compare the running configuration between two appliances — an HA pair, or a production / DR set — to spot drift before it bites. Differences are highlighted side by side so a change on one box that never made it to the other is immediately obvious. When it is time to replace an appliance, Migrate config copies the old one’s configuration onto the new one verbatim, with the identity commands blocked and every line shown before it runs — from a live appliance or an imported ns.conf, with the certificate files taken from a folder, and secrets the old appliance encrypted with its own key left out by default.

A refused sign-in is not a quiet appliance. When an appliance refuses the monitoring account, each refusal is a notification on that appliance. After two in a row its automatic polling is held, so the account is not locked out on the directory, and tried again every hour; Try now or saving new credentials proves the fix at once. The count and the hour are settings.

Syslog you can narrow. The messages view filters by time (the last 15 minutes to 30 days, or a range), module, IP address, text the line must not contain and configuration changes only, over a full-text index, and shows the whole message. A notification’s “from the syslog” link opens on the exact line it came from.