1. Barracuda Load Balancer - Overview What's New in the Barracuda Load Balancer Barracuda Load Balancer Release Notes

Transcription

1 Barracuda Load Balancer - Overview What's New in the Barracuda Load Balancer Barracuda Load Balancer Release Notes Barracuda Load Balancer Release Notes Barracuda Load Balancer Release Notes Barracuda Load Balancer Release Notes 4.x Barracuda Load Balancer Release Notes 4.x Barracuda Load Balancer Release Notes 4.0.x Deployment Options Deployment Service Types Route-Path Deployment Options How to Set Up Route-Path Deployment Sample Route-Path Deployment Network Situations One-Armed Route-Path Using TCP Proxy, UDP Proxy, or a Layer 7 Service Type Route-Path Configured with TCP Proxy, UDP Proxy, or a Layer 7 Service Type Two-Armed Route-Path Using TCP Proxy, UDP Proxy, or a Layer 7 Service Type Two-Armed Route-Path with Layer 4 Load Balancing Bridge-Path Deployment PCI Compliance Considerations and Barracuda Load Balancer Deployment Microsoft Exchange Server 2010 Deployment How to Deploy Microsoft Exchange Server 2010 in a One-Armed Configuration How to Deploy Microsoft Exchange Server 2010 in a Two-Armed Configuration How to Test the Microsoft Exchange Server 2010 Deployment Configuration Microsoft Exchange Server 2013 Deployment Remote Desktop Services in Windows Server 2008 R1 or R2 Deployment Step 1: How to Configure Session Broker with Remote Desktop Services in Windows Server 2008 R1 or R Step 2: How to Configure the Real Server with Remote Desktop Services in Windows Server 2008 R1 or R Step 3: How to Configure Remote Desktop Services with Remote Desktop Services in Windows Server 2008 R1 or R Step 4: How to Test the Installation of Remote Desktop Services in Windows Server 2008 R1 and R Microsoft Office Communications Server Deployment Understanding Microsoft Office Communications Server Deployment Microsoft Office Communications Server Deployment Example How to Deploy with Microsoft Office Communications Server Microsoft Lync Server 2010 Deployment Understanding Microsoft Lync Server 2010 Deployment Options How to Deploy with Microsoft Lync Server IP Worksheet Microsoft Office SharePoint Server 2007, 2010 and 2013 Deployment Direct Server Return Deployment Deployment in a Microsoft Windows Server 2003, 2008, and 2012 Environment Deployment of DSR in a Linux Environment Deployment of DSR in Windows XP Environment Multiple Network Adapters on Real Servers High Availability Deployment Understanding Barracuda Load Balancer High Availability How to Configure the Barracuda Load Balancers for High Availability How to Configure High Availability in Bridge-Path Mode How to Manage a High Availability Environment with Two Barracuda Load Balancers How to Replace a Barracuda Load Balancer in a High Availability Environment How to Remove a Barracuda Load Balancer from a High Availability Environment How to Update Firmware on Clustered Systems Virtual Deployment Hypervisor Compatibility and Deployment - OVF Package Hypervisor Compatibility and Deployment - VMX Package Hypervisor Compatibility and Deployment - XVA Package Barracuda Load Balancer Vx Quick Start Guide Sizing CPU, RAM and Disk for Your Barracuda Load Balancer Vx Backing Up Your Virtual Machine System State VMware View Deployment Getting Started Step 1: How to Install the Barracuda Load Balancer Step 2: How to Configure the Barracuda Load Balancer Step 3: How to Configure the Barracuda Load Balancer Web Interface Step 4: How to Configure the Load Balancer Administrative Settings

2 3.5 Step 5: How to Configure the Barracuda Load Balancer Network Services Services Overview How to Associate Real Servers with a Service Monitoring Services and Real Server Health Persistence Settings Remote Desktop Services Load Balancing TCP Proxy, Secure TCP Proxy, and UDP Proxy FTP Service and FTPS Service Layer 7 HTTP(S) Services How to Configure SSL Offloading How to Secure Communication with Real Servers How to Select a Scheduling Policy Understanding Intrusion Prevention How to Configure Intrusion Prevention How to Configure a Last Resort Action Client Impersonation Traffic Management Understanding Content Rules Understanding Redirect Rules How to Use Extended Match and Condition Expressions Understanding URL Rewrite Rules Understanding HTTP Caching Understanding HTTP Compression Global Server Load Balancing Global Server Load Balancing Overview Implementing Global Server Load Balancing Installing Global Server Load Balancing Integrating Global Server Load Balancing with the Existing DNS Infrastructure Site Selection Algorithms Implementing Global Server Load Balancing Regions Configuring Multiple Global Server Load Balancing Controllers Networking Multiport Configuration Understanding Multiport Configuration Setting Up Multiport Link Aggregation How to Configure Multiport Link Aggregation Multiport Link Aggregation Network Port Configuration Multiport Link Aggregation Deployment Options Example Configuration - Creating Services on Network Ports on Different Networks Configuring Multi-Gigabit Capacity Configuring the WAN IP Address Multiport Configuration in a High Availability Environment Creating Static Routes Adding Custom Virtual Interfaces Network Address Translation (NAT) VLANs Certificate Management Introduction to Certificates How to Add an SSL Certificate Installing SSL Certificates with Correct Chain Order Monitoring How to Remotely Administer Real Servers How to Monitor Services and Real Server Health How to Create Monitor Groups Understanding Testing Methods for Services and Real Servers How to Enable or Disable Real Servers How to View Performance Statistics How to View Logs How to Automate System Alert and SNMP Trap Delivery How to Configure SNMP Monitoring on the Barracuda Load Balancer How to Monitor the System Using SNMP How to Manage Multiple Systems with the Barracuda Cloud Control How to View System Tasks How to Configure Adaptive Scheduling

3 10 Maintenance How to Back up and Restore Your System Configuration How to Update the Firmware on Your Barracuda Load Balancer How to Update Intrusion Prevention Rules Using Energize Updates How to Replace a Failed System How to Reload, Restart, and Shut Down the System How to Troubleshoot Your Barracuda Load Balancer How to Reboot the System in Recovery Mode How to Use the Internet Protocol Version 6 (IPv6) with Barracuda Load Balancer Tools and Add-Ins How to Use the Response Rewrite Function to Enable Web Sites for Google Analytics APIs Automation API Guide API Descriptions Sample Program - Changing Real Server Status to Maintenance Mode Sample Program - Multiple Functions Barracuda Load Balancer Hardware Hardware Compliance Downloads

4 Barracuda Load Balancer Administrator's Guide - Page 4 Barracuda Load Balancer - Overview Designed to help organizations achieve their availability objectives, the Barracuda Load Balancer integrates IP load balancing and network intrusion prevention into an affordable and easy to use appliance. The Barracuda Load Balancer provides comprehensive failover capabilities in case of server failure, distribution of traffic across multiple servers, and integrated protection from network intrusions. The Barracuda Load Balancer ADC is another Barracuda product that is ideal for organizations looking for a high-performance, yet cost-effective application delivery and security solution. For technical information, see Barracuda Load Balancer ADC - Overview in the Barracuda TechLibrary, or check out the Barracuda website for marketing and demo information. Where to Start Download the Barracuda Load Balancer Quick Start Guide. For detailed installation and configuration steps, start here: Step 1: How to Install the Barracuda Load Balancer Step 2: How to Configure the Barracuda Load Balancer Step 3: How to Configure the Barracuda Load Balancer Web Interface Step 4: How to Configure the Load Balancer Administrative Settings Step 5: How to Configure the Barracuda Load Balancer Network Deployment Deployment Service Types Route-Path Deployment Options Bridge-Path Deployment PCI Compliance Considerations and Barracuda Load Balancer Deployment Microsoft Exchange Server 2010 Deployment Microsoft Exchange Server 2013 Deployment Remote Desktop Services in Windows Server 2008 R1 or R2 Deployment Microsoft Office Communications Server Deployment Microsoft Lync Server 2010 Deployment Microsoft Office SharePoint Server 2007, 2010 and 2013 Deployment Direct Server Return Deployment High Availability Deployment Virtual Deployment VMware View Deployment

5 Barracuda Load Balancer Administrator's Guide - Page 5 What's New in the Barracuda Load Balancer What's New in Version 4.2 Deployment New and updated deployment guides: VMware View Deployment Microsoft Exchange Server 2013 Deployment How to Deploy with Microsoft Lync Server 2010 Load Balancing On the ADVANCED > System Settings page, added option for persistence across HTTP and HTTPS services. Configure redirect rules across HTTP/HTTPS services. In settings for Layer 7 - HTTP and Layer 7 - HTTPS services, added option for ignoring the Expect header while buffering HTTP requests. Networking Configure multiple physically segregated networks. Configure link Bonds. Configure WAN and/or LAN IP address on a VLAN or link bond. Configure a default gateway on the MGMT port. 10G interface support. Monitoring Service monitor HTTP tests now include the ability to perform a POST request. Added option to select an interface when performing a Ping test. Added host header to Microsoft SharePoint authentication check. SNMP trap generation when available memory is less than 25%. Support for TCP keepalive probes for Layer 7 services. Cryptography Can manually enable or disable standard ciphers. Specify SSL protocols and ciphers to the front-end SSL. Specify SSL protocols for the backend SSL. Clustering Added the ability to retain the configuration on secondary system while disjoining two systems in a cluster. Statistics Layer 7 FTP Proxy Services support using MLSD and MLST. Web Interface Replaced Protocol column in the Services table on the BASIC > Server Health page with Service Type. Support to enable VDI on a service through web interface. Ability to add servers and server monitoring specific to content rules Fixes and Enhancements For detailed information on the fixes and enhancements included in the Barracuda Load Balancer version 4.2, see: Barracuda Load Balancer Release Notes Barracuda Load Balancer Release Notes Barracuda Load Balancer Release Notes Barracuda Load Balancer Release Notes 4.x Barracuda Load Balancer Release Notes 4.x Barracuda Load Balancer Release Notes 4.0.x

6 Barracuda Load Balancer Administrator's Guide - Page 6 Barracuda Load Balancer Release Notes Read Before Updating Before installing any firmware version, be sure to take a backup of your configuration and read all release notes that apply to versions more recent than the one currently running on your system. Do not manually reboot your system at any time during an upgrade, unless otherwise instructed by Barracuda Networks Technical Support. The update process typically takes a few minutes to complete after the update is applied. If the process takes longer, please contact Technical Support for further assistance. Reverting to an Earlier Firmware Version When reverting to an earlier firmware version: If you have enabled Network Port Configuration support on your Barracuda Load Balancer (versions 4.2 and later), before reverting to a version that does not support Network Port Configuration, you must: Disable Network Port Configuration. If you have enabled IPv6 support on your Barracuda Load Balancer (versions 4.1 and later), before reverting to a version that does not support IPv6 addresses, you must: Delete all IPv6 Services, IPv6 virtual interfaces, IPv6 static routes, and all IPv6 addresses on the BASIC > IP Configuration page. Turn off the Enable IPv6 option on the BASIC > IP Configuration page. Note : Upgrading to this version and then reverting to an earlier firmware version will reset the Barracuda Load Balancer web interface password to "admin." Enhancement The DEFAULT certificate used by the Barracuda Load Balancer for UI access using HTTPS has been renewed. [BNLB-4822] Fixes Vulnerability fix: OpenSSL vulnerability outlined in CVE is addressed. [BNLB-4908] Spurious logs are no longer generated after upgrades to version [BNLB-4890] Issues with SNMP failing to retrieve objects have been fixed. [BNLB-4889] Correct values are now displayed in the Cache Efficiency graph on the BASIC > Status page. [BNLB-4888] Simple HTTP server monitor test no longer incorrectly fails for servers added under content rules. [BNLB-4886] An issue with opening the System Configuration console has been fixed. [BNLB-4884] Login with guest account now works after upgrade to version [BNLB-4877] Server weight is now correctly set to 0 after server is put in maintenance mode. [BNLB-4856] An issue with changes to the Connection Pooling parameter for Layer 7 services has been fixed. [BNLB-4852] High availability messages no longer display for standalone appliances. [BNLB-4356] The DEFAULT certificate used by the Barracuda Load Balancer for UI access using HTTPS has been renewed with a 2K key. [BNLB-4903] Fixed a memory leak issue where memory allocated for objects to track persistence was not released after the persistency timeout. [BNLB-4848]

7 Barracuda Load Balancer Administrator's Guide - Page 7 Barracuda Load Balancer Release Notes Read Before Updating Before installing any firmware version, be sure to take a backup of your configuration and read all release notes that apply to versions more recent than the one currently running on your system. Do not manually reboot your system at any time during an upgrade, unless otherwise instructed by Barracuda Networks Technical Support. The update process typically takes a few minutes to complete after the update is applied. If the process takes longer, please contact Technical Support for further assistance. Reverting to an Earlier Firmware Version When reverting to an earlier firmware version: If you have enabled Network Port Configuration support on your Barracuda Load Balancer (versions 4.2 and later), before reverting to a version that does not support Network Port Configuration, you must: Disable Network Port Configuration. If you have enabled IPv6 support on your Barracuda Load Balancer (versions 4.1 and later), before reverting to a version that does not support IPv6 addresses, you must: Delete all IPv6 Services, IPv6 virtual interfaces, IPv6 static routes, and all IPv6 addresses on the BASIC > IP Configuration page. Turn off the Enable IPv6 option on the BASIC > IP Configuration page. Note: Upgrading to this version and then reverting to an earlier firmware version will reset the Barracuda Load Balancer web interface password to "admin." Enhancements Added the ability to retain configuration on secondary system while disjoining. [BNLB-4083] Support to enable VDI on a service through web interface. [BNLB-4686] Support for TCP keepalive probes for Layer 7 services. [BNLB-4473] Fix Vulnerability fix: OpenSSL vulnerabilities outlined in CVE , CVE , CVE addressed.

8 Barracuda Load Balancer Administrator's Guide - Page 8 Barracuda Load Balancer Release Notes Read Before Updating Before installing any firmware version, be sure to take a backup of your configuration and read all release notes that apply to versions more recent than the one currently running on your system. Do not manually reboot your system at any time during an upgrade, unless otherwise instructed by Barracuda Networks Technical Support. The update process typically takes a few minutes to complete after the update is applied. If the process takes longer, please contact Technical Support for further assistance. Reverting to an Earlier Firmware Version When reverting to an earlier firmware version: If you have enabled Network Port Configuration support on your Barracuda Load Balancer (versions 4.2 and later), before reverting to a version that does not support Network Port Configuration, you must: Disable Network Port Configuration. If you have enabled IPv6 support on your Barracuda Load Balancer (versions 4.1 and later), before reverting to a version that does not support IPv6 addresses, you must: Delete all IPv6 Services, IPv6 virtual interfaces, IPv6 static routes, and all IPv6 addresses on the BASIC > IP Configuration page. Turn off the Enable IPv6 option on the BASIC > IP Configuration page. Note: Upgrading to this version and then reverting to an earlier firmware version will reset the Barracuda Load Balancer web interface password to "admin." Enhancements Support to enable VDI on a service through web interface. [BNLB-4686] Support for TCP keepalive probes for Layer 7 services. [BNLB-4473] Persistence across HTTP and HTTPS services is now possible through web interface (Advanced -> System Settings). By default, this feature is disabled. [BNLB-4716] Ignore the Expect header while buffering HTTP requests in Layer 7 - HTTP and Layer 7 - HTTPS services. [BNLB-4754] Fixes Fixed: The system and API passwords are encrypted and stored in the local database. [BNSEC-1320 / BNLB-4322, BNSEC-1324 / BNLB-4323] Fixed: Private key associated with the signed certificate was not stored even though Assign Associated Key was enabled. This issue has been fixed now. [BNLB-4654] Fixed: Kernel issues that can lead to a system hang in some configurations. [BNLB-4423]

9 Barracuda Load Balancer Administrator's Guide - Page 9 Barracuda Load Balancer Release Notes 4.x Read Before Updating Before installing any firmware version, be sure to take a backup of your configuration and read all release notes that apply to versions more recent than the one currently running on your system. Do not manually reboot your system at any time during an upgrade, unless otherwise instructed by Barracuda Networks Technical Support. The update process typically takes a few minutes to complete after the update is applied. If the process takes longer, please contact Technical Support for further assistance. Reverting to an Earlier Firmware Version When reverting to an earlier firmware version: If you have enabled Network Port Configuration support on your Barracuda Load Balancer (versions 4.2 and later), before reverting to a version that does not support Network Port Configuration, you must: Disable Network Port Configuration. If you have enabled IPv6 support on your Barracuda Load Balancer (versions 4.1 and later), before reverting to a version that does not support IPv6 addresses, you must: Delete all IPv6 Services, IPv6 virtual interfaces, IPv6 static routes, and all IPv6 addresses on the BASIC > IP Configuration pa ge. Turn off the Enable IPv6 option on the BASIC > IP Configuration page. Firmware Version 4.2 New Features Created or updated the following guides to assist in deployment with the Barracuda Load Balancer. These guides are found in the Barracuda Networks TechLibrary: New: VMware View Deployment. New: Microsoft Exchange Server 2013 Deployment Updated: Steps to deploy Microsoft Lync Mobility are included in How to Deploy with Microsoft Lync Server 2010 Service Monitor HTTP tests now include the ability to perform a POST request. [BNLB-4225] Added option to select an interface when performing a Ping test. [BNLB-4098] Generate SNMP trap if available memory is less than 25%. [BNLB-4070] Replaced Protocol column in the Services table on the BASIC > Server Health page with Service Type. [BNLB-4009] Added host header to Microsoft SharePoint authentication check. [BNLB-3960] Can manually enable or disable standard ciphers. [BNLB-3920] Added a Weighted Least Connections load-balancing policy to client impersonation-enabled services. [BNLB-3846] Layer 7 FTP Proxy Services support using MLSD and MLST. [BNLB-3016] [BNLB-4248] Increased flexibility of content rules with regards to adding and monitoring servers. [BNLB-2875] [BNLB-4125] Version 4.009: Fixed : OpenSSL vulnerability [ CVE ] for TLS/DTLS Heartbleed attack has been addressed. [ BNLB-4774 ] Version 4.008: Fixed : High severity vulnerability: arbitrary command execution, remotely exploitable, unauthenticated. [BNSEC-2001 / BNLB-4489] Fixed : Added ability to configure TLS version for SSL communication with real servers. [BNLB-4637] Fixed : In rare cases, usually involving authentication with a 401 status code, requests were dropped if the server responded prematurely. These are now forwarded correctly. [BNLB-3959] Fixed : Primary unit sends a higher priority VRRP advertisement when recovering from a failed state in manual failback mode. [BNLB-4493] Fixed : URL encoding is performed for the ampersand (&) character in URL Translations > Redirect Rules. [BNLB-4522] Fixed : When clustered, the two systems assume the correct active-passive state combination. [BNLB-4520] Fixed : The "Critical Events" number is displayed correctly on the BASIC > Status page. [BNLB-4505] Fixed : Alert messages are generated only for the Services which have "Enable Notification" set to Yes. [BNLB-4373] Fixed : Restored ability to create a bond interface after updating to firmware version [BNLB-4531] Fixed : Fixed issue where web interface was listening on all available interface IP addresses, causing SSL enabled services to fail. [BNLB-4621] Version 4.007: Behavior change: If you are using an SNMP monitor, make sure that its IP address is in the Allowed SNMP IP/Range table on the ADV ANCED > SNMP Configuration page. If no IP addresses are entered in that field, SNMP access is not allowed. [BNLB-4551]

10 Barracuda Load Balancer Administrator's Guide - Page 10 Fixed : Issues with monitor groups for monitoring servers associated with content rules. [ BNLB-4476 ] [ BNLB-4478 ] [ BNLB-4480 ] Fixed : Client session for RDP traffic are not persisted to the correct server. [ BNLB-4387 ] Version 4.006: Fixed : Fixed memory leak in Exchange 2010 deployments. [BNLB-4337] Fixed : Core system modules have been upgraded to resolve out of memory errors. [ BNLB-4327 ] Fixed : Improved GUI memory management and performance when system memory is low. [ BNLB-4123 ] Fixed : Show LAN interface configuration as unavailable in a virtual machine if the second adapter is not found. [BNLB-4274 ] Fixed : Cookie persistence is maintained during HA failover. [BNLB-4100] Fixed : Added multiplier tag option for Adaptive Scheduling for SNMP CPU (to account for multiple cores and differing behavior between Linux and Windows). [BNLB-4120] Fixed : Outlook client failover from one CAS to another occurs quickly. [BNLB-4133] Fixed : Outlook client is able to download a large mailbox (>5GB) when using RPC over HTTP. [BNLB-4231] Fixed : All configured SNAT rules are maintained even after failover and fallback. [BNLB-4232] Fixed : Custom cipher is not used if default cipher is selected. [BNLB-4258] Fixed : Load Balancing with weighted least connections and TCP Proxy works as expected. [BNLB-4310] Fixed : Last Resort Server setting is maintained after failover and failback. [BNLB-4348] Fixed : Data part of Active FTP connection uses VIP address rather than WAN IP address of the Load Balancer. The WAN IP address was used if IP Masquerading was turned on. [BNLB-2645] Fixed : When using Internet Explorer 9, Server Health page shows column checkboxes correctly. [BNLB-3565] Fixed : Disabled LAN management access option in UI while in High Availability mode. [BNLB-3634] Fixed : Redirect Rule element type pathinfo works as expected. [BNLB-4010] Fixed : Common name field in BASIC > Certificates page displays subject common name instead of issuer common name. [BNLB-4015] Fixed : CPU temperature displays correctly on the BASIC > Status page. [BNLB-4097] Fixed : BASIC > Server Health page shows correct value for traffic. [BNLB-4159] Fixed : If server is down/disabled/in maintenance mode, then the Adaptive Scheduling SNMP CPU test for that server returns value of 0. [BNLB-4182] Fixed : If Direct Server Return is enabled, SIP health check works correctly. [BNLB-4195] Fixed : SSH to servers works with Layer 4 TCP ALL port service. [BNLB-4201] Fixed : Added more log file maintenance routines to conserve disk space. [BNLB-4209], [BNLB-4221] Fixed : For GSLB, test for the first site shows accurate results in user interface. [BNLB-4251] Fixed : Only unique entries for HTTP content type in compression rules are allowed. [BNLB-4265] Fixed : UDP Proxy Service for port 123 (NTP) works when first created. [BNLB-4277] Fixed : When server is disabled and then re-enabled, the Traffic to Servers graph for that server shows accurate data instead of spikes. [BNLB-4333] Fixed : Service/server health probe failure reason appears in BASIC > Event Log, even if name of Service/server includes a '-' or '_'. [BNLB-4334] Fixed : Status and link speed display correctly for a bonded interface.[bnlb-3785] Fixed : Automated SMB backups work. [BNLB-3893] Fixed : Server restore alert is sent when required by a group monitor test. [BNLB-4316]

11 Barracuda Load Balancer Administrator's Guide - Page 11 Barracuda Load Balancer Release Notes 4.x Read Before Updating Before installing any firmware version, be sure to take a backup of your configuration and read all release notes that apply to versions more recent than the one currently running on your system. Do not manually reboot your system at any time during an upgrade, unless otherwise instructed by Barracuda Networks Technical Support. The update process typically takes a few minutes to complete after the update is applied. If the process takes longer, please contact Technical Support for further assistance. Reverting to an Earlier Firmware Version When reverting to an earlier firmware version: If you have enabled Network Port Configuration support on your Barracuda Load Balancer (versions 4.2 and later), before reverting to a version that does not support Network Port Configuration, you must: Disable Network Port Configuration. If you have enabled IPv6 support on your Barracuda Load Balancer (versions 4.1 and later), before reverting to a version that does not support IPv6 addresses, you must: Delete all IPv6 Services, IPv6 virtual interfaces, IPv6 static routes, and all IPv6 addresses on the BASIC > IP Configuration pa ge. Turn off the Enable IPv6 option on the BASIC > IP Configuration page. Firmware Version 4.1 New Features Configure redirect rules across HTTP/HTTPS services. [BNLB-2599] 10G interface support. [BNLB-2916] Specify SSL protocols and ciphers to the frontend SSL. [BNLB-3995] Specify SSL protocols for the backend SSL. [BNLB-4059] Version 4.007: Fixed : Resolved issue with potential SSH access to unit when not deployed behind a firewall. To completely disable remote support functionality, contact Barracuda Networks Technical Support. Reported by Stefan Viehböck, SEC Consult Vulnerability Lab ( sec-consult.com). [ BNSEC-767 ] Fixed : SSH working with L4 TCP ALL Port service. [ BNLB-4201 ] Version 4.006: Fixed : Multiple IP's are now handled correctly when passed in header configured in the 'Actual Client IP Header' parameter. [ BNLB-4090 ] Fixed : POST requests without a Content-Type header are now handled correctly. Fixed : CVE , CVE on the possible vulnerability to SSL/TLS CRIME attack is addressed. [ BNLB-4022 ] Fixed : 'Service down' s are triggered only when all the servers attached to the service are down. [ BNLB-4086 ] Fixed : Intermittent issue with rendering of existing services on the Service page. [ BNLB-3953 ] Fixed : Added support for prioritizing the order of Cipher suites. [BNLB-3920 ] Version 4.004: Added: Configuration of maximum allowed length for a HTTP Header. [BNLB-3427] Fixed: Configure last resort servers for Content Rules. [BNLB-3485] Fixed: Speed/duplex mode remains unchanged after system reboot. [BNLB-3698] Fixed: Management IP configuration variable setting recognized. [BNLB-3870] Fixed: HTTP Cookies greater than 64Kb in size also allowed. [BNLB-3914] Fixed: Intermittent loss of access to the Barracuda Load Balancer web interface when HTTPS-only is enabled. [BNLB-3917] Fixed: Status of fan and temperature details now report properly on Barracuda Load Balancer model 640. [BNLB-3969] Fixed: Support tunnel opens as expected through Barracuda Cloud Control when Establish Connection To Barracuda Support Center is clicked. [BNLB-4030] Fixed: HttpOnly field for persistence cookie is configurable.[bnlb-3900]

12 Barracuda Load Balancer Administrator's Guide - Page 12 Barracuda Load Balancer Release Notes 4.0.x Read Before Updating Before installing any firmware version, be sure to take a backup of your configuration and read all release notes that apply to versions more recent than the one currently running on your system. Do not manually reboot your system at any time during an upgrade, unless otherwise instructed by Barracuda Networks Technical Support. The update process typically takes a few minutes to complete after the update is applied. If the process takes longer, please contact Technical Support for further assistance. Reverting to an Earlier Firmware Version When reverting to an earlier firmware version: If you have enabled Network Port Configuration support on your Barracuda Load Balancer (versions 4.2 and later), before reverting to a version that does not support Network Port Configuration, you must: Disable Network Port Configuration. If you have enabled IPv6 support on your Barracuda Load Balancer (versions 4.1 and later), before reverting to a version that does not support IPv6 addresses, you must: Delete all IPv6 Services, IPv6 virtual interfaces, IPv6 static routes, and all IPv6 addresses on the BASIC > IP Configuration pa ge. Turn off the Enable IPv6 option on the BASIC > IP Configuration page. Firmware Version 4.2 New Features Configure multiple physically segregated network(s). Configure Link Bond(s). Configure WAN and/or LAN IP Address on a VLAN or Link Bond. Configure a default gateway on the MGMT port. Version : Fixed: Periodic management GUI outage when HTTPS/SSL Access-Only is set to Yesunder ADVANCED > Secure Administration. Fixed: Management GUI outage when it has not been accessed for more than 10 days. Fixed: Layer 7 RDP service outage due to incorrect connection cleanup. Version : Fixed: RDP Proxy now works correctly with token-based persistence. Fixed: Subscription Status under BASIC > Status page does shows garbled strings. Fixed: High Availability Failover/Failback is delayed if Outbound SMTP Host is not reachable. Fixed: SSL offloaded services will not accept client initiated renegotiation and will close the TCP connection instead. Fixed: Computation used to calculate the new weight of the server for SNMP CPU-based Adaptive Scheduling will also factor in the number of CPU cores in the server. Fixed: Rebooting the active unit in a High Availability setup in Manual Failback Mode results in it becoming active again. Fixed: A possible outage when the request contains more than cookies or a header which exceeds 1M in size is addressed. Barracuda Load Balancer now drops such requests. Known Issues This firmware introduces a new optimized data store format for storing historical statistics which are displayed on the BASIC > Status pa ge. The new format is incompatible with the data store used in firmware version 4.1 or earlier. After upgrade to 4.2, graphs display statistics collected only after the upgrade.

13 Barracuda Load Balancer Administrator's Guide - Page 13 Deployment Options In this Section Deployment Service Types Route-Path Deployment Options Bridge-Path Deployment PCI Compliance Considerations and Barracuda Load Balancer Deployment Microsoft Exchange Server 2010 Deployment Microsoft Exchange Server 2013 Deployment Remote Desktop Services in Windows Server 2008 R1 or R2 Deployment Microsoft Office Communications Server Deployment Microsoft Lync Server 2010 Deployment Microsoft Office SharePoint Server 2007, 2010 and 2013 Deployment Direct Server Return Deployment High Availability Deployment Virtual Deployment VMware View Deployment Global Server Deployment Options Global Server Load Balancing Overview Installing Global Server Load Balancing Integrating Global Server Load Balancing with the Existing DNS Infrastructure Implementing Global Server Load Balancing Regions

14 Barracuda Load Balancer Administrator's Guide - Page 14 Deployment Service Types Services on the Barracuda Load Balancer can be deployed in the following three modes: Route-Path Bridge-Path Direct Server Return All of these deployment modes require specific network configurations. The Barracuda Load Balancer must be in either Route-Path or Bridge-Path mode. Direct Server Return is an option that you may choose for each Real Server. Choose the deployment mode for the Barracuda Load Balancer based on the type of network configuration that currently exists at your site as well as on the types of Services you wish to load balance. Route-Path is recommended over Bridge-Path because it provides a more robust deployment. Enabling the Direct Server Return option is recommended only for Real Servers that generate a much greater volume of outbound traffic relative to the inbound traffic. Service Types A Service is the access point that the client uses for the functionality provided by the Real Servers. There are multiple Service types supported by the Barracuda Load Balancer. Because the choice of Service type may affect the deployment method, this table gives a brief overview. Table Service Types. Service Type Layer 4 - TCP Layer 4 - UDP TCP Proxy UDP Proxy Layer 7 - HTTP Layer 7 - FTP Layer 7 - RDP Secure TCP Proxy Layer 7 - HTTPS Layer 7 - FTPS Description Traffic passes in half-nat mode, meaning the destination IP address is changed to that of the Real Server, but the source IP address remains intact. Traffic passes in full-nat mode, meaning that both the source and destination IP addresses are changed. The Barracuda Load Balancer acts as a full proxy. Connections from the client are terminated at the Barracuda Load Balancer and new ones are established between the Barracuda Load Balancer and the Real Servers. Same description as their non-secure counterparts. In addition, Services with this type perform SSL offloading using a certificate that is specified when the Service type is selected. Related Articles Services Overview How to Associate Real Servers with a Service Monitoring Services and Real Server Health Persistence Settings Remote Desktop Services Load Balancing TCP Proxy, Secure TCP Proxy, and UDP Proxy FTP Service and FTPS Service Layer 7 HTTP(S) Services How to Configure SSL Offloading How to Secure Communication with Real Servers How to Select a Scheduling Policy Understanding Intrusion Prevention How to Configure Intrusion Prevention How to Configure a Last Resort Action Client Impersonation

15 Barracuda Load Balancer Administrator's Guide - Page 15 Route-Path Deployment Options Route-Path is the most commonly used deployment method. If a Service type of Layer 4 - UDP or Layer 4 - TCP is used in a two-armed deployment, the Barracuda Load Balancer has to be the default gateway for all downstream Real Servers. For all other cases, the Real Servers and VIP addresses can be positioned in a variety of ways. Table 1 provides an overview of the Route-Path deployment options. Table Route-Path Deployment Options. Traffic Type Topology Options (Route-Path) Service Type Notes TCP or UDP Two-armed. Usually the recommended deployment for Layer 4 traffic. Layer 4 - UDP, Layer 4 - TCP Barracuda Load Balancer has to be the default gateway for all downstream Real Servers UDP One- or two-armed. UDP Proxy UDP Proxy supports persistence using both client IP address and port. Many UDP applications involve all client requests coming from one client IP address. A Service with type UDP Proxy and configured with persistence of client IP port number distributes traffic across all of the Real Servers. Layer 4 - UDP Services only consider client IP address. TCP One- or two-armed. Two-armed is recommended for best performance. TCP Proxy Can keep IP addresses of the Real Servers. There is a TCP Connection between the Barracuda Load Balancer and the Real Server. Any response goes back to the Barracuda Load Balancer. TCP or UDP One-armed. Best performance if almost all traffic is outgoing. Layer 4 - TCP or Layer 4 - UDP with Real Servers in Direct Server Return mode Requires loopback adapter on each Real Server. Can keep IP addresses of the Real Servers. SSL offloading and other Layer 7 capabilities are not supported. TCP with SSL processing offloaded to the Barracuda Load Balancer One- or two-armed. Two-armed is recommended for best performance. Secure TCP Proxy Can keep IP addresses of Real Servers. There is a TCP connection between Barracuda Load Balancer and Real Server. Any response goes back to Barracuda Load Balancer. HTTP (web servers) One- or two-armed. Layer 7 - HTTP or Layer 7 - HTTPS FTP (FTP servers) One- or two-armed. Layer 7 - FTP or Layer 7 - FTPS Can keep IP addresses of the Real Servers. There is a TCP connection between the Barracuda Load Balancer and the Real Server. Any response goes back to the Barracuda Load Balancer. Can keep IP addresses of the Real Servers. There is a TCP connection between the Barracuda Load Balancer and the Real Server. Any response goes back to the Barracuda Load Balancer.

16 Barracuda Load Balancer Administrator's Guide - Page 16 Remote Desktop Services One- or two-armed. Two-armed is recommended for best performance. Layer 7 - RDP Can keep IP addresses of the Real Servers. There is a TCP connection between the Barracuda Load Balancer and the Real Server. Any response goes back to the Barracuda Load Balancer. Related Articles Deployment Options Sample Route-Path Deployment Network Situations One-Armed Route-Path Using TCP Proxy, UDP Proxy, or a Layer 7 Service Type Route-Path Configured with TCP Proxy, UDP Proxy, or a Layer 7 Service Type Two-Armed Route-Path Using TCP Proxy, UDP Proxy, or a Layer 7 Service Type Two-Armed Route-Path with Layer 4 Load Balancing Multiple Network Adapters on Real Servers

