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.

165 Barracuda Load Balancer Administrator's Guide - Page 165 Understanding HTTP Compression This article applies to Services with type Layer 7 - HTTP. You can create a compression policy including applicable response content types for a Rule or Service with Layer 7 - HTTP Services on the WEB SITES > HTTP Compression page in the web interface. All configured Services and Rules display in the Compression table. To edit HTTP compression, go to the WEBSITES > HTTP Compression page, and click the Edit icon following the Service or Rule you wish to modify; the edit page displays: Modify the compression settings, and then click Save Changes.

166 Barracuda Load Balancer Administrator's Guide - Page 166 Global Server Load Balancing In this Section 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

167 Barracuda Load Balancer Administrator's Guide - Page 167 Global Server Load Balancing Overview In this article: Overview GSLB Examples GSLB Definitions Site Selection Criteria How GSLB Works Failover Overview Global Server Load Balancing (GSLB) allows you to coordinate how traffic is processed among multiple data centers. A Barracuda Load Balancer acts as a controller, selecting the location to which traffic is directed based on the parameters that you configure and the health of the data centers. This allows you to allocate the work among multiple data centers and to ensure that if one data center fails then traffic is redirected automatically to a functioning data center. GSLB Examples GSLB can be useful when: You have a number of server farms that are physically located around the world and you want incoming connections to be directed to the closest healthy server farm. You have two data centers and you want one of them to be reserved for use in the event of a disaster. You can assign the first with a high priority and have all traffic directed to it, while the other is used only if the first data center fails. You have multiple data centers and each has region-specific content. Depending on the location of the client, requests can be directed to the data center most appropriate for that region. GSLB Definitions A site is a network location that hosts data. It may be a Service on a Barracuda Load Balancer with a server farm or one Real Server. A GSLB Controller is the Barracuda Load Balancer which determines where traffic is directed. It contains configuration information about the sites and it performs health checks on all sites in regular intervals. Only one GSLB Controller is active at a time. It is recommended that you configure one or more backup GSLB Controllers. A region defines a geographical area, usually composed of one or more countries. You can define custom regions or use the predefined regions. Site Selection Criteria The GSLB Service allows you to specify traffic to be directed to a site based on one of three parameters: Proximity of the system making the request to a site that can serve the request; The region of the system making the request; or The priority order of the sites. How GSLB Works The GSLB Controller controls which IP address for a sub-domain is given to a client. These steps illustrate the process: A client tries to connect to a domain name such as It asks its local DNS server for the IP address of the domain 3. name, and the server issues a DNS request on its behalf. This request is eventually directed to the GSLB Controller (Barracuda Load Balancer) that acts as an authoritative DNS server for the delegated sub-domain www. The GSLB Controller considers the site selection algorithm and the health of the sites and issues a DNS response that contains a list of one or more IP addresses of valid sites. The client tries to connect to the first address in the list. In the following figure, the selection algorithm is based on the region of the client. The GSLB Controller determines the region where the request originated. The US client is returned the address of the site which handles clients from the US region ( ) while the client from Europe is given the address of the site which supports content for the European region ( ). Figure How GSLB Works.

168 Barracuda Load Balancer Administrator's Guide - Page 168 Failover The record that is returned by the GSLB Controller in response to a DNS query has a time to live (TTL) value of 10 seconds, meaning that the DNS servers across the Internet need to request the IP address of the site again if the record is older than 10 seconds. If a site becomes unavailable, it is removed from the list of returned IP addresses, the caches update quickly, and traffic is directed to a healthy site.

169 Barracuda Load Balancer Administrator's Guide - Page 169 Implementing Global Server Load Balancing Following are some sample situations and how to configure the site selection algorithm for each one on the Barracuda Load Balancer that acts as the Global Server Load Balancing (GSLB) Controller. Disaster Recovery - Two Sites in the World You have two sites and you want all traffic directed to one of the sites while the other is on standby and used only in the case of the failure of the first site. Create an entry for each site giving the primary site priority 1 (highest) and the backup priority Make the Response Policy By Priority so that only priority is considered when directing traffic. When a query for the address of the domain name is received, a response containing one or more IP addresses is returned. If it is operational, the primary site s IP address will be returned first in the list and the backup site s IP address will be second. If the primary site becomes unavailable, only the second site's IP address will be returned. The primary site will be monitored, even after failure, so that when it becomes available then its IP address will once again be first in the returned list. Direct Clients to Closest Data Center You have a number of server farms that are physically located around the world, and you want clients to be directed to the closest healthy server farm. Make the Response Policy Geo IP to send client requests to the geographically nearest site. If you have a backup site, set the Failover IP address to its IP address. Direct Clients to Specific Region You have multiple data centers, each with region-specific content, and you want client requests from a certain region to be directed to the data center that supports that region. Make the Response Policy Region Only to associate requests with a region based on the location of the client and direct traffic to the appropriate data center. If you have a backup site, set the Failover IP address to its IP address. Content switching rules can be used to direct HTTP traffic within the backup data center (see Directing HTTP Requests based on Content Rules). See Also Barracuda Networks Knowledgebase Solution #

170 Barracuda Load Balancer Administrator's Guide - Page 170 Installing Global Server Load Balancing Execute these tasks to design your Global Server Load Balancing (GSLB) network and to configure one or more GSLB Controllers. Step Notes Step Define the layout of your GSLB network Step Location-based Response Policy If you plan to use a location-based Response Policy: Define Regions (Region Only) Turn on Location Definitions updates Step 3. Set the DNS Service IP Address On each active GSLB Controller, complete Step 3. Step 4. Delegate a Sub-Domain to the GSLB Controller For each sub-domain to be hosted, complete Step 4. Step 5. Configure the DNS records on the GSLB Controller to identify the sub-domains that are being hosted For each GSLB Controller that may receive traffic for a given sub-domain and which is not the passive system for a cluster, complete Steps 5-7. Step 6. Choose the Response Policy Step 7. Enter the Failover IP address Step 8. Identify the rest of the sites that serve this sub-domain Step Define the GSLB network layout Click here to expand... Decide which Barracuda Load Balancers is to act as your active and which is to acct as your passive GSLB Controllers. GSLB Controllers must be externally accessible. They may also act as the load balancer for a server farm. Decide whether the site selection should be based on region, geographical proximity or by pre-configured priority. Determine what will happen in the case of a site failure. Gather the IP addresses (IP addresses of Real Servers or VIP addresses of Services) of the sites. Step Location-based Response Policy Click here to expand... Skip the tasks in this step if you do not intend to use a geographically-based Response Policy ( Geo IP or Region Only). If the Response Policy is Region Only, decide which site or sites are associated with each region where requests originate. In either case, make sure the Location Definitions are set to automatically update on every GSLB Controller. This setting is on the Advanced > Energize Updates page. Step 3. Set the DNS Service IP Address Click here to expand... For each active GSLB Controller, select the IP address to be used as the DNS Service IP address. DNS requests will be send to this IP address. It must be reachable from the WAN, LAN or VLAN of the GSLB Controller. If the GSLB Controller is in HA mode and a system failover occurs, the passive system will assume this address and handle the requests directed to it. If the GSLB Controller is not in HA mode, this address could be the externally reachable IP address of the GSLB Controller. On each active GSLB Controller, go to the Advanced > GSLB Services page and enter the DNS Service IP Address. If this is a clustered system, the passive system will be updated automatically. Step 4. Delegate a Sub-Domain to the GSLB Controller Click here to expand... This step needs to be done at your domain registrar or wherever your domains are hosted. In order to delegate a sub-domain to be resolved by the GSLB Controller, records must be added to the zone file of the domain so that DNS requests for the sub-domain will be forwarded to the GSLB Controller for resolution. For example, if the domain is example.com, and you want to host behind the GSLB Controller, you will need to add a DNS NS (nameserver) record to associate with each GSLB Controller. If there are two GSLB Controllers (one active, one passive) there is one record for the clustered pair:

171 Barracuda Load Balancer Administrator's Guide - Page IN NS nswww.example.com. Add an A (host) record for the GSLB Controller with its IP address and the domain www: nswww.example.com. IN A <DNS Service IP address of first cluster> where <DNS Service IP address...> is the DNS Service IP address assigned to the clustered pair. Do not enter the brackets (< >). Do add the dot (.) at the end of the nameserver. The remainder of the steps are performed on the Barracuda Load Balancer(s) that may act as the GSLB Controller. If you have a clustered GSLB Controller, you only need to do these steps on the active system because the configuration between two clustered Barracuda Load Balancers are synchronized automatically. Step 5. Create the Host DNS Record on each GSLB Controller Click here to expand... This step must be done on each GSLB Controller that is not a passive system in the cluster. Using the web interface of the Barracuda Load Balancer, create the records that describe the domain or domains that are available to the GSLB Controller. The following example generates the A (host) record for on the GSLB Controller. The domain name is example.com an d the host is www. This A record is initially associated with one site IP address but more site IP addresses can be added later. To create the DNS records on the GSLB Controller, 5a. Navigate to the Advanced > GSLB Services page. 5b. In the Add New GSLB Service section, supply the following information: Zone Name the zone maintained by your existing DNS server, e.g. example.com Host The host name (or sub-domain) to be resolved, e.g. www Site IP The IP address that is to receive the traffic. This may be the VIP address of Service on a Barracuda Load Balancer, or the IP address of a server Region This associates a region with the Site IP address. If you want the GSLB Controller to select the site based on region, select the region from the list. If the region you want is not already defined, add a custom region using the Advanced > GSLB Settings page Otherwise, select All Countries from the list A DNS record is created for Some of the fields in the record will contain default values for settings such as the Response Policy, which you can customize by editing the entry in the table. Step 6. Choose the Response Policy Click here to expand... Response Policies are described in the section Response Policy Options. The Response Policy is defined for a host e.g. Edit the Host record on the Advanced > GSLB Services page to modify the Response Policy. Step 7. Set the Failover IP Address Click here to expand... If you have a site that can handle the traffic in the case of failure of all sites that match the Response Policy, enter its IP address as the Failover IP address in the Host record on the Advanced > GSLB Services page. Step 8. Identify the rest of the sites that serve this host Click here to expand... To configure all of the sites that can process the traffic for this host (e.g. go to the Advanced > GSLB Services page and click Add New Site. You may want to associate a new site with a region or assign a priority to it. Remember that regions are only relevant if the Response Policy is Region Only. Similarly, priority is only considered by the By Priority Response Policy.

172 Barracuda Load Balancer Administrator's Guide - Page 172 Integrating Global Server Load Balancing with the Existing DNS Infrastructure In a typical GSLB deployment of the Barracuda Load Balancer, the existing DNS domain nameserver continues as the authoritative nameserver for the zone or domain, e.g. barracuda.com. But a hostname or sub-domain, e.g. www, is delegated to the Barracuda Load Balancer that acts as the GSLB Controller. When a DNS query for is received, it is forwarded to the GSLB Controller. The GSLB Controller acts as the authoritative DNS server for delegated sub-domains, returning definitive answers to DNS queries about domain names installed in its configuration. On the GSLB Controller you can identify one or more IP addresses of sites that serve a single domain name. When asked to resolve a host, the GSLB Controller returns a list of IP addresses of the sites that are both available and that match the site selection algorithm. Related Articles Configuring the Load Balancer Administrative Settings

173 Barracuda Load Balancer Administrator's Guide - Page 173 Site Selection Algorithms When the Global Server Load Balancing (GSLB) Controller receives a DNS request to resolve a sub-domain, it replies with a list of one or more IP addresses of valid sites that are both available and that match the site selection algorithm. This site selection algorithm is also called the Response Policy. Three Response Policies are available: one is based on site priority and the other two are based on location. Failover IP Address If no sites match the Response Policy or if all sites that match the Response Policy fail the health check, a pre-configured Failover IP address for the sub-domain is returned. This is the IP address of a site that can accept the traffic if the other systems become unavailable. The health of the site at the Failover IP address is not monitored. IP Address and Location Database In order to provide location-based Response Policies, the Barracuda Load Balancer uses a database of IP addresses and geographical locations. This database is updated by the Location Definitions which are part of the Energize Updates maintained by Barracuda Central. Response Policy Options Three Response Policies are supported: Geo IP, Region Only and By Priority. Geo IP and Region Only are based on the location of the client. By Priority is based only on the configured priority of the site. Geo IP The GSLB Controller determines the location of the system making the request based on the Location Definitions and compares that to the location of each site. It returns a list of site IP addresses ordered from closest to furthest. Geo IP does not consider site priority. Region Only The GSLB Controller determines the region of the system making the request based on the Location Definitions. If the originating system is in a region that is associated with one or more sites, a list of the healthy site IP address(es) is returned. The most specific matches appear first in the list; any sites that are associated with All Countries are last in the list. If the location of the originating system cannot be determined then any healthy sites that are associated with All Countries are returned. If neither of the preceding cases identifies at least one site IP address, the Failover IP address is returned. Region Only does not consider site priority. By Priority The GSLB Controller returns a list of site IP addresses ordered from lowest to highest priority value. Location is not considered.

