NetScaler Gateway sends wrong Host-Header to StoreFront

In gewissen Konstellationen kommt es bei NetScaler Gateway Deployments trotz korrekter Konfiguration dazu das Requests an Storefront mit dem externen DNS-Namen des NetScaler Gateways an Storefront weitergeleitet werden.

Dabei scheint es sich um einen Bug im Build 11.1-51.21 zu handeln. Der Bug kommt jedoch nur dann zum Vorschein wenn im UserAgent „CitrixReceiver“ vorkommt. Dabei ist es irrelevant wie die Session Policies konfiguriert sind, daher vermute ich eine defekte Clienterkennung innerhalb des NetScalers.

Das ganze lässt sich nachvollziehen indem man z.B. mein NetScaler Nagios Plugin um einen UserAgent erweitert. Wie genau dieser lautet ist egal, solange irgendwo im String „CitrixReceiver“ vorkommt.

$lwp->agent("CitrixReceiver/MyTestClient");

Das Resultat in einem Test Setup mit einer Sophos UTM als Loadbalancing sieht folgendermaßen aus.

root@web01:/opt/check_netscaler_gateway 
-bash# ./check_netscaler_gateway.pl -H gateway.linux-dev.ext -u username -p password -v
** POST https://gateway.linux-dev.ext/cgi/login ==> 302 Object Moved
** POST https://gateway.linux-dev.ext/cgi/setclient?wica ==> 200 OK
** POST https://gateway.linux-dev.ext/Citrix/StoreWeb/Home/Configuration ==> 403 Forbidden
NetScaler Gateway CRITICAL - request to https://gateway.linux-dev.extCitrix/StoreWeb/Home/Configuration failed with HTTP 403

Der „fehlerhafte“ Request wird von der Sophos UTM als möglicher Angriffsversuch erkannt und geblockt. Das ganze könnte jedoch auch bei anderen Loadbalancern oder einem Setup mit aktiviertem SNI auftreten.

Als Workaround kann eine Rewrite Policy genutzt werden, die den Host-Header mit dem internen DNS-Namen ersetzt (z.B. storefront.linux-dev.local).

add rewrite action act_rewrite_hostname replace HTTP.REQ.HOSTNAME "storefront.linux-dev.local"
add rewrite policy pol_rewrite_hostname true act_rewrite_hostname
bind vpn vserver vs_vpn_citrix -policy pol_rewrite_hostname -priority 100 -gotoPriorityExpression END -type REQUEST

Diese Policy ersetzt den Header bei jedem HTTP-Request in das Backend mit dem korrekten Namen. Diese Policy funktioniert so nur in „ICA Only“ Deployments. Für Setups mit Smartaccess (Clientless VPN) sind weitere Anpassungen notwendig.