I know the ZTNA is the new thing and I would love to see it extended to the NetScaler. Having said that, companies still use the SSL VPN, not quite dead yet. I believe the base connectivity for Citrix's ZTNA is the traditional SSL VPN client renamed to Secure Access Client or SAC. So let's have a look on SAC and client side tracing.
Client Machine Capturing
With the recent versions of the Agent, Wireshark cannot capture the traffic inside the tunnel of the Citrix Virtual Adapter when deployed as traditional SSL VPN with NetScaler. In the past capturing traffic on the Virtual Adapter will provide us the sessions inside the tunnel (towards the internal resources). This new behaviour is causing quite some troubles when you wish to troubleshoot the SSL VPN.
The ICMP is tunneled traffic on the screenshots below.
I do not believe it's a wireshark issue as this was perfectly working with versions before 22.10.1. Now you just see the encrypted SSL Tunnel.
You'll be able to observe only the SSL Tunnel (encrypted) between your IP and the Gateway IP.
You can use RawCap as alternative and stream the traffic to Wireshark. Somehow this tool is not affected by the changes made by Citrix. You can follow the below procedure. The tool is entirely portable although requiring Admin privileges.
- Download RawCap from RawCap - A raw socket sniffer for Windows (netresec.com)
- Run CMD as Administrator and navigate to the executable.
- Execute RawCap.exe –help to identify the Citrix VPN interface number:
- Execute RawCap.exe 0 - | “C:\Program Files\Wireshark\Wireshark.exe” -i - -k where “0” is the interface number.
- Wireshark should start automatically and read the VPN interface traffic.
Tips & Tricks
A few general recommendation if you're dealing with SAC:
- If you need to decrypt the client traffic, start a trace on NetScaler side with SSL keys enabled option and port the keys into the client-side trace of Wireshark.
- By default SAC uses the DNE drivers. I would recommend switching to the WFP driver & API of Windows. (DNE is considered legacy). To use the WFP driver for tunneling, admins must create the below registry entry (reboot required):
REG_PATH - HKEY_LOCAL_MACHINE\SOFTWARE\Citrix\Secure Access Client REG_TYPE - REG_DWORD REG_NAME - EnableWFP REG_VALUE – Set value to 1 to use WFP and 0 to use DNE (by default DNE is enabled if this registry value is not present or is set to 0)
- You can check the WFP load filters (including the ones from Citrix) by running the following command from elevated CMD
netsh wfp show filters file = <path_to_directory_output.xml>
- Client side registry keys here
- Be careful proving access to destination 172.16.0.0/16 CTX issue. The article claims it's fixed at v13.0 build 64.35 via NSHELP-23912 and the release notes confirms it, but in reallity the issue is still present. I would change the vpn session profile as below if using range 172.16.0.0/16:
set vpn sessionAction <ACTION_NAME> -fqdnSpoofedIP 169.254.0.0 -netmask 255.255.0.0
ZTNA deserves a detailed examination of its own amd I'll try to publish an article here in near future.
Thank you for reading!