174 Barracuda Load Balancer Administrator's Guide - Page 174 Implementing Global Server Load Balancing Regions Global Server Load Balancing (GSLB) regions are used only if the Response Policy is Region Only, to direct traffic to data centers with region-specific content. Add a region to a host on the ADVANCED > GSLB Services page so that traffic that originates in that region is directed to the Site IP address. A number of predefined regions are listed on the ADVANCED > GSLB Settings page. You can also create a custom region by specifying a region name and then adding one or more regions from a list.

175 Barracuda Load Balancer Administrator's Guide - Page 175 Configuring Multiple Global Server Load Balancing Controllers Only one Global Server Load Balancing (GSLB) Controller is active at any one time. However, you can configure multiple GSLB Controllers to increase the availability of your infrastructure in these two ways: Operate in High Availability mode, in which case all of the GSLB information is copied to the passive system. Configure one or more other Barracuda Load Balancers (or clustered pairs) as GSLB Controllers where: Each system or clustered pair has a DNS entry pointing to it. The first available entry is used by a client. The GSLB configuration is synchronized manually between all GSLB Controllers unless they are passive systems in a cluster. The following figure shows three clustered pairs of Barracuda Load Balancers, all in different locations. Each of these six Barracuda Load Balancers can act as GSLB Controllers and they share the same GSLB-specific configuration. The GSLB Controllers are listed in the order they are to be used as name servers in the DNS entry for the domain (see Steps to Install GSLB). Figure Multiple GSLB Controllers. As shown in the diagram, if #1 becomes unavailable, #2 takes over as the GSLB Controller. If both #1 and #2 become unavailable, #3 takes over operation as the GSLB Controller, and so on. See Installing Global Server Load Balancing for instructions on how to install multiple GSLB Controllers.

176 Barracuda Load Balancer Administrator's Guide - Page 176 Networking The Barracuda Load Balancer integrates IP load balancing and network intrusion prevention, and provides comprehensive Failover capabilities and integrated protection from network intrusions: Multiport link aggregation for increased bandwidth (available only on model 640 that includes PORT1 through PORT10 running firmware 4.2 or higher) Default gateway for the Mgmt port. On the BASIC > IP Configuration page you can define a default gateway on the Management (MGMT) port Ability to create a bond interface with a unique bond name and create unique link bonds on the ADVANCED > Advanced Networking p age (available on model 640) Configure VLANs on the ADVANCED > Advanced Networking page (available on all models) Define custom virtual interfaces on the ADVANCED > Advanced Networking page Define static routes on the ADVANCED > Advanced Networking page Create source network address translation (SNAT) rules to allow Real Servers to forward traffic on the ADVANCED > Advanced Networking page Enable IP Masquerading to allow Real Servers to connect directly to the Internet on the ADVANCED > Advanced Networking page In this Section 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 Creating Static Routes Adding Custom Virtual Interfaces Network Address Translation (NAT) VLANs

177 Barracuda Load Balancer Administrator's Guide - Page 177 Multiport Configuration In this Section The articles in this section refer to firmware 4.2 and higher running on the Barracuda Load Balancer model 640 that includes PORT1 through PORT10, except where noted. 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

178 Barracuda Load Balancer Administrator's Guide - Page 178 Understanding Multiport Configuration This article refers to firmware 4.2 and higher running on the Barracuda Load Balancer model 640 that includes PORT1 through PORT10. Configure multiport link aggregation to combine physical network links into a single link to increase capacity and availability. Note that when creating an interface bond, selecting the mode 803ad (or LACP) does not increase the bandwidth for a single conversation and achieves high utilization only when carrying multiple simultaneous conversations as it attempts to use the same ports for the same conversation. Multiport Link Aggregation Your Barracuda Load Balancer deployment is determined by your organizational needs including network traffic. Use link aggregation to maximize network throughput and failover, and to achieve multi-gigabit capacity. Multiport link aggregation enables direct addressing which balances traffic distribution through bonded links. Caution Multiport link aggregation is an advanced feature; before completing this deployment, establish whether this configuration is necessary to meet the needs of your organization. Use a multiport link aggregation deployment if your organization wishes to: Load balance multiple NICs; Combine multiple network connections; Incorporate redundancy in case one of the links fails; Use a Management (MGMT) or WAN network configuration; Increase bandwidth beyond the default 1GBps. Link Aggregation Requirements Before setting up multiport link aggregation, your Barracuda Load Balancer must meet the following requirements: Barracuda Load Balancer model 640 that includes PORT1 through PORT10 Firmware release 4.2 or higher Access to all Real Servers IP Configuration is set to either WAN or Management Operating Mode is set to Route-Path Physical links must be Gigabit (GE) operating in full duplex mode Link aggregation is supported only on links operating in full duplex mode. The model 640 includes 12-1GB Ethernet ports: WAN, MGMT, and PORT1 to PORT10. You configure the WAN IP (WAN) and Management IP (MGMT) on the BASIC > IP Configuration page. By default the network ports PORT1 to PORT10 are soft bridged to behave as a LAN port. This enables PORT1 to PORT10 to see the same data to achieve a maximum of 1Gbp/s throughput. By default, the LAN IP Configuration displays on the BASIC > IP Configuration page. If this is the initial multiport deployment, you do not need to configure the LAN IP; configure the IP address to the network ports that are in use. To use PORT 1 to PORT 10 as separate network ports, from the ADVANCED > Advanced Networking page, set Enable Network Port Configuration to Yes. When set to Yes, the LAN IP Configuration does not display on the BASIC > IP Configuration page. If you configure PORT1 to PORT10 as separate network ports on the BASIC > IP Configuration page before setting Enable Network Port Conf iguration to Yes, go to the ADVANCED > Advanced Networking page, and in the Network Port Configuration section select the port (PORT1 to PORT 10) connected to the switch or server from the Move LAN Configuration to menu. The LAN IP, VLAN Configuration, System Virtual Interfaces, and Static Routes configured under the LAN port are then automatically moved to the selected port. Link Bonding You can create a bond interface with a unique bond name, and then create unique link bonds. On the ADVANCED > Advanced Networking page, you click Add Interface Bond to open the Link Bonding page and create interface bonds. To create a link bond, you enter a unique bond name, and select the bond mode. There are three bond modes available when creating link bonding. Round Robin

179 Barracuda Load Balancer Administrator's Guide - Page 179 The round-robin mode transmits packets in sequential order from the first available network port through the last. This mode provides load balancing and fault tolerance. All outgoing traffic is spread evenly across all of the ports included in the bond. While round-robin distribution is the only mode that allows a single TCP/IP stream to utilize more than one network port worth of throughput, this mode also introduces the potential for out-of-order packets in peer systems and the potential of retransmitted segments. Barracuda Networks recommends using the Dynamic Link Aggregation Control Protocol (LACP). Active-Backup Only one port in the bond is active; a different port becomes active if, and only if, the active port fails. This mode provides fault tolerance only. Dynamic Link Aggregation Control Protocol (LACP) / IEEE 803ad Dynamic Link Aggregation This mode creates aggregation groups that share the same speed and duplex settings, and utilizes all ports in the active aggregator according to the IEEE 803ad specification; therefore, when operating in 8023ad mode, the packets are always distributed in the standard fashion, never in a round-robin fashion. This does not increase the bandwidth for a single conversation; it achieves high utilization only when carrying multiple simultaneous conversations. Port selection for outgoing traffic is done according to the transmit hash policy; the Barracuda Load Balancer configures the xmit_hash_policy to Layer3+4. To enable this mode the switch must support configuration to enable 803ad mode. When using the 803ad (LACP) mode, you must configure the mode on both sides of the link: on the switch side and where the bonded ports are connected. There are a total of 11 ports listed from which you can add one to five ports: WAN - Used to configure the System IP address and default system gateway. PORT1 to PORT10 - Configure Services on these individual ports. Click Add at the top of the page to create the link bond and add it to the Link Bonding table on the ADVANCED > Advanced Networking page. Multiple Ports You do not need to remove the IP addresses configure on a port when moving the PORT to link bonding unless multiple ports are configured with the IP address. For example, if you create the 'A' bond with the WAN interface, you do not need to remove the IP address/custom Virtual Interfaces/Static Routes/SNAT IP address on the WAN interface as these are automatically moved to the newly created bond. However, if you move multiple PORTs with IP addresses configured on the IP address, you cannot create the bond until you delete these IP addresses. Similarly, you can move the LAN IP address to any one of the PORTs and use that same port to create the bond for server-side configuration. Port Failover You must have at least two PORTs in a bond for failover to take place.

180 Barracuda Load Balancer Administrator's Guide - Page 180 Setting Up Multiport Link Aggregation This article refers to firmware 4.2 and higher running on the Barracuda Load Balancer model 640 that include PORT1 through PORT10. Setting Up Multiport Link Aggregation You can aggregate multiple Network Interfaces into a single logical bonded interface to improve throughput. Once the Barracuda Load Balancer is connected to the network, use the following steps to configure link aggregation: Log into the web interface, and on the BASIC > IP Configuration page, specify a WAN IP configuration; click Save Changes. On the BASIC > IP Configuration page, in the Operating Mode section, verify the operation is set to Route-Path mode. On the ADVANCED > Advanced Networking page, in the Network Port Configuration section, set Enable Network Port Configuration to Yes, and click Save Changes. In the Link Bonding section, click Add Interface Bond; the Link Bonding page displays. Enter the bond name, select the mode, and select the ports for bonding, then click Add. Complete step 6 for each link bond, and then close the page. There are a total of 11 ports listed in the Link Bonding page. It is recommended that you create a bond with multiples of two ports, i.e., 2, 4, 6, 8. WAN - Used to configure the System IP address and default system gateway PORT1 to PORT10 - Configure Services on these individual ports Once you create a bonded interface, it is available for selection in the Port selection list throughout the ADVANCED > Advanced Networking page, and in the Interfaces list under Add New Service configuration on the BASIC > Services page. 7. Click Edit after the bonded interface name to add or delete a Network Port from the bonded interface. You can create a service on a bonded interface after creating the bond. To do so, go to the BASIC > Services page, click Add New Service, and configure a new service.

181 Barracuda Load Balancer Administrator's Guide - Page 181 How to Configure Multiport Link Aggregation This article refers to firmware 4.2 and higher running on the Barracuda Load Balancer model 640 that includes PORT1 through PORT10. When network port configuration is enabled, you can configure the following: Set PORT1 throughport10 as separate network ports on the ADVANCED > Advanced Networking page. Set the IP/Network Address, Interface Name, Netmask, and Port in the Custom Virtual Interfaces section on the ADVANCED > Advanced Networking page. Create VLAN, Custom Virtual Interfaces, Static Routes, and Source Network Address Translation configuration by selecting the Port (identical to how the WAN port is configured) on the ADVANCED > Advanced Networking page. Select the desired Network Port when adding a new service on the BASIC > Services page. Configure the Default Gateway for the Network Ports PORT1 to PORT10 as special cases by setting the IP/Network Address and Netmask to in the Static Routes section on the ADVANCED > Advanced Networking page.

182 Barracuda Load Balancer Administrator's Guide - Page 182 Multiport Link Aggregation Network Port Configuration This article refers to firmware 4.2 and higher running on the Barracuda Load Balancer model 640 that includes PORT1 through PORT10. When network port configuration is enabled, you can configure the following: Set PORT1 throughport10 as separate network ports on the ADVANCED > Advanced Networking page. Set the IP/Network Address, Interface Name, Netmask, and Port in the Custom Virtual Interfaces section on the ADVANCED > Advanced Networking page. Create VLAN, Custom Virtual Interfaces, Static Routes, and Source Network Address Translation configuration by selecting the Port (identical to how the WAN port is configured) on the ADVANCED > Advanced Networking page. Select the desired Network Port when adding a new service on the BASIC > Services page. Configure the Default Gateway for the Network Ports PORT1 to PORT10 as special cases by setting the IP/Network Address and Netmask to in the Static Routes section on the ADVANCED > Advanced Networking page.