17 Barracuda Load Balancer Administrator's Guide - Page 17 How to Set Up Route-Path Deployment Route-Path is the most commonly used deployment method providing the most flexibility by allowing load balancing of any server in a downstream route. It is also desirable because it allows layer 7 (cookie) persistence and SSL offloading. To set up Route-Path, the following conditions must be met: Each real server must be logically isolated. This means all traffic going to each real server must go through the load balancer; each real server must have only 1 IP address, which is their private, isolated IP address. It is possible to have multiple IP addresses, but no network path may exist from the real servers to the client machines (this means if the real servers are also members of another network, this network must too be isolated and not connected in any way or through any other networks to the WAN network, including through the internet). The VIPs must be on the same subnet as the rest of the network; only the real servers are on the private, separate network. The servers need not be physically isolated and can share a switch with the rest of the network so long as the isolation condition is met. Each real server must be "one hop" away from the LAN port on the Barracuda Load Balancer. This means any relevant switches must be directly connected into the LAN port of the Load Balancer, or connected to a series of switches that eventually reach the LAN port of the Load Balancer without going through any other machines. Each real server must list the Barracuda's LAN IP address as its gateway. Each real server must use only one nic, if there is multiple nics the other nics must have no gateway or be disabled. Lastly, the box must be in Route Path mode on the IP configuration page (0 and above only). If you need to remotely administer these real servers individually, you can create new services, each of which only load-balances a single real server (so it acts as a NAT). Related Articles Deployment Options Route-Path Deployment Options Sample Route-Path Deployment Network Situations One-Armed Route-Path Using TCP Proxy, UDP Proxy, or a Layer 7 Service Type Route-Path Configured with TCP Proxy, UDP Proxy, or a Layer 7 Service Type Two-Armed Route-Path Using TCP Proxy, UDP Proxy, or a Layer 7 Service Type Two-Armed Route-Path with Layer 4 Load Balancing

18 Barracuda Load Balancer Administrator's Guide - Page 18 Sample Route-Path Deployment Network Situations Following are some common cases with suggested deployments; all of these cases use a Route-Path deployment. The Barracuda Load Balancer provides Layer 4 load balancing of TCP/IP traffic. Use two-armed Route-Path with one or more Layer 4 - TCP Services. The Barracuda Load Balancer provides Layer 4 load balancing of UDP traffic. Use two-armed Route-Path with one or more Layer 4 - UDP Services. 3. The Barracuda Load Balancer provides SSL offloading and Layer 4 load balancing of TCP/IP traffic. Use a one or two-armed Route-Path with one or more Secure TCP Proxy Services. If you use one-armed Route-Path, you will not need to reconfigure the IP addresses of the Real Servers. Two-armed Route-Path provides better performance. 4. The Real Servers are on the same subnet as the Barracuda Load Balancer and the configuration cannot be changed. Use one-armed Route-Path with a TCP Proxy Service (or a Secure TCP Proxy Service if SSL offloading is required). Or, if almost all of the traffic is outbound, use Direct Server Return with a Layer 4 Service. 5. There is an existing IT infrastructure using Windows where the web servers need to communicate with systems such as Active Directory Domain Services, ISA Servers or domain controllers. To avoid changing those network settings, either: Use one-armed Route-Path with a TCP Proxy Service. Use Direct Server Return with a Layer 4 Service. For best performance, the recommended deployment is to use a two-armed Route-Path with a Layer 4 Service. 6. The outbound traffic is far greater than the inbound traffic, for example, if the Real Servers are providing streamed audio or visual media. Use Direct Server Return with a Layer 4 Service to increase throughput. 7. There is a need to remotely administer the Real Servers individually. Create new Services, each of which only load balances a single Real Server. Deploy the Real Servers in a one-armed mode where they are on the WAN side of the Barracuda Load Balancer and serving a TCP Proxy Service. Or, deploy the Real Servers on the WAN side in Direct Server Return mode serving a Layer 4 Service. Related Articles Deployment Options Route-Path Deployment Options One-Armed Route-Path Using TCP Proxy, UDP Proxy, or a Layer 7 Service Type Route-Path Configured with TCP Proxy, UDP Proxy, or a Layer 7 Service Type Two-Armed Route-Path Using TCP Proxy, UDP Proxy, or a Layer 7 Service Type Two-Armed Route-Path with Layer 4 Load Balancing

19 Barracuda Load Balancer Administrator's Guide - Page 19 One-Armed Route-Path Using TCP Proxy, UDP Proxy, or a Layer 7 Service Type A One-Armed Route-Path topology has the following benefits: It is more simple to configure than the two-armed routh-path topology because all of the Real Servers and the VIP addresses are on the same subnet, and typically connected to the WAN (or, less commonly, to the LAN). See Figure 1 below. No re-configuration of the network is required. However, since the Real Servers and VIP addresses are on the same subnet, this configuration is less secure than the Two-Armed Route-Path deployment. Related Articles Deployment Options Two-Armed Route-Path with Layer 4 Load Balancing Two-Armed Route-Path Using TCP Proxy, UDP Proxy, or a Layer 7 Service Type Bridge-Path Deployment If the Service type is Layer 4 - TCP or UDP, the Real Servers will need to be configured in Direct Server Return mode. See Direct Server Return deployment. Alternatively, use the TCP Proxy Service type, the UDP Proxy Service type or one of the Layer 7 Service types. This provides a quick way to insert the Barracuda Load Balancer into an existing infrastructure with minimal changes to the network. No changes are required to the IP addresses of the Real Servers. The Barracuda Load Balancer may be on the same subnet as the Real Servers. Alternatively, the Real Servers are reachable through a router from the Barracuda Load Balancer. Virtual Interface If the Server is in the same network as the custom virtual interface, then the custom virtual interface is used to connect to the Server using the interface route/static route or the default gateway, in that order. If the Server, the custom virtual interface, and the WAN IP are all in the same network, you cannot use the custom virtual interface to connect to the Server. In this scenario, the WAN IP is always used to connect to the Server. The virtual interface of the service can be in any network. Figure 1 shows a WAN-side deployment using one-armed route-path and TCP Proxy, UDP Proxy or Layer 7 Services. The gateway IP address of the Real Servers remains the same as it was before the introduction of the Barracuda Load Balancer to the network. All of the Virtual IP addresses and IP addresses of the Real Servers are connected to the WAN port. Figure One-armed Route-Path using TCP Proxy, UDP Proxy, or a Layer 7 Service. If desired, you can keep an externally accessible IP address on a Real Server so that external clients can still access that address (for example,

20 Barracuda Load Balancer Administrator's Guide - Page 20 for FTP) only on that one system. Because configuration changes are not required, only that traffic which needs to be load balanced passes through the Barracuda Load Balancer. Figure 2 shows an example of a one-armed route path deployment using TCP Proxy Services. In this case, the Services are provided by multiple Barracuda Spam & Virus Firewalls and servers. Figure One-armed TCP Proxy Service with Barracuda Spam & Virus Firewalls. As shown in the diagram, passes through this network in the following way: #1 - is sent to the VIP address for the TCP Proxy Service that represents the Barracuda Spam & Virus Firewalls. #2 - It is directed to the appropriate Barracuda Spam & Virus Firewall for processing. #3 - After passing spam and virus checks, the is sent to the VIP address for the Service. #4 - The Barracuda Load Balancer load balances the traffic and passes it to an server. Related Articles Deployment Options Sample Route-Path Deployment Network Situations Route-Path Deployment Options Route-Path Configured with TCP Proxy, UDP Proxy, or a Layer 7 Service Type Two-Armed Route-Path Using TCP Proxy, UDP Proxy, or a Layer 7 Service Type Two-Armed Route-Path with Layer 4 Load Balancing

21 Barracuda Load Balancer Administrator's Guide - Page 21 Route-Path Configured with TCP Proxy, UDP Proxy, or a Layer 7 Service Type Choosing a Service type of TCP Proxy, UDP Proxy or one of the Layer 7 Service types makes the Barracuda Load Balancer act as a full proxy. Connections from the client are terminated at the Barracuda Load Balancer and new ones are established between the Barracuda Load Balancer and the Real Servers. Using one of these Service types allows the Real Servers to be located anywhere, as long as they can be routed to by the Barracuda Load Balancer (e.g., on the same subnet or VLAN or pre-configured static routes). This can be used in one-armed configurations for applications like Microsoft Exchange Server or Microsoft Office Communications Server as well as for custom applications. In two-armed configurations, Real Servers can access the Virtual IP (VIP) addresses of any TCP Proxy, UDP Proxy, or Layer 7 Services that are on the same side of the Barracuda Load Balancer. There are multiple alternatives for configuration when using the Barracuda Load Balancer in the Route-Path mode with one or more TCP Proxy, UDP Proxy, or Layer 7 Services: Some or all of the Real Servers are on the same subnet as the LAN IP address. Some or all of the Real Servers are on the same subnet as the WAN IP address. Some or all of the Real Servers are on the same VLAN as the Barracuda Load Balancer. Some or all of the Real Servers are on a different subnet than either the WAN or LAN IP address but accessible through static routes. Some or all of the Real Servers are on a different subnet and responding to a TCP Proxy, UDP Proxy, or Layer 7 Service. VIP addresses are on the same subnet as the WAN interface of the Barracuda Load Balancer, and Real Servers on a subnet separate from the VIPs. VIP addresses are on the same subnet as the LAN interface of the Barracuda Load Balancer and Real Servers on a subnet separate from the VIPs. Related Articles Deployment Options Route-Path Deployment Options Sample Route-Path Deployment Network Situations One-Armed Route-Path Using TCP Proxy, UDP Proxy, or a Layer 7 Service Type Two-Armed Route-Path Using TCP Proxy, UDP Proxy, or a Layer 7 Service Type Two-Armed Route-Path with Layer 4 Load Balancing

22 Barracuda Load Balancer Administrator's Guide - Page 22 Two-Armed Route-Path Using TCP Proxy, UDP Proxy, or a Layer 7 Service Type Two-armed Route-Path with a Service with type Layer 7 - RDP is the recommended configuration when deploying the Barracuda Load Balancer in a Microsoft Terminal Services environment. Figure 1 shows a network where there are Virtual IP addresses available on both the WAN and LAN side. Clients coming from the Internet or intranet can access the database or web Service. On the LAN side, the web servers can access the database Service. Related Articles Deployment Options Route-Path Deployment Options Sample Route-Path Deployment Network Situations One-Armed Route-Path Using TCP Proxy, UDP Proxy, or a Layer 7 Service Type Route-Path Configured with TCP Proxy, UDP Proxy, or a Layer 7 Service Type Two-Armed Route-Path with Layer 4 Load Balancing Figure Two-armed TCP Proxy, UDP Proxy, or Layer 7 Service.

23 Barracuda Load Balancer Administrator's Guide - Page 23

24 Barracuda Load Balancer Administrator's Guide - Page 24 Two-Armed Route-Path with Layer 4 Load Balancing Use this option if you are planning to use the Barracuda Load Balancer to provide Layer 4 load balancing of TCP or UDP traffic. If you are planning to use the Barracuda Load Balancer to provide SSL offloading for TCP/IP traffic, use a Service type of Secure TCP Proxy. Deploying the Barracuda Load Balancer in a two-armed Route-Path configuration requires changing the IP addresses of all of the Real Servers, but gives greater performance. If a Service type of Layer 4 is used, the Barracuda Load Balancer must be able to handle the responses to client requests that are issued by the Real Servers. To do this, set the Barracuda Load Balancer as the default gateway for all downstream Real Servers. Figure Two-armed Route-Path network with Layer 4 Services. Related Articles Deployment Options Route-Path Deployment Options Sample Route-Path Deployment Network Situations One-Armed Route-Path Using TCP Proxy, UDP Proxy, or a Layer 7 Service Type Route-Path Configured with TCP Proxy, UDP Proxy, or a Layer 7 Service Type Two-Armed Route-Path Using TCP Proxy, UDP Proxy, or a Layer 7 Service Type

25 Barracuda Load Balancer Administrator's Guide - Page 25 Bridge-Path Deployment Introduction Bridge-Path deployment entails placing the Barracuda Load Balancer inline with your existing IP infrastructure so that it can load balance the Real Servers without changing IP addresses. The LAN interface must be on the same logical switch as the Real Servers. The WAN and LAN interfaces must be on physically separate networks. If you are considering using a Bridge-Path deployment because you want to avoid changing the IP addresses of your Real Servers, we recommend that you instead use a TCP Proxy Service and Route-Path. The following table describes the advantages and disadvantages of deploying your Barracuda Load Balancer in Bridge-Path mode: Advantages Minimum network changes since the existing IP infrastructure is reused. Real Servers keep their existing IP addresses. Disadvantages Separate physical networks required for downstream Real Servers. Less resilient to network misconfigurations. Improper configuration of a Bridge-Path network may result in a broadcast storm, resulting in network outages. Figure Sample Bridge-Path network layout. Deploy Bridge-Path In Bridge-Path mode, the Real Servers must be physically isolated behind the Barracuda Load Balancer. This means that each Real Server is no longer visible on the network if the Barracuda Load Balancer becomes unavailable (a separate switch is required for the Barracuda Load Balancer 440 and below). The Real Servers must be on the same subnet and logical network as the Barracuda Load Balancer, the VIPs, and the rest of the WAN, and they must specify the same gateway as the Barracuda Load Balancer. Make sure that the Operating Mode of the Barracuda Load Balancer is set to Bridge-Path on the BASIC > IP Configuration page. The LAN IP Address on the same page is not used.

26 Barracuda Load Balancer Administrator's Guide - Page 26 PCI Compliance Considerations and Barracuda Load Balancer Deployment This article refers to firmware 4.1 and higher. You can install the latest firmware from the ADVANCED > Firmware Updates page in the Barracuda Load Balancer web interface. This article outlines implementation considerations when deploying the Barracuda Load Balancer in an environment subject to PCI Data Security Standard (PCI DSS) compliance. This article focuses on the requirements placed on the Barracuda Load Balancer for achieving PCI compliance, in an environment that includes the following: Barracuda Load Balancer Application Server Database Server For PCI DSS Requirement 6.6 compliance and added application security, consider including a Barracuda Web Application Firewall in your deployment environment. Efficient PCI Compliance PCI Compliance applies to entities that process, store, or transmit cardholder data. The Barracuda Load Balancer intelligently distributes traffic among servers for efficient use of server resources, and provides server fail-over for High Availability. The Barracuda Load Balancer, as an underlying technology infrastructure in your network, does not directly manage or store cardholder data. However, it provides a secure environment for the transmission of all application data including cardholder data. For merchants subject to PCI DSS, this facilitates certification attainment. According to section 4.1 of the Payment Card Industry (PCI) Data Security Standard v2, merchants handling credit card data are required to "...use strong cryptography and security protocols such as SSL/TLS or IPSEC to safeguard sensitive cardholder data during transmission over open, public networks. Deploying services behind the Barracuda Load Balancer simplifies your PCI compliance by relying on a secure, up-to-date PCI-compliant stack front-end for back-end servers. Additionally, the Barracuda Load Balancer provides risk mitigation and business continuity by relieving your certification process from full scanning, and operating system, middle-ware, and application update and patching on all your Internet-facing production servers which can result in downtime and administrator overhead. An information supplement to the PCI DSS notes that as long as the servers behind a load balancer are configured similarly, they are exempt from an internal scan. For more information, refer to Account for Load Balancers (page 14 of the PCI Approved Scanning Vendors Program Guide). Configure Front End SSL Front-end SSL refers to the SSL implemented between the Barracuda Load Balancer and the client connecting to the Barracuda Load Balancer from the Internet. Configure SSL for each Service that requires compliance. The use of SSL has the following security implications under PCI DSS compliance: 3. Disables Secure Sockets Layer version 2 (SSLv2); Disallows "weak" cryptography; Quarterly PCI security vulnerability scans conducted against your external-facing PCI systems. Without the first two measures, the scans are likely to fail, leading to falling out of compliance and the associated risks and consequences. Barracuda Load Balancer provides secure SSL Offloading for your services. To enable this, log into the Barracuda Load Balancer web interface, go to the BASIC > Services page, and click Edit following the Service you wish to modify. In the edit screen, scroll to the SSL Offloading sectio n:

27 Barracuda Load Balancer Administrator's Guide - Page 27 By default the Barracuda Load Balancer disables the deprecated ciphers and protocols, and is therefore "secure by default". As shown in the screenshot above, the Barracuda Load Balancer enables only: Secure Protocols SSL v3, TLS v0/1/2 Secure Ciphers all weak and medium ciphers are disabled Additionally, security researchers have recently identified new vulnerabilities in the SSL protocol; these are mitigated by the secure SSL stack in the Barracuda Load Balancer as shown in Table Table SSL Protocol Vulnerabilities Vulnerability Impact Remediation Insecure Renegotiation High Barracuda Load Balancer only supports secure renegotiation initiated by the Server. BEAST Attack Low SSL v3 and TLS 0 may be vulnerable to this attack even when block ciphers are used; configure the Barracuda Load Balancer to prioritize or enforce stream (RC4) cipher suites. CRIME Attack Low This attack exploits the protocol compression feature. By default, SSL compression is disabled in the Barracuda Load Balancer. Configuring Back-End SSL Back-end SSL refers to the use of the SSL protocol to re-encrypt traffic between the Barracuda Load Balancer and the back-end servers. PCI mandates SSL when transmitting data over "open, public" networks; see Requirement 4: Encrypt transmission of cardholder data across open, public networks (page 35 of the PCI Data Security Standard). When the path between the Barracuda Load Balancer and the servers is within a secure zone, organizations are not mandated to re-encrypt the traffic assuming the privacy of the path can be demonstrated for compliance. If your network architecture, environment, or the associated risk necessitates back-end SSL, go to the BASIC > Services page, click Edit followi ng the Service you wish to modify, and update the SSL section as shown in the following image:

28 Barracuda Load Balancer Administrator's Guide - Page 28 Back-end SSL uses the same secure SSL protocols and ciphers as front-end SSL. Secure Certificates Though PCI does not specify minimum certificate key sizes, Barracuda Network recommends a minimum of 2048 bit key strength when renewing certificates or deploying new services. Note that the National Institute for Standards and Technology (NIST) has mandated moving to 2048 bit certificates, which the Barracuda Load Balancer fully supports. Ensure that all SSL services, as well as the Management UI, employ strong certificates. Secure the Web-based Management UI Barracuda Networks recommends allowing the Management UI access only from the Management interface and disabling it from the WAN interface. This ensures that the Management UI is not exposed to external scanners and access is restricted to an internal, secure management network. To configure this, go to the BASIC > IP Configuration page, and update the WAN IP Configuration section as shown in the following image: For additional security, restrict Web Interface access by setting to, and disable regular HTTP access on the HTTPS/SSL Access Only Yes ADV ANCED > Secure Administration page. You can select a Private certificate if you have restricted access to a private network as in the screenshot shown above. If you choose to enable access via the WAN interface, ensure that you select a Trusted certificate instead.

29 Barracuda Load Balancer Administrator's Guide - Page 29 Secure SNMP Access To secure the SNMP access for compliance, go to the ADVANCED > SNMP Configuration page, and complete the following steps: In the SNMP Manager section, select the SNMP Version as v3. Provide a secure password for the admin user. Select SHA and AES as the Authentication Method and Encryption Method respectively; these are more secure than MD5 and DES. Restrict SNMP Access to an internal network via the Allowed SNMP IP/Range control: 5. If you choose to use SNMP v2c to support legacy SNMP clients, ensure that you change the default SNMP Community String: For details on scanner false positives with respect to SNMP, refer to PCI-DSS Requirement 4 later in this article. Enable Syslog for Audit Compliance Continuous activity log monitoring alerts you to any unusual activity on the Barracuda Load Balancer. To enable Syslog, go to the ADVANCED > Syslog page, enter the Syslog Server address, and click Add: Ensure Password Security

30 Barracuda Load Balancer Administrator's Guide - Page 30 Before you install and deploy one or more Barracuda Load Balancers, ensure that you have changed the default password on all devices. It is recommended that you have an organizational policy in place for setting passwords with a minimum strength that are distinct from personal passwords used by employees on the public Internet. Enabling HTTPS/SSL only access to the web-based interface, as noted earlier in this article, further enhances credential security over public and private networks. The console and web-based interface use separate passwords; be sure to change both passwords. Encrypt All Configuration Backups Ensure that all manual and automated backups are encrypted so that configuration and sensitive information is not compromised in the event the backup file is compromised. To configure encryption on all configuration backups, go to the ADVANCED > Backup page, and set Encrypt Backup File to Yes. Specify a strong Backup Key using the same principals used for strong passwords. This key is required to decrypt or restore the backup configuration. Additional PCI Compliance Barracuda Networks is committed to security of its devices and helping customers achieve compliance. Barracuda Networks has additional best-of-breed security product offerings that can help you achieve additional PCI compliance cost effectively, especially for web application security, encryption, anti-virus, and web filtering. Customers evaluating Barracuda Networks products can be assured of security and compliance commitment throughout the product s life cycles. For any issues or questions related to PCI compliance, contact Barracuda Networks Technical Support or your sales representative. Scanner False Positives Following are two false positives that some scanners have reported during PCI evaluations. SNMP vulnerability Some scanners incorrectly report that the Barracuda Load Balancer is susceptible to CVE CVE CVE Barracuda Load Balancer includes a customized port of NET-SNMP version: 5.4.1, which is not susceptible to the vulnerabilities mentioned in the reports. Only versions of NET-SNMP prior to 4.2 are susceptible to these. For additional information refer to CERT Advisory CA Multiple Vulnerabilities in Many Implementations of the Simple Network Management Protocol (SNMP) available at If you encounter this false positive, submit the report to the scanning organization for validation. Additionally, Barracuda Networks has implemented the following additional security measures as recommended by the security advisory: Ability to filter SNMP traffic from non-authorized internal hosts Ability to change default community strings Ability to disable SNMP service if not explicitly required Insecure Cookies The Barracuda Load Balancer inserts cookies for a service when the Persistence type is HTTP Cookies. Some scanners confuse these with application cookies and report them as insecure if the HTTP only or secure attribute is not set. You can configure both of these from the Persistence properties of a Service to avoid this false positive.

31 Barracuda Load Balancer Administrator's Guide - Page 31 Microsoft Exchange Server 2010 Deployment This article applies to: Barracuda Load Balancer running firmware version or higher Barracuda Load Balancer 340 or above Microsoft Exchange Server 2010 This article assumes you are connected to the Barracuda Load Balancer web interface and have an activated subscription. If you wish to scale your Microsoft Exchange Server 2010 deployment with High Availability, you must first have a pair of Barracuda Load Balancers joined in a cluster. See Understanding Barracuda Load Balancer High Availability for details. In this article: Introduction Deployment Options Deployment Tasks Configure the Client Access Server (CAS) Array Prepare Your Environment for SSL Offloading Select Your Deployment Option Introduction Organizations use the Barracuda Load Balancer to distribute the load and increase the availability of their Microsoft Exchange Server 2010 deployments. Using a Barracuda Load Balancer allows load balancing of a Client Access Server (CAS) array. Barracuda Networks has conducted interoperability tests between the Barracuda Load Balancer and Microsoft Exchange Server 2010 and here provides details for deploying the Barracuda Load Balancer in this environment. Table Terminology. Term Fully Qualified Domain Name (FQDN) Virtual IP (VIP) Address Service Client Access Server (CAS) Real Server Hub Transport Server (HUB) Outlook Web App (OWA) Description The unique name for a specific computer or host that can resolve to an IP address, e.g. The IP address assigned to a Service. Clients use the Virtual IP address to connect to the load-balanced Service. A combination of a Virtual IP address and one or more TCP/UDP ports that the Barracuda Load Balancer listens on. Traffic arriving on the specified port(s) is directed to one of the Real Servers associated with a Service. Client Access Server supports various protocols used by end users to access their mailboxes. This includes services such as RPC Client Access, IMAP, POP3, OWA, and ActiveSync. A server associated with a Service that handles the requests forwarded to it by the Barracuda Load Balancer. The Hub Transport server role handles all mail flow inside the organization and delivers messages to a recipient s mailbox. Originally called Outlook Web Access, OWA is the Webmail component of Microsoft Exchange Server Deployment Options There are two configurations that are supported when adding a Barracuda Load Balancer to a Microsoft Exchange Server 2010 environment: If your Exchange servers must be on the same subnet as the rest of your topology, choose a one-armed, Route-Path deployment. If the Exchange servers may be deployed on a separate subnet from the rest of the topology, connected to the LAN side of the Barracuda Load Balancer, choose a two-armed, Route-Path deployment. Deploying in Bridge-Path or Direct Server Return with Microsoft Exchange 2010 is untested and unsupported. Deployment Tasks

32 Barracuda Load Balancer Administrator's Guide - Page 32 The following sections provide instructions for the three tasks required to deploy the Barracuda Load Balancer in the Microsoft Exchange Server environment. The third task differs based on whether this is a one-armed or two-armed deployment. For both deployment options, the first task is to configure a Client Access server array for your Exchange site. This step needs to be done only on one Exchange Server. Second, prepare to offload the SSL processing of Exchange services onto the Barracuda Load Balancer. Third, configure the Service or Services that the clients use to access the CAS array on the Barracuda Load Balancer using the deployment instructions specific to your desired configuration. If your Barracuda Load Balancers are clustered, the configuration between the active and passive systems is synchronized automatically, so you will not need to modify any passive Barracuda Load Balancers at this time. Configure the Client Access Server (CAS) Array In this task you configure MAPI client access (for example, Microsoft Outlook clients). Perform the following steps once for the Exchange domain. There are many more options you may wish to consider, and you should consult Microsoft documentation for further information. Note that Microsoft only allows one Client Access server array per site. The clients access their mailboxes using RPC, and connect to the FQDN of the RPC Client Access Array set on the mailbox database. The FQDN resolves to a Virtual IP address on the Barracuda Load Balancer. In turn, the Barracuda Load Balancer connects with one of the Client Access servers. The following steps assume a single-site Exchange environment; contact Microsoft if you need assistance configuring a CAS Array in a multi-site environment. To configure the CAS Array, 3. The command should return nothing in an unconfigured single-site deployment. 4. Using the Exchange Management Shell, enter the following command to create a new CAS array: New-ClientAccessArray -Fqdn exchange.domain.local -Site Default-First-Site-Name which the Client Access server array belongs. 5. Ping the FQDN (e.g. exchange.domain.local). The ping should fail because the Service has not yet been created on the Barracuda 6. On the DNS Server, add an A record to the DNS zone that associates the VIP address with the FQDN (e.g., exchange.domain.local) that will be used by the clients to connect to the Client Access server array. On one Exchange server in the array, open the Exchange Management Shell. Using the Exchange Management Shell, enter the following command to verify that there are no existing CAS arrays: Get-ClientAccessArray where exchange.domain.local is the FQDN of the Client Access server array and Default-First-Site-Name is the Active Directory site to Load Balancer, but make sure that the domain name resolves correctly to the VIP address. In a single-site Exchange environment, use the Exchange Management Shell to enter the following command to add a mailbox database to the CAS Array: Get-MailboxDatabase Set-MailboxDatabase -RpcClientAccessServer exchange.domain.local where exchange.domain.local is the FQDN of the Client Access server array. If you are deploying in a multiple-site Exchange environment, you should restrict the Set-MailboxDatabase cmdlet with Identity mailb ox database name to return only databases you wish to include in the CAS Array. Refer to the Microsoft TechNet online library article G et-mailboxdatabase for the cmdlet syntax. Prepare Your Environment for SSL Offloading Use the following steps to offload SSL processing to the Barracuda Load Balancer. You must complete these steps for both deployment options. In order to maintain session persistence using HTTP cookies, SSL encryption and decryption must occur on the Barracuda Load Balancer. Offloading the SSL processing to the Barracuda Load Balancer also frees up processing power on your servers. When SSL offloading is turned on, clients access the VIP address using the SSL port 443. The decrypted traffic passes between the Barracuda Load Balancer and the servers using the same VIP address but on port 80. Retrieve the certificates, certificate chain, and private key for your Exchange OWA website from your CAS servers. If you do not already have a certificate in pfx form that includes the private key and intermediaries (if applicable), refer to the Microsoft TechNet online library article Export an Exchange Certificate for instructions on exporting your Exchange certificate. Install the certificates, certificate chain, and private key on the Barracuda Load Balancer on the BASIC > Certificate page in the Barracuda Load Balancer web interface. 3. Configure the Exchange 2010 Services to be SSL offloaded.

33 3. Barracuda Load Balancer Administrator's Guide - Page 33 Follow all of the steps in the the Microsoft TechNet online library article How to Configure SSL Offloading in Exchange 2010 for how to configure OWA, Outlook Anywhere (OA), Exchange Control Panel (ECP), Exchange Web Services (EWS), and ActiveSync (EAS) for SSL offloading. If you do not wish to turn off SSL on the Exchange IIS website, ensure you complete the optional steps when setting up services to enable Backend SSL on each Real Server. 4. There are a few more steps related to SSL offloading that will be performed in the next task. Select Your Deployment Option If your Exchange servers must be on the same subnet as the rest of your topology, choose a one-armed, Route-Path deployment. Continue with: How to Deploy Microsoft Exchange Server 2010 in a One-Armed Configuration If the Exchange servers may be deployed on a separate subnet from the rest of the topology, connected to the LAN side of the Barracuda Load Balancer, choose a two-armed, Route-path deployment. Continue with: How to Deploy Microsoft Exchange Server 2010 in a Two-Armed Configuration Refer to the Microsoft TechNet online library for more information on the following topics: Load Balancing Requirements for Exchange Protocols Configure SSL Offloading for Outlook Anywhere Microsoft Exchange Network Port Reference Understanding Load Balancing in Exchange 2010 Create a New Exchange Certificate

34 Barracuda Load Balancer Administrator's Guide - Page 34 How to Deploy Microsoft Exchange Server 2010 in a One-Armed Configuration Before completing a one-armed configuration, verify you have completed all of the steps in Microsoft Exchange Server 2010 Deployment. If you plan to use a two-armed configuration, refer to How to Deploy Exchange 2010 in a Two-Armed Configuration. In a one-armed configuration, the ports to be used by internal Outlook clients when communicating with the Exchange 2010 server using RPC must be pre-configured on both Exchange 2010 and the Barracuda Load Balancer. If your organization wishes to use a single VIP address and single FQDN for your Exchange deployment, you must use a one-armed configuration: Step Configure Exchange 2010 to use a Static Port Step Configure CAS Services on the Barracuda Load Balancer Step 3. Configure Hub Transport Services on the Barracuda Load Balancer Step 4. Configure a Rewrite Rule Step Configure Exchange 2010 to use a Static Port By default, the Exchange 2010 RPC client dynamically selects a port between 1024 and To allow for a one-armed deployment, configure Exchange to use a static port instead. Refer to the Microsoft TechNet online library article Load Balancing Requirements of Exchange Protocols for more detailed instructions on configuring Exchange 2010 with static ports and hardware load balancers. On each CAS server, complete the following: 1a. Configure the static port in the registry. Open the Registry Editor by typing regedit in the Start menu. Add a DWORD (32-bit) value named TCP/IP Port under HKEY_LOCL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeRpc\ParametersSystem You may need to create the ParametersSystem key prior to adding the DWORD registry value. In this case, when prompted, change the Base to Decimal and set the value data to (or a port of your choice between 1024 and 65535): If you have Public Folders in your deployment, you must also repeat this step on each server with the mailbox role installed that hosts a Public Folder. 1b. Change the port that clients use to connect for directory access. On each CAS server, complete the following: If you are running Microsoft Exchange 2010 RTM (including RTM Rollup 1-4), follow these instructions: a. In Windows Explorer, navigate to the Microsoft.exchange.addressbook.service.exe.config file. This file is located in the \Bin folder in the root directory of your Exchange 2010 install. b. Open this file using Notepad. c. Change the default value of 0 on line 13 to (or a port of your choice within the prior specified range) so it appears as follows, including the quotations: <add key="rpctcpport" value="65501" /> If you are running Microsoft Exchange 2010 SP1, follow these instructions: a. Configure the static port in the registry. To do this, open the Registry Editor by typing regedit in the Start menu. b. Add a String value ( REG_SZ) with Value name RpcTcpPort under HKEY_LOCL_MACHINE\SYSTEM\CurrentControlSet\services\MSExchangeAB\Parameters

35 Barracuda Load Balancer Administrator's Guide - Page 35 You may need to create the Parameters key prior to adding the REG_SZ registry value. In this case, change the value data to (or a port of your choice between 1024 and 65535): 1c. Restart the Microsoft Exchange Address Book and the Microsoft Exchange RPC Client Access services on all CAS and Mailbox servers that you modified. 1d. To test that your Client Access servers are using ports and 65501, open a Windows command prompt and run netstat na 1e. In the output, look for TCP entries marked as LISTENING with the ports and 6550 You will see an entry marked as LISTENING for :65500 and :6550 Step Configure CAS Services on the Barracuda Load Balancer On each active Barracuda Load Balancer that handles traffic for CAS Services, complete the following steps to configure CAS Services for Exchange 2010: 2a. Log into the Barracuda Load Balancer, and go to the BASIC > Services page. 2b. Add each Service listed in Table 1 and Table 2 by following these steps. Use the Basic View. In the Add New Service pane, if you are in the Advanced View, select Switch to Basic View Enter the Service Name. Enter the Virtual IP Address specified in the table. Select the protocol, and enter the Port for the Service from the table. Enter the Real Servers IP addresses for each server in the CAS array. Table Required Services. Service Name MAPI / DCOM MAPI / RPC Client Access MAPI / Global Address Book Virtual IP Address VIP address for FQDN that resolves to CAS array e.g. exchange. domain.local VIP address for FQDN that resolves to CAS array e.g. exchange. domain.local VIP address for FQDN that resolves to CAS array e.g. exchange. domain.local Protocol Service Type Service Port Real Server Port Monitor Port TCP TCP Proxy TCP TCP Proxy TCP TCP Proxy

36 Barracuda Load Balancer Administrator's Guide - Page 36 Exchange Services HTTPS Exchange Web Services HTTP Redirect VIP address for FQDN that clients use to access CAS array e.g. exchange. domain.local VIP address for FQDN that clients use to access CAS array e.g. exchange. domain.local TCP Layer 7 - HTTPS * 80* TCP Layer 7 - HTTP 80 N/A* N/A *Note: If your deployment requires end-to-end encryption of Exchange traffic, the Real Server and Monitor Port for the Exchange Services HTTPS service is 443, not 80. Table Optional Services. Service Name IMAP4 (optional) IMAP4 SSL (optional) POP3 (optional) POP3 SSL (optional) Virtual IP Address VIP address for FQDN that resolves to CAS array e.g. exchange. domain.local VIP address for FQDN that resolves to CAS array e.g. exchange. domain.local VIP address for FQDN that resolves to CAS array e.g. exchange. domain.local VIP address for FQDN that resolves to CAS array e.g. exchange. domain.local Protocol Service Type Service Port Real Server Port Monitor Port TCP TCP Proxy TCP TCP Proxy TCP TCP Proxy TCP TCP Proxy c. Once all of the Services are created, edit each Service as specified: On the BASIC > Services page, click the Edit icon for the Service you wish to edit. In the Service Detail page, for each service in the following table, edit the settings and save your changes: Service Name Service Detail Page Settings

