Barracuda Load Balancer ADC 使用手冊

1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5
1.1 What's New in the Barracuda Load Balancer ADC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.1.1 Release Notes Version 6.1.0.004 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.1.10 Release Notes Version 5.3.0.003 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
1.1.15 Release Notes Version 5.1.0.x . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
1.2 Deployment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
1.2.1 Deployment Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
1.2.2 Choosing Your Deployment Mode and Service Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
1.2.2.1 One-Armed Using a TCP Proxy, UDP Proxy, or Layer 7 Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
1.2.2.2 TCP Proxy, UDP Proxy, or a Layer 7 Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
1.2.2.3 Two-Armed Using TCP Proxy, UDP Proxy, or a Layer 7 Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
1.2.2.4 Two-Armed with Layer 4 Load Balancing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
1.2.3 Direct Server Return Deployment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
1.2.3.1 Deploying DSR in a Microsoft Windows Server 2003 or 2008 Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
1.2.3.2 Deploying DSR in a Linux Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
1.2.3.3 Deploying DSR in Windows XP Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
1.2.4 Virtual Deployment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
1.2.4.1 How to Deploy Barracuda Load Balancer ADC Vx Images . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
1.2.4.2 How to Deploy the Barracuda Load Balancer ADC Vx . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
1.2.4.3 Allocating Cores, RAM, and Hard Disk Space for Your Barracuda Load Balancer ADC Vx . . . . . . . . . . . . . . . . . . . . 51
1.2.4.4 Barracuda Load Balancer ADC Vx Quick Start Guide . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
1.2.4.5 Backing Up Your Virtual Machine System State . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
1.2.5 Public Cloud Hosting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
1.2.5.1 Amazon Web Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
1.2.5.1.1 Barracuda Load Balancer ADC Deployment and Quick Start Guide for Amazon Web Services . . . . . . . . . . . . 62
1.2.5.1.2 Clustering the Barracuda Load Balancer ADC Instances in Amazon Web Services . . . . . . . . . . . . . . . . . . . . . 70
1.2.5.1.3 Configuring Services on the Barracuda Load Balancer ADC Vx for Amazon Web Services . . . . . . . . . . . . . . . 109
1.2.5.1.4 Creating a Link Bond on the Barracuda Load Balancer ADC Vx for Amazon Web Services . . . . . . . . . . . . . . . 111
1.2.5.1.5 Disk Expansion of the Barracuda Load Balancer ADC on Amazon Web Services (AWS) . . . . . . . . . . . . . . . . . 112
1.2.5.1.6 Troubleshooting the Barracuda Load Balancer ADC Vx on Amazon Web Services . . . . . . . . . . . . . . . . . . . . . 115
1.2.5.2 Microsoft Azure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
1.2.5.3 VMware vCloud Air Deployment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
1.3 Getting Started . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
1.3.1 Step 1 - How to Install the Barracuda Load Balancer ADC Appliance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
1.3.2 Step 2 - How to Configure the Barracuda Load Balancer ADC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126
1.3.3 Step 3 - How to Activate and Update the Barracuda Load Balancer ADC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
1.3.4 Step 4 - How to Configure Administrator Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129
1.3.5 Step 5 - How to Configure Your Network and Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130
1.4 Application Deployment Guides . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132
1.4.1 Barracuda Email Security Gateway Deployment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133
1.4.2 Barracuda Web Security Gateway Deployment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136
1.4.3 Citrix XenApp and XenDesktop Deployment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139
1.4.3.1 Citrix XenApp and XenDesktop 6.x Deployment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140
1.4.3.2 Citrix XenApp and XenDesktop 7.x Deployment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143
1.4.4 IBM Domino Social Edition Deployment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147
1.4.5 Microsoft Exchange Server 2010 Deployment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151
1.4.5.1 How to Deploy Microsoft Exchange Server 2010 in a One-Armed Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154
1.4.5.2 How to Deploy Microsoft Exchange Server 2010 in a Two-Armed Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161
1.4.5.3 How to Test the Microsoft Exchange Server 2010 Deployment Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165
1.4.6 Microsoft Exchange Server 2013 and 2016 Deployment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166
1.4.7 Microsoft Forefront Unified Access Gateway Deployment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171
1.4.8 Microsoft Lync 2010 and 2013 Server Deployment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176
1.4.8.1 Understanding Microsoft Lync Server Deployment Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178
1.4.8.2 How to Deploy with Microsoft Lync Server 2010 and 2013 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180
1.4.8.3 IP Worksheet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188
1.4.9 Microsoft Remote Access (Direct Access and VPNs) Deployment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189
1.4.10 Microsoft SharePoint Server Deployment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191
1.4.11 Microsoft Windows AD FS Deployment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195
1.4.12 Moodle Deployment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198
1.4.13 Remote Desktop Services Deployment (Including Remote Desktop Gateway) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202
1.4.13.1 Remote Desktop Services Configuration When the Session or Connection Broker Is Deployed . . . . . . . . . . . . . . . . 209
1.4.14 VMware Horizon View Deployment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 211
1.5 Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 220
1.5.1 How to Create a Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221
1.5.2 Persistence Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222
1.5.3 How to Configure Service Groups and Service Group Persistence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224
1.5.4 Layer 4 TCP and Layer 4 UDP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225
1.5.5 TCP Proxy, Secure TCP Proxy, and UDP Proxy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 226
1.5.6 HTTP Service and HTTPS Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 227
1.5.7 Instant SSL Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 230
1.5.8 FTP and FTP SSL Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231
1.5.9 Layer 7 RDP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232
1.5.10 SSL Offloading . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233
1.5.11 How to Enable HTTP/2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234
1.5.12 How to Secure Communication with Real Servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 235
1.5.13 How to Select a Scheduling Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 236
1.5.14 How to Configure Adaptive Scheduling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 238
1.6 Access Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 241
1.6.1 How to Integrate an External Authentication Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242
1.6.2 How to Configure Access Control (AAA) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 246
1.6.3 How to Configure Single Sign-On (SSO) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 259
1.6.4 How to Set Up a Custom Login Page for Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 261
1.6.5 How to Configure SMS Passcode Authentication Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263
1.6.6 How to Set Up a Custom Challenge Page for Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 264
1.7 Technical White Papers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 266
1.7.1 PCI Compliance Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 267
1.8 Traffic Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273
1.8.1 Content Rules for HTTP and HTTPS Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 274
1.8.2 Extended Match and Condition Expressions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 275
1.8.3 Understanding HTTP Rewrite Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 279
1.8.4 Content Rewriting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 284
1.8.5 Example - Using Response Body Rewrite to Enable Web Sites for Google Analytics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 287
1.8.6 Understanding HTTP Caching . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 288
1.8.7 Understanding HTTP Compression . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 289
1.9 Logging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 290
1.9.1 How to Configure Syslog and other Logs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 291
1.9.2 How to Make the Client IP Address Available to the Back-end Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 294
1.9.2.1 Logging Actual Client IP Address In the IIS 7 and IIS 7.5 Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 297
1.9.2.2 Logging Actual Client IP Address on the Apache Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 298
1.9.3 How to Mask Sensitive Data in Logs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 299
1.9.4 Viewing Logs on the Barracuda Load Balancer ADC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 300
1.9.5 System Log Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 301
1.10 Global Server Load Balancing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 321
1.10.1 Global Server Load Balancing Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 322
1.10.2 Installing Global Server Load Balancing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 326
1.10.3 Integrating Global Server Load Balancing with the Existing DNS Infrastructure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 329
1.10.4 Implementing Global Server Load Balancing Regions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 330
1.11 Application Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 331
1.11.1 Security Policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 332
1.11.1.1 Configuring Cloaking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 333
1.11.1.2 Configuring Data Theft Protection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 334
1.11.1.3 Configuring Global ACLs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 335
1.11.1.4 Configuring Parameter Protection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 336
1.11.1.5 Configuring Request Limits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 337
1.11.1.6 Configuring the Action Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 338
1.11.1.7 Configuring URL Normalization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 339
1.11.1.8 Configuring URL Protection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 340
1.11.1.9 Securing HTTP Cookies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 341
1.11.2 Slow Client Attack Prevention . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 342
1.11.3 Configuring Website Profiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 343
1.11.4 How to Configure Antivirus Protection for File Uploads and Downloads . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 346
1.11.5 How to Configure Data Theft Protection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 347
1.11.6 How to Configure Brute Force Prevention . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 349
1.11.7 How to Configure Session Tracking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 350
1.11.8 Allow/Deny Rules for Headers and URLs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 351
1.11.8.1 Allow/Deny Rules for Headers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 352
1.11.8.2 Allow/Deny Rules for URLs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 353
1.11.9 Extended Match Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 354
1.11.10 Configuring User Defined Patterns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 356
1.11.10.1 Regular Expression Notation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 360
1.12 Networking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 362
1.12.1 Creating Static Routes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 363
1.12.2 Adding Custom Virtual Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 364
1.12.3 Network Address Translation NAT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 365
1.12.4 How to Use IPv6 with Barracuda Load Balancer ADC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 366
1.12.5 Multiport Link Aggregation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 367
1.12.6 VLANs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 369
1.12.7 Network Access Control Lists . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 370
1.12.7.1 How to Configure an IP Reputation Pool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 371
1.12.8 How the Barracuda Load Balancer ADC Selects the Source IP Address . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 372
1.12.9 Subnetwork Masks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 373
1.13 Certificate Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 374
1.13.1 How to Add an SSL Certificate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 375
1.13.2 Installing SSL Certificates with Correct Chain Order . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 377
1.13.3 How to Pass Client Certificate Details to a Back-end Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 379
1.13.4 Allowing or Denying Client Certificates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 381
1.13.5 Client Certificate Validation Using OCSP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 382
1.13.6 Creating a Client Certificate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 383
1.14 Monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 385
1.14.1 How to View System Health, Status, and Statistics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 386
1.14.2 Monitoring the Health of Services and Servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 387
1.14.2.1 How to Create Monitor Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 388
1.14.2.2 Understanding Testing Methods for Services and Real Servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 389
1.14.3 Reporting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 392
1.14.3.1 Traffic Reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 393
1.14.3.2 Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 396
1.14.3.3 PCI DSS Reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 397
1.14.3.4 Configuration Summary Reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 398
1.14.3.5 Administration/Audit Reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 399
1.14.4 How to Automate System Alert and SNMP Trap Delivery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 400
1.14.5 How to Configure SNMP Monitoring on the Barracuda Load Balancer ADC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 401
1.14.6 SNMP Objects and Traps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 402
1.14.7 How to Enable, Disable, and Maintain Real Servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 416
1.14.8 How to Remotely Administer Real Servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 418
1.14.9 How to View System Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 419
1.15 High Availability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 420
1.15.1 Understanding Barracuda Load Balancer ADC High Availability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 421
1.15.2 How to Configure the Barracuda Load Balancer ADC for High Availability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 422
1.15.3 How to Manage a High Availability Environment with Two Barracuda Load Balancer ADCs . . . . . . . . . . . . . . . . . . . . . . . . 423
1.15.4 How to Remove a Barracuda Load Balancer ADC from a High Availability Environment . . . . . . . . . . . . . . . . . . . . . . . . . . 424
1.15.5 How to Replace a Barracuda Load Balancer ADC in a High Availability Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 425
1.15.6 How to Update the Firmware on Clustered Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 427
1.15.7 High Availability - Firewall Failover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 428
1.16 System Administration and Maintenance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 429
1.16.1 How to Reload, Restart, and Shut Down the System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 430
1.16.2 How to Configure Administrator Access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 431
1.16.3 How to Update Definitions Under Energize Updates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 434
1.16.4 How to Update and Revert the Firmware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 436
1.16.5 How to Back Up and Restore Your System Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 438
1.16.6 How to Reboot the System in Recovery Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 439
1.16.7 How to Replace a Failed System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 440
1.16.8 Troubleshooting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 441
1.16.9 How to Migrate from the Barracuda Load Balancer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 442
1.17 Barracuda Load Balancer ADC - REST API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 444
1.18 Barracuda Load Balancer ADC Hardware Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 445
Barracuda Load Balancer ADC Administrator's Guide - Page 5
Overview
The Barracuda Load Balancer ADC is a unified high-performance platform that helps organizations achieve their availability, acceleration,
application control, and application security objectives.
Where to Start
Download the Barracuda Load Balancer ADC Quick Start Guide in English, German, or Japanese.
For detailed instructions on installing the Barracuda Load Balancer ADC hardware or the on how to install the virtual appliance, see Getting
Started.
Application Deployment Guides

Barracuda Email Security Gateway Deployment
Barracuda Web Security Gateway Deployment
Citrix XenApp and XenDesktop Deployment
IBM Domino Social Edition Deployment
Microsoft Exchange Server 2010 Deployment
Microsoft Exchange Server 2013 and 2016 Deployment
Microsoft Forefront Unified Access Gateway Deployment
Microsoft Lync 2010 and 2013 Server Deployment
Microsoft Remote Access (Direct Access and VPNs) Deployment
Microsoft SharePoint Server Deployment
Microsoft Windows AD FS Deployment
Moodle Deployment
Remote Desktop Services Deployment (Including Remote Desktop Gateway)
VMware Horizon View Deployment
Key Features
Load balancing with dynamic scheduling and advanced monitoring capabilities
SSL offloading, TCP connection pooling and caching, and compression to help accelerate application delivery
Content-based routing to provide fine-grained application control
Integrated application security to protect against application level attacks including the OWASP Top 10 risks
Protection against theft of sensitive and confidential data
Publish
Copyright © 2017, Barracuda Networks Inc.

What's New in the Barracuda Load Balancer ADC
What's New in Version 6.1
HTTP/2 Protocol over HTTPS: Support has been added for the HTTP/2 protocol over HTTPS.
Microsoft Azure: The Barracuda Load Balancer ADC is now available on Microsoft Azure.
High Availability: The Barracuda Load Balancer ADC on AWS now supports clustering across two availability zones for increased resilience and
high availability.
Auto Scaling Groups: Support has been added for configuring auto scaling groups as back-end servers in AWS.
For detailed information on the fixes and enhancements that are included in Barracuda Load Balancer ADC version 6.1, see:
Release Notes Version 6.1.0.004

Barracuda Load Balancer ADC models 641 and 642: The latest versions of Barracuda Load Balancer ADC models 641 and 642 leverage
specialized hardware to accelerate SSL transactions. These models now have dual power supplies.
Connection Logs: You can now use connection logs to display information about the connections made to the configured services and to the
associated servers.
Reporting: A new reporting module has been introduced to the Barracuda Load Balancer ADC with more than 25 reports and built in drill down
functions.
Source IP Persistence: Source IP Persistence support has been added at the Service Group level.
Static Source IP Addresses: You can now configure a static source IP address to connect to the real servers.
RBAs: Role Based Administrators (RBAs) are now supported.
Augmented SSL Capabilities:
Subject Alternative Names (SAN) certificate creation

SSL Session Resumption
Strict Transport Security (HSTS)
SSL Session ID Persistence

Barracuda Web Security Gateway service: Enables you to load balance traffic across multiple Barracuda Web Security Gateways (previously
Barracuda Web Filter).
VMware VDI over HTTPS and PCoIP: VMware Virtual Desktop Infrastructure (VDI) over HTTPS and Personal Computer over Internet Protocol
(PCoIP) is now supported.

SSL Hardware Support: SSL hardware support is now available.


SSL Enhancements: Perfect Forward Secrecy (PFS) with ECDSA and RSA certificates and associated ciphers are now supported. The key
exchange mechanism supported is Elliptic Curve DHE. These SSL enhancements are increasingly relevant in a post-Snowden world. With PFS,
communications intercepted today can never be decrypted, even far into the future, due to the ephemeral nature of the PFS scheme. You can
also customize backed SSL, including SNI extensions in the TLS header if the server requires this to be enabled. Supports Certificate Revocation
List (CRL) and OCSP validation for client certificates. And supports Intel QuickAssist Technology for SSL acceleration in the Barracuda Load
Balancer ADC 840 and above.
Traffic Management Enhancement: The Redirect Rule feature is now supported in the Barracuda Load Balancer ADC 340 and 440.
Load Balancer Migration Enhancement: You can now configure the WAN IP address, network mask, and gateway when restoring the
Barracuda Load Balancer 4.x backup file to the Barracuda Load Balancer ADC
Authentication and Authorization: Barracuda Load Balancer ADC models 540 and above can be integrated with an external authentication
server for client authentication. LDAP, RADIUS and Kerberos authentication protocols are supported. You can create authorization policies that
control access by authenticated users to web applications.
Application Security: The Application Security subscription, which adds Layer 7 security to your existing HTTP-, HTTPS-, FTP- or FTPS-based
applications, is being made available at no charge to all ADC customers on models 540 and above. Configure security policies using the pages
under the SECURITY tab.
Support for Barracuda Load Balancer Configuration: You can restore backup files from a Barracuda Load Balancer to a new ADC system.
Networking: Policy-based routing to route packets on a specific interface. You can add policy-based routing rules on the NETWORK > Routes
page.
User Interface
The BASIC > Services page makes it easier to add, edit, and view services and servers. You can view and update every option when
you add a service or a server. If you have similar services, you can use the settings of one service as a starting point when creating a
new service. And, as before, you can view the status of all services and real servers at a glance.
The BASIC > Status and SECURITY > Security Policies pages also have a new layout.
The web interface has a new color scheme and improved look and feel.
An Instant SSL service (that redirects an HTTP connection to an HTTPS service) appears as only one service in the user interface. An
Instant SSL service includes both the service port and the redirect port.

Release Notes Version 5.1.0.x

Before installing any firmware version, back up 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 update unless otherwise instructed by Barracuda Technical
Support. Depending on your current firmware version and other system factors, updating can take up to 10 minutes. If the process
takes longer, contact Barracuda Technical Support for further assistance.
Known Issues
In the High Availability environment, deleting a Layer 4 service or editing the server associated with the Layer 4 service in the Passive
unit is not handled properly in the backend. It is recommended to perform these operations on the Active unit. [BNADC-5795]
Due to known issues, the SSL hardware option is disabled in the Barracuda Load Balancer ADC 640 and 840. The administrator can
manually enable the SSL hardware functionality (if required). [BNADC-8689]
Fixes
False Energize Update Expired alert emails are not generated when the unit is offline. This issue has been addressed. [BNADC-8599]
Adding a new line in the Comments text box for Attack Types resulted in a configuration rollback. This issue has been addressed.
[BNADC-8614]
The data path crash when the Response Body Rewrite rule was configured for a service, has been fixed. [BNADC-8656]
The data path crash in HTTP2 traffic has been fixed. [BNADC-8657]
A GET query for service groups can now be executed without a forward slash in the REST API URL. [BNADC-8702]

Features
Support has been added for the HTTP/2 protocol over HTTPS. [BNADC-7208]
The Barracuda Load Balancer ADC is now available on Microsoft Azure. [BNADC-7721]
The Barracuda Load Balancer ADC on AWS now supports clustering across two availability zones for increased resilience and high
availability. [BNADC-8017]
Support has been added for configuring auto scaling groups as back-end servers in AWS. [BNADC-8353]
Enhancements
High Availability now supports automatic failover in case a critical process fails on an active device. [BNADC-1485]
Server health checks now support HTTP/1.0 and HTTP/1.1. [BNADC-5632]
The internal platform utilities and kernel have been upgraded. [BNADC-6461]
LDAP nested groups across different domains are now supported. [BNADC-7595]
Support for the AWS proxy protocol in WebSocket has been added and a known issue with backend SSL over WebSocket has been
addressed. [BNADC-7613]
The FTP access log can now be exported instantly. [BNADC-8408]
Fixes
Global Server Load Balancing (GSLB) can now process traffic without interruption. [BNADC-7021]
The serial number of the clustered peer Barracuda Load Balancer ADC is now displayed on the ADVANCED > High Availability page in
the Clustered System section. [BNADC-7101]
Both units in a high availability cluster are in the active state. This has been addressed. [BNADC-7134]
You can now specify the maximum number of times a user can attempt to authenticate. [BNADC-7392]
When starting Instant SSL with an existing HTTP service, there are duplicate database variables. This has been addressed.
[BNADC-7471]
A report is now being sent when an SMTP sever is configured with a user name and password. [BNADC-7866]
A character is being removed while completing a SharePoint rewrite. This has been addressed. [BNADC-7933]
Dual Authentication is now supported with LDAP as the primary authentication service and Radius as the secondary authentication
service. [BNADC-8022]
The initial characters of a certificate name can now include numbers. [BNADC-8137]
If you set Enable High Availability to Yes, the default value for Failback Mode is now set to Manual. [BNADC-8155]
Changing the service type from INSTANT SSL to HTTP/HTTPS and then back to INSTANT SSL now correctly creates the Redirect
service. [BNADC-8422]
After upgrading the firmware, the system failed to reboot due to a networking issue. This has been addressed. [BNADC-8449]
If the LDAP authentication service's default role is changed by the administrator in the ADVANCED > Admin Access Control page, the
role of LDAP mapped users is not changed. [BNADC-8453]
The domain name can now be sent along with the username to the Radius server for user authentication. [BNADC-8598]

Fixes
The wildcard character asterisk (*) is now allowed while configuring SNI domains. For example, *.abc.com [BNADC-7923]
HTTP Strict Transport Security (HSTS) is now available on all Barracuda Load Balancer ADC models. [BNADC-7907]
If the FTP access log is configured, all temporary access log files are cleared after transmitting the log files to the FTP server.
[BNADC-7943]
Processing HTTP headers in requests no longer triggers errors. [BNADC-7906]
For all web browsers, web pages are now served properly even after refreshing the page. [BNADC-7927]

Features
The Barracuda Load Balancer ADC now supports WebSocket traffic. With WebSocket support, the Barracuda Load Balancer ADC
behaves as a pass through proxy and does not intercept or analyze the traffic. [BNADC-3411]
It is now possible to add a client source port using the SRC_PORT macro under HTTP Request Rewrite on the TRAFFIC > Web
Translations page. [BNADC-7378]
Enhancements
The Element Type list under Extended Match now includes SSL-Version. [BNADC-6205]
The Barracuda Load Balancer ADC now sets the Max-Age and Expires attributes in HTTP requests to ensure all web browsers honor
the cookie expiry time. [BNADC-7405]
You can now configure whether or not to forward the persistent client connections to the backup or maintenance server when the real
server is up. [BNADC-6216]
Client and server details are now included in the server certificate validation error logs. [BNADC-7733]
You can now enable or disable SSL Error Logs for services and servers. [BNADC-7804]
Known Issue
For High Availability deployments, deleting a Layer 4 service or editing the server associated with the Layer 4 service in the Passive unit
is not handled properly in the backend. Barracuda recommends performing these operations on the Active unit. [BNADC-5795]
Fixes
DHE/ECDHE cipher support is enabled for backend SSL on SSL accelerator hardware. [BNADC-6687]
The HTTPS traffic interruption issue on 6.0 firmware with a hardware SSL accelerator has been addressed. [BNADC-7596]
The URL in the Recommended Fix for URL Profile now displays the complete URL path. [BNADC-7526]
The complete certificate chain for ECDSA certificate is now displayed during the SSL handshake. [BNADC-7539]
An increase in data path memory usage causing instability in the lower-end Barracuda Load Balancer ADC models has been addressed.
[BNADC-7631]
The status of clustered systems on virtual machines is now correctly displayed on the BASIC > Dashboard page. [BNADC-7058]
A possible race condition that interrupted the data path traffic when servers were marked down while serving the traffic has been
addressed. [BNADC-7693]

Enhancement
The Barracuda Load Balancer ADC now supports the ActiveSync Login Method in the authorization policy. [BNADC-7340]
Fixes
Adding Allowed Users/Groups in the authorization policy resulted in a configuration rollback. [BNADC-7379]
The Server Health page is now optimized to handle very large configurations. [BNADC-7338]
Querying SNMP Object Identifiers (OIDs) now provides accurate statistics. [BNADC-7414] [BNADC-7546] [BNADC-7495]
An issue with CRL Auto Update has been fixed. [BNADC-7385]
Invalid SSL ticket/SSL handshake can now be successfully completed with a new SSL session ticket. [BNADC-7434]
An Issue with GSLB NS records for external domain has been fixed. [BNADC-7393]
Changing the Service Type from HTTPS to Instant SSL now creates a redirect service. [BNADC-7299]
IPv6 servers using upper case letters in the IP address can now be edited or deleted. [BNADC-7506]
There was an issue where Source IP To Connect was automatically populated value after upgrading to version 6.0.0.005. Now, you can
explicitly configure Source IP To Connect after the upgrade. [BNADC-7431]
A memory leak due to SNMP requests has been fixed. [BNADC-5032]
The OpenSSL vulnerabilities mentioned in CVE-2016-2106 and CVE-2016-2107 have been addressed. [BNADC-7509]
In firmware version 6.0.0.005, processing HTTP traffic spiked the data path memory and caused the system to hang. [BNADC-7504]
The TLS server name extension is now sent properly when backend SNI is enabled for HTTPS services. [BNADC-7314]

Do not manually reboot your system at any time during an update unless otherwise instructed by Barracuda Technical Support.
Depending on your current firmware version and other system factors, updating can take up to 10 minutes. If the process takes longer,
contact Barracuda Technical Support for further assistance.
Fixes
An issue that marked the servers Null when the Barracuda Load Balancer backup was restored to the Barracuda Load Balancer ADC
has been fixed. [BNADC-7128]
There was an issue with email notifications when a server/service was disabled. [BNADC-7158 BNADC-7165]
A disk space issue in storing virus definitions has been resolved. [BNADC-6981]
The server health pages are optimized to handle more rule group servers. [BNADC-7283]
There was an Issue with client impersonation. [BNADC-7173 BNADC-7201]
There was an issue where the memory usage increased exponentially when the Servers were configured with Hostnames.
[BNADC-5621]
There was an issue where the Temporarily Unavailable page was displayed when clicking the Show ARPs button on the ADVANCED
> Troubleshooting page. [BNADC-7269]
System memory utilization has been optimized in the Barracuda Load Balancer ADC 340 and 440. [BNADC-7263]
The action policy configuration is now applied if Invalid Charset attack/violation is detected in the content routing rule. [BNADC-7218]
In a race condition, the configuration change was not getting updated in the user interface due to the configuration update module getting
locked unexpectedly. [BNADC-7026]
The port speed negotiation settings were incorrectly displayed as Unknown even though the speed was negotiated successfully.
[BNADC-7286]

Features
The latest versions of Barracuda Load Balancer ADC models 641 and 642 leverage specialized hardware to accelerate SSL
transactions. In addition, these models also have dual power supplies.
To accommodate this additional hardware, the network interface ports have been rearranged. Now the 1GB ports are in first eight slots
and the 10GB ports are in the next two slots (from left to right). [BNADC-6627]
You can now use connection logs to display information about the connections made to the configured services and to the associated
servers. This feature is available in the Barracuda Load Balancer ADC 540 and higher.
A new reporting module has been introduced to the Barracuda Load Balancer ADC with more than 25 reports and built in drill down
functions.
Source IP Persistence support has been added at the Service Group level. [BNADC-6316]
Administrators can now configure a static source IP address to connect to the real servers. [BNADC-3836]
Roll Based Administrators (RBAs) are now supported.
Augmented SSL Capabilities:
Subject Alternative Names (SAN) certificate creation
SSL Session Resumption
Strict Transport Security (HSTS)
SSL Session ID Persistence
Enhancements
Global Server Load Balancing (GSLB):

CNAME, SRV, and TXT record types have been added to GSLB services. [BNADC-3373]
GSLB statistics can now be queried using an SNMP request. [BNADC-4358]
The Barracuda Load Balancer ADC now supports the following Diffie-Hellman Ephemeral (DHE) cipher suites:
DHE-RSA-AES256-SHA256
DHE-RSA-AES256-SHA
DHE-RSA-CAMELLIA256-SHA
DHE-RSA-AES128-GCM-SHA256
DHE-RSA-AES128-SHA256
DHE-RSA-AES128-SHA
DHE-RSA-CAMELLIA128-SHA
[BNADC-6663]
Fixes
The RDP_IN_DATA and RDG_OUT_DATA HTTP methods are now available to support Remote Desktop Gateway configuration.
[BNADC-3206]
For GSLB services, you can now configure a private monitoring IP address when the published site IP address is a public IP address.
[BNADC-3207]
You can now configure high availability between 2 Barracuda Load Balancer ADCs only when they are on same network. [BNADC-4635]
The TCP dump function located on the on ADVANCED > Troubleshooting page now allows user to select a VLAN interface.
[BNADC-5173]
The Redirect URL now supports the %d option to copy the domain name from the HTTP request. [BNADC-5223]
Access logs can be exported to external FTP servers multiple times a day. [BNADC-5430]
You can now export the FTP access logs multiple times a day. You can also now set the time of the day to export the FTP access logs.
[BNADC-5430]
The Web User Interface for the Cookie Encryption Key has been improved to allow you to generate and save encryption keys on the
Barracuda Load Balancer ADC. [BNADC-5637]
Under certain scenarios, the Barracuda Load Balancer ADC went into Passive-Passive state when you changed the failback mode to
Automatic. [BNADC-6141]
There was an issue when editing the service IP address resulted in the deletion of the configured default gateway. [BNADC-6374]
There was an issue when attempting to delete the default gateway while editing the service IP address. [BNADC-6374]
The Backup server started to function as a normal server if the Back Server Status for the Layer 4 service was enabled. [BNADC-6381]
There was an issue with backup server functionality when toggling the server status for Layer 4 TCP services. [BNADC-6381]

The high availability failover and failback time has been improved on Barracuda Load Balancer ADC Vx appliances with large
configurations. [BNADC-6449]
There was an issue causing a data path outage when the POST parameter name exceeded 2M. [BNADC-6457]
The status of the GSLB request handler process is now monitored. [BNADC-6606]
The Mismatched IP Cookie Replay Attack logs were being generated on the BASIC > Web Firewall Logs page even when the
Cookie Replay Protection Type was set to None. [BNADC-6618]
There was an issue causing a data path outage when the configuration of an SSL-enabled server was edited. [BNADC-6666]
The OpenSSL fix for CVE-2015-3194 has been applied. [BNADC-6700]
There was an issue with not getting the correct client IP address if the Header for Client IP Address was chosen and the header
occurred after sixteen other HTTP headers. [BNADC-6738]
The server status in the web interface now displays the correct data when a real server goes up or down. [BNADC-6789]
The performance of the Barracuda Load Balancer ADC's UDP proxy has been improved. [BNADC-6812] [BNADC-6816] [BNADC-6817]
There was an issue causing VDI connections to hang and timeout. [BNADC-6814]
There was a memory leak when processing POST requests with the content type multipart/form-data. [BNADC-6940]
There was a memory leak during heavy web-firewall logging. [BNADC-6949]
Deprecated Operations and Known issues
The HTTP Slow and HTTPS Slow testing methods configured on the BASIC > Services page and on the TRAFFIC > Monitor Groups
page have been deprecated. Instead, use the HTTP and HTTPS server monitor tests respectively. [BNADC-5037]
Due to the changes to logging and monitoring framework, existing logs are not visible in the UI.
Barracuda Load Balancer platform 2 device’s configuration cannot be uploaded on Barracuda Load Balancer ADC devices for this
version of the firmware. To work around this issue, the customer is requested to upload the backup on the Barracuda Load Balancer
ADC firmware version 5.4 or earlier before upgrading to version 6.0.
Under some situations, enabling connection logs for Layer 4 services does not take effect. For these cases, please disable connection
logs and enable it again.

Features
Barracuda Load Balancer ADC 340, 440, and 540 have been doubled the number of Ethernet interfaces to improve the system
throughput. [BNADC-5860]
Enhancement
Default cores for Barracuda Load Balancer ADC Vx models 4xx, 5xx and 6xx are now updated to 4, 5 and 6 cores respectively.
[BNADC-6489]
Fixes
Data path outage issue that occurred due to POST parameter name exceeding 2 megabytes, has been fixed. [BNADC-6457]
Cluster Shared Secret can now include a # (hash) character. [BNADC-6409]
Values of Active servers/services retrieved through SNMP GET now matches with the values displayed on the Barracuda Load Balancer
ADC web interface. [BNADC-6354]
When a server associated with an HTTP service is disabled, an alert message is now logged only once in barracuda.log. [BNADC-6349]
Setting the Testing Method to HTTP and adding the XML data in HTTP Method Body for HTTP Method POST resulted in server
configuration being blank. This issue has been fixed. [BNADC-6511]
Selecting the Testing Method to SMTP/Barracuda Spam Firewall (BSF) no longer displays a target value error. [BNADC-6351]
In rare cases, Actions under servers on the BASIC > Services page displayed as undefined instead of actual actions. This issue has
been fixed. [BNADC-4781]
Test Configuration on the BASIC > Administration > Email Notifications page now displays the proper output. [BNADC-3873]
The scheduled backup feature related configuration items were not synchronized to the peer system in an HA cluster. Administrators can
configure these settings independently. This issue has been fixed. [BNADC-5801]
A logs storage issue has been fixed. [BNADC-6327]
An issue where a backend server that was responding to health probes successfully was getting displayed as being down in the web
interface after a cluster failback/failover event. This issue has been fixed. [BNADC-5779]
An issue where one of the monitoring daemons was running multiple times has been fixed. [BNADC-6515]
An issue where the routing table was getting altered incorrectly while creating services with the same IP address has been fixed.
[BNADC-6374]

Features
Added support for the Barracuda Web Security Gateway (previously Barracuda Web Filter) service that enables you to load balance
traffic across multiple Barracuda Web Security Gateways. [BNADC-4888]
Added support for VMware VDI over HTTPS and PCoIP. [BNADC-5072/BNADC-3626]
Fixes
Modifying an action policy is possible only when you provide the proper attack ID and group ID in REST API. [BNADC-2639]
Chunk encoded requests/responses that contain chunk extensions in the chunk header are now forwarded to the client/server.
[BNADC-3389]
The VM license token is retained even after the system is clustered. [BNADC-4527]
UDP Proxy service now gracefully handles zero length UDP packets. [BNADC-5416]
The limit for Replace String has been increased to 1024 characters in the Response Body Rewrite rule. [BNADC-5689]
The log storage mechanism is modified to improve the disk space usage. [BNADC-5796]
The Policy Fix and Exception Profiling Fix now correctly handles Maximum Instance of Parameter Exceeded attacks. [BNADC-5819]
The Policy Fix in the Web Firewall Logs now displays correctly when the parameter name includes a quote character. [BNADC-5820]
The Policy Fix wizard now correctly displays the parameter profile of requests with a colon character (:) in the parameter name.
[BNADC-5821]
An issue that caused services to go down when load balancing FTP traffic, has been fixed. [BNADC-5840]
The LDAP authentication framework is enhanced to support usernames with a backslash and other special characters. [BNADC-5897]
Unicode characters are now handled in Server Monitoring for HTTP/HTTPS test methods. [BNADC-5921]
Configuration changes are now applied properly to servers with names that overlap with another server name. [BNADC-5964]
It is now possible to create multiple content rules with overlapping names. [BNADC-5982]
An unusual case where the server monitoring file was corrupted causing servers associated with Layer 4 services to be displayed down
in the web interface, has been fixed. [BNADC-6066]
HTTP chunk encoded data no longer causes services to go down. [BNADC-5931]

Fixes
Changing a HTTPS/INSTANT SSL service to Secure TCP Proxy with SNI configured on the associated server now works properly.
[BNADC-5837]
The HTTP compression issue in Version 5.2 and 5.3 has been resolved. [BNADC-5847]

By default, SSL 3.0 is enabled due to the wide use of the protocol. Since SSL 3.0 is vulnerable to the POODLE
(CVE-2014-3566) attack, Barracuda recommends that you disable SSL 3.0 for all SSL services configured on the Barracuda
Load Balancer ADC.
Barracuda also recommends that you use the server IP address when configuring a server, as a server configured with the
hostname might not resolve to the proper server IP address in some cases.
Features
SSL hardware support is now available.
Fixes
Certificates with an expiration date after 2037 had issues when being uploaded to the Barracuda Load Balancer ADC. [BNADC-3026]
Logs counted on the BASIC > Status page consumed greater than expected CPU time, resulting in the system hanging or crashing.
[BNADC-3061]
The failover/failback time in the High Availability environment has been enhanced to handle large configurations. [BNADC-3534]
It is now possible to change an HTTP/HTTPS service to an INSTANT SSL service with content rules configured in it. [BNADC-3795]
The server monitoring process now retains the previous state of servers (Up or Down) if it is unable to perform the test. [BNADC-4269]
Services are now created with the enabled status only. [BNADC-4480]
The Cookie Path and Client IP Header fields no longer display example values and X-Forwarded-For respectively, since these values
could be confused with the default values. These fields are now kept blank. [BNADC-5270]
An issue that automatically enabled cookie security when URL redirect was configured on the Barracuda Load Balancer 340 and 440 has
been fixed now. [BNADC-5284]
Enabling/Disabling the TCP time stamp through the web interface is now reflected in the back-end. [BNADC-5370]
The Enable SSL Compatibility Mode feature was added to the server configuration to enable or disable cipher suits for the server.
BNADC-5379
Disabling the server on the Barracuda Load Balancer ADC web interface was not applied to the back-end. A recovery mechanism added
to the server monitoring process resolves this issue. [BNADC-5390]
Monitor Group is now supported for Global Server Load Balancing (GSLB) services. [BNADC-5402]
There is no longer a memory leak issue when changing the configuration. [BNADC-5404]
The hostname no longer resolves to a new server IP address, setting the server Status to Down in the web interface. [BNADC-5424]
The Barracuda Load Balancer ADC now accepts larger sized certificates associated with the SNI domain. [BNADC-5607]
For High Availability, failover/failback ALERTS and TRAPS are now sent even if the system assumes the same state (Active) after
recovering. [BNADC-5655]
An issue with the Simple HTTP/HTTPS server monitor test is now fixed. [BNADC-5675]
An issue that prevented the deletion of a renamed service is now fixed. [BNADC-5683]
An issue with the cookie update interval is now fixed. [BNADC-5691]
The Active-Active issue for High Availability is fixed. [BNADC-5702]
A faulty internal process no longer causes the system to use 99% of the CPU. [BNADC-5723]
During the migration process from Barracuda Load Balancer Version 4.2.3.004 to Barracuda Load Balancer ADC Version 5.x, the
persistence cookie parameters are now transferred properly. [BNADC-5742]
Users are now being redirected to the page specified in Auth Password Expired URL on the ACCESS CONTROL > Authentication pag
e when the password expires. [BNADC-5764]


By default, SSL 3.0 is enabled due to the wide use of the protocol. Since SSL 3.0 is vulnerable to the POODLE
(CVE-2014-3566) attack, Barracuda recommends that you disable SSL 3.0 for all SSL services configured on the Barracuda
Load Balancer ADC.
Barracuda also recommends that you use the server IP address when configuring a server, as the server configured with the
hostname might not resolve to the proper server IP address in some cases.
Features
Server Name Indication (SNI) extension can be enabled in the TLS header for backend SSL if server requires. [BNADC-2761]
Supports Mime Types to validate uploaded file extensions. [BNADC-2083]
Supports Certificate Revocation List (CRL) validation for client certificates. [BNADC-3039]
Supports Online Certificate Status Protocol (OCSP) validation for client certificates. [BNADC-3301]
Supports Intel QuickAssist Technology for SSL acceleration in the Barracuda Load Balancer ADC 840 and above. [BNADC-3353]
For a Layer-7 HTTP/HTTPS service, if all servers are down, then the custom error response page to be displayed to the client can be
configured by the administrator. [BNADC-3664]
You can now select if you want to retain the configuration or clear the configuration from the system when the unit is being removed from
the cluster. [BNADC-3375]
Certificates and Certificate Signing Request (CSR) now use SHA-256 digest for signing. [BNADC-4573]
SSL and TLS negotiated versions are now displayed for SSL connections in the BASIC > Access Logs page. [BNADC-4806],
[BNADC-4909]
The Barracuda Load Balancer ADC supports Perfect Forward Secrecy with ECDSA and RSA certificates and associated ciphers. The
key exchange mechanism supported is Elliptic Curve DHE. [BNADC-3041]
Enhancements
The Redirect Rule feature is now supported in the Barracuda Load Balancer ADC 340 and 440. [BNADC-4604]
You can now configure the WAN IP address, network mask, and gateway when restoring the Barracuda Load Balancer 4.x backup file to
the Barracuda Load Balancer ADC. [BNADC-4436]
Fixes
When an SSL service was changed to non-SSL service, the certificate associated with the server was not getting deleted from the
backend. Hence, the administrator was unable to delete the certificate on the BASIC > Certificates page. This issue has been fixed
now. [BNADC-3042]
The Location Definition is now displayed for the Barracuda Load Balancer ADC 340. [BNADC-3773]
There is now a UI option to enable and disable TCP timestamps. [BNADC-3960]
The RC4-MD5 cipher is now listed in Available Ciphers. [BNADC-4192]
A predefined policy "ibm_domino" is now available for the IBM Domino server on the SECURITY > Security Policies page.
[BNADC-4206]
The test delay setting configured by the admin for monitoring the server health was not working as expected and instead initiated probes
after the default interval of 10 seconds. This issue has been fixed. [BNADC-4005]
An issue where a certificate was being associated with the server automatically has been fixed. [BNADC-3931]
A possible race-condition with cookie persistence, which caused empty cookie or broken persistency has been fixed. [BNLB-4909]
The AAA feature is now available in the Barracuda Load Balancer ADC 340 and 440. [BNADC-4535]
The configured values of Connection Pooling timeout parameters are now set properly when the L7 services are migrated from the
Barracuda Load Balancer to the Barracuda Load Balancer ADC. [BNADC-4536]
On rare occasions, the persistency module was introducing cookies with blank values which resulted in the persistency module not
working for services. This issue has been fixed. [BNADC-4433]
SSLv3 is disabled for web interface access to mitigate POODLE attack (CVE-2014-3566). [BNADC-4806]
An issue which resulted in the administrator getting a web page error upon restoring a backup file has been fixed. [BNADC-4562]
During the migration process from the Barracuda Load Balancer to the Barracuda Load Balancer ADC, the SNI domain list configuration
was not getting migrated successfully causing a configuration roll back. This issue has been fixed. [BNADC-4812]
The logs are not generated for the service and the associated content rules when Enable Access Logs is set to No. [BNADC-4868]
Fixed double free with L7 UDP services. [BNADC-4849]
When SSL services were modified after upgrading the firmware from 5.1.1 to 5.2, the selected cipher list was not displayed. This issue

has been addressed. [BNADC-4891]

Fixes
Increased the limit on number of stored trusted certificates to 64. [BNADC-4147]

Column selections for the ADVANCED > System Logs page and the BASIC > Web Firewall Logs, Access Logs, and Audit Logs pag
es are now retained after pages are refreshed or sessions are closed. [BNADC-3986]
Fixed a memory leak issue where memory allocated for objects to track persistency was not released after the persistency timeout.
[BNADC-3842]

Enhancement
Added the ability to configure policy-based routing rules on the NETWORK > Routes page to route packets on a specific interface.
[BNADC-3598]
Fixes
Fixed possible buffer overflow when the Cookie Insert persistence method is used. [BNADC-3991]
Removed weak RC4-MD5 cipher. [BNADC-3763]
Enhancements to the automatic recovery mechanism which monitors critical processes. [BNADC-3919]
Configuration changes are no longer stalled when adaptive scheduling is enabled for multiple services and real server weights constantly
update. [BNADC-3784]
LDAP authentication: backslashes (\) are now allowed in User DN names. [BNADC-3761]
OpenSSL vulnerability [CVE-2014-0160] for TLS/DTLS Heartbleed attack has been addressed. [BNADC-3633]
Fixed an issue with moving services to the group selected from the Group list on the BASIC > Services page. [BNADC-3620]
A message about the Test Value parameter no longer displays when saving the configuration of the SIMPLE_HTTPS test.
[BNADC-3574]
The virtual IP addresses of services can now be created with the last octet as 0. [BNADC-3537 and BNADC-3538]
Email notifications now state the correct number of remaining active servers under a service. [BNADC-3310]
Fixed an issue with changes to the Connection Pooling parameter in the server settings for Layer 7 services. [BNADC-3876]
Requests with an authorization header are now redirected to the correct real server according to content rules. [BNADC-3787]

Release Notes Version 5.1.0.x
Version 5.1.0.009
Fixed
Known Issue
Version 5.1.0.008
Version 5.1.0.003
Authentication and Authorization
User Interface
Application Security
Support for Barracuda Load Balancer Configuration
Enhancements
Fixes
Known Issue
Version 5.1.0.009
Note:
The Barracuda Load Balancer ADC Vx is now available on Amazon Web Services.
The "DEFAULT" certificate for the Barracuda Load Balancer ADC UI has been renewed as part of the upgrade. If the firmware is
upgraded over HTTPS, you might not be redirected to the login screen due to renewal of the "DEFAULT" certificate. Please refresh the
page after five (5) minutes, and then accept the certificate to proceed.
Fixed
Vulnerability fix: OpenSSL vulnerabilities outlined in CVE-2014-0224, CVE-2014-0198, CVE-2010-5298 addressed. [BNADC-3916]
The "DEFAULT" certificate being used by Barracuda Load Balancer ADC for UI access using HTTPS has been renewed. [BNADC-3823]
It is now possible to change the service type for Layer 4 TCP services. [BNADC-3596]
The services were disrupted in a high availability environment due to an unnecessary reload issue. This is fixed now. [BNADC-3822]
In rare circumstances, the Barracuda Load Balancer ADC web interface used to hang up when any configuration change was made. This
issue is fixed now. [BNADC-3784]
It is now possible to add the "Simple HTTPS" testing method under Server Monitor. [BNADC-3574]
Known Issue
Layer 4 service with Direct Server Return (DSR) mode is not supported on Amazon Web Services.
Version 5.1.0.008
Fixed : OpenSSL vulnerability [ CVE-2014-0160 ] for TLS/DTLS Heartbleed attack has been addressed. [ BNADC-3633 ]
Version 5.1.0.003
Authentication and Authorization
Barracuda Load Balancer ADC models 540 and above can be integrated with an external authentication server for client authentication.
LDAP, RADIUS and Kerberos authentication protocols are supported. You can create authorization policies that control access by
authenticated users to web applications.
User Interface
The Services page makes it easier to add, edit, and view services and servers. You can view and update every option when you add a
service or a server. If you have similar services, you can use the settings of one service as a starting point when creating a new service.
And, as before, you can view the status of all services and real servers at a glance.
The Status and Security Policies pages also have a new layout.
The web interface has a new color scheme and improved look and feel.
An Instant SSL service (that redirects an HTTP connection to an HTTPS service) appears as only one service in the user interface. An
Instant SSL service includes both the service port and the redirect port.

The Application Security subscription, which adds Layer 7 security to your existing HTTP-, HTTPS-, FTP- or FTPS-based applications, is
being made available at no charge to all ADC customers on models 540 and above. Configure security policies using the pages under
the SECURITY tab.
Support for Barracuda Load Balancer Configuration
You can restore backup files from a Barracuda Load Balancer to a new ADC system.
Enhancements
Persistence across services for the same server. A client that is using a real server on one port and is redirected to another port / service
will continue to use the same real server. [BNADC-2533]
Provide support for TCP keepalive for Layer 7 HTTP services. [BNADC-2627]
Added option to redirect requests with 301 or 302 status code to a specific URL so that that URL can be cached on the client system.
[BNADC-2106]
Added ability to configure the global Layer 4 connection timeout on the ADVANCED > System Configuration page. [BNADC-1801]
Fixes
Microsoft Outlook clients failover from one CAS to another without delay. [BNADC-2665]
Barracuda Load Balancer ADC SNMP, syslog and NTP services continue to operate even if a Layer 7 UDP service is configured.
[BNADC-2315]
Instant SSL services will rewrite HTTP to HTTPS for content type application/json. [BNADC-1610]
Known Issue
If you are using IE 7 or IE 8, the BASIC > Services page may not always render correctly.

Deployment
You can deploy the Barracuda Load Balancer ADC either as a hardware system or as a virtual system on supported hypervisors.
When you deploy the Barracuda Load Balancer ADC, ensure that your network meets the setup requirements. You must also decide on:
Deploying the Barracuda Load Balancer ADC in either a one-armed or two-armed mode.
Creating services to load balance traffic at Layer 4 or Layer 7. A service is a combination of a virtual IP (VIP) address and one or more
TCP/UDP ports. Traffic arriving at the designated ports for the specified VIP address is directed to one of the real servers that are
associated with that particular service.
Configuring Direct Server Return (DSR) for real servers that generate more outbound traffic than inbound traffic.
Setting up two Barracuda Load Balancer ADCs in a high availability cluster as an active-passive pair. Only the active unit processes
traffic, but both units synchronize their configurations and monitor each other's health. For more information, see High Availability.
In this Section
Deployment Requirements
Choosing Your Deployment Mode and Service Types
Direct Server Return Deployment
Virtual Deployment
Public Cloud Hosting

Deployment Requirements
When you install the Barracuda Load Balancer ADC in your network, ensure that the following conditions are met:
1. The VIP addresses are on the same subnet as the rest of the network; only the real servers are on the private, separate network.
2. 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.
3. (Recommended) Each real server is "one hop" away from the port on the Barracuda Load Balancer ADC. Any relevant switches
must be either directly connected to a port of the Barracuda Load Balancer ADC or connected to a series of switches that
eventually reach the Barracuda Load Balancer ADC without going through any other machines.
If you must remotely administer real servers individually, you can create new services that each load balance only a single real server (so it acts
as a NAT).
Multiple Network Adapters on Real Servers
Real servers that are on multiple networks simultaneously can break the route path. If possible, each real server must be logically isolated. All
traffic going to each real server must go through the Barracuda Load Balancer ADC. Each real server must have only one IP address, which is
their private, isolated IP address.
If a real server has more than one network adapter enabled, which gives traffic an alternate route around the Barracuda Load Balancer ADC, the
deployment does not work properly even though it may appear to work initially. If your real servers have multiple network adapters, ensure that
one of the following is true:
The networks that the real servers are on are isolated from each other and cannot access the WAN (the network where incoming
traffic arrives) without going through the Barracuda Load Balancer ADC. No network path can exist from the real servers to the
client machines; 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.
Static routes for incoming and outgoing traffic for the IP address of each real server have been defined.

Choosing Your Deployment Mode and Service Types
You can deploy the Barracuda Load Balancer ADC in either one- or two-armed mode. Additionally, you select whether the Barracuda Load
Balancer ADC acts as a reverse proxy for each type of traffic that is load balanced.
A service is a combination of a virtual IP (VIP) address and one or more TCP/UDP ports. Traffic arriving at the designated ports for the specified
VIP address is directed to one of the real servers that are associated with that particular service.
When you create a service, specify whether the incoming traffic type is load balanced at Layer 4 or at Layer 7. You can also configure settings
such as a scheduling policy and security for each service.
One-Armed and Two-Armed Mode
You can deploy the Barracuda Load Balancer ADC in either one-armed mode or two-armed mode:
One-Armed – In a one-armed topology, all of the real servers and VIP addresses are configured on a single network, usually the WAN
network, or (less commonly) the LAN network.
Two-Armed – The VIP addresses (incoming traffic) and the real servers are configured on different networks. Internet traffic is routed
through one port on the Barracuda Load Balancer ADC. Traffic from the real servers is routed through a separate port on the Barracuda
Load Balancer ADC. A two-armed deployment requires you to configure separate networks for the incoming traffic and the real servers.
If a Layer 4 - UDP or Layer 4 - TCP service is used in a two-armed deployment, the Barracuda Load Balancer ADC must be the default
gateway for all downstream real servers. For all other types of services, the real servers and VIP addresses can be positioned in a
variety of ways.
Figure 1 shows a WAN deployment using a one-armed topology and TCP Proxy, UDP Proxy, or Layer 7 services. The gateway IP address of the
real servers need not change when adding the Barracuda Load Balancer ADC to the network. All of the virtual IP addresses and the IP addresses
for the real servers are connected to the WAN.
Figure 1. One-armed using TCP Proxy, UDP Proxy, or a Layer 7 service.
Figure 2 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.
Figure 2. Two-armed TCP Proxy, UDP Proxy, or Layer 7 Service.

Direct Server Return
If a real server generates a much greater volume of outbound traffic than inbound traffic, you can configure Direct Server Return (DSR) for it.
DSR increases outbound traffic throughput by directing traffic from the real server directly to the client, bypassing the Barracuda Load Balancer
ADC. For more information about this deployment option, see Direct Server Return Deployment.
Figure 3 below illustrates how requests and responses are processed in a one-armed network where DSR is enabled for the real servers.
1. The request arrives at the switch and is passed to the virtual IP (VIP) address on the Barracuda Load Balancer ADC.
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.
5. The real server responds directly to the client using the VIP address as the source IP address.
Figure 3. Example DSR, one-armed architecture.
Service Types
You can create Layer 4 or Layer 7 services to pass incoming traffic to the real servers. Both types of services provide different options for
handling traffic.
Layer 4 Services
Layer 4 services pass traffic in half-NAT mode, changing the destination IP address to that of the real server, but keeping the original source IP
address.
Traffic Type Deployment Mode Layer 4 Service Type Notes
TCP or UDP One-armed. Layer 4-TCP, Layer 4-UDP Requires a loopback

Provides the best performance Real servers in Direct Server adapter on each real server.
when most of the traffic is Return mode. This enables the real server
outgoing. to reply to the client using
the IP address of the
service configured on the
Barracuda Load Balancer
ADC instead of using its
own IP address which would
likely cause the client to
drop the incoming packets
(since the original
destination IP address
would not match the IP
address from the replying
server).
Can keep the IP addresses
of the real servers.
SSL offloading and other
Layer 7 capabilities are not
supported.
Persistence is achieved
using the client IP address.

Layer 7 Services
Layer 7 services pass traffic in full-NAT mode, changing both the source and destination IP addresses. The Barracuda Load Balancer ADC acts
as a proxy. Connections from the client are terminated at the Barracuda Load Balancer ADC and new connections are established between the
Barracuda Load Balancer ADC and the real servers.
For Layer 7 services, the topology can be either one-armed or two-armed. When you install the Barracuda Load Balancer ADC, you do not need
to change the gateway of the servers in the server farm.
For secure Layer 7 services (Secure TCP Proxy, HTTPS, and FTP SSL), the Barracuda Load Balancer ADC inspects the encrypted traffic using
a certificate that is specified when the service type is selected. The traffic can be re-encrypted, or you can configure SSL offloading to send the
de-crypted traffic to the real servers.
Traffic Type Layer 7 Service Type
UDP UDP Proxy
UDP Proxy supports persistence using both the client IP

address and port. Many UDP applications involve all client
requests coming from one client IP address. A UDP Proxy
service that is configured with persistence of client IP port
number distributes traffic across all of the real servers.
TCP TCP Proxy
TCP with SSL processing offloaded to the Barracuda Load Balancer Secure TCP Proxy
ADC
HTTP (web servers) HTTP or HTTPS
FTP (FTP servers) FTP or FTP SSL
Remote Desktop Services Layer 7 - RDP
Configuring Services
For more information on the available service types and how to configure them, see Services.
Deployment Examples
The following table lists some common cases with suggested deployments:
Use Case Suggested Deployment
The Barracuda Load Balancer ADC provides Layer 4 load balancing Create one or more Layer 4 - TCP services.
of TCP/IP traffic.
The Barracuda Load Balancer ADC provides Layer 4 load balancing Create one or more Layer 4 - UDP services.
of UDP traffic.
The Barracuda Load Balancer ADC provides SSL offloading and Create one or more Secure TCP Proxy services.
Layer 4 load balancing of TCP/IP traffic.
If you use a one-armed topology, you do not need to reconfigure the
IP addresses of the real servers.
A two-armed topology provides better performance.
The real servers are on the same subnet as the Barracuda Load You have the following options:
Balancer ADC, and the configuration cannot be changed.
Use a one-armed topology, and create a TCP Proxy service (or
a Secure TCP Proxy service if SSL offloading is required).
If almost all of the traffic is outbound, configure Direct Server
Return with a Layer 4 service.
There is an existing IT infrastructure using Windows where the web To avoid changing network settings, you have the following options:
servers must communicate with systems such as Active Directory
Domain Services, ISA Servers or domain controllers. Use one-armed topology. and create a TCP Proxy service.
Configure Direct Server Return with a Layer 4 service,
For the best performance, it is recommended that you use

a two-armed topology and create a Layer 4 service.

The outbound traffic is far greater than the inbound traffic. For Configure Direct Server Return with a Layer 4 service to increase
example, if the real servers are providing streamed audio or visual throughput.
media.
The real servers must individually be remotely administered. You have the following options:
Create new services that each load balance a single real server.
Deploy the real servers in a one-armed topology and add them
to a TCP Proxy service.
Deploy the real servers in Direct Server Return mode, and add
them to a Layer 4 service.
Additional Deployment Notes
More information about different deployment options can be found in these articles:
One-Armed Using a TCP Proxy, UDP Proxy, or Layer 7 Service

Two-Armed Using TCP Proxy, UDP Proxy, or a Layer 7 Service
TCP Proxy, UDP Proxy, or a Layer 7 Service
Two-Armed with Layer 4 Load Balancing


In a one-armed topology all of the real servers and VIP addresses are configured on a single network, usually the WAN network, or (less
commonly) the LAN network.
When you create services in this topology, consider the following:
Layer 4 TCP or UDP services: You must configure the real servers in Direct Server Return mode. See Direct Server Return deployment.
TCP Proxy, UDP Proxy, or any of the Layer 7 service types: You can add the Barracuda Load Balancer ADC into an existing
infrastructure with minimal changes to the network. This does not require changes to the IP addresses of the real servers. The Barracuda
Load Balancer ADC can be added to the same subnetwork as the real servers. Alternatively, the Barracuda Load Balancer ADC can
connect to the real servers through a router.
Terminology
WAN refers to interface(s) configured to access an external network.

LAN refers to interface(s) configured to access an internal network.
Virtual Interface
If the server is in the same network as the custom virtual interface, the custom virtual interface is used to connect to the real 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 address are all in the same network, you cannot use the custom virtual
interface to connect to the real server, so the WAN IP address is always used to connect to the real server.
The virtual interface for the service can be in any network.
Example Deployments
Figure 1 shows a WAN deployment using a one-armed topology and TCP Proxy, UDP Proxy, or Layer 7 services. The gateway IP address of the
real servers need not change when adding the Barracuda Load Balancer ADC to the network. All of the virtual IP addresses and the IP addresses
for the real servers are connected to the WAN.
If required, an externally accessible IP address can be kept on a real server so that external clients can still access that address (for example, for
FTP) only on that one system.
Because configuration changes are not required, traffic is only passed through the Barracuda Load Balancer ADC if it must be load balanced.
Figure 1. One-armed using TCP Proxy, UDP Proxy, or a Layer 7 service.
Figure 2 shows an example of a one-armed deployment using TCP Proxy services. For this example, the Barracuda Load Balancer ADC
distributes traffic for a set of email servers also supported by a set of Barracuda Email Security Gateways.
Figure 2. One-armed TCP Proxy service with Barracuda Email Security Gateways.



A TCP Proxy, UDP Proxy, or one of the Layer 7 services makes the Barracuda Load Balancer ADC act as a full proxy. Connections from the
client are terminated at the Barracuda Load Balancer ADC, and new connections are established between the Barracuda Load Balancer ADC
and the real servers.
You can place the real servers anywhere in your network, as long as they can be routed to by the Barracuda Load Balancer ADC (e.g., via the
same subnet, a VLAN, or pre-configured static routes). This can be used in one-armed configurations for applications like Microsoft Exchange
Server or Microsoft Lync Server, as well as for custom applications. In two-armed configurations, real servers can access the virtual IP addresses
(VIPs) of any TCP Proxy, UDP Proxy, or Layer 7 services that are on the same side of the Barracuda Load Balancer ADC.
There are multiple configuration options available when using 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.
Some or all of the real servers are on the same subnet as the WAN.
Some or all of the real servers are on the same VLAN as the Barracuda Load Balancer ADC.
Some or all of the real servers are on a different subnet than either the WAN or LAN but are 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 ADC, and real servers are on a subnet
separate from the VIPs.
VIP addresses are on the same subnet as the LAN interface of the Barracuda Load Balancer ADC, and real servers are on a subnet
separate from the VIPs.
Terminology
WAN refers to interfaces configured to access an external network.

LAN refers to interfaces configured to access an internal network.


A two-armed deployment with a Layer 7 - RDP service is the recommended configuration when deploying the Barracuda Load Balancer ADC 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.
Figure 1. Two-armed TCP Proxy, UDP Proxy, or Layer 7 Service.

Two-Armed with Layer 4 Load Balancing

Use this option to provide Layer 4 load balancing of TCP or UDP traffic with the Barracuda Load Balancer ADC.
Secure TCP Proxy Service
If you want to provide SSL offloading for TCP/IP traffic, use a Secure TCP Proxy service.
Deploying the Barracuda Load Balancer ADC in a two-armed configuration provides greater performance but requires you to change the IP
addresses of all your real servers. If a Layer 4 type of service is used, you must set the Barracuda Load Balancer ADC as the default gateway for
all downstream real servers so that the Barracuda Load Balancer ADC can handle the responses that are issued by these servers to client
requests.
Figure 1. Two-armed Route-Path network with Layer 4 services.

Direct Server Return Deployment
To increase outbound traffic throughput for sustained uploads, such as streamed audio or visual media, you can enable Direct Server Return
(DSR) for each of your real servers. With DSR, connection requests and incoming traffic are passed from the Barracuda Load Balancer ADC to
the real server but all outgoing traffic goes directly from the real server to the client. DSR is ideal for high-bandwidth requirements such as content
delivery networks and lets you keep the existing IP addresses of your real servers.
Terminology
WAN refers to interface(s) configured to access the external network.

LAN refers to interface(s) configured to access the internal network.
Overview
Figure 1 below illustrates how requests and responses are processed in a one-armed network where DSR is enabled for the real servers.
1. The request arrives at the switch and is passed to the virtual IP (VIP) address on the Barracuda Load Balancer ADC.
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.
5. The real server responds directly to the client using the VIP address as the source IP address.
Figure 1. Example DSR, one-armed architecture.
Requirements
Because DSR uses a flat network topology at the Layer 2 (switching) and Layer 3 (IP) levels, the Barracuda Load Balancer ADC, VIP addresses,
and real servers all must be within the same IP network and connected on the same switch. Figure 1 above shows this topology. Each real server
must be one hop away from the Barracuda Load Balancer ADC and use the WAN port. The switch of the real servers must be either directly
connected into the WAN port of the Barracuda Load Balancer ADC or connected to a series of switches that eventually reach the WAN port of the
Barracuda Load Balancer ADC without going through any other networking devices. You can have DSR servers and non-DSR servers running
the same service.
When you deploy real servers in DSR mode, ensure that the following conditions are met:
1. The Barracuda Load Balancer ADC has the WAN adapter plugged into the same switch or VLAN as all of the real servers.
2. The real servers are on the same subnet as the WAN of the Barracuda Load Balancer ADC.
3. The WAN IP address, all VIPs, and all of the real servers that use DSR are on the same IP subnet.
4. Each real server recognizes the VIP as a local address. Enable a non-ARPing virtual adapter such as a loopback adapter and bind it to
the VIP address of the load-balanced service. Because this is not a true adapter, do not define a gateway in the TCP/IP settings for this
adapter.
5. Real servers that accept traffic from multiple VIPs have a loopback adapter enabled for each VIP . Additionally, the applications on each
real server are aware of both the virtual IP address and the real IP addresses.
Limitations
DSR has the following limitations:
Layer 7 services (HTTP, FTP, UDP Proxy, TCP Proxy, and RDP) are not supported.
Response headers and data cannot be handled (e.g., caching, compression, URL rewrites).
SSL offloading is not supported.
Only Layer 4 load balancing is supported.
Only client IP persistence can be used; cookie persistence is not supported.

Enabling DSR
Before you use DSR, go to the NETWORK > Interfaces page and add a custom virtual interface with a netmask that is larger than that of the VIP
address. The Barracuda Load Balancer ADC uses the custom virtual interface to correctly forward packets to real servers that are enabled with
DSR.
After you add the custom virtual interface, go to the BASIC > Services page and enable DSR individually for each real server listed under each
service. In the server settings, set Direct Server Return to Enable.
Deployment Options
For more information on deploying DSR in a Microsoft Windows Server, Linux, or Windows XP environment, see:
Deploying DSR in a Microsoft Windows Server 2003 or 2008 Environment

Deploying DSR in a Linux Environment
Deploying DSR in Windows XP Environment

Deploying DSR in a Microsoft Windows Server 2003 or 2008 Environment

Missing the language English in this article! Please add the language, otherwise this article can not be displayed properly.

Deploying DSR 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.
1. 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 255.255.255.255
-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:1 192.168.4.217 netmask 255.255.255.255 -arp up
2. 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.

Deploying DSR in Windows XP Environment

For information on how to add a non-ARPing adapter in a Microsoft® Windows® XP environment, refer to http://support.microsoft.com/kb/839013.
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.

Virtual Deployment
Requirement
This virtual appliance requires a 64-bit capable host.
The Barracuda Load Balancer ADC Vx enables you to build a highly secure and scalable application infrastructure. It includes the following
features:
Optimizes application performance by offloading compute-intensive SSL transactions from the server.
Distributes traffic for efficient use of server resources and employs server failover for high availability.
Ensures that only known users can access critical applications.
Deploying Your Barracuda Load Balancer ADC Vx
Complete the following steps to deploy your Barracuda Load Balancer ADC Vx:
1. Deploy the Barracuda Load Balancer ADC Vx image.

2. Allocate the cores, RAM, and hard disk space for your Barracuda Load Balancer ADC Vx.
3. Set up the Barracuda Load Balancer ADC with the Vx Quick Start Guide.
4. Configure your network and services.
Managing Your Virtual Machine
Backing Up Your Virtual Machine System State

VMware Tools

How to Deploy Barracuda Load Balancer ADC Vx Images

Barracuda offers the following types of images for the Barracuda Load Balancer ADC Vx deployment. Follow the instructions for your hypervisor
to deploy the Barracuda Load Balancer ADC Vx appliance.
Image Type Supported Hypervisors
OVF VMware ESX and ESXi (vSphere Hypervisor) versions 4.x, 5.x,
and 6.x
Sun/Oracle VirtualBox and VirtualBox OSE version 3.2
VMX VMware Server 2.0+

VMWare Fusion 3.0, Player 3.x, and Workstation 6.x
XVA Citrix XenServer 5.5+
VHD Microsoft Hyper-V 2008

Microsoft Hyper-V 8, 8.1, 2012, 2012 R2, and 10
Download
You can download these images from the Barracuda Virtual Appliance Download page. After the download is complete, extract the files
from the ZIP folder.
Deploy OVF Images
VMware ESX and ESXi (vSphere Hypervisor) 4.x, 5.x, and 6.x
For VMware ESX and ESXi, follow the steps below to:
Deploy an Image in VMware ESX and ESXi

Add Additional Network Interfaces for VMware ESX and ESXi
Use the appropriate OVF file for this environment.
1. Download and expand the Barracuda Load Balancer ADC Vx ZIP folder.
2. Launch vSphere Client and select the appropriate host and resource pool.
3. From the File menu in the vSphere Client, select Deploy OVF Template.
4. Click Browse. Navigate to the extracted folder, and select the appropriate OVF file for your hypervisor version:
Hypervisor Version OVF File
ESX and ESXi 4.x Use the OVF file ending in -4x.ovf.
5.Click Next. Verify you selected the correct Barracuda virtual appliance. Click Next again.
6.Enter a name for the virtual appliance. Click Next.
7.Select the destination storage for the virtual machine. Click Next.
8.Select the Thick Provision Eager Zeroed disk format to ensure maximum stability when deploying your Barracuda Vx appliance. Click
Next.
9. Map the network to the target network for this virtual appliance. Click Next.
10. Review the deployment options. Click Finish to deploy the virtual appliance.
11. Follow the recommendations in Allocating Cores, RAM, and Hard Disk Space for Your Barracuda Load Balancer ADC Vx.
12. Locate the appliance within the appropriate virtual machine and resource pool. Select it and power it on by clicking the green arrow.
13. Click the Console tab to monitor the appliance as it is prepared for use.
14. Follow the Barracuda Load Balancer ADC Vx Quick Start Guide instructions to set up your virtual appliance.
1. Shutdown the Barracuda virtual appliance using the Console.

2. Navigate to the Resource Allocation tab. Under either CPU or Memory, click Edit .
3. On the Hardware tab, click Add.
4. Select Ethernet Adapter under device types. Click Next.
5. On the Network Type window, set the Adapter Type to VMXNET 3. Set the Network label to the setting appropriate for your network.
Click Next.
6. Click Finish.Click OK.
7.

7. Power On the Barracuda virtual appliance by clicking the green arrow.
Sun/Oracle VirtualBox and VirtualBox OSE 3.2
Use the OVF file ending in -4x.ovf for this hypervisor.
2. From the File menu in the VirtualBox client, select Import Appliance.
3. Navigate to the extracted folder and locate the Barracuda Load Balancer ADC OVF file.
4. Select the file and click Next.
5. On the Import Settings screen, follow the recommendations in Allocating Cores, RAM, and Hard Disk Space for Your Barracuda Load
Balancer ADC Vx. Click Finish.
6. Start the appliance.
Deploy VMX Images
VMware Server 2.x
Use the .vmx and .vmdk files for this hypervisor.
2. Navigate to the extracted folder and move 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).
3. From the VMware Infrastructure Web Access client's Virtual Machine menu, select Add Virtual Machine to Inventory.
4. Navigate to the folder in your datastore used in step 2 and select the file ending in .vmx. Click OK.
VMware Workstation 6.x, Player 3.x, and Fusion 3.x
Use the .vmx file for these hypervisors.
2. From the File menu, select Open a Virtual Machine.
3. Navigate to the extracted folder and select the file ending in .vmx.
4. Use the default settings and click Finish.
Deploy XVA Images
Citrix XEN Server 5.5+
Use the .xva file for this hypervisor. For XEN Server, you first import the virtual appliance template and then create a new virtual appliance based
on that template.
Step 1. Import the virtual appliance template:
2. From the File menu in the XenCenter client, select Import.
3. Click Browse, navigate to the extracted folder, and select the file ending in .xva. Click Next.
4. Select a server for the template. Click Next.
5. Select a storage repository for the template. Click Import.
6. Select a virtual network interface for the template. Click Next.
7. Review the template settings. Click Finish to import the template.
Step 2. Create a new virtual appliance:
1. Right-click the virtual appliance template and select New VM wizard.

2. Select the virtual appliance template. Click Next.
3. Enter a name for the virtual appliance. Click Next.
4. For the DVD drive, select <empty>. Click Next.
5. Select a home server. Click Next.
6. Specify the number of virtual CPUs and memory for the virtual appliance. Follow the recommendations in Allocating Cores, RAM, and
Hard Disk Space for Your Barracuda Load Balancer ADC Vx. Click Next.
7. Select a virtual disk. Click Next.
8. Select a virtual network interface. Click Next.
9. Review the virtual appliance settings. Click Create Now.
10.

10. When the virtual appliance is ready, right-click it and then click Start.
Deploy VHD Images
Microsoft Hyper-V 2008
Use the .vhd file for this hypervisor.
2. Navigate to the extracted folder and verify that the HyperV folder contains the following subfolders:
Snapshots
Virtual Hard Disks
Virtual Machines
3. In Hyper-V Manager, right-click the VM host and select Import Virtual Machine.
4. Navigate to the extracted folder, select the HyperV folder, and click Select Folder.
5. Select Copy the virtual machine and Duplicate all files. Click Import.
7. Start the Barracuda Load Balancer ADC Vx by right-clicking the virtual machine and selecting Start.
2. Launch the WinServerSetup.bat file located in the extracted folder. This batch file corrects a compatibility issue and takes less than a
minute to run.
Snapshots
Virtual Hard Disks
Virtual Machines
5. On the Before You Begin page of the Import Virtual Machine wizard, click Next.
6. On the Locate Folder page:
a. Click Browse, navigate to the extracted folder, and select the HyperV folder. Click Select Folder.
b. Click Next.
7. On the Select Virtual Machine page, click Next.
8. On the Choose Import Type page, select Copy the virtual machine (created a new unique ID). Click Next.
9. On the Choose Destination: Choose Folders for Virtual Machine Files page, click Browse to search for the location where you want
to store the VM files. Click Next.
10. On the Choose Storage Folders: Choose Folders to Store Virtual Hard Disks page, click Browse to search for the location where
you want to store the virtual hard disks for the VM. Click Next.
11. For Microsoft Windows 10, you can modify the RAM and Hard Disk space allocations after completing step 12.
On the Configure Memory page, enter a size for the Startup RAM that meets the requirements at Allocating Cores, RAM, and Hard
Disk Space for Your Barracuda Load Balancer ADC Vx. Keep the default settings for the other fields. Click Next.
12. On the Connect Network page, select the network interface that you want to use for management access of the VM. Click Next.
13. On the Summary page, verify that all the settings are correct. Click Finish.
14. For Microsoft Windows 10, go to the Actions pane and click on Settings under Barracuda Load Balancer ADC. Under Hardware,
ensure that their is enough memory and hard disk space as specified in Allocating Cores, RAM, and Hard Disk Space for Your
Barracuda Load Balancer ADC Vx.
15. Start your virtual appliance.
To take advantage of Microsoft's VHDX support on Hyper-V 2012, 2012 R2 and 10, follow the instructions in How to Convert and
Replace a Barracuda Virtual Appliance VHD File with a VHDX Format File.

How to Deploy the Barracuda Load Balancer ADC Vx
How to Deploy a Barracuda Virtual Appliance Using a Hypervisor

Barracuda supports the following hypervisors for deploying virtual appliances.
Supported Hypervisors Image Type
VMware ESX and ESXi (vSphere Hypervisor) versions OVF

4.x, 5.x, and 6.x
Sun/Oracle VirtualBox and VirtualBox OSE version 3.2
VMware Server 2.0+ VMX

VMWare Fusion 3.0, Player 3.x, and Workstation 6.x
Citrix XenServer 5.5+ XVA
Microsoft Hyper-V 2008 VHD

Download
You can download the Barracuda hypervisor images from the Barracuda Virtual Appliance Download page.
Deploy OVF Images
VMware ESX and ESXi (vSphere Hypervisor) 4.x, 5.x, and 6.x
For VMware ESX and ESXi, follow the steps below to:

Use the appropriate OVF file for this environment.
1. Download and expand the Barracuda virtual appliance ZIP folder.

2. Launch vSphere Client and select the appropriate host and resource pool.
3. From the File menu in the vSphere Client, select Deploy OVF Template.
4. Click Browse. Navigate to the extracted folder, and select the appropriate OVF file for your hypervisor version:
Hypervisor Version OVF File
5. Click Next. Verify you selected the correct Barracuda virtual appliance. Click Next again.
7. Select the destination storage for the virtual machine. Click Next.
8. Select the Thick Provision Eager Zeroed disk format to ensure maximum stability when deploying your Barracuda Vx
appliance. Click Next.
9. Map the network to the target network for this virtual appliance. Click Next.
10. Review the deployment options. Click Finish to deploy the virtual appliance.
12. Locate the appliance within the appropriate virtual machine and resource pool. Select it and power it on by clicking the
green arrow.
13. Click the Console tab to monitor the appliance as it is prepared for use.

1. Shutdown the Barracuda virtual appliance using the Console.

2. Navigate to the Resource Allocation tab. Under either CPU or Memory, click Edit .
3. On the Hardware tab, click Add.
4. Select Ethernet Adapter under device types. Click Next.
5. On the Network Type window, set the Adapter Type to VMXNET 3. Set the Network label to the setting appropriate for your
network. Click Next.
6. Click Finish.Click OK.
7. Power On the Barracuda virtual appliance by clicking the green arrow.
Sun/Oracle VirtualBox and VirtualBox OSE 3.2
Use the OVF file ending in -4x.ovf for this hypervisor.

2. From the File menu in the VirtualBox client, select Import Appliance.
3. Navigate to the extracted folder and locate the Barracuda Load Balancer ADC OVF file.
4. Select the file and click Next.
5. On the Import Settings screen, follow the recommendations in Allocating Cores, RAM, and Hard Disk Space for Your
Barracuda Load Balancer ADC Vx. Click Finish.
Deploy VMX Images
VMware Server 2.x
Use the .vmx and .vmdk files for this hypervisor.

2. Navigate to the extracted folder and move 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).
3. From the VMware Infrastructure Web Access client's Virtual Machine menu, select Add Virtual Machine to Inventory.
4. Navigate to the folder in your datastore used in step 2 and select the file ending in .vmx. Click OK.
VMware Workstation 6.x, Player 3.x, and Fusion 3.x
Use the .vmx file for these hypervisors.

2. From the File menu, select Open a Virtual Machine.
3. Navigate to the extracted folder and select the file ending in .vmx.
4. Use the default settings and click Finish.
Deploy XVA Images
Citrix XEN Server 5.5+
Use the .xva file for this hypervisor. For XEN Server, you first import the virtual appliance template and then create a new virtual
appliance based on that template.
Step 1. Import the virtual appliance template:
2. From the File menu in the XenCenter client, select Import.
3. Click Browse, navigate to the extracted folder, and select the file ending in .xva. Click Next.
4. Select a server for the template. Click Next.
5. Select a storage repository for the template. Click Import.
6. Select a virtual network interface for the template. Click Next.
7. Review the template settings. Click Finish to import the template.
Step 2. Create a new virtual appliance:

1. Right-click the virtual appliance template and select New VM wizard.

2. Select the virtual appliance template. Click Next.
4. For the DVD drive, select <empty>. Click Next.
5. Select a home server. Click Next.
6. Specify the number of virtual CPUs and memory for the virtual appliance. Follow the recommendations in Allocating Cores,
RAM, and Hard Disk Space for Your Barracuda Load Balancer ADC Vx. Click Next.
7. Select a virtual disk. Click Next.
8. Select a virtual network interface. Click Next.
9. Review the virtual appliance settings. Click Create Now.
10. When the virtual appliance is ready, right-click it and then click Start.
Deploy VHD Images
Microsoft Hyper-V 2008

Snapshots
Virtual Hard Disks
Virtual Machines
4. Navigate to the extracted folder, select the HyperV folder, and click Select Folder.
5. Select Copy the virtual machine and Duplicate all files. Click Import.
7. Start the Barracuda virtual appliance by right-clicking the virtual machine and selecting Start.

2. Launch the WinServerSetup.bat file located in the extracted folder. This batch file corrects a compatibility issue and takes
less than a minute to run.
Snapshots
Virtual Hard Disks
Virtual Machines
5. On the Before You Begin page of the Import Virtual Machine wizard, click Next.
6. On the Locate Folder page:
a. Click Browse, navigate to the extracted folder, and select the HyperV folder. Click Select Folder.
b. Click Next.
7. On the Select Virtual Machine page, click Next.
8. On the Choose Import Type page, select Copy the virtual machine (created a new unique ID). Click Next.
9. On the Choose Destination: Choose Folders for Virtual Machine Files page, click Browse to search for the location
where you want to store the VM files. Click Next.
10. On the Choose Storage Folders: Choose Folders to Store Virtual Hard Disks page, click Browse to search for the
location where you want to store the virtual hard disks for the VM. Click Next.
11. For Microsoft Windows 10, you can modify the RAM and Hard Disk space allocations after completing step 12.
On the Configure Memory page, enter a size for the Startup RAM that meets the requirements at Allocating Cores, RAM,
and Hard Disk Space for Your Barracuda Load Balancer ADC Vx. Keep the default settings for the other fields. Click Next.
12. On the Connect Network page, select the network interface that you want to use for management access of the VM. Click
Next.
13. On the Summary page, verify that all the settings are correct. Click Finish.
14. For Microsoft Windows 10, go to the Actions pane and click on Settings under the Barracuda virtual appliance. Under
Hardware, ensure that their is enough memory and hard disk space as specified in Allocating Cores, RAM, and Hard Disk
Space for Your Barracuda Load Balancer ADC Vx.
15. Start your virtual appliance.

To take advantage of Microsoft's VHDX support on Hyper-V 2012, 2012 R2 and 10, follow the instructions in How to
Convert and Replace a Barracuda Virtual Appliance VHD File with a VHDX Format File.

Allocating Cores, RAM, and Hard Disk Space for Your Barracuda Load Balancer ADC Vx
Barracuda recommends the following settings for the initial deployment of your virtual appliance or when upgrading existing
installations.
Cores, RAM, and Hard Disk Space for the Barracuda Load Balancer ADC Vx
Model Cores RAM - Recommended Hard Disk - Recommended

Minimum Minimum
340 Vx 2 4 GB 50 GB
440 Vx 4 8 GB 50 GB
540 Vx 5 12 GB 100 GB
640 Vx 6 (1) 16 GB 120 GB
Note:
(1) To increase the performance of this model, you should plan on adding 2 GB of RAM and 20 GB of additional hard disk space for each
additional core. To purchase licenses for additional cores, contact your Barracuda sales representative.
Allocating Cores
In your hypervisor, specify the number of cores to be used by the Barracuda Load Balancer ADC Vx. Each Barracuda Load Balancer ADC Vx mo
del can use only the number of cores specified in the table above, unless you buy licenses for additional cores from Barracuda. For example, if
you assign 4 cores to the Barracuda Load Balancer ADC 340 Vx (which supports only 2 cores by default), the hypervisor disables the 2 extra
cores that cannot be used.
To add cores to your appliance:
1. Shut down the Barracuda Load Balancer ADC Vx in your hypervisor.

2. In the virtual machine CPU settings, add cores.
Your hypervisor license and version might limit the number of cores that you can specify for your appliance. In some cases, you must
add cores in multiples of two.
Allocating Hard Drive Space
Barracuda recommends a minimum of 50 GB of hard disk space to run your Barracuda Load Balancer ADC Vx. From your hypervisor, you can
specify the size of the existing hard disk, or you can add a hard disk.
To specify the allocated hard disk space or add a hard disk to your appliance:
1. Shut down the Barracuda Load Balancer ADC Vx in your hypervisor.

2. Take a snapshot of your virtual machine.
3. In your virtual machine settings, specify the new size for the hard disk or add a new hard disk.
4. Restart the virtual machine. As the appliance is booting up, view the console for the Barracuda Load Balancer ADC Vx. When the blue
Barracuda console screen appears and asks if you want to use the additional hard disk space, enter Yes.
If you do not respond to the prompt in 30 seconds, the answer defaults to No. Resizing can take several minutes, depending

on the amount of hard disk space specified.
Next Step
For instructions on how to set up the Barracuda Load Balancer ADC Vx, see the Barracuda Load Balancer ADC Vx Quick Start Guide.

Barracuda Load Balancer ADC Vx Quick Start Guide
Before You Begin
Deploy the Barracuda Load Balancer ADC Vx on your hypervisor.
Step 1. Configure Your Firewall
If your Barracuda Load Balancer ADC Vx is located behind a firewall, open the following Barracuda network address ranges for the ports shown
in the table below:
64.235.144.0/20
198.207.200.0/22
209.222.80.0/21
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 updates (unless

configured to use a proxy)
123 Out UDP Network Time Protocol (NTP)
443 Out TCP Initial VM provisioning *
25 Out TCP Sending system alerts and

notifications to the administrator
via your mail server. This port
can be changed on the BASIC >
Administration page.
Any ports used by Services as needed as needed As required to access the VIP
address of a load-balanced
service. Configure 1:1 NATs as
needed. Certain protocols,
including FTP and streaming
media protocols, require
additional ports to be open.
* You can disable the initial provisioning port after the initial provisioning process is complete.
Step 2. Start the Virtual Appliance, Configure TCP/IP, and Enter the License Token
You need a Barracuda Vx license token, which you might have received via email or from the website when you downloaded the Barracuda Load
Balancer ADC Vx package. If not, you can request an evaluation on the Barracuda website https://www.barracuda.com/purchase/evaluation or
purchase one from https://www.barracuda.com/purchase/index. The license token looks similar to the following: 01234-56789-ACEFG.
1. In your hypervisor client, start the virtual appliance and allow it to boot up.
2. Log in to the console as admin with the password admin.
3. Navigate to TCP/IP Configuration. Set the System IP Address, Subnet Mask, Default Gateway, Primary DNS Server, and Seconda
ry DNS Server for your virtual appliance.
4. Navigate to Licensing. Enter your Barracuda license token and default domain to complete provisioning. The appliance will reboot as a
part of the provisioning process.
Step 3. Accept the End User License Agreement and Login
1. Go to http://<your ip>:8000 to access the web interface.

2. Read through the End User License Agreement. Scroll down to the end of the agreement.
3. Enter the required information: Name, Email Address, and Company (if applicable). Click Accept. You are redirected to the Login
page.
4. Log into the administration interface using admin for both the username and password.
If you are planning to put the Barracuda Load Balancer ADC Vx in Offline mode, ensure you check the following:
All definitions are updated on the ADVANCED > Energize Updates page.

The Barracuda Load Balancer ADC Vx is on the latest Firmware Version on the ADVANCED > Firmware Update page.
The Barracuda Load Balancer ADC periodically connects to Barracuda Central to check for the availability of new Energize Updates.
To receive new Energize Updates, ensure your Barracuda Load Balancer ADC is able to connect to internet to reach Barracuda
Central.
Step 4. Change the Administrator Password
Go to the BASIC > Administration page to change the administrator password.
Step 5. Attach Multiple Interfaces to the Deployed VM
Assign network interface cards (NICs) to the Barracuda Load Balancer ADC Vx. In the web administration interface, they are numbered in the
order that you assign them. The first interface that you attach to the VM will act as the management interface and is named MGMT. The next
interface that you attach to the VM (the first interface used for handling network traffic) is named ge-1-1. The next interface that you attach is
named ge-1-2, and so on. Once you have restarted your VM, the interfaces are displayed on the BASIC > Dashboard page as shown below:
The Barracuda Load Balancer ADC VM requires a minimum of two interfaces, one for management and one for network traffic. You can attach
more interfaces depending upon your deployment mode. For more information on the different deployment modes that are supported by the
Barracuda Load Balancer ADC, see Step 6. Choose a Deployment Mode.
Steps to attach additional interfaces varies from hypervisor to hypervisor, so follow the manual of your hypervisor to add more interfaces.
Before you attach the additional interfaces, stop your VM.

You can attach a maximum of eight interfaces to one VM.
Step 6. Choose a Deployment Mode
Choose the network layout that best suits your environment. For a complete list of deployment options, see Deployment. Common options
include:
One-armed deployment, with a TCP Proxy service, where one network connection of the Barracuda Load Balancer ADC is used for all
load-balanced traffic.

Figure 1. One-armed deployment
Two-armed deployment, where the Barracuda Load Balancer ADC is deployed in-line, performing NAT from the WAN network to the
LAN.
Figure 2: Two-armed Deployment
Next Step
Continue with Step 5 - How to Configure Your Network and Services.

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.

Public Cloud Hosting
Barracuda Networks offers the Barracuda Load Balancer ADC as a cloud-hosted virtual appliance, to load balance, secure, and accelerate the
performance of your applications. Cloud-hosted virtualization is available for Amazon Web Services (AWS) VMware vCloud Air.
Currently, the Barracuda Load Balancer ADC on AWS and vCloud Air supports flat networks (for example, your management IP address and VIP
address both reside in the same network). Key features include:
Load balancing with dynamic scheduling and advanced monitoring capabilities

SSL offloading, TCP connection pooling and caching, and compression to help accelerate application delivery
Content-based routing to provide fine-grained application control
Integrated application security to protect against application level attacks including the OWASP Top 10 risks
Protection against theft of sensitive and confidential data
You can deploy the Barracuda Load Balancer ADC on the following cloud services:
Amazon Web Services

VMware vCloud Air Deployment

Amazon Web Services

To meet a variety of performance requirements, the M1 Medium, M1 Large, and M1 Extra Large instance types are supported for deploying the
Barracuda Load Balancer ADC on Amazon Web Services (AWS). Depending on the instance type, you can have:
Up to 4 vCPUs.
Up to 15 GB of memory.
Up to 4 network interfaces. One interface is used for MGMT access and the remaining interfaces can be used for creating services. With
multiple network interfaces, you can create a link bond to improve the throughput of the Barracuda Load Balancer ADC.
Up to 16 private IP addresses per network interface. To ensure that services are available over the Internet, you can allocate a public IP
address, or Elastic IP address (EIP), to each private IP address.
The Barracuda Load Balancer ADC is available hourly in the AWS Marketplace or you can bring your own license (BYOL).
Licensing Options
The Barracuda Load Balancer ADC AMI is available on Amazon Web Services with the Hourly/Metered licensing option and the Bring Your Own
License (BYOL) option.
Bring Your Own License (BYOL)
With the Bring Your Own License (BYOL) option, you are required to get the Barracuda Load Balancer ADC license token, either by:
Providing the required information for a free evaluation at https://www.barracuda.com/purchase/evaluation OR

Purchasing online at https://www.barracuda.com/purchase.
From the Product list, select Barracuda Load
Balancer ADC AWS under Public Cloud Solutions. Then complete the rest of the form. With this license
option, there are no Barracuda Load Balancer ADC Software charges, but Amazon Elastic Compute Cloud (Amazon EC2) usage c
harges on Amazon are applicable.
BYOL Models and Instance Types
For BYOL, Barracuda offers three models. The following table lists each model and their corresponding instance type to be used in AWS. The
table also lists the CPU, memory, and networking capacity for each instance type.
If you want to increase the performance of a license that you have already purchased, you can buy additional cores from Barracuda and
reconfigure your VM for a larger instance type.
Barracuda Load Supported Default Default Maximum Number Maximum Number

Balancer ADC Instance Type in vCPU Memory of of
Model Amazon Web Elastic Network Private IP
Services Interfaces (ENIs) Addresses per ENI
BBFCAW003a m3.medium 1 3.75 GB 2 6
BBFCAW004a m3.large 2 7.5 GB 3 10
m4.large 2 8 GB 2 10
BBFCAW006a m3.xlarge 4 15 GB 4 15
m4.xlarge 4 16 GB 4 15
Hourly / Metered
With the Hourly/Metered licensing option, you complete the purchase or evaluation of the Barracuda Load Balancer ADC entirely within the AWS
Marketplace. After the instance is launched, it is provisioned automatically. You are charged hourly for both the Barracuda Load Balancer ADC
Software and Amazon Elastic Compute Cloud (Amazon EC2) usage on Amazon. For pricing information, refer to the AWS Marketplace.
Hourly/Metered Model and Instance Types
For Hourly / Metered licensing, Barracuda offers only model BBFCAW000p. Three instance types are available for this model. The following table
lists each instance type with its CPU, memory, and networking capacity.
If you want to increase the performance of an existing VM, configure it with a larger instance type on AWS and you will be charged accordingly by
Amazon. The VM will automatically be reconfigured by Amazon with the resources and capabilities of the larger instance type.
Barracuda Load Supported Default Default Maximum Number Maximum Number

Balancer ADC Instance Type in vCPU Memory of of
Model Amazon Web Elastic Network Private IP
Services Interfaces (ENIs) Addresses per ENI

BBFCAW000p m3.medium 1 3.75 GB 2 6
m3.large 2 7.5 GB 3 10
m4.large 2 8 GB 4 15
Before You Begin
Before you deploy the Barracuda Load Balance ADC on Amazon Web Services, decide whether you want to purchase it with the Hourly/Metered
licensing option or the Bring Your Own License (BYOL) option. Then set up an Amazon Virtual Private Cloud (VPC).
A VPC is an isolated virtual network on the Amazon Web Services (AWS) Cloud where you can launch AWS resources, such as Amazon EC2
instances. When you set up a VPC, specify IP addresses in the form of Classless Inter-Domain Routing (CIDR) blocks (for example, 10.0.0.0/16).
In a VPC, you can select your own IP address range, create subnets, and configure routing tables and network gateways.
The VPC cannot be larger than /16.
For more information about CIDR notation, refer to Classless Inter-Domain Routing on Wikipedia. For information about the number of VPCs that
you can create, refer to the AWS article Amazon VPC Limits.
To set up a VPC, complete the following steps. If you have already configured a VPC for the Barracuda Load Balancer ADC, you can skip ahead
to the Barracuda Load Balancer ADC Deployment and Quick Start Guide for Amazon Web Services.
Step 1. Create the Amazon VPC Cloud
1. Go to the AWS Management Console.

2. In the Networking section, click VPC.
3. On the VPC Dashboard, click Start VPC Wizard.
4. On the Step 1: Select a VPC Configuration page:

a. Select VPC with a Single Public Subnet.
b. Click Select.

5. On the Step 2: VPC with a Single Public Subnet page, do the following:
a. Enter an IP address for the VPC in the IP CIDR block field. It is recommend that you specify a CIDR block from the private
(non-publicly routable) IP address ranges as specified in RFC 1918; for example, 10.0.0.0/16.
b. Enter a name for the VPC in the VPC name field. Example: Barracuda-adc
c. Enter an IP address for the subnet in the Public subnet field. For example: 10.0.0.0/24
d. Select the availability zone for the VPC from the Availability Zone drop-down list.
e. Enter a name for the subnet in the Subnet name field.
f. Keep the default values for other parameters and click Create VPC.
Step 2. Add a Subnet to the VPC
If you wish to create multiple interfaces, add additional subnets to your VPC.
Perform the following steps to add a subnet to your VPC:
1. From the VPC Dashboard, select Subnets under Virtual Private Clouds.
2. Click Create Subnet.
3. In the Create Subnet window, do the following:
a. Specify a name for the subnet in the Name tag field. Example: ge-1-1
b. Select the VPC created in Step 1. Create a Virtual Private Cloud (VPC) from the VPC drop-down list.
c. Select the availability zone that your VPC resides from the Availability Zone drop-down list.
d. Specify the IP address(es) in the CIDR Block field.
e. Click Yes, Create.

If you want to use different networks for the interfaces created by you, add additional subnets to the VPC by repeating step 1 to 3.
Next Step
Now that you have set up a VPC for the Barracuda Load Balancer ADC, you can continue with the Barracuda Load Balancer ADC Deployment
and Quick Start Guide for Amazon Web Services.

Barracuda Load Balancer ADC Deployment and Quick Start Guide for Amazon Web Services
You can deploy the Barracuda Load Balancer ADC in a flat network (i.e., your management IP address and VIP address both reside in the same
network) on Amazon Web Services (AWS). Complete the steps in this guide to configure, launch, and license your Barracuda Load Balancer
ADC instance. Then log into the Barracuda Load Balancer ADC to verify your configuration and change your password before you start creating
services.
Requirements
Before you deploy the Barracuda Load Balance ADC on Amazon Web Services, ensure that you have completed the following:
Set up an Amazon Virtual Private Cloud (VPC) for the Barracuda Load Balancer ADC.
If you want to use the Bring Your Own Licensing (BYOL) model, get the Barracuda Load Balancer ADC license. See Bring Your Own
License (BYOL).
Step 1. Create a Security Group
Create a security group with rules that specify the protocols, ports, and source IP ranges permitted to reach the instance. Multiple security groups
can be created with different rules and assigned to each instance. For more information on security groups, refer to the AWS article Amazon EC2
Security Groups.
1. Log into the Amazon EC2 Management Console.

2. From the EC2 dashboard, select Security Groups under NETWORK & SECURITY.
3. Click Create Security Group.
4. In the Create Security Group window, do the following:
a. Security group name: Enter a name to identify the security group.
b. Description:Specify the description for the security group.
c. VPC: Select a VPC ID from the list.
5. Under Security group rules, specify the inbound and outbound traffic to be allowed for the instance.
a. Add ports 8000 and 443 in the inbound rule of the security group associated with the Barracuda Load Balancer ADC.
By default, the Barracuda Load Balancer ADC web interface listens on port 8000 for HTTP and port 443 for HTTPS.
If the instances are in cluster, add port 8002 (TCP) and port ALL for VRRP as inbound rule in the security group to
synchronize the configuration between them.
b. Add inbound rules to open the ports through which you configure the services on this instance.
Layer 4 services on the Barracuda Load Balancer ADC require all ports to be open for Inbound rules, so you must
open all ports if you are configuring any Layer 4 services on the Barracuda Load Balancer ADC.
c. Add an outbound rule to ensure that all ports are open irrespective of the service type:
TYPE: All Traffic
Protocol: All
Port Range: All
Destination: 0.0.0.0/0
d. If you are configuring Layer 4 services, add an inbound rule to ensure that all ports are open:
TYPE: All Traffic
Protocol: All
Port Range: All
Source: 0.0.0.0/0
e. After adding the inbound and outbound rules, click Create.

6. The created group appears in the security group table.
Step 2. Create a Network Interface
Create a minimum of two network interfaces (one for MGMT access and the other for creating services). Ensure that you create the network
interfaces in the subnet where you want to deploy the Barracuda Load Balancer ADC. The number of interfaces that can be attached to the
Barracuda Load Balancer ADC depends on the instance type that you selected on Amazon Web Services. For information about instance types,
see Licensing Options and Models.

2. From the EC2 dashboard, select Network Interfaces under NETWORK & SECURITY.
3. Click Create Network Interface.
4. In the Create Network Interface window, provide the following information for the network interface:
Description – Enter a name for the interface.
Subnet – Select the subnet of the VPC where you want to create the instance.
Private IP – It is recommended that you enter a static primary private IP address.
Security Groups – Select the security group that you created.
5. Click Yes, Create.
Step 3. Disable Source/Dest. check
You must also disable the Source/Dest. check in the interfaces that you created for the Barracuda Load Balancer ADC instance and configured
servers. When this check is enabled, it breaks the Layer 4 services.
1. Log into the AWS EC2 Management Console.

3. Right click the interface and select Change Source/Dest. Check.
4. In the Change Source/Dest. Check window, set Source/dest. check to Disabled and then click Save.
Step 4. (Optional) Assign Multiple Private IP Address(es) to the Network Interface of the Instance
Depending on the Barracuda Load Balancer ADC instance type, you can add multiple secondary IP addresses on the interfaces that are used to
create services on the Barracuda Load Balancer ADC. Do not add secondary IP addresses on the interface that is used for management access
of the Barracuda Load Balancer ADC. For more information on multiple IP addresses, refer to the Amazon EC2 article Multiple IP Addresses.
To assign a secondary private IP address:

3. Identify the interface needing a secondary private IP address assignment, and right-click the network interface attached to the instance.
4. Select Manage Private IP Addresses.
5. In the Manage Private IP Addresses window:
a. Click Assign a secondary private address.
b. In the Address field, enter an IP address that is within the subnet range for the instance. It is recommended that you use the
static IP address instead of auto-assign.
c. (Optional) To allow the secondary private IP address to be reassigned if it is already assigned to another network interface,
select Allow reassignment.
d. Click Yes, Update.
6.

6. Click Close.
Step 5. Deploy the Barracuda Load Balancer ADC on Amazon Web Services
In the Amazon VPC that you configured, launch an Amazon EC2 instance with the Barracuda Load Balancer ADC AMI image. The Amazon
Launch Instance wizard guides you through the following steps:
1. Log into the AWS Management Console and open the EC2 Management Console.
2. In the top right corner of the page, select the region for the instance. This is important because some Amazon EC2 resources can be
shared between regions.
3. Click Launch Instance.
4. On the Step 1: Choose an Amazon Machine Image (AMI) page, select AWS Marketplace and then search for and select the Barracu
da Load Balancer ADC AMI.
5. On the Step 2: Choose an Instance Type page, select an instance type from the All Instance types or General purpose table and
then click Next: Configure Instance Details to continue.
See Licensing Options to verify the recommended instance type for your Barracuda Load Balancer ADC model. Select the
recommended instance type.

6. On the Step 3: Configure Instance Details page:

a. Enter the Number of instances you want to launch.
b. Select the appropriate Network in which you want to deploy the instance.
c. Select the Subnet of the VPC where you want to create the instance.
d. In the Network Interface section:
i. Select the network interface for Management access of the Barracuda Load Balancer ADC.
ii. Click Add Device and select the network interface for creating services on the Barracuda Load Balancer ADC.
e. In the Advanced Details pane, keep the default setting for all parameters and then click Next: Add Storage.
7. On the Step 4: Add Storage page, review the storage device settings for the instance. Modify the values if required, and then click Next:
Tag Instance.

8. On the Step 5: Tag Instance page, add/remove the tags for the instance (if required) and then click Next: Configure Security Group.
9. On the Step 6: Configure Security Group page, select the security groups that you created in Step 1 and then click Review and
Launch.

10. On the Step 7: Review Instance Launch page, review your settings and then click Launch.
After you click Launch, Amazon Web Services begins provisioning the Barracuda Load Balancer ADC. Allow a few minutes for the Amazon Web
Services Agent and the Barracuda Load Balancer ADC image to boot up.
DO NOT restart the Barracuda Load Balancer ADC while it is launching.
Step 6. Allocate and Assign an Elastic IP Address to your Instance
As multiple interfaces are assigned to the instance, the Barracuda Load Balancer ADC will not be accessible to the outside world via the Internet
because the unit does not not yet have a public IP address. To resolve this issue, assign a persistent public IP address to the instance using
Elastic IP addressing. For more information, refer to the AWS article Elastic IP Addresses.
The elastic IP address associated to the first interface (eth0) will be the management IP address for the Barracuda Load Balancer ADC, and the
elastic IP address associated to the second interface (eth1) will be used to access the services created on the Primary IP Address of the
interface on the Barracuda Load Balancer ADC. Interface eth1 will be displayed as ge-1-1 on the Barracuda Load Balancer ADC.

2. From the EC2 dashboard, select Elastic IPs under NETWORK & SECURITY.
3. Click Allocate New Address.
4. Click Allocate to confirm and allocate a new IP address. A random public IP address is generated and displayed in the Allocate New
Address table.
5. On the Allocate New Address page, right-click the new IP address and select Associate.
6.

6. In the Associate Address window:

a. Either select the Instance and the Private IP Address of the instance or select a Network Interface and the Private IP
Address.
b. Select the Reassociation check box.
7. Click Associate.
8. If you completed Step 4. (Optional) Assign Multiple Private IP Address(es) to the Network Interface of the Instance to assign multiple
private IP address(es) to eth1 (which is displayed as ge-1-1 on the Barracuda Load Balancer ADC), repeat the steps above to assign the
Elastic IP address to each internal IP address so that they can be reachable from the outside world via the Internet.
Step 7. (BYOL Only) License the Barracuda Load Balancer ADC
If you deployed the Barracuda Load Balancer ADC with the Hourly/Metered option, you do not need to license the system; skip ahead
to Step 8. Verify your Configuration and Change the Password.
If you deployed the Barracuda Load Balancer ADC with BYOL, complete the licensing and provisioning of your system.

2. From the EC2 Dashboard, select Instances under INSTANCES.
3. In the Instances table, select the Barracuda Load Balancer ADC instance that you created and note the Elastic IP address associated
with eth0.
4. In a web browser, go to the Barracuda Load Balancer ADC web interface at the Elastic IP address that was assigned to eth0. Use port
8000 for HTTP. No port is required for HTTPS. For example:
For HTTP: http://<EIP>:8000
For HTTPS: https://<EIP>
The Barracuda Load Balancer ADC is not accessible via the HTTPS port while it is booting up. Use the HTTP port to access
the unit while it is booting. This displays the status of the unit (i.e., System Booting). After the boot process completes, you are
redirected to the login page.
5. On the Licensing page, enter your Barracuda Networks Token and Default Domain to complete licensing and then click Provision.
The Barracuda Load Balancer ADC connects to the Barracuda Update Server to get the required information based on your license and
then reboots automatically. Allow a few minutes for the reboot process.
After the boot process is complete, the Licensing page displays with the following options:

a. I Already Have a License Token – Use this option to provision your Barracuda Load Balancer ADC with the license token you
have already obtained from Barracuda Networks. Enter your Barracuda Networks Token and Default Domain to complete
licensing, and then click Provision.
The Barracuda Load Balancer ADC connects to the Barracuda Update Server to get the required information based on your
license, and then reboots automatically. Allow a few minutes for the reboot process. Once the instance is provisioned, you are
b. I Would Like to Purchase a License – Use this option to purchase the license token for the Barracuda Load Balancer ADC.
Provide the required information in the form, accept the terms and conditions, and click Purchase.
c. I Would Like to Request a Free Evaluation – Use this option to get 30 days free evaluation of the Barracuda Load Balancer
ADC. Provide the required information in the form, accept the terms and conditions, and click Evaluate.
Step 8. Verify your Configuration and Change the Password
2. Log into as the administrator. Use the following credentials:
Username: admin
Password: The Instance ID of your Barracuda Load Balancer ADC in Amazon Web Services.
3. Go to the BASIC > Administration page and change your password.
Next Steps
Before you start configuring services on the Barracuda Load Balancer ADC, you can attach multiple interfaces to the Barracuda Load Balancer
ADC, and bond those interfaces to increase the throughput of the Barracuda Load Balancer ADC. It is recommended that you create the link
bond before you configure your services because the Barracuda Load Balancer ADC cannot have any configurations when you create the link
bond. For instructions, see Creating a Link Bond on the Barracuda Load Balancer ADC for Amazon Web Services.
To start configuring your services in the Barracuda Load Balancer ADC, continue with Configuring Services on the Barracuda Load Balancer
ADC for Amazon Web Services.
If you need help troubleshooting any issues with your Barracuda Load Balancer ADC, see Troubleshooting the Barracuda Load Balancer ADC on
Amazon Web Services.

Clustering the Barracuda Load Balancer ADC Instances in Amazon Web Services
This article walks you through the steps to configure the Barracuda Load Balancer ADC for high availability in Amazon Web Services. It also
describes how to configure the Barracuda Load Balancer ADC to manage AWS routes for the applications.
In the high availability setup, both primary and secondary instances must be configured with minimum of two elastic network interfaces (i.e. one
default interface for management path traffic and the other for data path traffic). You can deploy the instances in the same availability zone or
different availability zones.
L2 networking is not exposed in AWS, so high availability pair makes use of AWS API's to failover services from the primary unit to the
secondary unit in the event of a primary unit outage.
Pre-requisites
Before deploying the Barracuda Load Balancer ADC instances in Amazon Web Services, ensure that you have completed the following:
1. Create a Virtual Private Cloud (VPC) - Refer to Step 1. Create the Amazon VPC Cloud in the Amazon Web Services article.
2. Add a subnet to the VPC - Refer to Step 2. Add a Subnet to the VPC in the Amazon Web Services article. This step is required only
when you want to use different networks for the interfaces you have created.
3. Create a Security Group - Refer to Step 1. Create a Security Group in the Barracuda Load Balancer ADC Deployment and Quick Start
Guide for Amazon Web Services article. If the instances are in a cluster, add port 8002 (TCP) and port ALL for VRRP as inbound rule in
the security group to synchronize the configuration between them.
4. Create a Network Interface - Refer to Step 2. Create a Network Interface in the Barracuda Load Balancer ADC Deployment and Quick
Start Guide for Amazon Web Services article.
5. Disable Source/Dest. Check - Refer to Step 3. Disable Source/Dest. Check in the Barracuda Load Balancer ADC Deployment and
Quick Start Guide for Amazon Web Services article.
6. Assign Multiple Private IP Address(es) to the Network Interface of the Instance - Refer to Step 4. (Optional) Assign Multiple Private IP
Address(es) to the Network Interface of the Instance in the Barracuda Load Balancer ADC Deployment and Quick Start Guide for
Amazon Web Services article.
7. Create an IAM Role.
8. (Optional) Get the Access Keys for Your AWS Account.
Create an IAM Role
AWS Identity and Access Management (IAM) is a web service on Amazon Web Services (AWS) that enables you to manage users and user
permissions to AWS resources. Using IAM, you can create a policy with the permissions to AWS resources and associate the policy with a role.
When the role is associated with the instance, applications running on that instance can use the role and make AWS API calls. You can select
and associate the role with the instance when launching an EC2 instance. A role can be associated with multiple instances on Amazon Web
Services.
To meet the needs of the Barracuda Load Balancer ADC HA functionality, create a policy/role with the following permissions for the same
availability zone and different availability zones:
IAM Policy for the Same Availability Zone
1. Ability to attach an Elastic Network Interface with an instance

2. Ability to detach an Elastic Network Interface with an instance
3. Read-only permissions to run Amazon EC2 describe* commands
4. Ability to assign private IP addresses with an instance
IAM Policy for Different Availability Zones
1. Ability to associate Elastic IP address

2. Ability to disassociate Elastic IP address
3. Ability to describe Elastic IP address
4. Read-only permissions to run Amazon EC2 describe* commands
Perform the following steps to create an IAM role:

2. Click Identity & Access Management under Security & Identity.

3. On the IAM Management Console page, click Policies on the left panel.
4. Click Create Policy.
5. On the Step 1: Create Policy page, click Select next to Create Your Own Policy.
6. On the Step 3: Review Policy page, do the following:

a. Policy Name: Enter a name for the policy.
b. Description: (Optional) Provide description for the policy.
c. Policy Document: Define the set of permissions for the policy in the JSON format.

Policy for the Same Availability Zone

{
"Version": "2012-10-17",
"Statement": [
"Sid": "Stmt1453446578000",
"Effect": "Allow",
"Action": [
"ec2:AssignPrivateIpAddresses",
"ec2:DescribeInstances",
"ec2:DetachNetworkInterface",
"ec2:AttachNetworkInterface"
],
"Resource": [
"*"
Policy for Different Availability Zones

{
"Version": "2012-10-17",
"Statement": [
"Action": [
"ec2:DescribeAddresses",
"ec2:AssociateAddress",
"ec2:DisassociateAddress",
"ec2:DescribeNetworkInterfaces",
"ec2:DescribeNetworkInterfaceAttributes"
],
"Resource": [
"*"
],
"Effect": "Allow"
d.

d. Click Validate Policy to verify that the policy is valid.

e. After the policy is validated, a status message: “This policy is valid” gets displayed on the screen.
f. Click Create Policy.

7. The created policy appears in the policies table.
8. On the IAM Management Console page, click Roles on the left panel.
9. Click Create New Role.
10. On the Step 1: Set Role Name page, specify a name for the role in the Role Name field and click Next Step.
11. On the Step 2: Select Role Type page, click Select next to Amazon EC2.
12. On the Step 4: Attach Policy page, select the policy created in step 5 and 6 above and click Next Step.

13. On the Step 5: Review page, review the role information and click Create Role.
This completes the creation of an IAM role. You can associate the role when you are launching an EC2 instance on AWS.
(Optional) Get the Access Keys for Your AWS Account
Access keys (Access Key ID and Secret Access Key) are required to perform AWS API calls. Proceed with this step if an IAM role is not defined
as mentioned in Step 1: Create an IAM Role. For more information on access keys, refer to the Getting Your Access Key ID and Secret Access
Key article in Amazon Web Services documentation.
Perform the following steps to get your access key ID and secret access key:

2. Click Identity & Access Management under Security & Identity.
3. On the IAM Management Console page, click Users on the left panel.
4. Click on the IAM user name to which you want to get an access key ID and secret access key.
5. Select Security Credentials under user summary, and click Create Access Key.

5.
6. The Create Access Key window appears with the security credentials. Click Show User Security Credentials to see the Access Key
ID and Secret Access Key associated with the user.
7. Click Download Credentials and save the keys to a secure location.
The secret key will no longer be available through the AWS Management Console. Ensure that you secure your access keys to protect your
account from unauthorized users. Do not email your access keys to anyone, and do not share it outside your organization even if an inquiry
appears to come from AWS or Amazon.com. No one who legitimately represents Amazon will ever ask you for your secret key.
Next Step
Continue with Configuring Auto Scale Group as Back-end Servers.

Barracuda Load Balancer ADC CloudFormation Template (CFT)
"AWSTemplateFormatVersion" : "2010-09-09",
"Description" : "Barracuda Load Balancer ADC - Sample CFT showing how to launch two instances in Active/Passive HA pair",
"Metadata" : {
"AWS::CloudFormation::Interface": {
"ParameterGroups" : [
"Label" : { "default" : "Network Configuration" },
"Parameters" : [ "VpcId", "SubnetID", "ADCAdditionalPort" ]
},
"Label" : { "default":"Amazon EC2 Configuration" },
"Parameters" : [ "InstanceType", "ConfigureHA", "AssignElasticIp" ]
},
"Label" : { "default":"Barracuda ADC BootStrap configuration" },
"Parameters" : [ "ADCServiceName", "ADCServiceType", "ADCServicePort",
"ADCHTTPRedirectPort", "ADCInstantSSLDomain", "ADCServiceNetmask", "ADCServers" ]
],
"ParameterLabels" : {
"VpcId" : { "default" : "Which VPC should this be deployed to?" },
"SubnetID" : { "default" : "Select the subnet of the VPC where you want to create the instance" },
"InstanceType" : { "default" : "Instance Type" },
"AssignElasticIp" : { "default" : "Assign Elastic IP ?" },
"ConfigureHA" : { "default" : "Configure instances in High Availability Mode ?" },
"ADCServiceName" : { "default" : "Service Name" },
"ADCServiceType" : { "default" : "Service Type" },
"ADCServicePort" : { "default" : "Service Port" },
"ADCAdditionalPort" : { "default" : "Additional Port" },
"ADCHTTPRedirectPort" : { "default" : "HTTP Redirect Port" },
"ADCInstantSSLDomain" : { "default" : "Secure Site Domain" },
"ADCServiceNetmask" : { "default" : "Service Netmask" },
"ADCServers" : { "default" : "Servers" }
},
"Parameters" : {

"VpcId": {
"Description": "Select the VPC chosen for this deployment",
"Type": "AWS::EC2::VPC::Id"
},
"SubnetID": {
"ConstraintDescription": "Enter valid Subnet Id's associated to the VPC (subnet-*)",
"Type": "AWS::EC2::Subnet::Id",
"Description": "Select subnet id which has been already assigned to the VPC used."
},
"InstanceType": {
"Default": "m3.medium",
"ConstraintDescription": "Choose from the following EC2 instance types: T2, M3, M4, C4",
"Type": "String",
"Description": "Choose the instance type to use for this deployment",
"AllowedValues": [
"m3.medium",
"m3.large",
"m3.xlarge",
"m3.2xlarge",
"m4.large",
"m4.xlarge"
},
"AssignElasticIp": {
"Description": "Associate Elastic Ip for accessing management interfaces and service that will be configured",
"Type": "String",
"Default" : "No",
"AllowedValues": [
"Yes",
"No"
},
"ConfigureHA": {
"Description": "Configure instances in Active/Passive HA pair",
"Type": "String",
"Default" : "No",
"AllowedValues": [
"Yes",
"No"

},
"ADCServiceName": {
"Description": "Specify the Service Name to be configured on the Barracuda ADC",
"AllowedPattern": "[0-9a-zA-Z-_]*",
"MinLength": "2",
"MaxLength": "64",
"Type": "String"
},
"ADCServiceType": {
"Description": "Specify the Service Type to be configured on the Barracuda ADC",
"Type": "String",
"Default" : "HTTP",
"AllowedValues": [
"Layer-4-TCP",
"Barracuda-Web-Filter",
"TCP-Proxy",
"Secure-TCP-Proxy",
"HTTP",
"HTTPS",
"Instant-SSL",
"FTP",
"FTP-SSL",
"Layer-7-RDP",
"Layer-4-UDP",
"UDP-Proxy"
},
"ADCServicePort": {
"Description": "Specify the Service Port to be configured on the Barracuda ADC. This port is exposed to the outside world. Default is 80.",
"Default": "80",
"ConstraintDescription": "Must be a valid port number (1-65535).",
"Type": "Number",
"MaxValue": "65535",
"MinValue": "1"
},
"ADCAdditionalPort": {
"Description": "(OPTIONAL) Specify any additional port to be opened in security group for dataplane interface. Default value -1 means no
additional port will be opened. This CFT by default will open 'Service Port' in security group for data plane interface. The following ports will be
opened in security group for managament interface(eth0): 8000, 443, 8002, 22, icmp(for ping test), VRRP(112) protocol. For details regarding
these ports please refer to Barracuda ADC AWS deployment techlib",

"Default": "-1",
"Type": "Number",
"MinValue": "-1"
},
"ADCHTTPRedirectPort": {
"Description": "(OPTIONAL) Specify the HTTP redirect port for an Instant SSL service. Default is 80",
"Default": "80",
"Type": "Number",
"MinValue": "1"
},
"ADCInstantSSLDomain": {
"Description": "(OPTIONAL) Specify the secure side domain for an Instant SSL service. To include all domains, enter an asterisk (*). ",
"Default": "*",
"ConstraintDescription": "Must be a valid domain as per the certificate. Use ADC Management UI to upload certificate",
"Type": "String"
},
"ADCServiceNetmask": {
"Description": "The netmask for the service.",
"Default": "255.255.255.0",
"Type": "String"
},
"ADCServers": {
"Description": "Specify the Server IP:Server Port combination in comma separated format e.g. 10.10.1.1:80, 10.10.2.1:80. This will be
configured as backend servers on the Barracuda ADC. Alternatively, you can also enter the FQDN of the instance or a downstream ELB to
connect to.",
"ConstraintDescription": "Must be a valid IP address or FQDN and Port separated by colon(:) in csv format",
"Type": "String"
},
"Mappings": {
"RegionMap": {
"us-east-1": {
"ImageID": "NOT_SUPPORTED"
},
"us-west-1": {
},

"us-west-2": {
"ImageID": "ami-d8b577b8"
},
"sa-east-1": {
},
"eu-central-1": {
},
"eu-west-1": {
},
"ap-southeast-1": {
},
"ap-southeast-2": {
},
"ap-northeast-1": {
},
"ap-northeast-2": {
},
"ServiceTypeMap": {
"Layer-4-TCP": {
"ServiceType" : "L4"
},
"Barracuda-Web-Filter": {
"ServiceType" : "INLINE"
},
"TCP-Proxy": {
"ServiceType" : "L7Tcp"
},
"Secure-TCP-Proxy": {
"ServiceType" : "SSL"
},
"HTTP": {
"ServiceType" : "HTTP"

},
"HTTPS": {
"ServiceType" : "HTTPS"
},
"Instant-SSL": {
"ServiceType" : "INSTANTSSL"
},
"FTP": {
"ServiceType" : "FTP"
},
"FTP-SSL": {
"ServiceType" : "FTPSSL"
},
"Layer-7-RDP": {
"ServiceType" : "RDP"
},
"Layer-4-UDP": {
"ServiceType" : "UDP"
},
"UDP-Proxy": {
"ServiceType" : "L7UDP"
},
"Conditions" : {
"AttachElasticIp" : {"Fn::Equals" : [{"Ref" : "AssignElasticIp"}, "Yes"]},
"HAPair" : {"Fn::Equals" : [{"Ref" : "ConfigureHA"}, "Yes"]},
"HAwithElasticIp" : {
"Fn::And": [
{"Fn::Equals" : [{"Ref" : "AssignElasticIp"}, "Yes"]},
{"Fn::Equals" : [{"Ref" : "ConfigureHA"}, "Yes"]}
},
"OpenAdditionalPort" : {
"Fn::Not" : [{
"Fn::Equals" : [
{"Ref" : "ADCAdditionalPort"},
-1
}]

},
"ServiceTypeUDP" : {
"Fn::Or": [
{"Fn::Equals" : [{"Ref" : "ADCServiceType"}, "Layer-4-UDP"]},
{"Fn::Equals" : [{"Ref" : "ADCServiceType"}, "UDP-Proxy"]}
},
"Resources": {
"HARole": {
"Type": "AWS::IAM::Role",
"Condition" : "HAPair",
"Properties": {
"AssumeRolePolicyDocument": {
"Statement": [ {
"Effect": "Allow",
"Principal": {
"Service": [ "ec2.amazonaws.com" ]
},
"Action": [ "sts:AssumeRole" ]
}]
},
"Path": "/",
"Policies": [ {
"PolicyName": "HA_Takeover",
"PolicyDocument": {
"Statement": [ {
"Effect": "Allow",
"Action": [
"ec2:AssignPrivateIpAddresses",
"ec2:DetachNetworkInterface",
"ec2:AttachNetworkInterface"
],
"Resource": "*"
}]
}]
},

"HARoleProfile": {
"Type": "AWS::IAM::InstanceProfile",
"Properties": {
"Path": "/",
"Roles": [ {
"Ref": "HARole"
}]
},
"mgmtENISG": {
"Type": "AWS::EC2::SecurityGroup",
"Properties": {
"GroupDescription": "Security Group for MGMT ENI",
"VpcId": { "Ref": "VpcId" },
"SecurityGroupIngress": [
{ "IpProtocol": "tcp", "FromPort": "443", "ToPort": "443", "CidrIp": "0.0.0.0/0" },
{ "IpProtocol": "icmp", "FromPort": "8", "ToPort": "-1", "CidrIp": "0.0.0.0/0" },
{ "IpProtocol": 112, "FromPort": "0", "ToPort": "-1", "CidrIp": "0.0.0.0/0" }
},
"dpENISG": {
"Type": "AWS::EC2::SecurityGroup",
"Properties": {
"GroupDescription": "Security Group for Data Plane ENI",
"VpcId": { "Ref": "VpcId" },
"SecurityGroupIngress": [
{ "IpProtocol": { "Fn::If" : [ "ServiceTypeUDP", "udp", "tcp" ] },
"FromPort": {"Ref": "ADCServicePort"},
"ToPort": {"Ref": "ADCServicePort"}, "CidrIp": "0.0.0.0/0"
},
"Fn::If" : [
"OpenAdditionalPort",
{ "IpProtocol": { "Fn::If" : [ "ServiceTypeUDP", "udp", "tcp" ] } ,
"FromPort": {"Ref": "ADCAdditionalPort"},

"ToPort": {"Ref": "ADCAdditionalPort"}, "CidrIp": "0.0.0.0/0"
},
{"Ref" : "AWS::NoValue"}
},
"dpENI": {
"Type": "AWS::EC2::NetworkInterface",
"Properties": {
"SubnetId": { "Ref": "SubnetID" },
"Description": "Dataplane Interface (ge-1-1)",
"GroupSet": [ { "Ref": "dpENISG" } ],
"SecondaryPrivateIpAddressCount" : 1,
"SourceDestCheck": "false"
},
"dpEIP" : {
"Type" : "AWS::EC2::EIP",
"Condition" : "AttachElasticIp",
"Properties" : {
"Domain" : "vpc"
},
"dpEIPAssoc" : {
"Type" : "AWS::EC2::EIPAssociation",
"Properties" : {
"NetworkInterfaceId" : { "Ref" : "dpENI" },
"AllocationId" : { "Fn::GetAtt" : ["dpEIP", "AllocationId"] },
"PrivateIpAddress" : { "Fn::Select" : ["0", { "Fn::GetAtt" : ["dpENI", "SecondaryPrivateIpAddresses"] } ] }
},
"mgmtENI": {
"Properties": {
"SubnetId": { "Ref" : "SubnetID" },
"Description": "Management Interface (eth0)",
"GroupSet": [ { "Ref": "mgmtENISG" } ],

"SourceDestCheck": "true"
},
"mgmtEIP" : {
"Properties" : {
"Domain" : "vpc"
},
"mgmtEIPAssoc" : {
"Properties" : {
"NetworkInterfaceId" : { "Ref" : "mgmtENI" },
"AllocationId" : { "Fn::GetAtt" : ["mgmtEIP", "AllocationId"] },
"PrivateIpAddress" : { "Fn::GetAtt" : ["mgmtENI", "PrimaryPrivateIpAddress" ] }
},
"AdcInstance": {
"Type": "AWS::EC2::Instance",
"Properties": {
"ImageId": { "Fn::FindInMap": [ "RegionMap", { "Ref": "AWS::Region" }, "ImageID" ] } ,
"InstanceType": { "Ref": "InstanceType" },
"IamInstanceProfile" : { "Fn::If" : [ "HAPair" , {"Ref" : "HARoleProfile"}, {"Ref" : "AWS::NoValue"} ] },
"Tags": [{ "Key" : "Name", "Value" : "ADC-1-CFT"}],
"NetworkInterfaces": [
{ "NetworkInterfaceId": { "Ref": "mgmtENI" }, "DeviceIndex": "0" },
{ "NetworkInterfaceId": { "Ref": "dpENI" }, "DeviceIndex": "1" }
],
"UserData": { "Fn::Base64" : { "Fn::Join" : ["", [
"#!/bin/bash\n",
"/opt/aws/bwaf/aws_bootstrap.pl ",
" --command init-config ",
" --clustered ", { "Ref" : "ConfigureHA" },
" --service_type ", { "Fn::FindInMap": [ "ServiceTypeMap", { "Ref": "ADCServiceType" }, "ServiceType" ] },
" --service_name ", { "Ref" : "ADCServiceName" },
" --service_ip ", { "Fn::Join" : [" ", { "Fn::GetAtt" : ["dpENI", "SecondaryPrivateIpAddresses"] } ] },
" --service_port ", { "Ref" : "ADCServicePort" },
" --interface ge-1-1 ",

" --http_redirect_port ", { "Ref" : "ADCHTTPRedirectPort" },
" --domain ", "'", { "Ref" : "ADCInstantSSLDomain" }, "'",
" --service_netmask ", { "Ref" : "ADCServiceNetmask" },
" --servers ", { "Ref" : "ADCServers" }, "\n"
]]}}
},
"dpENI2": {
"Properties": {
"SubnetId": { "Ref": "SubnetID" },
"Description": "Dataplane Interface (ge-1-1)",
"GroupSet": [ { "Ref": "dpENISG" } ],
"SourceDestCheck": "false"
},
"mgmtENI2": {
"Properties": {
"SubnetId": { "Ref" : "SubnetID" },
"Description": "Management Interface (eth0)",
"GroupSet": [ { "Ref": "mgmtENISG" } ],
"SourceDestCheck": "true"
},
"mgmtEIP2" : {
"Condition" : "HAwithElasticIp",
"Properties" : {
"Domain" : "vpc"
},
"mgmtEIPAssoc2" : {
"Properties" : {
"NetworkInterfaceId" : { "Ref" : "mgmtENI2" },
"AllocationId" : { "Fn::GetAtt" : ["mgmtEIP2", "AllocationId"] },

"PrivateIpAddress" : { "Fn::GetAtt" : ["mgmtENI2", "PrimaryPrivateIpAddress" ] }
},
"AdcInstance2": {
"Type": "AWS::EC2::Instance",
"DependsOn" : "AdcInstance",
"Properties": {
"ImageId": { "Fn::FindInMap": [ "RegionMap", { "Ref": "AWS::Region" }, "ImageID" ] } ,
"InstanceType": { "Ref": "InstanceType" },
"IamInstanceProfile" : { "Fn::If" : [ "HAPair" , {"Ref" : "HARoleProfile"}, {"Ref" : "AWS::NoValue"} ] },
"Tags": [{ "Key" : "Name", "Value" : "ADC-2-CFT"}],
"NetworkInterfaces": [
{ "NetworkInterfaceId": { "Ref": "mgmtENI2" }, "DeviceIndex": "0" },
{ "NetworkInterfaceId": { "Ref": "dpENI2" }, "DeviceIndex": "1" }
],
"UserData": { "Fn::Base64" : { "Fn::Join" : ["", [
"#!/bin/bash\n",
"/opt/aws/bwaf/aws_bootstrap.pl ",
" --command init-config ",
" --peer_node ", { "Fn::GetAtt" : ["mgmtENI", "PrimaryPrivateIpAddress" ] },
" --clustered ", { "Ref" : "ConfigureHA" }, "\n"
]]}}
},
"Outputs" : {
"InstanceId" : {
"Value" : { "Ref" : "AdcInstance" },
"Description" : "Instance ID of ADC"
},
"InstanceIdSecondary" : {
"Value" : { "Ref" : "AdcInstance2" },
"Description" : "Instance ID of ADC(Secondary)"
},
"ManagementURL" : {
"Value" : { "Fn::Join" : ["", [ "http://", { "Ref" : "mgmtEIP" }, ":8000"]]},
"Description" : "URL for accessing ADC management GUI"

},
"ManagementURLSecondary" : {
"Value" : { "Fn::Join" : ["", [ "http://", { "Ref" : "mgmtEIP2" }, ":8000"]]},
"Description" : "URL for accessing ADC management GUI(Secondary)"
},
"ServiceIPPort" : {
"Value" : { "Fn::Join" : ["", [ { "Ref": "dpEIP" }, ":", {"Ref" : "ADCServicePort"}]]},
"Description" : "Service IP and Port for accessing the virtual service"

Clustering the Barracuda Load Balancer ADC Instances in Different Availability Zones
This article walks you through the steps to configure the Barracuda Load Balancer ADC instances for high availability in different availability
zones in Amazon Web Services.
Before you continue with the steps mentioned below, ensure that you have completed the configuration settings mentioned in the Clust
ering the Barracuda Load Balancer ADC Instances in Amazon Web Services article.
Step 1. Deploy Two Barracuda Load Balancer ADC Instances on Amazon Web Services
Follow the instructions mentioned in Step 5. Deploy the Barracuda Load Balancer ADC on Amazon Web Services in the Barracuda Load
Balancer ADC Deployment and Quick Start Guide for Amazon Web Services article and deploy two Barracuda Load Balancer ADC instances in
two different availability zones.
Ensure you select the IAM role created in Create an IAM Role when deploying the Barracuda Load Balancer ADC instances.
Step 2. Allocate and Assign an Elastic IP Address to Your Instance
Follow the instructions mentioned in Step 6. Allocate and Assign an Elastic IP Address to your Instance in the Barracuda Load Balancer
ADC Deployment and Quick Start Guide for Amazon Web Services article to allocate the elastic IP address to the deployed Barracuda Load
Balancer ADC instances.
Step 3. License the Barracuda Load Balancer ADC
Follow the instructions mentioned in Step 7. (BYOL Only) License the Barracuda Load Balancer ADC in the Barracuda Load Balancer ADC
Deployment and Quick Start Guide for Amazon Web Services to provision the deployed Barracuda Load Balancer ADC instances.
Step 4. Verify Your Configuration and Change the Password
Follow the instructions mentioned in Step 8. Verify your Configuration and Change the Password in the Barracuda Load Balancer ADC
Deployment and Quick Start Guide for Amazon Web Services article to verify your configuration and change the password on both of the
deployed Barracuda Load Balancer ADC instances.
Step 5. Cluster the Deployed Barracuda Load Balancer ADC Instances
Follow the instructions mentioned in Step 5: Cluster the Deployed Barracuda Load Balancer ADC Instances in the Clustering the Barracuda
Load Balancer ADC Instances in the Same Availability Zone article to deploy the instances.
Step 6. Configure the Service(s) on the Barracuda Load Balancer ADC
If you have deployed the Barracuda Load Balancer ADC instance with two interfaces (i.e., mgmt (eth0) and ge-1-1 (eth1)), create the service by
following the steps mentioned below:
1. Log into the Barracuda-LB-ADC1 (Primary/Active unit) web interface.

2. Use the private IP addresses assigned to both the instances as your VIP to create the service. Go to the BASIC > Services page, and
click Add Service.
3. In the Add Service window, specify values for the following fields:
a. Name: Enter a name for the service.
b. Group: Enter the group name under which you want to create the service.
c. Service: Select Enable.
d. Type: Select the type of the service you want to create. For example: HTTP
e. IP Address: Click Add and enter the private IP address of the primary instance (i.e. Barracuda-LB-ADC1) and click Done
Editing. Click Add again, enter the private IP address of the secondary instance (i.e.Barracuda-LB-ADC2) and click Done
Editing.
f. Service Port: Enter the port for the service.
g. Netmask: Enter the netmask of the IP address.
h. Interface: Select the interface for the service.
i. Click Create. For more information on how to add a service, click the Help button in the web interface.

4. Go to the NETWORK > Routes page.

5. In the Add Static Route section:
a. IP Protocol Version - Select IPv4
b. IP Address - Enter 0.0.0.0.
c. Netmask - Enter 0.0.0.0.
d. Gateway Address - Enter 10.0.1.1.
e. Network Interface - Select ge-1-1.
6. Click Save.
7. Repeat step 5 and 6 to add another route. Note: The Gateway Address for this route should be the gateway address of the secondary
instance.
8. Go to the BASIC > Services page, select the service you created in step 3 and click Add Server.
9. In the Add Server window, specify values for the following fields:
a. Name: Enter a name for the server.
b. Status: Select Enable.
c. Identifier: Select Autoscale Group.
d. Port: Enter the port for the auto scale group.
e. Autoscale Group: Enter the auto scale group name created in Step 1: Create an Auto Scaling Group.
f. Click Resolve AutoScale Group. This will resolve the server IP addresses added in the specified auto scale group.

g. Specify values for other parameters as required and click Create.

Clustering the Barracuda Load Balancer ADC Instances in the Same Availability Zone
This article walks you through the steps to configure the Barracuda Load Balancer ADC instances for high availability in the same availability
zone in Amazon Web Services.
Step 1. Deploy Two Barracuda Load Balancer ADC Instances on Amazon Web Services
Follow the instructions mentioned in Step 5. Deploy the Barracuda Load Balancer ADC on Amazon Web Services in the Barracuda Load
Balancer ADC Deployment and Quick Start Guide for Amazon Web Services article and deploy two Barracuda Load Balancer ADC instances in
the same availability zone.
Ensure you select the IAM role created in Create an IAM Role when deploying the Barracuda Load Balancer ADC instances.
Step 2. Allocate and Assign an Elastic IP Address to Your Instance
Follow the instructions mentioned in Step 6. Allocate and Assign an Elastic IP Address to your Instance in the Barracuda Load Balancer
ADC Deployment and Quick Start Guide for Amazon Web Services article to allocate the elastic IP address to the deployed Barracuda Load
Balancer ADC instances
It is not required to assign the elastic IP address to the primary address of ge-1-1 and other subsequent interfaces, however, secondary
private IP addresses of ge-1-1 and other subsequent interfaces must be assigned with an elastic IP address, so that the services can
be accessed from the external network.
Step 3. License the Barracuda Load Balancer ADC
Follow the instructions mentioned in Step 7. (BYOL Only) License the Barracuda Load Balancer ADC in the Barracuda Load Balancer ADC
Deployment and Quick Start Guide for Amazon Web Services to provision the deployed Barracuda Load Balancer ADC instances.
This step is required only if you have deployed the BYOL model of the Barracuda Load Balancer ADC.
Step 4. Verify Your Configuration and Change the Password
Follow the instructions mentioned in Step 8. Verify your Configuration and Change the Password in the Barracuda Load Balancer ADC
Deployment and Quick Start Guide for Amazon Web Services article to verify your configuration and change the password on both of the
deployed Barracuda Load Balancer ADC instances.
Step 5. Cluster the Deployed Barracuda Load Balancer ADC Instances
Follow the steps below to cluster your Barracuda Load Balancer ADC virtual machines in Amazon Web Services:
1. Log into the first Barracuda Load Balancer ADC web interface that will act as your Primary/Active unit. In the instructions below, consider
this virtual machine as Barracuda-LB-ADC1.
2. In the Barracuda-LB-ADC1 web interface, go to the ADVANCED > High Availability page and do the following configuration in the Clus
ter Settings section:
a. Set Enable High Availability to Yes.
b. Enter a Cluster Shared Secret password. This is the shared passcode that the clustered units use when communicating with
one another. Both systems in the cluster must have the same shared secret.
c. Enter the Cluster Group ID. The ID should be the same on both Barracuda Load Balancer ADC instances that are to be
clustered. If, on the local network, other network components, such as firewalls, are clustered using VRRP, they should use a
different Cluster Group ID than this one. Maximum value is 255.
d. AWS Access Key ID: (Optional) Enter the access key ID created in Step 2: (Optional) Get the Access Keys for Your AWS
Account.
e. AWS Secret Access Key: (Optional) Enter the secret access key created in Step 2: (Optional) Get the Access Keys for Your
AWS Account.
3. Click Save.

4. Log into the second Barracuda Load Balancer ADC web interface that will act as your Secondary/Backup unit. In the instructions below,
consider this virtual machine as Barracuda-LB-ADC2.
5. In the Barracuda-LB-ADC2 web interface, go to the ADVANCED > High Availability page and do the following configuration:
a. Repeat step 2.a to step 2.e in the Cluster Settings section as mentioned in Step 7: Cluster the Deployed Barracuda Load
Balancer ADC Instances.
b. In the Clustered Systems section, enter the management IP address of the active Barracuda Load Balancer ADC and click Joi
n Cluster.
c. The clustering will run as a background task and take a few minutes to complete. Do not do any other configuration changes
while the clustering task is running.
6. After a few minutes, refresh the ADVANCED > High Availability page on both systems and verify the following:
a. Each system's management IP address appears in the Clustered Systems table.
b. The status of the Primary (active) system should be .
c. The status of the Backup (passive) system should be .
Continue with Configuring Services on the Barracuda Load Balancer ADC in High Availability Environment.
Step 6. Configure the Service(s) on the Barracuda Load Balancer ADC
This section includes:
Configuring the Service(s) on the Barracuda Load Balancer ADC Instance with Interfaces of the Same Subnet
Configuring the Service(s) on the Barracuda Load Balancer ADC Instance with Interfaces from the Multiple Network
Configuring Services on the Barracuda Load Balancer ADC Instance with Interfaces of the Same Subnet.
If you have deployed the Barracuda Load Balancer ADC instance with two interfaces (i.e., mgmt (eth0) and ge-1-1 (eth1)) from the same network,
create the service by following the steps mentioned below to reach the instance from the external network:
1. Log into the Barracuda-LB-ADC1 (Primary/Active unit) web interface.

2. Go to the BASIC > Services page. Use the secondary private IP addresses assigned to the instance as your VIP to create services. See
Step.4 (Optional) Assign Multiple Private IP Address(es) to the Network Interface of Instance in the Barracuda Load Balancer ADC
Deployment and Quick Start Guide for Amazon Web Services article. For more information on how to add a service, click the Help button
in the web interface.
3. Go to the NETWORK > Routes page.
4. In the Add Static Route section:
a. IP Protocol Version - Select IPv4
b. IP Address - Enter 0.0.0.0.
c. Netmask - Enter 0.0.0.0.
d. Gateway Address - Enter 10.0.0.1.
e. Network Interface - Select ge-1-1.
5. Click Save.

All configuration should be done on the Primary/Active unit only, the configuration will be replicated to the Secondary/Backup unit
automatically. As per the example above, the Primary unit is Barracuda-LB-ADC1, and the Secondary unit is Barracuda-LB-ADC2.
Configuring Services on the Barracuda Load Balancer ADC with Interfaces from Multiple Networks
Skip this section if you have deployed the Barracuda Load Balancer ADC instance with two interfaces from the same network.
If you have deployed the Barracuda Load Balancer ADC instance with three interfaces, where two interfaces (i.e., mgmt (eth0) and ge-1-1 (eth1)
are from the same network and the other interface (ge-1-2 (eth2)) is from a different network, you must assign secondary private IP address to
each interface and then associate each secondary IP address with an elastic IP address, so that the instance can be accessed from the external
network.
Perform the steps below to assign secondary private IP addresses and associate elastic IP address:
1. Follow step 1 and 2 mentioned in the Configuring Services on the Barracuda Load Balancer ADC Instance with Interfaces of the Same
Subnet section.
If the service is configured using the primary private IP address, it will not failover in case of primary unit outage.
2. Go to the NETWORK > Routes page, and add a static route for ge-1-1 interface as mentioned below:
a. IP Protocol Version: Select IPv4
b. IP Address: Enter 0.0.0.0.
c. Netmask: Enter 0.0.0.0.
d. Gateway Address: Enter 10.0.0.1.
e. Network Interface: Select ge-1-1.
3. Click Save.
4. Add a static route for ge-1-2 interface as mentioned below:
a. IP Protocol Version: Select IPv4
b. IP Address: Enter 0.0.0.0.
c. Netmask: Enter 0.0.0.0.
d. Gateway Address: Enter 10.0.1.1.
e. Network Interface: Select ge-1-2.
5. Click Save.
All configuration should be done on the Primary/Active unit only; the configuration will be replicated to the Secondary/Backup unit
automatically. As per the example above, the Primary unit is Barracuda-LB-ADC1, and the Secondary unit is Barracuda-LB-ADC2.
After creating services and adding routes to the Barracuda Load Balancer ADC instance that is deployed with interfaces from multiple networks,
you must map the internet gateway in the routing table. See Map the Internet Gateway in the Routing Table.
Map the Internet Gateway in the Routing Table
To transmit traffic through the ge-1-2 interface that is in a different subnet than that of the default public subnet, you should map the subnet to the
internet gateway in the routing table, so that the subnet is reachable from the external network. Perform the following steps:
1. From the VPC Dashboard, select Virtual Private Gateways under VPN Connections in the left panel.

2. Click Create Virtual Private Gateway.

3. In the Create Virtual Private Gateway window, enter a name for the virtual private gateway in the Name tag field and click Yes, Create.
4. Select the created virtual private gateway from the list, and click Attach to VPC.
5. In the Attach to VPC window, select the VPC to which you want to attach the virtual private gateway from the VPC list, and click Yes,
Attach.
6. Select Subnets under Virtual Private in the left panel.

7. Select the subnet that is used for creating the ge-1-2 interface from the subnets list. Note the Route table entry under Summary.
8. Select Route Tables under Virtual Private Cloud in the left panel.
9. Select the route you noted in step 7, click on the Routes tab and click Edit.

9.
10. Click Add another route with Destination as 0.0.0.0 and Target as “igw-1df3da78”, which is the internet gateway. Click Save.
11. Select the Subnet Associations tab, and click Edit.

12. Ensure the Associate check box is selected for both the subnets, and click Save.

13. Select the Route Propagation tab, click Edit, and select the Propagate check box next to virtual private gateway. Click Save.
Now, you can access the service from the external network using the elastic IP address assigned to the service virtual IP addresses.

Configuring Auto Scale Group as Back-end Servers

Auto Scaling helps you maintain application availability and allows you to scale your Amazon EC2 capacity up or down automatically according to
conditions you define. For more information on auto scaling, refer to the Amazon documentation: Auto Scaling and Auto Scaling Groups articles.
To create an auto scaling group, perform the following steps:
1. Go to the EC2 Management Console.

2. Click Auto Scaling Groups under AUTO SCALING.
3. Click Create Auto Scaling group.
4. On the Create Auto Scaling Group page, select Create a new launch configuration and click Next Step.
5. On the 1. Choose AMI page, select a server AMI,
6. On the 2.Choose Instance Type page, select an instance type and click Next: Configure details.

7. On the 3.Configure details page, do the following:

a. Name: Enter a name for the server instance.
b. IAM role: Select the IAM role you have created.
c. In the Advanced Details section, select Assign a public IP address to every instance under IP Address Type and click Next
: Add Storage.
8. On the 4: Add Storage page, review the storage device settings for the instance. Modify the values if required, and then click Next:
Configure Security Group..
9. On the 5: Configure Security Group page:

a. Choose Select an existing security group under Assign a security group.
b. Select the security groups that you created and click Review.

10. On the 6: Review page, review your settings and click Create launch configuration.
11. In the Select an existing key pair or create a new key pair pop-up window:
a. Choose an existing key pair or create a new pair.
b. Select the I acknowledge that I have access to the selected private key file ("key pair name"), and that without this file, I
won't be able to log into my instance check box.
c. Click Create launch configuration.
12. On the 1. Configure Auto Scaling group details page, specify values for the following:
a. Group name: Enter a name for the auto scale group.
b. Group size: Enter the number of instances you want to add in the auto scale group.
c. Network: Select the VPC created by you.
d. Subnet: Select the subnets created for the VPC.
e. Click Next: Configure scaling policies.

13. On the 2. Configure scaling policies page, select Keep this group at its initial size or select Use scaling policies to adjust the
capacity of the group to configure as per your requirement.
14. On the 3. Configure Notifications page, click Add notification to configure notification settings (if required).
15. On the 4: Configure Tags page, add/remove the tags for the instance (if required) and click Review.
16. On the 5: Review page, review your settings before creating the auto scaling group, and click Create Auto Scaling group.

16.
17. The created auto scale group gets displayed in the auto scale group list.
To configure auto scale group as your servers, use the Barracuda Load Balancer ADC web interface. Refer to Clustering the Barracuda Load
Balancer ADC Instances in Different Availability Zones.
Next Step
Continue with Clustering the Barracuda Load Balancer ADC Instances in the Same Availability Zone or Clustering the Barracuda Load Balancer
ADC Instances in Different Availability Zones.

Deploying the Barracuda Load Balancer ADC in a High Availability (HA) Setup using the CloudFormation Template on
Amazon Web Services
The Barracuda Load Balancer ADC can be deployed in a HA setup on Amazon Web Services using the CloudFormation Template. The
Barracuda Load Balancer ADC integrates with various AWS services to provide HA capability.
Deployment using the CloudFormation template enables you to bootstrap the configuration of the Barracuda Load Balancer ADC. The initial
deployment will allow you to specify the service configuration during launch. After the deployment, the instances come up as a clustered
Active/Passive HA pair. The configuration between the clustered instances is automatically synchronized once in every two (2) minutes.
The latest Barracuda CloudFormation Template (CFT) is available < HERE >. This CFT will deploy the Barracuda Load Balancer ADC with the
basic service configuration and set up the necessary AWS IAM Roles for a successful bootstrapping
This CFT deploys the Barracuda Load Balancer ADC into a pre-existing VPC deployment to load balance the servers.
The Barracuda CloudFormation Template (CFT):
Provides an option to select the deployment mode (Stand-alone or High Availability (HA)) for the Barracuda Load Balancer ADC.
Creates an IAM role that can be used to make AWS API calls for service failover in case of outage.
Security group creation and assignment to the deployed Barracuda Load Balancer ADC instances.
AWS Services required for the HA Setup
The following are the AWS services required for the HA setup:
Virtual Private Cloud (VPC)

Elastic Compute Cloud (EC2)
CloudFormation
Identity and Access Management (IAM)
Pre-requisites
Latest Barracuda Load Balancer ADC CFT Template.

VPC ID, and subnet ID where you want to deploy the Barracuda Load Balancer ADC and load balance your servers.
Ability to create an IAM Role. The CFT will create an IAM role that has permissions to attach and detach secondary private IP's.
Default Values of the Barracuda Load Balancer ADC CloudFormation Template
The following are the default values of the Barracuda CloudFormation Template (CFT). You can modify the values as needed.
Instance Type - Instance type to be used in Amazon Web Services (AWS). Default: m3.medium
Security Group with the following ports opened:
Port Protocol Description
8000 TCP Provides Management access to the

Barracuda Load Balancer ADC web
interface.
80 TCP Provides HTTP access to the Barracuda

Load Balancer ADC web interface
443 TCP Provides HTTPS access to the Barracuda

Load Balancer ADC web interface.
8002 TCP Required for clustering the instances.
ALL VRRP(112) Used for heart beat between the instances.
ALL ICMP To enable ping between the instances. This

is also helpful in troubleshooting.
ALL ALL Required for Layer 4 services to serve traffic.
How Barracuda CloudFormation Template (CFT) Works
What CloudFormation Template (CFT) does:
1. A CloudFormation Template (CFT) is uploaded and a stack is created on Amazon Web Services. With this:
a. An Amazon S3 bucket gets created with the specified stack name and unique ID.
b. An appropriate IAM role to access the S3 bucket is added.
2. The Barracuda Load Balancer ADC VM(s) will be deployed.
3. After the Barracuda Load Balancer ADC instance is up and ready to serve the traffic:
a.

3.
a. ADC Instance is configured based on the service configuration data provided during CFT upload.
4. The Barracuda Load Balancer ADC Primary is now ready to serve the traffic to the configured services.
5. If the secondary instance detects that primary is unreachable it does the following:
a. Make AWS API calls to transfer the secondary private IP addresses from the Primary instance to itself.
b. It assumes active role and starts serving the traffic till the primary instance is reachable again.
Importing the Barracuda Load Balancer ADC Template and Deploying the Instance
Perform the steps below to import the Barracuda Load Balancer ADC CloudFormation Template and deploy the instance:
1. Log into the Amazon Management Console.

2. Select CloudFormation under Management Tools.
3. In the CloudFormation Management Console, click Create Stack.

4. In the Create A New Stack page, perform the following steps:
a. On the Select Template page:
i. Select Upload a template to Amazon S3 under Choose a template.
ii. Click Browse to select the Barracuda Load Balancer ADC’s latest CFT
iii. Click Next. The Specify Details page appears.
b. On the Specify Details page, do the following configuration:

i. In the Specify Details section:
1. Enter a name for the CloudFormation stack in the Stack Name field.
ii. In the Parameters section, specify values for the following:
Network Configuration
Parameter Name Description
Which VPC should this be deployed to? Select the VPC that you wish to deploy the Barracuda
Load Balancer ADC instance(s) from the drop-down list.
Select the subnet of the VPC where you want to Select the subnet ID associated with the availability
create the instance zone(s) where the Barracuda Load Balancer ADC
instance needs to be deployed. Note that the subnet
must be part of the VPC that you choose.
Additional Port Specify any additional port to be opened in the security

group for the ge-1-1 interface. "-1" is the default value,
which means no additional port will be opened. If you
want to open additional ports like 443, 80, etc., specify
the required ports here.

Amazon EC2 Configuration
Instance Type Select an instance type depending on your requirement.
Configure instances in High Availability Mode? Select Yes if you want to deploy the instance in a
high availability setup.
Select No if you want to deploy the instance as a
stand-alone unit.
Assign Elastic IP? Select Yes to assign an elastic IP address to the

instance.
Barracuda ADC BootStrap Configuration
Service Name Enter a name for the service that needs to be created on
the Barracuda Load Balancer ADC instance.
Service Type Select the service type for the service.
Service Port Enter the port number on which the service is listening
to.
HTTP Redirect Port (Optional) Enter the HTTP redirect port for an Instant
SSL service.
Secure Site Domain (Optional) Enter the secure side domain for an Instant
SSL service. To include all domains, enter an asterisk
(*).
Service Netmask Enter the netmask for the service.
Servers Enter the IP address of the server, or Fully Qualified

Domain Name (FQDN) of the server.
c.

c. Click Next to continue.

d. On the Options page, enter a key-value pair to identify the instance(s) of this stack. Click Next.
e. On the Review page, verify the values you entered, select the IAM capability check box, and click Create.
5. The CFT now starts its operation. You can see the CREATE_IN_PROGRESS status displayed on the CloudFormation Management
Console for the stack. Select the tabs and see the status of events and resources that are being created. An example of the successfully
created resources is available in the screenshot below:

6. After the stack is created, the Barracuda Load Balancer ADC instances will be deployed. To access the instance(s), select the Output ta
b and click on the Management URLs.
7. You will be redirected to the Licensing page with the following options.
a. I Already Have a License Token – Use this option to provision your Barracuda Load Balancer ADC with the license token you
have already obtained from Barracuda Networks. Enter your Barracuda Networks Token and Default Domain to complete
licensing, and then click Provision.

b. I Would Like to Purchase a License – Use this option to purchase the license token for the Barracuda Load Balancer ADC.
Provide the required information in the form, accept the terms and conditions, and click Purchase.
c. I Would Like to Request a Free Evaluation – Use this option to get 30 days free evaluation of the Barracuda Load Balancer
ADC. Provide the required information in the form, accept the terms and conditions, and click Evaluate.
8. Log into the Barracuda Load Balancer ADC instance with:
a. Username: admin
b. Password: Instance ID of your Barracuda Load Balancer ADC in Amazon Web Services.
9. Navigate to the BASIC > Administration page and enter your old password, new password, and re-enter the new password. Click Save
Password.
If you have configured an HTTPS/Instant SSL service, ensure that the correct domain name and the trusted certificate is associated
with the service.

Configuring Services on the Barracuda Load Balancer ADC Vx for Amazon Web Services
Before you configure services on the Barracuda Load Balancer ADC Vx, you can create a link bond to increase the throughput of its
interfaces. For instructions, see Creating a Link Bond on the Barracuda Load Balancer ADC Vx for Amazon Web Services.
You can configure Layer 7 or Layer 4 services in the Barracuda Load Balancer ADC Vx on Amazon Web Services. For more information on the
available service types, see Services.
Step 1. Get the EIP and Private IP Address of your Instance

2. From the EC2 dashboard, select Instances under INSTANCES.
3. Select the Barracuda Load Balancer ADC Vx instance for which you want to configure a service and note the Elastic IP Address.
4. Click the instance in the Instances table and then click the eth1 link next to Network Interfaces.
5. Note the private IP address of eth1.
Step 2. Create the Service
2. Go to the BASIC > Services page and create a service (Layer 7 or Layer 4) using the Private IP Address assigned to the eth1 network
interface on Amazon Web Services (this is the ge-1-1 interface on the Barracuda Load Balancer ADC Vx).
3. Add a server to the created service.
4. Go to the NETWORK > Routes page and add a static route for the ge-1-1 interface to route all ge-1-1 traffic through the management
gateway. The static route for ge-1-1 is:
IP Protocol Version – IPv4
IP Address - 0.0.0.0
Netmask – 0.0.0.0
Gateway Address – Enter the IP address specified in IPv4 Default Gateway on the BASIC > IP Configuration page.
Network Interface – ge-1-1
Step 3. Allocate an Elastic IP Address for the Service IP Address
If you have assigned multiple IP addresses to the eth1 interface and have created the service using one of those IP addresses, ensure
that the IP address is associated with an Elastic IP address (EIP). An EIP ensures that the service is reachable over the Internet.
To assign and allocate an EIP for the service IP address:

2. From the EC2 dashboard, select Elastic IPs under NETWORK & SECURITY.
3. Click Allocate New Address.
4. Click Yes, Allocate to confirm and allocate a new IP address. A random public IP address is generated and displayed in the Allocate
New Address table.
5. In the Allocate New Address table, right-click the new IP address and select Associate.
6. In the Associate Address window:
a. Either select the Instance and the Private IP Address of the instance or select the Network Interface and the Private IP
Address.
b. Select the Allow Reassociation check box.
7. Click Yes, Associate.

Step 4. (Layer 4 Services Only) Change the Default Gateway for Servers
For Layer 4 services, change the default gateway for the associated servers.
1. Log into your server using SSH.
You must log into the server from the machine that resides in the same network as your server.
2. Remove the default gateway on the server.

3. Add the IP address which is being used to create the Layer 4 service on the Barracuda Load Balancer ADC Vx as your default gateway.
If you want to configure your server in Direct Server Return mode, follow the instructions given in Direct Server Return Deployment.
Troubleshooting
If you need help troubleshooting any issues with your Barracuda Load Balancer ADC Vx, see Troubleshooting the Barracuda Load Balancer ADC
Vx on Amazon Web Services.

Creating a Link Bond on the Barracuda Load Balancer ADC Vx for Amazon Web Services
Before you create a link bond, ensure the Barracuda Load Balancer ADC Vx has NO configurations.
You can attach multiple interfaces to the Barracuda Load Balancer ADC Vx, and bond those interfaces to increase the throughput of the
Barracuda Load Balancer ADC Vx. The maximum number of interfaces that you can attach to the Barracuda Load Balancer ADC Vx instance
depends on the instance type. For more information on instance types, see Licensing Options.
Step 1. Attach Multiple Interfaces to the Barracuda Load Balancer ADC Vx Instance
1. Turn OFF the Barracuda Load Balancer ADC Vx.

4. Create the additional network interfaces. For each interface:
a. Click Create Network Interface.
b. In the Create Network Interface window, provide the following information for the network interface:
Description – Enter a name for the interface.
Subnet – Select the subnet of the VPC where you created the Barracuda Load Balancer ADC Vx instance.
Private IP – It is recommended that you enter a static IP address.
Security Groups – Select the security group that you created for the Barracuda Load Balancer ADC Vx instance.
c. Click Yes, Create.
5. In the Network Interfaces table, right-click an interface that you want to bond and then click Attach.
6. In the Attach Network Interface window, select the Barracuda Load Balancer ADC Vx instance ID and click Attach.
7. Repeat steps 5 and 6 to attach the additional network interfaces to the Barracuda Load Balancer ADC Vx instance.
Step 2. Create the Link Bond
1. After you attach the network interfaces, turn ON and log into the Barracuda Load Balancer ADC Vx.
2. On the BASIC > Status page, verify that the attached interfaces are displayed in the Interfaces section.
3. Go to the NETWORK > Ports page and create the link bond as per your requirement.
Next Step
Now, you can use this bond to create services with more throughput, as compared to services configured on a single interface. Continue with Con
figuring Services on the Barracuda Load Balancer ADC Vx for Amazon Web Services.

Disk Expansion of the Barracuda Load Balancer ADC on Amazon Web Services (AWS)
The Barracuda virtual machines (VMs) purchased through the Amazon Marketplace prior to April 28, 2015 do not support disk
expansion. If you want to expand the disk for the virtual machines that were deployed prior to this date, you must re-deploy the VMs
using the latest Barracuda Load Balancer ADC AMI available in the Amazon Marketplace.
Step 1: Note the Barracuda Load Balancer ADC Information
1. Log into the AWS EC2 Management Console.

2. From the EC2 dashboard, scroll to INSTANCES and select Instance.
3. In the Instances table, select the Barracuda Load Balancer ADC requiring an increased disk size and note the following:
a. Instance ID
b. Availability Zone
c. EBS ID by clicking on the Root device value.
Step 2: Shutdown the Barracuda Load Balancer ADC Instance
1. If the Barracuda Load Balancer ADC is still running, go to the web user interface.
2. Navigate to the BASIC > Administration page, go to the System Reload/Shutdown section, and click Shutdown.
Step 3: Note the Disk Size and Create a Snapshot of the Volume
1. From the EC2 dashboard, scroll to ELASTIC BLOCK STORE and select Volumes.
2. In the search filter, enter the EBS ID noted in step 3.c under Step 1: Note the Barracuda Load Balancer ADC Information.
3. Note the current disk size listed next to Size.
4. Right click on the volume, and select Create Snapshot.
5. In the Create Snapshot window, enter a name and description, and click Create.
6. Note the snapshot ID.
Step 4: Create a New Volume for the Snapshot
1. From the EC2 dashboard, select Snapshots under ELASTIC BLOCK STORE.
2.

2. In the search filter, enter the snapshot ID noted in step 5 under Step.2: Create a Snapshot of the Volume.
3. Right click on the snapshot when Status displays completed, and click Create Volume.
4. In the Create Volume window, do the following:
a. Select the desired volume type.
b. Enter a new volume size.
c. Ensure the Availability Zone matches the instance Availability Zone noted in step 3.b under Step 1: Note the disk size of the
Barracuda Load Balancer ADC and stop the instance.
d. Click Create.
e. Note the volume ID.
Step 5: Detach the Old Volume from the Instance
1. From the EC2 dashboard, select Volumes under ELASTIC BLOCK STORE.
2. In the search filter, enter the EBS ID noted in step 3.c under Step 1: Note the disk size of the Barracuda Load Balancer ADC and stop
the instance.
3. Right click on the volume, and select Detach Volume.
4. In the Detach Volume window, click Yes, Detach to confirm.
Step 6: Attach the New Volume to the Instance
1. From the EC2 dashboard, select Volumes under ELASTIC BLOCK STORE.
2. In the search filter, enter the volume ID noted in step d under Step.3: Create a New Volume for the Snapshot.
3.

3. Right click on the volume, and select Attach Volume.

4. In the Attach Volume window, complete the following:
a. Enter the name or instance ID in the Instance field, and select the instance noted in step 3.a under Step 1: Note the disk size of
the Barracuda Load Balancer ADC and stop the instance.
b. Ensure the device name is /dev/xvda.
c. Click Attach.
Step 7: Restart the Instance to Apply the New Volume
1. From the EC2 dashboard, select Instance under INSTANCES.

2. In the Instances table, select the Barracuda Load Balancer ADC instance to which the new volume was attached in step 4 under Step.5:
Attach the New Volume to the Instance .
3. Right click on the instance, select Instance State and then select Start.
4. In the Start Instances window, choose Yes, Start. If the instance fails to start and this is a root volume, verify that you attached the
expanded volume using the same device name as the original volume, for example /dev/xvda.

Troubleshooting the Barracuda Load Balancer ADC Vx on Amazon Web Services

To troubleshoot the Barracuda Load Balancer ADC Vx on Amazon Web Services, log into the Amazon Web Services web interface, right-click the
Barracuda Load Balancer ADC Vx instance and select Get System Log to view the console logs.
To use the Barracuda Load Balancer ADC troubleshooting tools, log into the Barracuda Load Balancer ADC Vx web interface with your
credentials and go to the ADVANCED > Troubleshooting page. The page provides various tools that you can use to resolve network
connectivity issues that may impact the performance of your Barracuda Load Balancer ADC Vx:
Support Connection establishes a secure tunnel connection to Barracuda Central so that a Barracuda technician can help you
diagnose issues. Click Establish Connection To Barracuda Support Center to establish a connection to Barracuda Central. Contact B
arracuda Networks Technical Support for assistance.
Problem Report generates a report of all logs (Web Firewall Logs, Access Logs, Audit Logs, Network Firewall Logs, and System Logs),
backup, configuration, and temporary files as well as the internal state of the system.
Network Connectivity Tests provides access to a command-line utility that includes ping, telnet, Dig/NS-lookup, traceroute, etc., which
you can use to diagnose potential network problems and issues.
TCP Dump provides access to a command line-utility that includes TCP Dump, which lets you intercept and capture the TCP/IP and
other packets transmitted or received over the network to which the Barracuda Load Balancer ADC Vx is connected.
Session recording enables you to capture requests from and responses to the Barracuda Load Balancer ADC Vx for a specified client
IP address or user ID. The captured session is stored in an XML file.
See the ADVANCED > Troubleshooting page for details and procedures.

Microsoft Azure
If you need to add additional storage, you must create a new attached drive; this applies to Barracuda virtual machines purchased
through the Microsoft Azure Marketplace February 2015 or later. You cannot attach new storage in earlier deployments
Cloud hosted deployment of the Barracuda Load Balancer ADC on Microsoft Azure currently supports One-Arm Proxy Mode..
To meet a variety of performance requirements, the A1, A2, A3 and A4 instance types are supported. Depending on the instance type, you can
have:
Up to 8 vCPU.
Up to 14 GB of memory.
Licensing Options
The Barracuda Load Balancer ADC is available on Microsoft Azure with the Bring Your Own License (BYOL) and Hourly / Metered option.
With the Bring Your Own License (BYOL) option, you are required to get the Barracuda Load Balancer ADC license token, either by:

With this license option, there will be no Barracuda Load Balancer ADC Software charges, but Microsoft Azure usage charges on
Microsoft will be applicable.
For BYOL, Barracuda offers four models. The table below lists each model, the corresponding Instance Type to be used in Microsoft Azure, the
default CPU and Memory for the instance.
If you want to increase the performance of a license that you have already purchased, you can buy additional cores from Barracuda and
reconfigure for a larger instance type.
Barracuda Load Balancer ADC Supported Instance Type in Default vCPU Default Memory
Firewall Model Microsoft Azure
Level 1 D1 1 3.5 GB
Level 5 D2 2 7 GB

Level 10 D3 4 14 GB
Level 15 D4 8 28 GB
You can add multiple Barracuda Load Balancer ADC instances under one cloud service and load balance the traffic between the deployed
instances to increase the throughput. For more information on load balancing, see the Load Balancing For Clustered Barracuda Web Application
Firewall Instances in the Old Microsoft Azure Management Portal article.
Hourly / Metered
With the Hourly/Metered licensing option, you complete the purchase or evaluation of the Barracuda Load Balancer ADC entirely within the
Microsoft Azure gallery. After the instance is launched, it is provisioned automatically. You are charged hourly for both the Barracuda Load
Balancer ADC Software and Microsoft Azure usage on Microsoft.
Hourly / Metered Model and Instance Types
For more information on supported instance types, Default vCPU, Default Memory and Hourly pricing, refer to Barracuda Web Application
Firewall Pricing Details.
If you want to increase the performance of an existing VM, configure it with a larger instance type on Microsoft Azure and you will be charged
accordingly by Microsoft. The VM will automatically be reconfigured by Microsoft with the resources and capabilities of the larger instance type.
Before You Begin
Create a Microsoft Azure Account
Create an Azure Virtual Network
1. Log into your Microsoft Azure Management Portal.

2. In the left pane, click NETWORKS, and then click NEW at the bottom of the screen.
3. Click NETWORK SERVICES > VIRTUAL NETWORK > CUSTOM CREATE. The CREATE A VIRTUAL NETWORK window appears.
4. On the Virtual Network Details page:

a. Enter a unique name in the Name field. For example, AzureVirtualNet
b. Select a location from the LOCATION drop-down list. The virtual network can only be used for Azure instances in this
geographic region. E.g., South Central US
c.
c. Click Next .
5. (Optional) On the DNS Servers and VPN Connectivity page, select or enter your DNS SERVERS.
6. Click Next .
7. On the Virtual Network Address Spaces page, configure the ADDRESS SPACE:
a. STARTING IP: Enter the first IP address of the address space you want to use.
b. CIDR: Select the subnet mask for the virtual network. The maximum number of instances for a virtual network are listed in
parentheses.
8. Add a SUBNET:
a. STARTING IP: Enter the first IP address of the subnet.
b. CIDR: Select the subnet mask for the subnet.
9. Click Finish .
The created virtual network gets displayed in the VIRTUAL NETWORKS lists.
Next Step
Continue with Deploying and Provisioning the Barracuda Web Application Firewall in the Old Microsoft Azure Management Portal for instructions
on installation and configuration.

VMware vCloud Air Deployment

The Barracuda Load Balancer ADC is a unified high-performance platform that helps organizations achieve their availability, acceleration,
application control, and application security objectives.
To manage vCloud Portal (vCloud Air/vCloud Director), VMware recommends you use the Mozilla Firefox web browser. You will be asked to
download vCloud plugins when you access the vCloud Portal for the first time. You must accept and download the plugins, which are required for
the installation process.
The Barracuda Load Balancer ADC is available on vCloud Air through the Bring Your Own License (BYOL) option only.
With the BYOL option, you must get the Barracuda Load Balancer ADC license token, either by:

With this license option, there will be no Barracuda Load Balancer ADC Software charges, but VMware vCloud Air usage charges on
vCloud will be applicable.
For BYOL, Barracuda offers three models for VMware vCloud. The table below lists each model, the corresponding CPU and Memory for the
instance. If you want to increase the performance of a license that you have already purchased, you can buy additional cores from Barracuda and
reconfigure your VM for a larger instance type.
Barracuda Load Balancer ADC Cores (Maximum) RAM (Recommended Hard Disk (Recommended
Model Minimum) Minimum)
340 2 2 GB 50 GB
440 3 3 GB 50 GB
640 4 or more(1) 4 GB 50 GB
Note:
(1)
You can add up to 10 cores to your Barracuda Load Balancer ADC 660. The number of cores available is limited only by license. Add an
additional 1 GB RAM for each additional core.
Before You Begin
Before you deploy the Barracuda Load Balancer ADC on vCloud, ensure you have the following required components:
Barracuda Load Balancer ADC license (Evaluation / Purchase)

vCloud account
Virtual Public Cloud (VPC) on your vCloud account
Upload the Barracuda Load Balancer ADC Package as a vApp Template
You must install the VMware OVF tool to complete the steps in this section. The VMware OVF tool is available for Windows 32-bit and
64-bit, Linux 32-bit and 64-bit, and Mac OS X. This article describes how to install the tool on Linux and upload the Barracuda OVA
package. For details on installing the tool on other supported platforms, refer to the VMware OVF Tool Documentation.
Use the following steps to install the VMware OVF tool on Linux and upload the Barracuda OVA package:
1. Log in to https://my.vmware.com/web/vmware/login, and go to the Product Download page.

2. Download and install the latest Linux version of OVF Tool to your Linux host.
3. On your Linux system, open a terminal window and run the following command:
ovftool --sourceType="OVA" --vCloudTemplate="false" "Source_Location" "vcloud://@vCloud_Director_Hostname?vdc=Org_vDC&org=
Organization_Name&vappTemplate=Name_For_Uploaded_File&catalog=Organization_Catalog_Name"
Where:
Parameter Description Example
sourceType Source file type; OVA is the required OVA

Barracuda package source file type

vCloudTemplate Set to false to create a vApp template false

only; must be set to false for Barracuda
packages
Source_Location Barracuda OVA package source file /home/user1/Downloads/BarracudaLoadB

download location alancer-ADC-ova-package
vCloud_Director_Hostname vCloud Air region URL uk-slough-1-6.vchs.vmware.com
vdc Target Virtual Data Center (vDC) where Platform_Team

you want to upload the package
org Organization name; available from your aa66669c-d35b-444d-b570-23aase5eag5f

vCloud Director URL
vappTemplate Name for uploaded Barracuda OVA BarracudaLoadBalancerADC-vm4.2.7-fw5

package .4.0.004-20160405.ova
catalog vCloud Air catalog name where you want Test1_catalog

to upload the Barracuda package
For example:
ovftool --sourceType="OVA" --vCloudTemplate="false"

"/home/user1/Downloads/BarracudaLoadBalancerADC-vm4.2.7-fw5.4.0.004-20160405.ova" "vcloud://@uk-slough-1-6.vchs.vmware.com
?vdc=Platform_Team&org=aa66669c-d35b-444d-b570-23aase5eag5f&vappTemplate=BarracudaLoadBalancerADC-vm4.2.7-fw5.4.0.00
4-20160405&catalog=Test1_catalog"
4. When prompted, enter your vCloud account Username and Password, and press Enter.
5. In the Barracuda End User License Agreement (EULA) page, read the agreement and scroll to the end of the page. Type yes to
accept the license agreement, and press Enter to begin uploading the package.
6. Allow the upload to complete.
Deploy the Barracuda Load Balancer ADC Package to vCloud
Use the following steps to deploy the Barracuda Load Balancer ADC on vCloud using the uploaded package:
1. In the VMware Cloud Director window, click the Home tab.

2. Click Add vApp from Catalog under Quick Access.
3. In the Add vApp from Catalog window:
a. Click All Templates under Select vApp Template.
b. Select the uploaded template from the list and click Next.
c. Read the license agreement, select I agree and accept the above license agreements, and click Next.
d. Enter a name and description. Select a Virtual Datacenter for the vApp under Select Name and Location. Click Next.
e. Select a storage policy for the virtual machine under Configure Resources, and click Next.
f. Under Configure Networking:
i. Select Switch to the advanced networking workflow.
ii. Enter the Computer Name.
iii. Ensure the Network Adapter type is VMXNET3.
iv. Select the default-routed-network (or the network adapter with internet access) for Network. This network is the WAN
network on the Barracuda Load Balancer ADC.
v. Select Static-Manual from the list under IP Assignment, and enter the Static IP address for the Barracuda Load
Balancer ADC. Click Next.
g. Leave Advanced Networking settings as is, and click Next.
h. Under Customize Hardware, configure the CPU, Memory, and Hard Disks based on your Barracuda Load Balancer ADC
license. Click Next. For information on license options, see BYOL Models and Instance Types above.
i. On the Ready to Complete page, review the settings and click Finish.
4. The Home tab displays the new vApp status as Creating.
5. Once the vApp is created, the status changes to Stopped.
6. Choose the deployment mode for the Barracuda Load Balancer ADC and continue with the steps in that deployment mode. See the Depl
oyment Options section below.
Deployment Options
One-Arm Deployment Mode

Two-Arm Deployment Mode
One-Arm Deployment Mode
In One-Arm deployment mode, one interface is required for the Barracuda Load Balancer ADC. This interface will be the WAN interface of the

Barracuda Load Balancer ADC and all web servers reside in the same network.
To deploy the Barracuda Load Balancer ADC in One-Arm mode, perform the following steps:
1. Right click on the created vApp and select Open.

2. Select the Virtual Machines tab, right click on the VM and select Power On. The Barracuda Load Balancer ADC starts booting up.
3. Configure the NAT and Firewall rules for the Barracuda Load Balancer ADC to communicate with the internet. To configure the NAT and
Firewall rules, follow the steps in the Configure NAT and Firewall Rules on vCloud article.
The following ports should be opened on your firewall for the Barracuda Load Balancer ADC to operate properly:
Port Direction TCP UDP Usage
22 Out Yes No Technical Support

Connections
25 In/Out Yes No Email Alerts
53 Out Yes Yes Domain Name Service

(DNS)
80/8000 Out Yes No Virus/Attack/Security

Definitions and Firmware
Updates
123 Out No Yes Network Time Protocol

(NTP)
80 Out Yes No Initial Provisioning *
Note:
* The initial provisioning port can be disabled once the provisioning process is complete.
Two-Arm Deployment Mode
In Two-Arm deployment mode, two interfaces are required for the Barracuda Load Balancer ADC, one for WAN and the other for LAN. In this
mode, all web servers are in a separate private network (for example, the LAN network).
Pre-requisite: Ensure you have a private network configured where all your web servers are deployed.
To deploy the Barracuda Load Balancer ADC in Two-Arm mode, perform the following steps:
1. Right click on the created vApp and select Open.

2. Select the Networking tab, and click on the plus icon to add the network. The New vApp Network Wizard appears.
3. On the New vApp Network Wizard window:
a. Select Organization VDC network under Network Type, and click Next.

b. Select the private network where your web servers are configured under Organization VDC Network, and click Finish.
4. The selected network displays in the Configure Networking section.
5. Click Apply to apply the changes.
6. Select the Virtual Machines tab.
7. Right click on the Barracuda Load Balancer ADC VM and select Properties. The Virtual Machine Properties window appears.
8. On the Virtual Machine Properties window:
a. Select the Hardware tab.
b. Scroll down to the NICs section, select Show network adapter type, and click Add to add one or more networks to the virtual
machine. Configure the following in the NIC fields:
i. Ensure the Connected check box is selected.
ii. Select the private network under Network that you want to configure as LAN on the Barracuda Load Balancer ADC.
iii. Ensure you do not make the private network the Primary NIC.
iv. Select VMXNET3 from the Adapter Type list.
v. Select Static - Manual for IP Mode, and configure the Static IP address for the interface from the network.
c. Click OK.
9. Select the Virtual Machines tab, right click on the Barracuda Load Balancer ADC VM and select Power On. The Barracuda Load
Balancer ADC starts booting up.
The following ports should be opened on your firewall for the Barracuda Load Balancer ADC to operate properly:
Port Direction TCP UDP Usage
22 Out Yes No Technical Support

Connections
25 In/Out Yes No Email Alerts
53 Out Yes Yes Domain Name Service

(DNS)
80/8000 Out Yes No Virus/Attack/Security

Definitions and Firmware
Updates

123 Out No Yes Network Time Protocol

(NTP)
80 Out Yes No Initial Provisioning *
Note:
* The initial provisioning port can be disabled once the provisioning process is complete.

Getting Started
You can deploy the Barracuda Load Balancer ADC either as a hardware appliance or as a virtual appliance on supported hypervisors.
Deploy the Barracuda Load Balancer ADC Vx on a Supported Hypervisor
To install the Barracuda Load Balancer ADC Vx virtual appliance on a supported hypervisor, start with Virtual Deployment.
Deploy the Barracuda Load Balancer ADC Hardware Appliance
The following instructions are an expanded version of the Barracuda Load Balancer ADC Quick Start Guide that is shipped with every Barracuda
Load Balancer ADC. If you have already completed the steps in the Quick Start Guide to install and activate your appliance, go to Step 5 - How to
Configure Your Network and Services. Otherwise, complete the following steps:
Step 1 - How to Install the Barracuda Load Balancer ADC Appliance

Step 2 - How to Configure the Barracuda Load Balancer ADC
Step 3 - How to Activate and Update the Barracuda Load Balancer ADC
Step 4 - How to Configure Administrator Settings
Step 5 - How to Configure Your Network and Services

Step 1 - How to Install the Barracuda Load Balancer ADC Appliance
Deployment Options
Before installation, determine the best type of deployment for your Barracuda Load Balancer ADC; refer to the Deployment section for
a list of options.
Verify Equipment
Verify you have the necessary equipment:
Barracuda Load Balancer ADC

AC power cord
Ethernet cables
Mounting rails and screws
Monitor and keyboard (recommended)
Connect to the Network
1. Secure the Barracuda Load Balancer ADC in your environment.

2. Connect the Barracuda Load Balancer ADC to your network:
On the front of the device, connect the ports based on your deployment
Connect an Ethernet cable from the management port (either labeled MGMT or unlabeled on the back of the device) to the
network switch for your management network.
3. Connect the following to your Barracuda Load Balancer ADC:
Power cord; AC input voltage range is 100-200 volts at 50/60 Hz
Monitor and keyboard
4. Power on the device.
Configure the Management IP Address
Once fully booted, the login prompt appears on your monitor. To configure the management IP address:
1. At the barracuda login prompt, log in using admin/admin.
Barracuda recommends changing the administrator password. On the console, you can change the admin password from
the System menu.
2. Go to TCP/IP Configuration, and in the right pane, configure the addresses as appropriate for your network, including :
Management IP Address /Netmask
Gateway Address
Management VLAN ID (Optional)
Primary/Secondary DNS Servers
Proxy Server Configuration (Optional)
3. Select Save to save your changes, and then select Exit .
Continue with Step 2 - How to Configure the Barracuda Load Balancer ADC.

Step 2 - How to Configure the Barracuda Load Balancer ADC
Before configuring the IP address and the corporate firewall, complete Step 1 - How to Install the Barracuda Load Balancer ADC
Appliance.
Configure the Management IP Address
Once fully booted, the login prompt appears on your monitor. To configure the management IP address:
1. At the barracuda login prompt, log in using admin/admin.
Barracuda recommends changing the administrator password. On the console, you can change the admin
password from the System menu.
2. Go to TCP/IP Configuration, and in the right pane, configure the addresses as appropriate for your network, including :
Management IP Address /Netmask
Gateway Address
Management VLAN ID (Optional)
Primary/Secondary DNS Servers
Proxy Server Configuration (Optional)
3. Select Save to save your changes, and then select Exit .
Configure Your Corporate Firewall
For maximum security, place your Barracuda Load Balancer ADC behind a corporate firewall.
If your Barracuda Load Balancer ADC is located behind a corporate firewall, open the following ports to allow full access to the management port
on the Barracuda Load Balancer ADC and also to allow traffic flow for the load balancing services (as described in the last table row):
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 updates (unless

configured to use a proxy)
123 Out UDP Network Time Protocol (NTP)
443 Out TCP Initial VM provisioning *
25 Out TCP Sending system alerts and

notifications to the administrator
via your mail server. This port
can be changed on the BASIC >
Administration page.
Any ports used by Services as needed as needed As required to access the VIP
address of a load-balanced
service. Configure 1:1 NATs as
needed. Certain protocols,
including FTP and streaming
media protocols, require
additional ports to be open.
* You can disable the initial provisioning port after the initial provisioning process is complete.
Next Step
Continue with Step 3 - How to Activate and Update the Barracuda Load Balancer ADC.

Step 3 - How to Activate and Update the Barracuda Load Balancer ADC
Depending on whether your Barracuda Load Balancer ADC has Internet access, you can complete either an online or offline activation and
update.
In this article:
Before You Begin

Online Activation and Update
Offline Activation and Update
Before You Begin
Verify that the required firewall ports are open. For a complete list of the required ports, see Step 2 - How to Configure the Barracuda Load
Balancer ADC.
For offline activation and updates, you must also:
1. Contact Barracuda Networks Technical Support to get a Feature Code to enable offline updates.
2. Go to the Barracuda Product Activation page, complete the form, and get an Activation Code.
3. Go to the Support > Downloads page in your Barracuda Cloud Control account, and download update packages for the latest versions
of the following:
Firmware
Attack definition
Virus definition
Security definition
Location definition
Update definition
Online Activation and Update
If your Barracuda Load Balancer ADC is connected to the Internet, it can automatically update its activation status. Complete the following steps
to initiate the online activation process and update the system.
1. Log into the Barracuda Load Balancer ADC as the administrator. In a web browser, enter the Barracuda Load Balancer ADC
management IP address and default HTTP port (for example, http://192.168.200.200:8000/). Use the default admin credentials:
Username: admin
Password: admin
2. Go to the BASIC > Status page and view the Subscription Status section to verify that your Energize Update subscription status is Cur
rent. If the Barracuda Load Balancer ADC can access the activation servers, your Energize Update and Instant Replacement
subscriptions are most likely active. If not, a warning displays at the top of every page and you must activate your subscriptions before
continuing.
3. If the status of the Energize Updates subscription is Not Activated:
a. Click the activation link at the top of the page and complete your subscription activation.
b. Go back to the Subscription Status section of the BASIC > Status page, and click Refresh to automatically update the
activation status of the Energize Updates subscription.
4. Go to the ADVANCED > Firmware Update page and verify that the currently installed version is the latest general release that is
available. If you have the latest firmware version already installed, the Download Now button for the latest general release version is
disabled.
5. If there is a new Latest General Release available:
a. Click Download Now and allow the update to finish downloading.
b. After the update is completely downloaded, click Apply Now. Do not reboot or turn off the Barracuda Load Balancer ADC while
the firmware is updating. After the process completes, the Barracuda Load Balancer ADC automatically reboots and you are
redirected to the page to log back into the system.
6. Go to the BASIC > Administration page, and change the administrator password in the Password Change section.
After you activate and update your Barracuda Load Balancer ADC, continue with Step 5 - How to Configure Your Network and Services .
Offline Activation and Update
If your Barracuda Load Balancer ADC does not have Internet access, you must manually enter your Activation Code to activate the unit. Then
enable offline updates to apply the update packages that you downloaded from your Barracuda Cloud Control account.
1. Log into the Barracuda Load Balancer ADC as the administrator. In a web browser, enter the Barracuda Load Balancer ADC
management IP address and default HTTP port (for example, http://192.168.200.200:8000/). Use the default admin credentials:
Username: admin
Password: admin
2. Activate your product.
a.

2.
a. Go to the BASIC > Status page.
b. In the Subscription Status section, enter the Activation Code that you received from the Barracuda Product Activation page a
nd then click Activate.
3. Enable offline updates.
a. Enable expert mode by appending the URL with: &expert=1
b. Go to the ADVANCED > Offline Update page that appears.
c. Enter the Feature Code that you received from Barracuda Networks Technical Support, and then click Activate .
d. When the Enable Offline Updates setting appears, select Yes.
e. Click Save Changes.
4. Update your firmware.
a. Go to the ADVANCED > Firmware Update page.
b. In the Firmware Upload section, click Browse to navigate to and select the firmware package that you downloaded from your
Barracuda Cloud Control account.
c. Click Upload.
d. After the firmware package is completely uploaded, click Apply Now. Do not reboot or turn off the Barracuda Load Balancer
ADC while the firmware is updating. After the process completes, the Barracuda Load Balancer ADC automatically reboots and
you are redirected to the page to log back into the system.
5. Update the attack, virus, security, location, and update definitions.
a. Go to the ADVANCED > Energize Updates page.
b. In the Definition Update Upload section, click Browse to navigate to and select a definition package that you downloaded from
your Barracuda Cloud Control account.
c. After the definition package is completely uploaded, click Apply Now.
d. Repeat steps 5b and 5c until you have updated all of the definitions on the page.
6. Go to the BASIC > Administration page, and change the administrator password in the Password Change section.
After you activate and update your Barracuda Load Balancer ADC, continue with Step 5 - How to Configure Your Network and Services.

Step 4 - How to Configure Administrator Settings
Set and Restrict Administration Interface Access
Use the BASIC > Administration page to perform the following tasks related to Barracuda Message Archiver web access:
Change the password of the administration account admin (highly recommended for your security and protection).
Specify the Administrator IP/Range addresses/networks that can access the administrative web interface for the Barracuda Load
Balancer ADC (highly recommended for your security and protection).
Change the port used to access the Barracuda Load Balancer ADC over the web (default port is 8000).
Change the length of time after which idle users are to be logged out of the web interface (the default value is 20 minutes).
Configure the Password Policy
On the ADVANCED > Admin Access Control page under Administrator Account Settings, click Password Policy Settings to configure the
following:
Policy - You can select either Default or Custom. Select Custom to modify the password policy.
Minimum Characters - Specify the minimum number of characters needed for the password (the default value is 8).
Contains - Specify the types of characters that must be present in each password:
At Least One Upper Case Character
At Least One Lower Case Character
At Least One Special Character
At Least One Digit
Expires In - Time until password expires:
3 Months
6 Months
1 Year
Never
Other - Specify between 30 and 999 days.
Notify Before Expiry - Time before notifying the user that his or her password is about to expire.
1 Week
2 Weeks
Configure the Account Lockout Settings
To prevent unauthorized access to the Barracuda Load Balancer ADC, go to the ADVANCED > Admin Access Control page and under Admini
strator Account Settings click Account Lockout Settings. Use these settings to specify when a user will be locked out from the Barracuda
Load Balancer ADC based on the number of times they have failed to enter their login credentials correctly.
Maximum Failed Login Attempts - Specify the acceptable number of failed login attempts (default is 5).
Failed Login Time Threshold - Specify the time in minutes in which consecutive failed login attempts are counted (default is 15).
Lock User Account - Specify the time in minutes to lock the admin account if the user fails to login more than the Maximum Failed
Login Attempts value in less that the time specified by the Failed Login Time Threshold (default is 15).
If an account is locked after the maximum failed login attempt limit has been reached, an Admin user can clear the account lock in the
Administrator Accounts section by clicking Clear Lockout next to the user.

Step 5 - How to Configure Your Network and Services
Before proceeding:
If you are installing an appliance, complete Step 3 - How to Activate and Update the Barracuda Load Balancer ADC.
If you are installing a virtual system, complete Barracuda Load Balancer ADC Vx Quick Start Guide
This article applies to both virtual systems and appliances.
Determine Your Deployment
Read Deployment to assist you in deciding how to deploy your network. If you haven't already, make physical connections from the data ports on
the Barracuda Load Balancer ADC appliance or from your virtual system's host machine to the relevant switches.
Ports and Interfaces Mapping
In the web UI, the network interfaces that correspond to physical ports are referred to as gt-x-y where:
g is gigabit
t is the type of connection (e for Ethernet, f for fiber-optic)
x is the number of the module of 8 ports, where the left-most module is number 1
y is the number of the port within the module, where the top left port is number 1
On a Barracuda Load Balancer ADC appliance with 2 modules, the mapping from physical port to network interface would be:
On a Barracuda Load Balancer ADC Vx (virtual system), the network interfaces are numbered in the order you assigned the network interface
cards to the virtual system.
Configure Network Interfaces
Earlier, you entered the management IP address (using the administrative console for appliances). Now you should configure your other network
interfaces so that you can create services.
Configuring the default gateway for an interface ensures that return traffic exits the Barracuda Load Balancer ADC correctly. If the default
gateway is not configured, the outgoing traffic uses the default gateway of the management interface.
If you have multiple networks, you must specify a default gateway on the NETWORK > Routes page for every interface that accepts
incoming traffic.
In the following examples, ge-1-1 refers to a physical port connected into the network so that it accepts incoming traffic.
Option 1: One-Armed With Separate Management Network
In this case, incoming traffic is on the same subnet as the servers, and the management port is on a separate
subnet. ge-1-1 is connected into the network so that it accepts incoming traffic.
1. Configure the IP address for ge-1-1 using the NETWORK > Interfaces page.
2. Configure the default gateway for ge-1-1 using the NETWORK > Routes page.
If you have both bonded interfaces and VLANs, configure the bonded interfaces first. For each bonded interface:
1. Configure bonded ports using the NETWORK > Ports page.
2. Configure the IP address for each bonded interface using the NETWORK > Interfaces page.
3.

3. Configure the default gateway for each bonded interface using the NETWORK > Routes page.
For each VLAN:
1. Configure VLANs using the NETWORK > VLANs page.

2. Configure the IP address for each VLAN using the NETWORK > Interfaces page.
3. Configure the default gateway for each VLAN using the NETWORK > Routes page.
Option 2: Two-Armed With Separate Management Network
In this environment, incoming traffic is on a different subnet from the servers, and the management port is on a separate subnet. ge-1-1 is
connected into the network so that it accepts incoming traffic, and ge-1-2 is connected to the servers.
1. Configure the IP address for ge-1-1, ge 1-2, etc. using the NETWORK > Interfaces page.
2. Configure the default gateway for ge-1-1 using the NETWORK > Routes page. If any other interfaces accept incoming traffic, create
default gateways for those interfaces.
If you have both bonded interfaces and VLANs, configure the bonded interfaces first. For each bonded interface:
1. Configure bonded ports using the NETWORK > Ports page.
2. Configure the IP address for each bonded interface using the NETWORK > Interfaces page.
3. Configure the default gateway for each bonded interface using the NETWORK > Routes page.
For each VLAN:
1. Configure VLANs using the NETWORK > VLANs page.

2. Configure the IP address for each VLAN using the NETWORK > Interfaces page.
3. Configure the default gateway for each VLAN using the NETWORK > Routes page.
Option 3: One-Armed Without Separate Management Network
In this case, incoming traffic is on the same subnet as the real servers, and the management port is on that same subnet. Generally, this
describes a topology where all systems are on a flat network. No additional gateways need to be defined on the Barracuda Load Balancer ADC. I
t is more secure to segregate the production traffic from the management interface, as in Option 1.
Configure the IP address for ge-1-1 using the NETWORK > Interfaces page.
Configure Services
You are now ready to configure services and real servers.
On the BASIC > Services page, create each service by identifying a VIP address, port, and associating one or more real servers with it.
If you have a two-armed network, you may need to create a static route for the real servers:
On the NETWORK > Routes page, create a static route using the Static Routes table.
For more information about services, see Services.

Application Deployment Guides

The following guides assist you in deploying the Barracuda Load Balancer ADC in different environments:
Moodle Deployment
Publish

Required Product Version

This article describes how to deploy your Barracuda Load Balancer ADC version 5.1 or 5.2 with the
Barracuda Email Security Gateway.
The Barracuda Email Security Gateway is used to protect your organization's email infrastructure whether it is Microsoft's Exchange, 365, or even
Google Apps. This article will detail how to put an ADC in front of your two Spam Firewalls to balance the mail traffic in and out of the two Spam
firewalls.
Setup Diagram for a One-Armed Setup
Setup Diagram for Two-Armed Setup
Terminology
Term Definition
DNS Domain Name Server, typically hosted on the Domain Controller
VIP Virtual Internet Protocol (VIP) address. In the ADC deployment, the
VIP is added to the service on the Barracuda Load Balancer ADC.
Service A combination of a virtual IP address and one or more TCP/UDP

ports that the Barracuda Load Balancer ADC listens on. Traffic
arriving on the specified port(s) is directed to one of the real servers
associated with a service.

DSR With Direct Server Return, connection requests and incoming traffic
are passed from the Barracuda Load Balancer ADC to the real server
but all outgoing traffic goes directly from the real server to the client.
DSR is ideal for high-bandwidth requirements such as content
delivery networks and lets you keep the existing IP addresses of your
real servers.
Client Impersonation Lets the Barracuda Load Balancer ADC use the client IP address as
the source IP address to communicate to the real server. If client
impersonation is disabled, the IP address of the Barracuda Load
Balancer ADC used to communicate to the real server as the source
IP address.
Product Versions and Prerequisites
You must have the following:
Barracuda Load Balancer ADC firmware version 5.1 or 5.2

Barracuda Email Security Gateway 6.1 and above
You must have complete the following procedures:
Installed your Barracuda Load Balancer ADC(s), connected to the web interface, and activated your subscription(s).
Installed your Barracuda Email Security Gateways, connected to the web interface, and activated your subscriptions.
If you want to deploy with high availability, cluster your Barracuda Load Balancer ADCs. For more information, see High Availability.
Barracuda Load Balancer ADC Service Options
On the Barracuda Load Balancer ADC, create the applicable service depending on what you want: One-Armed or Two-Armed.
Scenario Service Options
You want your Mail Servers, Barracuda Email Security Gateway, and Create the SPAM_Layer4 service with DSR enabled
the Barracuda Load Balancer ADC to be all on the same network
(One-Armed)
You want your Mail Servers and Barracuda Email Security Gateway Create the SPAM_TCP service with Client Impersonation
to be on the same network but the Barracuda Load Balancer ADC to
be on the public external network (Two-Armed)
Step 1. Configure your email service with the Barracuda Email Security Gateway
The Barracuda Email Security Gateway is compatible with multiple email services such as Microsoft's Exchange, 365, and Google Apps.
See the Barracuda Email Security Gateway documentation for instructions on how to deploy with your specific email solution.
Step 2. Create the Spam Service on the Barracuda Load Balancer ADC
On the Barracuda Load Balancer ADC, create a service according to your deployment type:
1. Log into the Barracuda Load Balancer ADC as administrator.

2. Go to the BASIC > Services page.
3. Click Add Service and enter the values for the service related to your selected deployment type in the corresponding fields. If you
are doing a One-Armed Configuration, use the SPAM_Layer4 Service, otherwise for a two-armed configuration, use the
SPAM_TCP service
Name Type IP Address Port Netmask Server Monitor
SPAM_Layer4 Layer 4-TCP VIP Address for 25 Netmask for Testing

the Barracuda connection. For Method
Email Security example, : TCP
Gateway Service. 255.255.255.0. Port
For example, Check
10.5.7.193 Test
Delay: 1
0
seconds

SPAM_TCP TCP-Proxy VIP Address for 25 Netmask for Testing

the Barracuda connection. For Method
Email Security example, : TCP
Gateway Service. 255.255.255.0. Port
For example, Check
10.5.7.193 Test
Delay: 1
0
seconds
4. In the Load Balancing section, set the Algorithm to Weighted Least Requests.
Step 3. Add the Barracuda Email Security Gateways
Add your Barracuda Email Security Gateways to your service. For each Barracuda Email Security Gateway:
1. On the BASIC > Services page, verify that the correct service for the server is displayed.
2. Click Add Server.
3. Enter the IP address for the Barracuda Email Security Gateway and enter port 25
4. If you are using a one armed setup, enable DSR (Set DSR to "ON" under the configure server settings) and configure a Loop Back
Adapter on the Barracuda Email Security Gateway as follows:
a. Log on to the Barracuda Email Security Gateway and go to the Advanced > Advanced Networking > Loop back
Adapter page.
b. Enter the VIP address you set for the SPAM_Layer4 service you created above.
5. For a two armed SPAM_TCP service, turn on Client Impersonation in Advanced >Show > Client Impersonation.
6. For the SPAM_TCP service, ensure that the gateway settings on both Barracuda Email Security Gateways are set to the Barracuda
Load Balancer Interface IP Address (on the same network that your servers are on).
7. Click Create.
Verify Your Configuration
Use Telnet or another email service that is not on located on your domain to send email to your domain's to verify that emails are flowing to both
Barracuda Email Security Gateways.

You can use the Barracuda Load Balancer ADC to distribute traffic across multiple Barracuda Web Security Gateways in your network. The
Barracuda Load Balancer ADC can load balance outgoing Internet traffic across multiple Barracuda Web Security Gateways, so they handle even
traffic loads. Alternatively, you can configure the Barracuda Load Balancer ADC to send more traffic to higher performance Barracuda Web
Security Gateways, while sending less to lower performance appliances.
The following Barracuda Web Security Gateway features are not available when it is deployed behind a Barracuda Load Balancer
ADC:
Application specific block/accept policies (configured on the Block/Accept > Applications page)
Temporary access (configured on the Advanced > Temporary Access page)
Step 1. Deploy the Barracuda Load Balancer ADC and the Barracuda Web Security Gateways in Your Network
1. The Barracuda Load Balancer ADC and the Barracuda Web Security Gateways are deployed in one-armed mode. Configure all of the B
arracuda Web Security Gateways and the Barracuda Load Balancer ADC on the same LAN subnetwork. For more information, see One-
Armed Using a TCP Proxy, UDP Proxy, or Layer 7 Service.
2. Interconnect the Barracuda Load Balancer ADC, the Barracuda Web Security Gateways and the Internet-facing firewall or router. The
following illustration shows this topology. Be aware of the following:
Traffic to and from the Internet is sent to the intranet router handling Internet traffic for your organization.
The Barracuda Load Balancer ADC distributes Internet access requests to two or more Barracuda Web Security Gateways. In
the following illustration, the Barracuda Load Balancer ADC and the Barracuda Web Security Gateways send Internet traffic over
the 10.1.0.x network.
Each Barracuda Web Security Gateway applies its own policies to these requests. The Barracuda Web Security Gateway policie
s should be replicated across each of the Barracuda Web Security Gateways participating in this deployment. By configuring the
clustering feature, the Barracuda Web Security Gateways can automatically synchronize their policies. For more information,
see High Availability - Clustering the Barracuda Web Security Gateway.
The management ports on the Barracuda appliances should use a separate network from the one load balancing Internet traffic.
In the following illustration, the management ports are connected to the 10.7.32.x network.
Figure 1: Barracuda Load Balancer ADC supporting three Barracuda Web Security Gateways in a one-armed
deployment.

3. Configure policy-based routing (PBR) on the router to redirect outgoing requests and incoming Internet traffic to the Barracuda Load
Balancer ADC. Specifically, a policy to redirect traffic from ports TCP 80, TCP 443, UDP 53 and UDP 443 to the Barracuda Load
Balancer ADC. Ports 80 and 443 handle HTTP and HTTPS traffic respectively. UDP port 53 handles DNS requests and responses. To
be able to filter HTTP and HTTPS traffic properly, the Barracuda Web Security Gateways need to be able to receive traffic directed to
these ports.
4. Configure a NAT rule on the router to forward outbound traffic from the Barracuda Web Security Gateways to the Internet.
Step 2. Configure the Barracuda Load Balancer ADC
Complete the following steps to configure the Barracuda Load Balancer ADC to load balance traffic between the Barracuda Web Security
Gateways:

2. Click Add Service.
3. Specify a Name for the new service, set the Type to Barracuda Web Security Gateway, select the interface linked to the Barracuda
Web Security Gateways, and select a Load Balancing Algorithm.
4. Click Create.
5. Add each of the Barracuda Web Security Gateways you need to load balance by clicking Add Server and specifying a Name for the
server and an IP Address. You can also specify a Weight for each Barracuda Web Security Gateway. The greater the weight you
assign to a Barracuda Web Security Gateway, the more traffic it receives from the Barracuda Load Balancer ADC.
The following table shows an example of the values you could configure for a service based on the topology shown in Figure 1:
Name Interface Service Type Load Balancing
WSGProxySVC ge-1-1 Barracuda Web Security Persistence Type: Source IP

Gateway
Persistence Netmask: 255.255.2
55.255
Persistence Time: 1200

Step 3. Configure the Barracuda Web Security Gateways
Complete the following steps to configure each Barracuda Web Security Gateway. You need to complete these steps from the console on each B
arracuda Web Security Gateway:
1. Select Auxiliary Port. Here you can specify the IP address for the Management port on the Barracuda Web Security Gateway. The
Management port should be on a separate network from the Barracuda Web Security Gateway ports handling Internet traffic. Set the IP
Address, Subnet Mask, and Default Gateway. When finished, select Save.
2. Select TCP/IP Configuration. For the Default Gateway, set the IP address for the router connected to the Internet (in the illustration,
this address is 10.1.0.1). When finished, select Save.
Step 4. Monitor the Service on the Barracuda Load Balancer ADC
1. Log in to the web interface of the Barracuda Load Balancer ADC as admin.
2. Go to the BASIC > Services page and select the Barracuda Web Security Gateway service.
3. The Service must show a green check mark icon for each of the Barracuda Web Security Gateways added as a server.
Step 5. Verify the Configuration
The client browsers must be configured with the proxy settings using the Barracuda Web Security Gateway service's IP address (configured on
the Barracuda Load Balancer ADC) and port 3128. When the client accesses any website such as cnn.com, traffic from the client goes to the
Barracuda Web Security Gateway service on the Barracuda Load Balancer ADC. The Barracuda Load Balancer ADC then sends the traffic to
one of the Barracuda Web Security Gateways configured as part of the service.
If the Barracuda Web Security Gateways are not the same model, you can modify the weights for each to match its capability. Higher models
should have higher weights. By default, weights are set to 1, which means all of the Barracuda Web Security Gateways have the same capacity
and will receive the same volume of traffic.

Follow the steps in this guide to deploy the Barracuda Load Balancer ADC to increase the scalability and reliability of your Citrix XenApp and
XenDesktop deployment. The Barracuda Load Balancer ADC also improves the performance of Citrix XenApp and XenDesktop by balancing the
application and remote desktop connection requests and traffic to and from your servers.
To deploy Citrix XenApp and XenDesktop with the Barracuda Load Balancer ADC, you must have the following:
Barracuda Load Balancer ADC version 5.1 or 5.2

Citrix XenApp and XenDesktop 6 or 7
Windows Server 2008 r2 or later
You must also complete the following tasks:
Install your Barracuda Load Balancer ADC(s), connect to the web interface, and activate your subscription(s).
To deploy Citrix XenApp or XenDesktop with high availability, you need to cluster your Barracuda Load Balancer ADCs. For more
information, see High Availability.
Terminology
Term Definition
Fully Qualified Domain Name (FQDN) The unique name for a specific computer or host that can resolve to
an IP address (e.g., www.example.com).

VIP Virtual IP address. In the Barracuda Load Balancer ADC deployment,

the VIP address is added to the service on the Barracuda Load
Balancer ADC.
Deployment Scenario
Deploying Citrix XenApps and XenDesktop
For instructions on deploying your version of Citrix XenApp and XenDesktop, see these articles:
Citrix XenApp and XenDesktop 6.x Deployment



Follow the steps in this guide to deploy the Barracuda Load Balancer ADC to increase the scalability and reliability of your Citrix XenApp or
XenDesktop deployment.
Terminology
Term Definition

arriving on the specified port is directed to one of the real servers

Balancer ADC.
To deploy Citrix XenApp and XenDesktop 6.x with the Barracuda Load Balancer ADC, you must have the following:
Barracuda Load Balancer ADC version 5.1 and above

Citrix XenApp 6.x or Citrix XenDesktop 6.x
Windows Server 2008 R2 or later
Install your Barracuda Load Balancer ADC(s), connect to the web interface, and activate your subscription(s).
To deploy Citrix XenApp and/or XenDesktop with high availability, you must cluster your Barracuda Load Balancer ADCs. For more
On the Barracuda Load Balancer ADC, create services for the type of traffic that is supported by your Citrix servers. Depending on the traffic type,
you can create Instant SSL, HTTP, or HTTPS services.
Citrix servers support traffic over HTTP only Create the CITRIX_HTTP service.
Citrix servers support traffic over HTTPS only Create the CITRIX_HTTPS service.
Citrix servers support traffic over HTTP and HTTPS If you want to offload SSL to the ADC and redirect HTTP traffic to an
HTTPS service, create the CITRIX_INSTSSL service, otherwise
create a combination of the CITRIX_HTTP service and CITRIX_HTT
PS service.
Step 1. Configure the Citrix Servers
When you are deploying Citrix XenApp or Citrix XenDesktop, set up at least two servers in a server group configuration and license both servers.
Set up one server as the master and the other server as the support server. HTTP is configured by default. If you want to use HTTPS or Instant
SSL, first make the appropriate changes to the internal and external access links.
Step 2. Create Services on the Barracuda Load Balancer ADC
Add services according to the type of traffic supported by your Citrix servers.
1. Log into the Barracuda Load Balancer ADC as the administrator.

2. If you want to create an HTTPS or Instant SSL service, go to the BASIC > Certificates page and import the same certificate you
configured for the Citrix servers.
4. For each type of service that you add from Table 1, click Add Service and enter the values in the corresponding fields.
Table 1. Available Services
Name Type IP Address Port Session Server Monitor

Timeout

CITRIX_HTTP HTTP VIP address for the 80 0 Testing

Citrix service Method: Simp
For example: 10. le HTTP
5.7.193 HTTP
Method: HEA
D
Test Target: /
CitrixAccess/a
uth/login.aspx
Additional
Headers: Use
r-Agent:
Barracuda
Load Balancer
ADC Server
Monitor
Status Code:
200
Test Delay: 3
0 Seconds
CITRIX_HTTPS HTTPS VIP address for the 443 0 Testing

Citrix service Method: Simp
For example: 10. le HTTPS
5.7.193 HTTP
Method: HEA
D
Test Target: /
CitrixAccess/a
uth/login.aspx
Additional
Headers: Use
r-Agent:
Barracuda
Load Balancer
ADC Server
Monitor
Status Code:
200
Test Delay: 3
0 Seconds
CITRIX_INSTSSL INSTANT_SSL VIP address for the Port: 443 0 Testing

Citrix service HTTP Redirect Method: Simp
For example: 10. Port: 80 le HTTP
5.7.193 HTTP
Method: HEA
D
Test Target: /
CitrixAccess/a
uth/login.aspx
Additional
Headers: Use
r-Agent:
Barracuda
Load Balancer
ADC Server
Monitor
Status Code:
200
Test Delay: 3
0 Seconds
5. If your servers are configured in a cluster, specify these settings in the Load Balancing section:
a. For Algorithm, select Least Requests.
b. For Persistence Type, select Cookie Insert.
c.

5.
c. Enter a name for the cookie and configure the cookie settings that appear.
d. In the Persistence Time field, enter 1200.
6. Click Create.
Step 3. Add the Real Servers
Add your Citrix servers to your services. For each Citrix server:
3. Enter the IP address and port of the server.
If you are adding the server to an CITRIX_HTTP or CITRIX_INSTSSL service, use Port 80.
If you are adding the server to an CITRIX_HTTPS service, use Port 443.
4. If the server is part of a cluster, specify whether it is a Backup server and enter its Weight for the load balancing algorithm.
5. If you are adding the server to an HTTPS service, enable SSL.
a. Set Servers uses SSL to On. If you do not enable the server to use SSL, unencrypted traffic is passed to the server because
the Barracuda Load Balancer ADC decrypts incoming traffic in order to maintain session persistence using HTTP cookies.
b. Select the Certificate that you uploaded for the Citrix server.
6. Click Create.
Step 4. Configure DNS
Create an A record to point to the VIP address that you set on the Barracuda Load Balancer ADC for the Citrix XenApp service.
For example, if you want to use the name citrix and your domain is barracuda.com, your A record would appear as follows:
Name IP Address
citrix.barracuda.com 10.5.7.193
Step 5. Verify Your Configuration
Go to the Citrix Access Site by using the name that you set in the A record, and verify that you can log in and use the applications.
For example: citrix.barracuda.com
Next Steps
You can configure authentication and access control for your applications. For more information, see Access Control.


Follow the steps in this guide to deploy the Barracuda Load Balancer ADC to increase the scalability and reliability of your Citrix XenApp and
XenDesktop Deployment.
Terminology
Term Definition


Balancer ADC.
To deploy Citrix XenApp and XenDesktop 7.x with the Barracuda Load Balancer ADC, you must have the following:
Barracuda Load Balancer ADC version 5.1 and above

Citrix XenApp 7.x or XenDesktop 7.x
Windows Server 2012 or later
To deploy Citrix XenApp and/or XenDesktop with high availability, you must cluster your Barracuda Load Balancer ADCs. For more
On the Barracuda Load Balancer ADC, create services for the types of traffic that are supported by your Citrix servers. Depending on the traffic
type, you can create Instant SSL, HTTP, or HTTPS services.
Citrix servers support traffic over HTTP only Create the CITRIX_HTTP service.
Citrix servers support traffic over HTTPS only Create the CITRIX_HTTPS service.
Citrix servers support traffic over HTTP and HTTPS If you want to offload SSL to the ADC and redirect HTTP traffic to an
HTTPS service, create the CITRIX_INSTSSL service, otherwise
create a combination of the CITRIX_HTTP service and CITRIX_HTT
PS service.
Step 1. Configure the XenApp and XenDesktop Servers
Set up at least two Citrix XenApp and XenDesktop servers in a server group configuration and license both servers. Ensure that the Citrix Store
Front is properly configured. HTTP is enabled by default. If you want to use HTTPS or Instant SSL, first make the appropriate changes to the
internal and external access links.
Add services according to the type of traffic supported by your Citrix servers.

2. If you want to create an HTTPS or Instant SSL service, go to the BASIC > Certificates page and import the same certificate you
configured for the Citrix servers.
4. For each type of service that you add from Table 1, click Add Service and enter the values in the corresponding fields

Timeout

CITRIX_HTTP HTTP VIP address for 80 0 Testing

the Citrix service Method
For example: 10. : Simple
5.7.193 HTTP
HTTP
Method
: HEAD
Test
Target:
/Citrix/St
oreWeb
Additio
nal
Header
s: User-
Agent:
Barracu
da Load
Balance
r ADC
Server
Monitor
Status
Code: 2
00
Test
Delay: 3
0
Seconds
CITRIX_HTTPS HTTPS VIP address for 443 0 Testing

the Citrix service Method
For example: 10 : Simple
.5.7.193 HTTPS
HTTP
Method
: HEAD
Test
Target:
/Citrix/St
oreWeb
Additio
nal
Header
s: User-
Agent:
Barracu
da Load
Balance
r ADC
Server
Monitor
Status
Code: 2
00
Test
Delay: 3
0
Seconds

CITRIX_INSTSSL INSTANT_SSL VIP address for Port: 443 0 Testing

the Citrix service HTTP Redirect Method
For example: 10 Port: 80 : Simple
.5.7.193 HTTP
HTTP
Method
: HEAD
Test
Target:
/Citrix/St
oreWeb
Additio
nal
Header
s: User-
Agent:
Barracu
da Load
Balance
r ADC
Server
Monitor
Status
Code: 2
00
Test
Delay: 3
0
Seconds
6. Click Create.
Add your Citrix servers to your services. Configure each Citrix server as follows:
If you are adding the server to an CITRIX_HTTP or CITRIX_INSTSSL service, use Port 80.
If you are adding the server to an CITRIX_HTTPS service, use Port 443.
a. Set Servers uses SSL to On. If you do not enable the server to use SSL, unencrypted traffic is passed to the server
because the Barracuda Load Balancer ADC decrypts incoming traffic in order to maintain session persistence using
HTTP cookies.
b. Select the Certificate that you uploaded for the Citrix server.
6. Click Create.
Create an A record to point to the VIP address that you set on the Barracuda Load Balancer ADC for the Citrix XenApp and XenDesktop service.
For example, if you want to use the name citrix and your domain is barracuda.com, your A record would appear as follows:
Name IP Address
citrix.barracuda.com 10.5.7.193
Go to the Citrix Store Front site by using the name that you set in the A record, and verify that you can log in and use the applications.

For example: citrix.barracuda.com/StoreWeb
Next Steps

IBM Notes and Domino Social Edition brings social collaboration and business applications together in a single, easy-to-use environment, with
just-in-time access to applications and email across a wide range of client devices.
The Barracuda Load Balancer ADC increases the performance, scalability, and reliability of IBM Domino. It distributes traffic among the Domino
Servers in your deployment for better load distribution and monitors the health of each server.
Terminology
Term Definition
VIP Virtual Internet Protocol (VIP) address. In the ADC deployment, the
VIP is added to the service on the Barracuda Load Balancer ADC.

Instant SSL An Instant SSL service provides SSL (HTTPS) access to content on
servers without having to modify the servers or the content on the
servers. The Barracuda Load Balancer ADC rewrites the "http" links
in the response to "https".
You must have the following:
Barracuda Load Balancer ADC firmware version 5.1 or 5.2

For Application Security, you must have ADC firmware version 5.2
IBM Domino 9 Social Edition
You must have complete the following procedures:
If you want to deploy IBM Domino with high availability, cluster your Barracuda Load Balancer ADCs. For more information, see High
Availability.
Deployment Scenario
On the Barracuda Load Balancer ADC, create services for the types of traffic that are supported by your Domino servers. Depending on the traffic
type, you can create Instant SSL, HTTP, or HTTPS services.
Domino servers support traffic over HTTP only Create the DOMINO_HTTP service.
Domino servers support traffic over HTTPS only Create the DOMINO_HTTPS service.

Domino servers support traffic over HTTP and HTTPS If you want to redirect HTTP traffic to an HTTPS service, create the D
OMINO_INSTSSL service, otherwise create a combination of the DO
MINO_HTTP service and DOMINO_HTTPS service.
Step 1. Configure your Clustered Domino Servers
1. Set up at least two IBM Domino servers with your preferred operating system (Domino is available for both Windows and Linux).
2. Configure the servers and ensure that both servers are in the same cluster and replication is enabled.
Step 2. (HTTPS and Instant SSL Services Only) Import Domino Certificates
If you want to create an HTTPS or Instant SSL service, import either a certificate from the Domino servers or a CA certificate.

2. Go to the BASIC > Certificates page and upload the certificates.
3. If you are using a CA certificate, ensure that you also import it on the Domino servers.
On the Barracuda Load Balancer ADC, create services according to the type of traffic supported by your Domino servers.


Timeout
DOMINO_HTTP HTTP VIP address for the 80 0 Testing

Domino service Method: Simp
For example: 10.5 le HTTP
.7.193 HTTP
Method: HEA
D
Test Target: /
Additional
Headers: Use
r-Agent:
Barracuda
Load Balancer
ADC Server
Monitor
Status Code:
200
Test Delay: 3
0 Seconds
DOMINO_HTTPS HTTPS VIP address for the 443 0 Testing

Domino service Method: Simp
For example: 10.5 le HTTPS
.7.193 HTTP
Method: HEA
D
Test Target: /
Additional
Headers: Use
r-Agent:
Barracuda
Load Balancer
ADC Server
Monitor
Status Code:
200
Test Delay: 3
0 Seconds

DOMINO_INSTSS INSTANTSSL VIP address for the Port: 443 0 Testing

L Domino service HTTP Redirect Method: Simp
For example: 10.5 Port: 80 le HTTP
.7.193 HTTP
Method: HEA
D
Test Target: /
Additional
Headers: Use
r-Agent:
Barracuda
Load Balancer
ADC Server
Monitor
Status Code:
200
Test Delay: 3
0 Seconds
4. If you have the Barracuda Load Balancer ADC 640 and above and have ADC firmware version 5.2, you can enable Application Securit
y for the service.
a. For Application Security, select Enable.
b. For Security Mode, select Passive mode. It is recommended that you run the service in Passive mode before going active.
c. From the Security Policy list, select ibm_domino. This policy is predefined for all Domino applications. If you want to edit the
policy settings, go to the SECURITY > Security Policies page.
5. If y our servers are configured in a cluster, specify these settings in the Load Balancing section:
6. Click Create.
Add your Domino servers to your services. For each Domino server:
If you are adding the server to an HTTP service, use Port 80.
If you are adding the server to an HTTPS service, use Port 443.
b. Select the Certificate that you uploaded for the Domino server.
6. Click Create.
Step 5. Configure the DNS
Create an A record to point the VIP address that you set on the Barracuda Load Balancer ADC for the IBM Domino service.
For example, if you want to use the name Domino and your domain is barracuda.com, your A record would look something like this:
Name IP Address
Domino.barracuda.com 10.5.7.193
To ensure that your setup is fully working, navigate to the Domino Web Admin site by using the name that you set in the A record and verify that
the page displays correctly.
For example: Domino.barracuda.com/webadmin.nsf
Next Steps


Barracuda Networks has conducted interoperability tests using the Barracuda Load Balancer ADC and Microsoft® Exchange Server 2010. Follow
the steps in this guide to deploy the Barracuda Load Balancer ADC to increase the scalability and reliability of your Microsoft Exchange Server
2010 deployment. Using a Barracuda Load Balancer ADC allows load balancing of a Client Access server (CAS) array.
You must have:
Barracuda Load Balancer ADC version 5.1 or 5.2.

Microsoft® Exchange Server 2010 (Barracuda recommends that you upgrade to the latest service pack, SP3).
If you want to deploy the Microsoft Exchange Server with high availability, clustered your Barracuda Load Balancer ADCs. For more
Completed the steps in the following Deploying Exchange Services on the Barracuda Load Balancer ADC section.
Terminology
Term Description
Microsoft Exchange Server A Microsoft Exchange Server deployment consists of Client Access
Servers (CAS), Hub transport Server, and Exchange Mailbox
servers.
Virtual IP (VIP) Address The IP address assigned to a service. Clients use the virtual IP
address to connect to the load-balanced service.

Client Access Server (CAS) 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.
Real Server A server associated with a service that handles the requests
forwarded to it by the Barracuda Load Balancer ADC.
Hub Transport Server (HUB) The Hub Transport server role handles all mail flow inside the
organization and delivers messages to a recipient's mailbox.
Outlook Web App (OWA) Originally called Outlook Web Access, OWA is the Webmail
component of Microsoft Exchange Server 2010.
Deployment Options
There are two configurations that are supported when adding a Barracuda Load Balancer ADC to a Microsoft Exchange Server 2010
environment:
If your Exchange servers are on the same subnet as the rest of your topology, choose a one-armed, Route-Path deployment.
If the Exchange servers are on a separate subnet from the rest of the topology and connected to the LAN side of the Barracuda Load
Balancer ADC, choose a two-armed, Route-Path deployment.
Deploying in Direct Server Return with Microsoft Exchange 2010 is untested and unsupported.
Two-Arm Deployment Scenario

Microsoft TechNet Resources
Refer to the Microsoft TechNet online library for more information on the following topics:
Load Balancing Requirements of Exchange Protocols

Configure SSL Offloading for Outlook Anywhere
Microsoft Exchange Network Port Reference
Understanding Load Balancing in Exchange 2010
Create a New Exchange Certificate
Deploying Exchange Services on the Barracuda Load Balancer ADC
To deploy the Exchange servers with the Barracuda Load Balancer ADC, complete the following steps:
Configuring Clustered Barracuda Load Balancer ADCs

If your Barracuda Load Balancer ADCs are clustered, the configuration between the active and passive units is synchronized; you only
need to configure the active Barracuda Load Balancer ADC.
Step 1. Configure the Client Access Server (CAS) Array
To configure MAPI client access (for example, Microsoft Outlook clients), configure the CAS array for the Exchange domain. You only need to
complete this configuration on one Exchange Server. For any other options that you might want to consider, consult Microsoft documentation.
Note that Microsoft only allows one CAS array per site.
Clients access their mailboxes with RPC and connect to the FQDN of the RPC CAS array set on the mailbox database. The FQDN resolves to a
virtual IP address on the Barracuda Load Balancer ADC. In turn, the Barracuda Load Balancer ADC connects with one of the Client Access
servers.
Help for Multi-Site Exchange Environments

Help for Multi-Site Exchange Environments
The following steps assume a single-site Exchange environment. If you need help with configuring a CAS array in a multi-site
environment, contact Microsoft.
To configure the CAS array:
1. 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
is used by clients to connect to the CAS Array.
2. On one Exchange server in the array, open the Exchange Management Shell and create a new CAS array.
a. Verify that there are no existing CAS arrays. Enter the following command:
Get-ClientAccessArray
In an unconfigured single-site deployment, the command returns nothing.
b. Create a new CAS array. Enter the following command:
New-ClientAccessArray -Fqdn exchange.domain.local -Site Default-First-Site-Name
where exchange.domain.local is the FQDN of the CAS array and Default-First-Site-Name is the Active Directory site to which the
CAS array belongs.
3. Ping the FQDN (e.g. exchange.domain.local). The ping fails because the service has not yet been created on the Barracuda Load
Balancer ADC, but verify that the domain name resolves correctly to the VIP address.
4. Add a mailbox database to the CAS array. In the Exchange Management Shell, enter the following command:
Get-MailboxDatabase | Set-MailboxDatabase -RpcClientAccessServer exchange.domain.local

4.
where exchange.domain.local is the FQDN of the CAS array.

If you are deploying in a multiple-site Exchange environment, restrict the Set-MailboxDatabase cmdlet with -Identity 'mailbox database
name' to return only the databases that you want to include in the CAS Array. For the cmdlet syntax, see the Microsoft TechNet article
Get-MailboxDatabase .
Step 2. Prepare Your Environment for SSL Offloading
Offload SSL processing to the Barracuda Load Balancer ADC. To maintain session persistence using HTTP cookies, SSL encryption and
decryption must occur on the Barracuda Load Balancer ADC. Offloading the SSL processing to the Barracuda Load Balancer ADC 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 ADC and the servers using the same VIP address, but on port 80.
1. 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), see the Microsoft TechNet article Export an
Exchange Certificate for instructions on exporting your Exchange certificate.
2. In the Barracuda Load Balancer ADC web interface, go to the BASIC > Certificates page and install the certificates, certificate chain,
and private key.
3. Configure the Exchange 2010 Services to be SSL offloaded. For more information on configuring OWA, Outlook Anywhere (OA),
Exchange Control Panel (ECP), Exchange Web Services (EWS), and ActiveSync (EAS) for SSL offloading, see the Microsoft TechNet
article How to Configure SSL Offloading in Exchange 2010.
Next Step
If your Exchange servers are on the same subnet as the rest of your topology, continue with:
How to Deploy Microsoft Exchange Server 2010 in a One-Armed Configuration.
If your Exchange servers are not on the same subnet as the rest of your topology, and are connected to the interface configured for the internal
network side of the Barracuda Load Balancer ADC, continue with:
How to Deploy Microsoft Exchange Server 2010 in a Two-Armed Configuration.

How to Deploy Microsoft Exchange Server 2010 in a One-Armed Configuration

This article applies to the Barracuda Load Balancer ADC version 5.1 and above, with Microsoft® Exchange Server 2010.
For a full list of the prerequisites for this deployment, see Microsoft Exchange Server 2010 Deployment.
In a one-armed configuration, the ports that internal Outlook® clients use to communicate with the Exchange 2010 server using RPC must be
preconfigured on both Exchange 2010 and the Barracuda Load Balancer ADC.
If you want to use a single VIP address and single FQDN for your Exchange deployment, you must use a one-armed configuration.

Step 1. Configure Exchange 2010 to Use a Static Port
By default, the Exchange 2010 RPC client dynamically selects a port between 1024 and 65535. To allow for a one-armed deployment, configure
Exchange to use a static port instead. For more detailed instructions on configuring Exchange 2010 with static ports and hardware Load Balancer
ADCs, see the Microsoft TechNet article Load Balancing Requirements of Exchange Protocols.
On each CAS server, complete the following:
1. Configure the static port in the registry.

a. Open the Registry Editor by typing regedit in the Start menu.
b. Navigate to HKEY_LOCL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeRpc\ParametersSystem.
c. Add a new DWORD (32-bit) Value, and name it TCP/IP Port.
You might need to create the ParametersSystem key prior to adding the DWORD registry value. If prompted, change the Base
to Decimal and set the value data to 65500 (or a port of your choice between 1024 and 65535):
d. If you have Public Folders in your deployment, repeat these steps to configure the static port in the registry of each server with
the mailbox role installed that hosts a Public Folder.
2. Change the port that clients use to connect for directory access. On each CAS server, complete the set of instructions for your Exchange
version.
If you are running Microsoft Exchange 2010 RTM (including RTM Rollup 1 - 4), click here...
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 in Notepad.
c. In line 13, change the default value of 0 to 65501 (or a port of your choice within the prior specified range). The entry
appears as follows:
<add key="RpcTcpPort" value="65501" />
If you are running Microsoft Exchange 2010 SP1, click here...

a. Open the Registry Editor by typing regedit in the Start menu.
b. Navigate to HKEY_LOCL_MACHINE\SYSTEM\CurrentControlSet\services\MSExchangeAB\Parameters.
c. Add a new String Value (REG_SZ type), and name it RpcTcpPort .
You might need to create the Parameters key prior to adding the REG_SZ registry value. In this case, change the Data val
ue to 65501 (or a port of your choice between 1024 and 65535).

c.
3. Restart the Microsoft Exchange Address Book and the Microsoft Exchange RPC Client Access services on all the CAS and
Mailbox servers that you modified.
4. To verify that your Client Access servers are using ports 65500 and 65501, open a Windows command prompt and run:
netstat -na
In the output, look for TCP entries marked as LISTENING with ports 65500 and 65501. An entry is marked as LISTENING for
0.0.0.0:65500 and 0.0.0.0:65501.
Step 2. Configure CAS Services on the Barracuda Load Balancer ADC
On each active Barracuda Load Balancer ADC that handles traffic for CAS services, complete the following steps.
1. Log into the Barracuda Load Balancer ADC, and go to the BASIC > Services page.
2. Add all of the services listed in Table 1. For each service, add all the real servers in the CAS array. To add a service, click Add Service
and enter the values in the corresponding fields. To add a real server, click Add Server and enter the IP address and port for the server.
Table 1. CAS Services
Name Type IP Address Port Session SSL Certificate Load Real

Timeout Settings s Balancing Server
Port
MAPI-DCO TCP Proxy VIP 135 1200 N/A N/A Persis 135
M address for tence
the FQDN Type:
that Source
resolves to IP
the CAS Persis
array tence
e.g., excha Time:1
nge.doma 200
in.local
Note: This
service is
helpful in
cases
where there
is no port
restriction.

MAPI-RPC TCP Proxy VIP 65500 1200 N/A N/A Persis 65500
_Client_Ac address for tence
cess the FQDN Type:
that Source
resolves to IP
the CAS Persis
array tence
e.g., excha Time:1
nge.doma 200
in.local
Note: This
service is
helpful in
cases
where there
is no port
restriction.
MAPI-Glob TCP Proxy VIP 65501 1200 N/A N/A Persis 65501
al_Address address for tence
_Book the FQDN Type:
that Source
resolves to IP
the CAS Persis
array tence
e.g., excha Time:1
nge.doma 200
in.local
Note: This
service is
helpful in
cases
where there
is no port
restriction.
Exchange_ Instant SSL VIP Port: 443 1200 Select the Persis 80
Web_Servi address for certificate tence
ces the FQDN HTTP that you Type:
that clients Service uploaded HTTP
use to Port: 80 when Heade
access the preparing r
CAS array your Persis
e.g., excha environmen tence
nge.doma t for SSL Time:1
in.local offloading. 200
See Step 2 Heade
Note: in the r
"Deploying Name:
Exchange Authori
Services on zation
the
Barracuda
Load
Balancer
ADC"
section of
Microsoft
Exchange
Server
2010
Deploymen
t.

Secur
This
e Site
service
Domai
is
n–
useful
Enter
when
the
there
domai
are
n
port
name
restricti
of your
ons,
Excha
and
nge
traffic
server.
is
If the
allowe
interna
d only
l and
for port
extern
443.
al
To
domai
create
n are
an
differe
HTTP
nt, you
redirec
can
t
use
service
wildcar
autom
d
atically
charac
, you
ters.
must
For
create
exampl
an
e: *.b
Instant
arrac
SSL
uda.c
service
om
.
If your
Changi
Barrac
ng an
uda
HTTP
Load
S
Balanc
service
er
to an
ADC is
Instant
runnin
SSL
g
service
version
does
5.1.1 a
not
nd
autom
above,
atically
set the
create
Rewrit
a
e
HTTP
Suppo
redirec
rt optio
t
n to O
service
n. For
.
version
For
s belo
more
w 5.1.1
inform
, this
ation
option
about
is
Instant
named
SSL,
Instan
see Ins
t SSL.
tant
SSL
Servic
e.

3. If you have the Barracuda Load Balancer ADC 640 and above, you can enable Application Security for Exchange_Web_Services.
b. For Security Mode, select the Passive mode. It is recommended that you run the service in Passive mode before going active.
c. From the Security Policy list, select owa2010. This policy is predefined for all Exchange applications. If you want to edit the
policy settings, go to the SECURITY > Security Policies page
d. You need to modify the default owa2010 policy. Go to the SECURITY > Security Policies page and select the owa2010 securit
y policy. In the Cookie Security section, set Tamper Proof Mode to None.
If you want to use Integrated Windows Authentication with the Exchange service, go to the Request Limits section of
the security policy settings and increase the Max Header Value Length to 800.
4. If you require any of the protocols in Table 2, add the service for the protocol.
Table 2. Protocol Services.
Name Type IP Address Port Real Server Port
IMAP4 TCP Proxy VIP address for the 143 143

FQDN that resolves to
the CAS array
e.g., exchange.domai
n.local
IMAP4 SSL TCP Proxy VIP address for FQDN 993 993
that resolves to CAS
array
n.local
POP3 TCP Proxy VIP address for FQDN 110 110

array
n.local
POP3_SSL TCP Proxy VIP address for FQDN 996 996

array
n.local
Step 3. Configure the Real Servers for Exchange_Web_Services
For Exchange_Web_Services only, configure health checks for all of its real servers :
1. On the BASIC > Services page, click Edit next to the entry of the real server.
2. Scroll to the Server Monitor section, and enter the values in the corresponding fields.
Testing Port Test Target Test Match Additional Status Code Test Delay
Method Headers
Simple HTTPS 443 /owa/auth/logon Microsoft User-Agent: 200 30

.aspx (unless Corporation Barracuda Load
you modified Balancer ADC
the default path Server Monitor
of logon.aspx)
3. Click Save Changes.
Step 4. Create Content Rules for Exchange_Web_Services
Create content rules for Exchange_Web_Services to maintain persistence for Outlook Web Access, Exchange Control Panel and Exchange Web
Services.
1. On the BASIC > Services page, add the rules in Table 3. To add a rule, click Add Content Rule under Exchange_Web_Services in the
left pane. Then enter the values in the corresponding fields.
Table 3. Content Rules for Exchange_Web_Services

Name Host Match URL Match Persistence Persistence Time Cookie Name
Method
OWA * /owa/* Cookie Insert 1200 sessionid
ECP * /ecp/* Cookie Insert 1200 sessionid
EWS * /ews/* Cookie Insert 1200 sessionid
2. If you are using Outlook Anywhere (HTTPS only, not RPC over HTTPS), you must also add the following content rule for the Offline
Address Book.
Name Host Match URL Match Persistence Persistence Time Cookie Name
Method
OAB * /oab/* Cookie Insert 1200 sessionid
3. For each of the Content Rules you have configured, you need to add the appropriate Microsoft Exchange server(s). Select each Content
Rule and click Add Server and specify your Microsoft Exchange server(s).
4. If SNI is enforced on the Microsoft Exchange server(s), then you need to configure the following options. Go to the BASIC > Services pa
ge and click Edit for each affected server.
a. Change the port on the server to 443.
b. Navigate to the SSL section and set Server uses SSL to On.
c. Expand Settings and set Enable SNI to Yes.
Step 5. Configure Hub Transport Services on the Barracuda Load Balancer ADC
On each active Barracuda Load Balancer ADC that handles traffic for Hub Transport Services, configure Hub Transport Services for Exchange
2010.
If your real servers are consolidated with both the CAS and HUB roles installed, add each server for each service that you create. If the Hub
Transport role is installed on separate servers (other than those with the CAS role), add 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.
Never configure the Exchange Hub Transport to communicate with other internal Microsoft Exchange Hub Servers via the Barracuda
Load Balancer ADC. Only use the service on the Barracuda Load Balancer ADC for client connections or inbound connections from
other organizations.
On the BASIC > Services page, add the following SMTP service and, optionally, the SMTP-SSL service. To add a service, click Add Service an
d enter the values in the corresponding fields. To add a real server, click Add Server and enter the IP address and port for the server.
Name Type IP Address Port Real Server Port
SMTP TCP Proxy VIP address for the 25 25

the CAS array
e.g., exchange.domain
.local
(Optional) SMTP-SSL TCP Proxy VIP address for the 587 587
the CAS array
e.g. exchange.domain
.local
Step 6. Configure an HTTP Request Rewrite Rule
To simplify access to the Outlook Web Access site for your users, configure a rewrite rule to add /OWA to the end of the URL.
1. Go to the TRAFFIC > Web Translations page.

2. From the Service list, select Exchange_Web_Services.
3. In the HTTP Request Rewrite section, add the following rule. Click Add Rule and enter the values in the corresponding fields.
Rule Name Sequence number Action Old Value Rewrite Value Rewrite Condition
OWA 3 Redirect URL / /OWA *
4. Click Save.

Next Steps
Your installation is complete. You can now test your setup and configure access control to your applications. For instructions, see:
How to Test the Microsoft Exchange Server 2010 Deployment Configuration

Access Control

How to Deploy Microsoft Exchange Server 2010 in a Two-Armed Configuration

This article applies to the Barracuda Load Balancer ADC version 5.1 and above, with Microsoft® Exchange Server 2010.
For a full list of the prerequisites for this deployment, see Microsoft Exchange Server 2010 Deployment.
Follow the steps in this article to deploy the Microsoft® Exchange Server 2010 in a two-armed configuration.
Step 1. Create Services
On the Barracuda Load Balancer ADC, create services for the Exchange services.
1. Log into the Barracuda Load Balancer ADC, and go to the BASIC > Services page.
2. Add all of the services listed in Table 1. For each service, add all the real servers in the CAS array. To add a service, click Add Service
and enter the values in the corresponding fields. To add a real server, click Add Server and enter the IP address and port for the server.
Table 1. Required Services
Name Type IP Address Port Session SSL Certificate Load Real

Time Settings s Balancing Server
Port
Exchange Layer 4 - VIP ALL N/A N/A N/A Persistenc N/A

TCP address for e Time: 12
the FQDN 00
that
resolves to
the CAS
array
e.g. excha
nge.doma
in.local
Note: This
service is
helpful in
cases
where there
is no port
restriction.

OWA-HTT Instant SSL VIP Port: 443 1200 Secur Select the Persis 80
PS address for e Site certificate tence
that FQDN HTTP that you
Domai Type:
that clients Service uploaded
n– HTTP
use to Port: 80 when
Enter Heade
access the preparing r
OWA domai your Persis
e.g., owa.d n environmen tence
omain.lo name t for SSL Time:
cal of your offloading. 1200
Excha See Step 2 Heade
nge in the r
server. "Deploying Name:
If the Exchange Authori
interna Services on zation
l and the
extern Barracuda
al Load
domai Balancer
n are ADC"
differe section of
nt, you Microsoft
can Exchange
use Server
wildcar 2010
d Deploymen
charac t.
ters.
For
exampl
e: *.b
arrac
uda.c
om
If your
Barrac
uda
Load
Balanc
er
ADC is
runnin
g
version
5.1.1 a
nd
above,
set the
Rewrit
e
Suppo
rt optio
n to O
n. For
version
s belo
w 5.1.1
, this
option
is
named
Instan
t SSL.
3. If you have the Barracuda Load Balancer ADC 640 and above, you can enable Application Security for OWA-HTTPS.
b.

3.
c. From the Security Policy list, select owa2010. This policy is predefined for all Exchange applications. If you want to edit the
policy settings, go to the SECURITY > Security Policies page
If you want to use Integrated Windows Authentication with the OWA-HTTPS service, go to the Request Limits section
of the security policy settings and increase the Max Header Value Length to 800.
4. For OWA-HTTPS only, enable health checks for its real servers.
a. Next to the entry of the real server, click Edit.
b. Scroll to the Server Monitor section, and enter the values in the corresponding fields.
Testing Port Test Target Test Match Additional Status Code Test Delay
Method Headers
Simple HTTPS 443 /owa/auth/logo Microsoft User-Agent: 200 30

n.aspx (unless Corporation Barracuda
you modified Load Balancer
the default ADC Server
path of Monitor
logon.aspx)
c. Click Save.
5. If SNI is enforced on the Microsoft Exchange server(s), you need to configure the following options. Go to the BASIC > Services page
and click Edit for each affected server.
a. Change the port on the server to 443.
b. Navigate to the SSL section and set Server uses SSL to On.
c. Expand Settings and set Enable SNI to Yes.
6. If you deployed the Hub Transport Role on servers other than those in the CAS array, add the following services in Table 2.
Table 2. (If applicable) SMTP Services
Name Type IP Address Port Real Server Port Monitor Port
SMTP Layer 4 - TCP VIP address for the 25 25 25

FQDN that
resolves to HUB
Services
e.g., smtp.domai
n.local
(Optional) Layer 4 - TCP VIP address for the 587 587 587
SMTP_SSL FQDN that
resolves to HUB
Services
e.g., smtp.domai
n.local
7. Update the TCP timeout values on the Barracuda Load Balancer ADC.
a. Go to the ADVANCED > System Configuration page.
b. Set the TCP Connections Timeout and TCP Closed Connections Timeout to 1200 seconds.

2. From the Service list, select the OWA-HTTPS service.
4. Click Save.
Next Steps

Your installation is complete. You can now test your setup and configure access control to your applications. For instructions, see:

Access Control


Before testing the configuration, verify you have completed all of the steps in How to Deploy the Barracuda Load Balancer ADC
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:
1. 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.
2. 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 e-mail account, type in the FQDN of one of the Real Servers (members) of the CAS array. Enter a valid
email 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.
3. Open the Global Address book in Outlook, and make sure it behaves normally.
4. 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:
1. 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).
2. 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.

Barracuda Networks has conducted interoperability tests using the Barracuda Load Balancer ADC and Microsoft® Exchange Server 2013 and
Microsoft Exchange Server 2016. Follow the steps in this guide to deploy the Barracuda Load Balancer ADC to increase the scalability and
reliability of your Microsoft Exchange Server deployment. Using a Barracuda Load Balancer ADC allows load balancing of a Client Access Server
(CAS).
You must have:
Barracuda Load Balancer ADC version 5.1 or above.

Microsoft Exchange Server 2013 or Microsoft Exchange Server 2016.
If you want to deploy the Microsoft Exchange Server with high availability, clustered your Barracuda Load Balancer ADCs . For more
information, see High Availability .
Terminology
Term Description
Microsoft Exchange Server A Microsoft Exchange Server deployment consists of Client Access
Servers (CAS) and Exchange Mailbox servers.
Virtual IP (VIP) Address The IP address assigned to a service. Clients use the virtual IP
address to connect to the load-balanced service.

Instant SSL Instant SSL provides SSL (HTTPS) access to content on servers
without having to modify the servers or the content on the servers.
The Barracuda Load Balancer ADC rewrites the "http" links in the
response to "https".
Client Access Server (CAS) 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.
Real Server A server associated with a service that handles the requests
forwarded to it by the Barracuda Load Balancer ADC.
Outlook Web App (OWA) Originally called Outlook Web Access, OWA is the Webmail
component of Microsoft Exchange Server 2010.
Deployment Topology for Microsoft Exchange Server 2013

Deployment Topology for Microsoft Exchange Server 2016
Deploying Exchange Services on the Barracuda Load Balancer ADC
To deploy the Exchange servers with the Barracuda Load Balancer ADC, complete the following steps:
Certificates
Barracuda Networks recommends that you use the same certificate on the Barracuda Load Balancer ADC and each CAS.
Step 1. Create the Exchange Services

2. Go to the BASIC > Certificates page, and create or upload a certificate for the service.
3. Go to the BASIC > Services page and add the following services. Click Add Service and enter the values in the corresponding fields
(each service must be added separately).
Name Type IP Address Port HTTP Session SSL Certificate Load

Service Timeout Settings Balancing
Port

Exchange_I Instant SSL VIP addres 443 80 1200 Secure Select the Persistenc
nstantSSL s for the FQ Site certificate e Type:
DN Domain – that you Cookie
that clients Enter the uploaded Insert
use to acce domain for the
ss name of service. Persistenc
the Outlook your e Time
Web Exchange (Barracuda
Access server. If
(OWA) and the internal Load
Exchange and Balancer
Admin external ADC 5.4
Center. domain are and
different, earlier): 12
you can 00 seconds
use
wildcard Cookie
characters. Expiry
For (Barracuda
example: *
.barracu Load
da.com Balancer
ADC 6.0
If your
and later):
Barracuda
1200
Load
seconds
Balancer
ADC is
running Cookie
version 5.1. Name – Ch
1 and oose a
above, set cookie
the Rewrite name.
Support
option to Of
f. For
versions be
low
5.1.1, this
option is
named Inst
ant SSL.
Exchange_ TCP Proxy VIP 25 N/A 1200 N/A N/A Persistenc

SMTP address for e Type:
the FQDN Source IP
that
Microsoft Persistenc
Exchange e Time: 12
server uses 00
to receive
mail.
4. Click Create.
5. If you have the Barracuda Load Balancer ADC 540 and above, you can enable Application Security for the service.
c. From the Security Policy list, select owa2013. This policy is predefined for all Exchange applications and applies to both
Exchange Server 2013 and 2016.
If you want to use Integrated Windows Authentication with the Exchange_InstantSSL service, go to the Request
Limits section of the security policy settings and increase the Max Header Value Length to 800.

Add each CAS to your service. For each server, enable SSL and configure health checks. Certificate validation can be ignored.
2. Click Add Server. Enter the values in the corresponding fields.
IP Address Port Server Monitor
IP address of the CAS 443 Testing Method: Simple HTTPS

Port: 443
Test Target: /owa/auth/logon.aspx
(unless you modified the default path
of logon.aspx)
Test Match: Microsoft Corporation
Additional Headers: User-Agent:
Server Monitor
Status Code: 200
Test Delay: 30
3. Click Create.
4. If SNI is enforced on the Microsoft Exchange server(s), click Edit for each affected server, expand Settings and set Enable SNI to Yes.

2. From the Service list, select the Exchange_InstantSSL service.
4. Click Save.
Configure the VIP address on the CAS virtual directories. Configure the DNS for the following domain names to point to the VIP address that you
created for the Exchange_InstantSSL service:
mail.domain.local
autodiscover.domain.local
eas.domain.local
outlook.domain.local
oab.domain.local
ecp.domain.local
Configure HTTPS namespace on the Exchange Admin Center:
1. Log into your Microsoft Exchange Admin Center.

2. Click Servers > Virtual Directories.
3. Select CAS1, click Edit , and configure external access domain.

4. Add both servers to the list and configure the external domain.
5. Click Save.
Next Step

Microsoft Forefront Unified Access Gateway (UAG) provides remote end users access to corporate applications, networks, and internal resources
via a Web portal or site.
The Barracuda Load Balancer ADC increases the performance, scalability, and reliability of Forefront UAG. It distributes traffic among the UAG
Servers in your deployment for better load distribution and monitors the health of each server.
Terminology
Term Definition
VIP Virtual IP address. In the ADC deployment, the VIP is added to the
service on the Barracuda Load Balancer ADC.

UAG Array A combination of two or more Forefront UAG servers existing as a

logical unit and which share the same configuration.
You must have:

Microsoft Forefront Unified Access Gateway 2010.
If you want to deploy Microsoft Forefront Unified Access Gateway with high availability, cluster your Barracuda Load Balancer ADCs. For
more information, see High Availability.
Deployment Scenario
On the Barracuda Load Balancer ADC, create services for the types of traffic that are supported by your Microsoft Forefront Unified Access
Gateway servers. Depending on the traffic type, you can create HTTP or HTTPS services.
The UAG servers support traffic over HTTP only. Create an HTTP service.
The UAG servers support traffic over HTTPS only. Create an HTTPS service.
Deploy the Barracuda Load Balancer ADC for UAG
To deploy the Barracuda Load Balancer ADC for UAG servers in an array, complete the following steps :
Step 1. Configure your UAG Servers in an array
1. Set up at least two UAG servers with your preferred operating system.
2. Configure the servers in an array.

Step 2. (HTTPS Only) Import UAG Certificates
If you want to create an HTTPS service, import either a certificate from the UAG servers or a CA certificate.
1. Log into the Barracuda Load Balancer ADC as an administrator.

2. Go to the BASIC > Certificates page and upload the certificates.
3. If you are using a CA certificate, ensure that you also import it on the UAG servers.
On the Barracuda Load Balancer ADC, create services according to the type of traffic supported by your UAG servers.

Name Type IP Address Port Session Certificate Load Server

Timeout Balancing Monitor
UAG_HTTP HTTP The VIP 80 1800 Not Per Test

address for applicable sist ing
the UAG enc Met
service. e hod:
For example: Ty TC
10.5.7.193 pe: P
So Port
urc Che
e ck
IP ( or )
Per Tes
sist
enc
tin
e g
Ti Met
me:
ho
60
0 d:
Sim
ple
HT
TP
HTT
P
Met
hod:
GE
T
Test
Targ
et: /

Addi
tion
al
Hea
ders
: Ho
st:
adcu
ag.q
a.cu
daop
s.co
m
(Spe
cify
the
host
of
the
UAG
Admi
nistr
ation
Port
al).
Stat
us
Cod
e: 30
2 (b
eca
use
the
logi
n
UR
L
inv
olv
es
redi
rect
ion)
UAG_HTTPS HTTPS The VIP 443 1800 Select the Per
address for certificate sist
the UAG that you enc
service. uploaded for e
For example: the service. Ty
10.5.7.193 pe:
So
urc
e
IP
Per
sist
enc
e
Ti
me:
60
0

Test
ing
Met
hod:
TC
P
Port
Che
ck
( or )
Test
ing
Met
hod:
Sim
ple
HTT
PS
HTT
P
Met
hod:
GE
T
Test
Targ
et: /
Addi
tion
al
Hea
ders
: Ho
st:
adcu
ag.q
a.cu
daop
s.co
m
(Spe
cify
the
host
of
the
UAG
Admi
nistr
ation
Port
al).
Stat
us
Cod
e: 30
2 (be
caus
e the
login
URL
invol
ves
redir
ectio
n)

4. Click Create.
Step 4. Add the Real ( UAG ) Servers
If you are adding the server to an HTTP service, use Port 80.
If you are adding the server to an HTTPS, use Port 443.
b. If the certificate for the service is a self-signed or a test certificate, set Validate Certificate to Off. If the service is using a
CA-signed certificate, select On.
c. Select the Certificate that you uploaded for the UAG server.
6. Click Create.
Create an A record to point the VIP address that you set on the Barracuda Load Balancer ADC for the UAG service.
For example, if you want to use the name adcuag and your domain is barracuda.com, your A record would be:
Name IP Address
adcuag.barracuda.com 10.5.7.193
To ensure that your setup is fully working, navigate to the UAG Admin site by using the name that you set in the A record and verify that the page
displays correctly.
For example: https://adcuag.barracuda.com

Organizations can use the Barracuda Load Balancer ADC to enhance the scalability and availability of their Lync Server deployments (formerly
known as Microsoft Office Communications Server).
Barracuda Networks has conducted interoperability tests between the Barracuda Load Balancer ADC and Microsoft Lync Server. This guide
describes how to deploy the Barracuda Load Balancer ADC to provide scaling in a Lync environment.
For organizations that want a scalable solution, Microsoft recommends using a hardware load balancer to distribute the traffic among multiple
Lync Servers.
You must have:

Microsoft® Lync® Server 2010 or 2013 Enterprise Edition.
At least the minimum number of Barracuda Load Balancer ADCs required for your deployment:
Deployment Number of Barracuda Load Balancer ADCs
Internal Lync Server Deployment Minimum: One Barracuda Load Balancer ADC
Recommended: Two Barracuda Load Balancer ADCs for
high availability
Internal Lync Server Deployment and Edge Deployment Minimum: Two Barracuda Load Balancer ADCs.
Recommended: Four Barracuda Load Balancer ADCs for
high availability
To maintain the integrity of the edge security model, separate

load balancers are required for the internal traffic and the edge
traffic.
Internal Lync Server Deployment, Edge Deployment, and Minimum: Three Barracuda Load Balancer ADCs
non-collocated A/V Services Recommended: Six Barracuda Load Balancer ADCs for high
availability
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.
If you want to deploy Lync Server with high availability, clustered your Barracuda Load Balancer ADCs. For more information, see High
Availability.
Before Running Lync Topology Builder
Do not run the Lync Topology Builder until instructed to do so by this deployment guide. All of the services on the Barracuda Load
Balancer ADC must be configured before running the Topology Builder.
Support for Office Web Apps Server and Lync Server (for internal users only)
Office Web Apps Server is a new Office server product that delivers browser-based versions of Word, PowerPoint, Excel, and OneNote. A single
Office Web Apps server farm can support users who access Office files through SharePoint 2013, Lync Server 2013, Exchange Server 2013,
shared folders, and websites.
After the Office Web Apps server and Lync server are integrated, internal users can start sharing PowerPoint presentations without any further
changes on the Barracuda Load Balancer ADC.
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
2010 – http://technet.microsoft.com/en-us/library/gg398833(v=ocs.14).aspx
2013 – http://technet.microsoft.com/en-us/library/gg398833.aspx
Microsoft Lync Server Documentation
2010 – http://technet.microsoft.com/en-us/library/gg398616(v=ocs.14).aspx

2013 – http://technet.microsoft.com/en-us/library/gg398616.aspx
Deploy Office Web Apps Server – http://technet.microsoft.com/en-us/library/jj219455(v=office.15).aspx
Configuring Integration with Office Web Apps Server and Lync Server 2013 – http://technet.microsoft.com/library/3370ab55-9949-4f32-b
88b-5cffed6aaad8
Terminology
Term Description
Front-End Server A Lync Server in the internal network running the Front End Lync
Services.
Edge Server A Lync Server deployed in the perimeter network running the Edge
Lync Services.
an IP address, e.g., www.example.com
Service A combination of a virtual IP (VIP) address and one or more

TCP/UDP ports on which the Barracuda Load Balancer ADC listens.
Traffic arriving over the specified port(s) to a service is directed to
one of the real servers associated with that service.
Deploying with Microsoft Lync Server
Before you deploy with Microsoft Lync Server, you must understand your deployment options. See Understanding Microsoft Lync Server
Deployment Options.
Then see How to Deploy with Microsoft Lync Server 2010 and 2013 for instructions on how to deploy with the Microsoft Lync Server.

Understanding Microsoft Lync Server Deployment Options

Requirements
This article refers to the Barracuda Load Balancer ADC and Microsoft® Lync® Server 2010 or 2013 Enterprise Edition.
For a list of prerequisites, see Microsoft Lync 2010 and 2013 Server Deployment.
In your environment, the inbound firewall must not NAT inbound traffic addressed to the Edge deployment.
Lync Server Front-End Server Deployment Options
Because 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 ADC must be deployed
using a one-armed topology in either a single or multiple subnet configuration.
Unsupported Deployment Option

Deploying internal Lync pools using a two-armed Route-Path topology, Direct Server Return (DSR) 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.
Unsupported Deployment Option

Direct Server Return deployment does not work and is not supported.
Deployment Example
The following diagram shows an example Edge deployment. You can use this example as a reference in your next step of deploying the
Barracuda Load Balancer ADC in your Lync Server environment.
Lync Deployment Example

Next Step
Deploy the Barracuda Load Balancer ADC in your Lync Server environment. For instructions, see How to Deploy with Microsoft Lync Server 2010
and 2013.

How to Deploy with Microsoft Lync Server 2010 and 2013

This article applies to the Barracuda Load Balancer ADC 5.1 and above, with
Microsoft® Lync® Server 2010 or 2013 Enterprise Edition

For Lync Mobility, Apple iPhone and iPad; Android phone; Windows Phone 7; and Nokia mobile devices
For a full list of the prerequisites for this deployment, see Microsoft Lync 2010 and 2013 Server Deployment.
Before You Begin
Print or copy the IP Worksheet and use it to record your configuration. Complete this worksheet as you perform the tasks to deploy the Microsoft
Lync Server. The worksheet will help you when you run the Topology Builder.
If you want additional information on deployment requirements and options, the following Microsoft Lync References are available:
For a list of requirements, see Microsoft Lync 2010 and 2013 Server Deployment .
For deployment options, see Understanding Microsoft Lync Server Deployment Options.
For mobility deployment details, see the Microsoft TechNet article Deploying Mobility.

Do not run the Lync Topology Builder until instructed to do so by this deployment guide. All of the services on the Barracuda Load
Balancer ADC must be configured before running the Topology Builder.
Deployment Tasks

To deploy the Barracuda Load Balancer ADC in a Lync 2010 or 2013 environment, complete the following tasks:
Deployment Task Where
Task 1. Configure Enterprise Pool Services Do this on the internal-facing Barracuda Load Balancer ADC.
If you did not collocate A/V Services on your Front End Servers, you must also do the following:
Task 2. (If applicable) Configure Internal A/V Services Do this on the A/V Pool Barracuda Load Balancer ADC.
If you have an edge deployment, you must also complete the following tasks:
Task 3. Configure Internal Edge Services Do this on the internal-facing Barracuda Load Balancer ADC.
Task 4. Configure External Edge Services Do this on the external-facing Barracuda Load Balancer ADC.
If you have deployed Director servers, you must also complete the following task:
Task 5. Configure Director Services Do this on the Director Barracuda Load Balancer ADC.
Complete the following tasks after all Services are configured on the Barracuda Load Balancer ADC:
Task 6. Run Topology Builder Do this on the server where Topology Builder is installed.
Task 7. Configure SSL Settings Do this on the internal-facing Barracuda Load Balancer ADC.
Configure Mobility Services and configure the Barracuda Load Balancer ADC as a reverse proxy:
Task 8. Configure Lync Mobility Services Do this on the internal-facing Barracuda Load Balancer ADC.
Task 9. Configure the Barracuda Load Balancer ADC as a Reverse Do this on the external-facing Barracuda Load Balancer ADC.
Proxy for Lync Mobility Services
If you encounter connectivity issues with your deployment, you can use the Remote Connectivity Analyzer:

Troubleshooting
Task 1. Configure Enterprise Pool Services
Configure all services needed for an internal Lync deployment. Perform the following steps on the internal-facing Barracuda Load Balancer ADC.
1. Go to the BASIC > Services page in the web interface.

2. Add all of the services listed in Table 1, along with their real servers. For each service, click Add Service and enter the values in the
corresponding fields. To add a real server, click Add Server and enter the IP address and port for the server.
Table 1. Enterprise Pool Services
Persistence Settings for Lync 2013

In these settings, source IP persistence is recommended. However, for Lync 2013, you can choose to use cookie persistence
instead.
Name Type IP Address Port Session Real Servers

Timeout
MTLS_Front TCP Proxy IP address for the 5061 1800 IP addresses of yo

FQDN of the ur front-end
Internal Enterprise servers
Lync Pool (K and L from the d
e.g., 192.168.1. eployment example
11/24 for frontp )
ool.domain.loc
al
DCOM_WMI_Front TCP Proxy IP address for the 135 1800 IP addresses of

FQDN of the your front-end
eployment example
)
Internal_Conf_Fron TCP Proxy IP address for the 444 1800 IP addresses of

t FQDN of the your front-end
eployment example
)
HTTPS_Front HTTPS IP address for the 443 1800 IP addresses of

FQDN of the your front-end
eployment example
)
The Barracuda Load Balancer ADC is preconfigured with default settings that work with most applications. Lync 2010 requires
changes to the Session Timeout setting for each service configured for Lync on the Barracuda Load Balancer ADC to ensure
compliance with Microsoft specifications.
3. For the DCOM_WMI_Front service only, enable TCP port monitoring for each real server associated with the service.
a. Next to each real server entry in the Configured Servers table, click Edit.
b. In the Edit Server window, scroll to the Server Monitor section and specify these settings:
Testing Method – Select TCP Port Check.
Port – Enter 5061. Testing port 5061 for this service is recommended because port 135 always passes the TCP port
check, even if Lync Services are not responding.
4. For the HTTPS_Front service only, configure cookie persistence.
a. In the service settings, scroll to the Load Balancing section.
b. Configure these settings:
Persistence Type – Select Cookie Insert or Cookie Passive.
Persistence Time – Enter 1200.
5. If you have deployed any of the features in Table 2, add the service for the feature.

5.
Table 2. Services for Optional Features

instead.
Name Type IP Address Port Session Persistence Real Servers

Timeout
Application_Sh TCP Proxy IP address for 5065 1800 Type: Source IP addresses of
aring the FQDN of IP your front-end
the Internal Time : 1200 servers
Enterprise Lync (K and L from
Pool the deployment
example)
Response_Gro TCP Proxy IP address for 5071 1800 Type: Source IP Addresses of
up_Service the FQDN of IP your front-end
Pool the deployment
example)
Conferencing_A TCP Proxy IP address for 5072 1800 Type: Source IP addresses of
ttendant the FQDN of IP your front-end
Pool the deployment
example)
Conferencing_A TCP Proxy IP address for 5073 1800 Type: Source IP addresses of
nnouncement the FQDN of IP your front-end
Pool the deployment
example)
Task 2. (If Applicable) Configure Internal A/V Services
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 Balancer ADCs operating as a high availability pair. If your
deployment has more than 10,000 A/V users, contact Barracuda Networks Technical Support for assistance.
Task 3. 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 ADC.
1. Go to the BASIC > Services page in the web Interface.

Table 3. Internal Edge Services

instead.

Service Name Type IP Address Port Session Persistence Real Servers

Timeout
MTLS_Edge TCP Proxy IP address for 5061 1800 Type: Source Internal IP
the FQDN of IP addresses of
the Time: 1200 your Edge
Internal Edge Servers
Enterprise Lync (I and J from
Pool the deployment
e.g., example)
192.168.1.12/24
for edgepool.
domain.local
AV_Auth_Edge TCP Proxy IP address for 5062 1800 Type: Source Internal IP
the FQDN of IP addresses of
Pool the deployment
example)
AV_Edge HTTPS IP address for 443 1800 Type: Cookie Internal IP

the FQDN of Insert or Cookie addresses of
the Passive your Edge
Internal Edge Time: 1200 Servers
Pool Specify the Coo the deployment
kie Name if example)
needed.
Replica_Replic HTTPS IP address for 4443 1800 Type: Cookie Internal IP

ator_Edge the FQDN of Insert or Cookie addresses of
the Passive your Edge
Internal Edge Time: 1200 Servers
Enterprise Lync Specify the Coo (I and J from
Pool kie Name if the deployment
needed. example)
Web_Conferenc TCP Proxy IP address for 8057 1800 Type: Source Internal IP
ing_Edge the FQDN of IP addresses of
Pool the deployment
example)
RDP_Media_Ed UDP Proxy IP address for 3478 1800 Type: Source Internal IP
ge the FQDN of IP addresses of
Pool the deployment
example)
Task 4. Configure External Edge Services
WAN refers to interface(s) configured to access the external network.
LAN refers to interface(s) configured to access the internal network.
Ensure that the real servers are physically connected to a switch that is connected to the LAN-facing port (for two-armed deployment) or the
WAN-facing port (for one-armed deployment) of the Barracuda Load Balancer ADC.
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 ADC.
1.


Table 4. External Edge Services

instead.

Timeout
Access_Edge One-armed:TC IP address for 443 1800 Type: Source IP address of

P Proxy the FQDN of IP Access Edge
Two-armed: Access Edge NICs on each
Layer 4 - TCP e.g., IP address Time: 1200 Edge Server
for lync.exam (C and F from
ple.com the deployment
example)
Access_Fed_E One-armed:TC IP address for 5061 1800 Type: Source IP address of

dge P Proxy the FQDN of IP Access Edge
Two-armed: Access Edge NICs on each
Layer 4 - TCP e.g., IP address Time: 1200 Edge Server
for lync.exam (C and F from
ple.com the deployment
example)
Web_Conferenc One-armed:TC IP address for 443 1800 Type: Source IP address of of

ing_Edge P Proxy the FQDN of IP your Edge
Two-armed: WebConf Edge Servers
Layer 4 - TCP e.g., IP address Time: 1200 (D and G from
for webconf.e the deployment
xample.com example)
AV_Edge One-armed:TC IP address for 443 1800 Type: Source IP address of

P Proxy the FQDN of AV IP your Edge
Two-armed: Edge Servers
Layer 4 - TCP e.g., IP address Time: 1200 (E and H from
for av.exampl the deployment
e.com example)
AV_Media_Edg One-armed: IP address for 3478 1800 default settings IP address of

e UDP Proxy the FQDN of AV your Edge
Two-armed: Edge Servers
Layer 4 - UDP e.g., IP address (E and H from
for av.exampl the deployment
e.com example)
Task 5. Configure Director Services
To configure all services needed for a load-balanced Edge Deployment of Lync Server, perform the following steps on the external-facing
Barracuda Load Balancer ADC.

In these settings for the Director Services, source IP persistence is recommended. However, for Lync 2013, you can choose to use
cookie persistence instead.

2. Add the following Directory_MTLS service with its real servers. Click Add Service and enter the values in the corresponding fields. To
add a real server, click Add Server and enter the IP address and port for the server.

2.

Timeout
Directory_MTLS TCP Proxy IP address for 5061 1800 Type: Source IP address of
the FQDN of IP your Directory
the Directory Time: 1200 Servers
Service
3. If you must support Office Communications Server prior to version 2007 R2, add the following Directory_MTLS_Legacy service. If you
only have versions of Office Communications Server that are 2007 R2 or later (including Lync), do not add this service.

Timeout
Directory_MTLS TCP Proxy IP for FQDN of 5060 1800 Type: Source IP address of
_Legacy the Directory IP your Directory
Service Time: 1200 Servers
Task 6. Run Topology Builder
After you configure all services on the Barracuda Load Balancer ADC, run LyncTopology Builder. To complete the required fields, use the
configuration information that you recorded in the IP Worksheet.
Task 7. Configure SSL Settings
Install an SSL certificate on the internal-facing Barracuda Load Balancer ADC for the HTTPS services that were configured previously. The
Barracuda Load Balancer ADC uses this certificate to decrypt the SSL traffic directed to the HTTPS services, and it checks for a persistence
cookie.
Also, you must configure back-end SSL on the real servers to re-encrypt traffic before sending it to a server in the pool.
Using the Microsoft Management Console (MMC), export a certificate along with its private key, from one of the front-end Lync servers. Ensure
the pool name is in the certificate.
Perform the following steps on the internal-facing Barracuda Load Balancer ADC for the HTTPS_Front service.
1. Go to the BASIC > Certificates page, and import the certificate.

2. Go to the BASIC > Services page and edit the service. In the Certificates section of the service settings, select the uploaded certificate.
3. Enable SSL in the settings of the real servers.
b. In the Edit Server window:
i. Scroll to the SSL section and turn on the Server uses SSL setting.
ii. Scroll to the Certificates section and select the certificate that you uploaded.
4. If you deployed Edge services on the internal-facing Barracuda Load Balancer ADC, repeat these steps for the Replica_Replicator_Edge
and AV_Edge services.
Your installation of the Barracuda Load Balancer ADC and Microsoft Lync Server is now complete. Continue to configure the Barracuda Load
Balancer ADC for Lync Mobility.
Task 8. 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
ADC.

In these settings for the Lync Mobility Services, source IP persistence is recommended. However, for Lync 2013, you can choose to
use cookie persistence instead.

2. Add the following Lync_Mobility_HTTPS service with its real servers. Click Add Service and enter the values in the corresponding fields.
To add a real server, click Add Server and enter the IP address and port for the server.
Name Type IP Address Session Certificate Persistence Real Servers

Timeout

Lync_Mobility_ HTTPS IP address for 1800 Select the Type: Cookie Internal IP
HTTPS the FQDN of certificate Insert or Cookie addresses of
the Internal assigned to the Passive front-end
Enterprise Lync Lync front-end Time: 1200 servers
pool server for Port is 4443
Port is 4443 external web Specify the Coo
services. For kie Name if
more needed.
information on
creating and
assigning the
certificate, see
Appendix A.
Certificate for
Lync Mobility
Service.
3. Edit the SSL settings for the real servers of the Lync_Mobility_HTTPS service.
b. In the Edit Server window, scroll to the SSL section.
c. Set Server Uses SSL to On.
d. Expand the settings, and set Validate Certificate to Off.
4. If you enabled Lync Mobility connections over HTTP, add the following Lync_Mobility_HTTP service.
Name Type IP Address Session Persistence Real Servers

Timeout
Lync_Mobility_HTT HTTP IP address for the 1800 default Internal IP

P FQDN of the addresses of
Internal Enterprise front-end servers
Lync pool Port is 8080
Port is 8080
Task 9. Configure the Barracuda Load Balancer ADC as a Reverse Proxy for Lync Mobility Services
A reverse proxy is required to support Lync Mobility Services, because it lets remote users access the functionality provided by Lync Web
Services. To configure the services needed to deploy the Barracuda Load Balancer ADC as a reverse proxy, perform the following steps on the
external-facing Barracuda Load Balancer ADC.

In these settings for the Lync Mobiliity Services, source IP persistence is recommended. However, for Lync 2013, you can choose to
use cookie persistence instead.

2. Add the following Lync_RP_HTTPS service with its real servers. Click Add Service and enter the values in the corresponding fields. To
add a real server, click Add Server and enter the IP address and port for the server.
Service Name Type IP Address Session Certificate Persistence Real Server

Timeout

Lync_RP_HTTP HTTPS IP address of 1800 Select the Type: Cookie VIP address of
S the FQDN of certificate Insert or Cookie the Lync
the External assigned to the Passive Mobility HTTPS
Web Services Lync front-end Time : 1200 service
Port is 443 server for Cookie Name : Port is 4443
external web MS_WSMAN
services. For
more
information on
creating and
assigning the
certificate, see
Appendix A.
Certificate for
Lync Mobility
Service.
3. Edit the SSL settings for the real servers of the Lync_RP_HTTPS service.
b. In the Edit Server window, scroll to the SSL section.
c. Set Server Uses SSL to On.
d. Expand the settings, and set Validate Certificate to Off.
4. If you enabled Lync Mobility connections over HTTP, add the following Lync_RP_HTTP service.
Service Name Type IP Address Session Persistence Real Server

Timeout
Lync_RP_HTTP HTTP IP address of the 1800 default VIP address of the

FQDN of the Lync Mobility HTTP
External Web service
Services Port is 8080
Port is 80
Troubleshooting
To troubleshoot connectivity issues by simulating different scenarios, you can use the Remote Connectivity Analyzer at:
https://testconnectivity.microsoft.com/
Appendix A. Certificate for Lync Mobility Service
Using the Lync Certificate Wizard, you can create the certificate to be assigned to the Lync Mobility Service and to the Reverse Proxy (RP)
Service. 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 ADC can be assigned the same certificate.
For more information regarding certificate requirements, refer to the Microsoft TechNet article called Certificate Summary - Reverse Proxy.
When you use the Lync Certificate Wizard to request the certificate, select the Web services external check box and assign the certificate to the
Barracuda Load Balancer ADC:
Next Step

IP Worksheet
As you perform deployment tasks, record your IP Addresses on this worksheet. It will assist you when you run the Topology Builder.
Configured Barracuda FQDN IP Address Associated Topology Notes

Load Balancer ADC Builder Step(s)
Internal-facing Barracuda Front End Pool wizard Pool FQDN

Load Balancer ADC
Internal-facing Barracuda (1) Front End Pool wizard External Base URL
Load Balancer ADC
A/V Barracuda Load Front End Pool wizard A/V Conferencing Pool
Balancer ADC (if Define the new A/V
configured) Conferencing Server
Internal-facing Barracuda New Edge Pool wizard Edge Pool FQDN

Load Balancer ADC
External-facing New Edge Pool Edge SIP Access

Barracuda Load Balancer External FQDNs
ADC
External-facing New Edge Pool Edge Web Conferencing

ADC
External-facing New Edge Pool Edge Audio/Video

ADC
Note:
(1) Usually this is the same as your pool FQDN unless your organization has also implemented SIP DNS load balancing.


This article describes how to deploy your Barracuda Load Balancer ADC version 5.1 or 5.2 with
Microsoft® Remote Access.
The Barracuda Load Balancer ADC increases the performance and reliability of Microsoft Remote Access Service (Direct Access and VPN) by
load balancing between multiple Remote Access servers.
To Deploy your Barracuda Load Balancer ADC with Microsoft's Remote Access Services, complete the following steps:
Terminology
Term Definition
Domain Controller A server that responds to security authentication requests.
Service Defined by a combination of a virtual IP (VIP) address and one or

more TCP/UDP ports that the Barracuda Load Balancer ADC listens
on. Traffic arriving over the specified ports is directed to one of the
real servers associated with that service.
TCP Proxy Makes the Barracuda Load Balancer ADC act as a full proxy.
Connections from the client are terminated at the Barracuda Load
Balancer ADC, and new connections are established between the
Barracuda Load Balancer ADC and the real servers.
an IP address (for example, www.example.com).
Network Location Server The network location server is a key component of DirectAccess. It
detects whether computers configured as DirectAccess clients are
located in the corporate network. When clients are in the corporate
network, DirectAccess is not used to reach internal resources.
Instead, clients connect to internal resources directly.
Deployment Scenario
Microsoft TechNet References
See the following Microsoft TechNet article, Plan a Remote Access Cluster Deployment, for instructions on how to set up a load balanced cluster:
https://technet.microsoft.com/en-us/library/jj134151.aspx
Prerequisites
To complete this procedure, you must have the following:
Windows Server 2012 or newer. Barracuda recommends using the latest release of Windows Server.
The Barracuda Load Balancer ADC must be connected to the web interface with its subscription activated.
If you want to deploy Remote Access Services with high availability, cluster two or more Barracuda Load Balancer ADCs. For more
Step 1. Configure the Servers
1.

1. Set up the Windows Servers that provide the Microsoft Remote Access Services with the Direct Access and VPN (Or just Direct Access
or VPN service) in a Load Balanced Cluster setup environment (see the TechNet article referenced above for instructions).
2. Barracuda recommends the Behind an edge device (with single network adapter) deployment scenario.
3. Set up the Network Location Server on a separate server that is not your Remote Access (Direct Access and VPN) Server (Microsoft
supports installing Network Location Server properties on the same server as your Remote Access server but is not recommended in a
load balanced environment).
4. Ensure that the FQDN of the Network Location Server is reachable from the internal (corporate) network from the clients you wish to
deploy this on.
5. Ensure that on all deployed client computers, Remote Access is added to the Security Group configured on Remote Access.
Add the following TCP Proxy service on the Load Balancer ADC:
Name Type IP Address Port Load Balancing Server Monitor
RemoteAccessProxy TCP Proxy VIP Address for the 443 Set Persistence Set Testing Method
FQDN of the host Type to Source IP to TCP Port Check
used by Clients to with the appropriate
Connect to the netmask
Remote Access
Server
For example:
216.46.173.5
Add your Remote Access servers to your service. For each Remote Access Server:
On the BASIC > Services page, verify that the correct service for the server is displayed

2. Enter the IP address of the server with port 443.
3. If the server is part of a cluster, specify if it is a Backup server and enter its Weight for the load balancing algorithm.
4. Click Create.
1. Log in to one of the clients configured for Remote Access while it is off the internal (corporate) network and ensure that the Workplace
Connection is in the connected state.
2. If you opted for just VPN, test the VPN connection configured on a client while it is off the internal (corporate) network and ensure that
the client is able to connect.

The Barracuda Load Balancer ADC increases the scalability and reliability of your Microsoft Office SharePoint Server 2007, 2010, or 2013
deployment. You can deploy SharePoint servers in clusters with two or more front-end servers, an SQL server, and an application server. The
Barracuda Load Balancer ADC can provide advanced Layer 7 load balancing and Layer 7 application security for your SharePoint servers.
You must have:
Barracuda Load Balancer ADC version 5.1 or above.

Microsoft® SharePoint Server 2007, 2010, or 2013.
If you want to deploy SharePoint Server with high availability, clustered your Barracuda Load Balancer ADCs. For more information, see
High Availability.
Terminology
Term Definition

TCP/UDP ports that the Barracuda Load Balancer ADC listens on.
Traffic arriving over the specified port(s) is directed to one of the real
servers associated with that service.
Instant SSL The Instant SSL Service allows clients to talk to the service using
HTTPS while the Barracuda Load Balancer ADC talks to the server
using HTTP.
In the Instant SSL service settings, you must specify one secured site
domain whose links must be converted from HTTP to HTTPS. When
the redirect service receives a request from the specified domain, it
forwards the request to the service on port 443 (HTTPS), which then
forwards the request to the servers. In any responses, the HTTPS
service rewrites the HTTP request into an HTTPS request. For
example, if you specify http://www.barracuda.com/ every
occurrence is rewritten to https://www.barracuda.com/ in
outgoing responses.
After you add the Instant SSL service, you can edit the HTTPS
service to add more domains that must be rewritten in responses.
Deployment Options
Microsoft recommends a three-tier system of deploying SharePoint servers. For instructions, see these Microsoft TechNet articles:
(SharePoint 2013) Install SharePoint 2013 across multiple servers for a three-tier farm – http://technet.microsoft.com/en-us/library/ee80
5948.aspx
(SharePoint 2010) Multiple servers for a three-tier farm – http://technet.microsoft.com/en-us/library/ee805948%28v=office.14%29.aspx
(SharePoint 2007) Install Office SharePoint Server 2007 in a server farm environment – http://technet.microsoft.com/en-us/library/cc262
901(v=office.12).aspx
Deployment Scenario

On the Barracuda Load Balancer ADC, create services which correspond to the type of traffic supported by your SharePoint servers, and
considering the desired traffic type for client access. You can use the table below to decide whether Instant SSL, HTTP, or HTTPS services are
your best option:
Deployment Scenario Service Options
The SharePoint servers support traffic over HTTP only and you want Create an HTTP service
clients to access on HTTP only.
The SharePoint servers support traffic over HTTP only and you want Create an Instant SSL service.
clients to access over HTTPS
The SharePoint servers support traffic over HTTPS only. Create an HTTPS service.
The SharePoint servers support traffic over HTTP and HTTPS. See above scenarios for HTTP and HTTPS.
Deploying SharePoint Services on the Barracuda Load Balancer ADC
To deploy the SharePoint servers with the Barracuda Load Balancer ADC, complete the following steps:

If your Barracuda Load Balancer ADCs are clustered, the active and passive unit configurations are synchronized; you only need to
configure the active Barracuda Load Balancer ADC.
Step 1. (HTTPS and Instant SSL Services) Export and Upload a SharePoint Certificate
If you are creating an HTTPS or Instant SSL service, export a certificate from your SharePoint server and upload it to the Barracuda Load
Balancer ADC.
1. Export a certificate from your SharePoint front-end server. For instructions on how to export a server certificate from your IIS server, see
the Microsoft TechNet article at http://technet.microsoft.com/en-us/library/cc731386%28v=ws.10%29.aspx.
If the SharePoint servers are not bound to a certificate, you can create a self-signed certificate. For instructions, see How to
Add an SSL Certificate.
2. Log into the Barracuda Load Balancer ADC as an administrator.

3. Go to the BASIC > Certificates page and upload the certificate from your SharePoint front-end server.
If you are importing a certificate from IIS, it is in PKCS12 format.
Enter a password for the certificate.
Step 2. Create Services for the SharePoint Servers
Add services according to the type of traffic supported by your SharePoint servers.

2. For each service that you add from Table 1, click Add Service and enter the values in the corresponding fields.
Name Type IP Address Port Caching Compression

SharePoint_HTTP HTTP IP address for the 80 Select On. Then Select On. Then
fully qualified expand the caching expand the
domain name settings, and add compression
(FQDN) that clients the types of files settings, and add
use to access that are used by these content
SharePoint your servers. types:
SharePoint_HTTP HTTPS IP address for the 443 application

S fully qualified /vnd.ms-pub
domain name lisher
(FQDN) that clients application
use to access /pdf
SharePoint application
/xml
SharePoint_Instant Instant SSL IP address for the Port: 443
SSL fully qualified
domain name HTTP Service
(FQDN) that clients Port: 80
use to access
SharePoint
3. If you have an active subscription for Application Security, enable it and configure these settings:
Security Mode – Select the Passive mode. It is recommended that you run the service in Passive mode before going active.
Security Policy – For SharePoint 2007 and 2010, select SharePoint. For SharePoint 2013, select SharePoint 2013. These
policies are predefined for all SharePoint applications. To edit these policies, go to the SECURITY > Security Policies page.
4. For Instant SSL services only, configure these settings in the SSL Settings section:
a. In the Secure Site Domain field, enter the domain name of your SharePoint server . If the internal and external domain are
different, you can use wildcard characters. For example: *.barracuda.com
b. If your Barracuda Load Balancer ADC is running version 5.1.1 and above, set the Rewrite Support option to On. For versions b
elow 5.1.1, this option is named Instant SSL.
Then enable SharePoint Rewrite Support in the settings.
Ensure that your alternate access mappings in Microsoft SharePoint are set correctly to support SSL offloading. To
configure Microsoft SharePoint, go to SharePoint Central Administration, Application Management, Configure
alternate access mappings, and ensure that the public URL for Internet Zone is set to https:// and the Internal URL
is set to http://.
5. For HTTPS and Instant SSL services only, select the Certificate that you uploaded for your SharePoint server.
Algorithm – Select Round Robin.
Persistence Type – Select Cookie Insert and then configure the cookie settings that appear. Name the cookie Persistence.
7. Click Create.
8. If you have integrated Business Connectivity Services (BCS) with your SharePoint deployment for any of the services created from Table
1, go to the Other section and set Ignore Expect Headers to Yes.
Add your SharePoint servers to your services. For each SharePoint server:
3. Enter the IP address and port of the front-end servers.
5. If traffic must be encrypted before being passed to the server, configure these settings in the SSL section:
Servers uses SSL – Select On.
Settings – Expand this section,and then select the SSL protocols to use.
If you do not enable the server to use SSL, unencrypted traffic is passed to the server because the Barracuda Load Balancer ADC
decrypts incoming traffic in order to maintain session persistence using HTTP cookies.
6. If you are adding the server to an HTTPS or Instant SSL service, select the Certificate that you uploaded for your SharePoint server.
7. In the Server Monitor section, specify the method, port, login credentials, and settings for monitoring the availability of the server.
For the Testing Method, select MS SharePoint or MS SharePoint Secure.
For Username, enter the administrator username you configured for your SharePoint site, beginning with the domain (for
example, domain\adminuser).
For Password, enter the password for the user account specified above.
For Test Target, enter your SharePoint site (for example, /sites/demo_site/).
For Test Match, enter Microsoft SharePoint.

For Additional Headers, specify the host (this should be the same host specified in your SharePoint Central Administration for
your SharePoint application).
For the Status Code, specify 200.
For the Test Delay, specify 10 seconds.
8. Click Create.
Step 4. Configure Mapping for De-encrypted Traffic to Real Servers
If traffic sent to the back-end servers changes from encrypted to unencrypted as a result of deploying the Barracuda Load Balancer ADC, you
may need to configure Alternate Access Mappings through SharePoint Central Administration.
Step 5. Change DNS and NAT for Barracuda Load Balancer ADC VIP Address
Change your internal DNS and external NATs or external DNS to point to the Barracuda Load Balancer ADC VIP address.
Next Step
You can configure an authentication server with the Barracuda Load Balancer ADC. For Microsoft SharePoint, Kerberos authentication is
supported.
For information on how to configure Kerberos authentication, see the Kerberos section of How to Integrate an External Authentication
Server
For information on how to configure your application to accept authentication from the Barracuda Load Balancer ADC, see the SharePoin
t 2007, 2010, or 2013 for Kerberos Authentication section under How to Configure Access Control (AAA)

Follow the steps in this guide to deploy the Barracuda Load Balancer ADC to increase the scalability and reliability of your Microsoft Active
Directory Federation Services (AD FS) deployment. The Barracuda Load Balancer ADC also improves the performance of AD FS by balancing
the authentication requests that are sent to your AD FS servers.
Terminology
Term Definition

the VIP is added to the service on the Barracuda Load Balancer
ADC.

Deployment Scenario
You must have:

Active Directory Federation Services ( AD FS) 2.0 or above (Windows Server 2012 R2). It is strongly recommended that you use
Windows Server 2012 R2 and AD FS 3.0.
A fully configured AD FS farm with at least two servers.
If you want to deploy AD FS with high availability, cluster your Barracuda Load Balancer ADCs. For more information, see High
Availability.
If your Barracuda Load Balancer ADCs are clustered, the configuration between the active and passive units is synchronized so you
only need to configure the active Barracuda Load Balancer ADC.
Step 1. Set Up and Deploy the AD FS Farm
Configure at least two separate servers with the AD FS service that you want to load balance. Test the login page on each AD FS server to
ensure that AD FS is working. The URL is usually something like:
https://<fqdn of adfs>/adfs/ls/IdpInitiatedSignon.aspx
For example: https://adfs-1/adfs/ls/IdpInitiatedSignon.aspx
Complete the test by logging in with an Active Directory account.
Figure 1. Default AD FS Login Page


2. Go to the BASIC > Certificates page, and create or import the required certificate. If you import a certificate, ensure that it is the same
certificate that you configured AD FS with.
3. Go to the BASIC > Services page, and create the service listed in the following table. To add a real server, click Add Server.

Timeout
ADFS_HTTPS HTTPS The VIP 443 600 Type : IP

address for the Source IP addresses
AD FS service. Time: 1200 of the AD
For example: 1 seconds FS servers
0.5.7.193 Port: 443
Enable SS
L on both
servers
Upload or
select the
certificate
you
configured
the AD FS
service
with
4. Enable Server Name Identification (SNI) by scrolling to SSL Settings and opening the Advanced Options. Enable SNI and then add
each SNI domain by clicking Add SNI Domain. Enter the domain name and the associated certificate (the same certificate you
configured AD FS with). Complete this step for each SNI domain. Client requests for domains that are not associated with any certificate
will get the default certificate.
For wild card certificates, all of the possible hostnames must be configured in SNI. Although SNI is enabled by default on the
servers, it might be necessary to enable SNI at the back-end as well.
Create an A record to point the VIP address that you set on the Barracuda Load Balancer ADC for the AD FS service.
For example, if you want to use the name sso and your domain is barracuda.com, your A record would look something like this:

Name IP Address
sso.barracuda.com 10.5.7.193
Use of DNS Name when Deploying Applications with AD FS

When you deploy applications with AD FS to provide single sign-on authentication, use the DNS name that you created in this step.
Step 4. Test your Load Balanced AD FS Setup
Go to the AD FS login page using the name that you set in the A record and verify that the page displays correctly. The URL is usually something
like:
https://<fqdn of adfs>/adfs/ls/IdpInitiatedSignon.aspx
For e xample, if you set sso as the new name, go to:
https://sso.barracuda.com/adfs/ls/IdpInitiatedSignon.aspx

Moodle Deployment
The Barracuda Load Balancer ADC increases the scalability and reliability of your Moodle deployment.
You must have:

Moodle 2.6 or earlier versions.
Terminology
Before you begin deploying the Barracuda Load Balancer ADC with Moodle, familiarize yourself with these terms:
Term Definition
Moodle Modular Object-Oriented Dynamic Learning Environment. A free

software e-learning platform or a course management system that
provides easy-to-edit, secure, and structured course web sites.
NFS Network File System. Lets machines mount a disk partition on a

remote machine as if it were a local disk. It allows for fast, seamless
sharing of files across a network.

TCP/UDP ports that the Barracuda Load Balancer ADC listens on.
Traffic arriving over the specified port(s) is directed to one of the real
servers associated with a particular service.
Instant SSL Instant SSL provides SSL (HTTPS) access to content on servers
without having to modify the servers or the content on the servers.
The Barracuda Load Balancer ADC rewrites the "http" links in the
response to "https".
Moodle Services Deployment Options
Deployments of Moodle services are supported in either a one-armed or a two-armed topology. This can be either a single or multiple subnet
configuration. Unless the users must directly access individual servers, it is recommended that you place the servers in one or more subnets that
are reachable by an internal-facing port of the Barracuda Load Balancer ADC. If users must directly access individual servers, a one-armed
deployment is recommended.
Direct Server Return (DSR) is not supported in a Moodle services deployment.
You can create either an Instant SSL or HTTP service. If you want to enforce encryption for all connections to your Moodle servers, create an
Instant SSL service. Otherwise, create an HTTP service.
The following diagram shows an example of how the Barracuda Load Balancer ADC can be deployed with Moodle services in a web farm.
Deployment Scenario

Deploy the Barracuda Load Balancer ADC for Moodle
To deploy the Barracuda Load Balancer ADC for Moodle services in a web farm, complete the following steps :
Step 1. Install Moodle in a Web Farm
Install the latest Moodle software on the back-end servers.
It is recommended that you place the database on a separate server. You can use either NFS or Samba to share the Moodle database between
the database server and the back-end servers.
You can create either an Instant SSL or HTTP service. If you want to enforce encryption for all connections to your Moodle servers, create an
Instant SSL service. Otherwise, create an HTTP service.
Create an Instant SSL Service

2. Go to the BASIC > Certificates page and create the required certificate.
4. Click Add Service and enter the values in the corresponding fields.
Name Type IP Address Port HTTP SSL Settings Certificates Load

Service Port Balancing

Moodle_Insta Instant SSL The IP 443 80 Secure Select the Persiste

ntSSL address of Site certificate nce
the FQDN Domain that you Type –
that clients – Enter uploaded for Select S
use to the the service. ource IP
access. domain .
name of Persiste
For example, your nce
10.5.7.205. Moodle Netmas
server. If k–
the Enter: 2
internal 55.255
and .255.2
external 55
domain
are
different,
you can
use
wildcard
characte
rs. For
example:
*.barr
acuda.
com
If your
Barracud
a Load
Balancer
ADC is
running
version 5
.1.1 and
above,
set the R
ewrite
Support
option to
On. For
versions
below
5.1.1,
this
option is
named I
nstant
SSL.
5. Click Add Server to configure the real servers. In the server settings, ensure that you:
Enter the IP addresses of the back-end servers. For example, 192.168.17.197 and 192.168.17.199.
Use port 80.
If traffic must be encrypted when it is passed to the real servers, enable Server uses SSL. Otherwise, non-encrypted traffic is
passed to the real servers because the Barracuda Load Balancer ADC decrypts the incoming traffic.
6. If the Moodle server uses compression, configure the web translations. By default, the Barracuda Load Balancer ADC does not
decompress encoded content. If the Moodle servers use compression, create an HTTP Request Rewrite condition to remove the
Accept-Encoding header.
a. Go to the TRAFFIC > Web Translations page.
b. In the HTTP Request Rewrite section, create the following rule:
Rule Name Sequence Action Header Name Old Value Rewrite

Number Condition
Remove_Encodin 2 Remove Header Accept-Encoding * *

g

Create an HTTP Service

3. Click Add Service and enter the values in the corresponding fields.
Name Type IP Address Port Load Balancing
Moodle_HTTP HTTP The IP address of the 80 Persistence Type

FQDN that clients use – Select Source IP
to access. .
Persistence
Netmask – Enter:
255.255.255.25
5
4. Click Add Server to configure the real servers. In the server settings, ensure that you:
Enter the IP addresses of the back-end servers. For example, 192.168.17.197 and 192.168.17.199.
Use port 80.


This article describes how to deploy your Barracuda Load Balancer ADC version 5.1, 5.2, 5.3, 5.4, and
6.0 with Microsoft® Remote Desktop Services.
The Barracuda Load Balancer ADC increases the performance and reliability of Microsoft Remote Desktop Services by load balancing between
multiple terminal servers. It can also maintain session persistence by honoring the routing tokens provided by the Connection Broker, allowing a
client that disconnects from an active session on a terminal server to reconnect from another location and resume its session.
Terminology
Term Definition
Domain Controller A server that responds to security authentication requests.
Remote Desktop Connection Broker A component of Remote Desktop Services. Maintains a list of active
and disconnected sessions so that a disconnected user is
transparently redirected and reconnected to the server.
The Connection Broker (also known as the Session Broker) can be

configured to load balance remote desktop sessions. However, this
guide describes load balancing provided by the Barracuda Load
Balancer ADC.
Remote Desktop Gateway Reformats information from one network so that it's compatible with
another network.
Remote Desktop Services Known as Terminal Services in Windows Server 2003 and Windows
Server 2008. This component of Microsoft Windows lets users
remotely access applications and data.
Remote Desktop Session Host The terminal server that runs the applications for the Remote
Desktop users.
Remote Desktop Web Access Creates a web interface for clients to easily access applications and
desktop environments hosted on the session host.
Routing Token Redirects users to their existing sessions on the correct terminal
server.
Service A service is defined by a combination of a virtual IP (VIP) address

and one or more TCP/UDP ports that the Barracuda Load Balancer
ADC listens on. Traffic arriving over the specified ports is directed to
one of the real servers associated with that service.
Microsoft TechNet References
For Windows Server 2008 R1:
TS Session Broker Load Balancing Step-by-Step Guide
For Windows Server 2008 R2:
Remote Desktop Connection Broker

About IP Address and Token Redirection
For Windows Server 2012:
Configuring RDS for 2012
Remote Desktop Services Deployment Options
Deployments of Remote Desktop Services are supported in either a one-armed or a two-armed topology, with either a single or multiple subnet
configuration. Unless users must directly access individual servers, it is recommended that the servers be placed in one or more subnets that are

reachable by an internal-facing port of the Barracuda Load Balancer ADC. If clients must directly access individual servers, a one-armed
deployment is recommended.
Direct Server Return (DSR) is not supported in a Remote Desktop Services deployment.
Deployment Scenario
Prerequisites
To complete this procedure, you must have the following:
Windows Server 2008 R2 or newer. Barracuda recommends using the latest release of Windows Server.
The Barracuda Load Balancer ADC must be connected to the web interface with its subscription activated.
If you want to deploy Remote Desktop Services with high availability, cluster two or more Barracuda Load Balancer ADCs. For more
Step 1. Configure the Servers
1. Setup the servers that provide the Remote Desktop Services.

2. Configure the Remote Desktop (RD) Session Host, RD Web Access (optional), and RD gateway (optional) on at least 2 servers so they
can be load balanced.
3. If you deploy an RD Licensing Server, ensure that it is properly configured and operational.
4. Install and configure the necessary certificates for each role on each server.
5. If you deploy an RD Gateway, configure the gateway server name (under deployment properties). The gateway server name is tied to
the FQDN. The FQDN is tied to the DNS entry you create for the VIP.
6. When you have deployed a Session or Connection Broker, you must also complete the steps listed in this article: Remote Desktop
Services Configuration When the Session or Connection Broker Is Deployed.
Add the Remote Desktop Service on the active Barracuda Load Balancer ADC (you can load balance any of these services):
1. Go to the BASIC > Certificates page, and create or upload a certificate for the service.
3. To add a Remote Desktop services (RDP, RDWeb and RD Gateway), click Add Service.
If you are load balancing Remote Desktop Session Hosts, configure the RDP Session Host services as follows:
Table 1. RDP Session Host Services
Name Type IP Address Port Session Load Server

RDP TCP Proxy VIP address 3389 1800 Persisten Testing

for the FQDN ce Type: Method: RDP
of your Source IP Test
Remote
Desktop Ensure that
Service your session
host servers
For example: do not require
10.5.7.193 NLA (Network
Level
Authentication)
clients
If you are load balancing Remote Desktop Session Hosts with a Connection Broker, configure the RDP Session Host services
as follows:

Table 2. RDP Session Hosts with a Connection Broker

RDP RDP Proxy VIP address 3389 1800 N/A Testing

for the FQDN Method: RDP
of your Test
Remote
Desktop Ensure that
host servers
Level
Authentication)
clients
On the Remote Desktop Session Hosts, enable token redirection.
If you are load balancing Remote Desktop Session Hosts and Remote Desktop Gateway Servers with a Connection Broker,
configure the RDP Session Host services as follows:
Table 3. RDP Session Hosts and RD Gateway Servers with a Connection Broker

RDP RDP Proxy VIP address 3389 1800 N/A Testing

for the FQDN Method: RDP
of your Test
Remote
Desktop Ensure that
host servers
Level
Authentication)
clients
If you are load balancing only Remote Desktop Gateway Server(s) with a Connection Broker 2008R2, configure the Remote
Desktop Gateway Services as follows:
Table 4. RD Gateway Services with a Connection Broker 2008R2


RD_GATEWA HTTPS or VIP address 443 1800 Persisten Testing

Y_RDWeb Instant SSL for the FQDN ce Type: Method: Simp
of your RD HTTP le HTTPS
Gateway Header
For example: Header Test Target: /r
10.5.7.193 Name: Au dweb/Pages/e
thorization n-US/login.asp
x?ReturnUrl=/
Persisten
RDWeb/Pages
ce Time:
/en-US/Default
1200
.aspx
Additional
Headers: User
-Agent:
Barracuda
Load Balancer
ADC Server
Monitor
Status Code:
200
Test Delay: 3
0 seconds
HTTP
Method: HEA
D
If you are load balancing only Remote Desktop Gateway Server(s) with a Connection Broker 2012R2, configure the Remote
Desktop Gateway Services as follows:
Table 5. RD Gateway Servers with a Connection Broker 2012R2

RD_GATEWA HTTPS, VIP address 443 (HTTPS) 1800 Service Testing

Y_RDWeb Instant SSL, or for the FQDN 3391 (UDP Groups Method: Simp
UDP Proxy of your RD Proxy) Persisten le HTTPS
Gateway ce Type:
For example: Source IP Test Target: /r
10.5.7.193 Persisten dweb/Pages/e
ce Time: n-US/login.asp
1200 x?ReturnUrl=/
RDWeb/Pages
/en-US/Default
.aspx
Additional
Headers: User
-Agent:
Barracuda
Load Balancer
ADC Server
Monitor
Status Code:
200
Test Delay: 3
0 seconds
HTTP
Method: HEA
D
If you are load balancing both Remote Desktop Session Hosts and Remote Desktop Gateway Server(s) with a Connection

Broker 2008R2, configure the RDP and Remote Desktop Gateway Services as follows:
Table 6. RDP and RD Gateway Services with a Connection Broker 2008R2

RDP RDP Proxy VIP address 3389 1800 Persisten Testing

Remote Persisten
Desktop Ensure that
ce Time:
1200
host servers
Level
Authentication)
clients
RD_GATEWA HTTPS or VIP address 443 1800 Persisten Testing

Y_RDWeb Instant SSL for the FQDN ce Type: Method: Simp
of your RD HTTP le HTTPS
Gateway For Header
example: Header Test Target: /r
10.5.7.193 Name: Au dweb/Pages/e
x?ReturnUrl=/
Persisten
RDWeb/Pages
ce Time:
/en-US/Default
1200
.aspx
Additional
Headers: User
-Agent:
Barracuda
Load Balancer
ADC Server
Monitor
Status Code:
200
Test Delay: 3
0 seconds
HTTP
Method: HEA
D
On the BASIC > Services page for the RD_GATEWAY_RDWeb service, configure the following:
i. SSL Settings section (only for Instant SSL service type):

Secure Site Domain - Enter the domain name of your Remote Desktop Services server. If the internal and
external domain are different, you can use wildcard characters. For example: *.barracuda.com.
If your Barracuda Load Balancer ADC is running version 5.1.1 and above, set the Rewrite Support option to O
ff. For versions below 5.1.1, this option is named Instant SSL.
ii. Certificates section:
Select the certificate that was uploaded for the service.
If you are load balancing both Remote Desktop Session Hosts and Remote Desktop Gateway Server(s) with a Connection
Broker 2012R2, configure the RDP and Remote Desktop Gateway Services as follows:
Table 7. RDP Session Hosts and RD Gateway Services with a Connection Broker 2012R2


RDP RDP Proxy VIP address 3389 1800 Persisten Testing

Remote Persisten
Desktop Ensure that
ce Time :
1200
host servers
Level
Authentication)
clients
RD_GATEWA HTTPS, VIP address 443 (HTTPS) 1800 Service Testing

Y_RDWeb Instant SSL, or for the FQDN 3391 (UDP Group Method
UDP Proxy of your RD Proxy) Persisten (HTTPS): Sim
Gateway For ce Type: ple HTTPS
example: Source IP
10.5.7.193 Header Test Target: /r
Name: Au dweb/Pages/e
x?ReturnUrl=/
Persisten
RDWeb/Pages
ce Time :
/en-US/Default
1200
.aspx
Additional
Headers: User
-Agent:
Barracuda
Load Balancer
ADC Server
Monitor
Status Code:
200
Test Delay: 3
0 seconds
HTTP
Method: HEA
D
On the BASIC > Services page for the RD_GATEWAY_RDWeb service, configure the following:
a. SSL Settings section (only for Instant SSL service type):
Secure Site Domain - Enter the domain name of your Remote Desktop Services server. If the internal and
external domain are different, you can use wildcard characters. For example: *.barracuda.com.
If your Barracuda Load Balancer ADC is running version 5.1.1 and above, set the Rewrite Support option to O
ff. For versions below 5.1.1, this option is named Instant SSL.
b. Certificates section:
Add your Remote Desktop servers to your services. For each Remote Desktop server:
On the BASIC > Services page, verify that the correct service for the server is displayed.

If you are adding the Session Host server to an RDP service, use Port 3389
If you are adding the Web or Gateway server to an RD_GATEWAY_RDWeb service, use Port 443.
4. If you are adding the server to an RD_GATEWAY_RDWeb service, enable SSL.
Set Server uses SSL to On. If you do not enable the server to use SSL, unencrypted traffic is passed to the server because the
Barracuda Load Balancer ADC decrypts incoming traffic to maintain session persistence using HTTP cookies.
5. Click Create.

Create an A record to point the VIP address that you set on the Barracuda Load Balancer ADC for the Remote Desktop Service.
For example, if you want to use the name rdp and your domain is barracuda.com, your A record would appears as follows:
Name IP Address
rdp.barracuda.com 10.5.7.193
Step 5. Configure an HTTP Request Rewrite Rule (Optional)
To simplify access to the Remote Desktop Web Services site for your users, you may configure a rewrite rule to automatically add /rdweb to the
end of the URL

2. From the Service list, select the RD_GATEWAY_RDWeb service you configured for RDWeb Access
3. In the HTTP Request Rewrite section, click on Add Rule and enter the values in the corresponding fields.
Rule Name Sequence Action Old Value Rewrite Value Rewrite

Number Condition
RDWeb 3 Redirect URL / /rdweb *
4. Click Save.
1. Create two test users that have permission to log into Remote Desktop Services (for example, testuser1 and testuser2).
2. Using Remote Desktop Connection, connect testuser1 to the Virtual IP Address. Open Notepad and enter some text; do not close
Notepad.
3. Click Start > Disconnect.
4. Connect testuser2 to the same Virtual IP Address.
5. Once testuser2 is logged in, click Start > Disconnect.
6. Log in testuser1 again and ensure it reconnects to the session with Notepad open.
7. Log in testuser2 again and ensure the session reconnects to the testuser2 session.
8. If you have RD Web Access configured, verify that it is working by navigating to the FQDN that you set in the A record in Step 4 and
verify that the page displays correctly.
Example: https://rdp.barracuda.com/rdweb without the redirect rule, or rdp.barracuda.com with the instant ssl service and
redirect rule configured.

Remote Desktop Services Configuration When the Session or Connection Broker Is

Deployed
This article describes how to configure Remote Desktop Services to work with the Barracuda Load Balancer ADC.
Step 1: Configure the Session or Connection Broker with Remote Desktop Services
The Session Broker provides a mechanism for a disconnected user to be reconnected to the server that has its disconnected session. Installing
the 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 the Session Broker with Remote Desktop Services in Windows; if you choose not to
deploy the 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.
For Windows Server 2008 R1 or R2, complete the installation and configuration described below on the Session Broker server to ensure
that its settings are correctly configured.
Install the Session Broker role service on a server by completing the following steps:
a. Navigate to Start > Server Manager.

b. Under Server Manager (Server Name), click Roles.
c. Under Roles Summary, click Add Roles.
d. On the Select Server Roles page, turn on Remote Desktop Services and click Next.
e. On the Select Role Services page, select Remote Desktop Connection Broker.
f. Complete the Add Roles Wizard.
Set up a Session Brokerage privileges list to tell the Session Broker which computers are authorized to be brokered; complete the
procedures that correspond with your environment.
If the Session Broker is located on a server that is also a domain controller, complete the following steps:
a. Navigate to Start > Administrative Tools > Active Directory Users and Computers.
b. Expand your domain and select Users (although this is a group, it is still listed under Users).
c. Double-click the group Session Broker Computers to view its properties.
d. 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. If you do not, the Session Broker is denied RPC privileges.
If the Session Broker is not on a server that is also a domain controller, complete the following steps:
a. Navigate to Start > Server Manager.

b. Expand Configuration and click Local Users and Groups.
c. Click Groups. Double-click the group Session Broker Computers to view its properties.
d. 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. If you do not, the Session Broker is denied RPC privileges.
For more information about Remote Desktop Services in Windows Server 2012 or 2012 R2, refer to the Windows 2012 RDS Deployment
Overview in the Load Balancing Microsoft Remote Desktop Services Deployment Guide.
Step 2: Configure the Remote Desktop Session Host Server
For Remote Desktop Services in Windows Server 2008 R1 or R2, complete the following steps on all Remote Desktop Session Host
servers:
a. Navigate to Start > Administrative Tools > Remote Desktop Services > Remote Desktop Session Host Configuration.
b. On the main screen, near the bottom of the center pane, double-click Member of farm in RD Connection Broker.
c. Click the RD Connection Broker tab.
d. Deselect the Participate in Connection Broker Load-Balancing check box.
e. In the RD Connection Broker field, type the FQDN for the Real Server that is running Session Broker.
f. In the Farm name field, enter a farm name. You must use the same farm name on every Remote Desktop Session Host.
g. Select Use Token Redirection from the drop-down list.
h. Select the checkbox of the IPv4 address corresponding with your Real Server.
For Remote Desktop Services in Windows Server 2012 or 2012 R2, use either a Group Policy Object that applies to all Remote Desktop
Session Host servers or configure each server individually using local group policy:
a. Navigate to Computer Configuration > Administrative Templates > Windows Components > Remote Desktop Services >
Remote Desktop Session Host > RD Connection Broker
b.

b. Disable both Use IP Address Redirection and Use RD Connection Broker load balancing
When you have completed these procedures, return to Remote Desktop Services Deployment (Including Remote Desktop Gateway).

VMware Horizon View provides end users with access to their machines and applications through a unified workspace across multiple devices,
locations, and connections. The Horizon View Connection Server authenticates and then directs incoming user requests to the appropriate View
desktop.
The Barracuda Load Balancer ADC increases the performance, scalability, and reliability of VMware Horizon View. It distributes traffic among the
Horizon View Connection Servers in your deployment for better load distribution and monitors the health of each server.
You must have:
Barracuda Load Balancer ADC version 5.4 and above.

Personal Computer over Internet Protocol (PCoIP).
VMware ® Horizon View™ version 5.x.
If you want VMware Horizon View Servers with high availability, deploy the Barracuda Load Balancer ADCs in a clustered environment.
For more information, see High Availability.
A signed certificate to deploy the Barracuda Load Balancer ADC in a VMware Horizon View environment. Barracuda recommends that
you have a signed certificate authority (CA) certificate. If you already have a signed CA certificate, you can continue with configuring the
VMware Horizon View service on the Barracuda Load Balancer ADC. If you want to create a self-signed certificate, see Create a
Self-Signed Certificate for instructions.
Deployment Scenario
Deploying VMware Horizon View Services on the Barracuda Load Balancer ADC
Step 1. Import the Certificate to the Horizon View Connection Server
If you have not already installed the signed certificate on your Horizon View Connection servers, follow these steps to install the signed certificate
on every server:
1. Install the certificate on the Horizon View Connection Server.

2. Set Friendly Name to vdm for the installed certificate.
3. On the Horizon View Connection server, right-click My Computer and select Manage > Service and Applications > Services.
4. Select VMware Horizon View Connection Server Service, and click Restart to restart the service. Wait a few minutes for the Horizon V
iew Connection server to start listening.
5. On the Horizon View Connection Server, in the command window, type netstat -anp TCP and check the output to verify that the Hor
izon View Connection server is listening on port 443 for the Horizon View Connection service.

Reference: http://pubs.vmware.com/view-51/topic/com.vmware.view.installation.doc/GUID-80CC770D-327E-4A21-B382-786621B23C44.html in
the VMware View 5.1 Documentation Center.
Step 2. Install the Certificate on the Barracuda Load Balancer ADC
Install a copy of the signed certificate on the Barracuda Load Balancer ADC.
1. Create a copy of the signed certificate.

2. Log into the Barracuda Load Balancer ADC.
3. Go to the BASIC > Certificates page, and upload the certificate.
Step 3. Configure the VMware Horizon View Services on the Barracuda Load Balancer ADC
Configure the monitor group, the service group, and configure the services according to the type of traffic required by your VMware Horizon View
servers.
1. Go to the Traffic > Monitor Groups page and configure a new monitor group:
a. Group Name: Specify the service group name.
b. Monitor Name: Specify the name for the service monitor group.
c. Testing Method: Specify the testing methods (you can specify more that one testing method for the monitor group). See the
online help for documentation on how to configure these testing methods. See also the example shown in this article.
2. Go to the BASIC > Services page, click Add Service and specify the group name in the Group field in the Service Configuration secti
on.
3. For each service, enter the appropriate values in the corresponding fields of the Service Configuration section:
Services† Type IP Address Port Session Certificates Server Monitor

Timeout

VDI_HTTPS† HTTPS IP address of 443 1800 Select the Testing

the FQDN that certificate that Method: Si
clients use to you uploaded mple
access the View for the service. HTTPS
server. HTTP
Method: H
For example:
EAD
216.106.13.45
Test
Target: /
Additional
Headers:
User-Agent
: Barracuda
Load
Balancer
ADC
Server
Monitor
Status
Code: 200
Test
Delay: 30
Seconds
VDI_PCoIP UDP Proxy IP address of 4172 300 N/A Testing

(Optional, used the FQDN that Method: U
for VDI over clients use to DP Port
PCoIP † ) access the View Check
server.
For example:
216.106.13.45
VDI_PCoIP_TC TCP Proxy IP address of 4172 1800 N/A Testing

PProxy (Option the FQDN that Method: T
al, used for VDI clients use to CP Port
over PCoIP † ) access the View Check
server.
For example:
216.106.13.45
VDI_Blast (Opti Secure TCP IP address of 8443 1800 Select the Testing
onal) Proxy the FQDN that certificate that Method: T
clients use to you uploaded CP Port
access the View for the service. Check
server.
For example:
216.106.13.45
†(For versions greater than 5.4) If you are configuring VDI over PCoIP, the HTTPS Service, TCP Proxy Service (on Port 4172), UDP
Proxy Service (on Port 4172), and Blast Service (on port 8443) must all be under the same Service-Group. You must enable Source-IP
Persistence at this Service-Group level.
4. Under the Load Balancing section for the above services, configure the following:
For Persistence Type, select Source IP.
For Persistence Time, enter 1200.
For Persistence Netmask, enter 255.255.255.255.
5. Service Group Persistence ensures that a client's connection to a server is maintained even if the client switches to a difference service,
so long as that service is included in the Service Group and the same server is configured for both services. After the Persistence Time
has expired, the client can be switched to a different server the next time it attempts to switch to a different service.
a. To enable Source IP Persistence for the Service Group, go to the BASIC > Services page and select the Service Group in the
left pane.
b. On the Service Groups page, set the Persistence drop down menu to Source IP. Specify a Persistence Netmask and a Pers
istence Time in seconds.
If you enable Service Group Persistence, the Persistence settings (on the BASIC > Services page) you configure for

the services affected are ignored.
6. Go to the BASIC > Services page and scroll to the Server Monitor section. In the Testing Method drop down menu, scroll to the end of
the list to view the Monitor Groups. Select the new monitor group from this list.
7. For VDI_HTTPS service, under Other section, set the Enable VDI to Yes.
8. Click Create.
9. Click Add Server to add a back-end servers. In the server settings:
a. Enter the IP address of the Horizon View Connection server. For example: 192.168.17.197
b. Enter the corresponding ports for the servers, port 443 for VDI_HTTPS, port 4172 for VDI_PCoIP and VDI_PCoIP_TCPProxy
and port 8443 for VDI_Blast services.
c. In the SSL section for VDI_HTTPS and VDI_Blast services, set Server uses S SL to Yes.
d. If the certificate for the service is a self-signed or a test certificate, set Validate Certificate to Off. If the service is using a
CA-signed certificate, select On .
10. Click Create.
11. (in firmware release 5.4 and earlier) Go to Advanced > System Configuration page, under Advanced Settings section, set Show
Advanced Settings to Yes and then go to Advanced section, set Enable Persistence for VDI to Yes.
The following example illustrates how to enable service group monitoring to ensure source IP persistence for the service group. It includes four
services configured on the ADC, sharing the same two servers.
1. Create a service group for the following services.
Service Name Service Type IP Address Server Names Server IP Addresses
S1 HTTPS 10.1.1.1:443 R1 10.2.2.1:443
R2 10.2.2.2:443
S2 TCP Proxy 10.1.1.2:4172 R1 10.2.2.1:4172
R2 10.2.2.2:4172
S3 UDP Proxy 10.1.1.3:4172 R1 10.2.2.1:4172
R2 10.2.2.2:4172
S4 Secure TCP Proxy 10.1.1.4:8443 R1 10.2.2.1:8443
R2 10.2.2.2:8443
2. Go to the BASIC > Services page for each service and specify the group name as GM_Service in the Group field in the Service
Configuration section.
3. Go to Traffic > Monitor Groups page and configure a new monitor group for the service group:
a. Group Name: Specify the service group name as GM_Service.
b. Monitor Name: Specify the name for the service monitor group as GM_Example.
c. Testing Method: Specify Simple HTTPS, TCP Port Check, and UDP Port Check as the testing methods as shown below:
Monitor Testing Port Test Target Test Match Additional Status Test Delay
Name Method Headers Code
M1 Simple 443 / VMware User-Agent: 200 30

HTTPS Barracuda
Load
M2 TCP Port 4172 - - - - 10

Check
M3 UDP Port 4172 - - - - 10

Check
M4 TCP Port 8443 - - - - 10

Check
4. Go to the BASIC > Services page and scroll to the Server Monitor section. In the Testing Method drop down menu, scroll to the end of
the list to view the Monitor Groups. Select the GM_Example monitor group.
5. To enable Source IP Service Group Persistence, go to the BASIC > Services page and select the GM_Service service group in the left
pane.
a. Set the Persistence drop down menu to Source IP.
b. Specify the Persistence Netmask as 255.255.255.255
c.

c. Specify the Persistence Time as 1200. Click Save Changes.
Create an A record to point the VIP address that you set on the Barracuda Load Balancer ADC for the VMware Horizon View service.
For example, if you want to use the name vip and your domain is localserver.com, your A record would look something like this:
Name IP Address
vip.localserver.com 216.106.13.45
If you have both internal and external clients accessing the VMware service through the Barracuda Load Balancer ADC, you can configure two
different VIP addresses and two services—one service to direct the traffic to VMware Horizon View Security Servers, and another service to
direct traffic to the VMware Horizon View Connection Servers.
Step 5. Set up the Horizon View Connection Server (Not for SSL offloading)
Configure the Horizon View Connection Server for HTTPS Secure Tunnel, PCoIP Secure Gateway and Blast Secure Gateway services:
1. Log into the View Administrator Console, expand View Configuration, and click Servers.
2. In the right pane, click the Connection Servers tab. All configured View Connection servers display in the table.
3. Configure HTTPS only for the VMware Horizon View Connection server:
a. Select the server, and click Edit. The Edit Connection Server Settings window appears.
b. In the HTTP(S) Secure Tunnel section, select the Use Secure Tunnel connection to machine check box.
c. In the External URL field, enter the a URL with FQDN of the VDI service. For example: https://<FQDN>:443
4. (Optional) Configure HTTPS and PCoIP for the VMware Horizon View Connection server. As described earlier, be sure to have the
following services within the same Service-Group:Select the server, and click Edit . The Edit Connection Server Settings window
appears.
a. In the HTTP(S) Secure Tunnel section, select the Use Secure Tunnel connection to machine check box.
b. In the External URL field, enter the a URL with FQDN of the VDI service. For example: https://<FQDN>:443
c. In the PCoIP Secure Gateway section, select the Use PCoIP Secure Gateway for PCoIP connections to machine check
box.
d. In the PCoIP External URL field, enter the a PCoIP IP address and port 4172. For example: 216.106.13.45:4172

d.
5. (Optional) Configure HTTPS, PCoIP, and a Blast Secure Gateway for the VMware Horizon View Connection server.
As described earlier, you must have the following services in the same Service-Group, with Source-IP Persistence enabled at that group
level: HTTPS Service, TCP Proxy Service (on Port 4172), UDP Proxy Service (on Port 4172).
a. Select the server, and click Edit. The Edit Connection Server Settings window appears.
b. In the HTTP(S) Secure Tunnel section, select the Use Secure Tunnel connection to machine check box.
c. In the External URL field, enter the a URL with FQDN of the VDI service. For example: https://vdi.tchlib.com:443
d. In the PCoIP Secure Gateway section, select the Use PCoIP Secure Gateway for PCoIP connections to machine check
box.
e. In the PCoIP External URL field, enter the a PCoIP IP address and port 4172. For example: 216.106.13.45:4172
f. In the Blast Secure Gateway section, select the Use Blast Secure Gateway for HTML access to machine check box.
g. In the Blast External URL field, enter the a Blast external URL with port 8443. For example: https://vdi.techlib.com:8443
Note that clients coming from behind a NAT cannot use VDI Servers over PCoIP. These clients must use VDI Service over

HTTPS.
6. Click OK to save your changes.
Step 6. Verify that the VMware Horizon View Connection Service is Reachable
Verify that you can access the VMware Horizon View Connection service through the VIP address. If you cannot access the service through the
VIP address, see Troubleshooting.
Troubleshooting
Issue Solution
You received a server certificate warning. The installed certificate is not from a Certification Authority. You can
ignore the warning.

You received a warning or error message for server authentication The certificate on the Barracuda Load Balancer ADC and the Horizon
and cannot launch the snapshot. View Connection server do not match. A copy of the certificate from
the View Horizon Connection server was not installed on the
As a workaround, on the VMware Horizon View Client:
1. Go to Options > Configure SSL.

2. Select Do not verify server identity certificates and click OK.
You received a server authentication failed error, even though the Verify that the CN parameter of the installed certificate matches the
same certificate is installed on the Barracuda Load Balancer ADC FQDN of the service.
and the Horizon View Connection servers.
You received an error message that states, "Invalid Certificate The issuing authority for the certificate installed for the service is not
received from server." 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.
You received a message that the user is not authenticated even You did not enable persistence for the VMware Horizon View service
though the username and password are correct. on the Barracuda Load Balancer ADC.
You want to restart the VMware Horizon View Connection Server 1. On the Horizon View Connection Server, right-click My
service. Computer and go to Manage > Service and Applications >
Services.
2. Select VMware Horizon View Connection Server Service, and
click Start to restart the service. Wait a few minutes for the Horiz
on View Connection Server to start listening.
(Optional) Create a Self-Signed Certificate
If you do not have a signed certificate, you can use the following steps to create a self-signed certificate.

2. Go to the BASIC > Certificates page.
3.

3. In the Certificate Generation section, click Create Certificate

4. Enter the Certificate Name. For example: VMware View
5. Enter the Organization Info details:
a. In the Common Name field, enter the fully qualified domain name (FQDN) which resolves to the VIP address for the VMware Ho
rizon View service. For example: viewvip.localserver.com
b. Enter the Country Code, State or Province, Locality, Organization (Company) Name, and Organization (Departmental)
Unit for your organization.
c. From the Key Size list, select 2048.
d. In the Expires In field, enter the number of days that you want the generated certificate to be valid.
e. Set Allow Private Key Export to Yes.
6. Click Generate Certificate at the top of the section. The certificate is added to the Saved Certificates table in the Created
Certificates section.
7. In the Download column, click Certificate. The Save Token page appears.
8. Enter a password in the Encryption Password field.
9. Click Save. The certificate, including the private key, is exported as a PKCS12 token in a file named <certificate name>.pfx.
10. Click Close Window to return to the Certificates page.

Services
A service is a combination of a virtual IP (VIP) address and one or more TCP/UDP ports. Traffic arriving at the designated ports for the specified
VIP address is directed to one of the real servers that are associated with that particular service. The Barracuda Load Balancer ADC determines
which connections or requests are distributed to each real server based on the load balancing settings that are configured for the service.
Service Types
You can configure the following types of services:
Layer 4 TCP and Layer 4 UDP

TCP Proxy, Secure TCP Proxy, and UDP Proxy
HTTP Service and HTTPS Service
Instant SSL Service
FTP and FTP SSL Service
Layer 7 RDP
Configuring Services and Servers
For information on configuring services and their real servers, see the following articles:
How to Create a Service

Persistence Settings
How to Configure Service Groups and Service Group Persistence
SSL Offloading
How to Enable HTTP/2
How to Secure Communication with Real Servers
How to Select a Scheduling Policy
How to Configure Adaptive Scheduling

How to Create a Service
After you have determined your network configuration and installed your Barracuda Load Balancer ADC, you can start configuring your services.
Create a service by assigning a virtual IP (VIP) address and port to it, and adding one or more real servers to handle traffic that arrives at the VIP
address. You can also configure load balancing to specify how traffic is distributed to the real servers.
Step 1. Create the Service
To add a service:

2. Click Add Service.
3. In the Add Service window, specify values for the settings in the Service Configuration section. Enter a name and group, select the
service type, enter the VIP address and port, and select an interface for the service.
For Instant SSL services, also enter a port to receive HTTP traffic.
For HTTP and HTTPS services, you can also configure caching, compression, access logs, application security, a security
policy, and the web firewall log level.
4. In the Load Balancing section, select the algorithm for distributing traffic to the real servers for the service. To dynamically distribute
traffic based on server loads, you can use adaptive scheduling. For some service types, you can also select a persistence and failover
method.
5. Depending on your service type and requirements, you can also configure the following sections:
FTP Passive Configuration – (Only for FTP and FTP SSL services) Settings for passive FTP.
SSL Settings – (For secure service types) Encryption between the client and the service.
Certificates – (For secure service types) The certificate that is presented by the service when authenticating itself to a browser
or some other client.
Server Monitor – Health checks for the real servers. For more information on the testing methods for health checks, see Unders
tanding Testing Methods for Services and Real Servers.
Notifications – Alerts to notify you if the minimum number of operating real servers for this service is not available.
Other – (List of settings in this section varies for each service type) Additional settings such as the HTTP header name to use in
logs, whether to consider letter case in URLs when processing rules, keepalive probes, and a limit on keepalive requests.
6. After you finish configuring the service, click Create. The service appears in the left pane of the page.
Step 2. Add Real Servers for the Service
To add a real server for the service:
1. In the Configured Servers section above the service settings, click Add Server.
2. In the Add Server window, specify values for the settings in the Server Configuration section. Enter a name, IP address, and port for
the server.
For Layer 4 services, you can enable Direct Server Return.
For Layer 7 services, except Layer 7 - RDP, you can configure advanced options such as client impersonation and connection
pooling.
3. In the Server Monitor section, configure health checks for the real servers. For more information on the testing methods for health
checks, see Understanding Testing Methods for Services and Real Servers.
4. Depending on your service type and requirements, you can also configure the following sections:
SSL Settings – (For secure service types) Encryption between the service and server.
Certificates – (For secure service types) The certificate that is presented by the server when the service requires client
authentication.
5. After you finish configuring the server, click Create. The server appears in the Configured Servers table above the service settings.

Persistence Settings
The Barracuda Load Balancer ADC supports multiple options to direct clients back to the same Real Server, depending on the Service type. You
can also modify the persistence configuration globally for all services.
For information about how to configure persistence for service groups, see How to Configure Service Groups and Service Group
Persistence.
Global Persistence Setting
You can configure persistence globally for all services configured on the Barracuda Load Balancer ADC. Go to Advanced > System
Configuration. Under Global Settings, there is an option called Disable Maintenance Persistence. When Disable Maintenance Persistence i
s set to Yes, new connections from the persistent clients are not forwarded to the maintenance server. Also, new connections from the persistent
clients are not forwarded to the backup server when the main server is available for load balancing.
The default setting for Disable Maintenance Persistence is No. When a real server is in maintenance mode for a Layer 4 service, the Barracuda
Load Balancer ADC continues to forward new connections to the real server from persistent clients within the specified persistent timeout period.
The following examples illustrate how the Barracuda Load Balancer ADC behaves when Disable Maintenance Persistence is set to No:
Example 1
For example, you have configured a Layer 4 service called S1, set the persistent timeout period to 240 seconds, and have configured two servers
for the service, R1 and R2. A client makes a connection (Conn1) to service S1. The Barracuda Load Balancer ADC links connection Conn1 to
server R1. The administrator then puts server R1 in maintenance mode. New requests going through Conn1 continue to use server R1.
If Client C1 makes a new connection Conn2 to service S1 within the specified persistent timeout period (240 seconds), the Barracuda Load
Balancer ADC links this connection (Conn2) to server R1 only.
Example 2
The following example shows how the Barracuda Load Balancer ADC will behave when using the default setting for Disable Maintenance
Persistence (No) and a server failure occurs.
You have configured a Layer 4 service called S1, set the persistent timeout period to 240 seconds, and have configured two servers for the
service, R1 (main server) and R2 (backup server). A client makes a connection (Conn1) to service S1. The Barracuda Load Balancer ADC links
connection Conn1 to server R1. If real server R1 experiences a failure or is disabled by the administrator, the Barracuda Load Balancer ADC sets
the weight of real server R2 to 1.
If Client C1 then attempts to connect to real server R1, the Barracuda Load Balancer ADC forwards the connection (Conn1) to server R2. If real
server R1 comes back online, the Barracuda Load Balancer ADC changes real server R2's weight to 0. Real server R2 continues to receive data
on connection Conn1 from client C1. By default (Disable Maintenance Persistence is set to No) new connections from Client C1 are also
forwarded to R2.
HTTP/HTTPS
There are a variety of supported persistence methods for HTTP/HTTPS sessions:
Cookie Insert – Routes the first request from a client to one of the servers based on the load balancing algorithm. At the same time, it
inserts a cookie to identify the client. Subsequent requests from the client include the persistence cookie, so they can be routed to the
same server as the first request was.
Cookie Passive – Similar to Cookie Insert, only the server inserts the cookie if needed. This provides additional optimization because
requests are load-balanced normally unless there is a requirement to persist a session, which is indicated by the presence of a cookie.
Source 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, Layer 4 – UDP, FTP or FTP SSL
Only Source IP Address persistence is supported. An individual source 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 Source IP Address and Client IP 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 - 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.

How to Configure Service Groups and Service Group Persistence
You can assign a service to a service group by navigating to the BASIC > Services page, selecting the service in the left pane, and entering the
name of the Service Group in the Group field in the Service Configuration section. If you assign multiple services to the same Service Group
and those services share the same set of servers, you can also configure Persistence for the Service Group. Persistence helps to ensure an
uninterrupted connection between a client and a server being load balanced behind the Barracuda Load Balancer ADC.
Be aware of the following when configuring service groups:
By default, new services are created under the default service group.
You can name the service group while creating a service by specifying a string on the right with the Group field on the Add Service pag
e.
You can move the services from one group to another by changing the Name of the Group field on Edit service.
To enable Service Group Persistence, set Persistence to Source IP and assign a Persistence Netmask and a Persistence Time in seconds.
With Service Group Persistence enabled, a client's connection to a server is maintained even if the client switches to a different service, so long
as that service is included in the Service Group and the Server is configured for both services. After the Persistence Time has expired, the client
can be switched to a different server the next time it attempts to switch to a different service.
If you configure service group persistence, service level persistence is ignored.
Barracuda recommends that you configure all of the services specified under a service group with the same Server Monitor Testing Method (for
service group persistence). To accomplish this, configure a Monitor Group (TRAFFIC > Monitor Groups) with all of the testing methods needed.
And then configure the new Monitor Group for each service (BASIC > Services, go to the Server Monitor section, open the Testing Method dro
p down menu, and scroll to the bottom for the Monitor Groups).

Layer 4 TCP and Layer 4 UDP
Layer 4 load balancing of TCP or UDP traffic. You can deploy these services in either a one-armed configuration or a two-armed configuration:
One-Armed Using a TCP or UDP Virtual Service - Enable Direct Server Return on each of the servers. See Direct Server Return
deployment.
Two-Armed with Layer 4 Load Balancing - The default gateway for the server should be directed to the LAN IP address, the interface IP
address for the Barracuda Load Balancer ADC where the server is located.

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 ADC 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 ADC. See Deployment for examples of deployments using TCP and UDP Proxy Services. A Secure TCP Proxy Service
provides SSL Offloading.

HTTP Service and HTTPS Service
This article includes the following topics:
Introduction
Direct HTTP Requests Based on Content Rules
Content Rule Execution
Content Rule Caching and Compression
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 ADC 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 source IP based
persistence. This requires a two-armed deployment.
If you only need source 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 HTTP (for HTTP traffic) or HTTPS (for HTTPS traffic).
The rest of this section describes the processing options.
Direct HTTP Requests Based on Content Rules
Content rules are used to direct HTTP requests to specific Real Servers associated with a HTTP/HTTPS 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, Cookie Insert, Cookie Passive, HTTP Header, URL Parameter or Source 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 HTTP/HTTPS 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 Edit 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 www.example.com, URL /images/*

Rule B - host www.example.com, URL /images/*.png
and if the incoming request is for www.example.com/images/x.png 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.
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 TRAFFIC > HTTP Caching and the TRAFFIC >
HTTP Compression pages.
Modify HTTP Requests and Responses
You can set up rules to modify HTTP requests and responses that pass through the Barracuda Load Balancer ADC. These rules, which are
associated with a HTTP/HTTPS Service, are listed on the TRAFFIC > Web Translations 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 ADC.
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 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 TRAFFIC > Web Translations 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 TRAFFIC > Web Translations 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 HTTP/HTTPS Service or content rule on the TRAFFIC > 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 slow methods. Enabling this feature 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 HTTP/HTTPS Service or content rule on the TRAFFIC > 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
ADC 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:

Wildcard certificates
Subject Alternative Name (SAN) certificates

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 ADC to assign any number and any type of certificates (single, wildcard or SAN) to a single
Barracuda Load Balancer ADC Service. SNI support applies only to Services with type HTTPS and Instant SSL.
To enable SNI, complete the following steps:
1. Go to the BASIC > Services page and edit the HTTPS or Instant SSL Service.
2. Scroll to SSL Settings and Show the Advanced Options.
3. Scroll to Server Name Identification and enable SNI.
4. Click Add SNI Domain and enter a domain name it's associated certificate. Complete this step for each SNI domain. 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 ADC to serve multiple sub-domains. For example,
you can configure a single HTTP/HTTPS Service using a wildcard certificate, such as *.example.com, for https://sales.example.com or https://
support.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 www.mysite1.com and www.mysite2.com. 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 www.mysite1.com and www.mysite1.net.
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 www.example.com could have the domains www.examples.net and www.ex.com 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.

Instant SSL Service
Product Version
This article applies to the Barracuda Load Balancer ADC version 5.1 and above.
The Instant SSL Service allows clients to talk to the service using HTTPS while the Barracuda Load Balancer ADC talks to the server using
HTTP.
In the Instant SSL service settings, you must specify at least one secured site domain whose links must be converted from HTTP to HTTPS. Whe
n the redirect service receives a request for the specified domain, it forwards the request to the service on port 443 (HTTPS), which then forwards
the request to the servers. In any response, the HTTPS service rewrites HTTP requests to HTTPS requests. For example, an incoming request
for http://www.barracuda.com/ is rewritten as https://www.barracuda.com/ in the outgoing response.
The service also provides an additional rewrite option named SharePoint Rewrite Support for Microsoft® SharePoint applications. Normally, an
Instant SSL Service rewrites the HTTP links in responses to HTTPS using HTML tags, like href. However, SharePoint applications also insert
hyperlinks outside the basic HTML tags. You can enable SharePoint Rewrite Support to ensure that HTTP links outside HTML tags are also
properly rewritten to HTTPS.

FTP and FTP SSL Service
FTP Service
Create an FTP Service to enable the Barracuda Load Balancer ADC to process FTP traffic from clients to servers. An FTP client connects to an
FTP server typically to either upload or download files to that server. Both passive and active FTP are supported.
If passive FTP is used, and if the Barracuda Load Balancer ADC is behind a firewall performing NAT, 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(s)
are those allowed by the firewall. Enter the IP address and port(s) on the Add Service popup window.
FTP SSL Service
Create an FTP SSL Service to enable the Barracuda Load Balancer ADC to process encrypted FTP traffic from clients to servers. Only passive
FTP is supported, not active FTP.

Layer 7 RDP
For Layer 7 Remote Desktop Protocol (RDP), the TS Session Broker maintains a list of active and disconnected sessions and the Barracuda
Load Balancer ADC directs traffic accordingly. RDP is a Microsoft protocol used to connect to a remote computer over the network using a
graphical user interface. When you enable client IP impersonation for a server, configure the default gateway on the server to the IP address for
the interface on the Barracuda Load Balancer ADC.
The following deployment options are available for the Layer 7 RDP service:


SSL Offloading
Product Version
The Barracuda Load Balancer ADC can decrypt incoming SSL traffic to reduce the load on the real servers. Traffic coming from the real servers
is also encrypted and sent to the client. No SSL configuration on the real servers is necessary; all SSL certificates are stored on the Barracuda
Load Balancer ADC.
Web applications and any TCP application using a TCP Proxy service type can take advantage of SSL offloading. SSL offloading is not
compatible with Direct Server Return.
You can configure SSL offloading when creating or editing any secure service type (e.g., Secure TCP Proxy, HTTPS). To configure SSL
offloading, configure the real servers for the service to use port 80 and disable SSL.
1. Go to the BASIC > Certificates page and ensure that a certificate has been uploaded to the Barracuda Load Balancer ADC for the
service. Upload one SSL certificate for each service. A certificate can be ordered from a trusted Certificate Authority such as VeriSign. If
SSL processing was previously done on the server, then retrieve the certificate from that server.
2. Go to the BASIC > Services page and either create or edit the secure service with its real servers:
a. In the SSL Settings section of the service settings, ensure that the SSL certificate has been selected.
b. In the settings of the servers that you add for the service, use Port 80 and set Server Uses SSL to No.

How to Enable HTTP/2
Hypertext Transfer Protocol Version 2 (HTTP/2) is an upgraded version of HTTP/1.1. HTTP/2 uses network resources more efficiently and
reduces latency by introducing header field compression and allowing multiple concurrent exchanges on the same connection. It also introduces
unsolicited push of representations from servers to clients. The goal of HTTP/2 is to improve page load times and the overall user experience. For
more information about HTTP/2, refer to RFC 7540[1].
The Barracuda Load Balancer ADC supports HTTP/2 between client and server. When HTTP/2 is enabled for a service, the Barracuda Load
Balancer ADC and the client use HTTP/2 to communicate with each other.
How does the Barracuda Load Balancer ADC work when HTTP/2 is enabled for a Service:
1. The client sends an HTTP/2 request.

2. The Barracuda Load Balancer ADC recognizes the HTTP/2 protocol and parses HTTP/2 frames as they arrive.
3. The Barracuda Load Balancer ADC coverts the HTTP/2 request to an HTTP/1.1 request.
4. The HTTP/1.1 request is passed through the Barracuda Load Balancer ADC security modules for inspection and sanitation.
5. After performing security validations, the HTTP/1.1 request is sent to the back-end server. The back-end server responds to the request.
6. The Barracuda Load Balancer ADC converts the response into HTTP/2 formatted frames and forwards it to the client.
Head-of-Line Blocking
The Barracuda Load Balancer ADC allows clients to establish multiple HTTP/2 streams. When these streams are received, they are separated
out into individual HTTP/1.1 requests and sent to the backend server using connection pooling. Since the Barracuda Load Balancer ADC
recognizes that the client is HTTP/2 capable, it does not block the client if any of the backend HTTP/1.1 requests is incomplete. Instead, it
gathers the responses from the completed HTTP/1.1 requests and streams them out to the client after converting them to HTTP/2 streams.
Each of the HTTP/2 stream corresponding to a HTTP request can also be load balanced by the Barracuda Load Balancer ADC , and sent to the
back-end servers in parallel, assuming persistence settings allow such distribution.
Enabling HTTP/2 for a Service
It is recommended that you enable HTTP/2 for a service if there are numerous clients using the service that also support HTTP/2 and would
benefit from the improved user experience and page loading performance.
Perform the following steps to enable HTTP/2 for a service on a Barracuda Load Balancer ADC:

2. In the Services section, select the service on which you want to enable HTTP/2.
3. Navigate to SSL Settings and set Enable HTTP2 to Yes.
4. Click Save.

How to Secure Communication with Real Servers
If you want all communication between the Barracuda Load Balancer ADC and the real servers to be encrypted using SSL, you can configure this
on a per-server basis. This is also known as back-end SSL.
To configure the Barracuda Load Balancer ADC to encrypt the data sent to a server:
1. Copy the certificate from each server, and upload the certificate to the BASIC > Certificates page as a back-end certificate.
2. On the BASIC > Services page, edit each real server for the secure service and specify that the server uses SSL by navigating to the S
SL section and setting Server uses SSL to On.
You can optionally configure the following SSL settings for each real server:
SSL Protocols - The SSL protocols used by the service to connect to the server. Servers must support OpenSSL version 1.0.1
or higher to work with TLS v1.1 or TLS v1.2.
Enable SNI - Some servers require a hostname extension in the SSL handshake for the connection to be accepted. Enable this
option if your server requires a hostname extension. The hostname is picked from the host header in the incoming HTTP
request.
Validate Certificate - Requires the server certificate to be validated using certificates from well-known Certificate Authorities. If
set to No, any certificate from the server is accepted, including self-signed or test certificates.
SSL Error Logs - Set to On to help troubleshoot the SSL handshake problems in detail. These logs are displayed with the
system logs and can be viewed from the ADVANCED > System Logs page.
3. In the Certificates section, select the certificate that you uploaded. If necessary, change the port used by the real server.

How to Select a Scheduling Policy
The Barracuda Load Balancer ADC 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 ADC 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.
A URL provided by each Real Server which specifies a load value. If this option is selected, the Barracuda Load Balancer ADC will poll
the URL http://[Real 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 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 ADC 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 Server Configuration 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 ADC 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 ADC 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 ADC 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 >
Services page.
Scheduling for a Service with type Layer 7 - RDP
If the Service type is Layer 7 - RDP, the Barracuda Load Balancer ADC 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 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.

How to Configure Adaptive Scheduling
The Barracuda Load Balancer ADC provides a method for dynamic weighting based on the load of each Real Server called Adaptive Scheduling.
When enabled, the Barracuda Load Balancer ADC polls the Real Servers frequently and assigns weights to those Real Servers using the
information gathered.
To configure adaptive scheduling for the Barracuda Load Balancer ADC, go to the BASIC > Services page, navigate to the Load Balancing sect
ion, and open Advanced Options.
None
By default, Adaptive Scheduling is disabled.
SNMP CPU
This scheduling method polls the Simple Network Management Protocol (SNMP) Object Identifier (OID) for the CPU load and manipulates the
Real Server weights accordingly. Weights are assigned to each Real Server by assigning a weight based on the formula (100 Load). For
example, if the CPU load is 23, the result from the formula is 77 (100-23). 77 corresponds to a weight of 9, which is assigned as the weight of the
Real Server.
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 1.3.6.1.4.1.2021.10.1.3.1 and for Windows is
1.3.6.1.4.1.9600.1.1.5.1.5.1.48, but you can customize these by editing the Service.
Additionally, the Real Servers must:
Allow access using the community name specified in the SNMP Community String field on the Service Detail page. Note: The Real
Servers must use a community string of public.
Make SNMP available on standard SNMP port 161.
Allow SNMP read access by the corresponding custom virtual interface IP address of the Barracuda Load Balancer ADC.
Microsoft 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.
SNMP on Linux
If you have Linux servers, make sure that you have an SNMP agent installed and running. Barracuda Networks recommends using 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 ADC polls the URL http://[Re
al Server IP Address]/loadpage where loadpage is the directory or page name specified in the Load URL field. The result from the
poll should is returned in the format LOAD=Integer (showing the load as an integer between 0 and 100).
For the URL request to work, each Real Server must be running a web server that responds to the poll on port 80 and the Real Server’s IP
address.
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:
Allow access using the community name specified in the SNMP Community String field on the Service Detail page.
Make SNMP available on standard SNMP port 161.
Allow SNMP read access by the corresponding custom virtual interface IP address of the Barracuda Load Balancer ADC.
Testing the Adaptive Scheduling Settings

When you click Test, the value shown is derived from the Load value specified for each Real Server. You can determine the load value set for
the server by subtracting the value show here by 100.

The following example helps to illustrate the values assigned to your configured servers when you click Test for the Adaptive Scheduling config
uration:
1. 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.
2. You need to specify a load value on each of the servers. You configure this value in a file called index.html located on each server. The
file is located in the /var/www/barracuda_load/ folder.
For this example, the index.html file on Server4 would have the following value specified:
LOAD = 50
Each of the other servers must include an index.html file with a Load value. For this example, configure the following loads for each of
the servers:
Server1: 20
Server2: 20
Server3: 80
Server4: 50
3. For the HTTP service configuration, navigate to Advanced Options and set Adaptive Scheduling to Load URL and set the Load
Threshold to 35.
4. 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
Server4 50
5. You can calculate the load for each Server by subtracting the value generated by the Test function from 100.
Server Calculated Weight
Server1 Server 1 is unreachable for polling. Its weight is not calculated

and is set to 100.
Server2 100 - 80 = 20
Server3 100 - 20 = 80
Server4 100 - 50 = 50
These values match the weights configured in Step 2 except for Server1 which is unreachable.
6. The following table lists the weight assigned to servers based on the above calculation:
Formula Result Weight
85-100 10
75-84 9
65-74 8
55-64 7
45-54 6
35-44 5
25-34 4
15-24 3
5-14 2
0-4 1
7. The following table shows the weight assigned to each of the servers in this example based on the previous calculations:
Server Weight Reason
Server1 100 Server 1 is unreachable.

Server2 100 Load for Server2 is 20. 20 < 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 80. 80 > Load

Threshold. The weight for Server3 is set
to 3 (formula result is 20).
Server4 6 Load for Server 4 is 50. 50 > 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.

Access Control
Feature Availability
This article applies to the Barracuda Load Balancer ADC 540 and above, version 5.1 and above, and to
all Barracuda Load Balancer ADC models in version 5.2 and above.
On the Barracuda Load Balancer ADC 340 and above, you can integrate external authentication servers and configure authorization policies to
control the access of end users to your web applications. LDAP, RADIUS, and Kerberos authentication protocols are supported.
Overview of Access Control

Configuring Access Control
Overview of Access Control
To access resources from an application, end users must:
1. Provide a username and password for validation by an authentication server that has been integrated for the service of the application.
2. Have access privileges from an authorization policy that has been configured for the service of the application.
After users submit their initial request to the application, they must complete and submit a login form with a valid username and password. The
Barracuda Load Balancer ADC compares the submitted information with information from the external authentication server. If two-factor
authentication is configured, users are also redirected to a challenge page to enter the additional credentials (e.g., PIN or passcode). Users who f
ail authentication are redirected to a page that notifies them that they have failed authentication. Successfully authenticated users receive a
cookie and are redirected to a page that notifies them that they have been authenticated.
Any requests from authenticated users must then be allowed by an authorization policy. When the Barracuda Load Balancer ADC receives a
request, it compares the request to all authorization policies. Policies are matched to requests by URL, host, and other expressions. Policies also
contain lists of allowed and restricted users and groups. If a matching policy lets the user access the requested resource, the Barracuda Load
Balancer ADC forwards the request to the application server. If a matching policy does not allow the user to access the requested resource, the
user is redirected to a denied authorization page.
Configuring Access Control
For instructions on configuring access control and options such as single sign-on, custom login pages, and two-factor client authentication with
SMS PASSCODE®, see these articles:
How to Integrate an External Authentication Server

How to Configure Access Control (AAA)
How to Configure Single Sign-On (SSO)
How to Set Up a Custom Login Page for Authentication
How to Configure SMS Passcode Authentication Service
How to Set Up a Custom Challenge Page for Authentication

How to Integrate an External Authentication Server
Required Product Model and Version

Create an authentication service to connect with and get user information from your existing external authentication server. LDAP, RADIUS, and
Kerberos authentication protocols are supported.
LDAP
Lightweight Directory Access Protocol (LDAP) is used for storing and managing distributed information services in a network. LDAP is mainly
used to provide a single sign-on solution. It follows the same X.500 directory structure as MSAD.
To add an LDAP authentication service, identify a user who can query the LDAP directory, and specify the parameters for looking up information
about users.
To use LDAP authentication with IBM Domino, see the "Application-Specific Instructions" section of How to Configure Access Control
(AAA).
1. Go to the ACCESS CONTROL > Authentication Services page, and click the LDAP tab.
2. In the settings, specify the following:
Alias for the server
IP address, port, and connection type for connecting to the LDAP server
Bind DN, bind password, and login attribute for a user who has read access to all users in the LDAP directory
Attributes and filters used to look up and authenticate end users
3. Click Test LDAP to verify that a connection can be established with the LDAP server. The test results display at the bottom of the page.
If the test fails, re-enter and re-test the LDAP settings.
4. Click LDAP Discovery to verify that users can be found with the attributes and filters that you entered. If you want to view detailed query
results, select the Verbose check box. In the test results:
Green dot is displayed next to verified information.
Red dot is displayed next to information that must be corrected.
If any information is incorrect or missing, edit the field and click LDAP Discovery.
5. After your settings have been validated, click Add. The LDAP service appears in the Existing Authentication Services section.
You can now assign the LDAP service to a web service and configure an authorization policy. For instructions, see How to Configure Access
Control (AAA).
RADIUS
Remote Access Dial In User Service (RADIUS) is a networking protocol which provides authentication, authorization, and accounting.
To add a RADIUS authentication service, specify the shared key that is used by the Barracuda Load Balancer ADC and RADIUS server to verify
each other's identity. Also set a limit to how long the Barracuda Load Balancer ADC waits for a response from the RADIUS server and a limit on
the number of times that it can send a request packet.
You can also add a secondary RADIUS server for authenticating users. If the primary RADIUS server fails, the secondary RADIUS server takes
over as the primary RADIUS server for authenticating users.
To integrate the Barracuda Load Balancer ADC with a RADIUS authentication server:
1. Go to the ACCESS CONTROL > Authentication Services page, and click the RADIUS tab.
2. In the settings, specify:
An alias for the RADIUS server.
The IP address, port, and secret key for the RADIUS server.
The maximum Timeout and Retries for sending packets to the RADIUS server.
3. Click Add . The new RADIUS service appears in the Existing Authentication Services section.
4. If you want to configure a secondary RADIUS server:
a. Click Add next to the RADIUS authentication service for which you want to add the secondary server.
b. In the Add Secondary Radius Server window, enter the IP address and port of the secondary RADIUS server. All settings for
the secondary RADIUS server, except for the IP address and port, must be identical to the settings used for the primary RADIUS
server.
c. Click Add.
You can now assign the RADIUS service to a web service and configure an authorization policy. For instructions, see How to Configure Access
Control (AAA).

Kerberos
Kerberos is the native authentication method used by Windows 2000 and later Microsoft Windows platforms. Kerberos provides mutual
authentication (meaning both the user and the server verify each other's identity). It uses a trusted third party known as the Key Distribution
Center (KDC). The KDC must be a part of the Windows Domain Controller Active Directory.
The KDC provides two services:
Authentication Service (AS) that authenticates a user

Ticket Granting Service (TGS) that issues a session ticket to a client.
Kerberos relies on Service Principal Names (SPNs) to uniquely identify an instance of a service (which runs on a host) by a client. When you add
a Kerberos authentication service, you must also configure an SPN for your web service. The SPN must be registered in Active Directory. SPNs
can be formatted as follows:
<service type>/<instance/host name>

<service type>/<instance/host name>:<port number>/<service name>
The port and service name are optional. The port is only required when a non-default service type is used.
If you have multiple servers configured for a service, verify that a single SPN is registered in Active Directory for the service. For example, if you
have a service for web1.domain.com with two servers that are configured for load balancing, create an SPN for web1.domain.com and
register the SPN in Active Directory under the user. Both servers must provide required permissions for the user.
Requirements for Kerberos
Before continuing with the procedure for integrating Kerberos, verify that the following requirements are met:
Barracuda Load Balancer ADC has proper DNS servers configured

DNS IP address configured in the BASIC > IP Configuration > DNS Configuration section must be reachable by the Active Directory
domain (the domain where the KDC is installed)
All host machine clocks are synchronized to within 5 minutes of the Kerberos server clock
Step. 1 Add the Kerberos Server
To integrate the Barracuda Load Balancer ADC with a Kerberos server:
1. Go to the ACCESS CONTROL > Authentication Services page, and click the Kerberos tab.
2. In the settings, specify:
Alias for the server
KDC realm name
IP address or name and the port for the Kerberos server.
3. Click Add.
Step 2. Create a New User in Active Directory
1. In the Active Directory Users and Computers window, click Users > New > User.

2. In the New Object - User window, specify the name and login credentials for the user.
3. Click Next, specify values for other fields as required, and click Finish.
Step 3. Create the SPN for the User
Set the SPN under the user account that you just created in Active Directory. Open a command prompt, and execute the setspn command. The

SPN can be any name. In the following example, the SPN is HTTP/krbspn.barracuda.com:
Step 4. Create a DNS Entry for your SPN
Add the following entries to the DNS server in the domain:
Host A record for the SPN that you created (point the record to one of the servers that you configured for the service)
Reverse PTR record pointing to same name and server.

How to Configure Access Control (AAA)

After you integrate an external authentication server, you can associate it with a service to authenticate end users of a web application. LDAP,
RADIUS, and Kerberos authentication protocols are supported.
You can create authorization policies to allow or deny requests from authenticated users. In the policies, specify the URL, host, and other
expressions which match the requests to be handled, as well as a list of allowed and restricted users.
General Steps on Configuring Access Control
If instructions on configuring access control specifically for your application are not available, follow the instructions in this section.
Before You Begin
Create an authentication service for the LDAP, RADIUS, or Kerberos authentication server that you want to integrate with the Barracuda Load
Balancer ADC.
For instructions, see How to Integrate an External Authentication Server.
Step 1. Assign the Authentication Service to a Web Service
Assign the authentication service to the service for your website.
1. Go to the ACCESS CONTROL > Authentication page.

2. Next to the service, click Edit.
3. In the Edit Authentication Policy section:
a. Set the Status to On.
b. From the Authentication Service list, select the alias of the server for authenticating users of the service.
Password Reset Page for LDAP
When LDAP is selected as an authentication database server, the Auth Password Expired URL field is displayed. In
this field, specify the URL where users are redirected if their authentication fails because their passwords expired.
Users are redirected to reset their passwords. This feature only is supported when the authentication database is
Microsoft Active Directory-LDAP. The expired password on the OpenLDAP server is not detected by the Barracuda
Load Balancer ADC.
c. (Optional) Dual Authentication Required - Set to Yes to apply a dual authentication policy (requiring two separate
authentication services where the primary authentication service should be LDAP and the secondary should be RADIUS) to
authenticate the user. If you set this to Yes, you will also need to specify a RADIUS service as the Secondary Authentication
Service (this list includes all of the RADIUS authentication services configured on the ACCESS CONTROL > Authentication
Services page).
This option is available only when the LDAP authentication service is selected as the primary authentication service.
d. (Optional) Enable Bruteforce Prevention - Set to Yes to prevent unauthorized users from making repeated attempts to guess a
password. If you enable Bruteforce Prevention, you can also configure the following options:
Count Window - The time (in seconds) for allowing the maximum number of requests as specified using the Max
Failed Attempts Allowed Per IP option.
Max Failed Attempts Allowed Per IP - The maximum number of attempts allowed to enter a password from the client
tied to an IP address.
e. Specify the remaining settings.
Kerberos SPN
If you are assigning a Kerberos authentication service, ensure that you enter the Kerberos SPN.
4. Click Save.
In the Authentication Policies section, the name of the authentication service is displayed in the row for the service.
Step 2. Configure an Authorization Policy for the Service

Configure an authorization policy to control the access of authenticated users to your website. You can configure access by user, group or by
both. In the policy, specify the URL, host, and extended match patterns for requests that must be handled by the policy.
1. Go to the ACCESS CONTROL > Authorization page.

2. In the Add Authorization Policy section:
a. From the Service list, select the service that you are configuring the authorization policy for.
b. Enter a name for the policy.
c. Set the Status to On.
When you set the status to On, a user accessing the URL has to authenticate. When you set the status to Off, the
URL is exempt from the authorization policy. By default, a policy for /nclogin.submit is created and set to Off, because
you cannot request authentication from the login page.
d. Specify the URL, host, and other expressions that must match requests.
e. Specify the Login Method. If you want to create a custom login or challenge page, select HTML Form.
If you are using a custom challenge page, it does not support the HTTP Basic Authentication login method.
3. Click Add. The authorization policy appears in the Existing Authorization Policies section.
4. Next to the policy, click Edit.
5. In the Edit Authorization Policy window, specify if you want to allow or deny the request to all authenticated users or only to specific
users and groups.
6. Click Save .
Application-Specific Instructions for Configuring Access Control
Complete the instructions for your application on how to configure access control:
SharePoint 2007, 2010, or 2013 for Kerberos Authentication

Step 1. Configure Kerberos Authentication on the Barracuda Load Balancer ADC
Ensure that you have already configured the Kerberos Authentication service. For instructions, see How to Integrate an External
Authentication Server .
Step 2. Configure your SharePoint Servers
1. Navigate to your SharePoint Web Admin Site > Web Applications > Authentication Providers.
2. Select the Enable Windows Authentication check box.
3. Select the Integrated Windows authentication check box and then select Negotiate (Kerberos).

Step 3. Assign Kerberos Authentication Service to the SharePoint Service

3. In the Edit Authentication Policy section:
b. From the Authentication Service list, select the alias of the Kerberos service you created in Step 1.
4. Click Save.
Step 4. Configure an Authorization Policy for the SharePoint Service
Configure an authorization policy to control the access of authenticated users to your SharePoint Application. You can configure access by
user, group, or both user and group. In the policy, specify the URL, host, and extended match patterns for requests that must be handled by
the policy.

2. In the Add Authorization Policy section, click Add. The authorization policy appears in the Existing Authorization Policies sectio
n.
a. From the Service list, select the SharePoint service.
4. In the Edit Authorization Policy window, specify if you want to allow or deny the request to all authenticated users or only to
specific users and groups.
5. Set Send Basic Authentication to On.
6.

6. Click Save.
Step 5. Verify your Setup
1. Navigate to your SharePoint site via the FQDN of your VIP address.
2. After the Barracuda Load Balancer ADC authentication page loads, enter the user credentials of a user account that has access to
the SharePoint Application.
Exchange 2013 with LDAP Authentication

Step 1. Configure LDAP Authentication on the Barracuda Load Balancer ADC
Ensure that you have already configured the LDAP authentication service. For instructions, see How to Integrate an External Authentication
Server .
Step 2. Configure your Exchange 2013 Servers
1. Navigate to the Exchange Control Panel at https://<fqdn of CAS>/ecp.

2. Click Servers > Virtual Directories.
3. Click the first OWA page for one of the servers and click the edit icon.
4. Click authentication.
5. Click Use one or more standard authentication methods, and then select the Integrated Windows Authentication and Basic
Authentication check boxes.
6. Repeat steps 1 to 5 for the other OWA site on the other CAS as well as the ECP pages on your other CAS.
7. Go back to SERVERS > SERVERS, and edit one of the CAS.
8.

8. Click Outlook Anywhere.
9. Verify the internal and external host name settings and then click Allow SSL Offloading.
10. Repeat for the other CAS.
11. Next, open the Exchange Management Shell on your CAS and run the following commands.
Get-OutlookAnywhere -Server <ServerName> -ADPropertiesOnly |
Set-OutlookAnywhere -InternalClientAuthenticationMethod Basic
-IISAuthenticationMethods Basic, Ntlm
12. Reset the IIS to ensure that the changes are applied.

Step 3. Assign LDAP Authentication Service to the Exchange 2013 Service

3. In the Edit Authentication Policy section, click Save.
b. From the Authentication Service list, select the alias of the LDAP service you created in Step 1.
c. (Optional) S pecify the URL where users are redirected if their authentication fails because their passwords expired in the A
uth Password Expired URL. Users are redirected to reset their passwords.
Step 4. Configure an Authorization Policy for the Exchange 2013 Service
Configure an authorization policy to control the access of authenticated users to your Exchange OWA. You can configure access by user
and/or group. In the policy, specify the URL, host, and extended match patterns for requests that must be handled by the policy.

2. In the Add Authorization Policy section:Click Add. The authorization policy appears in the Existing Authorization Policies sectio
n.
a. From the Service list, select the Exchange 2013 service.
If you specify "/* " as the URL match, add the following Authorization Policies with the specified URL match and
set the Status to Off:
/Microsoft-Server-ActiveSync*
/rpc/rpcproxy.dll
/autodiscover/autodiscover.xml
As an alternative to setting /* as the URL match and adding the other "Off" policies, you can specify policies for
individual pages you want users to authenicate on before accessing the server, such as the OWA (Outlook Web
Access) or ECP (Exchange Control Panel) pages.
You can create the following Authorization Policies with the Status set to On:
/owa*
/ecp*
a. Set Send Basic Authentication to On.
5. Click Save .
1.

1. Go to: https://<FQDN of your Exchange 2013 VIP Address>/owa

2. After the Barracuda Load Balancer ADC authentication page loads, enter the user credentials of a user account that
has access to OWA.
Exchange 2010 with LDAP or Kerberos Authentication
Step 1. Configure LDAP or Kerberos Authentication on the Barracuda Load Balancer ADC
Ensure that you have already configured the LDAP or Kerberos authentication service. For instructions, see How to Integrate an External
Authentication Server .
Step 2. Configure your Exchange 2010 Servers
1. Open the Internet Information Services (IIS) Manager.

2. In the left pane, find and select the site that you are modifying.
3. In Features View for the selected site, double-click Authentication.
4. On the Authentications page, select Windows Authentication.

5. In the Actions pane, click Enable to use Windows authentication. The status for Windows Authentication then changes to Enabled.

6. Open the Exchange Management Console.
7. In the console tree, locate the virtual directory that you want to use Integrated Windows authentication.
8. Select Server Configuration and then select Client Access.
9. For each server hosting the Outlook Web App virtual directory:
a. Select the server and click the Outlook Web App tab.

b. In the work pane, select the virtual directory that you want to configure to use Integrated Windows authentication, and click
Properties in the Actions pane.
c. In the Properties window, click the Authentication tab.
d. Click Use one or more standard authentication methods, and select the Integrated Windows authentication check
box.
10. Click OK.

11. Restart the IIS for each server that you configured to use integrated Windows authentication.
Step 3. Assign LDAP Authentication Service to the Exchange 2010 Service

b. From the Authentication Service list, select the alias of the LDAP service you created in Step 1.
c. (Optional) Specify the URL where users are redirected if their authentication fails because their passwords expired in the Au
th Password Expired URL. Users are redirected to reset their passwords.
Step 4. Configure an Authorization Policy for the Exchange 2010 Service

Configure an authorization policy to control the access of authenticated users to your Exchange OWA. You can configure access by user,
group, or both user and group. In the policy, specify the URL, host, and extended match patterns for requests that must be handled by the
policy.

n.
a. From the Service list, select the Exchange 2010 Service
5. Click Save.
Step 5. Verify Your Setup
1. Go to: https://<FQDN of your Exchange 2010 VIP Address>/owa

OWA.
IIS Web Application with Kerberos Authentication

1. In the IIS Manager, click Application Pools in the left pane. All running applications then appear in the right pane.
2. Identify the application to associate with the user. Right-click the application, and select Advanced Settings.
3. In the Advanced Settings window, click the button next to Identity.

4. In the Application Pool Identity window, select Custom account and click Set.
5. Enter the username and password for the user that you created in Active Directory, and click OK.

6. In the IIS server's Applicationhost.config file, set useAppPoolCredential to true. The file is located at:
/windows/system32/inetsrv/config/Applicationhost.config
For example:
<location path="Default Web Site">

<system.webServer>
<security>
<authentication>
<anonymousAuthentication enabled="false" />
<windowsAuthentication enabled="true" useKernelMode="true" useAppPoolCredentials="true">
<extendedProtection tokenChecking="None" />
</windowsAuthentication>
</authentication>
</security>
</system.webServer>
</location>
IBM Domino with LDAP Authentication

Step 1. Configure LDAP Authentication on the Barracuda Load Balancer ADC
1. Go to the ACCESS CONTROL > Authentication Services page, and click the LDAP tab.
2. In the settings, specify the following:
Alias for the IBM Domino LDAP server
IP address and port of the server
Base DN: O= <Organization Name>
Administrator account credentials for Bind DN (Username) and Bind Password
Login Attribute: uid
3.

3. Click Test LDAP to verify that a connection can be established with the LDAP server. The test results display at the bottom of the
page. If the test fails, re-enter and re-test the LDAP settings.
4. Click LDAP Discovery to verify that users can be found with the attributes and filters that you entered. If you want to view detailed
query results, select the Verbose check box. In the test results:
A green dot means the information has been verified
A red dot means the information needs to be corrected
Although a red dot is displayed next to Base DN, it can be ignored. Click Add.
5. If any information is incorrect or missing, edit the field and click LDAP Discovery.
6. After your settings have been validated, click Add.
The LDAP service appears in the Existing Authentication Services section.
Step 2. Configure your IBM Domino Servers
Ensure that HTTP basic authentication is enabled on your IBM Domino servers. For higher security, enable SSL on your servers so that your
authentication information is not sent in clear text.
Authentication and access control with the Barracuda Load Balancer ADC does not work with IBM Domino's form-based single
sign on redirection.
Step 3. Assign LDAP Authentication Service to the IBM Domino Service

b. From the Authentication Service list, select the alias for the LDAP service that you created in Step 1.
Step 4. Configure an Authorization Policy for the IBM Domino Service
Configure an authorization policy to control the access of authenticated users to your IBM Domino iNotes site. You can configure access by
user, group, or both the user and group. In the policy, specify the URL, host, and extended match patterns for requests that must be handled
by the policy.

n.
a. From the Service list, select the IBM Domino service.
5. Set Send Basic Authentication to On.
6. Click Save.
1. Go to: https://<FQDN of your IBM Domino VIP Address>/webadmin

web admin site.
Additional Authentication Options
If you also want to configure single-sign on or set up a custom login page, see these articles:

For RADIUS servers, you can also configure the SMS PASSCODE for two-factor client authentication with passcodes that are sent to users'
mobile phones. See How to Configure SMS Passcode Authentication Service.


This article applies to the Barracuda Load Balancer ADC 540 and above, version 5.1 and above.
On the Barracuda Load Balancer ADC, you can configure Single Sign-On (SSO) to let end users access multiple applications across different
web servers protected by the Barracuda Load Balancer ADC, without requiring them to reauthenticate. Successfully authenticated users with
proper access privileges are given an SSO User Session Cookie, authenticating them for a period of time. If the login fails, the authentication
request is rejected.
The Barracuda Load Balancer ADC supports both single domain and multi-domain SSO.
Prerequisite
Verify that an authentication service and an authorization policy have been created for the services of your web applications.
For instructions, see How to Configure Authentication and Access Control (AAA).
Single Domain SSO
Single domain SSO takes place within a single domain. For example, bc.com hosts several restricted websites on several hosts. You can
configure single sign-on for this domain, so that authenticated users can access all or a subset of the restricted resources by authenticating once.
When a user logs out of a domain, the Barracuda Load Balancer ADC removes the user session cookie from the browser by expiring it, so that
the user is automatically logged out of other corresponding domains. For example, a user is logged into host1.bc.com , host2.bc.com , and
host3.bc.com using bc.com as the cookie domain. When the user logs out of host1.bc.com , the user session cookie is removed from
the browser and the user is automatically logged out of host2.bc.com and host3.bc.com .
Configure Single Domain SSO
In the authentication policy for the service, specify the SSO domain.

2. Click Edit next to the policy.
3. In the Edit Authentication Policy window, ensure that the policy is enabled and that an authentication service has been selected for the
service.
4. In the Session-Cookie Domain field, enter the domain name of the service (e.g., bc.com) .
5. In the Idle Timeout field, enter the maximum length of time that a user can remain idle in the domain before being logged out
automatically.
6. Click Save.
Multi-domain SSO
With multi-domain SSO, your users are authenticated for multiple domains after logging into one domain. When you configure multi-domain SSO,
you must designate a master domain with one or more slave domains. The master domain acts as a centralized authentication server that
authenticates the users and transfers the SSO User Session Cookie to the slave domains.
Users must be initially authenticated by the master domain. If a user tries to access the master domain before a slave domain, the user is
prompted to provide login credentials. If a user tries to visit a slave domain before the master domain, the user is redirected to the master service
URL for authentication and prompted to provide login credentials. After being successfully authenticated and authorized, the user is granted
access to the master domain and slave domains.
For example, www.abc.com is the master domain and www.xyz.com is the slave domain. If a user first tries to access www.abc.com, the user
is prompted to provide login credentials. If the user first tries to access www.xyz.com , the user is redirected to www.abc.com for authentication
and prompted to provide login credentials. After being successfully authenticated and authorized, the user receives SSO User Session Cookies to
access both domains.
When users log out of a domain, they are not automatically logged out of all domains; they must manually log out of each domain.
Configure Multi-Domain SSO
To set up multi-domain SSO, configure the authentication policies for the services of your master and slave domains. You must also create an
authorization policy for the master domain.
Step 1. Configure the Master and Slave Domains
Complete the following steps for the services of your master and slave domains.
1.


3. In the Edit Authentication Policy window, ensure that the policy is enabled and that an authentication service has been selected for the
service.
4. In the Single Sign On section, specify if the domain is the master or a slave.
If the domain is the master, set Master Service to Yes and enter its URL path in the Master Service URL field. The URL must
be a virtual URL (internal URL). For example: /ncsso.process
If the domain is a slave, set Master Service to No and enter the URL of the master domain in the Master Service URL field. In
the master service URL, you must specify the protocol, host, master domain, and URL path. For example: http://www.abc.c
om/ncsso.process
5. Click Save.
Step 2. Create an Authorization Policy for the Master Service
Create an authorization policy with the URL of the master service.

a. From the Service list, select the service.
c. Set the Status to Off.
d. In the URL Match field, enter the URL of the master service. For example: /ncsso.process
e. Specify the host and any other expressions that must be matched in the requests.
f. Specify the Login Method. If you want to create a custom login or challenge page, select HTML Form.
5. In the Edit Authorization Policy window, specify if you want to allow or deny the request to all authenticated users or only specific users
and groups.
6. Click Save.


With the Barracuda Load Balancer ADC, you can use a custom login page to prompt users for their login credentials when they try to access a
protected web application. After you create and deploy the custom login page, configure the application authorization policy to use the page. If
you enabled authorization for the entire website (i.e., the URL Match setting of the authorization policy is /*), you must also create an
authorization policy for the custom login page.
Prerequisite
Verify that an authentication service and an authorization policy have been created for the service of the web application.
Step 1. Create and Deploy the Custom Login Page
Create and deploy the custom login page on the web server for the application.
1. Create a custom login page named login.html. The page must contain the following parameters and values:
form id="nclogin"
name="login"
action="/nclogin.submit"
method=POST
User name field named f_username
Password field named f_passwd
An additional hidden parameter named f_method that is specified with value "LOGIN"
The form will look something like this:
<form id="nclogin" name="login" action="/nclogin.submit" method=POST>

<p>User Name: <input TYPE="text" name="f_username">
<p>Password: <input TYPE="password" name="f_passwd">
<p><input type=hidden name="f_method" value="LOGIN"><input TYPE="submit" Value="Login"><input
TYPE="reset" Value="Reset">
</form>
2. Deploy the custom login page on the web server for the application. For example, if the IP address of the web server is 192.168.128.10,
make the page available at http://192.168.128.10/login.html.
Step 2. Edit the Authorization Policy to Use the Custom Login Page
Edit the authorization policy of the service to display the custom login page to unauthenticated users.

3. In the Edit Authentication Policy window, configure these settings:
Auth Not done URL – Enter /login.html
The Auth Not done URL section indicates that whenever there is no Authentication header present, the ADC will
redirect users to this page. By default, it redirects users to the /nclogin.submit page (on the ADC).
Login Method – Select HTML Form.

Send Basic Authentication – Select Yes.
4. Click Save.
Step 3. Create an Authorization Policy for the Login Page
Create an authorization policy with the URL of the login page.

d. In the URL Match field, enter the URL of the login page. For example: /login.html
e.

e. Specify the host and any other expressions that must match requests.
and groups.
6. Click Save.

How to Configure SMS Passcode Authentication Service

On the Barracuda Load Balancer ADC, you can use SMS PASSCODE® with a RADIUS server to configure two-factor client authentication for
your web applications. With SMS Passcode, users go through the following authentication process:
1. The user enters a username and password. After the login credentials are verified, a passcode is sent to the user's mobile phone.
2. The user is redirected to a challenge page to enter the passcode.
3. After submitting the passcode, the user can access the application if the authorization policy allows it.
To set up SMS PASSCODE for a service, install it on a RADIUS server that you have integrated with the Barracuda Load Balancer ADC.
Prerequisites
Verify that a RADIUS authentication service and an authorization policy have been created for the service of the web application. For
instructions, see How to Configure Authentication and Access Control (AAA).
If you do not want to use the default challenge page that is provided by the Barracuda Load Balancer ADC, you can also create a custom
challenge page. See How to Set Up a Custom Challenge Page for Authentication.
Step 1. Set Up SMS Passcode
Install and configure the SMS Passcode on the RADIUS server that you have integrated with the Barracuda Load Balancer ADC. For details, see
your SMS PASSCODE Administrator's Guide.
Step 2. Verify that SMS Passcode Works Properly
As an end user, go through the followings steps to verify that SMS Passcode has been properly configured:
1. In a web browser, go to the URL of the web application.

2. On the default authentication page, or the custom login page, enter your username and password and click Login. You should receive a
passcode via SMS on your mobile phone.
3. Enter the passcode and click Login. You should be redirected to the page that you initially tried to access.

How to Set Up a Custom Challenge Page for Authentication

If you are using two-factor authentication (e.g., SMS PASSCODE) for a web application, you can use a custom challenge page to prompt users
for additional credentials after authenticating the username and password.
After you create and deploy the custom challenge page, configure the application's authentication and authorization policies to use the page.
Prerequisite
Verify that an authentication service and an authorization policy have been created for the service of the web application.
Step 1. Create and Deploy the Custom Challenge Page
Create and deploy the custom challenge page on the web server for the application.
1. Using a script that the back-end server supports (e.g., CGI Perl, PHP, or Java), create a custom challenge page named challenge.fi
leextension. For example, if you use PHP, the page name is challenge.php.
The page must contain the following parameters and values:
form id="nclogin"
name="login"
action="/nclogin.submit"
method=POST
Form fields named Challenge User Field and Challenge Prompt Field.
2. Deploy the custom login page on the web server for the application. For example, if the IP address of the web server is 192.168.128.10,
make the page available at http://192.168.128.10/challenge.php.
Step 2. Edit the Authentication Policy to Specify the Page URL and Query String Fields
Edit the authentication policy of the service to display the custom login page to unauthenticated users.

2. Click Edit next to the service.
3. In the Edit Authentication Policy window, configure these settings:
Auth Challenge URL – Enter the URL of the challenge page (e.g., /challenge.php).
Challenge User Field – Use the default value of challenge_user, unless you used a different query string field to pass the
username to the challenge page.
Challenge Prompt Field – Use the default value of challenge_prompt, unless you used a different query string field to pass
the prompt string to the challenge page.
4. Click Save.
Step 3. Edit the Authorization Policy to Use the Custom Challenge Page
Edit the authorization policy of the service to use the HTML Form login method.

3. In the Edit Authorization Policy window, verify that Login Method is set to HTML Form.
With a custom challenge page, the HTTP Basic Authentication login method is not supported.
4. Click Save .
Step 4. Create an Authorization Policy for the Challenge Page
Create an authorization policy with the URL of the challenge page.

d. In the URL Match field, enter the URL of the challenge page. For example: challenge.php
e.

e. Specify the host and any other expressions that must be matched in the requests.
and groups.
6. Click Save.

Technical White Papers
In this Section
PCI Compliance Considerations

PCI Compliance Considerations
This article outlines implementation considerations when deploying the Barracuda Load Balancer ADC in
an environment subject to PCI Data Security Standard (PCI DSS) compliance. This article focuses on
the requirements placed on the Barracuda Load Balancer ADC for achieving PCI compliance, in an
environment that includes the following:
Application Server
Database Server
For PCI DSS Requirement 6.6 compliance and added application security, consider purchasing an Application Security license for
the Barracuda Load Balancer ADC.
Efficient PCI Compliance
PCI Compliance applies to entities that process, store, or transmit cardholder data. The Barracuda Load Balancer ADC intelligently distributes
traffic among servers for efficient use of server resources, and provides server fail-over for High Availability. The Barracuda Load Balancer ADC,
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 v1.2, 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 ADC 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 ADC 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 ADC are configured similarly, they
are exempt from an internal scan. For more information, refer to Account for Load Balancer ADCs (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 ADC and the client connecting to the Barracuda Load
Balancer ADC from the Internet. Configure SSL for each Service that requires compliance.
The use of SSL has the following security implications under PCI DSS compliance:
1. Disables Secure Sockets Layer version 2 (SSLv2);

2. Disallows "weak" cryptography;
3. 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 ADC provides secure SSL Offloading for your services. To enable this, log into the Barracuda Load Balancer ADC web
interface, go to the BASIC > Services page, select a service, and scroll down to the SSL Settings section:

By default the Barracuda Load Balancer ADC disables the deprecated cipher and is therefore "secure by default". As shown in the screenshots
above, the Barracuda Load Balancer ADC enables only:
SSL Protocols – SSL v3, TLS v1.0/1.1/1.2

SSL Ciphers – Only the RC4-MD5 cipher is disabled. All other ciphers are enabled (see Selected Ciphers).
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 ADC as shown in Table 1.
Table 1. SSL Protocol Vulnerabilities
Vulnerability Impact Remediation
Insecure Renegotiation High Barracuda Load Balancer ADC only supports

secure renegotiation initiated by the Server.
BEAST Attack Low SSL v3 and TLS 1.0 may be vulnerable to

this attack even when block ciphers are
used; configure the Barracuda Load
Balancer ADC 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
ADC.
Configuring Back-End SSL
Back-end SSL refers to the use of the SSL protocol to re-encrypt traffic between the Barracuda Load Balancer ADC 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 ADC 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 for the
Server you wish to modify, and update the SSL section as shown in the following image:
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 ADC fully supports. Ensure that all SSL services, as well as the Management UI, employ strong

certificates.
Secure the Web-based Management UI
To allow Web Interface access by HTTPS/SSL only, enable HTTPS/SSL Access Only to Yes on the ADVANCED > Secure Administration page
. You can select a Private certificate if you have restricted access to a private network as in the screenshot shown above.
Secure SNMP Access
To secure the SNMP access for compliance, go to the ADVANCED > SNMP Configuration page, and complete the following steps:
1. In the SNMP Manager section, select the SNMP Version as v3.

2. Provide a secure password for the admin user.
3. Select SHA and AES as the Authentication Method and Encryption Method respectively; these are more secure than MD5 and DES.
4. 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 ADC.
To enable Syslog:
1. Go to the ADVANCED > Export Logs page.

2. In the Syslog section, click Add Syslog Server. The Add Syslog Server window appears.
3. Specify values for the following fields:
a. Name – Enter a name to identify this syslog server.
b. IP Address - Enter the IP address of the syslog server.
c. Port – Enter the port associated with the IP address of the syslog server.
d. Connection Type – Select the connection type to transmit the logs from the Barracuda Load Balancer ADC to the Syslog
server.
e. Validate Server Certificate – Set to Yes to validate the syslog server certificate using the internal bundle of Certificate
Authority's (CAs) certificates packaged with the system. If set to No, any certificate from the syslog server is accepted.
f. Client Certificate – When set to Yes, the Barracuda Load Balancer ADC presents the certificate while connecting to the syslog
server.
4. Click Add.
Ensure Password Security
Before you install and deploy one or more Barracuda Load Balancer ADCs, 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 > Backups page, and set Encrypt
Backup to Yes.

Click Generate to create a strong encryption key for your backup file. A new window opens with the generated key. Copy this key into the Backu
p Encryption Key field. This key is required to decrypt or restore the backup configuration. Click Save when you have finished.
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, email 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 ADC is susceptible to CVE 2002-0012 CVE 2002-0013 CVE2002-0053.
Barracuda Load Balancer ADC includes a customized port of NET-SNMP version: 5.4.2.1, which is not susceptible to the vulnerabilities
mentioned in the reports. Only versions of NET-SNMP prior to 4.2.2 are susceptible to these.
For additional information refer to CERT® Advisory CA-2002-03 Multiple Vulnerabilities in Many Implementations of the Simple Network
Management Protocol (SNMP) (http://www.cert.org/advisories/CA-2002-03.html)
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 ADC inserts cookies for a service when the Persistence type is set to 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.

Traffic Management
In this Section
Content Rules for HTTP and HTTPS Services

Extended Match and Condition Expressions
Understanding HTTP Rewrite Rules
Content Rewriting
Example - Using Response Body Rewrite to Enable Web Sites for Google Analytics
Understanding HTTP Caching
Understanding HTTP Compression

Content Rules for HTTP and HTTPS Services
You can add content rules to direct incoming requests for an HTTP or HTTPS service to one or more real servers, based on the host, URL, or
other HTTP header fields of the request. If a request does not match any content rule, it is directed to a real server that has been added to the
service.
Pattern Matching
When you create a content rule, enter the following patterns to match the requests that you want to be handled by the rule:
Host Match – The host or domain name to match in the host header of the requests.
URL Match – The URL to match in the URL header of the requests.
Extended Match – An expression consisting of a combination of HTTP headers and/or query string parameters. The extended match
pattern in a rule is evaluated only if the host and URL pattern are matched to the request. If a request does not match any extended
match expressions for the rule, then the request is considered to have failed to match the rule. For more information on extended match
and condition expressions, see Extended Match and Condition Expressions.
You can have multiple rules with the same host and URL match patterns but different extended match patterns. These rules are evaluated
sequentially by the extended match sequence number that you assign to them.
If there are multiple content rules for a service, the rule that matches a request most closely is executed. For example, if a service has these two
rules:
Rule A – host www.example.com, URL /images/*

Rule B – host www.example.com, URL /images/*.png
and the incoming request is for www.example.com/images/x.png, 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: http://www.home.com
URL Match: /*
Redirect URL: http://www.redirect.com%s
When a request such as http://www.home.com/a.html is sent, it is redirected to http://www.redirect.com/a.html
You can also use % in the URL to offset characters. For example,
Service: http://www.home.com/abc
URL Match: /*
Redirect URL: http://www.redirect.com/test/*
If you use %s, the redirected URL would be http://www.redirect.com/test/abc instead of http://www.redirect.com/test/*.
In this case, specify the Redirect URL as http://www.redirect.com/%4s. This format will copy anything in the URL match after 4 characters.
Create a Content Rule
To create a content rule for an HTTP or HTTPS service:

2. In the left pane, select the service.
3. Click the Add Content Rule option that appears.
4. In the Add Content Rule window, enter a name for the rule, enter the patterns to match the requests that you want to be handled by the
rule, and specify how the requests are distributed to the real servers for the rule.
5. Click Create. The content rule settings appear in the main pane of the web interface.
6. In the Configured Servers section, click Add Server to add and configure the real servers that you want to handle the requests that
match the rule.
redirect rules

Extended Match and Condition Expressions
You use extended match and condition expressions in content rules, HTTP request rewrite rules, and HTTP response rewrite rules to match the
requests and responses that you want to be handled by these rules.
Quick Reference
Expressions Element Match

(Expression) [Join (Expression) ...]
Joins &&, ||
Elements Request Elements: Method, HTTP-Version, Client-IP, URI,

URI-Path, Header
Request Parameters: Parameter, Pathinfo
Response Elements: Status-code, Response-Header
Operators Matching: eq, neq, req, nreq

Containing: co, nco, rco, nrco
Existence: ex, nex
Structure
An expression consists of one or more element matches that are combined with join operators to indicate AND and OR operations to combine
the element matches. Use parentheses to delimit individual element matches when using join operators. You can nest parentheses.
An element match consists of an element, an optional element name, and an operator followed by an optional value. Some elements like Head
er 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. You can use double quotes (") to enclose single tokens which contain parenthesis
characters or spaces. Use the backslash (\) to escape, or remove the special meaning of the special characters (space and parentheses).
Operators
You can use the following operators in an element match. The operators are case-insensitive; for example, eq, Eq, and EQ are all treated the
same.
Operator Description
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 one and ONE are treated the same.
neq True if the operand is not equal to the given value. A case-insensitive
string comparison is performed.
co True if the operand contains the given value.
nco True if the operand does not contain the given value.
rco True if the operand contains the given value, which is treated as a
regular expression.
nrco True if the operand does not contain the given value, which is treated
as a regular expression.
req True if the operand matches the given value, which is treated as a
regular expression.
nreq True if the operand does not match the given value, which is treated
as a regular expression.
ex True if the operand exists. A value is not required.
nex True if the operand does not exist. A value is not required.
Elements

The elements listed in the following table can only be used in certain expressions. Elements and element names are case-insensitive; for
example, Method and METHOD are treated the same.
Element Description Restrictions
Method The HTTP method that was received in the Only allowed in:
request.
Extended match expressions
Example: (Method eq GET) Request rewrite conditions
HTTP-Version The version of the HTTP protocol of the Only allowed in:
request.
Example: (HTTP-Version eq HTTP/1.1) Request rewrite conditions
Header An HTTP header in the request. An element Only allowed in:

name is required after the header.
Example: (Header Accept co gzip) Request rewrite conditions
Response rewrite conditions
This example checks if the Accept header
contains the string gzip.
Client-IP The IP address of the client sending the Only allowed in:
request. The IP address can be either a host
IP address or subnet IP address specified by Extended match expressions
a mask. Request rewrite conditions
Only eq and neq operations are allowed for

this element.
Examples: (client-ip eq
192.168.1.0/24), (Client-IP eq
192.168.1.10)
URI The uniform resource identifier in the Only allowed in:

request. This includes any query parameters
in the request. Extended match expressions
Request rewrite conditions
Example: (URI rco
/abc.*html?userid=b)
URI-path The path portion of the URI, which excludes Only allowed in:
any query parameters.
Example: (URI-path req
\/.*copy%20[^/]*)
Pathinfo The portion of the URL which is interpreted Only allowed in:
as PATH_INFO on the server. The Barracuda
Load Balancer ADC uses a set of known
extensions to determine whether a portion of
the URL provides information about a file
path.
For example, if the request URL is /twiki/

view.cgi/Engineering, then /Enginee
ring is considered to be the pathinfo rath
er than
part of the URL.
Example: (PathInfo rco abc*)
Parameter A parameter in the query string part of the Only allowed in:
URL and serves as a name-value pair. The
special $NONAME_PARAM Extended match expressions
parameter is used when the parameter name
is absent.
Examples: (Parameter sid eq 1234), (P

arameter $NONAME_PARAM co abcd)

Status-code The status code of the response returned by Only allowed in response rewrite conditions.
the servers.
Example: (status-code eq 302)
Response-header The HTTP response header in the response. Only allowed in response rewrite conditions.
The Response-header term must be
followed by the name of the header on which
the
action is to be applied.
Example: (Response-Header
Set-Cookie co sessionid)
Combining Expressions
You can use the following join operators to combine expressions:
Operator Description
|| True if either of the expressions are true.
&& True only if both the expressions are true.
When you combine element matches, you must enclose each element in parentheses. Combining element matches without parentheses is not
allowed.
Example: (Header cookie ex) && (URI rco .*\.html) && (Method eq GET)
Nesting Expressions
You can next sub-expressions by enclosing parentheses within expressions. This makes the expression more readable and clear.
Example: (HTTP-Version eq HTTP/1.1) && ((Header Host eq www.example.com) || (Header Host eq

website.example.com))
Escaping
Escape special characters by enclosing entire values in double quotes (") or prefixing characters with a backslash (\). The backslash character
escapes all characters, not just the special characters. For example, \c stands for the character c. In other words, the backslash followed by any
character stands for the character, whether or not that character has a special meaning in the syntax.
The space character and the parentheses characters are special characters because 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:1.8.1.3) Firefox/2.0.0.3
When you write expressions or conditions to match the header example above, you can escape the special characters as follows:
Header User-Agent eq “Mozilla/5.0 (Linux i686; en-US; rv:1.8.1.3) Firefox/2.0.0.3”

Header User-Agent eq Mozilla/5.0\ $Linux\ i686;\ en-US;\ rv:1.8.1.3$\ Firefox/2.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.
Macro Definitions
The Barracuda Load Balancer ADC 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.
Macro Description
$SRC_ADDR Inserts the source (client) IP address. You can use it for the new
value (Rewrite Value parameter) when inserting or rewriting a
header.

$URI Specifies the complete request URI including the query string. If you
are rewriting or redirecting the URI, use this macro in the new value.
$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. Access control or authentication is disabled. The value substituted for the macro is the special string NCURLNotPro
tected.
(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 displays a pop-up window to
visitors. A Javascript adds a query string that results in the following GET request:
GET /ad?xyz
The Barracuda Load Balancer ADC does not learn “no name” parameters such as query strings like "GET /ad?0" added by a
Javascript. As a workaround: add a null value URL ACL.
The Barracuda Load Balancer ADC treats xyz as the value of a parameter. In this case, you cannot create an exception rule based on the xyz v
alue 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 lets you 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

Understanding HTTP Rewrite Rules
Website translation is used to set a variety of address translation rules for application-specific packets sent through the Barracuda Load Balancer
ADC. It translates the internal codes, headers, and cookies so that the actual message is concealed from external users. Using website
translation, you can accomplish website cloaking and translation of URLs and headers in requests or responses.
Use the TRAFFIC > Web Translations page to create rules to modify inbound HTTP requests and outbound responses for HTTP/HTTPS
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
HTTP Request Rewrite Conditions

An HTTP request rewrite is applied to the HTTP request coming from the client to the Barracuda Load Balancer ADC. A request rewrite condition
is made up of one or more expressions. An expression consists of an operand, an operator, and a matching value.
Table 1. HTTP Request Rewrite Operators

Table 1 describes the operators you can use in the request rewrite condition expression:
Click here to expand...
Operator Values Description
contains, CONTAINS, co, CO Checks if the operand contains the matching value.
ncontains, nCONTAINS, nco, nCO Checks if the operand does not contain the matching value.
rcontains, rCONTAINS, rco, rC Checks if the operand contains the matching value, where the
matching value is interpreted as a regular expression.
equals, EQUALS, eq, E Checks if the operand is equal to the matching value.
nequals, nEQUALS, neq, nEQ Checks if the operand is not equal to the matching value.
requals, rEQUALS, req, rE Checks if the operand is equal to the matching value, where the
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 2. HTTP Response Rewrite Expression Tokens
Table 2 describes the tokens available for joining expressions:

Token Description
or, OR, || Checks if either of the expressions is true.
and, AND, & 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:
Operands Description Example

Header Examine the request header. You can Header Accept co soap
search for a header field name, which is a Header Soap-Action ex
string followed by a colon (:), or for any AnyString EX
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.
Client IP Check the IP address of the client that sent Client-IP eq 192.168.1.0/24 (s
the request. The IP address can be either ubnet IP address containing the mask)
the host IP address or subnet IP address Client-IP eq 192.168.1.10 (hos
specified by a mask. Only the EQUAL and N t IP address)
OT EQUAL operators may be used with this
operand
URI The Uniform Resource Identifier (URI) URI rco /abc*html

identifies the resource upon which to apply
the request. The matching value may be a
regular expression.
Method HTTP method in the request. Method eq GET
HTTP-Version HTTP protocol version of the request. HTTP-Version eq HTTP/1.1
Parameter The query portion of the URL which is Parameter sid eq 1234
passed to the server as a name-value pair. Parameter $NONAME_PARAM co a
$NONAME_PARAM may be used to refer to bcd
the case where the parameter name is
absent. The matching value may be a
regular expression.
Pathinfo The portion of URL containing extra pathinfo rco abc*

information about the path of the resource
on the server. The matching value may be
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 ADC.
Table 4. HTTP Response Rewrite Expression Operators
Table 4 describes the operators you can use in the response rewrite condition expression:
Operator Values Description
contains, CONTAINS, co, CO Checks if the operand contains the matching value.
ncontains, nCONTAINS, nco, nCO Checks if the operand does not contain the matching value.

rcontains, rCONTAINS, rco, rC Checks if the operand contains the matching value, where the
equals, EQUALS, eq, E Checks if the operand is equal to the matching value.
nequals, nEQUALS, neq, nEQ Checks if the operand is not equal to the matching value.
requals, rEQUALS, req, rE Checks if the operand is equal to the matching value, where the
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:

Token Description
or, OR, || Checks if either of the expressions is true.
and, AND, & 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:
Operands Description Example
Header Examine the request header. You can Header Accept co soap
search for a header field name, which is a Header Soap-Action ex
string followed by a colon (:), or for any AnyString EX
string. To search for HTTP or custom
header field names, type Header followed


Response-Header Examine the header of the response. You Response-Header Set-Cookie c

can search for a header field name, which o sessionid
is a string followed by a colon (:), or for any
string.
To search for HTTP or custom header field

names, type Response-Header followed

Status-Code Checks the status code of the response Status-Code eq 200

returned by the server .
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:

Field Name Description
Rule Name Enter a name to identify the rule.
Rule Order 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
www.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 Enter the text string on which to search in the response body.
Replace String Enter the replacement text string.

Additional Information
For a Response Body Rewrite example, refer to the article Example - Using Response Body Rewrite to Enable Web
Sites for Google Analytics .

Content Rewriting
The Barracuda Load Balancer ADC allows you to rewrite selected content of requests and responses. This feature can be used to implement
website cloaking and translation of URLs and headers in requests and responses. It can translate the internal codes, headers, and cookies so
they are concealed from external users. Content rewriting allows you to configure address translation rules for application specific packets sent
through the Barracuda Load Balancer ADC.
Configuring URL Translation
When a web server returns a URL, sensitive information can be exposed and used to launch a variety of web attacks against the server. You can
prevent these potential attacks by configuring URL translation rules on the Barracuda Load Balancer ADC to modify the prefix, domain, and
response body of an internal URL to an externally viewable URL.
You can also use URL translation to make internal applications publicly accessible, even when the applications link to internal servers that are not
defined in the external DNS name space. For example, Company ABC has an internal application registered in the internal DNS as finance.abc.
The application can be made available on the Internet at www.companyabc.com/finance.abc with a URL translation rule that maps the internal
domain to the external domain of www.companyabc.com.
To configure URL translation rules, go to the URL Translations section of the TRAFFIC > Website Translations page.
Configuring HTTP Request Rewrite
HTTP request rewrite rules specify how to modify the request headers and URL or specify how to redirect a request. Headers can be added,
removed, or edited on the Barracuda Load Balancer ADC before the request is forwarded to the back-end server. The URL can be rewritten to
map to a different resource. A redirect response can also be issued to the clients to point them to an updated location or resource. For example,
Request Rewrite is used by default to relay the client IP address to the back-end server (in Proxy mode), by inserting the header
X-Forwarded-For with the value of the client IP. The back-end server can extract and use this value. Similarly, authentication parameters (such as
certificate details or user name) can be forwarded by inserting request headers and using macros. See How to Pass Client Certificate Details to
a Back-end Server for more details. To configure HTTP Request Rewrite, navigate to TRAFFIC > Web Translations and then scroll to HTTP
Request Rewrite. For detailed configuration instructions, click Help on that page. To format a Request Rewrite
Condition refer to Rewrite Condition Format below.
Configuring HTTP Response Rewrite
This policy sets rewrite rules for outbound responses. It allows you to add, delete, or rewrite headers. Response Rewrites are used for many
purposes. For example, if a response included a header listing the source IP address, response rewrite could delete that header preventing
external users from seeing the actual IP address of the server.
To configure HTTP Response Rewrite, use TRAFFIC > Website Translations > HTTP Response Rewrite. For detailed configuration
instructions, click Help on that page.
Configuring Request Rewrite and Response Rewrite
To configure a request rewrite rule, perform the following steps:
1. Go to the TRAFFIC > Website Translations page, and in the HTTP Request Rewrite section or HTTP Response Rewrite section,
specify values for the following fields:
a. Rule Name – Enter a name for the request or response rewrite rule.
b. Sequence Number – Set the sequence number for the request or response rewrite policy. This number determines the order of
execution for multiple configured policies from highest (1) to lowest (1500).
c. Action – Set the action to: Insert Header –Inserts a header to the request; Remove Header – Removes the header from the
request; Rewrite Header – Rewrites the value of the existing header in the request.
d. Header Name – Enter the relevant Header Name, for example X-Forwarded-For.
e. Old Value – Enter the initial request header to be rewritten if the Action is Rewrite Header. An asterisk (*) rewrites all named
headers, or specify the value or expression to be rewritten.
f. Rewrite Value – Enter the new value of the header to be rewritten when the Action is set to Insert Header or Rewrite Header.
Use the macros listed below to specify parameters from the client. When rewriting a header you can specify one or more fields
using the separators such as colon (:), semicolon (;), space ( ) and comma (,). In Rewrite Value, the fields can be defined for
example: "Name=abc_cookie; Domain=example.com:Path=/". The rewrite-value supports substring addressing of matches, i.e.
the matching sub strings can be referenced using $1,$2,...$n. See Supported Macros below for a list of macros supported for
rewrite values.
g. Rewrite Condition – Set the condition under which a rewrite should occur. An asterisk (*) indicates there are no conditions
(applies to all). Details on the format of the Rewrite Condition are explained below in Rewrite Condition Format.
2. Click Add to add the above settings.
Note: When multiple policies are configured, the request continues to be processed by other (higher sequence number) policies. If you wish to
stop processing after a particular rule is matched, click Edit next to the rule and set Continue Processing to No.

Rewrite Condition Format
The request Rewrite Condition specifies when a rewrite should occur. The Rewrite Condition is made up of expressions combining Request
Rewrite Tokens and Operations on those tokens for Request Rewrites. The Rewrite Condition is made up of expressions combining Respo
nse Rewrite Tokens and Operations on those tokens for Response Rewrites.These expressions can then be joined with each other using
logical or (or, OR, ||) or logical and (and, AND, &&). Examples of Rewrite Conditions: (Header User-Agent co mozilla) , (URI rco /abc*html),
(Client-IP eq 10.0.0.1)&&(Method eq POST). An asterisk indicates there are no conditions for rewrite, so the rewrite is done in every case.
Request Rewrite Tokens
These tokens can be used in a request Rewrite Condition:
Header – The HTTP header in the request. The word Header precedes the name of the relevant header or * to indicate all headers.
Examples: Header Accept co soap, Header Soap-Action ex.
Client-IP –The IP address of the client sending the request. The IP address can be either a host IP address or a subnet specified by a
subnet mask. Only operations EQ and NEQ can be combined with this token. Examples: Client-IP eq 192.168.1.0/24 (subnet qualified by
a netmask) Client-IP eq 192.168.1.10 (host IP address)
Uri – The Uniform Resource Identifier of the resource on which to apply the rule. Example: URI rco /abc*html
Method – The HTTP method in the request. Example: Method eq GET
Http-Version – The HTTP protocol version of the request. Example: HTTP-Version eq HTTP/1.1
Parameter – The query part of the URL which is passed to the servers as a name-value pair. In addition, the word "$NONAME_PARAM"
can be used when the parameter name is absent. Examples: Parameter sid eq 1234, Parameter $NONAME_PARAM co abcd
Pathinfo – The portion of URL which contains extra information about the path of the resource on the server. Example: pathinfo rco
abc*
Response Rewrite Tokens
These tokens can be used in a response Rewrite Condition:
Header – The HTTP header in the request. The word Header precedes the name of the relevant header or * to indicate all headers.
Response-Header – An HTTP header on the response path. 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.
Status-Code – The status code of the response returned by the servers. Example: Status-Code eq 200
Operations for Request Rewrite and Response Rewrite Conditions
These operations can be combined with Request Rewrite Tokens and Response Rewrite Tokens in a request or response Rewrite Condition:
contains, CONTAINS, co, CO – Token contains the given value.

ncontains, nCONTAINS, nco, nCO – Token does not contain the given value.
rcontains, rCONTAINS, rco, rCO – Token contains the given value which is interpreted as a regular expression.
equals, EQUALS, eq, EQ – Token equals the given value.
nequals, nEQUALS, neq, nEQ – Token does not equal the given value.
requals, rEQUALS, req, rEQ – Token equals the given value interpreted as a regular expression.
exists, EXISTS, ex, EX – Token exists.
nexists, nEXISTS, nex, nEX – Token does not exist.
Configuring Response Body Rewrite
This policy sets the rule for searching and replacing any text string in the response body. Only responses whose content-type begins with text/
can be searched, including text/html, text/plain, text/javascript, text/css, text/xml. Neither flash nor applet content can be searched. The search
and replace strings should be text rather than regular expressions. Metacharacters cannot be used, such as \r or \n in either search or replace,
which means you cannot search and replace any multi-byte charset strings.
To configure Response Body Rewrite, use TRAFFIC > Website Translations > Response Body Rewrite. For detailed configuration
instructions, click Help on that page.
Supported Macros
For Request Rewrites
$SRC_ADDR Inserts the source (client) IP address. You can use it for the new value (Rewrite Value parameter) when inserting or
rewriting a header
$URI 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.
$X509_VERSION The client certificate's X509 version string.
$X509_SERIAL_NUMBER The serial number of the client certificate.
$X509_SIGNATURE_ALGORITHM The Signature Algorithm used in the client certificate.

$X509_ISSUER The client certificate's issuer string.

$X509_NOT_VALID_BEFORE Time from which the client certificate is valid.
$X509_NOT_VALID_AFTER Time after which the client certificate is invalid.
$X509_SUBJECT The client certificate's Subject string.
$X509_SUBJECT_PUBLIC_KEY_TYPE The X509 Certificate Subject Key Identifier String of the client certificate.
$X509_SUBJECT_PUBLIC_KEY Public Key modulus of the client certificate.
$X509_SUBJECT_PUBLIC_KEY_RSA_BITS Size of the client certificate's public key, in bits.
$X509_EXTENSIONS The client certificate's X509 Extensions String.
$X509_HASH The X509 Hash string of the client certificate.
$X509_WHOLE The X509 client certificate represented as a string in PEM format.
$AUTH_USER Adds the username.*
$AUTH_PASSWD Adds the password.*
$AUTH_GROUPS Adds the user roles.*
The URL is not protected, i.e. access-control or authentication is off. The value substituted for the above three macros will be
the special string NCURLNotProtected.
The client has not logged in. The value substituted for the above three macros will be the special string NCNoUserSession.
The user does not belong to any groups. The value substituted for $AUTH_GROUPS will be the special string NCNOUserRol
es.
For Response Page
%action-id The attack id of the violation which resulted in this response page being displayed.
%host The host which sent this request.
%s The URL of the request which caused this violation.
%client-ip The Client IP address of the request which caused the violation.
%attack-time The time at which the violation occurred.
%attack-name The attack name of the violation which resulted in the response page to be displayed.

Example - Using Response Body Rewrite to Enable Web Sites for Google
Analytics
Response Body Rewrite rules apply to only HTTP and HTTPS services.
This article assumes you have a Google® Analytics™ account to obtain the code for use in the response body.
The Response Body Rewrite option provides a single point for managing response rewrites to offload Google indexing to the Barracuda Load
Balancer ADC. Create rules to search and replace any string in the body of outbound responses to remove server banners or other header or
body information that you do not want clients to see, to eliminate extra code in web site pages. Only responses where the content-type begins
with text/ (for example: text/html, text/plain, text/javascript, text/css, text/xml) are searched; Flash and applet content are unsupported.
The search and replace strings must be text; regular expressions cannot be used.
Google Analytics Example
This procedure provides instructions for creating a Response Body Rewrite rule to offload Google indexing by inserting Google Analytics code
into responses. This rule example searches for the </html> string that is on every page and then adds the Google analytics code before the
string.
1. Log into the Barracuda Load Balancer ADC as the administrator, and go to the TRAFFIC > Web Translations page.
2. In the Response Body Rewrite section, click Add Rule.
3. In the Add Response Body Rewrite window, configure these settings:
Rule Name: Google
Host Match : *
URL Match : /*
Search String : </html>
Replace String :
<script type="text/javascript"> var gaJsHost = (("https:" ==
document.location.protocol) ? "https://ssl. " : *http://www. );
document.write(unescape{"%3Cscript src="+gaJsHost
+ "google-analytics.com/ga.js'
type='text/javascript'%3E%3C/script%3E"));</script> <script
type="text/javascript"> try {var pageTracker =
gatgetTracker{"UA-6605828-2");
pageTracker._trackPageview(); } catch (err) {}</script> </body></html>
4. Click Save. The rule appears in the Response Body Rewrite table.

Understanding HTTP Caching
On the BASIC > Services page, you can configure caching for HTTP, HTTPS, and Instant SSL services and their content rules. In the Caching s
ection of the virtual service or content rule settings, you can:
Enable and disable caching.

Specify the response file extensions that can be cached.
Specify the 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.
For more information on the settings, click the Help icon in the web interface.

Understanding HTTP Compression
On the BASIC > Services page, you can create a compression policy for HTTP, HTTPS, and Instant SSL services and their content rules. In the
Compression section of the virtual service or content rule settings, you can:
Enable and disable compression.

Specify the content types to be compressed.
Specify the minimum size of objects to be compressed.
For more information on the settings, click the Help icon.

Logging
To help you monitor and troubleshoot traffic, the Barracuda Load Balancer ADC generates the following types of logs:
System Logs – Events that are generated by the system and show the general activity of the system.
Web Firewall Logs – Web firewall activity, such as allowing, blocking, or modifying incoming requests and responses according to the
rules and policies of the Barracuda Load Balancer ADC.
Access Logs – Traffic activity and various elements of incoming HTTP requests and responses from back-end servers.
Audit Logs – Auditing events generated by the system, which log the configuration and UI activity by users like admin.
Network Firewall Logs – Network traffic passing through the interfaces (MGMT and configured interfaces) that matches configured
network ACL rules.
You can view these logs in the web interface of the Barracuda Load Balancer ADC or export these logs to remote syslog servers. You can also
export logs in CSV format to external files.
In this Section
How to Configure Syslog and other Logs

How to Make the Client IP Address Available to the Back-end Server
How to Mask Sensitive Data in Logs
Viewing Logs on the Barracuda Load Balancer ADC
System Log Messages

How to Configure Syslog and other Logs
You can add up to three syslog servers to receive logs from the Barracuda Load Balancer ADC. To differentiate the logs so they can be stored in
distinct files on the syslog server, you can assign different log facilities to them. :
For each configured syslog server, you can associate a specific facility (default = local0) with each log type, so your syslog server can segregate
the log of each type into a different file.
Prerequisites
If you are running syslog on a UNIX machine, start the syslog daemon process with the -r option so that it can receive messages from external
sources. Windows users require additional software to use syslog because the Windows OS does not include the syslog capability. Kiwi Syslog is
a popular solution, but there are many free and commercial options available.
Syslog messages are sent over UDP/TCP/SSL ports. If there are any firewalls between the Barracuda Load Balancer ADC and the syslog
servers, ensure that the respective port is open on the firewalls.
Add a Syslog Server
To add a syslog server:

2. In the Syslog section, click Add Syslog Server.
3. In the Add Syslog Server window, configure the settings for connecting to and sending logs to the syslog server.
If you want the Barracuda Load Balancer ADC to present a certificate when it connects to a syslog server, ensure that you
upload the certificate on the BASIC > Certificates page. For more information on how to upload a certificate, see How to Add
an SSL Certificate.
4. Click Add. The server appears in the Syslog table.
Configure Syslog Facilities
The local0 to local7 facilities are available for each log type. You can select a different facility for each log or select the same facility for all logs.
To select a syslog facility for each log type:

2. In the Syslog section, click Syslog Settings.
3. In the Syslog Settings window, select a facility (Local0 to Local7) for each log type and click Save Changes.
Configure Log Levels
You can specify the minimum priority of the logs that you want to send for a module to the syslog server. By default, the log level for modules is
set to 0-Emergency. Note that the lower the level, the higher the priority and the more attention that the log entry demands. For example, log
levels 0-Emergency and 1-Alert have the highest priority and demand more immediate response than 5-Notice or 6-Information.
1. Ensure that Advanced Settings are enabled. Go to the ADVANCED > System Configuration page, and ensure that Advanced
Settings is set to Yes.
3. In the Module Log Levels section, enter a name for the log level, select the module, and select the log level for the module. You can
also enter comment about the new setting.
4. Click Add.
Configure Log Formats
You can configure the format of the logs that are sent to the syslog server. You can use the default log format, select a predefined format, or edit
custom format.
Depending upon the configuration, the IP address of a service, client IP address, or server IP address can be either IPv4 or IPv6.

2. In the Logs Format section, select a format for the log. For more information on how you can edit customized formats, see the online
help.
3. Click Save.
Table of Log Formats

The following table describes the names and values for each logs:
System Logs Web Firewall Logs Access Logs Audit Logs
%ei - Event ID %ai - Application IP %ai - Application IP %add - Additional Data
%ll - Log Level %ap - Application Port %ap - Application Port %an - Admin Name
%ms - Message %at - Action Taken %au - Authenticated User %cht - Change Type
%md - Module Name %ad - Attack Description %br - Bytes Received %ct - Client Type
%t - Time Stamp %adl - Attack Details %bs - Bytes Sent %cn - Command Name
%ag - Attack Group %ch - Cache Hit %seq - Log ID
%aid - Attack ID %cu - Certificate User %li - Login IP
%au - Authenticated User %ci - Client IP %lp - Login Port
%ci - Client IP %cp - Client Port %lt - Login Type
%cp - Client Port %c - Cookie %nv - New Value
%fa - Follow-up Action %ct - Content Type %on - Object Name
%seq - Log ID %cs1 - Custom Header 1 %ot - Object Type
%lt - Log Type %cs2 - Custom Header 2 %ov - Old Value
%m - Method %cs3 - Custom Header 3 %t - Time Stamp
%p - Protocol %h - Host %tri - Transaction ID
%px - Proxy IP %s - HTTP Status %trt - Transaction Type
%pp - Proxy Port %id - Login ID %un - Unit Name
%r - Referer %seq - Log ID %var - Variable
%ri - Rule ID %lt - Log Type
%rt - Rule Type %m - Method
%sid - Session ID %p - Protocol
%sl - Severity Level %pf - Protected Field
%t - Time Stamp %px - Proxy IP
%u - URL %pmf - Profile Matched Field
%ua - User Agent %pp - Proxy Port
%un - Unit Name %q - Query
%r - Referer
%rr - Request Referer
%rtf - Response Type Field
%sid - Session ID
%si - Server IP
%sp - Server Port
%st - Server Time
%t - Time Stamp
%tt - Time Taken
%u - URL

%ua - User Agent
%un - Unit Name
%v - Version
%wmf - WF Matched Field

How to Make the Client IP Address Available to the Back-end Server
For Layer 4 - UDP and Layer 4 - TCP services, the actual client IP address is passed to the server in the TCP header. No further configuration is
necessary for Layer 4 services.
For all other service types (i.e., when deployed in proxy mode), the default behavior is that the outgoing interface of the Barracuda Load Balancer
ADC is used for connections with the real servers. In certain cases, you may want the Barracuda Load Balancer ADC to connect to the server
using the client IP address. If you have servers on the back-end that need to access the actual client IP address, there are two ways to provide it
to the servers:
Client Impersonation
X-Forwarded-For Header
Consider the following before deciding which option to configure:
Client Impersonation X-Forwarded-For Header
Provides the client IP address as the source IP address of the Provides the client IP address in the X-Forwarded-For header of
request. every request.
Requires a networking change. Requires a logging change.
Performance impact. Layer 7 HTTP and HTTPS services only
Configuring Client Impersonation
You can configure the Barracuda Load Balancer ADC to connect to a server using the client IP address. When the server responds to a message
using that original client IP address, the traffic will go directly to the client. However, the client is expecting the response from the Barracuda Load
Balancer ADC. In order for the return traffic to pass through the Barracuda Load Balancer ADC, you must change the default gateway of each
real server in the pool to a custom virtual interface on the Barracuda Load Balancer ADC. The custom virtual interface should associate an
externally-accessible IP address with the Internet-facing port.
To use the client IP address for connections:
1. On the web interface of the Barracuda Load Balancer ADC:

Enable the Client Impersonation option for each server. Edit the server (from the BASIC > Services page). On the
Server Configuration page, set Client Impersonation to Yes.
2. On the server:
Change the default gateway to the corresponding custom virtual interface on the Barracuda Load Balancer ADC.
To Use the Client IP address from the X-Forwarded-For Header
By default, the client IP address is inserted by the Barracuda Load Balancer ADC in the X-Forwarded-For header when the request is forwarded
to the back-end server.
To use the embedded IP address with Apache servers or with IIS 7 or IIS 7.5 servers, refer to the following articles:
Logging Actual Client IP Address on the Apache Server

Logging Actual Client IP Address In the IIS 7 and IIS 7.5 Server
How to Log Client IP Address when there is a Proxy Server between the Clients and the Barracuda Load Balancer ADC
If the Barracuda Load Balancer ADC or the client is deployed behind a proxy server, the client IP address of incoming requests is the address of
the proxy server. You can see this address in the Client IP column on the BASIC > Access Logs page. To log the actual client IP address
instead, edit the service, and specify the name of the header containing the actual client IP address that the proxy server inserts in each request.
To Configure the Header Name:
1. Edit the service from the BASIC > Services page.

2. Specify the header name in the Client IP Header box. Usually the header that stores the actual client IP address is either X-Forwarded-F
or or X-Client-IP.
When a request is received, the Barracuda Load Balancer ADC examines the specified header, retrieves the actual client IP address, and logs it.
For example, consider the client IP addresses 174.15.230.2 and 174.15.230.3, and proxy IP address 174.15.230.254. When the client sends a
request, the proxy receives the request and stores the IP address of the client in the X-Forwarded-For or X-Client-IP header, and forwards the
request to the Barracuda Load Balancer ADC. The Barracuda Load Balancer ADC extracts the client IP address from the specified header and
logs it. It can also be configured to forward the address to the back-end server.
Scenario 1 - Clients behind Proxy Server

Scenario 2 - Barracuda Load Balancer ADC behind Proxy Server


Logging Actual Client IP Address In the IIS 7 and IIS 7.5 Server
By default, the Barracuda Load Balancer ADC forwards the client IP address in the X-Forwarded-For header.
To record the actual client IP address instead of the Barracuda Load Balancer ADC's custom virtual interface IP address in the IIS logs, do the
following:
1. Download and Install the Microsoft Advanced Logging extension on the IIS 7.5 server. Alternatively, download the 64bit MSI Package.
2. Once advanced logging is installed, restart the IIS manager.
3. Select the server root and then Advanced Logging. Select the individual website if you wish to enable and configure advanced logging
options at the site level instead of server level.
4. In the Advanced Logging window, select the default log definition (%COMPUTERNAME%-Server) and select the Enable Advanced
Logging and Enable Client Logging options in the Actions pane. You can also create a new log definition and apply it to the server.
5. Click the Edit Logging Fields… option. In the Edit Logging Fields window, note that the default Client IP uses the TCP client IP
address to log the IP address in log files. Select the Client IP field and click Remove.
6. Click Add Field to define the custom Client IP field. In the Add Logging Field window, specify values for all parameters and click OK.
7. In the Advanced Logging page, double-click log definition. The Log Definition window appears. Select the field you created from the S
elected Fields section and click Edit.
8. In the Edit Field window, enter the Log header name, select the Required check box and click OK.
9. Toggle advanced logging by disabling and enabling it in the Actions pane.
10. Access the website and then click View Log Files in the Actions pane to view the actual source IP address in the log file.

Logging Actual Client IP Address on the Apache Server

To extract and log the actual client IP address from the X-Forwarded-For header of a request using an Apache server, make the following
changes to the server:
1. Log into the Apache server.

2. Go to /etc/httpd/conf or /usr/local/apache2/conf path and open the file httpd.conf.
3. Search for the string: “LogFormat “%h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\"" combined”
4. Change the %h to %{X-Forwarded-For}i. The string now appears as “LogFormat "%{X-Forwarded-For}i %l %u %t \"%r\" %>s %b
\"%{Referer}i\" \"%{User-Agent}i\"" combined”
5. Save the file and restart either apache or httpd.

How to Mask Sensitive Data in Logs
Masking cannot be applied to sensitive data in custom parameters or custom headers.

After data is masked, it cannot be retrieved, recovered, or restored.
You can configure the Barracuda Load Balancer ADC to mask sensitive data before logging it. Sensitive data such as credit card information,
U.S. Social Security numbers (SSNs), or other proprietary data in the URL parameters of a request can be masked. Data masking is configured
for an application using parameter names to specify sensitive data.
To configure data masking:
1. Go to the SECURITY > Advanced Security page.

2. In the Mask Sensitive Data section, click Edit in
the row for the virtual service that requires data masking.
3. In the Mask Sensitive Data window, enter the names of the parameters to mask. You can provide
multiple parameter names separated by commas with no spaces between them. (for example: cardId,
securityNumber,password).
4. Click Save.
On the BASIC > Access Logs page, the sensitive data will be overwritten by Xes.

Viewing Logs on the Barracuda Load Balancer ADC
System Logs
To view system logs, go to the ADVANCED > System Logs page.
Web Firewall Logs
All web firewall actions and events are logged under Web Firewall Logs. Use these logs to analyze traffic for suspicious activity and tune the web
firewall policies.
To view these logs, go to the BASIC > Web Firewall Logs page. This log data is obtained from the log database on the Barracuda Load
Balancer ADC itself.
Unit Name, Log Type, and Log ID are not displayed on the BASIC > Web Firewall Logs page.
Access Logs
All web traffic activities are logged under the Access Logs. Use these logs to obtain information about the website traffic and performance.
To view access logs, go to the BASIC > Access Logs page.
Audit Logs
Changes that are initiated by a system administrator on the Barracuda Load Balancer ADC are logged in the Audit Logs.
To view audit logs, go to the BASIC > Audit Logs page.
Network Firewall Logs
The Network Firewall Logs contain information on network traffic that passes through the interfaces (MGMT and configured interfaces) and
matches configured network ACL rules.
To view Network Firewall Logs, go to the NETWORK > Network Firewall Logs page.

System Log Messages
The following is the list of system log messages which includes:
Log Category - The Severity Level of the log.

Log ID - The Event ID of the log.
Log Message - Description about the log.
Log Category Log ID Log Message
SYSTEM
LOG_NOTICE 1003 Mem Start: SCB <Start Address>, Low

<Start Address>, High <Start Address>
LOG_INFO 1012 EVENTID_SYS_SHUTDOWN - Secure

Traffic Manager is exiting
LOG_CRIT 1013 System startup failed at initializing: <stage>.

Switching to maintenance mode
LOG_NOTICE 1024 Activate: Default boot image set to <Image

Name>
LOG_ALERT 1119 (System is getting real hot) or (Possible

overheating at device <device-name> temp
reading=<temp in 'C>)
LOG_INFO 1122 This Hardware =<component-name> is not

on the Board
LOG_ALERT 1125 SBC PII temp overshoot.
LOG_ALERT 1126 System highest temp has reached =

<External temp 'C> <Internal Temp in 'C>
LOG_ALERT 1128 In Fan Group <Group ID> Fan <Fan ID> is

Running at <Current Value> rps which is less
than expected <default value>
LOG_NOTICE 1130 HW: Changing FAN speed <Old Value> ->

<New Value> TempReadings (<Max internal
'C> <Max External temp in 'C>])
LOG_NOTICE 1203 SBC FAN <fan-name> detected rpm = <rpm

value>
LOG_WARN 41001 Cookie Encryption Key is going to expire

within <Number> days",
REMAINING_DAYS_FOR_EXPIRY(
pSharedKey->keyExpiryTimeout,curTimeInS
ecs)
MONITOR
LOG_CRIT 1014 [MON]: Shutting down all services
LOG_NOTICE 1014 [MON]: Shutting down services completed
LOG_NOTICE 1015 [MON]: Restarting services
LOG_NOTICE 1015 [MON]: Restarting services completed
LOG_ERROR 27001 SetMonitorAttributes: NULL monitor id\n
LOG_INFO 27001 SetMonitorAttributes: monitor (id

0x<internal-handle>) already exists. Deleting
it
LOG_INFO 27002 Monitor (0x<internal-handle> - <IP:Port>)

status is FEHC_INACTIVE

LOG_INFO 27002 Monitor (0x<internal-handle>) to <IP:Port>

freed
ARP
LOG_WARN 4011 arprequest for <IP Address> failed with no

memory
LOG_INFO 4012 ether address is broadcast for IP address

<IP Address>
LOG_ERROR 4013 <Host IP Address> is using my IP address

<IP Address>
LOG_ERROR 4014 Failed to find route for arp response to client

<IP Address>
LOG_WARN 4015 arp: <MAC Address> attempts to modify

permanent entry for <IP Address> on
<Interface Name>
LOG_WARN 4016 arp_rtrequest: bad gateway value
LOG_ERROR 4017 arpresolve: can't allocate info for <IP

Address>, rt=<route>
LOG_ERROR 4017 arp_rtrequest: malloc failed
CACHING (CACHE)
LOG_NOTICE 6001 System Low on Memory: Adjusting Cache

Parameters - Current Max:<Max Size>,
High:<High Water Mark>, Safe<Safe Water
Mark>
LOG_NOTICE 6001 System Low on Memory: Adjusting Cache

Parameters - New Max:<Max Size>,
High:<High Water Mark>, Safe<Safe Water
Mark>
LOG_NOTICE 6002 Cache Purged
LOG_NOTICE 6003 Cache purge failed: instance <Count>, thid

<Thread ID>, table <Table ID>, target
<Size>, collected <Freed Size>
LOAD BALANCER (LB)
LOG_ALERT 7005 Server <IP Address>:<Port> is enabled
LOG_ALERT 7006 Server <IP Address>:<Port> is disabled.

New mode <Operational Mode>
LOG_NOTICE 7007 Server <IP Address>:<Port> is created
LOG_ALERT 7008 Server <IP Address>:<Port> is deleted
WEBLOG
LOG_WARN 9001 Configurations for start or stop time *MAY*

not be proper.
LOG_ERROR 9003 Error: Unable to establish control connection.
LOG_ERROR 9004 Error: Unable to establish data connection
LOG_ERROR 9005 Error: Unable to establish ssl control

connection
LOG_ERROR 9006 Error: Unable to authenticate the user
LOG_ERROR 9007 Error: Unable to transfer data to ftp server:

<IP Address>

LOG_ERROR 9009 Connection to <IP Address> failed, error

code = <Error Code>
LOG_ERROR 9009 SSL Connection to <IP Address> failed
LOG_ERROR 9010 Out of memory for formatting logs
LOG_INFO 9011 ---- START OF LOG STATS FOR LOGS

EXPORTED TO <IP Address>:<Port> ----
LOG_INFO 9011 Connection to <IP Address>failed, error code

=<Error Code>
LOG_INFO 9011 Total number of logs: <Number>
LOG_INFO 9011 Total number of formatted: <Number>
LOG_INFO 9011 Total number of dropped: <Number>
LOG_INFO 9011 Total number of long url logs: <Number>
LOG_INFO 9011 Total number of control connection attempts

to the ftp server: <Number>
LOG_INFO 9011 Total number of control connections

successes: <Number>
LOG_INFO 9011 Total number of data connections:

<Number>
LOG_INFO 9011 Total number of 4xx errors: < number >
LOG_INFO 9011 Total number of 5xx errors: <Number>
LOG_INFO 9011 Total number of ftp failures: <Number>
LOG_INFO 9011 Total number of requests: <Number>, Total

duration: <Duration> secs
LOG_INFO 9011 ---- END OF LOG STATS FOR LOGS

EXPORTED TO <IP Address>:<Port> ----
LOG_INFO 9012 Web Logging enabled
LOG_NOTICE 9013 Dropping logs, running low on memory
LOG_ERROR 9013 Error in hash generation or encryption
LOG_NOTICE 9014 Logging parameters are set for vip <IP

Address>:<Port>
LOG_INFO 9017 FTP Session to <IP Address>, status code =

<FTP Status>
LOG_ERROR 9018 Unable to log the request since FTP server is

slow or unreachable
LOG_ERROR 9018 Dropping logs since queue is full
LOG_ERROR 9019 Signature generation of logs failed
EVENT MANAGER (EVM)
LOG_ERROR 11001 Event Manager startup failure: could not

handle signals
LOG_INFO 11005 Forwarding log messages to syslog

host[<index>]=<ip_address>,
facility=<facility> (socket=<socket_id>)
LOG_ERROR 11007 EnableSyslogService: create socket failed
LOG_ERROR 11008 fopen <log_filename>: <error_description>

LOG_ERROR 11009 <log_filename> write failed

<error_description>
CONFIG AGENT (CONFIG)
LOG_ERROR 12001 Digest failed
LOG_ERROR 12001 Configuring Secure Traffic Manager

Succeeded
LOG_ERROR 12002 Service
LOG_ERROR 12002 Duplicate parameter
LOG_ERROR 12002 VSite
LOG_ERROR 12002 Target doesn't exist
LOG_ERROR 12002 Backup
LOG_ERROR 12002 Deleting Server
LOG_ERROR 12002 Server delete succeeded
LOG_ERROR 12002 Unable to delete Server
LOG_ERROR 12002 Deleting Service
LOG_ERROR 12002 Service delete succeeded
LOG_ERROR 12002 Unable to delete Service
LOG_CRIT 12003 Failed to retrieve initial groups
LOG_INFO 12003 Failed to retrieve User’s Realms
LOG_ERROR 12004 Can't store rule ID
LOG_INFO 12004 Adding RuleGroup
LOG_ERROR 12005 Can't get " NEXTSAPID ": missing " SAPID "
or error retrieving " SAPID
LOG_ERROR 12007 Target doesn't exist
LOG_ERROR 12007 Failed to create server
LOG_ERROR 12007 SetServerConnAttr failed
LOG_ERROR 12007 SetServerRedirectAttr failed
LOG_ERROR 12007 SetServerOutOfBandMonitorAttr failed
LOG_ERROR 12007 SetServerMonitorAttr failed
LOG_ERROR 12007 SetServerLBAttr failed
LOG_ERROR 12007 StartServer failed
LOG_ERROR 12007 SetServerSSLServicePolicy failed
LOG_ERROR 12007 SetServerSSLServiceOn failed
LOG_ERROR 12007 SetServerSSLServiceOff failed
LOG_ERROR 12007 ActiveServerOutOfBandMonitorAttr failed
LOG_ERROR 12007 Failed to delete server
LOG_ERROR 12007 Failed to reset server ip, port or vlan
LOG_ERROR 12007 Failed to look up server
LOG_ERROR 12007 SetServerTcpMonitorAttr failed

LOG_ERROR 12007 EnableServer failed
LOG_ERROR 12007 DisableServer failed
LOG_ERROR 12007 Failed to delete server
LOG_ERROR 12007 Failed to reset server ip, port or vlan
LOG_ERROR 12007 Failed to look up server
LOG_ERROR 12007 SetServerTcpMonitorAttr failed
LOG_ERROR 12007 EnableServer failed
LOG_ERROR 12007 DisableServer failed
LOG_ERROR 12007 Server
LOG_ERROR 12008 Duplicate server
LOG_ERROR 12008 Attaching server
LOG_ERROR 12008 Attaching server succeeded
LOG_ERROR 12008 Failed to look up back-end server
LOG_ERROR 12008 Detaching server
LOG_ERROR 12008 Detaching server succeeded
LOG_ERROR 12009 OUT OF MEMORY !!! Asserting…
LOG_ERROR 12009 Error in reading ReadXmlFileIntoString
LOG_ERROR 12009 sapIndex.AddFromXMLStr (..., SAP::nsap)

failed
LOG_ERROR 12009 Error. AddFromXMLStr failed !
LOG_ERROR 12009 Cannot modify a read-only node
LOG_ERROR 12009 No path provided
LOG_ERROR 12009 Failed due to insufficient user permission
LOG_ERROR 12009 Internal error while adding a child node!
LOG_ERROR 12009 Internal error: while parsing query!
LOG_ERROR 12009 No Parameter found for querying
LOG_ERROR 12009 No path provided
LOG_ERROR 12009 Internal error while adding a child node!
LOG_ERROR 12009 Invalid or non existent home dir found !
LOG_ERROR 12009 GetPathForUser failed
LOG_ERROR 12009 Context doesn't exist !
LOG_ERROR 12009 CheckPerm failed for path
LOG_ERROR 12009 Unable to allocate memory
LOG_ERROR 12009 OUT OF MEMORY !!! Asserting...
LOG_ERROR 12009 in PutSAPTree. GetHomeDirForUser failed !

LOG_ERROR 12009 In PutSAPTree. Invalid path specified !
LOG_ERROR 12009 in PutSAPTree. No acl perm
LOG_ERROR 12009 in PutSAPTree.ModifySAP failed
LOG_ERROR 12009 in PutSAPTree. Trying to modify a read-only

node
LOG_ERROR 12009 in PutSAPTree.AddChildSAP failed
LOG_ERROR 12009 in PutSAPTree.DeleteSAPTree failed
LOG_ERROR 12009 PutRootSAPTree failed in GetAggSAP
LOG_ERROR 12010 Rule Group
LOG_ERROR 12010 Duplicate application
LOG_ERROR 12010 Failed to find back-end server in server list
LOG_ERROR 12010 Failed to look up Secure Traffic Manager

object
LOG_ERROR 12011 Couldn't add paramSAP, name:
LOG_ERROR 12018 Invalid Path Specified
LOG_ERROR 12018 Internal Error
LOG_ERROR 12018 Invalid Path Specified
LOG_ERROR 12019 Unable to allocate memory
LOG_ERROR 12021 in ParamCmp. Cant modify node attributes
LOG_ERROR 12021 Incorrect permissions given to root role
LOG_ERROR 12021 Cannot modify ACL for root node
LOG_ERROR 12021 Cannot give write permissions for a

read-only node.
LOG_ERROR 12021 in ParamCmp. Cant modify node attributes
LOG_ERROR 12021 in AggCmp. Cant modify node attributes
LOG_ERROR 12021 Incorrect permissions given to root role
LOG_ERROR 12021 Cannot modify ACL for root node
LOG_ERROR 12021 Cannot give write permissions for a

read-only node
LOG_ERROR 12024 Backup rule group cannot be the same as

the primary rule group
LOG_NOTICE 12040 Processing messages in the list
LOG_INFO 12049 Received SIGTERM
LOG_INFO 12049 Received SIGALRM
LOG_NOTICE 12049 Processing messages in the list failed.

Ignoring the error
LOG_NOTICE 12049 Starting main message processing loop
LOG_INFO 12049 Termination requested by the signal handler
LOG_ERROR 12053 Failed to initialize signal handlers
LOG_ERROR 12053 Failed to digest initial configuration
LOG_ERROR 12053 Termination requested by the signal handler

LOG_ERROR 12054 GetCmdGrpXML failed
LOG_ERROR 12054 sapIndex.AddFromXMLStr(..., \"nc:ncRoot\")

failed
LOG_ERROR 12054 Usage: sap_initdb xmlFile
LOG_ERROR 12054 Failed to initialize the sessions DB
LOG_ERROR 12054 Failed to initialize SAP DB
LOG_ERROR 12057 Can't store vhid
LOG_ERROR 12057 Updating virtual host id is not supported
LOG_ERROR 12057 VirtualHostId
LOG_ERROR 12057 VirtualHost
LOG_ERROR 12066 Socket::WritePktToSocket - sockfd == -1
LOG_ERROR 12067 Failed to look up associated application
LOG_ERROR 12067 Adding Application
LOG_ERROR 12067 Rule Group
LOG_ERROR 12067 No such object
LOG_ERROR 12068 Rule
LOG_ERROR 12068 No rules
LOG_ERROR 12068 Failed find back-end server in server list
LOG_ERROR 12081 Finalize succeeded!
LOG_ERROR 12083 Failed to look up Secure Traffic Manager

object
LOG_ERROR 12083 No such object
HTTP
LOG_DEBUG 13102 Server <IP Address:Port> prematurely

closes the connection
LOG_WARN 13103 OnHttpServerSockRecv: Session timed out

from <Client IP:Port>
HTTPSVC
LOG_ERROR 0 Bind failed due to 98 (Unable to connect to

the back-end server using the TCP port that
the client used while sending the request.).
SMTP
LOG_INFO 13201 QUIT command received before EHLO

command
LOG_INFO 13202 Backend server supports AUTH
LOG_INFO 13203 Client has not sent EHLO command as the

first command
LOG_INFO 13204 AUTH mechanism other than PLAIN/LOGIN

has been requested when WSG does
user-authentication
LOG_INFO 13205 Using PLAIN authentication mechanism
LOG_INFO 13206 Using LOGIN authentication mechanism

LOG_INFO 13207 User authentication failed
HEARTBEAT (HB)
LOG_ERROR 15001 Heartbeat events dropped, queue is full
LOG_ERROR 15002 Unable to bind to address
LOG_ERROR 15003 Error sending packet
LOG_INFO 15003 Opening the Heartbeat Connection pci port
LOG_INFO 15003 Closing the Heartbeat Connection pci port
LOG_INFO 15003 Unable to close Heartbeat connection pci

port
LOG_INFO 15003 Ignoring Heartbeat Connection close

command pci port
LOG_INFO 15003 Received data before initialization
LOG_ERROR 15003 Error receiving data From remote gateway
LOG_ERROR 15004 Attempting to reinitialize the Heartbeat

Server before closing
LOG_ERROR 15004 Attempting to send data without Initialization
CERTIFICATE (CERT)
LOG_NOTICE 17500 Cert Initialization
SSL
LOG_NOTICE 13200 Can not connect to server (<Error Code>) for

connection from: <Client IP Address>
LOG_NOTICE 13200 SSL connection to server for connection

from: <Client IP Address> failed
LOG_NOTICE 13200 Error connecting to server (<Error Code>) for

LOG_NOTICE 13200 Error opening SSL connection to server for

LOG_NOTICE 13200 SSL accept failed for connection from:

<Client IP Address>
LOG_NOTICE 13200 Error switching connection from: <Client IP

Address > to SSL
LOG_NOTICE 13200 Error accepting SSL connection from: <Client

IP Address >
LOG_INFO 13200 QUIT command received before switching to

SSL
LOG_NOTICE 16001 <ssl-function-name>: Base 0x<ssl-handle> -

Access denied: received bad certificate
signature

Access denied: failed to verify certificate
signature

Access denied: certificate chain too long

Access denied: failed to decode certificate


Access denied: no certificate

Access denied: failed to validate certificate
chain

Access denied: <Error Code>

Sending alert: <Alert-desc> (<Alert Code>)
from [<IP Address>:<Port>]

Received alert: <Alert-desc> (<Alert Code>)
from [<IP Address>:<Port>]
LOG_DEBUG 16010 <ssl-function-name>: Base 0x<ssl-handle> -

New SSL socket 0x<ssl-socket-handle> for
<Client IP:Port>

No RSA private key available

Mismatched key size <Size> (expected
<Size>)

Failed to get authority private key

Called on a client socket

Called on a server
LOG_ERROR 16013 <ssl-function-name>: Out of memory
LOG_ERROR 16013 <ssl-function-name>: Base 0x<ssl-handle> -

Out of memory
LOG_ERROR 16013 <ssl-function-name>: Socket

0x<sslsock-handle> - Out of memory
LOG_NOTICE 16014 <ssl-function-name>: Incorrect server name:

length should be between 0 and < length >
LOG_ERROR 16016 <ssl-function-name>: Base 0x<ssl-handle> -

Failed to schedule crypto command
LOG_NOTICE 16019 < ssl-function-name >: Cannot configure

more than <Number> certificate policies
LOG_NOTICE 16020 <ssl-function-name>: Cannot configure more

than <Number> trusted certificates per
service
LOG_NOTICE 16021 <ssl-function-name>: No available SSL

version for client socket
LOG_NOTICE 16023 <ssl-function-name>: Ephemeral Key

changed

No ephemeral key available
LOG_NOTICE 16500 SSL Initialization

LOG_NOTICE 17001 <ssl-function-name>: Trusted certificate

expired: CN=<Common Name>, OU=<Org
Name >
LOG_NOTICE 17001 <ssl-function-name>: Trusted certificate

expired: O=<Org Name> L=<Location>
S=<State> C=<City>
STM
LOG_ERROR 13100 HttpServerParseRequest: Parse failed;

Malformed version <request-buffer>

Unknown major number <request-buffer>

Unknown minor number <request-buffer>

Unknown method: <request-buffer>

Malformed URL <request-buffer>

Malformed line end <request-buffer>
LOG_ERROR 13101 HttpClientParseResponse: Parse failed;

Malformed version <request-buffer>

Unknown major number <request-buffer>

Unknown minor number <request-buffer>

Malformed status code <request-buffer>

Header: <request-buffer>

Malformed line end <request-buffer>
LOG_NOTICE 14001 New Service (ID 0x<vip-context>) Created at

<IP Address>:<Port>
LOG_ERROR 14001 Failed to Create Service at <IP

Address>:<Port>
LOG_NOTICE 14002 Service Started <IP Address>:<Port>
LOG_ERROR 14003 Failed to Delete Service (ID 0x%08x) at <IP

Address>:<Port>
LOG_ERROR 14004 Failed to Create Rule at <IP

Address>:<Port>
LOG_NOTICE 14004 New Rule (ID 0x<rule-context>) Created at

<IP Address>:<Port> for ID 0x<vip-context>
LOG_NOTICE 14005 <Not Commited | Commited> Rule: URL

[<URL Key>] Header [<Extended match
key>]
LOG_ERROR 14007 Failed to Create Service at <IP

Address>:<Port>
LOG_NOTICE 14007 New Vapp (ID 0x<vapp-context>) Created at

<IP Address>:<Port> for ID 0x<vip-context>

LOG_NOTICE 14008 Failed to commit Application: Domain

[<Application Rule Domain>] URL
[<Application Rule URL>]
LOG_ERROR 14009 Failed to Delete Vapp (ID 0x<vapp-context>)

at <IP Address>:<Port> Domain
[<Application Rule Domain>] URL
[<Application Rule URL>]
LOG_INFO 25200 getServerBySrcIPPort: ClntIp 0x<IP

Address> ClntPort 0x<port> Svr NULL
LOG_INFO 25200 bindServerBySrcIPPort: SvrIP 0x<IP

Address> SvrCookId <internal-id> SvrId
<internal-return-value>
AAA
LOG_INFO 18201 User <User ID> logged in
LOG_INFO 18202 Password changed successfully for User

<User ID>
LOG_ERROR 18203 Unable to contact the authentication server,

(RPC Queue full)
LOG_ERROR 18204 Remote procedure call to authentication

server timed out
LOG_ERROR 18205 Login attempt failed for user <User ID>
LOG_ERROR 18206 Changing password failed for user <User ID>
LOG_NOTICE 18207 Added a realm:<Realm ID>
LOG_ERROR 18208 Unable to add realm:<Realm ID>
LOG_NOTICE 18209 Deleted a realm:<Realm ID>
LOG_DEBUG 18210 Session created for user <User ID>
LOG_DEBUG 18211 Number of current users sessions =

<Number of User Sessions>
LOG_DEBUG 18212 Session destroyed for user <User ID> in

realm <Realm ID>
LOG_DEBUG 18213 Session exists for user <User ID>
LOG_DEBUG 18214 Session does not exist for user session id

<Session ID>
LOG_ERROR 18215 Error received from webauthd , <Error

String>
LOG_NOTICE 18216 Insert into ptrie - allocation failed (flags:

0x<internal-flags-value>, mem:
<internal-mem-handle>) "Creating
AuthzCache - inserting into ptrie
failed(nodes: <internal-node-handle>,
<internal-node-handle>
LOG_NOTICE 18217 Client attempted to Logout without login

session cookie\n
LOG_WARN 18218 Invalid external policy store configured,

realm name = <realm-name>
IPS

LOG_NOTICE 19031 XML Firewall error: <error-string> ( offset:

<offset number>, code: <error code>
)",pErr->desc,( int )pErr->offset, pErr->code
LOG_NOTICE 19031 XML Firewall error: Input validation
LOG_NOTICE 19031 XML Firewall error: Attack pattern
LOG_NOTICE 19031 XML Firewall error: Operation denied
LOG_ERROR 19032 Failed to allocate NCFORMINFO buffer
LOG_ERROR 19032 Unable to add session param to

NCFORMINFO (no-name param)
LOG_ERROR 19032 Failed to allocate NCFORMINFO buffer(resp)
LOG_ERROR 19032 Unable to add session param to

NCFORMINFO (multi-value)
LOG_ERROR 19032 Failed to allocate buffer for response URL

rewrite
LOG_ERROR 19032 Failed to allocate buffer for form encryption
LOG_WARN 19500 Could not cloak match for %s. Value of Initial
or Trailing Characters to Keep is too large
LOG_WARN 19500 POST request with both Content-Length and

Transfer-Encoding headers [ url:
<URL|Malformed URL> ], dropped
LOG_WARN 19500 No intrusion information for %d", intrusion
COOKIE
LOG_ALERT 20002 Session cookie decryption failed
LOG_ALERT 20003 Cookie expires: Client <IP Address>
LOG_ALERT 20004 Cookie auth failed: cookiename auth failed
LOG_ALERT 20005 Cookie Length Overflow: Client <IP

Address>
LOG_ERROR 20006 Failed to allocate Shared Key context for

cookie encryption
FTP PROXY (FTPPXY)
LOG_INFO 21002 <FTP Module Name>:created ftp proxy

session client-ip:<Client IP Address> VhId =
<Internal ID>
LOG_INFO 21003 Closing server session
LOG_INFO 21004 Control connection established with the FTP

server, <Interface IP Address> <Server IP
Address> <Server Port>
LOG_INFO 21005 Back-end FTP server connection has timed

out
LOG_INFO 21005 Closing connection to the FTP server
LOG_INFO 21005 FTP server closed the control connection
LOG_INFO 21006 Established data connection to FTP client

<Client IP Address>
LOG_INFO 21008 Established data connection to FTP server

<Server IP Address>

LOG_INFO 21010 Data transfer completed successfully
LOG_ERROR 21011 Error while transferring data
LOG_INFO 21012 Received the FTP command
LOG_WARN 21014 <Internal Session ID>:Invalid client

ip-address (<IP Address>) specified with the
port command, actual client ip-address is
(<IP Address>)
LOG_WARN 21014 <Internal Session ID>:Invalid port (<Port>)

specified with the port command, port value
must be greater than 1024
LOG_WARN 21014 <Internal Session ID>:Invalid ip-addr (<IP

Address>) used to connect to listening ftp
data socket, expected from (<IP Address>)
LOG_INFO 21015 <Internal Session ID>:Sent the FTP

response (<Response String>)
LOG_INFO 21016 Established SSL data connection with the

FTP client, <Client IP Address>
LOG_INFO 21016 Established SSL control connection with the

FTP client
LOG_INFO 21018 Established SSL control connection with the

FTP server
LOG_DEBUG 21020 Command sent to FTP server
LOG_DEBUG 21021 Client received <number> bytes on control

connection
LOG_ERROR 21022 Unable to allocate state control block for a

session
LOG_ERROR 21022 Unable to allocate memory for ftp session
LOG_ERROR 21022 Out of memory
LOG_ERROR 21022 <Service IP Address:Port>:Unable to

allocate memory for PORT cmd to FTP
server

allocate memory for SSL verbs

allocate memory for PORT cmd to FTP
server
LOG_ERROR 21023 Unable to get an active back-end server
LOG_ERROR 21024 Failed to create new socket
LOG_ERROR 21024 Failed to create SSL socket
LOG_ERROR 21024 Failed to create ssl client socket for data

connection
LOG_ERROR 21025 Unable to bind a server for data connection
LOG_ERROR 21025 Unable to setup data connection
LOG_ERROR 21026 Failed to connect to FTP server
LOG_ERROR 21026 Unable to establish SSL control connection

with the FTP server

LOG_ERROR 21026 Unable to connect to FTP server <Server IP

Address>
LOG_ERROR 21027 Unable to accept SSL connection from FTP

client
LOG_ERROR 21028 Failed to send response to the client
LOG_ERROR 21028 Failed to send control data to the server,

because of small TCP windows
LOG_ERROR 21028 Failed to send data to the FTP client on the

data connection
LOG_ERROR 21029 Failed to receive data from the FTP client on

the data connection
LOG_ERROR 21029 Failed to receive data from FTP server on

the data connection
LOG_ERROR 21030 Received bad response codes from the FTP

server
COMPRESSION (COMPRESS)
LOG_ERROR 24001 Compression request errored, <Error Code>,

<Error String>
LOG_INFO 24004 Part of the response data not submitted for

compression
LOG_ERROR 24006 Failed to initialize compression, switching

back to no-compression mode
REWRITE
LOG_INFO 26001 Rewrite Module: Low on Memory.
LOG_INFO 26001 <rewrite-module-name>: ReqCtx

0x<internal-reqctx-handle>, Error in ncvbuf
handling
LOG_ERROR 26051 Rewrite Module: URL rewrite by both

Url-Translation and Request Rewrite
LOG_ERROR 26052 Rewrite Module: HTTP header rewrite by

both URL-translation and Request Rewrite.
Please go over your configuration to see if
this can be avoided
LOG_INFO 26053 Response Body Rewrite: Replaced \"<find

buffer>\" with \"<replace buffer>
ROUTE
LOG_ERROR 3011 rn_addmask: mask impossibly already in tree
LOG_ERROR 3011 Mask for route not entered
LOG_ERROR 3012 rn_delete <Node Info>: Orphaned Mask

<node-info> at <Node Info>
LOG_ERROR 3013 rn_init: radix functions require max_keylen

be set
INTERFACE (IF)
LOG_ERROR 3002 failed to attach interface <Interface Name>
LOG_NOTICE 3003 <Interface Name>: promiscuous mode

enabled
ICMP

LOG_INFO 4001 redirect from <-address>: <Destination

Address> => <Gateway Address>
IP
LOG_ERROR 4033 can't find virtual host for route, dst = <IP
Address>
LOG_NOTICE 4034 ipflow to <IP Address> reached max refs
LOG_NOTICE 4034 Copyright (c) 2001, 2002 Barracuda Inc.
LOG_NOTICE 4034 Copyright (c) 1982, 1986, 1993 The Regents

of the University of California
TCP
LOG_ALERT 4054 Detected a SYN attack, using SYN cookies
CRYPTO
LOG_DEBUG 5003 Setting Encrypt Context Failed
LOG_DEBUG 5003 Encrypt Update Failed
LOG_DEBUG 5003 Encrypt Failed
LOG_DEBUG 5004 Decrypt Failed
PROCMON
LOG_WARN 44001 'PROCMON' "STM crash detected current

state is: <STM State> state <Number>
crashes in last <Time in Seconds>"
LOG_WARN 44002 'PROCMON' "Total retries: <Number>

waiting for <Time in seconds> before next
restart"
LOG_WARN 44003 'PROCMON' "Too many <Number> tries to

restart unstable STM, switching to Failed
state"
LOG_WARN 44004 'PROCMON' "Too many STM crashes

switching to Unstable state, will attempt
restart in <Time in seconds>"
LOG_NOTICE 44005 'PROCMON' "Attempting to restart STM and

Eventmgr"
LOG_NOTICE 44006 'PROCMON' "Attempting to recreate the log

DB"
LOG_ERROR 44007 'PROCMON' "Error : <Error code>

encountered with stm start"
LOG_ERROR 44008 'PROCMON' "STM restart failed: switching

to Failed state"
LOG_ERROR 44009 'PROCMON' "STM restart failed: switching

to Failed state"
LOG_NOTICE 44010 'PROCMON' "STM restart succeeded:

current state: Stable"
LOG_WARN 44011 'PROCMON' "shmget failed
LOG_WARN 44012 'PROCMON' "number of stm worker threads

is <Number of STM Threads>"
LOG_WARN 44013 'PROCMON' "shmread error <Failure

Error>"

LOG_WARN 44014 'PROCMON' "STM worker thread <Number>

seems to be hung. Event count <Number>"
LOG_WARN 44015 'PROCMON' "STM seems to be hung.

Killing STM"
LOG_NOTICE 44016 'PROCMON' "STM alive: switching from

<STM State> to stable state"
LOG_WARN 44017 'PROCMON' "<Process Name> state is

<Process State>"
LOG_ERROR 44018 'PROCMON' "bypass_hbeat.pl is dead

restarting gpio and bypass_hbeat"
LOG_ERROR 44019 'PROCMON' "clamd is dead, restarting

<Process Name>"
LOG_ERROR 44019 'PROCMON' "snmpd is dead, restarting

<Process Name>"
LOG_ERROR 44020 'PROCMON' "profile agent is dead,

restarting <Process Name>"
LOG_ERROR 44021 'PROCMON' "collectd is dead, restarting

<Process Name>"
LOG_ERROR 44022 'PROCMON' "namemon is dead, restarting

namemon"
LOG_ERROR 44023 'PROCMON' "config agent is dead,

restarting config_agent and stm"
LOG_CRIT 50003 'PROCMON' "System highest temp has

reached = <Temperature>"
LOG_CRIT 50004 'PROCMON' "System is getting real hot =

<Temperature>"
LOG_CRIT 50003 'PROCMON' "System highest temp has

reached = <Temperature>"
LOG_CRIT 50004 'PROCMON' "System is getting real hot =

<Temperature>"
LOG_ALERT 50005 'PROCMON' "One of the CPU fans is dead"
LOG_ALERT 50005 'PROCMON' "One of the System fans is

dead"
LOG_ALERT 50007 'PROCMON' "Firmware storage exceeds

85%"
LOG_ALERT 50008 'PROCMON' "Mail storage exceeds 85%"
LOG_ALERT 50009 'PROCMON' "Log storage exceeds 85%"
LOG_ALERT 50010 'PROCMON' "One of the RAID arrays is

degrading"
LOG_WARN 44034 'PROCMON' "<Interface Name>: link seems

down"
LOG_ALERT 44035 'PROCMON' "<Interface Name>: link is

down"
LOG_NOTICE 44036 'PROCMON' "<Interface Name>: link is up"
LOG_NOTICE 44001 'PROCMON' "Checking if configuration

needs to be synchronized with peer system"

LOG_NOTICE 44001 'PROCMON' "Notifying peer system to

check if configuration needs to be
synchronized"
LOG_ALERT 44038 'PROCMON' "<Interface Name>: link is

down"
LOG_ERROR 44039 'PROCMON' "heartbeat.pl is dead

<Number>, restarting"
LOG_ERROR 44040 'PROCMON' "heartbeat.pl is in state D for

<Number> tick(s). Ignoring the state"
LOG_ERROR 44041 'PROCMON' "cluster_manager is dead

<Number>, restarting"
LOG_ERROR 44042 'PROCMON' "cluster_manager is in state D

for <Number> tick(s). Ignoring the state"
LOG_ERROR 44043 'PROCMON' "Restarting spinal cord process

since there may be an issue in connecting to
Control Center"
LOG_ERROR 44043 'PROCMON' "Restarting ssh"
LOG_NOTICE 44001 'PROCMON' "Checking if configuration

needs to be synchronized with peer system"
LOG_ERROR 44044 'PROCMON' "Configuration dispatcher is

dead <Number>, restarting"
LOG_ERROR 44045 'PROCMON' "Configuration dispatcher is in

state D for <Number> tick(s). Ignoring the
state"
LOG_ALERT 44046 'PROCMON' "STM seems to be running

high on Memory. Please contact to
Barracuda Support Center for analysis"
LOG_ALERT 44047 'PROCMON' "Memory Usage exceeds 70%"
LOG_NOTICE 44048 'PROCMON' "Monitoring links: <Link

Name>"
LOG_NOTICE 44049 'PROCMON' "Started monitoring"
LOG_EMERG 1105 <Process> is not present
LOG_NOTICE 1111 Process mon /proc error ret =<retcode>

comm=<commandid> pid=<process-id>
CLUSTER
LOG_NOTICE 43001 'CLUSTER' "We are not yet in cluster

mode. Could not calculate destination IP
and destination Identity. Exiting.."
LOG_NOTICE 43001 'CLUSTER' "Invalid Role :

<PRIMARY/BACKUP:self_role> specified in
cluster.conf. Could not determine self role.
Exiting.."
LOG_ERROR 43001 'CLUSTER' "cluster.conf file is not

existing...Exiting"
UPDATE
LOG_ALERT 44401 'UPDATE' "Energize update subscription is

about to expire in <Number> days"
LOG_ALERT 44402 'UPDATE' "New attack definition version

<Number> is available"

LOG_ALERT 44403 'UPDATE' "New firmware update is

available Current Version = <Version
Number> Beta Version = <Version
Number>"
LOG_ALERT 44404 'UPDATE' "New firmware update is

available Current Version = <Version
Number> New Version = <Version
Number>"
LOG_ALERT 44402 'UPDATE' "New Attack Def version

<Number> current_attack_def_version is
installed reboot appliance to apply attack
def"
BYPASS
LOG_ALERT 44221 'BYPASS' "Unit is switching to bypass

mode"
LOG_NOTICE 44222 'BYPASS' "State set to bypass: stopping

heartbeat"
LOG_NOTICE 44223 'BYPASS' "State set to normal: starting

heartbeat."
LOG_NOTICE 44201 'BYPASS' "Mode change: Hard bypass =

<Hard Bypass Enabled> Bypass on Failure =
<Soft Bypass Enabled>"
LOG_NOTICE 44202 'BYPASS' "Mode set to bypass Hard bypass

= <Hard Bypass Enabled> Bypass on Failure
= <Soft Bypass Enabled>"
LOG_NOTICE 44203 'BYPASS' "Changing Heartbeat bit state

from <Old Hearbeat Version> to <New
Hearbeat Version>"
LOG_NOTICE 44204 'BYPASS' "Mode set to never bypass"
REPORTS
LOG_ERROR 44701 'REPORTS' "Could not open pdf <Report

Name> because: <Reason>"
LOG_ERROR 44702 'REPORTS' "Could not open html '<Report

Name>' because: <Reason>"
LOG_ERROR 44703 'REPORTS' "Report not sent to <IP

Address>: ".<Email Address>
LOG_INFO 44720 'REPORTS' "<Report Type>"
STM_WRAPPER
LOG_WARN 45001 'STM_WRAPPER' "Cannot execute

<Command Name> Command. Exiting.."
LOG_WARN 45002 'STM_WRAPPER' "Configuration agent is

not running. Cannot monitor <Command
Name> command"
LOG_WARN 45003 'STM_WRAPPER' "command<Command

Name> execution status = <Status>"
LOG_WARN 45004 'STM_WRAPPER' "Configuration agent

crashed. Failed to execute <Command
Name> command"

LOG_WARN 45005 'STM_WRAPPER' "Configuration agent is

not running....Cannot execute <Command
Name> command"
LOG_WARN 45006 'STM_WRAPPER' "Socket between stm

wrapper and Configuration agent
failed...Cannot execute <Command Name>
command"
LOG_ERROR 45007 'STM_WRAPPER' "Failed to initialize STM"
LOG_NOTICE 45008 'STM_WRAPPER' "Successfully initialized

STM"
LOG_NOTICE 45008 'STM_WRAPPER' "creatin db snapshot after

initwac"
LOG_NOTICE 45009 'STM_WRAPPER' "Successfully stopped

STM"
LOG_NOTICE 45010 'STM_WRAPPER' "<Failure Reason>"
LOG_INFO 45011 'STM_WRAPPER' "Procmon rollback

:Loading at <Date> from DB snapshotlast
successful digest"
LOG_NOTICE 45012 'STM_WRAPPER' "Rollback finished:

success"
LOG_ERROR 45013 'STM_WRAPPER' "Rollback failed : Failed

to restart STM"
LOG_NOTICE 45014 'STM_WRAPPER' "<Failure Reason>"
LOG_INFO 45015 'STM_WRAPPER' "Loading at <date> from

DB snapshotlast successful digest"
LOG_WARN 45016 'STM_WRAPPER' "[ALERT:<Event ID>]

Configuration size is <Current Config Size>
Bytes which exceeds the <Max Config Size>
Bytes safe limit. Please check your
configuration."
LOG_INFO 45017 'STM_WRAPPER' "creating db snapshot for

stm at <Date> because current config.xml =
previous config.xml"
LOG_WARN 45018 'STM_WRAPPER' "System in failed state:

attempting recovery for config"
LOG_ERROR 45019 'STM_WRAPPER' "STM startup failed.

Retrying with blank config"
LOG_ERROR 45020 'STM_WRAPPER' "STM startup failed even

with blank config. Exiting."
LOG_INFO 45021 'STM_WRAPPER' "STM startup succeeded

with blank config"
LOG_NOTICE 45022 'STM_WRAPPER' "Committing UI

configuration"
LOG_INFO 45023 'STM_WRAPPER' "creating db snapshot

last successful digest at <Date>"
LOG_NOTICE 45024 'STM_WRAPPER' "Killing STM for dumping

core"
NTP

LOG_INFO 48301 'NTP' "Time synced with the NTP server at

<Server Name/IP Address> time after sync =
<Timestamp>"
LOG_ERROR 48302 "NTP" "Couldn't connect to NTP server:

<Server Name/IP Address>"
LOG_INFO 48303 'NTP' "Time synced with the NTP server at

ntp.barracudacentral.com time after sync =
<Timestamp>"
PROCESS SCHEDULE
LOG_WARN 49001 'PROCESS SCHEDULE' "Scheduled

Backup failed : System has locked key
configuration"

Global Server Load Balancing
In this Section
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

Global Server Load Balancing Overview
Overview
Global Server Load Balancing (GSLB) allows you to coordinate how traffic is processed among multiple data centers. A Barracuda Load Balancer
ADC 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.
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.
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
Site – a network location that hosts data. It may be a Service on a Barracuda Load Balancer ADC with a server farm or one Real Server.
GSLB Controller – the Barracuda Load Balancer ADC 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.
Region – defines a geographical area, usually composed of one or more countries. You can define custom regions or use the
predefined regions.
How GSLB Works

As shown in the figure below, the GSLB devices at each site are configured as authoritative nameservers for the domain www.mydomain.com.
They also perform local load-balancing duties for their own four web servers.
As long as both sites and services are healthy, when a client makes a request for www.mydomain.com they are directed to the clustered GSLBs
in Site A. The GSLBs in Site A respond with an IP list based on the selected algorithm, described below.
The following figure shows the DNS Service IP Address for ADC 1, specified on the TRAFFIC > GSLB Settings page.

Site Selection Criteria
The GSLB Service allows you to specify traffic to be directed to a site based on one of three parameters:
Geo IP – Proximity of the system making the request to a site that can serve the request;
Region Only – Region of the system making the request; or
Priority – Priority order of the sites.
To provide location-based Response Policies, the Barracuda Load Balancer ADC 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.
The following sections consider each of these site selection criteria, using the diagram above.
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.
You might choose to use Geo IP if 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. Set the Response Policy to 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.
Geo IP does not consider site priority.
In the diagram above, Device Z is closest to Site B. So traffic from Device Z would be routed through the internet to Site B.
Following is a portion of the TRAFFIC > GSLB Services page, showing configuration for Geo IP.
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 associated with All Countries are last in the list.
If the location of the originating system cannot be determined, 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.
You might choose to use Region Only if 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. Set the Response Policy to 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. You can use content switching rules to direct HTTP traffic within the backup data center.
Region Only does not consider site priority.
In the diagram above, Device X is in the region with Site A. Devices Y and Z are in the region associated with Site B. Traffic from Device X will go
to Site A. Traffic from Devices Y and Z will go to Site B.
Following is a portion of the TRAFFIC > GSLB Services page, showing configuration for Region.
With the configuration shown here, when the client from Canada makes a DNS request to www.mydomain.com, the GSLB controller returns the

Canada region IP 216.239.64.232. If the client does not fall in Canada region, it will return the default All Countries IP 208.77.188.166.
Priority
The GSLB Controller returns a list of site IP addresses ordered from lowest to highest priority value.
Priority does not consider location.
Priority is often used for disaster recovery. As in the diagram above, y ou have two sites and you want all traffic directed to Site A while Site B is
on standby and used only in the case of the failure of Site A. Create an entry for each site giving the Site A Priority 1 (highest) and Site B Priori
ty 2 . Set the Response Policy to Priority so 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 (Site A's) IP address will be returned first in the list and the backup site’s (Site B'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, its IP address will once again be first in the returned list.
Following is a portion of the TRAFFIC > GSLB Services page, showing configuration for Priority.
Defining Response Policy
Define the Response Policy on the TRAFFIC > GSLB Services page. Select Geo IP, Priority, or Region.
If you select Priority, define the order of priority on the same page.
If you select Region or Geo IP settings, navigate to the TRAFFIC > GSLB Settings page.
Geo IP – Enter the IP address of the server, so the
Regions – Several predefined regions are listed on the TRAFFIC > GSLB Settings page. You can also create a custom region on
that same page. Scroll down to GSLB Regions and click Add Custom Region . Name the custom region and select one or more
small regions from the list. Then click Save . Return to the TRAFFIC > GSLB Services page to specify using the new Custom Region.
Refer to Installation of Global Server Load Balancing for instructions on how to install multiple GSLB Controllers.
Configuring Multiple GSLB 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 Balancer ADCs (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.
Configuration
This screen shows configuration for the Service IP on Site A for the domain ns0. www.mydomain.com.
This screen shows configuration for the Service IP on Site B for the domain ns1. www.mydomain.com .

Failover
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.
Monitoring
Servers must be monitored for their health. For the Monitoring IP address, enter the IP address of the server to be checked. If you will just use the
site IP address for health checks, then leave this field blank.

Installing Global Server Load Balancing
Perform these tasks to design your Global Server Load Balancing (GSLB) network and to configure one or more GSLB Controllers.
Step 1. Define the GSLB network layout
Decide which Barracuda Load Balancer ADC you want to act as your active and which you want to act as your passive GSLB
Controllers. GSLB Controllers must be externally accessible. They may also act as the Load Balancer ADC for a server farm.
Decide whether the Response Policy is based on region, geographical proximity, or by pre-configured priority. Response Policies are
described in the Site Selection Criteria section of the Global Server Load Balancing Overview page.
If your Response Policy is Region Only, decide which site or sites are associated with each region where requests originate.
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 2. Location Definitions for Location-based Response Policy
If you intend to use a priority-based Response Policy, and not a geographically-based Response Policy, skip this step and proceed to Step 3.
For either Geo IP or Region Only, make sure the Location Definitions are set to automatically update on every GSLB Controller.
1. Open the ADVANCED > Energize Updates page.

2. Scroll down to Location Definition Updates.
3. Set Automatic Updates to On.
Step 3. Set the DNS Service IP Address
For each active GSLB Controller, select the IP address to be used as the DNS Service IP address. DNS requests will be sent 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 TRAFFIC > GSLB Settings 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
This step must be done at your domain registrar or wherever your domains are hosted.
To delegate a sub-domain to be resolved by the GSLB Controller, add records 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 www.example.com behind the GSLB Controller, you will need to add a DNS
NS (nameserver) record to associate www.example.com with each GSLB Controller. If there are two GSLB Controllers (one active, one passive)
there is one record for the clustered pair:
www.example.com. IN NS ns1.www.example.com.
Add an A (host) record for the GSLB Controller with its IP address and the domain www:
ns1.www.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 ADC(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 Balancer ADCs are synchronized automatically.
Step 5. Create the Host DNS Record on each GSLB Controller
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 ADC, 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 www.example.com on the GSLB Controller. The domain name is example.com and the
host is www. This A record is initially associated with one site IP address but more site IP addresses can be added later.

For descriptions of other record types, see Record Type Descriptions at the bottom of this article.
To create the DNS records on the GSLB Controller,
1. Navigate to the TRAFFIC > GSLB Services page.

2. In the Add New GSLB Service section, supply the following information, then click Save.
Zone Name – The zone maintained by your existing DNS server, e.g., example.com
Record Type – A
Host – The host name (or sub-domain) to be resolved, e.g., www
Site IP – The IP address that you want to receive the traffic. This may be the VIP address of Service on a Barracuda Load
Balancer ADC, or the IP address of a server
Policy – Region Only
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. Otherwise, select All
Countries from the list.
If the region you want is not already defined, add a custom region.
1. Go to the TRAFFIC > GSLB Settings page.
2. Scroll to GSLB Regions and click Add Custom Region.
3. Return to the TRAFFIC > GSLB Services page and select the custom region from the list.
A DNS record is created for www.example.com. Some of the fields in the record will contain default values for settings, which you can
customize by editing the entry in the table.
Step 6. Set the Failover IP Address
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.
1. Go to the TRAFFIC > GSLB Services page.
2. In the table at the bottom of the page, click the Edit icon to edit the Host site.
3. In the Edit Host window, type the IP address in the Failover IP Address field. Then click Save.
Step 7. Identify the rest of the sites that serve this host
Configure all of the sites that can process the traffic for this host (e.g., www.example.com).
1. Go to the TRAFFIC > GSLB Services page.

2. Within the table at the bottom of the page, click the blue Site link in the Add column for the appropriate Host name.
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 when the Response Policy is Priority.
Record Type Descriptions
The following table describes the various Record Types available for GSLB services.
A New host.
CNAME CNAME specifies an alias or nickname for the official or canonical

name. An alias should be the only record associated with the alias;
all other resource records should be associated with the canonical
name and not with the alias. Any resource records that include a
zone name as their value (for example, NS or MX) must list the
canonical name, not the alias. This resource record is especially
useful when changing machine names.
MX MX records specify a list of hosts that are configured to receive mail

sent to this domain name. Every host that receives mail should have
an MX record, since if one is not found at the time the mail is
delivered, an MX value will be imputed with a cost of 0 and a
destination of the host itself.
NS NS lists a name server responsible for a given zone. The first "name''
field lists the zone that is serviced by the listed name server. There
should be one NS record for each name server of the zone, and
every zone should have at least two name servers, preferably on
separate networks.

TXT A TXT record contains free-form textual data. The syntax of the text
depends on the domain in which it appears; several systems use
TXT records to encode user databases and other administrative data.

Integrating Global Server Load Balancing with the Existing DNS Infrastructure
In a typical GSLB deployment of the Barracuda Load Balancer ADC, the existing DNS domain nameserver continues as the authoritative
nameserver for the zone or domain, for example, barracuda.com. But a hostname or sub-domain, for example, www, is delegated to the
Barracuda Load Balancer ADC that acts as the GSLB Controller. When a DNS query for www.barracuda.com 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.

Implementing Global Server Load Balancing Regions
To specify that Global Server Load Balancing (GSLB) regions be used to direct traffic to data centers with region-specific content, navigate to the
TRAFFIC > GSLB Services page and set the Response Policy to Region Only. When you add a region to a host on the TRAFFIC > GSLB
Services page, traffic that originates in that region is directed to the Site IP address.
Several predefined regions are listed on the TRAFFIC > GSLB Settings page. You can also create a custom region on that same page. Scroll
down to GSLB Regions and click Add Custom Region. Name the custom region and select one or more small regions from the list. Then click
Save. Return to the TRAFFIC > GSLB Services page to specify using the new Custom Region.

Feature Availability
Application Security is now available at no charge on the Barracuda Load Balancer ADC 540 and above, starting from version 5.1.
The Barracuda Load Balancer ADC protects your application from OWASP Top 10 attacks against both HTTP and
HTTPS application traffic. It provides a variety of security policies to protect the websites. Security Policies define
matching criteria for requests, and specify what actions to take when a request matches. All policies are global and
they can be shared among multiple services configured on the Barracuda Load Balancer ADC.
When a Service requires customized settings, the provided security policies can be tuned, or customized policies can be created. Each policy is a
collection of nine sub-policies. Modify a policy by editing the value of the parameter(s) on the sub-policy page.
In this Section
Security Policies
Slow Client Attack Prevention
Configuring Website Profiles
How to Configure Antivirus Protection for File Uploads and Downloads
How to Configure Data Theft Protection
How to Configure Brute Force Prevention
How to Configure Session Tracking
Allow/Deny Rules for Headers and URLs
Extended Match Syntax
Configuring User Defined Patterns

Security Policies
The Barracuda Load Balancer ADC associates security policies with HTTP, HTTPS, and Instant SSL services. A security policy has preset
configured security settings which apply to any associated virtual service. Security policies are shareable, so after a policy is created, it can be
assigned to more than one virtual service. The security policy rules specify inspection criteria for input or output data, identifying malicious or
vulnerable data. Security policies include mostly negative and some positive elements. For most websites, security policies sufficiently implement
good web application security.
Default and Preconfigured Security Policies
When a virtual service is created, it is associated with the default security policy and log levels. The Barracuda Load Balancer ADC includes the
following preconfigured security policies:
Default
Oracle
OWA
OWA2010
OWA2013
Sharepoint
Sharepoint2013
Security Policy Configuration
When needed, the security policy associated with the virtual service can be changed or refined. Security policies define matching criteria to
compare to requests, and rules for matching requests. All security policies are global, that is, they can be shared by multiple Services configured
on the Barracuda Load Balancer ADC.
When a virtual service needs refined security settings, the provided security policies can be adjusted, or customized policies can be created. To
create a customized security policy, see Steps to Create a New Policy. Each policy is a collection of nine sub-policies. Modify the following
sub-policies by editing the corresponding sub-policy page. The sub-policies include:
Request Limits
Cookie Security
URL Protection
Parameter Protection
Cloaking
Data Theft Protection
URL Normalization
Global ACLs
Action Policy
Create a Policy
To create a policy:
1. Go to the SECURITY > Security Policies page.

2. Click New Security Policy.
3. In the New Security Policy window, enter a name for the policy and click Create. The policy is created with default settings, that you
can edit in the main pane of the page.
Edit a Policy
To edit a configured policy:

2. In the left pane, click the policy name.
3. In the main pane of the page, edit the policy settings.
4. After you finish editing the policy, click Save Changes.

Configuring Cloaking
Cloaking prevents leakage of information about a website or service that is vulnerable to web attacks. HTTP headers and return codes are
concealed before sending a response to a client. The response headers are filtered based on the headers defined in the Headers to Filter field
found under Additional Options.
When Suppress Return Code is set to Yes, the Barracuda Load Balancer ADC inserts a default or custom response page in case of any error
responses from the server. Typically, the Barracuda Load Balancer ADC uses the default response page for error responses from the server. You
can also define a custom response page by navigating to the SECURITY > Libraries page, scrolling to the Response Pages section, and
clicking Add Response Page.
Cloaking features include:
Removing banner headers, such as "Server" etc., from responses.

Blocking client error (status code 4xx) and server error (status code 5xx) responses.
To configure cloaking, complete the following steps:
1. Navigate to Security > Security Policies.

2. Select a policy from the Policy Name list or create a New Security Policy.
3. Scroll to the Cloaking section and configure the cloaking settings as necessary. See the online help for additional information.

Configuring Data Theft Protection

Data theft protection prevents unauthorized disclosure of confidential information. Configuring data theft protection requires two steps:
Specify any at risk data elements handled by the web application by configuring a Security Policy.
Enable protection of these elements where needed by configuring a URL Policy.
Sensitive data elements might require masking to prevent their unauthorized disclosure or requests containing sensitive data might be blocked
altogether. You can configure a Security Policy to protect any sensitive data elements. These settings can then be used by any service
associated with the security policy. URL policies applied to narrowly defined URL spaces requiring this protection can be individually enable as
needed. Other URL spaces operate without unnecessarily incurring the processing hit. To optimize performance, enable data theft protection only
for the parts of the website that are known to carry sensitive information.
Specifying at Risk Data Elements
To configure Data Theft Protection, navigate to the SECURITY > Security Policies page. Click the New Security Policy button. Give the new
policy a name and click Create. Select this new policy under Custom Policies. Scroll to the Data Theft Protection section and click Configure.
From here, you can configure new Identity Theft data types.
Enable URL Protection
You can enable protection for specific URLs using the SECURITY > Advanced Security page. Security Policy Data Theft settings are then
enforced only for configured URLs. While, Barracuda Energize Updates provides a set of default protected patterns such as credit card and social
security numbers, these can be expanded or customized, using SECURITY > Libraries, to include other web application specific data patterns
needing protection from disclosure. Any configured pattern can be masked, or the response blocked altogether, if a protected pattern occurs in
the server response.
When Data Theft Protection is enabled, the Barracuda Load Balancer ADC intercepts the response from the server and matches with the pattern
listed in the SECURITY > View Internal Patterns page and SECURITY > Libraries page (if any custom identity theft patterns). If the response
matches any of the defined patterns, it is blocked or cloaked based on the Action (Block or Cloak) set. If action is set to Block, the response
sent by the server is blocked. If set to Cloak, a part of the data is cloaked that is, overwritten with "X"s.
The default identity theft elements provided by the Barracuda Load Balancer ADC are:
Credit Cards (credit-cards)

Directory Indexing (directory-indexing)
Social Security Numbers (ssn)
Credit Cards and Social Security Numbers
To prevent exposure of personal data, such as Credit Card number or a Social Security Number (SSN), select Block to block the response from
the server or Cloak to overwrite the characters based on values defined in the Initial Characters to Keep and Trailing Characters to Keep par
ameters. By default, the credit-card and ssn Protected Data Types are set to Cloak.
Directory Indexing
If a web server is configured to display the list of all files within a requested directory, it may expose sensitive information. The Barracuda Load
Balancer ADC prevents exposure of valuable data by blocking the response from the server. By default, directory indexing is set to Block.
To configure data theft protection, select a policy from the Policy Name list and click Configure… under Data Theft Protection in the Security
Policies section.

Configuring Global ACLs

Global URL access control rules (ACLs) are strict allow/deny rules shareable among multiple services configured on the Barracuda Load
Balancer ADC. You can add a new URL ACL or modify an existing URL ACL.
To add a new global URL ACL, complete the following steps:
1. Navigate to the SECURITY > Security Policies page and scroll to the Global ACLs section.
2. Click Configure.
3. In the Create Global ACL section, configure the settings associated the new global URL ACL.
4. When you have finished, click Add.
To edit an existing global URL ACL, complete the following steps:
1. Navigate to the SECURITY > Security Policies page and scroll to the Global ACLs section.
2. Click Configure.
3. In the Existing Global ACLs section, click Edit next to the URL ACL you need to modify.
4. In the Edit Global ACL popup window, modify the URL ACL settings as needed.
5. When you have finished, click Save.
The URL ACL settings are described in detail in the online help.

Configuring Parameter Protection

Parameter protection defends the service from attacks based on parameter values in the absence of a parameter profile. It is a replacement for
the settings that can otherwise be found under a parameter profile, and applies to all parameters when profiles are not being used. It defines strict
limitations in form fields and other parameters. It deep inspects user input when a FORM is submitted. This allows users to set up validation rules
for FORM parameters.
Special characters such as " ' ", " ; " or ' ' are used to embed SQL expressions in parameter values. SQL keywords such as "OR," "SELECT,"
"UNION" can be embedded in parameter values to exploit vulnerabilities. Special characters such as '<' or keywords such as "<script>," "<img"
are used to embed html tags in parameter values in the case of Cross-Site Scripting attacks. Keywords such as "xp_cmdshell" are used in
System Command Injection attacks.
To configure parameter protection, go to SECURITY > Security Policies, select a policy, and scroll down to the Parameter Protection section.
See the Online Help on the Barracuda Load Balancer ADC for detail instructions on how to configure parameter protection.

Configuring Request Limits

Request limits specify the maximum size that is allowed for the HTTP request header fields of incoming requests. Any requests with header fields
that exceed the limits are dropped and assumed to be buffer overflow attacks. Properly configured request limits mitigate buffer overflow exploits,
preventing Denial of Service (DoS) attacks.
Request limits are enabled by default. The default limits are normally sufficient, but you can reconfigure them for your specific requirements.
When to Change Default Request Limits
If a service or server is encountering issues with HTTP request header fields that are smaller than the request limits, decrease the maximum size
allowed in the header fields.
Decreasing the maximum size allowed for HTTP request headers can help the Barracuda Load Balancer ADC process requests more quickly.
For example, you can decrease the Max URL Length in the request limits, so the Barracuda Load Balancer ADC is required to parse a smaller
number of bytes.
If the default request limits cause false alarms, you can increase the maximum size allowed in the header fields.
Configure Request Limits
To configure request limits for a service:

2. In the left pane, click the name of the security policy that is assigned to the service.
3. In the Request Limit section of the policy settings, review and edit each setting.
4. After you finish configuring the request limits, click Save Changes.

Configuring the Action Policy

From the Security > Security Policies page, you can modify the configuration for the action policy. The action policy specifies the action to take
when a security violation occurs. It specifies the action to be taken when the Barracuda Load Balancer ADC detects a particular type of web
attack.
The following attack groups are available.
advanced-policy-violations
application-profile-violations
header-violations
param-profile-violations
protocol-violations
request-policy-violations
response-violations
url-profile-violations
The configuration for each attack action can be modified by clicking Edit.

Configuring URL Normalization

The Barracuda Load Balancer ADC normalizes all traffic before applying any security policy string matches. For HTTP data, this requires
decoding Unicode, UTF, or Hex to base text, to prevent disguised attacks using encoding formats for which string matches are not effective.
While the Barracuda Load Balancer ADC is active, URL normalization is always enabled. However, URL normalization includes the following
configuration options:
Use the Default Character Set parameter to specify the character set encoding type for incoming requests. UTF-8 is the default.
In some cases, multiple character set encoding is needed, as for a Japanese language site which might need both Shift-JIS and EUC-JP
encoding. To add character set encoding, expand the Additional Options and set the Detect Response Character Set parameter to Y
es. All response headers will be searched for a META tag specifying the character set encoding type and any supported types will be
added dynamically.
If you enable double decoding, after the regular URL normalization is complete, the Barracuda Load Balancer ADC attempts to further
decode the characters. If decoding fails, the request is blocked in active mode and a log is generated in the web firewall logs. In passive
mode, the request is allowed and a logs is generated. To enable double decoding, set Apply Double Decoding to Yes.
To configure URL normalization, select a policy from the Policy Name list and click Configure… under URL Normalization in the Secur
ity Policies section.

Configuring URL Protection

URL requests and embedded parameters in them can contain malicious script. Attacks embedded in URL requests or their parameters are
executed with the permissions of the executing component. Injection of operating system or database commands into the parameters of a URL
request, cross site scripting, remote file inclusion attacks, and buffer overflow attacks can all be perpetrated through unchecked URL requests or
their parameters.
Here is an example of malicious script within a URL Request:
http://www.example.com/sharepoint/default.aspx/%22);}if(true){alert(%22qwertytis
Defense from these attacks is achieved by restricting the allowed methods in headers and content for invoked URL requests, restricting the
number of request parameters and their lengths, limiting file uploads, and specifying attack types to explicitly detect and block. (Attack types are
configured on SECURITY > Libraries or SECURITY > View Internal Patterns.) URL Protection uses a combination of these techniques to
protect against various URL attack types. URL Protection defends the Service from URL request attacks when no URL Profile is configured to do
it. For information URL Profiles, see Configuring Website Profiles.
To configure URL protection, select a policy from the Policy Name list and click Configure under URL Protection in the Security Policies secti
on.

Securing HTTP Cookies

Securing cookies is important because they can include sensitive information such as registration and login credentials. If a cookie can be viewed
or changed, the system is vulnerable to attack and any sensitive information can be stolen.
On the Barracuda Load Balancer ADC, cookie security is transparent to back-end servers. You can configure the Barracuda Load Balancer ADC
to either encrypt or sign cookies that are inserted by the server in a response, before it delivers the response to a client. When a subsequent
request from the client returns this cookie, the Barracuda Load Balancer ADC intercepts the request and either decrypts the cookie or verifies the
signature of the cookie. If the cookie is unaltered, the Barracuda Load Balancer forwards the original cookie to the server. Altered cookies are
removed before the Barracuda Load Balancer ADC forwards the request to the server.
Cookie Signing
Encryption prevents both viewing and tampering with cookies, so it prevents the client from accessing cookie values. For clients who must access
cookie values, you can enable signing. When the Barracuda Load Balancer ADC signs cookies, it forwards two cookies to the client browser–one
plain text cookie and one signed cookie. If either of these cookies is altered when they are returned in a subsequent request from the client,
signature verification fails and the the Barracuda Load Balancer ADC removes the cookies before forwarding the request to the server.
Interaction with HTTP Request Header Limits
When a cookie is encrypted, its length might change but the number of headers in the message remains unchanged. When a cookie is signed, its
length can change and one or more headers are appended to the forwarded message.
Signed or encrypted cookies can exceed any limits that are enabled for the size or number of HTTP request headers (in the SECURITY >
Security Policies > Request Limits section). If this occurs, messages can be incorrectly rejected. These rejected messages are logged on the
BASIC > Web Firewall Logs page, with the Action of CLOAK.
Configure Cookie Security
To configure cookie security for a service:

2. In the left pane, click the name of the security policy that is assigned to the service.
3. In the Cookie Security section of the policy settings, review and edit each setting.
4. After you finish configuring the cookie security settings, click Save Changes.

Slow Client Attack Prevention
Overview
In a slow client attack, an attacker deliberately sends multiple partial HTTP requests to the server to carry out an HTTP DoS attack on the server.
The client attempts to slow the request or response so much that it holds connections and memory resources open on the server for a long time,
but without triggering session time-outs. Common ways to carry out this attack include:
Slow HTTP Headers Vulnerability (Slowloris) - The Slowloris HTTP DoS attack works by having the client never complete sending the
headers. It sends headers one-by-one at regular intervals to keep sockets from closing and the web servers thereby tied up. In particular,
threading servers tend to be vulnerable when they try to limit the amount of allowed threading. Slowloris must wait for all of the sockets to
become available before successfully consuming them, so for high traffic websites, it may take awhile for the site to free up its sockets.
Slow HTTP POST Vulnerability (R-U-Dead-Yet or RUDY) - Using this technique, the client attempts to DoS the server using long form
field submissions. The client sends all of the HTTP headers, one of which is a legitimate Content-Length header with a large value. The
client then repeatedly injects data into the form's post field at a slow rate, forcing the web application to wait for the all of the data to
arrive. As more and more threads are consumed, the server eventually runs out of resources and can no longer support legitimate
requests. Technical details about Layer-7 DDoS attacks can be found in the OWASP lecture: OWASP-Universal-HTTP-DoS (http://www.
hybridsec.com/papers/OWASP-Universal-HTTP-DoS.ppt).
Slow Read DoS Attack - Using this technique, client requests complete fully. However, when the server responds, the client advertises
small windows for accepting response data. For a large response (a file download, for example) the client's slow reception rate
consumes server resources for a long period of time. Multiple requests of this type can eventually take the server down.
These requests are Layer 7 DoS attacks. They are typically legitimate from a protocol compliance point of view and are therefore not detected by
network layer DDoS devices, by IPS/IDS, or even by your ISP. Clients can DoS the server stealthily and slowly, without consuming any significant
bandwidth on the network, so they remain otherwise undetected.
The SECURITY > DDoS Prevention page allows you to configure slow client attack prevention for HTTP and HTTPS Services.
How does Slow Client Attack Prevention Work?
The following settings allow the identification and prevention of a slow client request or response attack:
Max Request Timeout - The maximum time allowed to receive a request from a client. If a request does not complete in this time, the
connection is terminated, FIN is sent to the client, and further requests are blocked.
Incremental Request Timeout - This value specifies the initial timeout window a client has in which to complete a request. The system
then progressively shrinks the window using an adaptive algorithm. If the client repeatedly fails to complete a request in the shrinking
window, the request timeout window converges to zero and the connection is dropped. If the client begins to send data at a healthy rate,
the window is progressively expanded.
This adaptive algorithm ensures that temporary network delays do not affect genuine clients, but persistent slow clients are detected and
denied.
Incremental Response Timeout - This value specifies the initial timeout window a client has in which to receive a response. The
system then progressively shrinks the window using an adaptive algorithm. If the client repeatedly fails to receive the response in the
shrinking window, the response timeout window converges to zero and the connection is dropped. If the client begins to receive data at a
healthy rate, the window is progressively expanded.
This adaptive algorithm ensures that temporary network delays do not affect genuine clients, but persistent slow clients are detected and
denied.
Data Transfer Rate - The minimum data transfer rate the Barracuda Load Balancer ADC expects for requests from the client and
responses to the client. Data transfer rates slower than this are considered slow.
Exception Clients - The IP addresses that should be exempted from slow client attack prevention. Specify a single IP address or range
of IP addresses, or a combination of both using a comma delimiter with no spaces.
Steps to Configure Slow Client Attack Prevention
To view or edit Slow Client Attack Prevention for a Service, complete the following steps:
1. Navigate to the SECURITY > DDoS Prevention page.

2. In the Slow Client Attack Prevention section, Edit the Service requiring protection.
3. In the Edit Slow Client Attack Prevention page, you can view or edit the configured values.
4. Click Save Changes after modifying values. For more information, click Help on the web interface.

Configuring Website Profiles
Overview
The intricate structure of an application is called a profile of the website. Website profiles are made up of profiles for URLs and profiles for
parameters of those URLs. A URL profile lists allowed fields like HTTP methods, names and types of each parameter, query strings, length based
restrictions, etc. A Parameter profile defines the allowed format for each parameter using either a negative or positive security model and includes
length restrictions.
Website Profiles allow you to create specific rules to fine tune the security settings of a Service. They do not modify the default security policy
settings, but fine tune security settings specific to a Service. For a Service, a Website Profile is applied if Use Profile is set to Yes, meaning the
request must be validated against configured URL and Parameter profiles of that Service. Initially no URL and Parameter Profiles exist for a
Service. To use Website Profiles, the administrator must manually create URL and Parameter profiles for the Service.
When a Service is added on the BASIC > Services page, a website profile is created and Use Profile is set to "Yes" for the Service. To modify
the default settings for a Service, perform the following steps:
1. Go to the SECURITY > Website Profiles page.

2. In the Service section, select the Service from the Website drop-down list whose settings you want to modify.
3. Click the Edit button. The Edit Website Profile window appears. Specify values for the following fields if required:
a. Use Profile – Set to Yes to use URL profiles and parameter profiles for validating the requests coming for this Service.
b. Strict Profile – Set to Yes to enforce strict profile checks thereby denying requests which do not match any profile. If set to " No",
then the Service's default web firewall policy will be applied to those requests which do not have a profile.
c. Mode – Set the mode for the service:
i. Passive – Validates the requests against the URL Profiles and Parameter Profiles settings and logs request
errors/violations on the BASIC > Web Firewall Logs page.
ii. Active – Validates the requests against the URL Profiles and Parameter Profiles settings, blocks request violations and
logs the corresponding violations on the BASIC > Web Firewall Logs page.
d. Allowed Domains – Enter the domain or IP address of the Service whose requests/responses should be validated against the
URL and Parameter Profiles. If you wish to allow multiple sub domains under a main domain, then you can configure it as
domain=maindomain. For example, "world.com" might have pages at "india.world.com," "america.world.com," and "japan.w
orld.com." By default, if a web page on "india.world.com" is configured under Allowed Domains, only pages on "india.world.
com" are allowed. If the user wants all subdomains in the "world.com" domain to be allowed, then specify "domain=world.com
".
e. Exclude URL Patterns – Enter the list of URL patterns to be excluded from the URL Profile validations. These URLs are
exempted from learning even if the Learning is On. Examples: *.html,*.htm,*.jpg, *.gif,*.css,*.js
f. Include URL Patterns – Enter the list of URL patterns to be included in the URL profile validations in spite of being listed in Exc
lude URL Patterns.
4. Click Save Changes to save the settings.
URL Profiles
URL Profiles are validated against the requests for the Service based on the Mode setting of the URL profile.
How to Add a URL Profile

2. In the Service section, select the Service from the Website drop-down list to which you want to add a URL profile.
3. In the URL Profiles section, click Add URL. The Create URL Profile window appears. Specify values for the following fields:
a. URL Profile Name – Enter a name for the URL profile.
b. Status – Set to On if you want to enforce checks on requests/responses for the Service using this profile.
c. URL – Enter a URL to be compared to the URL in the request. The URL should start with a "/" and can have at most one " * "
anywhere in the URL. The value of “/*” means all URLs in the Service are matched against the URL in the request.
d. Extended Match – Specify an expression, a combination of HTTP headers and/or query string parameters, you want used to
match the special attributes in the HTTP headers or query string parameters in the requests. Use '*' to denote "any request", that
is, do not apply the Extended Match condition. For information on how to write extended match expression, see Extended
Match Syntax.
e. Extended Match Sequence – Enter a number to indicate the order in which the extended match rule will be evaluated in for
requests.
f. Mode – Set the mode for this URL profile.
i. Passive – Validates the requests comparing them to the URL profile and corresponding Parameter profile(s) settings
and logging request errors/violations on the BASIC > Web Firewall Logs page.
ii. Active – Validates the requests comparing them to the URL profile and corresponding Parameter profile(s) settings,
blocking request violations and logging the corresponding violation on the BASIC > Web Firewall Logs page.
g. Allow Query String – Set to Yes to allow parameters and its values along with the URL.
h. Hidden Parameter Protection – Specify whether or not to protect hidden parameters in the forms and URLs.
i.

h.
i. Forms – Protects the hidden parameters in the post body of forms.
ii. Forms and URLs – Protects the hidden parameters in the post body of forms and query string of the URLs.
iii. None – No protection to hidden parameters in forms and URLs.
i. CSRF Prevention – Specify whether or not to prevent cross-site request forgery attack on the forms and URLs.
j. Max Content Length – Enter the maximum content length to be allowed for POST request body.
k. Maximum Parameter Name Length – Enter the maximum length of the parameter name. The allowed length is 1 to 1024
bytes. No value (empty) implies unlimited.
l. Maximum Upload Files – Enter the maximum number of files that can be uploaded in one request. If the value is set to two (2),
then the third (3) file upload is denied. The Passive mode logs every uploaded file that exceeds the max count.
m. Blocked Attack Types – By default, all attack types are selected. Attack Types are specifications of malicious patterns. If the
value of a parameter matches one of the specified Attack Types, an intrusion is detected and logged on the BASIC > Web
Firewall Logs page. Attack Types are defined with groups of Regular expression patterns. Attack Types for SQL Injection,
Cross Site scripting and System Command Injection attacks are provided by default, and one or more of these can be enabled
for matching against request parameters.
n. Custom Blocked Attack Types – By default, all custom attack types are selected. Clear the checkbox to allow any of the
patterns.
4. Click Save to add the URL profile.
5. Click Edit next to the created URL profile to specify values for the following fields:
a. Allowed Methods – Enter the methods to be allowed in the request. The Barracuda Load Balancer ADC uses this to decide
whether to allow or disallow the methods.
b. Allowed Content Types – Enter the content types to be allowed for this URL profile.
c. Referrers for the URL Profile – Enter the address (URI) of the resource from which the Request URI was obtained. In case of
adaptive profiling, the referrers are learned as the profile sources. This referrer is not same as the “Referrer” in CSRF protection.
Note: This is used only for information purpose, and no security checks are enforced by the Barracuda Load Balancer.
d. Exception Patterns – Enter the patterns to be allowed as exceptions even if part of a malicious pattern group. The configuration
should be the exact "Pattern Name" as found on the SECURITY > View Internal Patterns page, or as defined during the
creation of a "New Group" through the SECURITY > Libraries page. The pattern name can also be found in a Web firewall log
when a false positive occurs due to a potential exception pattern. For example, if the parameter value matched "sql-comments"
regex pattern under "sql-injection medium" attacks on the SECURITY > View Internal Patterns page, then adding
"sql-comments" to this list will allow "sql-comments" in future.
6. Click Save Changes to save the above settings.
Parameter Profiles
Parameter profiles are compared to the requests for the Service based on the Mode setting of the corresponding URL profile.
How to Add a Parameter Profile

2. In the Service section, select the Service from the Website drop-down list.
3. In the URL Profiles section, select the desired URL profile where you want to add the Parameter profile.
4. Click Add Param in the Parameter Profiles section. The Create Parameter Profile window appears. Specify values for the following
fields:
a. Parameter Profile Name – Enter a name for the parameter.
b. Status – Set to On to validate the requests coming to the Service using this Parameter Profile.
c. Parameter – Enter the name of the parameter to be validated in requests/responses. The parameter names with the special
characters like &pathinfo and &sessionid and wildcard (*) should be manually specified, they are not learned automatically.
d. Type – Select the type of parameter to be validated in requests/responses.
If two or more parameters of different type have the same name, then parameters would be considered as Input type
and be bound to one of standard parameter classes and the value of the parameter Max Instances would be
updated. The types of parameters.
i. Input – The parameter other than File Upload, Global Choice, Read Only, Session Choice, and Session Invariant type is
treated as Input type.
ii. Read Only – All hidden parameters in the form and query parameters in the URL is learned as Read Only type. If an
exception occurs while learning, then the type is updated to Input. This type makes the parameter session specific.
iii. Session Choice – The parameter from a response form and the drop-down list is different across different sessions or
same session, then it is treated as Session Choice.
iv. Global Choice – The input type parameters like check boxes, radio buttons and menu parameters in a form is treated as
Global Choice type.
v. Session Invariant – Select this if the parameter value is same across multiple requests from the same session, then it
can be set as Session Invariant, for example; session-id. This type of parameter is not learned automatically.
vi. File Upload – The parameter of the type file upload in forms is treated as File Upload type.
e. Values – Define a fixed set of strings to match against the parameter's value, if the parameter Type is to Global Choice.
f.

f. Parameter Class – Select a parameter class to be compared to the parameters sent in the requests/responses.
g. Custom Parameter Class – Select the custom parameter class to be compared to the parameters sent in the
requests/responses. This is applicable only when Parameter Class is set to CUSTOM.
h. Max Value Length – Set the maximum allowable length for the value of the parameter. Example: The parameter "param" set to
0, which means:
p1=v1&param=&p2=v2 : allowed
p1=v1&param=v&p2=v2 : not allowed
i. Required – Set to Yes if the parameter must always be present in the request.
j. Ignore – Set to Yes if the parameter must be ignored completely, that is, never validate the value of the parameter at all.
k. Maximum Instances – Specify the maximum number of times the parameter should be allowed in the request/response.
l. File Upload Extensions – Define the extensions to be allowed in file upload. ‘.' is a special extension which indicates no
extension, and * is a wildcard which indicates any extension is allowed.
5. Click Add to add the Parameter profile.
6. Click Editnext to the created parameter profile to specify values for the following fields:
a. Allowed Metacharacters – Define the list of meta-characters to be allowed in spite of it being marked as denied in the
parameter class. Click the Edit icon, select the meta-characters and click Apply to populate the selected meta-characters.
b. Exception Patterns – Define a list of patterns to be allowed as exceptions in spite of them being part of a malicious pattern
group. The configuration should be the exact "Pattern Name" as found on the SECURITY > View Internal Patterns page or as
defined during the creation of a "New Group" through the SECURITY > Libraries page. The pattern name can also be found in
a Web firewall log when a false positive occurs due to such a potentially "exception" pattern. For example, if the parameter value
matched "sql-comments" regex pattern under "sql-injection medium" attacks on the SECURITY > View Internal Patterns page,
then adding "sql-comments" to this list will allow "sql-comments" in future.
7. Click Save Changes to save the above settings.

How to Configure Antivirus Protection for File Uploads and Downloads
You can enable virus scanning on a per URL basis. It should only be enabled for URLs which allow file uploads and downloads because virus
checking is a performance intensive task.
To enable Antivirus for file uploads/downloads
1. From the SECURITY > Advanced Security page in the Advanced Security section, identify the service for which you want to enable
Antivirus checking.
2. Click Edit next to that Service. The Edit URL Policy window appears.
3. In the Edit URL Policy section:
a. Set Enable Virus Scan to Yes.
b. Set Status to On.
c. Set Mode to Active.
4. Click Save.
When Virus Scan is enabled for a Service, all requests passing through the Barracuda Load Balancer ADC for that Service are scanned for
viruses, and any traffic containing viruses is blocked.
Antivirus Details
The Barracuda Load Balancer ADC uses the Clam AV integrated Antivirus engine to scan files for embedded viruses and malware. AV signatures
are created based on research conducted by Barracuda engineers. These AV signatures are sent to all deployed Barracuda Load Balancer ADCs
with active Energize Updates subscriptions. The Barracuda Load Balancer ADC Antivirus engine supports the same file types the Clam AV
engine supports. The Antivirus engine also uses streaming, so blocks of data are sent to the AV engine as they are received. Once the AV engine
returns scanned data, the data is pushed to the back-end server.
The default size for the Antivirus scanning file is 25Mb. Although Barracuda Networks Technical Support can change this file size, customers
cannot change this setting. When the Barracuda Load Balancer ADC receives an Antivirus scanning file larger than 25MB, the Clam engine
rejects connection request and a log entry, indicating that the Antivirus scanning file is too large, is also generated.

How to Configure Data Theft Protection
Data theft protection prevents unauthorized disclosure of confidential information. Configuring data theft protection requires two steps:
Specify any at risk data elements handled by the web application using a Security Policy.
Enable protection of these elements where needed, using a URL Policy.
Sensitive data elements might require masking to prevent their unauthorized disclosure, or requests containing sensitive data may be blocked
altogether. Using a Security Policy, you can specify which data elements need protection, along with how to handle them. These settings can be
used by any service associated with the security policy. URL policies applied to narrowly defined URL spaces requiring this protection can be
individually enabled as needed. Other URL spaces operate without requiring the additional processing. To optimize performance, you can limit
data theft protection to just the sections of the site containing sensitive information.
The Data Theft Protection section on the SECURITY > Security Policies page enables you to configure Identity Theft data types for a Security
Policy. You can enable protection for specific URLs from the SECURITY > Advanced Security page. Security Policy Data Theft settings are
then enforced only for configured URLs. The Barracuda Energize Updates provide a default set of protected data patterns, such as credit card
and social security numbers. However, these can be expanded or customized from the SECURITY > Libraries page to include other data
patterns. Any configured pattern can be masked, or the response blocked altogether, if a protected pattern occurs in the server response.
When Data Theft Protection is enabled, the Barracuda Load Balancer ADC intercepts the response from the server and matches against the
pattern listed in the SECURITY > View Internal Patterns page and SECURITY > Libraries page (for custom identity theft patterns). If the
response matches any of the defined patterns, it is blocked or cloaked based on the Action (Block or Cloak) set. If action is set to Block, the
response sent by the server is blocked. If set to Cloak, a part of the data is cloaked that is, overwritten with "X"s.
When set to Block, the response is blocked according to the action configured for Identity-theft-pattern-matched-in-response in SEC
URITY > Security Policies > Action Policy.
The default identity theft elements provided by the Barracuda Load Balancer ADC are:
Credit Cards
Directory Indexing
Social Security Numbers
Credit Cards and Social Security Numbers
To prevent exposure of personal data such as credit card and social security numbers, select Block to block the response from the server, Cloak
to overwrite the characters based on values defined in the Initial Characters to Keep and Trailing Characters to Keep parameters. By default,
credit card and social security numbers are set to Cloak.
Directory Indexing
If a web server is configured to display the list of all files within a requested directory, it may expose sensitive information. The Barracuda Load
Balancer ADC prevents exposure of valuable data by blocking the response from the server. By default, directory indexing is set to Block.
Steps to Configure Data Theft Protection:
1. From the SECURITY > Security Policies page select a policy from the Policy Name list to which you want to enable data theft
protection. Click Configure in the Data Theft Protection section. The Data Theft Protection page appears.
2. In the Configure Data Theft Protection section, specify values for the following fields:
a. Data Theft Element Name – Enter a name for the data theft element.
b. Enabled – Select Yes to use this data element to be matched in the server response pages. This data element is used for
matching server response pages only when Enable Data Theft Protection is also set to Yes on the SECURITY > Advanced
Security page.
c. Identity Theft Type – Select the data type from the drop-down list that the element mentioned in Data Theft Element Name
belongs to. The default identity theft patterns (Credit Card, SSN and Directory Indexing) are associated to data types defined
under SECURITY > View Internal Patterns > Identity Theft Patterns. If you want to associate a custom identity theft pattern
created on the SECURITY > Libraries page, select CUSTOM from the drop-down list and then select customized identity theft
type from the Custom Identity Theft Type field below.
d. Custom Identity Theft Type – Select the customized identity theft type to be used from the drop-down list.
e. Action – When set to Block, the response sent by the server containing this data type is blocked. The Block mode should be
used if the server should never expose this information. In the Cloak mode, a part of the data is cloaked, that is, overwritten with
X’s based on Initial Characters to Keep and Trailing Characters to Keep.
f. Initial Characters to Keep – Enter the number of initial characters to be displayed to the user when the data of this data type is
identified in a server page. For example, an online shopping service displays a user’s credit card number 1234 0000 0000 5678.
If Initial Characters to Keep is set to 4, the credit card number is displayed as 1234 XXXX XXXX XXXX.
g. Trailing Characters to Keep – Enter the number of trailing characters to be displayed to the user when the data of this data
type is identified in a server page. For example, an online shopping service displays a user’s credit card number as 1234 0000
0000 5678. If Trailing Characters to Keep is set to 4, the credit card number is displayed as XXXX XXXX XXXX 5678.
3.

Custom Identity Theft Patterns
The default data theft types are displayed under Protected Data Types in the SECURITY > Security Policies > Data Theft Protection page.
You can also create custom identity theft data types on the SECURITY > Libraries page.
Creating a Custom Identity Theft Pattern
1. Go to the SECURITY > Libraries page, Identity Theft Patterns section, enter a name in the New Group field and click Add.
2. Click Add Pattern next to the created identify theft pattern group. The Identity Theft Patterns window appears. Specify values for the
following fields:
a. Pattern Name – Enter a name to identify the pattern.
b. Status – Set to On if you wish to use this pattern for pattern matching in the responses.
c. Pattern Regex – Define the regular expression of the pattern or click the Edit icon to select and insert the pattern.
d. Pattern Algorithm – Select the algorithm to associate with the pattern from the drop-down list.
e. Case Sensitive – Select Yes if you wish the pattern defined to be treated as case sensitive.
f. Pattern Description – (Optional). Enter the description for the pattern defined. Example, Visa credit card pattern. This indicates
the pattern used here is the visa credit card pattern.
3. Click Save.
Using a Custom Identity Theft Pattern

2. Select a policy from the Custom Policies list or from the Predefined Policies list.
3. Scroll to the Data Theft Protection section. Click Configure.
4. In the Configure Data Theft Protection section, enter a name in the Data Theft Element Name text field.
5. Set Enabled to Yes to use this data element to be matched in the server response pages. This data element is used for matching server
response pages only when Enable Data Theft Protection is also set to Yes on the SECURITY > Advanced Security page.
6. Select CUSTOM from the Identity Theft Type drop-down list.
7. Select the Identity theft pattern you created from the Custom Identity Theft Type drop-down list.
8. Set the Action to Block or Cloak. If set to Block, the response sent by the server containing this data type is blocked. The Block mode
should be used if the server is never expected to expose such information. In Cloak mode, a part of the data is cloaked, that is,
overwritten with X characters based on Initial Characters to Keep and Trailing Characters to Keep.
9. Click Add.
10. Bind this policy to a Service, so that any request coming to that service is matched with the pattern and then processed.
Turning on Data Theft Protection Using a URL Policy
To use Data Theft Protection for a requested URL:
1. Go to the SECURITY > Advanced Security page.

2. Click Edit for the URL Policy on which you want to enable data theft protection.
3. Go to Enable Data Theft Protection and set it to Yes. Click Save.
When Enable Data Theft Protection is set to Yes for a requested URL, the Data Theft Protection settings from the Service's Security
Policy are enforced for this request.

How to Configure Brute Force Prevention
Brute Force Prevention
Brute Force attacks attempt unauthorized access by repeatedly bombarding the system with guessed parameters.
To enable Brute Force prevention:
1. Edit the default URL policy (default-url-policy) on the SECURITY > Advanced Security page.
2. Set Enable Bruteforce Prevention to Yes.
Preventing Brute Force Attacks
Brute Force prevention sets the maximum number of requests (all requests or only invalid requests) to a URL space from a single client, or from
all sources, within the specified time interval. It blocks offending clients from making further requests. You can specify exception clients for which
no maximum is enforced. Bruteforce prevention stops the following types of rate based attacks:
Brute force attempts to gain access – Repetitive login failures in quick succession may be an attempt to gain unauthorized access using
guessed credentials.
Brute force attempts to steal session tokens – Session tokens, authentication mechanisms for requests by already authenticated users,
can be guessed and stolen through repeated requests.
Distributed Denial of Service attacks (DDoS) – Repeated requests for the same resource can impair critical functionality by exhausting
server resources.
Vulnerability scanning tools – High rates of requests can probe web applications for weaknesses. Typically these tools execute a
database of commonly known and unknown (blind) attacks which are executed in quick succession.
Other Brute Force Attack Prevention

To detect brute force attacks against session management (too many sessions given out to a single IP address or range), use session
tracking.
On the SECURITY > Advanced Security page, locate the desired URL policy and click Edit in the Options column next to it.
To configure Brute Force prevention, modify the following settings:
Enable Bruteforce Prevention – Set to Yes to enable bruteforce attack prevention for this URL policy.
Enable Invalid Status Code Only – Set to Yes to monitor and count only invalid requests from a single client or all sources. If set to No,
both valid and invalid requests from a single client or all sources are counted. Requests exceeding the configured Max Allowed
Accesses Per IP and Max Allowed Accesses From All Sources are blocked.
Count Window – Specifies the time interval in seconds to which the Max Allowed Accesses Per IP or Max Allowed Accesses From
All Sources applies. Range: 1 – 6000; Default: 60 (one minute).
Max Allowed Accesses Per IP – Specifies the maximum number of requests allowed to this web application per IP address. Range: 1 –
65535; Default: 10.
Max Allowed Accesses From All Sources – Specifies the maximum number of requests allowed to this web application from all
sources. Range: 1 – 65535; Default: 100.
Counting Criterion – Specifies whether requests from all sources, or requests per IP are counted. Values: Per IP, All Sources; Default:
Per IP.
Exception Clients: Specifies IP addresses for which no maximum number of accesses is enforced. You can enter a single, or a range of
IP addresses, or a combination of both with a comma (,) as a delimiter. The range of IP addresses must be separated with a hyphen (-).
This makes an exception list of client IPs (unlimited access users). This list should not have any overlapping IP ranges. Values: Suitable
IP Range;
Click Save when you have finished.

How to Configure Session Tracking
Session Tracking
A Session refers to all requests a single client makes to a server. A session is specific to a user. For each user, a new session is created to track
all requests from that user. Every user has a unique session identified by a unique session identifier. Session Tracking enables the Barracuda
Load Balancer ADC to limit the number of sessions originating from a particular client IP address in a given interval of time. Limiting the session
generation rate by client IP address helps prevent session-based Denial of Service (DoS) attacks. To configure Session Tracking go to the SECU
RITY > Advanced Security page, scroll to Session Tracking, and click Edit in the Options column.
You can specify the following session protection options:
New Session Count – Maximum number of new sessions allowed per IP address; Range: 1 - 65535; Default: 10.
Interval – Time in seconds for which the number of sessions from the same client cannot exceed the New Session Count setting;
Range: 1 - 6000 seconds; Default: 60.
Status – Set to On to enable session tracking.
Session Identifiers – The token type used to recognize sessions. Choose from the list, or see Configuration of Session Identifiers to
add a Session Identifier.
Exception Clients – List clients which are exempted from this protection. IP address ranges should be separated by a "-" (hyphen).
Multiple ranges or IP addresses can be listed with "," (comma) separation. The list should not contain overlapping IP address ranges.
When you have finished configuring these options, click Save.
Configuration of Session Identifiers
Configuring session identifiers allows the Barracuda Load Balancer ADC to recognize session information in requests and responses.
To create a new session identifier, perform the following steps:
1. Go to the SECURITY > Libraries page and scroll to the Session Identifiers section.
2. Locate the desired identifier and click Edit, or to add a new identifier, click Add Session Identifier.
3. Enter or modify the session Identifier Name. This name will appear in the list of Session Identifiers from which you choose when you
configure Session Tracking.
4. Enter or modify the following session token parameters.
Token Name
Token Type
Start Delimiter
End Delimiter
5. Newly added or edited Session Identifiers appear in the Session Identifiers list on the Edit Session Tracking page on the SECURITY >
Advanced Security page in the Session Tracking section.
The following example shows how to enable the Barracuda Load Balancer ADC to extract the Session ID 12345 from session identifier:
“JSESSIONID=12345;”
Token Name – JSESSIONID

Token Type – Parameter
Start Delimiter – =
End Delimiter – ;

Allow/Deny Rules for Headers and URLs
The SECURITY > Allow/Deny page allows you to define strict access control rules for the Services. Further a request with any violation is
allowed or denied based on the settings in this URL ACL and Header ACL. These controls include location checks, form checks, size checks, and
content checks both to and from the servers. They can also set landing page and entry controls, and they can provide custom error responses
and request redirection.
In this Section
Allow/Deny Rules for Headers

Allow/Deny Rules for URLs

Allow/Deny Rules for Headers

You can enforce strict limitations on incoming headers intended for a service using SECURITY > Allow/Deny Rules > Header : Allow/Deny
Rules section. It is used to sanitize HTTP headers that carry sensitive information identifying the client and some application-specific state
information passed as one or more HTTP headers. A header ACL can be configured to protect against attack types and potentially malicious
metacharacters and keywords that are placed in a header.
To create a Header ACL rule:
1. Go to the SECURITY > Allow/Deny Rules page.

2. In the Header : Allow/Deny Rules section, identify the Service to which you want to add the header ACL rule.
3. Click Add next to the Service. The Create Header ACL window appears.
4. Specify appropriate values for the given fields and click Save.
For more information, click Help in the web interface.

Allow/Deny Rules for URLs

Strict allow/deny rules for a web application can be configured on the SECURITY > Allow/Deny Rules page. Allow/Deny rules allow you to
customize access to the web application based on a set of matching criteria. An administrator can configure the rule to control access to certain
portions of the web application as per the business requirement without changing any configuration on the web application itself.
A rule can be configured for a URL match, a Host header match and a set of optional extended match criteria (example: client IP address or the
HTTP method). Once a match is found, the request will be processed as per the configured action. The rule action can be configured to either
redirect the incoming request to another absolute URL, or to continue the processing of the request using the other security layers of the
Barracuda Web Application Firewall, apart from allowing or denying a request explicitly.
To configure a specific match, click Add or Edit next to the Service and use the Extended Match widget. For rule matching and subsequent
evaluation, URL match and Host header matches are prioritized over extended matches. If more than one rule with the same URL match/Host
header match is configured, they are evaluated based on the specified extended match sequence.
There are two ways of redirecting a request using the URL ACL:
Set the Action parameter to Redirect, and specify the Redirect URL.
Set the Action parameter to Deny and Log, set the Deny Response to Redirect and specify the Redirect URL.
The first case is not considered an attack, therefore:
It is logged at a lesser severity.

Passive mode has no effect on it.
The second case is a suspected attack, therefore:
It is logged at a higher severity.

Passive mode is applied so that the request is not denied.
To create a URL ACL rule:
1. Go to the SECURITY > Allow/Deny Rules page.

2. In the URL : Allow/Deny Rules section, identify the Service to which you want to add the URL ACL rule.
3. Click Add next to the Service. The Create ACL window appears.
4. Specify appropriate values for the given fields and click Save.
For more information, click Help in the web interface.

Extended Match Syntax
Extended Match and Condition Expression
Extended Match and Condition Expressions can be configured for various rule types, allowing you to specifically define which requests/responses
need the rule applied. You can configure conditions based on parameters or elements of a request/response, combining them in a flexible
manner, and applying the rule security settings only to those that match the defined expression.
A few examples:
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 www.example.com) && (Client-IP eq 10.0.0.0/24) - match a request whose host header is www.example.com and
whose client IP address is in the 10.0.0.* subnet.
Quick reference
Extended Match Expression:

Element Match
(Expression) [Join (Expression) ...]
Join:
&&, ||
Element Match:
Element [Element Name] Operator [Value]
Element:
Request Elements: Method, HTTP-Version, Client-IP, URI, URI-Path, Header
Request Parameters: Parameter, Pathinfo
Response Elements: Status-code, Response-Header
Operator:
Matching: eq, neq, req, nreq
Containing: co, nco, rco, nrco
Existence: ex, nex
Structure of an Extended Match Expression
An Extended Match expression consists of one or more Element Matches, combined using Join operators AND and OR. Parentheses 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) require a value, whereas some don't (like ex).
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 parenthesis).
Operators
The following are the possible operators in an Element Match. The operators are case insensitive so, for example, eq, Eq and EQ all behave the
same.
eq - true if the operand is equal to the given value. A case insensitive string comparison is performed, so a value of "01" does not equal
the value "1", whereas the values "one" and "ONE" are equal.
neq - true if the operand is not equal to the given value. A case insensitive string comparison is performed.
co - true if the operand contains the given value.
nco - true if the operand does not contain the given value.
rco - true if the operand contains the given value, specified as a regular expression.
nrco - true if the operand does not contain the given value, specified as a regular expression.
req - true if the operand matches the given value, specified as a regular expression.
nreq - true if the operand does not match the given value, specified as a regular expression.
ex - true if the operand exists. A value is not required.
nex - true if the operand does not exist. A value is not required.
Elements
The following Elements are allowed in an expression. Elements and Element Names are case insensitive, so Method and METHOD behave the
same.

Client-IP - 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 can be used with this element. Examples: (Client-IP eq 192.168.1.0/24), (Client-IP eq
192.168.1.10)
Method - The HTTP Method specified in the request. Example: (Method eq GET)
HTTP-Version - The version of the HTTP protocol of the request. Example: (HTTP-Version eq HTTP/1.1)
URI - The Uniform Resource Identifier in the request. This includes any query parameters in the request. Example: (URI rco
/abc.*html?userid=b)
URI-path - The path portion of the URI, excluding any query parameters. Example: (URI-path req \/.*copy%20[^/]*)
Parameter - A parameter in the query string part of the URL and serves as a name-value pair. The special parameter
"$NONAME_PARAM" allows reference to a parameter when the parameter name is absent. Examples: (Parameter sid eq 1234),
(Parameter $NONAME_PARAM co abcd)
Pathinfo - The portion of the URL considered the PATH_INFO on the server. The Barracuda Web Application Firewall uses a set of
known extensions to determine whether a portion of the URL is the Pathinfo or not. For example, if the request URL is /twiki/view.c
gi/Engineering, then, /Engineering is considered to be the pathinfo rather than part of the URL. Example: (PathInfo rco abc*)
Header - An HTTP header in the request. Requires an Element Name to identify which header, following the word Header. Example:
(Header Accept co gzip). This will check if the "Accept:" header contains the string "gzip".
X509_OU - The Organizational Unit (OU) stated in the X.509 certificate. Example: (X509_OU eq Engineering Division). When Client
Authentication is enabled for a HTTPS service, the certificate presented by the client is matched with the element value. If the request
matches the rule, the Barracuda Web Application Firewall executes the specified action.
To Enable Client Authentication, click Edit in the Options column next to the service on the BASIC > Services page in the Configured Virtual
Services section.
Not all elements are allowed in every expression. The following restrictions apply:
Request rules (ACLs, URL Policy, URL Profiles) allow only the elements Method, HTTP-Version, Header, Client-IP, URI, URI-Path, Pa
thInfo, and Parameter.
Request Rewrite Condition allows only the elements Method, HTTP-Version, Header, Client-IP, and URI.
Response Rewrite Condition allows only the elements Method, HTTP-Version, Header, Client-IP, URI, Status-code and Response-He
ader.
Joins
Expressions can be joined using:
|| - Or, checks if either expression is true.

&& - And, checks if both expressions are true.
Element Matches can be combined as long as the Element Matches are enclosed in parentheses. You cannot combine Element Matches without
parentheses. Example: (Header cookie ex) && (URI rco .*\.html) && (Method eq GET)
Nested sub-expressions can be created by enclosing expressions in parentheses, making the expression more readable as well as
unambiguous. Example: (HTTP-Version eq HTTP/1.1) && ((Header Host eq www.example.com) || (Header Host eq website.example.com))
Escaping
The space character and the parentheses characters are special characters which cause the parser to split the string into tokens at these
separators. In some cases, you must 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:1.8.1.3) Firefox/2.0.0.3
When a value contains space or parenthesis characters, they must be escaped by prefixing them with a back-slash (\), or by enclosing the entire
value in double-quotes ("). Examples:
Header User-Agent eq "Mozilla/5.0 (Linux i686; en-US; rv:1.8.1.3) Firefox/2.0.0.3"

Header User-Agent eq Mozilla/5.0\ $Linux\ i686;\ en-US;\ rv:1.8.1.3$\ Firefox/2.0.0.3
The double-quote character itself must be escaped with a back-slash. This is true whether or not it is inside a 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 whether or not it is within a quoted string.
The back-slash character escapes all characters, not just special characters. Thus, "\c" stands for the character "c" etc. In other words,
back-slash followed by any character stands for the character, whether or not that character has a special meaning in the extended match syntax.

Configuring User Defined Patterns
The Barracuda Load Balancer ADC allows you to create customized data patterns which can be detected and handled according to the
configured security settings.
The Barracuda Load Balancer ADC uses regular expressions (regex) to define data type patterns. Custom data types can be defined using regex
patterns to implement advanced data type enforcement on input parameters. For guidelines on how to write regular expressions, see Extended
Match Syntax. The pattern-match engine recognizes the lexical patterns in text and compares inputs to defined data type patterns. For example,
the following is the default regex pattern for a Visa credit card:
4[[:digit:]]{12}|4[[:digit:]]{15}
A pattern can also be associated with an algorithm, for example, an algorithm to validate a credit card number can be associated with a credit
card pattern. The algorithm runs on all strings matching the regular expression to decide whether they actually conform to this pattern.
Internal Patterns
The SECURITY > View Internal Patterns page includes Identity Theft Patterns, Attack Types, Input Types, and Parameter Class. Each data
type exhibits a unique pattern. These patterns can be bound to a policy or to profiles of an web application to validate the incoming requests.
The patterns displayed by default under each pattern group cannot be modified. To create a modified pattern, use the Copy function to copy a
pattern, then modify it as required. The copied pattern group can be found on the SECURITY > Libraries page under the corresponding group.
You can modify or delete patterns as required, and then apply them to a service security policy. For more information on how to copy a pattern
group, refer to Steps to Copy a Pattern Group .
The following provides a brief description about the internal patterns.
Identity Theft Patterns
Identity theft is the loss of personal data resulting in fraud. Disclosure of sensitive information such as credit card numbers, banking information,
passwords, or usernames in service communication might enable identity theft. The Barracuda Load Balancer ADC prevents unauthorized
exposure of at risk data.
The Identity Theft container includes Credit Cards, Social Security Numbers, and Directory Indexing data types. In addition, customized identity
theft patterns can be created and used. For more information, see How to Configure Data Theft Protection.
Attack Types
An attack is a technique used to exploit vulnerabilities in web applications. Attacks can insert or modify code in requests. If a request contains an
attack pattern, it is dropped. The attack data type container includes patterns for identifying Cross-site Scripting, Remote-file Inclusion, SQL
Injection, Directory Traversal, and OS Command Injection attacks. In addition customized attack data types can be created and used.
Input Types
Input data types are used to validate the HTTP request parameters. Inputs come from web forms, applications and Services, custom client
applications, or file based records. This validation ensures that the data conforms to the correct syntax, is within length boundaries, and contains
only permitted characters or numbers. Requests failing validation are assumed intrusions and are blocked. Input types are defined using reg-ex
patterns. Default Input Types including credit cards, numeric, hex-number, alpha, alphanumeric, string, name, and date are provided. In addition,
customized Input Types can be defined and used.
Parameter Class
Parameter class defines acceptable values for parameters. Parameter classes are bound to Parameter Profiles using SECURITY > Website
Profiles > Parameter Profiles and specify validation criteria for parameters in a request. In addition to the internal parameter classes,
customized parameter classes can be created and used.
Steps to Copy a Pattern Group
Do the following to copy a pattern group:
1. From the SECURITY > View Internal Patterns page identify the group you want to copy.
2. Click Copy next to that group. The Copy window appears.
3. In the New Group field, specify a new name for the group and click Paste.
4. Navigate to the SECURITY > Libraries page. The new pattern group appears under the group to which it belongs.
5. Click Edit Pattern to edit a particular pattern.
6. Click Delete to delete a particular pattern.
Creating and Using Custom Attack Types
The SECURITY > Libraries > Attack Types section allows creation of custom attack data types which, when detected in a request, identify the

request as an attack. One or more patterns which define the format of the attack type can be added to each group.
Creating a Custom Attack Type Pattern
1. Go to the SECURITY > Libraries > Attack Types section.

2. Enter a name in the New Group text box and click Add. The new attack type group created appears in the Attack Types section.
3. Click Add Pattern next to that group. The Attack Types window appears. Specify values for the following fields:
a. Pattern Name – Enter a name for the pattern.
b. Status – Set to On if you wish to use this pattern for pattern matching in the responses.
c. Pattern Regex – Define the regular expression of the pattern or click the Edit icon to select and insert the pattern.
d. Pattern Algorithm – Select the algorithm to be associated with the pattern from the list.
e. Case Sensitive – Select Yes if you wish the pattern defined to be treated as case sensitive.
f. Pattern Description – Optional. Enter a description for the defined pattern. Example, Visa credit card pattern would indicate the
pattern matches a visa credit card.
4. Click Add.
Using a Custom Attack Type
The added attack type pattern becomes available under Custom Blocked Attack Types on the following pages and sections:
SECURITY > Libraries > Custom Parameter Class

SECURITY > Website Profiles > URL Profiles
SECURITY > Security Policies > URL Protection
SECURITY > Security Policies > Parameter Protection
The Custom Blocked Attack Types are enabled by default under the SECURITY > Libraries > Custom Parameter Class section and the SEC
URITY > Website Profiles > URL Profiles section. Whereas in the SECURITY > Security Policies > URL Protection and SECURITY >
Security Policies > Parameter Protection pages you have to manually select the custom attack types.
Creating and Using Custom Input Types
The Barracuda Load Balancer ADC includes a collection of predefined and custom input data types, which can be used to validate HTTP
Request parameters. Input data types are used to validate that request parameters conform to expected formats. Most attacks can be prevented
by properly validating input parameter values against expected input data types. Input Type validation enforces the expected formats rather than
trying to identify malicious values. Requests failing validation are identified as intrusions and blocked. Default Input Types including
alpha-numeric strings, credit card, date and positive-long-integer are provided. Custom Input Data Types can also be added.
The SECURITY > Libraries > Input Types section allows you to create customized input data types. One or more patterns which define the
format of the input type can be added to each group.
Creating a Custom Input Type Pattern
1. Go to the SECURITY > Libraries > Input Types section.

2. Enter a name in the New Group text box and click Add. The new input type group created appears in the Input Types section.
3. Click Add Pattern next to that group. The Input Types window appears. Specify values for the fields and click Add to save the pattern.
Using a Custom Input Type
Perform the following steps to use a custom input data type:
1. Go to the SECURITY > Libraries > Custom Parameter Class section.

2. Click Add Custom Parameter Class. The Add Custom Parameter Class window appears.
3. In the Name text box, enter a name for the custom parameter class.
4. Select CUSTOM from the Input Type Validation drop-down list.
5. Select the custom input type you created from the Custom Input Type Validation drop-down list.
6. In the Denied Metacharacters text box, enter the metacharacters or click the Edit icon to select and apply the metacharacters to be
denied in this parameter value.
7. Select the required check box(es) of Blocked Attack Types and Custom Blocked Attack Types and click Add.
8. Bind this custom parameter class to a parameter profile.
Creating and Using Custom Parameter Class
The SECURITY > Libraries > Custom Parameter Class section allows creation of custom parameter classes which enforce expected input
formats and block attack formats for request parameters. One or more patterns which define the format of the data type can be added to each
group. Bind the custom parameter class to a parameter profile by adding a new parameter profile or editing an existing parameter profile using S
ECURITY > Website Profiles.
Creating a Custom Parameter Class
1. Go to the SECURITY > Libraries > Custom Parameter Class section.

2.

2. Click Add Custom Parameter Class. The Add Custom Parameter Class window appears. Specify values for the following fields:
a. Name – Enter a name for the custom parameter class.
b. Input Type Validation – Select the expected type of value for the configured parameter on the SECURITY > Website Profiles.
Most of the attacks could be prevented by properly validating input parameter values against the expected input. Input Type
validation enforces the expected value type as opposed to looking for malicious values. Values of configured parameters are
validated against the specified Input Type and requests with failed validations are detected as intrusions and blocked.
c. Custom Input Type Validation – Select the expected custom input data type for the configured parameter.
d. Denied Metacharacters – Enter the metacharacters to be denied in the parameter value, or click the Edit icon to select and
apply the metacharacters.
e. Blocked Attack Types – Select the check box(es) to detect malicious patterns in the configured parameter. An intrusion is
detected when the value of the configured parameter matches one of the specified Attack Types and the request is blocked.
f. Custom Blocked Attack Types – Select the custom attack type check box(es) to be used to detect the intrusions.
3. Click Add to add the above configuration.
Using a Custom Parameter Class
Perform the following steps to use a custom parameter class:
1. Go to the SECURITY > Website Profiles page

2. In the Service section, click the Website drop-down list and select the Service for which you wish to add the parameter profile.
3. In the URL Profiles section, select the check box next to the URL profile to which you want to add the Parameter profile.
4. In the Parameter Profiles section, click Add Param. The Create Parameter Profile window appears.
5. In the Parameter Profile Name text box, specify a name for the parameter profile. Ensure the Status is set to On.
6. Select CUSTOM from the Parameter Class drop-down list.
7. Select the custom parameter class you created from the Custom Parameter Class drop-down list and click Add.
8. Now, the parameter profile is used to validate the requests coming for the Service you selected depending on the Mode you configured
in the URL profile. For more information on URL and Parameter Profiles. See Configuring Website Profiles.
Creating and Using Custom Response Page
The SECURITY > Libraries > Response Pages section allows creation of customized HTML response pages for HTTP requests that violate
security policies on the Barracuda Load Balancer ADC. Either Edit an existing default response page or use Add Response Page to add
customized response pages that can be shared among multiple Services.
Creating a Custom Response Page
1. Go to the SECURITY > Libraries > Response Page section.

2. Click Add Response Page. The Add Response Page window appears. Specify values for the following fields:
a. Response Page Name – Enter a name for the response page.
b. Status Code- Enter the HTTP status for the response page. Examples:
i. 403 Forbidden
ii. 405 Method Not Allowed
iii. 406 Not Acceptable
c. Headers- Enter the response headers for the response page. Examples:
i. Allow – What request methods (GET, POST, etc.) does the server support?
ii. Content-type – Content type of the resource (such as text/html).
iii. Connection – Options that are specified for a particular connection and must not be communicated by proxies over
further connections.
iv. Location – Where should client go to get document?
v. Refresh – How soon should browser ask for an updated page (in seconds)?
d. Body- Enter the response body for the response page. The following macros are supported:
i. %action-id – This will be replaced by the attack ID of the violation which resulted in the response page to be displayed.
ii. %host – This will be replaced by the host header which sent the request.
iii. %s – This will be replaced by the URL of the request which caused the violation.
iv. %client-ip – This will be replaced by the Client IP of the request which caused the violation.
v. %attack-time – This will be replaced by the time at which the violation occurred.
vi. %attack-name – This will be replaced by the attack name of the violation which resulted in the response page to be
displayed.
3. Click Add to add the new custom page.
Example of a custom response: The request from %client-ip at %attack-time for the URL %s cannot be served due to attack %action-id on the
host %host.
An image can also be embedded in the response page. Here are the steps to do so:
1. Convert the image to base64 using openssl or any other utility. Example: openssl base64 -in barracuda.jpg -out
barracuda-jpg.b64
2. Embed the base64 encoded image into html with the "img" tag. Example: <html><img src="data:image/jpeg;base64,[BASE64

2.
ENCODED IMAGE] alt="Test"/></html>
Using a Custom Response Page
The added response page is listed under the following pages and sections:
SECURITY > Security Policies > Global ACLs > Existing Global ACLs
SECURITY > Security Policies > Action Policy > Action Policy
SECURITY > Allow/Deny > URL : Allow/Deny Rules
Perform the following steps to use a custom response page:
Steps to Use a Custom Response Page in the URL : Allow/Deny Rules
1. Go to the SECURITY > Allow/Deny > URL : Allow/Deny Rules section.

2. Click Add next to the Service for which you want to configure the response page. The Create ACL window appears.
3. In the URL ACL Name text box, enter a name for the URL ACL.
4. Select Response Page from the Deny Response drop-down list.
5. Select the response page you created from the Response Page drop-down list.
6. If required change values of other parameter(s) and click Add.
Steps to Use a Custom Response Page in the Action Policy
1. Go to the SECURITY > Security Policies > Action Policy > Action Policy section.
2. Click Edit next to the action policy for which you want to add the response page. The Edit Attack Action window appears.
3. Select the response page you created from the Response Page drop-down list, and click Save Changes.
Steps to Use a Custom Response Page in the Existing Global ACLs
1. Go to the SECURITY > Security Policies > Global ACLs > Existing Global ACLs section.
2. Click Edit next to the URL ACL for which you want to add the response page. The Edit Global ACL window appears.
3. Select the response page you created from the Response Page drop-down list, and click Save Changes.

Regular Expression Notation

The Barracuda Load Balancer ADC employs a regular expression (regex) engine to evaluate regular expressions (as defined in POSIX 1003.2)
used as values in various parameters. Regular expressions allow you to specify complex relationships. The following table describes syntax rules
that apply when creating a regular expression for a parameter value.
Regular expressions use raw bytes/characters for everything except for NUL(0x00 that gets escaped to %00) and LF(0x0a that gets
escaped to %0a).
Value Meaning
x Match the character x.
. Match any character (byte) except newline.
[xyz] Match the pattern (character class) among x, y, or z. Matching is

case dependent.
[abj-oZ] Match the pattern (character class with a range) among a, b, any
letter from j through o, or Z. Matching is case dependent.
[Â-Z] Match anything except the pattern (negated character class), that is,
any character but those in the class, which in this case is any
character except an uppercase letter.
[Â-Z\n] Match anything except the pattern (negated character class), which
in this case is any character except an uppercase letter or a newline.
r+ Match zero or more of r, where r is any regular expression.
r? Match zero or one of r (that is, an optional r), where r is any regular
expression.
r{2,5} Match two to five of r.
r{2,} Match two or more of r.
r{4} Match exactly 4 of r.
"[xyz]\"foo" Match the literal string: [xyz]"foo
\X If X is an a, b, f, n, r, t, or v, then match the ANSI-C interpretation of

\x applies. Otherwise, it is a literal X (used to escape operators such
as an asterisk [*]).
\0 Match a NULL character (ASCII code 0).
\123 Match the character with octal value 123.
\x2a Match the character with hexadecimal value 2a.
(r) Match the r. Parentheses are used to override precedence;

expressions in parentheses are evaluated first.
rs Match the regular expression r followed by the regular expression s.

This type of pattern is called concatenation.
r|s Match either an r or an s. This type of pattern is called alternation.
r/s Match an r if it is followed by an s. The text matched by s is included

when determining whether this rule is the "longest match," but it is
then returned to the input before the action is executed, so the action
only sees the text matched by r. This type of pattern is called trailing
context.
^r Match an r at the beginning of a line (that is, when starting to scan or

immediately after a newline has been scanned).
Note: The circumflex (^) character means beginning of the input
string when it appear at the beginning of a pattern. If it appears
elsewhere, it is treated as a character.

r$ Match an r at the end of a line (that is, just before a newline). This is
equivalent to r/\n.
Note: The dollar sign ($) character means end of the input string
when it appear at the end of a pattern. If it appears elsewhere, it is
treated as a character.
The following are special characters (that is, have special meaning as described in the above table) and must be escaped by prefixing a
back-slash (\) in order to be recognized as the character itself:
. [ ] ( ) ^ $ / * + ? { } \ |
The following characters must be escaped or quoted during header rule configuration for proper rule matching:
White spaces[' ', '\t', '\n'], the brackets '[' '(' and ')' ']] and ';'
Precede each character with the "\" character to escape it, or quote the entire string.
The regular expressions listed in Regular Expression Values table are grouped according to precedence, from highest precedence at the top to
lowest at the bottom. For example, the following two expressions are identical because the asterisk (*) operator has higher precedence than
concatenation, and concatenation has higher precedence than alternation (|):
foo|bar*
(foo)|(ba(r*))
This pattern matches either the string foo or the string ba followed by zero or more r strings.
Inside a character class, all regular expression operators lose their special meaning except escape (\) and the character class operators dash (-),
right bracket (]), and circumflex (^) at the beginning of the class.
Valid character class expressions are the following:
[:alnum:] [:alpha:] [:blank:]

[:cntrl:] [:digit:] [:graph:]
[:lower:] [:print:] [:punct:]
[:space:] [:upper:] [:xdigit:]
These expressions are equivalent to the corresponding standard C is XXX function. If used in case-insensitive mode, [:upper:] and [:lower:] are
equivalent to [:alpha:].
A rule can have at most one instance of the / or $ operators. The start condition (^) can only occur at the beginning of a pattern, none of these
operators can be grouped inside parentheses. A ^ character that does not occur at the beginning of a rule or a $ character that does not occur at
the end of a rule loses its special properties and is treated as a normal character.
If more than one match is found, the rule matching the most text is used. If two or more matches are of the same length, the first rule is chosen.
Usage Examples:
^r: Match the beginning of an input string only. For example, ^[a-z]+ matches foo but does not match 1foo because the latter does not
begin with an alphabetic character.
[â-z]: Negate character class. This form matches anything other than a lower case alphabetic character. For example, ^[â-z]
matches 1foo but does not match foo.
^ anywhere else: Literal character. For example, ^(^|[a-z]) matches foo and ^1foo but does not match 1foo.
Usage Examples: $
r$: Match the end of an input string only. For example, [a-z]+$ matches foo and 1foo but does not match foo1.
$ anywhere else: Literal character. For example, ([a-z]+|$) matches foo, 1foo, foo1, and foo$.
Usage Examples: Combinations
^r$: Match the pattern exactly. There can be no additional characters.

(r1|r2$): The dollar sign is treated as a literal character.
(^r1|r2): The circumflex is treated as a literal character.

Networking
In this Section
Creating Static Routes

Adding Custom Virtual Interfaces
Network Address Translation NAT
How to Use IPv6 with Barracuda Load Balancer ADC
Multiport Link Aggregation
VLANs
Network Access Control Lists
How the Barracuda Load Balancer ADC Selects the Source IP Address
Subnetwork Masks

Creating Static Routes
Static routes allow you to carefully manage how outgoing network traffic is directed from the Barracuda Load Balancer ADC. There are a variety
of reasons you might want to configure static routes depending on the scale and topology of your network.
The following scenarios describe some instances where you might want to configure static routes:
Configure specific routes to reach a particular network. For the following example, you need to reach the 10.1.0.0/16 network through
interface ge-1-1:
Configure interface ge-1-1 with IP Address 10.1.0.1/16.
Configure the Netmask as 255.255.0.0.
Configure the 10.2.0.1 as the Gateway Address for interface ge-1-1.
Configure a default gateway for network traffic on an interface of Barracuda Load Balancer ADC. A default gateway acts to handle all
network traffic transiting the interface. For example:
Configure interface ge-1-1 with IP Address 0.0.0.0.
Configure the Netmask as 0.0.0.0.
Adding a Static Route
To add a static route navigate to the NETWORK > Routes page and complete the following steps:
1. In the Add Static Route section, select the IP Protocol Version. It can be either IPv4 or IPv6.
2. Specify the IP Address for the destination. If you want this route to apply to any destination IP address, specify 0.0.0.0.
3. Specify the Netmask for the destination network. If you want this route to apply to all destination sub-networks, specify 0.0.0.0.
4. Specify the Gateway Address, the IP address for the network gateway, the device that allows the Barracuda Load Balancer ADC to
reach the destination.
5. Select the Network Interface. This is the interface on the Barracuda Load Balancer ADC on which you want to add the static route.
6. (Optional) Add a comment describing the purpose for the static route.
7. Click Save. The route appears in the Configured Routes table.
Barracuda recommends that you configure static routes to the server network (for the servers configured under the virtual services)
over the data path interfaces. This helps to ensure that data path traffic is not routed over the management interface.
Configured Routes Table
You can view any configured static routes in the Configured Routes table. Each static route is listed under its assigned interface.
To delete a static route, click the trash-can icon in the Options column for the route.

Adding Custom Virtual Interfaces
A configured interface is a logical exit point that allows traffic to flow between servers and the Barracuda Load Balancer ADC. To configure
interfaces, from the NETWORK > Interfaces page, go to the Add Custom Virtual Interface section, and add a virtual interface to the physical
port used to communicate with the servers. You can configure the virtual interface with either an IPv4 or IPv6 address by selecting the
corresponding option from the IP Protocol Version drop down menu.
From the Configured Interfaces section, you can edit any of the virtual interfaces you have configured for the Barracuda Load Balancer ADC.
To configure Custom Virtual Interfaces, you specify the following values:
Name: Enter a name to identify this custom virtual interface.

IP Protocol Version: Select the Internet protocol version from the drop-down list.
IP Address: Enter an IP address to communicate with the servers.
Netmask: Enter an associated Netmask for this interface.
Network Interface: Select the physical interface over which the virtual interface traffic needs to flow.

Network Address Translation NAT
Network Address Translation (NAT) maps private IP addresses to public IP addresses.
NAT allows you to:
Conceal the private IP address from exposure on the public Internet.

Reduce the demand for public IPv4 addresses. Private networks can use the private IPv4 address space and therefore are not in
contention for public IPv4 addresses (which are no longer readily available).
Direct external Internet traffic to the appropriate private IP address.
Source Network Address Translation (SNAT)
Source Network Address Translation (SNAT) maps private IP addresses to a 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 a private IP address into a public 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 a SNAT rule to allow the Real Servers to forward traffic to the Internet if they are located on a
private network and the WAN is on a public network.
Create a Source NAT Rule
Use the following steps to create a source NAT rule:
1. Log into the Barracuda Load Balancer ADC as the administrator, and navigate to the NETWORK > NAT page.
2. In the Add NAT Rule section, enter values for the following:
Pre SNAT Source - Enter the private 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 - Select the traffic to be used for the networks:
TCP
UDP
Any
Destination Port - Enter the destination port. You can either specify an individual port number (for example, 80) or range of port
numbers (for expample, 100-200). The default value of 1-65535 allows traffic from all ports.
Post SNAT Source - Depending on your network configuration, this may be an public IP address or some other IP address on
the WAN side of the Barracuda Load Balancer ADC that is translated by your firewall to a public IP address.
Outgoing Interface - Select the outgoing network interface for traffic to pass through to the Internet.
3. Click Save to save the NAT rule.
High Availability
When setting up High Availability (HA) between two Barracuda Load Balancer ADCs, you can create a custom virtual interface that
associates a public IP address with the WAN port, and then use this IP address to create a SNAT rule. This interface is used by the
backup system if failover occurs. For more information, log into the web interface, go to ADVANCED > High Availability and click the
Help button.

How to Use IPv6 with Barracuda Load Balancer ADC
The Barracuda Load Balancer ADC 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 an IPv4 address configured in the Management IP Configuration section on the BASIC > IP
Configuration page.
IPv6 addresses cannot be configured on the Administrative Console.

Multiport Link Aggregation
Multiport link aggregation, or link bonding, allows you to aggregate multiple physical network links into a single
logical link.You can use link aggregation to achieve multi-gigabit capacity to services and servers.
Caution
Multiport link aggregation is an advanced feature; before completing this deployment, confirm that this configuration is necessary to
meet the needs of your organization.
Use multiport link aggregation to:
Load balance multiple NICs;

Combine multiple network connections;
Incorporate redundancy in case one of the links fails;
Increase bandwidth beyond what is available through one port.
Link Aggregation Requirements
Physical links must be at least 1 Gbps operating in full duplex mode.

If you intend to use Dynamic Link Aggregation Control Protocol (IEEE 802.3ad), the corresponding switch must support it.
The configured speed of all ports of a bonded interface should be same or set to Automatic. You can configure this setting for each port
by editing the port on the NETWORK > Ports page.
Configuring Link Aggregation
To create a link bond, go to the NETWORK > Ports page. Enter a bond name, assign the bond mode, and then select the ports. It is
recommended that you select an even number of ports to bond.
Bond Modes
Three bond modes are supported:
Round Robin
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.
Outgoing traffic is spread across all of the ports in the bond. While round-robin distribution is the only mode that allows a single TCP/IP
stream to use more than one network port worth of throughput, this mode also introduces the potential for out-of-order packets and
retransmitted segments.
Example: Consider a bond configured with 4 ports [ge-1-1, ge-1-2, ge-1-3 and ge-1-4], and mode as Round Robin. In this case all packets
for outgoing traffic during a connection will be routed through all the ports configured in the bond. If there are four TCP segments to be sent
via the example bond, then each port will carry one segment.
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. All the packets are routed through the active port.
Example: Consider a bond configured with 2 ports [ge-1-1 and ge-1-2], and mode as Active-Backup. All outgoing traffic will be routed
through the active port ge-1-1 on the bond. The backup port ge-1-2 becomes active if, and only if, the active port fails.
Dynamic Link Aggregation Control Protocol (LACP) / IEEE 802.3ad Dynamic Link Aggregation
This mode creates aggregation groups that share the same speed and duplex settings, and utilizes all ports in the group according to the
IEEE 802.3ad specification. This does not increase the bandwidth for a single conversation; it achieves high utilization only when carrying
multiple simultaneous conversations.
Verify that IEEE 802.3ad/LACP is enabled on the switch.
Existing IP Addresses
When adding a port to a link, at most one of them may have an IP address configured. If an IP address/Custom Virtual
Interfaces/Static Routes/SNAT IP address exists on one of the ports, it is automatically moved to the newly created bond. However, if you attempt
to add multiple ports with IP addresses configured, you cannot create the bond until you delete these extra IP addresses.
Using a Bonded Interface

Once you create a bonded interface, it appears in the user interface and can be used in the same way as any physical interface. For example,
you will find it in the Interfaces list when you add a service on the BASIC > Services page.
Example - Creating Two Bonded Links
To create two bonded links, one for the service, one for the servers:
1. On the NETWORK > Ports page:

a. Create WANbond0 with ports 1-4
b. Create LANbond1 with ports 5-8.
c. If you selected Dynamic Link Aggregation as the mode, verify that IEEE 802.3ad is enabled on the switches.
2. On the NETWORK > Interfaces page:
a. Add a custom virtual interface that associates the network address of the services subnet with WANbond0.
b. Add a custom virtual interface that associates the network address of the real server subnet with LANbond1.
3. Create a service on the WANbond0 interface on the BASIC > Services page.
High Availability
If you are clustering two Barracuda Load Balancer ADC systems, make sure that each system has similar cabling. If failover occurs, any link
bonds are created on the newly-active system using the corresponding ports. For example, if port ge-1-2 and port ge-1-3 form a bond on the
active system, on failover, the newly-active system will attempt to use these same ports for the bond.

VLANs
The Barracuda Load Balancer ADC supports Layer 2 virtual LANs (VLANs). VLANs allow you to partition a single Layer 2 network into multiple
distinct broadcast domains, effectively allowing you to virtually isolate networks of Layer 2 traffic. The IEEE 802.1q VLAN networking standard is
supported on both the Barracuda Load Balancer ADC network ports and on the management port.
Configuring VLANs
On the NETWORK > VLANs page in the Barracuda Load Balancer ADC web interface, identify your VLANs using the Add VLAN section
. You must specify the VLAN name and ID, and select the interface to use. Once identified, the VLANs are available for selection when
completing the following tasks:
Associating a server or service with a VLAN

Creating a static route
Route to Multiple VLANs over an Interface
If any interface on the Barracuda Load Balancer ADC has to route to multiple VLANs, it must be connected to the VLAN switch via a trunk (or
hybrid) link, since traffic for multiple VLANs can only be transported over trunk links.
Associating the Management Port with a VLAN
You can associate the management port on the Barracuda Load Balancer ADC with a specific VLAN . If you have not specified a VLAN identifier
already, you can go to the BASIC > IP Configuration page and simply specify one using the VLAN ID field and save the change.
If you need to change an existing VLAN identifier to another VLAN identifier or if you need to delete the VLAN identifier, complete the following
steps (you can complete the same procedure using the IPv6 fields if you have configured IPv6 on your network):
1. On the BASIC > IP Configuration page, delete the IPv4 Default Gateway. Save the changes.
2. Configure the new IPv4 Address, IPv4 Subnet Mask, IPv4 Default Gateway, and the VLAN ID (if you need to delete the VLAN
identifier, you can do so now). Save the changes.
Before you change the IP settings for the management port, ensure that the new settings are network accessible from your
management PC. If you loose network access to the management port, you will need to connect to the console port on the Barracuda
Load Balancer ADC and reconfigure the IP settings from the console.

Network Access Control Lists
You configure network Access Control Lists (ACLs) to match IP traffic with a corresponding firewall action. If there is a rule match, the specified
firewall action is executed. ACLs can be created by matching a source network/host, or by designating an IP Reputation pool as the source.
Network ACL rules regulate traffic passing between a source IP address and a destination IP address. Geo ACL rules regulate traffic originating
from a specific geographic location based on its IP reputation (configured on the NETWORK > IP Reputation page).
The following types of ACLs can be configured:
Global Start
Global Network ACL
Global Geo ACL
Service
Service Network ACL
Service Geo ACL
Default ACL
Global End
Global Network ACL
Global Geo ACL
The ACLs configured under global_start are the system rules associated with all Services configured on the Barracuda Load Balancer ADC. The
global ACL (global_start) rules override ACLs configured under the Service (if configured).
The following outlines of when rule actions are performed:
1. Incoming packets are checked for a match with the global_start ACLs. If there is a match, the corresponding action (allow/deny) is
applied.
2. If not, the packets are matched with the ACLs configured under the Service (if any).
3. If the packet does not match global_start ACLs (Network or Geo) and Service ACLs (Network or Geo), the packet is matched with the
Services Default ACL rule and the corresponding firewall action is performed.
4. If the packet does not match any of these ACLs, the packets are matched with the global_end Network ACL rules.
5. If no ACL rules are configured under global_end, the packets are passed through.
Multiple Network and Geo ACLs can be configured for a Service. Each ACL is prioritized in ascending order and defines the permission rights for
clients or servers attempting to access the contents of a Service. IP addresses set within any ACL should be unique and not derived from any
other ACLs.
To create a Network or Geo ACL rule:
1. Go to the NETWORK > Network Firewall page.

2. In the Network ACLs section:
Click Network or Geo next to global_start or global_end (if you want to add a global ACL rule that will be matched with all
incoming packets).
Click Network or Geo next to a Service to add a Service specific ACL rule.
3. Specify values for the given fields and click Save.
For more information, click Help on the relevant page of the web interface.
ACLs for Forwarded Traffic
ACLs allow traffic from designated clients to pass through the Barracuda Load Balancer ADC to the back-end servers without any security
validations.
To add ACLs for Forwarded Traffic:
1. Go to the NETWORK > Network Firewall page.

2. In the ACLs for NAT/Forwarded Traffic section, click Add ACL.
3. In the Add ACL for NAT/Forwarded Traffic window, specify the values for the given fields and click Save.
For more detailed information, click Help on the relevant page of the web interface.

How to Configure an IP Reputation Pool

An IP reputation pool is a group of IP addresses that you can use in the network ACLs for a service. Each pool can include the following types of
IP addresses:
Geo Pool – List of geographical regions. You can create multiple pools with different geographical regions.
Anonymous Proxy – The IP addresses of proxies that hide the identifying information of client computers.
Satellite Provider – The IP addresses of satellite ISPs.
Traffic arriving at a service from the IP addresses in the IP reputation pool are blocked or denied, according to the network ACLs for the service.
Create an IP Reputation Pool
To create an IP reputation pool:
1. Go to the NETWORK > IP Reputation page.

2. In the Add IP Reputation Pool section, enter a name for the pool and select the types of IP addresses that you want to include in the
pool.
a. If you want to include all geographical regions, select the Geo Pool check box.
b. If you want to include only certain geographical regions, click Expand to find and select the regions.
3. Click Save. The new IP reputation pool appears in the IP Reputation Pools section.
You can add the IP reputation pool to the network ACL for a service on the NETWORK > Network Firewall page.
Edit an IP Reputation Pool
Configured IP reputation pools are listed in IP Reputation Pools section of the NETWORK > IP Reputation page.
To edit an IP reputation pool, click Edit ( ). To delete an IP reputation pool, click Delete ( ).

How the Barracuda Load Balancer ADC Selects the Source IP Address
The Barracuda Load Balancer ADC randomly selects an IP address from the custom virtual interfaces to use as the source IP address to connect
to the servers.
If you need to override the default behavior and specify the IP address used to communicate with the servers, complete the following steps:
1. Create a single custom virtual interface (See Adding Custom Virtual Interfaces) on the Load Balancer ADC, specifying the IP address
which you want the Barracuda Load Balancer ADC to use when connecting to the servers.
2. Specify a non-32 bit network mask for this custom virtual interface.
3. Specify 32-bit network masks for all other services and custom virtual interfaces configured on the Load Balancer ADC.
The Barracuda Load Balancer ADC will now use this custom virtual interface with the non-32 bit network mask to communicate with servers.
For additional information about these requirements, contact Barracuda Technical Support.

Subnetwork Masks
If you are unfamiliar with sub-networking, Barracuda Networks recommends that you spend some time learning about the concept before
configuring the network settings on your Barracuda Load Balancer ADC. Sub-networking is a decades old networking concept and as such there
is a wealth of information available on the Internet. However, the following information about sub-networking and subnetwork masks (netmasks)
provides some information on how to configure netmasks for the Barracuda Load Balancer ADC.
Sub-networking is the concept of logically dividing up the available network address space. In the context of a Barracuda Load Balancer ADC
deployment, this typically means the sub-networking of the private network address space being used within your organization. IPv4 designates
10.x.x.x, 172.16.x.x through 172.31.x.x, and 192.168.x.x as private address spaces, meaning that these addresses cannot be routed over the
public Internet and can only be used within private networks. The netmask you specify determines the number of network nodes that are directly
accessible by the Barracuda Load Balancer ADC. Sub-networking effectively allows you to isolate your Barracuda Load Balancer ADC and the
systems it supports on their own network. It also allows the Barracuda Load Balancer ADC to easily communicate with the other devices on its
own subnet.
There are many reasons you might need to configure a subnet for the Barracuda Load Balancer ADC. For example, you plan to use your
Barracuda Load Balancer ADC to load balance traffic across your web servers. Given that the volume of network traffic flowing back and forth
through the Barracuda Load Balancer ADC and the web servers it supports could be orders of magnitude greater than the volume of traffic
flowing over the rest of your private network (for example, the network traffic being exchanged by your employees), you might want to isolate the
Barracuda Load Balancer ADC and the web servers from the rest of your internal network.
The following example illustrates a simple solution to this problem. You would configure the IP address for the virtual service on your Barracuda
Load Balancer ADC as 192.168.1.1 and specify the netmask as 255.255.255.0 (this can also be represented as /24, representing the first 24 bits
of the IP address). This effectively isolates this virtual service to the 192.168.1.x private network. For this to function correctly, you would also
need to configure IP addresses on the same network for the web servers whose traffic is to be load balanced. For example, Web Server A could
use the address 192.168.1.2 and Web Server B could use the address 192.168.1.3. You could configure the same netmask for both web servers,
255.255.255.0, isolating them on the same private network (192.168.1.x) as the virtual service configured on the Barracuda Load Balancer ADC.
This example is relatively simple and would likely be useful for small to medium sized organizations (with dozens to hundreds of networked
devices). However, there is a wasteful element to the above example. Using the 255.255.255.0 netmask means that, of the 254 usable addresses
on this network, only 3 are being used. The other 251 addresses (192.168.1.4 through 192.168.1.254) aren't being used and can't be used by
other devices on your network (unless you want them to also share the network used by the Barracuda Load Balancer ADC and the web
servers). In larger organizations with thousands or tens of thousands of devices connected to the internal network, you might want to more
efficiently use your network address space. You could specify a narrower range of addresses by using a 255.255.255.240 netmask (a /28
subnet). This limits the range of addresses available to 192.168.1.1 through 192.168.1.14 (14 usable addresses), leaving the other addresses on
the 192.168.1.x network (192.168.1.16 through 192.168.1.254) available for use on other internal networks. It also provides some room for
expansion on the 192.168.1.1/28 subnet. There are 11 more usable addresses on this subnet which allows you to add additional web servers
without having to reconfigure all the network nodes (the Barracuda Load Balancer ADC virtual service, Web Server A, and Web Server B).
There are special implications to configuring a netmask of 255.255.255.255 or /32 for a virtual service on the Barracuda Load Balancer ADC.
Using our example, if you configure a virtual service with the address 192.168.1.1 and assign it a netmask of 255.255.255.255, the virtual service
can still receive traffic sent to 192.168.1.1. However, it cannot send traffic out using the same address. With a /32 netmask, the virtual service is
acting as an end host, the only device able to receive traffic on the 192.168.1.1 network. To forward traffic to other devices, the Barracuda Load
Balancer ADC requires additional configuration (a static route for example), allowing it to communicate with devices on a separate network. There
are reasons why you would want to configure a virtual service with a /32 netmask. However, those reasons are beyond the scope of this article.

Certificate Management
In an SSL transmission between a client and a server, the client requests a secure connection, and the server
responds with a certificate, identifying the certificate authority (CA) and the server’s public encryption key. This
allows the client to verify the server identity. If satisfied with the authenticity of the server, the client sends a test
transmission which can only be decrypted with the private key of the server. This transmission allows both parties to
encrypt and decrypt the impending transaction. A server may refuse to communicate with clients that fail to provide
a certificate for authentication.
The Barracuda Load Balancer ADC acts as a server on the front-end (Internet facing), receiving client requests. On the back end, the Barracuda
Load Balancer ADC acts as a client to the web servers, forwarding safe requests to them. In each case, data can be secured using SSL,
providing end-to-end secure data for requests and responses. Certificates can be obtained from a trusted CA or be self-signed.
The Barracuda Load Balancer supports SSL certificates in PKCS #12 and PEM formats. The certificates can be uploaded on the BASIC >
Certificates page.
In this Section
How to Add an SSL Certificate

Installing SSL Certificates with Correct Chain Order
How to Pass Client Certificate Details to a Back-end Server
Allowing or Denying Client Certificates
Client Certificate Validation Using OCSP
Creating a Client Certificate

How to Add an SSL Certificate
You can create a self-signed certificate, or upload a trusted certificate.
Signed Certificate Format

You can upload a signed certificate in either PKCS #12 Token Format or PEM format.
Adding a PKCS #12 Token Format Certificate
Use the following steps to upload a signed certificate obtained from a trusted Certificate Authority (CA) in PKCS #12 Token Format.
1. Log into the Barracuda Load Balancer ADC web interface, and go to the BASIC > Certificates page.
2. In the Upload Certificate section, select the Certificate Type as PKCS12 Token.
3. Set Allow Private Key Export to Yes to export the private key corresponding to the certificate.
Important
Certificates are downloaded in PKCS #12 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 PKCS #12 token for the signed certificate to be
uploaded.
6. Click Browse next to the Signed Certificate field, and select the PKCS #12 format signed certificate file.
Important
When uploading a signed certificate as a PKCS #12 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.
2. In the Upload Certificate section, select the Certificate Type as PEM Certificate.
3. Set Allow Private Key Export to Yes to export the private key corresponding to the certificate.
Important
Certificates are downloaded in PKCS #12 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.
4. If the certificate signing request (CSR) for this certificate was generated on the Barracuda Load Balancer ADC, set Assign the
associated key to Yes, otherwise, select No, and upload the private key in the Certificate Key field.
5. Enter an identifying name in the Certificate Name field.
6. 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. Click Browse next to the Signed Certificate field, and select the PEM format signed certificate file.
8. Click Browse next to the Intermediary Certificates field, and select the intermediary CA certificate. To add additional intermediary CA
certificates, click the plus ( + ) button.
9. 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 ADC web interface, and click the Help
button.

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.
Step 1 - Downloading the Certificate
Use the following steps to download the certificate from the Barracuda Load Balancer ADC:
2. In the Saved Certificates table, locate the certificate, and click Certificate in the Download column.
3. In the Save Token page, enter a passphrase in the Encryption Password field, and click Save.
4. The certificate is exported as a PKCS #12 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 ADC.
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
If the private key is encrypted, use the following steps to extract the private key from the PKCS #12 token and decrypt the private key on either a
Linux system or a Windows system using OpenSSL.
OpenSSL
Linux generally comes with OpenSSL preinstalled.
You can download OpenSSL version 1.0.2d for Windows from https://slproweb.com/download/Win32OpenSSL-1_0_2d.exe (d
ownload a later version if one is available from https://slproweb.com/products/Win32OpenSSL.html).
1. If you are using a Windows system, open a command prompt and change the working directory to the one where you installed OpenSSL
so you can run OpenSSL from the command line:
C:\OpenSSL-Win32\bin\>
2. Enter the following command to simultaneously extract and encrypt the private key. This command looks for the certificate file in the
C:\\OpenSSL-Win32\bin\ folder. If the file is located in a different drive or folder, prefix the path to the file name accordingly.
openssl pkcs12 -nocerts -in certificate.pfx -out private_key_encrypted.pem
3. When prompted, enter the password you assigned when downloading the .pfx file from the Barracuda Load Balancer ADC in point 3 in
the section Step 1 - Downloading the Certificate.
4. (Optional) You can export the signed certificate using the following command:
openssl pkcs12 -nokeys –nodes -in certificate.pfx -out signed_cert.cer
5. (Optional) You can decrypt the encrypted private key using the following command:
openssl rsa -in private_key_encrypted.pem -out private_key_decrypted.pem
Step 3 - Getting the Intermediate and Root Certificates
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.
1. On the system where you downloaded the certificate, double-click the downloaded certificate, for example, mycertificate.cer, and click
the Certificate Path tab.
2. 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.
3. Open Internet Explorer, and go to Tools > Internet Options > Content > Certificates .
4. Click the Intermediate Certification Authorities tab, and select the relevant certificate.
5. 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.
6.

6. In the Certificates page, click the Trusted Root Certification Authorities tab, and select the root certificate.
7. 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.
8. 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:
1. In the Barracuda Load Balancer ADC web interface, go to the BASIC > Certificates page.
2. In the Upload Certificate section, enter a name for the certificate in the Certificate Name field.
3. Select the Certificate Type as PEM Certificate.
4. Select Yes for Allow Private Key Export, and set Assign Associated Key to No.
5. In the Signed Certificate field, click Browse, and navigate to and select the Server Certificate.
6. In the Certificate Key field, click Browse, and navigate to and select the Private Key.
7. In the intermediary Certificates field, click Browse, and navigate to and select the Intermediate Certificate.
8. Click the plus ( + ) symbol following the Intermediary Certificates field.
9. In the new intermediary Certificates field, click Browse, and navigate to and select the Root Certificate.
10. Click Upload Now to upload the certificate.
11. 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 ADC is unable to verify the issuer from the Barracuda Load Balancer ADC's issuer
information internal bundle. This Barracuda Load Balancer ADC 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.

How to Pass Client Certificate Details to a Back-end Server
You can configure the Barracuda Load Balancer ADC to pass information from a client to the back-end server through the Barracuda Load
Balancer ADC. Using this feature web servers can access client authentication information like Client Certificate parameters or authenticated
username and password.
On the Barracuda Load Balancer ADC, you can add client information to a request by configuring a Request Rewrite. Headers can be inserted
into the request, or existing headers can be rewritten or deleted before passing the request to the web server, which can then extract the added
information. The Barracuda Load Balancer ADC provides macros you can use to communicate request parameters like client certificate details or
authenticated user information through headers.
Configuring Request Rewrite to Pass Client Information to a Web Application
To configure a request rewrite rule, perform the following steps:
1. Go to the TRAFFIC > Web Translations page, and in the HTTP Request Rewrite section specify values for the following fields:
a. Rule Name – Enter a name for the request rewrite rule.
b. Sequence Number – Set the sequence number for the request rewrite policy. The sequence number determines the order of
execution for multiple configured policies from highest (1) to lowest (1500).
c. Action - Select the action. To modify client information sent to the web application, the request rewrite action should be set to In
sert Header or Rewrite Header.
d. Header Name – Enter the relevant Header Name, for example X-Forwarded-For.
e. Old Value – Enter the initial request header to be rewritten if the Action is Rewrite Header. An asterisk (*) rewrites all named
headers, or specify the value or expression to be rewritten.
f. Rewrite Value – Enter the new value of the header to be rewritten when the Action is set to Insert Header or Rewrite Header.
Use the macros listed below to specify parameters from the client. When rewriting a header you can specify one or more fields
using the separators such as colon (:), semicolon (;), space ( ) and comma (,). In Rewrite Value, the fields can be defined for
example: "Name=abc_cookie; Domain=example.com:Path=/". The rewrite-value supports substring addressing of matches, i.e.
the matching substrings can be referenced using $1,$2,...$n. The following macros are supported for rewrite values:
$X509_ORGANIZATION, $X509_LOCALITY, $X509_CN, $X509_COUNTRY, $X509_OU,$X509_STATE, $X509_EM
AIL, $X509_SUBJECT, $X509_WHOLE: Fields in the X509 client certificate when client authentication is On.
$SRC_ADDR: The client IP from which the request originated.
$DST_ADDR: The destination address.
$URI: URI.
$AUTH_USER: Username of the authenticating user.
$AUTH_PASSWD: Password of the authenticating user.
$AUTH_GROUPS: Group associated to the authenticating user.
g. Rewrite Condition – Set the condition under which a rewrite should occur. An asterisk (*) indicates there are no conditions
(applies to all). Details on the format of the Rewrite Condition are explained below in Rewrite Condition Format.
Note: When multiple policies are configured, the request continues to be processed by other (higher sequence number) policies. If you wish to
stop processing after a particular rule is matched, click Edit next to the rule and set Continue Processing to No.
Rewrite Condition Format
The request Rewrite Condition specifies when a rewrite should occur. The Rewrite Condition is made up of expressions combining Request
Rewrite Tokens and Operations on those tokens. These expressions can then be joined with each other using logical or (or, OR, ||) or logical and
(and, AND, &&). Examples of Rewrite Conditions: (Header User-Agent co mozilla), (URI rco /abc*html), (Client-IP eq 10.0.0.1)&&(Method eq
POST). An asterisk indicates there are no conditions for rewrite, so the rewrite is done in every case.
Request Rewrite Tokens
These tokens can be used in a request Rewrite Condition:
Header: The HTTP header in the request. The word Header precedes the name of the relevant header or * to indicate all headers.
Client-IP:The IP address of the client sending the request. The IP address can be either a host IP address or a subnet specified by a
subnet mask. Only operations EQ and NEQ can be combined with this token. Examples: Client-IP eq 192.168.1.0/24 (subnet qualified by
a netmask) Client-IP eq 192.168.1.10 (host IP address)
Uri: The Uniform Resource Identifier of the resource on which to apply the rule. Example: URI rco /abc*html
Method: The HTTP method in the request. Example: Method eq GET
Http-Version: The HTTP protocol version of the request. Example: HTTP-Version eq HTTP/1.1
Parameter: The query part of the URL which is passed to the servers as a name-value pair. In addition, the word "$NONAME_PARAM"
can be used when the parameter name is absent. Examples: Parameter sid eq 1234, Parameter $NONAME_PARAM co abcd
Pathinfo: The portion of URL which contains extra information about the path of the resource on the server. Example: pathinfo rco abc*

Operations for Request Rewrite
These operations can be combined with Request Rewrite Tokens in a request Rewrite Condition:
contains, CONTAINS, co, CO – Token contains the given value.

ncontains, nCONTAINS, nco, nCO – Token does not contain the given value.
rcontains, rCONTAINS, rco, rCO – Token contains the given value which is interpreted as a regular expression.
equals, EQUALS, eq, EQ – Token equals the given value.
nequals, nEQUALS, neq, nEQ – Token does not equal the given value.
requals, rEQUALS, req, rEQ – Token equals the given value interpreted as a regular expression.
exists, EXISTS, ex, EX – Token exists.
nexists, nEXISTS, nex, nEX – Token does not exist.

Allowing or Denying Client Certificates
The TRAFFIC > Client Certificates page allows you to define allow/deny rules based on Client Certificates. These settings are not used unless
Enable Client Authentication is Yes for the Service on the BASIC > Services page under Advanced Options.
When Client Authentication is turned on for a service, all clients are required to present a certificate to access the website. The certificate is first
checked for validity. A valid certificate cannot be expired, and must be signed by a certificate authority (CA) listed under Trusted Certificates for
the service. Even a valid certificate signed by a trusted CA can be rejected based on the certificate attributes. This is useful when you wish to
revoke an issued valid certificate.
How it works:
Each Allow/Deny rule has the following important attributes:
A sequence number specifying the order in which to evaluate the rule.

A set of attribute matches (like Certificate Serial number). The attribute can either be a wildcard match (*, to indicate match any value), or
it can be a specific value, matching the certificate's corresponding attribute exactly.
An action to take when the presented client certificate matches this rule.
When a request is received, the Client certificate is compared to all Allow/Deny rules in sequence number order, starting from the lowest
sequence number. Each attribute in the rule is compared, and if all attributes match a rule, the corresponding action (Allow or Deny) is taken and
no further rules are compared.
When no rule matches the Client Certificate in the request, the request is allowed by default.
To allow only requests whose Client Certificates match a rule, create a Deny rule with a high sequence number (10000, for example) which
matches all rules (has * for all attributes) and the action Deny. Every request with a client certificate which fails to match a rule will be denied.
Each allowed certificate must have a corresponding Allow rule with a lower sequence number.
If you create a high sequence number Deny rule to deny all except explicitly allowed Certificates, a request will be allowed only if its
Certificate and all Certificates in its chain match an Allow Rule. If its intermediate or Trusted Certificate does not match any rule, the
request is denied.
Complex rules can be built using Allow/Deny rules. For example, to deny all certificates from the Sales department except one that is identified by
its serial number, create the following two rules:
Sequence = 1; Action = Allow; Organizational Unit = Sales; Serial Number = 12345

Sequence = 2; Action = Deny; Organizational Unit = Sales
While complex rules can be built if needed, the recommended configuration allows all certificates signed by a trusted CA and uses the
Allow/Deny list only to revoke access for issued certificates that are no longer valid. The Certificate serial number can uniquely identify a
Certificate issued by a single CA in the event that it must be revoked. The Common Name can also be used to identify a revoked Certificate.
Configuring Allow/Deny Certificate Rules
Detailed instructions for configuring Allow/Deny Certificate rules are available on the TRAFFIC > Client Certificates page by clicking Help on
that page.
For a certificate to be allowed using an Allow Rule, ensure that Allow Rules also exist for all Certificates in its chain. If the Certificate
itself matches an Allow Rule, but its intermediate or Trusted Certificate does not match any rule, the request is denied.

Client Certificate Validation Using OCSP
The Barracuda Load Balancer ADC supports Online Certificate Status Protocol (OCSP) to determine updated status of a digital certificate. While
Certificate Revocation Lists (CRLs) provide periodically updated certificate status, OCSP provides more current revocation status information for
certificates. A central OCSP server (aka OCSP Responder), a trusted Certificate Authority (CA) itself, collects and updates CRLs from various
Certificate Authority (CA) servers. When OCSP is enabled, the Barracuda Load Balancer ADC communicates with the OCSP server to validate
the revocation status of client certificates before allowing or denying SSL connections from the respective clients.
Functioning of OCSP Validation
When a client attempts to access a server, an OCSP status request for the client certificate is sent to an OCSP Responder. The OCSP
Responder validates whether the status request contains the information required to identify the certificate and then returns a signed response
message indicating the status as one of the following:
"GOOD" indicates a positive response that the certificate is not revoked.

"REVOKED" indicates that the certificate has been revoked.
"UNKNOWN" indicates that the OCSP Responder has no information about the requested certificate.
For any error or failure, the Responder may return an unsigned message indicating a failed communication, logged under System Logs. Errors
can occur because of a malformed request, an internal error, or an unauthorized request. To view system logs, navigate to the ADVANCED >
System Logs page. If you want system events sent to the syslog servers, configure one or more (maximum of three) syslog servers using Add
Syslog Server on the ADVANCED > Export Logs > Syslog section. For more information on configuring syslog, see the Online help .
Enforce Client Certificate must be set to Yes for a service on the BASIC > Services page if you want to authenticate client
certificates using OCSP.
Configuring OCSP Validation
To enable OCSP validation, do the following:
1. Go to the TRAFFIC > Client Certificates page.

2. In the Client Certificate Validation - OCSP section identify the Service for which you want to enable client certificate validation, and
click Edit next to that Service. The Client Certificate Validation - OCSP window appears.
3. Specify values for the following fields:
a. Enabled - Set to Yes to enable OCSP validation.
b. OCSP Responder URL - Specify the OCSP Responder URL. This is the URL issued by the trusted Certificate Authority (CA)
where the Barracuda Load Balancer ADC will send the OCSP requests. Both HTTP and HTTPS (SSL/TLS) URLs can be
specified. For example, http://ocsp.example.com
c. Certificate - Click the drop-down list and select the certificate to verify the signature on the OCSP response.
4. Click Save Changes.

Creating a Client Certificate
Before creating a client certificate you should create a CA certificate which can be used as the root CA certificate to sign the client certificates.
To create a CA certificate for the server designated as SSL CA server, perform the following steps:
Step 1 - Generate a Private Key for the CA Certificate
To generate a key for a CA certificate, run the following openssl command on your server:
openssl genrsa 2048 > ca-key.pem
This generates a private key “ca-key” in PEM format.
Step 2 - Create a CA Certificate using the Private Key
Use the private key generated in Step 1 to create the CA certificate for the server.
The openssl command to generate a CA certificate is as follows:
openssl req -new -x509 -nodes -days 1000 -key ca-key.pem > ca-cert.pem
You will be prompted to provide certain information which will be entered into the certificate.
See the example below:
Country Name (2 letter code) [AU]: US

State or Province Name (full name) [Some-State]: California
Locality Name (eg, city) []: Campbell
Organization Name (eg, company) [Internet Widgits Pty Ltd]: Barracuda Networks
Organizational Unit Name (eg, section) []: Engineering
Common Name (eg, YOUR name) []: barracuda.yourdomain.com
Email Address []: test@myemail.com
This creates the CA certificate with the values above. This certificate acts as a root CA certificate for authenticating the client certificates.
Step 3 - Import the CA Certificate to the Barracuda Load Balancer ADC
The created certificate needs to be uploaded in the BASIC > Certificates > Upload Trusted (CA) Certificate section.
Step 4 - Enable Client Authentication on the Barracuda Load Balancer ADC
To be able to use the CA certificate for validating client certificates, client authentication should first be enabled.
Steps to enable client authentication:

2. In the Configured Virtual Services section, identify the service for which you want to enable client authentication.
3. Click Edit next to the service. In the Service edit page, scroll down to the SSL section.
4. Set Enable Client Authentication and Enforce Client Certificate to Yes.
5. Select the check box(es) next to the Trusted Certificates parameter.
6. Specify values for other parameters as required, and click Save Changes.
Step 5 - Create a Client Certificate
To create a client certificate, use the following example:

openssl req -newkey rsa:2048 -days 1000 -nodes -keyout client-key1.pem > client-req.pem
Generating a 2048 bit RSA private key writing new private key to 'client-key1.pem'
......................................................................................+++
..+++
writing new private key to 'client-key1.pem'
-----
You are about to be asked to enter information that will be incorporated into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,

If you enter '.', the field will be left blank.

-----
Country Name (2 letter code) [AU]: US
State or Province Name (full name) [Some-State]: California
Locality Name (eg, city) []: Campbell
Organization Name (eg, company) [Internet Widgits Pty Ltd]: Barracuda Networks
Organizational Unit Name (eg, section) []: Tech Support
Common Name (eg, YOUR name) []: barracuda.mydomain.com
Email Address []: test@youremail.com
Please enter the following 'extra' attributes to be sent with your certificate request
A challenge password []: Secret123
An optional company name []: -
This creates the private key “client-key1.pem” in PEM format.
Now, use the following example to create a client certificate that will be signed by the CA certificate created in Step 2.
openssl x509 -req -in client-req.pem -days 1000 -CA ca-cert.pem -CAkey ca-key.pem -set_serial 01 >
client-cert1.pem
Signature ok
subject=/C=US/ST=California/L=Campbell/O=Barracuda Networks/OU=Tech
Support/CN=barracuda.mydomain.com/emailAddress=test@youremail.com
Getting CA Private Key
Step 6 - Converting PEM File to PKCS #12 Format
Use the following command to convert the “client-cert1.pem” certificate along with “client-key1.pem” to a Personal Information Exchange file (pfx
token).
openssl pkcs12 -export -in client-cert1.pem -inkey client-key1.pem -out client-cert1.pfx
Enter Export Password:secret

Verifying - Enter Export Password: secret
Step 7 - Import the Client Certificate to the Browser
The client certificate created above should be sent to the client to be imported on their browser.

Monitoring
In this Section
The following articles describe how to configure the monitoring features of the Barracuda Load Balancer ADC:
How to View System Health, Status, and Statistics

Monitoring the Health of Services and Servers
Reporting
How to Automate System Alert and SNMP Trap Delivery
How to Configure SNMP Monitoring on the Barracuda Load Balancer ADC
SNMP Objects and Traps
How to Enable, Disable, and Maintain Real Servers
How to Remotely Administer Real Servers
How to View System Tasks

How to View System Health, Status, and Statistics
The BASIC > Status page provides an overview of a various systems and components of the Barracuda Load Balancer ADC. For detailed
information about each of the information modules displayed on this page, see the online help. You can change which graphs are displayed on
the BASIC > Status page by clicking the preferences icon.
Hardware, System, and Performance
Traffic Statistics - Displays the total number of web requests and connections that have been received on the Barracuda Load Balancer
ADC during the last hour, day, and week.
Performance Statistics - Displays the current operating states of the system, including System Load, Firmware Storage, and High
Availability Status. Serious problems are displayed in red.
Events - Displays the number of events that are generated by the system on the BASIC > Web Firewall Logs, BASIC > Audit Logs, N
ETWORK > Network Firewall Logs, ADVANCED > System Logs pages.
Subscription Status - Displays the current status of your Energize Updates and (if applicable) Instant Replacement subscriptions, along
with any other subscriptions that you might have for the Barracuda Load Balancer ADC.
Interfaces - Displays the states of all available interfaces.
Total Traffic - Displays the total traffic in bits (kilobits, megabits, or gigabits) per second that passed through the interface(s) of the
Barracuda Load Balancer ADC, during the time period that is selected (Last Day, Last Hour, Last Month).
Attacks - Displays the total number of attacks that was received across all websites during the selected time period.
CPU Utilization - Displays the percentage of the CPU that was used during the selected time period.
Memory Utilization - Displays the total memory in bytes (kilobytes, megabytes, or gigabytes) that was used during the selected time
period.
Services
Services : Bandwidth - Displays the total traffic processed by the specified services in bits (kilobits, megabits, or gigabits) per second
during the selected time period.
Services : Active Connections - Displays the number of active connections to the specified services during the selected time period.
Services : Connections Rate - Displays the number of connections arriving at the specified services per minute, during the selected time
period.
Services : Requests Rate - Displays the number of requests received by the specified services per minute, during the selected time
period.
Servers
Servers : Bandwidth - Displays the total traffic processed by the specified servers in kilobits per second, during the selected time period.
Servers : Connections/Requests Rate - Displays:
The number of TCP connections to the specified servers per minute, during the selected time period for TCP Proxy and Layer 4
services.
The number of HTTP requests to the specified servers per minute, during the selected time period for HTTP and HTTPS
services.
The number of SSL sessions to the specified servers per minute, during the selected time period for FTP and SSL services.
Other Types of Information
Cache Efficiency - Displays the amount of data that is served from the cache versus the total amount of outbound traffic passing through
the Barracuda Load Balancer ADC, during the selected time period.
Cache Hits - Displays the number of HTTP responses served from the cache versus the total number of HTTP responses passing
through the Barracuda Load Balancer ADC, during the selected time period.
Cache Effectiveness For Services - Displays the percentage of data that was served from the cache during the selected time period, for
all outbound traffic passing through the Barracuda Load Balancer ADC for the selected services.
Compression Efficiency - Displays the size of the compressed responses sent to the clients versus the size of the uncompressed
responses received from the real servers, during the selected time period.
Compressed Responses - Displays the number of compressed HTTP responses versus the total number of HTTP responses, during the
selected time period.
Data Compression Effectiveness For Services - Displays the percentage of responses that was compressed during the selected time
period, for all responses that were received from the real servers from the selected services and sent to clients.
Enlarging and Magnifying a Graph
To enlarge a graph in a pop-up window, click the expand icon. To magnify an area of a graph, click and drag over the area. Click Reset Zoom
to reset the graph view.

Monitoring the Health of Services and Servers
Use the Service Monitor to check the health of your services and servers on an ongoing basis. A visual indicator appears next to the service or
server if it is not available. You can enable notifications on a per-service basis to have an email sent to the system alerts email address(es)
recorded in the BASIC > Administration page if the number of operating real servers for a service falls below a preset threshold. Also, you can
configure SNMP traps to be generated on certain conditions using the ADVANCED > SNMP Configuration page.
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 Real Server status indicators:
- The Real Server is up and responding to requests.
- 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.
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 TRAFFIC > Monitor Groups page. Then edit the Real Server or Service. The
monitor groups appear in the Testing Methods for the Service or Server Configuration page.

How to Create Monitor Groups

Use the TRAFFIC > 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, a test delay, and other options which
vary depending on which testing method you select:
Testing Method – Select from the list of all testing methods that are supported by the Barracuda Load Balancer ADC. See Understandin
g 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. You can enter either an IPv4 or IPv6 by selecting the appropriate option
using the dropdown menu. If left blank when using this group as the Testing Method for a Service, this test is applied to every Real
Server associated with the Service. If left blank when this group is used as the Testing Method for a Real Server, then that Real Server
will be tested.
Port – Port number used for running the test. Leave blank to use instance port.
Test Target – Enter the complete URL, starting with HTTP or HTTPS.
Test Match – Enter the pattern expected in the resulting HTML.
HTTP Methods – Select the HTTP method for the Monitor Test.
GET
HEAD
POST
HTTP Version – Select the HTTP version for the Monitor Test.
HTTP/1.0
HTTP/1.1
Additional Headers – Additional headers to be sent with the HTTP request, like Header1:Value1, Header2:Value2.
Status Code – Specify the expected HTTP response status code when accessing the URL. Any other status code is considered to be
unsuccessful, and will result in setting the server as out-of-service. Recommended: 200
Test Delay – How often, in seconds, the 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 Mo
nitor 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 page and the Server Configuration page.
Click Preferences to specify the number of groups shown on each page of this table.

Understanding Testing Methods for Services and Real Servers

Testing Methods are used by the Barracuda Load Balancer ADC 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 Edit next to the Service you wish to modify. To specify a test on
a Real Server basis, click Edit next to the IP address of the Real Server on the BASIC > Services page to display the Server Configuration pag
e.
The tests use the Real Server port configured on the Server Configuration 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 1. Monitor Group Testing Methods.
Test Name Description Test Target Test Match
TCP Port Check For Services specified with n/a n/a

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.
UDP Port Check Check if the UDP port is open by n/a n/a
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.
HTTP Performs an HTTP GET request Enter the complete URL starting Enter a pattern expected in the
to the specified URL. The Real with "http:" resulting HTML.
Server is used as a proxy server
to retrieve the page, so the
forward proxy setting on the Real
Server must be enabled.
Simple HTTP Performs an HTTP GET request Enter the root relative URL (such Enter a pattern expected in the
to the specified relative URL on as /cgi-bin/index.cgi). resulting HTML.
the Real Server being tested. Th
e actual URL used is http://[real
_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

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

Always Pass This test is used for n/a n/a

troubleshooting or for services
used for management access to
Real Servers. This test always
passes regardless of the
condition of the Real Server.
Specific HTTP Port Performs an HTTP GET request Enter the TCP port followed by a Enter a pattern expected in the
using a specified port to a ":" and the root relative URL (e.g. resulting HTML.
relative URL on the Real Server 8080:/cgi-bin/index.cgi)).
being tested. The URL used is ht
tp://[real_server_ip]:[port][URL
].
RADIUS Auth Tests the availability of a Enter the secret to use with the Enter a username and password
RADIUS server. RADIUS server. separated by "|". Example:
username|password
RADIUS Acct Tests the availability of a Enter the secret to use with the Enter a username and password
RADIUS server by making an RADIUS server. separated by "|". Example:
accounting request. username|password
RDP Test Attempts an RDP connection to Enter the port on the Real Server n/a
each Real Server to check the to use, if different than the port
availability of the Terminal specified on the Server
Service. Configuration page.
FTP Test Attempts a TCP connection to Optional. Username. Optional. Password.

each Real Server to check FTP
availability.
FTPS Test Attempts a TCP connection to Optional. Username. Optional. Password.

each Real Server to check FTPS
availability.

Reporting
The BASIC > Reports page allows you to configure and generate reports of various types, based on all logged information. You can either
generate a one-time report or configure the Barracuda Load Balancer ADC to automatically generate the reports on a daily, weekly, or monthly
basis. Reports can be emailed to specific email addresses or sent to an FTP server.
The Barracuda Load Balancer ADC reports are classified into following groups:
Traffic Reports
Security
PCI DSS Reports
Configuration Summary Reports
Administration/Audit Reports
How to Filter a Report
You can apply a filter to the Security reports and limit a report to specific data. For example, the Attacks By Service report in the Security sectio
n displays the services that have been recently attacked. You can further filter these results to examine specific types of attacks by applying the
following filter:
1. Go to the BASIC > Reports page.

2. In the Report Options section, click Show Advanced Options.
3. For the Security Filter options, select Attack Type and then select the type of security attack.
4. Scroll down to the Security section, select Attacks By Service and then click Show Report.
How to Schedule a Report
Complete the following steps to schedule a report:

2. (Optional) In the Report Options section, click Show Advanced Options and configure the Security Filter, Traffic Filter, and Top
Count settings.
3. Select the check box(es) next to the report type(s) under the report group (Client Traffic Reports, Service Traffic Reports, Security, S
erver Traffic Reports, PCI DSS Reports, Config Summary, and Administration/Audit Reports).
4. In the Schedule Report section, specify the following:
Report Name - Name for the report
Generate Report As - Format for the report (HTML or PDF)
Delivery Options - How you want the report to be delivered (Email or FTP)
Email ID(s) - Specify who receives the reports
Frequency - How frequently you want the report to be generated (Once, Daily, Weekly, or Monthly)
5. Click Apply.
How to Delete a Scheduled Report
Complete the following steps to delete a scheduled report:

2. Scroll to the bottom of the page and click Delete next to the report you want to remove.

Traffic Reports
Traffic reports are categorized into the three following groups:
Client Traffic Reports

Service Traffic Reports
Server Traffic Reports
Client Traffic Reports
Client Traffic Reports cover web client activity monitored by the Barracuda Load Balancer ADC.
Client Traffic Reports can be generated ONLY for HTTP, HTTPS, Instant SSL and TCP Proxy services.
The following table provides a detailed description of each report in the Client Traffic Reports section:
Report Name Report Description Graph/Chart Type Data in Graph/Chart Drill Down
Top Clients by Request Displays the top clients Bar Chart X plot displays the Report can be drilled
(IP addresses) accessing count of requests down by:
the service based on the corresponding to
requests sent. Response Type
clients.
Y plot displays the IP
address(es) of
clients accessing the
service..
Top Clients by Bandwidth Displays the top clients Bar Chart X plot displays the None
based on bandwidth bandwidth usage (in
usage. bytes) corresponding
to clients.
address(es) of
clients based on
bandwidth usage.
Top Clients by Displays the top clients Bar Chart X plot displays the None
Connections based on connections. number of
connections
corresponding to
clients.
address(es) of
clients based on the
number of
connections.
Top Countries by Displays the top countries Bar Chart X plot displays the None
Connections based on connections. number of
connections
corresponding to
countries.
Y plot displays the
names of countries
based on the
number of
connections.

Top Countries by RDP Displays the top countries Bar Chart X plot displays the None
Sessions based on Remote number of RDP
Desktop Protocol (RDP) sessions
sessions. corresponding to
countries.
Y plot displays the
names of countries
based on the
number of RDP
sessions.
Service Traffic Reports
Service traffic reports cover web traffic activities monitored by the Barracuda Load Balancer ADC for the configured services.
The following table provides a detailed description of each report in the Service Traffic Reports section:
Top URLs by Bandwidth Displays the top URLs Bar Chart X plot displays the None
based on bandwidth bandwidth usage (in
to URLs.
Y plot displays the
URLs accessed
based on bandwidth
usage.
Top Accessed Service Displays the top Bar Chart Displays the top None
accessed service. accessed service
based on bandwidth
usage.
Top Services by Displays the top services Bar Chart X plot displays the None
Bandwidth based on bandwidth bandwidth usage (in
to services.
address/Port of
services based on
bandwidth usage.
Top Services by Displays the top services Bar Chart X plot displays the None
Connections based on connections. connections
corresponding to
services.
address/Port of
services based on
connections
Top Services by RDP Displays the top services Bar Chart X plot displays the None
Session based on the number of RDP sessions
RDP (Remote Desktop corresponding to
Protocol) sessions. services.
address/Port of
services based on
RDP sessions.

Top Domains by Request Displays the top domains Bar Chart X plot displays the Report can be drilled
accessed based on the count of requests down by:
requests. corresponding to
Response Type
domains.
Y plot displays the
domain names
accessed based on
the requests
received.
Top Domains by Displays the top domains Bar Chart X plot displays the None
Bandwidth based on bandwidth bandwidth usage (in
to domains.
Y plot displays the
domain names
based on bandwidth
usage.
Services Summary Displays a summary of List Displays a summary None

the services configured of the services
on the appliance. configured on the
appliance.
Server Traffic Reports
Server Traffic Reports cover web traffic activities monitored by the Barracuda Load Balancer ADC for the configured servers.
The following table provides a detailed description of each report in the Server Traffic Reports section:
Top Accessed Servers by Displays the top servers Bar Chart X plot displays the None
Bandwidth based on bandwidth bandwidth usage
usage. corresponding to the
servers.
address(es) of
servers that are
accessed by clients.

Security
Security covers web attack prevention activity performed by the Barracuda Load Balancer ADC, including the following:
Number of attacks on the Service(s) within the specified time frame

Top attacked domains and URLs
Top attacking clients - top clients who attacked the services
The following table provides a detailed description of each report in the Security section:
Attacks by Service Displays the number of Bar Chart X plot displays the Report can be drilled
attacks for the service(s) count of attacks down by:
within the specified time corresponding to
frame. Domain
each service.
Time Stamp
Y plot displays the
Attack Category
service IP
Client
address(es).
Top Attacking Clients Displays the number of Bar Chart X plot displays the Report can be drilled
attacks from the client(s) count of attacks. down by:
within the specified time Y plot displays the IP
frame. Services
address(es) of
Attack Category
attacking clients.
Top Attacked Domains Displays the top attacked Bar Chart X plot displays the Report can be drilled
domains based on the count of attacks. down by:
requests received. Y plot displays the
Time
name of attacked
Attack Category
domains.
Services
Top Attacked URLs Displays the top attacked Bar Chart X plot displays the Report can be drilled
URLs based on the count of attacks. down by:
requests received. Y plot displays the
Time
attacked URLs.
Attack Category

PCI DSS Reports

PCI reports detail compliance with Payment Card Industry (PCI) standards and display:
Combined details of PCI attacks such as top attacking clients, and top attacked services, domains, and URLs
Details of PCI directives and the Barracuda Load Balancer ADC's compliance with those directives
The following table provides a detailed description of each report in the PCI DSS Reports section:
Report Name Report Description Graph/Chart Type Data in Graph Chart
PCI Attacks:
Top Attacking Clients Displays the number of attacks Bar Chart X plot displays the IP
from client(s). address(es) of attacking
clients.
Y plot displays the count of
attacks.
Top Attacked Domains Displays top attacked domains Bar Chart X plot displays the name of
based on the requests received. attacked domains.
attacks.
Top Attacked URLs Displays top attacked URLs Bar Chart X plot displays the attacked
based on the requests received. URLs.
attacks.
Attacks By Service Displays the number of attacks Bar Chart X plot displays the IP
per service. address(es) of attacked
service(s).
attacks.
Report Name Report Description Graph/Chart Type Data in Graph Chart
PCI Compliance (PCI DSS V2.0) Displays the details of the PCI Plain Text None
directives.

Configuration Summary Reports

Configuration Summary reports cover:
Performance of Barracuda Load Balancer ADC features such as Load Balancing, Rate Control, Learning, and so on.
Details of digital certificates including issuing date, expiry date, and associated services.
Details of accounts, their users, privileges assigned to them, permitted operations, etc.
Details of the configuration and status of the servers.
The following table provides a detailed description of each report in the Configuration Summary section:
Report Name Report Description Report Type
Application Security Summary Displays the summary of configured Plain Text

applications and associated policies.
The Application Security Summary report

includes:
Application Name
IP Address:Port
Server-IP:Port
Application Policies
Traffic Management
Security
URL Policies
Certificate Status Report Displays the summary of created/uploaded Plain Text

certificates and associated applications.
The Certificate Status report includes:
Certificate Name
Certificate Type
Issuing Date
Expiry Date
Associated Applications
Administrative Accounts Displays the operational and configuration Plain Text

privileges allowed for each role.
The Administrative Accounts report

includes:
Role Name
User
Denied Screens
Operations
Services
Security Policies
Authentication Services
Server Summary Displays the configuration settings of Plain Text

servers.
The Server Summary report includes:
Service Server
IP/Port
Operational Status
Front-end/Back-end SSL
Connection Pooling
Client Impersonation

Administration/Audit Reports
Administration/Audit reports cover the login/logout activities performed by different user roles.
The following table provides a detailed description of the report in the Administration/Audit Reports section:
Report Name Report Description Report Type
RBA Activity Displays the total number of activities Plain Text

performed by each role.
The Role-Based Administration (RBA)

activity report includes the following
information:
User
Successful Logins
Failed Logins
Last Login
Last Activity
Last Activity Time
Last Logout

How to Automate System Alert and SNMP Trap Delivery
From the BASIC > Administration page, you can configure the Barracuda Load Balancer ADC to automatically email notifications to the
addresses you specify. Go to the Email Notifications section and enter an email address in the System Alerts Email Address field. To enter
multiple addresses, separate each address with a comma. Email notifications are generated for a variety of issues. For example, an email alert is
sent when 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
configure the SNMP traps on the Barracuda Load Balancer ADC. Navigate to the SNMP Traps Events section to specify which system events
should trigger sending the corresponding SNMP trap. For example, you can send an SNMP trap when the CPU temperature is critical or when
the System fan has failed by clicking the corresponding checkbox.
Be sure to click Save Changes when you have completed your configuration.

How to Configure SNMP Monitoring on the Barracuda Load Balancer ADC
On the Barracuda Load Balancer ADC, you can enable an SNMP agent to enable SNMP to query the system for a variety of statistics, such as
the number of current connections, bandwidth, and system CPU temperature. You can also configure SNMP traps to be generated automatically
when certain events occur.
SNMPv2c and SNMPv3 are both supported by the SNMP agent. SNMPv2c is less secure because its queries and responses are not encrypted.
SNMPv3 can encrypt traffic and enables you to restrict access to only specified users with passwords.
In addition to configuring SNMP monitoring on the Barracuda Load Balancer ADC, you must also import the Barracuda Load Balancer MIBs into
your SNMP monitors.
Step 1. Configure SNMP Monitoring
If the Barracuda Load Balancer ADC is in high availability (HA) mode, you only need to configure the active unit. All SNMP settings are
propagated to the passive unit in the cluster.
On the Barracuda Load Balancer ADC, enable the Barracuda SNMP agent and specify the IP addresses of the SNMP monitors that are allowed
to query the agent. You can also configure SNMP traps.
1. Log into the Barracuda Load Balancer ADC web interface as administrator.
2. Go to the ADVANCED > SNMP Configuration page.
3. In the SNMP Manager section, enable the SNMP agent, select an SNMP version, and enter the IP addresses of the SNMP monitors that
are allowed to connect with the Barracuda Load Balancer ADC.
Allowed SNMP IP/Range

If no IP addresses or networks are added for the Allowed SNMP IP/Range, then SNMP access is possible from any system.
4. If you want to configure SNMP traps:

a. In the SNMP Traps section, enter the IP addresses and ports that the traps should be sent to.
b. In the SNMP Trap Events section, select the SNMP traps that you want to generate. For more information on the available
traps, see SNMP Objects and Traps.
5. Click Save.
Step 2. Import the Barracuda Load Balancer MIBs into the SNMP Monitor
To use an SNMP monitor or other program to query for system information using SNMP, you must obtain and import the Barracuda Load
Balancer MIB files into your SNMP monitor. You can download a TAR file containing the Barracuda Load Balancer MIB files at http://ADC-ma
nagement-IP-address:8000/Barracuda-LB-MIBS.tar. A link to this TAR file is also available in the online help for the ADVANCED >
SNMP Configuration page of the Barracuda Load Balancer ADC.
You can then monitor objects included in this MIB either from custom scripts or from your SNMP monitor.
Syntax
Refer to the MIBs for the Object IDs (OIDs) that correspond to the type of status that you want to monitor. For a list of of the objects that are
available in the Barracuda Load Balancer ADC MIB, see SNMP Objects and Traps.
If you are querying the Barracuda Load Balancer ADC from code, use the following syntax:
snmpget -v 2c -c public ADC-MIP-Address .1.3.6.1.4.1.20632.5.2
ADC-MIP-Address is the management IP address of your Barracuda Load Balancer ADC.
If you are using the snmpwalk command and do not include an OID, a list of all OIDs in the MIB is returned.

SNMP Objects and Traps
The following sections provide more information on the objects and traps that are available in the Barracuda Load Balancer ADC MIBs.
You can download a TAR file containing the Barracuda Load Balancer MIB files at http://ADC-management-IP-address:8000/Barracud
a-LB-MIBS.tar. A link to this TAR file is also available in the online help for the ADVANCED > SNMP Configuration page of the Barracuda
Load Balancer ADC.
System Traps
The following traps generate alerts about the firmware, operating state, and Energize Updates for the Barracuda Load Balancer ADC.
blbCPUFanDead
Description CPU fan has failed.
Object ID .1.3.6.1.4.1.20632.5.99.3.1.1
Alert ID ALERT:2
Message One of the CPU fans is dead.
Source MIB Barracuda-LB-EXT
blbSysFanDead
Description System fan has failed.
Object ID .1.3.6.1.4.1.20632.5.99.3.1.2
Alert ID ALERT:3
Message One of the system fans is dead
blbCPUTempHigh
Description CPU temperature is too high. This message is displayed when the
CPU temperature is higher than 70° Celsius.
Object ID .1.3.6.1.4.1.20632.5.99.3.1.3
Alert ID ALERT:4
Message System is getting real hot <value>
blbCpuTempCritical
Description CPU temperature is critical. This message is displayed when the

CPU temperature is higher than 80 ° Celsius
Object ID .1.3.6.1.4.1.20632.5.99.3.1.4
Alert ID ALERT:15
Message System highest temp has reached = <value>
blbFirmwareStorageHigh
Description Firmware disk space used has exceeded threshold.
Object ID .1.3.6.1.4.1.20632.5.99.3.1.5

Alert ID ALERT:5
Message Firmware storage exceeds 90%
blbLogsStorageHigh
Description Log disk space used has exceeded threshold.
Object ID .1.3.6.1.4.1.20632.5.99.3.1.6
Alert ID ALERT:6
Message Log storage exceeds 85%
blbHighAvailabilityStatus
Description High availability status has changed.
Object ID .1.3.6.1.4.1.20632.5.99.3.1.7
Alert ID ALERT:14
Message HA is dead. Restarting
blbEnergizeUpdateExpire
Description Energize Updates subscription is about to expire.
Object ID .1.3.6.1.4.1.20632.5.99.3.1.8
Alert ID ALERT:18
Message Energize update subscription is about to expire in <days> days
blbFirmwareUpdateAvailable
Description There is a firmware update available.
Object ID .1.3.6.1.4.1.20632.5.99.3.1.9
Alert ID ALERT:19
Message New Firmware Update is available Current Version =

<current_version> New Version = <newversion>
blbFirmwareUpdateAvailable
Description There is a firmware update available.
Object ID .1.3.6.1.4.1.20632.5.99.3.1.9
Alert ID ALERT:19
Message New Firmware Update is available Current Version =

<current_version> Beta Version = <betaversion>
blbAttackDefinitionUpdateAvailable

Description New attack definition version is available.
Object ID .1.3.6.1.4.1.20632.5.99.3.1.10
Alert ID ALERT:20
Message New Attack Definition Version <version> is available.
blbNewAttackDefinitionInstalled
Description New attack definition version is installed.
Object ID .1.3.6.1.4.1.20632.5.99.3.1.11
Alert ID ALERT:21
Message New Attack Definition Version <current_attack_def_version> is

installed , reboot appliance to apply attack def
Traffic Traps
The following traps generate alerts about the operating states of the real servers configured on the Barracuda Load Balancer ADC.
blbServerUp
Description Real server is up.
Object ID .1.3.6.1.4.1.20632.5.99.3.2.3
Alert ID ALERT:9
Message SERVER_RESTORED
Source MIB Barracuda-LB-EXT-MIB
blbServerDown
Description Real server is not responding.
Object ID .1.3.6.1.4.1.20632.5.99.3.2.4
Alert ID ALERT:10
Message SERVER_FAILED
blbMinServerThresholdReached
Description Number of active servers is below minimum threshold.
Object ID .1.3.6.1.4.1.20632.5.99.3.2.5
Alert ID ALERT:16
Message MIN_SERVER_THRESHOLD_REACHED
blbMinServerThresholdCrossed
Description Number of active servers has returned to minimum threshold.
Object ID 1.3.6.1.4.1.20632.5.99.3.2.6
Alert ID ALERT:17

Message MIN_SERVER_THRESHOLD_CROSSED
System Statistics Objects
The following objects return information on the operating state of the Barracuda Load Balancer ADC.
blbCPUTemperature
Description CPU temperature in degrees Celcius.
Object ID .1.3.6.1.4.1.20632.5.99.1.4.1
blbSystemLoad
Description Percentage of the CPU and system load.
Object ID .1.3.6.1.4.1.20632.5.99.1.4.2
blbFirmwareStorage
Description Percentage of the disk storage that is used by the firmware.
Object ID .1.3.6.1.4.1.20632.5.99.1.4.3
blbMailLogStorage
Description Percentage of the disk storage that is used by logs.
Object ID .1.3.6.1.4.1.20632.5.99.1.4.4
blbSystemActiveServices
Description Number of active services.
Object ID .1.3.6.1.4.1.20632.5.99.1.4.5
blbSystemOperatingServers
Description Number of operating real servers.
Object ID .1.3.6.1.4.1.20632.5.99.1.4.6
blbClusterStatus
Description Indicates if the Barracuda Load Balancer ADC is standalone or part

of a high availability cluster.
Object ID .1.3.6.1.4.1.20632.5.99.1.4.7
blbOperationMode

Description Indicates if the Barracuda Load Balancer ADC is operating in the

route-path or bridge mode.
Object ID .1.3.6.1.4.1.20632.5.99.1.4.8
Security Statistics Objects
The following objects provide statistics on your Application Security policies.
blbExtIpsReqSrvcStatsTable
Description A table of IP request service stats.
Object ID .1.3.6.1.4.1.20632.5.99.1.1.1
The following table describes the fields in blbExtIpsReqSrvcStatsTable:
Object Name Description Object ID
blbExtIpsLrnSrvcStatsEntry IPS request service stats entry. .1.3.6.1.4.1.20632.5.99.1.1.1.1
ipsReqSrvcAddressType The type of the service address, as defined .1.3.6.1.4.1.20632.5.99.1.1.1.1.1

in the InetAddress MIB.
ipsReqSrvcAddress Service address. .1.3.6.1.4.1.20632.5.99.1.1.1.1.2
ipsReqSrvcPort Port on which the IPS service is listening. .1.3.6.1.4.1.20632.5.99.1.1.1.1.3
ipsReqSrvcNoOfUrlProfMatched Number of URL profiles matched. .1.3.6.1.4.1.20632.5.99.1.1.1.1.4
ipsReqSrvcNoOfAppProfViol Number of app profile violations. .1.3.6.1.4.1.20632.5.99.1.1.1.1.5
ipsReqSrvcTotProfViol Total number of profile violations. .1.3.6.1.4.1.20632.5.99.1.1.1.1.6
blbExtIpsReqLimitStatsTable
Description A table of IPS request limit stats.
Object ID .1.3.6.1.4.1.20632.5.99.1.1.3
The following table describes the fields in blbExtIpsReqLimitStatsTable:
blbExtIpsReqLimitStatsEntry IPS request limit stats entry. .1.3.6.1.4.1.20632.5.99.1.1.3.1
ipsReqLimitAddressType The type of the service address, as defined .1.3.6.1.4.1.20632.5.99.1.1.3.1.1

ipsReqLimitAddress The service address. .1.3.6.1.4.1.20632.5.99.1.1.3.1.2
ipsReqLimitPort The port on which the IPS service is .1.3.6.1.4.1.20632.5.99.1.1.3.1.3

listening.
ipsReqLimitUrlLenOFErr Number of URL length overflow errors. .1.3.6.1.4.1.20632.5.99.1.1.3.1.4
ipsReqLimitQueryLenOFErr Number of query length overflow errors. .1.3.6.1.4.1.20632.5.99.1.1.3.1.5
ipsReqLimitReqLenOFErr Number of request length overflow errors. .1.3.6.1.4.1.20632.5.99.1.1.3.1.6
ipsReqLimitCookieLenOFErr Number of cookie length overflow errors. .1.3.6.1.4.1.20632.5.99.1.1.3.1.7
ipsReqLimitHdrCntOFErr Number of header count overflow errors. .1.3.6.1.4.1.20632.5.99.1.1.3.1.8
ipsReqLimitHdrLenOFErr Number of header length overflow errors. .1.3.6.1.4.1.20632.5.99.1.1.3.1.9

ipsReqLimitContentLenErr Number of content length overflow errors. .1.3.6.1.4.1.20632.5.99.1.1.3.1.10
ipsReqLimitBlkdMethodErr Number of blocked method errors. .1.3.6.1.4.1.20632.5.99.1.1.3.1.11
blbExtIpsUrlNormStatsTable
Description A table of IPS URL normalization stats.
Object ID .1.3.6.1.4.1.20632.5.99.1.1.4
The following table describes the fields in blbExtIpsUrlNormStatsTable:
blbExtIpsUrlNormStatsEntry IPS URL normalization stats entry. .1.3.6.1.4.1.20632.5.99.1.1.4.1
ipsUrlNormAddressType The type of the service address, as defined .1.3.6.1.4.1.20632.5.99.1.1.4.1.1

ipsUrlNormAddress The service address. .1.3.6.1.4.1.20632.5.99.1.1.4.1.2
ipsUrlNormPort The port on which the IPS service is .1.3.6.1.4.1.20632.5.99.1.1.4.1.3

listening.
ipsUrlNormEncodingErr Number of encoding errors. .1.3.6.1.4.1.20632.5.99.1.1.4.1.4
ipsUrlNormSlashDotInUrlErr Number of slash dot (/.) in URL errors. .1.3.6.1.4.1.20632.5.99.1.1.4.1.5
ipsUrlNormTildaInUrl Number of tilde (~) in URL errors. .1.3.6.1.4.1.20632.5.99.1.1.4.1.6
ipsUrlNormCharSetEncodingErr Number of character set encoding errors. .1.3.6.1.4.1.20632.5.99.1.1.4.1.7
blbExtIpsCookieSecStatsTable
Description A table of IPS cookie security stats.
Object ID .1.3.6.1.4.1.20632.5.99.1.1.5
The following table describes the fields in blbExtIpsCookieSecStatsTable:
blbExtIpsCookieSecStatsEntry IPS cookie security stats entry. .1.3.6.1.4.1.20632.5.99.1.1.5.1
ipsCookieSecAddressType The type of the service address, as defined .1.3.6.1.4.1.20632.5.99.1.1.5.1.1

ipsCookieSecAddress The service address. .1.3.6.1.4.1.20632.5.99.1.1.5.1.2
ipsCookieSecPort The port on which the IPS service is .1.3.6.1.4.1.20632.5.99.1.1.5.1.3

listening.
ipsCookieSecEncrypted Number of cookies encrypted. .1.3.6.1.4.1.20632.5.99.1.1.5.1.4
ipsCookieSecTampered Number of cookies tampered. .1.3.6.1.4.1.20632.5.99.1.1.5.1.5
ipsCookieSecNumCookieAllow Number of cookies allowed. .1.3.6.1.4.1.20632.5.99.1.1.5.1.6
ipsCookieSecNumCookieSet Number of cookies set. .1.3.6.1.4.1.20632.5.99.1.1.5.1.7
ipsCookieSecNumCookieErr Number of cookie errors. .1.3.6.1.4.1.20632.5.99.1.1.5.1.8
ipsCookieSecCookieDecErr Number of cookie decryption errors. .1.3.6.1.4.1.20632.5.99.1.1.5.1.9
ipsCookieSecCookieDecrypted Number of cookies decrypted. .1.3.6.1.4.1.20632.5.99.1.1.5.1.10
blbExtIpsUrlAclStatsTable

Description A table of IPS URL ACL stats.
Object ID .1.3.6.1.4.1.20632.5.99.1.1.6
The following table describes the fields in blbExtIpsUrlAclStatsTable:
blbExtIpsUrlAclStatsEntry IPS URL ACL stats entry. .1.3.6.1.4.1.20632.5.99.1.1.6.1
ipsUrlAclAddressType The type of the service address, as defined .1.3.6.1.4.1.20632.5.99.1.1.6.1.1

ipsUrlAclAddress The service address. .1.3.6.1.4.1.20632.5.99.1.1.6.1.2
ipsUrlAclPort The port on which the IPS service is .1.3.6.1.4.1.20632.5.99.1.1.6.1.3

listening.
ipsUrlAclProcessAclHits Number of ACL hits where the action is .1.3.6.1.4.1.20632.5.99.1.1.6.1.4

PROCESS.
ipsUrlAclPolicyHits Number of ACL policy hits. .1.3.6.1.4.1.20632.5.99.1.1.6.1.5
ipsUrlAclTimeStamp Time stamp at which this entry was last .1.3.6.1.4.1.20632.5.99.1.1.6.1.6

modified.
ipsUrlAclAllowAclHits Number of ACL policy hits where the action .1.3.6.1.4.1.20632.5.99.1.1.6.1.8

is ALLOW.
blbExtIpsHdrAclStatsTable
Description A table of IPS header ACL stats.
Object ID .1.3.6.1.4.1.20632.5.99.1.1.7
The following table describes the fields in blbExtIpsHdrAclStatsTable:
blbExtIpsHdrAclStatsEntry IPS header ACL stats entry. .1.3.6.1.4.1.20632.5.99.1.1.7.1
ipsHdrAclAddressType The type of the service address, as defined .1.3.6.1.4.1.20632.5.99.1.1.7.1.1

ipsHdrAclAddress The service address. .1.3.6.1.4.1.20632.5.99.1.1.7.1.2
ipsHdrAclPort The port on which the IPS service is .1.3.6.1.4.1.20632.5.99.1.1.7.1.3

listening.
ipsHdrAclHits Number of ACL hits. .1.3.6.1.4.1.20632.5.99.1.1.7.1.4
ipsHdrAclTimeStamp Time stamp at which this entry was last .1.3.6.1.4.1.20632.5.99.1.1.7.1.5

modified.
blbExtIpsWebAddrTransStatsTable
Description A table of web address translation stats.
Object ID .1.3.6.1.4.1.20632.5.99.1.1.8
The following table describes the fields in blbExtIpsWebAddrTransStatsTable:

blbExtIpsWebAddrTransStatsEntry IPS header ACL stats entry. .1.3.6.1.4.1.20632.5.99.1.1.8.1
ipsWebAddrTransAddressType The type of the service address, as defined .1.3.6.1.4.1.20632.5.99.1.1.8.1.1

ipsWebAddrTransAddress The service address. .1.3.6.1.4.1.20632.5.99.1.1.8.1.2
ipsWebAddrTransPort The port on which the IPS service is .1.3.6.1.4.1.20632.5.99.1.1.8.1.3

listening.
ipsWebAddrTransReqUrlTrans Number of URL translation requests. .1.3.6.1.4.1.20632.5.99.1.1.8.1.4
ipsWebAddrTransRspUrlTrans Number of URL translation responses. .1.3.6.1.4.1.20632.5.99.1.1.8.1.5
ipsWebAddrTransReqUrlReWritten Number of URLs rewritten. .1.3.6.1.4.1.20632.5.99.1.1.8.1.6
ipsWebAddrTransReqHdrReWritten Number of request headers rewritten. .1.3.6.1.4.1.20632.5.99.1.1.8.1.7
ipsWebAddrTransRspHdrReWritten Number of response headers rewritten. .1.3.6.1.4.1.20632.5.99.1.1.8.1.8
ipsWebAddrTransReqReDirection Number of requests redirected. .1.3.6.1.4.1.20632.5.99.1.1.8.1.9
ipsWebAddrTransTimeStamp Time stamp at which this entry was last .1.3.6.1.4.1.20632.5.99.1.1.8.1.10

modified.
blbExtHttpProxySecStatsTable
Description A table of HTTP proxy security stats.
Object ID .1.3.6.1.4.1.20632.5.99.1.1.12
The following table describes the fields in blbExtHttpProxySecStatsTable:
blbExtHttpProxySecStatsEntry HTTP proxy stats entry. .1.3.6.1.4.1.20632.5.99.1.1.12.1
httpProxySecAddressType The type of the HTTP proxy address, as .1.3.6.1.4.1.20632.5.99.1.1.12.1.1

defined in the InetAddress MIB.
httpProxySecAddress The HTTP proxy address. .1.3.6.1.4.1.20632.5.99.1.1.12.1.2
httpProxySecPort The port on which the HTTP proxy is .1.3.6.1.4.1.20632.5.99.1.1.12.1.3

listening.
httpProxySecWAFBlockedIntrusions Total number of ADC blocked intrusions. .1.3.6.1.4.1.20632.5.99.1.1.12.1.4
httpProxySecWAFMonitoredIntrusions Total number of ADC monitored intrusions. .1.3.6.1.4.1.20632.5.99.1.1.12.1.5
httpProxySecWAFWarnings Total number of ADC warnings. .1.3.6.1.4.1.20632.5.99.1.1.12.1.6
Traffic Statistics Objects
The following objects provide information about the traffic that is processed by the Barracuda Load Balancer ADC.
L4TCPConnections
Description Number of Layer 4 TCP connections.
Object ID .1.3.6.1.4.1.20632.5.6
Source MIB Barracuda-LIB
L7HTTPRequests
Description Number of requests to each Layer 7 HTTP service.
Object ID .1.3.6.1.4.1.20632.5.7

RDPUserSessions
Description Number of Layer 7 - RDP user sessions.
Object ID .1.3.6.1.4.1.20632.5.8
ServiceBandwidth
Description The current bandwidth to each service.
Object ID .1.3.6.1.4.1.20632.5.9
TotalBandwidthToLB
Description Total bandwidth.
Object ID .1.3.6.1.4.1.20632.5.10
RealServerBandwidth
Description Current bandwidth to each real server.
Object ID .1.3.6.1.4.1.20632.5.11
l7FTPSessions
Description Number of sessions for each FTP service.
Object ID .1.3.6.1.4.1.20632.5.19
l7TCPConnections
Description Number of connections to each Layer 7 TCP service.
Object ID .1.3.6.1.4.1.20632.5.20
realServerOperationStatus
Description Indicates if real servers are enabled, disabled, or in maintenance

mode.
Format:
service_name:real-server-ip-address=status
Example:
HTTPS_1:10.5.5.5= Enable
Object ID .1.3.6.1.4.1.20632.5.21
blbExtHttpProxyStatsTable

Description A table of HTTP proxy stats.
Object ID .1.3.6.1.4.1.20632.5.99.1.2.1
The following table describes the fields in blbExtHttpProxyStatsTable:
blbExtHttpProxyStatsEntry HTTP proxy stats entry. .1.3.6.1.4.1.20632.5.99.1.2.1.1
httpProxyAddressType The type of the HTTP proxy address, as .1.3.6.1.4.1.20632.5.99.1.2.1.1.1

httpProxyAddress The HTTP proxy address. .1.3.6.1.4.1.20632.5.99.1.2.1.1.2
httpProxyPort The port on which the HTTP proxy is .1.3.6.1.4.1.20632.5.99.1.2.1.1.3

listening.
httpProxyActiveConn Number of active connections. .1.3.6.1.4.1.20632.5.99.1.2.1.1.4
httpProxyTotalConn Total number of connections. .1.3.6.1.4.1.20632.5.99.1.2.1.1.5
httpProxyTotalReq Total number of requests. .1.3.6.1.4.1.20632.5.99.1.2.1.1.6
httpProxyServerReq Total number of server requests. .1.3.6.1.4.1.20632.5.99.1.2.1.1.7
httpProxyServerErr Total number of server errors. .1.3.6.1.4.1.20632.5.99.1.2.1.1.8
httpProxyClientAbrt Total number of client aborts. .1.3.6.1.4.1.20632.5.99.1.2.1.1.9
httpProxyServerAbrt Total number of server aborts. .1.3.6.1.4.1.20632.5.99.1.2.1.1.10
httpProxySessionTimeOut Total number of session timeouts. .1.3.6.1.4.1.20632.5.99.1.2.1.1.11
httpProxyParseErr Total number of parse errors. .1.3.6.1.4.1.20632.5.99.1.2.1.1.12
httpProxyUnknownRsp Total number of unknown responses. .1.3.6.1.4.1.20632.5.99.1.2.1.1.13
httpProxyInBytes Total number of In octets. .1.3.6.1.4.1.20632.5.99.1.2.1.1.14
httpProxyOutBytes Total number of Out octets. .1.3.6.1.4.1.20632.5.99.1.2.1.1.15
blbExtSslProxyStatsTable
Description A table of SSL stats.
Object ID .1.3.6.1.4.1.20632.5.99.1.2.2
The following table describes the fields in blbExtSslProxyStatsTable:
blbExtSslProxyStatsEntry SSL stats entry. .1.3.6.1.4.1.20632.5.99.1.2.2.1
sslProxyAddressType The type of the SSL proxy address, as .1.3.6.1.4.1.20632.5.99.1.2.2.1.1

sslProxyAddress The SSL proxy address. .1.3.6.1.4.1.20632.5.99.1.2.2.1.2
sslProxyPort The port on which the SSL proxy is listening. .1.3.6.1.4.1.20632.5.99.1.2.2.1.3
sslProxyActiveConn Number of active connections. .1.3.6.1.4.1.20632.5.99.1.2.2.1.4
sslProxyFullHandshakes Number of full handshakes. .1.3.6.1.4.1.20632.5.99.1.2.2.1.5
sslProxyResumptionHandshakes Number of resumption handshakes. .1.3.6.1.4.1.20632.5.99.1.2.2.1.6
sslProxyHandshakeAttempts Number of handshake attempts. .1.3.6.1.4.1.20632.5.99.1.2.2.1.7

sslProxyCacheHits Number of cache hits. .1.3.6.1.4.1.20632.5.99.1.2.2.1.8
sslProxyCacheMiss Number of cache misses. .1.3.6.1.4.1.20632.5.99.1.2.2.1.9
sslProxyCacheTimeouts Number of cache timeouts. .1.3.6.1.4.1.20632.5.99.1.2.2.1.10
sslProxyErrPms Number of PMC errors. .1.3.6.1.4.1.20632.5.99.1.2.2.1.11
sslProxyAuthBadCertErr Number of bad certificate errors. .1.3.6.1.4.1.20632.5.99.1.2.2.1.12
sslProxyAuthBadCNErr Number of bad CN errors. .1.3.6.1.4.1.20632.5.99.1.2.2.1.13
sslProxyBadDNCErr Number of bad DNC errors. .1.3.6.1.4.1.20632.5.99.1.2.2.1.14
sslProxyBadCRLErr Number of bad CRL errors. .1.3.6.1.4.1.20632.5.99.1.2.2.1.15
sslProxyInBytes Number of IN octets. .1.3.6.1.4.1.20632.5.99.1.2.2.1.16
sslProxyOutBytes Number of OUT octets. .1.3.6.1.4.1.20632.5.99.1.2.2.1.17
sslProxyTotalReq Total number of requests. .1.3.6.1.4.1.20632.5.99.1.2.2.1.18
sslProxyTotalConn Total number of connections. .1.3.6.1.4.1.20632.5.99.1.2.2.1.19
sslProxyCurrentConn Current number of connections. .1.3.6.1.4.1.20632.5.99.1.2.2.1.20
blbExtCompressionStatsTable
Description A table of compression stats.
Object ID .1.3.6.1.4.1.20632.5.99.1.2.3
The following table describes the fields in blbExtCompressionStatsTable:
blbExtCompressionStatsEntry Compression stats entry. .1.3.6.1.4.1.20632.5.99.1.2.3.1
webCmprProtocol The protocol used (HTTP or HTTPS). .1.3.6.1.4.1.20632.5.99.1.2.3.1.1
webCmprAddressType The type of the proxy address, as defined in .1.3.6.1.4.1.20632.5.99.1.2.3.1.2

the InetAddress MIB.
webCmprAddress The proxy address. .1.3.6.1.4.1.20632.5.99.1.2.3.1.3
webCmprPort The port on which the proxy is listening. .1.3.6.1.4.1.20632.5.99.1.2.3.1.4
webCmprNoOfReqCompressed Number of requests that were compressed. .1.3.6.1.4.1.20632.5.99.1.2.3.1.5
webCmprCompressibleDataSize Compressible data size. .1.3.6.1.4.1.20632.5.99.1.2.3.1.6
webCmprCompressedDataSize Compressed data size. .1.3.6.1.4.1.20632.5.99.1.2.3.1.7
blbExtCacheStatsTable
Description A table of cache stats.
Object ID .1.3.6.1.4.1.20632.5.99.1.2.4
The following table describes the fields in blbExtCacheStatsTable :
blbExtCacheStatsEntry Cache stats entry. .1.3.6.1.4.1.20632.5.99.1.2.4.1
webCacheProtocol The protocol used (HTTP or HTTPS). .1.3.6.1.4.1.20632.5.99.1.2.4.1.1

webCacheAddressType The type of the proxy address, as defined in .1.3.6.1.4.1.20632.5.99.1.2.4.1.2

webCacheAddress The proxy address. .1.3.6.1.4.1.20632.5.99.1.2.4.1.3
webCachePort The port on which the proxy is listening. .1.3.6.1.4.1.20632.5.99.1.2.4.1.4
webCacheHits Number of hits. .1.3.6.1.4.1.20632.5.99.1.2.4.1.5
webCacheMiss Number of misses. .1.3.6.1.4.1.20632.5.99.1.2.4.1.6
webCacheStale Number of stale sessions. .1.3.6.1.4.1.20632.5.99.1.2.4.1.7
webCacheCacheableRes Number of cacheable responses. .1.3.6.1.4.1.20632.5.99.1.2.4.1.8
webCacheReq Number of requests. .1.3.6.1.4.1.20632.5.99.1.2.4.1.9
webCacheCachedObjects Number of cached objects. .1.3.6.1.4.1.20632.5.99.1.2.4.1.10
webCacheLongHdrs Number of long headers. .1.3.6.1.4.1.20632.5.99.1.2.4.1.11
webCacheBytesOut Number of out bytes. .1.3.6.1.4.1.20632.5.99.1.2.4.1.12
blbExtHttpSrvrStatsTable
Description A table of HTTP server stats.
Object ID .1.3.6.1.4.1.20632.5.99.1.2.5
The following table describes the fields in blbExtHttpSrvrStatsTable:
blbExtHttpSrvrStatsEntry HTTP server stats entry. .1.3.6.1.4.1.20632.5.99.1.2.5.1
httpSrvrSrvcAddressType The type of the service address, as defined .1.3.6.1.4.1.20632.5.99.1.2.5.1.1

httpSrvrSrvcAddress The HTTP service address. .1.3.6.1.4.1.20632.5.99.1.2.5.1.2
httpSrvrSrvcPort The port on which the HTTP service is .1.3.6.1.4.1.20632.5.99.1.2.5.1.3

listening.
httpSrvrAddressType The type of the server address, as defined in .1.3.6.1.4.1.20632.5.99.1.2.5.1.4

httpSrvrAddress The HTTP server address. .1.3.6.1.4.1.20632.5.99.1.2.5.1.5
httpSrvrPort The port on which the HTTP server is .1.3.6.1.4.1.20632.5.99.1.2.5.1.6

listening.
httpSrvrTotReqAccepted The total number of requests accepted by .1.3.6.1.4.1.20632.5.99.1.2.5.1.7

the HTTP server.
httpSrvrTotReqActive The total number of active request at the .1.3.6.1.4.1.20632.5.99.1.2.5.1.8

server.
httpSrvrTotReqRejected The total number of requests rejected by the .1.3.6.1.4.1.20632.5.99.1.2.5.1.9

server.
httpSrvrTotSuccess The total number of requests that .1.3.6.1.4.1.20632.5.99.1.2.5.1.10

successfully connected to the server.
httpSrvrTotRefused The total number of requests rejected by the .1.3.6.1.4.1.20632.5.99.1.2.5.1.11

server.
httpSrvrTotTimedout The total number of requests that timed out .1.3.6.1.4.1.20632.5.99.1.2.5.1.12

at the server.

httpSrvrAvgReqPerConn The average number of requests per .1.3.6.1.4.1.20632.5.99.1.2.5.1.13

connection at the server.
httpSrvrTotResponse The total number of responses sent to the .1.3.6.1.4.1.20632.5.99.1.2.5.1.14

server.
httpSrvrAvgResTime The average response time of the server. .1.3.6.1.4.1.20632.5.99.1.2.5.1.15
httpSrvrMaxResTime The maximum response time of the server. .1.3.6.1.4.1.20632.5.99.1.2.5.1.16
httpSrvrMinResTime The minimum response time of the server. .1.3.6.1.4.1.20632.5.99.1.2.5.1.17
httpSrvrNumReqEnqueue The number of enqueued requests. .1.3.6.1.4.1.20632.5.99.1.2.5.1.18
httpSrvrNumFreeConn Number of free connections. .1.3.6.1.4.1.20632.5.99.1.2.5.1.19
httpSrvrNumOpeningConn Number of opening connections. .1.3.6.1.4.1.20632.5.99.1.2.5.1.20
httpSrvrNumConn Number of connections. .1.3.6.1.4.1.20632.5.99.1.2.5.1.21
httpSrvrNumIBDisabled Number of IB disabled. .1.3.6.1.4.1.20632.5.99.1.2.5.1.22
httpSrvrNumOOBDisabled Number of OOB disabled. .1.3.6.1.4.1.20632.5.99.1.2.5.1.23
httpSrvrNumOOBEnabled Number of OOB enabled. .1.3.6.1.4.1.20632.5.99.1.2.5.1.24
httpSrvrLastDisabledTime The length of time in milliseconds since the .1.3.6.1.4.1.20632.5.99.1.2.5.1.25

server was last disabled.
httpSrvrState Server state. Possible values: .1.3.6.1.4.1.20632.5.99.1.2.5.1.26
0: server up
1: server down
httpSrvrInBytes Total IN bytes. .1.3.6.1.4.1.20632.5.99.1.2.5.1.27
httpSrvrOutBytes Total OUT bytes. .1.3.6.1.4.1.20632.5.99.1.2.5.1.28
blbExtSslSrvrStatsTable
Description A table of SSL server stats.
Object ID .1.3.6.1.4.1.20632.5.99.1.2.6
The following table describes the fields in blbExtSslSrvrStatsTable:
blbExtSslSrvrStatsEntry SSL server stats entry. .1.3.6.1.4.1.20632.5.99.1.2.6.1
sslSrvrSrvcAddressType The type of the service address, as defined .1.3.6.1.4.1.20632.5.99.1.2.6.1.1

sslSrvrSrvcAddress The SSL service address. .1.3.6.1.4.1.20632.5.99.1.2.6.1.2
sslSrvrSrvcPort The port on which the SSL service is .1.3.6.1.4.1.20632.5.99.1.2.6.1.3

listening.
sslSrvrAddressType The type of the server address, as defined in .1.3.6.1.4.1.20632.5.99.1.2.6.1.4

sslSrvrAddress The SSL server address. .1.3.6.1.4.1.20632.5.99.1.2.6.1.5
sslSrvrPort The port on which the SSL server is .1.3.6.1.4.1.20632.5.99.1.2.6.1.6

listening.
sslSrvrTotReqAccepted The total number of requests accepted by .1.3.6.1.4.1.20632.5.99.1.2.6.1.7

the SSL server.
sslSrvrTotReqActive The total number of active requests at the .1.3.6.1.4.1.20632.5.99.1.2.6.1.8

server.

sslSrvrTotReqRejected The total number of requests rejected by the .1.3.6.1.4.1.20632.5.99.1.2.6.1.9

server.
sslSrvrTotSuccess The total number of requests that .1.3.6.1.4.1.20632.5.99.1.2.6.1.10

successfully connected to the server.
sslSrvrTotRefused The total number of requests rejected by the .1.3.6.1.4.1.20632.5.99.1.2.6.1.11

server.
sslSrvrTotTimedout The total number of requests that timed out .1.3.6.1.4.1.20632.5.99.1.2.6.1.12

at the server.
sslSrvrAvgReqPerConn The average number of requests per .1.3.6.1.4.1.20632.5.99.1.2.6.1.13

connection at the server.
sslSrvrTotResponse The total number of responses at the server. .1.3.6.1.4.1.20632.5.99.1.2.6.1.14
sslSrvrAvgResTime The average response time of the server. .1.3.6.1.4.1.20632.5.99.1.2.6.1.15
sslSrvrMaxResTime The maximum response time of the server. .1.3.6.1.4.1.20632.5.99.1.2.6.1.16
sslSrvrMinResTime The minimum response time of the server. .1.3.6.1.4.1.20632.5.99.1.2.6.1.17
sslSrvrNumReqEnqueue The number of requests enqueued at the .1.3.6.1.4.1.20632.5.99.1.2.6.1.18

server.
sslSrvrNumFreeConn Number of free connections at the server. .1.3.6.1.4.1.20632.5.99.1.2.6.1.19
sslSrvrNumOpeningConn Number of opening connections at the .1.3.6.1.4.1.20632.5.99.1.2.6.1.20

server.
sslSrvrNumConn Number of connections at the server. .1.3.6.1.4.1.20632.5.99.1.2.6.1.21
sslSrvrNumIBDisabled Number of IB disabled at the server. .1.3.6.1.4.1.20632.5.99.1.2.6.1.22
sslSrvrNumOOBDisabled Number of OOB disabled at the server. .1.3.6.1.4.1.20632.5.99.1.2.6.1.23
sslSrvrNumOOBEnabled Number of OOB enabled at the server. .1.3.6.1.4.1.20632.5.99.1.2.6.1.24
sslSrvrLastDisabledTime The length of time in milliseconds since the .1.3.6.1.4.1.20632.5.99.1.2.6.1.25

server was last disabled.
sslSrvrState Server state. Possible values: .1.3.6.1.4.1.20632.5.99.1.2.6.1.26
0: server up
1: server down
sslSrvrInBytes Total IN bytes. .1.3.6.1.4.1.20632.5.99.1.2.6.1.27
sslSrvrOutBytes Total OUT bytes. .1.3.6.1.4.1.20632.5.99.1.2.6.1.28

How to Enable, Disable, and Maintain Real Servers
Disabling your Real Servers allows you to perform maintenance or to temporarily disassociate them from a Service. A Real Server that is in
disabled, maintenance, or sticky 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 Enable, Disable, Maintenance, or Sticky actions on the BASIC > Server Health page.
Edit the Real Server on the BASIC > Services page.
If you set the state of a Real Server to Enable, it accepts new requests, connections or sessions.
The following tables describe how servers behave when set in Maintenance, Disable, and Sticky modes depending on the type of service.
Maintenance
Services Behavior
Layer 4 TCP Existing connections are handled by the server. No new connections
are allowed if either of the following are configured:
On the BASIC > Services page, Persistence Type under Load

Balancing is set to None (default value).
On the ADVANCED > System Configuration page, Disable
Maintenance Persistence under Global Settings is set to Yes.
TCP Proxy and Secure TCP Proxy Existing connections are handled by the server. No new connections
are allowed.
HTTP, HTTPS, Instant SSL Existing requests and connections are handled by the server. No new
requests or connections are allowed.
RDP Proxy Existing connections are handled by the server. No new connections
are allowed.
Layer 4 and Layer 7 UDP Existing datagrams continue to reach the server. However, the server
is not used for new datagrams.
FTP and FTP SSL Existing and ongoing connections are served by the server. No new
connections are allowed.
Disable
Services Behavior
Layer 4 TCP Service for existing requests and connections is stopped

immediately. Connections are closed after the time configured for TC
P Connections Timeout on the ADVANCED > System
Configuration page under System Settings. No new requests or
TCP Proxy and Secure TCP Proxy Existing requests and connections are dropped immediately. No new
HTTP, HTTPS, Instant SSL Existing requests and connections are handled by the server. No new
RDP Proxy No new connections are allowed.
Layer 4 UDP This server is not used for any datagram.
Layer 7 UDP Existing datagrams are handled by the server. The server is not used
for new datagrams.
FTP and FTP SSL Existing and ongoing connections are dropped immediately. No new
Sticky

Services Behavior
HTTP, HTTPS, Instant SSL, TCP Proxy, Secure TCP Proxy New persistence connections are allowed until their persistence
timers expire. No new connections are allowed.
FTP and FTP SSL Persistence connections continue to connect to the same server
unless the persistence timer has expired. No new connections are
allowed.

How to Remotely Administer Real Servers
You can remotely administer Real Servers that are located behind the Barracuda Load Balancer ADC by completing the following steps:
1. For each Real Server, create a Service on the Basic > Services page.
2. Configure just one Real Server for this service (the one you want to administer remotely).
3. Use the Virtual IP address for the 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

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.
The Running Tasks section lists the tasks that are being performed. Some of the tasks that the Barracuda Load Balancer ADC tracks include:
Linked management setup

Cluster setup
Configuration restoration
Report generation
Reports currently being generated
Reports queued for email
If pending reports are consuming too many system resources or are no longer needed, you can cancel these reports from this page.
Importing data
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 any errors encountered when performing system tasks.The errors are not phased out over time. An error remains in
the list until you explicitly remove it.

High Availability
In this Section
Understanding Barracuda Load Balancer ADC High Availability

How to Configure the Barracuda Load Balancer ADC for High Availability
How to Manage a High Availability Environment with Two Barracuda Load Balancer ADCs
How to Remove a Barracuda Load Balancer ADC from a High Availability Environment
How to Replace a Barracuda Load Balancer ADC in a High Availability Environment
How to Update the Firmware on Clustered Systems
High Availability - Firewall Failover

Understanding Barracuda Load Balancer ADC High Availability
For high availability (HA), you can cluster two Barracuda Load Balancer ADCs as an active-passive pair. Only one of the appliances is active and
processes traffic at any time, but the two systems continuously share almost all configuration settings and monitor each other's health. The
passive (backup) appliance does not load balance or monitor the services or real servers. For example, in the web interface of the passive
appliance, all of the services and real servers on the BASIC > Services page have green health indicators.
Failover Conditions
The active appliance in an HA setup handles all of the traffic until one of the following conditions is encountered:
The passive appliance detects that the active appliance is no longer responsive on the Management (MGMT) interface.
The active appliance detects that any of the monitored interfaces or links is down.
Memory usage on the active Barracuda Load Balancer ADC exceeds 75% of total system memory.
You manually execute a failover.
The active appliance encounters a hardware failure (including a power failure) or a failure in one of its critical software modules.
There is a data path crash on the active appliance.
If any of these conditions is encountered, the passive appliance becomes active, processes and load balances traffic for all of the services, and (if
enabled) performs security validation. It also sends out a gratuitous address resolution protocol (GARP) every minute; the passive appliance does
not issue any address resolution protocols (ARPs).
The active appliance is determined by the Virtual Router Redundancy Protocol (VRRP) specification. You must configure the clustered
appliances with the same Cluster Shared Secret and Cluster Group ID. If other systems on the same subnet are also using VRRP, the Cluste
r Group ID must be unique.
Requirements
Before you can cluster two Barracuda Load Balancer ADCs, they must be:
The same model.

Activated and upgraded to the same firmware version.
Able to access all real servers.
On the same physical network segment.
Able to reach each other on the MGMT interface.
In addition, the active appliance must be fully configured. For the complete list of service and network configurations that you must complete, see
Services and Step 5 - How to Configure Your Network and Services.
Recommendations
When setting up Barracuda Load Balancer ADCs for high availability, Barracuda recommends the following:
Do not configure services on the passive (backup) appliance.

To speed up recognition of a newly active Barracuda Load Balancer ADC, disable Spanning Tree Protocol on the ports of the switch
where the MGMT ports of the two Barracuda Load Balancer ADCs are connected. If it is a Cisco switch, enable Spanning Tree PortFast
on the ports connected to the MGMT ports of the Barracuda Load Balancer ADCs. When the Barracuda Load Balancer ADC becomes
active it sends out a gratuitous ARP. It continues to send a gratuitous ARP every minute; the passive system does not issue any ARPs.

How to Configure the Barracuda Load Balancer ADC for High Availability
For an overview of High Availability and a list of requirements, see the article Understanding Barracuda Load Balancer ADC High Availability.
Configuring the Unit for Clustering
Complete the following steps on each Barracuda Load Balancer ADC you plan to include in the high availability cluster:
1. Go to the ADVANCED > High Availability page.

2. In the Cluster Settings section, specify values for the following:
a. Enable High Availability – Set Enable High Availability to Yes on both the Barracuda Load Balancer ADCs before clustering.
If set to No, the Join Cluster will fail with an error.
b. Cluster Shared Secret – The passcode that the clustered units use when communicating with one another. It must be the same
on both systems.
c. Cluster Group ID – This must be same on both the Barracuda Load Balancer ADCs that are to be clustered. If other network
components on the local network, such as firewalls, are clustered using VRRP then they must use a different ID than this one.
Maximum value is 255.
d. Failback Mode – Set to Automatic if you want the Primary (Active) system to resume Service(s) upon its recovery. When set to
Manual, you will need to intervene to return the Service(s) from the Backup unit to the Primary unit upon its recovery.
e. Monitor Link(s) – Select the interface(s) to be monitored. If the backup system determines that the monitored link is not
available on active device, it will become active and assume the virtual IP addresses. The passive Barracuda Load Balancer
ADC becomes the active appliance and begins to handle all traffic.
It is essential that you configure the same interfaces for both the active and passive appliances before you enable high
availability. If the Monitor Link(s) configuration does not match, the passive appliance could automatically take over
for the active appliance, even though no actual failure has occurred.
3. Click Save Changes to save the settings.
To Cluster Two Barracuda Load Balancer ADCs
To cluster two Barracuda Load Balancer ADCs together, where the primary/active system is designated as Barracuda Load Balancer ADC 1, and
the backup/passive system is designated as Barracuda Load Balancer ADC 2:
1. Complete the installation process for each system.

2. On the ADVANCED > High Availability page of the Barracuda Load Balancer ADC 1, in the Cluster Settings section:
b. Specify values for Cluster Shared Secret, Cluster Group ID, Failback Mode and Failover on Link Down and click Save
Changes.
3. On the ADVANCED > High Availability page of the Barracuda Load Balancer ADC 2:
b. Specify values for Cluster Shared Secret, Cluster Group ID and Failback Mode and click Save Changes.These values
should be same as the Barracuda Load Balancer ADC 1.
c. In the Clustered Systems section, enter the management IP address of the Barracuda Load Balancer ADC 1 and click Join
Cluster.
d. The clustering will run as a background task and may take a few minutes to complete. Do not do any other configuration
changes while the clustering task is running.
4. After a few minutes, refresh the ADVANCED > High Availability page on both systems and verify the following:
a. Each system's MGMT IP address appears in the Clustered Systems table.
b. The status of the Primary (Active) system should be .
c. The status of the Backup (Passive) system should be .
Configuration Synchronization
Join Cluster clears any existing configuration on the backup system and copies the configuration settings from the primary system. When the
systems are clustered, the configuration continues to be synchronized once every 2 minutes.

How to Manage a High Availability Environment with Two Barracuda Load

Balancer ADCs
For an overview of High Availability, and a list of requirements, see the article Understanding Barracuda Load Balancer ADC High Availability .
Failover Due to the Monitored Link Going Down
There is an option to fail over to the Backup unit if the Primary unit cannot detect all monitored links.
Failover Due to Software Failures or Lack of Resources
An automatic failover can also be triggered by software failures or low system resources:
System critical process failures (for example, the data path processes or configuration handling processes crashes 3 or more times
within 10 minutes).
Low memory (if system memory usage exceeds 75% of total system memory).
Forceful or Manual Failover
You can force failover to the Backup unit using the web interface. This transfers the load to the Backup unit without bringing down any of the
interfaces of the Primary unit. When the Backup unit becomes Active, interface cables can be removed or other maintenance performed on the
now-Backup unit (for example, the failed Primary unit).
Primary and Backup Roles
When two units are joined in a cluster, the unit from where the Join Cluster operation is performed is the Backup unit. The other one has the role
of Primary unit. Initially, the Primary unit is the Active system that serves the traffic. Either of the systems in a cluster is capable of being the
Active system.
Failback
There is an automatic failback option that can be configured if you want the originally Active (Primary) unit 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 unit 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 unit
suffers an outage, the Backup unit takes over. When the Primary unit recovers, if automatic failback is selected, then it will once again
become the Active unit. This means two interruptions of service. If manual failback is selected, the Backup unit continues to process traffic even
after the recovery of the Primary unit.
If it appears that the Barracuda Load Balancer ADC is entering fault states due to running low on memory, Barracuda recommends setting the
failback mode to Manual.
If the Backup unit also runs low on memory, it should failback to the Primary unit as long as that system is in a good state. If both units
enter a fault state due to memory problems, they will not be able to service traffic. If you are unable to determine the cause of the low
memory problem on the clustered units, please contact Barracuda support.
Synchronize Data between Clustered Systems
When two Barracuda Load Balancer ADCs 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 page
The following data is unique between the clustered systems:
The Management IP address configuration (DNS servers and domain) configured on the BASIC > IP Configuration page.
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
.

How to Remove a Barracuda Load Balancer ADC from a High Availability

Environment
Remove a System from a Cluster
A Barracuda Load Balancer ADC can be removed from the cluster at any time. Perform the following steps to remove a unit from the cluster:
1. On the ADVANCED > High Availability page of the Backup unit perform the following:
2. Clear the Cluster Shared Secret in the Cluster Settings section, and click Save Changes.
3. Click the delete icon under Clustered Systems to remove the other unit from the cluster.
4. On the ADVANCED > High Availability page of the Primary unit which is in cluster with this unit, click the delete icon under Clustered S
ystems.
Removing the unit from the cluster clears all configuration including Services from the Backup unit, and retains all configuration on the
Primary unit.
Return a Unit to a Cluster
In case if you have removed the failed unit from the cluster and want to put it back in cluster, do the following:
1. Make sure the failed unit is removed from the network.

2. On the removed unit, navigate to the ADVANCED > System Configuration page and perform the Clear Configuration operation
before putting the unit back into the network.

How to Replace a Barracuda Load Balancer ADC in a High Availability

Environment
Caution
High availability (HA) is an advanced feature; contact Barracuda Networks Technical Support before replacing a Barracuda Load
Balancer ADC in a cluster.
See also: How Barracuda Networks Manages Returned Device Drives.
The steps for replacing a Barracuda Load Balancer ADC differ based on whether the system is the Primary or the Secondary device in the
cluster.
Note that both Barracuda Load Balancer ADCs in HA must be the same model and on the same firmware.
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 1. New Replacement Primary Device
Important
Follow the steps in this procedure carefully, it is necessary to perform a hot swap and delete the Primary device from the Secondary de
vice configuration at the end of this procedure to avoid wiping out the configuration of the Secondary device.
Figure 1. New Primary Device Replacement.
1. 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.
2. Complete the following steps on the Secondary device:

a. Log in to the Secondary device, and navigate to the ADVANCED > Backups page.
b. In the Manual Backups section, click Backup Now to download a backup to your desktop.
3. Install the new replacement Primary device and set the MGMT 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.
4. Once the new device is installed, log in to the Primary System, go to the ADVANCED > Backups page, and complete the following
steps:
a. In the Restore Backups section, click Browse next to Restore From; navigate to and select the configuration backup saved on
your desktop.
b. Click Open or Choose to download the file to your system. The downloaded backup file gets displayed on the top with the
details such as Backup Time, Serial#, Model, Firmware and Type.
c. Click Restore Now to restore the configuration backup file to the Primary device.
Warning
Connections on the primary and secondary devices may go down intermittently during this procedure.
5. 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.
6. 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 Default Domain name under Domain
Configuration.
c.

c. Navigate to the ADVANCED > High Availability page, and under Clustered Systems, set the IP address of the Primary device
, and click Join Cluster.
Scenario 2. Activate the New Primary Device in an Isolated Network
Figure 2. Isolated Network Environment.
1. Back up the system configuration on the Secondary device.
Note that the Secondary device must remain active until step 6 in this procedure.
2. Log in to the Secondary device, and navigate to the ADVANCED > Backups page.
3. In the Manual Backups section, click Backup Now to download a backup to your desktop.
4. Install the new replacement Primary device in an isolated network, and complete the following steps:
a. Go to the ADVANCED > Backups page on the Primary device, and in the Restore Backups section, click Browse next to Rest
ore From.
b. Navigate to and select the configuration backup saved on your desktop in step 3 above.
c. Click Open or Choose to download the file to the Primary device. The downloaded backup file gets displayed on the top with the
details such as Backup Time, Serial#, Model, Firmware and Type.
d. Click Restore Now to restore the configuration backup file to the Primary device.
e. Set the MGMT IP address of the old Primary device to the new Primary device.
5. Verify the configuration on the new Primary device.
6. 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.
7. Put the Secondary device in an isolated network.
8. 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.
1. Remove the old Secondary device using the instructions in the article How to Remove a Barracuda Load Balancer ADC from a High
Availability Environment.
2. Once the new device is installed, follow the steps in the article How to Configure the Barracuda Load Balancer ADC for High Availability t
o complete the system replacement in the HA configuration.
When replacing a system in a cluster, both systems must be on the same firmware version.

How to Update the Firmware on Clustered Systems
To update the firmware with a minimal disruption of service:
1. Download the new version of the firmware on both units.

2. Go to the ADVANCED > High Availability page of the Primary unit and set Failback Mode to Manual in the Cluster Settings section.
3. Go to the ADVANCED > High Availability page of the Backup (Passive) unit and ensure Failback Mode is Manual.
4. On the Backup unit, go to the ADVANCED > Firmware Update page and click on the Apply Now button next to the downloaded
firmware version.
5. This reboots the unit. Wait until the Backup unit comes up.
6. On the Primary unit, go to the ADVANCED > High Availability page and click the Failover button under Clustered Systems. This
operation fails over all Service(s) from the Primary unit to the Backup unit. The Backup unit assumes the Service(s) and continues to
process the traffic.
7. On the Primary unit, go to the ADVANCED > Firmware Update page and click on the Apply Now button next to the downloaded
firmware version. This reboots the unit.
8. Now, go to the ADVANCED > High Availability page of the Primary unit and click on the Failback button under Clustered Systems.
This operation fails back all Service(s) from the Backup unit to the Primary unit. The Primary unit assumes the Service(s) and continues
to process the traffic.
9. On the Primary unit, change the Failback Mode to Automatic if you want the Primary (Active) system to resume Service(s) upon its
recovery automatically.

High Availability - Firewall Failover
The following illustrations shows the topology for a pair of clustered Barracuda Load Balancer ADCs connected to a pair of redundant Dell N2048
switches. This topology would prevent a loss of network traffic in the event of a failure of either a switch or a Barracuda Load Balancer ADC. The
following describes how these devices are interconnected:
The solid lines linking ports 1 and 3 on both Barracuda Load Balancer ADCs to the two switches represent a WAN trunk configured over
a single VLAN.
The small dotted lines linking ports 2 and 4 on both Barracuda Load Balaner ADCs to the two switches represent a LAN trunk configured
over two VLANs.
The large dotted lines represent the connections from the MGMT ports on each Barracuda Load Balancer ADC to each switch.
The switches are also directly connected together. However, the switches are not stacked (the switches are managed separately as
opposed to being managed as a single unit).
Each trunk is seen as just one switch by the end units because multi-chassis link aggregation (MLAG) is configured across both
switches. MLAG allows you to bond two or more physical links into a logical link between two switches.
Based on the topology shown, the following describes the expected behavior of the Barracuda Load Balancer ADCs in the event of various types
of system failures.
1. If the active switch is Y and the active Barracuda Load Balancer ADC is A and the active switch fails-over to switch Z, Barracuda Load
Balancer ADC A should also failover to Barracuda Load Balancer ADC B.
2. If the active Barracuda Load Balancer ADC is A and it fails-over to Barracuda Load Balancer ADC B, switch Y should detect the
Baracuda Load Balancer ADC failover should failover to switch Z.
3. If the active Barracuda Load Balancer ADC is A and one of the LAN or WAN trunks fails, Barracuda Load Balancer ADC A should
fail-over to Barracuda Load Balancer ADC B and switch Y should failover to switch Z.
4. If the active Barracuda Load Balancer ADC is A and its MGMT connection fails, Barracuda Load Balancer ADC A should fail-over to
Barracuda Load Balancer ADC B and switch Y should failover to switch Z.
The behavior described for this topology might not apply when using switches from another vendor.

System Administration and Maintenance
In this Section
How to Reload, Restart, and Shut Down the System

How to Configure Administrator Access
How to Update Definitions Under Energize Updates
How to Update and Revert the Firmware
How to Back Up and Restore Your System Configuration
How to Reboot the System in Recovery Mode
How to Replace a Failed System
Troubleshooting
How to Migrate from the Barracuda Load Balancer
publish

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 ADC.
Shutting down the system powers off the unit. Restarting the system reboots the unit. Reloading the system re-applies the system configuration.
If your Barracuda Load Balancer ADC is equipped with a RESET button on the front panel, you can reboot the appliance by pressing it.

How to Configure Administrator Access
The Barracuda Load Balancer ADC is shipped with predefined administrator roles, each with distinct operational and configuration privileges.
These roles can be assigned to users to perform specific job functions. The admin role, by default, is assigned to the administrative user who has
permission for role management and also has access to all of the functionality of the Barracuda Load Balancer ADC.
Administrator Account Settings
On the ADVANCED > Admin Access Control page in the Administrator Account Settings section, you can configure a password security
policy to ensure that administrators and users create secure passwords. You can also configure a policy to lock administrator accounts after a
specified number of failed login attempts. For more information on password policy and account lockout policy settings, refer to the online Help.
Configure the Password Policy
Click Password Policy Settings to configure the following:
Policy - You can select either Default or Custom. Select Custom to modify the password policy.
Minimum Characters - Specify the minimum number of characters needed for the password (the default value is 8).
Contains - Specify the types of characters that must be present in each password:
At Least One Upper Case Character
At Least One Lower Case Character
At Least One Special Character
At Least One Digit
Expires In - Time until password expires:
3 Months
6 Months
1 Year
Never
Other - Specify between 30 and 999 days.
Notify Before Expiry - Time before notifying the user that his or her password is about to expire.
1 Week
2 Weeks
Configure the Account Lockout Settings
To prevent unauthorized access to the Barracuda Load Balancer ADC, click Account Lockout Settings. Use these settings to specify when a
user will be locked out from the Barracuda Load Balancer ADC based on the number of times they have failed to enter their login credentials
correctly.
Maximum Failed Login Attempts - Specify the acceptable number of failed login attempts (default is 5).
Failed Login Time Threshold - Specify the time in minutes in which consecutive failed login attempts are counted (default is 15).
Lock User Account - Specify the time in minutes to lock the admin account if the user fails to login more than the Maximum Failed
Login Attempts value in less that the time specified by the Failed Login Time Threshold (default is 15).
If an account is locked after the maximum failed login attempt limit has been reached, an Admin user can clear the account lock in the
Administrator Accounts section by clicking Clear Lockout next to the user.
Administrator Roles
The following table lists a predefined set of roles provided by the Barracuda Load Balancer ADC. A predefined role cannot be modified or deleted.
You can open a pop-up window with a detailed description of the access granted to a particular role by clicking Details. Each role is allowed to
complete specific operations on the Barracuda Load Balancer ADC and is denied access to specific user interface screens. These predefined
roles cannot be modified.
You can assign roles to users either by configuring an external authentication service (LDAP or RADIUS) or on an individual basis by configuring
a local administrator. When a user attempts to log in, the Barracuda Load Balancer ADC first tries to authenticate the user credentials against
configured local administrators, then queries the configured external authentication service. Once authenticated, the user inherits privileges from
the associated role.
Role Allowed Functions
Admin The super administrator
All system operations
Note: Only admins can assign roles

Service Manager Configuring services

Configuring security policies
Security Manager Configuring security policies
Network Manager IP configuration

IP operations (ping, telnet, TCP dump, etc)
Network troubleshooting
Reporting Manager Viewing and exporting logs

Scheduling and exporting reports
Guest View all configurations
Note: Guest cannot modify the configuration
External Authentication Services
External administrators or users are part of an external authentication service like the Lightweight Directory Access Protocol (LDAP) or Remote
Authentication Dial In User Service (RADIUS). The Barracuda Load Balancer ADC enables you to configure external authentication services,
allowing authenticated external users to access the system. An external user cannot be created, but is synchronized internally from the LDAP or
RADIUS server when the user is successfully authenticated with the configured directory services. You can override the default role association
for an external user by editing the user.
Configure LDAP or RADIUS External Authentication Services
The Barracuda Load Balancer ADC can use both LDAP and RADIUS external authentication services to validate users attempting to login and
administer the appliance. When a new user with valid credentials (as determined by checking the LDAP or RADIUS database) logs in, the
Barracuda Load Balancer ADC also creates a local account for that user. This gives you additional flexibility with regards to these users in that
you can alter their local account role independently of the configuration for LDAP or RADIUS external authentication service.
To configure an LDAP or RADIUS external authentication service, complete the following steps:
1. Go to the ADVANCED > Admin Access Control page.

2. In the External Authentication Services section, select LDAP or RADIUS from the drop down menu. The Add LDAP Service or Add
RADIUS Service popup window opens.
3. Configure the external service as required. See the online help for details about each configuration option.
4. Assign a default role to all of the users associated with a specific LDAP or RADIUS service by selecting a role from the Default Role dro
p down menu.
If the administrator changes the default role, the new role is assigned to the associated LDAP or RADIUS users, unless a user's role is
explicitly configured by the administrator in the Administrator Accounts section.
Add LDAP Service Group Mapping
You can assign users associated with a specific LDAP group to one of the predefined user roles on the Barracuda Load Balancer ADC. The
LDAP users would gain access to the features and functionality associated with that role. Groups are evaluated based on the specified role
priority (1 is the highest priority and 10 the lowest).
A user logging into the Barracuda Load Balancer ADC for the first time (the user has not yet been added to the user database) whose group on
the LDAP server does not match any of the predefined roles on the Barracuda Load Balancer ADC is assigned the default role configured for the
external LDAP server.
If you change the configuration for the default role of an external server, the role assignment for all the users of this external server is also
changed.
For more information on roles, see Administrator Roles.
If a user's role is mapped to one or more roles based on group mapping, the role with the higher priority is assigned to the user. If a
user does not belong to any of the mapped groups, the user assumes the default role configured for the LDAP server.
Change the Default Role for an External User
When a default role is associated with the LDAP or RADIUS authentication service, all external users authenticated through the LDAP or RADIUS
database are assigned to that role. For example, consider the default role, Security Manager, for the configured LDAP server. An external user
authenticated through that LDAP database is assigned Security Manager role and can perform only security management tasks. The Admin us
er can change the default role assigned to a user if required.

To change the role assigned to a user:

2. In the Administrator Accounts section, identify the desired user.
3. Click Edit next to the user. The Edit Administrator Account window appears.
4. Select a role for the user from the Role drop-down list.
5. Add an Email Address and click Update.
Administrator Accounts
You can specify local administrators on the Barracuda Load Balancer ADC. These users are authenticated internally by the appliance. The Admi
n user can create local users and associate each user with an administrator role. If you delete a local administrator account, that user is denied
access to the system.
When evaluating any user logging in to Barracuda Load Balancer ADC, preference is given first to the local account, then LDAP, and then
RADIUS. If the user's password does not match the password in the local account, no attempt is made to check if the user has a valid account on
the LDAP or RADIUS server and a password does not match error is displayed.
If there are two or more users who share the same username, the user logging in first is considered the valid user who is populated in the
administrator accounts. Other users with that username are considered invalid.
To add a local administrator, complete the following steps:

2. In the Administrator Accounts section, click on Add Local Administrator.
3. Specify a User Name, Password, and Email Address to the new user.
4. Select a role for the new user from the Role drop down menu. For more information, see Administrator Roles.

How to Update Definitions Under Energize Updates
Energize Updates delivers the latest attack, virus, security, update, and location definitions from Barracuda Central to protect your Barracuda
Load Balancer ADC. On the ADVANCED > Energize Updates page, you can choose to automatically or manually update each definition:
To let a definition sync automatically whenever a new version is available, enable the Automatic Updates setting for it.
If you want to manually update a definition, disable the Automatic Updates setting for it. You can manually update a definition online at
any time. If offline updates are enabled, you can complete offline updates of the definitions.
For maximum protection, Barracuda Networks recommends that you enable Automatic Updates for each set of definitions, so that you receive
the latest versions as soon as they are available from Barracuda Central.
Activating the Attack Definition

Activating the Attack Definition
After you update the Attack Definition (automatically or manually), you must activate it by clicking the Activation link that displays on
the BASIC > Status or ADVANCED > Energize Updates page. During the activation of the Attack Definition, the data path traffic
may be interrupted, possibly dropping incoming packets for a few seconds.
For the updates of all other definitions, traffic is processed normally.
Configure Automatic Definition Updates
To enable and disable automatic updates:
1. Go to the ADVANCED > Energize Updates page.

2. In the section for each definition that you want to automatically update, set Automatic Updates to On. The definition will automatically
update whenever a new version is available.
3. In the section for each definition that you do not want to automatically update, set Automatic Updates to Off. You must then manually
update the definition whenever a new version is available. You can update definitions online and offline.
4. Click Save.
Manually Update Definitions Online
To manually update definitions online:

2. In the section for each definition, compare the installed version to the latest general release version available. If you have the latest
definition version already installed, the Update button for the latest version is disabled.
3. If there is a new version available, click Update to update the definition immediately.
Manually Update Definitions Offline
To update definitions for the Barracuda Load Balancer ADC without Internet access, you must enable offline updates. You can then manually
download the latest definition packages from your Barracuda Cloud Control account and then upload the packages to the Barracuda Load
Balancer ADC.
1. Contact Barracuda Networks Technical Support for a Feature Code to enable offline updates.
2. Go to the Support > Downloads page in your Barracuda Cloud Control account, and download update packages for the latest versions
of the following:
Attack definition
Virus definition
Security definition
Location definition
Update definition
4. Enable expert mode by appending the URL with: &expert=1
5. Enable offline updates.
a. Go to the ADVANCED > Offline Update page that appears.
b. Enter the Feature Code on the page, and then click Activate.
c. Next to the Enable Offline Updates setting that appears, select Yes.
d. Click Save.
7. In the Definition Update Upload section, click Browse to navigate to and select a definition package that you downloaded from your
Barracuda Cloud Control account in step 2.
8.

8. After the definition package is completely uploaded, click Apply Now.

9. Repeat steps 7 and 8 until you have updated all of the definitions on the page.

How to Update and Revert the Firmware
Updating the Firmware for a High Availability Cluster

This article provides instructions on updating the firmware for standalone Barracuda Load Balancer ADCs.
If you want to update the firmware for two Barracuda Load Balancer ADCs configured in high availability cluster, see How to Update the
Firmware on Clustered Systems.
On the ADVANCED > Firmware Update page, you can update or revert the firmware version of the Barracuda Load Balancer ADC. If offline
updates are enabled, you can complete an offline firmware update.
Because the Barracuda Load Balancer ADC reboots during the firmware update, it is recommended that you update the firmware in a planned
maintenance window.
Before You Update the Firmware
Before you update the firmware version of the Barracuda Load Balancer ADC, it is strongly recommended that you:
Go to the ADVANCED > Backups page and back up your current configuration.
Read all release notes that apply to versions that are more recent than the one currently running on your system. You can view the
release notes on the ADVANCED > Firmware Update page. if you are performing an offline firmware update, the release notes appear
after you upload the firmware update package with the steps in the Offline Firmware Update section below.
Online Firmware Update
To update the firmware for the Barracuda Load Balancer ADC:
1. Go to the ADVANCED > Firmware Update page.

2. Compare the installed version in the Current Firmware Version section to the latest general release version available in the Firmware
Download section. If you have the latest firmware version already installed, the Download Now button for the latest general release
version is disabled.
3. If there is a new Latest General Release available, click Download Now and allow the update to finish downloading.
4. After the update is completely downloaded, click Apply Now.
Do not reboot or turn off the Barracuda Load Balancer ADC while the firmware is updating. The process can take several minutes to complete,
depending on your configuration. After the firmware finishes updating, the Barracuda Load Balancer ADC automatically reboots and you are
redirected to the login screen.
Offline Firmware Update
To update the firmware for the Barracuda Load Balancer ADC without Internet access, you must enable offline updates. You can then download
the latest firmware package from your Barracuda Cloud Control account and upload the package to the Barracuda Load Balancer ADC.
1. Contact Barracuda Networks Technical Support for a Feature Code to enable offline updates.
2. Go to the Support > Downloads page in your Barracuda Cloud Control account, and download the latest firmware package.
4. Enable expert mode by appending the URL with: &expert=1
5. Go to the ADVANCED > Offline Update page that appears and enable offline updates.
a. Enter the Feature Code that you received from Barracuda Networks Technical Support, and then click Activate.
b. When the Enable Offline Updates setting appears, select Yes.
c. Click Save.
6. Go to the ADVANCED > Firmware Update page.
7. In the Firmware Upload section, click Browse to navigate to and select the firmware package that you downloaded from your Barracuda
Cloud Control account in step 2.
8. Click Upload.
9. After the firmware package is completely uploaded, click Apply Now.
Do not reboot or turn off the Barracuda Load Balancer ADC while the firmware is updating. The process can take several minutes to complete,
depending on your configuration. After the firmware finishes updating, the Barracuda Load Balancer ADC automatically reboots and you are
redirected to the login screen.
Firmware Revert
If you are reverting the firmware to a major release, the configuration that you had for that release version is loaded after the revert
process completes.

You can revert the firmware to the previously installed version or to the factory installed version at any time. However, it is strongly recommended
that you contact Barracuda Networks Technical Support before reverting the firmware.
To revert the firwmare, go to the ADVANCED > Firmware Update page and revert to either the previously installed version or to the factory
installed version in the Firmware Revert section. Do not reboot or turn off the Barracuda Load Balancer ADC while the firmware is reverting. The
process can take several minutes to complete, depending on your configuration. After the firmware finishes reverting, the Barracuda Load
Balancer ADC automatically reboots and you are redirected to the login screen.

How to Back Up and Restore Your System Configuration
On the ADVANCED > Backups page, you can back up and restore the configuration of the Barracuda Load Balancer ADC. It is strongly
recommended that you regularly back up your appliance in case you must restore this information on a replacement Barracuda Load Balancer
ADC or in the event that your current system data becomes corrupt.
If you are restoring a backup file on a new Barracuda Load Balancer ADC that is not configured, you must assign your new system an IP address
and DNS information on the BASIC > IP Configuration page.
Backup File
Do not edit backup files. Instead, use the web interface to configure your Barracuda Load Balancer ADC. The configuration backup file
contains a checksum that prevents the file from being uploaded to the system if any changes are made.
The following information is not included in the backup file:
System password
System IP information
DNS information

How to Reboot the System in Recovery Mode
If your Barracuda Load Balancer ADC 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 ADC and run a memory test or perform a complete system recovery, as described
in this section.
To perform a system recovery or hardware test:
1. Connect a monitor and keyboard directly to your Barracuda Load Balancer ADC.
2. 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.
3. The Barracuda splash screen displays with the following three boot options:
Barracuda
Recovery
Hardware_Test
4. 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 ADC defaults to starting up in the normal mode (first option).
Reboot Options
Reboot Options Description
Barracuda Starts the Barracuda Load Balancer ADC 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.
Recovery Displays the Recovery Console where you can select the following
options:
Perform file system repair – Repairs the file system on the

Perform full system re-image – Restores the factory settings
on your Barracuda Load Balancer ADC 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, run 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 ADC to stop the hardware

test. You may do this by pressing Ctrl-Alt-Del on the keyboard.

How to Replace a Failed System
Before you replace your Barracuda Load Balancer ADC, use the tools provided on the ADVANCED > Troubleshooting page to try to resolve the
problem.
In the event that a Barracuda Load Balancer ADC 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 ADC 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 95008
To set up the new Barracuda Load Balancer ADC 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.
See also: How Barracuda Networks Manages Returned Device Drives.

Troubleshooting
The ADVANCED > Troubleshooting page provides various tools that help troubleshoot network connectivity issues that may be impacting the
performance of your Barracuda Load Balancer ADC.
From this page you can open a secure troubleshooting connection from your Barracuda Load Balancer ADC to Barracuda Central, allowing a
Barracuda Networks technician to diagnose and troubleshoot an issue with your system.
To open a troubleshooting connection:
1. Click Establish Connection to Barracuda Support Servers.

2. Provide the support engineer with the displayed serial number.
3. After the issue is resolved, click Terminate connection to Barracuda Central to close the connection between your Barracuda Load
Balancer ADC and Barracuda Central.
Network Connectivity Tests
You can use the tools in this section to diagnose potential network problems on the Barracuda Load Balancer ADC:
Ping Device – An interface to the ping command on the Barracuda Load Balancer ADC. 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 ADC. 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 ADC. 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 Be
gin Dig.
TCP Dump – An interface to the TCP dump command on the Barracuda Load Balancer ADC. 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 ADC. 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 ADC 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 ADC. 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 ADC. It shows the destination network
address, gateway network address, and subnetwork mask for the physical and virtual interfaces.
Show Interfaces – This command displays the MAC address for each interface used by the Barracuda Load Balancer ADC.

How to Migrate from the Barracuda Load Balancer
To migrate from a Barracuda Load Balancer to the Barracuda Load Balancer ADC version 5.1 and above, you can restore a backup file from the
Barracuda Load Balancer.
When you restore the configuration from a backup file, the current configuration of your Barracuda Load Balancer ADC is overwritten.
If the Barracuda Load Balancer ADC is part of a high availability cluster, do not restore a backup file onto the appliance because the
cluster information will be lost and both units will have to be reclustered.
Requirements
On the Barracuda Load Balancer ADC, you can restore backup files from only the following versions of the Barracuda Load Balancer:
3.6.1
4.0.0
4.1.0
4.2.1
4.2.2
4.2.3
Before migrating from the Barracuda Load Balancer, you must upgrade it to one of the versions listed above.
Migrate from a Barracuda Load Balancer
To migrate to the Barracuda Load Balancer ADC from a Barracuda Load Balancer:
1. Ensure that the Barracuda Load Balancer has been upgraded to one of the versions listed above in Requirements.
2. If you do not yet have a backup file for a version of the Barracuda Load Balancer that is supported for this migration, log into the
appliance and go to the ADVANCED > Backups page. In the Configuration Backup section, you can back up the current configuration
of the appliance.
3. Log into the Barracuda Load Balancer ADC and go to the ADVANCED > Backups page.
4. In the Restore Backups section, click Browse to select the Barracuda Load Balancer backup file and then click Open.
5. Wait for the backup file to finish being uploaded and prepared. After the backup file is uploaded, information about the file is displayed at
the top of the page.
6. Click Add Migration Details to configure the WAN IP address, WAN network mask, and WAN gateway from the Barracuda Load
Balancer on the Barracuda Load Balancer ADC.
7. Click Restore Now to confirm that you selected the correct backup file and start the process of applying the configurations from the
backup file. This process can take a few minutes. After the process completes, the Barracuda Load Balancer ADC reboots and you are
redirected to the login page for the web interface.
Migration Changes
The following diagram illustrates some of the differences in the configuration of a Barracuda Load Balancer versus a Barracuda Load Balancer
ADC:

You should be aware of the following aspects of your Barracuda Load Balancer ADC configuration once you have completed the migration of the
Barracuda Load Balancer backup file:
On the Barracuda Load Balancer, you configure the IP address for the appliance on the WAN port. You can also configure services on
the same port.
On the Barracuda Load Balancer ADC, you configure the IP address for the appliance on the management (MGMT) port. You configure
services on the first port (ge-1-1, ge-2-1, or ge-3-1, depending on the model) that are labeled gt-x-y where:
g is gigabit
t is the type of connection (e for Ethernet, f for fiber-optic)
x is the number of the module of 8 ports, where the left-most module is number 1
y is the number of the port within the module, where the top left port is number 1
You need to provide the Barracuda Load Balancer WAN IP address, WAN network mask, and WAN gateway when you restore the
Barracuda Load Balancer configuration to a Barracuda Load Balancer ADC.
After the migration to the Barracuda Load Balancer ADC, review your service settings. You might have to change the network
configuration and netmask for your services because the services that were configured on the WAN port of the Barracuda Load Balancer
are reconfigured on the first port (ge-1-1, ge-2-1, or ge-3-1, depending on the model) of the Barracuda Load Balancer ADC. If you need
assistance, please contact Barracuda Technical Support.
The following custom virtual interface and static route are created automatically based on the WAN details provided by you when you restore the
Barracuda Load Balancer backup file to the Barracuda Load Balancer ADC)
A custom virtual interface named LB_WAN_interface configured with an IP address that matches the Barracuda Load Balancer WAN IP
address and network mask that matches Barracuda Load Balancer WAN network mask is created on the ge-x-x interface of the
A static route configured with the following settings is created on the first port of the Barracuda Load Balancer ADC. This route is
displayed on the Networks -> Routes page of Barracuda Load Balancer ADC.
IP address: 0.0.0.0
Network mask: 0.0.0.0
Gateway: Barracuda Load Balancer WAN gateway

Barracuda Load Balancer ADC - REST API
Overview
The Barracuda Load Balancer ADC Representational State Transfer (REST) Application Programming Interface (API) enables you to remotely
administer and configure your Barracuda Load Balancer ADC. The REST API can be used to complete large configurations by automating the
manual configuration process available through the web interface. For example, you can use the REST API to create services.
You identify resources by their URIs and use HTTP to send requests to the Barracuda Load Balancer ADC. Your application parses the
response, which is always returned using JavaScript Object Notation (JSON). You can use any programming language to interact with the API.
The complete documentation for the Barracuda Load Balancer ADC REST API is provided in the following guide:
Barracuda Load Balancer ADC REST API Version 2
Code examples in this reference guide are written in Curl. If you are using Perl, see the Perl Implementation section of this guide.
If you have any questions after reading this API guide, please contact Barracuda Networks Technical Support at +1-408-342-5400 or email suppo
rt@barracuda.com.
The Barracuda Load Balancer ADC REST API archive is available for download:
Barracuda Load Balancer ADC REST API .zip Archive
Availability
The REST API is available for all Barracuda Load Balancer ADC models running firmware version 5.1, 5.2, 5.3, or 6.0.
Version
The most recent version of the Barracuda Load Balancer ADC REST API is version 2. The REST API version is separate from the firmware
version for the appliance.

Barracuda Load Balancer ADC Hardware Features
Front Panel
Barracuda Load Balancer ADC 240
Table 1. Barracuda Load Balancer ADC 240 front panel features.
Label Description
WAN Port 1 Gigabit copper Ethernet port.
LAN Port 1 Gigabit copper Ethernet port.
Disk Light Displays a blinking blue light during disk activity.
Power Button Turns the appliance on and off.
Power Indicator Displays a solid blue light while the appliance is turned on.
Reset Button Resets the appliance.
Table 1. Barracuda Load Balancer ADC 340 and 440 front panel features.
Label Description
P1 through P4 4 X 1 Gigabit copper Ethernet ports for WAN and LAN connections.

Label Description
P1 through P8 8 X 1 Gigabit copper Ethernet ports for WAN and LAN connections.
Table 4. Barracuda Load Balancer ADC 640, 641, and 642 front panel features.
Label Description
1 Gb Ethernet Ports (labeled 1 through 8) 8 X 1 Gigabit Ethernet copper ports for WAN and LAN connections.
10 Gb Ethernet Ports (labeled 9 and 10) 2 X 10 Gigabit Ethernet ports for WAN and LAN connections.
Model 641: Ethernet copper ports

Model 642: Ethernet fiber ports
USB Ports Reserved for future use.
Unlabeled Ethernet Port Reserved for future use.

Label Description
1 Gb Ethernet Ports 8 X 1 Gigabit Ethernet copper ports for WAN and LAN connections.
Disk Light Displays a blinking yellow light during disk activity.
Failed System State Displays a red light during a appliance failure.
Management Port Activity Displays a blinking green light during network activity over the
management port on the back panel.
Power Indicator Displays a solid green light while the appliance is turned on.
Unused LED This LED does not currently have a function.
Unused Port LED LED for the unused port on the back panel.
Barracuda Load Balancer ADC 841 and 842
Table 6. Barracuda Load Balancer ADC 841 and 842 front panel features.
Label Description
1 Gb Ethernet Ports 8 X 1 Gigabit Ethernet copper ports for WAN and LAN connections.
10 Gb Ethernet Ports 4 X 10 Gigabit Ethernet ports for WAN and LAN connections.
Model 841: Ethernet copper ports

Model 842: Ethernet fiber ports
Disk Light Displays a blinking yellow light during disk activity.
Failed System State Displays a red light during a appliance failure.

Management Port Activity Displays a blinking green light during network activity over the
management port on the back panel.
Power Indicator Displays a solid green light while the appliance is turned on.
Unused LED This LED does not currently have a function.
Unused Port LED LED for the unused port on the back panel.
Back Panel
Barracuda Load Balancer ADC 340, 440, and 540
Table 7. Barracuda Load Balancer ADC 340, 440, and 540 back panel features.
Label Description
DVI-D (Dual Link) Port DVI-D connection for a monitor.
Keyboard Port Connection for the keyboard.
Mouse Port Connection for the mouse.
Management Port Ethernet port that is used as the management port.
Power Supply Socket for the AC power cord; standard power supply.
USB Ports Connections for USB devices.
VGA Port VGA connection for a monitor.
Label Description
Keyboard Port Connection for the keyboard.
Power Supplies (2) Redundant power supplies.

Label Description
Power Supplies (2) Redundant power supplies.
Power Indicator Lights Displays based on power supply health:
Solid green light – System is powered on and the power supply

is healthy
Solid orange/amber light – Power supply is degraded*
No light – System is not powered on or a power supply unit
(PSU) has failed
Serial Port Connection for a serial device.
Unused Port Unused Ethernet port.
USB Ports Connections for USB devices.
Note:
*The power supply may be degraded when, for example, one of the PSUs is not functioning. Push Reset; if this does not resolve the issue you
may need to replace a PSU. Contact Barracuda Networks Technical Support for additional troubleshooting.
Barracuda Load Balancer ADC Appliance Input/Thermal Output
Model Input Current Voltage BTU/hr

(Amps AC)
240 0.3 100-240V 50-60 Hz 123 BTU/hr
340 0.46 100-240V 50-60 Hz 188 BTU/hr
440 0.48 100-240V 50-60 Hz 197 BTU/hr
540 0.6 100-240V 50-60 Hz 246 BTU/hr
640 1 100-240V 50-60 Hz 409 BTU/hr
641 1 100-240V 50-60 Hz 590 BTU/hr
642 1 100-240V 50-60 Hz 540 BTU/hr
840 3.8 100-240V 50-60 Hz 737 BTU/hr
841 3.8 100-240V 50-60 Hz 811 BTU/hr
842 3.8 100-240V 50-60 Hz 786 BTU/hr

Barracuda Load Balancer ADC 使用手冊

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Barracuda Load Balancer ADC 使用手冊

Uploaded by

Copyright:

Available Formats

1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Application Deployment Guides

Copyright © 2017, Barracuda Networks Inc.

What's New in the Barracuda Load Balancer ADC

What's New in Version 6.1

Release Notes Version 6.1.0.004

What's New in Version 6.0

RBAs: Role Based Administrators (RBAs) are now supported.

Augmented SSL Capabilities:

Subject Alternative Names (SAN) certificate creation

Release Notes Version 6.0.1.006

What's New in Version 5.4

Release Notes Version 5.4.0.004

What's New in Version 5.3

SSL Hardware Support: SSL hardware support is now available.

Release Notes Version 5.3.0.003

Copyright © 2017, Barracuda Networks Inc.

What's New in Version 5.2

Release Notes Version 5.2.0.004

What's New in Version 5.1

Release Notes Version 5.1.1.004

Copyright © 2017, Barracuda Networks Inc.

Release Notes Version 6.1.0.004

Copyright © 2017, Barracuda Networks Inc.

Release Notes Version 6.1.0.003

Copyright © 2017, Barracuda Networks Inc.

Release Notes Version 6.0.1.006

Copyright © 2017, Barracuda Networks Inc.

Release Notes Version 6.0.1.005

Copyright © 2017, Barracuda Networks Inc.

Release Notes Version 6.0.0.008

Copyright © 2017, Barracuda Networks Inc.

Release Notes Version 6.0.0.005

Copyright © 2017, Barracuda Networks Inc.

Release Notes Version 6.0.0.004

Global Server Load Balancing (GSLB):

Copyright © 2017, Barracuda Networks Inc.

Deprecated Operations and Known issues

Copyright © 2017, Barracuda Networks Inc.

Release Notes Version 5.4.0.004

Copyright © 2017, Barracuda Networks Inc.

Release Notes Version 5.4.0.003

Copyright © 2017, Barracuda Networks Inc.

Release Notes Version 5.3.0.003

Copyright © 2017, Barracuda Networks Inc.

Release Notes Version 5.3.0.002

SSL hardware support is now available.

Copyright © 2017, Barracuda Networks Inc.

Copyright © 2017, Barracuda Networks Inc.

Release Notes Version 5.2.0.004

Copyright © 2017, Barracuda Networks Inc.

has been addressed. [BNADC-4891]

Copyright © 2017, Barracuda Networks Inc.

Release Notes Version 5.1.1.004

Increased the limit on number of stored trusted certificates to 64. [BNADC-4147]

Copyright © 2017, Barracuda Networks Inc.

Release Notes Version 5.1.1.003

Copyright © 2017, Barracuda Networks Inc.

Release Notes Version 5.1.0.x

Authentication and Authorization

Copyright © 2017, Barracuda Networks Inc.

Support for Barracuda Load Balancer Configuration

Copyright © 2017, Barracuda Networks Inc.

Copyright © 2017, Barracuda Networks Inc.