183 Barracuda Load Balancer Administrator's Guide - Page 183 Multiport Link Aggregation Deployment Options In this Section The articles in this section refer to firmware 4.2 and higher running on the Barracuda Load Balancer model 640 that includes PORT1 through PORT10, except where noted. 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

184 Barracuda Load Balancer Administrator's Guide - Page 184 Example Configuration - Creating Services on Network Ports on Different Networks This article refers to firmware 4.2 and higher running on the Barracuda Load Balancer model 640 that includes PORT1 through PORT10. You can create services on each Network Port on different networks. You can configure Network Ports on both a one-arm and a two-arm configuration for a combined configuration. Route Path in a Two-Arm Configuration In the web interface, go to the BASIC > Services page, and Create the following services to establish Route Path in a two-arm configuration: Service Service1 on [ PORT1 ] and the servers of this service under [ PORT6 ] Service Service2 on [ PORT2 ] and the servers of this service under [ PORT7 ] Service Service3 on [ PORT3 ] and the servers of this service under [ PORT8 ] Service Service4 on [ PORT4 ] and the servers of this service under [ PORT9 ] Service Service5 on [ PORT5 ] and the servers of this service under [ PORT10 ] Any Network Port can be used for either services or servers. Route Path in a One-Arm Configuration In the web interface, go to the BASIC > Services page, and create the following services to establish Route Path in a one-arm configuration: Service Service1 on [ WAN ] and the servers of this service under [ WAN ] Service Service2 on [ PORT1 ] and the servers of this service under [ PORT1 ] Service Service3 on [ PORT2 ] and the servers of this service under [ PORT2 ] Service Service4 on [ PORT3 ] and the servers of this service under [ PORT3 ] Service Service5 on [ PORT4 ] and the servers of this service under [ PORT4 ] Service Service6 on [ PORT5 ] and the servers of this service under [ PORT5 ] Service Service7 on [ PORT6 ] and the servers of this service under [ PORT6 ] Service Service8 on [ PORT7 ] and the servers of this service under [ PORT7 ] Service Service9 on [ PORT8 ] and the servers of this service under [ PORT8 ] Service Service10 on [ PORT9 ] and the servers of this service under [ PORT9 ] Service Service11 on [ PORT10 ] and the servers of this service under [ PORT10 ]

185 Barracuda Load Balancer Administrator's Guide - Page 185 Configuring Multi-Gigabit Capacity This article refers to firmware 4.2 and higher running on the Barracuda Load Balancer model 640 that include PORT1 through PORT10. You can achieve multi-gigabit capacity on both the service and server side. Use the following steps to configure the interface on both the service and server: Create bond0 with [ PORT1 PORT2 PORT3 PORT4 PORT5 ] in the Link Bonding section on the ADVANCED > Advanced Networking page. Create bond1 with [ PORT6 PORT7 PORT8 PORT9 PORT10 ] in the Link Bonding section on the ADVANCED > Advanced Networking page. Configure bond0 Interface Network IP in the Custom Virtual Interfaces section on the ADVANCED > Advanced Networking page. Configure bond1 Interface Network IP in the Custom Virtual Interfaces section on the ADVANCED > Advanced Networking page. Create a service on the bond0 Interface on the BASIC > Services page. You can include the WAN Port as part of a service bond interface; Barracuda Networks recommends that you create the bond interface with multiples of

186 Barracuda Load Balancer Administrator's Guide - Page 186 Configuring the WAN IP Address This article refers to firmware 4.2 and higher running on the Barracuda Load Balancer model 640 that includes PORT1 through PORT10, except where noted. You can configure the WAN IP Address on a VLAN, on the WAN Port, or as a bonded interface. By default the WAN IP is configured on the WAN Port as an untagged network. Configure the WAN IP Address on a VLAN Network If this is your initial deployment, you can configure the Barracuda Load Balancer in a WAN VLAN network by configuring the VLAN Network ID to the System VLAN ID while configuring the System IP through consconf. However, if you previously configured your Barracuda Load Balancer in a different deployment and wish to move the WAN IP to VLAN network from an untagged network, you must create a VLAN Interface in the VLAN Configuration section on the ADVANCED > Advanced Networking page: 3. Log into the web interface, and in the VLAN Configuration section on the ADVANCED > Advanced Networking page, enter the VLAN Name, VLAN ID, and select WAN from the Port menu. Click Add. In the WAN IP Configuration section on the BASIC > IP Configuration page, select the port value of the VLAN Name you defined in St ep 1 above, and click Save Changes. Configure the WAN IP as a Bonded Interface This section refers to firmware 4.2 and higher running on the Barracuda Load Balancer model 640 that includes PORT1 through PORT10. You can configure the Barracuda Load Balancer WAN IP as a bonded interface using the following steps: Log into the web interface, and go to the ADVANCED > Advanced Networking page. In the Link Bonding section, click Add Interface Bond. Enter a name for the link bond, and select the mode. Highlight the WAN port, and click Add to move the WAN port to the Ports list. Click Add at the top of the page to create the bond interface and automatically add the WAN IP, custom virtual interfaces, static routes, and source network address translation created on the WAN port and VLANs. Creation of a bonded interface from consconf is not supported, however, from consconf you can configure the WAN IP on the WAN port, and then create the bond interface by selecting the WAN port as part of the bonded interface. Configure the WAN IP on a VLAN Network of a Bonded Interface You can configure a WAN on a VLAN network on any Barracuda Load Balancer model running firmware 4.2 and higher, however, you can only add a WAN on a bonded interface on a model 640 that includes PORT1 through PORT10. You can configure the Barracuda Load Balancer WAN IP on a VLAN Network of a bonded interface using the following steps: Log into the web interface, and go to the ADVANCED > Advanced Networking page. In the VLAN Configuration section, enter the name and ID in the VLAN Name and VLAN ID fields, and from the Port menu, select WA N. Click Add. In the WAN IP Configuration section on the BASIC > IP Configuration page, select the Port value to the VLAN Configuration you created in Step 2 above. Go to the ADVANCED > Advanced Networking page, and in the Link Bonding section, click Add Interface Bond. Enter a name for the link bond and select the mode. Highlight the WAN port and click Add to move the WAN port to the Ports list. Click Add at the top of the page to create the bond interface and automatically add the WAN IP, custom virtual interfaces, static routes, and source network address translation created on the WAN port and VLANs. High Availability If you are using High Availability (HA) to cluster two Barracuda Load Balancers: Ensure that the WAN IP Address and VLAN Interface are configured the same on both systems when the WAN IP is on the VLAN Interface. Ensure that the WAN IP Address is configured with the same bond interface. Ensure that the WAN IP Address is on the same VLAN as the bonded interface. In HA, any link bonding configuration synchronizes to the peer system. Note that when creating an interface bond, selecting the mode 8 03ad (or LACP) does not increase the bandwidth for a single conversation and achieves high utilization only when carrying multiple

187 Barracuda Load Balancer Administrator's Guide - Page 187 simultaneous conversations as it attempts to use the same ports for the same conversation. Failover In Failover, the bonds are created on the peer system, and heatbeat and configuration synchronization continue on the WAN port as usual. The system can monitor one or more of the "un-bonded" ports or the bonds for the Failover on Link Down setting. The system lists all ports as there is no bond on the system. For example, if there was a bond between PORT2 and PORT3 then you will see PORT1, BOND1, PORT4 and so on. Note that ports that are part of a bond do not display individually. The bonding information, including the modes (round-robin, active-backup, or 803ad/LACP) is synced across the nodes, however, the administrator must ensure proper cabling for it to take effect on a Failover. For example, if PORT2 and PORT3 form a bond on the primary device then the system attempts to use these same ports (PORT2 and PORT3) for the bond on a Failover, therefore the administrator must verify they are connected to the same switch as the bond on the primary. On the ADVANCED > High Availability page, you can monitor the network ports by selecting them from the Failover on Link Down v alues. When Enable Network Port Configuration is set to No, you can connect any of the ports to the LAN. This allows traffic to work properly by connecting any ports from device A to device B to the LAN switch. However, to monitor these ports as part of the High Availability Failover mechanism, select the same physical port on device A and device B. Related Articles Multiport Configuration in a High Availability Environment

188 Barracuda Load Balancer Administrator's Guide - Page 188 Multiport Configuration in a High Availability Environment This article refers to firmware 4.2 and higher running on the Barracuda Load Balancer model 640 that includes PORT1 through PORT10. 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. If you are using HA to cluster two Barracuda Load Balancers: Ensure that the WAN IP Address and VLAN Interface are configured the same on both systems when the WAN IP is on the VLAN Interface. Ensure that the WAN IP Address is configured with the same bond interface. Ensure that the WAN IP Address is on the same VLAN as the bonded interface. In HA, any link bonding configuration synchronizes to the peer system. Note that when creating an interface bond, selecting the mode 8 03ad (or LACP) does not increase the bandwidth for a single conversation and achieves high utilization only when carrying multiple simultaneous conversations as it attempts to use the same ports for the same conversation. Failover In Failover, the bonds are created on the peer system, and heartbeat and configuration synchronization continue on the WAN port as usual. The system can monitor one or more of the "un-bonded" ports or the bonds for the Failover on Link Down setting. The system lists all ports as there is no bond on the system. For example, if there was a bond between PORT2 and PORT3 then you will see PORT1, BOND1, PORT4 and so on. The bonding information, including the modes (round-robin, active-backup, or 803ad/LACP) is synced across the nodes; however, the administrator must ensure proper cabling for it to take effect on a Failover. For example, if PORT2 and PORT3 form a bond on the primary device then the system attempts to use these same ports (PORT2 and PORT3) for the bond on a Failover, therefore the administrator must verify they are connected to the same switch as the bond on the primary. On the ADVANCED > High Availability page, you can monitor the network ports by selecting them from the Failover on Link Down values. When Enable Network Port Configuration is set to No, you can connect any of the ports to the LAN. This allows traffic to work properly by connecting any ports from device A to device B to the LAN switch. However, to monitor these ports as part of the High Availability Failover mechanism, select the same physical port on device A and device B. If the WAN IP Address on the Barracuda Load Balancers in a cluster is configured with the same bond interface, and the minimum link falls below the specified Failover value, Failover is still successful. However, the status of the peer on the ADVANCED > High Availability page displays as peer down. For example, if the systems in HA for a bond using WAN, PORT1-2, and PORT1-4, the minimum link value is 3. In this instance, if PORT1-2 goes down on the Primary System, the Failover is successful, but the Status of both devices displays as down in the ADVANCED > High Availability page. Related Articles Configuring the WAN IP Address

189 Barracuda Load Balancer Administrator's Guide - Page 189 Creating Static Routes This article refers to firmware 4.2 and higher running on all Barracuda Load Balancer models except where noted. You can configure traffic routes to determine network routing decisions. Static routes are used to configure the default route for each port. To configure static routes, you specify the following values on the ADVANCED > Advanced Configuration page in the web interface: IP/Network Address: Enter the IP or network address of the destination in a route entry. Netmask: Enter the associated Netmask for the route entry. Gateway Address: Enter the network gateway IP address. Port: Select the port or VLAN associated with the entered IP/Network Address. Barracuda Load Balancer Model 640 Only On the Barracuda Load Balancer model 640 that includes PORT1 through PORT10, if link bonding is defined, you can select a link bond from the Port list when defining a static route.

190 Barracuda Load Balancer Administrator's Guide - Page 190 Adding Custom Virtual Interfaces This article refers to firmware 4.2 and higher running on all Barracuda Load Balancer models except where noted. A configured interface is a logical exit point that allows traffic to flow between servers and the Barracuda Load Balancer. To configure interfaces, from the ADVANCED > Advanced Networking page, go to the Custom Virtual Interfaces section, and add virtual interface(s) to the physical port used to communicate with the servers. Barracuda Load Balancer Model 640 Only On the Barracuda Load Balancer model 640 that includes PORT1 through PORT10 running firmware 4.2 and higher, you can also create a custom virtual interface on PORT1 through PORT 10. Use the Custom Virtual Interfaces table to add new virtual interfaces to the Barracuda Load Balancer, or to change the port used by an existing Service or virtual interface. If an IPv6 address is assigned to the Barracuda Load Balancer, and if IPv6 addresses are enabled on the BASIC > IP Configuration page, you can add or change a Service or virtual interface for an IPv6 address. To configure Custom Virtual Interfaces, you specify the following values: IP/Network Address: Enter an IP address to communicate with the servers. Interface Name: Enter a unique name for the virtual interface. Netmask: Enter an associated Netmask for this interface. Port: Select the port over which communication is to be transmitted. To do this, select WAN, LAN, or the respective VLAN. For additional information, log into the web interface, go to the ADVANCED > Advanced Networking page, and click the Help button.

