The Business Problem
A backend application team needed to block a specific hostname (SNI) from reaching a TLS-terminated backend while allowing every other legitimate hostname to pass through untouched. In this case, the requirement was to drop any TLS session where the client requested director1.cxaxxx.com and log the drop event with the client IP for audit purposes.
On F5 BIG-IP, this requires an iRule that manually walks the raw TCP payload byte-by-byte to parse the TLS ClientHello, locate the SNI extension, and extract the hostname all before the platform’s native TLS stack has even processed the handshake.
On Citrix NetScaler, this is native, declarative, built-in functionality. No scripting. No manual byte offsets. No TCP payload parsing.
The F5 Approach: Manual TLS Parsing in TCL
when CLIENT_ACCEPTED {
# Collect the first part of the TCP payload to inspect the TLS header
TCP::collect
}
when CLIENT_DATA {
# Initialize SNI variable
set sni ""
# Check if this is a TLS Handshake (Record type 22 / 0x16)
binary scan [TCP::payload] cSS tls_xaction tls_version tls_recordlen
if { [info exists tls_xaction] && $tls_xaction == 22 } {
# Binary parse to jump through the TLS ClientHello structure
# (Skips Record Header, Handshake Header, Session ID, Cipher Suites, and Compression Methods)
binary scan [TCP::payload] @43c tls_sessionlen
set offset [expr {44 + $tls_sessionlen}]
binary scan [TCP::payload] @${offset}S tls_ciphlen
set offset [expr $offset + 2 + $tls_ciphlen]
binary scan [TCP::payload] @${offset}c tls_complen
set offset [expr {$offset + 1 + $tls_complen}]
# Check if TLS Extensions exist
if { [TCP::payload length] > $offset } {
binary scan [TCP::payload] @${offset}S tls_extenlen
set offset [expr {$offset + 2}]
# Loop through extensions to find SNI (Extension Type 0x0000)
while { $offset < [TCP::payload length] } {
binary scan [TCP::payload] @${offset}SS ext_type ext_len
if { $ext_type == 0 } {
# We found the SNI extension!
# The actual string starts at offset + 9
# The string length is the extension length minus the 5 bytes of SNI sub-headers
set name_len [expr {$ext_len - 5}]
binary scan [TCP::payload] @[expr {$offset + 9}]A${name_len} sni_string
set sni [string tolower $sni_string]
break
}
# Move to the next extension (4 bytes for type+length fields, plus the extension data)
set offset [expr {$offset + 4 + $ext_len}]
}
}
}
# Evaluate the extracted SNI
if { $sni equals "director1.cxaxxx.com" } {
log local0. "Dropped L4 connection for restricted SNI: $sni from IP:[IP::client_addr]"
drop
} else {
# Release the payload and let it flow to the backend untouched
TCP::release
}
}The iRule below does the following:
- Collects the initial TCP payload on CLIENT_ACCEPTED
- Manually verifies the payload is a TLS Handshake record (0x16) and a ClientHello (0x01)
- Walks fixed byte offsets to skip the Record Header, Handshake Header, Session ID, Cipher Suites, and Compression Methods
- Loops through TLS extensions looking for extension type 0x0000 (Server Name Indication)
- Extracts the SNI string using manual offset math (offset + 9, length minus 5, etc.)
- Compares the extracted SNI against the restricted hostname
- Drops the connection and logs it if matched, or releases the payload to the backend if not
This works but it requires deep protocol-level TCL scripting, is fragile to any changes in TLS record structure, is hard to maintain, and is nearly impossible for someone without deep F5 iRule expertise to safely modify.
~40+ lines of imperative, byte-level TLS parsing logic.
F5 also offers a native, non-iRule path for this, Local Traffic Policies with an SNI condition which avoids manual byte parsing but is still a verbose, nested tmsh configuration (roughly 50 lines across two policy rules). Either path, F5 requires substantially more configuration than the NetScaler equivalent below.
The NetScaler Approach: Native SNI Evaluation, Not Manual Parsing
NetScaler evaluates the TLS ClientHello natively at the CLIENTHELLO_REQ bind point on the SSL vServer SNI is already a first-class, pre-parsed policy variable (CLIENT.SSL.CLIENT_HELLO.SNI). No manual byte offsets, no TCP payload walking.
Here is the actual working configuration from a production gateway VIP, restricting access based on SNI and forwarding legitimate mTLS traffic to a dedicated backend target:
The decision logic – the direct functional equivalent of the iRule
# Forward action for the legitimate SNI target
add ssl action act_fwd_mtls -forward lbvs_mtls_dir_target
# Policy: forward anything reaching this bind point to the mTLS target
add ssl policy pol_fwd_mtls -rule true -action act_fwd_mtls
# Policy: reset the connection if the ClientHello SNI matches the restricted hostname
add ssl policy pol_block_wrong_sni -rule "CLIENT.SSL.CLIENT_HELLO.SNI.EQ(\"director1.cxaxxx.com\")" -action RESET
# Bind both at the ClientHello stage, in evaluation order
bind ssl vserver lbvs_director_sni_block -policyName pol_block_wrong_sni -priority 10 -type CLIENTHELLO_REQ
bind ssl vserver lbvs_director_sni_block -policyName pol_fwd_mtls -priority 20 -type CLIENTHELLO_REQThat’s 5 lines of policy logic – 2 policies, 1 forward action, 2 bindings, doing exactly what the F5 iRule’s 35 lines of manual TLS parsing did: inspect the SNI at handshake time and branch the connection accordingly.
The supporting infrastructure
To make this a fully operational gateway, the config also stands up the front-end VIP and the mTLS backend target it forwards to:
add serviceGroup sg_mtls_director SSL_BRIDGE -maxClient 0 -maxReq 0 -cip DISABLED -usip NO -useproxyport YES -cltTimeout 180 -svrTimeout 360 -CKA NO -TCPB NO -CMP NO
add lb vserver lbvs_mtls_dir_target SSL_BRIDGE 0.0.0.0 0 -persistenceType SSLSESSION -cltTimeout 180
bind lb vserver lbvs_mtls_dir_target sg_mtls_director
bind serviceGroup sg_mtls_director 172.16.22.7 443
add service Always_UP_service_SSL 1.2.3.4 SSL 443 -gslb NONE -maxClient 0 -healthMonitor NO -maxReq 0 -cip DISABLED -usip NO -useproxyport YES -sp OFF -cltTimeout 180 -svrTimeout 360 -CKA NO -TCPB NO -CMP NO
add lb vserver lbvs_director_sni_block SSL 172.16.22.190 443 -persistenceType NONE -cltTimeout 180
bind lb vserver lbvs_director_sni_block Always_UP_service_SSL
set ssl vserver lbvs_director_sni_block -ssl3 DISABLED -dtls1 DISABLED -SNIEnable ENABLED
bind ssl vserver lbvs_director_sni_block -certkeyName cxaxxxwildcard -SNICertThis isn’t overhead unique to NetScaler – it’s the standard virtual server / pool plumbing that any ADC needs to have an operational gateway. The F5 iRule doesn’t show this layer because it assumes an LTM virtual server and pool already exist; it only shows the SNI-inspection logic attached to that vserver. So this infrastructure block is the fair NetScaler equivalent of “the LTM vserver and pool F5 needed but didn’t show” it’s not extra complexity NetScaler introduced.
Optional- Audit logging equivalent to the F5 log local0. line
If you also want to log the dropped SNI and client IP (as the iRule does with log local0.), pair the DROP policy with a responder-style audit message action or enable SSL logging with client hello parameters via set ssl parameter -defaultProfile ENABLED and NetScaler’s native audit/syslog policy binding again fully declarative, no scripting required.
The apples-to-apples comparison is 35 lines of imperative protocol-parsing logic vs. 5 lines of declarative policy logic both platforms need standard vserver infrastructure underneath, but only one of them makes you hand-parse a TLS handshake to read a hostname.
Proof It Works: Validated Against the Live VIP
Theory is one thing; here’s the policy actually enforcing SNI-based access control on lbvs_director_sni_block (172.16.22.190), tested with openssl s_client.
Test 1 - Wrong SNI (director1.cxaxxx.com) → connection reset
openssl s_client -connect 172.16.22.190:443 -servername director1.cxaxxx.com
CONNECTED(00000003)
write:errno=54The connection is torn down before any certificate is exchanged, zero bytes read, no handshake data. This is pol_block_wrong_sni firing its RESET action the instant the ClientHello’s SNI is evaluated, exactly as designed.
Test 2 - Correct SNI (director.cxaxxx.com) → full handshake, forwarded to backend.
openssl s_client -connect 172.16.22.190:443 -servername director.cxaxxx.com
CONNECTED(00000003)
...
New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384
Server public key is 2048 bit
...
Post-Handshake New Session Ticket arrivedA complete TLS 1.3 handshake, a certificate returned from the backend (CN = CXA-DDC1.cxaxxx.com), and a session ticket issued for resumption. This confirms pol_fwd_mtls is correctly forwarding matched traffic through to lbvs_mtls_dir_target.
The result: identical inbound VIP and port, two completely different outcomes, decided entirely by the SNI in the ClientHello, no application-layer logic, no custom scripting, just a 5-line native policy evaluated before the TLS handshake even completes.
The Takeaway
This is a great real-world example of a broader theme in Application Delivery Controller design philosophy: F5 often requires you to build capability through scripting (iRules/TCL), while NetScaler frequently offers the same capability as a native, first-class policy construct.
For a security or platform team, that difference isn’t cosmetic it directly impacts:
- Time-to-delivery for new access control requirements
- Operational risk (fewer custom scripts = fewer things that can silently break)
- Skill dependency (you don’t need a TCL specialist on-call to maintain SNI blocking rules)
- Auditability (declarative policies are easier to review than imperative scripts)
What took 40+ lines of manual TLS parsing on F5 took 5 lines of native SSL policy logic on NetScaler a good illustration of why platform-native protocol awareness matters when evaluating ADC platforms for migration or greenfield deployments