37 Barracuda Load Balancer Administrator's Guide - Page 37 Exchange Web Services (Port 443) In the General section, set Service Type to Layer 7 - HTTPS. In the SSL Offloading section, in the Certificate menu, select the certificate that you uploaded in Prepare Your Environment for SSL Offloading. In the Persistence section, set Persistence Type to HTTP Header, set Persistence Time to 1200, and set Header Name t o Authorization. In the Advanced Options section, set Session Timeout to Exchange Web Services HTTP Redirect In the General section, set Service Type to Layer 7 - HTTP. Set Ena ble HTTP Redirect to Yes. IMAP4 (Port 143) IMAP4 / SSL (Port 993) In the General section, set Service Type to TCP Proxy. Persistence is not required for these Services as they are transactional based. POP3 (Port 110) POP3 SSL (Port 996) MAPI / RPC Client Access (Port 65500) MAPI / DCOM (Port 135) MAPI / Global Address Book (Port 65501) In the General section, set Service Type to TCP Proxy. In the Persistence section, set Persistence Time to Set Persistence Type to Client IP. In the Advanced Options section, set Session Timeout to d. Use the following steps to change the port and Server Testing Method for every Real Server associated with the Exchange Web Services Service: 3. On the BASIC > Services page, for each Real Server associated with the Exchange Web Services Service, click the Edit icon; the Real Server Detail page displays. In the Real Server Detail section, set Port to 80. In the Server Monitor section: Set the Testing Method to Simple HTTP Set the Port to 80 Change the Test Target to /owa/auth/logon.aspx If you have modified the path of logon.aspx from the Exchange 2010 default, use the modified path in the Test Target. Change Test Match to 2006 Microsoft Corporation Change Additional Headers to User-Agent: Barracuda Load Balancer Server Monitor Set the Status Code to 200 and set the Test Delay to 30 2e. Create two content rules for the Exchange Web Services Service to maintain persistence for Outlook Web Access and the Exchange Control Panel. On the BASIC > Services page, click Rule in the Add column of the Exchange Web Services Service. On the Add Rule page, configure the rule. Use the following table to add the rule for Outlook Web Access: Rule Parameter Name Rule Name Rule Setting OWA Host Match * URL Match Persistence Type Cookie Name /owa/* HTTP Cookie sessionid Persistence Time (Seconds) 1200 Click Save Changes. Use the following table to add the rule for the Exchange Control Panel. On the BASIC > Services page, click Rule in the Add column of the

38 Barracuda Load Balancer Administrator's Guide - Page 38 Exchange Web Services Service. On the Add Rule page, configure the rule. Rule Parameter Name Rule Name Rule Setting ECP Host Match * URL Match Persistence Type Cookie Name /ecp/* HTTP Cookie sessionid Persistence Time (Seconds) 1200 Click Save Changes. Outlook Anywhere Users If you are using Outlook Anywhere (HTTPS only, not RPC over HTTPS), you must create an extra content rule. For Outlook Anywhere, use the following table to add the rule for the Offline Address Book: Rule Parameter Name Rule Name Rule Setting OAB Host Match * URL Match Persistence Type Cookie Name /oab/* HTTP Cookie sessionid Persistence Time (Seconds) f. If Real Servers are segregated and secure in your network, we recommend not enabling back-end SSL for each Real Server thereby avoiding

39 Barracuda Load Balancer Administrator's Guide - Page 39 additional processing load. But if you require end-to-end encryption of Exchange Web Services data, direct the Barracuda Load Balancer to re-encrypt traffic before sending it to the Real Server: On the BASIC > Services page, for each Real Server associated with the Exchange Web Services Service, click the Real Server Edit ic on; the Real Server Detail page displays. 3. In the Real Server Detail section, set Port to 443. In the SSL section, set Enable HTTPS/SSL to Yes. Traffic is now encrypted using the same key uploaded and created from your Exchange CAS array. If this setting is enabled, Exchange Web Services will no longer need to accept unencrypted sessions on port 80. This increases processing load on both the Barracuda Load Balancer and all CAS Array members. Step 3. Configure Hub Transport Services on the Barracuda Load Balancer On each active Barracuda Load Balancer that handles traffic for Hub Transport Services, complete the following steps to configure Hub Transport Services for Exchange a. Log into the Barracuda Load Balancer, and go to the BASIC > Services page. 3b. Using the following table, add the SMTP Service and, optionally, the SMTP / SSL Service. To add a Service (use the Basic View. These instructions assume you do not Switch to Advanced View): In the Service Name box, enter the name for the Service. Enter the Virtual IP Address specified in the table. Select the protocol and enter the Port for the Service in the table. In the Real Servers box, if your Real Servers are consolidated with both the CAS and HUB roles installed, enter the IP address for each Service you create. If the Hub Transport role is installed on separate servers from the CAS role, enter the IP addresses of only the servers with the Hub role installed. The created Services load balance the SMTP traffic to the Hub transport servers for incoming client SMTP connections. Exchange Hub Transport should never be configured to communicate with other internal Microsoft Exchange Hub Servers via the Barracuda Load Balancer. The Service on the Barracuda Load Balancer should only be used for client connections or inbound connections from other organizations. Service Name SMTP SMTP / SSL (optional) Virtual IP Address VIP address for FQDN that resolves to CAS array e.g. exchange.domai n.local VIP address for FQDN that resolves to CAS array e.g. exchange.domai n.local Protocol Service Type Service Port Real Server Port Monitor Port TCP TCP Proxy TCP TCP Proxy c. To change the Service type for the SMTP and SMTP / SSL Services to TCP Proxy: 3. On the BASIC > Services page, click the Edit icon for the Service. In the Service Detail page, in the General section, set the value of Service Type to TCP Proxy. Save your changes. Step 4. Configure a Rewrite Rule Use the following steps to configure a rewrite rule to add '/OWA' to the end of the URL: 4a. Log into the Barracuda Load Balancer, and go to the WEBSITES > URL Rewrites page. 4b. In the Layer 7 - HTTP Services section, select the newly created service. 4c. In the HTTP Request Rewrite section, create a new rule, for example OWA:

40 Barracuda Load Balancer Administrator's Guide - Page 40 4d. Click Add. In the Rule Order field, enter 3 For the Action, select Redirect URL. Leave the Header Name field blank In the Old Value field, enter / In the Rewrite Value field, enter a slash (/) and the rule name, for example /OWA In the Rewrite Condition field, enter * Your installation is complete. Continue to How to Test the Microsoft Exchange Server 2010 Deployment Configuration. Outlook Anywhere Users If you are using Outlook Anywhere (HTTPS only, not RPC over HTTPS), you must create an extra content rule for the Offline Address Book.

41 Barracuda Load Balancer Administrator's Guide - Page 41 How to Deploy Microsoft Exchange Server 2010 in a Two-Armed Configuration Before completing a two-armed configuration, verify you have completed all of the steps in Microsoft Exchange Server 2010 Deployment. If you plan to use a one-armed configuration, go to How to Deploy Exchange 2010 in a One-Armed Configuration. In this article: Step Create Services Step Configure a Rewrite Rule In a two-armed configuration, create Services for Exchange Services on the active Barracuda Load Balancer by doing the following steps. Step Create Services 1a. Log into the Barracuda Load Balancer, and go to the BASIC > Services page. 1b. For each entry in the following table, add a Service: Enter the Service Name. Enter the Virtual IP Address specified in the table. Select the protocol, and enter the Port specified for the Service in the table. Enter the IP address of each real server in the CAS array under Real Servers. Service Name Exchange Virtual IP Address VIP address for FQDN that resolves to CAS array e.g. exchange. domain.local Note: This service is helpful in cases where there is no port restriction. Protocol Service Type Service Port Real Server Port Monitor Port TCP Layer 4 ALL N/A 443 OWA - HTTPS VIP address for FQDN that clients use to access OWA e.g. owa.domai n.local Note: This service is helpful if there are port restrictions, and traffic is allowed only for port 443. TCP Layer 7 - HTTPS HTTP Redirect VIP address for FQDN that clients use to access OWA e.g. owa.domai TCP Layer 7 - HTTP 80 N/A (Redirect Service) 80 n.local Note: This service is needed to automatically redirect the users to the HTTPS service. 1c. Add the following Services if you have deployed the Hub Transport Role on separate servers from the servers with the CAS Role. The

42 Barracuda Load Balancer Administrator's Guide - Page 42 Services in the following table are optional and depend on your environment. Service Name SMTP SMTP / SSL (optional) Virtual IP Address VIP address for FQDN that resolves to HUB Services e.g. smtp.doma in.local VIP address for FQDN that resolves to HUB Services e.g. smtp.doma in.local Protocol Service Type Service Port Real Server Port Monitor Port TCP Layer TCP Layer d. Once all of the Services are created, use the following steps to edit the settings: On the BASIC > Services page, for each Service, click the Edit icon to edit the settings. In the Service Detail page, for each service in the following table, edit the settings and save your changes: Service Name Service Detail Page Settings Exchange In the Persistence section, set Persistence Time (Seconds) to OWA - HTTPS In the General section, set the value of Service Type to Layer 7 - HTTPS. In the SSL Offloading section, in the Certificate menu, select the certificate that you uploaded in Preparing Your Environment for SSL Offloading. In the Persistence section, set Persistence Time to Set Persistence Type to HTTP Header. In the Header Name field, set the value to Authorization. In the Advanced Options section, set Session Timeout to HTTP Redirect In the General section, set the value of Service Type to Layer 7 - HTTP. Set Enable HTTP Redirect to Yes. 1e. Change the port and Server Testing Method for every Real Server associated with the OWA HTTPS / Outlook Anywhere Service: 3. On the BASIC > Services page, click the Edit icon for each Real Server associated with the OWA - HTTPS Service; The Real Server Detail page displays. In the Real Server Detail section, set Port to 80. In the Server Monitor section: Set the Testing Method to Simple HTTP. Set the Port to 80. Change the Test Target to /owa/auth/logon.aspx If you have modified the path of logon.aspx from the Exchange 2010 default, use the modified path in the Test Target. Change Test Match to 2006 Microsoft Corporation Change Additional Headers to User-Agent: Barracuda Load Balancer Server Monitor Set the Status Code to 200 and set the Test Delay to 30. 1f. Update TCP timeout values on the Barracuda Load Balancer: Log into the Barracuda Load Balancer, and go to the ADVANCED > System Settings page. Set the TCP Connections Timeout and TCP Closed ConnectionsTimeout to 1200 seconds. Step Configure a Rewrite Rule Use the following steps to configure a rewrite rule to add '/OWA' to the end of the URL:

43 Barracuda Load Balancer Administrator's Guide - Page 43 2a. Log into the Barracuda Load Balancer, and go to the WEBSITES > URL Rewrites page. 2b. In the Layer 7 - HTTP Services section, select the newly created service. 2c. In the HTTP Request Rewrite section, create a new rule, for example OWA: 2d. Click Add. In the Rule Order field, enter 3 From the Action drop-down menu, select Redirect URL Leave the Header Name field blank. In the Old Value field, enter / In the Rewrite Value field, enter slash (/) and the rule name, for example /OWA In the Rewrite Condition field, enter * Your installation is complete. Continue to How to Test the Microsoft Exchange Server 2010 Deployment Configuration.

44 Barracuda Load Balancer Administrator's Guide - Page 44 How to Test the Microsoft Exchange Server 2010 Deployment Configuration Before testing the configuration, verify you have completed all of the steps in How to Deploy the Barracuda Load Balancer with Microsoft Exchange Server 2010, and either How to Deploy Exchange 2010 in a One-Armed Configuration or How to Deploy Exchange 2010 in a Two-Armed Configuration. Configure an Outlook Client Use the following steps to configure an Outlook client on your local network: If Autodiscover is enabled, ensure clients are connected to your CAS array and the VIP address that you just configured, and that there are no certificate errors. If Autodiscover is not enabled, configure an Outlook client to connect to the FQDN of the new CAS array you just configured. While configuring a new Exchange account, type in the FQDN of one of the Real Servers (members) of the CAS array. Enter a valid account name and click Check Name. Ensure that the Exchange Server name gets rewritten as the FQDN of the CAS array and the account name is underlined. Open the Global Address book in Outlook, and make sure it behaves normally. Watch an authenticated and connected Exchange client and ensure that it remains connected to Exchange while idle and does not disconnect and reconnect within one or two minutes. Test SSL Offloading Use the following steps to test SSL offloading: Open a browser and go to the FQDN of the VIP address for your SSL-offloaded HTTPS Service (for Outlook Anywhere and Outlook Web App). Ensure the browser has no certificate errors or warnings and that the certificate presented by the browser is the same one that was assigned to the SSL-offloaded Service. Diagnostic View For a complete diagnostic view of all Client Access Server parameters for each server in the array, from the Exchange Management Shell, execute the following command: Get-ClientAccessServer fl Connectivity To check the connectivity between the Exchange CAS array and Outlook, press Ctrl and right-click the Outlook icon in the system tray, and click Connection Status. Verify all connections are listed as established. Related Articles Microsoft Exchange Server 2010 Deployment How to Deploy Microsoft Exchange Server 2010 in a One-Armed Configuration How to Deploy Microsoft Exchange Server 2010 in a Two-Armed Configuration

45 Barracuda Load Balancer Administrator's Guide - Page 45 Microsoft Exchange Server 2013 Deployment This article applies to: Barracuda Load Balancer running firmware version or higher Barracuda Load Balancer 340 or above Microsoft Exchange Server 2013 This article assumes you are connected to the Barracuda Load Balancer web interface and have an activated subscription. In this article: Step Create Services Step Edit the Settings Step 3. Configure HTTPS Connection to the CAS Server Step 4. HTTPS Service Health Checks Step 5. Configure DNS Step 6. Configure Hub Transport Services on the Barracuda Load Balancer Step Create Services 1a. Log into the Barracuda Load Balancer as the administrator, and go to the BASIC > Service page. 1b. Click Advanced View, and add a Service for all items in Table 1 below: In the Server Name field, enter the Service name In the Service Type field, select the Server type In the Virtual IP field, enter the Virtual IP address Select the protocol, and enter it in the port in the associated field Choose the interface to be bound to 6. Add the Real Server IP addresses, and add the port of the CAS servers IP address. To add multiple servers click on the button. Table Services. Service Name HTTPS Virtual IP Address VIP Address of t he FQDN that cli ent use to access mail.domin.local autodiscover.do main.local eas.domain.local outlook.domain.l ocal oab.domain.local ecp.domain.local Protocol Service Type Service Port Real Server Port Monitor Port TCP Layer 7 HTTPS

46 Barracuda Load Balancer Administrator's Guide - Page 46 HTTP Redirect VIP Address of the FQDN that client use to access TCP Layer 7 HTTP 80 N/A Redirect Service 80 mail.domin.local autodiscover.do main.local eas.domain.local outlook.domain.l ocal oab.domain.local ecp.domain.local Step Edit the Settings Once the Services are configured, edit the Service settings using the values in Table Table Service Settings. Service Name HTTPS Service Details Page Setting Persistence Setting Set Persistence Time: 1200 Persistence Type: HTTP Cookie Cookie name: Choose a cookie name Session Timeout Settings (found at the bottom of the page in the Adv anced section) Set Session Timeout: 1200 SSL Offloading Certificate: Choose a certificate that you have uploaded to the Barracuda Load Balancer HTTP Redirect In the General Section, set the value Enable HTTP Redirect to yes. Step 3. Configure HTTPS Connection to the CAS Server Click Edit on the Server setting using the values in Table 3. Table 3. Server Details Service Name HTTPS Server Details Setting Edit the Server details, Edit the SSL the config to enable HTTPS / SSL Certificate validation can be ignored Step 4. HTTPS Service Health Checks 4a. Go to the BASIC > Services page, and click the Edit icon for each Real Server associated with the OWA - HTTPS Service; The Real Server Detail page displays. 4b. In the Real Server Detail section, set Port to c. In the Server Monitor section, set the following values: Set the Testing Method to Simple HTTPS. Set the Port to 443. Change the Test Target to: /owa/auth/logon.aspx If you have modified the path of logon.aspx from the Exchange 2013 default, use the modified path in the Test Target.

47 Barracuda Load Balancer Administrator's Guide - Page Config Test Match to: 2011 Microsoft Corporation Change Additional Headers to: User-Agent: Barracuda Load Balancer Server Monitor Set the Status Code to 200 and set the Test Delay to 30. Step 5. Configure DNS Once the configuration is complete you can configure the DNS for mail.domain.local, autodiscover.domain.local,eas.domain.local, outlook.domain.local, oab.domain.local, ecp.domain.local to point to the VIP created for the HTTP & HTTPS Service using the following steps: 5a. Configure HTTPS namespace on the Exchange Admin Center: Log into your Microsoft Exchange Admin Center. Click on Servers, click on the virtual directories, click edit on CAS1, and configure external access domain: 3. Add both the servers to the list and configure the external domain:

48 Barracuda Load Balancer Administrator's Guide - Page 48 5b. Click save to save the configuration. Certificates Barracuda Networks recommends that you use the same certificate on both the Barracuda Load Balancer and on CAS arrays. Step 6. Configure Hub Transport Services on the Barracuda Load Balancer On each active Barracuda Load Balancer that handles traffic for Hub Transport Services, complete the following steps to configure Hub Transport Services for Exchange. 6a. Log into the Barracuda Load Balancer, go to the BASIC > Services page, and expand the Add New Service section. 6b. Add the SMTP Service and, optionally, the SMTP/SSL Service listed in Table 4. Table 4. SMTP Service Service Name Virtual IP Address Protocol Service Type Service Port Real Server Port SMTP VIP address for FQDN that resolves to CAS array. For example: exchange.domain.lo cal TCP TCP Proxy 25 25

49 Barracuda Load Balancer Administrator's Guide - Page 49 (Optional) SMTP/SSL VIP address for FQDN that resolves to CAS array. For example: exchange.domain.lo cal TCP TCP Proxy In the Real Server field, if your Real Servers are consolidated with both the CAS and HUB roles installed, enter their IP addresses for each Service that you create. If the Hub Transport role is installed on separate servers (other than those with the CAS role), enter the IP addresses of only the servers with the Hub role installed. The created Services load balance the SMTP traffic to the Hub transport servers for incoming client SMTP connections. Exchange Hub Transport should never be configured to communicate with other internal Microsoft Exchange Hub Servers via the Barracuda Load Balancer. The Service on the Barracuda Load Balancer should only be used for client connections or inbound connections from other organizations.

50 Barracuda Load Balancer Administrator's Guide - Page 50 Remote Desktop Services in Windows Server 2008 R1 or R2 Deployment This article refers to firmware version and higher running on a configured Barracuda Load Balancer 340 or higher, and Microsoft Windows Server 2008 R1 or R2 Standard, Enterprise, or Datacenter Edition. In this article: Prerequisites Terminology Remote Desktop Services Deployment Options Deployment Tasks Prerequisites Microsoft Server 2008 R1/R2 Standard, Enterprise, or Datacenter Edition Session Broker (optional but highly recommended - for purposes of this deployment, it is presumed that Session Broker will be installed and configured as described in Step 1) Barracuda Load Balancer 340 or higher Barracuda Load Balancer running firmware version or higher Minimum one Barracuda Load Balancer, two recommended for high availability (HA) Note: If you are planning to deploy Remote Desktop Services with HA, you must first cluster your Barracuda Load Balancers. See the article Und erstanding Barracuda Load Balancer High Availability. Terminology Term Remote Desktop Services Fully Qualified Domain Name (FQDN) Service Remote Desktop or Terminal Services Session Broker (RD Session Broker or TS Session Broker) Routing Token Domain Controller Remote Desktop Session Host (RD Session Host) Definition Known as Terminal Services in Windows Server 2008 and Windows Server One of the components of Microsoft Windows that allows users to remotely access applications and data. The unique name for a specific computer or host that can resolve to an IP address, e.g. A combination of a virtual IP (VIP) address and one or more TCP/UDP ports that the Barracuda Load Balancer listens on. Traffic arriving over the specified port(s) is directed to one of the Real Servers associated with a particular Service. An optional component of Remote Desktop Services. It maintains a list of active and disconnected sessions so that a disconnected user is transparently redirected and connected to the server that has its disconnected session. Used to redirect users to their existing sessions on the correct Terminal Server. A server that responds to security authentication requests. The terminal server (the term used by Windows Server 2008) that runs the applications for the Remote Desktop users. Remote Desktop Services Deployment Options Deployments of Remote Desktop Services are supported in either a onearmed or a twoarmed topology. This may be either a single or multiple subnet configuration. Unless the users need to directly access individual servers, it is recommended that the servers be placed in one or more subnets reachable by the LAN port of the Barracuda Load Balancer. If users must directly access individual servers, a onearmed deployment is recommended. Important Direct Server Return (DSR) and Bridge Mode are not supported in a Remote Desktop Services deployment. Deployment Tasks

51 Barracuda Load Balancer Administrator's Guide - Page 51 To deploy the Barracuda Load Balancer for Remote Desktop Services, complete the following tasks: Task Step Configure Session Broker Where Do this on the Session Broker for your Remote Desktop farm. Step Configure Real Servers Do this on every Real Server in the server farm. Step 3. Configure the Remote Desktop Services on the Barracuda Load Balancer Step 4. Test the Remote Desktop Services installation Do this on the active Barracuda Load Balancer. Do this using a client that can access the Virtual IP address that you create in Step 3. If the Barracuda Load Balancers are clustered, the configuration between the active and passive systems is synchronized; there is no need to modify any passive Barracuda Load Balancers. For additional information, refer to the TS Session Broker load Balancing Step-by-Step Guide available on the Microsoft TechNet website.

52 Barracuda Load Balancer Administrator's Guide - Page 52 Step 1: How to Configure Session Broker with Remote Desktop Services in Windows Server 2008 R1 or R2 This article refers to firmware version and higher running on a configured Barracuda Load Balancer 340 or higher, and Microsoft Server 2008 R1 or R2 Standard, Enterprise, or Datacenter Edition. For prerequisites, refer to Remote Desktop Services in Windows Server 2008 R1 or R2 Deployment. Session Broker provides a mechanism for a disconnected user to be reconnected to the server that has its disconnected session. Installing Session Broker greatly improves the overall experience for end-users; installation is optional, but highly recommended by Barracuda Networks. This article describes how to install and configure Session Broker with Remote Desktop Services in Windows; if you choose not to deploy Session Broker, ensure the following: Verify the Group Policy for the domain does not allow for disconnected sessions. Verify users are limited to one connection in a Group Policy Object for your domain. Complete the installation and configuration described below on the Session Broker server to ensure that its settings are correctly configured. Install Session Broker Install the Session Broker role service on a server by performing the following steps Go to Start > Server Manager. Under Server Manager (Server Name), click Roles. Under Roles Summary, click Add Roles. On the Select Server Roles page, turn on Remote Desktop Services and click Next. On the Select Role Services page, select Remote Desktop Connection Broker. Complete the Add Roles Wizard. Configure Session Broker Set up a Session Brokerage privileges list to tell the Session Broker which computers are authorized to be brokered; perform the steps that match your environment. If the Session Broker is on a server that is also a domain controller, use the following steps: Go to Start > Administrative Tools > Active Directory Users and Computers. Expand your domain and select Users (even though this is a group, it is still listed under Users). Double-click the group Session Broker Computers to view its properties. Add all of the servers in your domain that are to be used for Remote Desktop Services load balancing. Important: You must add the Session Broker server to this list. Failure to do so results in the Session Broker being denied RPC privileges. If the Session Broker is not on a server that is a domain controller, use the following steps: Go to Start > Server Manager. Expand Configuration, and click Local Users and Groups. Click Groups. Double-click the group Session Broker Computers to view its properties. Add all of the servers in your domain that are to be used for Remote Desktop Services load balancing. Important: You must add the Session Broker server to this list. Failure to do so results in the Session Broker being denied RPC privileges. Go to Step How to Configure the Real Servers. Related Articles Deployment Options Remote Desktop Services in Windows Server 2008 R1 or R2 Deployment

53 Barracuda Load Balancer Administrator's Guide - Page 53 Step 2: How to Configure the Real Server with Remote Desktop Services in Windows Server 2008 R1 or R This article refers to firmware version and higher running on a configured Barracuda Load Balancer 340 or higher, and Microsoft Server 2008 R1 or R2 Standard, Enterprise, or Datacenter Edition. For prerequisites, refer to Remote Desktop Services in Windows Server 2008 R1 or R2 Deployment. Complete the tasks in Step How to Configure Session Broker prior to completing Step 2 of the deployment. Complete the following steps on each Real Server in the server farm to identify it as a Remote Desktop Session Host. Go to Start > Administrative Tools > Remote Desktop Services > Remote Desktop Session Host Configuration. On the main screen, near the bottom of the center pane, double-click Member of farm in RD Connection Broker. Click the RD Connection Broker tab. Unselect the Participate in Connection Broker Load-Balancing check box. In the RD Connection Broker field, type the FQDN for the Real Server that is running Session Broker. In the Farm name field, enter a farm name. You must use the same farm name on every Remote Desktop Session Host. Select Use Token Redirection from the drop-down list. Select the checkbox for the IPv4 address of your Real Server. Go to Step 3. How to Configure the Remote Desktop Services. Related Articles Deployment Options Remote Desktop Services in Windows Server 2008 R1 or R2 Deployment How to Associate Real Servers with a Service How t o Enable or Disable Real Servers

54 Barracuda Load Balancer Administrator's Guide - Page 54 Step 3: How to Configure Remote Desktop Services with Remote Desktop Services in Windows Server 2008 R1 or R2 This article refers to firmware version and higher running on a configured Barracuda Load Balancer 340 or higher, and Microsoft Server 2008 R1 or R2 Standard, Enterprise, or Datacenter Edition. For prerequisites, refer to Remote Desktop Services in Windows Server 2008 R1 or R2 Deployment. Complete the tasks in Step How to Configure the Real Server prior to completing Step 3 of the deployment. Use the following steps to add the Remote Desktop Service on the active Barracuda Load Balancer. Go to the BASIC > Services page in the web interface. Add the RDP Service: In the Service Name box, enter the name for the Service, e.g. RDP. In the Virtual IP Address box, enter the IP address for the FQDN of your Remote Desktop Service, e.g., rdp.domain.local. Select TCP from the drop-down list. In the Port box, enter In thereal Servers box, enter the internal IP address for every Real Server running the Remote Desktop Host Role. To edit the Service, click the Edit ( ) icon next to the Service entry in the table. The Service Detail page displays. Complete the following in the Service Detail page: In the General section, set the Service Type to Layer 7 RDP. In the Service Monitor section, set the Testing Method to RDP. Go to Step 4. How to Test the Remote Desktop Services. Related Articles Deployment Options Remote Desktop Services in Windows Server 2008 R1 or R2 Deployment

55 Barracuda Load Balancer Administrator's Guide - Page 55 Step 4: How to Test the Installation of Remote Desktop Services in Windows Server 2008 R1 and R This article refers to firmware version and higher running on a configured Barracuda Load Balancer 340 or higher, and Microsoft Server 2008 R1 or R2 Standard, Enterprise, or Datacenter Edition. For prerequisites, refer to Remote Desktop Services in Windows Server 2008 R1 or R2 Deployment. Complete the tasks in Step 3. How to Configure the Remote Desktop Service prior to completing Step 4 of the deployment. Complete the following tests. Create two test users that have permission to log into Remote Desktop Services (e.g., testuser1 and testuser2). Using Remote Desktop Connection, connect testuser1 to the Virtual IP Address created in Step 3. Open Notepad and enter some text; do not close Notepad. Click Start > Disconnect. Connect testuser2 to the Virtual IP Address created in Step 3. Once testuser2 is logged in, click Start > Disconnect. Log in testuser1 again and ensure it reconnects to the session with Notepad open. Log in testuser2 again and ensure the session reconnects to the testuser2 session. Your installation is now complete. Related Articles Deployment Options Remote Desktop Services in Windows Server 2008 R1 or R2 Deployment

56 Barracuda Load Balancer Administrator's Guide - Page 56 Microsoft Office Communications Server Deployment Prerequisites: Barracuda Load Balancer running firmware version or higher Barracuda Load Balancer 340 or above Microsoft Office Communications Server 2007 R2 Enterprise Edition Connection to the Barracuda Load Balancer web interface and an activated subscription To deploy Microsoft Office Communications Server with the Barracuda Load Balancer, see the following articles: Understanding Microsoft Office Communications Server Deployment Microsoft Office Communications Server Deployment Example How to Deploy with Microsoft Office Communications Server Refer to the Microsoft TechNet online library for more information on the following topics: Load Balancing Requirements for Office Communications Server 2007 Enterprise Pools: Load Balancers for Office Communications Server 2007 R2: Load Balancer Requirements for Edge Servers: Using a Load Balancer to Increase Capacity and Availability:

57 Barracuda Load Balancer Administrator's Guide - Page 57 Understanding Microsoft Office Communications Server Deployment This article applies to: Barracuda Load Balancer running firmware version or higher Barracuda Load Balancer 340 or above Microsoft Office Communications Server 2007 R2 Enterprise Edition This article assumes you are connected to the Barracuda Load Balancer web interface and have an activated subscription. Organizations use solutions like Microsoft Office Communications Server to allow them to effectively disseminate information and enhance collaborative efforts among their employees. Microsoft Office Communication Suite offers functionality such as VoIP, instant messaging and web collaboration. All these Services can be utilized by clients from either the internal office network or from the Internet. Companies deploying Microsoft Office Communication Servers for higher traffic throughput look to deploy a scalable solution. To scale the deployment of the Microsoft Office Communication Server solution, Microsoft recommends using a hardware load balancer to distribute the traffic among multiple Office Communications Servers. Barracuda Networks has conducted interoperability tests between the Barracuda Load Balancer and Office Communications Server 2007 R This document describes some ways to deploy the Barracuda Load Balancer to provide scaling in an Office Communications Server environment. Table Terminology. Term Front-End Server Edge Server Fully Qualified Domain Name (FQDN) Virtual IP (VIP) Address Service Description A Microsoft Office Communications Server in the internal network. A Microsoft Office Communications Server deployed in the perimeter network. The unique name for a specific computer or host that can resolve to an IP address, e.g. The IP address assigned to a Service. Clients use the Virtual IP address to connect to the load-balanced Service. A combination of a Virtual IP address and one or more TCP/UDP ports that the Barracuda Load Balancer listens on. Traffic arriving on the specified port(s) is directed to one of the Real Servers associated with a Service. Deployment Recommendations High Availability If you wish to scale your Microsoft Office Communications Server deployment with High Availability, you must first have a pair of Barracuda Load Balancers joined in a cluster. Note that if your Barracuda Load Balancers are already clustered, the configuration between the active and passive systems is synchronized automatically, so you will not need to modify any passive Barracuda Load Balancers at this time. Internal Office Communications Minimum one Barracuda Load Balancer, two recommended for high availability. Internal Office Communications Deployment and Edge Deployment Minimum two Barracuda Load Balancers, four recommended for high availability. Internal Office Communications Deployment, Edge Deployment, and Communicator Web Access Deployment Minimum three Barracuda Load Balancers, six recommended for high availability. Deployment Options The following options are supported in an Office Communications Server and the Barracuda Load Balancer deployment: Office Communications Front-End Server Deployment Options - Servers in an Office Communications Server enterprise pool communicate with each other using the VIP address of the pool. To facilitate this communication, create a TCP Proxy Service and associate the servers with it. The servers and the Barracuda Load Balancer must be deployed using a one-armed topology in either a single or multiple subnet configuration. Deploying internal Office Communications Server pools using a two-armed topology (Route-Path), Direct Server Return (DSR) or Bridge Mode does not work. Office Communications Edge Server Deployment Options - Load balanced Edge deployments are supported using either a one-armed topology using a TCP Proxy Service or a two-armed (Route-Path) topology using a Layer 4 Service.

58 Barracuda Load Balancer Administrator's Guide - Page 58 Bridge Mode and Direct Server Return deployments do not work. Refer to the Microsoft TechNet online library for more information on the following topics: Load Balancing Requirements for Office Communications Server 2007 Enterprise Pools: Load Balancers for Office Communications Server 2007 R2: Load Balancer Requirements for Edge Servers: Using a Load Balancer to Increase Capacity and Availability: Next Step Proceed to How to Deploy with Microsoft Office Communications Server.

59 Barracuda Load Balancer Administrator's Guide - Page 59 Microsoft Office Communications Server Deployment Example This article applies to: Barracuda Load Balancer running firmware version or higher Barracuda Load Balancer 340 or above Microsoft Office Communications Server 2007 R2 Enterprise Edition This article assumes you are connected to the Barracuda Load Balancer web interface and have an activated subscription. Figure 1 illustrates a complete Office Communications Server deployment with Barracuda Load Balancers. This example is used in the deployment tasks in the article How to Deploy with Microsoft Office Communications Server. In this example, the Edge deployment uses a Route-Path topology while the Front-End deployment uses a one-armed topology. Figure Office Communications Server Deployment Example. As shown in Figure 1, the firewall should not NAT inbound traffic addressed to the Edge deployment. Refer to the Microsoft TechNet online library for more information on the following topics: Load Balancing Requirements for Office Communications Server 2007 Enterprise Pools Load Balancers for Office Communications Server 2007 R2 Load Balancer Requirements for Edge Servers Using a Load Balancer to Increase Capacity and Availability Next Step Proceed to How to Deploy with Microsoft Office Communications Server.

