Category Archives: Netscaler

Arrow

Presentation: Netscaler Insight, a Brief introduction

insightheader

During another Great E2EVC Conference, my friend Ronnie Hamilton and I presented a session on the greatness of Netscaler Insight and we planned to share the following presentation afterwards as there were a number of sizing recommendations and figures that didn’t lend themselves to a presentation!

In this presentation you’ll find the following topics:

  • What is Netscaler Insight.
  • Demo of insight data natively from Insight manager.
  • What’s it available in (licensing).
  • Deploying Insight in 5 minutes.
  • Integrating it into director.
  • How can it be deployed.
  • What’s new in version 11.
  • Netscaler Sizing Considerations.
  • Insight Manager Sizing considerations.

Download link.

A big thank you to Ronnie and E2EVC for the great trip. See you soon!

 

Blocking the new Citrix VPN iOS connection to Netscaler gateway:

This is a fast publish article, more detail will follow.

We have discovered a potential security issue or undesired functionality with the new application release from Citrix titled Citrix VPN.

vpn

Description:

In situations where customers have netscaler gateways configured for client access from iOS devices (think integration with citrix receiver app on mobile devices) configured users can now download this application, point the application at your internet facing Netscaler Gateway and Achieve a VPN connection directly to your internal network providing their credentials.
Worryingly, where the Netscaler may be on the internal network, or not be restricted with access lists or firewall rules, the users will achieve internal connectivity via the IP Address of the Netscaler gateway and impersonate the gateway to browse the network.

Am I affected:

If you configured the Netscaler Gateway via the Wizard, used the XenMobile Access Wizard or have a configuration as above, your users will be able to utilise the VPN to achieve internal network connectivity. The best way to find out is to test.
Work around:
<-Disclaimer->
The work around may break current functionality whereby your environment may require the “Windows / MAC OS X” plugin type to function correctly. It is highly advisable that you speak with your Citrix partner / integrator if you are concerned about this issue or wish to make the change.
Work Around 1:
To work around this issue and to block any connections while we engage with Citrix, consider changing the Plugin Type to “Java”. This will block VPN connections.
Work Around 2: 
Bind the following statement, with action of “drop” to a global responder policy:
HTTP.REQ.HEADER(“User-Agent”).CONTAINS(“CitrixReceiver/NSGiOSplugin”)
more info here:
Credits of find:
  • Andrew Morgan – Initial functionality discovery.
  • Bobby Maher – Confirmation of functionality & session type work around.
  • Rick Roetenberg – Confirmation of functionality & responder work around.

The idiots guide to load balancing App-V LWS via a Citrix Netscaler:

I set about recently to load balance app-v lightweight streaming servers traffic across Netscalers. I found this task a little more tricky than I had hoped and decided it would be useful to break this task down to its most basic steps and publish this to help anyone else who needs to do this in future.

Despite great articles on Technet and hakabo.com, the sooner doesn’t have any fault tolerance for RTSP specific issues and focuses on the command line, which many administrators morbidly fear on the Netscaler. The later is geared at management servers which have slightly different requirements to LWS servers, the monitor recommended utilises commands which the LWS server does not support. Which results in downstate App-V servers at all times.

So below you will find an idiot proof guide (tested by this idiot) to marry two of my favourite pieces of technology into a kick ass solution.

What you will need:

  • Netscalers!
  • at least 2 App-V Light Weight streaming servers!
  • One netscaler Virtual IP address to load balance the traffic
  • About 30 minutes of time (including testing).

1: To start, take a note of the ip addresses currently configured on your App-V LWS servers.

2: Log into your wonderful netscalers.

First up, we’ll configure the monitor. This monitor will poll your App-V servers and ensure they are up and working.

3: From the configuration page, select Load Balancing > Monitors > Add:

4: Name the monitor something specific and easily identifed, then configure the below options:

  • type = RTSP
  • Interval =20
  • Destination port = 554

5: Click the Special Parameters tab, Then set the below values:

  • RTSP Request = Options *
  • Response Codes: 401

(yes yes, 401 is an error response, but the LWS server has to be actively accepting connections to throw this error)

6: Once finished, hit Create:

And that’s it, monitor configured!

Next, we’ll create a service group, this service group is a logical collection of our App-V servers. Here we will configure the ports and monitoring configuration to catch outages.

7: Browse to Load Balancing > Service Groups, then choose Add:



8: Name the Service group something specific and easily identifed, then define the following options:

  • Protocol = Any

9: Enter each IP address of the App-V server, ensure to choose * as the port and click Add. Repeat this step for each subsequent App-V server.

10: Once you’ve entered all your IP addresses, it should look as below: (ip addresses omitted)

11: Now flick to the Monitors tab and select the service group we created earlier:

12: Once finished, save your changes, the service group is done.

We’re on the home straight, now we’ll tie it all to a virtual IP and configure the load balancing specific settings:

13: Now to the Virtual server, browse to Load Balancing > Virtual Servers > Add.

14: Name the Virtual Server something specific and easily identifed, then define the following options:

  • Protocol = Any
  • IP address = the virtual ip address to be hosted by the netscaler.
  • Port = *

15: Flick to the Service Groups tab, then select the service group we just created:

16: Flick to the Method and Persistence tab, then configure the following options:

  • Method = Least connection
  • Persistence = Source IP
  • ipv4 Netmask = 255.255.255.255

17: Now flick to the Advanced tab, then configure the following options:

  • Redirection mode = IP Based

Thats it, we’re done! time to test.

18: Open up a telnet client, and attempt to telnet to the newly configured virtual server:

19: If all has gone to plan, the window should empty its contents and appear as below:

20: Now go celebrate your success and genius. If for some reason it has not worked, feel free to drop a comment and I’ll see what I can assist you with.