Welcome to what I hope will be the first in a new series of blog articles, “Notes from the field!” Here, I plan to share NetScaler configuration issues, recommendations, and solutions for problems that I’m commonly seeing on customers’ sites.
The following are real issues impacting other real customers; hopefully this will be quite enlightening 🙂
Topics in this article
- L3 mode should be disabled (unless you can validate why it is required)
- Physical cabling and the use of LACP channels
- SNIPs and VLAN bindings
L3 mode should be disabled (unless you can validate why it is required)
To clarify a common misconception, L3 mode is not necessary for NetScaler to use the local routing table.
As can be observed within the NetScaler “Getting Started” documentation, the purpose of the L3 mode is to cause NetScaler to perform packet forwarding and to act as a router.
Enabling packet forwarding on an appliance connected to both a North and South bound network could allow an attacker, having compromised a computer in the North, to use the NetScaler as an unauthenticated route to the South, and to bypass firewall rules.
If the L3 mode is not required, it is good practice that it be disabled.
The behaviour of L3 mode can be observed in the packet processing diagram below.
Physical cabling and the use of LACP channels
Where NetScaler is connected to one network via multiple interfaces, it is recommended that an LACP channel or link aggregate be configured.
If this isn’t done, and multiple interfaces are connected to the same network, MAC addresses can move between ports and HA heartbeats will be lost. Additionally, the MAC address tables on the local switch may be in a constant state of flux, potentially leading to other issues.
The following graph (produced from newnslog files at a recent customer engagement) shows how frequently MAC addresses can move between ports when a channel is not used. Here 1/1, 1/4, and 1/5 were connected to the same VLAN.
SNIPs and VLAN bindings
SNIPs are bound to VLANs, VLANs are attached to interfaces; or they should be…
A not uncommon misconfiguration is for all SNIPs to be bound to the default VLAN, and the default VLAN connected to all interfaces.
While this may not be a problem if it meets the security model, it is certainly an issue if a two-arm mode was intended and the NSIP and internal only VIPs are now available on the DMZ.
When I see this, additional VLANs have often been created but due to an error or oversight, are not being used. We should take care to ensure that VLANs are configured corresponding to the design and that each has a subnet bound.
Additionally, it should be considered that many customers have security policies that would prevent one NetScaler instance having NICs in different Security Zones (one in the DMZ, one in the internal network), even if L3 mode is disabled and a proper VLAN binding has been created, as such a design bridges the firewall.