60 Barracuda Load Balancer Administrator's Guide - Page 60 How to Deploy with Microsoft Office Communications Server This article refers to firmware 3.1 and higher, running on model 340 or higher, and Microsoft Office Communications Server 2007 R2 Enterprise Edition. In this article: This article assumes you are connected to the Barracuda Load Balancer web interface and have an activated subscription. The deployment tasks in this article are based on the example described in the article Microsoft Office Communications Server Deployment Example. For a description of supported deployment options, refer to Understanding Microsoft Office Communications Server Deployment. Task Modify the TCP and UDP Connections Settings Task Configure Enterprise Pool Services Task 3. Configure Internal Edge Services Task 4. Configure External Edge Services Task 5. Confirm the Configure Edge Server Wizard Setting Task 6. Configure Director Services Task 7. Configure Communicator Web Access Services If your Barracuda Load Balancers are clustered, the configuration between the active and passive systems is synchronized; there is no need to modify any passive Barracuda Load Balancers. To deploy the Barracuda Load Balancer in an Office Communications Server environment, complete the following tasks: Deployment Task Task Modify TCP and UDP Connections Settings. Task Configure Enterprise Pool Services. Where Do this on all active Barracuda Load Balancers, both internal and external. If your systems are clustered, the passive systems do not need to be configured separately. Do this on the internal-facing Barracuda Load Balancers. If you have an edge deployment, you must also complete the following tasks: Task 3. Configure Internal Edge Services. Task 4. Configure External Edge Services. Task 5. Confirm the Configure Edge Server Wizard Setting. Do this on the internal-facing Barracuda Load Balancers. Do this on the external-facing Barracuda Load Balancers. Check this on all Edge Servers. If you have deployed Director Servers, you must also do the following task: Task 6. Configure Director Services. Do this on the Director Barracuda Load Balancers. If you have deployed Communicator Web Access, you must also complete the following task: Task 7. Configure Communicator Web Access Services. Do this on the CWA Barracuda Load Balancers. Task Modify the TCP and UDP Connections Settings The Barracuda Load Balancer comes configured with default settings that work with most applications. Office Communications Server requires changes to the default advanced IP settings on the Barracuda Load Balancer to ensure it complies with Microsoft s specifications. To modify the TCP and UDP Connections settings on the System Settings page: 3. Go to the ADVANCED > System Settings tab in the web interface. In the TCP Connections Timeout box, enter 1800 (30 minutes). In the UDP Connections Timeout box, enter 1800 (30 minutes). Task Configure Enterprise Pool Services To configure all Services needed for an internal OCS deployment: Go to the BASIC > Services page in the web interface.

61 Barracuda Load Balancer Administrator's Guide - Page 61 Add each Service listed in the table using the steps that follow; all of these Services are required : Service Name Virtual IP Address Protocol Port Real Servers MTLS Front DCOM WMI Front Internal Conf Front HTTPS Front IP for FQDN of Internal enterprise OCS Pool e.g., /24 for frontpool.domai n.local IP for FQDN of Internal Enterprise OCS Pool IP for FQDN of Internal Enterprise OCS Pool IP for FQDN of Internal Enterprise OCS Pool TCP 5061 IP addresses of your Front-End Servers (K and L from the example) TCP 135 IP addresses of your Front-End Servers (K and L from the example) TCP 444 IP addresses of your Front-End Servers (K and L from the example) TCP 443 IP addresses of your Front-End Servers (K and L from the example) For the DCOM WMI Front Service only, edit each Real Server associated with the Service by clicking the Edit icon next to each Real Server entry in the table. On the Real Server Detail page that appears: a. b. To add a Service: In the Server Monitor section, set the Testing Method to TCP Port Check. In the Port field, enter the value 506 It is better to test port 5061 for this Service because port 135 always passes the TCP port check even if OCS Services are not responding. In the Service Name box, enter the name for the Service. In the Virtual IP Address box, enter the IP address for the FQDN of your Internal OCS Pool. Select the protocol and in the Port box, enter the port for the Service in the table. In the Real Servers box, enter the IP address for every Front-End server in your OCS Pool. The following Services are optional ; add each Service only if you have deployed that feature. Service Name Virtual IP Address Protocol Port Real Servers Application Sharing (optional) QoE Agent (optional) Response Group Service (optional) Conferencing Attendant (optional) Conferencing Announcement (optional) IP for FQDN of Internal enterprise OCS Pool IP for FQDN of Internal Enterprise OCS Pool IP for FQDN of Internal Enterprise OCS Pool IP for FQDN of Internal Enterprise OCS Pool IP for FQDN of Internal Enterprise OCS Pool TCP 5065 IP addresses of your Front-End Servers (K and L from the example) TCP 5069 IP addresses of your Front-End Servers (K and L from the example) TCP 5071 IP addresses of your Front-End Servers (K and L from the example) TCP 5072 IP addresses of your Front-End Servers (K and L from the example) TCP 5073 IP addresses of your Front-End Servers (K and L from the example)

62 Barracuda Load Balancer Administrator's Guide - Page 62 Outside Voice Control (optional) IP for FQDN of Internal Enterprise OCS Pool TCP 5074 IP addresses of your Front-End Servers (K and L from the example) For each Service created, edit the Service by clicking the Edit icon next to the Service entry in the table. On the Service Detail page that appears: In the General section, set Service Type to TCP Proxy. In the Advanced Options section, set Session Timeout to 0 (session never times out). Task 3. Configure Internal Edge Services Complete this task if you have an edge deployment. To configure all the Services needed for a load balanced OCS Edge deployment, perform the following steps on the internal-facing Barracuda Load Balancer: Go to the BASIC > Services page in the web Interface. Add each Service listed in the table using the steps that follow; all Services are required : Service Name Virtual IP Address Protocol Port Real Servers MTLS Edge AV Auth Edge RTP HTTP Edge WebConf Edge RDP Media Edge IP for FQDN of Internal Enterprise OCS Pool e.g., /24 for frontpool.domai n.local IP for FQDN of Internal Edge Enterprise OCS Pool IP for FQDN of Internal Edge Enterprise OCS Pool IP for FQDN of Internal Edge Enterprise OCS Pool IP for FQDN of Internal Edge Enterprise OCS Pool TCP 5061 Internal IP addresses of your Edge Servers (I and J from the example) TCP 5062 Internal IP addresses of your Edge Servers (I and J from the example) TCP 443 Internal IP Addresses of your Edge Servers (I and J from the example) TCP 8057 Internal IP addresses of your Edge Servers (I and J from the example) UDP 3478 Internal IP addresses of your Edge Servers (I and J from the example) To add a Service: In the Service Name box, enter the name for the Service. In the Virtual IP Address box, enter the IP address for the FQDN of your Internal Edge OCS Pool. Select the protocol and in the Port box, enter the port for the Service in the table. In the Real Servers box, enter the internal IP address for every Edge server. For each TCP Service created, edit the Service by clicking the Edit icon next to the Service entry in the table. In the General section, set the Service Type to TCP Proxy. In the Advanced Options section set Session Timeout to 0 (session never times out). No change is required for RDP Media Edge, which is a UDP Service. Task 4. Configure External Edge Services Complete this task if you have an edge deployment.

63 Barracuda Load Balancer Administrator's Guide - Page 63 The Real Servers should be physically connected to a switch which is connected to the LAN port of the Barracuda Load Balancer. To configure all Services needed for a load balanced Edge Deployment of Office Communications Server, perform the following steps on the external-facing Barracuda Load Balancer: Go to the BASIC > Services page in the web Interface. Add each Service listed in the following table: Service Name Virtual IP Address Protocol Port Real Servers Access Edge WebConf Edge AV Edge AV UDP Edge IP for FQDN of Access Edge e.g. IP address for ocs.example.com IP for FQDN of WebConf Edge e.g. IP address for web conf.example.com IP for FQDN of AV Edge e.g. IP address for av. example.com IP for FQDN of AV Edge e.g. IP address for av. example.com TCP 443 IP address of Access Edge NICs on each Edge Server (C and F from the example) TCP 443 IP address of WebConf NICs on each Edge Server (D and G from the example) TCP 443 IP address of AV NICs on each Edge Server (E and H from the example) UDP 3478 IP address of AV NICs on each Edge Server (E and H from the example) To add a Service: In the Service Name box, enter the name for the Service. In the Virtual IP Address box, enter the IP address for the FQDN of your Internal Edge Lync Pool. In the Port box, enter the port for that Service in the table. In the Real Servers box, enter the internal IP address for every Edge Server. No modifications need to be made to the default settings for these Services. Task 5. Confirm the Configure Edge Server Wizard Setting Complete this task if you have an edge deployment. Verify the following on the Edge Servers: When completing the Configure Edge Server Wizard, the Internal Interface dialog displays the following message: If you are using a load balancer, specify the IP address of the local server and the FQDN of the load balancer s VIP." In the FQDN for the internal interface field, enter the FQDN for the Access Edge DNS entry that external users are to use. When correctly set, when the Edge Servers are queried for their host name strings, they return the FQDN of the VIP address for the external Access Edge instead of the FQDN of the internal interface. This ensures that the Subject Alternative Name (SAN) on the certificate assigned to this internal interface for the Access Edge matches the host string of the Edge server. Task 6. Configure Director Services Complete this task if you have deployed Director Servers. To configure all the Services needed for Director Services, perform the following steps on the Director Barracuda Load Balancer: Go to the BASIC > Services page in the web interface. Add each Service listed in the following table: Service Name Virtual IP Address Protocol Port Real Servers

64 Barracuda Load Balancer Administrator's Guide - Page 64 Directory MTLS Directory MTLS Legacy IP for FQDN of the Director Service IP for FQDN of the Director Service TCP 5061 IP address of your Director Servers TCP 5060 IP address of your Director Servers To add a Service: In the Service Name box, enter the name for the Service. In the Virtual IP Address box, enter the IP address for the FQDN of your Director Service. In the Port box, enter the port for that Service in the table. In the Real Servers box, enter the internal IP address for every Director Server. For each Service created, edit the Service by clicking the Edit icon next to the Service entry in the table. On the Service Detail page that appears, complete the following: In the General section, set Service Type to TCP Proxy. In the Advanced Options section, set Session Timeout to 0 (session never times out). Task 7. Configure Communicator Web Access Services Complete this task if you have deployed Communicator Web Access. Communicator Web Access (CWA) is an optional feature of Office Communication Server that allows users who do not have access to the Office Communicator Client to access many of the features of Office Communications Server from a browser. Installations of CWA that have greater than 5000 users should deploy a load balancer for this feature. Microsoft recommends that you dedicate one or more load balancers that are used only for CWA for acceptable performance. Configure the CWA servers to use HTTP rather than HTTPS. This allows the Barracuda Load Balancer to do SSL offloading, which improves the performance of the CWA Service. Also, this allows end user connections to be maintained using cookies, as recommended by Microsoft. To configure the Services needed for a load balanced Communicator Web Access Server, perform the following steps on the Communicator Web Access Barracuda Load Balancer: 3. Go to the BASIC > Certificates page in the web interface, and upload the CWA certificate to the Barracuda Load Balancer. Go to the BASIC > Services page in the web interface. Add the Service listed in the following table: Service Name Virtual IP Address Protocol Port Real Servers CWA IP for FQDN of CWA e.g. IP address for cwa.domain.local TCP 443 IP address of CWA Servers To add a Service: In the Service Name box, enter the name for the Service. In the Virtual IP Address box, enter the IP address for the FQDN of your CWA Service. In the Port box, enter the port for that Service in the table. In thereal Servers box, enter the internal IP address for every CWA Server. Edit the Service by clicking the Edit icon next to the Service entry in the table. On the Service Detail page that appears, complete the following: In the General section, set Service Type to Layer 7 - HTTP. In the Service Monitor section, in the Testing Method list, click HTTP. In the Test Target box, enter <fqdn of your CWA website> / 3. For example, In the Test Match box, enter Microsoft Corporation. In the Persistence section, change the Persistence Type to HTTP Cookie. In the SSL Offloading section, set Enable HTTPS/SSL to Yes. In the SSL Certificate list, select the name of the certificate you uploaded for CWA. In the Advanced Options section, set Session Timeout to 0 (session never times out). For each Real Server added, edit the Real Server by clicking the Edit icon next to each Real Server entry in the table. In the Real Server Detail section, change the value for Port to 80.

65 Barracuda Load Balancer Administrator's Guide - Page 65 To create a rewrite rule, go to the Advanced > URL Rewrites page in the web interface and create a rule to replace outgoing <fqdn of your CWA Web site> with <fqdn of your CWA Web site>. This rewrites absolute paths written by CWA so that they all appear as encrypted links; this rule prevents unsecure content errors in the browser: In the Layer 7 - HTTP Services section, select the CWA Service from the list. In the Response Body Rewrite section, create a new rule with the following options: Rule Name: cwa Rule Order: 1 Host Match: <fqdn of your CWA Web site>, e.g. cwa.domain.local URL Match: /cwa/client/* Search String: <fqdn of your CWA Web site>, e.g. Replace String: <fqdn of your CWA Web site>, e.g. Create the CWA Redirect Service; this Service ensures that end users are redirected from HTTP to the HTTPS Service: Go to the BASIC > Services page in the web interface. In the Service Name field, enter the CWA Redirect Service name. In the Virtual IP Address field, enter the IP address for the FQDN for your CWA Service. Select the protocol TCP, and in the Port field enter 80. Edit the CWA Redirect Service by clicking the Edit icon next to the Service entry in the table: In the General section, set the Service Type to Layer 7 - HTTP. Set Enable HTTP Redirect to Yes. Test the CWA installation: Open a browser and enter: <fqdn of your CWA Web site>, e.g. Ensure that all images load and that you are able to log into the CWA application without errors. Your installation is now complete. Refer to the Microsoft TechNet online library for more information on the following topics: Load Balancing Requirements for Office Communications Server 2007 Enterprise Pools Load Balancers for Office Communications Server 2007 R2 Load Balancer Requirements for Edge Servers Using a Load Balancer to Increase Capacity and Availability

66 Barracuda Load Balancer Administrator's Guide - Page 66 Microsoft Lync Server 2010 Deployment Organizations can use the Barracuda Load Balancer to enhance the scalability and availability of their Microsoft Lync Server 2010 deployments (formerly known as Microsoft Office Communications Server). Barracuda Networks has conducted interoperability tests between the Barracuda Load Balancer and Microsoft Lync Server This guide describes how to deploy the Barracuda Load Balancer to provide scaling in a Lync environment. Microsoft Lync Server Overview Organizations use solutions like Microsoft Lync to allow them to effectively disseminate information and enhance collaborative efforts among their employees. Microsoft Lync Server 2010 offers functionality such as VoIP, instant messaging and web collaboration. All these services may be accessed by clients from either the internal office network or from the Internet. For companies that want a scalable solution, Microsoft recommends using a hardware load balancer to distribute the traffic among multiple Lync Servers. Requirements Microsoft Lync Server 2010 Enterprise Edition Barracuda Load Balancer running firmware version or higher Barracuda Load Balancer 340 or above For Internal Lync Server Deployment: Minimum one Barracuda Load Balancer, two recommended for high availability For both Internal Lync Server Deployment and Edge Deployment: Minimum two Barracuda Load Balancers, four recommended for high availability. In order to maintain the integrity of the edge security model, separate load balancers are required for the internal traffic and the edge traffic. For Internal Lync Server Deployment, Edge Deployment, and non-collocated A/V Services: Minimum three Barracuda Load Balancers, six recommended for high availability. In order to maintain the integrity of the edge security model, separate load balancers are required for the internal traffic, the edge traffic and the non-collocated A/V Services. This document assumes that you have installed your Barracuda Load Balancer(s), have connected to the web interface, and activated your subscription(s). If you are planning to deploy Lync Server 2010 with high availability, you must first cluster your Barracuda Load Balancers. Do not run the Lync Topology Builder until instructed to in this deployment guide. All of the Services on the Barracuda Load Balancer must be configured before running the Topology Builder. Additional References Refer to the Microsoft TechNet library for the following: A description of ports and protocols used by the servers, load balancers, and clients in a Microsoft Lync deployment environment Microsoft Lync Server 2010 Documentation Terminology Term Front-End Server Edge Server Fully Qualified Domain Name (FQDN) Service Description A Lync Server in the internal network running the Front End Lync Services. A Lync Server deployed in the perimeter network running the Edge Lync Services. The unique name for a specific computer or host that can resolve to an IP address, e.g., A combination of a virtual IP (VIP) address and one or more TCP/UDP ports on which the Barracuda Load Balancer listens. Traffic arriving over the specified port(s) to a Service is directed to one of the Real Servers associated with a particular Service. Next Article

67 Barracuda Load Balancer Administrator's Guide - Page 67 Understanding Microsoft Lync Server 2010 Deployment Options

68 Barracuda Load Balancer Administrator's Guide - Page 68 Understanding Microsoft Lync Server 2010 Deployment Options This article refers to firmware version and higher running on a configured Barracuda Load Balancer 340 or higher. For a list of requirements, refer to Microsoft Lync Server 2010 Deployment. In this article: Lync Server Front-End Server Deployment Options Lync Edge Server Deployment Options Deployment Options Lync Server Front-End Server Deployment Options As the servers in a Lync Server enterprise pool communicate with each other using the VIP address of the pool, create a TCP Proxy Service and associate the servers with it to facilitate this communication. The servers and the Barracuda Load Balancer must be deployed using a one-armed topology in either a single or multiple subnet configuration. Deploying internal Lync pools using a two-armed Route-Path topology, Direct Server Return (DSR) or Bridge Mode does not work and is not supported. Lync Edge Server Deployment Options Load balanced Edge deployments are supported using either a one-armed Route-Path topology using a TCP Proxy Service or a two-armed Rou te-path topology using a Layer 4 Service. For maximum performance, a two-armed Route-Path topology is recommended. Bridge Mode and Direct Server Return deployments do not work and are not supported. Deployment Options Figure 1 shows an example of a complete Lync deployment with Barracuda Load Balancers. This example is referenced in the deployment tasks detailed in the sections that follow. Note that in this example, the Edge deployment uses a two-armed topology while the Front-End deployment uses a one-armed configuration. Figure Lync Deployment Example.

69 Barracuda Load Balancer Administrator's Guide - Page 69 The inbound firewall should not NAT inbound traffic addressed to the Edge deployment. Figure 2 shows an example of a one-armed edge. This deployment example is very similar to the deployment shown in Figure 1, with the difference being that the Edge deployment uses a one-armed topology. Use the references in the deployment tasks in the following sections for both deployment examples. Figure Lync Deployment Example Using a One-Armed Topology.

70 Barracuda Load Balancer Administrator's Guide - Page 70 Proceed to How to Deploy with Microsoft Lync Server 2010 or deployment tasks required to deploy the Barracuda Load Balancer in a Lync Server 2010 environment. Next Article How to Deploy with Microsoft Lync Server 2010

71 Barracuda Load Balancer Administrator's Guide - Page 71 How to Deploy with Microsoft Lync Server 2010 This article refers to firmware version and higher running on a configured Barracuda Load Balancer 340 or higher. This article applies to: Microsoft Lync Server 2010 For Lync Mobility, Apple iphone and ipad; Android phone; Windows Phone 7; and Nokia mobile devices Microsoft Lync References: In this article: For a list of requirements, refer to Microsoft Lync Server 2010 Deployment For deployment options, refer to Understanding Microsoft Lync Server 2010 Deployment Options For mobility deployment details, refer to the Microsoft TechNet article Deploying Mobility Task Modify TCP and UDP Connections Settings Task Configure Enterprise Pool Services Task 3. Configure Internal A/V Services (if applicable) Task 4. Configure Internal Edge Services Task 5. Configure External Edge Services Task 6. Configure Director Services Task 7. Run Topology Builder Task 8. Enable Cookie Persistence Task 9. Configure Lync Mobility Services Task 10. Configure the Barracuda Load Balancer as a Reverse Proxy for Lync Mobility Services Appendix A. Certificate for Lync Mobility Service Related Articles Microsoft Lync Server 2010 Deployment Understanding Microsoft Lync Server 2010 Deployment Options IP Worksheet Use the IP Worksheet to record your configuration. Barracuda Networks recommends completing this worksheet as you perform these tasks to assist you when running the Topology Builder in Task 7. To deploy the Barracuda Load Balancer in a Lync 2010 environment, complete the following tasks: Deployment Task Task Modify TCP and UDP Connections Settings. Task Configure Enterprise Pool Services. Where Do this on all active Barracuda Load Balancers, both internal and external. Do this on the internal-facing Barracuda Load Balancer. If you did not collocate A/V Services on your Front End Servers, you must also complete step 3: Task 3. Configure Internal A/V Services (if applicable). Do this on the A/V Pool Barracuda Load Balancer. If you have an edge deployment, you must also complete the following tasks: Task 4. Configure Internal Edge Services. Task 5. Configure External Edge Services. Do this on the internal-facing Barracuda Load Balancer. Do this on the external-facing Barracuda Load Balancer. If you have deployed Director servers, you must also complete the following task: Task 6. Configure Director Services. Do this on the Director Barracuda Load Balancer. Complete the following tasks after all Services are configured on the Barracuda Load Balancer: Task 7. Run Topology Builder. Task 8. Enable Cookie Persistence. Do this on the server where Topology Builder is installed. Do this on the internal-facing Barracuda Load Balancer. Configure Mobility Services and configure the Barracuda Load Balancer as a reverse proxy:

72 Barracuda Load Balancer Administrator's Guide - Page 72 Task 9. Configure Lync Mobility Services. Task 10. Configure the Barracuda Load Balancer as a Reverse Proxy for Lync Mobility Services. Do this on the internal-facing Barracuda Load Balancer. Do this on the external-facing Barracuda Load Balancer. If your Barracuda Load Balancers are clustered, the configuration between the active and passive systems is synchronized; there is no need to modify any passive Barracuda Load Balancers. Task Modify TCP and UDP Connections Settings Do the following on all active Barracuda Load Balancers, both internal (the Barracuda Load Balancer configured with the front-end servers) and external (if there is a Barracuda Load Balancer deployed with Edge servers). The Barracuda Load Balancer comes configured with default settings that work with most applications. Lync 2010 requires changes to the default TCP and UDP connection settings on the Barracuda Load Balancer to ensure compliance with Microsoft specifications. To modify the TCP and UDP Connections settings on the System Settings page: 3. Go to the ADVANCED > System Settings tab in the web interface. In the TCP Connections Timeout box, enter 1800 (30 minutes). In the UDP Connections Timeout box, enter 1800 (30 minutes). Task Configure Enterprise Pool Services To configure all Services needed for an internal Lync deployment, perform the following steps on the internal-facing Barracuda Load Balancer: Go to the BASIC > Services page. Make sure the Add New Service section is in the advanced view. Add each Service listed in the table using the steps that follow; all Services are required: Service Name Service Type Virtual IP Address Real Servers MTLS Front TCP Proxy IP for FQDN of Internal Enterprise Lync Pool e.g., /24 for fron tpool.domain.local Port is 5061 DCOM WMI Front TCP Proxy IP for FQDN of Internal Enterprise Lync Pool; Port is 135 Internal Conf Front TCP Proxy IP for FQDN of Internal Enterprise Lync Pool; Port is 444 HTTPS Front Layer 7 - HTTPS IP for FQDN of Internal Enterprise Lync Pool; Port is 443 IP address of every front-end Server in your Lync Pool (K and L from the example (1) ) IP address of every front-end Server in your Lync Pool (K and L from the example (1) ) IP address of every front-end Server in your Lync Pool (K and L from the example (1) ) IP address of every front-end Server in your Lync Pool (K and L from the example (1) ) Note: (1) See Understanding Microsoft Lync Server 2010 Deployment Options for deployment examples. 3. For the HTTPS Front Service only: In the Persistence section, set Persistence Type to HTTP Cookie and Persistence Time to Leave Cookie Name blank. In the Advanced Options section, set Session Timeout to 0 (session never times out). 4. For the DCOM WMI Front Service only, edit each Real Server associated with the Service by clicking the Edit icon next to each Real Server entry in the table. On the Real Server Detail page that appears: In the Server Monitor section, set the Testing Method to TCP Port Check. In the Port field, enter the value 506 It is better to test port 5061 for this Service because port 135 always passes the TCP port check even if Lync Services are not responding. The following Services are optional; add each Service only if you have deployed that feature:

73 Barracuda Load Balancer Administrator's Guide - Page 73 Service Name Service Type Virtual IP Address Real Servers Application Sharing (optional) TCP Proxy IP for FQDN of Internal enterprise Lync Pool; Port is 5065 QoE Agent (optional) TCP Proxy IP for FQDN of Internal Enterprise Lync Pool; Port is 5069 IP address of every Front-End Server in your Lync Pool (K and L from the example (1) ) IP address of every Front-End Server in your Lync Pool (K and L from the example (1) ) Response Group Service (optional) TCP Proxy IP for FQDN of Internal Enterprise Lync Pool; Port is 5071 IP address of every Front-End Server in your Lync Pool (K and L from the example (1) ) Conferencing Attendant (optional) TCP Proxy IP for FQDN of Internal Enterprise Lync Pool; Port is 5072 IP address of every Front-End Server in your Lync Pool (K and L from the example (1) ) Conferencing Announcement TCP Proxy IP for FQDN of Internal Enterprise Lync Pool; Port is 5073 Outside Voice Control (optional) TCP Proxy IP for FQDN of Internal Enterprise Lync Pool; Port is 5074 IP address of every Front-End Server in your Lync Pool (K and L from the example (1) ) IP address of every Front-End Server in your Lync Pool (K and L from the example (1) ) Note: (1) See Understanding Microsoft Lync Server 2010 Deployment Options for deployment examples. For each Service created, edit the Service by clicking the Edit icon next to the Service entry in the table. On the Service Detail page that appears, for any optional service created: In the Persistence section, set Persistence Type to Client IP and Persistence Time to In the Advanced Options section, set Session Timeout to 0 (session never times out). Task 3. Configure Internal A/V Services (if applicable) Complete this step if you did not collocate A/V Services on your Front End Servers. If you have more than 10,000 users in this pool, it is recommended that you separate the A/V Services of your Internal Lync Pool and do not collocate the A/V services on the Front End Pool. If you choose to collocate A/V Services on your Front End Pool, no further changes to the configuration are required. Separating out the A/V Services into its own pool requires two more Barracuda Load Balancers operating as a High Availability pair. Contact Barracuda Technical Support if your deployment has more than 10,000 A/V users for assistance. Task 4. Configure Internal Edge Services To configure all Services needed for a load-balanced Lync Edge deployment, perform the following steps on the internal-facing Barracuda Load Balancer. Go to the BASIC > Services page. Make sure the Add New Service section is in the advanced view. Add each Service listed in the following table: Service Name Service Type Virtual IP Address Real Servers MTLS Edge TCP Proxy IP for FQDN of Internal Edge Enterprise Lync Pool e.g., /24 for edge pool.domain.local Port is 5061 Internal IP addresses of your Edge Servers (I and J from the example)

74 Barracuda Load Balancer Administrator's Guide - Page 74 AV Auth Edge TCP Proxy IP for FQDN of Internal Edge Enterprise Lync Pool; Port is 5062 RTP HTTPS Edge Layer 7 - HTTPS IP for FQDN of Internal Edge Enterprise Lync Pool; Port is 443 HTTPS Layer 7 - HTTPS IP for FQDN of Internal Edge Enterprise Lync Pool; Port is 4443 Web Conferencing Edge TCP Proxy IP for FQDN of Internal Edge Enterprise Lync Pool; Port is 8057 RDP Media Edge Layer 4 - UDP IP for FQDN of Internal Edge Enterprise Lync Pool; Port is 3478 Internal IP addresses of your Edge Servers (I and J from the example) Internal IP addresses of your Edge Servers (I and J from the example) Internal IP addresses of your Edge Servers (I and J from the example) Internal IP addresses of your Edge Servers (I and J from the example) Internal IP addresses of your Edge Servers (I and J from the example) Note: (1) See Understanding Microsoft Lync Server 2010 Deployment Options for deployment examples. 3. For each TCP Proxy Service created, edit the Service by clicking the Edit icon next to the Service entry in the table. On the Service Detail page that appears: 4. In the Persistence section, set Persistence Type to Client IP and Persistence Time to In the Advanced Options section, set Session Timeout to 0 (session never times out). For the HTTPS and RTP HTTPS Edge Services only, edit the Service by clicking the Edit icon next to the Service entry in the table: 5. In the Persistence section, set Persistence Type to HTTP Cookie and Persistence Time to Leave Cookie Name blank. In the Advanced Options section, set Session Timeout to 0 (session never times out). No change is required for RDP Media Edge which is a Layer 4 - UDP Service. Task 5. Configure External Edge Services The Real Servers should be physically connected to a switch which is connected to the LAN port (for two-armed deployment) or the WAN port (one-armed deployment) of the Barracuda Load Balancer. To configure all Services needed for a load balanced Edge Deployment of Lync Server, perform the following steps on the external-facing (Internet-facing) Barracuda Load Balancer: Go to the BASIC > Services page. Make sure the Add New Service section is in the advanced view. Add each Service listed in the following table: Service Name (1) Service Type Virtual IP Address Real Servers Access Edge One-armed deployment: TCP Proxy Two-armed deployment: Layer 4 - TCP IP for FQDN of Access Edge e.g., IP address for lync.exa mple.com; Port is 443 IP address of Access Edge NICs on each Edge Server (C and F from the example (2) ) Access Edge (3) One-armed deployment: TCP Proxy Two-armed deployment: Layer 4 - TCP IP for FQDN of Access Edge e.g., IP address for lync.exa mple.com; Port is 5061 IP address of Access Edge NICs on each Edge Server (C and F from the example (2) ) Web Conferencing Edge One-armed deployment: TCP Proxy Two-armed deployment: Layer 4 - TCP IP for FQDN of WebConf Edge e.g., IP address for webconf. example.com; Port is 443 IP address of WebConf NICs on each Edge Server (D and G from the example (2) ) A/V Edge One-armed deployment: TCP Proxy Two-armed deployment: Layer 4 - TCP IP for FQDN of AV Edge e.g., IP address for av.examp le.com; Port is 443 IP address of AV NICs on each Edge Server (E and H from the example (2) )

75 Barracuda Load Balancer Administrator's Guide - Page 75 A/V UDP Layer 4 - UDP IP for FQDN of AV Edge e.g., IP address for av.examp le.com; Port is 3478 IP address of AV NICs on each Edge Server (E and H from the example (2) ) Notes: (1) Each Service must have its own VIP Address. (2) See Understanding Microsoft Lync Server 2010 Deployment Options for deployment examples. (3) This Service is required if you have enabled federation on your Enterprise Edge Pool For each TCP Service created, edit the Service by clicking the Edit icon next to the Service entry in the table. On the Service Detail pag e that appears: For a two-armed deployment: - In the Persistence section, set Persistence Type to Client IP and Persistence Time to 1200 For a one-armed deployment: - In the Persistence section, set Persistence Type to Client IP and Persistence Time to In the Advanced Options section, set Session Timeout to 0 (session never times out). No further modifications are necessary to the default settings for the UDP Service Task 6. Configure Director Services Complete the following steps on the Director Barracuda Load Balancer. To configure all the Services needed for a load balanced Edge Deployment of Lync Server, perform the following steps on the external-facing Barracuda Load Balancer: Go to the BASIC > Services page in the web interface. Make sure the Add New Service section is in the advanced view. Add each Service listed in the following table: Service Name Service Type Virtual IP Address Real Servers Directory MTLS TCP Proxy IP for FQDN of the Directory Service; Port is 5061 Directory MTLS Legacy (1) TCP Proxy IP for FQDN of the Directory Service; Port is 5060 Internal IP address of your Directory Servers Internal IP address of your Directory Servers 3. Note: (1) Add this Service if you need to support Office Communications Server prior to version 2007 R If you only have versions of Office Communications Server that are 2007 R2 or later (including Lync), do not add this Service. For each Service created, edit the Service by clicking the Edit icon next to the Service entry in the table. On the Service Detail page that appears: In the Persistence section, set Persistence Type to Client IP and Persistence Time to In the Advanced Options section, set Session Timeout to 0 (session never times out). Task 7. Run Topology Builder Once all of the Services are configured on the Barracuda Load Balancer, run Lync Topology Builder; use the configuration information recorded in the IP Worksheet to complete the required fields. Task 8. Enable Cookie Persistence In this step you install an SSL certificate on the internal-facing Barracuda Load Balancer to enable cookie persistence for the Layer 7 - HTTPS Services that were partially configured previously. Additionally, you configure backend SSL on the Real Servers. The Barracuda Load Balancer uses the certificate that you install to decrypt the SSL traffic directed to Layer 7 - HTTPS Services. It checks for a persistence cookie and then re-encrypts the traffic before sending it to a server in the pool. Each of the front-end Lync servers should have the pool name in its certificate. Export a certificate, making sure it has the pool name, from one of the front-end servers. Using the Certificate Manager in the Microsoft Management Console (MMC), export a certificate along with its private key. To enable cookie persistence, perform the following steps on the internal-facing Barracuda Load Balancer Import the certificate using the BASIC > Certificates page. Go to the BASIC > Services page and edit the HTTPS Front Service. On the Service Detail page, in the SSL Offloading section, select the SSL certificate from the SSL Certificate list. 3. Go the BASIC > Services page and edit each Real Server that is associated with the HTTPS Front Service. On the Real Server Detail page, set Enable HTTPS/SSL to Yes so that the Barracuda Load Balancer re-encrypts the traffic sent to the Real Server.

76 Barracuda Load Balancer Administrator's Guide - Page 76 If you deployed edge services on the internal-facing Barracuda Load Balancer, identify the certificate for the HTTPS and RTP HTTPS Edge Services: Go to the BASIC > Services page and edit the HTTPS and RTP HTTPS Edge Services. On the Service Detail, in the SSL Offloading s ection, select the SSL certificate from the SSL Certificate list. Go to the BASIC > Services page and edit each Real Server that is associated with each of these Services. On the Real Server Detail page, set Enable HTTPS/SSL to Yes so that the Barracuda Load Balancer re-encrypts the traffic sent to the Real Server. Your installation of the Barracuda Load Balancer and Microsoft Lync Server is now complete. Continue to configure the Barracuda Load Balancer for Lync Mobility. Task 9. Configure Lync Mobility Services To configure the Services needed for a Lync Mobility deployment, perform the following steps on the internal-facing Barracuda Load Balancer: Go to the BASIC > Services page. Make sure the Add New Service section is in the advanced view. Add each Service listed in the following table: Service Name Service Type Virtual IP Address Real Servers Lync Mobility HTTPS Layer 7 - HTTPS IP address for FQDN of Internal Enterprise Lync pool; Port is 4443 Internal IP addresses of front-end Servers; Port is 4443 Lync Mobility HTTP (1) (optiona l) Layer 4 - TCP IP address for FQDN of Internal Enterprise Lync pool; Port is 8080 Internal IP addresses of front-end Servers; Port is 8080 Note: (1) The optional Lync Mobility HTTP service is required only if you enabled Lync Mobility connections over HTTP. 3. For the Lync Mobility HTTPS Service only, edit the Service by clicking the Edit icon in the Actions column. On the Service Detail page that appears: In the Persistence section, set Persistence Type to HTTP Cookie, and the Persistence Time to 1200 ; leave the Cookie Name box blank. In the SSL Offloading section, in the Certificate list, select the certificate assigned to the Lync front-end Server for external web services; see Appendix A. Certificate for Lync Mobility Service for additional information. In the Advanced Options section, set Session Timeout to 0 (session never times out). Task 10. Configure the Barracuda Load Balancer as a Reverse Proxy for Lync Mobility Services A reverse proxy is required to support Lync Mobility Services, as it allows remote users to access the functionality provided by Lync Web Services. To configure the Services needed to deploy the Barracuda Load Balancer as a reverse proxy, perform the following steps on the external-facing Barracuda Load Balancer: Go to the BASIC > Services page. Make sure the Add New Service section is in the advanced view. Add each Service listed in the following table: Service Name Service Type Virtual IP Address Real Server Lync RP HTTPS Secure TCP Proxy IP address of the FQDN of External Web Services; Port is 443 Lync RP HTTP (1) (Optional) Layer 4 - TCP IP address of the FQDN of External Web Services; Port is 80 VIP address of the Lync Mobility HTTPS Service; Port is 4443 VIP address of the Lync Mobility HTTP Service; Port is 8080 Note: (1) The optional Lync RP HTTP service should be added only if you enabled Lync Mobility connections over HTTP. 3. For the Lync RP HTTPS Service only, edit the Service by clicking the Edit icon in the Actions column. On the Service Detail page that appears : In the Persistence section, set Persistence Type to HTTP Cookie, and the Persistence Time to Enter MS-WSMAN in the Cookie Name box. In the SSL Offloading section, in the Certificate list, select the certificate assigned to the Lync front-end Server for external web services; see Appendix A. Certificate for Lync Mobility Service for additional information. In the Advanced Options section, set Session Timeout to 0 (session never times out).