191 Barracuda Load Balancer Administrator's Guide - Page 191 Network Address Translation (NAT) Network Address Translation (NAT) maps outbound IP addresses to prevent exposing internal IP addresses. NAT allows you to: Conceal the internal IP address from external exposure or access. Reduce the demand for registered IP addresses because internal IP addresses are not revealed to the outside world. Incoming IP addresses can be translated to correct internal IP addresses. Source Network Address Translation (SNAT) Source Network Address Translation (SNAT) maps internal IP (private IP) addresses to an external IP (public IP) address. SNAT re-writes the IP address of the computer that originated the packet. SNAT is composed of two steps: The process of translating an internal IP address into an external IP address; The process of undoing the translation for returning traffic, that is, rewriting the IP address of the computer that originated the packet. On the NETWORK > NAT page, you can define an SNAT rule to allow Real Servers to forward traffic to the Internet. Create a Source NAT Rule To create a source NAT rule, complete the following steps: Log into the Barracuda Load Balancer ADC as the administrator, and go to the NETWORK > NAT page. In the ADD NAT RULE section, enter values for the following: Pre SNAT Source - Enter the internal IP address or source network that is to be translated. Pre SNAT Source Mask - Enter the subnet for the entered network; you can use a 32-bit netmask if required for single IP NAT. Protocol - Specify TCP or UDP. Destination Port: Either enter an individual port number (for example, 80) or a range of port numbers (for example, ). The default value of allows all ports. Post SNAT Source: Enter the source IP address after the translation. If you specified a range in the P re SNAT Source Mask, this is the first IP address in the translated range. There must already be a virtual interface configured on this system with the IP address (and range, if applicable) specified in Post SNAT Source. If not, the NAT rule will not be added and you will get an error message. 3. Outgoing Interface: The network connection that the outgoing traffic passes through. Click Save.

192 Barracuda Load Balancer Administrator's Guide - Page 192 VLANs This article refers to firmware 3.1 and higher, running on model 340 and higher. The Barracuda Load Balancer supports Layer 2 VLANs to segment traffic. Configuring VLANs In Bridge-Path mode, if VLANs are used, both the LAN and WAN ports must be on the same VLAN. To route a VLAN through the WAN, LAN, or MGMT interface, a VLAN interface must be added to receive the broadcast traffic from the VLAN and route traffic to the VLAN. To add a VLAN interface, you must specify the VLAN name and ID, and select the port to use. On the ADVANCED > Advanced Networking page, add your VLANs to the VLAN Configuration section. If the Barracuda Load Balancer is in route-path mode, select the port for the VLAN. Once identified, the VLANs are available for selection when completing the following tasks: Associating a Real Server with a VLAN Associating a Service with a VLAN Adding a Service directly on a VLAN Creating a static route for an IP or Network Address Additionally, you can move the System IP from WAN to a VLAN (tagged) network on the BASIC > IP Configuration page. 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, the LAN port must be connected to a trunk port on the VLAN switch.

193 Barracuda Load Balancer Administrator's Guide - Page 193 Certificate Management Certificates are digital identity documents used for SSL offloading. Certificates are associated with the Barracuda Load Balancer to establish secure information exchange over the internet, allowing web servers to "prove" their identity to a browser. A certificate contains information such as user name, expiration date, a unique serial number assigned to the certificate by a trusted CA, organization name, domain name, locality, country, the public key, and the name of the CA that issued the certificate. In this Section Introduction to Certificates How to Add an SSL Certificate Installing SSL Certificates with Correct Chain Order

194 Barracuda Load Balancer Administrator's Guide - Page 194 Introduction to Certificates This article refers to firmware 4.1 and higher. Certificates are digital identity documents used for SSL offloading. Certificates are associated with the Barracuda Load Balancer to establish secure information exchange over the internet, allowing web servers to "prove" their identity to a browser. A certificate contains information such as user name, expiration date, a unique serial number assigned to the certificate by a trusted CA, organization name, domain name, locality, country, the public key, and the name of the CA that issued the certificate. The Barracuda Load Balancer supports SSL certificates in PKCS12 and PEM formats. You can use a self-signed certificate or obtain a certificate from a trusted third party Certificate Authority (CA) for SSL encryption. The certificates can be uploaded on the BASIC > Certificates page. Generate/Import a Certificate - Create a secure and authentic certificate using the Barracuda Load Balancer, or import a third party certificate obtained from a trusted CA such as VeriSign. Some browsers require an encrypted certificate from a reliable and known CA. In this case you can: Import a third-party certificate obtained from the CA, or Download the certificate signing request (CSR) and send it to a trusted CA for signing. A CA administrator verifies the CSR, signs the request and returns a signed valid certificate to use for SSL encryption. The imported certificates are stored locally on the Barracuda Load Balancer. Trusted Certificate - A trusted certificate is sent from a trusted CA. Using a CA certificate as a trusted certificate implies that any entity that has a certificate signed by the CA is authenticated for SSL encryption. Additional Information For additional information, go to the BASIC > Certificates page in the Barracuda Load Balancer web interface, and click the Help butto n.

195 Barracuda Load Balancer Administrator's Guide - Page 195 How to Add an SSL Certificate This article refers to firmware 4.1 and higher. You can create a self-signed certificate, or upload a trusted certificate. Uploading a Signed Certificate Signed Certificate Format You can upload a signed certificate in either PKCS12 Token Format or PEM format. Adding a PKCS12 Token Format Certificate Use the following steps to upload a signed certificate obtained from a trusted Certificate Authority (CA) in PKCS12 Token Format. 3. Log into the Barracuda Load Balancer web interface, and go to the BASIC > Certificates page. In the Upload Certificate section, select the Certificate Type as PKCS12 Token. Set Allow Private Key Export to Yes to export the private key corresponding to the certificate. Important Certificates are downloaded in PKCS12 format including both the private key and certificate. If Allow Private Key Export is set to No, the private key is locked and the certificate can be downloaded only in PEM format and the system configuration backup cannot be taken. Allow Private Key Export is valid for generated and imported certificates only. 4. Enter an identifying name in the Certificate Name field. 5. In the Certificate Password field, specify a password that will be used to generate the PKCS12 token for the signed certificate to be uploaded. 6. Click Browse next to the Signed Certificate field, and select the PKCS12 format signed certificate file. Important When uploading a signed certificate as a PKCS12 token, ensure that the file uses a.pfx extension; otherwise the file is treated as a PEM file. When uploading a certificate in.pfx format, verify that any intermediary certificates are bundled in the.pfx file. 7. Click Upload to upload the certificate. Adding a PEM Format Certificate Use the following steps to upload a signed certificate obtained from a trusted CA in PEM Format. 3. Log into the Barracuda Load Balancer web interface, and go to the BASIC > Certificates page. In the Upload Certificate section, select the Certificate Type as PEM Certificate. Set Allow Private Key Export to Yes to export the private key corresponding to the certificate Important Certificates are downloaded in PKCS12 format including both the private key and certificate. If Allow Private Key Export is set to No, the private key is locked and the certificate can be download only in PEM format and the system configuration backup cannot be taken. Allow Private Key Export is valid for generated and imported certificates only. If the certificate signing request (CSR) for this certificate was generated on the Barracuda Load Balancer, set Assign the associated key to Yes, otherwise, select No, and upload the private key in the Certificate Key field. Enter an identifying name in the Certificate Name field. If the Assign the associated key field is set to No, click Browse next to the Certificate Key field to select the corresponding private key for the signed certificate. Important The key must be unencrypted and in PEM format. 7.

196 Barracuda Load Balancer Administrator's Guide - Page Click Browse next to the Signed Certificate field, and select the PEM format signed certificate file. Click Browse next to the Intermediary Certificates field, and select the intermediary CA certificate. To add additional intermediary CA certificates, click the plus ( + ) button. Click Upload to upload the certificate. Certificate Upload Order If your certificate is signed by a trusted CA, upload the certificate in the following order: 1 - Leaf Certificate 2 - Intermediate Certificates 3 - Root CA Certificate Additional Information For additional information, go to the BASIC > Certificates page in the Barracuda Load Balancer web interface, and click the Help butto n. Related Articles Installing SSL Certificates with Correct Chain Order

197 Barracuda Load Balancer Administrator's Guide - Page 197 Installing SSL Certificates with Correct Chain Order A browser running on a desktop system is capable of building the certificate chain in the correct order regardless of the order in which the certificates are presented. However, a browser running on a mobile device, such as Android, may not be capable of building the certificate chain properly if the certificates are not presented in the correct order. This article describes how to resolve this issue by uploading the certificate chain so that the certificate is "digested" in the correct order, and thus presented to the client in the correct order. In this article: Step 1 - Downloading the Certificate Step 2 - Extracting the Private Key Step 3 - Getting the Intermediate and Root Certificates Step 4 - Uploading the Certificate Step 1 - Downloading the Certificate Use the following steps to download the certificate from the Barracuda Load Balancer: Log into the Barracuda Load Balancer web interface, and go to the BASIC > Certificates page. In the Saved Certificates table, locate the certificate, and click Certificate in the Download column. In the Save Token page, enter a passphrase in the Encryption Password field, and click Save. The certificate is exported as a PKCS12 token which includes the private key. Private Key If you already have the private key, ensure that it is decrypted before uploading it to the Barracuda Load Balancer. You can obtain the private key from the device on which the Certificate Signing Request (CSR) was generated, or you can extract it from a previously uploaded certificate. Open the private key file in a text editor such as WordPad or Notepad++ (do not use Notepad), and look for the word ENCRYPTED. If this word is present, the private key is encrypted. Refer to Step 2 - Extracting the Private Key point 5 for the private key decryption process. Step 2 - Extracting the Private Key This section describes how to extract the private key from the certificate using OpenSSL. If the private key is encrypted, use the following steps to extract the private key from the PKCS12 token and decrypt the private key on either a Linux system or a Windows system. OpenSSL Linux generally comes with OpenSSL preinstalled. You can download OpenSSL for Windows from If you are using a Windows system, change the working directory so that you can run OpenSSL from the command line: C:\OpenSSL-Win32\bin\> Enter the following command to simultaneously extract and encrypt the private key: openssl pkcs12 -nocerts -in certificate.pfx -out private_key_encrypted.pem When prompted, enter the password you assigned when downloading the.pfx file from the Barracuda Load Balancer in point 3 in the section Step 1 - Downloading the Certificate. When prompted again, enter a password to encrypt the private key. This is necessary as the private key must be secured at all times, including when it is displayed onscreen. Enter the following command to decrypt the encrypted private key: openssl rsa -in private_key_encrypted.pem -out private_key_decrypted.pem When prompted, enter the password you created in point 4 of this section. Step 3 - Getting the Intermediate and Root Certificates

198 Barracuda Load Balancer Administrator's Guide - Page 198 You can download the intermediate and root certificates of most certificate authorities (CAs) using Microsoft Internet Explorer. However, you may need to follow the support link on the CA site to obtain the correct intermediate and root certificates. On the system where you downloaded the certificate, double-click the downloaded certificate, for example, mycertificate.cer, and click the Certificate Path tab. Double-click each CA in the issuer hierarchy, and note the details including the name of the issuer and the certificate expiry date. These details are helpful in identifying the intermediate and root certificates in the steps that follow. Open Internet Explorer, and go to Tools > Internet Options > Content > Certificates Click the Intermediate Certification Authorities tab, and select the relevant certificate. Click Export. Follow the instructions in the Wizard, exporting the certificate as Base-64 encoded X.509 (.CER), and saving the export with the appropriate name. In the Certificates page, click the Trusted Root Certification Authorities tab, and select the root certificate. Click Export. Follow the instructions in the Wizard, exporting the certificate as a Base-64 encoded X.509 (.CER), and saving the export with an appropriate name. Because Internet Explorer adds trailing line breaks to files, open each exported file in a basic editing program such as WordPad or Notepad++ (do not use Notepad), and remove any trailing line breaks. Step 4 - Uploading the Certificate Use the following steps to upload the certificate chain in the correct order, using the screenshot for reference: In the Barracuda Load Balancer web interface, go to the BASIC > Certificates page. In the Upload Certificate section, select the Certificate Type as PEM Certificate. Select Yes for Allow Private Key Export, and set Assign Associated Key to No. In the Certificate Name field, enter a recognizable name for the certificate. In the Certificate Key field, click Browse, and navigate to and select the Private Key. In the Signed Certificate field, click Browse, and navigate to and select the Server Certificate. In the intermediate Certificates field, click Browse, and navigate to and select the Intermediate Certificate. Click the plus ( + ) symbol following the Intermediate Certificates field. In the new intermediate Certificates field, click Browse, and navigate to and select the Root Certificate. 10. The uploaded certificate displays in the Upload Certificates section of the Saved Certificates table. Warning Message If a warning message such as Unable to verify issuer certificate displays when uploading the certificates, this means that the Barracuda Load Balancer is unable to verify the issuer from the Barracuda Load Balancer's issuer information internal bundle. This Barracuda Load Balancer internal bundle contains issuer information updated with each firmware release, and therefore may be incomplete. Conversely, client browsers update issue information dynamically and are able to verify the issuer from the information presented and so this warning can be ignored.

