The user gets connected to VPN successfully

After connection, the user can access HTTP sites on port 80 or even on non-standard ports, but unable to access RDP / SMB servers / https / any other non plain-text http applications through the VPN. 

However, the telnet connection to the same RDP / SMB server works on port 3389/445/443, but still cannot access.

Traffic policy with expression ns_true should not be avoided, as it can cause these type of issues. It is always recommended to limit the policy execution based on the requirement of the policy. 

For example, if the policy and it's associated action is for HTTP traffic, instead of having the policy expression as "ns_true" use an expression using port / IP address or a combination of both for which the policy is actually needed. 

Example 

"REQ.TCP.DESTPORT == 80" limits the traffic policy execution to TCP port 80 only
"REQ.IP.DESTIP == 1.1.1.1" limits the traffic policy execution to destination IP 1.1.1.1 only

---

Problem Cause

As the application doesn't work but telnet works, the problem is at layer 7

In this configuration, the Traffic policy was configured on the Netscaler Gateway VIP with expression "true".
The profile was of type HTTP,

Example (problematic configuration)
add vpn trafficAction trafficact1 http -kcdAccount xxxxx -SSO ON
add vpn trafficPolicy trafficpol1 ns_true trafficact1
bind vpn vserver <vserver name> -policy trafficpol1 -priority 90

With this configuration, the policy with expression ns_true will hit for all traffic, but the action being HTTP specific will fail to execute for non-HTTP traffic, due to this the traffic gets dropped and never forwarded to the back-end. 

Telnet to the affected Non-HTTP services works because it is just the three-way handshake and there is nothing to be processed.

A packet trace would show that upon receiving a client connection request (GET /CS) for a non-http back-end server resource one of two things will happen, sample flow below. (Note: the Gateway and Client communication can only be seen after decrypting the packet trace with appropriate keys)

Behavior-1
CLIENT >> GET /CS >> Gateway Vserver  (Request for connection to 1.1.1.1 on port 8890)
SNIP/IIP >> TCP [SYN] >> 1.1.1.1:8890
SNIP/IIP << TCP [SYN/ACK] << 1.1.1.1:8890
SNIP/IIP >> TCP [FIN/ACK]  >> 1.1.1.1:8890
CLIENT <<  HTTP 200 OK << Gateway Vserver  (Indicating tunnel established) 
CLIENT >> [App specific data/CLIENT HELLO] >> Gateway Vserver 
CLIENT <<  HTTP 400 Bad request << Gateway Vserver

OR

Behavior-2
CLIENT >> GET /CS >> Gateway Vserver  (Request to open connection to 1.1.1.1 on port 8890)
CLIENT <<  HTTP 200 OK << Gateway Vserver  (Indicating tunnel established) 
CLIENT >> [App specific data] >> Gateway Vserver 
CLIENT <<  HTTP 400 Bad request << Gateway Vserver

Citrix Article - NetScaler Unified Gateway Advanced Authorization Policy Support for UDP/ICMP/DNS Traffic