77 Barracuda Load Balancer Administrator's Guide - Page 77 Appendix A. Certificate for Lync Mobility Service You can create the certificate to be assigned to the Lync Mobility Service and to the Reverse Proxy (RP) Service using the Lync Certificate Wizard. The certificate's SAN must contain the autodiscover URL and your external web services URL. The Lync RP HTTPS Service and the Lync Mobility HTTPS Service that you create on the Barracuda Load Balancer can be assigned the same certificate For more information regarding certificate requirements, refer to the Microsoft TechNet article called Certificate Summary - Reverse Proxy: /technet.microsoft.com/en-us/library/jj20538aspx When you use the Lync Certificate Wizard to request the certificate, select the Web services external option check box, and assign the resulting certificate to the Barracuda Load Balancer:

78 Barracuda Load Balancer Administrator's Guide - Page 78 IP Worksheet As you perform the deployment tasks, record your IP Addresses on this worksheet. It will assist you when you run the Topology Builder. Configured Barracuda Load Balancer Internal-facing Barracuda Load Balancer FQDN IP Address Associated Topology Builder Step(s) Front End Pool wizard Notes Pool FQDN Internal-facing Barracuda Load Balancer (1) Front End Pool wizard External Base URL A/V Barracuda Load Balancer (if configured) Internal-facing Barracuda Load Balancer External-facing Barracuda Load Balancer External-facing Barracuda Load Balancer External-facing Barracuda Load Balancer Front End Pool wizard Define the new A/V Conferencing Server New Edge Pool wizard New Edge Pool External FQDNs New Edge Pool External FQDNs New Edge Pool External FQDNs A/V Conferencing Pool Edge Pool FQDN Edge SIP Access Edge Web Conferencing Edge Audio/Video Note: (1) Usually this is the same as your pool FQDN unless your organization has also implemented SIP DNS load balancing. Related Articles How to Deploy with Microsoft Lync Server 2010 Understanding Microsoft Lync Server 2010 Deployment Options

79 Barracuda Load Balancer Administrator's Guide - Page 79 Microsoft Office SharePoint Server 2007, 2010 and 2013 Deployment This article describes how to deploy your Barracuda Load Balancer with Microsoft Office SharePoint Server 2007, 2010 and 2013 to increase the scalability and reliability of your SharePoint deployment. This article applies to: Barracuda Load Balancer running firmware version or higher Barracuda Load Balancer model 340 or above Microsoft Office SharePoint Server 2007, 2010 or 2013 This article assumes you are logged into the Barracuda Load Balancer web interface and have an activated subscription. If you wish to increase the reliability of your Microsoft Office SharePoint Server deployment with High Availability, you must first have a pair of Barracuda Load Balancers joined in a cluster. If your Barracuda Load Balancers are already clustered, the configuration between the active and passive systems is synchronized automatically, so you do not need to modify any passive Barracuda Load Balancers. In this article: Example Installation Install the SharePoint Certificate on the Barracuda Load Balancer Configure Services Encrypted Traffic to Real Servers Example Installation This article is written for a SharePoint deployment where SharePoint servers support traffic over both HTTP and HTTPS. In this environment, create two Services on the Barracuda Load Balancer, one for each type of traffic. The incoming traffic will be load-balanced among the servers. The Barracuda Load Balancer will monitor the server health by periodically requesting a page from each server. Install the SharePoint Certificate on the Barracuda Load Balancer Obtain the SSL certificate for SharePoint. Install the certificates, certificate chain, and private key using the BASIC > Certificate page in the Barracuda Load Balancer web interface. Configure Services Go to the BASIC > Services page. Make sure the Add New Service section is in the advanced view, and add each Service listed in the following table: Service Name Service Type Virtual IP Address SSL Certificate Real Servers SharePoint HTTP Service Layer 7 - HTTP IP address for the fully qualified domain name (FQDN) that clients use to access SharePoint; Port 80 Internal IP addresses of your SharePoint Servers; Port 80 SharePoint HTTPS Service Layer 7 - HTTPS IP address for the fully qualified domain name (FQDN) that clients use to access SharePoint; Port 443 SharePoint SSL certificate Internal IP addresses of your SharePoint Servers; Port 443 In the Services Configuration table, click the Edit icon in the Actions column for each of the newly added Services. On the Service Detail page that appears: In the Service Monitor section, select the MS Sharepoint or MS Sharepoint Secure and complete the fields for the test. This test issues an HTTP/S request to the specified page and checks the returned page for the expected text. Authentication information for the SharePoint server is required. In the Persistence section, enter 1200 in the Persistence Time (Seconds) field, and set the Persistence Type to HTTP Cookie; additional fields display, but leave them at their default values. In the Advanced Options section, set Session Timeout to 0 (session never times out). Encrypted Traffic to Real Servers

80 Barracuda Load Balancer Administrator's Guide - Page 80 The Barracuda Load Balancer decrypts the incoming traffic in order to maintain session persistence using HTTP cookies. By default, this unencrypted traffic is passed to the Real Servers. If you want the traffic to be sent encrypted instead, then edit each Real Server from the BASIC > Services page and change the Enable HTTPS/SSL setting to Yes. As a result of deploying the Barracuda Load Balancer, the traffic sent to the Real Servers changes from encrypted to unencrypted, you may have to configure Alternate Access Mappings through SharePoint Central Administration..

81 Barracuda Load Balancer Administrator's Guide - Page 81 Direct Server Return Deployment Direct Server Return (DSR) is an option associated with a Real Server which allows for increased outbound traffic throughput when performing sustained uploads, such as streamed audio or visual media. With DSR, connection requests and incoming traffic are passed from the Barracuda Load Balancer to the Real Server, but all outgoing traffic goes directly from the Real Server to the client. Because the Barracuda Load Balancer does not process the outgoing traffic in DSR mode, Layer 7 Service types (HTTP, FTP, UDP, TCP Proxy and RDP), SSL offloading, and cookie persistence are not supported with DSR. Using DSR requires enabling a non-arping loopback adapter on each Real Server. Additionally, your applications may need to be explicitly bound to the loopback adapter. You may have DSR servers and non-dsr servers running the same Service. Real Servers that are in DSR mode must be on the same subnet as the WAN of the Barracuda Load Balancer. The following table summarizes the advantages and disadvantages of deploying your Real Servers in DSR mode: Advantages Ideal for high-bandwidth requirements such as content delivery networks. Keeps existing IP addresses of Real Servers. Disadvantages Requires flat network topology. Client IP persistence only. Only Layer-4 load balancing is supported. HTTP, TCP Proxy, UDP Proxy, FTP and RDP are not supported. SSL offloading is not supported. No actions can be performed on the response headers and data (e.g., caching compression, URL rewrites). Figure Sample DSR, one-armed architecture. As shown in the diagram, this is how DSR works: #1 - The request comes to the switch and is passed to the Virtual IP (VIP) address on Barracuda Load Balancer. #2 - A Real Server is selected, and the data frame of the packet is modified to be the MAC address of that Real Server. #3 - The packet is then placed back on the network. #4 - Because the VIP address is bound to the Real Server s loopback interface, the Real Server accepts the packet.

82 Barracuda Load Balancer Administrator's Guide - Page 82 #5 - The Real Server responds directly to the client using the VIP address as the source IP address. DSR in conjunction with Bridge-Path deployment is not supported. Network Topology DSR uses a flat network topology at the Layer 2 (Switching) and Layer 3 (IP) levels, which means that the Barracuda Load Balancer, VIP addresses, and Real Servers all must be within the same IP network and connected on the same switch. The figure above shows this topology. Each Real Server must be one hop away from the Barracuda Load Balancer and using the WAN port. The switch of the Real Servers must be directly connected into the WAN port of the Load Balancer, or connected to a series of switches that eventually reach the WAN port of the Load Balancer without going through any other networking devices. If you specify Route-Path deployment for the Barracuda Load Balancer, but only use Real Servers with DSR enabled, the physical LAN port is used for management or not at all. On the BASIC > Services page, each Real Server listed under each Service must individually be configured for DSR mode. Edit each Real Server and select Enable for the DSR option. When deploying Real Servers in DSR mode, note the following: The Barracuda Load Balancer needs to have the WAN adapter plugged into the same switch or VLAN as all of the Real Servers. The WAN IP, all VIPs, and all of the Real Servers that use DSR must be on the same IP subnet. Each Real Server needs to recognize the VIP as a local address. This requires enabling of a non-arping virtual adapter such as a loopback adapter and binding it to the VIP address of the load-balanced Service. Because this is not a true adapter, there should be no gateway defined in the TCP/IP settings for this adapter. Real Servers accepting traffic from multiple VIPs must have a loopback adapter enabled for each VIP. Additionally, the applications on each Real Server must be aware of both the Virtual IP address as well as the real IP addresses. Deployment Options Deployment in a Microsoft Windows Server 2003, 2008, and 2012 Environment Deployment of DSR in a Linux Environment Deployment of DSR in Windows XP Environment Multiple Network Adapters on Real Servers

83 Barracuda Load Balancer Administrator's Guide - Page 83 Deployment in a Microsoft Windows Server 2003, 2008, and 2012 Environment In this article: Prepare Microsoft Windows Server 2003, 2008, and 2012 for DSR Step Disable the Windows Firewall Step Install the Loopback Adapter Windows Server 2003 Windows Server 2008 or Windows Server 2008 R2 Step 3. Make the Windows Networking Stack Use the Weak Host Model Step 4. Add the Loopback Adapter to your Site Bindings (IIS only) Step 5. Verify Direct Server Return Deployment Prepare Microsoft Windows Server 2003, 2008, and 2012 for DSR To make servers that are running Microsoft Windows Server 2003, 2008, and 2012 ready for Direct Server Return (DSR), you must complete the following steps on each server: Step Disable the Windows Firewall To enable traffic to the loopback adapter: For Microsoft Windows Server 2003, 2008, and 2012, you need to disable the built in firewall or manually change the rules to enable traffic to and from the loopback adapter. By default, the Windows firewall blocks all connections to the loopback adapter. Step Install the Loopback Adapter Windows Server 2003 To install the Microsoft loopback adapter refer to This note describes how to install the loopback adapter. Windows Server 2008 or Windows Server 2008 R Open Device Manager. On the Start menu, click Run and type dev mgmt*.msc at the prompt. Right-click on the server name and click Add legacy hardware. When prompted by the wizard, choose to Install the hardware that I manually select from a list (Advanced). Find Network Adapter in the list, and click Next. From the listed manufacturers select Microsoft, and then select Microsoft Loopback Adapter:

84 Barracuda Load Balancer Administrator's Guide - Page 84 This adds a new network interface to your server. Step 3. Make the Windows Networking Stack Use the Weak Host Model This step is required to allow the modified packet to be accepted by Windows Server 2008 servers. If you are using Windows Server 2003, you can skip to Step 4 Add the Loopback Adapter to your Site Bindings. If you are using Windows Server 2008 or Windows Server 2008 R2, use the steps in this section to make the Windows networking stack use the weak host model (which is the same model used in Windows Server 2003). DSR works by modifying the destination MAC address of the incoming traffic to one of the Real Servers behind your VIP. In versions of Windows prior to 2008, the Windows networking stack used a weak host model which allowed the host to receive packets on an interface not assigned as the destination IP address of the packet being received. With Windows Server 2008, Microsoft has implemented a strong host model which breaks the method that DSR uses. Open a command prompt with elevated permissions. To determine the interface ID for both the loopback adapter and the main NIC on the server, type: netsh interface ipv4 show interface 3. Note the IDX for both the main network interface and the loopback adapter you created. If you have not changed the interface names for this server then usually the main NIC displays as Local Area Connection, and the loopback adapter is named Local Area Connection An entry displays that includes the IDX numbers for both your loopback adapter and your Internet facing NIC. For each of these adapters enter the following commands: netsh interface ipv4 set interface <IDX number for Server NIC> weakhostreceive=enabled netsh interface ipv4 set interface <IDX number for loopback> weakhostsend=enabled netsh interface ipv4 set interface <IDX number for loopback> weakhostreceive=enabled For example: netsh interface ipv4 set interface 23 weakhostreceive=enabled netsh interface ipv4 set interface 24 weakhostsend=enabled netsh interface ipv4 set interface 24 weakhostreceive=enabled

85 Barracuda Load Balancer Administrator's Guide - Page 85 Step 4. Add the Loopback Adapter to your Site Bindings (IIS only) By default, IIS includes all interfaces, however, if you have configured a site to be bound to an individual IP address, you need to ensure that the IP address for the loopback adapter (your VIP address) is also included in the site bindings in IIS. Use the following steps to bind the loopback adapter Open the Internet Information Services (IIS) Manager, and expand the Sites folder. Click Default Web Site or click the name of the site you are modifying. Click Bindings on the Actions panel. Click Add and click HTTP or HTTPS in the Type list. Enter the IP address of your loopback adapter and the port: 5. Click OK to add the Site Binding: 6. On the Actions panel, click Restart under Manage Web Site to ensure the new binding takes effect. Step 5. Verify Direct Server Return Deployment When you are done adding the loopback adapters, try to ping the Real Servers and the VIP, and telnet to the Real Servers. If the ping doesn t work or if in response to the telnet you get a connection refused from the VIP, then the loopback adapter has not been configured correctly.

86 Barracuda Load Balancer Administrator's Guide - Page 86 Try to verify that the loopback adapters are non-arping. On either Linux or Windows systems, use the arp -a command. Also, check the systems event logs to check for IP address conflicts. If, later, once the Service is set up, the client tries to connect but is unable to access the application, then the IIS (Windows) or application has not been associated with the real IP address and the VIP.

87 Barracuda Load Balancer Administrator's Guide - Page 87 Deployment of DSR in a Linux Environment Deploy in a Linux Environment To add a non-arping adapter to a Real Server running Linux, add an alias to the lo (loopback) adapter. The following commands are examples of how to do this for some versions of Linux. Consult your operating system vendor if you need more details about how to add a non-arping loopback adapter. Edit your rc.local file (usually located at /etc/rc.d/rc.local) and add the following: sysctl -w net.ipv4.conf.lo.arp_ignore=1 sysctl -w net.ipv4.conf.lo.arp_announce=2 sysctl -w net.ipv4.conf.all.arp_ignore=1 sysctl -w net.ipv4.conf.all.arp_announce=2 ifconfig <interface_name> <ip_address> netmask arp up where: <interface_name> is lo:<number> (e.g. lo:0, lo:1, lo:2) <ip_address> is the Virtual IP Address for the Service For example: ifconfig lo: netmask arp up httpd.conf must have a VirtualHost entry for the VIPs. Edit the file to add these two lines: listen <virtual_ip_address>:80 listen <real_ip_address>:80 where: <virtual_ip_address> is the Virtual IP Address for the Service <real_ip_address> is the actual IP Address for the Real Server 3. To check if the loopback adapter is working, make sure the Real Server is bound to the loopback adapter s IP address. Output from the i fconfig command should show the presence of the loopback adapter.

88 Barracuda Load Balancer Administrator's Guide - Page 88 Deployment of DSR in Windows XP Environment Deploy in a Windows/XP Environment For information on how to add a non-arping adapter in a Windows/XP environment, refer to Or, check the Microsoft Support Site for your operating system. Applications running on Microsoft Real Servers must be configured to accept traffic received on the VIP addresses (the loopback IP addresses). To do this, add the VIP addresses to IIS (Internet Information Services) on each Real Server. The VIP addresses must be listed above the real IP address of the Real Server. Associate the website or application with the VIP addresses. Related Articles Direct Server Return Deployment Deploying in a Linux Environment Deployment in a Microsoft Windows Server 2003, 2008, and 2012 Environment Multiple Network Adapters on Real Servers

89 Barracuda Load Balancer Administrator's Guide - Page 89 Multiple Network Adapters on Real Servers Real Servers that are on multiple networks simultaneously may break the route path. If a Real Server has more than one network adapter enabled, which gives traffic an alternate route around the Barracuda Load Balancer, the deployment will not work properly even though it may appear to work initially. There are two exceptions where Real Servers may have multiple network adapters: The networks that the Real Servers are on are isolated from each other and cannot access the WAN network without going through the Barracuda Load Balancer. Static routes for incoming and outgoing traffic for each IP address of each Real Server have been defined. Related Articles Direct Server Return Deployment Deploying in a Linux Environment Deploying in a Windows/XP Environment Deployment in a Microsoft Windows Server 2003, 2008, and 2012 Environment

90 Barracuda Load Balancer Administrator's Guide - Page 90 High Availability Deployment Caution High availability (HA) is an advanced feature and may not be appropriate for all environments; contact Barracuda Networks Technical Support before enabling this feature. In this Section Understanding Barracuda Load Balancer High Availability How to Configure the Barracuda Load Balancers for High Availability How to Configure High Availability in Bridge-Path Mode How to Manage a High Availability Environment with Two Barracuda Load Balancers How to Replace a Barracuda Load Balancer in a High Availability Environment How to Remove a Barracuda Load Balancer from a High Availability Environment How to Update Firmware on Clustered Systems Multiport Configuration in a High Availability Environment

91 Barracuda Load Balancer Administrator's Guide - Page 91 Understanding Barracuda Load Balancer High Availability Caution High availability (HA) is an advanced feature and may not be appropriate for all environments; contact Barracuda Networks Technical Support before enabling this feature. The High Availability (HA) environment is available on the Barracuda Load Balancer 340 and higher. Virtual Interface If the Server is in the same network as the custom virtual interface, then the custom virtual interface is used to connect to the Server using the interface route/static route or the default gateway, in that order. If the Server, the custom virtual interface, and the WAN IP are all in the same network, you cannot use the custom virtual interface to connect to the Server. In this scenario, the WAN IP is always used to connect to the Server. The virtual interface of the service can be in any network. High Availability Operation Use High Availability (HA) to cluster two Barracuda Load Balancers as an active-passive pair. Only one system actively processes traffic at any one time, but the two systems continuously share almost all configuration and monitor each other's health. The active system in a clustered pair handles all of the traffic until one of the following conditions is encountered: Passive system detects that the active system is no longer responsive on the WAN; Active system detects that its LAN connection has been lost; Administrator manually forces failover using the web interface; Active system encounters a hardware failure (including a power failure) or a failure in one of its critical software modules. If any of these conditions is encountered, the passive Barracuda Load Balancer then: becomes active; assumes all of the Virtual IP addresses of the services and the LAN IP address of the other Barracuda Load Balancer; performs the load balancing. Clustered Barracuda Load Balancers negotiate which is the active one according to the Virtual Router Redundancy Protocol (VRRP) specification. The two systems must be configured with the same cluster shared secret and group ID. If other systems on the same subnet are also using VRRP, the cluster group ID must be unique. The passive Barracuda Load Balancer does not do any load-balancing or monitoring of Services or Real Servers. For example, in the web interface of the passive system, all of the Services and Real Servers on the BASIC > Services have red health indicators. Requirements Before joining two systems, each Barracuda Load Balancer must meet the following requirements: Barracuda Load Balancer 340 or higher; note that both Barracuda Load Balancers must be the same model; Activated and on the same version of firmware; Able to access all Real Servers; On the same physical network segment; Able to reach the other Barracuda Load Balancer on the WAN interface. When clustering two Barracuda Load Balancers for high availability, Barracuda Networks recommends enabling PortFast on the relevant ports. In addition, the active system should be fully configured; see Services and Configuring the Load Balancer Network for a complete list of service and network configuration tasks. For the passive system, follow the instructions in the Configuring the Passive System section. Once the systems are clustered, you must manually reboot the passive system. Do not configure Services on the passive system. To speed up recognition of a newly active Barracuda Load Balancer, disable spanning tree protocol on the ports of the switch where the WAN ports of the two Barracuda Load Balancers are connected. If it is a Cisco switch, enable Spanning Tree PortFast on the ports connected to the WAN ports of the Barracuda Load Balancers. When the Barracuda Load Balancer becomes active it sends out a gratuitous address resolution protocol (ARP). It continues to send a gratuitous ARP every minute; the passive system does not issue any ARPs.

92 Barracuda Load Balancer Administrator's Guide - Page 92 Related Articles How to Configure the Barracuda Load Balancers for High Availability How to Manage of a High Availability Environment with Two Barracuda Load Balancers How to Remove a Barracuda Load Balancer from a High Availability Environment

93 Barracuda Load Balancer Administrator's Guide - Page 93 How to Configure the Barracuda Load Balancers for High Availability For an overview of High Availability (HA), and a list of requirements, see the article Understanding Barracuda Load Balancer High Availability. Requirements Before joining two systems, each Barracuda Load Balancer must meet the following requirements: Barracuda Load Balancer 340 or higher; note that both Barracuda Load Balancers must be the same model; Activated and on the same version of firmware; Able to access all Real Servers; On the same physical network segment; Able to reach the other Barracuda Load Balancer on the WAN interface. The active system should be fully configured; see Services and Configuring the Load Balancer Network for a complete list of service and network configuration tasks. When clustering two Barracuda Load Balancers for HA, Barracuda Networks recommends enabling PortFast on the switch ports to which the Barracuda Load Balancer s interfaces are to be connected. Configure the Active (Primary) System On the Primary system, complete the following steps: Log into the Primary system as the administrator, go to the ADVANCED > BACKUP page, and back up the configuration. Go to the ADVANCED > High Availability page, and complete the following: Set Enable High Availability to Yes. In the Cluster Shared Secret field, enter an alphanumeric shared secret passcode; you must enter the same code on the Active and Passive systems in an HA configuration so that the systems trust one another. Do not use special characters. In the Cluster group ID field, enter a numeric shared group value. You must enter the same value on the Primary and Secondar y systems in an HA configuration. The Maximum value is Specify how you wish a failed system to behave when recovering from a failed state: Select Automatic if you wish the failed system to resume the active role upon recovery. Select Manual to ensure that the currently active system does not failback to the peer automatically but continues to remain active until the administrator can determine the cause of failure of the now recovered peer. Click Save Changes. Go to the BASIC > IP Configuration page, and note the WAN IP Address; you will enter this value on the Secondary system in the AD VANCED > High Availability page in the section that follows. Configure the Passive (Secondary) System On the Secondary system, complete the following steps: Log into the Secondary system as the administrator, go to the ADVANCED > High Availability page, and complete the following: Set Enable High Availability to Yes. Enter the same shared secret you entered on the Primary system in the Cluster Shared Secret field. In the Cluster group ID field, enter the same value you entered on the Primary system. Click Save Changes. Go to the BASIC > IP Configuration page, and verify the LAN IP Address and LAN Netmask fields are blank. Go to the ADVANCED > High Availability page, and enter the WAN IP address of the Primary system in the Clustered Systems field, and click Join Cluster. Allow a few minutes for the clustering process to complete. Verify the Configuration is in Sync Once joined in a cluster, on each system, verify the associated system displays its peer in the Clustered Systems table on the ADVANCED > High Availability page. After verifying that the configuration is in sync, please perform some configuration changes on the active unit and check whether those changes appear on the Passive unit. The clustering process may take up to 5 minutes to complete and no configuration changes are permitted during this period. Configuration changes may take up to a minute to sync to the peer, on clustered systems.

94 Barracuda Load Balancer Administrator's Guide - Page 94 Related Articles Understanding Barracuda Load Balancer High Availability How to Manage of a High Availability Environment with Two Barracuda Load Balancers How to Add or Remove a Barracuda Load Balancer form a High Availability Environment Multiport Configuration in a High Availability Environment

95 Barracuda Load Balancer Administrator's Guide - Page 95 How to Configure High Availability in Bridge-Path Mode This article refers to Barracuda Load Balancer firmware release 3.1 and higher. For an overview of High Availability (HA), and a list of requirements, see the article Understanding Barracuda Load Balancer High Availability. Requirements Before joining two systems, each Barracuda Load Balancer must meet the following requirements: Barracuda Load Balancer 340 or higher; note that both Barracuda Load Balancers must be the same model; Activated and on the same version of firmware; Able to access all Real Servers; On the same physical network segment; Able to reach the other Barracuda Load Balancer on the WAN interface. The active system should be fully configured; see Services and Configuring the Load Balancer Network for a complete list of service and network configuration tasks. When clustering two Barracuda Load Balancers for HA, Barracuda Networks recommends enabling PortFast on the switch ports to which the Barracuda Load Balancer s interfaces are to be connected. Configure the Active (Primary) System On the Primary system, complete the following steps: Log into the Primary system as the administrator, go to the ADVANCED > BACKUP page, and back up the configuration. Go to the ADVANCED > High Availability page. Set Enable High Availability to Yes. In the Cluster Shared Secret field, enter an alphanumeric shared secret passcode; you must enter the same code on the Active and Passive systems in an HA configuration so that the systems trust one another. Do not use special characters. In the Cluster group ID field, enter a numeric shared group value. You must enter the same value on the Primary and Secondary syste ms in an HA configuration. The Maximum value is 255. Specify how you wish that a failed system behaves when recovering from a failed state: Select Automatic if you wish that a failed system resume the active role upon recovery. Select Manual to ensure that the currently active system does not failback to the peer automatically but continues to remain active until the administrator can determine the cause of failure of the now recovered peer. Click Save Changes. Go to the BASIC > IP Configuration page, and note the WAN IP Address; you will enter this value on the Secondary system in the AD VANCED > High Availability page in the section that follows. Configure the Passive (Secondary) System On the Secondary system, complete the following steps: Log into the Secondary system as the administrator, and go to the BASIC > IP Configuration page. In the Operating Mode section, verify the mode is set to Route-Path; if the operating mode is set to Bridge-Path, click Convert Once the clustering process is complete, the configuration sync automatically converts the operational mode to Bridge-Path. Disconnect the LAN cable from the Secondary system to prevent network looping. Go to the ADVANCED > High Availability page, and complete the following: Set Enable High Availability to Yes. Enter the same shared secret you entered on the Primary system in the Cluster Shared Secret field. In the Cluster group ID field, enter the same value you entered on the Primary system. Verify no ports are selected for Failover on Link Down. Click Save Changes. Go to the BASIC > IP Configuration page, and verify the LAN IP Address and LAN Netmask fields are blank. Go to the ADVANCED > High Availability page, and enter the WAN IP address of the Primary system in the Clustered Systems field, and click Join Cluster. Allow a few minutes for the clustering process to complete. Reconnect the LAN cable to the Secondary system once clustering begins. Verify the Configuration is in Sync Once joined in a cluster, on each system, verify the associated system displays its peer in the Clustered Systems table on the ADVANCED > High Availability page.

96 Barracuda Load Balancer Administrator's Guide - Page 96 After verifying that the configuration is in sync, please perform some configuration changes on the active unit and check whether those changes appear on the Passive unit. The clustering process may take up to 5 minutes to complete and no configuration changes are permitted during this period. Configuration changes may take up to a minute to sync to the peer, on clustered systems. Related Articles Understanding Barracuda Load Balancer High Availability How to Manage a High Availability Environment with Two Barracuda Load Balancers How to Remove a Barracuda Load Balancer from a High Availability Environment

97 Barracuda Load Balancer Administrator's Guide - Page 97 How to Manage a High Availability Environment with Two Barracuda Load Balancers For an overview of High Availability, and a list of requirements, see the article Understanding Barracuda Load Balancer High Availability. In this article: Manage Access to the Passive System Failover if LAN Link Goes Down Forceful or Manual Failover Primary and Backup Roles Failback Synchronize Data between Clustered Systems Specify Source IP Address in a Clustered Environment Update Firmware on Clustered Systems Manage Access to the Passive System Unless you wish to use the WAN IP address to access the web interface of the passive system, configure a management IP address in the Mana gement IP Configuration section on the BASIC > IP Configuration page. This management IP address is used by the Ethernet port on the back of the passive system. Failover if LAN Link Goes Down There is an option to fail over to the passive system if the active system cannot detect its LAN link. In one-armed deployments (including Direct Server Return), the LAN port does not need to be monitored as the Real Servers are all connected to the WAN, so this option should be disabled. If the Barracuda Load Balancer is in bridge-path mode, LAN port monitoring is compulsory. Forceful or Manual Failover You can force failover to the passive system using the web interface. This transfers the load to the passive system without bringing down any of the interfaces of the active system. When the passive system has become active, LAN or WAN cables can be removed or other maintenance performed on the now-passive system. Primary and Backup Roles When two systems are joined in a cluster, the system that joins the cluster is the backup system. The other one has the role of primary system. Initially, the primary system is the active system. Either of the systems in a cluster is capable of being the active system. The backup and primary roles are important when discussing failback. Failback There is an automatic failback option that can be configured if you want the originally active (primary) system to take over the Virtual IP addresses and resume load balancing upon its recovery after a failover. This option can be found on the ADVANCED > High Availability page. You can manually switch to the primary system using the Failback command that is available on the same page. It may be better to opt for manual failback, as it can minimize the number of times that service is interrupted. For example, if the primary system suffers an outage, the backup system takes over. When the primary system recovers, if automatic failback is selected, then it will once again become the active system. This means two interruptions of service. If manual failback is selected, then the backup system will continue processing traffic even after the recovery of the primary system. Synchronize Data between Clustered Systems When two Barracuda Load Balancers are initially joined, most configuration settings are copied from the primary system in the cluster to the backup system (the system that joins the cluster). These settings are synchronized between the systems on an ongoing basis. The following data is shared between the clustered systems: Global system settings configured through the web interface Any installed SSL Certificates All static routes and VLANs, etc., configured on the ADVANCED > ADVANCED IP Config The following data is unique between the clustered systems: All of the system IP configuration (WAN IP address, management IP address, operating mode, DNS servers and domain) configured on the BASIC > IP Configuration page except for the LAN IP address System password, time zone, and web interface HTTP port as configured on the BASIC > Administration page Parameters on the ADVANCED > Appearance page The HTTPS port and SSL certificate used to access the web interface as configured on the ADVANCED > Secure Administration page page

98 Barracuda Load Balancer Administrator's Guide - Page 98 Specify Source IP Address in a Clustered Environment By default, the source IP address of traffic sent to the Real Servers is translated (source NAT d) to be the WAN IP address of the Barracuda Load Balancer. If the Barracuda Load Balancer is clustered, the WAN IP address is not shared between the two clustered systems. To use the same source IP address in the event of failover, complete the following steps on the active system to create a custom virtual interface that associates an externally-accessible IP address with the WAN port. Use this IP address to create a source NAT rule. This interface is used by the backup system if failover occurs. The changes made are propagated automatically to the passive system. On the ADVANCED > Advanced IP Config page, in the Custom Virtual Interfaces table, create a custom interface by filling in the following fields: IP/Network Address and Netmask an externally-accessible IP address and netmask (may be on the same subnet as the WAN IP address) Service/Interface Name e.g., SNAT IP Address Port Select WAN from the list In the Source Network Address Translation table, create a source NAT rule by entering values for: Internal Address, Netmask Enter an internal IP address and netmask. Usually this is the Real Server network Outbound Address The externally-accessible IP address from step Port Select the WAN port Update Firmware on Clustered Systems Update the passive system first. On the passive system: If the passive system is also the backup system, go to the ADVANCED > High Availability page and set Failback Mode to Manual. This ensures that the transfer of control from one system to the other does not happen while the firmware update is in process. Go to the ADVANCED > Firmware Update page and follow the instructions there to update the firmware. When the update is complete and the passive system is running the new firmware, update the firmware on the active system. When all updates are complete, you can failback to the primary system, if desired, by either: Changing Failback Mode to Automatic, or Clicking Failback in the Clustered Systems table Related Articles Understanding Barracuda Load Balancer High Availability How to Configure the Barracuda Load Balancers for High Availability How to Remove a Barracuda Load Balancer from a High Availability Environment

99 Barracuda Load Balancer Administrator's Guide - Page 99 How to Replace a Barracuda Load Balancer in a High Availability Environment Caution High availability (HA) is an advanced feature; contact Barracuda Networks Technical Support before replacing a Barracuda Load Balancer in a cluster. The steps for replacing a Barracuda Load Balancer differ based on whether the system is the Primary or the Secondary device in the cluster. The High Availability (HA) environment is available on the Barracuda Load Balancer 340 and higher; note that both Barracuda Load Balancers in HA must be the same model and on the same firmware. In this article: Replace the Primary System in a High Availability Environment Scenario New Replacement Primary Device Scenario Activate the New Primary Device in an Isolated Network Replace the Secondary System in a High Availability Environment Replace the Primary System in a High Availability Environment This section describes the most common scenarios for replacing the Primary system in HA. Because the Primary system is offline during replacement, you must schedule downtime when replacing the Primary system in HA. Select the scenario that best fits your use case, and complete the associated steps when replacing the Primary system in an HA environment. Scenario New Replacement Primary Device Important Follow the steps in this procedure carefully; on firmware version or higher, it is necessary to perform a hot swap and delete the Primary device from the Secondary device configuration at the end of this procedure to avoid wiping out the configuration of the Se condary device. Figure New Primary Device Replacement. Back up the system configuration on the Secondary device. Note that the Secondary device must remain active since the Primary device is down during this replacement procedure Complete the following steps on the Secondary device: a. b. Log in to the Secondary device, and navigate to the ADVANCED > Backup page. In the Configuration Backup section, click Backup to download a backup to your desktop. Install the new replacement Primary device and assign the WAN IP address of your old Primary device to the new Primary device. Verify the new Primary device is on the same firmware version as the existing devices. Once the new device is installed, log in to the Primary System, go to the ADVANCED > Backup page, and complete the following steps: a. In the Restoring Backups section, click Browse after the Restore Backup File; navigate to and select the configuration backup saved to your desktop. b. Click Upload to upload the configuration backup file to the Primary device. Warning Connections on the primary and secondary devices may go down intermittently during this procedure On the Primary device, go to the ADVANCED > High Availability page, and configure all attributes in the exact same manner as those on the Secondary device; the Cluster Shared Secret must match exactly. On the Secondary device, navigate to the ADVANCED > High Availability page, and complete the following steps: a. In the Clustered Systems section, delete the IP address of the old Primary device; the system refreshes and wipes out all of the configuration settings. b. Once the device is back online, go to the BASIC > IP Configuration page and set the domain name. c. Navigate to the ADVANCED > High Availability page, and under Clustered Systems, assign the IP address of the Primary de