199 Barracuda Load Balancer Administrator's Guide - Page 199 Monitoring In this Section 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

200 Barracuda Load Balancer Administrator's Guide - Page 200 How to Remotely Administer Real Servers To remotely administer Real Servers that are located behind the Barracuda Load Balancer, for each Real Server, create a Service which load balances only that one Real Server. Use the Virtual IP address for that Service whenever you need to use Secure Shell (SSH) to access the Real Server or perform Remote Desktop Protocol (RDP) administration on the Real Server.

201 Barracuda Load Balancer Administrator's Guide - Page 201 How to Monitor 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

202 Barracuda Load Balancer Administrator's Guide - Page 202 How to Create Monitor Groups Use the ADVANCED > Monitor Groups page to create and associate a monitoring group with each Service and Real Server. Each monitoring group contains one or more tests. The results of those tests determine the status of the Real Server and the Service. The failure of any one test means the Real Server is considered to be unavailable. For example, you can specify a monitoring group with two tests and use that group as the Testing Method for a Real Server. Then, if either one of the tests fails, the Real Server is then removed from the load-balancing pool. Each group contains one or more monitors, and each monitor includes a testing method, an IP address, and a test delay: Testing Method - Select from the list of all testing methods that are supported by the Barracuda Load Balancer. See Understanding Testing Methods for Services and Real Servers for a description of each test. IP Address - Optional. This is the IP address of a Real Server. If left blank and this group is used as the Testing Method for a Service, then this test is applied to every Real Server associated with the Service. If left blank and this group is used as the Testing Method for a Real Server, then that Real Server is tested. Other parameters, if any, as required by the Testing Method. Test Delay - This is how often, in seconds, this test within this monitor is run. It is also the length of time that this test is allowed to complete; minimum value is 5 seconds. To add a group, enter the group name and the details for the first monitor, and click Add Group. To add another monitor to an existing group, click Monitor on the entry for the group in the Existing Monitor Groups table. Existing Monitor Groups The Existing Monitor Groups table displays all of the monitoring groups that have been added. To add a monitor to an existing group, click Mon itor on the entry for the group in the table. Edit the monitor by clicking the Edit icon. The groups listed in this table appear in the Testing Methods drop-down that is on the Service Detail page and the Real Server Detail page. Click Preferences to specify the number of groups shown on each page of this table. Related Articles Monitoring How to Monitor Services and Real Server Health Understanding Testing Methods for Services and Real Servers Remote Desktop Services in Windows Server 2008 R1 or R2 Deployment

203 Barracuda Load Balancer Administrator's Guide - Page 203 Understanding Testing Methods for Services and Real Servers Testing Methods are used by the Barracuda Load Balancer Service Monitor to check the health of the Real Servers that provide a Service. The Testing Method configured at the Service level is executed on every Real Server that provides that Service unless a different test is configured at the Real Server level. To specify a test on a Service basis, go to the BASIC > Services page, and click the Edit icon for the Service you wish to modify. To specify a test on a Real Server basis, click the Edit icon next to the IP address of the Real Server on the BASIC > Services page to display the Real Server Detail page. The tests use the Real Server port configured on the Real Server Detail page for the Service except in the following cases: The Real Server port is set to ALL. The tests use the default port for the test type (e.g., SMTP = 25, HTTP = 80, DNS = 53, HTTPS = 443, IMAP = 143, POP = 110, FTP = 21 and SNMP = 161). The Specific HTTP Port test and the RDP test allow you to identify the port to use. The minimum value for the test interval, meaning the time between test start times, is 5 seconds, and the default is 30 seconds. The test interval is also the length of time the test is allowed to complete before it is considered to have failed. Table Monitor Group Testing Methods. Test Name Description Test Target Test Match TCP Port Check For Services specified with TCP-based ports, the Service Monitor validates that the port is open. For UDP-based Services and Services defined with "ALL" ports, the Service Monitor performs a PING test. n/a n/a UDP Port Check Check if the UDP port is open by sending a 0 byte datagram to the Real Server IP address and port. This test depends on receiving an "ICMP Port Unreachable" message to determine the result. If there is a firewall that prevents outbound ICMP messages, the test assumes that the port is open. n/a n/a HTTP Performs an HTTP GET request to the specified URL. The Real Server is used as a proxy server to retrieve the page, so the forward proxy setting on the Real Server must be enabled. Enter the complete URL starting with " Enter a pattern expected in the resulting HTML. Simple HTTP Performs an HTTP GET request to the specified relative URL on the Real Server being tested. Th e actual URL used is _server_ip]:[port][url]. You can also specify additional headers to be sent with the HTTP request in the format Header1:Value1, Header2:Value2, etc. Make sure to specify the expected HTTP response status code when accessing the URL as any other status code will be considered an error. Recommended: 200 Enter the root relative URL (such as /cgi-bin/index.cgi). Enter a pattern expected in the resulting HTML.

204 Barracuda Load Balancer Administrator's Guide - Page 204 Simple HTTPS Same as Simple HTTP test but using SSL. The actual URL used will be port][url]. Enter the root relative URL (such as /cgi-bin/index.cgi) in the Test Target box. Enter a pattern expected in the resulting HTML. HTTPS Test Performs an HTTPS GET reques t to the specified URL. The Real Server is used as a proxy server to retrieve the page, so the forward proxy setting on the Real Server must be enabled. Enter the complete URL starting with " Enter a pattern expected in the resulting HTML. DNS Sends a DNS query to retrieve the IP address of the specified hostname. This value is compared to the IP address in Enter a fully qualified hostname in the Test Target box. To validate resolution to a specific IP address, enter that IP in the Test Match box. the Test Match box. IMAP Simple Test for IMAP service. If no username and password are provided, this test verifies availability of the IMAP service on the Real Server. Optional. Username to log in as. Optional. Password to use. POP Simple Test for POP service. If no username and password are provided, this test verifies availability of the POP service on the Real Server. Optional. Username to log in as. Optional. Password to use. SMTP Simple Test for SMTP service. Enter the domain for the mail server to be tested. Optional. Enter a pattern that is expected in the banner of the SMTP Server. SNMP Do an SNMP GET using the OID in the Test Target box, and match the response to the pattern in the Test Match box. If the Test Target box is empty, the test checks if the SNMP is available on the Real Server. Optional. Enter a valid SNMP OID in the Test Target box. Optional. Enter a pattern to match in the response. SIP Simple Test for SIP service. This n/a n/a test sends an OPTIONS packet to the SIP server to check availability of the SIP service. LDAP/AD Bind Test for LDAP/AD service. If no username and password are provided, the LDAP/AD test verifies availability of the anonymous user. Optional. Username with full LDAP schema. Optional. Password to use. LDAPS/AD Bind Test for LDAPS/AD service. If no username and password are provided, the LDAPS/AD test verifies availability of the anonymous user. Optional. Username with full LDAP schema. Optional. Password to use. Barracuda Spam Firewall The Barracuda Load Balancer IP address must be exempted from any Rate Control settings on the Barracuda Spam Firewall. Enter the domain for the mail server to be tested. Enter a pattern that is Optional. expected in the banner of the SMTP Server.

205 Barracuda Load Balancer Administrator's Guide - Page 205 Always Pass This test is used for troubleshooting or for services used for management access to Real Servers. This test always passes regardless of the condition of the Real Server. n/a n/a Specific HTTP Port Performs an HTTP GET request using a specified port to a relative URL on the Real Server being tested. The URL used is ht tp://[real_server_ip]:[port][url ]. Enter the TCP port followed by a ":" and the root relative URL (e.g. 8080:/cgi-bin/index.cgi)). Enter a pattern expected in the resulting HTML. RADIUS Auth Tests the availability of a RADIUS server. Enter the secret to use with the RADIUS server. Enter a username and password separated by " ". Example: username password RADIUS Acct Tests the availability of a RADIUS server by making an accounting request. Enter the secret to use with the RADIUS server. Enter a username and password separated by " ". Example: username password RDP Test Attempts an RDP connection to each Real Server to check the availability of the Terminal Service. Enter the port on the Real Server to use, if different than the port specified on the Real Server Detail page. n/a FTP Test Attempts a TCP connection to each Real Server to check FTP availability. Optional. Username. Optional. Password. FTPS Test Attempts a TCP connection to each Real Server to check FTPS availability. Optional. Username. Optional. Password. Related Articles Monitoring How to Monitor Services and Real Server Health How to Create Monitor Groups Remote Desktop Services in Windows Server 2008 R1 or R2 Deployment

206 Barracuda Load Balancer Administrator's Guide - Page 206 How to Enable or Disable Real Servers You can change the state of a Real Server to either Enable, Disable or Maintenance. Enable a Real Server to make it accept new requests, connections or sessions. Disable a Real Server to terminate all existing connections immediately or put it into Maintenance mode to allow existing connections to terminate naturally. Disabling your Real Servers allows you to perform maintenance or to temporarily disassociate them from a Service. A Real Server that is in disabled or maintenance mode will not accept any new connections or requests until it is enabled. There are two ways to change the status of a Real Server: Use the Disable/Maintenance/Enable actions on the BASIC > Server Health page. Edit the Real Server on the BASIC > Services page. Related Articles Monitoring Remote Desktop Services in Windows Server 2008 R1 or R2 Deployment

207 Barracuda Load Balancer Administrator's Guide - Page 207 How to View Performance Statistics The BASIC > Status page provides an overview of the health and performance of your Barracuda Load Balancer, including: Traffic statistics, which shows the number of connections or requests for various types of traffic since the last system reset for up to five Services. The subscription status of Energize Updates. Performance statistics, such as CPU temperature and system load. Performance statistics displayed in red signify that the value exceeds the normal threshold. Hourly and daily traffic statistics.

208 Barracuda Load Balancer Administrator's Guide - Page 208 How to View Logs The BASIC > Event Log page maintains a list of all noteworthy events that affect the operation of the Barracuda Load Balancer, such as attacks upon various Services and status changes for a Real Server. You can view the Syslog, which contains administrative updates such as logins and configuration changes as well as all of the system events contained in the Event Log, using the ADVANCED > Syslog page. You can also enter an IP address where the syslog output can be directed. If Intrusion Prevention System is enabled, you can look at messages related to it in the Intrusion Prevention Log on the BASIC > Intrusion Prevention page.

209 Barracuda Load Balancer Administrator's Guide - Page 209 How to Automate System Alert and SNMP Trap Delivery The BASIC > Administration page allows you to configure the Barracuda Load Balancer to automatically notifications to the addresses you specify. To enter multiple addresses, separate each address with a comma. An notification is generated if the number of operating Real Servers for a Service falls below a preset threshold. You can also configure SNMP traps to be generated when certain events occur. Go to the ADVANCED > SNMP Configuration page to see the list of possible traps.

