HTTPS SNI Monitoring How-to
Hi, You may or may not already have encountered a webserver that requires the SNI (Server Name Indication) extension in order to know which website it needs to serve you. It comes down to "if you don't tell me what you want, I'll give you a default website or even simply reset the connection". A typical IIS8.5 will do this, even with the 'Require SNI' checkbox unchecked. So you have your F5, with its HTTPS monitors. Those monitors do not yet support SNI, as they have no means of specifying the hostname you want to use for SNI. In comes a litle script, that will do exactly that. Here's a few quick steps to get you started: Download the script from this article (it's posted on pastebin: http://pastebin.com/hQWnkbMg). Import it under 'System' > 'File Management' > 'External Monitor Program File List'. Create a monitor of type 'External' and select the script from the picklist under 'External Program'. Add your specific variables (explanation below). Add the monitor to a pool and you are good to go. A quick explanation of the variables: METHOD (GET, POST, HEAD, OPTIONS, etc. - defaults to 'GET') URI ("the part after the hostname" - defaults to '/') HTTPSTATUS (the status code you want to receive from the server - defaults to '200') HOSTNAME (the hostname to be used for SNI and the Host Header - defaults to the IP of the node being targetted) TARGETIP and TARGETPORT (same functionality as the 'alias' fields in the original monitors - defaults to the IP of the node being targetted and port 443) DEBUG (set to 0 for nothing, set to 1 for logs in /var/log/ltm - defaults to '0') RECEIVESTRING (the string that needs to be present in the server response - default is empty, so not checked) HEADERX (replace the X by a number between 1 and 50, the value for this is a valid HTTP header line, i.e. "User-Agent: Mozilla" - no defaults) EXITSTATUS (set to 0 to make the monitor always mark te pool members as up; it's fairly useless, but hey... - defaults to 1) There is a small thing you need to know though: due to the nature of the openssl binary (more specifically the s_client), we are presented with a "stdin redirection problem". The bottom line is that your F5 cannot be "slow" and by slow I mean that if it requires more than 3 seconds to pipe a string into openssl s_client, the script will always fail. This limit is defined in the variable "monitor_stdin_sleeptime" and defaults to '3'. You can set it to something else by adding a variable named 'STDIN_SLEEPTIME' and giving it a value. From my experience, anything above 3 stalls the "F5 script executer", anything below 2 is too fast for openssl to read the request from stdin, effectively sending nothing and thus yielding 'down'. When you enable debugging (DEBUG=1), you can see what I mean for yourself: no more log entries for the script when STDIN_SLEEPTIME is set too high; always down when you set it too low. I hope this script is useful for you, Kind regards, Thomas SchockaertCustom HTTPS External Monitor
Happy to step aside and feature a community member's content as a guest article for this post. Please welcome Leonardo Souza to the ranks of DevCentral authors! Introduction If you have upgraded a F5 device (BIG-IP) before, you probably have faced SSL/TLS compatibility issues. That is not exclusive to F5 devices, but a general problem every time a new software version or functionality is released. In theory things should be compatible with previous version, but in reality most of the time it is not. When talking about encryption we use the term SSL, however when we start to discuss the technical details we need to differentiate SSL and TLS. I will not extend the SSL/TLS topic, as there is a good article in DevCentral that explains how a F5 device uses SSL/TLS. Basically, TLS 1.0 is defined in RFC 2246 in 1999, TLS 1.1 RFC 2246 in 2006, TLS 1.2 in RFC 4346 in 2008, and TLS 1.3 still in draft. Searching the F5 release notes, TLS 1.2 started to be supported in 10.2.3 and 11.0.0, this was around 2010/2011. Starting in 10.2.0 we started to have the option to use the clientssl-insecure-compatible and serverssl-insecure-compatible, to allow the use of insecure SSL/TLS options. The insecure profiles are very well known today, and they provide a quick workaround for many SSL/TLS problems after the upgrade. However, the insecure profiles apply only to traffic from users to servers via the F5 device. F5 devices must also monitor the servers, and sometimes because security requirements, both the client side and server sides must be encrypted. In this case F5 devices must monitor the servers using SSL/TLS, with the options that the servers are capable to accept. F5 devices use the daemon bigd to monitor nodes and pool members, and bigd works with OpenSSL to perform HTTPS monitoring. When OpenSSL changes the behaviour, bigd consequently changes as well. In 2012 OpenSSL 1.0.1 was released with support for TLS 1.1 and 1.2. BIG-IP version 11.4.1 uses OpenSSL version 0.9.8y, version 11.5.0 uses 1.0.1e. This is where the things started to complicate, and is what I’m trying to address in this article. Problem As expected when using software to provide a security layer, bigd/OpenSSL will try to use the highest SSL/TLS version available, and the server should either accept that version or suggest a different version. However some servers that don’t support TLS v1.2 are not able to downgrade to TLS 1.1 or TLS1.0, and they just terminate the connection. This behavior translates to a pool member been marked down after the timeout defined. With clientssl and serverssl profiles we can change both the protocol version and the ciphers used. We can do that either changing the ciphers or using the options list, both in the profile configuration. However these options are handled by TMM (also OpenSSL for COMPAT, but let’s skip that), that is F5 TMOS Kernel. As explained, bigd is responsible for monitoring tasks, and uses OpenSSL. The problem is that OpenSSL does not allow changing the protocol using the cipher string. OpenSSL have specific options to change the protocol version, like -tls1_2 to force the use of TLS 1.2. That limits the use of built-in HTTPS monitor, as we can’t force bigd to use TLS 1.0 for example. If we can’t use the build-in monitor, we need to use an external monitor to workaround the limitation. Solution Using an external monitor we can force OpenSSL to use the protocol version that is compatible with the server, and also change the cipher in case is needed. Curl is not a valid option here, because the options tlsv1.0/tlsv1.1/tlsv1.2 were only added in version 7.34.0 that was release end of 2013. At the time I’m writing this article the latest BIG-IP version is 12.1.1, and uses curl 7.19.7. The script has extra information as comments, and should be simple to use. I will not go over the details of the script, or how to write external monitors, as there are multiple articles in DevCentral about that (see resources section below.) The script is available here in the codeshare.The script expects some variables (the order does not matter in this case,) and it will use those variables in the OpenSSL command. Variable: cipher Example: ECDHE-RSA-AES256-SHA The cipher defines with cipher or ciphers OpenSSL should use. Variable: protocol Example: tls1 Indicates witch protocol version OpenSSL should use. Variable: send_string Example: GET / Similar as in the HTTP/HTTPS monitor, indicates the string that is sent to server. Variable: receive_string Example: Welcome Similar as in the HTTP/HTTPS monitor, indicates the string we should receive from the server. Variable: receive_string_down Example: Moved Mark pool member down when the string is received. Variable: debug Example: enable or disable Enable or disable debug. If not present, debug is disabled. Limitations The HTTPS monitor has an option to disable the member when a defined string is received, that functionality exists in this external monitor, however the pool member is marked down. I could disable the pool member using tmsh, but that triggers a configuration change status, and is easier just mark the pool member down. I have successfully tested the external monitor with multiple versions and also with route domains. Resources SSL Profiles (Part 1) Whiteboard Wednesday: External Monitors A Brief Introduction to External Monitors LTM External Monitors: The Basics LTM External Monitors: Troubleshooting External Monitor Wiki Page
Using an F5 iApp to Install and Configure VMware Horizon with View on Nutanix
Welcome to the second post in my series about realizing the benefits of using F5 technology with hyper-converged infrastructure such as the Nutanix hyper-converged platform. Last month, I walked you through the simple process of installing BIG-IP Virtual Editions on Nutanix using the VMware ESXi hypervisor. Today, I’m going to talk about using Nutanix best practices to set up VMware Horizon with View and then configuring the BIG-IP VEs we installed earlier to proxy the PCoIP traffic — all using an easy F5 iApp. So if you’re ready, let’s get going. This is a bit of a long post, so I’ll break it up into a few sections. In the first section, I’ll discuss the components that make up the solution, then we will move on to the steps required to prep the BIG-IP device for this solution. I’ll then tackle how to download the View iApp, and how to import it to the BIG-IP. The next section takes us through the View-specific configuration steps required to use View with F5 BIG-IPs. Since SSL certificate management is an important and required part of any View environment, I’ll show you how to import the necessary SSL certificate and key. And finally, I’ll walk you through filling out the iApp wizard, showing how easy it is to configure the BIG-IPs for View. Solution Components In this screenshot of the vSphere Web Client inventory pane, you can see the environment as it exists for this solution. We also have a pair of View Connection Servers and a Composer Server, all tied to an already existing database server. A few templates have been created for the three example desktop pools: one full clone, one linked clone dedicated pool, and one linked clone floating pool. In addition, we have the Nutanix Controller Virtual Machines (CVMs) running on each of the three Nutanix hosts in this environment. We also have the vCenter 6 Server for this environment running on one of the Nutanix hosts. You might notice that there are no View Security Servers, nor are there any View Access Point servers being deployed in this scenario. Instead, we are going to be using the F5 BIG-IP VEs to handle secure access via the PCoIP and HTML5 protocols. We have an HA pair of BIG-IP VEs, version 11.6 HF6. This is the version of BIG-IP that was recently released to support Horizon with View 6.2. You can see here that the Nutanix-supplied datastores being used in this environment are VAAI (vStorage APIs for Array Integration)-enabled, and set up according to Nutanix best practices. Here is the setting in the View Admin UI, which allows for the use of the Nutanix VAAI and View Composer Array Integration features to enable fast cloning. Now this is where I was really impressed. For this pool, I chose to have five desktops cloned at the same time from an existing replica… and bang, 15 seconds later, all five desktops are cloned and ready to be powered on. Configuring the BIG-IP Before we can allow the F5 devices to proxy the PCoIP traffic for View on the Nutanix platform, we have to do a bit of BIG-IP configuration. First, I went through the initial setup process for the BIG-IPs, setting the management IP address, the hostname, DNS resolvers, NTP servers, passwords and the like. I licensed these BIG-IPs with a VE BEST set of licenses, and I also deployed an HA Active/Standby pair of BIG-IPs, configuring them with Traffic Management Interface Self and “Floating” IPs to enable them to be in a Device Service Cluster. These are standard procedures that are required anytime you configure an HA pair of BIG-IPs. It’s very well documented on our F5 Support site, which, by the way, is a great resource. · Here’s how to deploy BIG-IP VEs on ESXi. · Here’s a guide that discusses the initial setup of the BIG-IPs. · And finally, a guide that discusses the Device Service Clustering process. Now, let’s get back to it. One step that is required for this specific implementation with View is to provision the BIG-IP Access Policy Manager (APM) module, which integrates with Active Directory (AD) and the PCoIP protocol, enabling the BIG-IPs to provide secure remote access to the View desktops. You can see here that we need to put a check mark next to APM and set the provisioning to Nominal. Downloading and Installing the F5 iApp Let’s take a second and talk about F5 iApps, a user-customizable framework for deploying applications. iApps give you a powerful, flexible way to automate tasks and templatize sets of functionality on your F5 gear. Using APL (Application Presentation Language), you define a question-driven interface with which users will interact with their application and enter data. Using that data, you can then automate nearly any task on the device. For example, you can use iApps to automate the way you add virtual servers so that you don’t have to go through the same manual steps every time you add a new application. And guess what? There’s a great iApp already written for View. You can get all the iApps right here; the one we’ll be using for this solution is f5.vmware.view.v1.3.0.tmpl. Once you have logged in to the F5 Downloads site, choose the BIG-IP v12.x / Virtual Edition link to see the latest set of iApp templates. Then select the iApp-Templates download, read and accept the EULA, and download both the .zip and the .md5 files. You can use the tool of your choice to check the MD5 hash of the download to verify it has not been monkeyed with. Extracting this .zip file will create a folder with all of the latest iApp templates. We are interested in the vmware.view one in the above screenshot. Make note of this location, because we’ll reference it when we import the iApp into the BIG-IP. And it wouldn’t be a bad idea to check the MD5 hash against the .tmpl file and to read the README.txt file while you’re at it. The next major step is to import the iApp into the BIG-IP so we can utilize it with the View infrastructure we have installed. Navigate to the iApps > Templates section of the BIG-IP UI, and click Import. On the next screen, click Browse and head over to the location where you unzipped the iApp templates earlier. Choose the file. This will upload the template to the BIG-IP device, which will be synchronized with the other BIG-IP device in the cluster at the next synchronization event, whether that’s a manual sync event or an automatic sync event. Configuring the View Environment After the iApp is on the BIG-IP device, we can configure View for use with the BIG-IP PCoIP proxy — and to configure the BIG-IP via the iApp to provide PCoIP and HTML5 remote access services. Let’s start with the configuration of the View environment. From the View Administrator GUI, expand the View Configuration twisty and choose Servers, and then the Connection Servers tab. Highlight one of the Connection Servers and click the Edit button. Make sure that all three checkboxes on the General tab are unchecked, since the BIG-IPs are going to be handling the Secure Tunnel, PCoIP Secure Gateway, and Blast Secure Gateway services. Repeat these steps for all remaining Connection Servers in your environment. Uploading the SSL Certificate Since View uses SSL certificates to assist in the encryption of the View traffic, we must have the SSL certificates used by View on the BIG-IP. Navigate to System > File Management > SSL Certificate List and choose Import. Provide the type, name, source, and password for the certificate (assuming a PKCS 12) and click Import. We will reference this certificate and key via the iApp wizard. Using the iApp to Configure the BIG-IP for View The final step in the whole process is to configure the BIG-IPs via the iApp. Navigate to the iApp > Application Services section, and click on the Create button. Enter a name for the service you are creating and choose f5.vmware.view.v1.3.0 from the dropdown list of available templates. Those blue bands to the left of certain field names indicate that the field is required. Notice that in this section, I chose to change from the default to support HTML5 Clientless browser connections. This allows the BIG-IP to proxy both PCoIP and HTML5 browser–delivered virtual desktops in a secure manner. In this section, I specified the NetBIOS domain name, location of my Active directory, the DNS suffix of my AD domain, and the credentials used for accessing AD. (I’d suggest that you create a unique AD user with administrative rights so that you can easily audit these connections.) Here I chose to decrypt and re-encrypt the SSL traffic associated with View and specified the cert and key imported earlier. While it would be technically possible to only do SSL decryption and communicate between the BIG-IP and the View Connection Servers via port 80, this would require additional configuration steps to be completed on the View Connection Servers; it’s also less secure than re-encrypting. Notice that I specified BOTH an internal and an external virtual server. The external virtual server securely proxies the PCoIP and HTML5 View traffic to clients on external untrusted networks, while the internal virtual server load balances the Connection Servers and allows for direct connections to clients on trusted internal networks. This section is optional, but I created an advanced health monitor that allows for the BIG-IP to validate that not only are the Connection Servers pingable, but that they are actually able to authenticate a user and present back the list of available desktop pools to this particular user. This provides a higher level of assurance that the entirety of the View infrastructure is functioning as designed. Finally, it is time to click Finished. And to watch as the hundreds of configuration objects are created on the BIG-IP device. One of the major benefits of an iApp (beyond the speed of deployment) is that all of the configuration objects used to provide the service are grouped together in one screen where you can see their interrelatedness and notice the health of each of the components — all in one place. And that’s how easy it is. You’re ready to go. If you’re interested in the business benefits of the F5 and Nutanix partnership, check out the following posts from my colleague, Frank Strobel: · Boost Business Mobility and Application Security with Nutanix and F5 · F5 and Nutanix: Together, Powering Business MobilityMonitoring APM Session Limit Availability from GTM
F5er Harry Kleinbourg came up with a great solution for monitoring the availability of BIG-IP APM targets not just based on the availability of the virtual service but also on its ability to handle service based on the licensed session limits. Goals The goal of this solution is for BIG-IP GTM to redirect SSL VPN users to an available BIG-IP APM. The BIG-IP APM must be considered down if the number of users reaches the license limit. However, there is not an existing built-in monitor that allows BIG-IP GTM to act on this scenario. The setup: 2 or more datacenters 1 BIG-IP GTM in at least two datacenters 2 or more BIG-IP APM in each datacenter Solution Target The solution is to utilize an external monitor on the BIG-IP APM. The external monitor uses an snmp request for the apmAccessStatCurrentActiveSessions OID against a local self IP address. This OID returns the number of current active sessions in APM. An iRule checks the pool status (the pool member is irrelevant, no traffic is sent to this pool member, it's just a placeholder for the OID call) and returns an UP/DOWN status to the GTM HTTP monitor. Very clever, Harry! Solution Details Create an HTTP Monitor in BIG-IP GTM. This monitor is bound to the virtual server that represents the BIG-IP APM listeners. The Alias address is the virtual server called VS_Monitoring on the BIG-IP APM. Over on the BIG-IP APM, add the snmp-check external monitor to the system under /config/monitors or via the GUI under System-> File Management-> External Monitor Program File List, then, create the external monitor: The value of the variable "result" is the number of current sessions NOT to exceed (ie, your license limit). If the value is reached the the monitor will be marked down. The alias address is a self-IP address of the BIG-IP APM to monitor (recommendation would be the floating IP in the case of an HA or pair). This is the IP the SNMP get will be sent to.Next, bind the monitor to a pool that will be used in the iRule: Add a single member here. Again, this member is not used for traffic, but you need at least one member. Based on that monitor, the pool will have an available member or not, and based on that information, the iRule will send a specific HTTP reply. Now, create the iRule: when HTTP_REQUEST { if { [HTTP::uri] eq "/monitoring" } { set response "Monitoring:OK" if { [active_members pool_monitoring_apm] eq 0 } { set response "Monitoring:NO" log local0.info "ERROR, Pool pool_monitoring_apm failed -> No members available" } } # Final HTTP Response HTTP::respond 200 content $response "Content-Type" "text/html" "Cache-Control" "no-cache, must-revalidate" "Connection:close" } Finally, create the virtual server VS_Monitoring. This is the virtual server that the BIG-IP GTM will check. It only has an iRule resource, no pool is necessary. Now with the solution in place, the BIG-IP GTM will monitor via HTTP to the BIG-IP APM, which will return a status message of availability based on its own pool status for the SNMP OID return value. Again, very clever, Harry, and thanks for sharing your solution with the DevCentral community.