100 c. Barracuda Load Balancer Administrator's Guide - Page 100 vice, and click Join Cluster. Scenario Activate the New Primary Device in an Isolated Network Figure Isolated Network Environment. Back up the system configuration on the Secondary device Log in to the Secondary device, and navigate to the ADVANCED > Backup page. In the Configuration Backup section, click Backup to download a backup to your desktop. Install the new replacement Primary device in an isolated network, and complete the following steps: a. Go to the ADVANCED > Backup page on the Primary device, and in the Restoring Backups section, click Browse after the R estore Backup File. Navigate to and select the configuration backup saved to your desktop in step 3 above. Click Upload to upload the configuration backup file to the Primary device. b. c. d. Note that the Secondary device must remain active until step 6 in this procedure. Assign the WAN IP address of the old Primary device to the new Primary device. Verify the configuration on the new Primary device. After verifying the configuration, complete the following at the same time: Shutdown the Secondary device, and Connect and power up the new Primary device to the production network. Put the Secondary device in an isolated network. On the Primary device, go to the ADVANCED > High Availability page, and configure all attributes in the exact same manner as those on the Secondary device; the Cluster Shared Secret must match exactly. 9. Remove the Secondary device from the cluster by deleting the IP address of the old Primary device from the Clustered Systems section. 10. Put the Secondary device back in the production network. Replace the Secondary System in a High Availability Environment Figure 3. Secondary System Replacement. Remove the old Secondary device using the instructions in the article How to Remove a Barracuda Load Balancer from a High Availability Environment. 3. Install the new replacement Secondary device using the Barracuda Load Balancer Quick Start Guide. Once the new device is installed, follow the steps in the article How to Configure the Barracuda Load Balancers for High Availability to complete the system replacement in the HA configuration. When replacing a system in a cluster, both systems must be on the same firmware version. Related Articles Understanding Barracuda Load Balancer High Availability How to Configure the Barracuda Load Balancers for High Availability How to Manage a High Availability Environment with Two Barracuda Load Balancers How to Update Firmware on Clustered Systems How to Remove a Barracuda Load Balancer from a High Availability Environment Barracuda Load Balancer Deployment Options

101 Barracuda Load Balancer Administrator's Guide - Page 101 How to Remove a Barracuda Load Balancer from a High Availability Environment If you are running firmware version or earlier you must manually delete the service virtual interfaces and any custom virtual interfaces from the system you are removing from the cluster. Remove a System from a Cluster On the Barracuda Load Balancer to be removed from the cluster, perform the following steps: On the ADVANCED > High Availability page, clear the Cluster Shared Secret to remove the Barracuda Load Balancer from the cluster. You are automatically logged out of the web interface; log back into the system. On the ADVANCED > High Availability page, click the Trash icon to delete the other system from the Clustered Systems table; you must perform this action on both systems in the cluster. 3. If the systems are in two-arm Route-Path mode, go to the BASIC > IP Configuration page and manually clear the LAN IP Address to prevent any IP conflicts with the peer system, and then click Save Changes. 4. The peer system should now be standalone and active with its configuration intact; this device is now standalone but without any virtual interfaces. Related Articles Understanding Barracuda Load Balancer High Availability How to Configure the Barracuda Load Balancers for High Availability How to Manage of a High Availability Environment with Two Barracuda Load Balancers Multiport Configuration in a High Availability Environment

102 Barracuda Load Balancer Administrator's Guide - Page 102 How to Update Firmware on Clustered Systems Update the passive system first. On the passive system: 3. If the passive system is also the backup system, go to the ADVANCED > High Availability page and set Failback Mode to Manual. This ensures that the transfer of control from one system to the other does not happen while the firmware update is in process. Go to the ADVANCED > Firmware Update page and follow the instructions there to update the firmware. When the update is complete and the passive system is running the new firmware, update the firmware on the active system. When all updates are complete, you can failback to the primary system, if desired, by either: Changing Failback Mode to Automatic, or Clicking Failback in the Clustered Systems table Related Articles Understanding Barracuda Load Balancer High Availability How to Configure the Barracuda Load Balancers for High Availability How to Manage of a High Availability Environment with Two Barracuda Load Balancers How to Add or Remove a Barracuda Load Balancer form a High Availability Environment Multiport Configuration in a High Availability Environment

103 Barracuda Load Balancer Administrator's Guide - Page 103 Virtual Deployment This virtual appliance requires a 64-bit capable host. Step 1: Select Your Hypervisor Deployment: In this Section Download Package Type Hypervisor Compatibility OVF Package Deployment VMware ESX and ESXi ("vsphere Hypervisor") versions 4.0, 4.1, 5.0, 5.1 VMware ESX and ESXi version 3.5 Sun/Oracle VirtualBox and VirtualBox OSE version 3.2 VMX Package Deployment VMware Server 0+ Workstation 6.0+, Player 3.0+ Fusion 3.0 XVA Package Deployment Citrix XenServer 5.5+ Step 2: Getting Your Virtual Machine Up and Running: Barracuda Load Balancer Vx Quick Start Guide Step 3: Getting Started With the Load Balancer: Configure the Barracuda Load Balancer Vx Web Interface Managing Your Virtual Machine: Adding Disk Space, Drives and RAM for Your Virtual Appliance Backing Up Your Virtual Machine System State

104 Barracuda Load Balancer Administrator's Guide - Page 104 Hypervisor Compatibility and Deployment - OVF Package Hypervisor Compatibility This package's virtual appliance runs under the following hypervisors: VMware ESX and ESXi ("vsphere Hypervisor") versions 4.0 and above VMware ESX and ESXi version 3.5 Sun/Oracle VirtualBox and VirtualBox OSE version 3.2 Deploying the Virtual Appliance with Your Hypervisor ESX(i) 3.5: Use the OVF file ending in: -35.ovf for this environment. 3. Select Import from file: and navigate to the file BarracudaLoadBalancer-vm<version#>-fw FIRMWARE -<version#>.ovf. Clicking Next, review the appliance information, End User License Agreement, and set the name of the virtual appliance to something useful to your environment. Click Finish. 4. Once your appliance has finished importing, right-click it and choose Open Console and then click the green arrow to power on the Clicking Next, review the appliance information, End User License Agreement, and set the name of the virtual appliance to something useful to your environment. Set the network to point to the target network for this virtual appliance. 4. Once your appliance has finished importing, right-click it and choose Open Console and then click the green arrow to power on the From the File menu in the VMware Infrastructure client, choose Virtual Appliance -> Import. virtual appliance. Follow the Quick Start Guide instructions to provision your virtual appliance. ESX(i) 4.x and 5.x: Use the OVF file ending in: -4x.ovf for this environment. VirtualBox: From the File menu in the vsphere client, choose Deploy OVF Template... Select Import from file: and navigate to the file BarracudaLoadBalancer-vm3.0-fw FIRMWARE x.ovf. virtual appliance. Follow the Quick Start Guide instructions to provision your virtual appliance. Use the OVF file ending in: -4x.ovf for this environment. From the File menu in the VirtualBox client, choose Import Appliance. Navigate to the file BarracudaLoadBalancer-vm3.0-fw FIRMWARE x.ovf Use the default settings for the import and click Finish. Start the appliance. Follow the Quick Start Guide instructions to provision your virtual appliance.