210 Barracuda Load Balancer Administrator's Guide - Page 210 How to Configure SNMP Monitoring on the Barracuda Load Balancer This article refers to Barracuda Load Balancer firmware version 3.3 and higher. The Barracuda Load Balancer supports SNMP versions v2c and v3. In this article: Configuring the Barracuda Load Balancer Importing the Barracuda Load Balancer MIBs Syntax Objects Configuring the Barracuda Load Balancer To use your SNMP monitor with the Barracuda Load Balancer, you must identify the Barracuda Load Balancer as a system which is allowed SNMP access. To do so, use the following steps Log into the Barracuda Load Balancer web interface as the administrator. On the ADVANCED > SNMP Configuration page, in the SNMP Manager section, select the SNMP version. Note: If you select SNMP version v3, you must enter the SNMP user name and password; the SNMP password must be a minimum of 12 alphanumeric characters in length. Enter the IP address of SNMP monitor in the Allowed SNMP IP/Range fields, and click Add. Repeat step 3 for any additional SNMP monitors you wish to include. Update the other SNMP-related settings as necessary, and click Save Changes. Note: If the Barracuda Load Balancer is in high availability (HA) mode, all SNMP settings are propagated to the other system in the cluster. Use the following steps to configure SNMP traps. On the ADVANCED > SNMP Configuration page in the SNMP Traps section, enter the IP address and port number to which SNMP traps are to be sent, and click Add. Repeat step 1 for each additional IP address to which you wish to send SNMP traps, and then click Save Changes. In the SNMP Trap Events section, select the SNMP traps you wish to generate, and click Save Changes. Importing the Barracuda Load Balancer MIBs In order to use an SNMP monitor or other program to query for system information using SNMP, you must obtain and import the following MIB files into your SNMP monitor: Barracuda Load Balancer MIB Barracuda Reference MIB The MIB files are located on the Barracuda Load Balancer, and can be obtained by replacing the [LB IP] in the following URLs with a management IP address from your Barracuda Load Balancer: IP]:8000/Barracuda-LB-MIB.txt IP]:8000/Barracuda-REF-MIB.txt Syntax If you are using an SNMP monitoring tool, import the MIBs into the SNMP monitor. Refer to the MIBs for the Object IDs (OIDs) that correspond to the type of status you wish to monitor as to view generated traps. If you are querying the Barracuda Load Balancer from code, use the following syntax, where [LBM IP] is the management IP address of your Barracuda Load Balancer. If you are using the snmpwalk command and do not include an OID, a list of all OIDs in the MIB is returned. snmpget -v 2c -c public [LB IP] Objects The following table lists the objects available in the Barracuda Load Balancer MIB. OID Object Description systemactiveservices Number of active Services on the Barracuda Load Balancer systemoperatingservers Number of operating Real Servers L4TCPConnections Number of Layer 4 TCP connections.

211 Barracuda Load Balancer Administrator's Guide - Page L7HTTPRequests Number of requests to each Layer - 7 HTTP Service configured on the device RDPUserSessions Number of Layer 7 - RDP user sessions ServiceBandwidth Current bandwidth to each Service TotalBandwidthToLB Total bandwidth RealServerBandwidth Current bandwidth to each Real Server ClusterStatus If this Barracuda Load Balancer is in a cluste r or is standalone SystemLoad System load as a percentage CPUTemperature CPU temperature in degrees Celsius FirmwareStorage The space occupied by the firmware, as a percentage of the space allocated to it MailLogStorage The space occupied by the mail/log, as a percentage of the space allocated to it OperationMode The operating mode of the Barracuda Load Balancer: either Route-Path or Bridge. Related Articles Monitoring How to Monitor the System Using SNMP

212 Barracuda Load Balancer Administrator's Guide - Page 212 How to Monitor the System Using SNMP Using the Barracuda Load Balancer SNMP agent, you can use an SNMP monitor to query the system for a variety of statistics such as the number of current connections, bandwidth, and system CPU temperature. SNMP v2c and SNMP v3 are both supported by the SNMP agent. SNMP v2c queries and responses are not encrypted, so it is less secure. When using SNMP v3, traffic is encrypted and you can allow access only by specified users with passwords. Related Articles Monitoring How to Configure SNMP Monitoring on the Barracuda Load Balancer

213 Barracuda Load Balancer Administrator's Guide - Page 213 How to Manage Multiple Systems with the Barracuda Cloud Control Barracuda Cloud Control enables administrators to manage, monitor and configure multiple Barracuda Load Balancers (firmware version 3.6 and higher) at one time from one console. You can connect one or more Barracuda Load Balancers to Barracuda Cloud Control by doing the following: If you don't already have an account with Barracuda Networks, visit to create one. Make a note of your username ( address) and password. 3. Log into your Barracuda Load Balancer as the administrator. On the ADVANCED > Firmware Upgrade page, check to make sure you have the latest firmware installed. If not, download and install it now. 4. From the ADVANCED > Cloud Control page, enter the Barracuda Networks username and password you created, and click Yes to connect to Barracuda Cloud Control. Note that your Barracuda Load Balancer can connect with only one Barracuda Cloud Control account at a time. 5. Log into Barracuda Cloud Control with your username and password. The Barracuda Load Balancer statistics display in the BASIC > Status page. To access the web interface of your Barracuda Load Balancer, click on the link in the Products column in the pane on the left side of the page, or you can click on the product name in the Product column of the Unit Health pane on the right side of the page. 6. Follow steps 3 and 4 to connect every subsequent Barracuda Load Balancer to Barracuda Cloud Control. To disconnect your Barracuda Load Balancer and Barracuda Cloud Control, from the ADVANCED > Cloud Control page, enter the Barracuda Cloud Control username and password, and click No for Connect to Barracuda Cloud Control. Use this step when there is to be a loss of connectivity between the appliance and Barracuda Cloud Control due to the appliance being physically moved, or when there are other network connectivity issues. Related Articles Monitoring How to Configure SNMP Monitoring on the Barracuda Load Balancer

214 Barracuda Load Balancer Administrator's Guide - Page 214 How to View System Tasks The ADVANCED > Task Manager page provides a list of tasks that are in the process of being performed and also displays any errors encountered when performing these tasks. Some of the tasks that the Barracuda Load Balancer tracks include: Cluster setup Configuration restoration If a task takes a long time to complete, you can click the Cancel link next to the task name and then run the task at a later time when the system is less busy. The Task Errors section lists an error until you manually remove it from the list. Related Articles How to Configure SNMP Monitoring on the Barracuda Load Balancer

215 Barracuda Load Balancer Administrator's Guide - Page 215 How to Configure Adaptive Scheduling 3. This article refers to firmware versions 3.0 and above. The Barracuda Load Balancer provides a method for dynamic weighting based on the load of each Real Server called Adaptive Scheduling. Whe n enabled, the Barracuda Load Balancer polls the Real Servers frequently and assigns weights to those Real Servers using the information gathered. To select the adaptive scheduling method: Go to the BASIC > Services page and edit the Service. On the Service Detail page, in the Policy section, select the desired Adaptive Scheduling option. Click Save Changes. Select from the following options: None SNMP CPU Load URL Terminal Sessions Testing the Adaptive Scheduling Settings None None disables Adaptive Scheduling. SNMP CPU This scheduling method polls the SNMP OID on each Real Server for CPU load and manipulates the weights accordingly. Weights are assigned to each Real Server using the formula (100load). For example, if the CPU load is 23, the Real Server is assigned a weight of 77. The Real Servers must have an SNMP agent installed that supports the SNMP OID for CPU load. You may need to install an SNMP agent and possibly an agent extension on your Real Servers. The default OID for Linux is and for Windows is , but you can customize these by editing the Service. Additionally, the Real Servers must: Allow access using the community name specified on the Service Detail page. Make SNMP available on the standard SNMP port of 16 Allow SNMP read access by the LAN IP address of the Barracuda Load Balancer, if in route-path mode, or the WAN IP address, if in DSR mode. About the Windows SNMP Agent The Windows SNMP Agent that comes with Microsoft Windows 2003 or higher does not support the required OID for CPU load. Because of this, you need to install either an extension to the Windows SNMP agent or a new SNMP agent that supports the CPU load OID on the Windows servers Some administrators have successfully installed the SNMP Informant Standard agent, which is a free SNMP extension agent available from Informant Systems, Inc. It runs in conjunction with the Windows SNMP agent and supports the OID for CPU load. About SNMP on Linux Systems If you have Linux servers, make sure that you have an SNMP agent installed and running. Several Barracuda customers have reported successful use of Net-SNMP which supports the OID for CPU load. Load URL This scheduling method polls a URL which returns a load value. When selected, the Barracuda Load Balancer polls the URL Se rver IP Address]/loadpage where loadpage is the directory or page name specified in the Load URL box. The result from the poll should look like LOAD=23 (showing the load as an integer between 0 and 100). Weights are assigned to each Real Server using the formula (100 Load). For example, if the Load URL value is 23, the Real Server is assigned a weight of 77. For the URL request to work, each Real Server must be running a web server that responds to the poll at the Real Server s IP address and port 80. Terminal Sessions This scheduling method dynamically redistributes connections between Windows Terminal Servers based on the number of sessions per server determined by an SNMP query. The Real Servers must:

216 Barracuda Load Balancer Administrator's Guide - Page 216 Allow access using the community name specified on the Service Detail page. Make SNMP available on the standard SNMP port of 16 Allow SNMP read access by the LAN IP address of the Barracuda Load Balancer, if in route-path mode, or the WAN IP address, if in DSR mode. Testing the Adaptive Scheduling Settings When you click Test, the value shown is a subtraction of the Load value. To determine the load value set on the server, subtract this value by 100. If the server is unreachable, you should know the expected value generated by clicking Test and the weight assigned to the unreachable server (which should be similar to a server on which polling has failed but which is still reachable). The following example helps to illustrate the values assigned to your configured servers when you click Test for the Adaptive Scheduling config uration: Create an HTTP service and configure it with the four servers. Name the servers Server1, Server2, Server3, and Server4. For this example, Server1 should be inaccessible. Configure the following weights for each of the servers (click Edit next to each Server and enter a new value in the Weight field): Server1: Server2: 20 Server3: 80 Server4: 50 For the HTTP service configuration, show Advanced Options and set Adaptive Scheduling to Load URL and set the Load Threshold to 35. Click Test. The Barracuda Load Balancer ADC should generate the following output (this is result of the Formula as described in Step 6): Server1 100 Server2 80 Server3 20 Server You can calculate the weight configured for each Server by subtracting the value generated by the Test function from 100. Server Server1 Calculated Weight Server 1 is unreachable for polling. Its weight is not calculated and is set to 100. Server = 20 Server = 80 Server = These values match the weights configured in Step 2 except for Server1 which is unreachable. The following table lists the weight assigned to servers based on the above calculation: Formula Result Weight The following table shows the weight assigned to each of the servers in this example based on the previous calculations:

217 7. Barracuda Load Balancer Administrator's Guide - Page 217 Server Weight Reason Server1 100 Server 1 is unreachable. Server2 100 Load for Server2 is < Load Threshold (configured as 35). The weight for Server2 is not calculated and it is instead set to 100. Server3 3 Load for Server3 is > Load Threshold. The weight for Server3 is set to 3 (formula result is 20). Server4 6 Load for Server 4 is > Load Threshold. The weight for Server4 is set to 6 (formula result is 50). 8. If the actual load is greater than the configured Load Threshold, the weight is adjusted based on the formula result which can be displayed by clicking the Test. Related Articles Monitoring Services

218 Barracuda Load Balancer Administrator's Guide - Page 218 Maintenance In this Section 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

219 Barracuda Load Balancer Administrator's Guide - Page 219 How to Back up and Restore Your System Configuration Use the ADVANCED > Backup page to back up and restore Barracuda Load Balancer configuration. You should back up your system on a regular basis in case you need to restore this information on a replacement Barracuda Load Balancer or in the event your current system data becomes corrupt. If you are restoring a backup file on a new Barracuda Load Balancer that is not configured, you need to assign your new system an IP address and DNS information on the BASIC > IP Configuration page. Backup File Do not edit backup files. Any configuration changes you want to make need to be done through the web interface. The configuration backup file contains a checksum that prevents the file from being uploaded to the system if any changes are made. You can safely view a backup file in Windows WordPad or Microsoft Word. You should avoid viewing backup files in Windows Notepad because the file can become corrupted if you save the file from this application. The following information is not included in the backup file: System password System IP information DNS information

220 Barracuda Load Balancer Administrator's Guide - Page 220 How to Update the Firmware on Your Barracuda Load Balancer The ADVANCED > Firmware Update page allows you to manually update the firmware version of the system or revert to a previous version. The only time you should revert back to an old firmware version is if you recently downloaded a new version that is causing unexpected problems. In this case, call Barracuda Networks Technical Support before reverting back to a previous firmware version. If you have the latest firmware version already installed, the Download Now button is disabled. If you have two Barracuda Load Balancers configured in High Availability mode, update the firmware on the passive Barracuda Load Balancer first, then update the firmware on the active Barracuda Load Balancer. The passive Barracuda Load Balancer becomes operational when the active system is rebooted, thus maintaining availability. If your Barracuda Load Balancers are not in High Availability mode, applying a new firmware version results in a temporary loss of service. For this reason, you should apply new firmware versions during non-busy hours.

