In some cases, users may need to deploy a full VPN solution as it allows a client to become a part of the internal network using the NetScaler Gateway plugin. With the use of the NetScaler Gateway plugin, we also have Endpoint analysis that allows us to scan a client for specific processes, or check if the client has antivirus active and configured. In version 10.5, Citrix added OPSWAT support. OPSWAT is a library that allows us to perform granular scans of an endpoint before it is allowed access.

Configuring the use of regular VPN with NetScaler Gateway is not much different from ICA Proxy. We need the following:

The only difference here is that we need to set the vServer to non ICA-mode and we need to change the session policy.

We can also add a pre-authentication policy to allow NetScaler to check client-side security before users are authenticated. This method makes sure that a device is compliant before being allowed to communicate with internal resources.

When we are creating the session profile, there are attributes that should be configured in the Client Experience pane. There are multiple settings that define how a VPN tunnel should behave, so it is important to know what each feature does. The settings are as follows:

There are some exceptions here. If the Split Tunnel option is disabled, it means that all endpoint traffic is routed through NetScaler. If it is enabled, it means only traffic that is destined for the internal network is routed through NetScaler. This also means that if the feature is enabled, we need to define which IP address or range of addresses the gateway should intercept. This is done using something called an intranet application, which is available as an option under the vServer pane. Here, we can define a range of IP addresses or a single IP address that the Gateway will intercept for the client. There are some differences here. For example, for Java-based clients, we need to define intranet applications as proxy-based, and for regular Windows/Mac clients, we need to define the intranet applications as transparent. We cannot combine these two types of intranet applications.

Also, should we require giving a connected client a dedicated IP address, we will have to define intranet IPs that will act like a DHCP server. Here, we can define a range of IP addresses that can be given to users. These intranet IPs can be bound to an AAA user, an AAA group, a vServer, or they can be bound at a global level. IP addresses that are bound to a user take priority over the other options.

Now, under the Published Applications pane, we need to define the following:

When users connect to this vServer now, they will be presented with a download option that allows them to download the NetScaler Gateway plugin, and they will be redirected to the StoreFront site.

As a part of NetScaler Gateway plugin, we have the option to perform scans on the client both as part of the pre-authentication policy process and as part of the security configuration session policy with a client security check, which has the option to place a client in quarantine group if, for instance, antivirus is switched off. The pre-authentication profile has the option to delete files on the computer or cancel processes before it is allowed connection. An example might be a client that is connecting where we have split tunneling switched off. The client connecting has a torrent client running, which consumes a large number of resources and will now start routing this traffic via the NetScaler. Using a pre-authentication policy, we can make the endpoint client scan for this and then shut down the process before the client is allowed to connect.

Up until now, we have only used the ns_true expression when defining policies. Now it is time to explore OPSWAT further, which we discussed briefly earlier. OPSWAT is an open source library that allows us to perform granular scans of expressions based upon, for instance, whether drive encryption is enabled or antivirus is running. OPSWAT can be run using a regular session policy or a pre-auth policy or as part of a security check.

When setting up a session profile under the Expression pane, we have an option called OPSWAT EPA editor. If we click on this button, we are given two options: Mac and Windows. From there, we have multiple options to choose from. For instance, if we choose Antivirus, then choose Generic Antivirus Product Scan, and then click on the + sign, we have the option to check if the device connecting has a specific version, has real-time protection enabled, and so on.

When we have configured a policy, we can also define frequency. If this is set to blank, the scan will only be performed once. Frequency scans only work on SSL VPN–based sessions.

Now, after we are done altering the expression, we can bind it to the vServer as show in the following screenshot:

This will allow users who have antivirus with real-time protection enabled access to the vServer. Clients who do not fulfill the expression requirements are not granted access, and thus they will not trigger the session policy.

Now, even though the VPN uses the NetScaler Gateway plugin to establish a connection, we still need Citrix Receiver to establish a connection to the Citrix environment and process ICA sessions. It is possible to integrate these two clients. If a user has Citrix Receiver installed previously and they then install the NetScaler Gateway plugin, they will get a new option under Citrix Receiver Applet | About | Advanced | Access Gateway Settings. From here, users can start a full VPN session directly using Citrix Receiver when they are connected by clicking on Login from the Access Gateway Settings option.

So after these settings are configured, you will have successfully configured a VPN solution on our Gateway. An important point to note is that in some cases, you may face issues with building a VPN tunnel. This issue occurs with some firewalls. In such a case, you may consider using MAC-based forwarding.