105 Barracuda Load Balancer Administrator's Guide - Page 105 Hypervisor Compatibility and Deployment - VMX Package Hypervisor Compatibility This package's virtual appliance runs under the following hypervisors: VMware Server 0+ Workstation 6.0+, Player 3.0+ Fusion 3.0+ Deploying the Virtual Appliance with Your Hypervisor Server x: Put the files ending in.vmx and.vmdk into a folder in your datastore (which you can locate from the Datastores list on your server's summary page). From the VMware Infrastructure Web Access client's Virtual Machine menu, choose Add Virtual Machine to Inventory. Navigate to the folder used in step 1 and click the file BarracudaLoadBalancer.vmx from the list under Contents. Click OK. Start the appliance. Follow the Quick Start Guide instructions to provision your virtual appliance. Player 3.x: From the File menu, choose Open a Virtual Machine. Navigate to the file BarracudaLoadBalancer.vmx Use the default settings and click Finish. Start the appliance. Follow the Quick Start Guide instructions to provision your virtual appliance. Workstation 6.x: From the File menu, choose Open a Virtual Machine. Navigate to the file BarracudaLoadBalancer.vmx Use the default settings and click Finish. Start the appliance. Follow the Quick Start Guide instructions to provision your virtual appliance. Fusion 3.x: From the File menu, choose Open a Virtual Machine. Navigate to the file BarracudaLoadBalancer.vmx Use the default settings and click Finish. Start the appliance. Follow the Quick Start Guide instructions to provision your virtual appliance.

106 Barracuda Load Balancer Administrator's Guide - Page 106 Hypervisor Compatibility and Deployment - XVA Package Hypervisor Compatibility This package's virtual appliance runs under the following hypervisors: Citrix XenServer 5.5+ Deploying the Virtual Appliance with Your Hypervisor From the File menu in the XenCenter client, choose Import VM... Browse to the file BarracudaLoadBalancer-<version#>-fw FIRMWARE -<version#>.xva and choose the Exported template radio button. Clicking Next >, review the template information and click Finish to import the template. Right-click the resulting template and choose New VM... Follow the Quick Start Guide instructions to provision your virtual appliance.

107 Barracuda Load Balancer Administrator's Guide - Page 107 Barracuda Load Balancer Vx Quick Start Guide To setup your Barracuda Load Blalancer Vx, complete the following steps: Before You Begin Step Enter the License Code Step Open Firewall Ports Step 3. Deployment Options Step 4. Configure Network Settings Step 5. Configure a Service Step 6. Test connectivity Next Step Related Articles Adding Disk Space, Drives and RAM for Your Virtual Appliance Backing Up Your Virtual Machine System State Before You Begin Deploy the Barracuda Load Balancer Vx on your hypervisor. You will need only a single virtual NIC on your virtual appliance. Step Enter the License Code You will need your Barracuda Vx license token. You should have received this via or from the website when you downloaded the Barracuda Load Balancer Vx package. If not, you can request an evaluation on the Barracuda Networks website at The license token looks similar to the following: ACEFG. 3. Start your virtual appliance, making sure to open the console. When the login prompt appears, log in as admin with a password of admin. Set the IP address and, under Licensing, enter your Barracuda License Token and default domain to complete provisioning. The virtual appliance will reboot at this time. Step Open Firewall Ports If your Barracuda Load Balancer Vx is located behind a corporate firewall, open the following ports on your firewall to ensure proper operation: Port Direction TCP UDP Usage 22 Out Yes No Technical Support Services 53 Out Yes Yes Domain Name Service (DNS) 80 Out Yes No IPS and firmware updates 123 Out No Yes Network Time Protocol (NTP) 80 Out Yes No Initial Provisioning * * The initial provisioning port can be disabled once the initial provisioning process is complete. For any ports used by Services, configure 1:1 NATs as needed. Also configure any port required to access the VIP address of a load-balanced Service. To send system alerts and notifications to the administrator, the Barracuda Load Balancer must be able to communicate with the mail server over the port specified on the BASIC > Administration page. This may require opening that port on the firewall. Certain protocols require additional ports to be open. Examples include FTP and streaming media protocols. When configuring Services using these protocols, ensure that the additional ports required are not blocked by the firewall. Step 3. Deployment Options

108 Barracuda Load Balancer Administrator's Guide - Page 108 Before deploying the virtual appliance, take the following into consideration: 3. The Barracuda Load Balancer Vx can be deployed only in Route-Path mode; Bridge-Path deployment is not supported. Once you have imported the image, verify the RAM and CPU Cores have been assigned based on the details in the article Sizing CPU, RAM and Disk for Your Barracuda Load Balancer Vx. You can assign a maximum of 3 network interface cards (NICs) to the Barracuda Load Balancer 340 and 440 based on the following priority list: First NIC Card: WAN Port Second NIC Card: LAN Port Third NIC Card: Management Port For example, if you only need the WAN and the management ports, you must still assign 3 NICs based on this priority list. Common deployment options include: Use a Service type of TCP Proxy in a one-armed Route Path deployment, where the WAN port of the Barracuda Load Balancer is used for all load-balanced traffic as shown in Figure Figure One-armed Route-Path deployment. Two-armed Route-Path deployment, where the Barracuda Load Balancer is deployed in-line, performing a NAT from the WAN network to the LAN. By default the VM is configured for one network interface card (NIC). If you add another NIC, the first installed NIC is the WAN and the second installed NIC is the LAN. A complete list of deployment options are described in the Barracuda Load Balancer Deployme nt Options article.

109 Barracuda Load Balancer Administrator's Guide - Page 109 Figure 2: Two-armed Route-Path Deployment. Step 4. Configure Network Settings Log into the Barracuda Load Balancer Vx web interface as the administrator. Username: admin Password: admin Go to the BASIC > IP Configuration page. If there is a LAN interface, enter the LAN IP address and subnet mask. In two-armed Route-Path mode, the LAN IP address acts as the default gateway for the Real Servers. In one-armed Route-Path mode, the LAN IP address may be used for management. 3. Fill in values for the rest of the fields on the page and save your changes. Step 5. Configure a Service For a one-armed Route-Path deployment, connect the Real Servers to the switch plugged into the interface. Create the Service on the Barracuda Load Balancer Vx using the BASIC > Services page. Step 6. Test connectivity Verify network connectivity by using a system in your existing network to access the Service you just defined. Connect to the Virtual IP address in the same way you used to go to the single server. Next Step Follow the instructions in Step 3: How to Configure the Barracuda Load Balancer Web Interface to configure your virtual machine.

110 Barracuda Load Balancer Administrator's Guide - Page 110 Sizing CPU, RAM and Disk for Your Barracuda Load Balancer Vx Barracuda Networks recommends the following sizing for initial deployment of your virtual appliance, or upgrading existing installations. RAM and Cores Model Maximum #Cores RAM - Recommended Minimum GB (1) 3GB (1) or more (1) 4GB (1) Note: (1) 1GB per core. CPUs/Cores You need to provision the number of cores in your hypervisor before the Barracuda Load Balancer Vx can make use of them. Each model can only make use of a certain number of cores. If you assign 6 cores, for example, to a model 340 Barracuda Load Balancer Vx, which can only make use of 2 cores, the virtual machine will turn off the extra cores that cannot be used. To add cores: 3. Shut down your hypervisor. Go into Hypervisor settings. Add CPUs. The number of CPUs shown that you can add will vary with your hypervisor licensing and version. In some cases, the number of CPUs you can add must be a multiple of Hard Drives Barracuda Networks requires a minimum of 50GB hard disk space to run your Barracuda Load Balancer Vx: Model Hard Disk Space GB GB GB From your hypervisor, you can edit the provisioned size of the hard drives, or you can add a hard drive. To add a hard drive: Shut down your Barracuda Load Balancer Vx. Take a snapshot of your virtual machine. Edit the settings in your virtual machine and either increase the size of the hard drive or add a new hard drive. Restart the virtual machine. As it is booting up, using the POPOUT CONSOLE, a blue screen pop-up displays asking if you want to use the new additional space. Answer Yes. Note that the pop-up will time out after 30 seconds if you do not respond, and the answer will default to No. Resizing may take several minutes, depending on the amount of provisioned hard drive space.

111 Barracuda Load Balancer Administrator's Guide - Page 111 Backing Up Your Virtual Machine System State Virtual machine environments generally provide a snapshot capability, which captures the state of a system as it's running. Once a snapshot is created, you can perform additional operations on the system and revert to the snapshot in the case of disaster recovery (or for any other reason). Because this feature is so powerful, Barracuda strongly recommends performing a snapshot at certain points in time: Before upgrading the Barracuda product firmware. Before making major changes to your configuration (this makes taking a snapshot a convenient undo mechanism). After completing and confirming a large set of changes, such as initial configuration. As a periodic backup mechanism. Before taking a snapshot, Barracuda strongly recommends powering off the virtual machine. This step is particularly important if you are using Microsoft Hyper-V as your virtual machine environment. Barracuda Networks recommends that you review your virtual environment documentation regarding the snapshot capabilities and be familiar with their features and limitations.

112 Barracuda Load Balancer Administrator's Guide - Page 112 VMware View Deployment This article applies to Barracuda Load Balancer running firmware version 4.2 or higher, and VMware View version 5.1 or higher. VMware View was formerly known as VMware Virtual Desktop Infrastructure (VDI). This article assumes you have installed the Barracuda Load Balancer, have an activated subscription, and that your virtual systems are installed and configured. By the time you are ready to deploy in production, you will need to update your DNS server with an entry that links the fully qualified domain name (FQDN) of the VMware service with the corresponding VIP address on the Barracuda Load Balancer. If you have both internal and external clients accessing the VMware service through the Barracuda Load Balancer, you may configure two different VIP addresses and two services, one to direct the traffic to VMware View Security Servers, and the other that directs traffic to the VMware View Connection Servers. This article describes how to deploy the Barracuda Load Balancer in a VMware View environment. Follow the steps in this article to configure your Barracuda Load Balancer to direct traffic to your VMware View servers. Session-based persistence of View client connections is facilitated by inspecting the JSESSIONID cookie. You can configure SSL offloading to reduce the load on your VMware servers. Follow the steps according to whether you want the Barracuda Load Balancer to perform SSL offloading or not. In this article: References If you do not want the Barracuda Load Balancer to perform SSL offloading, follow these steps: Step Import the Certificate to the View Connection Server Step Install the Certificate on the Barracuda Load Balancer Step 3. Set Up the View Service on the Barracuda Load Balancer Step 4. Set Up the View Connection Server (Not for SSL offloading) To configure the View Service with SSL offloading on the Barracuda Load Balancer, follow these steps: Step Install the Signed Certificate on the Barracuda Load Balancer Step Create the Service on the Barracuda Load Balancer Step 3. Configure Each View Connection Server for HTTP Traffic Step 4. Log into View Administrator Console Troubleshooting Why am I getting a Server Certificate warning? Why am I getting a warning/error for server authentication and unable to launch the snapshot? Why am I getting a Server Authentication failed error, even though the same certificate is installed on the Barracuda Load Balancer and the View Connection Servers? Why am I getting an error as Invalid Certificate received from server? Why I am getting a user not authenticated failure even though the username and password provided are correct? How do I restart a View Connection Server Service? How to Create a Self-Signed Certificate ja Barracuda Load BalancerSSL View Connection Server Barracuda Load Balancer Barracuda Load Balancer Barracuda Load BalancerWeb > 3. Barracuda Load BalancerView Service 4. View Connection ServerSSL Barracuda Load BalancerSSLView Service Barracuda Load Balancer Barracuda Load Balancer 3. HTTPView Connection Server 4. View Administrator Console? /? Barracuda Load BalancerView Connection Server?

113 Barracuda Load Balancer Administrator's Guide - Page 113?? View Connection Server Service? Signed Certificate You must have a signed certificate to deploy the Barracuda Load Balance in a VMware View environment; Barracuda Networks recommends that you have a signed certificate authority (CA) certificate. If you already have a signed CA certificate, go to the next task. If you do not have a signed certificate, you can use the steps at How to Create a Self-Signed Certificate to create a self-signed certificate. References VMware View 5.1 Documentation If you do not want the Barracuda Load Balancer to perform SSL offloading, follow these steps: Step Import the Certificate to the View Connection Server If you have not already installed the signed certificate on your View Connection Servers, follow these steps to install the signed certificate on every server: Select, and click to restart the 5. Install the certificate on the View Connection Server. Set the Friendly Name to vdm for the installed certificate. On the View Connection Server, right-click My Computer, and go to Manage > Service and Applications > Services View Connection Server Service Start Service. Wait for a few minutes for the View Connection Server to start listening. On the View Connection Server, in the command window, type netstat -anp TCP and check the output to see if the View Connection Server is listening on port 443 for the View Connection Service. Reference: B B23C44.html in the VMware View 5.1 Documentation Center. Step Install the Certificate on the Barracuda Load Balancer Make a copy of the signed certificate and install it on the Barracuda Load Balancer: Log in to the Barracuda Load Balancer web interface, and go to the BASIC > Certificates page. Upload the certificate. Step 3. Set Up the View Service on the Barracuda Load Balancer Use the following steps to create the View Service over SSL/HTTPS: Go to the BASIC > Services page. Click Add New Service, and create a Layer 7 - HTTPS Service: a.

114 3. 4. a. b. b. a. b. c. d. e. Barracuda Load Balancer Administrator's Guide - Page 114 The VIP address must be the address configured for the FQDN in the DNS record. From the SSL Certificate menu, select the certificate that you just installed for this Service. Click Ad d Service. In the Services Configuration table, click the Edit ( ) icon in the Actions column to edit the new Service. a. In the Persistence section, select HTTP Cookie as the Persistence Type, and specify the Cookie Name as JSESSIONID. In the Advanced Options section, set the Session Timeout to 0, and click Save Changes at the top of the page. Add each View Connection Server that provides the Service: In the Services Configuration table, click the Server link in the Add column. The Add Real Server page displays. Enter the View Connection Server details, and click Add. The server displays below the Service in the Services Configuration table. Click the Edit ( ) icon in the Actions column for the View Connection Server. In the Real Server Detail page, in the SSL section, set Enable HTTPS/SSL to Yes. If the Certificate for the Service is not a CA signed certificate, set Validate Certificate to No, otherwise set this value to Yes. Step 4. Set Up the View Connection Server (Not for SSL offloading) Configure the View Connection Server for HTTPS/SSL: 3. Log into the View Administrator Console, expand View Configuration, and click Servers. In the right pane, click the Connection Servers tab; all configured View Connection Servers display in the table below. Edit each server that is going to be part of the pool: a. b. c. d. Select the VDI Connection Server, and click Edit.... The Edit View Connection Server Settings dialog box displays. In the HTTP(S) Secure Tunnel section, select the Use Secure Tunnel connection to desktop check box In the External URL field, edit the URL to specify the FQDN of the VDI Service in the form <FQDN> :443 In the PCoIP Secure Gateway section, clear the Use PCoIP Secure Gateway for PCoIP connections to desktop check box: e. Click OK to save your changes. You should be able to access the VMware View Connection service through the VIP address. If not, refer to Troubleshooting. To configure the View Service with SSL offloading on the Barracuda Load Balancer, follow these steps: Step Install the Signed Certificate on the Barracuda Load Balancer Make a copy of the signed certificate and install it on the Barracuda Load Balancer: Log in to the Barracuda Load Balancer web interface, and go to the BASIC > Certificates page. Upload the certificate. Step Create the Service on the Barracuda Load Balancer

115 Barracuda Load Balancer Administrator's Guide - Page 115 Use the following steps to create the View Service over SSL/HTTPS: Go to the BASIC > Services page. Click Add New Service, and create a Layer 7 - HTTPS Service: a. b. The VIP address must be the address configured for the FQDN in the DNS record. From the SSL Certificate menu, select the certificate that you just installed for this Service. Click Add Service In the Services Configuration table, click the Edit ( ) icon in the Actions column to edit the new Service. a. In the Persistence section, select HTTP Cookie as the Persistence Type, and specify the Cookie Name as JSESSIONID. b. In the Advanced Options section, set the Session Timeout to 0, and click Save Changes at the top of the page. Add each View Connection Server that provides the Service: a. In the Services Configuration table, click the Server link in the Add column. The Add Real Server page displays. b. Enter the View Connection Server details. Set the Port to 80, or whatever the HTTP listening port is on the VMware View Connection Server and click Add. The server displays below the Service in the Services Configuration table. c. d. e. Click the Edit ( ) icon in the Actions column for the View Connection Server. In the Real Server Detail page, in the SSL section, set Enable HTTPS/SSL to No. Click Save Changes to save your settings and close the window. Step 3. Configure Each View Connection Server for HTTP Traffic Configure each VMware View Connection Server to receive HTTP traffic instead of HTTPS: Log into the View Connection Server, and locate or create the locked.properties file, located in the SSL gateway configuration folder on the View Connection Server or Security Server host. For example, install_directory\vmware\vmware View\Server\sslgateway\conf\locked.properties To configure the View Server's protocol, add the serverprotocol property to the file and set the property to http (you must enter htt p in lowercase). 3. Optional. You can add properties to configure a non-default HTTP listening port and a network interface on the View Server. To do so, To change the HTTP listening port from 80, set serverportnonssl to another port number to which the intermediate device is configured to connect. If the View Server has more than one network interface and you want it to listen for HTTP connections on only one interface, set serverhost to the IP address of that network interface. On the Barracuda Load Balancer, make sure the Service you created in the last step has this port value. 4. Save the locked.properties file. 5. Restart the View Connection Server Service or Security Server Service. Your changes take effect once the Service is restarted. Step 4. Log into View Administrator Console Update the VMware View Connection Server settings: 3. Log into the View Administrator Console, expand View Configuration, and click Servers. In the right pane, click the Connection Servers tab; all configured View Connection Servers display. Edit each VMware View Connection Server : a. b. c. d. Select the server and click Edit. The Edit View Connection Server Settings dialog box displays. In the HTTP(S) Secure Tunnel section, turn Off Use Secure Tunnel connection to desktop. In the PCoIP Secure Gateway section, turn Off Use PCoIP Secure Gateway for PCoIP connections to desktop. Click OK to save your changes. Reference: Allow HTTP Connections to Intermediate Servers tion.doc%2fguid-690c7f60-fa7f-4c35-b9a6-22f271af1ddhtml You should be able to access the VMware View Connection service through the VIP address. If not, refer to Troubleshooting. Troubleshooting Why am I getting a Server Certificate warning? The installed certificate is not from a Certification Authority. You can ignore the warning. Why am I getting a warning/error for server authentication and unable to launch the snapshot? The certificate on the Barracuda Load Balancer and the View Connection Server do not match. You should have installed a copy of the certificate from the View Connection Server onto the Barracuda Load Balancer. As a workaround, on the VMware View Client: Go to Options -> Configure SSL. Select Do not verify server identity certificates and click OK.

116 Barracuda Load Balancer Administrator's Guide - Page 116 Why am I getting a Server Authentication failed error, even though the same certificate is installed on the Barracuda Load Balancer and the View Connection Servers? The CN parameter of the installed certificate should match the FQDN of the service. Why am I getting an error as Invalid Certificate received from server? The issuing authority for the certificate installed for the service is not present under Trusted Root Certification Authorities on the client device. Install the same certificate under LOCAL Computer > Trusted Root Certification Authorities for the client device. Why I am getting a user not authenticated failure even though the username and password provided are correct? You did not enable persistence for the VMware View service on the Barracuda Load Balancer. How do I restart a View Connection Server Service? On the View Connection Server, right-click My Computer, and go to Manage > Service and Applications > Services. Select View Connection Server Service, and click Start to restart the Service. Wait for a few minutes for the View Connection Server to start listening. How to Create a Self-Signed Certificate Optional. If you do not have a signed certificate, you can use the following steps to create a self-signed certificate Log into the Barracuda Load Balancer web interface, go to the BASIC > Certificates page, and in the Certificate Generation section, click Create Certificate Enter the Certificate Name, for example, VMware View Enter the Organization Info details: In the Common Name field, enter the fully qualified domain name (FQDN) which resolves to the VIP address for the VMware View Service. For example, viewvip.localserver.com Enter the Country Code, State or Province, Locality, Organization (Company) Name, Organization (Departmental) Unit fo r your organization. From the Key Size menu, select 2048 Set Expires In to the number of days the generated certificate is to be valid. Set Allow Private Key Export to Yes.

117 Barracuda Load Balancer Administrator's Guide - Page Click Generate Certificate at the top of the section. The certificate is added to the Saved Certificates table in the Created Certificates section. In the Download column, click Certificate; the Save Token page displays. Enter a password in the Encryption Password field. Click Save. The certificate, including the private key, is exported as a PKCS12 token in a file named <certificate name>.pfx. Click Close Window to return to the Certificates page. ja 4.2Barracuda Load BalancerVMware View 5.1VMware ViewVMware VDIVirtual Desktop Infrastructure Barracuda Load Balancer VMwareFQDNBarracuda Load BalancerVIPIPDNS Barracuda Load BalancerVMwareVMware View Security ServerVMware View Connection Server2VIP Barracuda Load BalancerVMware View VMware ViewBarracuda Load BalancerJSESSIONID CookieView Client SSLVMwareBarracuda Load BalancerSSL References If you do not want the Barracuda Load Balancer to perform SSL offloading, follow these steps: Step Import the Certificate to the View Connection Server Step Install the Certificate on the Barracuda Load Balancer Step 3. Set Up the View Service on the Barracuda Load Balancer Step 4. Set Up the View Connection Server (Not for SSL offloading) To configure the View Service with SSL offloading on the Barracuda Load Balancer, follow these steps: Step Install the Signed Certificate on the Barracuda Load Balancer Step Create the Service on the Barracuda Load Balancer Step 3. Configure Each View Connection Server for HTTP Traffic Step 4. Log into View Administrator Console Troubleshooting Why am I getting a Server Certificate warning? Why am I getting a warning/error for server authentication and unable to launch the snapshot? Why am I getting a Server Authentication failed error, even though the same certificate is installed on the Barracuda Load Balancer and the View Connection Servers? Why am I getting an error as Invalid Certificate received from server? Why I am getting a user not authenticated failure even though the username and password provided are correct? How do I restart a View Connection Server Service? How to Create a Self-Signed Certificate ja Barracuda Load BalancerSSL View Connection Server Barracuda Load Balancer Barracuda Load Balancer Barracuda Load BalancerWeb > 3. Barracuda Load BalancerView Service 4. View Connection ServerSSL Barracuda Load BalancerSSLView Service Barracuda Load Balancer Barracuda Load Balancer 3. HTTPView Connection Server 4. View Administrator Console? /? Barracuda Load BalancerView Connection Server??? View Connection Server Service?

118 Barracuda Load Balancer Administrator's Guide - Page 118 Signed Certificate Barracuda Load BalancerVMware ViewCACA VMware View 5.1: Barracuda Load BalancerSSL View Connection Server View Connection Server View Connection Server Friendly Namevdm View Connection ServerMy ComputerManage > Service and Applications > Services View Connection Server ServiceStartView Connection Server View Connection Servernetstat -anp TCPView Connection ServerView Connection Service443 : VMware View 5.1 Documentation Centerttp://pubs.vmware.com/view-51/topic/com.vmware.view.installation.doc/G UID-80CC770D-327E-4A21-B B23C44.html. Barracuda Load Balancer Barracuda Load Balancer Barracuda Load BalancerWeb > 3. Barracuda Load BalancerView Service SSL/HTTPSView Service > 7-HTTPS a. b. VIPDNSFQDN SSL a. HTTP CookieCookieJSESSIONID b. 0 View Connection Server a. b. View Connection Server c. d. e. View Connection Server SSLHTTPS/SSL CA

119 Barracuda Load Balancer Administrator's Guide - Page View Connection ServerSSL HTTPS/SSLView Connection Server 3. View Administrator ConsoleView ConfigurationServers Connection ServersView Connection Server a. b. c. d. VDI Connection ServerEdit...Edit View Connection Server Settings HTTP(S) Secure TunnelUse Secure Tunnel connection to desktop External URLURLVDIFQDNhttps://<FQDN>:443 PCoIP Secure GatewayUse PCoIP Secure Gateway for PCoIP connections to desktop e. OK VMware View Connection ServiceVIP Barracuda Load BalancerSSLView Service Barracuda Load Balancer Barracuda Load Balancer Barracuda Load BalancerWeb > Barracuda Load Balancer SSL/HTTPSView Service 3. > 7-HTTPS a. b. a. b. VIPDNSFQDN SSL HTTP CookieCookieJSESSIONID 0 4. View Connection Server a. b. View Connection Server c. d. View Connection Server SSLHTTPS/SSL e.

120 Barracuda Load Balancer Administrator's Guide - Page 120 e. CA 3. HTTPView Connection Server HTTPSHTTPVMware View Connection Server View Connection ServerView Connection ServerSecurity ServerSSL gatewaylocked.properties: install_directory\vmware\vmware View\Server\sslgateway\conf\locked.properties ViewserverProtocolhttphttp HTTPView HTTP80serverPortNonSSL ViewView1HTTPserverHostIP Barracuda Load Balancer locked.properties View Connection Server ServiceSecurity Server Service 4. View Administrator Console VMware View Connection Server 3. View Administrator ConsoleView ConfigurationServers Connection ServersView Connection Server VMware View Connection Server a. b. c. d. EditEdit View Connection Server Settings HTTP(S) Secure TunnelUse Secure Tunnel connection to desktop PCoIP Secure GatewayUse PCoIP Secure Gateway for PCoIP connections to desktop OK : HTTPhttp://pubs.vmware.com/view-51/index.jsp?topic=%2Fcom.vmware.view.administration.doc%2FGUID-690C7F60-FA7F-4C35-B9A6-22F2 71AF1DDhtml VMware View Connection ServiceVIP? CA /? Barracuda Load BalancerView Connection ServerView Connection ServerBarracuda Load Balancer VMware View Client Options > Configure SSL Do not verify server identity certificatesok

121 Barracuda Load Balancer Administrator's Guide - Page 121 Barracuda Load BalancerView Connection Server? CNFQDN? CATrusted Root Certification AuthoritiesLOCAL Computer > Trusted Root Certification Authorities? Barracuda Load BalancerVMware View Service View Connection Server Service? View Connection ServerMy ComputerManage > Service and Applications > Services View Connection Server ServiceStartView Connection Server Barracuda Load BalancerWeb > VMware View In the Common Name field, enter the fully qualified domain name (FQDN) which resolves to the VIP address for the VMware View Service. For example, viewvip.localserver.com Enter the Country Code, State or Province, Locality, Organization (Company) Name, Organization (Departmental) Unit fo r your organization. From the Key Size menu, select 2048 Set Expires In to the number of days the generated certificate is to be valid. Set Allow Private Key Export to Yes. <>.pfxpkcs#12

122 Barracuda Load Balancer Administrator's Guide - Page 122 Getting Started Recommended Steps Step 1: How to Install the Barracuda Load Balancer Step 2: How to Configure the Barracuda Load Balancer Step 3: How to Configure the Barracuda Load Balancer Web Interface Step 4: How to Configure the Load Balancer Administrative Settings Step 5: How to Configure the Barracuda Load Balancer Network

123 Barracuda Load Balancer Administrator's Guide - Page 123 Step 1: How to Install the Barracuda Load Balancer Before installation, determine the best type of deployment for your Barracuda Load Balancer; refer to the Deployment section for a list of options. Note that if you choose the virtual machine deployment, only the Barracuda Load Balancer 340 and 440 are supported. Installation instructions are covered in the Virtual Deployment section. Verify Equipment Verify you have the necessary equipment: Barracuda Load Balancer (check that you have received the correct model) AC power cord Ethernet cables Mountain rails and screws VGA monitor (recommended) PS2 keyboard (recommended) Connect to the Network Fasten the Barracuda Load Balancer to a standard 19-inch rack or other stable location. Do not block the cooling vents located on the front and rear of the unit. Connect the Barracuda Load Balancer to your network: a. Connect a CAT5 Ethernet cable from the WAN interface on the Barracuda Load Balancer to the network switch through which the traffic destined to the VIP addresses is to be routed. b. For the Barracuda Load Balancer 240, 340 and 440: Connect a CAT5 Ethernet cable from the LAN interface on the Barracuda Load Balancer to the network switch where the Real Servers reside. If desired, connect a CAT5 Ethernet cable from the Ethernet port on the back of the appliance to the network switch for your management network. c. For the Barracuda Load Balancer 640 only: Connect Port 1 through Port 2 to the Real Servers. Connect a CAT5 Ethernet cable from the MGMT interface on the front of the Barracuda Load Balancer to the network switch for your management network. 3. Connect the following to your Barracuda Load Balancer: Power cord; AC input voltage range is volts at 50/60 Hz VGA monitor PS2 keyboard 4. After you connect the AC power cord, you may hear the fan operate for a few seconds and then power off; this behavior is normal. 5. Press the Power button located on the front of the unit. The administrative console login prompt displays on the monitor, and the power light on the front of the Barracuda Load Balancer turns on. Continue with Step 2: How to Configure the Barracuda Load Balancer.

124 Barracuda Load Balancer Administrator's Guide - Page 124 Step 2: How to Configure the Barracuda Load Balancer Before configuring the IP address and network settings, complete Step 1: How to Install a Barracuda Load Balancer. Configure WAN IP Address and Network Settings The Barracuda Load Balancer is assigned a default WAN IP address of To set a new WAN IP address from the administrative console: Connect your keyboard and monitor directly to the Barracuda Load Balancer. At the barracuda login prompt, enter admin for the login and admin for the password. The User Confirmation Requested window displays the current IP configuration of the Barracuda Load Balancer. Using your Tab key, select Change and press Enter to change the WAN IP configuration. Enter the new WAN IP address, netmask, and default gateway for your Barracuda Load Balancer. Enter the IP address of your primary and secondary DNS servers. Select Save to save your changes, and then select Exit. The new WAN IP address and network settings are applied to your Barracuda Load Balancer. Configure Your Corporate Firewall If your Barracuda Load Balancer is located behind a corporate firewall, refer to the following table for the ports that need to be opened on your corporate firewall to allow communication between the Barracuda Load Balancer virtual IP addresses, and remote servers. Port Direction Protocol Description 22 Out TCP Remote diagnostics and technical support services 53 Out TCP/UDP Domain Name Server (DNS) 80 Out TCP Firmware and Energize updates (unless configured to use a proxy) 123 Out UDP Network Time Protocol (NTP) any ports used by Services as needed as needed 1:1 NATs as needed, and any port required to access the VIP of a load balanced Service To send system alerts and notifications to the administrator, the Barracuda Load Balancer must be able to communicate with the mail server over the port specified on the BASIC > Administration page. This may require opening that port on the firewall. Certain protocols require additional ports to be open. Examples include FTP and streaming media protocols. When configuring Services using these protocols ensure that the additional ports required are not blocked by the firewall. Continue with Step 3: How to Configure the Barracuda Load Balancer Web Interface.

125 Barracuda Load Balancer Administrator's Guide - Page 125 Step 3: How to Configure the Barracuda Load Balancer Web Interface Before configuring the web interface, complete Step 2: How to Configure the Barracuda Load Balancer. In this article: Configure the Barracuda Load Balancer from the Web Interface Subscription Status Update the Barracuda Load Balancer Firmware Update the IPS Definitions Configure the Barracuda Load Balancer from the Web Interface After specifying the IP address of the Barracuda Load Balancer and opening the necessary ports on your corporate firewall, configure the Barracuda Load Balancer from the web interface. Make sure the system being used to access the web interface is connected to the same network as the Barracuda Load Balancer, and that the appropriate routing is in place to allow connection to the Barracuda Load Balancer s IP address via a web browser. To configure administrative settings on the Barracuda Load Balancer: From a web browser, enter followed by the IP address of the Barracuda Load Balancer, followed by the default web Interface 3. HTTP Port (:8000). For example: Log into the administration interface using admin for both the username and password. Go to the BASIC > IP Configuration page and perform the following steps: a. Enter the following information in the WAN IP Configuration section: IP Address. The address associated with the port that connects the Barracuda Load Balancer to the WAN. Subnet Mask. The subnet mask assigned to the WAN interface of the Barracuda Load Balancer. Default Gateway. The default router for network traffic not destined for the local subnet. Allow administration access. Set to Yes if you want to allow administration access using this IP address. The web interface port has a default of 8000 but can be changed on the BASIC > Administration page. b. If the Barracuda Load Balancer is in Bridge-Path mode, or if only Direct Server Return mode is being employed, then go to Step 3c. If you are configuring a passive Barracuda Load Balancer in a cluster, then go to Step 3c. If the system becomes active and if it is in Route-Path mode, it will assume the LAN IP address and netmask that are configured on the originally-active Barracuda Load Balancer. See High Availability Deployment. Enter the following information in the LAN IP Configuration section: LAN IP Address and LAN Netmask. The address that connects the Barracuda Load Balancer to the LAN. This is only used for two-armed Route-Path mode or, if in one-armed Route-Path mode, for management. Allow administration access. Set to Yes if you want to allow administration access using this IP address. The web interface port has a default of 8000 but can be changed on the BASIC > Administration page. c. If desired, enter the following information in the Management IP Configuration section: d. e. f. g. Management IP Address and Management Netmask. The management IP address can be used only for administration access and is optional. It should not be on the same network as either the LAN or WAN IP address. On certain 640 models, it is used by the MGMT port on the front of the unit; on most other models, it is used by the Ethernet port on the back of the appliance. Allow administration access. Set to Yes. The web interface port has a default of 8000 but can be changed on the BA SIC >Administration page. Enter the IP address of your primary and secondary DNS servers. Enter the default hostname and default domain name of the Barracuda Load Balancer. If the Barracuda Load Balancer is behind a proxy server, enter the relevant parameter. Click Save Changes. If you change the IP address that you were using to access your Barracuda Load Balancer, you will be disconnected from the web interface. Use the new IP address to connect and log in again. 4. h. If you want this Barracuda Load Balancer to operate in Bridge-Path mode, and this is not a backup Barracuda Load Balancer in a cluster, click Convert to change the operation form Route-Path to Bridge-Path. Select BASIC > Administration, and perform the following steps: a. b. Assign a new administration password to the Barracuda Load Balancer. Make sure the local time zone is set correctly. Time on the Barracuda Load Balancer is automatically updated via NTP (Network Time Protocol). It requires that port 123 is opened for outbound UDP traffic on your firewall (if the Barracuda Load Balancer is located behind one). It is important that the time zone is set correctly because this information is used to coordinate traffic distribution and in all logs and reports. Also, if this system is going to be clustered with another one, both systems must have the same time zone. c.

126 Barracuda Load Balancer Administrator's Guide - Page 126 c. d. e. f. If desired, change the port number used to access the Barracuda Load Balancer user interface. The default port is Enter the amount of time, in minutes, for the length of your web interface session before you are logged off due to inactivity. (Optional) Specify your local SMTP server. Enter the address for your administrator to receive system alerts and notifications Click Save Changes. Subscription Status the Barracuda Load Balancer has access to the activation servers, your Energize Update and Instant Replacement subscriptions are most likely active. If not, you will see a warning at the top of every page. You must activate your subscriptions before continuing. Click on the link in the warning message or use the link on the BASIC > Status page to open up the Barracuda Networks Product Activation page in a new browser window. Fill in the required fields and click Activate. A confirmation page displays the terms of your subscription. On the BASIC > Status page, you may need to enter the activation code from the Barracuda Networks Product Activation page to activate your Barracuda Load Balancer. If your subscription status does not change to, or if you have trouble filling out the page, contact your Current Product Activation Barracuda Networks sales representative. Update the Barracuda Load Balancer Firmware Use the following steps to update the firmware: 3. Go to the ADVANCED > Firmware Update page. Read the release notes to learn about the latest features and fixes in the new firmware version. Click Download Now next to Latest General Release. Click OK on the download duration window. Updating the firmware may take several minutes. Do not turn off the unit during this process. Download Now is disabled if the Barracuda Load Balancer is running the latest firmware version. 4. The Barracuda Load Balancer begins downloading the latest firmware version. Click Refresh to view the download status, until you see a message stating that the download has completed. 5. Click Apply Now when the download completes. 6. Click OK when prompted to reboot the Barracuda Load Balancer. A Status page displays the progress of the reboot. Once complete, the login page appears. Update the IPS Definitions If you are configuring a passive Barracuda Load Balancer in a cluster, then you may skip this set of steps. To apply the newest definitions for the Intrusion Prevention System: Select ADVANCED > Energize Updates. Select Hourly or Daily for Automatically Update. The recommended setting is Hourly for IPS definitions. Check to see if the current version is the same as the latest general release. If the rules are up-to-date, proceed to the next section. If the rules are not up-to-date, continue to the next step. Click Update to download and install the latest available IPS definitions onto the Barracuda Load Balancer. Click Save Changes. Continue with Step 4: How to Configure Administrative Settings.

127 Barracuda Load Balancer Administrator's Guide - Page 127 Step 4: How to Configure the Load Balancer Administrative Settings Before configuring administrative settings, complete Step 3: How to Configure the Web Interface. Control Access to the Administration Interface The BASIC > Administration page is where you perform the following tasks related to web interface access for the Barracuda Load Balancer: Change the password of the administration account admin. Change the port used to access the Barracuda Load Balancer web interface. Change the length of time after which idle users are to be logged out of the web interface (the default value is 20 minutes). Specify the IP addresses or netmask of the systems that can access the web administration interface. Attempts to log in as other systems are denied. admin from Use the BASIC > IP Configuration page to allow or deny access to the web interface from the WAN and LAN IP addresses, and, optionally, to configure a management IP address. Set the System Time Zone You can set the time zone of your Barracuda Load Balancer from the BASIC > Administration page. The current time on the system is automatically updated via Network Time Protocol (NTP). When the Barracuda Load Balancer resides behind a firewall, NTP requires port 123 to be opened for outbound UDP traffic. It is important that the time zone is set correctly because this information is used to coordinate traffic distribution and in all logs and reports. The Barracuda Load Balancer automatically reboots when you change the time zone. Customize the Web Interface Appearance The ADVANCED > Appearance page allows you to customize the default images used on the web interface. This tab is available only on the Barracuda Load Balancer 440 and above. Enable SSL for Administrators and Users The ADVANCED > Secure Administration page allows you to configure SSL for the web interface for your Barracuda Load Balancer. SSL not only ensures that your passwords are encrypted, but also ensures that all data transmitted to, and received from, the web interface is encrypted. You can require HTTPS to be used for secure access, and specify the certificate to be used. The SSL configuration referred to here is related only to the web interface. To enable SSL offloading for a Service, refer to SSL Offloading. In order to only allow secured connections when accessing the web interface, you need to supply a digital SSL certificate which will be stored on the Barracuda Load Balancer. This certificate is used as part of the connection process between client and server (in this case, a browser and the web interface on the Barracuda Load Balancer). The certificate contains the server name, the trusted certificate authority, and the server s public encryption key. The SSL certificate which you supply may be either private or trusted. A private, or self-signed, certificate provides strong encryption without the cost of purchasing a certificate from a trusted certificate authority (CA). However, the client web browser will be unable to verify the authenticity of the certificate and a warning will be sent about the unverified certificate. To avoid this warning, download the Private Root Certificate and import it into each browser that accesses the Barracuda Load Balancer web interface. You may create your own private certificate using the ADVANCED > Secure Administration page. You may also use the default pre-loaded Barracuda Networks certificate. The client web browser will display a warning because the hostname of this certificate is barracuda.barracudanetworks.com and it is not a trusted certificate. Access to the web interface using the default certificate may be less secure. However, this certificate can be used for SMTP over TLS, so any mail messages sent by the Barracuda Load Balancer will be secure. A trusted certificate is a certificate signed by a trusted certificate authority (CA). The benefit of this certificate type is that the signed certificate is recognized by the browser as trusted, thus preventing the need for manual download of the Private Root Certificate. Continue with Step 5: How to Configure the Barracuda Load Balancer Network.

128 Barracuda Load Balancer Administrator's Guide - Page 128 Step 5: How to Configure the Barracuda Load Balancer Network Before configuring administrative settings, complete Step 4: How to Configure the Load Balancer Administrative Settings. In this article: Modify LAN and WAN IP Addresses VLAN Support Route to Multiple VLANs over an Interface Make Services Accessible from the LAN/WAN Create Static Routes Allow Real Servers to Connect to the Internet Modify LAN and WAN IP Addresses The BASIC > IP Configuration page contains the basic network configuration for your Barracuda Load Balancer. This page also contains the setting to specify whether this Barracuda Load Balancer operates in Route-Path or Bridge-Path mode. Finally, if the Barracuda Load Balancer is behind a proxy server, you can configure its location so that it can download firmware and Energize Updates VLAN Support The Barracuda Load Balancer supports Layer 2 VLANs to segment traffic. Use the ADVANCED > Advanced Networking page to identify VLANs on the Barracuda Load Balancer. You can then associate Services or Real Servers with VLANs. In Bridge-Path mode, if VLANs are used, both the LAN and WAN ports must be on the same VLAN. To associate a Real Server with a VLAN: On the ADVANCED > Advanced Networking page, create an entry for the VLAN using the VLAN Configuration table. Go to the Basic > Services page and add the Real Server. On the ADVANCED > Advanced Networking page, in the Custom Virtual Interfaces table, create an interface for the Real Server. On the ADVANCED > Advanced Networking page, add a static route to the Real Server if necessary. To associate a Service with a VLAN: On the ADVANCED > Advanced Networking page, create an entry for the VLAN using the VLAN Configuration table. Go to the BASIC > Services page and add the Service. On the ADVANCED > Advanced IP Config page, in the System Virtual Interfaces table, locate the entry for the Service. Select the VLAN from the Port list and save your changes. Route to Multiple VLANs over an Interface If any interface on the Barracuda Load Balancer has to route to multiple VLANs, it must be connected to the VLAN switch via a trunk (or hybrid) link, since multiple VLAN traffic can only be transported over trunk links. If the Real Servers are distributed across multiple VLANs, say 100, 105, and 111, then the LAN port must be connected to a trunk port on the VLAN switch. Make Services Accessible from the LAN/WAN You can add virtual interface(s) to the physical port (WAN or LAN) used to communicate with the Services. To make a Service accessible from the LAN: Go to the BASIC > Services page and add the Service. On the ADVANCED > Advanced Networking page, in the System Virtual Interfaces table, locate the entry for the Service. Select LAN from the Port list and save your changes. To access the Service from the WAN, create another Service with a different VIP but the same Real Servers. Create Static Routes You can create static routes to specify the exact route to a remote network. To add a static route: On the ADVANCED > Advanced Networking page, create an entry for the VLAN using the VLAN Configuration table, if necessary. On the same page, fill in the fields in the Static Routes table. Allow Real Servers to Connect to the Internet If the Real Servers are on a private network on the LAN side of the Barracuda Load Balancer and the WAN is on a public network, Real Servers

129 Barracuda Load Balancer Administrator's Guide - Page 129 are not allowed by default to connect to the Internet. You can override this behavior if, for example, the Real Servers need to get operating system or application updates. This option is available in both Route-Path and Bridge-Path mode. To allow Real Servers to connect directly to the Internet: On the ADVANCED > Advanced Networking page, create a source network address translation (source NAT) rule to map the internal IP address of a Real Server to an external IP address or some other IP address on the WAN side of the Barracuda Load Balancer that is translated by the firewall to an external IP address. See Specifying Source IP Address in a Clustered Environment for information about the source IP address of incoming traffic.

130 Barracuda Load Balancer Administrator's Guide - Page 130 Services A Service is a combination of a Virtual IP (VIP) address and one or more TCP/UDP ports. Traffic arriving at the designated port(s) for the specified Virtual IP address is directed to one of the Real Servers associated with that particular Service. The Barracuda Load Balancer determines which connections or requests are distributed to each Real Server based on the scheduling policy selected for the Service. In this Section Services Overview How to Associate Real Servers with a Service Monitoring Services and Real Server Health Persistence Settings Remote Desktop Services Load Balancing TCP Proxy, Secure TCP Proxy, and UDP Proxy FTP Service and FTPS Service Layer 7 HTTP(S) Services How to Configure SSL Offloading How to Secure Communication with Real Servers How to Select a Scheduling Policy Understanding Intrusion Prevention How to Configure Intrusion Prevention How to Configure a Last Resort Action Client Impersonation

131 Barracuda Load Balancer Administrator's Guide - Page 131 Services Overview In this article: Basic View Advanced View Port Settings Configuring a Service Basic View HTTP Redirect Service Content Rules for a Layer 7 - HTTP Service Configure a Real Server Service Status Real Server Status A Service is a combination of a Virtual IP (VIP) address and one or more TCP/UDP ports. Traffic arriving at the designated port(s) for the specified Virtual IP address is directed to one of the Real Servers that are associated with that particular Service. The Barracuda Load Balancer determines which connections or requests are distributed to each Real Server based on the scheduling policy selected for the Service. The BASIC > Services page lets you create Services by identifying a Virtual IP address, port and one or more Real Servers. Once you have created a Service, you can configure advanced settings (including Service type) by clicking the Edit icon next to the Service. If the creation of the Service is successful, the Service name appears on the BASIC > Services page with a green, orange, or red health indicator next to it. You can select either the Basic or Advanced view when adding a Service. The Advanced option allows you to configure more parameters (including Service Type) when adding a Service. Once the Service is added, you can change its settings by clicking Edit in the table. on the Service entry Basic View You have two options for creating a new Service in the Basic view. Option 1: or Option 2: Enter the Service Name and Virtual IP address. In the protocol list click TCP or UDP. Enter the TCP/UDP port that the Service will listen on. This may be any TCP port or, if this is a Layer 4 Service, ALL for all ports. Enter the IP address(es) of the Real Servers that will perform the actual function(s) for this Service. Click Add. Click Auto-Discover. Auto-Discover displays another dialog which presents a list of all servers that are currently available and responding to this Barracuda Load Balancer. You can fill in the same fields as above to create a new Service. Advanced View Use the following steps to create a new Service in the Advanced view. Enter the Service Name and select the Service Type. Enter the Virtual IP address. Enter the TCP/UDP port that the Service will listen on. This may be any TCP port or, if this is a Layer 4 Service, ALL for all ports. If this is a secure Service (e.g. type Secure TCP Proxy, Layer 7 - HTTPS, Layer 7 - FTPS), select the SSL certificate that is to be used to 3. decrypt the incoming traffic. Add certificates using the Basic > Certificates page. 4. Select the interface from the dropdown. Interfaces can be configured on the Advanced > Advanced IP Config page. 5. Enter the IP address(es) of the Real Servers that will perform the actual function(s) for this Service and click the + button. Click Add Service when the list is done. or: Click Auto-Discover to display a dialog that presents a list of all servers that are currently available and responding to this Barracuda Load Balancer. Select the Real Servers for this Service and click Add Service. Port Settings If the port for a Service is set to ALL, then traffic received by a port on that Service is directed to the corresponding port on the Real Server. However, you may want the Service to listen on a different port than the port used to communicate with the Real Server. As long as the port for a Service is a numeric value, you can change the port used to receive traffic on the Real Server by clicking the Edit icon next to the Real Server. As an example, a Service that supports HTTPS may listen on port 443. If you choose SSL offloading for this Service, you may want the Real Servers to use port 80 to receive the unencrypted traffic.

132 Barracuda Load Balancer Administrator's Guide - Page 132 Configuring a Service There are many additional settings associated with a Service; click the Edit icon on the Service entry in the table to view and modify these settings, including: Service name and type Last Resort Server Scheduling policy Service monitor Persistence Settings Content rules SSL offloading Notifications if number of functioning Real Servers drops below threshold Intrusion Prevention Service Inbound firewall rules Basic View To create any Service that is not Layer 4 (Basic View): Follow the steps above to add a Service, but make sure that the Port is not set to ALL. 3. Once the Service is created, click Edit next to that Service. In the Service Detail page, set the Service Type to the desired type and save your changes. HTTP Redirect Service You can make a Layer 7 - HTTP Service be a HTTP Redirect Service. This causes all traffic to the port for the Service to be redirected to port 443 (or the specified port) on the same Virtual IP address. Click Enable HTTP Redirect when you edit the Layer 7 - HTTP Service. Be sure to create the Service to handle the redirected traffic. Content Rules for a Layer 7 - HTTP Service Use the following steps to create content rules for a Layer 7 - HTTP Service: Add a least one Real Server to a Layer 7 - HTTP or HTTPS Service. Rule will appear in the Add column of the Service entry. Click Rule to create rules to direct traffic to Real Servers based on content of the traffic. Configure a Real Server There are several settings associated with a Real Server. To make changes to any of the following settings, click Edit for the Real Server: Name Port - can be changed only if the Service port setting is not ALL Weight Status - enabled or not Content rules Direct Server Return Health testing method SSL certificate Service Status Following is the list of Service status indicators: - The Service is up and all Real Servers are responding to requests. - The Service is up, but at least one Real Server is not responding. - The Service is down. No Real Servers are responding. A Real Server may not respond because it was removed from the Service by an administrator or because of a system failure. Real Server Status Following is the list of Service status indicators: - The Real Server is up and responding to requests.

133 Barracuda Load Balancer Administrator's Guide - Page The Real Server is not enabled; click the Edit icon to change its status. - The Real Server is not responding but its state is enabled.

134 Barracuda Load Balancer Administrator's Guide - Page 134 How to Associate Real Servers with a Service You can identify the Real Servers that handle the traffic for a Service when you create the Service or later, using the BASIC > Services page. Edit advanced Real Server settings by clicking the Edit graphic next to the Real Server. From this page, you can: Enable the Real Server or disable it in one of two ways. Disabled mode terminates all existing connections immediately. Maintenance mode allows existing connections to terminate naturally. In either case, no new connections or request are accepted until the Real Server is enabled again. If this Real Server is associated with a Layer 7 - HTTP Service, specify whether this Real Server accepts only HTTP requests that match a content rule. Change the weight of this Real Server to be used when assigning client connections. Specify if the Real Server is using Direct Server Return. Require all communication between the Real Server and the Barracuda Load Balancer be encrypted using SSL. Change or execute the Testing Method for the Real Server. Related Articles Services How to Configure Adaptive Scheduling Understanding Testing Methods for Services and Real Servers

135 Barracuda Load Balancer Administrator's Guide - Page 135 Monitoring Services and Real Server Health Service Monitor The Service Monitor checks the health of each Service and Real Server on an ongoing basis. Specify which test to perform and how frequently to do the test by editing the Service or Real Server on the BASIC > Services page. The BASIC > Services and BASIC > Server Health pages display the health of all load-balanced Services and associated Real Servers. There are many different methods available to establish the availability of a Service or Real Server. These include TCP port check, HTTP GET request, DNS query and RADIUS test. The various tests are fully documented in the online help. The tests always use the configured Real Server port for the Service unless the Real Server port is set to ALL. In that case, the tests use the default port for the test type (e.g. SMTP = 25, HTTP = 80, DNS = 53, HTTPS = 443, IMAP = 143, POP = 110 and SNMP = 161). If a Real Server is associated with more than one Service, but with the same test and test interval for each Service, it will be tested once per test interval. Otherwise, it may be checked more frequently. Unless the tests are identical, the Service Monitor performs its health checks for each Service s set of Real Servers independently. Monitor Groups Monitor groups are sets of tests that are conducted on Real Servers. Use them when one test does not give a complete picture of the health of a Real Server. You can specify a monitoring group with two or more tests and the Service Monitor will perform all the tests in the group. The failure of any one test means the Real Server is considered to be unavailable and it will be removed from the load-balancing pool. Create monitor groups that contain one or more tests on the ADVANCED > Monitor Groups page. Then edit the Real Server or Service. The monitor groups appear in the Testing Methods for the Service Detail or Real Server Detail page. Related Articles Monitoring How to Create Monitor Groups Understanding Testing Methods for Services and Real Servers Remote Desktop Services in Windows Server 2008 R1 or R2 Deployment

136 Barracuda Load Balancer Administrator's Guide - Page 136 Persistence Settings The Barracuda Load Balancer supports multiple options to direct clients back to the same Real Server, depending on the Service type. Layer 7 - HTTP(S) There are a variety of supported persistence methods for HTTP sessions: HTTP Cookie - When a client initiates contact, the Barracuda Load Balancer inserts a cookie into the outgoing response. This cookie is returned by the client with each subsequent request. The Barracuda Load Balancer strips the cookie from the request and then directs the request to the same Real Server. Client IP Address - Subsequent requests from a client with a recurring IP address or systems from the same subnet go to the same Real Server. HTTP Header - All incoming HTTP requests are directed to the same Real Server based on the value of a header. The application (e.g., Microsoft Exchange) specifies the name of the header to be examined. URL Parameter - All incoming HTTP requests are directed to the same Real Server based on the value of the specified parameter in the URL. Layer 4 -TCP, TCP Proxy, Secure TCP Proxy or Layer 4 - UDP Only client IP address persistence is supported. An individual client IP address can be used or you can specify a subnet mask so that subsequent TCP connections or UDP datagrams from systems from the same subnet go to the same Real Server. UDP Proxy A UDP Proxy Service supports persistence using both client IP address and port to distribute the traffic across all of the Real Servers. This helps mitigate the fact that many UDP applications involve all client requests coming from one client IP address. Layer 7 - FTP(S) Persistence is not supported. Layer 7 - RDP Session persistence is achieved by querying Windows Server 2003 Terminal Services Session Directory, Windows Server 2008 Terminal Services Session Broker or Windows Server 2008 R2 Session Broker. See Remote Desktop Services Load Balancing.

137 Barracuda Load Balancer Administrator's Guide - Page 137 Remote Desktop Services Load Balancing The Barracuda Load Balancer may be deployed with a Terminal Server farm that is using Windows Server 2003 Terminal Services, Windows Server 2008 Terminal Services or Windows Server 2008 R2 Remote Desktop Services. The Barracuda Load Balancer uses the routing token supplied by the Session Director or the TS Session Broker to determine which Real Server to use. There are settings that need to be configured on the Real Servers to allow the Barracuda Load Balancer to use the routing tokens. Related Articles Services Remote Desktop Services in Windows Server 2008 R1 or R2 Deployment

138 Barracuda Load Balancer Administrator's Guide - Page 138 TCP Proxy, Secure TCP Proxy, and UDP Proxy You can create a TCP Proxy Service, a Secure TCP Proxy Service or a UDP Proxy Service to make the Barracuda Load Balancer act as a full TCP or UDP proxy. Using these Service types allows the Real Servers to be located anywhere, as long as they are reachable by the Barracuda Load Balancer. See Deployment Options for examples of deployments using TCP and UDP Proxy Services. A Secure TCP Proxy Service provides SSL offloading. Related Articles Services Route-Path Configured with TCP Proxy, UDP Proxy, or a Layer 7 Service Type

139 Barracuda Load Balancer Administrator's Guide - Page 139 FTP Service and FTPS Service FTP Service You can create a Service with type Layer 7 - FTP to allow the Barracuda Load Balancer to process FTP traffic from the clients to the servers. An FTP client connects to an FTP server to manipulate files on that server. Both passive and active FTP are supported. If passive FTP is to be used, and if the Barracuda Load Balancer is behind a NAT ing firewall, you should specify an IP address and one or more ports that are sent in the response to a PASV request from a client. The client connects to the specified IP address and port to receive the data. Usually this address is the external IP address that is translated by the firewall to the Virtual IP address of the FTP Service. The port or ports are those allowed by the firewall. Enter the IP address and port(s) on the Service Detail page. FTPS Service A Service with type Layer 7 - FTPS supports encrypted FTP traffic. It only supports passive and not active FTP.

140 Barracuda Load Balancer Administrator's Guide - Page 140 Layer 7 HTTP(S) Services In this article: Introduction Direct HTTP Requests Based on Content Rules Content Rule Execution Content Rule Caching and Compression Setting Up an HTTP Redirect Modify HTTP Requests and Responses Rule Execution Order Configure Caching Configure Compression Host Multiple Domains with one Service Server Name Indication (SNI) Wildcard Certificates Subject Alternative Name (SAN) Certificates Introduction HTTP or HTTPS traffic can be handled to a varying degree by the Barracuda Load Balancer before it is directed to a web server. The handling differs based on the type of the Service that receives the traffic. Choose a Layer 4 - TCP Service type if you want the traffic simply redirected to the web servers and using only client IP based persistence. This requires a two-armed deployment. If you only need client IP based persistence but want to use a one-armed deployment, choose a TCP Proxy Service type. To take advantage of Layer 7 handling such as directing requests based on content rules, inspecting and modifying HTTP headers, SSL offloading, or persistence based on cookies, choose either Layer 7 - HTTP (for HTTP traffic) or Layer 7 - HTTPS (for HTTPS traffic). The rest of this section describes the Layer 7 processing options. Direct HTTP Requests Based on Content Rules Content rules are used to direct HTTP requests to specific Real Servers associated with a Layer 7 - HTTP(S) Service. This functionality is also known as content switching or URL switching. A content rule includes: One or more expressions that specify a pattern in the host, URL or header fields of the request The Real Server or Servers that handle the matching request The load balancing algorithm used to direct requests to the Real Servers Persistence: none, HTTP cookie, HTTP header, URL parameter or client IP address Use these rules to partition requests to Real Servers that deliver different types of data, such as: Content optimized for a mobile device Content in a particular language Images or video Data that is maintained on different servers but you want to make it appear to have come from one source. Create a content rule by clicking Rule next to a Layer 7 - HTTP(S) Service on the BASIC > Services page. This option only appears next to a Service that has at least one Real Server associated with it. Click on the Edit icon next to the rule name on the BASIC > Services to edit an existing content rule. You can edit one or more Real Servers from the BASIC > Services page to accept only HTTP requests that match a content rule. Requests that fail to match any rule are directed to the Real Servers for the Service that are not configured to exclusively handle requests that match a content rule. For example, a Real Server which only delivers images can be configured to accept only HTTP requests that match a content rule. Content Rule Execution There are up to three types of patterns in each content rule: host match, URL match, and extended match. Extended matches are compared to values in the HTTP header. If there are multiple rules for a Service, the most specific host and URL match will be executed. For example, if a Service has these two rules: Rule A - host URL /images/* Rule B - host URL /images/*.png and if the incoming request is for then the most specific matching rule, which is Rule B, is executed. If a rule has the most specific host and URL for a request, any extended match expressions for that rule are evaluated in the order established by

141 Barracuda Load Balancer Administrator's Guide - Page 141 the Extended Match Order field. If the request does not match any extended match expression for the rule then the request is considered to have failed to match any rule. The possible values for the content rules can be found in the online help. A detailed description of the extended match syntax can be found in Ho w to Use Extended Match and Condition Expressions. Content Rule Caching and Compression You can enable caching and compression on the data that matches a content rule using the WEBSITES > HTTP Caching and the WEBSITES > HTTP Compression pages. Setting Up an HTTP Redirect HTTP redirect causes all HTTP traffic on the specified port on a virtual IP address to be redirected to another port (usually port 443) on the same virtual IP address, where SSL requests are served. Implementing HTTP redirect requires configuring two Services, an HTTP redirect Service and an HTTPS Service. HTTP requests that are addressed to are redirected to e_port/. This is useful when a site supports only HTTPS access. A client may initially access the site using HTTP, which is the default for most browsers if the URI scheme is not entered. The redirect option allows the client to be transparently moved over to the secure site. To enable the redirect, create an HTTP redirect Service with Service type of Layer 7 - HTTP. Edit the Service and enable HTTP redirect. Because this Service only redirects HTTP requests to an HTTPS Service (the one at the redirect port), you cannot add Real Servers. In fact, few configuration options on the Service Detail page are relevant, and all of the other options are hidden (and the settings, if any, ignored). Finally, you need to create a Layer 7 - HTTPS Service for the same VIP address on the redirect port to receive the redirected requests. Modify HTTP Requests and Responses You can set up rules to modify HTTP requests and responses that pass through the Barracuda Load Balancer. These rules, which are associated with a Layer 7 - HTTP(S) Service, are listed on the WEBSITES > URL Rewrites page. One HTTP request rewrite rule is created automatically. It sets the X-Forwarded-For header to the IP address of the client. The Real Server can examine the X-Forwarded-For header to discover the true identity of the requestor, rather than using the sending IP address, which is the IP address of the Barracuda Load Balancer. You can create response rewrite rules to remove server banners or other header or body information which you do not want the clients to see. The actions which can be performed by the request rewrite rules are: Insert Header - Inserts a header in the request. Remove Header - Removes the header from the request. Rewrite Header - Rewrites the value of the header in the request Rewrite URL - Rewrites the request URL to the URL specified in the rule. Redirect the URL - Redirects the request to the URL specified in the rule and sends that redirect back to the client. Only the first three actions are valid for response header rewrite rules. Response body rules allow any text string (content-type must begin with text/) in an outbound HTTP response body to be rewritten. The online help for the WEBSITES > URL Rewrites page lists the syntax for the rules. In addition, a detailed description of the condition expressions, which specify when the rewrite should occur, is found in Extended Match and Condition Expressions. Rule Execution Order Content rules are evaluated first on incoming HTTP traffic. The rules on the WEBSITES > URL Rewrites page are evaluated second. Configure Caching Caching is a process of storing commonly used information in local memory for quick retrieval rather than sending repeated requests to the web server for the same information. This can improve performance (sometimes dramatically) and reliability. It also reduces the resource utilization on the web servers. Caching can store web pages and commonly used objects such as graphics files. Caching provides the following benefits: Reduced latency when retrieving web content. An overall reduction in bandwidth and server load. Automatic identification and replication of site content. By default, caching is disabled, but you can enable caching on any Layer 7 - HTTP(S) Service or content rule on the WEBSITES > HTTP Caching page. For each Service or content rule you can specify a set of parameters that determine what is cached. Configure Compression Compression improves the response time for clients accessing the service through dial-up or other slow methods. Enabling this feature

142 Barracuda Load Balancer Administrator's Guide - Page 142 compresses web pages that use HTML, JavaScript, Java and other text-based languages, resulting in a reduction in download time. By default, compression is disabled, but you can enable compression on any Layer 7 - HTTP(S) Service or content rule on the WEBSITES > HTTP Compression page. For each Service or content rule you can specify the content types and minimum response size to be compressed. Barracuda Networks recommends enabling compression for text based content-types like text/plain, text/html, etc. Host Multiple Domains with one Service Hosting multiple SSL-enabled sites on a single server usually requires a unique IP address for each domain, but the Barracuda Load Balancer supports three alternative ways to host multiple domains on one Service. This is particularly useful in a virtual hosting scenario, where you may have several domains hosted on a single Real Server, using the same IP address. These methods are: Server Name Indication (SNI) Wildcard certificates Subject Alternative Name (SAN) certificates Server Name Indication (SNI) SNI extends the SSL/TLS protocol to solve the issue of hosting multiple domains on the same IP address. If each domain has a distinct SSL certificate, there needs to be a way for the Real Server to select the proper certificate for a particular domain. The virtual domain information is sent as part of the SSL/TLS negotiation between the client and server. Clients supporting this extension send the domain name when initializing a secure SSL session. The server side component will look at the domain name and send the corresponding certificate to the client. For SNI to work properly, both the client browser and the web servers must support the SNI extension. SNI is already supported on most major browser platforms, and on both Apache and IIS. With SNI, you can use the Barracuda Load Balancer to assign any number and any type of certificates (single, wildcard or SAN) to a single Barracuda Load Balancer Service. SNI support applies only to Services with type Layer 7 - HTTPS. To enable SNI, edit the Service and change the setting on the Service Detail page. On the same page, you can enter multiple domain names and associate a certificate with each one. Client requests for domains that are not associated with any certificate will get the default certificate. You can add as many certificates to the Service as needed. Wildcard Certificates Another alternative is to use wildcard certificates. This allows you to use a single certificate for sub-domains within a domain. If you use a wildcard certificate, you only have to set up a single Service on the Barracuda Load Balancer to serve multiple sub-domains. For example, you can configure a single Layer 7 - HTTPS Service using a wildcard certificate, such as *.example.com, for or upport.example.com. On the negative side, wildcard certificates: Are more expensive (typically 3-5x more expensive than single domain certificates). Cannot support multi-domains that are distinct from each other, such as and Multi-domain support is especially critical for web hosting providers or Managed Service Providers (MSP) who may have multiple virtual web servers representing numerous domains on a single physical server using a single IP address. Cannot secure host names on different base domains, such as and Subject Alternative Name (SAN) Certificates SAN certificates fall between a wildcard certificate and a single domain certificate, as each certificate allows you to specify a list of domain names to be protected. A SAN certificate for could have the domains and listed as alternative names for the same Service. On the negative side, SAN certificates are more expensive than single domain certificates and are often limited to 3-5 domains. More importantly, not all Certificate Authorities sell SAN enabled certificates. Related Articles Services Route-Path Deployment Two-Armed Route-Path Deployment One-Armed Route-Path Deployment

143 Barracuda Load Balancer Administrator's Guide - Page 143 How to Configure SSL Offloading The Barracuda Load Balancer can perform decryption and encryption of SSL traffic to reduce the load on the Real Servers. The encrypted traffic received on the VIP address is decrypted before it is passed to the Real Servers, and traffic coming from the Real Servers is encrypted before it leaves the Barracuda Load Balancer. No SSL configuration on the Real Servers is necessary; all SSL certificates are stored on the Barracuda Load Balancer. If the Barracuda Load Balancers and the Real Servers are on a trusted network, such as within the same datacenter, enabling SSL offloading does not compromise security. If this is not the case, the Barracuda Load Balancer can re-encrypt the traffic before directing it to the Real Servers. SSL offloading is not compatible with Direct Server Return. It is also not available for Layer 4, UDP Proxy or Layer 7 - RDP Service types. To set up SSL offloading, complete the following tasks: 3. Upload one SSL certificate for each Service to the Barracuda Load Balancer. Identify the Services that are using SSL offloading as secure Service types. Change the port used by the Real Servers, if necessary. Upload SSL Certificates One SSL certificate for each Service to be offloaded must be stored on the Barracuda Load Balancer. A certificate can be ordered from a trusted Certificate Authority such as VeriSign. Or, if SSL processing was previously done on the server, then retrieve the certificate from that server. To view, edit or add SSL certificates to the Barracuda Load Balancer, go to the BASIC > Certificates page. Specify SSL Offloading for a Service To configure SSL offloading for a Service, go to the BASIC > Services page and edit the Service. On the Service Detail page, change the Service type to the secure Service type (e.g., TCP Proxy to Secure TCP Proxy). Select the SSL certificate you wish to use from the SSL Certificate list. Update Ports on the Real Servers If the Real Servers were using port 443 before, update their port setting on the Barracuda Load Balancer. Go to BASIC > Services page and click Edit for each Real Server for the Service. On the Real Server Detail page update the port. For example, the Service may use port 443 while the Real Servers use port 80.

144 Barracuda Load Balancer Administrator's Guide - Page 144 How to Secure Communication with Real Servers If you want all communication between the Real Servers and the Barracuda Load Balancer to be encrypted using SSL, you can configure this option by editing each Real Server on the BASIC > Services page. An SSL certificate must exist on the Real Server. Related Articles How to Enable or Disable Real Servers How to Monitor Services and Real Server Health

145 Barracuda Load Balancer Administrator's Guide - Page 145 How to Select a Scheduling Policy In this article: Adaptive Scheduling Pre-Assigned Weight Scheduling Policies Scheduling for a Service with type Layer 7 - RDP Viewing Current Connections The Barracuda Load Balancer supports multiple scheduling methods to determine which Real Server that is associated with a Service gets the next new connection. On an ongoing basis each Real Server is assigned a weight, which indicates the proportion of the load that this Real Server will bear relative to other Real Servers. Weights are either calculated dynamically using Adaptive Scheduling, or they are pre-assigned. These Real Server weights are then used by the scheduling algorithm, which is either Weighted Round-Robin or Weighted Least Connections, to determine which Real Server gets the next connection. Adaptive Scheduling The Adaptive Scheduling feature polls the Real Servers frequently and assigns weights to those Real Servers using the information gathered. The parameter polled may be: CPU Load, determined by an SNMP query. If you wish to use this and you have Real Servers running a version of Windows, refer to Ho w to Configure Adaptive Scheduling. Number of Windows Terminal Server sessions, determined by an SNMP query. In order to use this option, Real Servers must allow the Barracuda Load Balancer SNMP access to the community specified in the SNMP Community String box. This option is not available if the Service type is Layer 7 - RDP (see Scheduling for a Service with type Layer 7 - RDP on page 48). A URL provided by each Real Server which specifies a load value. If this option is selected, the Barracuda Load Balancer will poll the URL Server IP Address]/barracuda_load/ and expect the output to look like LOAD=23 (showing the load as an integer between 0 and 100). Weights are assigned to each Real Server using the formula (100LOAD). For example, if the Load URL value is 23, the Real Server is assigned a weight of 77. In order for the URL query to work, you must create a load determination script and make the results available by running a web server on the Real Server that responds to the poll at the Real Server s IP address and port 80. If, for example, all Real Servers have the same value for CPU load, then the Real Servers will be assigned the same weight. These weights will change as the value of the CPU Load for each Real Server varies. Configure adaptive scheduling for a Service by editing it using the BASIC > Services page. On the Service Detail page, select the adaptive scheduling algorithm to use when making weight adjustments. Pre-Assigned Weight As an alternative to adaptive scheduling, static weights for each Real Server can be used. If some of the Real Servers are faster or have more capacity than others, you can tell the Barracuda Load Balancer to direct more traffic to them by increasing their weight relative to the other Real Servers. Configure the static weight for a Real Server by editing it on the BASIC > Services page. On the Real Server Detail page, enter a weight value to be compared against the weights of all other Real Servers for this Service. For example, a Real Server with a weight of 50 will get half the amount of traffic as a Real Server with a weight of 100, but will get twice that of a Real Server with a weight of 25. If the Service is configured to use adaptive scheduling, these static weight values are ignored. Scheduling Policies The Barracuda Load Balancer considers the weight values for the Real Servers and then applies a scheduling algorithm, either Weighted Round-Robin or Weighted Least Connections, to determine which Real Server gets the next connection. In Weighted Round-Robin, Real Servers with higher weights get more connections than those with lower weights and Real Servers with equal weights get equal connections. The scheduling sequence is generated according to the Real Server weights. New connections are directed to the different Real Servers based on the scheduling sequence in a round-robin manner. The shortcoming with this method is that a majority of long-lived connections may go to the same Real Server. In Weighted Least Connections, the Barracuda Load Balancer considers the number of live connections that each Real Server has, as well as the weight values. The Real Servers with higher weight values will receive a larger percentage of live connections at any one time. The Barracuda Load Balancer dynamically checks the number of live connections for each Real Server. Weighted Least Connections is the recommended choice. To configure whether Weighted Round-Robin or Weighted Least Connections will be used for a Service, edit the Service on the BASIC >

146 Barracuda Load Balancer Administrator's Guide - Page 146 Services page. Scheduling for a Service with type Layer 7 - RDP If the Service type is Layer 7 - RDP, the Barracuda Load Balancer keeps track of the number of RDP sessions on each Real Server. This number is used in conjunction with Real Server weights when selecting which Real Server gets the next new session. The Real Server weights are determined by either one of these adaptive scheduling methods: Executing an SNMP GET for the CPU load on the Real Servers; Polling a URL provided by each Real Server which specifies a load value; or by retrieving pre-configured static weights (from the Real Server Detail page). The number of active RDP sessions and the Real Server weights are used as input to the Weighted Round Robin or Weighted Least Connections algorithm. On the Service Detail page the Terminal Sessions adaptive scheduling option is disabled for Layer 7 - RDP Services. Because the number of RDP sessions on each Real Server is maintained internally, there is no need for the adaptive scheduling algorithm to issue an SNMP query to get the number of active Windows Terminal Sessions. Viewing Current Connections To see the number of current open connections/requests/sessions with each Service and each Real Server, navigate to the BASIC > Server Health page. The bars on the page display the approximate percentage of all traffic that is currently connected to each Service or Real Server. Sometimes it may appear that a Real Server is handling more traffic than it should be based on its calculated weight. This is caused by persistence. If clients that were previously connected reconnect within a short period of time, they are directed to the same Real Server regardless of its current load.

147 Barracuda Load Balancer Administrator's Guide - Page 147 Understanding Intrusion Prevention To help secure your network, the Intrusion Prevention System (IPS) can automatically receive intrusion prevention and security updates from Barracuda Central, an advanced 24/7 security operations center that works to continuously monitor and block emerging Internet threats. An alternative solution for intrusion prevention is the Barracuda NG Firewall. The Intrusion Prevention System protects your load-balanced services from the following common threats: Denial of Service (DDoS) attacks. Protocol-specific attacks. The Barracuda Load Balancer contains protocol-specific guards that protect your Real Servers from attacks targeting the SMTP, DNS, and LDAP protocols. Application-specific attacks. The Barracuda Load Balancer protects common applications that are particularly vulnerable to external attacks. These applications include IIS, Websphere, Cold Fusion, Exchange, and many more. Operating system-specific attacks. The Barracuda Load Balancer contains Microsoft and UNIX-specific detection capabilities that identify malicious activity against these operating systems. Exploit signatures are regularly updated at Barracuda Central and are automatically delivered to your Barracuda Load Balancer via Energize Updates. The following figure shows how Barracuda Central provides the latest updates through the Energize Update feature. Figure Barracuda Energize Updates. Related Articles Services How to Configure Intrusion Prevention

148 Barracuda Load Balancer Administrator's Guide - Page 148 How to Configure Intrusion Prevention You can enable or disable the Intrusion Prevention System (IPS) for all Services on the Barracuda Load Balancer from the BASIC > Intrusion Prevention page. This page displays a list of all of the Services and whether IPS is enabled for each one. By default, IPS is disabled for a newly created Service. To enable IPS for an individual Service, edit the Service and select the IPS option on the Service Detail page. To test if the IPS is working on the Barracuda Load Balancer, there is a simple URL that will generate a test IPS catch. To test with this URL, create or locate a web Service (with at least one Real Server) on port 80 from the BASIC > Services page. Then type the following address in your browser window: where VIP is the VIP address of the web Service. If IPS is on, it will block this. Your browser will give an error because the connection will be immediately rejected. There should also be an IPS catch in the Intrusion Prevention Log on the BASIC > Intrusion Prevention page. See Understanding Intrusion Prevention for an overview of IPS and how the Energize Updates feature works. Related Articles Services Configuration of Intrusion Prevention

149 Barracuda Load Balancer Administrator's Guide - Page 149 How to Configure a Last Resort Action The Last Resort action for a Service is taken if all of the Real Servers associated with the Service are unavailable. This setting is configured on the Service Detail page. There are three options: Return a failure message or close the connection, depending on the Service type. The details can be found in the online help. Reset the connection. Direct all traffic to a Last Resort Server. To increase the availability of the Service, identify a Last Resort Server. The Last Resort Server can be located anywhere, so long as it is reachable by the Barracuda Load Balancer. It has the same deployments options available as any Real Server. If it is associated with a Layer 7 Service, any policies configured for the Service will also be applied to the Last Resort Server. The Barracuda Load Balancer does not perform any health checks on the Last Resort Server.

150 Barracuda Load Balancer Administrator's Guide - Page 150 Client Impersonation By default, for Layer 7 Services, the Barracuda Load Balancer s WAN IP address is used when connecting to the Real Server. In certain cases, you may want the Barracuda Load Balancer to connect to the Real Server using the client IP address instead. To use the client's IP address instead: Edit the Service. On the Service Detail page, enable the Client Impersonation option. When the Real Server responds to a message using the client IP, the traffic will go directly to the client. However, the client is expecting the response from the Barracuda Load Balancer. In order for the return traffic to pass through the Barracuda Load Balancer, you must change the default gateway of each Real Server in the pool to an address on the Barracuda Load Balancer. Ideally, you should create a custom virtual interface that associates an externally-accessible IP address with the WAN port, and use that IP address for the gateway. To create the custom virtual interface: On the Advanced > Advanced Networking page, in the Custom Virtual Interfaces table, create a custom interface by filling in the fields: IP/Network Address and Netmask an externally-accessible IP address and netmask (may be on the same subnet as the WAN IP address) Service/Interface Name e.g., External IP Address Port Select WAN from the list.

151 Barracuda Load Balancer Administrator's Guide - Page 151 Traffic Management In this Section Understanding Content Rules Understanding Redirect Rules How to Use Extended Match and Condition Expressions Understanding URL Rewrite Rules Understanding HTTP Caching Understanding HTTP Compression

152 Barracuda Load Balancer Administrator's Guide - Page 152 Understanding Content Rules You can create content rules to specify how an HTTP request is directed to one or more Real Servers based on the URL or Header fields of an incoming request. If a request does not match any content rule, it is directed to the Service's Real Servers. After you define a Layer 7 - HTTP or HTTPS Service on the BASIC > Services page, click Rule in the Add field to open the Content Rule page. A content rule consists of three patterns, host, URL, and extended match. If there are multiple rules for a service, each element of an incoming request is matched against each element of the content rules in the following sequence: 3. Host URL Extended match First an attempt is made to match the request against the host specified in each content rule. Next, an attempt is made to match the URL. Last, an attempt is made to match against the Extended Match. Once a match is made, the content rule is executed. For example, if a Service has the following three rules: Rule A - host * URL: /xyz/123.htm extended match: * Rule B - host * URL: /* extended match: * Rule C - host.abc.com URL: / extended match: * And the Load Balancer receives a request for Rule C is the rule executed, because Rule C has the most specific match for the host request. Here is another example. This time the Service has the following two rules: Rule A - host URL /images/* Rule B - host URL /images/*.png The Load Balancer receives a request is for This time Rule B is executed because both the host pattern and the URL pattern are the most specific match for the request. If a rule has the most specific host and URL for a request, any Extended Match expressions for that rule are evaluated in the order established by the Extended Match Order field. If the request does not match any Extended Match expression for the rule then the request is considered to have failed to match any rule. On the BASIC > Services page, you also configure the Real Servers that process the traffic matching the rule. Additional Information For details on Extended Match and Condition expressions, see How to Use Extended Match and Condition Expressions. For information on Redirect Rules, see Understanding Redirect Rules.

153 Barracuda Load Balancer Administrator's Guide - Page 153 Understanding Redirect Rules Use the WEBSITES > Redirect Rules page to define rules to redirect client requests to a specific URL or to a domain appending the requested URL for a selected Service: A redirect rule consists of three patterns: host match, URL match, and extended match. If there are multiple rules for a Service, the most specific host and URL match is executed. For example, if a Service has these two rules: Rule A - host URL /images/* Rule B - host URL /images/*.png and if the incoming request is for then the most specific matching rule, which is Rule B, is executed. If a rule has the most specific host and URL for a request, any Extended Match expressions for that rule are evaluated in the order established by the Extended Match Order field. If the request does not match any Extended Match expression for the rule then the request is considered to have failed to match any rule. You can include %s in the URL to redirect to the domain (URL) specified appending the same requested URL. For example, Service: URL Match: /* Redirect URL: When a request such as is sent, it is redirected to You can also use % in the URL to offset characters. For example, Service: URL Match: /* Redirect URL: If you use %s, the redirected URL would be instead of In this case, specify the Redirect URL as %4s. This format will copy anything in the URL match after 4 characters. Rule Key Each redirect rule can be specified using a Rule key. The key is comprised of the URL, host and an optional extended match rule (that is, a value or expression for the header parameter). The matching Rule is determined by a best match algorithm using the host, URL and extended match fields in specified sequential order. In most cases, host and URL may only be used to specify a Rule. The Barracuda Load Balancer optimizes the search for the most common case by implementing a parallel search algorithm on all Rules. The best matching Rule is the Rule with closest matching host and URL keys. To configure a more complex Rule based on certain fields in the request such as a client IP or an HTTP header, use extended match rules. Not all extended match rules are considered for evaluation. Only the ones specified for the matching host and URL are

154 Barracuda Load Balancer Administrator's Guide - Page 154 used for evaluation. If more than one such rule is specified, they are evaluated based on the specified extended match sequence, and the lower the extended match sequence the higher the priority of the rule in the sequence. Additional Information For more information on building a redirect rule, log into the Barracuda Load Balancer web interface, go to the WEBSITES > Redirect Rules page, and click the Help button. For details on Extended Match and Condition expressions, HTTP request rewrite rules, and HTTP response rewrite rules, refer to the article How to Use Extended Match and Condition Expressions. For details on adding Content Rules to a Service, refer to the article Understanding Content Rules.

155 Barracuda Load Balancer Administrator's Guide - Page 155 How to Use Extended Match and Condition Expressions You can use Extended Match and Condition expressions in content rules, HTTP request rewrite rules, and HTTP response rewrite rules. To learn more about these rules, all of which only apply to Layer 7 - HTTP(S) Services, see the following: Directing HTTP Requests based on Content Rules Modifying HTTP Requests and Responses In this article: Quick Reference Structure Operators Elements Joins Combining Escaping Macro Definitions No Name Parameters This article documents the syntax of the extended match and condition expressions. For example: Header Host co example.com - match a request whose Host header contains example.com Parameter userid ex - match any request in which the parameter 'userid' is present (Header Host eq && (Client-IP eq /24)- match a request whose host header is le.com and the requesting client's IP address is in the * subnet. Quick Reference Expressions Element Match (Expression) [Join (Expression)...] Joins &&, Elements Operators Request Elements: Method, HTTP-Version, Client-IP, URI, URI-Path, Header Request Parameters: Parameter, Pathinfo Response Elements: Status-code, Response-Header Matching: eq, neq, req, nreq Containing: co, nco, rco, nrco Existence: ex, nex Structure The following explains the components of an Extended Match or Condition expression. An expression consists of one or more Element Matches, combined using Join operators to indicate AND and OR operations to combine the Element Matches. Parentheses must be used to delimit individual Element Matches when using join operators. Parentheses can be nested. An Element Match consists of an Element, an optional Element Name, an Operator followed by an optional Value. Some elements like Header require an Element Name like User-Agent, whereas some elements like HTTP-Version require no further qualification. Also, some operators like eq (stands for equals ) require a value, whereas some operators like ex (stands for exists ) require no value. Tokens are delimited by space and the parenthesis characters. Double quotes (") can be used to enclose single tokens which contain parenthesis characters or spaces. The back-slash character can also be used to escape, that is, remove the special meaning of the special characters (space and parentheses). Operators The following are the possible operators in an Element Match. The operators are case insensitive; for example, eq, Eq and EQ are all treated the same. eq True if the operand is equal to the given value. A case insensitive string comparison is performed. Thus, a value of 01 is not the same as a value of 1, whereas values one and ONE are treated the same.

156 Barracuda Load Balancer Administrator's Guide - Page 156 neq co nco rco nrco req nreq ex nex True if the operand is not equal to the given value. A case insensitive string comparison is performed. True if the operand contains the given value. True if the operand does not contain the given value. True if the operand contains the given value, which is treated as a regular expression. True if the operand does not contain the given value, which is treated as a regular expression. True if the operand matches the given value, which is treated as a regular expression. True if the operand does not match the given value, which is treated as a regular expression. True if the operand exists. A value is not required. True if the operand does not exist. A value is not required. Elements The following are the different Elements allowed in the expression. Elements and Element Names are case insensitive, so Method and METHOD are treated the same. Method The HTTP Method that was received in the request. Example: ( Method eq GET) HTTP-Version This refers to the version of the HTTP protocol of the request. Example: ( HTTP-Version eq HTTP/1) Header An HTTP header in the request. An Element Name to identify which header is required to follow the word Header. Example: ( Header Accept co gzip). This checks if the Accept: header contains the string gzip. Client-IP This refers to the IP address of the client sending the request. The IP address can be either host IP address or subnet IP address specified by a mask. Only eq and neq operations are possible for this element. Examples: ( client-ip eq /24), ( Client-I P eq ) URI The URI is the Uniform Resource Identifier in the request. This includes any query parameters in the request. Example: ( URI rco /abc.*html?userid=b) URI-path This refers to the path portion of the URI, which excludes any query parameters. Example: ( URI-path req \/.*copy%20[^/]*) Pathinfo This refers to the portion of URL which is interpreted as PATH_INFO on the server. The Barracuda Load Balancer uses a set of known extensions to determine whether a portion of the URL is a Pathinfo or not. For example, if the request URL is /twiki/view.cgi/engine ering, then, /Engineering is considered to be the pathinfo ra ther than part of the URL. Example: ( PathInfo rco abc* )

157 Barracuda Load Balancer Administrator's Guide - Page 157 Parameter This refers to a parameter in the query string part of the URL. the servers as a name-value pair. The special parameter $NONAME_PAR AM is used to refer to the case where the parameter name is absent. Examples: ( Parameter sid eq 1234), ( Parameter $NONAME_PARAM co abcd) Status-code This refers to the status code of the response returned by the servers. Example: ( status-code eq 302) Response-header This refers to the HTTP response header in the response. The term Response-header should be followed by the name of the header on which the action is to be applied. Example: (Response-Header Set-Cookie co sessionid) Restrictions Each expression may use only some of these elements. The following restrictions apply: The Extended Match expression in the Content Rules can use these elements: Method, HTTP-Version, Header, Client-IP, URI, URI-Path, Pathinfo, and Parameters. Request Rewrite Condition allows these elements: Method, HTTP-Version, Header, Client-IP, Parameter, Pathinfo and URI. Response Rewrite Condition allows these elements: Header, Status-code and Response-Header. Joins Each expression can be joined with another expression by one of the following: True if either of the expressions are true. && True only if both the expressions are true. Combining More than one Element Match can be combined together by using the join operators and && provided the Element Matches are enclosed in parentheses. Combining Element Matches without parentheses is not allowed. Example: (Header cookie ex) && (URI rco.*\.html) && (Method eq GET) Nested sub-expressions can be created by enclosing parentheses within expressions. This makes the expression more readable as well as unambiguous. Example: (HTTP-Version eq HTTP/1) && ((Header Host eq (Header Host eq website.example.com)) Escaping The space character and the parentheses characters are special characters since they cause the parser to split the string into tokens at these separators. In some cases, it is required to specify these characters as part of the value itself. For example, the User-Agent header typically contains both spaces and parentheses, as in: User-Agent: Mozilla/5.0 (Linux i686; en-us; rv:8.3) Firefox/0.0.3 The spaces and parenthesis characters in such cases must be escaped by prefixing these characters with a back-slash (\), or the entire value can be enclosed in double-quotes ( ). Examples: Header User-Agent eq Mozilla/5.0 (Linux i686; en-us; rv:8.3) Firefox/0.0.3 Header User-Agent eq Mozilla/5.0\ \(Linux\ i686;\ en-us;\ rv:8.3\)\ Firefox/0.0.3 To specify the double-quote character itself, it must be escaped with a back-slash. This is true inside a quoted string, or a non-quoted string. Note that the single quote character has no special meaning, and is treated as any other character. To specify the back-slash character itself, it must be escaped as \\. This is true within both quoted strings and non-quoted strings. The back-slash character escapes all characters, not just the special characters. Thus, \c stands for the character c etc. In other words,

158 Barracuda Load Balancer Administrator's Guide - Page 158 back-slash followed by any character stands for the character, whether or not that character has a special meaning in the syntax. Macro Definitions The Barracuda Load Balancer supports several macros to assist in configuring policies. The following table describes these macros arranged by the areas where they can be used. The URI in these cases does not include the host. $SRC_ADDR $URI Inserts the source (client) IP address. You can use it for the new value (Rewrite Value parameter) when inserting or rewriting a header. Should be specified in the new value, if you are rewriting or redirecting the URI. $URI specifies the complete request URI including the query string. $AUTH_USER Adds the username. (1) (2) (3) $AUTH_PASSWD Adds the password. (1) (2) (3) $AUTH_GROUPS Adds the user roles. (1) (2) (3) URL ACLs $NONAME_PARAM Inserts a parameter with no name (see No Name Parameters) Notes: (1) The URL is not protected, i.e. access-control or authentication is off. The value substituted for the macro is the special string NCURLNotPr otected. (2) The client has not logged in. The value substituted for the macros is the special string NCNoUserSession. (3) The user does not belong to any groups. The value substituted for $AUTH_GROUPS is the special string NCNOUserRoles. No Name Parameters There might be times when you want to configure a parameter without a name. For example, consider a site that pops up an advertising window when a user lands there. A Javascript adds a query string that results in the following GET request: GET /ad?xyz The Barracuda Load Balancer does not learn no name parameters such as query strings like " GET /ad?0" added by a Javascript. Workaround: Add a null value URL ACL. The Barracuda Load Balancer treats xyz as the value of a parameter. In this case, you cannot create an exception rule based on the xyz value because there is no way to associate it with a named parameter. To address such situations (that is, requests with parameter name-value pairs of the type?xyz or?=xyz where xyz is the value), you can use a special token: $NONAME_PARAM (case insensitive). This token allows you to create an expression for a parameter without a name as in the following examples: set = parameter $NONAME_PARAM ex set = parameter $NONAME_PARAM eq 0 set = parameter $noname_param co xyz

159 Barracuda Load Balancer Administrator's Guide - Page 159 Understanding URL Rewrite Rules Use the WEBSITES > URL Rewrites page to create rules to modify inbound HTTP requests and outbound response rules for Layer 7 - HTTP Services. From this page you can: Create rewrite rules to modify incoming HTTP request headers and URLs Create rewrite rules to modify outbound HTTP response headers Create rules to rewrite any text string in an outbound HTTP response body Layer 7 - HTTP Services Once you select a Layer 7 HTTP Service in the WEBSITES > URL Rewrites page, the page refreshes to show the rules for the selected service. HTTP Request Rewrite Conditions A request rewrite condition is made up of one or more expressions. An expression consists of an operand, an operator, and a matching value. HTTP Request Rewrite An HTTP request rewrite is applied to the HTTP request coming from the client to the Barracuda Load Balancer. Table HTTP Request Rewrite Operators Table 1 describes the operators you can use in the request rewrite condition expression: Click here to expand... Operator Values contains, CONTAINS, co, CO ncontains, ncontains, nco, nco rcontains, rcontains, rco, rc equals, EQUALS, eq, E nequals, nequals, neq, neq requals, requals, req, re Description Checks if the operand contains the matching value. Checks if the operand does not contain the matching value. Checks if the operand contains the matching value, where the matching value is interpreted as a regular expression. Checks if the operand is equal to the matching value. Checks if the operand is not equal to the matching value. Checks if the operand is equal to the matching value, where the matching value is interpreted as a regular expression. exists, EXISTS, ex, EX Checks if the operand exists. No matching value is required. nexists, nexists, nex, nex Checks if the operand does not exist. No matching value is required. Table HTTP Response Rewrite Expression Tokens Table 2 describes the tokens available for joining expressions: Click here to expand... Token or, OR, and, AND, & Description Checks if either of the expressions is true. Checks if both the expressions are true. ( ) Use parentheses to group together multiple expressions. Table 3. HTTP Response Rewrite Expression Operands Table 3 describes the possible operands for the expression; all keywords are case insensitive:

160 Barracuda Load Balancer Administrator's Guide - Page 160 Click here to expand... Operands Description Example Header Examine the request header. You can search for a header field name, which is a string followed by a colon (:), or for any string. To search for HTTP or custom header field names, type Header followed by the header field name. The header field name to be examined may be a string (e.g. user-agent, accept) or a wildcard (to examine all headers). To search for any string in the header area, enter that string without the keyword. In all of these cases, the matching value may be a regular expression. Header Accept co soap Header Soap-Action ex AnyString EX Client IP Check the IP address of the client that sent the request. The IP address can be either the host IP address or subnet IP address specified by a mask. Only the EQUAL and N OT EQUAL operators may be used with this operand Client-IP eq /24 (s ubnet IP address containing the mask) Client-IP eq (hos t IP address) URI The Uniform Resource Identifier (URI) identifies the resource upon which to apply the request. The matching value may be a regular expression. URI rco /abc*html Method HTTP method in the request. Method eq GET HTTP-Version HTTP protocol version of the request. HTTP-Version eq HTTP/1 Parameter Pathinfo The query portion of the URL which is passed to the server as a name-value pair. $NONAME_PARAM may be used to refer to the case where the parameter name is absent. The matching value may be a regular expression. The portion of URL containing extra information about the path of the resource on the server. The matching value may be a regular expression. Parameter sid eq 1234 Parameter $NONAME_PARAM co a bcd pathinfo rco abc* HTTP Response Rewrite Conditions A response rewrite condition is made up of one or more expressions consisting of an operand, an operator, and a matching value. HTTP Response Rewrite An HTTP Response rewrite is applied to the HTTP response going out from the servers to the client through the Barracuda Load Balancer. Table 4. HTTP Response Rewrite Expression Operators Table 4 describes the operators you can use in the response rewrite condition expression: Click here to expand... Operator Values contains, CONTAINS, co, CO Description Checks if the operand contains the matching value.

161 Barracuda Load Balancer Administrator's Guide - Page 161 ncontains, ncontains, nco, nco rcontains, rcontains, rco, rc equals, EQUALS, eq, E nequals, nequals, neq, neq requals, requals, req, re Checks if the operand does not contain the matching value. Checks if the operand contains the matching value, where the matching value is interpreted as a regular expression. Checks if the operand is equal to the matching value. Checks if the operand is not equal to the matching value. Checks if the operand is equal to the matching value, where the matching value is interpreted as a regular expression. exists, EXISTS, ex, EX Checks if the operand exists. No matching value is required. nexists, nexists, nex, nex Checks if the operand does not exist. No matching value is required. Table 5. HTTP Response Rewrite Expression Tokens Table 5 describes the expressions available for joining expressions: Click here to expand... Token or, OR, and, AND, & Description Checks if either of the expressions is true. Checks if both the expressions are true. ( ) Use parentheses to group together multiple expressions. Table 6. HTTP Response Rewrite Expression Operands Table 6 describes the possible operands for the expression; all keywords are case insensitive: Click here to expand... Operands Description Example Header Examine the request header. You can search for a header field name, which is a string followed by a colon (:), or for any string. To search for HTTP or custom header field names, type Header followed by the header field name. The header field name to be examined may be a string (e.g. user-agent, accept) or a wildcard (to examine all headers). To search for any string in the header area, enter that string without the keyword. In all of these cases, the matching value may be a regular expression. Header Accept co soap Header Soap-Action ex AnyString EX

162 Barracuda Load Balancer Administrator's Guide - Page 162 Response-Header Examine the header of the response. You can search for a header field name, which is a string followed by a colon (:), or for any string. Response-Header Set-Cookie c o sessionid To search for HTTP or custom header field names, type Response-Header followed by the header field name. The header field name to be examined may be a string (e.g. user-agent, accept) or a wildcard (to examine all headers). To search for any string in the header area, enter that string without the keyword. In all of these cases, the matching value may be a regular expression. Status-Code Checks the status code of the response returned by the server. Status-Code eq 200 Response Body Rewrite You can create rules for searching and replacing any string in the body of outbound responses. Only responses where the content-type begins with text/ (text/html, text/plain, text/javascript, text/css, text/xml) are searched, not flash or applet content. Table 7 lists the response body rewrite values. Search and replace strings must be text; regular expressions cannot be used. Additionally, because meta-characters such as \r or \n cannot be used, you cannot search and replace any multi-byte character set strings. Table 7. Response Body Rewrite Values Table 7 describes the Response Body Rewrite Rule fields: Click here to expand... Field Name Rule Name Rule Order Description Enter a name to identify the rule. If there is more than one rule, enter the order of execution; the range is 1 to 128 with '1' executed first. Host Match Enter a value matching the Hostname field in the request header. This value can identify a specific host or it can be a wildcard match with a single asterisk (*) anywhere in the hostname, for example: * *.abc.com URL Match Enter a value matching the URL field in the request header. The URL Match must start with a slash (/) and can have only one asterisk (*) anywhere in the URL. A value of /* means that the ACL applies for all URLs in that domain. For example: /* /index.html /public/index.html Search String Replace String Enter the text string on which to search in the response body. Enter the replacement text string.

163 Barracuda Load Balancer Administrator's Guide - Page 163 Additional Information For more information on creating URL Rewrite rules, log into the Barracuda Load Balancer web interface, go to the WEBSITES > URL Rewrites page, and click the Help button. For a Response Body Rewrite example, refer to the article How to Use the Response Rewrite Function to Enable Web Sites for Google Analytics.

164 Barracuda Load Balancer Administrator's Guide - Page 164 Understanding HTTP Caching Use the WEBSITES > HTTP Caching page to edit caching parameters for a Service or Rule: From this page you can set the following parameters: Enable/disable caching for the Service or Rule Specify response file extensions that can be cached Specify maximum and minimum object size for caching Specify whether to ignore request headers, response headers, and negative responses Enter the default cached object expiration age Additional Information For more information on editing caching parameters for a Layer 7 HTTP or HTTPS Service or Rule, log into the Barracuda Load Balancer web interface, go to the WEBSITES > HTTP Caching page, click the Edit icon next to the Service or Rule you wish to change, and then click the Help button.