221 Barracuda Load Balancer Administrator's Guide - Page 221 How to Update Intrusion Prevention Rules Using Energize Updates The ADVANCED > Energize Updates page allows you to manually update the Intrusion Prevention System rules, as well as change the interval at which the Barracuda Load Balancer checks for updates. We recommend that the setting be set to so your Barracuda Load Balancer receives the latest rules as soon as Automatically Update Hourly new threats are identified by Barracuda Central.

222 Barracuda Load Balancer Administrator's Guide - Page 222 How to Replace a Failed System Related Articles How Barracuda Networks Manages Returned Device Drives Before you replace your Barracuda Load Balancer, use the tools provided on the ADVANCED > Troubleshooting page to try to resolve the problem. In the event that a Barracuda Load Balancer fails and you cannot resolve the issue, customers that have purchased the Instant Replacement service can call Technical Support and arrange for a new unit to be shipped out within 24 hours. After receiving the new system, ship the old Barracuda Load Balancer back to Barracuda Networks at the address below with an RMA number marked clearly on the package. Barracuda Networks Technical Support can provide details on the best way to return the unit. Barracuda Networks 3175 S. Winchester Blvd Campbell, CA To set up the new Barracuda Load Balancer so it has the same configuration as your old failed system, restore the backup file from the old system onto the new system, and then manually configure the new system s IP information on the BASIC > IP Configuration page. For information on restoring data, refer to How to Back up and Restore Your System Configuration.

223 Barracuda Load Balancer Administrator's Guide - Page 223 How to Reload, Restart, and Shut Down the System The System Reload/Shutdown section on the BASIC > Administration page allows you to shutdown, restart, and reload system configuration on the Barracuda Load Balancer. Shutting down the system powers off the unit. Restarting the system reboots the unit. Reloading the system re-applies the system configuration. You can also reboot the Barracuda Load Balancer 240, 340, and 440 by pressing RESET on the front panel of the Barracuda Load Balancer. Do not press and hold the RESET button for more than a couple of seconds. Holding it for five seconds or longer changes the configuration to the factory default, wiping out all current settings, including the current network settings.

224 Barracuda Load Balancer Administrator's Guide - Page 224 How to Troubleshoot Your Barracuda Load Balancer The ADVANCED > Troubleshooting page provides various tools that help troubleshoot network connectivity issues that may be impacting the performance of your Barracuda Load Balancer. From this page you can open a secure troubleshooting connection from your Barracuda Load Balancer to Barracuda Central, allowing a Barracuda Networks technician to diagnose and troubleshoot an issue with your system. To open a troubleshooting connection to your Barracuda Load Balancer: 3. Click Establish Connection to Barracuda Support Servers. Provide the support engineer with the displayed serial number. After the issue is resolved, click Terminate connection to Barracuda Central to close the connection between your Barracuda Load Balancer and Barracuda Central. Network Connectivity Tests You can use the tools in this section to diagnose potential network problems on the Barracuda Load Balancer: Ping Device An interface to the ping command on the Barracuda Load Balancer. To verify connectivity with any network host, enter the IP address or hostname to ping, and then click Begin Ping. Telnet Device An interface to the telnet command on the Barracuda Load Balancer. To verify connectivity and initial response from the remote server, enter the IP address or hostname of the remote server, and then click Begin Telnet. This session is non-interactive. Dig/NS-lookup Device An interface to the dig command on the Barracuda Load Balancer. To look up any type of DNS record (such as A, MX, SOA, TXT, or NS), enter the IP address or hostname of the device in the Dig/NS-lookup Device field, and then click Begin Dig. TCP Dump An interface to the TCP dump command on the Barracuda Load Balancer. To monitor network traffic packets, enter the TCP dump command options, and then click Begin TCP Dump. Traceroute Device An interface to the traceroute command on the Barracuda Load Balancer. To determine the path taken by traffic to its destination, enter the destination and click Begin Traceroute. Wget Web Page Execute the Wget command with spider option. Enter a URL and click Begin Wget. Wget will not download the pages; it only checks that they are there. Pages are not returned or cached. You can use a host name or an IP address in the URL. Wget supports HTTP, HTTPS, and FTP protocols, as well as retrieval through HTTP proxies. Advanced TCP Dump The Advanced TCP Dump option allows you to execute a TCP dump command on the Barracuda Load Balancer and write the results to a file for downloading. The maximum number of packets that can be captured for each run is limited to 10,000. The IP Address and Port fields are optional. Network Information These commands are primarily for use by Barracuda Networks Technical Support. Show ARPs This command displays the ARP (Address Resolution Protocol) entries for this Barracuda Load Balancer. It shows the MAC address and the corresponding IP address of each interface. Show Routes This command displays the IP routing table on the Barracuda Load Balancer. It shows the network address and subnet information for the LAN and WAN, and the default gateway. Show Interfaces This command displays the MAC address for each interface used by the Barracuda Load Balancer.

225 Barracuda Load Balancer Administrator's Guide - Page 225 How to Reboot the System in Recovery Mode If your Barracuda Load Balancer experiences a serious issue that impacts its core functionality, you can use diagnostic and recovery tools that are available at the reboot menu to return your system to an operational state. Before you use the diagnostic and recovery tools, do the following: Use the built-in troubleshooting tools on the ADVANCED > Troubleshooting page to help diagnose the problem. Perform a system restore from the last known good backup file. Contact Barracuda Networks Technical Support for additional troubleshooting tips. As a last resort, you can reboot your Barracuda Load Balancer and run a memory test or perform a complete system recovery, as described in this section. To perform a system recovery or hardware test: Connect a monitor and keyboard directly to your Barracuda Load Balancer. Reboot the system by doing one of the following: Click Restart on the BASIC > Administration page. Press the Power button on the front panel to turn off the system, and then press the Power button again to turn the system back on. The Barracuda splash screen displays with the following three boot options: Barracuda Recovery Hardware_Test Use your keyboard to select the desired boot option, and click Enter. You must select the boot option within three seconds of the splash screen appearing. If you do not select an option within three seconds, the Barracuda Load Balancer defaults to starting up in the normal mode (first option). Reboot Options Reboot Options Barracuda Recovery Description Starts the Barracuda Load Balancer in the normal (default) mode. This option is automatically selected if no other option is specified within the first three (3) seconds of the splash screen appearing. Displays the Recovery Console where you can select the following options: Perform file system repair Repairs the file system on the Barracuda Load Balancer. Perform full system re-image Restores the factory settings on your Barracuda Load Balancer and clears out all configuration information. Enable remote administration Initiates a connection to Barracuda Central that allows Barracuda Networks Technical Support to access the system. Another method for enabling this troubleshooting connection is to click Establish Connection to Barracuda Central on the ADVANCED >Troubleshooting pag e. Run diagnostic memory test Runs a diagnostic memory test from the operating system. If problems are reported when running this option, we recommend running the Hardware_Test option next. Hardware_Test Performs a thorough memory test that shows most memory related errors within a two-hour time period. The memory test is performed outside of the operating system and can take a long time to complete. Reboot your Barracuda Load Balancer to stop the hardware test. You may do this by pressing Ctrl-Alt-Del on the keyboard. You can also reboot a Barracuda Load Balancer 240, 340 or 440 by pressing the R ESET button on the front panel of the appliance.

226 Barracuda Load Balancer Administrator's Guide - Page 226 How to Use the Internet Protocol Version 6 (IPv6) with Barracuda Load Balancer The Barracuda Load Balancer supports IPv6 as well as IPv4; this article describes how to use IPv6. To enable IPv6 support, go to the BASIC > IP Configuration page and enable it. Using the same page, assign IPv6 addresses to the relevant interfaces. Only then can you connect to an IPv6 network. The following table lists the combinations of IPv6 and IPv4 interfaces to Services and Real Servers that can be used when IPv6 is enabled: VIP Address Real Server Addresses Use Case IPv6 IPv6 Used when the complete network setup is being migrated to support IPv6 based addressing. IPv6 IPv4 Used when you wish to publish IPv6 addresses for web applications without changing the addressing in your internal network. IPv4 IPv6 Used when third party applications connecting to your applications are not yet ready to communicate via IPv6. IPv4 IPv4 Used in current deployments without any IPv6 support. IPv6 is not supported in these two areas: Connecting to the Barracuda Networks Technical Support Center via a support tunnel is not possible using IPv6 addresses. If you need to do this, make sure you have IPv4 addresses configured for the WAN and LAN IP addresses on the BASIC > IP Configuration page. IPv6 addresses cannot be configured on the Administrative Console.

227 Barracuda Load Balancer Administrator's Guide - Page 227 Tools and Add-Ins In this Section How to Use the Response Rewrite Function to Enable Web Sites for Google Analytics

228 Barracuda Load Balancer Administrator's Guide - Page 228 How to Use the Response Rewrite Function to Enable Web Sites for Google Analytics This article refers to firmware 3.1 and higher, running on a Barracuda Load Balancer 340 or higher. Response Body Rewrite rules apply to Layer 7 - HTTP Services only. This article assumes you have a Google Analytics account to obtain the code for use in the response body. Response Body Rewrite Rules The Response Body Rewrite option provides a single point for managing response rewrites to offload Google indexing to the Barracuda Load Balancer. Create rules to search and replace any string in the body of outbound responses to remove server banners or other header or body information you do not wish clients to see, to eliminate extra code in web site pages. Only responses where the content-type begins with " text/ " ( t ext/html, text/plain, text/javascript, text/css, text/xml) are searched, flash and applet content are not supported. The search and replace strings must be text; regular expressions cannot be used. Google Analytics Example This example describes how to offload Google indexing by inserting Google Analytics code into the responses by looking for a unique text string, for example, </html> or Copyright, guaranteed to appear in a page only once, for search and replace to avoid duplication. In this example, for the response body rewrite, the Google Analytics code is inserted into the responses by the ' string' guaranteed to be present in every page, which is then replaced with the ' string' + ' Google Analytics code'. To create the rule, complete the following steps: Log into the Barracuda Load Balancer as the administrator, and go to the WEBSITES > URL Rewrites page. Go to the Response Body Rewrite section. In the Rule Name field enter a name for the rule, for example: Google In the Rule Order field, enter the order of execution if there is more than one rule. Range: 1 to 128, where 1 is executed first. In the Host Match field, Enter * which will be used to match the hostname field in the request header. In the URL Match field, enter /* which will be used to match the URL field in the request header. This value means that the ACL applies for all URLs in that domain. In the Search String field, enter the unique text string to be searched, for example: </html> In the Replace String field, enter the Google Analytics code followed by the search string, for example: 8. Click Add. Related Articles Understanding URL Rewrite Rules

229 Barracuda Load Balancer Administrator's Guide - Page 229 APIs In this Section Automation API Guide API Descriptions Sample Program - Changing Real Server Status to Maintenance Mode Sample Program - Multiple Functions

230 Barracuda Load Balancer Administrator's Guide - Page 230 Automation API Guide Missing the language English in this article! Please add the language, otherwise this article can not be displayed properly.

231 Barracuda Load Balancer Administrator's Guide - Page 231 API Descriptions service.add service.delete service.show server.add server.delete server.change_state service.add This method adds a Service to the configuration database. The VIP address and port combination must be unique. Parameter name vip protocol port type Description Service name Set this to the Virtual IP address of the Service The protocol used by the Service, either TCP or UDP The port used by the Service The Service type. Supported values: L4 with protocol UDP adds a Layer 4 UDP Service L4 with protocol TCP adds a Layer 4 TCP Service L7 with protocol TCP adds a Layer 7 HTTP Service L7TCP with protocol TCP adds a TCP Proxy Service L7UDP with protocol UDP adds a UDP Proxy Service FTP with protocol TCP adds a Layer 7 FTP Service Other combinations are not valid. Adding SSL offloaded Services (e.g., Layer 7 HTTPS) is not supported. Example Result my $result; #Add a Service $result = $xmlrpc->call('service.add' {name=>'xml_rpc_test',vip=>' ',protocol=>'tcp',port=>'21', type=>'l4'}); print Dumper ($result); The output of a successful call is a hash with a value and a message. val msg 200 Service successfully added $VAR1 = { msg => Service successfully added, val => 200 }; service.delete This method deletes an existing Service from the configuration database. Parameter vip Description Set this to the Virtual IP address of the Service protocol The protocol used by the Service, either TCP or UDP port The port used by the Service

232 Barracuda Load Balancer Administrator's Guide - Page 232 Example Result my $result; $result = $xmlrpc->call('service.delete' {vip=>' ',port=>'21', protocol=>'tcp'}); print Dumper ($result); The output of a successful call is a hash with a value and a message. val msg 200 Service successfully deleted $VAR1 = { msg => Service successfully deleted, val => 200 }; service.show This method displays configuration and state information for a Service and/or a Real Server. If no parameters are entered to identify one Service or Real Server, information about all existing Services and Real Servers is returned. Parameter vip ip port show Description Optional. Set this to the Virtual IP address of the Service that this Real Server is to be associated with, followed by a colon, followed by TCP or UDP, i.e., VIP address: protocol Optional. The IP address of the Real Server The protocol used by the Service, either TCP or UDP A list of what is to be shown, separated by /. For example, to show the status of a Service and the state of a Real Server, use status/state Example Result my $result; #Show Service status and Real Server state my $service_show = 'status/state' ; $result = $xmlrpc->call('service.show', {vip=>' :21:tcp', port=> '21', ip=> ' ', show=> $service_show}); print Dumper ($result); The output of a successful call is a hash for each Service with a set of variables: Variable proto ip status name port Description TCP or UDP VIP address of the Service Service status down or up Service name Service port

233 Barracuda Load Balancer Administrator's Guide - Page 233 and a hash for each Real Server with a set of variables: Variable ip status port state Description Address of the Real Server Real Server status disabled or enabled Real Server port Real Server state maintenance, disabled, or enabled server.add This method adds a Real Server to the configuration database. It must be added to an existing Service. Parameter vip ip port Description Set this to the Virtual IP address of the Service that this Real Server is to be associated with, followed by a colon, followed by TCP or UDP, i.e., VIP address: protocol The IP address of the Real Server The port used by the Real Server Example Result my $result; #Add a Real Server $result = $xmlrpc->call('server.add', {vip=>' :21:tcp',ip => ' ',port => '21'}); print Dumper ($result); The output of a successful call is a hash with a value and a message. val msg 200 Server successfully added $VAR1 = { msg => Server successfully added, val => 200 }; server.delete This method removes an existing Real Server from an associated Service. Parameter vip ip port Description Set this to the Virtual IP address of the Service that this Real Server is associated with, followed by a colon, followed by TCP or UDP, i.e., VIP address: protocol The IP address of the Real Server The port used by the Real Server Example

234 Barracuda Load Balancer Administrator's Guide - Page 234 Result my $result; #Delete the Real Server $result = $xmlrpc->call('server.delete', {vip=>' :21:tcp',ip => ' ',port => '21'}); print Dumper ($result); The output of a successful call is a hash with a value and a message. val msg 200 Service successfully deleted $VAR1 = { msg => Server successfully deleted, val => 200 }; server.change_state This method changes the state of a Real Server to disabled, maintenance or enabled. Changing it to disabled terminates all connections immediately. When placed in maintenance mode, the Real Server keeps existing connections but does not accept any new ones. Maintenance can be performed when all active connections are closed. Parameter vip ip port action Description Set this to the Virtual IP address of the Service that this Real Server is associated with, followed by a colon, followed by TCP or UDP, i.e., VIP address: protocol The IP address of the Real Server The port used by the Real Server Set to one of the following strings: disable / enable / maintenance Example Result my $result; #Change Real Server state to (disabled / enabled / maintenance mode) $result = $xmlrpc->call('server.change_state', {vip=>' :21:tcp', port=>'21', ip => ' ', action=>'disable'}); print Dumper ($result); The output of a successful call is a hash with a value and a message. val msg 200 Server mode successfully changed $VAR1 = { msg => Server mode successfully changed, val => 200 }; Related Articles Automation API Guide Sample Program - Multiple Functions

235 Barracuda Load Balancer Administrator's Guide - Page 235 Sample Program - Changing Real Server Status to Maintenance Mode

236 Barracuda Load Balancer Administrator's Guide - Page 236 Sample Program - Changing Real Server Status to Maintenance Mode This program changes the status for a list of Real Servers to maintenance mode. It performs the following functions: For each IP address in a list, it sets the status of the Real Server to maintenance. The Barracuda Load Balancer will not direct any new client connections or requests to a Real Server in maintenance mode; It displays the Real Server state to confirm that the state has changed. Edit the IP addresses should be the WAN IP address of your Barracuda Load Balancer, is the VIP address of an existing Service, and and are the IP addresses of the Real Servers to be put into maintenance mode. You can put more Real Servers in the $server_ips list, just be sure to separate them by a comma (,). Change the password to the API password for the Barracuda Load Balancer. You can also modify this program to disable the Real Servers or make them active again by changing the value of the $action parameter to disable or enable. To run maint.pl, at a command prompt type: perl maint.pl maint.pl

237 Barracuda Load Balancer Administrator's Guide - Page 237 #!/usr/bin/perl use strict; use warnings; use XML::RPC; use LWP::UserAgent; # Service parameters my $service_ip = ' ' ; my $service_protocol = 'TCP' ; my $service_port = '80' ; # Server parameters my $server_ips = ' , ' ; my $server_port = '80' ; my $method_change = "server.change_state" ; my $action = 'maintenance' ; #disable/enable/maintenance my $service_id = "$service_ip:$service_port:$service_protocol" ; = split(",",$server_ips); my $service_show = 'status/state' ; my $result; # Create the XML::RPC object my $ua = LWP::UserAgent->new ; $ua->timeout( 60 ); my $xmlrpc = XML::RPC->new ( ' 'lwp_useragent' => $ua ); #Change Real Server status for the IP addresses in the list #to maintenance mode my $disable_parameters = { vip => $service_id, port => $server_port, action => $action }; foreach my $ip (@server_ip){ $disable_parameters->{'ip'} = $ip; print "Setting status for server $ip to $action.\n"; $result = $xmlrpc->call($method_change, $disable_parameters ); print "$result->{'msg'}\n"; } #Show the Real Server state now $result = $xmlrpc->call( 'service.show', { vip => $service_id, port => $server_port, ip => $ip, show => $service_show } ); my $instance_id = "$ip". ":". "$server_port"; print "Server status: $result->{$service_id}{$instance_id}{'state'}\n"; Related Articles Automation API Guide API Descriptions Sample Program - Multiple Functions

238 Barracuda Load Balancer Administrator's Guide - Page 238 Sample Program - Multiple Functions This program uses most of the API calls described in the article API Descriptions. It performs the following functions: Adds a Service and a Real Server; Shows the Service and Real Server state before and after setting the state of the Real Server to maintenance mode; Deletes the Real Server and the Service. You can copy and paste this code into a file and save it as sample.pl. Edit the IP addresses should be the WAN IP address of the Barracuda Load Balancer, is the VIP address of a Service, and is the IP address of a Real Server. Change the password to the API password for the Barracuda Load Balancer. To run sample.pl, at a command prompt type: perl sample.pl sample.pl

239 Barracuda Load Balancer Administrator's Guide - Page 239 #!/usr/bin/perl use strict; use warnings; use XML::RPC; use LWP::UserAgent; use Data::Dumper; my $ua = LWP::UserAgent->new ; $ua->timeout( 60 ) ; # Create the XML::RPC object my $xmlrpc = XML::RPC->new ( ' 'lwp_useragent' => $ua ); my $result; #Add a Service $result = $xmlrpc->call('service.add', {name=>'xml_rpc_test', vip=>' ', protocol=>'tcp', port=>'21', type=>'l4'}); print Dumper ($result); #Add a Real Server $result = $xmlrpc->call('server.add', {vip=>' :21:tcp',ip => ' ',port => '21'}); print Dumper ($result); my $service_show = 'status/state' ; #Show all Services and Real Servers state $result = $xmlrpc->call('service.show', {show=> $service_show}); print Dumper ($result); #Change Real Server status to maintenance mode (could be one of disable/enable/maintenance) $result = $xmlrpc->call('server.change_state', {vip=>' :21:tcp', port=>'21', ip => ' ', action=>'maintenance'}); print Dumper ($result); #Show Service status and Real Server state $result = $xmlrpc->call('service.show', {vip=>' :21:tcp', port=> '21', ip=> ' ', show=> $service_show}); print Dumper ($result); #Delete the Real Server $result = $xmlrpc->call('server.delete', {vip=>' :21:tcp', ip => ' ', port => '21'}); print Dumper ($result); #Delete the Service $result = $xmlrpc->call('service.delete', {vip=>' ', port=>'21', protocol=>'tcp'}); print Dumper ($result);

240 Barracuda Load Balancer Administrator's Guide - Page 240 Related Articles Automation API Guide API Descriptions Sample Program - Changing Real Server Status to Maintenance Mode

241 Barracuda Load Balancer Administrator's Guide - Page 241 Barracuda Load Balancer Hardware The Load Balancer appearance varies according to the device number, as described in this article. Barracuda Load Balancer 240, 340, and 440 Front Panel The following image illustrates the front components of the Barracuda Load Balancer 240, 340, and 440: Table Barracuda Load Balancer 240, 340, and 440 Front Panel. Label WAN LAN System Reserved Disk Light Power Light Description Port for WAN connection Port for LAN connection Displays system power Reserved for future use Shows disk activity Displays: Green light when the system is powered on and the power supply is healthy. Orange/Amber light = the power supply is degraded, such as, for example, one of the two PSUs is not functioning. Pushing the Reset button may solve the problem; otherwise one of the PSUs should be replaced. No light = the power supply is not working. Reset Power Button Resets the Barracuda Load Balancer Powers on/off the Barracuda Load Balancer Barracuda Load Balancer 240, 340, 440 Back Panel The following image illustrates the back panel components of the Barracuda Load Balancer 240, 340, and 440: Table Barracuda Load Balancer 240, 340, and 440 Back Panel. Component Name Power Supply Fan Mouse Port Keyboard Port Description Connection for the AC power cord; standard power supply Location of the fan Connection for the mouse Connection for the keyboard

242 Barracuda Load Balancer Administrator's Guide - Page 242 Parallel Port Monitor Port USB Ports (4) Ethernet Port Connection for the parallel cable Connection for the monitor Reserved for future use Can be used as a management port Barracuda Load Balancer 640 Front Panel The following image illustrates the front components of the Barracuda Load Balancer 640; note that the power switch is on the back of the appliance and there is no reset button: Table 3. Barracuda Load Balancer 640 Front Panel. Label Serial Power Light Description Can be used to access the administrative console. The settings are 9600/8-N- Displays: Green light when the system is powered on and the power supply is healthy. Orange/Amber light = the power supply is degraded, such as, for example, one of the two PSUs is not functioning. Pushing the Reset button may solve the problem; otherwise one of the PSUs should be replaced. No light = the power supply is not working. Disk Light USB MGMT WAN Ports Shows disk activity Reserved for future use Can be used as a management port. If there is no port with this label, use the Ethernet port on the back for management. Port for WAN connection Connect these ports to the Real Servers Table 4. Barracuda Load Balancer 640 Back Panel. Component Name Power Supply Fan Mouse Port Keyboard Port Description Connection for the AC power cord; standard power supply Location of the fan Connection for the mouse Connection for the keyboard Power Requirements AC input voltage volts Frequency 50/60 Hz

243 Barracuda Load Balancer Administrator's Guide - Page 243 Hardware Compliance Hardware Compliance This section contains compliance information for the Barracuda Load Balancer hardware. Notice for the USA Compliance Information Statement (Declaration of Conformity Procedure) DoC FCC Part 15: This device complies with part 15 of the FCC Rules. Operation is subject to the following conditions: This device may not cause harmful interference, and This device must accept any interference received including interference that may cause undesired operation. If this equipment does cause harmful interference to radio or television reception, which can be determined by turning the equipment off and on, the user in encouraged to try one or more of the following measures: Reorient or relocate the receiving antenna. Increase the separation between the equipment and the receiver. Plug the equipment into an outlet on a circuit different from that of the receiver. Consult the dealer or an experienced radio/television technician for help Notice for Canada This apparatus complies with the Class B limits for radio interference as specified in the Canadian Department of Communication Radio Interference Regulations. Notice for Europe (CE Mark) This product is in conformity with the Council Directive 89/336/EEC, 92/31/EEC (EMC). Power Requirements AC input voltage volts; frequency 50/60 Hz.

244 Barracuda Load Balancer Administrator's Guide - Page 244 Downloads Click the desired link to download a PDF version of a subset of the Barracuda Load Balancer documentation. Most documentation for Barracuda Load Balancer is found in this system by searching in the Search bar or navigating in the left menu bar. Quick Start and Guides Barracuda Load Balancer Quick Start Guide Barracuda Load Balancer API Guide SNMP Monitoring for the Barracuda Load Balancer Deployment Guides Deploying the Barracuda Load Balancer with Office Communications Server 2007 R2