Name: ProxySG

Text: Blue Coat® Systems
ProxySG® Appliance

Configuration and Management Suite
Volume 5: Advanced Networking

Version SGOS 5.3.x

Volume 5: Advanced Networking

Contact Information
Blue Coat Systems Inc.
420 North Mary Ave
Sunnyvale, CA 94085-4121
http://www.bluecoat.com/support/contactsupport
http://www.bluecoat.com
For concerns or feedback about the documentation: documentation@bluecoat.com

Copyright© 1999-2008 Blue Coat Systems, Inc. All rights reserved worldwide. No part of this document may be reproduced by any means
nor modified, decompiled, disassembled, published or distributed, in whole or in part, or translated to any electronic medium or other
means without the written consent of Blue Coat Systems, Inc. All right, title and interest in and to the Software and documentation are
and shall remain the exclusive property of Blue Coat Systems, Inc. and its licensors. ProxyAV™, CacheOS™, SGOS™, SG™, Spyware
Interceptor™, Scope™, ProxyRA Connector™, ProxyRA Manager™, Remote Access™ and MACH5™ are trademarks of Blue Coat
Systems, Inc. and CacheFlow®, Blue Coat®, Accelerating The Internet®, ProxySG®, WinProxy®, AccessNow®, Ositis®, Powering
Internet Management®, The Ultimate Internet Sharing Solution®, Cerberian®, Permeo®, Permeo Technologies, Inc.®, and the Cerberian
and Permeo logos are registered trademarks of Blue Coat Systems, Inc. All other trademarks contained in this document and in the
Software are the property of their respective owners.
BLUE COAT SYSTEMS, INC. DISCLAIMS ALL WARRANTIES, CONDITIONS OR OTHER TERMS, EXPRESS OR IMPLIED,
STATUTORY OR OTHERWISE, ON SOFTWARE AND DOCUMENTATION FURNISHED HEREUNDER INCLUDING WITHOUT
LIMITATION THE WARRANTIES OF DESIGN, MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE AND
NONINFRINGEMENT. IN NO EVENT SHALL BLUE COAT SYSTEMS, INC., ITS SUPPLIERS OR ITS LICENSORS BE LIABLE FOR
ANY DAMAGES, WHETHER ARISING IN TORT, CONTRACT OR ANY OTHER LEGAL THEORY EVEN IF BLUE COAT SYSTEMS,
INC. HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.

Document Number: 231-03014
Document Revision: SGOS 5.3.1 08/2008

ii

Contents
Contact Information

Chapter 1: About Advanced Networking

About This Book................................................................................................................................ 13
Document Conventions ................................................................................................................... 14
Notes and Warnings ......................................................................................................................... 14
About Procedures ............................................................................................................................. 14
Illustrations ........................................................................................................................................ 15
Chapter 2: Configuring an Application Delivery Network
Section A: ADN Overview

About the Application Delivery Network Elements ................................................................... 19
Section B: About ADN Deployment, Compression, and Security Behavior

Selecting the Correct Deployment.................................................................................................. 24
Transparent Connections .......................................................................................................... 25
Explicit Connections .................................................................................................................. 26
Combination of Transparent/Explicit Connections.............................................................. 27
Choosing Which Traffic to Optimize....................................................................................... 27
About ADN Compression ............................................................................................................... 27
ADN Security .................................................................................................................................... 28
Authenticating and Authorizing ADN Peers......................................................................... 28
Securing ADN Connections...................................................................................................... 29
Section C: Basic ADN Setup

About the ADN Manager ................................................................................................................ 30
ADN Connection Behavior for ADN Managers .................................................................... 31
Configuring the ADN Managers.............................................................................................. 32
Section D: Transparent and Explicit Connection Deployments

Configuring a Transparent Deployment ....................................................................................... 34
Transparent Deployment Notes............................................................................................... 34
Transparent Load Balancing..................................................................................................... 35
Configuring an Explicit Deployment............................................................................................. 38
Managing Server Subnets and Enabling an Internet Gateway............................................ 38
Preserving the Destination Port ............................................................................................... 41
Explicit Load Balancing ............................................................................................................. 41
Configuring a Combined (Transparent and Explicit) Deployment .......................................... 44

iii

Volume 5: Advanced Networking

Section E: Securing the ADN Network

Configuring ADN Security Settings .............................................................................................. 47
Setting Device Security.............................................................................................................. 47
Securing Connections ................................................................................................................ 49
Authorizing Devices to Join the Network .............................................................................. 51
Approved/Pending Notes .............................................................................................................. 53
Section F: ADN Network History, Active Sessions, Byte-Caching Statistics, and Health Metrics

Reviewing ADN History ................................................................................................................. 54
Reviewing ADN Active Sessions ................................................................................................... 55
Reviewing Byte-Caching Statistics................................................................................................. 57
Reviewing ADN Health Metrics .................................................................................................... 57
Section G: Advanced Tunnel Optimization

Setting Advanced Tunneling Parameters ..................................................................................... 60
Section H: Byte-Cache Dictionary Sizing

Understanding Dictionaries ............................................................................................................ 64
Understanding Dictionary Sizing ............................................................................................ 64
Ranking Peers ............................................................................................................................. 65
Dictionary Sizing Messages ...................................................................................................... 66
Ranking New Peers .......................................................................................................................... 66
Manually Sizing Peers ............................................................................................................... 66
Section I: Related CLI Syntax to Configure an ADN Network
Section J: Policy
Section K: Troubleshooting

Using the Test ADN Diagnostics Command................................................................................ 73
Transparent ADN: Success ....................................................................................................... 73
Transparent ADN: Success but no Upstream ADN Connection ........................................ 74
Explicit ADN: Success ............................................................................................................... 74
Explicit ADN: The Upstream Device is not Functioning ..................................................... 75
Error Codes ................................................................................................................................. 75
Showing the ADN Configuration .................................................................................................. 76
Byte-Cache Configuration CLI Tables .................................................................................... 77
Chapter 3: Preventing Denial of Service Attacks

About Attack Detection ................................................................................................................... 79
Configuring Attack-Detection Mode for the Client..................................................................... 80
Changing Global Settings ......................................................................................................... 80
Configuring Attack-Detection Mode for a Server or Server Group.......................................... 83
Chapter 4: TCP Connection Forwarding

About Asymmetric Routing Environments.................................................................................. 85

iv

Contents

The TCP Connection Forwarding Solution................................................................................... 86
About Bidirectional Asymmetric Routing.............................................................................. 87
About Dynamic Load Balancing.............................................................................................. 88
About ADN Transparent Tunnel Load Balancing ................................................................ 89
TCP Configuration Forwarding Deployment Notes ............................................................ 90
Configuring TCP Connection Forwarding ................................................................................... 90
Copying Peers to Another ProxySG in the Cluster ............................................................... 91
Removing a Peer......................................................................................................................... 92
Related CLI Syntax to Configure TCP Connection Forwarding ......................................... 92
Chapter 5: Bandwidth Management

Bandwidth Management Overview .............................................................................................. 93
Allocating Bandwidth ............................................................................................................... 94
Flow Classification ..................................................................................................................... 98
Configuring Bandwidth Allocation ............................................................................................... 98
Enabling Bandwidth Management.......................................................................................... 99
Creating, Editing, and Deleting Bandwidth Classes............................................................. 99
Bandwidth Management Statistics............................................................................................... 102
Current Class Statistics Tab .................................................................................................... 102
Total Class Statistics Tab ......................................................................................................... 103
Bandwidth Management Statistics in the CLI ..................................................................... 103
Using Policy to Manage Bandwidth ............................................................................................ 104
CPL Support for Bandwidth Management .......................................................................... 105
VPM Support for Bandwidth Management ......................................................................... 105
Bandwidth Allocation and VPM Examples ......................................................................... 106
Policy Examples: CPL.............................................................................................................. 113
Chapter 6: Authenticating a ProxySG

Introduction..................................................................................................................................... 115
ProxySG Appliance Overview...................................................................................................... 115
Appliance Certificates and SSL Device Profiles ......................................................................... 116
About ProxySG Appliance Certificates................................................................................. 116
About SSL Device Profiles ...................................................................................................... 116
Obtaining a ProxySG Appliance Certificate ............................................................................... 117
Automatically Obtaining an Appliance Certificate............................................................. 118
Manually Obtaining an Appliance Certificate..................................................................... 119
Obtaining a Non Blue Coat Appliance Certificate..................................................................... 121
Creating an SSL Device Profile for Device Authentication ...................................................... 122
Related CLI Syntax to Manage Device Authentication............................................................. 124

v

Volume 5: Advanced Networking

Chapter 7: Configuring Failover

About Failover ................................................................................................................................ 125
Configuring Failover ...................................................................................................................... 126
Viewing Failover Statistics ............................................................................................................ 128
Troubleshooting.............................................................................................................................. 128
Chapter 8: Configuring the Upstream Network Environment
Section A: Overview
Section B: About Forwarding

About Load Balancing............................................................................................................. 133
About Host Affinity ................................................................................................................. 133
Using Load Balancing with Host Affinity ............................................................................ 134
Section C: Configuring Forwarding

Creating Forwarding Hosts and Groups .............................................................................. 136
Configuring Global Forwarding Defaults................................................................................... 139
Configuring the Default Sequence ............................................................................................... 140
Statistics............................................................................................................................................ 143
Section D: Using Forwarding Directives to Create an Installable List

Creating Forwarding Host and Group Directives ..................................................................... 145
Creating Forwarding Hosts .................................................................................................... 145
Creating Forwarding Groups Using Directives .................................................................. 146
Setting Special Parameters ............................................................................................................ 146
Setting Fail Open/Closed and Host Timeout Values ......................................................... 146
Configuring Load-Balancing Directives ............................................................................... 147
Configuring Host Affinity Directives.................................................................................... 148
Creating a Default Sequence ......................................................................................................... 148
Creating a Forwarding Installable List........................................................................................ 149
Chapter 9: Internet Caching Protocol (ICP) Configuration

About ICP Hierarchy ..................................................................................................................... 153
Using ICP Configuration Directives to Create an Installable List........................................... 154
Naming the IP Hosts ...................................................................................................................... 155
Restricting Access ........................................................................................................................... 156
Connecting to Other ICP Hosts .................................................................................................... 157
Creating an ICP Installable List .................................................................................................... 158
Enabling ICP.................................................................................................................................... 159
Chapter 10: Managing Routing Information Protocols (RIP)

Installing RIP Configuration Files................................................................................................ 161
Configuring Advertising Default Routes.................................................................................... 163
RIP Commands ............................................................................................................................... 163

vi

Contents

net ............................................................................................................................................... 163
host ............................................................................................................................................. 164
RIP Parameters................................................................................................................................ 164
ProxySG-Specific RIP Parameters ................................................................................................ 165
Using Passwords with RIP ............................................................................................................ 166
Chapter 11: Configuring the ProxySG as a Session Monitor

Configuring the Session Monitor ................................................................................................. 167
Configuring the RADIUS Accounting Protocol Parameters.............................................. 167
Configuring a Session Monitor Cluster ................................................................................ 168
Configuring the Session Monitor........................................................................................... 169
Creating the CPL............................................................................................................................. 170
Notes .......................................................................................................................................... 171
Chapter 12: Accelerating and Controlling Micro-Branch and Mobile User Connections (ProxyClient)
Section A: ProxyClient Concepts

Why Deploy ProxyClient?............................................................................................................. 174
Terminology .................................................................................................................................... 175
About Blue Coat in the Network.................................................................................................. 177
About the Roles of ProxySG Appliances With the ProxyClient .............................................. 178
About the Role of the ProxyClient ............................................................................................... 179
About ProxyClient Licensing........................................................................................................ 181
Software and Hardware Requirements....................................................................................... 182
About Location Awareness ........................................................................................................... 182
Overview of Location Awareness.......................................................................................... 182
About Location Conditions .................................................................................................... 183
About Condition Rulebase Ordering .................................................................................... 191
About ADN Feature Support in ProxyClient ............................................................................. 192
ADN Features ........................................................................................................................... 192
About Internet Gateways........................................................................................................ 193
About Reflecting the ProxyClient IP Address ..................................................................... 194
About ProxyClient Web Filtering................................................................................................. 196
Web Filtering Terminology .................................................................................................... 196
How Blue Coat Enforces Web Filtering for Remote and Micro-Branch Users ............... 197
Enabling or Disabling Web Filtering Based on Location ................................................... 198
About the BCWF Database and Categorization .................................................................. 201
About Security With Guest User Scenarios.......................................................................... 204
ProxyClient Security Disclaimers................................................................................................. 204
Section B: Configuring a ProxySG as the Client Manager

About ProxyClient Deployment................................................................................................... 205
Before You Begin Configuring the Client Manager ............................................................ 205

vii

Volume 5: Advanced Networking

ProxySG Administrator Configuration Tasks...................................................................... 206
Client Installation Tasks.......................................................................................................... 207
Preparing the ProxySG ADN Configuration for ProxyClient Deployment .......................... 207
About Manager Listening Mode............................................................................................ 208
About Tunnel Listening Mode ............................................................................................... 209
About Secure Outbound Mode .............................................................................................. 209
Designating a ProxySG as the Client Manager .......................................................................... 210
Before You Configure the Client Manager ........................................................................... 210
Designating the Client Manager ............................................................................................ 210
Uploading the ProxyClient Software to the Client Manager ................................................... 214
Section C: Configuring the ProxyClient

Accelerating Network Traffic ....................................................................................................... 216
Before You Begin Configuring ProxyClient Policy ............................................................. 216
Specifying the ProxyClient ADN Manager .......................................................................... 217
Tuning the ADN Configuration............................................................................................. 218
Enabling File Sharing Acceleration ....................................................................................... 221
Enabling ProxyClient Acceleration ....................................................................................... 223
Configuring ProxyClient Locations ............................................................................................. 225
Location Awareness Task Summary ..................................................................................... 225
Configuring Specific Locations .............................................................................................. 226
Ordering Locations in the Rulebase ...................................................................................... 229
Configuring Default Actions .................................................................................................. 230
Configuring ProxyClient Web Filtering ...................................................................................... 231
Web Filtering Task Summary................................................................................................. 231
Enabling Blue Coat Web Filtering ......................................................................................... 233
Enabling the Use of the Local Database (Optional) ............................................................ 236
Enabling ProxyClient Web Filtering ..................................................................................... 238
Assigning Policy Actions to Content Categories................................................................. 240
Web Filtering Best Practices ................................................................................................... 251
Displaying and Customizing Web Filtering Exception Pages........................................... 253
Enabling Web Filtering Logging............................................................................................ 256
Configuring the ProxyClient from the Command Line............................................................ 261
Setting the Client Manager (CLI)........................................................................................... 261
Configuring General ProxyClient Settings (CLI) ................................................................ 261
Configuring ProxyClient ADN Manager Settings (CLI) .................................................... 262
Configuring ProxyClient ADN Rules Settings (CLI) .......................................................... 262
Configuring ProxyClient Locations (CLI) ............................................................................ 262
Configuring ProxyClient File Sharing (CIFS) Settings (CLI) ............................................. 263
Configuring ProxyClient Web Filtering (CLI) ..................................................................... 264
Loading the Software (CLI) .................................................................................................... 264

viii

Contents

Showing ProxyClient Settings (CLI) ..................................................................................... 265
Section D: Distributing the ProxyClient Software

ProxyClient Compatibility with SGOS........................................................................................ 266
Overview of Distributing the ProxyClient Software ................................................................. 267
Preparing Interactive Installations ............................................................................................... 268
Preparing Silent Installations and Uninstallations .................................................................... 273
Parameters for Silent Installations ......................................................................................... 274
Command for Silent Uninstallations..................................................................................... 278
Example Installations and Uninstallations........................................................................... 279
Limiting ProxyClient Visibility and Interactivity................................................................ 281
Using Group Policy Object Distribution ..................................................................................... 285
Section E: About the ProxyClient Application

How Users Access the ProxyClient Application........................................................................ 288
About the Status Tab Page...................................................................................................... 289
About the Network Tab Page................................................................................................. 290
About the Advanced Tab Page .............................................................................................. 291
Section F: Monitoring ProxyClient Performance

Viewing History Statistics ............................................................................................................. 293
Viewing ProxyClient ADN History Statistics ............................................................................ 295
Viewing ProxyClient Active Session Statistics........................................................................... 296
Section G: About the ProxyClient System Footprint

Installation ....................................................................................................................................... 298
Folders ....................................................................................................................................... 298
Files ............................................................................................................................................ 299
Setup Executable ...................................................................................................................... 299
Setup MSI .................................................................................................................................. 299
During Runtime .............................................................................................................................. 302
Logging and Support............................................................................................................... 302
Acceleration Files ..................................................................................................................... 302
Web Filter Files ......................................................................................................................... 303
Data Collector ........................................................................................................................... 303
Removal ........................................................................................................................................... 303
Section H: ProxyClient Troubleshooting

About HTTPS Browser Proxies .................................................................................................... 304
Client Manager Logging................................................................................................................ 305
Client Connection Issues ............................................................................................................... 305
Acceleration Troubleshooting....................................................................................................... 306
About ADN Tunnels................................................................................................................ 306
Diagnosing the Concentrator ................................................................................................. 306

ix

Volume 5: Advanced Networking

Diagnosing the ProxyClient ................................................................................................... 307
Web Filtering Troubleshooting..................................................................................................... 307
Why Are Users Receiving Blocked or Warn Messages For No Justifiable Reason?....... 308
ProxyClient Web Filtering Licensing .................................................................................... 309
Disputing URL Categorization For ProxyClient ................................................................. 309
Advanced Troubleshooting........................................................................................................... 310
Changing the Client Manager....................................................................................................... 313
Limiting ProxyClient Visibility After Installation ..................................................................... 315
Performing Data Traces and Data Collection ............................................................................. 317
About ProxyClient Logs.......................................................................................................... 317
About the Data Collection Application ................................................................................ 318
Instructing Users to Perform Data Traces ............................................................................ 318
Instructing Users to Run the ProxyClient Data Collector .................................................. 319
Clearing the Cache.......................................................................................................................... 323
Changing the Location of the Cache ............................................................................................ 324
Uninstalling the ProxyClient Software........................................................................................ 325
Chapter 13: SOCKS Gateway Configuration
Section A: Configuring a SOCKS Gateway

Configuring Global SOCKS Defaults........................................................................................... 332
Configuring the Default Sequence ............................................................................................... 333
Statistics............................................................................................................................................ 336
Section B: Using SOCKS Gateways Directives with Installable Lists

Configuring SOCKS Gateways Using Directives ...................................................................... 338
Creating SOCKS Gateways Groups Using Directives .............................................................. 339
Setting Special Parameters ............................................................................................................ 339
Setting Fail Open/Closed ...................................................................................................... 339
Configuring Load Balancing Directives ............................................................................... 339
Configuring Host Affinity Directives.................................................................................... 340
Creating a Default Sequence ......................................................................................................... 341
Creating a SOCKS Gateway Installable List ............................................................................... 342
Chapter 14: Verifying the Health of Services Configured on the ProxySG
Section A: Overview

Background DNS Resolution ........................................................................................................ 347
Section B: About Blue Coat Health Check Components

Health Check Types................................................................................................................. 350
Health Check Tests .................................................................................................................. 351
Section C: Configuring Global Defaults

About Health Check Defaults ....................................................................................................... 355

x

Contents

Enabling and Disabling Health Checks ................................................................................ 355
Notifications and SNMP Traps .............................................................................................. 356
Changing Health Check Default Settings ................................................................................... 357
Configuring Health Check Notifications .................................................................................... 361
Section D: Forwarding Host and SOCKS Gateways Health Checks

Forwarding Hosts and SOCKS Gateways Configurations....................................................... 366
Forwarding Hosts Health Checks.......................................................................................... 366
SOCKS Gateways Health Checks .......................................................................................... 366
Forwarding and SOCKS Gateways Groups Health Checks .............................................. 366
Editing Forwarding and SOCKS Gateways Health Checks .............................................. 366
Section E: DNS Server Health Checks

Editing DNS Server Health Checks....................................................................................... 373
Section F: Authentication Health Checks
Section G: Virus Scanning and Content Filtering Health Checks
Section H: Managing User-Defined Health Checks

About User-Defined Host Health Checks................................................................................... 386
About User-Defined Composite Health Checks.................................................................. 387
Creating User-Defined Host and Composite Health Checks................................................... 388
Copying and Deleting User-Defined Health Checks ................................................................ 395
Section I: Viewing Health Check Statistics

About Health Check Statistics................................................................................................ 397
Interpreting Health Check Statistics...................................................................................... 400
Section J: Using Policy
Section K: Related CLI Syntax to Configure Health Checks
Chapter 15: TCP/IP Configuration

About the Options .......................................................................................................................... 405
RFC-1323 .......................................................................................................................................... 406
TCP NewReno................................................................................................................................. 406
ICMP Broadcast Echo Support ..................................................................................................... 406
ICMP Timestamp Echo Support................................................................................................... 406
TCP Window Size........................................................................................................................... 407
TCP Time Wait ................................................................................................................................ 408
TCP Loss Recovery Mode.............................................................................................................. 408
Viewing the TCP/IP Configuration............................................................................................. 408
Chapter 16: Virtual IP Addresses

Uses of a VIP.................................................................................................................................... 409
Creating a VIP ................................................................................................................................. 409

xi

Volume 5: Advanced Networking

Chapter 17: WCCP Settings

Configuring WCCP ........................................................................................................................ 411
Procedure Overview................................................................................................................ 411
WCCP Router Configuration ................................................................................................. 411
ProxySG Configuration ........................................................................................................... 412
Viewing WCCP Statistics and Service Group Status................................................................. 415
Viewing WCCP Settings ......................................................................................................... 415
Appendix A: Using Policy to Manage Forwarding
Glossary
Index

xii

Chapter 1: About Advanced Networking

Volume 5: Advanced Networking discusses networking tasks that are not required
in every environment, such as:


WAN Optimization, which enables you to optimize environments with
application delivery networks (ADNs).



TCP/IP settings.



Forwarding, which allows you to define the hosts and groups of hosts to
which client requests can be redirected.



Health Checks, which reports on the health of upstream hosts.

About This Book
This book is organized into the following chapters:


Chapter 2: "Configuring an Application Delivery Network" on page 17



Chapter 3: "Preventing Denial of Service Attacks" on page 79



Chapter 4: "TCP Connection Forwarding" on page 85



Chapter 5: "Bandwidth Management" on page 93



Chapter 6: "Authenticating a ProxySG" on page 115



Chapter 7: "Configuring Failover" on page 125



Chapter 8: "Configuring the Upstream Network Environment" on page
131



Chapter 9: "Internet Caching Protocol (ICP) Configuration" on page 153



Chapter 10: "Managing Routing Information Protocols (RIP)" on page 161



Chapter 11: "Configuring the ProxySG as a Session Monitor" on page 167



Chapter 12: "Accelerating and Controlling Micro-Branch and Mobile User
Connections (ProxyClient)" on page 173



Chapter 13: "SOCKS Gateway Configuration" on page 327



Chapter 14: "Verifying the Health of Services Configured on the ProxySG"
on page 345



Chapter 15: "TCP/IP Configuration" on page 405



Chapter 16: "Virtual IP Addresses" on page 409



Chapter 17: "WCCP Settings" on page 411



Appendix A: "Using Policy to Manage Forwarding" on page 419

13

Volume 5: Advanced Networking

Document Conventions
The following table lists the typographical and Command Line Interface (CLI)
syntax conventions used in this manual.
Table 1–1 Document Conventions

Conventions

Definition

Italics

The first use of a new or Blue Coat-proprietary term.

Courier font

Screen output. For example, command line text, file names, and
Blue Coat Content Policy Language (CPL).

Courier Italics

A command line variable that is to be substituted with a literal
name or value pertaining to the appropriate facet of your
network system.

Courier Boldface

A Blue Coat literal to be entered as shown.

Arial Boldface

Screen elements in the Management Console.

{ }

One of the parameters enclosed within the braces must be
supplied

[ ]

An optional parameter or parameters.

|

Either the parameter before or after the pipe character can or
must be selected, but not both.

Notes and Warnings
The following is provided for your information and to caution you against actions
that can result in data loss or personal injury:
Note: Information to which you should pay attention.

Important:

Critical information that is not related to equipment damage or
personal injury (for example, data loss).

WARNING! Used only to inform you of danger of personal injury or physical
damage to equipment. An example is a warning against electrostatic discharge
(ESD) when installing equipment.

About Procedures
Many of the procedures in this volume begin:


Select Configuration > TabName,

if you are working in the Management Console,

or


14

From the (config) prompt, if you are working in the command line interface (CLI).

Chapter 1: About Advanced Networking

Blue Coat assumes that you are logged into the first page of the Management
Console or entered into configuration mode in the CLI.

Illustrations
To save space, screen shots illustrating a procedure often have the bottom portion
removed, along with the blank space.

Figure 1–1

Configuration > General Tab with Bottom Buttons

Preview:



Click this button to view the configuration changes before applying
the configuration to the ProxySG. To modify your changes, click Close and
return to the the tab whose settings you want to modify.



Apply:



Revert:



Help: Click this button to view conceptual and procedural documentation
about the tab’s topic.

Click this button to apply unsaved configuration changes to the
ProxySG.
Click this button to revert any unapplied changes to the ProxySG
configuration. Changes that previously have been applied to the ProxySG are
not affected.

Figure 1–2

Configuration > General Tab with Bottom Buttons Removed

15

Volume 5: Advanced Networking

16

Chapter 2: Configuring an Application Delivery Network

This chapter discusses the Blue Coat implementation of an Application
Delivery Network (ADN), which optimizes traffic over the enterprise WAN.

Topics in this Chapter
This chapter includes information about the following topics:


Section A: "ADN Overview" on page 18



Section B: "About ADN Deployment, Compression, and Security Behavior"
on page 24.



Section C: "Basic ADN Setup" on page 30.



Section D: "Transparent and Explicit Connection Deployments" on page 34.



Section E: "Securing the ADN Network" on page 46.



Section F: "ADN Network History, Active Sessions, Byte-Caching Statistics,
and Health Metrics" on page 54.



Section G: "Advanced Tunnel Optimization" on page 60.



Section H: "Byte-Cache Dictionary Sizing" on page 64.



Section I: "Related CLI Syntax to Configure an ADN Network" on page 70.



Section J: "Policy" on page 72.

17

Volume 5: Advanced Networking

Section A: ADN Overview
Visibility is the key to achieving secure application performance while
maintaining control over users and content. Because proxies terminate
application traffic, they have a unique and native visibility into the application,
the user, and the content of the interaction.
The Blue Coat Application Delivery Network, or ADN, optimizes application
protocol traffic over the WAN by implementing Blue Coat MACH5 technology.
MACH5 refers to the following aspects of the Multiprotocol Accelerated Caching
Hierarchy.


Bandwidth Management—Adds a throttle or modulate option to possible
actions, which enables organizations to limit or guarantee bandwidth for
individual (or groups of) applications.



Protocol Optimization—Reduces the effects of latency for common protocols
that were not initially designed to operate efficiently across WAN links by
employing object pipelining, local authentication, and DNS caching.



Object Caching—Reduces latency and bandwidth by caching and serving
application data locally and supporting various pre-placing of commonlyrequested content.



Byte Caching—Reduces transmitted data at the packet level by replacing large
chunks of TCP data with smaller tokens that represent that data.



Compression—Reduces transmitted data through various other compression
technology, such as GZIP, caching compressed and uncompressed objects, and
HTTP and point-to-point compression.

The MACH5 optimization techniques complement each other to provide a multilayered approach to application acceleration. As the five layers are governed by
granular policy, organizations can apply acceleration techniques best suited to
particular applications. Blue Coat ProxySG appliances located at key points in the
network allow IT personnel to intercept and control all TCP (and UDP for
streaming) traffic that is sent over the WAN, such as:


Web (HTTP)



File sharing services (CIFS)



Microsoft Outlook/Exchange (MAPI)



Secure Web (SSL)



Generic TCP



DNS



Live and on-demand streaming (RTSP, MMS, and streaming over HTTP)

An ADN defines the physical network that enables application acceleration
between various corporate offices separated by WAN links with limited
bandwidth. An ADN consists of ProxySG appliances that are easily integrated
into the network and provide acceleration and control. An ADN Manager

18

Chapter 2: Configuring an Application Delivery Network
Section A: ADN Overview

ProxySG located at the corporate location controls and manages other ProxySG
appliances—called peers—that perform the ADN tasks. These peers are located at
branch office and corporate data center locations. A branch office peer compresses
data before sending it to its data center peer, but before accepting traffic from a
peer, each ProxySG must verify that the peer is a valid member of the ADN.
The following diagram illustrates a high-level ADN deployment.

When deployed together at various network points, these elements function
together to form an ADN.

About the Application Delivery Network Elements
An ADN requires a minimum of two ProxySG appliances: one at the core (or
enterprise data center location) and one at a branch location. Most deployments,
however, require additional ProxySG appliances to accommodate the volume of
enterprise users and various locations.
To create an ADN, you configure ProxySG appliances to serve in various roles in
the ADN network. Any ProxySG can be configured to be an ADN Manager,
branch peer or concentrator peer, based on its location in the network and
connectivity to servers.
The following table describes the ADN roles of ProxySG appliances deployed at
various points on the network.

19

Volume 5: Advanced Networking
Section A: ADN Overview
Table 2–1 ADN Elements and Network Locations

ProxySG

ADN Role
ADN Manager—Every ADN must have an ADN manager. This device
performs the following functions:

• Responsible for the authentication and authorization of peers.
• In explicit ADN deployments, the ADN Manager Publishes the routing
table to all ADN peers.
• In transparent ADN deployments, peers discover each other as packets are
routed through the ADN (router redirection).
Although Blue Coat recommends that the ADN Manager not participate as
an ADN peer, this is an acceptable deployment if you have correctly sized the
ProxySG appliances.
Backup ADN Manager—Blue Coat recommends configuring a second
ProxySG as a backup ADN manager. If a peer in the ADN detects that the
primary ADN manager is not available (determined by keep alive messages),
the peer switches to the backup ADN manager. When the primary ADN
manager resumes responding to the peer, the active routing connection
returns to the primary ADN manager.
Concentrator Peer—ProxySG appliances deployed as concentrators reside in
the data center and connect to a WAN router. Larger enterprises with
multiple data centers deploy a concentrator in each data center. They can be
also be deployed in clusters for load balancing and failover. Concentrator
peers terminate the ADN tunnels, decompress the traffic, and forward the
uncompressed data to the application server; the application data is then
compressed and returned over the WAN to the requesting client by way of
the branch peer.
Branch Peer—A ProxySG deployed near the gateway of each remote location

(small or regional offices) that contains a centrally-managed router or where
there is private IP connectivity through Multi Protocol Label Switching
(MPLS), satellite, or point-to-point network. To retrieve client file and data
requests from application servers located in the corporate data center, the
branch proxy connects to the ADN concentrators—which are advertised by
the ADN Managers or discovered transparently—in the data centers at the
corporate location.
If the branch location has servers, the branch peer also serves as a
concentrator.
ADN peers build byte caches and strive to maintain connections with the
same peers in the network to take advantage of established byte caches. This
is known as host affinity.

20

Chapter 2: Configuring an Application Delivery Network
Section A: ADN Overview
Table 2–1 ADN Elements and Network Locations

ProxySG

ADN Role
Client Manager/ProxyClient—For mobile users and remote deployments
(such as a micro-branch or home office) where users connect directly to the
Internet through a corporate-controlled VPN, Blue Coat offers the
ProxyClient solution. When installed on user systems, ProxyClient mimics a
small ProxySG appliance and provides ADN optimization and Web content
filtering. A Client Manager is a ProxySG on the ADN that provides
monitoring and software and configuration updates. Like all peers in the
ADN, the ProxyClient application connects to the ADN Manager and obtains
the advertised routes from the ADN Manager.

The Client Manager can be the same ProxySG as the ADN Manager; a
separate device is not required.
Note: The ProxyClient component is outside the scope of this document.
Chapter 12: Accelerating and Controlling Micro-branch and Mobile Connections
(ProxyClient) in Volume 5: Advanced Networking of the SGOS Configuration
and Management Suite provides full conceptual and implementation
information.

Example
The following series of diagrams illustrate the principal functionality of an
explicit ADN (transparent ADN performs the same conceptually). Through
compression and object caching technologies, the ADN solution reduces WAN
network traffic and improves the user experience.

The ADN peers advertise their availability to the ADN Manager (denoted by the shield symbol).

21

Volume 5: Advanced Networking
Section A: ADN Overview

User Jeff requests a PowerPoint presentation from a file share named ExampleCorpPresentations
on a server located at the corporate location. As this application is determined by policy to be
mission-critical, the connection receives maximum allowed WAN bandwidth. The concentrator
compresses the data and routes it back to over the WAN and through the branch ProxySG, where
the content is decompressed, cached, and sent to Jeff’s system.
Jeff changes the content on two slides and saves the file. When Jeff saves the file, the data is
transmitted from Jeff's system to the branch ProxySG, which caches the new file, compresses the
data, and sends only the changed data from the two modified slides over the WAN. The
Concentrator decompresses the data and sends the updated file to the server.

An hour later, user Bob requests the same Powerpoint presentation. The branch ADN peer serves
the updated file from the object cache.

22

Chapter 2: Configuring an Application Delivery Network
Section A: ADN Overview

1: At the corporate campus, Maya retrieves the file from the ExampleCorpPresentations share and
modifies some content.
2: Jeff requests the file again. This time, the branch peer registers a partial cache hit, as most of
object data in the byte cache unchanged. A check to the concentrator peer indicates new object
data (Maya’s changes). Only the new content is retrieved over the WAN.

Before deploying and configuring ProxySG appliances in your enterprise to form
an ADN, you must understand your network topography and select a supported
deployment type.

23

Volume 5: Advanced Networking
Section B: About ADN Deployment, Compression, and Security Behavior

Section B: About ADN Deployment, Compression, and Security
Behavior
This section provides conceptual information regarding various deployments that
employ WAN optimization.
Blue Coat recommends that you review this section for a high-level overview of
the Blue Coat ADN implementation.
This section contains discussions on:


"Selecting the Correct Deployment" on page 24.



"About ADN Compression" on page 27.



"ADN Security" on page 28.

Selecting the Correct Deployment
You must decide if the network should use explicit tunnel connections,
transparent connections, or a combination of both. Note that ADN peers always
intercept incoming transparent connections if ADN is enabled.

24



Transparent: The branch ProxySG connects to the original server destination
address and port. If an upstream proxy is capable of transparent tunneling,
the downstream proxy transfers data over the ADN tunnel. The destination
port is preserved and is not affected by security being enabled. Skip to
"Transparent Connections" for more information.



Explicit: The branch ProxySG connection is established to the ADN peer
discovered from the routing lookup table. The connection is established to the
tunnel listening port by default or, if you are preserving the destination port,
to the port number the application specifies. Skip to "Explicit Connections" on
page 26 for more information.



Combination: In some circumstances, some ADN peers can connect
transparently, while other peers require explicit routing. Skip to "Combination
of Transparent/Explicit Connections" on page 27.

Chapter 2: Configuring an Application Delivery Network
Section B: About ADN Deployment, Compression, and Security Behavior

Transparent Connections
Transparent connections are used when the network is required to see the original
destination IP addresses and ports. This requires that each peer be configured as
an ADN peer and deployed in inline mode or virtual inline mode.
Note: Beyond setting up an ADN peer in an in-line network and configuring

the ADN peer to point to the ADN manager and backup manager, no
additional effort is required for transparent connections. If you use explicit
connections, those connections must be explicitly configured.
Transparent connections take advantage of ADN tunnels that maintain layer-4
information from the original application connections. Layer-4 information
provides an administrator more granular control of the ADN network and allows
the enforcement of network policy.
In a transparent connection deployment, connections are not established to a
particular peer in the ADN, as they are in an explicit deployment. An ADN peer
can establish connections to its peers automatically in the absence of any ADN
routing information.
The reject-inbound per interface setting is honored for transparent tunnel
interception, while the allow-intercept setting is ignored for transparent tunnel
interception.
Internet-bound traffic is automatically accelerated in a transparent deployment if
a transparent ADN peer is installed at the internet access point and Internet traffic
is routed correctly.

Transparent Deployment Load Balancing Scenarios
In transparent load balancing, routes are not advertised, and configuration of load
balancing must be done on each peer in the ADN cluster.
If you are using a transparent deployment, you have two options for load
balancing.


A dedicated ProxySG appliance as a load balancer; that system makes the
decision about which peer receives which traffic.



A WCCP router or other external load balancer, where the individual peers in
the ADN cluster make the informed load balancing decision.

25

Volume 5: Advanced Networking
Section B: About ADN Deployment, Compression, and Security Behavior

Explicit Connections
Explicit connections are used when maximum network control and granularity is
needed.
Blue Coat supports two explicit connections deployments: explicit or explicit but
preserving the destination port. In the latter case, the destination port used is the
original destination port from the client’s request, such as port 80 for HTTP. The
destination port is not affected by the connection setting.
In both explicit deployments, the server subnets that are fronted by each peer
must be explicitly configured; the server subnets are then advertised to each ADN
peer.
To accelerate Internet traffic in an explicit ADN network, set up a specific ADN
peer as the Internet gateway. Typically, the Internet gateway is an ADN peer close
to the enterprise’s Internet access point.
Note: If multiple Internet gateways are available, each peer has its own preferred
Internet gateway to route all Internet subnets.

When an ADN peer is configured as an Internet gateway, all other ADN peers
forward the Internet traffic to this peer. The following logic is used by an ADN
peer to determine if the connection is destined to the Internet:


If the destination address matches an advertised subnet from any of the ADN
peers, the connection is forwarded to that peer over the ADN tunnel.



If the destination address matches one of the exempted subnets, the
connection is not forwarded over the ADN tunnel.



If the destination address does not match an advertised subnet or an
exempted subnet, the connection is forwarded to an ADN peer that is
designated as an Internet gateway.

Explicit Deployment Load Balancing Scenarios
If you use explicit network connections, you have two options when configuring
load balancing:

26



A server subnet, where the branch ProxySG makes the decision about the peer
receiving specific traffic for a destination subnet. This is the easiest and more
preferred method. For more information, see"Using a Server Subnet" on page
41.



An external load balancer, where that system makes the informed decision
about which peer in the ADN cluster receives specific traffic. For more
information, see "Using an External Load Balancer" on page 42.

Chapter 2: Configuring an Application Delivery Network
Section B: About ADN Deployment, Compression, and Security Behavior

Combination of Transparent/Explicit Connections
In some circumstances, it necessary to use explicit connections in addition to the
much easier and preferred transparent connection deployment. A transparent
network that can advertise explicit routing connections is supported. This
configuration is useful:


When a small branch office is using the ProxyClient, which allows SGOS
functionality when a ProxySG is not on site.



If some peers are not in an in-line configuration or are incapable of initiating
transparent connections.

By default, if an ADN peer is advertising routes, explicit connections are made. If
no explicit routes are found and there is an upstream proxy in the path capable of
transparent tunneling, the connection is intercepted. This preference is
configurable.

Choosing Which Traffic to Optimize
When you configure proxy services to manage TCP traffic through the ADN
network, you can set various attributes that can optimize the traffic for the
network. A specific attribute, use ADN, allows you to disable ADN for a given
service.
For information on using proxy services, including the services available, refer to
Volume 2: Proxies and Proxy Services.

About ADN Compression
ADN compression enables organizations to fully extract every performance
benefit available when sending data through an ADN tunnel between ProxySG
appliances. ADN tunnels require that ProxySG appliances on opposite sides of
the WAN be members of the same ADN network and that the upstream ProxySG
appliance either be advertising routes to servers to be accessed by appliances on
the opposite side of the WAN or be deployed inline so that transparent ADN
tunnels can be used.
Traffic accelerated between clients and servers is automatically compressed before
being sent through the ADN tunnel, decreasing bandwidth usage and optimizing
response time. ADN compression is often used in conjunction with byte caching
and object caching to achieve optimum results. In the case of byte caching and
compression, byte caching is first applied to the data and then the resulting data is
compressed. Both features are enabled by default to optimize ADN directed
traffic. ADN compression for any arbitrary protocol can also be configured on the
ProxySG using policy; it can also be controlled separately for both inbound and
outbound traffic on the WAN.
For more information on byte caching, see Section H: "Byte-Cache Dictionary
Sizing" on page 64.

27

Volume 5: Advanced Networking
Section B: About ADN Deployment, Compression, and Security Behavior

ADN Security
ADN networks can and should be secured. You can limit access by:


Authenticating and authorizing the ADN peers that are allowed on the
network and prevent unauthorized peers from participating.



Securing ADN connections.

Authenticating and Authorizing ADN Peers
By default, authentication and authorization are disabled.

ADN Peer Authentication
Secure ADN requires an appliance certificate for each ADN peer, including the
ADN manager and backup manager for identification. You can provide your own
device appliance certificates or obtain Blue Coat-issued appliance certificates from
the Blue Coat CA server. For the most secure environment, Blue Coat-issued
appliance certificates are recommended.
To enable secure ADN, you must enable the appliance authentication profile for
the ADN network to use before configuring any other security parameters.
In secure ADN mode, full mutual authentication can be supported between the
ADN manager and the ADN peers and among ADN communicating peers. If
authorization is enabled on the ADN manager, the peer proxy is authorized
through an approval mechanism by the ADN manager before joining the
network. For more information on managing appliance certificates, see
Chapter 6: "Authenticating a ProxySG".

ADN Peer Authorization
Authorization occurs when the ADN manager gives approval for the device to
join the network.
If the profile, authentication, and authorization are configured on each peer, and
the Pending Peers option is enabled on both the ADN manager and the backup
ADN manager (if one is configured), the following behavior takes place
automatically:

28



When an ADN peer comes up, it contacts the ADN manager for routing
information.



The ADN manager extracts the device ID from the connecting ADN peer's
appliance certificate and looks for the device ID in its approved list of ADN
peers.


If the device is on the approved list, a REQUEST-APPROVED response is sent,
followed by the route information, and the peer joins the network.



If the device is not on the approved list, the ADN manager adds the
connecting peer's device ID to a pending-peers list and sends a REQUESTPENDING response. After the peer is moved to the Approved list by the
administrator, a REQUEST-APPROVED response is sent, followed by the route
information, and the peer joins the network.

Chapter 2: Configuring an Application Delivery Network
Section B: About ADN Deployment, Compression, and Security Behavior





If the Pending Peers option is not enabled and a peer is not on the approved
list, the ADN manager sends a REQUEST-DENIED response and closes the
connection. The connecting peer closes the connection and updates its
connection status.
If a peer is deleted from the approved list, the ADN manager broadcasts a
to all peers to delete this peer and terminate any existing
ADN connections to it. No new connections are routed through the
deleted ADN peer.

REJECT-PEER

For information on configuring authentication and authorization on each ADN
peer, see "Configuring ADN Security Settings" on page 47.

Securing ADN Connections
By default, ADN routing and tunnel connection requests are unauthenticated and
all ADN protocol messaging and compressed application data are transferred in
plaintext. For maximum security, you can configure the ADN network to secure
ADN routing and tunnel connections using standard SSL protocol, which
provides authentication, message privacy, and message authenticity security
services, regardless of the application traffic that is being accelerated or tunneled.
In secure ADN mode, you can specify that the ADN manager and tunnel use
secure mode to listen for routing and tunnel requests.
When secure ADN is enabled, any existing plain outbound connections are
dynamically secured by activating SSL according to the secure-outbound setting.
For information on optimizing and securing ADN tunnels, see Section E:
"Securing the ADN Network" on page 46 and Section G: "Advanced Tunnel
Optimization" on page 60.

29

Volume 5: Advanced Networking
Section C: Basic ADN Setup

Section C: Basic ADN Setup
Basic ADN setup includes:


Configuring each peer in an in-line deployment; if you are configuring an
explicit deployment, you do not need to configure the network in an in-line
deployment.



Plugging each peer in.



Enabling the ADN manager and backup manager on each peer, starting with
the ADN manager and backup manager themselves.

If you are using a transparent connection deployment without load balancing,
ADN configuration is complete at this point.
If you are using an explicit connection deployment, a transparent connection
deployment with load balancing, or if you are securing the ADN network (highly
recommended), after finishing this section you must continue with:


"Explicit Load Balancing" on page 41, for explicit deployment.



"Transparent Load Balancing" on page 35, for transparent deployment.



Section E: "Securing the ADN Network" on page 46.

About the ADN Manager
The ADN manager keeps track of and advertises the routes of the appliances it
knows about. The ADN manager must be one of the peers in the ADN
optimization network.
A backup ADN manager (optional, but recommended) can also be configured.
The ADN managers and the registered peers periodically send keep-alive
messages to each other. If a peer detects the primary ADN manager is not
responding, the peer automatically fails over to the back-up ADN manager. The
peer repeatedly attempts to restore its connection with the primary manager.
After the primary ADN manager is responding to the peer again, the active
routing connection of this peer switches back to the primary manager.
If the ADN manager detects a peer is not responding, the ADN manager removes
the peer from the database and notifies all other peers in the network to do the
same.
If both the ADN manager and the backup ADN manager are unavailable, no
further routing advertisements are broadcast. In this case, routes already known
by the peers continue to be remembered and used.
You also can use the ADN manager and backup manager to authorize which
peers are allowed to advertise or retrieve route information to and from the ADN
manager, and whether plain connection requests to the ADN manager are
accepted.

30

Chapter 2: Configuring an Application Delivery Network
Section C: Basic ADN Setup

ADN Connection Behavior for ADN Managers
Connections to the ADN manager and backup manager are made at startup and
kept open as long as ADN is enabled. These connections are referred to as routing
connections, and are used to advertise configured server subnets and to receive
routing table updates from the ADN manager.
Note: Even if you use a transparent tunnel deployment where ADN peers do not

require routing information, you must configure each ADN peer and register it
with the ADN manager. If you secure the network (highly recommended), the
ADN manager is used to authorize ADN peers before they join the network.
Whenever the ADN manager receives a new advertisement from a peer that is
joining the network, a route update is sent to all the appliances in the ADN
optimization network that have already established a routing connection; in
addition, the current routing table is updated. The ADN manager and backup
manager can each listen on two ports: one accepting the default plain (unsecured)
routing connection requests and another accepting secure routing connection
requests. The plain listener can be shut down if routing connections from all ADN
peers are secured.
When ProxySG connects to the primary ADN manager, subnet information is sent
to the manager, including:


Peer ID: The serial number of the device. This is a globally unique identifier
for the peer ProxySG that is used as a key to select the dictionary of tokens to
use.



Data IP Address and Port: The destination IP address and port number that a
branch proxy should use when establishing an explicit (non preserve-destport) tunnel connection.



Server Subnet Advertisements: The list of server subnets the ProxySG
contains are sent to the ADN manager.

31

Chapter 2: Configuring an Application Delivery Network
Section C: Basic ADN Setup

Verification


If the ADN managers connect successfully, the procedure worked.



If the ADN managers did not connect successfully, make sure:


Both systems are turned on.



Both systems are running the same version of SGOS.



Both systems are using the same device profile.



The ADN backup manager was approved by the ADN manager to join the
ADN network (Configuration > ADN > Manager > Pending Peers).

33

Volume 5: Advanced Networking
Section D: Transparent and Explicit Connection Deployments

Section D: Transparent and Explicit Connection Deployments
If you are configuring a transparent connection deployment without load
balancing, remember that ADN peers always intercept incoming transparent
connections if ADN is enabled. No special configuration is required after basic
ADN configuration is completed unless you use transparent connection load
balancing or if you need to configure a combined (explicit and transparent)
connection network.
The basic steps for configuring a combined transparent/explicit deployment or a
pure explicit deployment are:


Connect the peers in in-line mode or virtual in-line mode only for those peers
that are using transparent connections.



(Optional) Secure the ADN network:





Configure the ADN peers for ADN authentication and authorization for
maximum security (see "Configuring ADN Security Settings" on page 47).
The settings on each system should be identical.



Configure secure tunnels (see Section G: "Advanced Tunnel Optimization"
on page 60).

(Optional) Configure the load balancing parameters for each peer to be used
in load balancing (see "Explicit Load Balancing" on page 41 or "Transparent
Load Balancing" on page 35).

To configure transparent connections, including transparent connection load
balancing, continue with the next section.
To configure explicit connections, including explicit connection load balancing,
see "Configuring an Explicit Deployment" on page 38.
To configure a combined connection deployment, skip to "Configuring a
Combined (Transparent and Explicit) Deployment" on page 44.

Configuring a Transparent Deployment
After you have completed basic ADN configuration, transparent connections are
made automatically. No further configuration is required, unless you need to
configure transparent load balancing.

Transparent Deployment Notes

34



The first proxy in the chain that supports transparent tunnels and is on the
same ADN network intercepts ADN transparent tunnel connections.



In transparent load balancing, routes are not advertised, and configuration of
load balancing must be done on each peer in the ADN cluster.



Transparent load balancing relies on connection forwarding clusters for
proper operation. All peers in an ADN load balancing group must be part of
the same connection forwarding cluster.

Chapter 2: Configuring an Application Delivery Network
Section D: Transparent and Explicit Connection Deployments


In the context of ADN, connection forwarding relates to how to a ProxySG
handles the first packet of a request. A decision is made on the first packet
about which ADN peer is best to process that request, and subsequently that
request is forwarded to that ADN peer from start to finish. If connection
forwarding is not set up correctly, load balancing fails. For information on
connection forwarding, see Chapter 4: "TCP Connection Forwarding".

Transparent Load Balancing
In transparent load balancing, routes are not advertised, and configuration of load
balancing must be done on each peer in the ADN cluster.
If you are using a transparent deployment, you have two options for load
balancing.


A dedicated ProxySG appliance as a load balancer; that system makes the
informed decision about which peer receives which traffic.



A WCCP router or other external load balancer, where the individual peers in
the ADN cluster make the informed load balancing decision.

Using the ProxySG as a Load Balancer
When a Blue Coat appliance is used as the external load balancer, it makes the
decisions about which traffic is directed to which peer.

To configure transparent load balancing with a dedicated Blue Coat appliance as
the decision maker:

35

Volume 5: Advanced Networking
Section D: Transparent and Explicit Connection Deployments


Deploy the load-balancing ProxySG in-line so that it can transparently
intercept all traffic.



Enable load balancing on all peers by going to Configuration > ADN > Tunneling >
Load Balancing, and selecting the Enable Load Balancing checkbox.



(Optional) Configure each box in the cluster with the same load-balancing
group name.



On the Blue Coat appliance that’s acting as the dedicated load balancer, select
Act as load balancer only through the Configuration > ADN >Tunneling > Load
Balancing tab.



Put all ADN peers into a connection forwarding cluster. For more information,
see Chapter 4: "TCP Connection Forwarding" on page 85.

Note: For load balancing purposes, o special configuration is required for client
IP address reflection beyond standard configuration. The standard configuration
is to enable reflect-client-ip on the branch ProxySG and to set the concentrator
ProxySG to allow client-ip reflection under ADN tunneling.

Using a WCCP Router or L4 Switch as a Load Balancer
Using a WCCP router or L4 switch as a transparent load balancer is similar to
using a ProxySG as a transparent load balancer, except that WCCP router or L4
switch must be configured on each system in the cluster. In this scenario, the
router or switch cannot guarantee ADN peer affinity because the router cannot
use the peer ID as input for its hash. Because of this, the ADN peers make the
actual informed routing decisions.

36

Chapter 2: Configuring an Application Delivery Network
Section D: Transparent and Explicit Connection Deployments

To configure transparent load balancing with the peers in the ADN cluster as the
decision makers:


Enable load balancing on all peers by going to Configuration > ADN > Tunneling >
Load Balancing, and selecting the Enable Load Balancing checkbox.



(Optional) Set the same group name on all of the peers in the cluster.



Put all ADN peers into a forwarding connection cluster. For more information,
see Chapter 4: "TCP Connection Forwarding" on page 85.



Configure WCCP settings on all peers. For more information, see Chapter 17:
"WCCP Settings" on page 411.



Configure WCCP router settings. Review the vendor’s documentation for
information.

37

Volume 5: Advanced Networking
Section D: Transparent and Explicit Connection Deployments

Note: If client IP address reflection is needed, you must configure WCCP so
that both traffic from the Branch Appliance to the Origin Content Server and
traffic from the Origin Content Server to the Branch Appliance is redirected
through WCCP. This requires configuring WCCP on multiple interfaces on
your router, or configuring "in/out" rules. If specific ports are desired (rather
than all ports), you must configure both source-port and destination-port
rules in two different service groups.

See Also


"WCCP Settings"



Chapter 2, “Services,” in Volume 2: Proxies and Proxy Services

Configuring an Explicit Deployment
Complete the following steps to configure an explicit deployment:


Configure server subnets on each peer and enable an Internet gateway (see
"Managing Server Subnets and Enabling an Internet Gateway" ).



(Optional) Preserve the destination port (see "Preserving the Destination Port"
on page 41).



Configure explicit load balancing (see "Explicit Load Balancing" on page 41)

Managing Server Subnets and Enabling an Internet Gateway
The server subnets you create here are advertised by this peer upon joining the
explicit ADN network. You can also enable the peer as an Internet gateway. In
addition, subnets not intended to go over ADN tunnels or to be routed to Internet
gateways can be configured as exempt subnets.
Note: You can also configure the exempt subnet capability through policy that
allows you to disable ADN tunnel for specific connections. For more
information, refer to Volume 10: Content Policy Language Guide.

To create server subnets for this peer:

1. Select Configuration > ADN > Routing > Server Subnets.

38

Chapter 2: Configuring an Application Delivery Network
Section D: Transparent and Explicit Connection Deployments

Preserving the Destination Port
Complete the following procedure.
To preserve the destination port:

1. Select Configuration > ADN > Tunneling > Connection.

2. Select the When a route is available, preserve the destination TCP port number when
connecting to the ADN peer option.

Explicit Load Balancing
Of the two explicit load balancing types, server subnet or external load balancer,
the server subnet is the preferred and easiest to use. While the server subnets
must be configured, no additional load balancing settings must be made, and the
ADN peers explicitly advertise their own IP addresses.

Using a Server Subnet
If you use an explicit deployment, or if you just want to load balance traffic
destined to a specific subnet, configure the subnet as a server subnet on each
ADN peer within that group.
To forward the connection destined to the load balanced subnet, each ADN peer
selects the preferred peer from the list of all peers fronting that subnet. This is
done by ranking the list of all peers fronting a given subnet from highest to
lowest. The peer with the highest rank is chosen to route the client traffic for that
subnet.
Note: Load balancing is based on a hashing function, meaning that load
balancing distribution is approximate, tending to be more evenly distributed
with larger numbers of devices. Also, no allowance is made for equalizing load
among different-sized hardware in the same ADN cluster.

41

Volume 5: Advanced Networking
Section D: Transparent and Explicit Connection Deployments

Using an External Load Balancer
If you use explicit deployments, you can rely upon an external load-balancer
fronting a group of ADN peers. The load balancer is configured to distribute the
load among the peers that it fronts using client/IP address affinity.
The external load balancer provides more control than the server subnet, but it
requires more configuration. For example, you must create an external VIP
address on the Configuration > ADN > Tunneling > Load Balancing tab on each system in
the ADN cluster; the VIP address is explicitly advertised by the ADN manager.
Both server subnet and external load balancer use a cluster of ADN peers for load
balancing. The cluster is formed by ADN peers that are configured to the same
ADN manager and are advertising the same server subnets.

42

Chapter 2: Configuring an Application Delivery Network
Section D: Transparent and Explicit Connection Deployments

Whether you are using server subnets or an external load balancer, you must
configure server subnets. If you are using an external load balancer, you must also
configure the external load balancer with a VIP address and put the address in the
Load Balancing tab. Continue with the next procedures to configure explicit load
balancing.

Explicit Load Balancing Procedures
If you want to use either the server subnet load balancing deployment or the
external load balancing deployment, you must configure server subnets. If you
are using the external load balancing deployment, you must also configure the
external load balancer with a VIP address.
To configure server subnets:

1. Go to Select Configuration > ADN > Routing.
2. Click Add.
3. Add the IP/Subnet route to be advertised by the ADN manager; click OK.
4. (Optional) Repeat for additional routes.
For detailed information about configuring server subnets, see "Managing Server
Subnets and Enabling an Internet Gateway" on page 38.

43

Volume 5: Advanced Networking
Section D: Transparent and Explicit Connection Deployments
To configure VIP addresses:

1. Select Configuration > ADN > Tunneling > Load Balancing.
2. Enter the VIP address of the external load balancer.
Note: The VIP address is added from the Load Balancing tab of the App

Delivery Network menu, not the Advanced tab of the Network menu.
3. Click Apply.
The address must be entered on each ADN peer in the cluster.

See Also


"Virtual IP Addresses"

Configuring a Combined (Transparent and Explicit) Deployment
If you set up a transparent ADN network with no explicit connections, no
additional configuration is required for transparent tunnel connections to work
unless you want to configure load balancing. To configure transparent load
balancing, skip to "Setting Device Security" on page 47.
If you set up a combined ADN network with both explicit and transparent
connections, you must:


Configure the explicit routes you need (see "Managing Server Subnets and
Enabling an Internet Gateway" on page 38).



Configure the routing preference for each ADN peer to tell ADN peers to
prefer transparent connections (see "To configure the routing preference:" ).
The default is to always use advertised, explicit, routes.



Set the manager listening mode to Plain read-only mode if ProxyClients are in
the network (see "To configure ADN manager and tunnel listening mode and
ports:" on page 50.



Configure transparent or explicit load balancing, if necessary. For more
information, see "Transparent Load Balancing" on page 35 or "Explicit Load
Balancing" on page 41.

To configure the routing preference:

1. Select Configuration > ADN > Routing > Advanced.

2. Select the Tell ADN peers to prefer transparent connections over advertised routes
option.

44

Chapter 2: Configuring an Application Delivery Network
Section D: Transparent and Explicit Connection Deployments

See Also


Chapter 2, “Adapters,” in Volume 1: Getting Started



Appendix B, “Explicit and Transparent Proxy,” in Volume 1: Getting Started

45

Volume 5: Advanced Networking
Section E: Securing the ADN Network

Section E: Securing the ADN Network
Depending on your environment, you might need to secure your ADN network
to provide the following services:


Host validation: Securing the ADN network allows you to be sure that the
ADN peers are talking to the right devices and that the peer is authorized to
join the ADN network.



Privacy: Privacy can be an issue, especially for tunnels that carry application
data. You can configure the ADN network to secure ADN routing and tunnel
connections using standard SSL protocol. SSL tunnels provide authentication,
message privacy, and message authenticity security services, regardless of the
application traffic that is being accelerated or tunneled.



Message authenticity: Ensure that messages sent over ADN connections are
not altered. Messages include the route information sent over the routing
connections and compressed application data sent over the tunnel
connections.

Secure ADN implementation includes:


Device authentication, managed through the device authentication profile.



Securing the device, including device authentication profile selection and
device ID-based peer authorization.



Securing the connections, both inbound and outbound connection security
control.



Configuring the SSL proxy.
Note: If you only want secure routing connections to the ADN manager, an

SSL license is not required. Secure tunnel connections for applications such as
CIFS, MAPI, TCP Tunnel, HTTP, or HTTPS/SSL, are dependent upon an SSL
license.

46

Chapter 2: Configuring an Application Delivery Network
Section E: Securing the ADN Network

Configuring ADN Security Settings
For information on setting device security, continue with the next section. For
information on setting connection security, continue with "Securing Connections"
on page 49.

Setting Device Security
For maximum security, configure the ADN network for both device
authentication and device authorization. Device authentication must be
configured first.
Note: If the device being configured for authentication has Internet access,

acquisition of the ProxySG appliance certificate is automatic. If you use your own
appliance certificates and profile, or if the affected device does not have Internet
access, manual device authentication is required.
For information on configuring device authentication, see Chapter 6:
"Authenticating a ProxySG".
After the device authentication has been set up, point the ADN manager and
ADN backup manager to the profile that is being used for authentication. Then
enable authorization for maximum security.
Note: You cannot enable device authorization before configuring the ADN
manager and backup ADN manager. You can, however, configure the ADN
manager and backup ADN manager and then, without pressing Apply, enable
device authorization. Then press Apply to save both tabs.
To set device security:

1. Select Configuration > ADN > General > Device Security.

47

Chapter 2: Configuring an Application Delivery Network
Section E: Securing the ADN Network

Securing Connections
Use the Connection Security tab to set:


Manager and Tunnel Listening Mode



Secure Outbound Connections

Listening Mode Options
In secure ADN mode, you can specify that the ADN manager and tunnel use
secure mode to listen for routing and tunnel requests. By default, ADN routing
and tunnel connection requests are unauthenticated and all ADN protocol
messaging and compressed application data are transferred in plain text.
You must enable the device authentication profile before setting any other
security parameters.
After the profile is configured, the following security modes are automatically set:


Secure-outbound: (Secure Proxies)

Both outbound routing and secure proxy
connections are secured. You can also select the radio button to:


Not secure ADN connections.



Secure only ADN routing connections.



Secure all ADN and routing connections.

Note: The secure-outbound feature is dependent upon an SSL license.




Manager-listening-mode:

(Both) Listen for requests on two ports: plain and
secure. If your deployment requires a different ADN manager listening mode,
you must explicitly configure it. Other options available are:


Secure Only.



Plain Only.



Plain Read-Only. Use this mode if SG Client is deployed in your ADN
network. Currently, SG Client does not support secure ADN.

Tunnel-listening-mode: (Both)

Listen for requests on two ports: plain and secure.

Other options are:


Secure Only. Do not use this mode if you have SG Client deployed in your
ADN network.



Plain Only.

49

Volume 5: Advanced Networking
Section E: Securing the ADN Network

Secure Outbound Connections
When secure ADN is enabled, any existing plain outbound connections are
dynamically secured by activating SSL according to the secure-outbound setting.
Determine which outbound ADN connections are secured by changing the
secure-outbound parameter. If you select:


None: Neither routing nor tunnel connections are secured. Secure proxy
connections bypass ADN connections and go directly to the origin content
sever.



Routing-only:



Secure Proxies:



ALL:

Only routing connections are secured. Secure proxy connections
bypass ADN connections and go directly to the origin content sever.
Routing connections and secure proxy connections are secured.

All outbound connections are secured.

Note: Securing all outbound ADN connections should be done only if the
platform has sufficient capacity to handle the extra overhead.

The table below describes secure outbound behavior with various applications.
Table 2–2 Secure Outbound Behavior

Application Connections
SecureOutbound
Setting

Routing
Connections

CIFS

SSL Proxy
Intercept Mode

SSL Proxy
Tunnel Mode

None

Plain Text

Plain Text

Bypass ADN

Bypass ADN

Routing-only

Encrypted

Plain Text

Bypass ADN

Bypass ADN

Secure Proxies

Encrypted

Plain Text

Encrypted

Encrypted by
application

All

Encrypted

Encrypted

Encrypted

Encrypted by
application

To configure ADN manager and tunnel listening mode and ports:

1. Select Configuration > ADN > General > Connection Security.

50

Volume 5: Advanced Networking
Section E: Securing the ADN Network


If the ADN peer connects to the secure manager listening port, the ADN
manager extracts the device ID from connecting ADN peer's appliance
certificate and looks for the device ID in its approved list of ADN peers.


If the device is on the approved list, a REQUEST-APPROVED response is sent,
followed by the route information, and the peer joins the network.



If the device is not on the approved list, the ADN manager adds the
connecting peer's device ID to the pending-peers list and sends a REQUESTPENDING response. After the peer is moved to the Approved list by the
administrator, a REQUEST-APPROVED response is sent, followed by the route
information, and the peer joins the network.



If the Pending Peers option is not enabled and a peer is not on the approved
list, the ADN manager sends a REQUEST-DENIED response and closes the
connection. The connecting peer closes the connection and updates its
connection status.



If a peer is deleted from the approved list, the ADN manager broadcasts a
REJECT-PEER to all peers to delete this peer and terminate any existing
ADN connections to it. No new connections are routed through the
deleted ADN peer. To have the denied peer rejoin the ADN network, go to
ADN > Config > General > Reconnect to Managers.

To approve a device to join the network:
Note: Device security must be enabled on all ADN peers you want to join the
network before you complete this procedure on the ADN manager and
backup ADN manager. For more information, see "Setting Device Security"
on page 47.

1. Select Configuration > ADN > Manager > Approved Peers.
2. To manage peers that you want to be approved to join the network or that
have previously been approved to join the network:

52



Add peers to the list by selecting Add; a dialog box displays that allows
you to enter one or a group of peers by listing one to a line. Click OK when
through. If the device contacts the ADN manager and is on the approved
list, a REQUEST-APPROVED response is sent, followed by the route
information, and the peer joins the network.



Remove peers by highlighting the peer or peers and selecting Remove. If a
peer is deleted from the approved list, the ADN manager broadcasts a
REJECT-PEER to all peers to delete this peer and terminate any existing
ADN connections to it. No new connections are routed through the
deleted ADN peer.

Chapter 2: Configuring an Application Delivery Network
Section E: Securing the ADN Network
To manage devices not yet approved to join the network:

If a peer is configured to contact the ADN manager on startup but has not been
added to the approved list, the ADN manager adds the peer to the list of pending
peers if the Allow Pending Peers checkbox is selected. The peer moves from the
Pending Peers list to the Approved Peers list only through human action.
1. Select Configuration > ADN > Manager > Pending Peers.

2. Select the Allow Pending Peers option.
3. To manage pending peers:


Highlight a peer and click Accept or Reject; alternatively, you can select or
reject all peers in the list by clicking Accept All or Reject All. If accepted, the
peer moves to the Approved list; if not, it is dropped from the Pending Peers
list.



You can also leave peers in the pending list by not selecting them or
selecting them and clicking Mark Pending.

4. Click Apply.

Approved/Pending Notes


Approved lists on the primary and backup ADN managers are not
automatically kept in sync. You must approve peers on both the primary and
backup ADN managers.

53

Volume 5: Advanced Networking
Section F: ADN Network History, Active Sessions, Byte-Caching Statistics, and Health Metrics

Section F: ADN Network History, Active Sessions, Byte-Caching
Statistics, and Health Metrics
After ADN optimization has been enabled and is processing, you can review
various ADN history and statistics.

Reviewing ADN History
Review the ADN history by selecting Statistics > ADN History.

You can view either usage statistics or gain statistics (by clicking the Gain tab) and
either Unoptimized Bytes or Optimized Bytes through the pie charts on the right side.
The left side of the tab represents optimized and unoptimized bytes trend graphs
for the selected peer or all peers; hovering the cursor over the graph displays
statistics in numeric form. For information on tool tips, refer to Volume 9:
Managing the Blue Coat ProxySG Appliance.
The right-side pie chart represents optimized and unoptimized bytes for all peers.
The rows in the table below the graphs represent ADN peers and columns
representing various aspects of the ADN peers:
Note: All ProxyClient peers are combined and shown on one row. For more
information on ProxyClient statistics, see Chapter 12: "Accelerating and
Controlling Micro-Branch and Mobile User Connections (ProxyClient)" on
page 173.

54

Chapter 2: Configuring an Application Delivery Network
Section F: ADN Network History, Active Sessions, Byte-Caching Statistics, and Health Metrics


Peer ID:

ID of the peer.



Peer IP:

IP address of the peer.



Optimized Bytes:



Unoptimized Bytes:



Savings: The percentage of data that did NOT have to be sent over the WAN
because of object and byte caching, protocol optimization, and compression.
Moving the cursor over the Savings column value displays tool-tip
information.

Data that has been byte-cached and/or compressed.

Data that is to be byte-cached or compressed and data that
has been un-byte-cached or decompressed.

Selecting any row in the table changes the trend graph at top left and display
graphs for the selected peer. If you select the last row, which displays totals, the
trend graph at top left reflects the cumulative data. Changing the duration (using
the Duration drop-down list) changes the graph accordingly.

See Also


Chapter 5, “Statistics,” in Volume 9: Managing the Blue Coat ProxySG Appliance.

Reviewing ADN Active Sessions
You can view active ADN inbound connections through the Statistics > Active
Information from the ADN Inbound Connections
tab can be used for diagnostic purposes.

Sessions > ADN Inbound Connections.

Note that these connections are not persistent. When a connection completes, the
statistics for that connection no longer display.

55

Volume 5: Advanced Networking
Section F: ADN Network History, Active Sessions, Byte-Caching Statistics, and Health Metrics

You can filter on a number of variables, including client, server, or peer IP
address; server port, or none (shown above). You can also limit the number of
connections being displayed to the n most recent.
Note: You must press Show each time you change display options or if you want

to refresh the page.
You can terminate an active ADN inbound connection or you can download
session details.


To terminate an ADN inbound connection, select the session in the list and
click Terminate Connection.



To download details about all connections as a text file that you can open in a
spreadsheet program, click Download. Note that all of the connections in the list
are downloaded.

Each connection has the following details.


Client:



Server:



Peer:



Duration:



Unopt. Bytes:



Opt. Bytes: The amount of compressed/byte-cached data sent to/received from

The IP address of the system that is being sent through the ProxySG
over ADN connections.
The IP address of the server to which you are connecting: CNN, for
example, or Google.
The downstream ProxySG or ProxyClient.
The length of time the connection has been active.

The amount of data served to/from the server prior to or
subsequent to ADN optimization.
the downstream ProxySG/ProxyClient.



Savings:



Compression:

A relative percentage of bandwidth savings on the WAN link.
Whether gzip compression is active in either direction on that

tunnel.


Byte Caching:



Encryption:



Tunnel Type:

Whether byte caching is active in either direction on that tunnel.

Whether encryption is active in either direction on that tunnel.
One of the following: Explicit, Transparent, or Client.

See Also
Chapter 5, “Statistics, in Volume 9: Managing the Blue Coat ProxySG Appliance.

56

Chapter 2: Configuring an Application Delivery Network
Section F: ADN Network History, Active Sessions, Byte-Caching Statistics, and Health Metrics

Reviewing Byte-Caching Statistics
To review byte caching statistics, select Statistics > Advanced and select the ADN >
ADN Statistics link from the list.
Per-connection, real-time statistics are provided. Each connection has the
following details:


Client IP address/port.



Server IP address/port.



Bytes received from the application: The total bytes received from the client/
server/application proxy.



Bytes sent to the application: The total bytes sent to the client/server/
application proxy.



Bytes received from the peer SG appliance: The bytes received on the ADN
tunnel connection from the peer at the other end of the WAN link. (This is
compressed unless byte caching is disabled).



Bytes sent to the peer SG appliance: The bytes sent on the ADN tunnel
connection to the peer at the other end of the WAN Link. (This is compressed
unless byte caching is disabled).



Duration: The lifetime of this connection.

Reviewing ADN Health Metrics
You can see the state of the ADN network, specifically the ADN peer, by checking
the Statistics > Health Monitoring> General tab.
The status can have the values as shown in the following table. The information is
meant for diagnostic and debugging purposes.

57

Volume 5: Advanced Networking
Section F: ADN Network History, Active Sessions, Byte-Caching Statistics, and Health Metrics
Table 2–3 Connectivity to ADN Routing Manager Health Metric

Status

Message

Description

State

ADN Health Status

Connected

The ADN peer is connected to the
ADN manager, ready to receive any
route/peer updates.

OK

If a backup manager exists, this state
indicates the peer is connected to both
Managers.
Functionality
Disabled

ADN functionality is not enabled.

OK

Not operational

ADN functionality is not operational
yet — components are starting up or
shutting down.

OK

Connection
Approved

The ADN peer has been approved to
connect to the ADN manager.

OK

Connecting

The ADN peer is in process of
connecting to ADN manager.

OK

Partially
Connected

The ADN peer is connected to one
ADN manager but not the other.

Warning

Mismatching
Approval Status

The ADN peer is approved by the
current active ADN manager but is
rejected by the backup manager. This
warning only exists if a backup ADN
manager is configured.

Warning

Approval Pending

The ADN peer is awaiting a decision
from the active ADN manager for the
peer’s request to join the ADN
network.

Warning

Disconnected

The ADN peer is not connected to the
ADN manager and cannot receive
route/peer information.

Critical

If a backup manager is configured, this
state indicates the peer is disconnected
from both manager peers.
Connection
Denied

58

The ADN peer is rejected by the ADN
managers in the peer's request to join
the ADN network.

Critical

Chapter 2: Configuring an Application Delivery Network
Section F: ADN Network History, Active Sessions, Byte-Caching Statistics, and Health Metrics
Table 2–3 Connectivity to ADN Routing Manager Health Metric (Continued)

Status

Message

Description

State

ADN Manager Status

Not an ADN
manager

The ADN peer is not an ADN manager.

OK

No Approvals
Pending

All ADN peers that are requesting to
join the network are already on the
approved list.

OK

Approvals
Pending

ADN peers are requesting to join the
network. The approvals are made by
the administrator.

Warning

59

Volume 5: Advanced Networking
Section G: Advanced Tunnel Optimization

Section G: Advanced Tunnel Optimization
Tunnel connections are between the branch and concentrator proxies and are
made on demand. To reduce connection startup latency, tunnel connections are
pooled and reused.
If a route is present, proxies that support ADN optimization use an ADN tunnel
connection. Data traveling over the tunnel connection is subject to byte caching,
compression, and encryption, per the defined policies.
The tunnel connection occurs independently of the ADN optimization options
chosen for that connection. These options can be configured for specific services
and can also be modified in policy.
Note: Encryption options cannot be set through policy.

Optimization options include byte caching and gzip compression; byte caching
and gzip compression can be controlled separately for inbound and outbound
traffic on the WAN.
By default, ADN routing and tunnel connection requests are unauthenticated and
all ADN protocol messaging and compressed application data are transferred in
plaintext. For maximum security, you can configure the ADN network to secure
ADN routing and tunnel connections using standard SSL protocol, which
provides authentication, message privacy, and message authenticity security
services, regardless of the application traffic that is being accelerated or tunneled.
For information on securing the network, see Section E: "Securing the ADN
Network" on page 46.

Setting Advanced Tunneling Parameters
The tunneling parameters you set determine the behavior when you have special
environmental needs where the default parameters are not adequate. These
parameters generally do not need to be changed. Parameters that can be changed
include:


Connection Settings (see "To configure ADN manager and tunnel listening
mode and ports:" on page 50).



Network Settings (see "To configure network tunneling settings:" ).



Load Balancing Settings (see "Transparent Load Balancing" on page 35 and
"Explicit Load Balancing" on page 41).



Proxy Processing Settings (see "To change parameters for proxy processing:"
on page 63).

To configure network tunneling settings:

1. Select Configuration > ADN > Tunneling > Network.

60

Chapter 2: Configuring an Application Delivery Network
Section G: Advanced Tunnel Optimization

2. Determine the behavior of the concentrator proxy when a branch proxy
requests client IP reflection. Concentrator client IP reflection configuration
determines what IP address the concentrator advertises to the origin server as
the source address—the concentrator’s own address (referred to as use local IP)
or as the proxy’s address (referred to as reflect the client IP).
The option you choose depends mainly on whether or not the concentrator is
installed inline between the proxy and the origin server, as follows:


Reject the request

Choose this option to reject a proxy’s request to reflect the client IP; as a
result, the connection to the concentrator is rejected.
Note: The behavior of the ProxyClient is different than the behavior of a
branch proxy. For the ProxyClient, this option is the same as Allow the request but
use a local IP. For more information, see "About Reflecting the ProxyClient IP
Address" on page 194.


Allow the request and reflect the client IP

Choose this option if the concentrator is installed inline between the
branch proxy and the origin server. This option means the return packets
will have the branch proxy's IP address as the destination address and
must be routed back through the same concentrator.

61

Volume 5: Advanced Networking
Section G: Advanced Tunnel Optimization



Allow the request but use a local IP

Choose this option if the concentrator is installed out of line with respect
to the branch proxy and the origin server and when the option to reflect
the client IP address results in a failed connection. The next paragraph
discusses why connections might fail.
With the option to reflect the client IP enabled, the concentrator opens a
different connection to the origin server than the one originally opened by
the branch proxy, so response packets going directly from the origin server
to the branch proxy will be rejected and the connection will fail.
3. TCP window size is the number of bytes that can be buffered on a system before
the sending host must wait for an acknowledgement from the receiving host.
The TCP window size for ADN optimization tunnel connections is set and
updated automatically, based on current network conditions and on the
receiving host’s acknowledgement. In most situations, the TCP Settings option
should be left as Automatically adjusted.
Only use the Manual override setting if your network environment has
intervening network equipment that makes the delay appear lower than it
actually is. These environments are sometimes found on satellite links that
have high bandwidth and high delay requirements. In this case, the
automatically adjusted window size would be smaller than optimal.
The configurable range is between 8 Kb and 4 MB (8192 to 4194304),
depending on your bandwidth and the round-trip delay. Setting sizes below
64Kb are not recommended.
Note: If you know the bandwidth and round-trip delay, you can compute

the value to use as, roughly, 2 * bandwidth * delay. For example, if the
bandwidth of the link is 8 Mbits/sec and the round-trip delay is 0.75
seconds:
window = 2 * 8 Mbits/sec * 0.75 sec = 12 Mbits = 1.5 Mbytes

The setting in this example would be 1500000 bytes. This number goes up
as either bandwidth or delay increases, and goes down as they decrease.
You can decrease or increase the window size based on the calculation;
however, decreasing the window size below 64Kb is not recommended..
The window-size setting is a maximum value; the normal TCP/IP
behaviors adjust downward as necessary. Setting the window size to a
lower value might result in an artificially low throughput.
4. Click Apply to commit the changes to the ProxySG.

62

Chapter 2: Configuring an Application Delivery Network
Section G: Advanced Tunnel Optimization
To change parameters for proxy processing:

1. Select Configuration > ADN > Tunneling > Proxy Processing.

2. (Optional) If the concentrator is required to perform HTTP proxy processing
on requests arriving over an ADN tunnel, select HTTP. For most deployments,
this is not needed. All proxy processing always happens at the branch proxy;
generally speaking, the concentrator proxy just compresses and decompresses
bytes and forwards them to and from the server. If this setting is enabled,
proxy processing happens at both the branch and concentrator.
Note: If you enable this setting, do not duplicate any of the policy that

exists at the branch, since the branch settings still apply. Depending on
the policy involved, doing the processing twice can cause problems
(such as doing URL rewrite multiple times) or it might just be
unnecessary, taking up valuable resources.
3. Click Apply.

63

Volume 5: Advanced Networking
Section H: Byte-Cache Dictionary Sizing

Section H: Byte-Cache Dictionary Sizing
A byte cache dictionary comprises a set of data streams. A data stream can be
thought of as a binary file containing data extracted from the data sent between
two peers. The actual dictionary size is determined by the number of data streams
in the dictionary.
Dictionary sizing is automatic and generally does not need to be changed.
However, if a peer’s dictionary is too small or too large, you can manually resize
the dictionary. For more information on manually sizing a peer’s dictionary, see
"Manually Sizing Peers" on page 66.

Understanding Dictionaries
Actual dictionary size is determined by the number of data streams in the
dictionary. For dictionary sizing, the disk is considered full when the amount of
disk space allocated to byte caching is full.
Unpopular streams are deleted when the dictionary becomes full. In normal
operation, the disk is kept nearly full, with data streams being deleted and created
in nearly the same numbers.

Understanding Dictionary Sizing
The actual size of a dictionary is determined by the number of data streams in the
dictionary. The calculation of the actual size of a dictionary assumes the actual
size is the product of the number of data streams in the dictionary and the
maximum size of a data stream, which is 16 megabytes.
By default, a new peer is allocated 100MB for its dictionary, although it does not
require that much space at the beginning. The allocated dictionary size is treated
as a minimum. If resources are available after all dictionaries have been allocated,
any dictionary can request and get more space. To guarantee a minimum
dictionary size, the value should be set manually on both peers. (See "To manually
resize byte cache dictionaries from the Statistics tab:" on page 67.)
The ProxySG resizes the dictionary automatically for best utilization of the disk
space, although you can force a re-size if necessary. As dictionary sizing can be an
expensive operation, it is avoided whenever it is unnecessary.
The dictionary is resized:


The first time after midnight (UTC) that the dictionary is used. A scheduled
resizing is skipped if an immediate sizing has been done within the last two
hours.
This setting is not configurable.



64

If you modify the allocation for byte caching by setting the ADN maximum
disk usage size. This causes a resizing if initialization has been completed.
Increasing the allocation for byte caching causes a resizing if the byte cache
status is Insufficient Resources.

Chapter 2: Configuring an Application Delivery Network
Section H: Byte-Cache Dictionary Sizing


If you manually size a peer (or change the dictionary sizing to AUTO). If there
is currently enough room to allocate the requested size for the peer, no
resizing is done.



If a peer either starts or stops using byte caching. If enough disk space is
available to allocate a dictionary for the peer that is starting to use byte
caching, no resizing is done; if the byte-cache status is "Insufficient Resources"
when a peer stops using byte caching, resizing is done.

The re-sizing allows potentially unused or unutilized dictionaries to be identified,
freeing resources.
The allocated size of a dictionary is a minimum size, not a maximum size.
However, the allocated size is not a guaranteed minimum because it might take
some time for a dictionary to grow to that size, and because the peer might be
unable to provide a dictionary that large.
A peer with no allocated dictionary might still be able to get some data streams
and do byte caching. In steady state, the disk is nearly full, and as new data
arrives, streams must be deleted to make room. Only dictionaries whose actual
size is larger than their allocated size are subject to stream deletion. The smaller
the dictionary, the less likely it is that a match will be found. If no matches are
found, gzip compression is the only available optimization.

Ranking Peers
A table of peer rankings and dictionary sizes is created and maintained by the
ProxySG. The highest-ranked peer is listed first. Manually sized peers outrank
automatically sized peers, independent of their traffic.
Peer rankings are derived based on the amount of data traffic carried and the
byte-caching efficiency.
Note: The rank table can track peers that are using SGOS versions prior to SGOS

5.3, but these peers cannot dynamically re-size or delete their dictionary.
If a peer is not using the current SGOS version, the peer is not ranked unless it has
a manually sized dictionary.
Note: All manually sized peers using an older version of SGOS have the same

rank, which is below the lowest ranked manually sized peer using the current
version of SGOS and above the highest ranked automatically size peer using the
current version of SGOS; they are displayed in random order. Similarly, all
automatically sized peers using an older version of SGOS are considered to have
the same rank; these peers are displayed at the end in random order.

65

Volume 5: Advanced Networking
Section H: Byte-Cache Dictionary Sizing

The dictionary-sizing algorithm, starting with the highest-ranked peer, does the
following:


Calculates the recommended size based on traffic history and byte-caching
efficiency



Allocates this size, if possible.
Note: If it is not possible to allocate the recommended size, it allocates the

available disk space if there is at least 100 MB, or else nothing is allocated. No
lower-ranked peer gets a dictionary.

Dictionary Sizing Messages
Peers send messages to each other announcing the allocated memory size; if the
allocated size is other than zero, it is displayed as the advised size and a
dictionary is allocated as per the algorithm.
If the advised size is zero, the peer does not have a dictionary, and no dictionary is
allocated. If the peer had previously been using byte caching, the disk space
allocated to that peer's dictionary is eventually freed.

Ranking New Peers
When a peer joins the network, it is added to the peer ranking table. How much
dictionary space the peer is allocated depends:


If no history exists for this peer, the peer is allocated 100MB.



If history does exist for the peer, the peer is allocated a dictionary based on
that history.

Manually Sizing Peers
Under certain circumstances, you might need to manually size a peer that does
not get enough disk space, or you might have a network where one peer takes a
disproportionate amount of resources. For example, if there are many peers, it is
simpler to manually resize the one large dictionary than to manually resize all the
rest.
If you determine that the algorithm does not guarantee the right dictionary size
for a specific peer (either too large or too small), you can control the amount of
disk space to be set aside for that peer’s dictionary.
Note: You cannot reduce the space available for byte caching to below the total

size of all manually sized dictionaries. You also cannot assign a size to a
dictionary that would cause the total size of all manually sized dictionaries to
exceed the space available for byte-caching.

66

Chapter 2: Configuring an Application Delivery Network
Section H: Byte-Cache Dictionary Sizing

You can manually resize an ADN byte-caching dictionary in two places in the
Blue Coat appliance Management Console: From the Statistics > ADN History > Peer
Dictionary Sizing tab, or from the Configuration > ADN > Byte Caching tab. You might
find the Statistics tab easier to use, since that tab does not require you to know the
peer ID. Note, however, that only peers that are known with an established
dictionary are displayed in the Statistics tab. If a peer is unknown or has no
existing dictionary, use Configuration > ADN > Byte Caching.
To manually resize byte cache dictionaries from the Statistics tab, continue with
the next section. To manually resize byte cache dictionaries from the Configuration
tab, skip to "To manually resize byte cache dictionaries from the Configuration >
ADN > Byte Caching tab:" on page 68.
To manually resize byte cache dictionaries from the Statistics tab:

1. Select Statistics > ADN History > Peer Dictionary Sizing.

2. The Peer Dictionary Sizing tab gives you statistics relevant to the byte cache
dictionary size of all peers on the network.


Rank:



Peer ID:

The serial number of the device.



Peer IP:

The IP address of the device, if it is connected.



Byte Cache Score:

The score of this peer relative to other peers. Score is
calculated based on the traffic history and byte-caching efficiency of the
peer.



Peer Traffic (GB/Day): The



Fill Rate (GB/Day): The



Recommended Dict Size (GB): The

The ranking of a peer’s dictionary. Manually-configured peers have
a higher rank than dynamically-configured peers.

average amount of pre-byte-cache traffic per day.

average amount of data put into the dictionary per
day over the last week.

dictionary size the Blue Coat appliance
recommends, based on the peer traffic over the last week.

67

Volume 5: Advanced Networking
Section H: Byte-Cache Dictionary Sizing



Actual Dict Size (GB):

The actual size of the dictionary.

3. Highlight the device whose dictionary you want to re-size and click Edit. The
Edit Peer dialog displays.
4. To select a dictionary size for the device, select the Manual Re-size radio button
on the Edit Peer dialog and enter the value you want in megabytes.
5. Click OK to have the resizing take effect immediately.
To manually resize byte cache dictionaries from the Configuration > ADN > Byte
Caching tab:

1. Select Configuration > ADN > Byte Caching.

2. To change the total disk space available for all byte-cache dictionaries, change
the percentage in the Maximum Disk Space to Use for Byte Caching field.
The statement Max-disk-usage Range should be between 5 and 80 percent of x GB
indicates how much of the existing disk can be used for byte caching.
3. Click New. The Create Manual Dictionary Sizing dialog displays.

4. Enter the peer ID (serial number) of the device with which you are sharing a
dictionary.
5. Enter the new value in megabytes in the Size field or select the Disable Byte
Caching radio button to disable byte caching for this peer.

68

Chapter 2: Configuring an Application Delivery Network
Section H: Byte-Cache Dictionary Sizing

Note: If you enter an invalid value, an error message displays when you

click Apply. The error message gives you the maximum accepted value to
use. Repeat the previous steps to get a valid size.

6. Click OK. The peer is added to the manually configured dictionary sizing list
and is ranked among the other manually sized peers at the top of the
dictionary byte cache table.
Dynamic dictionary sizing is re-enabled through highlighting the peer and
selecting Delete.

69

Volume 5: Advanced Networking
Section I: Related CLI Syntax to Configure an ADN Network

Section I: Related CLI Syntax to Configure an ADN Network


To enter configuration mode:
SGOS#(config) adn
SGOS#(config adn)

Note: For detailed information on using these commands, refer to Volume 11:
Command Line Interface Reference.


The following subcommands are available:
SGOS#(config adn) {enable | disable}
SGOS#(config adn) exit
SGOS#(config adn) byte-cache
SGOS#(config
SGOS#(config
auto | none}
SGOS#(config
SGOS#(config

adn byte-cache) max-disk-usage percentage
adn byte-cache) peer-size peer-id {size_in_megabytes |
adn byte-cache) exit
adn byte-cache) view

SGOS#(config adn) load-balancing
SGOS#(config
SGOS#(config
SGOS#(config
SGOS#(config
SGOS#(config
disable}
SGOS#(config
SGOS#(config

adn
adn
adn
adn
adn

load-balancing)
load-balancing)
load-balancing)
load-balancing)
load-balancing)

{enable | disable}
exit
external-vip IP_address
group group_name
load-balance-only {enable |

adn load-balancing) no {external-vip | group}
adn load-balancing) view

SGOS#(config adn) manager
SGOS#(config adn manager) backup-manager {IP_address [ID] | self}
SGOS#(config adn manager) exit
SGOS#(config adn manager) no {backup-manager | primary-manager}
SGOS#(config adn manager) port port_number
SGOS#(config adn manager) primary-manager {IP_address [ID] | self}
SGOS#(config adn manager) secure-port secure_port_number
SGOS#(config adn manager) view [approved-peers | backup-manager-id
| pending-peers | primary-manager-id]
SGOS#(config adn manager) approved-peers
SGOS#(config
SGOS#(config
SGOS#(config
SGOS#(config

adn
adn
adn
adn

approved-peers)
approved-peers)
approved-peers)
approved-peers)

add peer-device-ID
exit
remove peer-device-ID
view

SGOS#(config adn manager) pending-peers
SGOS#(config
SGOS#(config
SGOS#(config
SGOS#(config

adn
adn
adn
adn

pending-peers)
pending-peers)
pending-peers)
pending-peers)

{accept | reject}
{enable | disable}
exit
view

SGOS#(config adn) routing
SGOS#(config adn routing) exit
SGOS#(config adn routing) prefer-transparent {enable | disable}
SGOS#(config adn routing) view

70

Chapter 2: Configuring an Application Delivery Network
Section I: Related CLI Syntax to Configure an ADN Network
SGOS#(config adn routing) advertise-internet-gateway
SGOS#(config adn routing advertise-internet-gateway) {disable |
enable}
SGOS#(config adn routing advertise-internet-gateway) exemptsubnet {add {subnet_prefix[/prefix_length]} clear-all | remove
{subnet_prefix[/prefix_length]} | view}
SGOS#(config adn routing advertise-internet-gateway) exit
SGOS#(config adn routing advertise-internet-gateway) view
SGOS#(config adn routing) server-subnets
SGOS#(config adn
prefix length]
SGOS#(config adn
SGOS#(config adn
prefix length]
SGOS#(config adn
SGOS#(config adn

routing server-subnets) add subnet_prefix [/
routing server-subnets) clear-all
routing server-subnets) remove subnet_prefix [/
routing server-subnets) exit
routing server-subnets) view

SGOS#(config adn) security
SGOS#(config adn security) authorization {enable | disable}
SGOS#(config adn security) exit
SGOS#(config adn security) manager-listening-mode {plain-only |
plain-read-only | secure-only| both}
SGOS#(config adn security) no ssl-device-profile
SGOS#(config adn security) secure-outbound {none | routing-only|
secure-proxies | all}
SGOS#(config adn security) ssl-device-profile profile_name
SGOS#(config adn security) tunnel-listening-mode {plain-only |
secure-only | both}
SGOS#(config adn security) view
SGOS#(config adn) tunnel
SGOS#(config adn tunnel)
SGOS#(config adn tunnel)
SGOS#(config adn tunnel)
SGOS#(config adn tunnel)
SGOS#(config adn tunnel)
SGOS#(config adn tunnel)
use-local-ip)
SGOS#(config adn tunnel)
SGOS#(config adn tunnel)
|window_size_in_bytes}
SGOS#(config adn tunnel)

connect-transparent {enable | disable}
exit
preserve-dest-port {enable | disable}
port port_number
proxy-processing http {enable | disable}
reflect-client-ip (deny | allow |
secure-port secure_port_number
tcp-window-size {auto
view

71

Chapter 2: Configuring an Application Delivery Network
Section J: Policy

Section J: Policy
The following gestures can be used for WAN optimization from either the VPM or
CPL.
Note: For more information on using the VPM or CPL to configure policy, refer to

Volume 6: The Visual Policy Manager and Advanced Policy or Volume 10: Content
Policy Language Guide.


adn.server(yes | no) (This property overrides all other routing and intercept
decisions made by ADN based on configuration and routing information.)



adn.server.optimize(yes | no)



adn.server.optimize.inbound(yes | no)



adn.server.optimize.outbound(yes | no)



adn.server.optimize.byte-cache(yes | no)



adn.server.optimize.inbound.byte-cache(yes | no)



adn.server.optimize.outbound.byte-cache(yes | no)



adn.server.optimize.compress(yes | no)



adn.server.optimize.inbound.compress(yes | no)



adn.server.optimize.outbound.compress(yes | no)



adn.server.dscp

72

Chapter 2: Configuring an Application Delivery Network
Section K: Troubleshooting

Section K: Troubleshooting
You can troubleshoot your ADN network several ways:


through the test adn diagnostics command



through viewing the ADN configuration

Each of these tools can provide information about the ADN network and suggest
reasons for the network failure.

Using the Test ADN Diagnostics Command
This command is used to test connectivity from one ProxySG to a server on a
specified port. This test also can be done with an ADN port to test the success or
failure of a ProxySG connection to an ADN peer.
The command provides details of its success or failure.

Transparent ADN: Success
Blue Coat SG200 Series# test adn 192.168.0.222 80
connecting to 192.168.0.222:80...succeeded!
Diagnostics
Route decision
Route reason
Route policy
Connect result
Remote peer
Local Addr
Peer Addr

:
:
:
:
:
:
:

Connect Transparently
ADN transparent due to no explicit route
Success
207060009
192.168.0.121:64881
192.168.0.222:80

Notes


The remote peer information (device ID and IP address) is provided in a
successful attempt.



The Remote Peer is the device ID (serial number, in this case) of the remote
ProxySG the test ADN command found.



The Local Addr is the originating system.



The Peer Addr is the server IP address, a side effect of the test adn command
and a transparent deployment. Normally, the Peer Addr would be a ProxySG
IP address.

73

Chapter 2: Configuring an Application Delivery Network
Section K: Troubleshooting

Transparent ADN: Success but no Upstream ADN Connection
Blue Coat SG200 Series# test adn 192.168.0.222 80
Connecting to 192.168.0.222:80...succeeded!
Diagnostics
Route decision
Route reason
Route policy
Connect result
Peer Addr

:
:
:
:
:

Attempted Transparent but went Direct
ADN transparent due to no explicit route
Success
192.168.0.222:80

Notes


Because no ADN connection existed, the Route decision indicates what
happened:


The test adn command went directly to the server.



Success in this case refers to the successful connection to the server but not

through an ADN connection.


Remote peer device ID and local address information were not available.

Explicit ADN: Success
Blue Coat SG200 Series# test adn 192.168.0.222 80
Connecting to 192.168.0.222:80...succeeded!
Diagnostics
Route decision : Connect Explicitly
Route reason
: ADN explicit route found
Route policy
:
Explicit routes found:
Peer (207060009) ip#0: 192.168.0.122, ports: 3035,3037 Connect
result : Success
Remote peer
: 207060009
Local Addr
: 192.168.0.121:53892

Peer Addr

: 192.168.0.122:3035

Notes


The Remote Peer is the device ID (serial number, in this case) of the remote SG
the test ADN command found.



The Local Addr is the originating system.



The Peer Addr is the IP address of the remote peer.

74

Chapter 2: Configuring an Application Delivery Network
Section K: Troubleshooting

Explicit ADN: The Upstream Device is not Functioning
Blue Coat SG200 Series# test adn 192.168.0.222 80
Connecting to 192.168.0.222:80...failed with error :
Diagnostics

5!

Route decision : Connect Explicitly
Route reason
: ADN explicit route found
Route policy
:
Explicit routes found:
Peer (207060009) ip#0: 192.168.0.122, ports: 3035,3037
Connect result : Failure
Failure reason : Socket internal error
Network error
: Socket error(5)
Local Addr
: 192.168.0.121:53892
Peer Addr
: 192.168.0.122:3035

Notes


For an explicit connection, the local IP address is displayed even if a
connection cannot be established.

Error Codes
Table 2–4 Error Codes

Error Code

Description

5

Networking Input/output error

50

Network is down

51

Network is unreachable

52

Network dropped connection on reset

53

Software caused connection abort

54

Connection reset by peer

55

No buffer space available

56

Socket is already connected

57

Socket is not connected

58

Can't send after socket shutdown

59

Too many references: can't splice

60

Operation timed out

61

Connection refused

75

Chapter 2: Configuring an Application Delivery Network
Section K: Troubleshooting

Showing the ADN Configuration
You can view the entire ADN configuration through the show adn CLI command.
Also, you can use the show adn subcommands to view specific parts of the ADN
configuration. This section describes the show adn subcommands.


ADN Manager Configuration: The manager

configuration shows the primary and
backup mangers, ports, and where approved devices connect from.

SGOS# show adn manager
Primary manager:
Backup manager:
Port:
Secure port:
Approved device
2505060056 10.25.36.48
Allow pending devices:
Pending device


self
10.9.59.243 2505060056
3034
3036
Connecting from
enabled
Connecting from

Tunnel Configuration: The tunnel configuration displays connection information

for this device.
SGOS# show adn tunnel
Port:
Secure port:
proxy-processing http:
connect-transparent:
preserve-dest-port:
TCP window size:
reflect-client-ip:


3035
3037
disabled
enabled
disabled
auto
use-local-ip

Load Balance Configuration:

The load balance configuration displays the Load
Balance information for this device.

SGOS# show adn load-balancing
Load Balancing Configuration:
Load-balancing:
disabled
Load-balancing Group:

Load-balance only mode:
disabled; will take traffic
External VIP:
none


Routing Table:

The routing table section shows the advertised subnets for this
device. Note that the routing table is only populated if explicit ADN is used.

SGOS# show adn routing
Prefer Transparent:
Internet Gateway:
Exempt Server subnet:
Exempt Server subnet:
Exempt Server subnet:
Server subnet:

disabled
enabled
10.0.0.0/8
172.16.0.0/12
192.168.0.0/16
10.25.36.0/24

76

Chapter 2: Configuring an Application Delivery Network
Security Configuration: This section displays security information about
the device.
SGOS# show adn security
Ssl-device-profile:
4605060001)
Manager-listening mode:
Tunnel-listening mode:
Authorization:
Secure-outbound:


bluecoat-appliance-certificate (Device-id:
both
both
enabled
secure-proxies

Byte Cache Configuration:

This section shows the percentage of disk space you
are allowing this peer to use for byte caching. The recommended range is also
displayed. For more information on the byte-caching CLI tables that are
displayed as part of the byte-cache configuration output, continue with the
next section.

SGOS# show adn byte-cache
Byte Cache Configuration:
Max-disk-usage:
65
; Max-disk-usage Range should be between 5 and 80 percent of 40 GB

Byte-Cache Configuration CLI Tables
As part of the byte-cache configuration CLI output, two tables are displayed:


Global Information



Per-Peer Data

Viewing Byte-Cache Global Information
The table has information that affects all caches.
|

Time of

|Tot Size|

Total

|Tot Size
Current Time (UTC)
Alloc'd

| Next Peer Ranking (UTC)

|Allocabl|Rec Size|

------------------------|--------------------------|--------|-------|-----19:50:00 16/04/2008 |
571 MB

00:00:00 17/04/2008 |

20 GB|

571 MB|

The table contains the:


current time



time for the next scheduled (daily, at midnight UTC) peer ranking



total allocable disk space (converted from a percent into an actual size in SI
units—20GB is 20,000,000,000 bytes)



total recommended size of all dictionaries



total allocated size of all dictionaries

77

Volume 5: Advanced Networking

Viewing Per-Peer Data
This table has per-peer data, with one line for each peer (all ProxyClients are
combined into a single line).
Peer ID |Traffic|Savings| Adj. | Rec. | Alloc.| Actual| Manual| Flags
|
|
| Gzip | Size | Size | Size | Size |
------------|-------|-------|-------|-------|-------|-------|-------|---6
Clients | 18 MB| 742 KB|
0 B| 30 MB| 30 MB|8069 MB|
0 B| ___

Note: One line summarizes all ProxyClients, as shown in the per-peer data table

above—instead of a peer id, it says "N Clients", and information provided
includes the total overall client statistics for the traffic, savings, adjusted gzip,
recommended size, allocated size, actual size, and manual size; the flags column
displays an unbroken underline.
Information included is the:

78



peer id (or the number of ProxyClients)



traffic (total uncompressed data over the last week)



savings (byte-cache savings during the last week)



adjusted gzip data (all the uncompressed data sent or received during the last
week when byte caching was not being done)



recommended size for this peer's dictionary



allocated size for this peer's dictionary



actual size for this peer's dictionary



manual size for this peer's dictionary



flags


N



M



A means that the peer has advertised that it is using a manual size for its
dictionary



P

means that the user chose not to do compression when sending data to
this peer
means that manual sizing is in effect for this dictionary

means that the dictionary is peer-limited. The peer has asked for a
smaller dictionary than allocated.

Chapter 3: Preventing Denial of Service Attacks

This chapter describes how the ProxySG prevents attacks designed to prevent
Web services to users.

Topics in this Chapter
This chapter includes information about the following topics:


About Attack Detection



"Configuring Attack-Detection Mode for the Client" on page 80



"Configuring Attack-Detection Mode for a Server or Server Group" on page
83

About Attack Detection
The SGOS software can reduce the effects of distributed denial of service
(DDoS) attacks and port scanning, two of the most common virus infections.
A DDoS attack occurs when a pool of machines that have been infected with a
DDoS-type of virus attack a specific Web site. As the attack progresses, the
target host shows decreased responsiveness and often stops responding.
Legitimate HTTP traffic is unable to proceed because the infected system is
waiting for a response from the target host.
Port scanning involves viruses attempting to self-propagate to other machines
by arbitrarily attempting to connect to other hosts on the Internet. If the
randomly selected host is unavailable or behind a firewall or does not exist, the
infected system continues to wait for a response, thus denying legitimate HTTP
traffic.
The ProxySG prevents attacks by limiting the number of simultaneous TCP
connections from each client IP address and either does not respond to
connection attempts from a client already at this limit or resets the connection.
It also limits connections to servers known to be overloaded.
If the ProxySG starts seeing a large number of HTTP errors, and that number
exceeds the configured error limit, subsequent requests are blocked and the
proxy returns a warning page.
If the requests continue despite the warnings, and the rate exceeds the warning
limit, the client is blocked at the TCP level.
You can configure attack detection for both clients and servers or server groups,
such as http://www.bluecoat.com. The client attack-detection configuration is
used to control the behavior of virus-infected machines behind the ProxySG.
The server attack-detection configuration is used when an administrator knows
ahead of time that a virus is set to attack a specific host.
This feature is only available through the CLI. You cannot use the Management
Console to enable attack detection.

79

Volume 5: Advanced Networking

Configuring Attack-Detection Mode for the Client
To enter attack-detection mode for the client:

From the (config) prompt, enter the following commands:
SGOS#(config) attack-detection
SGOS#(config attack-detection) client

The prompt changes to:
SGOS#(config client)

Changing Global Settings
The following defaults are global settings, used if a client does not have specific
limits set. They do not need to be changed for each IP address/subnet if they
already suit your environment:


client limits enabled: false



client interval: 20 minutes



block-action: drop (for each client)



connection-limit: 100 (for each client)



failure-limit: 50 (for each client)



unblock-time: unlimited



warning-limit: 10 (for each client)

To change the global defaults:

Remember that enable/disable limits and interval affect all clients. The values
cannot be changed for individual clients. Other limits can be modified on a perclient basis.
Note: If you edit an existing client’s limits to a smaller value, the new value only

applies to new connections to that client. For example, if the old value was 10
simultaneous connections and the new value is 5, existing connections above 5 are
not dropped.
SGOS#(config client) enable-limits | disable-limits
SGOS#(config client) interval minutes
SGOS#(config client) block ip_address [minutes] | unblock ip_address
SGOS#(config client) default block-action drop | send-tcp-rst
SGOS#(config client) default connection-limit
integer_between_1_and_65535
SGOS#(config client) default failure-limit integer_between_1_and_500
SGOS#(config client) default unblock-time minutes_between_10_and_1440
SGOS#(config client) default warning-limit integer_between_1_and_100
:

Table 3–1 Changing Global Defaults
enable-limits |
disable-limits

80

Toggles between true (enabled) and false (disabled). The
default is false. This is a global setting and cannot be
modified for individual clients.

Chapter 3: Preventing Denial of Service Attacks
Table 3–1 Changing Global Defaults (Continued)
interval

integer

Indicates the amount of time, in multiples of 10 minutes,
that client activity is monitored. The default is 20. This is a
global setting and cannot be modified for individual
clients.

block | unblock

ip_address
[minutes]

Blocks a specific IP address for the number of minutes
listed. If the optional minutes argument is omitted, the
client is blocked until explicitly unblocked. Unblock
releases a specific IP address.

default blockaction

drop | sendtcp-rst

Indicates the behavior when clients are at the maximum
number of connections or exceed the warning limit: drop
the connections that are over the limit or send TCP RST for
connections over the limit. The default is drop. This limit
can be modified on a per-client basis.

default
connection-limit

integer

Indicates the number of simultaneous connections between
1 and 65535. The default is 100. This limit can be modified
on a per-client basis.

default failurelimit

integer

Indicates the maximum number of failed requests a client
is allowed before the proxy starts issuing warnings. Default
is 50. This limit can be modified on a per-client basis.

default unblocktime

minutes

Indicates the amount of time a client is blocked at the
network level when the client-warning-limit is exceeded.
Time must be a multiple of 10 minutes, up to a maximum
of 1440. By default, the client is blocked until explicitly
unblocked. This limit can be modified on a per-client basis.

default warninglimit

integer

Indicates the number of warnings sent to the client before
the client is blocked at the network level and the
administrator is notified. The default is 10; the maximum is
100. This limit can be modified on a per-client basis.

To create and edit a client IP address:

Client attack-detection configuration is used to control the behavior of virusinfected machines behind the ProxySG.
1. Verify the system is in the attack-detection client submode.
SGOS#(config) attack-detection
SGOS#(config attack-detection) client
SGOS#(config client)

2. Create a client.
SGOS#(config client) create {ip_address | ip_and_length}

3. Move to edit client submode.
SGOS#(config client) edit client_ip_address

The prompt changes to:
SGOS#(config client ip_address)

4. Change the client limits as necessary.

81

Volume 5: Advanced Networking
SGOS#(config client ip_address)
SGOS#(config client ip_address)
integer_between_1_and_65535
SGOS#(config client ip_address)
integer_between_1_and_65535
SGOS#(config client ip_address)
SGOS#(config client ip_address)
integer_between_1_and_65535

block-action drop | send-tcp-rst
connection-limit
failure-limit
unblock-time minutes
warning-limit

Table 3–2 Changing the Client Limits
block-action

drop | send-tcp-rst

Indicates the behavior when the client is at the
maximum number of connections: drop the connections
that are over the limit or send TCP RST for the
connection over the limit. The default is drop.

connection-limit

integer

Indicates the number of simultaneous connections
between 1 and 65535. The default is 100.

failure-limit

integer

Indicates the behavior when the specified client is at the
maximum number of connections: drop the connections
that are over the limit or send TCP RST for the
connection over the limit. The default is 50.

unblock-time

minutes

Indicates the amount of time a client is locked out at the
network level when the client-warning-limit is exceeded.
Time must be a multiple of 10 minutes, up to a
maximum of 1440. By default, the client is blocked until
explicitly unblocked.

warning-limit

integer

Indicates the number of warnings sent to the client
before the client is locked out at the network level and
the administrator is notified. The default is 10; the
maximum is 100.

To view the specified client configuration:

Enter the following command from the edit client submode:
SGOS#(config client ip_address)
Client limits for 10.25.36.47:
Client connection limit:
Client failure limit:
Client warning limit:
Blocked client action:
Client connection unblock time:

view
700
50
10
Drop
unlimited

To view the configuration for all clients:

1. Exit from the edit client submode:
SGOS#(config client ip_address) exit

2. Use the following syntax to view the client configuration:
view { | blocked | connections | statistics}

82

Chapter 3: Preventing Denial of Service Attacks
To view all settings:
SGOS#(config client) view
Client limits enabled:
true
Client interval:
20 minutes
Default client limits:
Client connection limit:
100
Client failure limit:
50
Client warning limit:
10
Blocked client action:
Drop
Client connection unblock time:
unlimited
Client limits for 10.25.36.47:
Client connection limit:
Client failure limit:
Client warning limit:
Blocked client action:
Client connection unblock time:

700
50
10
Drop
unlimited

To view the number of simultaneous connections to the ProxySG:
SGOS#(config client) view connections
Client IP
Connection Count
127.0.0.1
1
10.9.16.112
1
10.2.11.133
1

To view the number of blocked clients:
SGOS#(config client) view blocked
Client
Unblock time
10.11.12.13
2004-07-09 22:03:06+00:00UTC
Never
10.9.44.73

To view client statistics:
SGOS#(config client) view statistics
Client IP
Failure Count
10.9.44.72
1

Warning Count
0

To disable attack-detection mode for all clients:
SGOS#(config client) disable-limits

Configuring Attack-Detection Mode for a Server or Server Group
Server attack-detection configuration is used when an administrator knows ahead
of time that a virus is set to attack a specific host.
You can create, edit, or delete a server. A server must be created before it can be
edited. You can treat the server as an individual host or you can add other servers,
creating a server group. All servers in the group have the same attack-detection
parameters, meaning that if any server in the group gets the maximum number of
simultaneous requests, all servers in the group are blocked.
You must create a server group before you can make changes to the configuration.
To create a server or server group:

1. At the (config) prompt:
SGOS#(config) attack-detection
SGOS#(config attack-detection) server

83

Volume 5: Advanced Networking
The prompt changes to:
SGOS#(config server)

2. Create the first host in a server group, using the fully qualified domain name:
SGOS#(config server) create hostname

To edit a server or server group:

At the (config server) prompt:
SGOS#(config server) edit hostname

The prompt changes to (config server hostname).
SGOS#(config server hostname) {add | remove} hostname
SGOS#(config server hostname) request-limit integer_from_1_to_65535

where:
hostname

The name of a previously created server or server
group. When adding a hostname to the group, the
hostname does not have to be created. The host that
was added when creating the group cannot be
removed.

add | remove

hostname

Adds or removes a server from this server group.

request-limit

integer

Indicates the number of simultaneous requests allowed
from this server or server group. The default is 1000.

To view the server or server group configuration:
SGOS#(config server hostname) view
Server limits for hostname:
Request limit:
1500

84

Chapter 4: TCP Connection Forwarding

This chapter describes how to configure the ProxySG appliance to join peer
clusters that process requests in asymmetrically routed networks.

Topics in this Chapter
The following topics are covered in this chapter:


"About Asymmetric Routing Environments" on page 85



"The TCP Connection Forwarding Solution" on page 86



"Configuring TCP Connection Forwarding" on page 90

About Asymmetric Routing Environments
It is common in larger enterprises to have multiple ProxySG appliances
residing on different network segments; for example, the enterprise receives
Internet connectivity from more than one ISP. If IP spoofing is enabled,
connection errors can occur because the ProxySG terminates client connections
and makes a new outbound connection (with the source IP address of the
client) to the server. The response might not return to the originating ProxySG,
as illustrated in the following diagram.

85

Volume 5: Advanced Networking

1: The client makes a request; ProxySG 1 intercepts the connection.
2: ProxySG 1 terminates the client connection and invokes an outbound connection to the
server (with the client source IP address).
3: Based on its internal routing policies, the server believes ISP 2 provides a viable path
back to the client.
4: ProxySG 2 intercepts the response with the originating client IP address; however, it
does not recognize the connection from the client and attempts to reset the connection.
5: The client connection ultimately times out and the client receives a connection timeout
error.
Figure 4–1

Multiple ProxySG appliances in an asymmetric routing environment

After a connection occurs (either intercepted or bypassed) through any ProxySG
in the connection forwarding cluster, future packets of any such recorded flow
that is subject to asymmetric routing are properly handled. The ProxySG also
recognizes self-originated traffic (from any of the peers of the connection
forwarding cluster), so any abnormal internal routing loops are also appropriately
processed.

The TCP Connection Forwarding Solution
Enabling TCP Connection Forwarding is a critical component of the following
solutions:

86



"About Bidirectional Asymmetric Routing" on page 87.



"About Dynamic Load Balancing" on page 88.



"About ADN Transparent Tunnel Load Balancing" on page 89.

Chapter 4: TCP Connection Forwarding

About Bidirectional Asymmetric Routing
To solve the asymmetric routing problem, at least one ProxySG on each network
segment must be configured to perform the functionality of an L4 switch. These
selected appliances form a cluster. With this peering relationship, the connection
responses are able to be routed to the network segment where the originating
client resides.
In the 5.1.4.x release, cluster membership is manual; that is, ProxySG appliances
must be added to a cluster by enabling connection forwarding and adding a list of
other peers in the cluster. After a peer joins a cluster, it begins sending and
receiving TCP connections, and notifies the other peers about its connection
requests.

1: The client makes a request; ProxySG 1 intercepts the connection.
2: Because ProxySG 1 and ProxySG 2 are peers in the TCP forwarding cluster, ProxySG 1
informs ProxySG 2 about the connection request.
3: ProxySG 1 terminates the client connection and invokes an outbound connection to the
server (with the client source IP address).
4: Based on its internal routing policies, the server believes ISP 2 provides a viable path
back to the client.
5: ProxySG 2 intercepts the response with the originating client IP address.
6: ProxySG 2 routes the response back up to the internal network.
7: ProxySG 1 receives the response and serves the client.
Figure 4–2

ProxySG appliances share TCP connection information

87

Volume 5: Advanced Networking

About Dynamic Load Balancing
In a deployment where one ProxySG receives all of the traffic originating from
clients and servers from an external routing device and distributes connections to
other ProxySG appliances, TCP connection forwarding enables all of the
appliances to share connection information (for each new connection) and the inline ProxySG routes the request back to the originating appliance, thus lightening
the load on the inline appliance.

Figure 4–3

A ProxySG appliance serving inline as a load balancer

In the above network topography, ProxySG SG 1 is deployed inline to receive all
traffic (by way of a switch) originating from the clients to the servers and servers
to the clients and serves as a load balancer to the other four ProxySG appliances.
Appliances 2 through 5 also have independent connectivity to the clients and the
servers. When all appliances belong to the same peering cluster and have
connection forwarding enabled, appliance SG 1 knows which of the other
appliances made a specific connection and routes the response to that appliance.
In this deployment, a TCP acknowledgement is sent and retransmitted, if
required, to ensure the information gets there, but each new connection message
is not explicitly acknowledged. However, if the ProxySG receives packets for a
connection that is unrecognized, the appliance retains those packets for a short
time before deciding whether to forward or drop them, which allows time for a
new connection message from a peer to arrive.
While adding more peers to a cluster increases the connection synchronization
traffic, the added processing power all but negates that increase. You can have
multiple peer clusters, and if you are cognoscente of traffic patterns to and from
each cluster, you can create an effective cluster strategy. The only limitation is that
a ProxySG can only be a peer in one cluster.
The Blue Coat load balancing solution is discussed in greater detail in earlier
sections of this chapter.

88

Chapter 4: TCP Connection Forwarding

About ADN Transparent Tunnel Load Balancing
TCP connection forwarding is a critical component of the Blue Coat ADN
transparent tunnel load balancing deployment. Achieving efficient load balancing
is difficult when ADN transparent tunneling is employed and an external load
balancer is distributing requests to multiple ProxySG appliances.
A user-noticeable performance degradation occurs if the router, switch, or load
balancer sends traffic to a ProxySG that has not been servicing a particular client
long enough to build up substantial byte caching dictionary, thus the compression
ratio is low. When the ProxySG appliances connected to the routing device belong
to the same peer cluster and connection forwarding is enabled, the ADN
managers on each appliance know which of their peers has the best byte caching
dictionary with the client and forwards the request. This is illustrated in the
following diagram.

1: Client 3 in a branch office makes another in a series of requests to a server at a
corporate location.
2: The load balancer forwards a series of requests to ProxySG 2.
3: ProxySG 2 has been servicing Client 3 and the ADN Manager has built up a substantial
compression ratio with ProxySG at the corporate location.
4: ProxySG 4 contacts the server and sends the response that it receives from the server.
5: The load balancer sends the next request to ProxySG 3.
6: ProxySG 3 knows ProxySG 2 has a better compression ratio with this client, and the
ADN Manager forwards the request over to ProxySG 2.
Figure 4–4

ADN Transparent Tunnel load balancing with Connection Forwarding enabled

89

Volume 5: Advanced Networking
Load balancing is based on the IP address of the remote ADN peer. This assures
that all the traffic from a particular ADN peer to the local ADN cluster always
goes to a specific local ProxySG, thus eliminating the inefficiency of keeping
dictionaries for that remote peer on more than one local ProxySG.
The Blue Coat ADN solution is discussed in greater detail in Chapter 2:
"Configuring an Application Delivery Network" on page 17.

TCP Configuration Forwarding Deployment Notes
When configuring your network for TCP connection forwarding, consider the
following:


Peers can be added to clusters at any time without affecting the performance
of the other peers. A ProxySG that joins a peer cluster immediately contacts
every other peer in the cluster. Likewise, a peer can leave a cluster at anytime.
This might be a manual drop or a forced drop because of a hardware or
software failure. If this happens, the other peers in the cluster continue to
process connection forwarding requests.



Connections between peers are not encrypted and not authenticated. If you do
not assign the correct local IP address on a ProxySG with multiple IP
addresses, traffic sent peer to peer might be routed through the Internet, not
the intranet, exposing your company-sensitive data.



The peering port—the connection between ProxySG connection forwarding
peers—cannot be configured with bypass services. This means a ProxySG
cannot be deployed in transparent mode between two ProxySG appliances
that are peers.



The ProxySG does not enforce a maximum number of appliances a peer
cluster supports, but currently the deployment is designed to function with
up to 20 ProxySG appliances.



Because TCP connection forwarding must function across different network
segments, employing multicasting, even among ProxySG peers on the same
network, is not supported.



There might be a slight overall performance impact from enabling TCP
connection forwarding, especially in deployments where traffic is largely
already being routed to the correct ProxySG. If a substantial amount of traffic
requires forwarding, the performance hit is equitable to processing the same
amount of bridging traffic.

Configuring TCP Connection Forwarding
As described in the previous concept sections, enabling TCP connection
forwarding provides one component to a larger deployment solution. After you
have deployed Blue Coat appliances into the network topography that best fits
your enterprise requirements, enable TCP connection forwarding on each Blue
Coat appliance that is to belong to the peering cluster, and add the IP address of
the other peers. The peer lists on all of the cluster members must be the same, and
a ProxySG cannot have a different local peer IP address than what is listed in
another peers list. A peer list can contain only one local IP address.

90

Volume 5: Advanced Networking
Clipboard to paste the list of peers, and click Apply. Whichever peer IP address is the

new appliance’s local IP address is pulled out of the list and used as the local IP
address on the new appliance. If a local IP address is not found or if more than
one local IP address is found, the paste fails with an error.

Removing a Peer
A network change or other event might require you to remove a peer from the
cluster. Highlight a peer IP address and click Remove. The peer connection is
terminated and all connections associated with the peer are removed from the
local system.
Note: A CLI command is available that allows you to disable a peer, which
terminates the communication with other peers, but does not remove the peer
from the cluster. See the next section.

Related CLI Syntax to Configure TCP Connection Forwarding


To enter configuration mode:
SGOS# (config) connection-forwarding



The following subcommands are available:
SGOS#
SGOS#
SGOS#
SGOS#
SGOS#



(config
(config
(config
(config
(config

connection
connection
connection
connection
connection

forwarding)
forwarding)
forwarding)
forwarding)
forwarding)

add ip_address
port number
[enable | disable]
[clear | remove ip_address]
[view | exit]

The following configuration and statistics commands are available:
SGOS# show connection-forwarding configuration
SGOS# show connection-forwarding statistics

92

Chapter 5: Bandwidth Management

Bandwidth management (BWM) allows you to classify, control, and limit the
amount of bandwidth used by different classes of network traffic flowing into
or out of the ProxySG appliance. Network resource sharing (or link sharing) is
accomplished by using a bandwidth-management hierarchy where multiple
traffic classes share available bandwidth in a controlled manner.
Note: The ProxySG does not attempt to reserve any bandwidth on the network

links that it is attached to or otherwise guarantee that the available bandwidth
on the network can sustain any of the bandwidth limits which have been
configured on it. The ProxySG can only shape the various traffic flows passing
through it, and prioritize some flows over others according to its configuration.
By managing the bandwidth of specified classes of network traffic, you can
accomplish the following:


Guarantee that certain traffic classes receive a specified minimum amount
of available bandwidth.



Limit certain traffic classes to a specified maximum amount of bandwidth.



Prioritize certain traffic classes to determine which classes have priority
over available bandwidth.

Topics in this Chapter
This chapter includes information about the following topics:


"Bandwidth Management Overview" on page 93



"Configuring Bandwidth Allocation" on page 98



"Bandwidth Management Statistics" on page 102



"Using Policy to Manage Bandwidth" on page 104

Bandwidth Management Overview
To manage the bandwidth of different types of traffic that flow into, out of, or
through the ProxySG, you must do the following:


Determine how many bandwidth classes you need and how to configure
them to accomplish your bandwidth management goals. This includes
determining the structure of one or more bandwidth hierarchies if you
want to use priority levels to manage bandwidth.



Create and configure bandwidth classes accordingly.



Create policy rules using those bandwidth classes to identify and classify
the traffic in the ProxySG.

93

Volume 5: Advanced Networking


Enable bandwidth management.

Bandwidth management configuration consists of two areas:


Bandwidth allocation
This is the process of creating and configuring bandwidth classes and placing
them into a bandwidth class hierarchy. This process can be done using either
the Management Console or the CLI.



Flow classification
This is the process of classifying traffic flows into bandwidth management
classes using policy rules. Policy rules can classify flows based on any criteria
testable by policy. You can create policy rules using either the Visual Policy
Manager (VPM), which is accessible through the Management Console, or by
composing Content Policy Language (CPL).

Note: For more information about using VPM to create policy rules, refer to
Volume 6: The Visual Policy Manager and Advanced Policy. For information about
composing CPL, refer to Volume 10: Content Policy Language Guide.

Allocating Bandwidth
The process of defining bandwidth classes and grouping them into a bandwidth
class hierarchy is called bandwidth allocation. Bandwidth allocation is based on:


the placement of classes in a hierarchy (the parent/child relationships).



the priority level of classes in the same hierarchy.



the minimum and/or maximum bandwidth setting of each class.

For example deployment scenarios, see "Bandwidth Allocation and VPM
Examples" on page 106.

Bandwidth Classes
To define a bandwidth class, you create the class, giving it a name meaningful to
the purpose for which you are creating it. You can configure the class as you
create it or edit it later. The available configuration settings are:

94



Parent: Used to create a bandwidth-management hierarchy.



Minimum Bandwidth: Minimum amount of bandwidth guaranteed for traffic
in this class.



Maximum Bandwidth: Maximum amount of bandwidth allowed for traffic in
this class.



Priority: Relative priority level among classes in the same hierarchy.

Chapter 5: Bandwidth Management

Parent Class
A parent class is a class that has children. When you create or configure a
bandwidth class, you can specify another class to be its parent (the parent class
must already exist). Both classes are now part of the same bandwidth-class
hierarchy, and so are subject to the hierarchy rules (see "Class Hierarchy Rules
and Restrictions" on page 96).

Minimum Bandwidth
Setting a minimum for a bandwidth class guarantees that class receives at least
that amount of bandwidth, if the bandwidth is available. If multiple hierarchies
are competing for the same available bandwidth, or if the available bandwidth is
not enough to cover the minimum, bandwidth management is not be able to
guarantee the minimums defined for each class.
Note: The ProxySG does not attempt to reserve any bandwidth on the network
links that it is attached to or otherwise guarantee that the available bandwidth on
the network can be used to satisfy bandwidth class minimums. The ProxySG can
only shape the various traffic flows passing through it, and prioritize some flows
over others according to its configuration.

Maximum Bandwidth
Setting a maximum for a bandwidth class puts a limit on how much bandwidth is
available to that class. It does not matter how much bandwidth is available; a class
can never receive more bandwidth than its maximum.
To prevent a bandwidth class from using more than its maximum, the ProxySG
inserts delays before sending packets associated with that class until the
bandwidth used is no more than the specified maximum. This results in queues of
packets (one per class) waiting to be sent. These queues allow the ProxySG to use
priority settings to determine which packet is sent next. If no maximum
bandwidth is set, every packet is sent as soon as it arrives, so no queue is built and
nothing can be prioritized.
Unlike minimums and priority levels, the maximum-bandwidth setting can
purposely slow down traffic. Unused bandwidth can go to waste with the
maximum-bandwidth setting, while the minimum-bandwidth settings and
priority levels always distributes any unused bandwidth as long as classes
request it. However, priority levels are not meaningful without a maximum
somewhere in the hierarchy. If a hierarchy has no maximums, any class in the
hierarchy can request and receive any amount of bandwidth regardless of its
priority level.

Priority
When sharing excess bandwidth with classes in the same hierarchy, the class with
the highest priority gets the first opportunity to use excess bandwidth. When the
high-priority class uses all the bandwidth it needs or is allowed, the next class
gets to use the bandwidth, if any remains. If two classes in the same hierarchy
have the same priority, then excess bandwidth is shared in proportion to their
maximum bandwidth setting.

95

Volume 5: Advanced Networking

Class Hierarchies
Bandwidth classes can be grouped together to form a class hierarchy. Creating a
bandwidth class allows you to allocate a certain portion of the available
bandwidth to a particular type of traffic. Putting that class into a bandwidth-class
hierarchy with other bandwidth classes allows you to specify the relationship
among various bandwidth classes for sharing available (unused) bandwidth.
The way bandwidth classes are grouped into the bandwidth hierarchy determines
how they share available bandwidth among themselves. You create a hierarchy so
that a set of traffic classes can share unused bandwidth. The hierarchy starts with
a bandwidth class you create to be the top-level parent. Then you can create other
bandwidth classes to be the children of the parent class, and those children can
have children of their own.
To manage the bandwidth for any of these classes, some parent in the hierarchy
must have a maximum bandwidth setting. The classes below that parent can then
be configured with minimums and priority levels to determine how unused
bandwidth is shared among them. If none of the higher level classes have a
maximum bandwidth value set, then bandwidth flows from the parent to the
child classes without limit. In that case, minimums and priority levels are
meaningless, because all classes get all the bandwidth they need at all times. The
bandwidth, in other words, is not being managed.

Class Hierarchy Rules and Restrictions
Certain rules and restrictions must be followed to create a valid BWM class
hierarchy:


Each traffic flow can only belong to one bandwidth management class.
You can classify multiple flows into the same bandwidth class, but any given
flow is always counted as belonging to a single class. If multiple policy rules
match a single flow and attempt to classify it into multiple bandwidth classes,
the last classification done by policy applies.

96



When a flow is classified as belonging to a bandwidth class, all packets
belonging to that flow are counted against that bandwidth class.



If a minimum bandwidth is configured for a parent class, it must be greater
than or equal to the sum of the minimum bandwidths of its children.



If a maximum bandwidth is configured for a parent class, it must be greater
than or equal to the largest maximum bandwidth set on any of its children. It
must also be greater than the sum of the minimum bandwidths of all of its
children.



The minimum bandwidth available to traffic directly classified to a parent
class is equal to its assigned minimum bandwidth minus the minimum
bandwidths of its children. For example, if a parent class has a minimum
bandwidth of 600 kbps and each of its two children have minimums of 300
kbps, the minimum bandwidth available to traffic directly classified into the
parent class is 0.

Chapter 5: Bandwidth Management

Relationship among Minimum, Maximum, and Priority Values
Maximum values can be used to manage bandwidth for classes whether or not
they are placed into a hierarchy. This is not true for minimums and priorities,
which can only manage bandwidth for classes that are placed into a hierarchy.
Additionally, a hierarchy must have a maximum configured on a high-level
parent class for the minimums and priorities to manage bandwidth.
This is because, without a maximum, bandwidth goes to classes without limit and
there is no point to setting priorities or minimum guarantees. Bandwidth cannot
be managed unless a maximum limit is set somewhere in the hierarchy.
When a hierarchy has a maximum on the top-level parent and minimums,
maximums and priorities placed on the classes related to that parent, the
following conditions apply:


If classes in a hierarchy have minimums, the first thing that happens with
available bandwidth is that all the minimum requests are satisfied. If the
amount requested is less than the minimum for any class, it receives the entire
amount, and its priority level does not matter.
Even though a minimum is considered to be a guaranteed amount of
bandwidth, satisfying minimums is dependent on the parent being able to
receive its own maximum, which is not guaranteed.



When all of the classes in a hierarchy have had their minimums satisfied, any
additional requests for bandwidth must be obtained. When a class requests
more than its minimum, it must obtain bandwidth from its parent or one of its
siblings. If, however, a class requests more than its maximum, that request is
denied—no class with a specified maximum is ever allowed more than that
amount.



If a class does not have a minimum specified, it must obtain all of the
bandwidth it requests from its parents or siblings, and it cannot receive any
bandwidth unless all of the minimums specified in the other classes in its
hierarchy are satisfied.



Classes obtain bandwidth from their parents or siblings based on their
priority levels—the highest priority class gets to obtain what it needs first,
until either its entire requested bandwidth is satisfied or until it reaches its
maximum. After that, the next highest priority class gets to obtain bandwidth,
and this continues until either all the classes have obtained what they can or
until the maximum bandwidth available to the parent has been reached. The
amount available to the parent can sometimes be less than its maximum,
because the parent must also participate in obtaining bandwidth in this way
with its own siblings and/or parent if it is not a top-level class.

97

Volume 5: Advanced Networking

Flow Classification
You can classify flows to BWM classes by writing policy rules that specify the
bandwidth class that a particular traffic flow belongs to. A typical transaction has
four traffic flows:
1. Client inbound—Traffic flowing into the ProxySG from a client (the entity
sending a request, such as a client at a remote office linked to the appliance).
2. Server outbound—Traffic flowing out of the ProxySG to a server.
3. Server inbound—Traffic flowing back into the appliance from a server (the
entity responding to the request).
4. Client outbound—Traffic flowing back out of the appliance to a client.
The figure below shows the traffic flows between a client and server through the
ProxySG.

Some types of traffic can flow in all four directions. The following example
describes different scenarios that you might see with an HTTP request. A client
sends a GET to the ProxySG (client inbound). The appliance then forwards this
GET to a server (server outbound). The server responds to the ProxySG with the
appropriate content (server inbound), and then the appliance delivers this content
to the client (client outbound).
Policy allows you to configure different classes for each of the four traffic flows.
See "Using Policy to Manage Bandwidth" on page 104 for information about
classifying traffic flows with policy.

Configuring Bandwidth Allocation
You can use either the Management Console or the CLI to do the following tasks:

98



Enable or disable bandwidth management.



Create and configure bandwidth classes.



Delete bandwidth classes.



View bandwidth management class configurations.

Chapter 5: Bandwidth Management

Note: If you plan to manage the bandwidth of streaming media protocols
(Windows Media, Real Media, or QuickTime), you might want to use the
streaming features instead of the bandwidth management features described in
this section. For most circumstances, Blue Coat recommends that you use the
streaming features to control streaming bandwidth rather than the bandwidth
management features. For information about the differences between these two
methods, refer to Volume 3: Web Communication Proxies.

Enabling Bandwidth Management
The following procedures explain how to enable or disable bandwidth
management.
To enable bandwidth management:

1. Select Configuration > Bandwidth Management > BWM Classes > Bandwidth Classes.

2. Select Enable Bandwidth Management.
3. Click Apply.

Creating, Editing, and Deleting Bandwidth Classes
The following procedure details how to create bandwidth management class.
To create a BWM class:

1. Select Configuration > Bandwidth Management > BWM Classes > Bandwidth Classes.

99

Chapter 5: Bandwidth Management
To edit a BWM class:

1. Select Configuration > Bandwidth Management > BWM Classes > Bandwidth Classes.
2. Highlight the class and click Edit.
3. Edit the fields as appropriate.
To delete a BWM class:
Note: You cannot delete a class that is referenced by another class or by the

currently installed policy. For instance, you cannot delete a class that is the parent
of another class or one that is used in an installed policy rule. If you attempt to do
so, a message displays explaining why this class cannot be deleted.
1. Select Configuration > Bandwidth Management > BWM Classes > Bandwidth Classes.
2. Highlight the class to delete and Delete.
3. Click Yes to delete the class.
4. Click Apply.

Viewing Bandwidth Management Configurations
You can view the following bandwidth class configurations:


Level in the hierarchy (parent/child relationships)



Priority level



Maximum bandwidth value



Minimum bandwidth value

To view BWM configuration:

1. Select Configuration > Bandwidth Management > BWM Classes > Bandwidth Classes.
On this tab, you can view a class’s minimum, maximum and priority value.
Top level classes are visible—classes with children have a folder icon on the
left.
2. To view the configurations of the child class(es) of a class, double-click the
folder icon.
The child classes become visible. A second double-click closes the folder.

Related CLI Syntax to Configure Bandwidth Management


To enter configuration mode:
SGOS#(config) bandwidth-management



The following subcommands are available:
SGOS#(config bandwidth-management) enable | disable
SGOS#(config bandwidth-management) create | delete bwm_class



To enter edit mode:
SGOS#(config bandwidth-management) edit bwm_class

101

Volume 5: Advanced Networking


The following subcommands are available:
SGOS#(config bw-class bwm_class) min-bandwidth minimum_in_kbps
SGOS#(config bw-class bwm_class) max-bandwidth maximum_in_kbps
SGOS#(config bw-class bwm_class) priority value_from_0_to_7
bandwidth-management bwm_class) no {min-bandwidth | max-bandwidth}
SGOS#(config bandwidth-management bwm_class) parent parent_class_name
-orSGOS#(config bandwidth-management bwm_class) no parent
SGOS#(config bandwidth-management bwm_class) view

Bandwidth Management Statistics
The bandwidth management statistics tabs (Current Class Statistics and Total
Class Statistics) display the current packet rate and total number of packets
served, the current bandwidth rate, and the total number of bytes served and
packets dropped.

Current Class Statistics Tab
The Current Class Statistics tab displays the following information for each
bandwidth class:


Current Packet Rate:



Current Bandwidth:

current packets-per-second (pps) value.

current bandwidth in kilobits per second (Kbps).

To view current bandwidth management class statistics:

1. Select Statistics > Bandwidth Management > Current Class Statistics.
The high level bandwidth classes and their statistics are visible.

2. To view the statistics of child bandwidth classes, double-click the folder icon
of the parent class.
The child classes become visible. A second double-click closes the folder.

102

Chapter 5: Bandwidth Management

Total Class Statistics Tab
The Total Class Statistics tab displays the following information for each bandwidth
class:


Packets:



Bytes: the



Drops:

the total number of packets served.
total number of bytes served.

the total number of packets dropped.

To view total bandwidth management class statistics:

1. Select Statistics > Bandwidth Management > Total Class Statistics.
The high level bandwidth classes and their statistics are visible.

2. To view the statistics of child bandwidth classes, double-click the folder icon
of the parent class. A second double-click closes the folder.

Bandwidth Management Statistics in the CLI
To view bandwidth management statistics:

1. To view all bandwidth management statistics, enter the following commands
at the prompt:
SGOS#(config) bandwidth-management
SGOS#(config bandwidth-management) view statistics

2. To view the BWM statistics for a specific class, enter the following command
at the (config) command prompt:
SGOS#(config bandwidth-management) view statistics bwm_class

103

Volume 5: Advanced Networking

Example
SGOS#(config bandwidth-management) view statistics http
Class Name:
http
Parent:

Minimum Bandwidth:
unspecified
Maximum Bandwidth:
unlimited
Priority:
0
Total Bytes:
0 bytes
Total Packets:
0 pkts
Dropped Packets:
0 pkts
Current Bandwidth:
0 kbps
Current Packet Rate: 0 pps
Queue Length:
0 bytes
Parent

The class name of the parent of this class.

Minimum Bandwidth

The maximum bandwidth setting for this class.

Maximum Bandwidth

The minimum bandwidth setting for this class.

Priority

The priority level for this class.

Total Bytes

The total number of bytes served.

Total Packets

The total number of packets served.

Dropped Packets

Total number of packets dropped (packets in the queue
that are dropped because the queue length is reached).

Current Bandwidth

Current bandwidth value (in kilobits per second).

Current Packet Rate

Current packets-per-second value.

Queue Length

Maximum length allowed for the queue of packets that
lack available bandwidth but are waiting for bandwidth to
become available.

To clear bandwidth management statistics:

1. To clear bandwidth management statistics for all bandwidth management
classes, enter the following command at the prompt:
SGOS# clear-statistics bandwidth-management

2. To clear bandwidth management statistics for a particular class, enter the
following command at the prompt:
SGOS# clear-statistics bandwidth-management class bandwidth_class_name

Using Policy to Manage Bandwidth
After creating and configuring bandwidth management classes, create policy
rules to classify traffic flows using those classes. Each policy rule can only apply
to one of four traffic flow types:

104



Client inbound



Client outbound



Server inbound

Chapter 5: Bandwidth Management



Server outbound

You can use the same bandwidth management classes in different policy rules;
one class can manage bandwidth for several types of flows based on different
criteria. However, any given flow is always be counted as belonging to a single
class. If multiple policy rules match a flow and try to classify it into multiple
bandwidth classes, the last classification done by policy applies.
To manage the bandwidth classes you have created, you can either compose CPL
(see "CPL Support for Bandwidth Management" on page 105 below) or you can
use VPM (see "VPM Support for Bandwidth Management" on page 105). To see
examples of policy using these methods, see "Bandwidth Allocation and VPM
Examples" on page 106 or "Policy Examples: CPL" on page 113.

CPL Support for Bandwidth Management
You must use policy to classify traffic flows to different bandwidth classes. Refer
to Volume 10: Content Policy Language Guide for more information about writing
and managing policy.

CPL Triggers
You can use all of the CPL triggers for BWM classification (refer to Volume 10:
Content Policy Language Guide for information about using CPL triggers). Basing a
bandwidth decision on a trigger means that the decision does not take effect until
after the information needed to make that decision becomes available. For
example, if you set the CPL to trigger on the MIME type of the HTTP response,
then the HTTP headers must be retrieved from the OCS before a classification can
occur. The decision to retrieve those headers occurs too late to count any of the
request bytes from the client or the bytes in the HTTP response headers. However,
the decision affects the bytes in the body of the HTTP response and any bytes sent
back to the client.

Supported CPL
Bandwidth class can be set with policy on each of these four traffic flows:
| bwm_class)



limit_bandwidth.client.inbound(none



limit_bandwidth.client.outbound(none



limit_bandwidth.server.inbound(none



limit_bandwidth.server.outbound(none

| bwm_class)

| bwm_class)
| bwm_class)

If you set policy to none, the traffic is unclassified and is not to be bandwidthmanaged.

VPM Support for Bandwidth Management
You can manage bandwidth using VPM in the Action column of four policy layers:
Web Access, DNS Access, Web Content, and Forwarding Layers. For more
information about using VPM to manage bandwidth, refer to Volume 6: The Visual
Policy Manager and Advanced Policy. For examples of bandwidth management
scenarios using VPM, see "Bandwidth Allocation and VPM Examples" below.

105

Volume 5: Advanced Networking

Bandwidth Allocation and VPM Examples
This section illustrates how to use the VPM to allocate bandwidth, arrange
hierarchies, and create policy. It describes an example deployment scenario and
the tasks an administrator must accomplish to manage the bandwidth for this
deployment. For specific instructions about allocating bandwidth, see
"Configuring Bandwidth Allocation" on page 98. For examples of CPL bandwidth
management tasks, see "Policy Examples: CPL" on page 113.

Task One: Bandwidth Allocation
The administrator is responsible for managing the bandwidth of three branch
offices. He was told to ensure that each office uses no more than half of its total
link bandwidth for Web and FTP traffic. The total link bandwidth of each office is
as follows:


Office A: 1.5 Mb



Office B: 1 Mb



Office C: 2 Mb

He creates one bandwidth class for each of the three offices and configures the
maximum bandwidth to an amount equal to half of the total link bandwidth of
each, as shown below. He also creates policy rules for each class, as described
below in "Task One: VPM".

Each of the classes above has a maximum set at an amount equal to half of the
total link bandwidth for each office. A hierarchy does not exist in this scenario.

Task One: VPM
The administrator has created one bandwidth class for each office, setting a
maximum bandwidth on each one equal to the half of the total link bandwidth of
each. Now he must create policy rules to classify the traffic flows.

106

Chapter 5: Bandwidth Management

The administrator launches the VPM and creates a new Web Access Layer,
naming it FTP/HTTP Limitations. He selects the Client IP Address/Subnet object in the
Source column, filling in the IP address and mask of the subnet used by Office_A.

He selects a Combined Service Object in the Service column, naming it FTP/HTTP and
adding a Client Protocol for FTP and for HTTP.

107

Volume 5: Advanced Networking

He adds both protocols to the At least one of these objects field.

In the Action column, he selects Manage Bandwidth, naming it Office_A and setting it
to manage the bandwidth of Office_A on the Client side in the Outbound direction.
He adds two more similar rules for the other two offices. He is able to reuse the
same Combined Service Object in the Service column, but must add new objects
specific to each office in the Source and Action columns. The order of the rules does
not matter here, because each office, and thus each rule, is distinct because of its
IP address/subnet mask configuration.

Task Two: Bandwidth Allocation
A few days later, the administrator gets a visit from the CEO of his company. She
wants him to fix it so that she can visit any of the branch offices without having
her own Web and FTP access slowed down unnecessarily.
The administrator creates two more classes for each office: one for the CEO and
another for everyone else (employees). He sets the parent class of each new class
to the appropriate class that he created in Task One. For example, he creates
Emp_A and CEO_A and sets their parent class to Office_A. He also sets a priority
level for each class: 0 (the lowest) for employees and 1 for the CEO. He then uses
VPM to create additional policy rules for the new classes (see "Task Two: VPM" on
page 109). This figure shows the hierarchical relationship among all of the classes.

108

Chapter 5: Bandwidth Management

The administrator now has three separate hierarchies. In each one, bandwidth is
limited by the configuration of the parent class, and the two child classes are
prioritized to determine how they share any unused bandwidth. Because no
minimums have been set, the highest priority class has the first opportunity to use
all of the available bandwidth; whatever is left then goes to the next priority class.
Priority levels are only effective among the classes in the same hierarchy. This
means that the priority levels for the Office_A hierarchy do not affect the classes in
the Office_B or Office_C hierarchies.

Task Two: VPM
Because the CEO wants to prioritize FTP and HTTP access among employees and
herself, the administrator must create additional bandwidth classes (as described
above in "Task Two: Bandwidth Allocation") and write policy rules to classify the
traffic for the new classes.

He first edits each of the three VPM rules for the three offices. He edits each the
Manage Bandwidth objects, changing the name of the objects to Emp_A, Emp_B,
and Emp_C and changes the bandwidth class to the corresponding employee class.

109

Volume 5: Advanced Networking

Next, he creates three more rules for the CEO, moving them above the first three
rules. For the CEO rules, he selects the same combined FTP/HTTP object in the
Service column; in the Action column, he selects a Manage Bandwidth object
configured for client side/outbound, as before, but this time, he names the objects
CEO_A, CEO_B, and CEO_C and selects the corresponding CEO bandwidth class. In
the Source column, he creates a Combined Source Object, naming it for the CEO. He
combines the Client IP/subnet object already created for each office with a User
object that he creates for the CEO.
The administrator places all three CEO rules above the employee rules, because
the ProxySG looks for the first rule that matches a given situation and ignores the
remaining rules. If he had placed the CEO rules below the employee rules, the
appliance would never get to the CEO rules because the CEO’s Web surfing client
IP address matches both the CEO rules and the employee rules, and the ProxySG
would stop looking after the first match. With the CEO rules placed first, the
appliance applies the CEO rules to the CEO’s Web surfing, and an employee’s
Web surfing does not trigger the CEO rules and instead skips ahead to the
appropriate employee rule.

Task Three: Bandwidth Allocation
It soon becomes apparent that CEO visits are causing problems for the branch
offices. At times, she uses all of the available bandwidth, resulting in decreased
productivity throughout the office she visits. Also, management has complained
that they have been given the same priority for FTP and HTTP traffic as regular
employees, and they are requesting that they be given priority over employees for
this type of traffic.
First, the administrator creates two new classes for each office. In this example, we
look at the classes and configurations for the first office only. He creates a class
called Staff_A and sets a minimum bandwidth of 500 kbps on it. He also creates a
110

Chapter 5: Bandwidth Management

class called Mgmt_A, setting the priority to 1 and the parent to Staff_A. He edits the
class Emp_A, setting the parent to Staff_A. Finally, he edits the class CEO_A,
changing the priority to 2. The resulting hierarchy is illustrated below. To see what
the administrator did to the policy rules, see "Task Three: VPM" on page 111.

In the example illustrated above, employees and management combined are
guaranteed a total of 500 kbps. The CEO’s priority level has no effect until that
minimum is satisfied. This means that the CEO can only use 250 kbps of
bandwidth if the rest of the staff are using a total of 500 kbps. It also means that
the CEO can use 750 kbps if no one else is using bandwidth at the time. In fact,
any of the classes can use 750 kbps if the other classes use none.
Priority levels kick in after all of the minimums are satisfied. In this example, if
the staff requests more than 500 kbps, they can only receive it if the CEO is using
less than 250 kbps. Now notice that the minimum setting for the staff is set on the
parent class, Staff_A, and not on the child classes, Emp_A or Mgmt_A. This means
that the two child classes, representing employees and management, share a
minimum of 500 kbps. But they share it based on their priority levels. This means
that management has priority over employees. The employees are only
guaranteed a minimum if management is using less than 500 kbps.

Task Three: VPM
The administrator has added additional classes for each office and edited the
existing employee classes, as described above in "Task Three: Bandwidth
Allocation" on page 110. One of the new classes he added for each office is a
parent class that does not have traffic classified to it; it was created to provide a
minimum amount of bandwidth to its child classes. Not every class in the
hierarchy has to have a traffic flow. This means that he needs to add just three
more rules for the three new management classes. For the management rules, he
selects the same combined FTP/HTTP object in the Service column; in the Action
column, he selects a Manage Bandwidth object configured for client side/outbound
with the bandwidth class one of the management classes (Mgmt_A, Mgmt_B, or
Mgmt_C). In the Source column, he creates a Combined Source Object containing the
subnet object for the office and the Group object for management.

111

Volume 5: Advanced Networking
The management rules must go above the employee rules, although it does not
matter where they are placed in relation to the CEO rules. This would not be true
if the CEO was part of the same group as management, however. If that were true,
the CEO rules would still need to go on top.

Task Four: Bandwidth Allocation
The administrator decided later that he needed to guarantee employees some
bandwidth. He configures a minimum for the class Emp_A, as illustrated below.

He decides to leave the minimum on the parent class Staff_A and not to set a
minimum for the class Mgmt_A. This is okay, because the minimum of the parent
class is available to its children if the parent class does not use all of it, and the
only way that the CEO can get more than 250 kbps is if the employees and
management combined use less than 500.
This last change does not require additional changes to policy; the administrator
has added a minimum to a class that he has already classified for traffic using
policy.
In the above scenario, the class called Staff_A does not have traffic configured for
it—it was created to guarantee bandwidth minimums for its child classes.
However, if it were configured for traffic, it would have a practical minimum of
300 kbps. The practical minimum of a parent class is equal to its assigned
minimum bandwidth minus the minimums of its children. In that case, if the
parent class Staff_A used 300 kbps and the child class Emp_A used 200 kbps, the
child class Mgmt_A would not receive any bandwidth unless the class CEO_A was
using less than 250 kbps. Under those circumstances, the administrator probably
also needs to create a minimum for management.

Task Five: Bandwidth Allocation
The CEO makes another request, this time for the main office, the one the
administrator himself works from. This office uses the content filtering feature of
the ProxySG to control the types of Web sites that employees are allowed to view.
Although the office uses content filtering, access to sports sites is not restricted
because the CEO is a big fan.

112

Chapter 5: Bandwidth Management

The administrator creates a bandwidth management class called Sports with a
maximum bandwidth of 500 kbps and launches VPM to create policy for this class
as described below.

Task Five: VPM
To classify traffic for the Sports class, the administrator opens VPM, creates a Web
Access Layer, and sets the Destination column to the Category object that includes
sports viewing (content filtering is already set up in VPM). He sets the Action
column to the Manage Bandwidth object, selecting Server side/Inbound and the Sports
bandwidth class he created. After installing the policy and verifying that
bandwidth management is enabled, he is finished.

Policy Examples: CPL
The examples below are complete in themselves. The administrator uses CLI to
create and configure bandwidth management classes and writes CPL to classify
traffic flow for these classes. These examples do not make use of a bandwidth
class hierarchy. For examples of hierarchies, see "Bandwidth Allocation and VPM
Examples" on page 106.

Example One: CPL
In this example, the administrator of a college is asked to prevent college students
from downloading MP3 files during peak hours, while still allowing the music
department to download MP3 files at any time. The CPL triggers used are
authentication and/or source subnet and MIME type. The action taken is to limit
the total amount of bandwidth consumed by students to 40 kbps.
CLI commands:
SGOS#(config) bandwidth-management
SGOS#(config bandwidth-management) create mp3
SGOS#(config bandwidth-management) edit mp3
SGOS#(config bw-class mp3) max-bandwidth 40

CPL:
define condition student_mp3_weekday
client_address=student_subnet response_header.Content-Type="audio/
mpeg" \
weekday=1..5 hour=9..16
end condition

condition=student_mp3_weekday limit_bandwidth.server.inbound(mp3)

Example Two: CPL
In this example, an administrator must restrict the amount of bandwidth used by
HTTP POST requests for file uploads from clients to 2 Mbps. The CPL trigger
used is request method, and the action taken is to throttle (limit) the amount of
bandwidth used by client side posts by limiting inbound client side flows.
CLI:

113

Volume 5: Advanced Networking
SGOS#(config) bandwidth-management
bandwidth-management) create http_post
SGOS#(config bandwidth-management) edit http_post
SGOS#(config bw-class http_post) max-bandwidth 2000

CPL:
define condition http_posts
http.method=POST
end condition

condition=http_posts limit_bandwidth.client.inbound(http_post)

Example Three: CPL
In this example, the administrator of a remote site wants to limit the amount of
bandwidth used to pre-populate the content from headquarters to 50 kbps during
work hours. The CPL triggers used are current-time and pre-population
transactions. The action taken is to limit the total amount of bandwidth consumed
by pre-pop flows.
CLI:
SGOS#(config) bandwidth-management
SGOS#(config bandwidth-management) create pre-pop
SGOS#(config bandwidth-management) edit pre-pop
SGOS#(config bw-class pre-pop) max-bandwidth 50

CPL:
define condition prepop_weekday
content_management=yes weekday=1..5 hour=9..16
end condition

condition=prepop_weekday limit_bandwidth.server.inbound(pre-pop)

114

Chapter 6: Authenticating a ProxySG

This chapter discusses device authentication, which is a mechanism that allows
devices to verify each others’ identity; devices that are authenticated can be
configured to trust only other authenticated devices.
Note: ProxySG authentication is always used in association with other SGOS
features. For example, you can use appliance authentication with the ADN
implementation of secure tunnels. The secure tunnels feature uses
authentication, the process of verifying a device’s identity, with authorization,
the process of verifying the permissions that a device has. For information on
secure tunnels and appliance authentication, see Section E: "Securing the ADN
Network" on page 46.

Introduction
Device authentication is important in several situations:


Securing the network. Devices that are authenticated have exchanged
certification information, verified each others’ identity and know which
devices are trusted.



Securing protocols. Many protocols require authentication at each end of
the connection before they are considered secure.

Topics in this Chapter
This chapter includes information about the following topics:


"ProxySG Appliance Overview"



"Appliance Certificates and SSL Device Profiles" on page 116



"Creating an SSL Device Profile for Device Authentication" on page 122



"Related CLI Syntax to Manage Device Authentication" on page 124



"Obtaining a Non Blue Coat Appliance Certificate" on page 121



"Related CLI Syntax to Manage Device Authentication" on page 124

ProxySG Appliance Overview
The Blue Coat implementation allows devices to be authenticated without
sending passwords over the network. Instead, a device is authenticated
through certificates and SSL device profiles that reference the certificates. Both
the profile and the referenced certificate are required for device authentication.


Certificates: Certificates contain information about a specific device. Blue
Coat runs an Internet-accessible Certificate Authority (CA) for the purpose
of issuing appliance certificates to SGOS devices. You can also create your
own appliance certificates.

115

Volume 5: Advanced Networking


Profiles: A profile is a collection of information used for several purposes,
such as device-to-device authentication or when the ProxySG is an SSL
endpoint for non-proxy traffic.
Three built-in profiles exist: The profile for device authentication is called
bluecoat-appliance-certificate and references the appliance certificate on your
ProxySG. The profile can indicate whether the device has a certificate and if
the certificates of other devices should be verified. You can create other
profiles to change the default settings.

Note: Authenticating the ProxySG appliance and authenticating the ProxySG

appliance server name are two different procedures that require two different
certificates. For information on authenticating server names, refer to Volume 4:
Securing the Blue Coat ProxySG Appliance.

Appliance Certificates and SSL Device Profiles
In the Blue Coat implementation of device authentication, both an appliance
certificate and an SSL device profile that references the appliance certificate
keyring are required for device authentication to be successful. Each device to be
authenticated must have an appliance certificate and a profile that references that
certificate.
Note that device authentication does not take effect unless the SSL device profile
is enabled; for example, if you use WAN optimization, you enable the profile on
the Configuration > ADN > General > Device Security tab.

About ProxySG Appliance Certificates
ProxySG appliances come with a cryptographic key that allows the system to be
authenticated as an ProxySG appliance when an appliance certificate is obtained.
An appliance certificate is an X.509 certificate that contains the hardware serial
number of a specific ProxySG as the CommonName (CN) in the subject field. This
certificate then can be used to authenticate the ProxySG appliance whose
hardware serial number is listed in the certificate. Information from the presented
certificate is extracted and used as the device ID.
Blue Coat runs an Internet-accessible CA for the purpose of issuing appliance
certificates. The root certificate for the Blue Coat CA is automatically trusted by
SGOS for device authentication. These Blue Coat-signed certificates contain no
authorization information and are valid for five years.
You can provide your own device authentication certificates for the ProxySG
appliances on your network if you prefer not to use the Blue Coat CA.

About SSL Device Profiles
An SSL device profile contains the information required for device authentication:


116

The name of the keyring that contains the private key and certificate this
device uses to authenticate itself. The default keyring is appliance-key. (For
information on private and public keys, refer to Volume 4: Securing the Blue
Coat ProxySG Appliance.)

Chapter 6: Authenticating a ProxySG



The name of the CA Certificate List (CCL) that contains the names of
certificates of CAs trusted by this profile. If another device offers a valid
certificate signed by an authority in this list, the certificate is accepted. The
default is appliance-ccl. For information on CCLs, refer to Volume 4: Securing
the Blue Coat ProxySG Appliance.



Verification of the peer certificate.
When the ProxySG is participating in device authentication as an SSL client,
the peer certificate verification option controls whether the server certificate is
validated against the CCL. If verification is disabled, the CCL is ignored.
When the ProxySG is participating in device authentication as an SSL server,
the peer certificate verification option controls whether to require a client
certificate. If verification is disabled, no client certificate is obtained during the
SSL handshake. The default is verify-peer-certificate enabled.



Specification of how the device ID authorization data is extracted from the
certificate. The default is $(subject.CN).



SSL cipher settings. The default is AES256-SHA.

Each Blue Coat appliance has an automatically-constructed profile called bluecoatappliance-certificate that can be used for device-to-device authentication. This
profile cannot be deleted or edited.
If you cannot use the built-in profile because, for example, you require a different
cipher suite or you are using your own appliance certificates, you must create a
different profile, and have that profile reference the keyring that contains your
certificate.
Note: If you do not want to use peer verification, you can use the built-in passiveattack-detection-only profile

in place of the bluecoat-appliance-certificate profile.

This profile uses a self-signed certificate and disables the verify-peer option, so
that no authentication is done on the endpoints of the connection. The traffic is
encrypted, but is vulnerable to active attacks.
This profile can be used only when there is no threat of an active man-in-themiddle attack. Like the bluecoat-appliance certificate profile, the passive-attackdetection-only profile cannot be edited or deleted.
If you create your own profile, it must contain the same kind of information that is
contained in the Blue Coat profile. To create your own profile, skip to "Creating an
SSL Device Profile for Device Authentication" on page 122.

Obtaining a ProxySG Appliance Certificate
In many cases, if you have Internet connectivity, an appliance certificate is
automatically fetched by the ProxySG, and no human intervention is required. In
other cases, if the Internet connection is delayed or if you do not have Internet
access, you might have to manually initiate the process of obtaining an appliance
certificate.

117

Volume 5: Advanced Networking
How you obtain an appliance certificate depends upon your environment:


If the device to be authenticated has Internet connectivity and can reach the
Blue Coat CA server, continue with "Automatically Obtaining an Appliance
Certificate" on page 118.



If the device to be authenticated cannot reach the Blue Coat CA server, you
must acquire the certificate manually; continue with "Manually Obtaining an
Appliance Certificate" on page 119.

After the certificate is obtained, you must configure the device to use the profile
you choose to use. For information on configuring the device to use the profile,
see Chapter 2: "Configuring an Application Delivery Network".
If you are configuring device authorization as well as authentication, configure
device authentication before authorization. For more information on device
authorization, see Chapter 2: "Configuring an Application Delivery Network".
Important:

Only the following ProxySG platforms support appliance certificates:



SG200 (manufactured after August 1, 2006)



SG210



SG510



SG810



SG8100

If you attempt to obtain an appliance certificate for other platforms (through
Configuration > SSL > Appliance Certificates > Request appliance certificate), the request
fails with the following error message:


Request failed: Signing server reported error: No such serial number serial number.

If you receive this message, you cannot use Blue Coat appliance certificates, but
you can create your own appliance certificates for use in a secure network. For
more information, see "Obtaining a Non Blue Coat Appliance Certificate" on page
121.

Automatically Obtaining an Appliance Certificate
The appliance attempts to get the certificate completely automatically (with no
user intervention) if it can connect to the Blue Coat CA server at boot time or
within about five minutes of being booted. If the appliance does not have a
certificate (for example, it had one until you did a restore-defaults factorydefaults command) it attempts to get one on every boot. Once the appliance gets
a certificate, that certificate is used until another restore-defaults factorydefaults command is issued.
If Internet connectivity is established more than five minutes after the system is
booted, you might need to complete the following steps.

118

Chapter 6: Authenticating a ProxySG
To automatically obtain an appliance certificate:

1. Select Configuration > SSL > Appliance Certificates > Request Certificate.
2. Click Request appliance certificate.
The Blue Coat CA server does validation checks and signs the certificate. The
certificate is automatically placed in the appliance-key keyring. Note that the
appliance-key keyring cannot be backed up. The keyring is re-created if it is
missing at boot time.

Manually Obtaining an Appliance Certificate
Complete the following steps to obtain an appliance certificate manually. The
overview of the procedure is to:


Generate a appliance certificate signing request and send it to the Blue Coat
CA server for verification and signature.



Import the signed certificate into the ProxySG.

To generate a CSR:

1. Select Configuration > SSL > Appliance Certificates > Request Certificate.
2. Select Create CSR.

3. Copy the certificate request, including the certificate request signature. Be
sure to include the Begin Certificate and End Certificate statements, as
well as the Begin CSR Signature and End CSR Signature statements.
4. Click OK.
5. Go to the Blue Coat CA Server Website at https://abrca.bluecoat.com/signmanual/index.html.

119

Volume 5: Advanced Networking

6. Paste the CSR and signature into the CSR panel.
7. Click Generate Cert.
The signed certificate displays, and can be pasted into the appliance-key
keyring.
-----BEGIN CERTIFICATE----MIIF/jCCBOagAwIBAgICAMowDQYJKoZIhvcNAQEFBQAwgbYxCzAJBgNVBAYTAlVT
MRMwEQYDVQQIEwpDYWxpZm9ybmlhMRIwEAYDVQQHEwlTdW5ueXZhbGUxIDAeBgNV
BAoTF0JsdWUgQ29hdCBTeXN0ZW1zLCBJbmMuMRkwFwYDVQQLExBCbHVlIENvYXQs
IEFCUkNBMRswGQYDVQQDExJhYnJjYS5ibHVlY29hdC5jb20xJDAiBgkqhkiG9w0B
CQEWFXN5c2FkbWluQGJsdWVjb2F0LmNvbTAeFw0wNzAxMjkyMDM5NDdaFw0xMjAx
MjkyMDM5NDdaMIGGMQswCQYDVQQGEwJVUzELMAkGA1UECBMCQ0ExEjAQBgNVBAcT
CVN1bm55dmFsZTEgMB4GA1UEChMXQmx1ZSBDb2F0IFN5c3RlbXMsIEluYy4xHzAd
BgNVBAsTFkJsdWUgQ29hdCBTRzIwMCBTZXJpZXMxEzARBgNVBAMTCjA1MDUwNjAw
OTIwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAMBUmCuKSsSd+D5kJQiWu3OG
DNLCvf7SyKK5+SBCJU2iKwP5+EfiQ5JsScWJghtIo94EhdSC2zvBPQqWbZAJXN74
k/yM4w9ufjfo+G7xPYcMrGmwVBGnXbEhQkagc1FH2orINNY8SVDYVL1V4dRM+0at
YpEiBmSxipmRSMZL4kqtAgMBAAGjggLGMIICwjAJBgNVHRMEAjAAMAsGA1UdDwQE
AwIE8DBOBgNVHSUERzBFBggrBgEFBQcDAQYIKwYBBQUHAwIGCCsGAQUFBwMEBgsr
BgEEAfElAQECAQYLKwYBBAHxJQEBAgIGCysGAQQB8SUBAQIDMB0GA1UdDgQWBBSF
NqC2ubTI7OT5j+KqCPGlSDO7DzCB6wYDVR0jBIHjMIHggBSwEYwcq1N6G1ZhpcXn
OTIu8fNe1aGBvKSBuTCBtjELMAkGA1UEBhMCVVMxEzARBgNVBAgTCkNhbGlmb3Ju
aWExEjAQBgNVBAcTCVN1bm55dmFsZTEgMB4GA1UEChMXQmx1ZSBDb2F0IFN5c3Rl
bXMsIEluYy4xGTAXBgNVBAsTEEJsdWUgQ29hdCwgQUJSQ0ExGzAZBgNVBAMTEmFi

120

Chapter 6: Authenticating a ProxySG

cmNhLmJsdWVjb2F0LmNvbTEkMCIGCSqGSIb3DQEJARYVc3lzYWRtaW5AYmx1ZWNv
YXQuY29tggkAhmhbUPEEb60wgZ8GCCsGAQUFBwEBBIGSMIGPMEkGCCsGAQUFBzAB
hj1odHRwczovL2FicmNhLmJsdWVjb2F0LmNvbS9jZ2ktYmluL2RldmljZS1hdXRo
ZW50aWNhdGlvbi9vY3NwMEIGCCsGAQUFBzAChjZodHRwOi8vYWJyY2EuYmx1ZWNv
YXQuY29tL2RldmljZS1hdXRoZW50aWNhdGlvbi9jYS5jZ2kwSAYDVR0fBEEwPzA9
oDugOYY3aHR0cDovL2FicmNhLmJsdWVjb2F0LmNvbS9kZXZpY2UtYXV0aGVudGlj
YXRpb24vQ1JMLmNybDBfBgNVHSAEWDBWMFQGCisGAQQB8SUBAQEwRjBEBggrBgEF
BQcCARY4aHR0cDovL2FicmNhLmJsdWVjb2F0LmNvbS9kZXZpY2UtYXV0aGVudGlj
YXRpb24vcnBhLmh0bWwwDQYJKoZIhvcNAQEFBQADggEBACIhQ7Vu6aGJBpxP255X
d2/Qw7NiVsnqOlAy913QZlieFfVATJnCeSrH+M9B/2XtnRxVT0/ZWrf4GbsdYqTF
hc9jR/IwKu6kZq32Dqo8qFU5OzbAEzT2oebB5QgwuJtHcJHggp9PS9uS27qAnGQK
OeB2bYcjWtMvTvr50iDOV69BEQz+VXos8QiZmRHLVnebQSjl3bi1w3VjBw31tCmc
clgz0SlN9ZmJdRU/PlWdNVqD4OLqcMZQ53HqcdWNEzN2uvigIb//rM7XazK7xIaq
r23/+BsZlYKAeVMq3PEmxaA2zLzO+jf79a8ZvIKrF27nNuTN7NhFL/V6pWNE1o9A
rbs=
-----END CERTIFICATE-----

To import a certificate onto the ProxySG appliance:

1. Copy the certificate to your clipboard. Be sure to include the Begin
Certificate and End Certificate statements.
2. Select Configuration > SSL > Keyrings.
3. Select the keyring that is used for device authentication. The keyring used by
the bluecoat-appliance-certificate profile is the appliance-key keyring.
4. Click Edit in the Keyrings tab.
5. In the Certificate panel, click Import.
6. Paste the certificate you copied into the dialog box.
7. Click Close.

Obtaining a Non Blue Coat Appliance Certificate
If you run your own certificate signing authority for device authentication,
complete the following steps:
1. Create a keyring for the appliance's certificate. For information on creating a
keyring, refer to Volume 4: Securing the Blue Coat ProxySG Appliance.
2. Generate the certificate signing request and get it signed. For information on
creating a CSR, refer to Volume 4: Securing the Blue Coat ProxySG Appliance.

121

Volume 5: Advanced Networking

Note: You cannot put a Blue Coat appliance certificate into a keyring you

create yourself.
3. Create a CA certificate list.For information on creating a CCL, refer to Volume
4: Securing the Blue Coat ProxySG Appliance.
a. Import the CA's root certificate.
b. Add the certificate to the CCL.
4. Create a device authentication profile. (To create a profile, see "Appliance
Certificates and SSL Device Profiles" on page 116.)
5. Associate the profile with the keyring and CCL. The keyring and CCL must
already exist.
Adjust other parameters, including authorization data extractor (if the
certificate is to be used for authorization), as needed.
Configure each application that uses device authentication to reference the newly
created profile, and set up its whitelist. To associate the device with the profile, see
Chapter 2: "Configuring an Application Delivery Network".

Creating an SSL Device Profile for Device Authentication
An SSL device profile only needs to be created if you cannot use the built-in
bluecoat-appliance-certificate profile without modification; note that the bluecoatappliance-certificate profile cannot be deleted or edited.
Additional profiles with different settings can be created; for example, if you
require a different cipher setting than what the bluecoat-appliance-certificate profile
uses, you can create a profile with the different cipher suite.
To create a new authentication profile:

1. Select Configuration > SSL > Device Profiles > Profiles.
2. Click New.

122

Chapter 6: Authenticating a ProxySG

3. Name: Give the profile a meaningful name. The only valid characters are
alphanumeric, the underscore, and hyphen, and the first character must be a
letter.
4. SSL protocol versions: Change the default from SSLv2v3TLSv1 to any other
protocol listed in the drop-down list.
5. Keyring: From the drop-down list, select the keyring you want to use for device
authentication.
Note: ou must create a new keyring for device authentication if you do not use

the appliance-key keyring. The keyrings shipped with the ProxySG are dedicated
to other purposes. For information on creating a new keyring, refer to Volume 4:
Securing the Blue Coat ProxySG Appliance.
6. CCL: From the drop-down list, select the CA Certificate List you want to use.
7. Device ID extractor: The field describes how device ID information is extracted
from a presented certificate. The string contains references to the attributes of
the subject or issuer in the form $(subject.attr[.n]) or $(issuer.attr[.n]),
where attr is the short-form name of the attribute and n is the ordinal
instance of that attribute, counting from 1 when the subject is in LDAP (RFC
2253) order. If n is omitted, it is assumed to be 1.
The default is $(subject.CN); many other subject attributes are recognized,
among them OU, O, L, ST, C, and DC.
8. Verify peer: This setting determines whether peer certificates are verified
against the CCL or whether client certificates are required.

123

Volume 5: Advanced Networking

9. Selected ciphers: To use a different cipher suite:
a. click Edit ciphers.
b. Select the ciphers and click Add to add the cipher to the list of selected
cipher suites. Cipher suites that you do not want to use should be
removed from the selected list.
10. Click OK to close the dialog.
11. Click Apply.

Related CLI Syntax to Manage Device Authentication


To enter configuration mode:
SGOS#(config) ssl



The following SSL device profile commands are available:
SGOS#(config ssl) create ssl-device-profile profile_name keyring_ID
SGOS#(config ssl) edit ssl-device-profile test
SGOS#(config device-profile test) cipher-suite cipher-suite
SGOS#(config device-profile test) ccl ccl_name
SGOS#(config device-profile test) device-id device_ID
SGOS#(config device-profile test) exit
SGOS#(config device-profile test) keyring-id keyring_ID
SGOS#(config device-profile test) protocol {sslv2 | sslv3 | tlsv1 |
sslv2v3 | sslv2tlsv1 | sslv3tlsv1 | sslv2v3tlsv1}
SGOS#(config device-profile test) verify-peer [enable | disable]
SGOS#(config device-profile test) view
SGOS#(config ssl) request-appliance-certificate
SGOS#(config ssl) view appliance-certificate-request
SGOS#(config ssl) view ssl-device-profile

124

Chapter 7: Configuring Failover

Using IP address failover, you can create a redundant network for any explicit
proxy configuration. If you require transparent proxy configuration, you can
create software bridges to use failover. For information on creating software
bridges, refer to Volume 1: Getting Started.
Note: If you use the Pass-Through adapter for transparent proxy, you must

create a software bridge rather than configuring failover. For information on
using the Pass-Through adapter, refer to Volume 1: Getting Started.
Using a pool of IP addresses to provide redundancy and load balancing, Blue
Coat moves these IP addresses among a group of machines.

Topics in this Chapter
This chapter includes information about the following topics:


"About Failover"



"Configuring Failover" on page 126

About Failover
Failover allows a second machine to take over if a first machine (not just an
interface card) fails, providing redundancy to the network through a master/
slave relationship. In normal operations, the master (the machine whose IP
address matches the group name) owns the address. The master sends
keepalive messages (advertisements) to the slaves. If the slaves do not receive
advertisements at the specified interval, the slave with the highest configured
priority takes over for the master. When the master comes back online, the
master takes over from the slave again.
The Blue Coat failover implementation resembles the Virtual Router
Redundancy Protocol (VRRP) with the following exceptions:


A configurable IP multicast address is the destination of the
advertisements.



The advertisement interval is included in protocol messages and is learned
by the slaves.



A virtual router identifier (VRID) is not used.



Virtual MAC addresses are not used.



MD5 is used for authentication at the application level.

125

Volume 5: Advanced Networking
Masters are elected, based on the following factors:


If the failover mechanism is configured for a physical IP address, the machine
owning the physical address have the highest priority. This is not
configurable.



If a machine is configured as a master using a virtual IP address, the master
has a priority that is higher than the slaves.

When a slave takes over because the master fails, an event is logged in the event
log. No e-mail notification is sent.

Configuring Failover
Before you begin, ensure that software bridges already exist. For information on
configuring bridges, refer to Volume 1: Getting Started.
You also must decide which machine is the master and which machines are the
slaves, and whether you want to configure explicit proxy or transparent proxy
network.
When configuring the group, the master and all the systems in the group must
have exactly the same failover configuration except for priority, which is used to
determine the rank of the slave machines. If no priority is set, a default priority of
100 is used. If two appliances have equal priority, the one with the highest
physical address ranks higher.
Note: Configuring failover on an Application Data Network (ADN) is similar to
configuring failover on other appliances, with the exception that you add a server
subnet on multiple boxes instead of just one.
To configure failover:

1. Select Configuration > Network > Advanced > Failover.
2. Click New.

126

Volume 5: Advanced Networking

Related CLI Syntax to Configure Failover


To enter configuration mode:
SGOS#(config) failover



The following subcommands are available:
SGOS#(config failover) create group_address
SGOS#(config failover) edit group_address
SGOS#(config failover group_address) multicast-address
multicast_address
SGOS#(config failover group_address) master
SGOS#(config failover group_address) priority number
SGOS#(config failover group_address) interval seconds
SGOS#(config failover group_address) secret secret
-orSGOS#(config failover group_address) encrypted-secret encrypted_secret
SGOS#(config failover group_address) enable

Viewing Failover Statistics
At any time, you can view statistics for any failover group you have configured
on your system.
To view failover status:

1. Select Statistics > System > Failover.

2. From the drop-down list, select the group to view.
The information displayed includes the multicast address, the local address, the
state, and any flags, where V indicates the group name is a virtual IP address, R
indicates the group name is a physical IP address, and M indicates this machine
can be configured to be the master if it is available.

Troubleshooting
An indication that there may be issues with the election of a master is if
advertisements are not being sent or received by either of the systems in a failover
group.
To troubleshoot, view statistics in the command line interface:
Blue Coat SG200 Series#(config)failover
Blue Coat SG200 Series#(config failover)view statistics
Failover Statistics
Advertisements Received

128

: 0

Chapter 7: Configuring Failover

Advertisements Sent

: 0

States Changes

: 0

Bad Version

: 0

Bad Packet

: 0

Bad Checksum

: 0

Packet Too Short

: 0

Bad Packet Header

: 0

Invalid Group

: 0

Blue Coat SG200 Series#(config failover)

If the statistics illustrate there may be a potential issue, debug further by running
a PCAP on each ProxySG to verify the multicast packets are actually being sent. If
not, verify the multicast address is configured correctly (Configuration > Network >
Advanced > Failover). If both proxies are sending the multicast packets but not
receiving them, it is possible that a switch/router is blocking multicast packets.

129

Volume 5: Advanced Networking

130

Chapter 8: Configuring the Upstream Network Environment

This chapter describes how to configure the ProxySG to interact with both the
local network and with the upstream network environment.

Topics in this Chapter
This chapter includes information about the following topics:


Section A: "Overview" on page 132



Section B: "About Forwarding" on page 133



Section C: "Configuring Forwarding" on page 136



Section D: "Using Forwarding Directives to Create an Installable List" on
page 144

131

Volume 5: Advanced Networking
Section A: Overview

Section A: Overview
To control upstream interaction, the ProxySG appliance supports:

132



The ProxySG forwarding system—Allows you to define the hosts and groups
of hosts to which client requests can be redirected. Those hosts can be servers
or proxies. Rules to redirect requests are set up in policy.



SOCKS gateways—SOCKS servers provide application-level firewall
protection for an enterprise. The SOCKS protocol provides a generic way to
proxy HTTP and other protocols. For information on configuring SOCKS
gateways, see Chapter 13: "SOCKS Gateway Configuration" on page 327.



ICP—ICP handles ICP queries from other caching devices looking for cached
data. The ProxySG appliance also can use ICP. For information on configuring
ICP, see Chapter 9: "Internet Caching Protocol (ICP) Configuration" on page
153.

Chapter 8: Configuring the Upstream Network Environment
Section B: About Forwarding

Section B: About Forwarding
Forwarding allows you to redirect requests to IP addresses other than those
specified in the URL. Forwarding also allows you to organize how the Web traffic
flows around the network. Forwarding does not affect the URL that appears in the
request. It only affects the IP address of the upstream device a request is sent to.
The ProxySG forwarding system consists of forwarding, upstream SOCKS
gateways, load balancing, host affinity, health checks, and ICP. The ProxySG
appliance forwarding system determines the upstream address where a request is
sent, and is tied in with all the protocol agents, including HTTP, HTTPS,
streaming, and FTP, and the network configuration. The combination of
forwarding and the policy engine allows traffic management and flexible
configuration.
Note: The ProxySG forwarding system directly supports the forwarding of HTTP,
HTTPS, FTP, Windows Media, RTSP, Telnet, and TCP tunnels.

About Load Balancing
Load balancing is a way to share traffic requests among multiple upstream systems
or multiple IP addresses on a single host. Load-balancing methods include round
robin, which selects the next system in the list, or least connections, which selects
the system with the least number of connections among the selected group.
You can configure load balancing two ways:


For individual hosts: If a host is DNS-resolved to multiple IP addresses, then
that host's load-balancing method (round robin, least connections, or none) is
applied to those IP addresses. The method is either explicitly set for that host
or taken from the configurable global default settings.



For groups: Load balancing for groups works exactly the same as load
balancing for hosts with multiple IP addresses—the forwarding system
collects all of the IP addresses for all of the hosts in the group and load
balances over that set using the method that is specified. You can also use a
domain or URL hash, as well.

About Host Affinity
Host affinity is the attempt to direct multiple connections by a single user to the
same group member. Host affinity is closely tied to load balancing behavior; both
should be configured if load balancing is important. For example, a Web site uses
shopping carts to allow customers to purchase items. The site might use load
balancing with a group of Web servers working in parallel, but only one server in
the group has information on a single user. If the user connections are sent to a
different server, the server has no previous information on the user and might
start over.

133

Volume 5: Advanced Networking
Section B: About Forwarding

Host affinity forces the user’s connections to return to the same server until the
user is idle. After a configurable period of inactivity, the host affinity times out
and the association of multiple connections with that single user is lost.
Host affinity allows you to use the following options:


Use the client IP address to determine which group member was last used.
When the same client IP sends another request, the host makes the connection
is made to that group member.



Place a cookie in the response to the client. When the client makes further
requests, the cookie data is used to determine which group member the client
last used. The host makes the connection to that group member.



For HTTPS, extract the SSL session ID name from the connection information.
The host uses the session ID in place of a cookie or client IP address to
determine which group member was last used. The host makes the connection
to that group member.

Using Load Balancing with Host Affinity
By default, if you use load balancing, each connection is treated independently.
The connection is made to whichever member of the load-balancing group that
the load-balancing algorithm selects. The load balancing responsibility is to
distribute the connections among group members to share the load.
If host affinity is configured, the system checks host affinity first to see if the
request comes from a known client. If this is a first connection, the load-balancing
algorithm selects the group member to make the connection. Host affinity records
the result of the load balancing and uses it if that client connects again.
Host affinity does not make a connection to a host that health checks report is
down; instead, if host affinity breaks, the load-balancing algorithm selects a group
member that is healthy and re-establishes affinity on that working group member.
Note: You might find it necessary to disable caching for traffic sent to the loadbalanced groups (or hosts if DNS hides a group under one entry) to prevent
copies of customized Web pages being served to a different user.

It is not always necessary to disable caching; for example, load balancing can be
used without host affinity or without disabling caching to distribute load among
several proxies.
However, if caching is enabled for traffic going through load balancing, retrieval
of updated content by the cache is done according to load balancing rules; the
cache does not support host affinity and ignores it if enabled.

134

Chapter 8: Configuring the Upstream Network Environment
Section B: About Forwarding

Host affinity methods are discussed in the table below.
Table 8–1 Host Affinity Methods

Setting

Description

HTTP

SSL

Other (TCP
Tunnel or
Telnet)

Global Default

Use the default setting for all
forwarding hosts on the system.

x

x

x

None

Disables host affinity.

x

x

x

Client IP
Address

Uses the client IP address to
determine which group member
was last used.

x

x

x

Accelerator
Cookie

Inserts a cookie into the
response to the client.

x

x

SSL Session ID

Used in place of a cookie or
client IP address. Extracts the
SSL session ID name from the
connection information.

x

135

Volume 5: Advanced Networking
Section C: Configuring Forwarding

Section C: Configuring Forwarding
High-level steps to configure forwarding are:


Create the forwarding hosts and groups, including parameters such as
protocol agent and port.



Set Load Balancing and Host Affinity values.

Creating Forwarding Hosts and Groups
You can create as many hosts, groups, or members of a group as you need.
To create groups, see "To create forwarding groups:" on page 137
To create forwarding hosts:

1. Click Configuration > Forwarding > Forwarding Hosts.
2. Click New. The Add Forwarding Host dialog displays.
.

3. Configure the host options:
a. In the Alias field, enter the name of the host as it will be named in
policy.

136

Chapter 8: Configuring the Upstream Network Environment
Section C: Configuring Forwarding

Note: The host alias cannot be a CPL keyword, such as no, default, or
forward.

b. In the Host field, give the name of the host domain or its IP address.
c. Define the host type by selecting either the Proxy or Server radio button.
Terminated HTTPS, TCP tunnels, and Telnet can be forwarded to a
server only; they cannot be forwarded to a proxy. Server specifies to use
the relative path for URLs in the HTTP header because the next hop is
a Web server, not a proxy server. The default is Proxy.
d. Select the port you want to use.
Port 80 is the default for HTTP. The rest of the host types default to their
appropriate Internet default port, except TCP tunnels, which have no
default and for which a port must be specified.
e. In the Load Balancing and Host Affinity section, select a load-balancing
method from the drop-down list. Global default (configured on the
Configuration > Forwarding > Global Defaults tab), sets the default for all
forwarding hosts on the system. You can also specify the loadbalancing method for this system: Least Connections or Round Robin, or
you can disable load balancing by selecting None.
f.

In the Host affinity methods drop-down list (see Table 8–1, "Host Affinity
Methods" on page 135), select the method you want to use.

4. Click OK.
5. Click Apply.
To create forwarding groups:

An existing host can belong to one or more groups as needed. It can only belong
once to a single group.
1. Click Configuration > Forwarding > Forwarding Groups.
2. Click New. The Add Forwarding Group dialog displays, showing the available
aliases.

137

Volume 5: Advanced Networking
Section C: Configuring Forwarding

3. Enter a name for the new group in the Alias field.
Note: The group alias cannot be a CPL keyword, such as no, default, or
forward.

4. To add members to a group, highlight the hosts you want grouped and click
Add. You can also create a group with no members.
5. In the Load Balancing and Host Affinity section, select the load-balancing method
from the drop-down list. Global default (configured on the Configuration >
Forwarding > Global Defaults tab), are the defaults that were set for all forwarding
groups on the system. To specify the load-balancing method for this system,
select Least Connections, Round Robin, Domain Hash, URL Hash, or you can disable
load balancing by selecting None.
6. In the Host affinity methods drop-down list (see Table 8–1, "Host Affinity
Methods" on page 135), select the method you want to use.
7. Click OK.
8. Click Apply.

138

Chapter 8: Configuring the Upstream Network Environment
Section C: Configuring Forwarding

Configuring Global Forwarding Defaults
The global defaults apply to all forwarding hosts and groups unless the settings
are specifically overwritten during host or group configuration.
To configure global defaults:

1. Select Configuration > Forwarding > Global Defaults.

2. Configure General Settings as follows:
a. Determine how connections behave if no forwarding is available.
Failing open is an insecure option. The default is to fail closed. This
setting can be overridden by policy, if it exists.
b. Decide if you want to Use forwarding for administrative downloads. The
default is to use forwarding in this case.
This option determines whether forwarding is applied to requests
generated for administrative reasons on the system, such as downloading
policy files or new system images.
If the option is on, meaning that forwarding is applied, you can control the
forwarding in policy as needed.
This option also affects the use of SOCKS gateways.
c. Enter the Timeout for integrated hosts interval: An integrated host is an
Origin Content Server (OCS) that has been added to the health check
list. The host, added through the integrate_new_hosts policy property,
ages out after being idle for the specified time. The default is 60
minutes.
3. Configure Global Load Balancing and Host Affinity Settings.
a. Load-balancing methods:

139

Volume 5: Advanced Networking
Section C: Configuring Forwarding



Forwarding hosts: Specify the load-balancing method for all
forwarding hosts unless their configuration specifically overwrites the
global settings. You can choose Least Connections or Round Robin, or you
can disable load balancing by selecting None. Round Robin is specified
by default.



Forwarding groups: Specify the load-balancing method for all
forwarding groups unless their configuration specifically overwrites
the global settings. You can choose to do a domain hash or a URL hash.
You can also select Least Connections or Round Robin, or disable load
balancing by selecting None. Round Robin is specified by default.

b. In the Global Host Affinity methods (see Table 8–1, "Host Affinity
Methods" on page 135), select the method you want to use.
c. Enter the Host Affinity Timeout interval, the amount of time a user's IP
address, SSL ID, or cookie remains valid after its most recent use. The
default is 30 minutes, meaning that the IP address, SSL ID or cookie
must be used once every 30 minutes to restart the timeout period.
4. Click Apply.

Configuring the Default Sequence
The default sequence is the default forwarding rule, used for all requests lacking
policy instructions. Failover is supported if the sequence (only one is allowed) has
more than one member.
Note: Creating the default sequence through the CLI is a legacy feature. You can
set up sequences by using policy alone. The default sequence (if present) is
applied only if no applicable forwarding gesture is in policy.

For information on using VPM, refer to Volume 6: The Visual Policy Manager and
Advanced Policy; for information on using CPL, refer to Volume 10: Content Policy
Language Guide. For information on using forwarding with policy, see
Appendix A: "Using Policy to Manage Forwarding" on page 419.
The default sequence (and any sequence specified in policy) works by allowing
healthy hosts to take over for an unhealthy host (one that is failing its DNS
Resolution or its health check). If more than one member is in the sequence, the
sequence specifies the order of failover, with the second host taking over for the
first host, the third taking over for the second, and so on.
Note: In normal circumstances, only the first member of the sequence is ever
used. Traffic is forwarded to the first member of the sequence until it fails, then
traffic is sent to the second member of list until it fails or the first member
becomes healthy again, and so on.

140

Chapter 8: Configuring the Upstream Network Environment
Section C: Configuring Forwarding
To create a default sequence:

1. Select Configuration > Forwarding > Default Sequence. The available aliases are
displayed.

2. To select an alias, highlight it and click Add.
Note: Any host or group in the default sequence is considered in use by
policy. As a result, if you try to delete a host or group while it is in the default
sequence, you receive an error message. You must remove the host/group
from the sequence first, then delete the host or group.

3. Click Promote or Demote to change the order of the hosts in the failover
sequence.
4. Click Apply.

Related CLI Syntax to Configure Forwarding


To enter configuration mode for forwarding:
SGOS#(config) forwarding
SGOS#(config forwarding)



The following subcommands are available:
SGOS#(config) forwarding
SGOS#(config forwarding) create host host_alias host_name [http[=port]
[https[=port]] [ftp[=port]] [mms[=port]] [rtsp[=port]] [tcp[=port]]
[telnet[=port]] [ssl-verify-server[=yes | =no]] [group=group_name]
[server | proxy]
SGOS#(config forwarding) create group group_name
SGOS#(config forwarding) delete all
SGOS#(config forwarding) delete group group_name

141

Volume 5: Advanced Networking
Section C: Configuring Forwarding
SGOS#(config forwarding) delete host host_alias
SGOS#(config forwarding) download-via-forwarding {disable | enable}
SGOS#(config forwarding) edit host_alias
SGOS#(config forwarding host_alias) exit
SGOS#(config forwarding host_alias) {ftp | http | https | mms |
rtsp | tcp | telnet} [port]}
SGOS#(config forwarding host_alias) host hostname
SGOS#(config forwarding host_alias) host-affinity http {default |
none | client-ip-address | accelerator-cookie}
SGOS#(config forwarding host_alias) host-affinity ssl {default |
none | client-ip-address | accelerator-cookie | ssl-session-id}
SGOS#(config forwarding host_alias) host-affinity other {default |
none | client-ip-address}
SGOS#(config forwarding host_alias) load-balance method {default |
least-connections | none | round-robin}
SGOS#(config forwarding host_alias) no {ftp | http | https | mms |
rtsp | ssl-verify-server | tcp | telnet}
SGOS#(config forwarding host_alias) proxy | server
SGOS#(config forwarding host_alias) ssl-verify-server
SGOS#(config forwarding host_alias) view
SGOS#(config forwarding) edit group_alias
SGOS#(config forwarding group_alias) {add | remove} host_alias
SGOS#(config forwarding group_alias) exit
SGOS#(config forwarding group_alias) host-affinity http {default |
none | client-ip-address | accelerator-cookie}
SGOS#(config forwarding group_alias) host-affinity ssl {default |
none | client-ip-address | accelerator-cookie | ssl-session-id}
SGOS#(config forwarding group_alias) host-affinity other {default |
none | client-ip-address}
SGOS#(config forwarding group_alias) load-balance {default |
domain-hash | least-connections | none | round-robin | url-hash}
SGOS#(config forwarding group_alias) view
SGOS#(config forwarding) exit
SGOS#(config forwarding) failure-mode {closed | open}
SGOS#(config forwarding) host-affinity http {default | none | clientip-address | accelerator-cookie} host_or_group_alias
SGOS#(config forwarding) host-affinity http {none | client-ip-address
| accelerator-cookie}
SGOS#(config forwarding) host-affinity ssl {default | none | clientip-address | accelerator-cookie | ssl-session-id} host_or_group_alias
SGOS#(config forwarding) host-affinity ssl {none | client-ip-address |
accelerator-cookie | ssl-session-id}
SGOS#(config forwarding) host-affinity other {default | none | clientip-address} host_or_group_alias
SGOS#(config forwarding) host-affinity other {none | client-ipaddress}
SGOS#(config forwarding) host-affinity timeout minutes
SGOS#(config forwarding) integrated-host-timeout minutes

142

Chapter 8: Configuring the Upstream Network Environment
Section C: Configuring Forwarding
SGOS#(config forwarding) load-balance group {default | none | domainhash | url-hash | round-robin | least-connections} group_alias
SGOS#(config forwarding) load-balance group {none | domain-hash | urlhash | round-robin | least-connections}
SGOS#(config forwarding) load-balance host {default | none | roundrobin | least-connections} host_alias
SGOS#(config forwarding) load-balance host {none | round-robin |
least-connections}
SGOS#(config forwarding) no path
SGOS#(config forwarding) path url
SGOS#(config forwarding) sequence add host_or_group_alias
SGOS#(config forwarding) sequence clear
SGOS#(config forwarding) sequence demote host_or_group_alias
SGOS#(config forwarding) sequence promote host_or_group_alias
SGOS#(config forwarding) sequence remove host_or_group_alias
SGOS#(config forwarding) view

Statistics
To view forwarding statistics, select Statistics > Advanced > Forwarding.

143

Volume 5: Advanced Networking
Section D: Using Forwarding Directives to Create an Installable List

Section D: Using Forwarding Directives to Create an Installable List
You can use directives instead of using the Management Console or CLI to
configure forwarding. Note that the Management Console offers the easiest
method of configuration. Using directives, you can:


Create the forwarding hosts and groups



Provide load balancing and host affinity

Table 8–2 Forwarding Directives

144

Directive

Meaning

See

fwd_fail

Determines whether the
forwarding host should fail
open or fail closed if an
operation does not succeed.

"Setting Fail Open/Closed
and Host Timeout Values"
on page 146.

fwd_host

Creates a forwarding host and
sets configuration parameters
for it, including protocols and
ports.

"Creating Forwarding
Hosts" on page 145.

group

Creates a forwarding group
and identifies members of the
group.

"Creating Forwarding
Groups Using Directives"
on page 146.

host_affinity

Directs multiple connections
by a single user to the same
group member.

"Configuring Host Affinity
Directives" on page 148.

integrated_host_
timeout

Manages an origin content
server that has been added to
the health check list. The host
ages out after being idle for the
specified time.

"Setting Fail Open/Closed
and Host Timeout Values"
on page 146.

load_balance

Manages the load among
forwarding hosts in a group,
or among multiple IP
addresses of a host.

"Configuring LoadBalancing Directives" on
page 147.

sequence

Sets the default sequence to
the space separated list of one
or more forwarding host and
group aliases. (The default
sequence is the default
forwarding rule, used for all
requests lacking policy
instructions.)

"Creating a Default
Sequence" on page 148.

Chapter 8: Configuring the Upstream Network Environment
Section D: Using Forwarding Directives to Create an Installable List

Creating Forwarding Host and Group Directives
A forwarding host directive creates a host along with all its parameters. You can
include a group that the forwarding host belongs to.
A group directive creates a group and identifies group members. For more
information on group directives, skip to "Creating Forwarding Groups Using
Directives" on page 146.

Creating Forwarding Hosts
To create a forwarding host, choose the protocols you want to use and add the
forwarding host to a group, enter the following into your installable list. Create a
fwd_host directive for each forwarding host you want to create.
fwd_host host_alias hostname [http[=port]] [https[=port]] [ftp[=port]]
[mms[=port]] [rtsp[=port]] [tcp=port] [telnet[=port]] [ssl-verifyserver[=yes | =no]] [group=group_name [server | proxy]]
:

Table 8–3 Commands to Create Forwarding Host and Group Directives
host_alias

This is the alias for use in policy. Define a
meaningful name.

hostname

The name of the host domain, such
www.bluecoat.com, or its IP address.

http

=port

At least one protocol must be selected

https
ftp

HTTPS and Telnet cannot be used with a proxy.

mms

Note that HTTPS refers to terminated HTTPS, so
it is used only for a server.

rtsp
telnet
tcp

=port

If you choose to add a TCP protocol, a TCP port
must be specified.
TCP protocols are not allowed if the host is a
proxy.

ssl-verifyserver

=yes | =no

Sets SSL to specify that the ProxySG checks the
CA certificate of the upstream server.
The default for ssl-verify-server is yes. This
can be overridden in the SSL layer in policy.
To disable this feature, you must specify sslverify-server=no in the installable list or CLI.
In other words, you can configure ssl-verifyserver=yes in three ways: do nothing (yes is the
default), specify ssl-verify-server=no, or
specify ssl-verify-server=yes.

145

Volume 5: Advanced Networking
Section D: Using Forwarding Directives to Create an Installable List
Table 8–3 Commands to Create Forwarding Host and Group Directives (Continued)
group

=group_name

Specifies the group (or server farm or group of
proxies) to which this host belongs. If this is the
first mention of the group group_name then that
group is automatically created with this host as its
first member.
The ProxySG uses load balancing to evenly
distribute forwarding requests to the origin
servers or group of proxies.

server | proxy

server specifies to use the relative path for URLs
in the HTTP header because the next hop is a Web
server, not a proxy server. The default is proxy.

Example
fwd_host www.bluecoat1.com 10.25.36.48 ssl-verify-server=no
group=bluecoat

Creating Forwarding Groups Using Directives
The forwarding groups directive has the following syntax:
group group_name host_alias_1 host_alias_2...

where group_name is the name of the group, and host_alias_1, host_alias_2, and
so forth are the forwarding hosts you are assigning to the forwarding group.
Forwarding host parameters are configured through the forwarding host
directives.

Setting Special Parameters
After you configure the forwarding hosts and groups, you might need to set other
special parameters to fine tune the hosts. You can configure the following settings:


"Setting Fail Open/Closed and Host Timeout Values".



"Configuring Load-Balancing Directives" on page 147.



"Configuring Host Affinity Directives" on page 148.

Setting Fail Open/Closed and Host Timeout Values
Using directives, you can determine if the forwarding host fails open or closed, if
an operation does not succeed, and the interval it takes for integrated hosts to be
aged out.
An integrated host is an Origin Content Server (OCS) that has been added to the
health check list. If the policy property integrate_new_hosts applies to a
forwarding request as a result of matching the integrate_new_hosts property, the
ProxySG makes a note of each OCS and starts health checking to help future
accesses to those systems. If the host is idle for the interval you specify, it is aged
out. Sixty minutes is the default interval.

146

Chapter 8: Configuring the Upstream Network Environment
Section D: Using Forwarding Directives to Create an Installable List

The syntax is:
fwd_fail {open | closed}
integrated_host_timeout minutes
Table 8–4 Commands to Set Fail Open/Closed and Host Timeout Values
fwd_fail

{open |
closed}

Determines whether the forwarding host
should fail open or fail closed if an
operation does not succeed. Fail open is a
security risk, and fail closed is the default if
no setting is specified.
This setting can be overridden by policy,
(using the forward.fail_open(yes|no)
property).

integrated_host_timeout

minutes

An OCS that has been added to the health
check list is called an integrated host. The
host ages out after being idle for the
specified time.

Examples
fwd_fail open
integrated_host_timeout 90

Configuring Load-Balancing Directives
Load balancing shares the load among a set of IP addresses, whether a group or a
host with multiple IP addresses.
The syntax is:
load_balance group {none | domain-hash | url-hash | round-robin |
least-connections} [group_alias]
load_balance host {none | round-robin | least-connections}
[host_alias]
Table 8–5

Load Balancing Directives

Command

Suboptions

Description

load_balance
group

{none | domain-hash | urlhash | round-robin |
least-connections}
[group_alias]

If you use group for load balancing,
you can set the suboption to none or
choose another method. If you do
not specify a group, the settings
apply as the default for all groups.

load_balance
host

{none | round-robin |
least-connections}
[host_alias]

If you use host for load balancing,
you can set the suboption to none or
choose another method. If you do
not specify a host, the settings apply
as the default for all hosts.

Example
load_balance host least_connections

147

Volume 5: Advanced Networking
Section D: Using Forwarding Directives to Create an Installable List

Configuring Host Affinity Directives
Host affinity is the attempt to direct multiple connections by a single user to the
same group member.
The syntax is:
host_affinity http {none | client-ip-address | accelerator-cookie}
[host_or_group_alias]
host_affinity ssl {none | client-ip-address | accelerator-cookie |
ssl-session-id} [host_or_group_alias]
host_affinity other {none | client-ip-address} [host_or_group_alias]
host_affinity timeout minutes
Table 8–6 Commands to Configure Host Affinity Directives

Command

Suboption

Description

host_affinity
http

{accelerator-cookie |
client-ip-address | none}
[host_or_group_alias]

Determines which HTTP hostaffinity method to use
(accelerator cookie or clientip-address), or you can specify
none. If you do not specify a host or
group, the settings apply as the
default for all hosts or groups.

host_affinity
ssl

{accelerator-cookie |
client-ip-address | none
| ssl-session-id}
[host_or_group_alias]

Determines which SSL host-affinity
method to use (accelerator
cookie, client-ip-address, or
ssl-session-id), or you can
specify none. If you do not specify a
host or group, the settings apply as
the default for all hosts or groups.

host_affinity
other

{none | client-ipaddress}
[host_or_group_alias]

Determines whether client-ipaddress mode is used with TCP
tunnels or Telnet.

host_affinity
timeout

minutes

Determines how long a user's IP
address, SSL ID, or cookie remains
valid when idle

Example
host_affinity ssl_method 10.25.36.48
host_affinity timeout 5

Creating a Default Sequence
The default sequence is the default forwarding rule, used for all requests lacking
policy instructions. Failover is supported if the sequence (only one is allowed) has
more than one member.
Note: The default sequence is completely overridden by policy.

148

Chapter 8: Configuring the Upstream Network Environment
Section D: Using Forwarding Directives to Create an Installable List

A default failover sequence works by allowing healthy hosts to take over for an
unhealthy host (one that is failing its DNS resolution or its health check). The
sequence specifies the order of failover, with the second host taking over for the
first host, the third taking over for the second, and so on).
If all hosts are unhealthy, the operation fails either open or closed, depending
upon your settings.
This configuration is generally created and managed through policy. If no
forwarding policy applies, you can create a default sequence through the CLI.
This single default sequence consists of a single default host (or group) plus one
or more hosts to use if the preceding ones are unhealthy.
The syntax is:
sequence alias_list

where alias_list is a space-separated list of one or more forwarding host
and group aliases.

Example
sequence bluecoat

Creating a Forwarding Installable List
You can create and install the forwarding installable list using one of the
following methods:


Text Editor, which allows you to enter the installable list of directives (or copy
and paste the contents of an already-created file) directly onto the appliance.



A local file, created on your system; the ProxySG can browse to the file and
install it.



A remote URL, where you placed an already-created file on an FTP or HTTP
server to be downloaded to the ProxySG.



CLI inline command.

When the Forwarding Installable List is installed, it replaces the forwarding
configuration on the ProxySG. The configuration remains in effect until
overwritten by another installable list; the configuration can be modified or
overwritten using CLI commands.
Note: During the time that a forwarding installable list is being compiled and

installed, forwarding might not be available. Any transactions that come into the
ProxySG during this time might not be forwarded properly.
Installation of forwarding installable lists should be done outside peak traffic
times.

149

Volume 5: Advanced Networking
Section D: Using Forwarding Directives to Create an Installable List
To create a forwarding installable list:

1. Select Configuration > Forwarding > Install Forwarding File.
2. From the drop-down list, select the method to use to install the forwarding
installable list; click Install.
Note: A message is written to the event log when you install a list through
the SGOS software.



Remote URL:
Enter the fully-qualified URL, including the filename, where the
installable list is located. To view the file before installing it, click View.
Click Install. Examine the installation status that displays; click OK.



Local File:
Click Browse to display the Local File Browse window. Browse for the
installable list file on the local system. Open it and click Install. When the
installation is complete, a results window opens. View the results, close
the window, click Close.



Text Editor:
The current configuration is displayed in installable list format. You can
customize it or delete it and create your own. Click Install. When the
installation
is complete, a results window opens. View the results, close the window,
click Close.
Note: The Management Console text editor is a way to enter an

installable list for forwarding. It is not a way to enter CLI commands. The
directives are understood only by the installable list parser for
forwarding.
3. Click Apply.
Note: You can create forwarding settings using the CLI #inline forwarding

command. You can use any of the forwarding directives.
For more information on using inline commands, refer to Volume 11: Command
Line Interface Reference.
To delete forwarding settings on the ProxySG:

From the (config) prompt, enter the following commands to delete a host, a
group, or all hosts and groups from the forwarding configuration:
SGOS#(config) forwarding
SGOS#(config forwarding) delete {all | group group_name | host
host_alias}

150

Note: : Any host or group in the default sequence (or the DRTR service
configuration) is considered in use by policy. As a result, if you try to delete a host
or group while it is in the default sequence or DRTR service configuration, you
will receive an error message. You must remove the host/group from the
sequence or service first, then delete.

151

152

Chapter 9: Internet Caching Protocol (ICP) Configuration

ICP is a communication protocol for caches. It allows a cache (not necessarily a
ProxySG) to query other caches for an object, without actually requesting the
object. By using ICP, the cache can determine if the object is available from a
neighboring cache, and which cache provides the fastest response.
Note: The ProxySG (assuming ICP is configured) does ICP queries only if no

forwarding host or SOCKS gateway is identified as an upstream target. If ICP is
used by the appliance, it prompts other cache devices for the item, and upon a
positive response re-directs the upstream request to that cache device instead of
the content origin server.
Only use ICP if you have ICP hosts available or to have the ProxySG support
requests from other ICP hosts.
By default, the ICP protocol requires the requesting host to wait up to two
seconds for all ICP hosts to respond to the request for an object (the time is
configurable).
If the ICP service is configured and running, the service is used if no
forwarding or SOCKS gateway target was specified. In other words, the policy
rule icp(yes) is the default, assuming that the ICP service is available. You can
disable ICP with the policy rule icp(no) to control ICP queries for requests.

Topics in this Chapter
This chapter includes information about the following topics:


"About ICP Hierarchy" on page 153



"Using ICP Configuration Directives to Create an Installable List" on page
154



"Naming the IP Hosts" on page 155



"Restricting Access" on page 156



"Connecting to Other ICP Hosts" on page 157



"Creating an ICP Installable List" on page 158



"Enabling ICP" on page 159

About ICP Hierarchy
An ICP hierarchy is comprised of a group of caches, with defined parent and
sibling relationships. A cache parent is one that can return the object if it is in
the cache, or request the object from the source on behalf of the requester if the
object is not in the cache. A cache sibling is a device that can only return the
object if it is in the cache. One cache acting as a parent can also act as a sibling to
other cache devices.

153

Volume 5: Advanced Networking


When an object is not cached, the cache device sends an ICP query to its
neighbors (parents and siblings) to see if any of its peers holds the object.



Each neighbor that holds the requested object returns an ICP_HIT reply.



Each neighbor that does not hold the object returns an ICP_MISS reply.

Based on the responses, the cache can determine where to request the object: from
one of its neighbors or from the source. If an ICP_HIT reply is received, the request
is sent to the host that returned the first reply. If no ICP_HIT reply is received, the
request is forwarded to the first parent that replied. If no parents respond or are
configured, the request is made directly to the source.

Using ICP Configuration Directives to Create an Installable List
To configure ICP you must create an installable list and load it on the ProxySG.
The ICP protocol contains a number of directives, commands used to create a list
that can be installed on the ProxySG.
For information on installing the file itself, see "Creating an ICP Installable List"
on page 158.
The ICP configuration includes directives that:


Name the ICP hosts



Restrict ICP access to only these hosts

Available directives are listed in Table 9–1.
Table 9–1 ICP Directives

Directive

Meaning

Where used

icp_host

The icp_host directive describes cache peers in
the hierarchy. There should be one entry for each
ProxySG you want to use.

Names the ICP hosts. See
"Naming the IP Hosts" on
page 155.

icp_access_ domain

The icp_access_domain directive is used to
control which ICP queries are accepted. The
icp_access_domain directive requires a reverse
DNS lookup of each ICP query to validate the IP
address.

Restricts access. See
"Restricting Access" on
page 156.

icp_access_ip

The icp_access_ip directive works like the
icp_access_domain command, except that you
can specify an IP address and subnet mask rather
than a domain.

Restricts access.

The icp_port directive sets the port the ProxySG
uses to listen for ICP requests. The default port is
3130. If you set the port to 0, ICP is disabled.

Connects to other ICP
hosts. See "Connecting to
Other ICP Hosts" on page
157.

icp_port

154

See "Restricting Access" on
page 156.

Chapter 9: Internet Caching Protocol (ICP) Configuration
Table 9–1 ICP Directives (Continued)

Directive

Meaning

Where used

neighbor_timeout

The neighbor_timeout directive sets the number
of seconds the ProxySG waits for ICP replies.
When the cache device sends an ICP request, it
waits for all hosts to reply or for the
neighbor_timeout to expire. The default timeout
is two seconds.

Connects to other ICP
hosts. See "Connecting to
Other ICP Hosts" on page
157.

icp_failcount

The icp_failcount directive sets the number of
consecutive failures the cache device can receive
before considering the ICP host as failed. By
default, the ICP failure count is set to 20. Each
time a request fails, the failure count is
incremented. When a request succeeds, the failure
count is reset to zero.

Connects to other ICP
hosts. See "Connecting to
Other ICP Hosts" on page
157.

http_failcount

The http_failcount directive sets the number of
consecutive failures the cache device can receive
before considering the HTTP host as failed. By
default, the HTTP failure count is set to five. The
failure count increments each time a request fails.
When a request succeeds, the failure count is reset
to zero. When an HTTP host fails, the cache device
waits five minutes before attempting to use it
again as a forwarding target. If the next request
fails, the cache device continues to wait five
minutes between attempts until the cache
becomes available.

Connects to other ICP
hosts. See "Connecting to
Other ICP Hosts" on page
157.

host_fail_notify

The host_fail_notify directive tells the cache
device to send event notification e-mail when a
connect fails persistently.

Connects to other ICP
hosts. See "Connecting to
Other ICP Hosts" on page
157.

host_recover_
notify

The host_recover_notify directive tells the
cache device to send event notification e-mail
when a failed host recovers.

Connects to other ICP
hosts. See "Connecting to
Other ICP Hosts" on page
157.

Naming the IP Hosts
The icp_host directive describes peers in the hierarchy. One entry is required for
each ProxySG appliance you want to use.
icp_host hostname peertype HTTPport ICPport [default | backup |
feeder]
Table 9–2 ICP_host Directive

Command
hostname

Suboptions

Description
The host name of the ProxySG.

155

Volume 5: Advanced Networking
Table 9–2 ICP_host Directive

Command

Suboptions

Description

peertype

{parent |
sibling}

Relationship of the appliance to the cache device you are configuring.

HTTPport

TCP port where the appliance accepts HTTP requests. The common
HTTP port is 80 or 8080.

ICPport

UDP port where the appliance accepts ICP requests. The common ICP
port is 3130.

default

If specified, designates a ProxySG host parent to be the default ICP
parent. If no ICP reply is received, all requests are forwarded to the
default parent.

backup

If specified, designates the cache device host parent to be the backup
default ICP parent. If the default parent is not available, the cache
device uses the backup default parent.

feeder

If specified, designates the ProxySG host sibling as a feeder-type host,
using ICP request loops to populate the appliance.

The following are sample icp_host directives that can be entered into the ICP
configuration:
; Define
icp_host
icp_host
icp_host
icp_host
icp_host

ICP parent and sibling hosts.
cm1.bluecoat.com parent 8080 3130 default
cm2.bluecoat.com sibling 8080 3130
cm3.bluecoat.com sibling 8080 3130
cm4.bluecoat.com sibling 8080 3130
cm5.bluecoat.com parent 8080 3130

Restricting Access
You can restrict access to ProxySG appliances acting as caches by other ICP hosts
using the icp_access_domain and icp_access_ip directives. By default, when ICP
is configured, all ICP hosts are allowed access. You should deny access to all
domains other than the ICP hosts you want to use.

icp_access_domain Directive
The icp_access_domain directive defines which hosts can request objects from the
Web cache using ICP. The default action is to allow all requests. When you use
icp_access_domain, each ICP query requires a reverse DNS lookup to validate the
IP address. Depending on the number of ICP requests, these lookups can
consume ProxySG resources.
icp_access_domain {allow | deny} domain
Table 9–3 ICP_Access_Domain Directive

156

Directive Option

Description

allow | deny

Allows or denies ICP queries from neighbors that match the
domain specification.

Chapter 9: Internet Caching Protocol (ICP) Configuration
Table 9–3 ICP_Access_Domain Directive

Directive Option

Description

domain

The domain to match. All ICP queries from neighbors that match
the specified domain are handled by the host. The special domain
of all defines the default action when there is no domain match.

The following are sample icp_access_domain directives to be entered into the ICP
configuration:
; allow ICP access to this Blue Coat Systems SG Appliance from the
; bluecoat.com domain
icp_access_domain allow bluecoat.com
icp_access_domain deny all
; the deny all option should always be specified to deny all other
; domains

icp_access_ip Directive
The icp_access_ip directive works like the icp_access_domain command, except
that you can specify an IP address and subnet mask rather than a domain. The
following describes the parameters for the icp_access_ip command:
icp_access_ip {allow | deny} subnet mask
Table 9–4 ICAP_Access_IP Directive

Directive Option

Description

allow | deny

Allow or deny ICP queries from neighbors that match the
address specification.

address/subnet mask

The address and subnet mask to match. All ICP queries that
match the specified address are handled by the ICP host. The
special address of 0.0.0.0 defines the default action when
there is no address match.

The following are sample icp_access_ip directives to be entered into the ICP
configuration:
; allow ICP access to this Blue Coat Systems SG Appliance from the
local subnet
icp_access_ip allow 192.168.10.0/255.255.255.0
icp_access_ip deny 10.25.36.47
; the deny all option should always be specified to deny all other
domains

Connecting to Other ICP Hosts
In addition to the ICP directives described in the sections above, you can specify
the following directives in the ICP configuration:
icp_port 0
neighbor_timeout 2
icp_failcount 20
http_failcount 5
host_fail_notify on
host_recover_notify on

157

Volume 5: Advanced Networking

Table 9–5 Connecting to Other ICP Hosts

Directive

Description

icp_port

The default port is 3130. If you set the port to 0, ICP is disabled.

neighbor_timeout

When the cache device sends an ICP request, it waits for all
hosts to reply or for the neighbor_timeout to expire. The
default timeout is two seconds.

http_failcount

By default, the HTTP failure count is set to five. The failure
count increments each time a request fails. When a request
succeeds, the failure count resets to zero. When an HTTP host
fails, the cache device waits five minutes before attempting to
use it again as a forwarding target.

icp_failcount

By default, the ICP failure count is set to 20. Each time a request
fails, the failure count is incremented. When a request succeeds,
the failure count is reset to zero.

host_fail_notify

on tells the cache to send event notification e-mail when a
connect fails persistently; off disables this setting.

host_recover_
notify

on tells the cache to send event notification e-mail when a failed
host recovers; off disables this setting.

Creating an ICP Installable List
You can create the ICP installable list using one of the following methods:


Text Editor, which allows you to enter directives (or copy and paste the
contents of an already-created file) directly onto the ProxySG.



Local file, installed on your system; the ProxySG can browse to the file and
install it.



A remote URL, where you place an already-created file on an FTP or HTTP
server to be downloaded to the appliance.



The CLI inline command.

When the ICP installable list is created and installed, it overwrites any ICP
settings on the ProxySG.
To create an ICP installable list:

1. Select Configuration > Forwarding > ICP.
2. From the drop-down list, select the method you want to use to install the ICP
configuration; then click Install.


Remote URL:
Enter the fully-qualified URL, including the filename, where the
configuration is located. To view the file before installing it, click View.
Click Install. Examine the installation status that displays; click OK.

158

Chapter 9: Internet Caching Protocol (ICP) Configuration



Local File:
Click Browse to bring up the Local File Browse window. Browse for the file
on the local system. Click Install. When the installation is complete, a
results window opens. View the results, close the window, click Close.



Text Editor:

The current configuration is displayed in installable list format. You can
customize it or delete it and create your own. Click Install. When the
installation is complete, a results window opens. View the results, close
the window, click Close.
3. Click Apply.
Note: You can create ICP settings using the CLI inline commands.

For more information on using inline commands, refer to Volume 11: Command
Line Interface Reference.

Enabling ICP
Before ICP can be used in the ProxySG environment:


ICP must be running



At least one forwarding host must be configured

ICP can be enabled or disabled through the policy rule icp.The default is
can disable ICP with the policy rule icp(no) to control ICP queries
for requests.

icp(yes). You

159

Volume 5: Advanced Networking

160

Chapter 10: Managing Routing Information Protocols (RIP)

This chapter discusses the Routing Information Protocol (RIP), which is
designed to select the fastest route to a destination. RIP support is built into the
ProxySG appliance, and is configured by created and installing an RIP
configuration text file onto the device.
The Blue Coat RIP implementation also supports advertising default gateways.
Default routes added by RIP are treated the same as the static default routes;
that is, the default route load balancing schemes apply to the default routes
from RIP as well.

Topics in this Chapter
This chapter includes information about the following topics:


"Installing RIP Configuration Files" on page 161



"Configuring Advertising Default Routes" on page 163



"RIP Commands" on page 163



"RIP Parameters" on page 164



"ProxySG-Specific RIP Parameters" on page 165



"Using Passwords with RIP" on page 166

Installing RIP Configuration Files
No RIP configuration file is shipped with the appliance. For commands that
can be entered into the RIP configuration file, see "RIP Commands" on page
163.
After creating an RIP configuration file, install it using one of the following
methods:


Using the Text Editor, which allows you to enter settings (or copy and paste
the contents of an already-created file) directly onto the appliance.



Creating a local file on your local system; the ProxySG can browse to the file
and install it.



Using a remote URL, where you place an already-created file on an FTP or
HTTP server to be downloaded to the ProxySG.



Using the CLI inline rip-settings command, which allows you to paste
the RIP settings into the CLI.



Using the CLI rip commands, which require that you place an alreadycreated file on an FTP or HTTP server and enter the URL into the CLI. You
can also enable or disable RIP with these commands.

161

Volume 5: Advanced Networking
To install an RIP configuration file:
Note: When entering RIP settings that affect current settings (for example, when
switching from ripv1 to ripv2), disable RIP before you change the settings; reenable RIP when you have finished.

1. Select Configuration > Network > Routing > RIP.
2. To display the current RIP settings, routes, or source, click one or all of the
View RIP buttons.
3. In the Install RIP Setting from drop-down list, select the method used to install
the routing table; click Install.


Remote URL:
Enter the fully-qualified URL, including the filename, where the routing
table is located. To view the file before installing it, click View. Click Install.
To view the installation results, click Results; close the window when you
are finished. Click OK.



Local File:
Click Browse to display the Local File Browse window. Browse for the file
on the local system. Open it and click Install. When the installation is
complete, a results window opens. View the results and close the window.



Text Editor:
The current configuration is displayed in installable list format. You can
customize it or delete it and create your own. Click Install. When the
installation is complete, a results window opens. View the results, close
the window, and click OK.

4. Click Apply.
5. Select Enable RIP.
6. Click Apply.

Related CLI Syntax to Configure RIP
SGOS#(config) rip {disable | enable}


To enter a path to a remote URL where you have placed an already-created
RIP configuration file, enter the following commands at the (config)
command prompt:
SGOS#(config) rip path url
SGOS#(config) load rip-settings



To paste an RIP configuration directly into the CLI, enter the following
command at the (config) command prompt:
SGOS#(config) inline rip-settings end-of-file_marker

162

Chapter 10: Managing Routing Information Protocols (RIP)

Configuring Advertising Default Routes
Default routes advertisements are treated the same as the static default routes;
that is, the default route load balancing schemes also apply to the default routes
from RIP.
By default, RIP ignores the default routes advertisement. You can change the
default from disable to enable and set the preference group and weight through
the CLI only.
To enable and configure advertising default gateway routes:

1. At the (config) command prompt:
SGOS#(config) rip default-route enable
SGOS#(config) rip default-route group group_number
SGOS#(config) rip default-route weight weight_number

Where group_number defaults to 1, and weight_number defaults to 100, the same
as the static default route set by the ip-default-gateway command.
2. (Optional) To view the default advertising routes, enter:
SGOS#(config) show rip default-route
RIP default route settings:
Enabled:
Yes
Preference group:
3
Weight:
30

RIP Commands
You can place any of the commands below into a Routing Information Protocol
(RIP) configuration text file. You cannot edit a RIP file through the command line,
but you can overwrite a RIP file using the inline rip-settings command.
After the file is complete, place it on an HTTP or FTP server accessible to the
ProxySG and download it.
Note: RIP parameters are accepted in the order that they are entered. If a RIP
parameter is added, it is appended to the default RIP parameters. If a subsequent
parameter conflicts with a previous parameter, the most recent one is used.

net
net Nname[/mask] gateway Gname metric Value {passive | active |
external}
Table 10–1 net Commands

Parameters

Description

Nname

Name of the destination network. It can be a symbolic
network name, or an Internet address specified in dot
notation.

/mask

Optional number between 1 and 32 indicating the netmask
associated with Nname.

163

Volume 5: Advanced Networking
Table 10–1 net Commands (Continued)

Parameters

Description

Gname

Name or address of the gateway to which RIP responses
should be forwarded.

Value

The hop count to the destination host or network. A net
Nname/32 specification is equivalent to the host Hname
command.

passive | active |
external

Specifies whether the gateway is treated as passive or active,
or whether the gateway is external to the scope of the RIP
protocol.

host
host Hname gateway Gname metric Value {passive | active | external}
Table 10–2 host Commands

Parameters

Description

Hname

Name of the destination network. It can be a symbolic
network name, or an Internet address specified in dot
notation.

Gname

Name or address of the gateway to which RIP responses
should be forwarded. It can be a symbolic network name, or
an Internet address specified in dot notation.

Value

The hop count to the destination host or network. A net
Nname/32 specification is equivalent to the host Hname
command.

passive | active |
external

Specifies whether the gateway is treated as passive or active,
or whether the gateway is external to the scope of the RIP
protocol.

RIP Parameters
Lines that do not start with net or host commands must consist of one or more of
the following parameter settings, separated by commas or blank spaces:
Table 10–3 RIP Parameters

Parameters

Description

if=[0|1|2|3]

Specifies that the other parameters on the line apply to the interface
numbered 0,1,2, or 3 in SGOS terms.

passwd=XXX

Specifies an RIPv2 password included on all RIPv2 responses sent and
checked on all RIPv2 responses received. The password must not contain any
blanks, tab characters, commas or ‘#’ characters.

no_ag

Turns off aggregation of subnets in RIPv1 and RIPv2 responses.

164

Chapter 10: Managing Routing Information Protocols (RIP)
Table 10–3 RIP Parameters (Continued)

Parameters

Description

no_super_ag

Turns off aggregation of networks into supernets in RIPv2 responses.

passive

Marks the interface to not be advertised in updates sent through other
interfaces, and turns off all RIP and router discovery through the interface.

no_rip

Disables all RIP processing on the specified interface.

no_ripv1_in

Causes RIPv1 received responses to be ignored.

no_ripv2_in

Causes RIPv2 received responses to be ignored.

ripv2_out

Turns off RIPv1 output and causes RIPv2 advertisements to be multicast
when possible.

ripv2

Is equivalent to no_ripv1_in and no_ripv1_out. This parameter is set by
default.

no_rdisc

Disables the Internet Router Discovery Protocol. This parameter is set by
default.

no_solicit

Disables the transmission of Router Discovery Solicitations.

send_solicit

Specifies that Router Discovery solicitations should be sent, even on point-topoint links, which by default only listen to Router Discovery messages.

no_rdisc_adv

Disables the transmission of Router Discovery Advertisements.

rdisc_adv

Specifies that Router Discovery Advertisements should be sent, even on
point-to-point links, which by default only listen to Router Discovery
messages.

bcast_rdisc

Specifies that Router Discovery packets should be broadcast instead of
multicast.

rdisc_pref=N

Sets the preference in Router Discovery Advertisements to the integer N.

rdisc_interval=N

Sets the nominal interval with which Router Discovery Advertisements are
transmitted to N seconds and their lifetime to 3*N.

trust_gateway=rname

Causes RIP packets from that router and other routers named in other
trust_gateway keywords to be accept, and packets from other routers to be
ignored.

redirect_ok

Causes RIP to allow ICMP Redirect messages when the system is acting as a
router and forwarding packets. Otherwise, ICMP Redirect messages are
overridden.

ProxySG-Specific RIP Parameters
The following RIP parameters are unique to ProxySG configurations:

165

Volume 5: Advanced Networking

Table 10–4 ProxySG-Specific RIP Parameters

Parameters

Description

supply_routing_info

-s option:

-or-

Supplying this option forces routers to supply routing
information whether it is acting as an Internetwork router
or not. This is the default if multiple network interfaces are
present or if a point-to-point link is in use.

advertise_routes

-g option:

This flag is used on Internetwork routers to offer a route to
the `default' destination. This is typically used on a
gateway to the Internet, or on a gateway that uses another
routing protocol whose routes are not reported to other
local routers.
-h option:
Suppress_extra_host_routes advertise_host_route
-m option:
Advertise_host_route on multi-homed hosts
-A option:

Ignore_authentication //
no_supply_
routing_info

-q option:

no_rip_out

Disables the transmission of all RIP packets. This setting is
the default.

no_ripv1_out

Disables the transmission of RIPv1 packets.

no_ripv2_out

Disables the transmission of RIPv2 packets.

rip_out

Enables the transmission of RIPv1 packets.

ripv1_out

Enables the transmission of RIPv1 packets.

rdisc

Enables the transmission of Router Discovery
Advertisements.

ripv1

Causes RIPv1 packets to be sent.

ripv1_in

Causes RIPv1 received responses to be handled.

opposite of -s.

Using Passwords with RIP
The first password specified for an interface is used for output. All passwords
pertaining to an interface are accepted on input. For example, with the following
settings:
if=0 passwd=aaa
if=1 passwd=bbb
passwd=ccc

Interface 0 accepts passwords aaa and ccc, and transmits using password aaa.
Interface 1 accepts passwords bbb and ccc, and transmits using password bbb. The
other interfaces accept and transmit the password ccc.

166

Chapter 11: Configuring the ProxySG as a Session Monitor

This chapter discusses how you can configure the SGOS software to monitor
RADIUS accounting messages and to maintain a session table based on the
information in these messages. The session table can then be used for logging
or authentication.
You can also, optionally, configure multiple appliances to act as a session
monitor cluster. The session table is then replicated to all members of the cluster.
Once configured and enabled, the session monitor maintains a session table
that records which sessions are currently active and the user identity for each
session.

Topics in this Chapter
This chapter includes information about the following topics:


"Configuring the Session Monitor" on page 167



"Creating the CPL" on page 170

Configuring the Session Monitor
Three steps are required to configure the session monitor:


Configure the RADIUS accounting protocol parameters for the session
monitor.



(Optional) Configure the session monitor cluster.



Configure the session monitor parameters.

Configuring the RADIUS Accounting Protocol Parameters
The configuration commands to create the RADIUS accounting protocol
parameters can only be done through the CLI. If you are using session-monitor
clustering, the commands must be invoked on each system in an alreadyexisting failover group. (For information on configuring a failover group, see
Chapter 7: "Configuring Failover" on page 125.)
To configure the RADIUS accounting protocol parameters:


To enter configuration mode:
SGOS#(config) session-monitor



The following subcommands are available:
SGOS#(config session-monitor) radius acct-listen-port port_number
SGOS#(config session-monitor) radius authentication {enable |
disable}
SGOS#(config session-monitor) radius encrypted-shared-secret
encrypted_secret

167

Volume 5: Advanced Networking
SGOS#(config session-monitor) radius no encrypted-shared-secret
SGOS#(config session-monitor) radius response {enable | disable}
SGOS#(config session-monitor) radius shared-secret plaintext_secret
t

Table 11–1 Session Monitor Accounting Command Descriptions

Command

Option

Description

radius acct-listen-port

port_number

The port number where the ProxySG listens for
accounting messages

radius authentication

enable | disable

Enable or disable (the default) the
authentication of RADIUS messages using the
shared secret. The shared secret must be
configured before authentication is enabled.

radius encrypted-sharedsecret

encrypted_shared_
secret

Specify the shared secret (in encrypted form)
used for RADIUS protocol authentication. The
secret is decrypted using the configurationpasswords-key.

radius no shared-secret

Clears the shared secret used for RADIUS
protocol authentication.

radius response

enable | disable

Enable (the default) or disable generation of
RADIUS responses.

radius shared-secret

plaintext_secret

Specify the shared secret used for RAIDUS
protocol in plaintext.

Configuring a Session Monitor Cluster
Configuring a session monitor cluster is optional. When a session monitor cluster
is enabled, the session table is replicated to all members of the cluster. The cluster
members are the ProxySG appliances that are configured as part of the failover
group referenced in the session monitor cluster configuration. The failover group
must be configured before the session monitor cluster. (For information on
configuring a failover group, see Chapter 7: "Configuring Failover" on page 125.)
To replicate the session table to all the members of a failover group, you can use
the following commands.
Note: When using a session monitor cluster, the RADIUS client must be

configured to send the RADIUS accounting messages to the failover group's
virtual IP address.
Proxy traffic can be routed to any of the machines in the cluster.
Note: Each member of the failover group must configured with the cluster

commands to maintain the session table for RADIUS accounting messages.
To configure session monitor cluster parameters:
SGOS#(config) session-monitor

168

Chapter 11: Configuring the ProxySG as a Session Monitor



The following subcommands are available:
SGOS#(config
SGOS#(config
SGOS#(config
SGOS#(config
SGOS#(config

session-monitor)
session-monitor)
session-monitor)
session-monitor)
session-monitor)

cluster
cluster
cluster
cluster
cluster

{enable | disable}
group-address IP_address
port port_number
grace-period seconds
synchronization-delay seconds

Table 11–2 Session Monitor Cluster Command Descriptions

Command

Option

Description

cluster

enable |
disable

Enable or disable (the default) clustering on a failover
group. The group address must be set before the
cluster can be enabled.

cluster group-address
| no group-address

IP_address

Set or clear (the default) the failover group IP address.
This must be an existing failover group address.

cluster port

port_number

Set the TCP/IP port for the session replication control.
The default is 55555.

cluster
synchronization-delay

seconds

Set the maximum time to wait for session table
synchronization. The default is zero; the range is from
0 to 2 ^31 -1 seconds. During this time evaluation of
$(session.username) is delayed, so proxy traffic
might also be delayed.

cluster grace-period

seconds

Set the time to keep session transactions in memory
while waiting for slave logins. This can be set to allow
session table synchronization to occur after the
synchronization-delay has expired. The default is 30
seconds; the range is 0 to 2^31-1 seconds.

Configuring the Session Monitor
The session monitor commands set up session monitoring behavior. If using
session-monitor clustering, these commands must be invoked on all systems in
the failover group.
To configure the session monitor:

1. At the (config) prompt:
SGOS#(config) session-monitor
SGOS#(config session-monitor) disable | enable
SGOS#(config session-monitor) max-entries integer
SGOS#(config session-monitor) timeout minutes

169

Volume 5: Advanced Networking

Table 11–3 Session Monitor Configuration Command Descriptions

Command

Option

enable | disable

Description
Enable or disable (the default) session monitoring

max_entries

integer

The maximum number of entries in the session
table. The default is 500,000; the range is from 1
to 2,000,000. If the table reaches the maximum,
additional START messages are ignored.

timeout

minutes

The amount of time before a session table entry
assumes a STOP message has been sent. The
default is 120 minutes; the range is from 0 to
65535 minutes. Zero indicates no timeout.

2. (Optional) To view the session-monitor configuration, you can either use the
session-monitor view command or the config show session-monitor
command.
SGOS#(config) show session-monitor
General:
Status: enabled
Entry timeout: 120 minutes
Maximum entries: 500000
Cluster support: enabled
Cluster port: 55555
Cluster group address: 10.9.17.159
Synchronization delay: 0
Synchronization grace period: 30
Accounting protocol: radius
Radius accounting:
Listen ports:
Accounting: 1813
Responses: Enabled
Authentication: Enabled
Shared secret: ************

Creating the CPL
Be aware that the examples below are just part of a comprehensive authentication
policy. By themselves, they are not adequate.
Note: Refer to Volume 10: Content Policy Language Guide for details about CPL and

how transactions trigger the evaluation of policy file layers.


In this example, the ProxySG is using the session table maintained by the
session monitor for authentication.

allow authenticate(session)

where session is a policy substitution realm that uses $(session.username) in
building the username. (For information on creating a Policy Substitution
realm, refer to Volume 4: Securing the Blue Coat ProxySG Appliance.)

170

Chapter 11: Configuring the ProxySG as a Session Monitor

Notes


The session table is stored entirely in memory. The amount of memory needed
is roughly 40MB for 500,000 users.



The session table is kept in memory. If the system goes down, the contents of
the session table are lost. However, if the system is a member of a failover
cluster, the current contents of the session table can be obtained from another
machine in the cluster. The only situation in which the session table is entirely
lost is if all machines in the cluster go down at the same time.



The session replication protocol replicates session information only;
configuration information is not exchanged. That means that each ProxySG
must be properly configured for session monitoring.



The session replication protocol is not secured. The failover group should be
on a physically secure network to communicate with each other.



The session monitor requires sufficient memory and at least 100Mb-persecond network links among the cluster to manage large numbers of active
sessions.



The username in the session table is obtained from the Calling-Station-ID
attribute in the RADIUS accounting message and can be a maximum of 19
bytes.

171

Volume 5: Advanced Networking

172

Chapter 12: Accelerating and Controlling Micro-Branch and
Mobile User Connections (ProxyClient)

This chapter describes the Blue Coat ProxyClient solution, which provides
security to mobile users and enables systems that do not reside behind a
gateway Blue Coat ProxySG to achieve accelerated performance and ensure
users abide by company Web usage policies.
This chapter discusses the following topics:


Section A: "ProxyClient Concepts" on page 174



Section B: "Configuring a ProxySG as the Client Manager" on page 205



Section C: "Configuring the ProxyClient" on page 216



Section D: "Distributing the ProxyClient Software" on page 266



Section E: "About the ProxyClient Application" on page 288



Section F: "Monitoring ProxyClient Performance" on page 293



Section G: "About the ProxyClient System Footprint" on page 298



Section H: "ProxyClient Troubleshooting" on page 304

173

Volume 5: Advanced Networking
Section A: ProxyClient Concepts

Section A: ProxyClient Concepts
Before configuring the ProxyClient, Blue Coat recommends that you understand
the conceptual information discussed in this section.
Note: This section assumes that you are familiar with the Blue Coat
Application Delivery Network (ADN) concepts and features, as described in
Chapter 2: "Configuring an Application Delivery Network" on page 17.

This section includes the following topics:











"Why Deploy ProxyClient?"
"Terminology" on page 175
"About Blue Coat in the Network" on page 177
"About the Roles of ProxySG Appliances With the ProxyClient" on page 178
"About the Role of the ProxyClient" on page 179
"About ProxyClient Licensing" on page 181
"About Location Awareness" on page 182
"About ADN Feature Support in ProxyClient" on page 192
"About ProxyClient Web Filtering" on page 196
"ProxyClient Security Disclaimers" on page 204

Why Deploy ProxyClient?
As mobile technology efficiency has advanced, so has the ability for enterprises
and other organizations to mobilize their workforce and allow access to remote
systems. Employees who are often in the field, at home, or in small offices—
including those who log into the corporate network through a Virtual Private
Network (VPN) connection—require the same performance that is achieved when
in the corporate network environment.
Likewise, corporations seek to extend the same security, policy control, and
tracking abilities that are available in the corporate network. Blue Coat designed
the ProxyClient solution to provide accelerated application delivery and Web
filtering in the following scenarios:


For employees using laptops and who work from both the office and the field.
These users enjoy accelerated network performance while on the corporate
network, but lose that performance when they must, from a remote location,
connect to the enterprise network using VPN.



For users in micro-branches, or offices with a very small number of users,
where it might not be cost-justifiable to deploy even the smallest Blue Coat
ProxySG acceleration gateway appliance.

In both of these scenarios, the ProxyClient maintains user productivity levels by
providing enterprise-grade performance, while also ensuring that the corporate
Web usage policies are maintained on company-owned systems in the field (only
users with administrator privileges can remove or disable the ProxyClient).

174

Chapter 12: Accelerating and Controlling Micro-Branch and Mobile User Connections (ProxyClient)
Section A: ProxyClient Concepts

Terminology
This chapter commonly uses to the following terms:


ProxyClient
Downloaded and installed on user systems, the ProxyClient provides
increased network performance and Web filtering when the connection is
from a network that is not fronted by a Blue Coat ProxySG. Users are afforded
some configuration and monitoring abilities.



ADN Manager
Every ADN network must have a ProxySG designated as the ADN Manager,
which is responsible for publishing the routing table to ProxyClients (and to
other ProxySG ADN peers).
You can optionally designate another ProxySG appliance as the backup
manager. This appliance takes over the duty of providing routing information
to ProxyClients in the event the ADN manager becomes unavailable.



Concentrator
A ProxySG appliance that receives inbound ADN tunnels from the
ProxyClient (and other ProxySG appliances on the ADN network) and
accelerates data center resources (such as file servers and Web applications).



Branch ProxySG
A ProxySG deployed near a branch office router (where branch office means a
small or regional office). To retrieve client file and data requests from servers
located in the corporate data center, the branch proxy connects to the ADN
concentrators—which are advertised by the ADN manager or discovered
transparently—in the data centers at the corporate location.
If the branch location has servers, the branch peer also serves as a
concentrator. A branch ProxySG can provide acceleration, Web filtering, or
both for the branch office.



Client Manager
A Client Manager is a ProxySG (running a compatible version of SGOS) that
provides the ProxyClient software to users, maintains the software and the
client configuration of all clients in the ADN network. Commonly, the Client
Manager appliance is deployed in the intranet behind the enterprise VPN
gateway, with a router connection to the Internet.
For details, including which SGOS versions are supported, see the
ProxyClient Release Notes.



Mobile user
Employees who use laptops with ProxyClient installed and travel from
corporate locations to other locations, such as customer sites, hotels, or home
offices. Mobile users does not refer to users with hand-held devices.

175

Volume 5: Advanced Networking
Section A: ProxyClient Concepts


Location awareness
The ability of the ProxyClient to detect the presence of a network connection
and enable or disable acceleration and Web filtering as determined by policy.
For example, you typically disable both ProxyClient acceleration and Web
filtering in the office but enable them for mobile users.
The ProxySG administrate determines the criteria that define locations and
enables or disables acceleration and Web filtering for each location.



Byte caching
A specific form of compression that looks for repeated data patterns
transmitted over the WAN. Byte caching plus other forms of compression
(such as gzip) optimizes the data sent over the TCP tunnel.



Common Internet File System (CIFS) optimization
ProxyClient significantly enhances WAN file service delivery by
implementing the following:


CIFS protocol optimization, which improves performance by
consolidating data forwarded across the WAN.



Client object caching, which enables clients to get previously obtained
data from the cache rather than from across the WAN.

These terms are brief descriptions of ADN technology as they relate to
ProxyClient. For more detailed information about the Blue Coat WAN optimization
solution, see Chapter 2: "Configuring an Application Delivery Network".

176

Chapter 12: Accelerating and Controlling Micro-Branch and Mobile User Connections (ProxyClient)
Section A: ProxyClient Concepts

About Blue Coat in the Network
ProxyClient optimizes the enterprise network conduit between remote or microbranch office systems and ProxySG appliances. Figure 12–1 provides a high-level,
logical view of Blue Coat deployed in the network.

Figure 12–1 Blue Coat in the network

Blue Coat does not provide strict guidelines for determining whether a remote
location requires a local ProxySG. Generally, use a local ProxySG if the branch
office has a data center (that is, file servers and so on) and to offload acceleration
and Web filtering functions from the corporate ProxySGs to the branch.
Blue Coat recommends considering a ProxyClient-only solution at a remote
location if any of the following is true:


The remote location is a mobile user whose location is constantly changing.



The remote location is a home office.



The remote location has a few users and therefore does not justify a local
ProxySG appliance.

In any of the proceeding locations, you might provide connectivity to the
corporate network with VPN client software; however, that is not a requirement
for using the ProxyClient.

177

Volume 5: Advanced Networking
Section A: ProxyClient Concepts

Note: Refer to the ProxyClient Release Notes for the latest list of supported VPN
technologies and operating systems.

About the Roles of ProxySG Appliances With the ProxyClient
One or more ProxySG appliances interact with ProxyClients in the following
ways:


ADN Manager and backup manager—As discussed in "Terminology" on page
175, you must configure an ADN Manager and Blue Coat recommends you
also configure a backup manager.



Client Manager—The ProxySG that provides the management infrastructure
to ProxyClients, including the following services:


Software for the client (initial deployment and updates)



Periodic verification of the Blue Coat Web Filter (BCWF) license and
database (required to use BCWF)



Monitoring



Client configuration management (such as Web filtering policy)

Note: The Client Manager can be any appliance in the ADN network, including a
concentrator, the ADN manager, or a backup manager. For example, the Client
Manager could also be the ADN manager, but that is not a requirement.

178



Concentrator—A ProxySG that terminates ProxyClient ADN tunnels, and
provides two-way compression and data forwarding to and from the
appropriate server. A concentrator accelerates network traffic.



Branch ProxySG—Depending on how it is configured, a branch ProxySG
might provide acceleration and Web filtering for a branch office.

Chapter 12: Accelerating and Controlling Micro-Branch and Mobile User Connections (ProxyClient)
Section A: ProxyClient Concepts

The following diagram illustrates a high-level network architecture involving
ProxyClient.

Figure 12–2 High-level ProxyClient network diagram

About the Role of the ProxyClient
The ProxyClient software is made available either manually by user installation
or is pre-installed by administrators. After it is installed and enabled, ProxyClient
mimics a proxy appliance and processes requests.
For example, if Web filtering is enabled and a user requests the URL
www.amazon.com, a policy check occurs to verify that Shopping is an allowable
category.
If acceleration is enabled and a user requests a file transfer, ProxyClient applies
the Blue Coat ADN compression capability to the CIFS protocol. The following
diagram illustrates the high level decision order within ProxyClient (and assumes
a valid base SGOS or trial license is installed).

179

Volume 5: Advanced Networking
Section A: ProxyClient Concepts

ProxyClient

FLOW
1—A mobile or micro-branch user initiates a request (either for files or for Web content by requesting a
URL).
2—Assuming the license is valid and ProxyClient Web Filtering is enabled, ProxyClient performs a URL
policy check (which involves more operations than depicted here). If the policy action is allow, the request
continues to the acceleration check.
3—ProxyClient determines if ADN acceleration is enabled and applicable to this object.
4a—If the ADN Manager is advertising ADN routes, the traffic routes to the proper ADN concentrator (that is,
the ProxySG with the associated byte cache).
4b—Requests are sent directly to the destination if there is no concentrator advertising a route to the
destination; or when the only route is to the default Internet gateway and the destination is in the gateway’s
exempt subnets list.

Figure 12–3 ProxyClient data flow decision diagram

180

Chapter 12: Accelerating and Controlling Micro-Branch and Mobile User Connections (ProxyClient)
Section A: ProxyClient Concepts

Note: More information about Web filtering is discussed in "About ProxyClient

Web Filtering" on page 196.

About ProxyClient Licensing
There are two ProxyClient feature license components:


The ProxyClient—Acceleration license enables the ProxyClient to accelerate
ADN traffic, optimize file transfers using the CIFS protocol, and collect
statistics to ProxyClient systems in your enterprise.
The Client Manager license enables unlimited ProxyClient connections
provided the SGOS base license is valid; however, concentrators have user
limits. Each unique IP address counts as one user.
Although the Client Manager license enables it to support unlimited users,
you must size your ProxyClient deployment based on Client Manager
scalability and concentrator user limits.



The ProxyClient—Web Filtering license enables content filtering policy
enforcement on ProxyClients.

Important:



ProxyClient Web Filtering requires a valid Blue Coat Web Filter (BCWF)
contract, with a valid BCWF database installed on the Client Manager
(that is, the database must be updated at least once every 30 days).



Even if you have BCWF databases installed on other ProxySG appliances
serving as forward proxies, you must download the BCWF database on
the Client Manager.

Licenses are installed on the ProxySG and managed the same as other ProxySG
features (as described in Volume 1: Getting Started). For ProxyClient, the feature
licenses components enable the ProxySG to be a Client Manager. Any ProxySG
still operating in the trial period can be a Client Manager as well. Client (user)
systems do not require licenses to use the ProxyClient software.

181

Volume 5: Advanced Networking
Section A: ProxyClient Concepts

Software and Hardware Requirements
For information about software and hardware requirements, see the ProxyClient
Release Notes.

About Location Awareness
This following sections discuss location awareness:




"Overview of Location Awareness"
"About Location Conditions" on page 183
"About Condition Rulebase Ordering" on page 191

Overview of Location Awareness
Location awareness enables administrators to enable or disable ProxyClient
acceleration and Web filtering functionality based on the location from which the
client connects.
For example, the administrator should disable both acceleration and Web filtering
for users in the office if ProxySG concentrators and proxies in the office perform
those functions. Administrators should enable both acceleration and Web filtering
for mobile users because there is no local ProxySG to perform those functions. (In
general, enable the ProxyClient to perform functionality a local ProxySG does not
perform.)
Locations are defined by the ProxySG administrator using one or more the
following location conditions (Configuration > ProxyClient > General > Locations):


Source IP range, which is appropriate for situations (such as in the office)
where you know the IP address range from which clients connect.



DNS server IP address
In some situations, the client’s IP address might not be enough to uniquely
define a location. If that is the case, DNS servers can be used as additional
location conditions.



Virtual network interface IP address, which should be used whenever clients
connect to the corporate network using VPN software.
VPN software typically creates a virtual network adapter (referred to as a
virtual NIC) that is assigned an IP address that is used when the client
connects to the corporate network over VPN.
A VPN gateway behind the firewall at the corporate data center provisions IP
addresses and DNS server addresses to VPN clients.

Note: Location conditions are logically ANDed together so choosing more
than one location condition for a location is a good way to uniquely identify
the location.

182

Chapter 12: Accelerating and Controlling Micro-Branch and Mobile User Connections (ProxyClient)
Section A: ProxyClient Concepts

About Location Conditions
This section discusses general guidelines to follow when setting up locations and
provides an example:



"General Guidelines for Location Conditions"
"Location Example" on page 184

General Guidelines for Location Conditions
In general, configure the ProxyClient to perform the features that a ProxySG does
not perform (that is, either acceleration or Web filtering). When planning your
ProxyClient deployment, Blue Coat recommends you take the following into
account:


Whether or not a ProxySG at the location performs acceleration or Web
filtering



Which two of the three available location conditions uniquely defines the
location

The following table shows how to use these guidelines in a sample four-location
deployment:
Location type

How to apply the guidelines

Mobile with no local
ProxySG

• Role of local ProxySG: There is none so the location
should enable both ProxyClient acceleration and Web
filtering.
• Location conditions: To uniquely identify the
location, choose Virtual NIC IP address and DNS
server IP address.

Headquarters with several
local ProxySGs

• Role of local ProxySGs: Perform both acceleration
and Web filtering so the location should disable both
features.
• Location conditions: To uniquely identify the
location, choose source IP address range and DNS
server IP address.

Branch office with no local
ProxySG

• Role of local ProxySG: There is none so the location
should enable ProxyClient acceleration. However, if
a branch ProxySG at headquarters performs Web
filtering, you should disable Web filtering at the
branch office.
• Location conditions: To uniquely identify the
location, choose source IP address range and DNS
server IP address.

183

Volume 5: Advanced Networking
Section A: ProxyClient Concepts
Location type

How to apply the guidelines

Branch office with a local
ProxySG

• Role of local ProxySG: If the local ProxySG performs
both acceleration and Web filtering, the location
should disable both.
However, if the local ProxySG performs only
acceleration, the location should disable ProxyClient
acceleration and enable Web filtering.
• Location conditions: To uniquely identify the
location, choose source IP address range and DNS
server IP address.

Location Example
Figure 12–4 shows a sample deployment with the following locations
(Configuration > ProxyClient > General > Locations):

184



A home office or mobile user that uses VPN to connect to the network



Company headquarters



Branch office with no local ProxySG; in this example, there is an IP address
conflict to illustrate the importance of choosing more than one location
condition



Branch office with a local ProxySG that performs both acceleration and Web
filtering

Chapter 12: Accelerating and Controlling Micro-Branch and Mobile User Connections (ProxyClient)
Section A: ProxyClient Concepts

Figure 12–4 ProxyClient location awareness

The following sections discuss Figure 12–4 in more detail:





"Home Office or Mobile Location"
"Headquarters Location" on page 187
"Branch Office Location with no ProxySG" on page 189
"Branch Office With a Local ProxySG" on page 190

Home Office or Mobile Location
The home office user in Figure 12–4 connects to the corporate network using VPN.
The network administrator configures a VPN gateway at headquarters to
provision a pool of IP addresses and DNS server IP addresses for connecting to
the corporate network. In this example, the IP address range is a subset of the
headquarters IP address range.
The user’s VPN client software creates a virtual network adapter (also referred to
as a virtual NIC) that has an IP address that is used when the user connects to the
network.
In Figure 12–4, the VPN IP address (also referred to as a virtual NIC IP) for the
home office user is 10.3.0.5.

185

Volume 5: Advanced Networking
Section A: ProxyClient Concepts

Setting up the home office or mobile location
Keeping in mind the information discussed in "General Guidelines for Location
Conditions" on page 183, the ProxySG administrator notes that in this location,
there is no ProxySG to perform either acceleration or Web filtering.
Therefore, to enable location awareness for home office or mobile users, the
administrator sets up a location similar to the following:

186

Chapter 12: Accelerating and Controlling Micro-Branch and Mobile User Connections (ProxyClient)
Section A: ProxyClient Concepts

The administrator chooses to match both of the following:


A Virtual NIC IP range that matches the IP address range the VPN gateway at
headquarters provisions. In this example, the Virtual NIC IP range is a subset
of the headquarters IP address range.
If your VPN hardware device manages its own IP addresses, or if you
configure your VPN hardware to provision IP addresses in a particular range,
make sure you enter the correct address range; otherwise, clients will not be
identified at the correct location.



To make sure the location is unique, the administrator adds the DNS servers’
IP addresses.

Enabling features for the home office location
The ProxySG administrator enables both ProxyClient acceleration and Web
filtering for this location because the user does not connect to a branch ProxySG.
Note: Some VPN software does not create a virtual NIC with a separate IP

address. Instead, the computer uses the IP address assigned to it by the user’s
home router or DHCP server. In that case, the administrator has the following
options:


If this VPN solution enables the client computer to keep its IP address
and DNS server, the same location works because even though the
user’s IP address might conflict with headquarters, the DNS server IP
address will not. The user will be correctly identified in both locations.



Configure default policy actions, which are used when users do not
match any location conditions. For more information, see "Configuring
Default Actions" on page 230.

Headquarters Location
Users at headquarters connect to a ProxySG concentrator. Other ProxySG
appliances at headquarters might perform other functions, such as Web filtering.

Setting up the headquarters location
Keeping in mind the information discussed in "General Guidelines for Location
Conditions" on page 183, the ProxySG administrator notes that in this location,
there are ProxySGs that perform both acceleration and Web filtering.

187

Volume 5: Advanced Networking
Section A: ProxyClient Concepts

Therefore, to enable location awareness for headquarters users, the administrator
sets up a location similar to the following.

The administrator chooses to match both of the following:


Source IP ranges because the administrator knows that users at headquarters
are assigned IP addresses in this range.



DNS servers because the administrator knows the DNS servers at
headquarters.
Together, source IP address ranges and DNS servers uniquely identify
headquarters users.

Enabling features for the headquarters location
The ProxySG administrator disables both ProxyClient acceleration and Web
filtering for this location because the user connects to a branch ProxySG at
headquarters. Web filtering services are provided by a branch ProxySG; at
headquarters, acceleration is usually not necessary because the client computer is
on the same network as the servers.

188

Chapter 12: Accelerating and Controlling Micro-Branch and Mobile User Connections (ProxyClient)
Section A: ProxyClient Concepts

Branch Office Location with no ProxySG
In this example, assume that because of a recent acquisition, the branch office gets
IP addresses assigned from the same network as headquarters (10.0.0.0 to
10.5.255.255) This source address range poses a potential problem for the ProxySG
administrator because it makes the two locations indistinguishable based on
source IP address alone.
Also, assume that the network is configured so traffic is sent from the branch
through headquarters so a branch ProxySG at headquarters performs Web
filtering.
Keeping in mind the information discussed in "General Guidelines for Location
Conditions" on page 183, the ProxySG administrator notes that in this location,
there is no ProxySG to perform acceleration but there is a branch ProxySG at
headquarters that performs Web filtering.
Therefore, to enable location awareness for branch office users, the administrator
sets up a location similar to the following:

The administrator chooses to match both of the following:


Source IP range because it partially identifies the branch office location.
However, the problem is that a computer at the branch office might be
identified as being at headquarters if only the source IP address range is used.
If a computer at this branch office is identified as being at headquarters,
neither acceleration nor Web filtering is enabled.

189

Volume 5: Advanced Networking
Section A: ProxyClient Concepts


The branch’s DNS server IP address because it is different from the DNS
servers at headquarters.
Because the administrator chooses to add the DNS server IP address to this
location condition, both the headquarters and branch office locations are
unique. Computers at each location will have the correct ProxyClient features
applied to them.

Enabling features for the branch office location (no ProxySG)
The ProxySG administrator enables ProxyClient acceleration but disables Web
filtering for this location. Acceleration is provided by the ProxyClient
communicating with a concentrator at headquarters.
Web filtering is provided by a branch ProxySG at headquarters so the
administrator disables Web filtering at the branch office.

Branch Office With a Local ProxySG
To a ProxySG administrator, configuring a branch office that has a local ProxySG
is similar to configuring the headquarters location.
Keeping in mind the information discussed in "General Guidelines for Location
Conditions" on page 183, the ProxySG administrator notes that in this location,
there is a ProxySG to perform both acceleration and Web filtering.
Therefore, to enable location awareness for branch office users, the administrator
sets up a location similar to the following.

190

Chapter 12: Accelerating and Controlling Micro-Branch and Mobile User Connections (ProxyClient)
Section A: ProxyClient Concepts

The administrator chooses to match both source IP address range and DNS server
IP address because both are unique to this branch office.

Enabling features for the branch office location (with ProxySG)
The ProxySG administrator disables both ProxyClient acceleration and Web
filtering for this location because the ProxySG at the branch office provides these
services.

About Condition Rulebase Ordering
The order in which locations display on the Configuration > ProxyClient > General >
tab page determine the order in which the rules are evaluated when
users connect to the Client Manager. To avoid mismatches, order the rules from
most to least restrictive.

Locations

For example, suppose headquarters uses IP addresses in the range from 10.0.0.0 to
10.255.255.255 but the VPN gateway located at headquarters has a pool of IP
addresses in a subset of that range; for example, 10.3.1.1 to 10.3.1.255. Because the
VPN gateway is used by home office or mobile users, the administrator wants to
use different policy actions for headquarters and home office users.
Users at the headquarters location should have ProxyClient acceleration and Web
filtering disabled but users in a home office or mobile location should have both
ProxyClient features enabled.
To accomplish that, the administrator creates the two locations as follows.
Location

Conditions

Headquarters

• Source IP address range: 10.0.0.0 to 10.255.255.255
• DNS server IP address: For example, 10.0.0.11 and
10.0.0.12

Home office or mobile

• DNS server IP address: Same as headquarters
• VNIC IP address range: 10.3.1.1 to 10.3.1.255

To make sure the home office or mobile location is detected first, the administrator
must order it in the rulebase before the headquarters location. An example
follows.

191

Volume 5: Advanced Networking
Section A: ProxyClient Concepts

About ADN Feature Support in ProxyClient
This section includes the following topics:




"ADN Features" on page 192
"About Internet Gateways" on page 193
"About Reflecting the ProxyClient IP Address" on page 194

ADN Features
The ProxyClient supports the following ADN features:


Byte caching—Byte caching is a compression mechanism where data tokens
that represent larger blocks of repeated data are sent across the WAN.
When one of these data tokens match tokens in the data dictionary cached on
the ProxyClient computer, the entire block of data is passed to the application
that requested it, resulting in reduced WAN bandwidth. For example, if you
request a file using Internet Explorer and a data dictionary match is found, the
data is sent to Internet Explorer.
If no data dictionary match is found, the token and its corresponding byte
values are added to the data dictionary cached on the ProxyClient computer.
A data token is a few bytes in size; the corresponding block of data for a token
is much larger.



CIFS protocol (file sharing) optimization and CIFS object caching on the
client—Regions of files that are read or written by the client are placed in the
cache. Object caching applies to both read and write file activities.

Note: You can set the maximum percentage of total disk space (as opposed to

available disk space) the ProxyClient allocates to the byte cache and the CIFS
cache. The ProxyClient always leaves at least 1GB of available disk space on
the client computer. By default, the cache is located on the system root volume
but the cache location can be changed as discussed in "Changing the Location
of the Cache" on page 324.


Load balancing and failover—The ProxyClient attempts three types of
connections in the ADN network: the routing connection, the ADN tunneling
connection, and a control connection. The routing connection obtains the routing
table from the ADN Manager or backup Manager; the tunneling connection
transfers data to the ADN network; and the control connection contains client
identification information.
The ProxyClient first attempts to connect to the primary ADN manager to get
routing information; if the ADN Manager is not available, the client attempts
to connect to the backup ADN Manager. If the backup ADN manager is also
not available, the connection continues on (bypassed by ADN) because an
ADN route is not provided. When either of the ADN Managers becomes
available again, acceleration automatically resumes.

192

Chapter 12: Accelerating and Controlling Micro-Branch and Mobile User Connections (ProxyClient)
Section A: ProxyClient Concepts

Client connections that do not go through a concentrator are not accelerated
and remain unaccelerated as long as the connection is open (that is, until the
connection is closed by the application).
After a concentrator becomes available, new connections are accelerated.
ADN peer affinity helps maintain fast application performance by persisting
connections from a ProxyClient to a particular concentrator and therefore
reusing the byte cache. After establishing a connection to an ADN peer,
ProxyClient always attempts to connect to that peer; a connection to another
peer occurs only when the initial peer becomes unavailable.


Cache encryption—To maintain a high security level after content is retrieved
over the network connection, ProxyClient supports the Microsoft Encrypted
File System (EFS), which makes it extremely difficult for malicious users to
hack into a user system’s cache to retrieve company-sensitive files.
No other user can access the data in the cache, even the system administrator.
If ProxyClient is uninstalled, the EFS encrypted caches are also deleted.
Note: EFS is supported only on the New Technology File System (NTFS)

partitions, although Windows XP Home Edition supports NTFS, but not EFS.
File Allocation Table (FAT) or FAT32 partitions do not support EFS and
therefore, the cache is not encrypted on those partitions.

About Internet Gateways
The ProxyClient honors Internet Gateway settings. Network traffic that is not
bound by ADN routing rules routes to the specified gateway unless an exception
rule applies.
There are some routes, such as those for local hosts, that are not required to go
through the ADN Internet gateway. You can define these routes using the
ProxySG Management Console (Configuration > ADN > Routing > Internet Gateway).
ProxyClient uses this configuration.

193

Volume 5: Advanced Networking
Section A: ProxyClient Concepts

About Reflecting the ProxyClient IP Address
When the ProxyClient version 3.1 or later attempts to connect to a destination, it
always requests the concentrator reflect its IP address. The concentrator can be
configured to either reflect the client’s IP address or to reject the reflection request.
Concentrator client IP reflection configuration determines what IP address the
concentrator advertises to the origin server as the source address—the
concentrator’s own address (referred to as use local IP) or as the ProxyClient
computer’s address (referred to as reflect the client IP).
Note: For client IP reflection to work, the concentrator used by the ProxyClient

should be deployed inline between the ProxyClient and the origin server. In
other words, the return packets will have ProxyClient's IP address as the
destination address and must be routed back through the same concentrator.
If the origin server is able to connect directly back to the ProxyClient computer,
the connection fails. This happens because the concentrator opens a different
connection to the origin server than the one originally opened by the
ProxyClient, so response packets going directly from the origin server to the
ProxyClient will be rejected and the connection will fail.
If the concentrator is deployed out of line, you can configure the concentrator
to use local IP.
For example, suppose the ProxyClient requests data from a server in the corporate
data center. The ProxyClient request is accepted by a ProxySG concentrator,
which sends the request to the server. When the concentrator sends the request,
you can configure the following IP reflection options:


Allow the request and reflect the client IP—The concentrator can present its own IP

address as the source address.
Select this option if your network is configured so that the origin server
cannot reach a ProxyClient computer with an outside IP address; in other
words, an IP address located outside the internal network.

194



Allow the request but use a local IP—The concentrator can present the ProxyClient
computer IP address as the source address.



Reject the request—If

the concentrator can be configured to deny client
reflection, in which case one of the following occurs:


If the concentrator runs SGOS 5.3 or later, the concentrator presents its
own IP address as the source address. This option is equivalent to Allow the
request but use a local IP.



If the concentrator runs an SGOS version earlier than 5.3, the connection
fails.

Chapter 12: Accelerating and Controlling Micro-Branch and Mobile User Connections (ProxyClient)
Section A: ProxyClient Concepts

Note: If a ProxyClient connects to an ADN concentrator running an SGOS

version earlier than 5.3, and that concentrator that is configured to reject client IP
reflection requests, you must change the configuration. Otherwise, ProxyClients
cannot connect to origin servers.
Any of the following options can be used with the ProxyClient:


Management Console using the Configuration > ADN > Tunneling > Network
tab page.
Choose either of the following options (click Help for more information
about the options):





Allow the request and reflect the client IP



Allow the request but use a local IP

Command line:


SGOS#(config adn tunnel) reflect-client-ip allow



SGOS#(config adn tunnel) reflect-client-ip use-local-ip

195

Volume 5: Advanced Networking
Section A: ProxyClient Concepts

About ProxyClient Web Filtering
Web filtering is required by many enterprises for security and compliance
reasons. Network managers want the security of knowing users can be prevented
from accessing Web sites with malicious content. Human Resources wants to
prevent users from accessing offensive content or from losing productivity due to
too much Web surfing.
Blue Coat’s Web filtering solution provides an answer for both concerns by
providing robust filtering—both in the office and on the road.
This section discusses Web filtering in the following sections:






"Web Filtering Terminology"
"How Blue Coat Enforces Web Filtering for Remote and Micro-Branch Users"
on page 197
"Enabling or Disabling Web Filtering Based on Location" on page 198
"About the BCWF Database and Categorization" on page 201
"About Security With Guest User Scenarios" on page 204

Web Filtering Terminology
This section defines common terms used to discuss ProxyClient Web filtering.


Blue Coat Web Filtering (BCWF) database
A database that stores URLs and their corresponding categories. The database
is maintained by Blue Coat and is accessible by service points located around
the globe.
To enable and use ProxyClient Web filtering, the BCWF database must be
downloaded on the Client Manager and updated at least once every 30 days.
(The database must be downloaded on the Client Manager for licensing
purposes only; the ProxyClient does not use the BCWF database on the Client
Manager.)
The administrator chooses categories and policy actions for each category;
these categories and actions are downloaded to the ProxyClient in its
configuration file. For example, you can configure the ProxyClient to block
any Web site that is categorized in the BCWF database as Pornography and to
allow any Web site that is categorized as News/Media.



Category
Each known URL is classified into one or more categories. These categories
are used by ProxySG administrators to determine whether a user who goes to
a URL is allowed to access it, is blocked from accessing it, or is warned about
accessing it.



Service point
Located around the world, service points obtain a URL categorization from
the BCWF database. Anytime a ProxyClient user browses to a URL whose
policy action has not already been cached on the client, the service point

196

Chapter 12: Accelerating and Controlling Micro-Branch and Mobile User Connections (ProxyClient)
Section A: ProxyClient Concepts

returns the category for the URL. If the URL has not yet been categorized, the
URL goes to DRTR.
URLs, categories, and policy actions are temporarily cached on the
ProxyClient computer.


Dynamic Real-Time Rating (DRTR)
A service that categorizes URLs that are not yet categorized in the BCWF
database.

Note: One major difference between ProxyClient Web filtering and branch

ProxySG Web filtering is that categorization for the ProxyClient is performed
by service points and, if necessary, DRTR. ProxyClient categorization is not
performed by the Client Manager.
To use ProxyClient Web filtering, you must enable the BCWF database on the
Client Manager. However, DRTR does not need to be enabled on the Client
Manager because DRTR lookup is always performed for any uncategorized
ProxyClient request without the Client Manager’s involvement.


Policy action
The action that is applied to a ProxyClient URL request. Possible actions are
allow, block and warn. More information about these policy actions can be
found in "How Blue Coat Enforces Web Filtering for Remote and MicroBranch Users" .



WebPulse
The service that provides Dynamic Web Analysis; in other words, the service
that includes the BCWF database, service points, and DRTR.

How Blue Coat Enforces Web Filtering for Remote and Micro-Branch
Users
The ProxyClient filters URL requests based on the configuration file it downloads
from the Client Manager. The configuration file determines the following:


Whether or not Web filtering is enabled for the user’s location.
More information about Web filtering and location awareness can be found in
"Enabling or Disabling Web Filtering Based on Location" on page 198.



Web site categories the administrator configures on the Client Manager and
policy actions for each. Possible policy actions are allow, warn, and block.
URL categorization is performed either by the service point or DRTR. URLs
and categories are stored in the BCWF database.

197

Volume 5: Advanced Networking
Section A: ProxyClient Concepts

Note: One major difference between ProxyClient Web filtering and branch
ProxySG Web filtering is that categorization for the ProxyClient is performed
by service points and, if necessary, DRTR. ProxyClient categorization is not
performed by the Client Manager.

To use ProxyClient Web filtering, you must enable the BCWF database on the
Client Manager. However, DRTR does not need to be enabled on the Client
Manager because DRTR lookup is always performed for any uncategorized
ProxyClient request without the Client Manager’s involvement.
For the ProxyClient to perform Web filtering, ProxySG administrators must
enable the following features on the Client Manager:


The Blue Coat Web Filter database: Configuration > Content Filtering > General.



Download the current BCWF database: Configuration > Content Filtering > Blue
Coat.



Categories for use by the ProxyClient and policy actions for each: Configuration
> ProxyClient > Web Filtering > Policy.

More information about these options can be found in:


"Configuring ProxyClient Web Filtering" on page 231



Volume 7: Managing Content

Enabling or Disabling Web Filtering Based on Location
You can enable or disable Web filtering based on a user’s location. For example, if
the user is at headquarters or in a branch office where there is a branch ProxySG
that performs Web filtering, you should disable ProxyClient Web filtering. You
should enable ProxyClient Web filtering in mobile locations because mobile users
do not connect to a branch ProxySG.
Use location awareness to enable or disable ProxyClient features as discussed in
"About Location Awareness" on page 182.
The key differences between Web filtering features offered by the ProxyClient and
the ProxySG follow:


Multiple operating system support: Currently, the ProxyClient is supported
only on Windows clients, while any computer in an ADN network can have
Web filtering policies applied to it by a branch ProxySG.
For details about ProxyClient operating system support, see the ProxyClient
Release Notes.

198

Chapter 12: Accelerating and Controlling Micro-Branch and Mobile User Connections (ProxyClient)
Section A: ProxyClient Concepts


Web filtering policies can be set per user: Using CPL or VPM, you can
configure the branch ProxySG to apply different Web filtering policies for
users or groups. For example, a network administrator might have a less
restrictive Web filtering policy than an ordinary user.
More information about performing these tasks can be found in Volume 10:
Content Policy Language Guide or Volume 6: The Visual Policy Manager and
Advanced Policy.

Figure 12–5 illustrates the Web filter service decisions in a sample two-location
configuration.
ProxyClient

User’s
location?
Mobile

No

ProxyClient
filtering
enabled?

Office

Yes

ProxyClient
filtering
enabled?

No

Categorization

Policy actions
Acknow- Warn
lege?

Policy
action

No
Yes

Redirect
page

Request
goes to
destination

User denied
page

Figure 12–5 High-level diagram of ProxyClient Web filtering

199

Volume 5: Advanced Networking
Section A: ProxyClient Concepts

In the preceding figure, two locations are defined: Mobile and Office. The
following sections discuss how the ProxyClient processes Web filtering for each
location:



"Mobile Web Filtering Summary"
"In-Office Web Filtering Summary" on page 201

Mobile Web Filtering Summary
This section discusses a summary of the mobile Web filtering process. For more
detail, see "About Categorization" on page 201.
If the user is in a mobile location without a branch ProxySG:
1. The user requests a URL.
2. The ProxyClient’s configuration file determines whether or not Web filtering
is enabled for this location:


If ProxyClient Web filtering is disabled, the URL request goes to its
destination. That is the end of the process.



If ProxyClient Web filtering is enabled, continue with step 3.

3. The ProxyClient collects Web filtering categories from its configuration file.
4. The ProxyClient requests a category for the URL from a service point.
The result of the request can be one of the following:


The URL request is categorized by a service point, if a result was not found
in the cache.



If the URL is not found in the BCWF database, the service point gets a
categorization using DRTR.



If DRTR cannot determine a URL’s category, the URL is categorized as
and the appropriate policy action is taken.

none



If no service point is available, the URL is categorized as unavailable and
the appropriate policy action is taken.

5. After categories are determined, the ProxyClient’s configuration file
determines the policy action (block, deny, or warn) according to the first
match in the rulebase.
If the policy action is warn, the user can visit the Web site for 15 minutes after
clicking an acknowledgement link.
6. Results of service point lookups are temporarily cached.

See Also
"About Categorization" on page 201
"About Location Conditions" on page 183
"Assigning Policy Actions to Content Categories" on page 240
"Web Filtering Best Practices" on page 251

200

Chapter 12: Accelerating and Controlling Micro-Branch and Mobile User Connections (ProxyClient)
Section A: ProxyClient Concepts

In-Office Web Filtering Summary
This section discusses the main differences between in-office Web filtering and
mobile Web filtering. If a user is in an office that has a branch ProxySG and if the
user’s location is identified as in the office, you should disable ProxyClient Web
filtering in the location.
The branch ProxySG then performs the following tasks:


The branch ProxySG performs categorization and, if necessary, gets a category
from DRTR.



Specific policies defined on the branch ProxySG can be applied to users and
groups. For example, network administrators might have less restrictive
policy actions applied to them compared to ordinary users.

About the BCWF Database and Categorization
This section discusses the following topics:



"About the BCWF Database"
"About Categorization" on page 201

About the BCWF Database
The Client Manager is responsible for getting the current BCWF database at least
once every 30 days. If the database is not updated within 30 days since its last
update, BCWF becomes inactive and all URL requests are either allowed or
blocked, depending on the administrator’s choice for the On License Expiration
option located on the Configuration > ProxyClient > Web Filtering > Policy tab page.
Note: The Client Manager must keep the BCWF database current for licensing

purposes only. The ProxyClient does not use the BCWF database on the Client
Manager; instead, it gets URL categories from a service point.

About Categorization
Categorization is the process of assigning a classification to a particular requested
URL. If ProxyClient Web filtering is enabled for the user’s location, the
categorization process is as follows:
1. The user requests a URL.
2. The ProxyClient collects Web filtering categories from its configuration file.
Categories are defined by the following:


The local database, if enabled.



VPM policy, if configured.



Results of service point lookups that are temporarily cached on the user’s
computer.

3. The ProxyClient requests a category for the URL from a service point.

201

Volume 5: Advanced Networking
Section A: ProxyClient Concepts

The result of the request can be one of the following:


The URL request is categorized by a service point, if a result was not found
in the cache.
(The cache, which is temporary, consists of results from previous lookups.)



If the URL is not found in the BCWF database, the service point gets a
categorization using DRTR.



If DRTR cannot determine a URL’s category, the URL is categorized as
none and the appropriate policy action is applied.



If BCWF is not available, the URL is categorized as unavailable and the
appropriate policy action is applied.

Note: One Web site can have many URLs associated with it. For example,
many Web sites have advertisements that each trigger a URL request and
therefore a categorization request to the service point.

4. After categories are determined, the ProxyClient’s configuration file
determines the policy action (block, deny, or warn) according to the first
match in the rulebase.


If the policy action is allow, the request goes to its destination.



If the policy action is block, the blocked category exception page displays.



If the policy action is warn, a warning message displays.
The user must click an acceptance link, which represents an
acknowledgment that the content request might violate corporate Web use
policy. If the user clicks the acceptance link, the request goes to its
destination.
Note: If a user clicks the acceptance link, the requested Web site will be
accessible for 15 minutes. The accessibility time period is not currently
configurable for the Web site.

5. Results of service point lookups are temporarily cached.

Resolving Policy Action Conflicts
In step 4 of the preceding procedure, suppose the same URL is listed in two or
more categories with different policy actions.
In the case of a conflict between policy actions, the policy action associated with
the first rulebase match is applied.
For example, suppose the same URL (www.example.com/news) is listed in two
categories. One category has a policy action of allow and the other category has a
policy action of block.
In the table that follows, www.example.com/news is in both the Blogs/Personal
Pages and News/Media categories. The following table shows how the conflict is
resolved.

202

Chapter 12: Accelerating and Controlling Micro-Branch and Mobile User Connections (ProxyClient)
Section A: ProxyClient Concepts

Rulebase configuration

Policy action
Because News/Media is first in the
rulebase and its policy action is allow,
www.example.com/news is allowed.

Because Blogs/Personal Pages is first in
the rulebase and its policy action is
block, www.example.com/news is
blocked.

Note: If the user is in an office location with ProxyClient Web filtering

disabled, a branch ProxySG performs Web filtering. For more information
about configuring a branch ProxySG to perform Web filtering, see Volume 7:
Managing Content.
Blue Coat recommends you order Web filtering rules in the category rulebase as
follows:
1. Whitelist overrides (that is, local database and policy categories you always
want to allow)
2. Blacklist overrides (that is, local database and policy categories you always
want to block)
3. All other categories with policy action set to block
4. All other categories with policy action set to warn
5. All other categories with policy action set to allow

203

Volume 5: Advanced Networking
Section A: ProxyClient Concepts

About Security With Guest User Scenarios
When travelling, users might be required to initially access the Internet as a guest.
For example, some businesses and hotels provide WiFi or hard-wired networks,
but require users to gain access through a portal. When the user connects to the
network and opens their Web browser, the browser redirects to a welcome page
from which the user must interact to gain connectivity to the Internet.
The welcome page can be as simple as a click-through service agreement or as
complex as a service that requires a credit card payment for Internet access. After
users complete the required agreement or transaction, they are allowed to access
the Internet.
When the ProxyClient detects this, it enables the user to view the welcome page
and complete whatever authentication transaction is required to gain additional
connectivity without applying Web filtering. After the user can connect to the
Internet, the ProxyClient applies Web filtering policy.
ProxyClient operates within the restricted network before completing the
welcome page transaction, yet prevents any unauthorized user access.

ProxyClient Security Disclaimers
When you deploy the ProxyClient in your network, be aware of the following:


Any user with administrative privileges can disable the ProxyClient by
stopping the service or by disabling acceleration, Web filtering, or both.



Avoid allowing users with FAT and FAT32 partitions to download the
ProxyClient for the following reasons:





EFS encryption is not supported; therefore, the object cache (that is, the
byte cache and CIFS cache) will not be encrypted.



Because the ProxyClient uses NTFS permissions, Web filtering can be
bypassed on FAT or FAT32 partitions and logs can be deleted.

Any user with sufficient privileges to edit files on the machine can change the
Web filtering log files before or after they are uploaded to the FTP server.
Because the FTP server allows anonymous access, anyone can download a log
file, change it, and upload it again without detection (although your FTP
server can report the source IP address used to upload log files).
The preceding vulnerabilities can be exploited by a legitimate user or by an
unauthorized user (such as a hacker or malware).



If a user runs a VMWare image on their computer, even if the computer has
the ProxyClient, the VMWare image can access the Internet without
restrictions, effectively circumventing Web filtering. (The VMWare image also
operates without acceleration.)
To avoid this issue, install the ProxyClient software on the VMWare image.

204

Chapter 12: Accelerating and Controlling Micro-Branch and Mobile User Connections (ProxyClient)
Section B: Configuring a ProxySG as the Client Manager

Section B: Configuring a ProxySG as the Client Manager
This section describes how to configure the ProxySG Client Manager to manage
the ProxyClient application.
This section includes the following topics:





"About ProxyClient Deployment"
"Preparing the ProxySG ADN Configuration for ProxyClient Deployment" on
page 207
"Designating a ProxySG as the Client Manager" on page 210
"Uploading the ProxyClient Software to the Client Manager" on page 214

About ProxyClient Deployment
ProxyClient deployment requires the following high-level tasks:


A ProxySG administrator configures the Client Manager options, which
define the behavior of the ProxyClient application.



The user (or administrator) installs the ProxyClient application on remote and
desktop computers (or provides instructions describing how to perform the
installation).

This section discusses the high-level administrator configuration tasks and client
installation tasks.

Before You Begin Configuring the Client Manager
To enable the ProxyClient to perform acceleration, you must configure an ADN
manager and optionally a backup ADN manager as discussed in "Configuring the
ADN Managers" in Chapter 2: "Configuring an Application Delivery Network".
Make sure you review the concepts discussed in Section A: "ADN Overview" and
Section B: "About ADN Deployment, Compression, and Security Behavior" in
Chapter 2: "Configuring an Application Delivery Network".
You can also configure internet gateway settings (Configuration > ADN > Routing >
Internet Gateway) because the ProxyClient honors internet gateway settings. For
more information, see "Managing Server Subnets and Enabling an Internet
Gateway" on page 38.

205

Volume 5: Advanced Networking
Section B: Configuring a ProxySG as the Client Manager

ProxySG Administrator Configuration Tasks
The ProxySG administrator performs all of the following tasks in the order
shown:
1. Set up an ADN manager and optionally a backup ADN manager as discussed
in "Before You Begin Configuring the Client Manager" on page 205.
This enables the ProxyClient to perform acceleration.
2. Confirm the ProxySG ADN configuration settings are compatible for
ProxyClient deployment.
For more information, see "Preparing the ProxySG ADN Configuration for
ProxyClient Deployment" on page 207.
3. Configure a ProxySG as the Client Manager,
For more information, see "Designating a ProxySG as the Client Manager" on
page 210.
4. Verify the Client Manager has a valid SGOS base license.
For more information, see "About ProxyClient Licensing" on page 181.
5. Upload the latest Blue Coat ProxyClient software to the Client Manager.
For more information, see "Uploading the ProxyClient Software to the Client
Manager" on page 214.
6. Configure the following ProxyClient options:
• "Accelerating Network Traffic" on page 216
• "Configuring ProxyClient Locations" on page 225
• "Configuring ProxyClient Web Filtering" on page 231
7. Provide the ProxyClient software to users in one of the ways discussed in this
chapter.
For more information, see "Distributing the ProxyClient Software" on page
266.

206

Chapter 12: Accelerating and Controlling Micro-Branch and Mobile User Connections (ProxyClient)
Section B: Configuring a ProxySG as the Client Manager

Client Installation Tasks
The ProxyClient deployment process involves the following:
1. An administrator provides the ProxyClient software URL displayed on the
Client Manager to users or pre-installs the application using SMS or another
software distribution system before issuing the system to a user.
Note: To run ProxyClientSetup.exe and ProxyClientSetup.msi, the user

must be in the Administrators group on the computer.
When the person performing the installation enters the URL, a setup
application (ProxyClientSetup.exe) runs that in turn downloads and starts a
Microsoft Installer (ProxyClientSetup.msi).
Note: Installation methods are discussed in Section D: "Distributing the
ProxyClient Software" on page 266.

2. After installing the ProxyClient software, the user must reboot the machine.
3. Periodically, the ProxyClient polls the Client Manager for changes to the
ProxyClient software and configuration.

Preparing the ProxySG ADN Configuration for ProxyClient Deployment
To use the ProxyClient in your ADN network, you must configure options for
Manager Listening Mode and Tunnel Listening Mode on the ADN manager and
backup manager (if any) as discussed in this section.
The ProxyClient does not publish routes; it obtains routes from the ADN
manager. Also, the ProxyClient uses plain communications only. The options you
select for manager listening mode and tunnel listening mode must be compatible
with the ProxyClient.
This section discusses the following topics:




"About Manager Listening Mode" on page 208
"About Tunnel Listening Mode" on page 209
"About Secure Outbound Mode" on page 209

Note: To select options for either manager listening mode or tunnel listening

mode, you must have previously set up an SSL device profile on the ProxySG.
For more information about SSL device profiles, see "About SSL Device
Profiles" on page 116.

207

Volume 5: Advanced Networking
Section B: Configuring a ProxySG as the Client Manager

About Manager Listening Mode
Manager listening mode determines the way routes are published in the ADN
network: using the plain manager port (non-secure communication) or the secure
manager port (secure communication), or both.
Select manager listening mode options on the ADN manager and backup
manager only. Manager listening mode options are not available on other
ProxySG appliances.
For more information about setting the plain manager port and the secure
manager port, see "About the ADN Manager" on page 30.
As discussed in "Securing Connections" on page 49, the following options are
available:


Secure Only

Only ProxySG appliances using secure connections can publish routes.
However, because selecting this option means that only the secure listener is
active, you cannot select this option if you have ProxyClients in your ADN
network because ProxyClients use only plain connections.


Plain Read-Only

Select this option if all ProxySG appliances in the ADN network use SGOS
version 5.1.4 or later—where all appliances support secure routing, and you
have enabled secure routing on those ProxySG appliances.
This option means that ProxySG appliances that use secure connections can
publish routes. Devices that use plain communications can obtain routes but
cannot publish routes.
Note: Select this option only if all appliances in the ADN network run SGOS
version 5.1.4 or later.


Plain Only

Select this option in cases where you do not secure any ADN connections
between ProxySG appliances.
This option means that only ProxySG appliances that use plain connections
can publish routes.


Both

Select this option if you use the ProxyClient in your ADN network and some
appliances in the network are not capable of using secure connections (for
example, some appliances run SGOS version 5.1.3 or earlier).
This option means that ProxySG appliances that use either secure or plain
connections can publish routes. If secure is enabled and available, it is used by
default.

208

Chapter 12: Accelerating and Controlling Micro-Branch and Mobile User Connections (ProxyClient)
Section B: Configuring a ProxySG as the Client Manager

About Tunnel Listening Mode
Tunnel listening mode determines the type of incoming tunnel communications
this ProxySG appliance accepts: using the plain tunnel port (non-secure
communications) or the secure tunnel port (secure communications).
Select options for tunnel listening mode on every concentrator to which you
expect ProxyClients to connect. For example, select a tunnel listening mode
option for the concentrator discussed in "About Tunnel Listening Mode" on page
209.
For more information about the plain tunnel port and the secure tunnel port, see
"Securing Connections" on page 49.
The following options are available:


Secure Only

This option means the ProxySG appliance accepts only secure tunneling
connections. Because the ProxyClient uses only plain connections, you cannot
select this option if you have ProxyClients in your ADN network.


Plain

Select this option to enable the ProxyClient to connect to the appliance in cases
where you do not secure any ADN connections between ProxySG appliances.
This option means this appliance accepts only plain tunneling connections.


Both

Recommended for ProxyClient deployments in ADN networks in which secure ADN
is used. Select this option if you use the ProxyClient in your ADN network and
some appliances in the network use secure ADN. This option also enables you
to support appliances that are not capable of accepting incoming secure
tunneling connections (for example, some appliances run SGOS version 5.1.3
or earlier).
This option means this appliance accepts both plain and secure tunneling
connections.

About Secure Outbound Mode
The Secure Outbound Mode options have no impact on the ProxyClient because
these options determine how ProxySG appliances communicate with each other.
For a tunneling connection to be established between two ProxySG appliances,
the initiating appliance’s secure outbound mode must be compatible with the
tunnel listening mode of the receiving appliance.

209

Volume 5: Advanced Networking
Section B: Configuring a ProxySG as the Client Manager

Designating a ProxySG as the Client Manager
This section discusses how to configure an appliance in the ADN network as the
Client Manager.
You must configure one ProxySG in your ADN network as the Client Manager.
The Client Manager is responsible for providing the ProxyClient software,
software updates, and client configuration to ProxyClient applications installed
on user computers.
Note: The Client Manager can be a different appliance than the ADN manager
or the backup ADN manager. That is, you can configure the ADN manager or
the backup ADN manager as the Client Manager, but it is not required.

Before You Configure the Client Manager
Before you configure the Client Manager, make sure you performed all of the
following tasks:




"Before You Begin Configuring the Client Manager" on page 205
"Preparing the ProxySG ADN Configuration for ProxyClient Deployment" on
page 207
"About ProxyClient Licensing" on page 181.

Designating the Client Manager
This section discusses how to designate a ProxySG concentrator as the Client
Manager.
To designate a ProxySG as the Client Manager:

1. Log in to the Client Manager’s Management Console as an administrator.
2. Click ProxyClient > General > Client Manager.

3. On the Client Manager tab page, select the Enable Client Manager check box.
This designates this ProxySG as a Client Manager.

210

Chapter 12: Accelerating and Controlling Micro-Branch and Mobile User Connections (ProxyClient)
Section B: Configuring a ProxySG as the Client Manager

4. In the Client Manager section, enter or edit the following information:
Table 12–1 Client Manager options

Option

Description

Host section

Specify the host from which users get the ProxyClient software,
configuration, and updates. Blue Coat recommends you specify a fully
qualified host name, and not an unqualified (short) host name or IP
address. If you use a fully qualified host name and the Client Manager’s IP
address changes later, you need only to update DNS for the Client
Manager’s new address and clients can continue to download the software
and updates from the Client Manager.
You have the following options:
• Use host from initial client request: (Recommended.) Select this option to
enable clients to download the ProxyClient software, configuration, and
updates from the host from which the clients originally obtained the
software and configuration. In other words, in a typical ProxyClient
deployment, the administrator e-mails users a URL from which they
obtain the ProxyClient software and configuration initially. The host
name or IP address in this URL is used to download the software to the
client and is written to the client’s configuration file for use in future
software and configuration updates.
This option is compatible with all methods of deploying the ProxyClient,
including Windows Group Policy Object (GPO) and Microsoft Systems
Management Server (SMS). For more information about these
deployment options, see Section D: "Distributing the ProxyClient
Software" on page 266.
• Use host: Select this option to download the ProxyClient software and
configuration from the host name you specify. Enter a fully qualified
host name or IP address only; do not preface it with http:// or
https:// because downloads will fail.
Use this option to migrate users from one Client Manager to another
Client Manager. (Also see "Changing the Client Manager" on page 313.)

Port field

Enter the port on which the Client Manager listens for requests from
clients. The default is 8084.

Keyring list

Click the name of the keyring to use when clients connect to the Client
Manager.

Update Interval field

Specify the length of time (in minutes) between update checks. For
example, if the value is 120, each ProxyClient application connects to the
Client Manager every 120 minutes for configuration and software updates
(beginning at startup).
Valid values are 10-432000 (that is, 300 days). The default is 120 minutes.

After you apply the changes, the Client Components section displays a summary
of the information you selected.

211

Volume 5: Advanced Networking
Section B: Configuring a ProxySG as the Client Manager

Table 12–2 discusses the meaning of this information.
Table 12–2 Client Components section

Item

Description

Client setup

Displays the URL from which users download the
ProxyClient setup application. The setup application
(ProxyClientSetup.exe) downloads the Microsoft installer
(ProxyClientSetup.msi) to the client.
This information is intended for interactive client
installations from the Client Manager; for more information,
see "Preparing Interactive Installations" on page 268.
Provide this URL to users so they can install the ProxyClient
software on their computers. To install the software this way,
the user must have administrator privileges on the client
machine.
Note: If you selected Use host from client request for Host,
the URL displays as follows:
https://host-from-client-request:8084/
proxyclient/ProxyClientSetup.exe

To download the ProxyClient using this URL, substitute the
Client Manager’s host name or IP address for host-fromclient-request.
Client install MSI

Displays the URL from which ProxyClientSetup.exe
downloads ProxyClientSetup.msi.
This information is intended for non-interactive installations
using Group Policy Objects (GPO) or the Microsoft Systems
Management Server (SMS), as discussed in "Using Group
Policy Object Distribution" on page 285.
Note: Blue Coat recommends users not run the .msi on their
computers because the installation fails unless the user
enters parameters on the command line (for example,
BCSI_UPDATEURL).

212

Chapter 12: Accelerating and Controlling Micro-Branch and Mobile User Connections (ProxyClient)
Section B: Configuring a ProxySG as the Client Manager
Table 12–2 Client Components section

Item

Description

Client configuration

Displays the URL from which the ProxyClient installer
downloads the client configuration file
(ProxyClientConfig.xml).
This information is provided for your reference only. This
URL must be used as the value of the BCSI_UPDATEURL
parameter for silent, GPO, or SMS installations. For more
information, see one of the following sections:
• "Preparing Silent Installations and Uninstallations" on
page 273
• "Using Group Policy Object Distribution" on page 285

Client configuration
last modified

Displays the most recent date and time
ProxyClientConfig.xml was updated on the Client
Manager.

See Also
Section D: "Distributing the ProxyClient Software" on page 266
"About the Roles of ProxySG Appliances With the ProxyClient" on page 178
"Setting the Client Manager (CLI)" on page 261
"Configuring General ProxyClient Settings (CLI)" on page 261

213

Volume 5: Advanced Networking
Section B: Configuring a ProxySG as the Client Manager

Uploading the ProxyClient Software to the Client Manager
This section describes how to upload the latest ProxyClient software to the Client
Manager to make it available to install or to update on client machines.
Important:

After you update the ProxyClient software on the Client Manager,
whenever users connect using the ProxyClient, they must update their
ProxyClient software unless software updates are disabled. You have the option
of disabling software updates from the Client Manager if you plan to distribute
updates some other way (for example, by GPO or SMS). For more information,
see "Parameters for Silent Installations" on page 274.

Before uploading the ProxyClient software, verify the Client Manager is running
compatible SGOS software. For example, ProxyClient 3.1.x requires SGOS 5.3.x.
To upload ProxyClient.car to the Client Manager:

1. Get ProxyClient.car as follows:
a. Log in to WebPower by entering your credentials at the following
URL:
http://webpower.bluecoat.com

If you do not have a WebPower login, register at http://
webpower.bluecoat.com/register.
b. Click Download Software.
c. On the Downloads page, click the Blue Coat ProxyClient link.
d. Click the link to request the ProxyClient software.
e. When prompted, enter your WebPower credentials.
f.

A link to the software will be e-mailed to the user who registered with
WebPower.

g. Follow the prompts in the e-mail to download ProxyClient.car.
2. Locate ProxyClient.car in any of the following:


On the local file system of the computer you run the Client Manager’s
Management Console.
That is, to upload the ProxyClient software from your local file system or
from a network share drive (as opposed to uploading it from a remote
URL), you must copy ProxyClient.car to an accessible location.



On a Web server the Client Manager can access.

3. Log in to the Client Manager’s Management Console as an administrator.
4. Click ProxyClient > Client Manager > Client Software.
The Current ProxyClient Software section displays information about the
ProxyClient software this Client Manager is currently using.
5. From the Install ProxyClient software from list, click one of the following:

214

Chapter 12: Accelerating and Controlling Micro-Branch and Mobile User Connections (ProxyClient)
Section B: Configuring a ProxySG as the Client Manager



Remote URL: Upload ProxyClient.car from a location specified by a URL in

the following format:
http://host:port/path/ProxyClient_version.car

For example,
http://myapache.example.com/software/ProxyClient_3.1.1.1.car



Local file: Upload the ProxyClient software from a location accessible by
the machine on which you are running the Management Console.

6. Click Install.
7. Follow the displayed prompts to complete the upload.
8. Clients get the updated software at the next update interval.

215

Volume 5: Advanced Networking
Section C: Configuring the ProxyClient

Section C: Configuring the ProxyClient
The Client Manager enables you to configure the following options for the
ProxyClient:




"Accelerating Network Traffic"
"Configuring ProxyClient Locations" on page 225
"Configuring ProxyClient Web Filtering" on page 231

For more information about these options, see Section A: "ProxyClient Concepts"
on page 174.

Accelerating Network Traffic
This following sections discuss how to configure the WAN acceleration options
on the Client Manager:






"Before You Begin Configuring ProxyClient Policy"
"Specifying the ProxyClient ADN Manager" on page 217
"Tuning the ADN Configuration" on page 218
"Enabling File Sharing Acceleration" on page 221
"Enabling ProxyClient Acceleration" on page 223

Before You Begin Configuring ProxyClient Policy
Before performing the tasks discussed in this section, you must configure your
ADN manager to route subnets; otherwise, no network traffic will be accelerated.
On all concentrators that front servers to which you want to accelerate
ProxyClient traffic, click Configuration > ADN > Routing > Server Subnets. For
additional assistance, click Help or see "Managing Server Subnets and Enabling an
Internet Gateway" on page 38.
Because the ProxyClient also accelerates Internet traffic, you can set Internet
gateway options: Configuration > ADN > Routing > Internet Gateway. For more
information, see "Managing Server Subnets and Enabling an Internet Gateway"
on page 38.

216

Chapter 12: Accelerating and Controlling Micro-Branch and Mobile User Connections (ProxyClient)
Section C: Configuring the ProxyClient

Specifying the ProxyClient ADN Manager
This section discusses how to specify the ADN manager that will publish routes
to the ProxyClient.
To specify the ADN manager for the ProxyClient:

1. Log in to the Client Manager’s Management Console as an administrator.
2. Click Configuration > ProxyClient > Acceleration > ADN Manager.

3. On the ADN Manager tab page, enter or edit the following information:
Field

Description

Primary manager IP address

Enter the IP address of the ADN manager for the
ADN network to which the ProxyClient connects.
For more information about the role of the ADN
manager, see "Terminology" on page 175 and "About
the Roles of ProxySG Appliances With the
ProxyClient" on page 178.

Backup manager IP address

Enter the IP address of the backup ADN manager, if
any.

ADN manager port

Enter the ADN manager’s plain listen port (by
default, 3034).

Important: Do not enter a secure port number, because the ProxyClient
version 3.1.x does not support secure tunnels.

4. Click Apply.

217

Volume 5: Advanced Networking
Section C: Configuring the ProxyClient

5. If you have not already done so, perform the following tasks to enable
ProxyClient acceleration:
a. Click Configuration > ProxyClient > Acceleration > General.
b. In the right pane, click the Enable Acceleration check box.
c. Click Apply.
You must also enable acceleration for locations as discussed in "Configuring
ProxyClient Locations" on page 225.

Tuning the ADN Configuration
The ProxySG enables you to customize include and exclude subnets and port lists,
which are advanced settings that limit the traffic that is accelerated by the ADN
network. Because the ADN manager sets options for both its peers in the ADN
network and for ProxyClients, you can use the include or exclude ports list to
fine-tune the way ProxySG appliances interact with the ProxyClient.
For example, if you know that ProxyClient traffic over particular ports is not
compressible, you can add those ports in the exclude ports list. Blue Coat strongly
recommends you test the include/exclude ports settings in a controlled
environment before using them in production because improper settings can have
an adverse impact on performance.
Specifically, you must understand the following:


Excluded subnets—You can exclude intranet connections from being
forwarded to a ProxySG configured as an Internet gateway. This is important
if your network is designed such that a connection to an intranet server fails if
it is sent through an Internet gateway.
Provided an Internet gateway is configured, forwarding occurs as follows:
a. If the destination IP address is a local address, do not attempt to use an
ADN tunnel; instead, connect directly. This is the end of the process.
b. If the destination IP address is in the ProxyClient’s excluded subnets
list, do not attempt to use an ADN tunnel; instead, connect directly.
This is the end of the process.
Otherwise, if the IP address is not in the ProxyClient’s exclude list,
continue with the next step.
c. If the destination IP address matches an entry in the ADN routing
table, forward the connection over an ADN tunnel; otherwise,
continue with the next step.
d. If a ProxySG is configured as an Internet gateway, look up the
destination IP address in the Internet gateway’s exception list.
If the address does not match, forward the connection over an ADN tunnel
to the Internet gateway; otherwise, connect directly to the destination IP
address.

218

Chapter 12: Accelerating and Controlling Micro-Branch and Mobile User Connections (ProxyClient)
Section C: Configuring the ProxyClient


Include and exclude ports—Includes or excludes TCP ports in ADN tunnels.
Assuming ProxyClients can connect to a ProxySG that can optimize traffic to
the destination address, this setting determines which ports are accelerated
(or are not accelerated) for clients. You can use either the excluded ports list or
included ports list, but not both.

See one of the following sections for more information:



"Excluding Subnets from Being Accelerated"
"Excluding and Including Ports" on page 220

Excluding Subnets from Being Accelerated
This section discusses how to prevent subnets from being accelerated when
clients connect using the ProxyClient.
To exclude subnets:

1. Log in to the Client Manager’s Management Console as an administrator.
2. Click Configuration > ProxyClient > Acceleration > ADN Rules.
3. On the ADN Rules tab page, in the Excluded Subnets section, click Add.
The Add IP/Subnet dialog displays.

219

Volume 5: Advanced Networking
Section C: Configuring the ProxyClient

4. Enter or edit the following information:
Option

Description

IP / Subnet Prefix field

Enter either an IP address or an IP
address and subnet in Classless InterDomain Routing (CIDR) notation (for
example, 192.168.0.0/16).

Subnet Mask field

Use this field if you entered only an IP
address in the preceding field (that is, if
you used CIDR notation in the
preceding field, you do not need to
enter a value in this field).

5. In the Add IP/ Subnet dialog, click OK.
6. Repeat these tasks to exclude more subnets, if required.

Excluding and Including Ports
This section discusses how to include and exclude from traffic on certain TCP
ports; in other words, traffic on these ports either will be accelerated (if included)
or will not be accelerated (if excluded). Note that if you include ports, all other
traffic is not accelerated.
To exclude or include ports:

1. Log in to the Client Manager’s Management Console as an administrator.
2. Click Configuration > ProxyClient > Acceleration > ADN Rules.
The ports section displays.

3. In the Ports section, click one of the following options:


Exclude:

Client traffic from specified ports is not routed through the ADN
tunnel. All other traffic is accelerated.
Valid values: Comma-separated list of ports and port ranges (no spaces,
separated by a dash character). For example:
22,88,443,993,995,1352,1494,1677,3389,5900-5902

220

Chapter 12: Accelerating and Controlling Micro-Branch and Mobile User Connections (ProxyClient)
Section C: Configuring the ProxyClient



Include: Client traffic from specified ports is routed through the ADN
tunnel and therefore is accelerated. All other traffic bypasses the tunnel
and is not accelerated.

Valid values: Comma-separated list of ports and port ranges (no spaces,
separated by a dash character). For example:
80,139,445,8080-8088

Include ports 139 and 445 for file sharing (CIFS services) acceleration.
Note: The include and exclude ports lists are advanced settings that limit the

traffic that is accelerated by the ADN network.
4. Click Apply.

Enabling File Sharing Acceleration
This section discusses how to enable the ProxyClient to enable Common Internet
File System (CIFS) protocol acceleration, which is the protocol used to send files
and directories across the WAN. Using CIFS acceleration improves performance
when users request the same files from a file server at headquarters, for example.
Note: The ProxyClient does not perform CIFS acceleration in the following

conditions:


to a server that has SMB message signing enabled. For more
information, see Microsoft KB article 887429.



to a server that uses SMB 2.0



other conditions discussed in the ProxyClient Release Notes

For file sharing conceptual information, see "ADN Features" on page 192.
For more detailed information about CIFS optimization on the ProxySG, see
the Acceleration File Sharing chapter in Volume 2: Proxies and Proxy Services of
the ProxySG Configuration and Management Documentation Suite
To enable file sharing acceleration using the ProxyClient:

1. Log in to the Client Manager’s Management Console as an administrator.
2. Verify the CIFS ports are listed in the Included Port list as discussed in
"Enabling File Sharing Acceleration" on page 221.
3. Click Configuration > ProxyClient > Acceleration > CIFS.

221

Volume 5: Advanced Networking
Section C: Configuring the ProxyClient

The CIFS tab page displays.

4. On the CIFS tab page, enter or edit the following information:
Option

Description

Enable CIFS
acceleration check box

You must select this check box to enable clients to accelerate
CIFS traffic.

Write Back options

Write back options determine whether or not user
connections continue sending data to the ProxySG
appliance while the appliance is writing data on the back
end. Select one of the following:
• Select Full to enable write-back, which causes the
ProxyClient to sending data to the appliance without
waiting for acknowledgement that the data was written
successfully.
This setting improves responsiveness but can lead to data
loss if the ProxyClient crashes or the link drops before
delivering all the data to the ProxySG appliance.
• Select None to disable write-back. Disabling write-back
can introduce substantial latency while clients send data
to the appliance and wait for acknowledgement before
sending more data.
One reason to set this option to None is the risk of data
loss if the link from the branch to the core server fails.
There is no way to recover queued data if such a link
failure occurs.

Directory cache time

field

5. Click Apply.

222

Enter the number of seconds for directory listings to remain
in the client’s cache.

Chapter 12: Accelerating and Controlling Micro-Branch and Mobile User Connections (ProxyClient)
Section C: Configuring the ProxyClient

See Also
Volume 2: Proxies and Proxy Services
"ADN Features" on page 192
"Clearing the Cache" on page 323
"Changing the Location of the Cache" on page 324

Enabling ProxyClient Acceleration
After you have configured your network parameters (ADN manager information,
excluded subnets, included or excluded ports, and CIFS protocol options), you are
ready to enable acceleration for the ProxyClient.
To enable ProxyClient acceleration:

1. Log in to the Client Manager’s Management Console as an administrator.
2. If you have not already done so, perform the following prerequisite tasks:
a. Enable the Client Manager as discussed in "Designating a ProxySG as
the Client Manager" on page 210.
b. Specify the ADN manager as discussed in "Specifying the ProxyClient
ADN Manager" on page 217.
3. Click Configuration > ProxyClient > Acceleration > General.

4. On the General tab, enter or edit the following information:
Option

Description

Enable Acceleration

You must select this check box to enable ProxyClient
to accelerate network traffic using all of the following
methods:
• gzip
• CIFS protocol acceleration
• byte caching
If you clear the check box, the ProxyClient performs
no acceleration.

223

Volume 5: Advanced Networking
Section C: Configuring the ProxyClient
Option

Description

Acceleration License

Displays the status of your acceleration license as
either Valid or Invalid.
The ProxyClient—Acceleration license component is
part of the base SGOS license. If the status is Invalid,
there is a problem with your Blue Coat license.
Verify a valid base SGOS license is installed
(Maintenance > Licensing > View). Contact Blue Coat
Support for license troubleshooting issues.

Maximum percentage of disk
space to use for caching field

Enter the maximum percentage of total client disk
space (as opposed to available disk space) to use for
caching objects, such as CIFS objects. Valid values are
1–90; the default is 10.
The higher you set the value, the more information is
cached on user systems, but at the expense of disk
space that might be required to run other applications.
See also:
• "Clearing the Cache" on page 323
• "Changing the Location of the Cache" on page 324

5. Click Apply.

More About ProxyClient Caching
The following is a summary of how CIFS protocol acceleration and byte caching
work on the client computer:
1. The ProxyClient starts.
2. The user requests a cacheable object, such as a file.
3. The ProxyClient allocates sufficient disk space on the client computer to cache
the object—up to the limit set by the administrator. That is, if the client
computer’s system has 100GB of total space and the administrator configures
the cache to use a maximum of 10%, the ProxyClient allocates up to 10GB for
the cache.
Cache space is divided equally between the CIFS cache and the byte cache.
However, if the maximum cache size leaves less than 1GB of available disk
space, the cache size is further limited. Continuing this example, if the client
has only 9GB of available space, the maximum cache size is 8GB instead of
10GB.
4. If any single object (such as a file) exceeds the maximum CIFS cache size, that
object is not cached in the CIFS cache; however, tokens associated with the
object are cached in the byte cache.

224

Chapter 12: Accelerating and Controlling Micro-Branch and Mobile User Connections (ProxyClient)
Section C: Configuring the ProxyClient

For example, if the maximum size of the CIFS cache is 5GB, and the client
requests a file that is 6GB in size, that file is not cached in the CIFS cache.
5. If the cache is full, objects are expired from the cache based on a number of
criteria, such as unopened files and oldest objects first.
Note: For details about where the cache files are stored by default and for
information about how to change the location of cache files, see "Changing the
Location of the Cache" on page 324.

Configuring ProxyClient Locations
The ProxyClient application automatically detects its location by matching a
combination of IP address, virtual NIC IP address, and DNS server address as
specified by the ProxySG administrator.
The purpose of configuring locations is to enable ProxyClient features based on
where the user connects. For example, a user who works from home on a laptop
needs the ProxyClient to perform both acceleration and Web filtering because the
user does not connect to a network with a local ProxySG that performs those
functions. However, if the user brings the same laptop to work, both ProxyClient
acceleration and Web filtering should be disabled because a local ProxySG
concentrator or branch appliance performs those functions.
This section discusses the following topics:



"Configuring Specific Locations"
"Configuring Default Actions" on page 230

For an overview and examples, see "About Location Awareness" on page 182.

Location Awareness Task Summary
The following table summarizes the tasks required to set up location awareness:
Task

Description

1. "About Location Conditions" on
page 183

Understand your network; specifically, how
clients use VPN to access your network, IP
source address ranges, and DNS server IP
addresses.

2. "Location Example" on page 184

Plan your locations.

3. "Configuring Specific Locations"
on page 226

Configure locations for office, branch office,
home office, and mobile users.

4. "Configuring Default Actions" on
page 230

Default actions are used for users that do not
match any configured locations.

5. "Ordering Locations in the
Rulebase" on page 229

To make sure users match the correct location,
put the most restrictive (that is, more specific)
locations in the rulebase before less restrictive
locations.

225

Volume 5: Advanced Networking
Section C: Configuring the ProxyClient

Configuring Specific Locations
This section discusses how to use location conditions to define specific locations,
such as office headquarters, branch offices with ProxySG concentrators, and
mobile users.
For more information and examples, see the following sections:



"About Location Conditions" on page 183
"About Condition Rulebase Ordering" on page 191

To specify locations:

1. Log in to the Client Manager’s Management Console as an administrator.
2. Select Configuration > ProxyClient > General > Locations.
3. On the Locations tab page, click New.
The New Locations dialog displays.
4. In the Name field, enter a name that identifies this location. For example,
Headquarters.
Note: The location name cannot be changed later.

5. In the Conditions section, select one or more conditions that define this
location.
The Conditions section enables you to specify one or more conditions that
define the location, and therefore the ProxyClient features to apply to users in
the location. For more information and examples of setting up locations, see
the following sections:



226

"About Location Conditions" on page 183
"About Condition Rulebase Ordering" on page 191

Chapter 12: Accelerating and Controlling Micro-Branch and Mobile User Connections (ProxyClient)
Section C: Configuring the ProxyClient

To add a location condition, perform the following tasks:
Condition

Tasks

Source IP ranges

1. Select the Match source IP ranges check box.
2. Click New.
Note: You cannot directly edit an existing condition. First delete
the existing condition and then add a new one.
3. In the Add IP Source Range dialog, enter a starting and ending
IP address in the provided fields.
You must enter a pair of IP addresses; you cannot enter CIDR
notation.
4. Click OK.
5. Repeat these tasks to enter other source IP address ranges if
required.
Note: This condition is matched if the user has an IP address in
any of the ranges you define.

DNS servers

1. Select the Match DNS servers check box.
2. Click New.
Note: You cannot directly edit an existing condition. First delete
the existing condition and then add a new one.
3. In the Add DNS Servers IPs dialog, enter the server’s IP
address.
4. Click OK.
5. Repeat these tasks to enter other DNS server IP addresses if
required.
Note: This condition is matched only if all DNS servers are
matched. For example, if the location defines DNS IP addresses
10.1.1.1 and 10.1.1.2, and the user’s computer has only
10.1.1.2 defined, there is no match. However, if the location
condition defines DNS IP addresses 10.1.1.1 and 10.1.1.2,
and the user’s computer has 10.1.1.1, 10.1.1.2, and
10.1.1.3 defined, there is a match.

227

Volume 5: Advanced Networking
Section C: Configuring the ProxyClient
Condition

Tasks

Virtual NIC IP
ranges

1. Select the Match Virtual NICs IP check box.
2. Click New.
Note: You cannot directly edit an existing condition. First delete
the existing condition and then add a new one.
3. In the Add Virtual NIC IP Range dialog, enter a starting and
ending IP address in the provided fields. The range you enter
should correspond to a range of IP addresses provisioned by
your VPN gateway.
You must enter a pair of IP addresses; you cannot enter CIDR
notation.
4. Click OK.
5. Repeat these tasks to enter other Virtual NIC IP address ranges
if required.
Note: This condition is matched if the user has an VNIC IP
address in any of the ranges you define.

6. Select the check box corresponding to which features are enabled for this
location:


Enable Acceleration: Select

this option to accelerate network traffic using all

of the following:





gzip



CIFS protocol acceleration



byte caching

Enable Web Filter: Select this option to perform Web filtering in this location.

Important:

All selected conditions must match to enable the selected
location features. For example, if Source IP Address and DNS Servers
conditions are selected, and if the user matches the source IP address but not
the DNS server IP address, the user does not match this location and the
features enabled by the location will not be applied to the user.
Users who do not match any location conditions have default actions
applied to them as discussed in "Configuring Default Actions" on page 230.

7. Click OK.
The location name and
associated policy actions
display on the Locations tab
page.

228

Chapter 12: Accelerating and Controlling Micro-Branch and Mobile User Connections (ProxyClient)
Section C: Configuring the ProxyClient

See Also
"Overview of Location Awareness" on page 182
"About Location Conditions" on page 183
"About Condition Rulebase Ordering" on page 191

Ordering Locations in the Rulebase
The order in which locations display on the Configuration > ProxyClient > General >
tab page determine the order in which the rules are evaluated when
users connect to the Client Manager. To avoid mismatches, order the rules from
most to least restrictive.

Locations

For example, suppose headquarters uses IP addresses in the range from 10.0.0.0 to
10.255.255.255 but the VPN gateway located at headquarters has a pool of IP
addresses in a subset of that range; for example, 10.3.1.1 to 10.3.1.255. Because the
VPN gateway is used by home office or mobile users, the administrator wants to
use different policy actions for headquarters and home office users.
Users at the headquarters location should have ProxyClient acceleration and Web
filtering disabled but users in a home office or mobile location should have both
ProxyClient features enabled.
To accomplish that, the administrator creates the two locations as follows.
Location

Conditions

Headquarters

• Source IP address range: 10.0.0.0 to 10.255.255.255
• DNS server IP address: For example, 10.0.0.11 and
10.0.0.12

Home office or mobile

• DNS server IP address: Same as headquarters
• VNIC IP address range: 10.3.1.1 to 10.3.1.255

To make sure the home office or mobile location is detected first, the administrator
must order it in the rulebase before the headquarters location. An example
follows.

229

Volume 5: Advanced Networking
Section C: Configuring the ProxyClient

Configuring Default Actions
The purpose of default actions is to enable ProxyClient features for users that do
not match any location conditions you defined earlier.
For example, mobile users that do not connect to the network using VPN have
unknown source IP ranges and DNS servers. If a mobile user connects to the
network using VPN, the user has a VNIC IP address you can use to establish the
user’s location.
To configure default actions:

1. Log in to the Management Console as an administrator.
2. Click Configuration > ProxyClient > General > Locations.
3. At the bottom of the Locations tab page, in the Default Actions section, select
the check box corresponding to features to enable for clients who do not
match any defined location conditions.
The following figure shows an example of enabling both acceleration and Web
filtering by default:

See Also
"Overview of Location Awareness" on page 182
"About Location Conditions" on page 183

230

Chapter 12: Accelerating and Controlling Micro-Branch and Mobile User Connections (ProxyClient)
Section C: Configuring the ProxyClient

Configuring ProxyClient Web Filtering
This section discusses how to configure the Client Manager to provide the Blue
Coat Web Filtering service for ProxyClient users. Web filtering enables you to
allow, block, or warn users about accessing content in categories you specify
using any of the following:


The Blue Coat Web Filtering database categories



Local database categories



Policy categories (also referred to as custom categories)



System and Default categories, which are discussed in more detail later in this
section

For conceptual information about Web filtering, see "About ProxyClient Web
Filtering" on page 196.

Web Filtering Task Summary
To use ProxyClient Web filtering, you must perform the following tasks in the
order shown:
Task

Description

1. Prerequisites

• "About ProxyClient Licensing" on page 181
The use of BCWF depends on proper licensing on
the Client Manager.
• "Designating a ProxySG as the Client Manager"
on page 210
You must designate a Client Manager before you
can enable Web filtering for the ProxyClient.

2. "Enabling the Blue Coat Web Filter
Database" on page 233

The BCWF database must be enabled on the Client
Manager before ProxyClient Web filtering can be
enabled.
Note: Although it is possible to enable other
databases (for example, Internet Watch Foundation),
only the following categories can be used by the
ProxyClient:
• Blue Coat Web Filter
• Policy, such as VPM policy
• The local database
• System and Default categories
Categories from other databases are not used by
ProxyClient Web filtering.

3. "Setting up the BCWF Database
Download" on page 234

Set up updates for the BCWF database; the database
must be updated on the Client Manager at least
once every 30 days.

231

Volume 5: Advanced Networking
Section C: Configuring the ProxyClient
Task

Description

4. Optional. "Enabling the Use of the Local
Database (Optional)" on page 236

The local database is one way you can optionally
create categories to whitelist or blacklist specific lists
of URLs for your employees.
You can also add policy categories (also referred to
as custom categories) to set up whitelists and
blacklists. For more information, see "Managing
Policy Categories" on page 242.

232

5. "Enabling ProxyClient Web Filtering" on
page 238

After you have the current BCWF database, you can
enable the ProxyClient to perform Web filtering.

6. "Assigning Policy Actions to Content
Categories" on page 240

Define categories of content you will allow users to
access, block users from accessing, or warn users
about accessing.

7. "Web Filtering Best Practices" on page 251

Information about how to best use Web filtering in
your corporation.

8. "Displaying and Customizing Web
Filtering Exception Pages" on page 253

Exception pages are displayed to users when they
attempt to access content that the administrator
chose to either block or to warn about. Blue Coat
recommends you customize the default exception
pages to provide users with more specific
information.

9. "Enabling Web Filtering Logging" on
page 256

How to upload user Web filtering logs to an
anonymous FTP server.

Chapter 12: Accelerating and Controlling Micro-Branch and Mobile User Connections (ProxyClient)
Section C: Configuring the ProxyClient

Enabling Blue Coat Web Filtering
Before Web filtering can be enabled for the ProxyClient, Blue Coat Web Filtering
must be enabled on the Client Manager.
You must obtain a BCWF license, which entitles you to a BCWF user name and
password. For more information, contact your Blue Coat representative. Because
the BCWF database must be updated at least once every 30 days, make sure the
Client Manager is capable of accessing the Internet.
Note: The Client Manager must keep the BCWF database current for licensing

purposes only. The ProxyClient does not use the BCWF database on the Client
Manager; instead, it gets URL categories from a service point.

Enabling the Blue Coat Web Filter Database
This section discusses how to enable the use of the Blue Coat Web Filter database,
which is required for ProxyClient Web filtering.
Note: Blue Coat Web Filtering must be enabled on the Client Manager; however,
DRTR does not need to be enabled. ProxyClient categorization does not occur on
the Client Manager; instead, the ProxyClient gets categories from a service point.
The service point gets a category from DRTR if the URL is not already categorized
in the BCWF database.
To enable the Blue Coat Web Filter database:

1. Log in to the Client Manager’s Management Console as an administrator.
2. Click Configuration > Content Filtering > General.

3. In the right pane, select the Enable check box for Blue Web Filter.
4. Click Apply.
5. Continue with the next section.
For more information about other options, including lookup mode and
memory allocation, click Help or see the section on setting the memory
allocation in Chapter 2, Filtering Web Content, in Volume 7: Managing Content.

233

Volume 5: Advanced Networking
Section C: Configuring the ProxyClient

Setting up the BCWF Database Download
The Blue Coat Web Filter database must be updated at least once every 30 days.
You have the option of updating the database automatically or at a time range you
select. This section discusses how to update the database automatically.
To set up the BCWF database download:

1. Log in to the Client Manager’s Management Console as an administrator.
2. Click Configuration > Content Filtering > Blue Coat > Blue Coat Web Filter.
3. On the Blue Coat Web Filter tab page, enter the following information:
Option

Description

Username field

Enter the user name provided with your BCWF
subscription.

Change Password button

Click the button and follow the prompts on
your screen to set or change your BCWF
password.

URL field

Enter the URL provided with your BCWF
subscription. Typically, the URL is:
https://list.bluecoat.com/bcwf/activity/
download/bcwf.db

Set to default button

Click to reset the URL field to its default value
of https://list.bluecoat.com/bcwf/
activity/download/bcwf.db

4. Click Download Now.
This starts the download process. Make sure you verify the download was
successful as discussed in the next step.
5. Allow a few minutes for the download to complete and click Verify Download.
The following table shows sample success messages.
Type of download

Success message

Full database

Blue Coat download at: 2008/07/16 19:25:29 0500
Downloading from https://list.bluecoat.com/
bcwf/activity/download/bcwf.db
Requesting initial database
Download size:
170228642
Database date:
Wed, 16 Jul 2008 04:06:30
UTC
Database expires:
Fri, 15 Aug 2008 04:06:30
UTC
Database version:
200819804
Database format:
1.1

234

Chapter 12: Accelerating and Controlling Micro-Branch and Mobile User Connections (ProxyClient)
Section C: Configuring the ProxyClient
Type of download

Success message

Differential update

Blue Coat download at: 2008/07/16 14:16:19 0500
Downloading from https://list.bluecoat.com/
bcwf/activity/download/bcwf.db
Requesting differential update
Differential update applied successfully
Download size:
170228642
Database date:
Wed, 16 Jul 2008 04:06:30
UTC
Database expires:
Fri, 15 Aug 2008 04:06:30
UTC
Database version:
200819804
Database format:
1.1

The following table shows sample error messages with suggestions about how to
correct the error.
Failure message

Suggested workaround

ERROR: Socket connect
error

The Client Manager cannot contact the BCWF URL,
most likely for any of the following reasons:
• The URL is incorrect
Click Configuration > Content Filtering > Blue Coat
and verify the value of the URL field with the
information provided with your Web filtering license.
Try clicking Set to default and trying the download
again.
• Network issues prevent the Client Manager from
reaching the site.
Log in to the Client Manager’s CLI and enter the
following command:
> ping list.bluecoat.com

If you cannot ping the list.bluecoat.com Web site,
check the configuration of routers and firewalls to
make sure the Client Manager can reach the site.
ERROR: HTTP 401 Unauthorized

Either the user name or password you specified is
incorrect.
Click Configuration > Content Filtering > Blue Coat and
verify the value of the Username field. Click Change
Password and enter your password again in the
provided fields.

235

Volume 5: Advanced Networking
Section C: Configuring the ProxyClient

For more information about other options, click Help or see the section on
configuring Blue Coat Web filter in Chapter 2, Filtering Web Content, in
Volume 7: Managing Content.
1. Select the Automatically check for updates check box.
2. Click Apply.
3. Continue with the next section.

Enabling Other Databases
Although it is possible to enable other databases (for example, Internet Watch
Foundation), categories in these databases are not used by ProxyClient Web
filtering. Categories from only the following sources are used by the ProxyClient:


The BCWF database



The local database



Policy, such as VPM policy



System categories (none and unavailable), which cannot be edited or deleted



The Default category, which enables you to allow or block any content request
that is not classified into any of the preceding categories

The tasks required to use categories from these sources are discussed in the
following sections.

Enabling the Use of the Local Database (Optional)
The local database can be used by administrators to set up whitelists or blacklists;
in other words, it enables you to add categories with particular URLs that you can
allow, block, or warn.
If you do not wish to enable the local database, skip this section and continue with
"Enabling ProxyClient Web Filtering" on page 238.
This section discuses the following topics:



"Creating the Local Database"
"Enabling the Local Database" on page 237

Creating the Local Database
To create the local database:

1. Create a text file in the following format:
define category-name
url1
url2
urln
end

236

Chapter 12: Accelerating and Controlling Micro-Branch and Mobile User Connections (ProxyClient)
Section C: Configuring the ProxyClient
define category-name
url1
url2
urln
end

For example,
define category whitelist
www.cnn.com
www.webmd.com
end
define category blacklist
www.gambling.com
end

Each category can have an unlimited number of URLs.
2. Upload the text file to a Web server that the Client Manager can access.
3. Continue with the next section.

Enabling the Local Database
To enable the local database:

1. Log in to the Client Manager’s Management Console as an administrator.
2. Click Configuration > Content Filtering > General.
3. In the right pane, select the Enable check box next to Local Database.
4. Click Apply.
5. Continue with the next section.

Uploading the Local Database to the Client Manager
To upload the local database to the Client Manager:

1. Log in to the Client Manager’s Management Console as an administrator.
2. Click Configuration > Content Filtering > Local Database.

237

Volume 5: Advanced Networking
Section C: Configuring the ProxyClient

3. In the right pane, enter or edit the following information:
Option

Description

Username field

Enter the user name required to access the local
database, if any.

Change Password button

Click the button and follow the prompts on
your screen to set or change your local database
password.

URL field

Enter the URL to the local database.

4. Click Download Now.
5. To verify the download, click Verify Download.
6. Select the Automatically check for updates check box.
7. Click Apply.
8. Continue with the next section.

See Also
Section on configuring the local database in Chapter 2, Filtering Web Content, in
Volume 7: Managing Content

Enabling ProxyClient Web Filtering
This section discusses how to enable ProxyClient Web filtering on the Client
Manager.
To enable ProxyClient Web filtering:

1. Complete the following prerequisite tasks:
a. "Designating a ProxySG as the Client Manager" on page 210
b. "Enabling Blue Coat Web Filtering" on page 233
2. Log in to the Client Manager’s Management Console as an administrator.
3. Click Configuration > ProxyClient > Web Filtering > Policy.

238

Chapter 12: Accelerating and Controlling Micro-Branch and Mobile User Connections (ProxyClient)
Section C: Configuring the ProxyClient

4. Verify the status of Web Filtering License is Valid.
If another status displays (such as Invalid), perform the following tasks on
Configuration > Content Filtering > Blue Coat > Blue Coat Web Filter:


Verify that the value for Username is correct.



Click Change Password and enter the password provided with your BCWF
license in the provided fields.



Optional. Click Set to default to set the value of the download URL to its
default value.

5. If you have a valid Web filtering license, select the Enable Web Filtering check
box.
6. Click Apply.
If that does not resolve the problem, download the database manually as
discussed in steps 4 and 5 in "Setting up the BCWF Database Download" on
page 234.
7. After you have successfully enabled the BCWF database with a valid license,
continue with the next section.

See Also
Chapter 2, Filtering Web Content, in Volume 7: Managing Content

239

Volume 5: Advanced Networking
Section C: Configuring the ProxyClient

Assigning Policy Actions to Content Categories
You define content policy by selecting categories and corresponding policy
actions that either allows the content, blocks the content, or warns users that
accessing content might violate company Web use policies.
This section discusses the following topics:








"Getting Started With Categories"
"Selecting Categories" on page 241
"Managing Policy Categories" on page 242
"Selecting Policy Actions for Categories" on page 244
"Configuring System and Default Policy Actions" on page 246
"Ordering Categories in the Rulebase" on page 247
"Configuring Other Web Filtering Options" on page 250

If you are configuring ProxyClient Web filtering for the first time, you should
complete the tasks discussed in the preceding sections in the order in which they
are shown. If you are modifying an existing configuration, choose any task.

Getting Started With Categories
This section discusses how to locate the available categories so you can get started
defining categories and their associated policy actions.
To implement Web filtering policy for ProxyClient users:

1. Log in to the Client Manager’s Management Console as an administrator.
2. Click Configuration > ProxyClient > Web Filtering > Policy.
On the Policy tab, the All Categories section displays
the available category nodes:

240



Blue Coat:



Local: The local database, which is discussed in
"Enabling the Use of the Local Database
(Optional)" on page 236.



System:



Policy: Categories defined using policy (usually the Visual Policy Manager
(VPM)).

The BCWF database.

Special categories (none and unavailable) that are discussed in
more detail in Step 4 on page 246.

Chapter 12: Accelerating and Controlling Micro-Branch and Mobile User Connections (ProxyClient)
Section C: Configuring the ProxyClient

Note:



If you are not familiar with ProxySG content filtering, refer to
Chapter 2, Content Filtering, in Volume 7: Managing Content of the
Blue Coat ProxySG Configuration and Management Suite.



Many Web sites generate more than one URL request so it is
possible that an allowed Web site might create other URL
requests that are categorized differently, or are categorized as the
System category none.
For example, images and advertisements displayed on an
allowed Web site are individually classified based on their URLs.
Even if you allow users to access that Web site, each of the ads
and images on the site can be blocked based on each URL’s
categorization.

3. Continue configuring Web filtering.
If you are configuring ProxyClient Web filtering for the first time, complete
following tasks in the order in which they are presented. If you have already
configured Web filtering and need to modify your previous choices, choose a
task from the following list.






"Selecting Categories"
"Configuring System and Default Policy Actions" on page 246
"Selecting Policy Actions for Categories" on page 244
"Ordering Categories in the Rulebase" on page 247
"Configuring Other Web Filtering Options" on page 250

Selecting Categories
This section discusses how to select categories to use when filtering Web content
for ProxyClient users. Select only the categories you wish to explicitly allow, deny,
or warn users about accessing.
If a user accesses content that is not associated with any categories you select, the
policy action for the Default category is applied. For more information about the
Default category, see "Configuring System and Default Policy Actions" on page
246.
To select categories:

1. Complete the tasks discussed in the following sections first:
• "Enabling Blue Coat Web Filtering" on page 233
• Optional. "Enabling the Use of the Local Database (Optional)" on page 236
• "Enabling ProxyClient Web Filtering" on page 238
2. In the Client Manager’s Management Console, click Configuration > ProxyClient
> Web Filtering > Policy.

241

Volume 5: Advanced Networking
Section C: Configuring the ProxyClient

3. In the All Categories pane, expand Blue Coat.
Note: If the Client Manager does not have a valid BCWF database, the

BCWF categories do not display. If the database is stale (not updated in
the last 30 days), the categories are unavailable. Both of these symptoms
indicate a BCWF license issue. For more information, see one of the
following:


"Configuring ProxyClient Web Filtering" on page 231



Chapter 2, Web Filtering, in Volume 7: Managing Content

4. Select the check box next to each category to enforce a policy action on that
category.
When you select a category, it automatically displays in the Selected Category
Rulebase pane with a policy action the opposite of the Default category.
5. Repeat the preceding steps for the local and policy categories.
If you have no policy categories defined, see the next section.
If you do not wish to configure or change your policy categories, skip the next
section and continue with "Selecting Policy Actions for Categories" on page
244.

Managing Policy Categories
This section discusses how to add or edit policy categories. If an administrator has
already configured policy categories using VPM, you can add, edit, delete, or edit
URLs in any configured category. If you do not already have policy categories,
you can add them.
For more information about using VPM to add categories, see Volume 6: The Visual
Policy Manager and Advanced Policy.
To add, edit, delete, or edit URLs in policy categories:

1. Complete the tasks discussed in the following sections first:
• "Enabling Blue Coat Web Filtering" on page 233
• "Enabling the Use of the Local Database (Optional)" on page 236
• "Enabling ProxyClient Web Filtering" on page 238
• "Getting Started With Categories" on page 240
2. In the Client Manager’s Management Console, click Configuration > ProxyClient
> Web Filtering > Policy.
3. Near the bottom of the right pane, click Edit Categories.
The Edit Categories dialog displays the currently configured category nodes
(for example, Policy, Local, Blue Coat, and System).

242

Chapter 12: Accelerating and Controlling Micro-Branch and Mobile User Connections (ProxyClient)
Section C: Configuring the ProxyClient

Note: You can manage only the Policy categories. With the exception of local

categories (that come from the local database, if it is configured), the other
categories cannot be changed.
4. In the Edit Categories dialog, expand Policy.
5. You have the following options:
Task

Procedure

Add a policy category

1. Click Policy.
2. Click Add.
3. In the Object Name dialog, enter a name for
the policy category.
4. Click OK.
5. Add URLs to the category as discussed in
later in this table.

Rename a policy category

1. Click the name of the category.
2. Click Rename.
3. In the Edit Locally defined category Object
dialog, enter a new name for the policy
category.
4. Click OK.
5. Optionally add URLs to the category as
discussed in later in this table.

Delete a policy category

1. Click the name of the category.
2. Click Remove.
You are required to confirm the deletion.

Edit the list of URLs in a policy
category

1. Click the name of the category in which you
want to edit the list of URLs.
Note: You cannot add URLs to the Policy
node. You must first create a category under
that node as discussed earlier in this table.
2. Click Edit URLs.
3. In the Edit Locally defined category Object
dialog, enter or edit the list of URLs, one
URL per line.
4. Click OK.

6. In the Edit Categories dialog, click OK.
7. Continue with the next section.

243

Volume 5: Advanced Networking
Section C: Configuring the ProxyClient

Selecting Policy Actions for Categories
After choosing content categories, you must assign a policy action to each
category. You have the following options:


If the policy action is allow, the request goes to its destination.



If the policy action is block, the blocked category exception page displays.



If the policy action is warn, a warning message displays.
The user must click an acceptance link, which represents an acknowledgment
that the content request might violate corporate Web use policy. If the user
clicks the acceptance link, the request goes to its destination.
Note: If a user clicks the acceptance link the requested Web site will be
accessible for 15 minutes. The accessibility time period is not currently
configurable for the Web site.

To select policy actions:

1. Complete the tasks discussed in the following sections first:
• "Enabling Blue Coat Web Filtering" on page 233
• "Enabling the Use of the Local Database (Optional)" on page 236
• "Enabling ProxyClient Web Filtering" on page 238
• "Getting Started With Categories" on page 240
• "Selecting Categories" on page 241
2. In the Client Manager’s Management Console, click Configuration > ProxyClient
> Web Filtering > Policy.
3. In the Selected Category Rulebase section, select a policy action for each category
you added.
The following table discusses the available policy actions.
For detailed information about the exception page that displays in the user’s
Web browser for the block and warn policy actions, see "Displaying and
Customizing Web Filtering Exception Pages" on page 253.
Policy action
Block:

Users are denied this content; an
access log entry occurs; the user receives an
exception page notifying their breach of
Web use policy.

244

Example

Chapter 12: Accelerating and Controlling Micro-Branch and Mobile User Connections (ProxyClient)
Section C: Configuring the ProxyClient
Policy action

Example

Allow:

Users are allowed this content; an
access log entry occurs for URL tracking
and analyzing Web use (if the value of Log
Exceptions Only on the Configuration >
ProxyClient > Web Filtering > Log tab page is set
to All).

Warn:

An access log entry occurs; an
exception page displays in the user’s Web
browser notifying the user this Web
content might violate Web use policy; the
user must click a displayed link to
acknowledge this browsed category before
proceeding (or they can opt out).

Note: If a user clicks the acceptance link the
requested Web site will be accessible for 15
minutes. The accessibility time period is not
currently configurable for the Web site.

4. Continue with the next section.
If you have already defined policy actions for the system and default
categories, continue with "Ordering Categories in the Rulebase" on page 247.

245

Volume 5: Advanced Networking
Section C: Configuring the ProxyClient

Configuring System and Default Policy Actions
This section discusses how to configure policy actions for the following
categories:
Category

Description

System

The System node contains the following categories, which cannot be edited or
deleted:
• none, a category for Web sites that are not rated in any available categories and
for which the DRTR could not determine a rating. Available categories mean
BCWF database categories, local database categories (if enabled), and policy
categories (if configured).
Many Web sites generate more than one URL request so it is possible that an
allowed Web site might create other URL requests that are categorized
differently, or are categorized as none.
For example, images and advertisements displayed on an allowed Web site are
individually classified based on their URLs. Even if you allow users to access
that Web site, each of the ads and images on the site can be blocked based on
each URL’s categorization.
• unavailable, a category that is used if all of the following are true of a
particular URL request:
• When a service point cannot be reached
• When there is no match either in the local database (if enabled) or policy
categories (if configured)

Default

The Default category always displays as the last entry in the Category Rulebase
section. The policy action for the Default category is used if a URL request is not
classified into any of the categories in the Category Rulebase section.
Use caution before setting the policy action of the Default category to block. If
Default is set to block, any URL that is not in a category that you specifically allow
will be blocked.
To configure the System categories and the Default category:

1. Complete the tasks discussed in the following sections first:
• "Enabling Blue Coat Web Filtering" on page 233
• "Enabling the Use of the Local Database (Optional)" on page 236
• "Enabling ProxyClient Web Filtering" on page 238
• "Getting Started With Categories" on page 240
• "Selecting Categories" on page 241
2. In the Client Manager’s Management Console, click Configuration > ProxyClient
> Web Filtering > Policy.
3. In the All Categories pane, expand System.
4. Select the check box next to the none or unavailable categories.

246

Chapter 12: Accelerating and Controlling Micro-Branch and Mobile User Connections (ProxyClient)
Section C: Configuring the ProxyClient

The following table discusses the meanings of policy actions for these
categories.
System category

Policy action description

none

Set the policy action for Web sites that could not be
categorized by the service point.

unavailable

Set the policy action for Web sites for which the
ProxyClient could not reach a service point, or the
service point could not reach BCWF, to determine a
categorization.

5. When you are satisfied with your policy configuration, select the Enable Web
Filtering check box.
6. Click Apply.
7. In the Selected Category Rulebase pane, choose a policy action for the Default
category.
Note: The Default category cannot be moved from the bottom position because

this category is intended to be used if no other category matches result.
8. Click Apply.
9. Continue with the next section.

Ordering Categories in the Rulebase
After you have added categories to the rulebase and selected policy actions for
each, you must consider how the categories are ordered. Many URLs are
classified in more than one category, which results in a conflict.
In the case of a conflict between policy actions, the policy action associated with
the first rulebase match is applied.
For example, suppose the same URL (www.example.com/news) is listed in two
categories. One category has a policy action of allow and the other category has a
policy action of block.
In the table that follows, www.example.com/news is in both the Blogs/Personal
Pages and News/Media categories. The following table shows how the conflict is
resolved.

247

Volume 5: Advanced Networking
Section C: Configuring the ProxyClient

Rulebase configuration

Policy action
Because News/Media is first in the
rulebase and its policy action is allow,
www.example.com/news is allowed.

Because Blogs/Personal Pages is first in
the rulebase and its policy action is
block, www.example.com/news is
blocked.

Note: If the user is in an office location with ProxyClient Web filtering

disabled, a branch ProxySG performs Web filtering. For more information
about configuring a branch ProxySG to perform Web filtering, see Volume 7:
Managing Content.
Blue Coat recommends you order Web filtering rules in the category rulebase as
follows:
1. Whitelist overrides (that is, local database and policy categories you always
want to allow)
2. Blacklist overrides (that is, local database and policy categories you always
want to block)
3. All other categories with policy action set to block
4. All other categories with policy action set to warn
5. All other categories with policy action set to allow

248

Chapter 12: Accelerating and Controlling Micro-Branch and Mobile User Connections (ProxyClient)
Section C: Configuring the ProxyClient
To order categories in the category rulebase:

1. Complete the tasks discussed in the following sections first:
• "Enabling Blue Coat Web Filtering" on page 233
• "Enabling the Use of the Local Database (Optional)" on page 236
• "Enabling ProxyClient Web Filtering" on page 238
• "Getting Started With Categories" on page 240
• "Selecting Categories" on page 241
• "Configuring System and Default Policy Actions" on page 246
• "Selecting Policy Actions for Categories" on page 244
2. In the Client Manager’s Management Console, click Configuration > ProxyClient
> Web Filtering > Policy.
3. In the Category Rulebase pane, click the name of a category to move.
4. Click one of the following buttons:
Button

Meaning

Move-Up

Move the selected category up one position in the
rulebase. Use this button to move a more restrictive
category and action before a less restrictive category
and action.

Move-Down

Move the selected category down one position in the
rulebase. Use this button to move a more general
category and action after a more restrictive category
and action.

Promote to Top

Move the selected category and action to the top of the
rulebase. Use this button to move a very specific
category and action to the top of the rulebase.

Demote to Bottom

Move the selected category and action to the bottom of
the rulebase. (The Default category is always the last
category in the rulebase; this button demotes the
selected category to a position immediately above
Default.)

5. Continue with the next section.
If you have already configured options for license expiration, HTTPS filtering,
and safe search, continue with one of the following sections:




"Web Filtering Best Practices" on page 251
"Displaying and Customizing Web Filtering Exception Pages" on page 253
"Enabling Web Filtering Logging" on page 256

249

Volume 5: Advanced Networking
Section C: Configuring the ProxyClient

Configuring Other Web Filtering Options
This section discusses how to configure the following options:


On license expiration, which sets the behavior of ProxyClient Web filtering in
the event the BCWF license expires on the Client Manager



HTTPS filtering, which determines whether or not Web filtering policy actions
are applied to HTTPS content



Safe search, which determines whether or not ProxyClient users are required
to use safe search with supported search engines.

To configure other Web filtering options:

1. Complete the tasks discussed in the following sections first:
• "Enabling Blue Coat Web Filtering" on page 233
• "Enabling the Use of the Local Database (Optional)" on page 236
• "Enabling ProxyClient Web Filtering" on page 238
• "Getting Started With Categories" on page 240
• "Selecting Categories" on page 241
• "Configuring System and Default Policy Actions" on page 246
• "Selecting Policy Actions for Categories" on page 244
2. In the Client Manager’s Management Console, click Configuration > ProxyClient
> Web Filtering > Policy.
The bottom portion of the Policy tab page displays.

Editing categories is not discussed in this section; for more information, see
"Managing Policy Categories" on page 242.
3. Enter or edit the following information:
Option

Description

On License Expiration list

Select the action to take if the BCWF license expires
(usually because the database has not been updated
in a 30-day period):
• Fail Open—Users are allowed to browse
anywhere; in other words, content is not filtered.
Select this option if user Web access is more
critical than filtering or security.
• Fail Closed—Users are not allowed to browse to
any Web page. A Service Unavailable exception
displays in the user’s Web browser. Select this
option if security is your primary concern.

250

Chapter 12: Accelerating and Controlling Micro-Branch and Mobile User Connections (ProxyClient)
Section C: Configuring the ProxyClient
Option

Description

Enable HTTPS Filtering check

Select this check box to use Web filtering when the
content request is sent over an SSL connection using
the default port 443. For exceptions to this behavior,
see the ProxyClient Release Notes.

box

Clear this check box to not filter HTTPS traffic if
certain browsers are used.
Enforce Safe Search check box

Select this check box to force a search engine that
supports Safe Search to enable its strictest search
filter; however, the quality of the filtering is based
on the search engine’s built-in capabilities. The same
search string entered on one search engine might
yield different results when entered on another
search engine (including returning varying levels of
inappropriate content).
Safe Search is supported on the following search
engines: A9, Altavista, MSN/Live, Google, Yahoo,
ASK, Earthlink, and Orange.co.uk.
With safe search enabled, the search engine Web
page displays Safe Search ON, Family Filter On,
Safe Search Strict, or another engine-specific string.
Clear this check box if you do not wish to enforce
Safe Search.

See Also
"About ProxyClient Web Filtering" on page 196
"Web Filtering Best Practices" on page 251
"Displaying and Customizing Web Filtering Exception Pages" on page 253
"Enabling Web Filtering Logging" on page 256
"Configuring ProxyClient Web Filtering (CLI)" on page 264

Web Filtering Best Practices
Blue Coat recommends the following best practices when configuring
ProxyClient Web filtering:


If you have mobile users who frequently stay in hotels or access networks that
require an initial guest login before getting Internet access, select the System >
unavailable category and set it to Allow. For more information about this
scenario, see "About Security With Guest User Scenarios" on page 204.



Some software update sites will be blocked if the Business/Economy category
is set to Block or Warn.
For example, Java updates would fail because the Java update site is rated as
Business/Economy. Either allow the Business/Economy category or add the
software update Web sites to a custom category (using either the local

251

Volume 5: Advanced Networking
Section C: Configuring the ProxyClient

database or VPM), set its policy action to Allow, and order the rule before the
the Business/Economy category.


Because a particular URL might be listed in more than one category, policy
action conflicts can occur.

In the case of a conflict between policy actions, the policy action associated with
the first rulebase match is applied.
For example, suppose the same URL (www.example.com/news) is listed in two
categories. One category has a policy action of allow and the other category has a
policy action of block.
In the table that follows, www.example.com/news is in both the Blogs/Personal
Pages and News/Media categories. The following table shows how the conflict is
resolved.
Rulebase configuration

Policy action
Because News/Media is first in the
rulebase and its policy action is allow,
www.example.com/news is allowed.

Because Blogs/Personal Pages is first in
the rulebase and its policy action is
block, www.example.com/news is
blocked.

Note: If the user is in an office location with ProxyClient Web filtering

disabled, a branch ProxySG performs Web filtering. For more information
about configuring a branch ProxySG to perform Web filtering, see Volume 7:
Managing Content.

252

Chapter 12: Accelerating and Controlling Micro-Branch and Mobile User Connections (ProxyClient)
Section C: Configuring the ProxyClient

Blue Coat recommends you order Web filtering rules in the category rulebase as
follows:
1. Whitelist overrides (that is, local database and policy categories you always
want to allow)
2. Blacklist overrides (that is, local database and policy categories you always
want to block)
3. All other categories with policy action set to block
4. All other categories with policy action set to warn
5. All other categories with policy action set to allow

Displaying and Customizing Web Filtering Exception Pages
An exception page is an HTML message that displays in a user’s Web browser
when a content request triggers a policy action. You have the option of editing the
default exception pages to provide more detail about why the category is blocked.
Note: The behavior of exception pages when the user is browsing HTTPS content
when HTTPS filtering is enabled is as follows:



Some Web browsers: The exception page displays in the same browser
window as the request.



All other Web browsers: The exception page displays in a new browser
window.

For more information, see:


For up-to-date information about Web browsers and their behavior with
HTTPS filtering, see the ProxyClient Release Notes.



To enable HTTPS filtering, in the Client Manager’s Management Console,
click Configuration > ProxyClient > Web Filtering > Policy, and select the Enable
HTTPS Filtering check box. Click Help for more information.

Blue Coat provides default exception pages for the following occurrences:


Blocked content: When a user requests content that violates (matched by
category) enterprise Web use policy, the following message displays in the
Web browser:
Your request was denied because of its content categorization:
Category: offending_category_name
URL: requested_URL

253

Chapter 12: Accelerating and Controlling Micro-Branch and Mobile User Connections (ProxyClient)
Section C: Configuring the ProxyClient

3. Customize exception pages:
a. From the Exception page for list, select a page to customize:


Block:



Warn: Display text to inform users that the content they are requesting
might violate Web use policy. Users must click a link to acknowledge
this warning before receiving the content.



Unavailable:

Display text when a user browses to content blocked by policy.

Display text when the rating service becomes unavailable.

b. Customize the Web page header and body text. The Substitution
Variables field provides variables you can insert to display content
information:


url:



cs-categories: A full list of all category rating assigned to the Web site.
Many Web sites have more than one rating.



cs-categories-exception: The category that caused the exception (the first
one matched in the rulebase).



override-url: Applies to the Warn exception page only. This is used if
you change the Continue anyway link to something else, such as a
button. It will be substituted with the URL that must be pulled
through an HTML request to visit the page that was blocked by the
exception.

Displays the requested URL.

To add a variable to the custom message, insert the cursor in the HTML
code where you want the variable to be, select a variable, and click Insert.
You can add as many variables as you want.
c. Click Apply.

255

Volume 5: Advanced Networking
Section C: Configuring the ProxyClient

Enabling Web Filtering Logging
This section discusses Web filtering logging in the following sections:




"About Web Filtering Logging"
"How to Enable Web Filtering Logging" on page 256
"Interpreting the Log Files" on page 259

About Web Filtering Logging
Analyzing user Web browsing activity allows you to better customize your
content filter policies and to verify that your users are abiding by company
policies. You can configure the ProxyClient to upload user Web browsing activity
logs to an anonymous FTP server at regular time intervals or when the local log
file reaches a specified size.
Connections occur only when the client system has access to the specified FTP
server, which is typically when the user connects to the corporate network.
Note: Because log files are uploaded using anonymous FTP, Blue Coat strongly
recommends you put your FTP server behind the corporate firewall. In addition,
you should configure the FTP server to disable scans and file overwrites.

Placing an FTP server outside the firewall has the advantage that even mobile
users can upload log files to it; however, it exposes the server and your company
to potentially serious malicious activity.

How to Enable Web Filtering Logging
This section discusses how to enable Web filtering logging. You need to know the
name of the anonymous FTP server to which to upload files and the directory to
which to write the files. You can also configure automatic upload options based
on configurable thresholds.
If the user exceeds either of the following configurable thresholds, log updates
occur as soon as possible:


Number of hours since the last upload



Number of MB required for log files on the user’s computer

To enable logging and configure logging options:

1. Log in to the Client Manager’s Management Console as an administrator.

256

Chapter 12: Accelerating and Controlling Micro-Branch and Mobile User Connections (ProxyClient)
Section C: Configuring the ProxyClient

2. Click Configuration > ProxyClient > Web Filtering > Log.
The Log tab page displays.

3. Select the Enable Logging check box.
4. Click one of the following logging options:
Option

Description

Log All

Log all Web browsing activity.

Log Exceptions Only

Add a log entry only when a policy exception occurs
(blocks, warnings, and rating service unavailability).

257

Volume 5: Advanced Networking
Section C: Configuring the ProxyClient

5. In the FTP Server Connection section, enter or edit the following information:
Option

Description

Settings for list

Click the type of host you are configuring:
• Primary FTP Server
• Alternate FTP Server

Hosts field

Enter the FTP server’s fully-qualified domain name
or IP address.

Port field

Enter the FTP server’s listen port. The default is port
21. Make sure your firewall allows FTP traffic
through this port, and change the port from the
default only if your firewall and FTP server are
configured accordingly.

Path field

Enter the relative path on the server to write the
access log files.

6. Choose options that determine when files are uploaded from the ProxyClient
computer to the FTP server.
You can choose either a time interval or the total size, in MB, files occupy on
the client computer. This setting is particularly useful for mobile or offsite
users that cannot connect to your FTP server.
If a mobile or offsite user is away from the network for an extended period of
time and the threshold values are exceeded, an upload occurs as soon as
possible.

258

Chapter 12: Accelerating and Controlling Micro-Branch and Mobile User Connections (ProxyClient)
Section C: Configuring the ProxyClient

Enter or edit the following information:
Option

Description

Upload periodically every

• Hours field: Enter the maximum number of hours
to wait before attempting to upload logs from the
ProxyClient computer to the FTP server.
• Minutes field: Enter the maximum number of
minutes to wait before attempting to upload logs
from the ProxyClient computer to the FTP server.
Note: If you enter a non-zero value for both Hours
and Minutes, the total amount of time is used. For
example, if you enter 24 Hours and 10 Minutes, the
client waits 24 hours and 10 minutes to upload log
files.

Start an early upload if log
reaches

Enter the minimum log file size, in megabytes, to
trigger a log file upload.
This value takes precedence over the value you
entered in the preceding field. In other words, if you
specify 24 hours in the preceding field and 10
megabytes in this field, if the client log file size
reaches 10 megabytes after only 10 hours, the
ProxyClient attempts to upload its log files to the FTP
server.

7. Click Apply.

Interpreting the Log Files
The log file starts similarly to the following:
#Software:SG Client 3.1.1.0
#Version:1.0
#Fields: datetime c-ip c-username x-cs-auth-domain c-computername xexception-idcs-categoriescs-categories-exception cs-referer cs-method
cs-uri-schemecs-hostcs-uri-port cs-uri-path cs-uri-query cs-uriextensioncs-user-agents-ip

The following table defines the fields used in the log:
Field

Description

date

Date in Universal Time Code (UTC) format.

time

Time stamp in UTC format.

c-ip

Client’s IP address.

c-username

Client’s login user name.

x-cs-auth-domain

Client’s domain name (if available).

c-computername

Client’s computer name.

259

Volume 5: Advanced Networking
Section C: Configuring the ProxyClient
Field

Description

x-exception-id

One of the following:
• - if the content is allowed.
• content_filter_warned if the policy action is
warn.
• content_filter_denied if the policy action is
block.

cs-categories

Semi-colon-delimited categories for the content
request.

cs-categories-exception

The first category match; in other words, the
category on which the policy action shown by xexception-id is based.

cs-referer

Referring URL, if any.

cs-method

The method used in the content request (for
example, GET).

cs-uri-scheme

The URI’s schema (http or https).

cs-host

The host portion of the URI.

cs-uri-port

The port used to access the URI.

cs-uri-path

The path relative to cs-host. If cs-uri-scheme is
https, this field is blank.

cs-uri-query

Query string, if any. If cs-uri-scheme is https, this
field is blank.

cs-uri-extension

File extension of the object.

cs-user-agent

Information about the Web browser that requested
the object.

s-ip

Web server’s public IP address.

Following is a sample log entry showing that content was blocked:
2008-07-3117:51:17-joe.jones USA-TX-Austin
content_filter_denied"Vehicles" "Vehicles"
80
/ --Mozilla/4.0 (compatible; MSIE
CLR 1.1.4322; .NET CLR 2.0.50727; .NET CLR

LT-JOEJONES
-GET /http www.mazdausa.com
7.0; Windows NT 5.1; .NET
3.0.04506.30)129.33.107.81

In the preceding example, user joe.jones requested content from http://
www.mazdausa.com and the content was blocked. The content was categorized as
Vehicles, was requested by Internet Explorer 7, and was delivered from a Web
server with public IP address 129.33.107.81.

260

Chapter 12: Accelerating and Controlling Micro-Branch and Mobile User Connections (ProxyClient)
Section C: Configuring the ProxyClient

Configuring the ProxyClient from the Command Line
This section includes the following topics:










"Setting the Client Manager (CLI)" on page 261
"Configuring General ProxyClient Settings (CLI)" on page 261
"Configuring ProxyClient ADN Manager Settings (CLI)" on page 262
"Configuring ProxyClient ADN Rules Settings (CLI)" on page 262
"Configuring ProxyClient Locations (CLI)" on page 262
"Configuring ProxyClient File Sharing (CIFS) Settings (CLI)" on page 263
"Configuring ProxyClient Web Filtering (CLI)" on page 264
"Loading the Software (CLI)" on page 264
"Showing ProxyClient Settings (CLI)" on page 265

Setting the Client Manager (CLI)
For more information about configuring the Client Manager, see "Designating a
ProxySG as the Client Manager" on page 210.
To configure the Client Manager:

1. At the #(config) command prompt, enter proxy-client.
2. Enable this appliance as the Client Manager:
#(config proxy-client) enable

3. Configure Client Manager settings:
#(config proxy-client) client-manager host {from-client-address |
ip_address | host}
#(config proxy-client) client-manager install-port port
#(config proxy-client) client-manager keyring keyring

Configuring General ProxyClient Settings (CLI)
For more information about general client settings, see "Designating a ProxySG as
the Client Manager" on page 210.
To configure general client settings:

1. At the #(config) command prompt, enter proxy-client.
2. Configure general client settings:
#(config
#(config
#(config
#(config

proxy-client)
proxy-client)
proxy-client)
proxy-client)

max-cache-disk-percent percentage
software-upgrade-path url
update-interval minutes
view

261

Volume 5: Advanced Networking
Section C: Configuring the ProxyClient

Configuring ProxyClient ADN Manager Settings (CLI)
For more information about client ADN Manager settings, see "Accelerating
Network Traffic" on page 216.
To configure client ADN manager settings:

1. At the #(config) command prompt, enter proxy-client.
2. At the #(config proxy-client) prompt, enter adn.
3. Configure ADN manager settings:
#(config proxy-client acceleration adn) primary-manager ip-address
#(config proxy-client acceleration adn) backup-manager ip-address
#(config proxy-client acceleration adn) manager-port plain-port

Configuring ProxyClient ADN Rules Settings (CLI)
For more information about client ADN rules settings, see "Accelerating Network
Traffic" on page 216.
To configure client ADN rules settings:

1. At the #(config) command prompt, enter proxy-client.
2. At the #(config proxy-client) prompt, enter adn.
3. Configure ADN rules settings:
#(config proxy-client acceleration adn) port-list {exclude-ports |
include-ports}
#(config proxy-client acceleration adn) {exclude-ports | includeports} {port | port-list | port-range}
#(config proxy-client acceleration adn) exclude-subnets
#(config proxy-client acceleration adn
remove} subnet_prefix[/prefix length]
#(config proxy-client acceleration adn
#(config proxy-client acceleration adn
#(config proxy-client acceleration adn

exclude-subnets) {add |
exclude-subnets) clear
exclude-subnets) exit
exclude-subnets) view

#(config proxy-client acceleration adn) exit

Configuring ProxyClient Locations (CLI)
For more information about location settings, see "Configuring ProxyClient
Locations" on page 225.
To configure client location settings:

1. At the #(config) command prompt, enter proxy-client.
2. At the #(config proxy-client) command prompt, enter locations.

262

Chapter 12: Accelerating and Controlling Micro-Branch and Mobile User Connections (ProxyClient)
Section C: Configuring the ProxyClient

3. Configure location settings:
#(config proxy-client locations) create location_name
#(config proxy-client locations) edit location_name
#(config proxy-client name) acceleration {enable | disable}
#(config proxy-client name) webfilter {enable | disable}
#(config
#(config
#(config
#(config
#(config

proxy-client
proxy-client
proxy-client
proxy-client
proxy-client

name
name
name
name
name

dns)
dns)
dns)
dns)
dns)

add ip-address
clear
exit
remove ip-address
view

#(config
#(config
#(config
#(config
#(config

proxy-client
proxy-client
proxy-client
proxy-client
proxy-client

name
name
name
name
name

source)
source)
source)
source)
source)

#(config
#(config
#(config
#(config
#(config

proxy-client
proxy-client
proxy-client
proxy-client
proxy-client

name
name
name
name
name

vnic)
vnic)
vnic)
vnic)
vnic)

add ip-address-range
clear
exit
remove ip-address-range
view

add vnic-address-range
clear
exit
remove vnic-address-range
view

#(config proxy-client name) match-dns {enable | disable}
#(config proxy-client name) source {enable | disable}
#(config proxy-client name) vnic {enable | disable}
#(config proxy-client name) exit
#(config proxy-client name) view
#(config proxy-client
#(config proxy-client
#(config proxy-client
location_name}
#(config proxy-client
#(config proxy-client
#(config proxy-client

locations) acceleration {disable | enable}
locations) webfilter {disable | enable}
locations) {promote location_name | demote
locations) delete location_name
locations) clear
locations) view

Configuring ProxyClient File Sharing (CIFS) Settings (CLI)
For more information about CIFS client settings, see "Enabling File Sharing
Acceleration" on page 221.
To configure client CIFS client settings:

1. At the #(config) command prompt, enter proxy-client.
2. At the #(config proxy-client) command prompt, enter cifs.
3. Configure CIFS settings:
#(config
#(config
#(config
#(config
#(config

proxy-client
proxy-client
proxy-client
proxy-client
proxy-client

acceleration
acceleration
acceleration
acceleration
acceleration

cifs)
cifs)
cifs)
cifs)
cifs)

directory-cache-time seconds
{disable | enable}
exit
write-back {full | none}
view

263

Volume 5: Advanced Networking
Section C: Configuring the ProxyClient

Configuring ProxyClient Web Filtering (CLI)
For more information about Web Filtering client settings, see "Configuring
ProxyClient Web Filtering" on page 231.
To configure Proxy Client Web Filtering settings:

1. At the #(config) command prompt, enter proxy-client.
2. At the #(config proxy-client) command prompt, enter web-filtering.
3. Configure Web filtering settings:
#(config proxy-client web-filtering)
#(config proxy-client web-filtering)
#(config proxy-client web-filtering)
#(config proxy-client web-filtering)
category_name | warn category_name}
#(config proxy-client web-filtering)
category_name}
#(config proxy-client web-filtering)
demote-to-bottom category_name}
#(config proxy-client web-filtering)
#(config proxy-client web-filtering)
#(config proxy-client web-filtering)
enable}
#(config proxy-client web-filtering)
warn} data end-of-file-marker
#(config proxy-client web-filtering)

disable
enable
default-action {allow | block}
{allow category_name | block
{promote category_name | demote
{promote-to-top category_name |
failure-mode {open | closed}
safe-search {disable | enable}
https-filtering {disable |
inline exception {block | allow |
log

#(config proxy-client web-filtering
#(config proxy-client web-filtering
#(config proxy-client web-filtering
interval hours [minutes]
#(config proxy-client web-filtering
primary} host hostname port
#(config proxy-client web-filtering
exceptions-only}

log) {disable | enable}
log) early-update megabytes
log) periodic-upload uploadlog) ftp-client {alternate |
log) mode {all-requests |

#(config proxy-client web-filtering) view

Loading the Software (CLI)
The following commands enable you to upload an updated ProxyClient.car file
to the Client Manager.
#(config proxy-client) software-upgrade-path path-to-proxyclient-car

You can use any of the following commands to load the ProxyClient software on
the Client Manager:
#(config) load proxy-client-software

264

Chapter 12: Accelerating and Controlling Micro-Branch and Mobile User Connections (ProxyClient)
Section C: Configuring the ProxyClient

Showing ProxyClient Settings (CLI)
To show current ProxyClient settings:
#(config) show proxy-client [adn [exclude-subnets] | clients | cifs |
locations | web-filtering]

265

Volume 5: Advanced Networking
Section D: Distributing the ProxyClient Software

Section D: Distributing the ProxyClient Software
This section discusses the following topics:






"ProxyClient Compatibility with SGOS"
"Overview of Distributing the ProxyClient Software" on page 267
"Preparing Interactive Installations" on page 268
"Preparing Silent Installations and Uninstallations" on page 273
"Using Group Policy Object Distribution" on page 285

ProxyClient Compatibility with SGOS
Before you deploy the ProxyClient, make sure the ADN manager, backup
manager (if any), concentrators and the Client Manager in your ADN network are
running compatible versions of SGOS. In general, use the following guidelines:


Make sure the ADN manager, ADN backup manager (if any), concentrators,
and Client Manager are running the most recent version of SGOS.



If you need to upgrade ProxySG appliances, do so in the following order:
a. ADN Manager and ADN backup manager, if any
b. Concentrators
c. Client Manager
d. ProxyClient software on client computers

The following table summarizes SGOS compatibility with the ProxyClient
(version 3.1.x) and the SG Client (version 2.1.x):
5.3 CM
5.3 ADN
Mgr
5.3 Con

5.3 CM
5.3 ADN
Mgr
5.2 Con

5.3 CM
5.2 ADN
Mgr
5.2 Con

5.2 CM
5.2 ADN
Mgr
5.2 Con

5.2 CM
5.3 ADN
Mgr
5.2 Con

5.2 CM
5.3 ADN
Mgr
5.3 Con

SG Client
version 2.1.x

Compatible

Compatible

Compatible

Compatible

Compatible

Compatible

ProxyClient
version 3.1.x

Compatible

Compatible

Compatible

Not
compatible

Not
compatible

Not
compatible

In other words, SGOS 5.3 is backward compatible with the SG Client version 2.1.x.
However, to use the ProxyClient version 3.1.x in your ADN network, your Client
Manager and ADN Manager (and backup manager, if any) must run SGOS
version 5.3.x. In addition, Blue Coat recommends all concentrators that provide
ADN tunnels for ProxyClients be upgraded to SGOS version 5.3.x.

266

Chapter 12: Accelerating and Controlling Micro-Branch and Mobile User Connections (ProxyClient)
Section D: Distributing the ProxyClient Software

Overview of Distributing the ProxyClient Software
Administrators can make ProxyClient software available to users in any of the
following ways:


Interactive installations started from:


A command line on the user’s machine



The Client Manager

For more information, see "Preparing Interactive Installations" on page 268


Silent installations
For more information, see "Preparing Silent Installations and Uninstallations"
on page 273



Windows Group Policy Object distribution
For more information, see "Using Group Policy Object Distribution" on page
285



Windows Systems Management Server (SMS) distribution
For more information about SMS, consult the documentation provided with
your SMS server.

Note: For the user to run ProxyClientSetup.exe or ProxyClientSetup.msi, the

user must be in the Administrators group on the client machine.

Important:



Do not rename ProxyClientSetup.msi; doing so causes future updates to
fail.



Do not edit ProxyClientConfig.xml after it has been downloaded to the
client machine; instead, click Check for Updates Now on the ProxyClient Web
browser window’s Advanced tab page to get updates from the Client
Manager.

267

Volume 5: Advanced Networking
Section D: Distributing the ProxyClient Software

Preparing Interactive Installations
Users can install the ProxyClient software either by downloading
ProxyClientSetup.exe from the Client Manager, or manually by running
ProxyClientSetup.msi from a command line, as shown in the following table:
Table 12–3 ProxyClient Installation Options

Option

Description

Install from Client
Manager

Provide users the URL to ProxyClientSetup.exe, which
displays on the Client Manager tab page when you select
ProxyClient > Client Manager.
ProxyClientSetup.exe downloads and runs
ProxyClientSetup.msi on the client machine. Users see

the installation in progress and have the option of
canceling the installation.
For more information about this installation method, see
"Interactive Installations from the Client Manager" on
page 268.
Install from the command
line

To install the ProxyClient using ProxyClientSetup.msi,
users must first download it to the client machine, then
execute it from the command line as discussed in
"Interactive Manual Installations" on page 272.
Note: For a complete discussion of
ProxyClientSetup.msi command-line parameters, see

"Preparing Silent Installations and Uninstallations" on
page 273.
Note: Users who run the ProxyClient setup application must be in the
Administrators group on the client machine. Also, although it is possible for users
to run the .msi, it is not recommended because the installation will fail unless the
user provides parameters on the command-line (for example, BCSI_UPDATEURL).

Interactive Installations from the Client Manager
To interactively install the ProxyClient software from the Client Manager, the user
must be in the Administrators group on the client machine.
To enable users to run ProxyClientSetup.exe from the Client Manager:

Send users an e-mail with the URL to ProxyClientSetup.exe on the Client
Manager.
The URL displays when on the ProxyClient > Client Manager > Client Manager tab
page.

268

Chapter 12: Accelerating and Controlling Micro-Branch and Mobile User Connections (ProxyClient)
Section D: Distributing the ProxyClient Software
To install the ProxyClient using this method:

1. Get the URL or location from which you access ProxyClientSetup.exe.
2. Click the URL in an e-mail or enter it in your browser’s address field.
3. ProxyClientSetup.exe starts the setup application—ProxyClientSetup.msi—
that installs the ProxyClient software.
The following dialog displays if you use Internet Explorer 6:

4. Click Run. The following dialog displays if your browser is Internet Explorer 6:

Note: The Security Warning dialog displays because ProxyClientSetup.exe is
not signed. This is because ProxyClientSetup.exe is unique to each Client
Manager, which in turn makes signing it by a recognized certificate authority
difficult.

5. Click Run.

269

Volume 5: Advanced Networking
Section D: Distributing the ProxyClient Software

The ProxyClient software download begins. During the download, a progress
dialog similar to the following displays:

When the download completes, the InstallShield Wizard dialog displays.

6. Click Next.
7. The Destination Folder dialog allows you to determine the folder location to
which ProxyClient is installed. Blue Coat recommends that you install to the
default directory: c:\Program Files\Blue Coat\Proxy Client. To accept the
default click Next and proceed to Step 8.

270

Chapter 12: Accelerating and Controlling Micro-Branch and Mobile User Connections (ProxyClient)
Section D: Distributing the ProxyClient Software

To install to a directory of your choosing, click Change. The Change Current
Destination Folder dialog displays. Click the icons to navigate to a folder and
click Ok.

8. When are satisfied with your installation preparation decisions, click Install.
The Installing Blue Coat ProxyClient wizard dialog displays.

271

Volume 5: Advanced Networking
Section D: Distributing the ProxyClient Software

When the installation is complete, a dialog displays.



Click Restart Now to reboot the system immediately.



Click Restart Later to reboot the system at a later time. Select this option to
save work before you reboot.

Interactive Manual Installations
To enable users to manually install the ProxyClient software:

Provide a location from which the user can download ProxyClientSetup.msi to
the client machine; for example, provide the user the URL to the Client Manager.
Important:

Do not rename ProxyClientSetup.msi; doing so causes future
updates to fail.

Do not edit ProxyConfig.xml on the client machine; instead, click Check for Updates
Now on the Advanced tab page in the ProxyClient Web browser window to get
updates from the Client Manager.
To install the ProxyClient using this method:

1. Download ProxyClientSetup.msi to a location on the local file system.
2. Perform either of the following:


Select Start > Run, then enter the command shown in step 3.



Open a DOS command prompt window and change to the directory to
which you downloaded ProxyClientSetup.msi

3. Enter the following command:
path\ProxyClientSetup.msi BCSI_UPDATEURL=url-to-config.xml

where path is the absolute file system path to ProxyClientSetup.msi (if
necessary), url-to-config.xml is the URL to ProxyConfig.xml on the Client
Manager.

272

Chapter 12: Accelerating and Controlling Micro-Branch and Mobile User Connections (ProxyClient)
Section D: Distributing the ProxyClient Software

This URL displays when you select ProxyClient > Client Manager and click the
Client Manager tab as discussed in "Designating a ProxySG as the Client
Manager" on page 210.
For example,
ProxyClientSetup.msi BCSI_UPDATEURL=http://mysg.example.com:8084/
proxy/ProxyClientConfig.xml

Note: Other command-line parameters are available. For a complete list, see
"Preparing Silent Installations and Uninstallations" on page 273.

4. The installation proceeds as discussed in steps 1–5 in "Interactive Installations
from the Client Manager" on page 268.

Preparing Silent Installations and Uninstallations
This section discusses how to silently install or uninstall the ProxyClient.
This section includes the following topics:




"Parameters for Silent Installations" on page 274
"Command for Silent Uninstallations" on page 278
"Example Installations and Uninstallations" on page 279

Important:

Do not rename ProxyClientSetup.msi; doing so causes future
updates to fail.

Do not edit ProxyClientConfig.xml on the client computer after it has been
downloaded from the Client Manager. Instead, click Check for Updates Now on the
Advanced tab page of the ProxyClient’s Web browser window to get a
configuration update.
For information about distributing the ProxyClient software using Group Object
Policy, skip this section and see "Using Group Policy Object Distribution" on page
285.

273

Volume 5: Advanced Networking
Section D: Distributing the ProxyClient Software

Parameters for Silent Installations
The following table shows parameters to use with ProxyClientSetup.msi for silent
installations. For examples, see "Example Installations and Uninstallations" on
page 279.

Silent Installation Usage
ProxyClientSetup.msi [/qf | /qb | /qr | /qn] BCSI_UPDATEURL=url
REINSTALL=ALL REINSTALLMODE=vamus [AUTOUPDATEPROHIBITED=0|1]
[FORCEREBOOT={yes|no} | {y|n}] [REBOOTTIME=secs]
[REGISTRYSETTINGS=settings] [NO_UI_SHORTCUT={0|1} [/l*v logfile]

Silent Installation Parameters
The following table shows the meanings of the parameters that can be used for
silent installations; for examples, see "Example Installations and Uninstallations"
on page 279:
Table 12–4 Parameters for Silent ProxyClient Installations

Parameter

Argument

/qf | /qb | /qr | /qn
| /quiet

Description
Sets the user interface level (in other words, the extent to
which the installer interface displays to the user).
/qf (fully visible and interactive, the default) enables the

user to see and interact with the installer and to cancel the
installation.
/qb (basic)
/qr (reduced) enables the user to see and interact with the

installer and to cancel the installation.
/qn or /quiet (totally silent) prevents the user from

seeing or interacting with the installer and from canceling
the installation.
Note: Because this is an msiexec parameter, other options
are available. Enter msiexec at a command prompt for
more information about other options.
BCSI_UPDATEURL

url

URL to ProxyClientConfig.xml on the Client Manager,
which you can find as discussed in "Designating a
ProxySG as the Client Manager" on page 210, entered in
the following format:
https://client-manager-host:client-managerport/proxyclient/ProxyClientConfig.xml

REINSTALL

ALL

Installs all ProxyClient components, whether they are
already installed or not.
ALL is the only supported parameter value in this release.

274

Chapter 12: Accelerating and Controlling Micro-Branch and Mobile User Connections (ProxyClient)
Section D: Distributing the ProxyClient Software
Table 12–4 Parameters for Silent ProxyClient Installations (Continued)

Parameter

Argument

Description

REINSTALLMODE

vamus

Blue Coat recommends using vamus as the parameter
value. Because this is an msiexec parameter, other
options are available. For more information, see the
description of the REINSTALLMODE parameter on the
MSDN Web site.

AUTOUPDATEPROHIBITED

0|1

0 (default) means the ProxyClient automatically
implements software updates at the interval the
administrator specified for software update interval in
"Designating a ProxySG as the Client Manager" on page
210.
1 means only the ProxyClient configuration can be

updated (automatically or manually), but the ProxyClient
software cannot be updated. Use this setting if you want
to distribute software updates in some way other than the
Client Manager, such as GPO or SMS.
Note: Regardless of the value of this setting, the client
always gets configuration updates automatically when
they are available. Users can also get configuration
updates manually.
FORCEREBOOT

yes|no

yes or y mean the dialog displays with only a Restart Now

y|n

button and a progress bar that increments until the
computer reboots. (However, if REBOOTTIME=0, neither a
dialog nor progress bar displays.)
no or n (default) mean a dialog displays with two options:
Restart Now and Restart Later, enabling users to either

reboot immediately, wait for the timer to expire (see the
next parameter), or wait until a later time of their
choosing.
REBOOTTIME

secs

Number of seconds after the ProxyClient installation
completes before the user’s machine is rebooted. A nonzero value means a counter displays on the postinstallation reboot dialog.
A value of 0 means there is no timer before rebooting; to
the user, a value of 0 has different meanings, depending
on the value of FORCEREBOOT. For more information, see
"Example Installations and Uninstallations" on page 279.
The default is 0.

275

Volume 5: Advanced Networking
Section D: Distributing the ProxyClient Software
Table 12–4 Parameters for Silent ProxyClient Installations (Continued)

Parameter

Argument

Description

NOUISHORTCUT

0 | 1

Set to 1 to hide the Start menu option for the ProxyClient:
Start > [All] Programs > Blue Coat ProxyClient >
ProxyClient. To start the ProxyClient browser window, a
user must double-click the ProxyClient shortcut located
in %SystemDrive%:\Program Files\Blue
Coat\ProxyClient.
Set to 0 to show the Start menu option.
The default is 0.

REGISTRYSETTINGS

“name:datatype:value”

Colon-delimited, semicolon-separated list of registry
settings to create for the client. For more information, see
Table 12–5.

/l*v

logfile

If you want the installation to be logged, enter the
absolute file system path and file name of the log file.
The user installing the software must have permission to
write to the indicated folder and the folder must be
available during the installation; therefore, you should
avoid specifying a network drive.

Table 12–5 shows the available arguments for the REGISTRYSETTINGS parameter.
This parameter sets the key name, data type, and value of ProxyClient registry
settings under HKEY_LOCAL_MACHINE\SOFTWARE\Blue Coat Systems\Proxy Client.
Examples of using these settings can be found in "Limiting ProxyClient Visibility
and Interactivity" on page 281.
Important:

Blue Coat strongly recommends testing these registry settings
before deploying them in a production environment. Improper registry settings
might cause the installation to fail or to not function as expected.

276

Chapter 12: Accelerating and Controlling Micro-Branch and Mobile User Connections (ProxyClient)
Section D: Distributing the ProxyClient Software
Table 12–5 Parameters for ProxyClient registry settings

Key name

Data type

Value

CacheDirectory

REG_SZ

Set the folder in which ProxyClient byte and CIFS cache
files are stored. The directory you specify must already
exist. For example,
REGISTRYSETTINGS="CacheDirectory:REG_SZ:
D:\BCCacheDir"

By default, with no registry key specified, cache files are
stored in the following folder:
• Windows XP
%SystemDrive%\Documents and
Settings\LocalService\Local
Settings\Application Data\Blue Coat\Blue Coat
ProxyClient

• Windows Vista
%SystemDrive%\Windows\
system32\config\systemprofile\
AppData\Local\Blue Coat\Blue Coat ProxyClient
ChangeCMAllowed

REG_DWORD

Allowed values: 0 | 1
Set to 1 to allow the user to change the Client Manager.
For example,
REGISTRYSETTINGS="ChangeCMAllowed:REG_DWORD:1"

Set to 0 to prevent the user from changing the Client
Manager.
The default is 0.
TiNotVisible

REG_DWORD

Allowed values: 0 | 1
Set to 1 to hide the ProxyClient system tray icon and popup messages except to indicate that software updates are
being downloaded, or if the computer must be rebooted
to apply a software update. For more detail about
ProxyClient icon states, see "Limiting ProxyClient
Visibility and Interactivity" on page 281.
For example,
REGISTRYSETTINGS="TiNotVisible:REG_DWORD:1”

Set to 0 to display the ProxyClient tray icon and pop-up
messages.
The default is 0.

277

Volume 5: Advanced Networking
Section D: Distributing the ProxyClient Software
Table 12–5 Parameters for ProxyClient registry settings

Key name

Data type

Value

TiNotVisibleForceUpdate

REG_DWORD

Allowed values: 0 | 1
Set to 1 to force ProxyClient software updates on client
computers without user interaction. This registry setting
does not depend on the setting for TiNotVisible; in
other words, setting the value of this key to 1 means
clients always get updates regardless of whether or not
the tray icon is hidden.
For example,
REGISTRYSETTINGS="TiNotVisibleForceUpdate:
REG_DWORD:1"

Set to 0 to apply ProxyClient software updates normally;
that is, provided updates are allowed, users must install
the updates manually.
The default value is 0.
Note: Regardless of the value of this registry key, clients
always get configuration updates automatically at the
update interval you set using Configuration > ProxyClient
> General > Client Manager. Clients can also get
configuration updates manually at any time.

Command for Silent Uninstallations
To silently uninstall the ProxyClient software, use the following command:
msiexec /X{D35B0C7A-4545-4A98-A810-3810B3FE25E5} /quiet

The string {D35B0C7A-4545-4A98-A810-3810B3FE25E5} identifies the ProxyClient
installer’s MSI product code.

278

Chapter 12: Accelerating and Controlling Micro-Branch and Mobile User Connections (ProxyClient)
Section D: Distributing the ProxyClient Software

During uninstallation, the ProxyClient removes:


The SG Client (this is the pre-SGOS 5.3 version of ProxyClient).



All ProxyClient drivers, folders, files, the service, and so on.



ProxyClient cache files and the cache folder.

Note: Users who have administrative privileges on their machines can uninstall

the ProxyClient using the Control Panel > Add or Remove Programs application.

Example Installations and Uninstallations
This section shows the following examples:


"Example Installations" on page 279



"Example Uninstallation" on page 281

Additional examples are discussed in "Limiting ProxyClient Visibility and
Interactivity" on page 281.
Important:

Do not rename ProxyClientSetup.msi; doing so causes future
updates to fail.

Do not edit ProxyClientConfig.xml on the client computer after it has been
downloaded. Instead, click Check for Updates Now on the Advanced tab page of the
ProxyClient’s Web browser window to get updates.

Example Installations
Example 1: Automated, interactive installation, manual software updates
possible, cache directory located in D:\BCCacheDir:
ProxyClientSetup.msi /qr BCSI_UPDATEURL=https://mysg.example.com:8084/
proxyclient/ProxyClientConfig.xml REINSTALL=ALL REINSTALLMODE=vamus
FORCEREBOOT=no REBOOTTIME=30
REGISTRYSETTINGS="CacheDirectory:REG_SZ:D:\BCCacheDir"

The ProxyClient configuration downloads from the Client Manager at
https://mysg.example.com:8084. The user sees the installation in progress and
can cancel it.
The REINSTALL and REINSTALLMODE parameters cause all ProxyClient
components to install, which is useful in cases where you are recovering from
an incomplete or previously unsuccessful installation.
After the installation is complete, a dialog counts down from 30 seconds to the
time the computer will reboot automatically. When the dialog displays, the
user has the following options:


Click Restart Later in the dialog to defer rebooting until a later time.



Click Restart Now in the dialog to reboot immediately.

279

Volume 5: Advanced Networking
Section D: Distributing the ProxyClient Software

The REGISTRYSETTINGS parameter locates the cache directory in D:\BCCacheDir.
This directory must exist prior to the installation; otherwise, the default cache
directory will be used.
Example 2: Automated, interactive installation; the user has the ability to change
the Client Manager using the ProxyClient browser window
ProxyClientSetup.msi /qr BCSI_UPDATEURL=https://mysg.example.com:8084/
proxyclient/ProxyClientConfig.xml REINSTALL=ALL REINSTALLMODE=vamus
FORCEREBOOT=yes REBOOTTIME=30
REGISTRYSETTINGS="ChangeCMAllowed:REG_DWORD:1"

The ProxyClient configuration downloads from the Client Manager at
https://mysg.example.com:8084. The user sees the installation in progress and
can cancel it. The REINSTALL and REINSTALLMODE parameters make sure that all
ProxyClient components install, which is useful in cases where you are
recovering from an incomplete or previously unsuccessful installation.
The REGISTRYSETTINGS parameter creates a registry key that enables users to
change the Client Manager using the ProxyClient browser window (for more
information, see "Changing the Client Manager" on page 313).
After the installation is complete, the user has the following options:


Wait 30 seconds for the machine to reboot.



Click Restart Now in the dialog to reboot immediately.

Example 4: Automated, interactive installation without a timer
ProxyClientSetup.msi /qr BCSI_UPDATEURL=https://mysg.example.com:8084/
proxyclient/ProxyClientConfig.xml REINSTALL=ALL REINSTALLMODE=vamus
FORCEREBOOT=no REBOOTTIME=0

The ProxyClient configuration downloads from the Client Manager at
https://mysg.example.com:8084. The user sees the installation in progress and
can cancel it. The REINSTALL and REINSTALLMODE parameters make sure that all
ProxyClient components install, which is useful in cases where you are
recovering from an incomplete or previously unsuccessful installation.
After the installation is complete, the user has the following options:


Click Restart Later in the dialog to defer rebooting until a later time.



Click Restart Now in the dialog to reboot immediately.

Example 5: Totally silent installation, immediate reboot
ProxyClientSetup.msi /qn BCSI_UPDATEURL=https://mysg.example.com:8084/
proxyclient/ProxyClientConfig.xml REINSTALL=ALL REINSTALLMODE=vamus
FORCEREBOOT=yes REBOOTTIME=0

The ProxyClient configuration downloads from the Client Manager specified
at https://mysg.example.com:8084. The user does not see the installation in
progress and cannot cancel it. The user’s machine is rebooted immediately
after the installation is complete. The REINSTALL and REINSTALLMODE
parameters make sure that all ProxyClient components install, which is useful
in cases where you are recovering from an incomplete or previously
unsuccessful installation.

280

Chapter 12: Accelerating and Controlling Micro-Branch and Mobile User Connections (ProxyClient)
Section D: Distributing the ProxyClient Software

Example Uninstallation
msiexec /X{D35B0C7A-4545-4A98-A810-3810B3FE25E5} /quiet

The string {D35B0C7A-4545-4A98-A810-3810B3FE25E5} identifies the ProxyClient
installer’s MSI product code.

Limiting ProxyClient Visibility and Interactivity
This section discusses how to limit ProxyClient application visibility and user
interaction with the ProxyClient software. You can implement any or all of the
following options:
Option

Setting

Force ProxyClient software and
configuration updates on clients without
user interaction

key set to 1

Hide the ProxyClient system tray icon

TiNotVisible registry key set to 1

Hide the ProxyClient Start menu option

NOUISHORTCUT installer switch

TiNotVisibleForceUpdate registry

Registry keys and installer switches are discussed in more detail in "Command for
Silent Uninstallations" on page 278.
The following table shows the ProxyClient tray icon states and how they are
affected by these settings:
Icon

Icon meaning

Registry setting

Description

Normal

Default: TiNotVisible
registry key not present

Always displays

Invisible:

Never displays

TiNotVisible set to 1

281

Volume 5: Advanced Networking
Section D: Distributing the ProxyClient Software
Icon

Icon meaning

Registry setting

Description

Warning state (for
example, low disk space
or updates are available)

Default:

Always displays to warn users
about critical states or when user
action is required (for example, to
get software updates manually)

• TiNotVisible registry
key not present
• TiNotVisibleForceUpdate set to 0
Invisible but interactive:
• TiNotVisible set to 1
• TiNotVisibleForceUpdate registry
key not present

Invisible and noninteractive:
• TiNotVisible set to 1
• TiNotVisibleForceUpdate set to 1
Reboot required

TiNotVisible registry
key not present, set to 0 or
set to 1

Never displays; configuration
updates are downloaded
automatically but the user must
get software updates manually.
However, if software updates are
disabled (AutoUpdateProhibited registry key set to 1),
the user never gets software
updates.
Displays only to indicate that
software updates are currently
being downloaded; configuration
updates are downloaded
automatically but the icon does
not display.
Displays to indicate that a reboot
is required after a software update
or driver failure.

Note:
• In the preceding table, only the
(critical) icon state depends on both
TiNotVisible and TiNotVisibleForceUpdate. The other icon states are not
affected by TiNotVisibleForceUpdate.
• To enable users to get software updates if you hide the system tray icon or Start
menu option, set the AutoUpdateProhibited registry key to 0. You can do this by
editing the registry or by installing the ProxyClient software with the
AUTOUPDATEDPROHIBITED installer option absent or set to 0.

To use these options after you install the ProxyClient software, see "Limiting
ProxyClient Visibility After Installation" on page 315.

Examples
This section provides the following examples:


Example of installation allowing partially interactivity: Hiding the system
tray icon, and requiring clients to accept software updates without interaction:
ProxyClientSetup.msi /qn BCSI_UPDATEURL=https://mysg.example.com:8084/
proxyclient/ProxyClientConfig.xml REINSTALL=ALL REINSTALLMODE=vamus
FORCEREBOOT=yes REGISTRYSETTINGS="TiNotVisible:REG_DWORD:1;
TiNotVisibleForceUpdate:REG_DWORD:1"

282

Chapter 12: Accelerating and Controlling Micro-Branch and Mobile User Connections (ProxyClient)
Section D: Distributing the ProxyClient Software

This example sets the following options:
Option

Description

/qn

Performs a non-interactive installation.

BCSI_UPDATEURL=https://mysg.example.com:8084/
proxyclient/ProxyClientConfig.xml

Specifies the URL from which clients obtain
policy.

REINSTALL=ALL

Installs all ProxyClient components,
whether they are already installed or not.

REINSTALLMODE=vamus

For more information, see the description
of the REINSTALLMODE parameter on the
MSDN Web site.

FORCEREBOOT=yes

Forces clients to reboot after installing the
ProxyClient software.

REGISTRYSETTINGS="TiNotVisible:REG_DWORD:1;

• TiNotVisible:REG_DWORD:1

TiNotVisibleForceUpdate:REG_DWORD:1"

Hides the ProxyClient system tray icon
unless software updates are being
downloaded. The icon also displays after
the updates have been installed to
indicate the computer must be rebooted.
• TiNotVisibleForceUpdate:REG_DWORD:
1

Requires clients to accept software
updates when they are available. User
interaction is not permitted.
However, if the AutoUpdateProhibited
registry key is set to 1, it takes
precedence and software updates are
never downloaded.


Example of installation with no application visibility or interactivity:
Installing the ProxyClient to hide the system tray icon, hide the Start menu
option, and require clients to accept upgrades without interaction:
ProxyClientSetup.msi /qn BCSI_UPDATEURL=https://mysg.example.com:8084/
proxyclient/ProxyClientConfig.xml REINSTALL=ALL REINSTALLMODE=vamus
FORCEREBOOT=yes NO_UI_SHORTCUT=1
REGISTRYSETTINGS="TiNotVisible:REG_DWORD:=1;
TiNotVisibleForceUpdate:REG_DWORD:1"

283

Volume 5: Advanced Networking
Section D: Distributing the ProxyClient Software

This example sets the following options:
Option

Description

/qn

Performs a non-interactive installation.

BCSI_UPDATEURL=https://mysg.example.com:8084/
proxyclient/ProxyClientConfig.xml

Specifies the URL from which clients obtain
policy.

REINSTALL=ALL

Installs all ProxyClient components,
whether they are already installed or not.

REINSTALLMODE=vamus

For more information, see the description
of the REINSTALLMODE parameter on the
MSDN Web site.

FORCEREBOOT=yes

Forces clients to reboot after installing the
ProxyClient software.

NO_UI_SHORTCUT=1

Hides the ProxyClient Start menu option.
To view the ProxyClient browser window,
the user must double-click the
ProxyClient shortcut located in
%SystemDrive%:\Program Files\Blue
Coat\ProxyClient

REGISTRYSETTINGS="TiNotVisible:REG_DWORD:=1;
TiNotVisibleForceUpdate:REG_DWORD:1"

• TiNotVisible:REG_DWORD:1
Hides the ProxyClient system tray icon
unless software updates are being
downloaded. The icon also displays after
the updates have been installed to
indicate the computer must be rebooted.
• TiNotVisibleForceUpdate:REG_DWORD:
1

Requires clients to accept software or
configuration updates when they are
available. User interaction is not
permitted.
However, if the AutoUpdateProhibited
registry key is set to 1, it takes
precedence and software updates are
never downloaded.

284

Chapter 12: Accelerating and Controlling Micro-Branch and Mobile User Connections (ProxyClient)
Section D: Distributing the ProxyClient Software

Using Group Policy Object Distribution
This section discusses how to distribute the ProxyClient software using Windows
Group Policy Object (GPO).
Important: Only an experienced Windows administrator should attempt to
complete the tasks discussed in this section.
To distribute the ProxyClient software using GPO:

1. Get an .msi transform tool, such as the Orca database editor.
Orca is a table-editing tool available in the Windows Installer SDK that can be
used to edit your .msi files. You can also use similar tools available from other
vendors.
Note: Blue Coat does not recommend a particular transform tool.

For more information about Orca, see Microsoft KB article 255905.
The remainder of this section assumes you use Orca. Consult the
documentation provided with the transform tool you are using for vendorspecific instructions.
2. Open ProxyClientSetup.msi.
3. Perform the following changes to the Property table:
Note: Be advised, this action invalidates the signature on the MSI.

Table 12–6 ProxyClient setup property table changes

Property

Action

Value

BCSI_UPDATEURL

Add
row

Required for all installations.
URL to ProxyClientConfig.xml on the Client
Manager, entered in the following format:
https://client-manager-host:clientmanager-port/proxyclient/
ProxyClientConfig.xml

FORCEREBOOT

Edit
value

Required for all installations.
Change the value from n to y. This value causes
the user’s machine to reboot after the
ProxyClient is downloaded, which is required to
use the ProxyClient.

285

Volume 5: Advanced Networking
Section D: Distributing the ProxyClient Software
Table 12–6 ProxyClient setup property table changes

Property

Action

Value

REINSTALL

Add
row

Add this row and set it to all only if you want to
update the ProxyClient software and
configuration using GPO.
If clients get future ProxyClient software and
configuration updates from the Client Manager,
do not add this row.

REINSTALLMODE

Add
row

Add this row and change it to vamus only if you
want to update the ProxyClient software and
configuration using GPO.
If clients will get future ProxyClient software
and configuration updates from the Client
Manager, do not add this row.

AUTOUPDATEPROHIBITED

Edit
value

Change the value from 0 to 1 only if you want to
update the ProxyClient software in some way
other than from the Client Manager, such as
using GPO or SMS. (Configuration updates are
obtained from the Client Manager whose URL is
specified by the BCSI_UPDATEURL parameter
discussed earlier in this table.)
1 means only the ProxyClient configuration can

be updated (automatically or manually), but the
ProxyClient software cannot be updated. Use this
setting if you want to distribute software
updates in some way other than the Client
Manager, such as using GPO or SMS.
If clients will get future ProxyClient software
updates from the Client Manager, leave this
value at 0.

286

Chapter 12: Accelerating and Controlling Micro-Branch and Mobile User Connections (ProxyClient)
Section D: Distributing the ProxyClient Software

4. To implement registry changes discussed in Table 12–5 on page 277, use the
following steps:
a. Add one row to the Registry table for every registry setting you wish
to set.
b. In the Add Row dialog box, enter the following information:
Field

Description

Registry

Enter a unique description of the registry entry. The
value you enter is not written to the registry; it is used
only to identify the entry. The value must begin with
Registry.
For example, Registry1.

Root

Enter 2.

Key

Enter the ProxyClient registry path relative to
HKEY_LOCAL_MACHINE, Software\Blue Coat
Systems\Proxy Client

Name

Enter the name of the registry key; see Table 12–5 on
page 277.

Value

Enter the value of the registry key.
Note: If the value is REG_DWORD, you must preface
the value with the number sign (#). For example, a
registry key value of 1 must be entered as #1.

Component

Enter ProxyClientSvc.exe.

5. Generate the transformation.

287

Volume 5: Advanced Networking
Section E: About the ProxyClient Application

Section E: About the ProxyClient Application
This section provides an overview of the ProxyClient application that runs on
user systems. Review this section so that you are aware of your users interaction
with ProxyClient.
The user interface allows users to view statistics and Web filtering verdicts,
manually retrieve configuration and policy updates from the Client Manager,
perform basic troubleshooting tasks, and forward diagnostic information to
system administrators.
Note: The descriptions in this section are brief; for more detailed explanations of
specific options, access the Help file in the application.

How Users Access the ProxyClient Application
Users access the application by:


Selecting from the Windows Start menu: [All] Programs > Blue Coat ProxyClient >
ProxyClient.



Double-clicking the ProxyClient shield icon in the system program tray.



Right-clicking the ProxyClient shield icon in the system program tray and
selecting Show Status.

Note: To prevent users from seeing the ProxyClient application or knowing it is
running, you can optionally hide the tray icon as discussed in "Limiting
ProxyClient Visibility and Interactivity" on page 281.

ProxyClient starts in a Web browser window. If your default Web browser is
Internet Explorer, the ProxyClient starts in an Internet Explorer window. If your
default Web browser is Firefox, the ProxyClient starts in a Firefox window.
If your default Web browser is neither Internet Explorer nor Firefox, the
ProxyClient starts in an Internet Explorer window.

288

Volume 5: Advanced Networking
Section E: About the ProxyClient Application


D: Diagnostic Tools: These options allow users to (when instructed) perform
ProxyClient process traces. These traces can be for all processes or limited to
acceleration or Web filtering processes. For more detailed troubleshooting
information, see "Performing Data Traces and Data Collection" on page 317.
Also, users can click View Log to see a list of recent actions. For details, see
"Admin Log Contents" on page 292.



E: Disk Cache: Allows users to clear the ADN object cache. See "Client Manager

Logging" on page 305.

Admin Log Contents
The ProxyClient software maintains a diagnostic log that records the following:


Client installation (the timestamp of the initial installation and any
updates, including errors).



Activation of the driver and client service components every time those
components start.



Configuration download events (whenever a configuration download is
attempted and whether it succeeded or failed).



Connection information between the client machine and the ADN
manager.



ADN tunnel creation and destruction.



Activation/deactivation of the trace log, which is discussed in more detail
in "Performing Data Traces and Data Collection" on page 317.



Various error conditions (for example, out of memory, out of disk space,
and so on).

Log entries include the date and time of each event. The log file is a maximum of
20MB in size, after which the oldest log entries are deleted as new entries are
written.

292

Chapter 12: Accelerating and Controlling Micro-Branch and Mobile User Connections (ProxyClient)
Section F: Monitoring ProxyClient Performance

Section F: Monitoring ProxyClient Performance
This section discusses the following topics:


"Viewing History Statistics"
Statistics

> ProxyClient History

Aggregated bandwidth usage statistics related to the ProxyClient and all
concentrators in the network, and with the Client Manager (for example,
number of clients, number of software updates, and number of configuration
updates).


"Viewing ProxyClient ADN History Statistics" on page 295
Statistics

> ADN History

Statistics related to the ProxyClient and a particular concentrator. To view
statics related to ProxyClients and all concentrators on the network, view the
BW Usage tab page on Statistics > ProxyClient History.


"Viewing ProxyClient Active Session Statistics" on page 296
Statistics > Sessions > Active Sessions > ADN Inbound Connections

Statistics related to inbound ADN connections to a concentrator from
ProxyClients.

Viewing History Statistics
This section describes how to view the following statistics:


Client Manager: Current active ProxyClients, the number of software updates,
number of configuration updates, and ProxyClient version information.



Concentrators: Bandwidth usage aggregated for all concentrators.

To view ProxyClient history statistics:

1. Log in to a ProxySG appliance’s Management Console as an administrator.
The statistics you view depend on the role of the appliance, as follows:


Client Manager: To view Active Clients, Configurations Served, Software
Served, or Client Version Count.



Concentrator: To view BW Usage.

2. From the Management Console, select Statistics > ProxyClient History.

293

Chapter 12: Accelerating and Controlling Micro-Branch and Mobile User Connections (ProxyClient)
Section F: Monitoring ProxyClient Performance



E—Whether or



Tunnel—The type of TCP tunnel; ProxyClient connections are always
identified as Client.

not the incoming ADN tunnel is encrypted. In this release,
ProxyClient connections are not encrypted.

297

Volume 5: Advanced Networking
Section G: About the ProxyClient System Footprint

Section G: About the ProxyClient System Footprint
This section lists each file and folder on user systems impacted by the installation
and removal of the ProxyClient application. This chapter divides the information
into the following sections:






"Installation" on page 298


"Folders" on page 298



"Files" on page 299



"Setup Executable" on page 299



"Setup MSI" on page 299


"Installed Files" on page 300



"Shortcuts" on page 300



"Registry" on page 301



"During Runtime" on page 302

"During Runtime" on page 302


"Logging and Support" on page 302



"Acceleration Files" on page 302



"Web Filter Files" on page 303



"Data Collector" on page 303

"Removal" on page 303

Installation
This section lists all of the folders and files affected by installation.

Folders
Installation affects the following folders.
Table 12–7 Folders affected by installation

Name Used in the
Document

Default Path

Notes

Temp

%temp%

This is the user's
temporary folder.

Support

%SystemDrive%\Documents and
Settings\All Users\Application
Data\Blue Coat
Systems\ProxyClient\support

Diagnostic data is stored
here.

Installation Target

%SystemDrive%\Program Files\Blue
Coat\ProxyClient

Default installation
location.

298

Chapter 12: Accelerating and Controlling Micro-Branch and Mobile User Connections (ProxyClient)
Section G: About the ProxyClient System Footprint
Table 12–7 Folders affected by installation

Name Used in the
Document

Default Path

Notes

Drivers

%SystemDrive%\WINDOWS\system32\
drivers

None

Files
Installation affects the following files.
Table 12–8 Files affected by installation

File Name

Location

ProxyClientSetup.exe

If the file is opened directly from the
browser, it will be downloaded to the
Internet Explorer’s temporary Internet
files folder.

ProxyClientSetup.msi

%TEMP%

InstallSupport.log

Support folder

proxyclientlog.etl

Support folder

ProxyClientSetup_exe.log

Support folder

ProxyClientSetup_msi.log

Support folder

Setup Executable
The user can download the setup executable to any location on the system (disk).
The executable is a single file that downloads the setup MSI to the Temp folder
before execution (see "Setup MSI" for details about the MSI package).
Additionally, it creates the Support folder. Within this folder the executable creates
the install support log, the setup log for the executable, and a trace (.etl) file.
After it downloads the MSI, the executable runs the MSI to perform the actual
installation.

Setup MSI
This is to be run either by the setup executable or directly by the user (or by a
software distribution mechanism, such as SMS or GPO). If the Support folder and
files have not already been created by the setup executable, the MSI creates the
folder and files. The MSI package itself is approximately 7 MB in size.

299

Volume 5: Advanced Networking
Section G: About the ProxyClient System Footprint

Installed Files
The MSI installs the majority of the ProxyClient files to the Installation Target,
with the exception of the drivers, which are installed in the Drivers folder. The
following table lists these files.
Table 12–9 List of installed files.

File Name

Description

ProxyClient

Shortcut for the ProxyClient application

ProxyClientSvc.exe

ProxyClient service executable

ProxyClientUI.exe

ProxyClient tray icon executable

ProxyClient.dll

ProxyClient acceleration/web filtering
library

ProxyClientDC.exe

ProxyClient Data Collector utility

SGClientEula.html

End User License Agreement

Chartdir.dll

User interface support library

SGCustomAction.dll

Installation support library

Bridge.pyc

User interface support file

StringTable.pyc

User interface support file

ProxyClientConfig.xml

ProxyClient configuration and policy
file (downloaded from Client Manager)

ProxyClientFlt.sys

Acceleration driver (written to Drivers
folder)

ProxyClientWebFilter.sys

Web Filter driver (written to Drivers
folder)

Additionally, several user interface files are written to the include and webroot
folders under the Installation Target. The total size of the installed files (not
including the initial configuration file) is approximately 10 MB. The size of the
configuration file varies in size, from 2 KB to several MB.

Shortcuts
The MSI also creates a shortcut in the Start menu. The shortcut is called ProxyClient,
and is in the Blue Coat ProxyClient folder. No shortcuts are created on the desktop.

300

Chapter 12: Accelerating and Controlling Micro-Branch and Mobile User Connections (ProxyClient)
Section G: About the ProxyClient System Footprint

Registry
Table 12–10 lists some of the registry keys used by the ProxyClient. In the table,
the following abbreviations are used:


HKCR

means HKEY_CLASSES_ROOT



HKCU

means HKEY_CURRENT_USER



HKLM

means HKEY_LOCAL_MACHINE

Table 12–10List of registry keys.

Path

Purpose

HKCR\AppID\{5CDD0A2B-2C5C-4313-83EFA3F4A4551918}

Key: Contains data required
by the service

HKCU\Software\Blue Coat Systems\Proxy
Client\{DE43B3A2-ABC3-E2AE-37EC4C3557CB104E}

Key: Required by installer

HKLM\Software\Blue Coat Systems\Proxy Client

Key: Software settings for
ProxyClient
Keys under this node are
discussed in Table 12–11 on
page 311.

HKLM\Software\Microsoft\Windows\
CurrentVersion\Run

Value: Start tray icon on login

HKLM\Software\Microsoft\Windows
NT\CurrentVersion\Tracing\ProxyClient
Service

Key: Diagnostic settings

HKLM\System\CurrentControlSet\Services\
(proxyclientflt, proxyclientwebfilter,
WebFilter)

Sub-keys (in parentheses)
created for acceleration and
web filter drivers

HKLM\System\CurrentControlSet\Control\
SafeBoot\Network\proxyclientsvc

Key: Start ProxyClient when
booting in Safe Mode

301

Volume 5: Advanced Networking
Section G: About the ProxyClient System Footprint

During Runtime
As the ProxyClient runs, it creates additional files depending on what
functionality is enabled. When the service runs, an encrypted folder is created
under the Windows user folder for the LocalService account. This provides a
more secure environment for storing sensitive data.

Logging and Support
In the Support folder, if tracing is enabled a file named proxyclientdebug.etl is
created. Additionally, if the service crashes for any reason, a memory dump file is
generated in the Support folder.
Note: Trace files and memory dumps must be sent to Blue Coat Support for
interpretation.

If at any point a downgrade is performed through the auto-update mechanism, an
additional downgrade log is created in the Support folder.

Acceleration Files
When acceleration is enabled, this encrypted folder contains the byte and object
cache files in a protected environment. The size of the cache varies by machine,
and is determined by the amount of free space on the drive as well as the
configured amount of disk space to use.
The cache directory is used for both byte caching and CIFS caching, with each
cache using approximately have of the available space. The size of the files in the
cache directory are limited; 1GB free space is always available on the client
computer. For more information, see "More About ProxyClient Caching" on page
224.
The default location of the cache directory follows:


Windows XP
%SystemDrive%\Documents and Settings\LocalService\Local
Settings\Application Data\Blue Coat\Blue Coat ProxyClient



Windows Vista
%SystemDrive%\Windows\
system32\config\systemprofile\AppData\Local\Blue Coat\Blue Coat
ProxyClient

To change the location of the cache directory, see one of the following sections:

302



To set the cache directory when you install the ProxyClient software, see
"Command for Silent Uninstallations" on page 278.



To change the location of the cache directory after the software is installed, see
"Changing the Location of the Cache" on page 324.

Chapter 12: Accelerating and Controlling Micro-Branch and Mobile User Connections (ProxyClient)
Section G: About the ProxyClient System Footprint

Web Filter Files
When Web filtering is enabled, activity is logged to the encrypted folder. The log
files are periodically uploaded, and the extent of the data to be logged is
determined by the administrator.

Data Collector
The Data Collector utility, which is installed with the ProxyClient, creates a folder
within the Temp folder as a repository for the collected data. The contents of the
Support folder are copied here, and several new files are created. The specifics of
the folder's contents are discussed in other documents about the Data Collector.
Note: The Data Collector is a troubleshooting utility. For more details, see
"Instructing Users to Run the ProxyClient Data Collector" on page 319

Removal
When the ProxyClient is removed from a user's system, all installed software and
drivers are removed, including:






The object cache
The Web filter cache
Support data
Registry data
Application shortcut

Contents Left Behind
No files that were created in the Temp folder are removed. There is currently no
mechanism to track all of the files that are created there. However, these files are
safe for removal at any time.
Immediately following the removal of the ProxyClient (but before rebooting), it
might appear that some files created by the software or the installation process
have not yet been removed. This is because the files are still in use by other system
resources.
When this happens, the removal process marks the files for removal upon reboot.
Windows automatically removes them the next time that the system is restarted.

303

Volume 5: Advanced Networking
Section H: ProxyClient Troubleshooting

Section H: ProxyClient Troubleshooting
For administrators to assist ProxyClient users with diagnosing errors, you must
be familiar with the topics discussed in this section:










"About HTTPS Browser Proxies" on page 304
"Client Manager Logging" on page 305
"Acceleration Troubleshooting" on page 306
"Web Filtering Troubleshooting" on page 307
"Advanced Troubleshooting" on page 310
"Performing Data Traces and Data Collection" on page 317
"Clearing the Cache" on page 323
"Changing the Location of the Cache" on page 324
"Uninstalling the ProxyClient Software" on page 325

Note: If ProxyClient users are unable to get software or configuration updates
from the Client Manager or if network acceleration is not working, make sure
your firewall has the following ports open:



Client Manager listen port (by default, 8084)



ADN manager’s plain listen port (by default, 3034)



Concentrator’s plain tunnel port (by default, 3035)

About HTTPS Browser Proxies
This section discusses how to configure an Internet Explorer browser proxy to
enable users to download the ProxyClient software and updates. If you do not use
a proxy for SSL traffic, you can skip this section.
Note: Because the ProxyClient uses the Internet Explorer proxy settings to
download software and configuration updates, change the proxy settings in
Internet Explorer.

The following options are available:

304



If users can connect directly to the Client Manager, change the browser’s
proxy settings to exclude the Client Manager from being proxied.



Change the proxy settings to allow connections to the Client Manager listen
port (by default, 8084). You defined the Client Manager listen port as
discussed in "Designating a ProxySG as the Client Manager" on page 210.

Chapter 12: Accelerating and Controlling Micro-Branch and Mobile User Connections (ProxyClient)
Section H: ProxyClient Troubleshooting

Client Manager Logging
The Client Manager logs success or failure events related to users downloading
the ProxyClient software and configuration. Each log should include timestamp,
HTTP GET string (including the HTTP return code), and client machine name.
To obtain Client Manager logs:

Enter the following URL in your browser’s address field:
https://host:port/proxyclient/log

where host is the fully qualified host name or IP address of the Client
Manager, and port is the ProxySG appliance’s listen port.

Client Connection Issues
Use standard networking tools such as ping, tracert, telnet, and Internet Explorer
to understand why the client cannot connect. Because the Client Manager
protocol is HTTPS and the client uses the standard Windows Wininet library
(which is also used by Internet Explorer, and shares settings such as proxy
settings with Internet Explorer), you can use Internet Explorer as the main tool to
test these types of connectivity problems.
Verify the user can connect to the Client Manager from Internet Explorer by
entering the URL of the Client Manager. For example:
https://client_manager_IP_address:8084/

Note: For remote users, a VPN connection might be required to access the Client
Manager.

If Internet Explorer can access this URL, the client should also be able to
communicate with the Client Manager. If this is not the case, look for:


Things that might block traffic on the desktop for specific applications, such as
desktop security products.



Application-specific settings on the remote access VPN solution (verify that
traffic from the ProxyClientSvc.exe service is handled by the VPN solution).

Note: If ProxyClient users are unable to get software or configuration updates
from the Client Manager or if network acceleration is not working, make sure
your firewall has the following ports open:



Client Manager listen port (by default, 8084)



ADN manager’s plain listen port (by default, 3034)



Concentrator’s plain tunnel port (by default, 3035)

305

Volume 5: Advanced Networking
Section H: ProxyClient Troubleshooting

Acceleration Troubleshooting
The main sources of information for troubleshooting are the ProxyClient, the
Client Manager (for checking configuration and viewing client status), and the
relevant ProxySG concentrator. If you suspect there are ADN routing problems,
you can use the ADN manager for troubleshooting.
Note: If ProxyClient users are unable to get software or configuration updates

from the Client Manager or if network acceleration is not working, make sure
your firewall has the following ports open:


Client Manager listen port (by default, 8084)



ADN manager’s plain listen port (by default, 3034)



Concentrator’s plain tunnel port (by default, 3035)

About ADN Tunnels
On the Network tab page of the ProxyClient browser window, clicking the More Info
link in the ADN Tunnels area displays detailed information about available tunnels,
including whether a tunnel is idle or bypassed.
An idle tunnel is one that is not currently being used but preserves connection
connection information to decrease the amount of time required to use that
connection later, if necessary.
A direct tunnel indicates an error with the connection to the indicated ProxySG.

Diagnosing the Concentrator
This section provides what to look for on the concentrator:


Statistics > Active Sessions > ADN Inbound Sessions displays information about
currently active sessions, including sessions with ProxyClients. Use a client IP
address filter to view tunnels from a specific client.

For more information, see "Viewing ProxyClient Active Session Statistics" on
page 296
To view related client statistics, see the discussion of the Live ADN Session
View in "Diagnosing the ProxyClient" on page 307


306

Statistics > Advanced > ADN:



The Peer statistics link displays aggregate information per peer (client). For
each peer, it shows byte cache information such as dictionary status and
cache size.



The tunnel connection link shows information per each active connection.



The tunnel connection pool link shows information about idle tunnels.
This correspond to the idle tunnels displayed on the client side Live ADN
Session View.

Chapter 12: Accelerating and Controlling Micro-Branch and Mobile User Connections (ProxyClient)
Section H: ProxyClient Troubleshooting



The dashboard link and other links display aggregate information for
components such as tunnels and dictionary sizes.

Diagnosing the ProxyClient
This section provides what to look for on the client side of the ADN. Most of the
information provided by ProxyClient is statistical, but it might help you narrow
the ADN device causing the issues.


The Admin log (Advanced tab > Diagnostic Tools area) displays any error
conditions with established connections to the ADN Manager and to the
Concentrators. The log also displays successful events for connecting to the
ADN manager and establishing a new tunnel to a concentrator. However, it
does not show successful accelerated connection events.



Advanced Acceleration Admin Log—When this is activated, successful
accelerated connection events will also be recorded in the Admin Log.



The ProxyClient tray icon displays warnings or errors (such as pending
configuration updates and updates that require rebooting). Hover the mouse
pointer over the icon to display details.



ProxyClient user interface:


The Acceleration Statistics area of the Status tab provides information about
total traffic gains (totals and historic charts).



The Network tab provides information about the current ADN
configuration. For example, which subnets and ports are accelerated
(Configuration, Subnets, and Exempt Routes areas). The ADN Tunnels area
displays the number of active tunnels, idle tunnels, and direct
connections. The ADN managers are listed in the Configuration area.



The More Info link in the Network tab > ADN Tunnels area displays a dialog
referred to as the Live ADN Session View. This dialog displays all
currently accelerated connections, idle tunnels, and direct connections,
each with statistics showing acceleration gains (if accelerated), activity,
and the process that owns the connection.



The user can disable acceleration by clicking on the Status link on the Status
tab > Acceleration Statistics area.

Web Filtering Troubleshooting
The following sections provide methods to diagnose Web filtering issues reported
by users:




"Why Are Users Receiving Blocked or Warn Messages For No Justifiable
Reason?"
"ProxyClient Web Filtering Licensing" on page 309
"Disputing URL Categorization For ProxyClient" on page 309

307

Volume 5: Advanced Networking
Section H: ProxyClient Troubleshooting

Why Are Users Receiving Blocked or Warn Messages For No
Justifiable Reason?
The most common message you are likely to receive from your users is that
ProxyClient is denying them access to a Web site that they feel does not violate
Web-use policy.
The first step is to understand why the page is blocked or warned:


The rating server returned a category that resulted in a block action. The
exception page, admin log, and Most Recent Events list displays the category
that caused the block action.



The rating server did not return a category, and the none system category is
configured with a block action.



None the BCWF service points (rating servers) are available, and the
unavailable system category is associated with a block action.



License expiration is fail closed and the Client Manager is not licensed for
ProxyClient Web Filtering or does not have a fresh BCWF database.
ProxyClient displays Not licensed as the Web Filtering status on the Status tab.
The tray icon mouse over text also displays this state.



The service is not running or not responding, and the unavailable system
category is configured with a policy action of block. In this case, the tray icon
displays as
(needs reboot). The ProxyClient browser interface and admin
log are not available in this case.



After uninstalling the ProxyClient software but before rebooting because the
ProxyClient blocks all URLs when a reboot is required.



After a software update has been received but before the computer is rebooted
if the unavailable system category is configured with a block action.
In other words, software updates require a reboot. Between the time the
update is installed and the time the user reboots, the policy action for the
unavailable system category is applied.



by the client because the client blocks all URLs when a reboot is required.
Software updates always require a reboot.
Normal Web filtering resumes after the user reboots.



Some images on requested pages do not display. This is most likely caused by
subsequent requests on an allowed Web page falling into a blocked category.
(For example, a section or portlet on an allowed Web page might contact a
prohibited site for an advertisement.)
Advise your users this is expected behavior.

More detailed information for most of these events can be retrieved by activating
the Advanced Web Filtering Admin Log (see "Instructing Users to Perform Data
Traces" on page 318).

308

Chapter 12: Accelerating and Controlling Micro-Branch and Mobile User Connections (ProxyClient)
Section H: ProxyClient Troubleshooting

Various actions to remedy unjustified block (and warn) actions are available,
depending on the reason for the block action:


Add a URL to a custom category that is associated with an allow action (that
is, create a whitelist). Move this category above the category that is causing
the block action. This causes the allow action to be processed first.
You also have the option to disagree with the rating decision made by BCWF
and submit a request for categorization change.
See "Disputing URL Categorization For ProxyClient" on page 309.



Consider modifying the rule base, allowing the blocked category, allowing
none or unavailable categories, or changing the unlicensed behavior to fail open.
This option is valid if you are authorized to change the corporate compliant
browsing policy.



Fix the license violation. See "ProxyClient Web Filtering Licensing" on page
309.



Restart ProxyClient to fix non-responsive services.

ProxyClient Web Filtering Licensing
If your users notify you that the application displays the Filtering Unlicensed
message, the BCWF license is no longer valid or the URL database has not been
refreshed in the last 30 days.
On the Configuration > Content Filtering > Blue Coat > Blue Coat Web Filter tab page,
verify you have a valid license and click Download now to update the database.

Disputing URL Categorization For ProxyClient
In the event users report they are blocked from accessing a normally allowable
Web site, first make sure the problem is not caused by improper ordering of
categories in the Web filter rulebase. This is particularly true if a single URL is
listed in multiple categories.
For more information, see "Web Filtering Best Practices" on page 251.
If BCWF is blocking access to the Web site and you disagree with the URL’s
categorization, Blue Coat enables you to submit a Web site for review, stating
ProxyClient as the Web filter source.

309

Volume 5: Advanced Networking
Section H: ProxyClient Troubleshooting
To dispute a ProxyClient Web filter rating:

1. In your Web browser’s address or location field, enter:
http://sitereview.bluecoat.com/sitereview.jsp

The Web Page Review Process page displays.
2. In the field, enter the URL to be reviewed and click Submit.
3. On the second Web Page Review Process page, select Blue Coat ProxyClient from
the Filtering Service drop-down list.
4. From the first What category or categories does this site belong to? drop-down list,
select the category you believe the site belongs to. You can optionally select a
secondary category (for example, if your Web filtering policy allows one
category, but not the other).
5. (Optional) Select Please send results of the Site Review via email if you want Blue
Coat to notify you of the submission verdict.
6. In the Comments and Site Description field, enter a detailed message to Blue Coat
site reviewers explaining your reason for this submission.
7. Click Submit.

Advanced Troubleshooting
This section discusses advanced troubleshooting tools and procedures for
administrators. The tasks discussed in this section should be performed only by
administrators, or by users with assistance from administrators.
Following is a brief discussion of each troubleshooting tool:
Task

Description

Detail

For more
information

Change the
Client Manager
URL

Enables you to connect to a Client
Manager other than the one from which
you initially downloaded the
ProxyClient software. The typical use is
running ProxySG demonstrations, trials,
and evaluations from different ADN
networks.

After you set the
required registry key,
click the Advanced tab.
In the Client Manager
section, the Client

"Changing the
Client
Manager" on
page 313

Collects ProxyClient process information
(that is, both acceleration or Web
filtering) and provides more details than
the Admin Log.

Advanced tab page, in

Enables users to collect detailed trace
information for acceleration or Web
filtering individually, or for both.

Advanced tab page, in

Support trace

Advanced logs

310

Manager Address

value is a link.
the Diagnostic Tools
section.

the Diagnostic Tools
section. Click More
under Admin Log.

"Instructing
Users to
Perform Data
Traces" on page
318
"Performing
Data Traces
and Data
Collection" on
page 317

Chapter 12: Accelerating and Controlling Micro-Branch and Mobile User Connections (ProxyClient)
Section H: ProxyClient Troubleshooting
Task

Description

Detail

For more
information

Data collector

Collects diagnostic information useful to
troubleshoot unexpected behavior and
connectivity problems.

Enables users to collect
logs and system
information so you can
analyze the problem
and refer it to Blue
Coat Support, if
necessary. If you have
an SR number, you can
attach data collector
output to the SR ticket.

"Instructing
Users to Run
the ProxyClient
Data Collector"
on page 319

Registry
settings

See Table 12–11.

Table 12–11 summarizes ProxyClient registry settings:
Table 12–11ProxyClient registry settings

Key name

Data type

Value

AutoUpdateProhibited

DWORD

0 (default) means the ProxyClient automatically

implements software updates at the interval the
administrator specified for software update interval
in "Designating a ProxySG as the Client Manager" on
page 210.
1 means only the ProxyClient configuration can be

updated (automatically or manually), but the
ProxyClient software cannot be updated. Use this
setting if you want to distribute software updates in
some way other than the Client Manager, such as
GPO or SMS.
Note: Regardless of the value of this setting, the client
always gets configuration updates automatically
when they are available. Users can also get
configuration updates manually.

311

Volume 5: Advanced Networking
Section H: ProxyClient Troubleshooting
Table 12–11ProxyClient registry settings

Key name

Data type

Value

CacheDirectory

STRING

Set the folder in which ProxyClient cache files are
stored. The path must already exist; otherwise, the
default cache directory is used.
The default cache directory follows:
• Windows XP
%SystemDrive%:\Documents and
Settings\LocalService\Local
Settings\Application Data\Blue Coat\Blue
Coat ProxyClient

• Windows Vista
%SystemDrive%:\Windows\
system32\config\systemprofile\
AppData\Local\Blue Coat\Blue Coat
ProxyClient

For more information, see "Changing the Location of
the Cache" on page 324.
ChangeCMAllowed

DWORD

Allowed values: 0 | 1
Set to 1 to allow the user to change the Client
Manager.
Set to 0 to prevent the user from changing the Client
Manager.
The default is 0.
For more information, see "Changing the Client
Manager" on page 313.

TiNotVisible

DWORD

Allowed values: 0 | 1
Set to 1 to hide the ProxyClient system tray icon and
pop-up messages except in certain circumstances.
Set to 0 to display the ProxyClient tray icon and popup messages.
By default, this registry key does not exist.
For more information, see "Limiting ProxyClient
Visibility After Installation" on page 315.

312

Chapter 12: Accelerating and Controlling Micro-Branch and Mobile User Connections (ProxyClient)
Section H: ProxyClient Troubleshooting
Table 12–11ProxyClient registry settings

Key name

Data type

TiNotVisibleForceUpdate

DWORD

Value
Allowed values: 0 | 1
Set to 1 to force users to accept software and
configuration updates without interaction. This key is
independent of TiNotVisible; in other words, the
setting for this key determines update behavior
whether or not the ProxyClient tray icon is hidden.
Set to 0 to allow updates normally; that is, users
always get configuration updates. Software updates
can be installed manually.
By default, this registry key does not exist.
Note: The availability of software updates is
controlled by the AutoUpdateProhibited registry
key. If AutoUpdateProhibited is set to 1, users
cannot get software updates, regardless of the value
of this registry key. For more information, see
"Parameters for Silent Installations" on page 274.
For more information, see "Limiting ProxyClient
Visibility After Installation" on page 315.

Changing the Client Manager
You can change which Client Manager the ProxyClient uses if, for example, you
want to run trials or demonstrations on a different ADN network than the one for
which you initially configured the ProxyClient.
Note: After you change the Client Manager IP address, the client gets a
configuration update immediately. The behavior of software updates is not
changed; in other words, if you prohibited software updates, the client will not
attempt get a software update after it connects to the new Client Manager. If
software updates are allowed, the client gets an update at the next update
interval.
To change the Client Manager URL:

1. Set the ChangeCMAllowed registry key in any of the following ways:


When the ProxyClient software is installed as discussed in Table 12–5 on
page 277.



After installing the ProxyClient software as discussed in the next step.

2. If a user is not allowed to change the Client Manager URL and the ProxyClient
is already installed, perform the following tasks:
a. Start a registry editor application like regedit.

313

Volume 5: Advanced Networking
Section H: ProxyClient Troubleshooting

b. Browse to the following node:
HKEY_LOCAL_MACHINE\SOFTWARE\Blue Coat Systems\ProxyClient

c. Double-click the ChangeCMAllowed registry key.
d. In the Edit DWORD Value dialog, in the Value data field, enter 1.
e. Click OK.
Note: It is safe to set this while the service is already running.

3. In the ProxyClient Web browser window, click the Advanced tab.
4. In the Client Manager section, click the current Client Manager address link.
The Change Client Manager dialog displays.
5. In the Change Client Manager dialog, enter or edit the following information:
Field

Description

New Address

Enter the Client Manager’s fully qualified host name
or IP address.

New Port

Enter the Client Manager’s listen port.

6. Click OK.
A success or fail message displays in the Change ProxyClient Manager
browser window as the URL is verified.
The client gets a configuration update from the new Client Manager
immediately. If software updates are ready to download at the next update
interface, and if the client is allowed to get software updates, you are notified
before the updates are installed.
When the operation is complete, the Advanced tab page displays the new
Client Manager host name or IP address.

314

Chapter 12: Accelerating and Controlling Micro-Branch and Mobile User Connections (ProxyClient)
Section H: ProxyClient Troubleshooting

Limiting ProxyClient Visibility After Installation
This section discusses how to limit ProxyClient application visibility and user
interaction with the ProxyClient software. You can implement any or all of the
following options:
Option

Setting

Force ProxyClient software and
configuration updates on clients without
user interaction

key set to 1

Hide the ProxyClient system tray icon

TiNotVisible registry key set to 1

Hide the ProxyClient Start menu option

NOUISHORTCUT installer switch

TiNotVisibleForceUpdate registry

This section discusses how to limit visibility and interaction after the ProxyClient
software is installed.
The following table shows the ProxyClient tray icon states and how they are
affected by these settings:
Icon

Icon meaning

Registry setting

Description

Normal

Default: TiNotVisible
registry key not present

Always displays

Invisible:

Never displays

TiNotVisible set to 1

Warning state (for
example, low disk space
or updates are available)

Default:
• TiNotVisible registry
key not present
• TiNotVisibleForceUpdate set to 0
Invisible but interactive:
• TiNotVisible set to 1
• TiNotVisibleForceUpdate registry
key not present

Invisible and noninteractive:
• TiNotVisible set to 1
• TiNotVisibleForceUpdate set to 1

Always displays to warn users
about critical states or when user
action is required (for example, to
get software updates manually)

Never displays; configuration
updates are downloaded
automatically but the user must
get software updates manually.
However, if software updates are
disabled (AutoUpdateProhibited registry key set to 1),
the user never gets software
updates.
Displays only to indicate that
software updates are currently
being downloaded; configuration
updates are downloaded
automatically but the icon does
not display.

315

Volume 5: Advanced Networking
Section H: ProxyClient Troubleshooting
Icon

Icon meaning

Registry setting

Description

Reboot required

TiNotVisible registry
key not present, set to 0 or
set to 1

Displays to indicate that a reboot
is required after a software update
or driver failure.

Note:
• In the preceding table, only the
(critical) icon state depends on both
TiNotVisible and TiNotVisibleForceUpdate. The other icon states are not
affected by TiNotVisibleForceUpdate.
• To enable users to get software updates if you hide the system tray icon or Start
menu option, set the AutoUpdateProhibited registry key to 0. You can do this by
editing the registry or by installing the ProxyClient software with the
AUTOUPDATEDPROHIBITED installer option absent or set to 0.

To install the ProxyClient software with limited visibility and user interaction, see
"Limiting ProxyClient Visibility and Interactivity" on page 281.
To limit ProxyClient visibility and interaction after installation:

1. Log in to a computer running the ProxyClient as an administrator.
2. Start a registry editor application like regedit.
3. Navigate to the following node:
HKEY_LOCAL_MACHINE\SOFTWARE\Blue Coat Systems\ProxyClient

4. Do any of the following:
To get this behavior

Perform these tasks

Hide the system tray icon

1. Right-click the ProxyClient key.
2. From the pop-up menu, click New > DWORD Value.
3. For the name of the value, enter TiNotVisible.
4. Double-click TiNotVisible.
The Edit DWORD Value dialog displays.
5. In the Value Data field, enter 1.
6. Click OK.

Force users to accept
configuration and software
updates without interaction

1. Right-click the ProxyClient key.
2. From the pop-up menu, click New > DWORD Value.
3. For the name of the value, enter
TiNotVisibleForceUpdate.
4. Double-click TiNotVisible.
The Edit DWORD Value dialog displays.
5. In the Value Data field, enter 1.
6. Click OK.

5. Close the registry editor application.

316

Chapter 12: Accelerating and Controlling Micro-Branch and Mobile User Connections (ProxyClient)
Section H: ProxyClient Troubleshooting

6. Reboot the computer for the changes to take effect.
The tray icon and pop-up messages are not visible except to notify the user
that a software update is being downloaded, and to notify the user to reboot
the computer after updates have been installed. If you prohibit automatic
software updates, the icon never displays.

Performing Data Traces and Data Collection
Traces, logs, and data collection allows users to send you files containing
ProxyClient process data that you or Blue Coat Support can use to diagnose
issues.
This section discusses the following topics:





"About ProxyClient Logs"
"About the Data Collection Application" on page 318
"Instructing Users to Perform Data Traces" on page 318
"Instructing Users to Run the ProxyClient Data Collector" on page 319

About ProxyClient Logs
Logs are written to the following folder:


Windows XP:
%SystemDrive%\Documents and Settings\All Users\Application Data\Blue
Coat Systems\ProxyClient\support



Windows Vista:
%SystemDrive%\ProgramData\Blue Coat Systems\proxyclient\support

The ProxyClient creates the following log files:
Log file name

Used by

proxyclientautoupdate.log

Logs automatic software updates but not
configuration updates.

proxyclientlog.etl

Admin log (the log users can view on the
ProxyClient Web browser window’s Advanced tab
page).
The admin log contains information about
acceleration, Web filtering, software upgrades, and
configuration updates.
The admin log is written during the entire time the
ProxyClient is running.

317

Volume 5: Advanced Networking
Section H: ProxyClient Troubleshooting
Log file name

Used by

proxyclientdebug.etl

• All advanced admin logs on the Advanced tab
page
Trace logs contain more information than the
admin log. Users can enable trace logging for
acceleration, Web filtering, or both. All trace logs
are written to this file.
• Support trace, which records all client activity in
detail.

Note: .etl is a binary format that is readable only by Blue Coat Support.

About the Data Collection Application
The ProxyClientDC application gathers system information to send to Blue Coat
Support for troubleshooting and debugging purposes. Users have the option of
collecting logs and e-mailing them to you or sending them directly to Blue Coat
support and attaching them to an existing Service Request (SR).
For more information, see "Instructing Users to Run the ProxyClient Data
Collector" on page 319.

Instructing Users to Perform Data Traces
To create trace logs to get assistance from Blue Coat support, ask users to enable
any of the following:


The support trace, which records all client activity.



Detailed trace activity for acceleration, Web filtering, or both.

For users to start a trace:

1. The user starts the ProxyClient Web browser window.
If you limited the ProxyClient’s visibility, see "Limiting ProxyClient Visibility
After Installation" on page 315.
2. Click the Advanced tab.
3. On the Advanced tab page, in the Diagnostic Tools section, click More under
Admin Log.
4. Click the Start Trace link next to the trace you wish to start.
5. Repeat the activity that caused the problem.
6. Click the Stop Trace link.
7. Click Open Trace Folder.
8. Send the appropriate .etl file to Blue Coat Support with detailed information
about what caused the issue.

318

Chapter 12: Accelerating and Controlling Micro-Branch and Mobile User Connections (ProxyClient)
Section H: ProxyClient Troubleshooting

Note: These instructions are included in the ProxyClient on-line help that is

available to users. Users can click Help either on the ProxyClient system tray
icon or in the Web browser window.

Instructing Users to Run the ProxyClient Data Collector
Installed in the ProxyClient folder on user systems, the ProxyClient Data
Collector is a utility that end users run to collect comprehensive system
information that administrators or Blue Coat Support can use to diagnose
problems with the ProxyClient application and network connectivity.
When users access the Data Collector, they must select one of two data collection
modes:




System Administrator Mode: This mode collects the following information,
which is intended for corporate network administrators:


All ProxyClient logs, including installation logs and diagnostic trace
messages.



A memory dump of the ProxyClient service process.



The current configuration file and registry settings.



A list of all running processes on the system.



Various network-related information (IP configuration, trace route, netstat
data, and so on).

Blue Coat Mode: If your issue was assigned a Service Response (SR) number,
the user must enter the SR number to enter Blue Coat mode. In Blue Coat
mode, the ProxyClient collects the following information in addition to the
information discussed in the preceding point:


Diagnostic trace messages.



A full memory dump of the ProxyClient service process.

To run the ProxyClient Data Collector utility:

1. The user starts Windows Explorer or double-clicks My Computer.
2. Locate the ProxyClient installation folder.
The default location is %SystemDrive%:\Program Files\Blue Coat\Proxy
Client\.

319

Chapter 12: Accelerating and Controlling Micro-Branch and Mobile User Connections (ProxyClient)
Section H: ProxyClient Troubleshooting

Options are discussed in the following table.
Option

Action
Ask users to select this
option if you suspect a
configuration or
network problem.

If you have entered a
support case with
Blue Coat Support and
have received an SR
number, provide users
with that number. The
user should select the
check box and enter
the SR number in the
provided field.
Alternate: If you do
not have an SR
number but want to
collect detailed
information for Blue
Coat Support, clear
the check box. After
the data collection
process completes, ask
the user to send you
the file so you can
contact Blue Coat
Support.

5. Click Next.
The Data Collector starts and displays the Blue Coat ProxyClient
DataCollector dialog.

321

Volume 5: Advanced Networking

Figure 12–8 Green check marks indicate successful task completion.

Note: The preceding example shows collecting data in System Administrator

mode. If the user selects Blue Coat Support mode, additional tasks are
performed.
A green check mark displays next to each task as it completes successfully
(some tasks might require several minutes to complete). At any time, click
Stop to stop the data collection process (for example, the process appears hung
on one stage).
6. After ProxyClient completes all of the tasks:


322

System Administrator Mode or Blue Coat mode without selecting the
check box to send the data to Blue Coat. Instruct users to:
a

Click View collected data. The collected files display in Windows
Explorer.

b

Right-click the .zip file (begins with proxyclientdc- and ends with
the user’s system name and date/timestamp) and select Send to >
My Documents.

c

E-mail the .zip file to you.

d

Click Exit.

Chapter 12: Accelerating and Controlling Micro-Branch and Mobile User Connections (ProxyClient)



Blue Coat Mode (with the Automatically upload data directly to Blue Coat
option selected): ProxyClient automatically forwards the information and
associated case number to Blue Coat Support. Click Exit.



Blue Coat Mode—connection error: If users experience a connection
error—that is, ProxyClient cannot upload to Blue Coat—instruct them to
run the Data Collector in Blue Coat Mode again, but do not select
Automatically upload data directly to Blue Coat.

Clearing the Cache
Clearing the object cache might be necessary to free disk space if disk space
becomes critical. Because the object cache improves network performance, you
should consider this action only after the user removes other unnecessary
applications and files.
Clearing the object cache removes files for both byte caching and CIFS
optimization. These files are located by default in one of the following hidden
folders:


Windows XP
%SystemDrive%\Documents and Settings\LocalService\Local
Settings\Application Data\Blue Coat\Blue Coat ProxyClient



Windows Vista
%SystemDrive%\Windows\
system32\config\systemprofile\AppData\Local\Blue Coat\Blue Coat
ProxyClient

To clear the object cache:

1. The user double-clicks the ProxyClient system tray icon to start the Web
browser window.
If you chose to hide the system tray icon, see "Limiting ProxyClient Visibility
and Interactivity" on page 281.
2. Click the Advanced tab.
3. On the Advanced tab page, in the Disk Cache section, click Clear Cache.
You are required to confirm the action.
Note:



Clearing the cache while the client is running does not delete files that are
currently in use.



These instructions are included in the ProxyClient on-line help that is
available to users. Users can click Help either on the ProxyClient system
tray icon or in the Web browser window.

323

Volume 5: Advanced Networking

Changing the Location of the Cache
This section discusses how to change the location the ProxyClient stores CIFS
cache and byte cache files.
By default, the cache is stored in the following folder:


Windows XP
%SystemDrive%\Documents and Settings\LocalService\Local
Settings\Application Data\Blue Coat\Blue Coat ProxyClient



Windows Vista
%SystemDrive%\Windows\system32\config\systemprofile\AppData\Local\Blue
Coat\Blue Coat ProxyClient

To optionally locate the files on a different volume (for example, a volume that
has more available space):

1. If the ProxyClient is already installed, perform the following tasks first:
a. Double-click the ProxyClient icon in the system tray.
b. In the ProxyClient Web browser window, click the Advanced tab.
c. On the Advanced tab page, click Clear Cache.
You are required to confirm the action. This deletes or expires all the files
in the cache directory.
2. Create a registry value named CacheDirectory of type REG_SZ (that is, String)
in the following key:
HKEY_LOCAL_MACHINE\SOFTWARE\Blue Coat Systems\ProxyClient

3. Set the Value data of CacheDirectory to the location to store the object cache.
Note:



The directory must already exist; otherwise, the default cache directory
will be used.



You can also create the registry key during a silent installation as
discussed in Table 12–5 on page 277.

4. Reboot the client computer for the registry key to take effect.

324

Chapter 12: Accelerating and Controlling Micro-Branch and Mobile User Connections (ProxyClient)

Uninstalling the ProxyClient Software
This section describes how to uninstall the ProxyClient application software from
user systems. You can uninstall ProxyClient from your system only if you are in the
Administrators group on the computer.

For information about silent uninstallation, see "Example Uninstallation" on page
281.
To uninstall the ProxyClient software:

1. Log in to your machine as a user who is a member of the Administrators
group.
2. Click Start > Control Panel.
3. In the Control Panel window, double-click Add or Remove Programs.
4. Click Blue Coat ProxyClient.
5. Click Remove.
6. Follow the prompts to uninstall the software.

Secondary Procedure
If you discover the preceding procedure did not remove all traces of the
ProxyClient software, perform the tasks discussed in this section.
To uninstall the ProxyClient in Windows Safe Mode:

1. Boot into Safe Mode without Networking, which means that no ProxyClient
components are loaded by the system.
2. Log in as an administrator
3. Click Start > Settings > Control Panel.
4. In the Control Panel window, double-click Add or Remove Programs.
5. Click Blue Coat ProxyClient.
6. Click Remove.
7. Follow the prompts to uninstall the software.

325

Volume 5: Advanced Networking

326

Chapter 13: SOCKS Gateway Configuration

This chapter discusses the Blue Coat implementation of SOCKS, which
includes the following:


A SOCKS proxy server that supports both SOCKSv4/4a and SOCKSv5,
running on the ProxySG appliance.



Support for forwarding through SOCKS gateways.

To configure a SOCKS proxy server on the ProxySG, refer to Volume 2: Proxies
and Proxy Services. To use SOCKS gateways when forwarding traffic, continue
with this chapter.

Topics in this Chapter
This chapter includes information about the following topics:


Section A: "Configuring a SOCKS Gateway" on page 328.



Section B: "Using SOCKS Gateways Directives with Installable Lists" on
page 337.

327

Volume 5: Advanced Networking
Section A: Configuring a SOCKS Gateway

Section A: Configuring a SOCKS Gateway
SOCKS servers provide application level firewall protection for an enterprise.
SOCKS gateways, like ICP and forwarding, can use installable lists for
configuration. You can configure the installable list using directives. You can also
use the Management Console or the CLI to create a SOCKS gateways
configuration. Using the Management Console is the easiest method.
To configure a SOCKS gateway:

1. Select Configuration > Forwarding > SOCKS Gateways > SOCKS Gateways.
2. Click New to create a new SOCKS gateway.

3. Configure the SOCKS gateway as follows:
a. Alias: Give the gateway a meaningful name.

328

Chapter 13: SOCKS Gateway Configuration
Section A: Configuring a SOCKS Gateway

Note: SOCKS gateway aliases cannot be CPL keywords, such as no,
default, forward,

or socks_gateways.

b. Host: Add the IP address or the host name of the gateway where traffic
is directed. The host name must DNS resolve.
c. Port: The default is 1080.
d. SOCKS version: Select the version that the SOCKS gateway can support
from the drop-down list. Version 5 is recommended.
e. Username (Optional, and only if you use version 5) The username of the
user on the SOCKS gateway. The username already must exist on the
gateway. If you have a username, you must also set the password.
f.

Set Password:

The plaintext password or encrypted password of the
user on the SOCKS gateway. The password must match the gateway’s
information. The password can be up to 64 bytes long. Passwords that
include spaces must be within quotes.
You can enter an encrypted password (up to 64 bytes long) either through
the CLI or through installable list directives.

g. In the Load Balancing and Host Affinity section, select the load balancing
method from the drop-down list. Global default (configured on the
Configuration > Forwarding > Global Defaults tab), sets the default for all
SOCKS gateways on the system. You can also specify the load
balancing method for this system: Least Connections or Round Robin, or
you can disable load balancing by selecting None.
h. In the Host affinity methods drop-down list, select the method you want
to use:


HTTP: The default is to use the Global Defaults. Other choices are None,
which disables host affinity, Accelerator Cookie, which places a cookie in
the response to the client, and Client IP Address, which uses the client
IP address to determine which upstream SOCKS gateway was last
used.

By default, SOCKS treats all incoming requests destined to port 80 as
HTTP, allowing the usual HTTP policy to be performed on them,
including ICAP scanning. If the SOCKS connection is being made to a
server on another port, write policy on the ProxySG to match on the
server host and port and specify that it is HTTP using SOCKS.


SSL:

The default is to use the Global Defaults. Other choices are None,
which disables host affinity, Accelerator Cookie, which places a cookie in
the response to the client, and Client IP Address, which uses the client IP
address to determine which group member was last used. In addition,
you can select SSL Session ID, used in place of a cookie or IP address,
which extracts the SSL session ID name from the connection
information.

329

Volume 5: Advanced Networking
Section A: Configuring a SOCKS Gateway



Other. Other

applies to any traffic that is not HTTP, terminated HTTPS,
or intercepted HTTPS. You can attempt load balancing of any of the
supported traffic types in forwarding and this host affinity setting can
be applied as well. For example, you could load balance a set of TCP
tunnels and apply the Other host affinity (client IP only).

The default is to use Global Defaults. Other choices are None, which
disables host affinity, and Client IP Address, which uses the client IP
address to determine which group member was last used.
i.

Click OK to close the dialog.

4. Click Apply.
To create groups:

An existing gateway can belong to none, one, or more groups as desired (it can
only belong once to a single group, however).
1. Select Configuration > Forwarding > SOCKS Gateways > SOCKS Gateway Groups.
2. Click New. The Add SOCKS Gateway Group dialog displays.

330

Chapter 13: SOCKS Gateway Configuration
Section A: Configuring a SOCKS Gateway

3. To create an alias group, highlight the hosts and groups you want grouped,
and click Add.
4. Give the new group a meaningful name.
5. In the Load Balancing and Host Affinity section, select the load balancing method
from the drop-down list. Global default (configured on the Configuration >
Forwarding > SOCKS Gateways > Global Defaults tab), sets the default for all
forwarding hosts on the system. You can also specify the load balancing
method for this system: Least Connections, Round Robin, Domain Hash, URL Hash,
or you can disable load balancing by selecting None.
6. In the Host affinity methods drop-down lists, select the method you want to use.
Refer to the previous procedure for details on methods.You are selecting
between the resolved IP addresses of all of the hosts in the group, not the
resolved IP addresses of an individual host.


HTTP: The default is to use the Global Defaults. Other choices are None, which
disables host affinity, Accelerator Cookie, which places a cookie in the
response to the client, and Client IP Address, which uses the client IP

address to determine which group member was last used.

331

Volume 5: Advanced Networking
Section A: Configuring a SOCKS Gateway



SSL:

The default is to use the Global Defaults. Other choices are None, which
disables host affinity, Accelerator Cookie, which places a cookie in the
response to the client, and Client IP Address, which uses the client IP
address to determine which group member was last used. In addition, you
can select SSL Session ID, used in place of a cookie or IP address, which
extracts the SSL session ID name from the connection information.



Other.

Applies to any traffic that is not HTTP, terminated HTTPS, or
intercepted HTTPS. You can attempt load balancing of any of the
supported traffic types in forwarding and this host affinity setting can be
applied as well. For example, you could load balance a set of TCP tunnels
and apply the Other host affinity (client IP only).

The default is to use Global Defaults. Other choices are None, which disables
host affinity, and Client IP Address, which uses the client IP address to
determine which group member was last used.
7. Click OK to close the dialog.
8. Click Apply.

Configuring Global SOCKS Defaults
The global defaults apply to all SOCKS gateways hosts and groups unless the
settings are specifically overwritten during host or group configuration.
To configure global defaults:

1. Select Configuration > Forwarding > SOCKS Gateways > Global Defaults.

2. Determine how you want connections to behave if the health checks fail:
Connect Directly (fail open) or Deny the request (fail closed). Note that failing open is
an insecure option. The default is to fail closed. This option can be overridden
by policy, if it exists.
3. In the Global Load Balancing and Host Affinity area:
a. Configure Load Balancing methods:

332

Chapter 13: SOCKS Gateway Configuration
Section A: Configuring a SOCKS Gateway



SOCKS hosts: Specify the load balancing method for all forwarding
hosts unless their configuration specifically overwrites the global
settings. You can choose Least Connections or Round Robin, or you can
disable load balancing by selecting None. Round Robin is specified by
default.



SOCKS groups:

Specify the load balancing method for all forwarding
groups unless their configuration specifically overwrites the global
settings. You can choose to hash the domain or the full URL. You can
also choose Least Connections, Round Robin, Domain Hash, URL Hash, and
you can disable load balancing by selecting None. Round Robin is
specified by default.

b. Configure Global Host Affinity methods:


HTTP: The default is to use None, which disables host affinity. Other
choices are Accelerator Cookie, which places a cookie in the response to
the client, and Client IP Address, which uses the client IP address to
determine which group member was last used.



SSL:



Other: Other applies to any traffic that is not HTTP, terminated HTTPS,
or intercepted HTTPS. You can attempt load balancing of any of the
supported traffic types in forwarding and this host affinity setting can
be applied as well. For example, you could load balance a set of TCP
tunnels and apply the Other host affinity (client IP only).

The default is to use None, which disables host affinity. Other
choices are Accelerator Cookie, which places a cookie in the response to
the client, and Client IP Address, which uses the client IP address to
determine which group member was last used, and SSL Session ID,
used in place of a cookie or IP address, which extracts the SSL session
ID name from the connection information.

The default is to use None, which disables host affinity. You can also
choose Client IP Address, which uses the client IP address to determine
which group member was last used.
c. Host Affinity Timeout: This is the amount of time a user's IP address, SSL
ID, or cookie remains valid. The default is 30 minutes, meaning that
the IP address, SSL ID or cookie must be used once every 30 minutes to
restart the timeout period.
4. Click Apply.

Configuring the Default Sequence
The default sequence defines what SOCKS gateways to use when no policy is
present to specify something different. The system uses the first host or group in
the sequence that is healthy, just as it does when a sequence is specified through
policy. Only one default sequence is allowed. All members must be pre-existing
hosts, and no member can be in the group more than once.

333

Volume 5: Advanced Networking
Section A: Configuring a SOCKS Gateway

A default failover sequence allow healthy hosts to take over for an unhealthy host
(one that is failing its DNS Resolution or its health check). The sequence specifies
the order of failover, with the second host taking over for the first host, the third
taking over for the second, and so on.
If all hosts are unhealthy, the operation fails either open or closed, depending
upon your settings.
This configuration is usually created and managed through policy. If no SOCKSgateways policy applies, you can create a default sequence through the CLI. This
single default sequence consists of a single default host (or group) plus one or
more hosts to use if the preceding ones are unhealthy.
To create the default sequence:
Note: Traffic is forwarded to the first member of the list until it fails, then traffic is
sent to the second member of list until it fails or the first member becomes healthy
again, and so on.

1. Select Configuration > Forwarding > SOCKS Gateways > Default Sequence.

2. The available aliases (host and group) display in the Available Aliases pane. To
select an alias, highlight it and click Add.
Note: Any host or group in the default sequence is considered in use by
policy. As a result, if you try to delete a host or group while it is in the default
sequence, you receive an error message. You must remove the host/group
from the sequence first, then delete the host or group.

3. You can use the Promote and Demote buttons to change the order of the hosts
and groups in the sequence after you add them to the Selected Aliases pane.
4. Click Apply.

Related CLI Syntax to Configure SOCKS Gateways
SGOS#(config) socks-gateways
SGOS#(config socks-gateways) create gateway gateway_alias gateway_host
SOCKS_port [group=group-alias] [version {=4 | =5}] [user=username
{password=password | encrypted-password=encrypted-password}]

334

Chapter 13: SOCKS Gateway Configuration
Section A: Configuring a SOCKS Gateway
SGOS#(config
SGOS#(config
SGOS#(config
SGOS#(config
SGOS#(config
SGOS#(config

socks-gateways)
socks-gateways)
socks-gateways)
socks-gateways)
socks-gateways)
socks-gateways)

create group group_name
delete all
delete gateway gateway_alias
delete group group_name
destroy-old-passwords
edit gateway_alias

SGOS#(config socks-gateways gateway_alias) encrypted-password
encrypted_password
SGOS#(config socks-gateways gateway_alias) host gateway_host
SGOS#(config socks-gateways gateway_alias) host-affinity http
{default | none | client-ip-address | accelerator-cookie}
SGOS#(config socks-gateways gateway_alias) host-affinity ssl
{default | none | client-ip-address | accelerator-cookie | sslsession-id}
SGOS#(config socks-gateways gateway_alias) host-affinity other
{default | none | client-ip-address}
SGOS#(config socks-gateways gateway_alias) load-balance method
{default | least-connections | none | round-robin}
SGOS#(config socks-gateways gateway_alias) no {password | user}
SGOS#(config socks-gateways gateway_alias) password password
SGOS#(config socks-gateways gateway_alias) port socks_port
SGOS#(config socks-gateways gateway_alias) user username
SGOS#(config socks-gateways gateway_alias) version {4 | 5}
SGOS#(config socks-gateways gateway_alias) view
SGOS#(config socks-gateways) edit group_alias
SGOS#(config socks-gateways group_alias) {add | remove}
gateway_alias
SGOS#(config socks-gateways group_alias) host-affinity http
{default | none | client-ip-address | accelerator-cookie}
SGOS#(config socks-gateways group_alias) host-affinity ssl {default
| none | client-ip-address | accelerator-cookie | ssl-session-id}
SGOS#(config socks-gateways group_alias) host-affinity other
{default | none | client-ip-address}
SGOS#(config socks-gateways group_alias) load-balance method
{default | domain-hash | least-connections | none | round-robin |
url-hash}
SGOS#(config socks-gateways group_alias) view
SGOS#(config socks-gateways) exit
SGOS#(config socks-gateways) failure-mode {open | closed}
SGOS#(config socks-gateways) host-affinity http {default | none |
client-ip-address | accelerator-cookie} gateway_or_group_alias
-orSGOS#(config socks-gateways) host-affinity ssl {default | none |
client-ip-address | accelerator-cookie | ssl-session-id}
gateway_or_group_alias
-orSGOS#(config socks-gateways) host-affinity other {default | client-ipaddress | none} gateway_or_group_alias
SGOS#(config socks-gateways) load-balance gateway {default | none |
round-robin | least-connections} gateway_alias
SGOS#(config socks-gateways) load-balance group {default | none |
domain-hash | url-hash | round-robin | least-connections} group_alias
SGOS#(config socks-gateways) no path

335

Volume 5: Advanced Networking
Section A: Configuring a SOCKS Gateway
SGOS#(config socks-gateways)
SGOS#(config socks-gateways)
remove} gateway-alias
SGOS#(config socks-gateways)
SGOS#(config socks-gateways)

path url
sequence {add | demote | promote |
sequence clear
view

Statistics
SOCKS gateways statistics are available through the Statistics > Advanced > SOCKS
item.

Gateways menu

336

Chapter 13: SOCKS Gateway Configuration
Section B: Using SOCKS Gateways Directives with Installable Lists

Section B: Using SOCKS Gateways Directives with Installable Lists
To configure a SOCKS gateway, you can use the Management Console (easiest),
the CLI, or you can create an installable list and load it on the ProxySG. To use the
Management Console, see Section A: "Configuring a SOCKS Gateway" on page
328. For information on installing the file itself, see "Creating a SOCKS Gateway
Installable List" on page 342.
The SOCKS gateways configuration includes SOCKS directives that:


Names the SOCKS gateways, version, and port number



Creates the SOCKS gateways groups



Provide load balancing and host affinity



Specifies the username



Specifies the password

Available directives are described in the table below.
Table 13–1 SOCKS Directives

Directive

Meaning

gateway

Specifies the gateway alias and name, SOCKS port, version
supported, usernames and password.

group

Creates a forwarding group directive and identifies member of
the group.

host_affinity

Directs multiple connections by a single user to the same group
member.

load_balance

Manages the load among SOCKS gateways in a group, or
among multiple IP addresses of a gateway.

sequence
alias_list

Adds a space-separated list of one or more SOCKS gateways
and group aliases. (The default sequence is the default
forwarding rule, used for all requests lacking policy instructions

socks_fail

In case connections cannot be made, specifies whether to abort
the connection attempt or to connect to the origin content server.

Syntax for the SOCKS directives are:
gateway gateway_alias gateway_name SOCKS_port [group=group_alias]
[version={4 | 5}] [user=username] [password=password] [encryptedpassword=encrypted_password]
group=group_alias [gateway_alias_list]
host_affinity http {none | client-ip-address | accelerator-cookie}
[gateway_or_group_alias]
host_affinity ssl {none | client-ip-address | accelerator-cookie |
ssl-session-id} [gateway_or_group_alias]
host_affinity other {none | client-ip-address}
[gateway_or_group_alias]
host_affinity timeout minutes

337

Volume 5: Advanced Networking
Section B: Using SOCKS Gateways Directives with Installable Lists
load_balance group {none | domain-hash | url-hash | round-robin |
least-connections} [group_alias]
load_balance gateway {none | round-robin | least-connections}
[gateway_alias]
sequence alias_list
socks_fail {open | closed}

For more information on SOCKS gateway directives, continue with the next
section. For information on:
directives, continue with "Creating SOCKS Gateways Groups Using
Directives" on page 339



group



load_balance



host_affinity



socks_fail



sequence

directives, continue with "Configuring Load Balancing
Directives" on page 339

directives, continue with "Configuring Host Affinity
Directives" on page 340
directives, continue with "Setting Fail Open/Closed" on page 339

directives, continue with "Creating a Default Sequence" on page 341

Configuring SOCKS Gateways Using Directives
SOCKS gateways can be configured using the gateways suboptions in the table
below.
Table 13–2 SOCKS Gateways Syntax

Command

Suboptions

gateway

338

Description
Configures the SOCKS gateway.

gateway_alias

A meaningful name that is used for policy rules.

gateway_name

The IP address or name of the gateway where
traffic is directed. The gateway name must DNS
resolve.

SOCKS_port

The port number of the SOCKS gateway.

version={4 | 5}

The version that the SOCKS gateway can
support.

user=username

(Optional, if you use v5) The username of the
user. It already must exist on the gateway.

password=password

(Optional, if you use v5) The password of the
user on the SOCKS gateway. It must match the
gateway’s information.

encryptedpassword=encrypted_
password

(Optional, if you use v5) The encrypted
password of the user on the SOCKS gateway. It
must match the gateway’s information.

Chapter 13: SOCKS Gateway Configuration
Section B: Using SOCKS Gateways Directives with Installable Lists

Example
gateway Sec_App1 10.25.36.47 1022 version=5 user=username
password=password

Creating SOCKS Gateways Groups Using Directives
The SOCKS gateway groups directive has the following syntax:
group group_name gateway_alias_1 gateway_alias_2...

where group_name is the name of the group, and gateway_alias_1,
gateway_alias_2, and so forth are the gateways you are assigning to the SOCKS
gateways group.

Setting Special Parameters
After you configure the SOCKS gateways and groups, you might need to set other
special parameters to fine tune gateways. You can configure the following
settings:


"Setting Fail Open/Closed"



"Configuring Load Balancing Directives" on page 339



"Configuring Host Affinity Directives" on page 340

Setting Fail Open/Closed
Using directives, you can determine if the SOCKS gateways fails open or closed or
if an operation does not succeed.
The syntax is:
socks_fail {open | closed}

where the value determines whether the SOCKS gateways should fail open or
fail closed if an operation does not succeed. Fail open is a security risk, and
fail closed is the default if no setting is specified. This setting can be
overridden by policy, using the SOCKS_gateway.fail_open(yes|no) property.

Examples
socks_fail open

Configuring Load Balancing Directives
Load balancing shares the load among a set of IP addresses, whether a group or a
gateway with multiple IP addresses.
The syntax is:
load_balance group {none | domain-hash | url-hash | round-robin |
least-connections} [group_alias]
load_balance gateway {none | round-robin | least-connections}
[gateway_alias]

339

Volume 5: Advanced Networking
Section B: Using SOCKS Gateways Directives with Installable Lists
Table 13–3 Load Balancing Directives

Command

Suboptions

Description

load_balance
group

{none | domain-hash | urlhash | round-robin |
least-connections}
[group_alias]

If you use group for load balancing,
you can set the suboption to none or
choose another method. If you do
not specify a group, the settings
apply as the default for all groups.

load_balance
gateway

{none | round-robin |
least-connections}
[gateway_alias]

If you use gateway for load
balancing, you can set the suboption
to none or choose another method.
If you do not specify a gateway, the
settings apply as the default for all
gateways.

Example
load_balance gateway least_connections

Configuring Host Affinity Directives
Host affinity is the attempt to direct multiple connections by a single user to the
same group member.
The syntax is:
host_affinity http {none | client-ip-address | accelerator-cookie}
[gateway_or_group_alias]
host_affinity ssl {none | client-ip-address | accelerator-cookie |
ssl-session-id} [gateway_or_group_alias]
host_affinity other {none | client-ip-address}
[gateway_or_group_alias]
host_affinity timeout minutes
Table 13–4 Commands to Configure Host Affinity Directives

340

Command

Suboption

Description

host_affinity
http

{accelerator-cookie |
client-ip-address | none}
[gateway_or_group_alias]

Determines which HTTP hostaffinity method to use
(accelerator cookie or clientip-address), or you can specify
none. If you do not specify a
gateway or group, the settings
apply as the default for all gateways
or groups.

Chapter 13: SOCKS Gateway Configuration
Section B: Using SOCKS Gateways Directives with Installable Lists
Table 13–4 Commands to Configure Host Affinity Directives (Continued)

Command

Suboption

Description

host_affinity
ssl

{accelerator-cookie |
client-ip-address | none
| ssl-session-id}
[gateway_or_group_alias]

Determines which SSL host-affinity
method to use (accelerator
cookie, client-ip-address, or
ssl-session-id), or you can
specify none. If you do not specify a
gateway or group, the settings
apply as the default for all gateways
or groups.

host_affinity
other

other {none | client-ipaddress}
[gateway_or_group_alias]

Determines whether TCP tunnel
and Telnet is used. Determines
whether to use the client-ipaddress host-affinity method or
specify none. If you do not specify a
gateway or group, the settings
apply as the default for all gateways
or groups.

host_affinity
timeout

minutes

Determines how long a user's IP
address, SSL ID, or cookie remains
valid when idle.

Example
host_affinity ssl accelerator-cookie 10.25.36.48
host_affinity timeout 5

Creating a Default Sequence
The default sequence is the default SOCKS gateways rule, used for all requests
lacking policy instructions. Failover is supported if the sequence (only one is
allowed) has more than one member.
Note: Creating the default sequence through the CLI is a legacy feature. You can
set up sequences by using policy alone. The default sequence (if present) is
applied only if no applicable command is in policy.

For information on using VPM, refer to Volume 6: The Visual Policy Manager and
Advanced Policy; for information on using CPL, refer to Volume 10: Content Policy
Language Guide.
A default failover sequence works by allowing healthy SOCKS gateways to take
over for an unhealthy gateway (one that is failing its DNS resolution or its health
check). The sequence specifies the order of failover, with the second gateway
taking over for the first gateway, the third taking over for the second, and so on).
If all gateways are unhealthy, the operation fails either open or closed, depending
upon your settings.

341

Volume 5: Advanced Networking
This configuration is generally created and managed through policy. If no
forwarding policy applies, you can create a default sequence through the CLI.
This single default sequence consists of a single default gateway (or group) plus
one or more gateways to use if the preceding ones are unhealthy.
The syntax is:
sequence alias_list

where alias_list is a space-separated list of one or more SOCKS gateways
and group aliases.

Example
sequence gateway_alias

Creating a SOCKS Gateway Installable List
You can create and install the SOCKS gateway installable list with the following
methods:


Use the Text Editor, which allows you to enter directives (or copy and paste
the contents of an already-created file) directly onto the ProxySG.



Create a local file on your local system; the ProxySG can browse to the file and
install it.



Use a remote URL, where you place an already-created file on an FTP or
HTTP server to be downloaded to the ProxySG appliance.

When the SOCKS gateway installable list is created, it overwrites any previous
SOCKS gateway configurations on the ProxySG. The installable list remains in
effect until it is overwritten by another installable list; it can be modified or
overwritten using Management Console or CLI commands.
Note: During the time that a SOCKS gateways installable list is being compiled
and installed, SOCKS gateways might not be available. Any transactions that
come into the appliance during this time might not be forwarded properly.

Installation of SOCKS gateways installable-list configuration should be done
outside peak traffic times.
To create a SOCKS gateway installable list:

1. Select Configuration > Forwarding > SOCKS Gateways > Install SOCKS Gateway File.
2. If you use a SOCKS gateway server for the primary or alternate forwarding
gateway, you must specify the ID for the Identification (Ident) protocol used
by the SOCKS gateway in SOCKS server handshakes. The default is BLUECOAT
SYSTEMS.

3. From the drop-down list, select the method used to install the SOCKS
gateway configuration; click Install.

342

Chapter 13: SOCKS Gateway Configuration



Remote URL:

Enter the fully-qualified URL, including the filename, where the
configuration is located. To view the file before installing it, click View.
Click Install. Examine the installation status that displays; click OK.


Local File:

Click Browse to bring up the Local File Browse window. Browse for the file
on the local system. Click Install. When the installation is complete, a
results window opens. View the results, close the window, click Close.


Text Editor:

The current configuration is displayed in installable list format. You can
customize it or delete it and create your own. Click Install. When the
installation is complete, a results window opens. View the results, close
the window, click Close.
4. Click Apply.

Related CLI Syntax to specify the SOCKS Gateway Machine ID
SGOS#(config) socks-machine-id machine_ID

343

Volume 5: Advanced Networking

344

Chapter 14: Verifying the Health of Services Configured on
the ProxySG

This chapter discusses Blue Coat health checks, which enable you to determine
the availability of external networking devices and off-box services.

Topics in this Chapter
This chapter includes information about the following topics:


Section A: "Overview" on page 346



Section B: "About Blue Coat Health Check Components" on page 349



Section C: "Configuring Global Defaults" on page 355



Section D: "Forwarding Host and SOCKS Gateways Health Checks" on
page 366



Section E: "DNS Server Health Checks" on page 373



Section F: "Authentication Health Checks" on page 377



Section G: "Virus Scanning and Content Filtering Health Checks" on page
380



Section H: "Managing User-Defined Health Checks" on page 386



Section I: "Viewing Health Check Statistics" on page 397



Section J: "Using Policy" on page 403



Section K: "Related CLI Syntax to Configure Health Checks" on page 404

345

Volume 5: Advanced Networking
Section A: Overview

Section A: Overview
The ProxySG performs health checks to test for network connectivity and to
determine the responsiveness of external resources. Examples of external
resources include — DNS servers, forwarding hosts, SOCKS gateways,
authentication servers, ICAP services (for example, anti-virus scanning services),
and Websense off-box services.
The ProxySG automatically generates health checks based on:


Forwarding configuration



SOCKS gateways configuration



DNS server configuration



ICAP service configuration



Websense off-box configuration



Authentication realm configuration



Whether Dynamic Real-Time Rating (DRTR) is enabled

You also can create user-defined health checks, including a composite health
check that combines the results of multiple other health check tests. For
information on health check types, see Section B: "About Blue Coat Health Check
Components" on page 349.
Health checks fall into three broad categories:






346

Determining if the IP address can be reached. Health check types that fall into
this category are:


Forwarding hosts



SOCKS gateways



User-defined host health checks

Determining if a service is responsive. Health check types that fall into this
category are:


Authentication servers



DNS server



Dynamic Real-Time Rating (DRTR) service



ICAP services



Websense off-box services

Determining if a group is healthy. Group tests are compilations of individual
health checks, and the health of the group is determined by the status of the
group members. Health check types that fall into this category are:


Forwarding groups



SOCKS gateway groups

Chapter 14: Verifying the Health of Services Configured on the ProxySG
Section A: Overview



ICAP service groups



Websense off-box service groups



User-defined composite health checks

Information provided by health checks allows you to accomplish the following:


Detect potential network issues before they become critical. For example, if
the health check for an individual host fails, the ProxySG sends an alert (using
e-mail, SNMP, or by writing to an event log) to the designated recipients, if
configured. To configure recipients, see Section C: "Configuring Global
Defaults" on page 361.



Track response times and report failures. For example, if the DNS server
performance suffers a reduction, the users experience response time delays.
The DNS health check records the average response time (in milliseconds) and
allows you to interpret the reason for the performance reduction. Should the
DNS server become unavailable, the failed health check triggers an alert.

Furthermore, the ProxySG uses health check information to accomplish the
following:


When combined with failover configurations, health checks redirect traffic
when a device or service failure occurs. For example, a health check detects an
unhealthy server and a forwarding rule redirects traffic to a healthy server or
proxy.



Monitor the impact of health check states on the overall health of the
appliance. Health check status is a metric in calculating the overall health of
the ProxySG and is reflected in the health monitor, which is located at the
upper right hand corner of the Management Console. For example, if a health
check fails, the health monitor displays Health: Warning. You can click on the
health monitor link to navigate and view the cause for the warning.

Executing an instant health check
Although the ProxySG automatically executes health checks, you can run an
instant health check from the Configuration > Health Checks > General > Health Checks
tab by selecting the health check and clicking Perform health check. You can also
view the health check state on the Statistics > Health Check tab.

Background DNS Resolution
Background testing of the DNS resolutions is done on all resolvable hostnames
used in the health check system, including forwarding hosts, DRTR, and SOCKS
gateways. That way, the list of IP addresses associated with a hostname stays
current. The DNS system is checked whenever the time-to-live (TTL) value of the
DNS entry expires.
Note: If a hostname consists of a dotted IP address, no DNS resolution is
performed.

347

Volume 5: Advanced Networking
Section A: Overview

When a host is resolved by DNS to multiple IP addresses, health checks keep
those addresses current through background updates. You can configure the
timing for the updates on the Configuration > Health Checks > Background DNS tab.
After the test or tests are conducted for each IP address, the results are combined.
If the result for any of the resolved IP addresses is healthy, then the host is
considered healthy because a healthy connection to that target can be made.

348

Chapter 14: Verifying the Health of Services Configured on the ProxySG
Section B: About Blue Coat Health Check Components

Section B: About Blue Coat Health Check Components
Health checks have two components:




Health check type: The kind of device or service the specific health check tests.
The following types are supported:


Forwarding host and forwarding group



SOCKS gateway and SOCKS gateway group



DNS servers



External Authentication servers



ICAP service and ICAP service group



Websense off-box service and Websense off-box service group



Dynamic Real-Time Rating Service



User-defined host and composite health checks

Health check tests: The method of determining network connectivity, target
responsiveness, and basic functionality.




Health checks (external targets)


Authentication



Internet Control Message Protocol (ICMP)



DNS



TCP



SSL



HTTP



HTTPS



ICAP



Websense



DRTR

Health checks (group targets)


Groups



Composite

Note: Some health checks (such as forwarding hosts and SOCKS

gateways) can be configured to report the result of a composite health
check instead of their own test.

349

Volume 5: Advanced Networking
Section B: About Blue Coat Health Check Components

Some health check types only have one matching test, while others have a
selection. For more information about health check types and tests, see Table 14–1
on page 351.

Health Check Types
Most health checks are automatically created and deleted when the underlying
entity being checked is created or deleted. When a forwarding host is created, for
example, a health check for that host is created. Later, if the forwarding host is
deleted, the health check for it is deleted as well. User interaction is not required,
except to change or customize the health check behavior if necessary. However, if
a health-check is referenced in policy, you cannot delete the corresponding host or
the health check itself until the reference in policy is deleted.
In addition to the health checks that are automatically generated, run, and
deleted, Blue Coat also supports two kinds of user-defined health checks. These
health checks are manually created, configured, and deleted.


Composite health checks: A method to take the results from a set of health
checks (automatically generated or user-defined health checks) and combine
the results.



Host health checks: A method to test a server, using a selection of ICMP, TCP,
SSL, HTTP, and HTTPS tests.
Note: Although a host health check tests an upstream server, it can also be
used to test whether a proxy is working correctly. To test HTTP/HTTPS
proxy behavior, for example, you can set up a host beyond the proxy, and
then use forwarding rules so the health check passes through the proxy to the
host, allowing the proxy to be tested.

User-defined health checks allow you to test for attributes that the ProxySG does
not test automatically. For example, for a forwarding host, you could perform
three user-defined tests — an HTTP test, an HTTPS test, and a TCP test of other
ports. Then, you can set up a composite health check that combines the results of
these user-defined tests to represent the health of the forwarding host. The
ProxySG reports the status of the (user-defined) composite health check as the
forwarding host's health, instead of the default forwarding host health check.
All health check types are given standardized names, based on the name of the
target. For example:

350



Forwarding hosts and groups have a prefix of fwd



DNS servers have a prefix of dns



SOCKS gateways and gateway groups have a prefix of socks



Authentication realms have a prefix of auth



External services have prefixes of icap, ws, and drtr



User-defined or composite health checks have a prefix of user

Chapter 14: Verifying the Health of Services Configured on the ProxySG
Section B: About Blue Coat Health Check Components

Health Check Tests
Based on the health check type, the ProxySG periodically tests the health status,
and thus the availability of the host. You can configure the time interval between
tests. If the health check test is successful, the appliance considers the host
available.
The health check tests are described in the table below.
Table 14–1 Health Check Tests

Health Check
Test

Description

Used With
Health Check
Type

Response Times

The minimum, maximum, and average
response times are tracked, with their values
being cleared whenever the health check
changes state.

All

ICMP Test (Layer
3)

The basic connection between the ProxySG and
the origin server is confirmed. The server must
recognize ICMP echoing, and any intervening
networking equipment must support ICMP.
The ProxySG appliance sends a ping (three
ICMP echo requests) to the host.

Forwarding
hosts, SOCKS
gateways, or
user-defined
hosts

ICMP tests do not support policy for SOCKS
gateways or forwarding.
TCP Socket
Connection Test
(Layer 4)

A TCP test establishes that a TCP layer
connection can be established to a port on the
host. Then the connection is dropped.
TCP tests for a SOCKS gateway do not support
policy for SOCKS gateways or forwarding.

Forwarding
hosts, SOCKS
gateways, or
user-defined
hosts

TCP tests for a forwarding host or a userdefined health check support SOCKS gateways
policy but not forwarding policy.
SSL Test

A connection is made to a target and the full
SSL handshake is conducted. Then, much like
the TCP test, the connection is dropped.

Forwarding
hosts or userdefined hosts

For a forwarding host, a terminating HTTPS
port must be defined or the test fails.
SSL tests for a forwarding host or a userdefined health check support SOCKS gateways
policy. The SSL tests do not support forwarding
policy.
An SSL test executes the SSL layer in policy and
obeys any settings that apply to server-side
certificates, overriding any settings obtained
from a forwarding host.

351

Volume 5: Advanced Networking
Section B: About Blue Coat Health Check Components
Table 14–1 Health Check Tests (Continued)

Health Check
Test

Description

Used With
Health Check
Type

HTTP/HTTPS
Tests for Servers
and Proxies

HTTP/HTTPS tests execute differently
depending on whether the upstream target is a
server or a proxy. For a forwarding host, the
server or a proxy is defined as part of the
forwarding host configuration. For a userdefined health check, the target is always
assumed to be a server.

Forwarding
hosts or userdefined hosts.

For a server:
• The HTTP test sends an HTTP GET request
containing only the URL path to an HTTP
port.
• The HTTPS test sends an HTTPS GET request
containing only the URL path over an SSL
connection to a terminating HTTPS port.
If an appropriate port is not available on the
target, the test fails.
For a proxy:
• The HTTP test sends an HTTP GET request
containing the full URL to an HTTP port.
• Since a server is required to terminate
HTTPS, the HTTPS test sends an HTTP
CONNECT request to the HTTP port.
If an appropriate HTTP port is not available on
the proxy, either test fails.
An HTTP/HTTPS test requires a full URL for
configuration.
The HTTP/HTTPS tests for a forwarding host
support SOCKS gateway policy but not
forwarding policy.
The HTTP/HTTPS tests for a user-defined
health check support SOCKS gateway and
forwarding policy.
An HTTPS test executes the SSL layer in policy
and obeys any settings that apply to server-side
certificates, overriding any settings obtained
from a forwarding host.
HTTP/HTTPS
Authentication

352

For HTTP/HTTPS tests, you can test
authentication using a configured username
and password. The passwords are stored
securely in the registry.

Forwarding
hosts or userdefined hosts.

Chapter 14: Verifying the Health of Services Configured on the ProxySG
Section B: About Blue Coat Health Check Components
Table 14–1 Health Check Tests (Continued)

Health Check
Test

Description

Used With
Health Check
Type

HTTP/HTTPS
Allowed
Responses

For an HTTP or HTTPS test, this is the set of
HTTP response codes that indicate success. The
default is to accept only a 200 response as
successful. You can specify the sets of response
codes to be considered successful.

Forwarding
hosts or userdefined hosts.

External Services
Tests

The tests for external services are specialized
tests devised for each particular kind of external
service. The health check system conducts
external service tests by sending requests to the
external services system, which reports back a
health check result.

ICAP, Websense
off-box, DRTR
service.

Group

Individual tests that are combined for any of the
four different available groups (forwarding,
SOCKS gateways, ICAP services, and Websense
off-box). If any of the members is healthy, then
the group as a whole is considered healthy.

Forwarding
groups, SOCKS
gateways
groups, and
ICAP and
Websense offbox external
service groups.

Note: Blue Coat supports a composite test,
used only with composite (user-defined)
health checks, that is similar to a group test
except that, by default, all members must be
healthy for the result to be healthy.
These settings are configurable.
By default, group health tests are used for two
purposes:
• Monitoring and notification
• Policy
DNS Server

The DNS server maps the hostname, default is
www.bluecoat.com, to an IP address. The health
check is successful if the hostname can be
resolved to an IP address by the DNS server.

DNS

Authentication

Authentication health checks assess the realm’s
health using data maintained by the realm
during active use. Authentication health checks
do not probe the authentication server with an
authentication request.

Authentication

See Also:


"To edit forwarding and SOCKS gateways health checks:" on page 367



"To edit forwarding or SOCKS gateway group health checks:" on page 369



"To edit a DNS server health check:" on page 373

353

Volume 5: Advanced Networking
Section B: About Blue Coat Health Check Components

354



"To edit an authentication health check:" on page 377



"To edit virus scanning and content filtering tests:" on page 380



"To edit Websense off-box or ICAP group tests:" on page 383



"To create a user-defined host health check:" on page 388



"To create a user-defined composite health check:" on page 392

Chapter 14: Verifying the Health of Services Configured on the ProxySG
Section C: Configuring Global Defaults

Section C: Configuring Global Defaults
In general, all health checks are initially configured to use global defaults.
Note: The DRTR service is initially configured to override two of the default

settings. The healthy interval is set to 10800 seconds (3 hours), and a failure
trigger is set to 1.

About Health Check Defaults
You can change the defaults on most health checks. These defaults override global
defaults, which are set from the Configuration > Health Checks > General > Default
Settings tab.
You can edit health check intervals, severity, thresholds, and notifications for
automatically generated health checks in two ways:


Setting the global defaults. These settings affect all health checks, unless
overridden by explicit settings.



Setting explicit values on each health check.

The default health check values are:


Ten seconds for healthy and sick intervals (an interval is the period between
the completion of one health check and the start of the next health check).



One for healthy and sick thresholds. A healthy threshold is the number of
successful health checks before an entry is considered healthy; a sick threshold
is the number of unsuccessful health checks before an entry is considered sick.



Warning for the severity notification, which governs the effect that a health
check has on the overall health status of the ProxySG.



Disabled for logging health check status using e-mails, event logs, or SNMP
traps.

To configure the settings, continue with "Changing Health Check Default
Settings" on page 357. To configure notifications, continue with "Configuring
Health Check Notifications" on page 361.

Enabling and Disabling Health Checks
You can enable or disable health checks and configure them to report as healthy or
unhealthy during the time they are disabled.
Setting a health check as disabled but reporting healthy allows the ProxySG to use
the device or service without performing health checks on it. If, for example, you
have configured a forwarding host on the ProxySG, a health check for the
forwarding host is automatically created. If you then configure the health check as
disabled reporting healthy, the ProxySG considers the forwarding host as healthy
without performing periodic health checks on it.

355

Volume 5: Advanced Networking
Section C: Configuring Global Defaults

If the case of a group health check that is disabled but reporting healthy, all
members of the group are treated as healthy regardless of the status of the
members’ individual health checks.
Note: Individual health checks for members of a group remain active; they can be

used apart from the group.
Setting a health check as disabled but reporting sick is useful to remove an
upstream device for servicing, testing, or replacement. This setting takes the
device offline after it completes processing pre-existing traffic. Then the device
can be safely disconnected from the network without altering any other
configuration.
You cannot enable or disable all health checks at once.

Related CLI Syntax to Enable and to Disable a Health Check
#(config health-check) enable alias_name

Enables the health check.
{ healthy alias_name | sick alias_name }
Disables the specified health check and sets it to report healthy or unhealthy.

#(config health-check) disable

Notifications and SNMP Traps
If you configure notifications, the ProxySG sends all or any of e-mail, SNMP, and
event log notifications when a change of health check state occurs. By default, all
notifications are disabled.
On the ProxySG you can:


Globally change notifications for all health checks



Explicitly change notifications for specific health checks



Enable notifications of transitions to healthy



Enable notifications of transitions to unhealthy

A transition to healthy occurs as soon as the target is sufficiently healthy to be sent
a request, even though the target might not be completely healthy. For example, if
you have multiple IP addresses resolved and only one (or a few) is responsive, the
group is classified as healthy and the health status might be Ok with errors or Ok for
some IP’s. For some health check groups, like forwarding hosts, you can configure
a minimum number of members that must be healthy for the group to be healthy.
In the event log, status changes can be logged as either informational or severe
logs. In addition to the overall health of the device, you can enable notifications
for each resolved IP address of a target device (if applicable).
An SNMP trap can also be used for notification of health check state changes. It is
part of the Blue Coat Management Information Base (MIB) as blueCoatMgmt 7.2.1.
For information on configuring SNMP, see Volume 9: Managing the Blue Coat
ProxySG Appliance.

356

Chapter 14: Verifying the Health of Services Configured on the ProxySG
Section C: Configuring Global Defaults

Guidelines for Setting the Severity of a Health Check
Severity indicates how a failed health check affects the overall health of the
device. The severity option links Health Checks and Health Monitoring. The health
monitor displays the overall health of the device after considering the health
check status in conjunction with other health monitoring metrics. For information
on the health monitoring metrics, see Volume 9: Managing the Blue Coat ProxySG
Appliance.
Note: Severity of a health check is pertinent only when a health check fails.

The ProxySG allows you to configure the severity option to Critical, Warning and
No effect. Set the severity of a health check to:


Critical: If the success of a health check is crucial to the health of the device. If
the health check then reports unhealthy, the overall health status becomes
Critical.



Warning: If a failed health check implies an emerging issue and the
administrator must be alerted when the health check state transitions from
healthy to unhealthy. Consequently, when the health check reports unhealthy,
the overall health status transitions to Warning.



No effect: If the success of a health check bears no impact on the health of the
device. Should the health check transition to unhealthy, the overall health
status of the device retains its current status and does not change.

For example, if the severity on an external service health check for Websense—
ws.ws_1, is set to severity level Critical and the health check fails, the overall health
status of the device will transition to Health: Critical.
To change notifications, continue with "Configuring Health Check Notifications"
on page 361.

Changing Health Check Default Settings
You can modify the default settings for all health checks on the Configuration >
Health Checks > General > Default Settings tab or you can override the default settings
for a health check on the Configuration > Health Checks > General > Health Checks tab,
selecting the health check, and clicking Edit. Explicit health settings override the
global defaults.
To change the global default settings:
1. Select Configuration > Health Checks > General > Default Settings.

357

Volume 5: Advanced Networking
Section C: Configuring Global Defaults

2. Change the settings as appropriate:
a. Specify the healthy interval, in seconds, between health checks. The
default is 10. The healthy interval can be between 1 second and
31536000 seconds (about one year).
b. Specify the healthy threshold for the number of successful health
checks before an entry is considered healthy. Valid values can be
between 1 and 65535. The default is 1.
c. Specify the sick interval, in seconds, between health checks to the
server that has been determined to be unhealthy or out of service. The
default is 10. The sick interval can be between 1 second and 31536000
seconds (about 1 year).
d. Specify the sick threshold, or the number of failed health checks before
an entry is considered unhealthy. Valid values can be between 1 and
65535. The default is 1.
e. Specify the failure threshold for the number of failed connections to
the server before a health check is triggered. Valid values can be
between 1 and 2147483647. It is disabled by default.
The failures are reported back to the health check as a result of either a
connection failure or a response error. The number of these external
failures is cleared every time a health check is completed. If the number of
failures listed meets or exceeds the threshold and the health check is idle
and not actually executing, then the health of the device or service is
immediately checked.
f.

Specify the maximum response time threshold, in milliseconds. The
threshold time can be between 1 and 65535.

3. Click Apply.
To override default settings for a targeted health check:

1. Select Configuration > Health Checks > General > Health Checks.
2. Select the test you want to modify.
3. Click Edit. The example below uses a SOCKS gateway.

358

Volume 5: Advanced Networking
Section C: Configuring Global Defaults

an entry is considered unhealthy. Valid values are 1-65535. The default
is 1.
f.

Specify the failure trigger for the number of failed connections to the
server before a health check is triggered.Valid values are between 1
and 2147483647.
The failures are reported back to the health check as a result of either a
connection failure or a response error. The number of these external
failures is cleared every time a health check is completed. If the number of
failures listed meets or exceeds the threshold, and the health check is idle
and not actually executing, then the health of the device or service is
immediately checked.

g. Specify the maximum response time threshold, in milliseconds. The
threshold time can be between 1 and 65535.
h. Click OK to close the dialog.
5. Click Apply.

Related CLI Syntax to Modify Default Settings Globally
#(config health-check) default failure-trigger {none | count}

Configures defaults for the failure-trigger options.
#(config health-check) default interval {healthy seconds| sick
seconds}

Configures defaults for interval options.
#(config health-check) default threshold {healthy count | responsetime milliseconds | sick count}

Configures defaults for threshold options.

Related CLI Syntax to Modify Default Settings for a Targeted Health Check
#(config health-check) edit alias_name

Allows you to configure options for the specified health check.
#(config health-check alias_name) clear-statistics

Clears statistics for this health check.
#(config health-check alias_name) failure-trigger {default | none |
count}

Configures options for the failure-trigger.
#(config health-check alias_name) interval {healthy {default |
seconds}| sick {default | seconds}}

Configures intervals before the health check is re-run. The intervals can be
different for health checks that are reporting healthy and health checks that
are reporting sick.
#(config health-check alias_name) perform-health-check

Starts the health check immediately and reports the result.

360

Chapter 14: Verifying the Health of Services Configured on the ProxySG
Section C: Configuring Global Defaults
#(config health-check alias_name) threshold {healthy {default | count}
| response-time {default | none | milliseconds} | sick {default |
count}}

Sets the level when health checks will report healthy or sick.
#(config health-check alias_name) use-defaults

Resets the defaults of the health check to use the global defaults instead of any
explicitly set values.
#(config health-check alias_name) exit

Exits the health check editing mode.

Configuring Health Check Notifications
The ProxySG allows you to configure notifications that alert you to changes in
health status and to emerging issues. By default, notifications for health check
events and status are disabled.
You can set up health check notifications:


Globally on the Configuration > Health Checks > General > Default Notifications tab



Explicitly, for a health check, on the Configuration > Health Checks > General >
Health Checks tab, selecting the health check, and clicking Edit.
Explicit health settings override the global defaults.

To configure health check notifications globally:

1. Select Configuration > Health Checks > General > Default Notifications.
2. Select the Severity level for the health check.


Critical: If the health check fails, the device is in critical condition



Warning: If the health check fails, the device needs to be monitored and
the health check status displays as Warning. This is the default setting.



No effect: The health check has no impact on the overall health of the
device.

361

Volume 5: Advanced Networking
Section C: Configuring Global Defaults

3. Select the options to enable notifications:
a. E-mail notification: Select the appropriate check boxes to enable the email notifications you require. Recipients are specified in Maintenance >
Event Logging > Mail.
b. Event logging: Select the appropriate options to enable the event logging
you require. Messages can be logged as either informational or severe.
c. SNMP traps: Select the situations for which you require SNMP traps to
be sent.
4. Click Apply.
To override the default notifications for a targeted health check:

1. Select Configuration > Health Checks > General > Health Checks.
2. Select the test you want to modify.
3. Click Edit. The Edit dialog displays. The example below uses a forwarding
host.
4. To change default notifications for this test, click Override the default notifications.
By default, notifications are not sent for any health checks.

362

Chapter 14: Verifying the Health of Services Configured on the ProxySG
Section C: Configuring Global Defaults

5. Select the options to override. You can cancel your choices by clicking Clear all
overrides.
a. Severity: Select the severity option as required.


Critical: If the health check fails, the device is in critical condition



Warning: If the health check fails, the device needs to be monitored
and the health check status displays as Warning. This is the default
setting.

363

Volume 5: Advanced Networking
Section C: Configuring Global Defaults



No effect: The health check has no impact on the overall health of the
device.

b. Override E-mail notification: Select the appropriate check boxes to enable
the e-mail notifications you require. Specify recipients in Maintenance >
Event Logging > Mail.
c. Event logging: Select the appropriate check boxes to enable the event
logging you need. Messages can be logged as either informational or
severe.
d. SNMP traps: Select the situations in which you want SNMP traps to be
sent.
e. Click OK to close the override dialog
f.

Click OK to close the edit dialog.

6. Click Apply.

Related CLI Syntax to Modify Default Notifications Globally
#(config health-check) default e-mail {healthy {enable |disable} |
report-all-ips {enable|disable} | sick {enable|disable}}

Configures defaults for e-mail notifications.
#(config health-check) default event-log {healthy {disable
|information |severe} | report-all-ips {enable |disable} | sick
{disable |information |severe}}

Configures defaults for event-log notifications. An informational or a severe
event-log message is logged depending on the setting chosen.
#(config health-check) default snmp {healthy {enable |disable} |
report-all-ips {enable |disable} | sick {enable |disable}}

Configures defaults for snmp notifications.
#(config health-check) default severity {critical|no-effect|warning}

Configures default severity for all health checks.

Related CLI Syntax to Modify Default Notifications for a Targeted Health
Check
#(config health-check) edit alias_name

Allows you to configure options for the specified health check.
#(config health-check alias_name) severity {critical|no-effect|default
| warning}

Configures default severity for the health check.
#(config health-check alias_name) e-mail {healthy {enable |disable |
default} | report-all-ips {enable |disable |default} | sick {enable |
disable |default}}

Configures e-mail notifications for the health check.

364

Chapter 14: Verifying the Health of Services Configured on the ProxySG
Section C: Configuring Global Defaults
#(config health-check alias_name) event-log {healthy {disable|
information| severe}| report-all-ips {enable | disable} | sick {
disable| information|severe}}

Configures event-log notifications for the health check. An informational or a
severe event-log message is logged depending on the setting chosen.
#(config health-check alias_name) snmp {healthy {enable |disable} |
report-all-ips {enable|disable} | sick {enable|disable}}

Configures snmp notifications for the health check
#(config health-check alias_name) use-defaults

Resets the defaults of the health check to use the global defaults instead of any
explicitly set values.

365

Volume 5: Advanced Networking
Section D: Forwarding Host and SOCKS Gateways Health Checks

Section D: Forwarding Host and SOCKS Gateways Health Checks
Before you can edit forwarding or SOCKS gateways health check types, you must
configure forwarding hosts or SOCKS gateways. For information about
configuring forwarding, see Chapter 8: "Configuring the Upstream Network
Environment" on page 131; for information about configuring SOCKS gateways,
see Chapter 13: "SOCKS Gateway Configuration" on page 327.
This section discusses managing the automatically generated forwarding host
and SOCKS gateway health checks.

Forwarding Hosts and SOCKS Gateways Configurations
The forwarding host health check configuration defines whether the target being
tested is a server or a proxy, which ports are available, and provides the setting for
the server certificate verification.
The SOCKS gateways health check configuration defines the SOCKS port, the
version (4 or 5), and possibly a username and password.

Forwarding Hosts Health Checks
The default for a newly created forwarding host is a TCP health check using the
first port defined in the forwarding host's port array (typically the HTTP port).
You can change the port setting. The TCP test can support SOCKS gateway policy.
The URL uses the forwarding host hostname, such as:
tcp://gateway_name:port/

SOCKS Gateways Health Checks
The default for a newly created SOCKS gateway is a TCP health check using the
SOCKS port in the SOCKS gateways configuration.

Forwarding and SOCKS Gateways Groups Health Checks
Specific tests are not done for groups. Health check test results are determined
from examining and combining the health of the group members.
Note: You can create groups in the Configuration > Forwarding > Forwarding Hosts tab

or Configuration > Forwarding > SOCKS Gateways tab.
By default, if any of the members of the group are healthy, then the group is
considered healthy. You can specify the number of group members that must be
healthy for the group to be considered healthy.

Editing Forwarding and SOCKS Gateways Health Checks
You can edit, but not delete, the forwarding and SOCKS gateway tests and
groups. The settings you can change are:


366

Enable or disable the health check

Chapter 14: Verifying the Health of Services Configured on the ProxySG
Section D: Forwarding Host and SOCKS Gateways Health Checks


Override default notifications



Select the type of test



Specify settings for the selected test



Override default settings



Select the minimum number of healthy members for a group to report healthy

To edit forwarding and SOCKS gateways health checks:

1. Select Configuration > Health Checks > General > Health Checks.
2. Select the forwarding host test or SOCKS gateways test to modify.
3. Click Edit.

367

Volume 5: Advanced Networking
Section D: Forwarding Host and SOCKS Gateways Health Checks

4. Make the necessary changes:
a. Select the Type of Test from the drop-down list.
b. Select the Enabled state radio button as required.
c. Select the port setting you require. If you select Use Port, enter the new
port number.
d. To change the default settings for this test, click Override the default
settings. Select the options to override. Cancel your choices by clicking
Clear all overrides. For detailed information about configuring healthy
and sick intervals and thresholds, see "Changing Health Check Default
Settings" on page 357. Click OK to close the dialog.
e. To change default notifications, click Override the default notifications. By
default, no notifications are sent for any health checks. Select the
options to override. You can cancel your choices by clicking Clear all
overrides. For detailed information about configuring notifications, see
"Configuring Health Check Notifications" on page 361. Click OK to
close the dialog.
f.

Click OK to close the edit dialog.

5. Click Apply.

368

Chapter 14: Verifying the Health of Services Configured on the ProxySG
Section D: Forwarding Host and SOCKS Gateways Health Checks
To edit forwarding or SOCKS gateway group health checks:
Note: The only way to add or delete group members to the automatically
generated health check tests is to add and remove members from the actual
forwarding or SOCKS gateway group. The automatically generated health
check is then updated.

1. Select Configuration > Health Checks > General > Health Checks.
2. Select the forwarding or SOCKS gateways group health check you need to
modify.
3. Click Edit.

4. Make the necessary changes:
a. Select the Enabled state radio button as required.
b. Select the Minimum number of users that must be healthy for group to be
healthy from the drop-down list.
c. To create notification settings, click Override the default notifications.
Select the options. Cancel your choices by clicking Clear all overrides.
For detailed information about configuring notifications, see
"Configuring Health Check Notifications" on page 361.
d. Click OK to close the override dialog.
e. Click OK to close the health check group.
5. Click Apply.

Related CLI Syntax to Edit Forwarding Groups and SOCKS Groups Health
Checks
The examples below use the forwarding group, fwd.group_name.
#(config health-check) edit fwd.group_name

369

Volume 5: Advanced Networking
Section D: Forwarding Host and SOCKS Gateways Health Checks

Allows you to configure options for the health check you specified.
#(config health-check fwd.group_name) combine {all healthy | anyhealthy | some-healthy}

Combines the results when a group test is healthy.
#(config health-check fwd.group_name) e-mail {healthy {default |
enable | disable}| report-all-ips {default | enable | disable}| sick
{default | enable | disable}}

Sends e-mail notification when the health check reports healthy or sick,
whether or not those reports are for all IP addresses.
#(config health-check fwd.group_name) event-log {healthy {default |
disable | information | severe}| report-all-ips {default | enable |
disable}| sick {default | disable | information | severe}}

Logs an event when the health check reports healthy or sick, whether or not
those reports are for all IP addresses. An informational or a severe event-log
message is logged depending on the setting chosen.
#(config health-check fwd.group_name) exit

Exits the health check editing mode.
#(config health-check fwd.group_name) perform-health-check

Starts the health check immediately and reports the result.
#(config health-check fwd.group_name) severity {critical|no-effect
|default |warning}

Configures default severity for the health check.
#(config health-check fwd.group_name) snmp {healthy {default | enable
| disable}| report-all-ips {default | enable | disable}| sick {default
| enable | disable}}

Sends a trap when the health check reports healthy, whenever an IP address
health check reports healthy, or when a health check reports sick.
#(config health-check fwd.group_name) use-defaults

Resets the defaults of the health check to use the global defaults instead of any
explicitly set values.
#(config health-check fwd.group_name) view {configuration |
statistics}

Views the health check’s configuration or statistics.

Related CLI Syntax to Edit Forwarding Hosts and SOCKS Gateway Health
Checks
The examples below use the forwarding host, fwd.host_name.
#(config health-check)edit fwd.host_name

Allows you to configure options for the health check you specified.

370

Chapter 14: Verifying the Health of Services Configured on the ProxySG
Section D: Forwarding Host and SOCKS Gateways Health Checks
#(config health-check fwd.host_name) authentication {basic | disable |
encrypted-password encrypted-password| password password| username
username}

Allows you to specify a username and password for the health-check target, if
it uses basic authentication.(Used with HTTP or HTTPS health checks.)
#(config health-check fwd.host_name) clear-statistics

Clears statistics for this health check.
#(config health-check fwd.host_name) e-mail {healthy {default | enable
| disable}| report-all-ips {default | enable | disable}| sick {default
| enable | disable}}

Sends e-mail notification when the health check reports healthy or sick,
whether or not those reports are for all IP addresses.
#(config health-check fwd.host_name) event-log {healthy {default |
disable | information | severe}| report-all-ips {default | enable |
disable}| sick {default | disable | information | severe}}

Logs an event when the health check reports healthy or sick, whether or not
those reports are for all IP addresses. An informational or a severe event-log
message is logged depending on the setting chosen.
#(config health-check fwd.host_name) exit

Exits the health check editing mode.
#(config health-check fwd.host_name) failure-trigger {default | none |
count}

Configures options for the failure-trigger.
#(config health-check fwd.host_name) interval {healthy {default |
seconds}| sick {default | seconds}}

Configures intervals before the health check is re-run. The intervals can be
different for health checks that are reporting healthy and health checks that
are reporting sick.
#(config health-check fwd.host_name) perform-health-check

Starts the health check immediately and reports the result.
#(config health-check fwd.host_name) proxy-authentication {basic |
disable | encrypted-password encrypted-password | password password |
username username}

Allows you to specify a username and password for the intermediate proxy.
(Used with HTTP or HTTPS health checks, when intermediate proxies are
between you and the target.)
#(config health-check fwd.host_name) response-code {add codes | remove
codes}

Manages a list of codes that are considered valid and result in health-check
successes. You can add or remove codes, separated by semi-colons. If a
success code is received by the health check, the health check considers the
HTTP/ HTTPS test to be successful.
(Used with HTTP or HTTPS health checks.)

371

Volume 5: Advanced Networking
Section D: Forwarding Host and SOCKS Gateways Health Checks
#(config health-check fwd.host_name) severity {critical |no-effect
|default |warning}

Configures default severity for the health check.
#(config health-check fwd.host_name) snmp {healthy {default | enable |
disable}| report-all-ips {default |enable |disable}| sick {default |
enable |disable}}

Sends a trap when the health check reports healthy, whenever an IP address
health check reports healthy, or when a health check reports sick.
#(config health-check fwd.host_name) threshold {healthy {default |
count} | response-time {default | none | milliseconds} | sick {default
| count}}

Sets the level when the health check will report healthy or sick.
#(config health-check fwd.host_name) type (http URL | https URL | icmp
hostname | ssl hostname [port] | tcp hostname [port]}

Sets the number of consecutive healthy or sick test results before the health
check actually reports as healthy or sick.
#(config health-check fwd.host_name) use-defaults

Resets the defaults of the health check to use the global defaults instead of any
explicitly set values.
#(config health-check fwd.host_name) view {configuration | events
|statistics}

Displays the health check’s configuration, recent event-log messages or
statistics.

372

Chapter 14: Verifying the Health of Services Configured on the ProxySG
Section E: DNS Server Health Checks

Section E: DNS Server Health Checks
A DNS server health check is automatically generated for each DNS server
configured on the ProxySG and is deleted when the DNS server is removed. For
information on configuring DNS servers, refer to Volume 1: Getting Started.
The ProxySG uses DNS server health checks to verify the responsiveness of the
DNS server. The health check status is recorded as:


Healthy, when the ProxySG successfully establishes a connection with the
DNS server and is able to resolve the configured hostname.



Unhealthy, either if the ProxySG is unable to establish a connection with the
DNS server, or if the ProxySG is unable to resolve the configured hostname.
The status reports Check failed or DNS failed.

When a DNS server is unhealthy, the ProxySG avoids contacting that server and
directs requests to other DNS servers configured in the group, as applicable.
The DNS health check attempts to look up a configurable hostname. The default
hostname depends on the DNS configuration:


For a server in the primary or alternate DNS group, the default is
www.bluecoat.com.



For a server in a custom DNS group, the default is the longest domain name
listed in the group.

You can also override these defaults and specify a health check hostname for each
DNS server.

See Also
DNS (Volume 1, Chapter 8)

Editing DNS Server Health Checks
On the ProxySG, you can edit the following settings for a DNS server health
check:


Enable or disable the health check



Specify a hostname



Override default settings — change healthy and sick intervals, and thresholds



Override default notifications — change the severity and notification options
for alerts

To edit a DNS server health check:

1. Select Configuration > Health Checks > General > Health Checks.
2. Select the DNS health check to modify.
3. Click Edit. The Edit DNS server dialog displays.

373

Volume 5: Advanced Networking
Section E: DNS Server Health Checks

4. Configure the DNS server health check options:
a. Select the Enabled state option, as required.


Enabled allows



Disabled, reporting as healthy disables

the ProxySG to query the DNS server and to report
changes in the health state.
the health check and reports the

service as healthy.


Disabled, reporting as sick

disables the health check and reports the

service as unhealthy.
b. Select the Host option, as required.


374

Use default host

uses the default hostname.

Volume 5: Advanced Networking
Section E: DNS Server Health Checks



Use user defined host allows you to configure a custom hostname for this

health check. Enter the hostname in the box provided.
Proceed to Step e if you do not want to override defaults.
c. To change default settings, click Override the default settings. Select the
options to override. Cancel your choices by clicking Clear all overrides.
For detailed information about configuring healthy and sick intervals
and thresholds, see "Changing Health Check Default Settings" on page
357. Click OK to close the dialog.
d. To change the default notifications, click Override the default notifications.
Select the options. Cancel your choices by clicking Clear all overrides.
For detailed information about configuring notifications, see
"Configuring Health Check Notifications" on page 361.
e. Click OK to close the override dialog.
5. Click OK to close the edit dialog.
6. Click Apply.

Related CLI Syntax to Edit DNS Server Health Checks
#(config health-check)edit dns.test_name

Allows you to configure options for the health check you specified.
#(config health-check dns.test_name) clear-statistics

Clears statistics for this health check.
#(config health-check dns.test_name) e-mail {healthy {default | enable
| disable}| report-all-ips {default | enable | disable}| sick {default
| enable | disable}}

Sends e-mail notification when the health check reports healthy or sick,
whether or not those reports are for all IP addresses.
#(config health-check dns.test_name) event-log {healthy {default |
disable | information | severe}| report-all-ips {default | enable |
disable}| sick {default | disable | information | severe}}

Logs an event when the health check reports healthy or sick, whether or not
those reports are for all IP addresses. An informational or a severe event-log
message is logged depending on the setting chosen.
#(config health-check dns.test_name) exit

Exits the health check editing mode.
#(config health-check dns.test_name) failure-trigger {default | none |
count}

Configures options for the failure-trigger.
#(config health-check dns.test_name) interval {healthy {default |
seconds}| sick {default | seconds}}

375

Volume 5: Advanced Networking
Section E: DNS Server Health Checks

Configures intervals before the health check is re-run. The intervals can be
different for health checks that are reporting healthy and health checks that
are reporting sick.
#(config health-check dns.test_name) hostname {default|hostname }

Sets the hostname for the DNS Server health check to the default hostname or
to a user-defined hostname.
#(config health-check dns.test_name) perform-health-check

Starts the health check immediately and reports the result.
#(config health-check dns.test_name) severity {critical|no-effect
|default |warning}

Configures default severity for the health check.
#(config health-check dns.test_name) snmp {healthy {default | enable |
disable}| report-all-ips {default | enable | disable}| sick {default |
enable | disable}}

Sends a trap when the health check reports healthy, whenever an IP address
health check reports healthy, or when a health check reports sick.
(config health-check dns.test_name) threshold {healthy {default |
count} | response-time {default | none | milliseconds} | sick {default
| count}}

Sets the level when health checks will report healthy or sick.
#(config health-check dns.test_name) use-defaults

Resets the defaults of the health check to use the global defaults instead of any
explicitly set values.
#(config health-check dns.test_name) view {configuration | events
|statistics}

Displays the health check’s configuration, recent event-log messages or
statistics.

376

Volume 5: Advanced Networking
Section F: Authentication Health Checks

Section F: Authentication Health Checks
This section includes information on authentication server health checks. For
information on authentication realms, refer to Volume 4: Securing the Blue Coat
ProxySG Appliance.
An authentication health check is automatically generated for each external
authentication realm that is configured on the ProxySG. Authentication health
checks assess the realm’s health based on data gathered during the most recent
authentication attempt. The response time recorded for this health check
represents the average response time between two consecutive health checks.
Unlike most health checks, authentication health checks do not probe the target
realm with an authentication request. Therefore, the health check will report
healthy until the ProxySG records a failed authentication attempt.
The health states for authentication health checks can be:


Ok,



Check failed,



Functioning on alternate server,



Functioning properly with errors,

when the ProxySG records successful authentication attempts.
when the device records an unsuccessful authentication attempt.
when a realm is operating on its alternate server.
when the health check records intermittent

failures on a server.
On an authentication health check, you can edit the following settings:


Enable or disable the health check



Override default settings — change healthy and sick intervals, and thresholds



Override default notifications — change the severity, and notification options
for alerts

By default, the health check is enabled and the ProxySG tracks the response time
for the most recent authentication attempts. The other options are — Disabled,
reporting sick and Disabled, reporting healthy.
Use the Disabled, reporting sick option when an authentication server requires
downtime for maintenance, or the server is taken off-line temporarily. And the
Disabled, reporting healthy option is relevant when you elect to use an
authentication server despite failures in authentication attempts.
To edit an authentication health check:

1. Select Configuration > Health Checks > General > Health Checks.
2. Select the auth.test_name health check to modify.
3. Click Edit. The Edit Authentication health check dialog displays

377

Volume 5: Advanced Networking
Section F: Authentication Health Checks

4. Configure the authentication health check options:
a. Select the Enabled state radio button as required.
b. To change the default settings, click Override the default settings. Select
the options to override. Cancel your choices by clicking Clear all
overrides. For detailed information about configuring healthy and sick
intervals and thresholds, see "Changing Health Check Default
Settings" on page 357. Click OK to close the dialog.
c. To change the default notifications, click Override the default notifications.
Select the options. Cancel your choices by clicking Clear all overrides.
For detailed information about configuring notifications, see
"Configuring Health Check Notifications" on page 361. Click OK to
close the dialog.
d. Click OK to close edit dialog.
5. Click Apply.

Related CLI Syntax to Edit Authentication Health Checks
#(config health-check)edit auth.test_name

Allows you to configure options for the health check you specified.
#(config health-check auth.test_name) clear-statistics

Clears statistics for this health check.

378

#(config health-check auth.test_name) e-mail {healthy {default |
enable | disable}| report-all-ips {default | enable | disable}| sick
{default | enable | disable}}

Sends e-mail notification when the health check reports healthy or sick,
whether or not those reports are for all IP addresses.
#(config health-check auth.test_name) event-log {healthy {default |
disable | information | severe}| report-all-ips {default | enable |
disable}| sick {default | disable | information | severe}}

Logs an event when the health check reports healthy or sick, whether or not
those reports are for all IP addresses. An informational or a severe event-log
message is logged depending on the setting chosen.
#(config health-check auth.test_name) exit

Exits the health check editing mode.
#(config health-check auth.test_name) failure-trigger {default | none
| count}

Configures options for the failure-trigger.
#(config health-check auth.test_name) interval {healthy {default |
seconds}| sick {default | seconds}}

Configures intervals before the health check is re-run. The intervals can be
different for health checks that are reporting healthy and health checks that
are reporting sick.
#(config health-check auth.test_name) perform-health-check

Starts the health check immediately and reports the result.
#(config health-check auth.test_name) severity {critical|no-effect
|default |warning}
Configures default severity for the health check.
#(config health-check auth.test_name) snmp {healthy {default | enable
| disable}| report-all-ips {default | enable | disable}| sick {default
| enable | disable}}

Sends a trap when the health check reports healthy, whenever an IP address
health check reports healthy, or when a health check reports sick.
#(config health-check auth.host_name) threshold {healthy {default |
count} | response-time {default | none | milliseconds} | sick {default
| count}}

Sets the level when health checks will report healthy or sick.
#(config health-check auth.test_name) use-defaults

Resets the defaults of the health check to use the global defaults instead of any
explicitly set values.
#(config health-check auth.test_name) view {configuration | events
|statistics}

Displays the health check’s configuration, recent event-log messages or
statistics.

379

Volume 5: Advanced Networking
Section G: Virus Scanning and Content Filtering Health Checks

Section G: Virus Scanning and Content Filtering Health Checks
The virus scanning and content filtering services include ICAP services, Websense
off-box services, and the DRTR service. While these external service health checks
are created and deleted automatically, the service itself must be created before
health checks can be used. For more information about creating ICAP and
Websense off-box services, refer to Volume 7: Managing Content. The DRTR service
health check is automatically created if you use Blue Coat Web Filter (BCWF) and
the rating service is enabled.
The health check system conducts external service tests by sending requests to the
external services system, which reports back a health check result.The tests for
each of the external services is specialized and is devised specifically for each
service.
Note: The names of the ICAP and Websense off-box services and service groups
can be a maximum of 64 characters long, a change from previous releases, which
allowed names to be a maximum of 127 characters. If a previously existing name
exceeds 64 characters, the service or service group continues to function normally
but no corresponding health check type is created.

The settings you can change on ICAP, Websense off-box, and DRTR service health
checks are:


Enable or disable the health check



Override default settings



Override default notifications

To edit virus scanning and content filtering tests:

1. Select Configuration > Health Checks > General > Health Checks.
2. Select the external service to modify. External services have prefix names of
drtr, icap, and ws.
3. Click Edit.

380

4. Make the necessary changes:
a. Select the Enabled state radio button as required.
b. (Websense only): If you do not want to use the default URL, select the
Use user defined URL option and enter the test URL to use.
c. To change default settings, click Override the default settings.


Select the check boxes to override. Cancel your choices by clicking
Clear all overrides. For detailed information about configuring healthy
and sick intervals and thresholds, see "Changing Health Check Default
Settings" on page 357.

Note: DRTR health check has default settings that differ from the

defaults for other external services: 10800 seconds (3 hours) for the
interval, and 1 for the failure trigger.


Click OK.

d. To change default notifications, click Override the default notifications. By
default, no notifications are sent for any health checks. Select the
options. Cancel your choices by clicking Clear all overrides. For detailed
information about configuring notifications, see "Configuring Health
Check Notifications" on page 361.
e. Click OK to close the override dialog.
f.

Click OK to close the edit dialog.

5. Click Apply.

381

Volume 5: Advanced Networking
Section G: Virus Scanning and Content Filtering Health Checks

Related CLI Syntax to Modify ICAP Service and Content Filtering Health
Checks
The examples below use Blue Coat’s Content Filter — DRTR_
#(config health-check)edit drtr.test_name

Allows you to configure options for the health check you specified.
#(config health-check drtr.test_name) clear-statistics

Clears statistics for this health check.
#(config health-check drtr.test_name) e-mail {healthy {default |
enable | disable}| report-all-ips {default |enable |disable}| sick
{default | enable | disable}}

Sends e-mail notification when the health check reports healthy or sick,
whether or not those reports are for all IP addresses.
#(config health-check drtr.test_name) event-log {healthy {default |
disable |information |severe}| report-all-ips {default |enable |
disable}| sick {default |disable |information |severe}}

Logs an event when the health check reports healthy or sick, whether or not
those reports are for all IP addresses. An informational or a severe event-log
message is logged depending on the setting chosen.
#(config health-check drtr.test_name) exit

Exits the health check editing mode.
#(config health-check drtr.test_name) failure-trigger {default |none |
count}

Configures options for the failure-trigger.
#(config health-check drtr.test_name) interval {healthy {default |
seconds}| sick {default |seconds}}

Configures intervals before the health check is re-run. The intervals can be
different for health checks that are reporting healthy and health checks that
are reporting sick.
#(config health-check drtr.test_name) perform-health-check

Starts the health check immediately and reports the result.
#(config health-check drtr.test_name) severity {critical|noeffect|default|warning}

Configures default severity for the health check.
#(config health-check drtr.test_name) snmp {healthy {default | enable
| disable}| report-all-ips {default | enable | disable}| sick {default
| enable | disable}}

Sends a trap when the health check reports healthy, whenever an IP address
health check reports healthy, or when a health check reports sick.
#(config health-check drtr.test_name) threshold {healthy {default
|count} | response-time {default | none| milliseconds} | sick {default
|count}}

382

Sets the level when the health check will report healthy or sick.
#(config health-check ws.test_name) test-url {default |url}

(Used only with the WebSense health checks) Sets the test URL to default.
#(config health-check drtr.test_name) use-defaults

Resets the defaults of the health check to use the global defaults instead of any
explicitly set values.
#(config health-check drtr.test_name) view {configuration |events
|statistics}

Displays the health check’s configuration, recent event-log messages or
statistics.
To edit Websense off-box or ICAP group tests:
Note: The only way to add or delete group members to the automatically
generated health check tests is to add and remove members from the ICAP or
Websense off-box services. The automatically generated health check type is
then updated.

1. Select Configuration > Health Checks > General > Health Checks.
2. Select the external service group health check to modify. Groups are identified
in the Type column.
3. Click Edit.

383

Volume 5: Advanced Networking
Section G: Virus Scanning and Content Filtering Health Checks

4. Make the necessary changes:
a. Enable or disable the Enabled state radio button as required.
b. Select the Minimum number of members that must be healthy for group to be
healthy from the drop-down list. The default is set to one.
c. To create notification settings, click Override the default notifications.
Select the options. Cancel your choices by clicking Clear all overrides.
For detailed information about configuring notifications, see
"Configuring Health Check Notifications" on page 361.
d. Click OK to close the override dialog.
e. Click OK to close the edit dialog.
5. Click Apply.

Related CLI Syntax to Modify ICAP and Websense Group Tests
The examples below use Websense.
#(config health-check) edit ws.group_name

Allows you to configure options for the health check you specified.
#(config health-check ws.group_name) combine {all healthy | anyhealthy | some-healthy}

Combines the results when a group test is healthy.
#(config health-check ws.group_name) e-mail {healthy {default | enable
| disable}| report-all-ips {default | enable | disable}| sick {default
| enable | disable}}

Sends e-mail notification when the health check reports healthy or sick,
whether or not those reports are for all IP addresses.
#(config health-check ws.group_name) event-log {healthy {default |
disable |information |severe}| report-all-ips {default |enable |
disable}| sick {default |disable |information |severe}}

384

Logs an event when the health check reports healthy or sick, whether or not
those reports are for all IP addresses. An informational or a severe event-log
message is logged depending on the setting chosen.
#(config health-check ws.group_name) exit

Exits the health check editing mode.
#(config health-check ws.group_name) perform-health-check

Starts the health check immediately and reports the result.
#(config health-check ws.group_name) snmp {healthy {default |enable |
disable}| report-all-ips {default | enable | disable}| sick {default |
enable |disable}}

Sends a trap when the health check reports healthy, whenever an IP address
health check reports healthy, or when a health check reports sick.
#(config health-check ws.group_name) use-defaults

Resets the defaults of the health check to use the global defaults instead of any
explicitly set values.
#(config health-check ws.group_name) view {configuration |events
|statistics}

Displays the health check’s configuration, recent event-log messages or
statistics.

385

Volume 5: Advanced Networking
Section H: Managing User-Defined Health Checks

Section H: Managing User-Defined Health Checks
You can manually create and manage ICMP, TCP, HTTP, HTTPS, or SSL health
check tests for any upstream TCP/IP device. You can use these user-defined
health check types to send notifications of health check state changes.
Under most circumstances, you do not need to create user-defined health checks
because the automatically generated health checks meet most needs. However, to
check for things that Blue Coat does not test for automatically — for example, the
health of the Internet or of the router, you might create user-defined heath checks.
If, for example, you want to control Web traffic based on the apparent health of
the Internet, you can create a user-defined health check to target known Internet
sites. As long as a certain number of the sites are healthy, you can consider the
Internet as healthy.
Further, you can use policy to configure forwarding rules on the ProxySG.
Subsequently, if the user-defined health check determining internet accessibility
transitions to unhealthy, all requests directed to the ProxySG will be forwarded to
the alternate ProxySG until the primary ProxySG transitions to healthy again.
Note: Frequent testing of specific Internet sites can result in that Internet site
objecting to the number of hits.

Blue Coat supports two types of user-defined health checks:


Host: This health check type is for any upstream TCP/IP device. For more
information, continue with the next section.



Composite: This health check type combines the results of other existing
health checks. It can include other composite health checks, health checks for
user defined hosts, and any automatically generated health checks. For more
information, continue with "About User-Defined Composite Health Checks"
on page 387.

For information about configuring parameter and notification settings for
automatically generated health check types, see Section C: "Configuring Global
Defaults" on page 355.

About User-Defined Host Health Checks
You can create, configure, and delete user-defined host health checks. These
health checks support everything an automatically generated health check
contains, including background DNS resolution monitoring and support for
multiple addresses.
User-defined health checks can include:


386

ICMP: The basic connection between the ProxySG and the origin server is
confirmed. The server must recognize ICMP echoing, and any intervening
networking equipment must support ICMP.



TCP: Establishes that a TCP layer connection can be made to a port on the
host. Then the connection is dropped.



SSL: A connection is made to a target and the full SSL handshake is confirmed.
Then the connection is dropped.



HTTP/HTTPS: An HTTP or HTTPS test is defined by the URL supplied. The
port used for this test is as specified in that URL. If no port is explicitly
specified in the URL, the port defaults to the standard Internet value of 80 or
443.

When configuring user-defined host health check types, keep the following in
mind:


User-defined host health checks are created and deleted manually.



All individual user-defined tests consider the target to be a server.



To conduct proxy HTTP/HTTPS tests, a proxy must be defined as a
forwarding host, set up between the originating device and the target, and
forwarding policy must cause the test to be directed through the proxy.



For an ICMP test, a hostname is specified in the health check configuration.



The TCP and SSL tests support SOCKS gateway policy, based on a URL of
tcp://hostname:port/ and ssl://hostname:port/, respectively, using a
hostname and port supplied in health check configuration.



An HTTP/HTTPS test requires a full URL. The port used for this test is as
specified in that URL. If no port is explicitly specified in the URL, the port
defaults to the standard value for these protocols of 80 or 443. The server
being tested is assumed to support whatever port is indicated.
Forwarding and SOCKS gateway policy is applied based on the URL. The
HTTPS or SSL tests use all the server certificate settings in the SSL layer in
policy. For a forwarding host, all the sever certificate settings in the SSL layer
also apply, and if present, override the forwarding host configuration setting.
Note: None of the above tests apply to user-defined composite health checks,
which only consist of a set of members and a setting to combine the results.

About User-Defined Composite Health Checks
You can create a composite health check to combine the results of multiple health
checks. A composite health check can contain any number of individual health
checks. Further, forwarding host and SOCKS gateway health checks can be
configured to use the result of a composite health check.
By default, to report healthy, all members of a composite health check must be
healthy. However, you can configure the number of members that must be
healthy for the composite result to report healthy.
Composite health checks with no members always appear unhealthy.

387

Volume 5: Advanced Networking
Section H: Managing User-Defined Health Checks

Note: Automatically generated group tests and user-defined composite tests
are not the same.

Group tests are automatically generated; they cannot be deleted. Some
editing is permitted, but you cannot add or remove members of the group
through the health checks module. You must modify the forwarding or
SOCKS gateways groups to update the automatically generated group tests.
For a group test, the default is for the group to be healthy if any member is
healthy. For a composite test, the default is for the group to be healthy if all
members are healthy. (The default is configurable.)

Creating User-Defined Host and Composite Health Checks
You can create user-defined host and composite health checks for arbitrary
targets.
Note: You cannot create user-defined health checks for external service tests,

such as authentication servers, ICAP, Websense off-box, and the DRTR
service.
The following procedure explains how to create a user-defined host health check.
To create a user-defined composite health check, continue with "To create a userdefined composite health check:" on page 392.
To create a user-defined host health check:

1. Select Configuration > Health Checks > General > Health Checks.
2. Click New.

388

3. Select the type of test to configure from the Type of test drop-down list. To
configure a composite test, see "To create a user-defined composite health
check:" on page 392.
The options you can select vary with the type of health check. The example
above uses the HTTP/HTTPS options. Options for other tests are explained in
this procedure, as well.
a. Enter a name for the health check.
b. Select the Enabled state option, as required.
c. If you are configuring an SSL or TCP health check, enter the port to
use.
d. If you are configuring an ICMP, SSL, or TCP health check, enter the
hostname of the health check’s target.
e. For HTTP/HTTPS only:


Enter the URL address of the target.

389

Volume 5: Advanced Networking
Section H: Managing User-Defined Health Checks



To use Basic user authentication, select the check box and enter the
username and password of the target.



To use Basic proxy authentication because intermediate proxies might
be between you and the target, select the check box and enter the
username and password of the target.



To manage a list of HTTP/HTTPS response codes that are considered
successes, enter the list in the Allowed Response Code field, separated by
semi-colons. If one of them is received by the health check then the
health check considers the HTTP(S) test to have been successful.

Note: The 200 response code is added by default. The list must always

have at least one member.
f.

To change the default settings for this test, click Override the default
settings. Select the override options. Cancel your choices by clicking
Clear all overrides. For detailed information about configuring healthy
and sick intervals and thresholds, see "Changing Health Check Default
Settings" on page 357. Click OK.

g. To change the default notifications for this test, click Override the default
notifications. By default, no notifications are sent for any health checks.
Select the override options. You can cancel your choices by clicking
Clear all overrides. For detailed information about configuring
notifications, see "Configuring Health Check Notifications" on page
361 Click OK.
h. Click OK to close the dialog.
4. Click Apply.

Related CLI Syntax to Create and Modify User-Defined Host Health
Checks
#(config health-check) create {composite alias_name | http alias_name
url | https alias_name url | icmp alias_name hostname| ssl alias_name
hostname [port]| tcp alias_name hostname [port]}

Creates a user-defined health check of the type specified.
#(config health-check) edit health_check_name

Allows you to configure options for the health check you specified.
#(config health-check user.health_check_name) authentication {basic |
disable | encrypted-password encrypted-password| password password|
username username}

Allows you to specify a username and password for the health-check target, if
its allows basic authentication.(Used with HTTP or HTTPS health checks.)
#(config health-check user.health_check_name) clear-statistics

Clears statistics for this health check.

390

#(config health-check user.health_check_name) e-mail {healthy {default
| enable | disable}| report-all-ips {default | enable | disable}| sick
{default | enable | disable}}

Sends e-mail notification when the health check reports healthy or sick,
whether or not those reports are for all IP addresses.
#(config health-check user.health_check_name) event-log {healthy
{default | disable | information | severe}| report-all-ips {default |
enable | disable}| sick {default | disable | information | severe}}

Logs an event when the health check reports healthy or sick, whether or not
those reports are for all IP addresses. An informational or a severe event-log
message is logged depending on the setting chosen.
#(config health-check user.health_check_name) exit

Exits the health check editing mode.
#(config health-check user.health_check_name) failure-trigger {default
| none | count}

Configures options for the failure-trigger.
#(config health-check user.health_check_name) interval {healthy
{default | seconds}| sick {default | seconds}}

Configures intervals before the health check is re-run. The intervals can be
different for health checks that are reporting healthy and health checks that
are reporting sick.
#(config health-check user.health_check_name) perform-health-check

Starts the health check immediately and reports the result.
#(config health-check user.health_check_name) proxy-authentication
{basic | disable | encrypted-password encrypted-password | password
password | username username}

Allows you to specify a username and password for the intermediate proxy.
(Used with HTTP or HTTPS health checks, when intermediate proxies are
between you and the target.)
#(config health-check user.health_check_name) response-code {add codes
| remove codes}

Manages a list of codes that are considered valid and result in health-check
successes. You can add or remove codes, separated by semi-colons. If a
success code is received by the health check, the health check considers the
HTTP/ HTTPS test to be successful. (Used with HTTP or HTTPS health
checks.)
#(config health-check user.health_check_name) severity {critical |noeffect |default |warning}

Configures default severity for the health check.
#(config health-check user.health_check_name) snmp {healthy {default |
enable | disable}| report-all-ips {default |enable |disable}| sick
{default |enable |disable}}

Sends a trap when the health check reports healthy, whenever an IP address
health check reports healthy, or when a health check reports sick.

391

Volume 5: Advanced Networking
Section H: Managing User-Defined Health Checks
#(config health-check user.health_check_name) threshold {healthy
{default | count} | response-time {default | none | milliseconds} |
sick {default | count}}

Sets the threshold level when the health check will report healthy or sick.
#(config health-check user.health_check_name) type (http URL | https
URL | icmp hostname | ssl hostname [port] | tcp hostname [port]}

Sets the number of consecutive healthy or sick test results before the health
check actually reports as healthy or sick.
#(config health-check user.health_check_name) use-defaults

Resets the defaults of the health check to use the global defaults instead of any
explicitly set values.
#(config health-check user.health_check_name) view {configuration |
events | statistics}

Displays the health check’s configuration, recent event-log messages or
statistics.
To create a user-defined composite health check:

1. Select Configuration > Health Checks > General > Health Checks.
2. Click New.

392

3. Make the necessary changes:
a. Select Composite from the Type of Test from the drop-down list.
b. Enable or disable the Enabled state option as required.
c. Select the Minimum number of members that must be healthy for the group to
be healthy from the drop-down list. The default is All.
d. Add the health check members to the composite test from the Available
Aliases list by selecting the health check to add and clicking Add to
move the alias to the Selected Alias list.
e. To change the default notifications for this test, click Override the default
notifications. By default, no notifications are sent for any health checks.
Select the override options. You can cancel your choices by clicking
Clear all overrides. For detailed information about configuring
notifications, see "Configuring Health Check Notifications" on page
361
f.

Click OK to close the override dialog.

g. Click OK to close the edit dialog.
4. Click Apply.

393

Volume 5: Advanced Networking
Section H: Managing User-Defined Health Checks

Related CLI Syntax to Create and Modify User-Defined Composite Health
Checks
#(config health-check) create {composite alias_name | http alias_name
url | https alias_name url | icmp alias_name hostname| ssl alias_name
hostname [port]| tcp alias_name hostname [port]}

Creates a user-defined health check of the type specified.
#(config health-check) edit composite_health_check

Edits the specified composite health check.
#(config health-check user.composite_health_check) add member_name

Adds the specified member to the composite health check group.
#(config health-check user.composite_health_check) combine {allhealthy | any-healthy | some-healthy}

Requires that all, some, or any members of the group report as healthy to have
the composite health check report as healthy.
#(config health-check user.composite_health_check) e-mail {healthy
{default |enable |disable}| report-all-ips {default |enable |disable}|
sick {default |enable |disable}}

Sends e-mail notification when the health check reports healthy or sick,
whether or not those reports are for all IP addresses.
#(config health-check user.composite_health_check) event-log {healthy
{default |disable |information |severe}| report-all-ips {default
|enable | disable}| sick {default |disable |information |severe}}

Logs an event when the health check reports healthy or sick, whether or not
those reports are for all IP addresses. An informational or a severe event-log
message is logged depending on the setting chosen.
#(config health-check user.composite_health_check) exit

Exits the composite health check editing submode.
#(config health-check user.composite_health_check) perform-healthcheck

Performs a health check on the members of the composite immediately and
reports the result.
#(config health-check user.composite_health_check) remove member_name

Removes a member from the composite group.
#(config health-check user.composite_health_check) snmp {healthy
{default |enable |disable}| report-all-ips {default |enable |disable}|
sick {default |enable |disable}}

Sends a trap when the health check reports healthy or sick, whether or not
those reports are for all IP addresses.
#(config health-check user.composite_health_check) severity {critical
| default|no-effect|warning}

394

Sets the severity level of the health check, which determines how this health
check affects the overall health of the device.
#(config health-check user.composite_health_check) use-defaults

Resets the defaults of the health check to use the global defaults instead of any
explicitly set values.
#(config health-check user.composite_health_check) view {configuration
|events |statistics}

Displays the composite health check’s configuration, event log messages, or
statistics.

Copying and Deleting User-Defined Health Checks
Only user-defined health checks can be copied and deleted. Automatically
generated health checks cannot be copied or deleted.


If the source health check is user-defined host or a composite and the target
alias name does not exist:


A new health check of the same kind with that alias name is created



The new health check has identical configuration settings to the source
health check.



If the target alias does exist and the target is of the same kind (that is, both are
user- defined hosts or both are composite), then the complete configuration is
copied from the source to the target.



If a health check is referenced either in policy or in another health check, it
cannot be deleted.

To copy or delete a user-defined host or composite health check:

1. Select Configuration > Health Checks > General > Health Checks.
2. Select the user-defined host or composite health check to copy or to delete.
3. Click Copy or Delete, as applicable.

If the target does not match the source type, the copy operation fails and you
receive an error message.

Related CLI Syntax to Copy and to Delete a User-Defined Health Check
#(config health-check) copy source-alias target-alias

395

Volume 5: Advanced Networking
Section H: Managing User-Defined Health Checks

Copies settings from one health check to another, creating the target if
necessary.
#(config health-check) delete alias_name



396

Deletes the specified health check.

Section I: Viewing Health Check Statistics
The ProxySG presents a comprehensive list of all the health checks configured on
the appliance in the Statistics > Health Checks tab. You can view the details and
events for each health check in this screen, to edit the health checks, go to the
Configuration > Health Checks > General tab.
To view health checks on the ProxySG:

Select Statistics > Health Checks. The list of configured health checks displays.

About Health Check Statistics
The Statistics > Health Check panel provides a snapshot of all the health checks
configured on the device. By default, the screen is sorted by the name column. To
change the sort order, click any column header to sort by that column.
The Statistics > Health Check screen displays the following information:


Current time:



Last Boot:



Displays the current date and time.

Displays the date and time when the device was last booted.

Since Boot: Displays the time that the device has been functioning since the last

boot.


Status: Displays the summary of each health check configured on the ProxySG.



Name: The



State: The health check state is represented by an icon and a status
message. If the health check is disabled, it displays as:



health check name. Example, auth.blue_coat_iwa

Disabled: Healthy

397

Volume 5: Advanced Networking
Section I: Viewing Health Check Statistics



Disabled: Unhealthy
If the health check is enabled, the table below shows the messages
displayed:

Table 14–2 Status messages for enabled health checks

Status Message





398

Description

Health State

Unknown

Health has not yet been tested
successfully.

Healthy

OK

The target device or service is
completely healthy.

Healthy

OK with errors (multiple
IP addresses)

One or more IP addresses have
errors but none are down.

Healthy

OK for some IP
addresses (multiple IP
addresses)

One or more IP addresses are
down but not all.

Healthy

OK on alt server

The primary server has failed; the
realm is functioning on the
alternate server.

Healthy

Functioning but going
down (single IP address)

Failures are occurring; but the IP
address is still functioning.

Healthy

Check failed

Device or service cannot be used.

Unhealthy

DNS failed

The hostname cannot be resolved Unhealthy

Last check:



When:



Time:

Icon

Information on the last completed health check probe.

Time of the last check.

Response time of the last check.

Since last transition:

Displays aggregate values since the last transition between
healthy and unhealthy.


Duration:

Length of time since the last transition.



#Checks:

Number of health checks performed since the last transition.



Avg:



Min: Minimum response time. This statistic is not displayed for a health
check reporting unhealthy.



Max:

The mean response time since the last transition. This statistic is not
displayed for a health check reporting unhealthy.

Maximum response time. This statistic is not displayed for a health
check reporting unhealthy.



Details: This option is active only if a single row is selected. When you click
Details, it displays a new HTML window that contains detailed statistics on the

selected health check. For example, in a domain check, this display provides
an itemized explanation about each IP address in a domain.


Events:

This button is active only when a single row is selected. When you
click the button, it displays a new HTML window containing the filtered
event log entries for the selected health check.

399

Volume 5: Advanced Networking
Section I: Viewing Health Check Statistics

Interpreting Health Check Statistics
The Statistics > Health Check tab in the Management Console provides a snapshot of
all the health checks configured on the ProxySG. This screen allows you to glance
at the health checks for routine maintenance, to diagnose potential problems, and
to view health check failures.
The screenshot below shows the Statistics > Health Check panel along with an
explanation of the display.

400



The current time is 11:17 on January 23, 2008



Authentication realm Blue Coat IWA —auth.bc_iwa is functioning on its
alternate server for 17 minutes. The primary server failed just 17 minutes ago.



Authentication realm Blue Coat LDAP — auth.blue_coat_ldap is configured,
but is not currently referenced in policy.The health state is Unknown because it
is not being queried by the ProxySG for authentication lookups or for health
checks.



DNS server —dns.10.2.2.100 is functioning with errors, and it reports healthy
since boot. Select the row and click Events to view the expanded display about
the earlier failed health check.



DNS server —dns.10.2.2.101 is not functioning since 11:17 (for 18 minutes
now). Select the row and click Details to view the expanded display for the
health check.



DNS server 172.16.90.110 reports healthy and is stable since the device was
booted.



SOCKS gateway— socks.gateway1 is healthy and is operating for the last 3.7
hours. The average response time for this gateway is 65 ms.



DRTR service group — drtr.rating-service is healthy, and the average response
time is adequate. However the status icon shows that the service is
experiencing difficulties with some IP addresses. Select the row and click
Details to view the information on the configured IP addresses and the failure
points. The Details button displays the following information:
Domain name: sp.cwfservice.net

DNS status: success

Enabled OK for some IPs UP
IP address: 217.169.46.101

Enabled

OK

UP

Last status: Success.
Successes (total): 8
(consecutive): 8
Failures

(total): 0

(last): Wed, 23 Jan 2008 16:35:36 GMT
(last): Never (consecutive): 0 (external): 0

Last response time: 331 ms

Average response time: 357 ms

Minimum response time: 300 ms

Maximum response time: 613 ms

IP address: 65.160.238.181 Enabled

Check failed

DOWN

Last status: A communication error has occurred.
Successes (total): 0

(last): Never

(consecutive): 0

Failures (total): 3809 (last): Wed, 23 Jan 2008 16:45:09 GMT
(consecutive): 3809 (external): 0
Last response time: 9990 ms

Average response time: 9992 ms

Minimum response time: 9981 ms

Maximum response time: 10071 ms

IP address: 204.246.129.201 Enabled

OK

UP

Last status: Success.
Successes (total): 8
(consecutive): 6

(last): Wed, 23 Jan 2008 16:41:57 GMT

Failures (total): 15 (last): Wed, 23 Jan 2008 01:41:44 GMT
(consecutive): 0 (external): 0
Last response time: 104 ms

Average response time: 1133 ms

Minimum response time: 96 ms

Maximum response time: 6281 ms

IP address: 65.160.238.183

Enabled

Check failed

DOWN

Last status: A communication error has occurred.
Successes (total): 0

(last): Never

(consecutive): 0

Failures (total): 3809 (last): Wed, 23 Jan 2008 16:45:09 GMT
(consecutive): 3809 (external): 0
Last response time: 9991 ms

Average response time: 9993 ms

Minimum response time: 9981 ms

Maximum response time: 10067 ms



Forwarding host — fwd.google is functioning for 20.2 hours.



The forwarding host — fwd.my_ssh is healthy since boot.



ICAP service — icap.inbound and icap.outbound are healthy.



ICAP service — icap.test is disabled and configured to report healthy.
Disabled health checks appear grayed out on the screen.



SOCKS gateway — socks.personal is disabled and configured to report
unhealthy.

401

Volume 5: Advanced Networking
Section I: Viewing Health Check Statistics


402

The user-defined health check — user.public.dns.server is healthy.

Section J: Using Policy
The results of a health check can be affected through forwarding, SOCKS gateway,
or SSL certificate policy. The health check transactions execute the layer
and (for SSL or HTTPS tests) the layer to determine applicable policy.
This allows health check behavior to match as closely as possible to that of the SSL
traffic that the health check is monitoring.
Health checks cannot be deleted while referenced in policy. If a health check is
automatically deleted when its target is deleted, a reference to the health check in
policy can block deletion not only of the health check but of its target.
Two policy conditions exist for health checks:




health_check= : This condition tests whether the current transaction is a health
check transaction. Optionally, the condition tests whether the transaction is
that of a specific health check.
is_healthy.health_check_name=

: This condition tests whether the specified

health check is healthy.
Example: For a user-defined health check user.internet that gates access to a
popular Website and tests for Internet connectivity and responsiveness, you could
define policy to redirect traffic through a forwarding host if the health check fails.
To do this in policy:

is_healthy. user.internet = no forward(alternate_route)

For more information about using policy, refer to Volume 6: The Visual Policy
Manager and Advanced Policy and Volume 10: Content Policy Language Guide.

403

Volume 5: Advanced Networking
Section K: Related CLI Syntax to Configure Health Checks

Section K: Related CLI Syntax to Configure Health Checks


To enter health check mode:
SGOS#(config) health-check
SGOS#(config health-check)

Note: For detailed information about using these commands, refer to Volume

11: Command Line Interface Reference.


The following subcommands are available:
SGOS#(config health-check) copy source-alias target-alias
SGOS#(config health-check) create {composite alias_name | http
alias_name url | https alias_name url | icmp alias_name hostname| ssl
alias_name hostname [port]| tcp alias_name hostname [port]}
SGOS#(config health-check) default e-mail {healthy {enable |disable} |
report-all-ips {enable |disable} | sick {enable |disable}}
SGOS#(config health-check) default event-log {healthy { disable
|information |severe}| report-all-ips {enable |disable} | sick {enable
|disable}}
SGOS#(config health-check) default failure-trigger {none | count}
SGOS#(config health-check) default interval {healthy seconds| sick
seconds}
SGOS#(config health-check) default snmp {healthy {enable |disable} |
report-all-ips {enable |disable} | sick {enable |disable}}
SGOS#(config health-check) default severity {no-effect |warning
|critical}
SGOS#(config health-check) default threshold {healthy count |
response-time milliseconds | sick count}
SGOS#(config health-check) delete alias_name
SGOS#(config health-check) disable {healthy alias_name | sick
alias_name}
SGOS#(config health-check) edit health_check_name
(config health-check health_check_name) subcommands
SGOS#(config health-check) enable alias_name
SGOS#(config health-check) exit
SGOS#(config health-check) perform-health-check alias_name
SGOS#(config health-check) view {configuration |quick-statistics |
statistics}

404

Chapter 15: TCP/IP Configuration

This chapter describes the TCP/IP configuration options, which enhance the
performance and security of the ProxySG. Except for IP Forwarding (refer to
Volume 2: Proxies and Proxy Services), these commands are only available
through the CLI.

Topics in this Chapter
The following topics are discussed in this chapter:


"About the Options" on page 405



"RFC-1323" on page 406



"TCP NewReno" on page 406



"ICMP Broadcast Echo Support" on page 406



"ICMP Timestamp Echo Support" on page 406



"TCP Window Size" on page 407



"PMTU Discovery" on page 407



"TCP Time Wait" on page 408



"TCP Loss Recovery Mode" on page 408



"TCP Loss Recovery Mode" on page 408

About the Options


RFC-1323: Enabling RFC-1323 support enhances the high-bandwidth and
long-delay operation of the ProxySG appliances over very high-speed
paths, ideal for satellite environments.



TCP NewReno: Enabling TCP NewReno support improves the fast
recovery of the appliances.



ICMP Broadcast Echo: Disabling the response to these messages can limit
security risks and prevent an attacker from creating a distributed denial of
service (DDoS) to legitimate traffic.



ICMP Timestamp Echo: Disabling the response to these messages can
prevent an attacker from being able to reverse engineer some details of your
network infrastructure.



TCP Window Size: Configures the amount of unacknowledged TCP data
that the ProxySG can receive before sending an acknowledgement.



PMTU Discovery: Enabling PMTU Discovery prevents packets from being
unable to reach their destination because they are too large.

To view the TCP/IP configuration, see "TCP Loss Recovery Mode" on page 408.

405

Volume 5: Advanced Networking

RFC-1323
The RFC-1323 TCP/IP option enables the ProxySG to use a set of extensions to
TCP designed to provide efficient operation over large bandwidth-delay-product
paths and reliable operation over very high-speed paths, including satellite
environments. RFC-1323 support can be configured through the CLI and is
enabled by default.
To enable or disable RFC-1323 support:

At the (config) command prompt, enter the following command:
SGOS#(config) tcp-ip rfc-1323 {enable | disable}

TCP NewReno
NewReno is a modification of the Reno algorithm. TCP NewReno improves TCP
performance during fast retransmit and fast recovery when multiple packets are
dropped from a single window of data. TCP NewReno support is enabled by
default.
To enable or disable TCP NewReno support:

At the (config) command prompt, enter the following command:
SGOS#(config) tcp-ip tcp-newreno {enable | disable}

ICMP Broadcast Echo Support
Disabling the ICMP broadcast echo command can prevent the ProxySG from
participating in a Smurf Attack. A Smurf attack is a type of Denial-of-Service
(DoS) attack, where the attacker sends an ICMP echo request packet to an IP
broadcast address. This is the same type of packet sent in the ping command, but
the destination IP is broadcast instead of unicast. If all the hosts on the network
send echo reply packets to the ICMP echo request packets that were sent to the
broadcast address, the network is jammed with ICMP echo reply packets, making
the network unusable. By disabling ICMP broadcast echo response, the ProxySG
does not participate in the Smurf Attack.
This setting is disabled by default.
To enable or disable ICMP broadcast echo support:

At the (config) command prompt, enter the following command:
SGOS#(config) tcp-ip icmp-bcast-echo {enable | disable}

For more information on preventing DDoS attacks, see Chapter 3: "Preventing
Denial of Service Attacks" on page 79.

ICMP Timestamp Echo Support
By disabling the ICMP timestamp echo commands, you can prevent an attacker
from being able to reverse engineer some details of your network infrastructure.

406

Chapter 15: TCP/IP Configuration

For example, disabling the ICMP timestamp echo commands prevents an attack
that occurs when the ProxySG responds to an ICMP timestamp request by
accurately determining the target's clock state, allowing an attacker to more
effectively attack certain time-based pseudo-random number generators (PRNGs)
and the authentication systems on which they rely.
This setting is disabled by default.
To enable or disable ICMP Timestamp echo support:

At the (config) command prompt, enter the following command:
SGOS#(config) tcp-ip icmp-timestamp-echo {enable | disable}
PMTU Discovery

PMTU (Path Maximum Transmission Unit) is a mechanism designed to discover
the largest packet size sent that is not fragmented anywhere along the path
between two communicating appliances that are not directly attached to the same
link.
A ProxySG that is not running PMTU might send packets larger than that allowed
by the path, resulting in packet fragmentation at intermediate routers. Packet
fragmentation affects performance and can cause packet discards in routers that
are temporarily overtaxed.
A ProxySG doing PMTU sets the Do-Not-Fragment bit in the IP header when
transmitting packets. If fragmentation becomes necessary before the packets
arrive at the second ProxySG, a router along the path discards the packets and
returns an ICMP Host Unreachable error message, with the error condition of
Needs-Fragmentation, to the original ProxySG appliance. The first appliance then
reduces the PMTU size and re-transmits the transmissions.
The discovery period temporarily ends when the ProxySG estimates the PMTU is
low enough that its packets can be delivered without fragmentation or when the
ProxySG stops setting the Do-Not-Fragment bit.
Following discovery and rediscovery, the size of the packets that are transferred
between the two communicating nodes dynamically adjust to a size allowable by
the path, which might contain multiple segments of various types of physical
networks.
PMTU is disabled by default.
To configure PMTU discovery:

At the (config) command prompt:
SGOS#(config) tcp-ip pmtu-discovery {enable | disable}

TCP Window Size
Adjusting the TCP window-size regulates the amount of unacknowledged data
that the ProxySG receives before sending an acknowledgement.
To configure the TCP window size:

At the (config) command prompt, enter the following command:
SGOS#(config) tcp-ip window-size window_size

407

Volume 5: Advanced Networking
where window_size indicates the number of bytes allowed before
acknowledgement (the value must be between 8192 and 4194304).

TCP Time Wait
When a TCP connection is closed (such as when a user enters quit for an FTP
session), the TCP connection remains in the TIME_WAIT state for twice the
Maximum Segment Lifetime (MSL) before completely removing the connection
control block.
The TIME_WAIT state allows an end point (one end of the connection) to remove
remnant packets from the old connection, eliminating the situation where packets
from a previous connection are accepted as valid packets in a new connection.
The MSL defines how long a packet can remain in transit in the network. The
value of MSL is not standardized; the default value is assigned according to the
specific implementation.
To change the MSL value, enter the following commands at the (config) command
prompt:
SGOS#(config) tcp-ip tcp-2msl seconds

where seconds is the length of time you chose for the 2MSL value. Valid
values are 1 to 16380 inclusive.

TCP Loss Recovery Mode
A new TCP algorithm helps to recover throughput efficiently after packet losses
occur and also addresses performance problems due to a single packet loss during
a large transfer over long delay pipes. The feature is enhanced by default.
To enable the algorithm:
SGOS#(config) tcp-ip tcp-loss-recovery-mode {enhanced | aggressive}

To disable the algorithm:
SGOS#(config) tcp-ip tcp-loss-recovery-mode {normal}

Viewing the TCP/IP Configuration
To view the TCP/IP configuration:
SGOS#(config) show tcp-ip
RFC-1323 support:
TCP Newreno support:
IP forwarding:
ICMP bcast echo response:
ICMP timestamp echo response:
Path MTU Discovery:
TCP 2MSL timeout:
TCP window size:
TCP Loss Recovery Mode:

408

enabled
disabled
disabled
disabled
disabled
disabled
120 seconds
65535 bytes
Aggressive

Chapter 16: Virtual IP Addresses

This chapter discusses the uses of Virtual IP (VIP) addresses and how to create
them.
Virtual IP addresses are addresses assigned to a system (but not an interface)
that are recognized by other systems on the network. Up to 255 VIPs can be
configured on each ProxySG appliance.

Topics in this Chapter
This chapter includes information about the following topics:


"Uses of a VIP" on page 409



"Creating a VIP" on page 409

Uses of a VIP
VIP addresses have several uses:


Assign multiple identities to a system on the same or different network,
partitioning the box in to separate logical entities for resource sharing or
load sharing.



Create an HTTPS Console to allow multiple, simultaneous, secure
connections to the system.



Direct authentication challenges to different realms.



Set up failover among multiple ProxySG appliances on the same subnet.

Note: For information on creating an HTTPS Console, refer to Volume 2: Proxies

and Proxy Services; for information on using VIPs with authentication realms,
refer to Volume 4: Securing the Blue Coat ProxySG Appliance; to use VIPs with
failover, see Chapter 7: "Configuring Failover" on page 125.

Creating a VIP
To create a VIP:

1. Select Configuration > Network > Advanced > VIPs.
2. Click New.
3. Enter the virtual IP address you want to use. It can be any IP address,
except a multicast address. (A multicast address is a group address, not an
individual IP address.)

409

Volume 5: Advanced Networking

Note: You cannot create a VIP address that is the IP address used by the

origin content server. You must assign a different address on the ProxySG,
and use DNS or forwarding to point to the origin content server's real IP
address.
4. Click OK.
5. Click Apply.
The VIP address can now be used.

Related CLI Syntax to manage a VIP
SGOS#(config) virtual address ip_address
SGOS#(config) virtual no address ip_address
SGOS#(config) virtual clear
SGOS#(config) show virtual

410

Chapter 17: WCCP Settings

The SGOS software can be configured to participate in a WCCP (Web Cache
Control Protocol) scheme, in which a WCCP-capable router collaborates with a
set of WCCP-configured ProxySG appliances to service requests.

Topics in this Chapter
This chapter includes information about the following topics:


"Configuring WCCP" on page 411



"Viewing WCCP Statistics and Service Group Status" on page 415

Configuring WCCP
WCCP is a Cisco®-developed protocol that allows you to establish redirection
of the traffic that flows through routers.
Note: Blue Coat recommends that WCCP-compliant caches from different
vendors be kept separate and that only one vendor’s routers be used in a
service group.

One of the caches participating in the WCCP service group is automatically
elected as the designated cache to configure the home router’s redirection
tables. This way, caches can be transparently added and removed from the
WCCP service group without requiring operator intervention. WCCP version 2
supports multiple service groups.
For detailed information on using WCCP with a ProxySG, refer to the WCCP
Reference Guide.

Procedure Overview
Two tasks must be completed to get WCCP running with the ProxySG:


Configuring the router



Configuring the ProxySG

WCCP Router Configuration
1. From the router (config) mode, tell WCCP which service group you want
use. The Web-cache service group redirects port 80 (HTTP) traffic only.
Create other service groups to redirect traffic from other ports.
Router(config) #ip wccp web-cache

2. Enter the (config-if) submode by telling WCCP which IP address to use.
Router(config)# int interface

411

Volume 5: Advanced Networking
where interface is the adapter interface with an IP address. The prompt
changes to configuration interface submode.
3. Enable packet redirection on the LAN (inbound) interface.
Router(config-if)# ip wccp web-cache redirect in

4. If L2 packet return is enabled, prevent those return packets from being
considered for WCCP redirection by running the following command on the
interface used to communicate with the ProxySG:
Router(config-if)# ip wccp redirect exclude in

For more information on WCCP router configuration, refer to the WCCP Reference
Guide.

ProxySG Configuration
The Management Console provides a text editor that can be used to create the
configuration file. The ProxySG configuration file is used to tell the Cisco device
how to use WCCP with this cache (the ProxySG).
Note: You can also create the file off-box, downloading the file from a
ProxySG-accessible Web server or uploading the file from a local system.

An example of a WCCP configuration file is:
wccp enable
wccp version 2
service-group 9
forwarding-type L2
assignment-type mask
mask-scheme source-port
priority 1
protocol 6
service-flags destination-ip-hash
service-flags ports-defined
ports 80 21 1755 554 0 0 0 0
interface 0:0
home-router 10.16.18.2
end

For descriptions of the values in the configuration file, refer to the WCCP Reference
Guide.
To install the configuration file:

1. Select Configuration > Network > Advanced >WCCP.

412

Chapter 17: WCCP Settings

2. (Optional): View the WCCP settings that are currently on the system or view
the text file with the current settings by going to the View WCCP Settings panel
and clicking WCCP Settings or Source.
3. In the Install WCCP Settings panel, select the location of the configuration file: a
remote URL, a local file, or you can use the text editor on the system.
4. Click Install.
If you selected Remote URL or Local File, a dialog opens that allows you to enter
the complete path, and the file is retrieved.
If you selected Text Editor, the text editor displays with the current settings. You
can copy and paste the contents of an existing configuration file or you can
enter new text and click Install when finished.
5. If the configuration file contains the line wccp enable, WCCP is automatically
enabled when the WCCP configuration is installed. Otherwise, you must
specifically enable WCCP on the ProxySG. To do this, go the WCCP Statistics
panel and click Enable WCCP.
Note: If you enable or disable WCCP, the action is completed immediately.

6. Click Apply to save the changes.
To view WCCP status:

1. Select Configuration > Network > Advanced >WCCP.

413

Volume 5: Advanced Networking

2. To enable or disable WCCP, click Enable/Disable WCCP.
3. The current status of the WCCP services are in the pane below the Enable/
Disable WCCP button.
a. You can use Refresh WCCP Statistics to update WCCP statistics. The last
refresh time is displayed.
b. Redirected packets, either GRE or Layer 2, are displayed. The
redirected packets value is reset when WCCP is disabled.
c. Service Groups: Lists details on the available service groups


The Cache IP address is the designated Web cache (the ProxySG with the
lowest IP address) for the service group.



The Router IP address is also the router ID.

d. State: Displays the availability of the service group.Messages include:

414



Idle: Before the first Here I Am protocol message is sent.



Waiting: Here I Am protocol message is sent; waiting for the I See You
message to be returned.



Negotiating: I See You protocol message received.



Capability Mismatch: I See You protocol message parsed, but the
router/ProxySG WCCP capabilities do not match.



Packet Forwarding Mismatch: I See You protocol message parsed, but
a forwarding-type mismatch was found.



Packet Return Mismatch: I See You protocol message parsed, but a
return-type mismatch was found.

Chapter 17: WCCP Settings



Assignment Mismatch: I See You protocol message parsed, but an
assignment-type mismatch was found.



Service Group Mismatch: I See You protocol message parsed, but a
service-group mismatch was found



Security Mismatch: I See You protocol message parsed, but a security
mismatch was found.



Bad Router ID: I See You protocol message parsed, but a bad router ID
component was found.



Bad Router View: I See You protocol message parsed, but a bad router
view component was found.



Ready: Redirect Assignment protocol messages sent.

e. Protocol messages: Lists the number of packets sent and received:


Here I Am: Announces the ProxySG presence to the routers.



I See You: Router acknowledges the ProxySG



Redirect Assignments: ProxySG sends assignment requests.

To create a ProxySG WCCP configuration file and enable WCCP using the CLI:

1. Create a WCCP configuration file through either the ProxySG appliance’s CLI
inline commands or through a text editor.
2. Make sure that the home router you enter here is the home router that was
named in the router’s configuration. If there is a mismatch, you must correct it
before continuing. For troubleshooting information, refer to the WCCP
Reference Guide.
3. Next steps:
a. If you used the inline commands, you have completed WCCP
configuration on the ProxySG. No further steps are needed.
b. If you used a text editor, copy the file to an HTTP server accessible to
the ProxySG. Then, enable WCCP and download the configuration file
to the ProxySG.
SGOS#(config) wccp enable
SGOS#(config) wccp path http://10.25.36.47/files/wccp.txt
SGOS#(config) load wccp-settings

Viewing WCCP Statistics and Service Group Status
Viewing WCCP Settings
You can view the following WCCP statistics through the CLI show wccp command
options:


configuration



statistics



service-group status

415

Volume 5: Advanced Networking

Configuration
This command displays the configuration for each service group on the system.
SGOS# show wccp configuration
;WCCP Settings
;Version 1.3
wccp enable
wccp version 2
service-group 29
forwarding-type GRE
assignment-type hash
priority 1
protocol 6
service-flags source-ip-hash
service-flags ports-defined
ports 8080 0 0 0 0 0 0 0
interface 0:0
home-router 10.25.36.47
end

Statistics
WCCP statistics are repeated for each service group on the system.
SGOS# show wccp statistics
;WCCP Statistics
;Version 1.3
Current time
Last stats reset time

:Tue, Mar 11 2008 21:36:40 UTC
:Tue, Mar 11 2008 20:21:04 UTC

Packets sent
:1,374
Bytes sent
:165,852
Packet received
:1,342
Bytes received
:187,536
Bad packets received :0
Receive error
:0
Unknown type
:0
Total size too small:0
Header too small
:0
Bad version
:0
Bad security comp
:0
Bad service info comp:0
Bad query info comp :0
Unknown group
:0
Unsolicited query
:0
Bad router id comp :0
Bad router view comp:0
Service group mismatch:0
Forwarding type mismatch:0
Returning type mismatch:0
Assignment type mismatch:0
Capability mismatch :0
Bad security packets :0
Internal errors
:0
Failed to send
:0
Add RID for router :0
Alloc query member :0
Alloc query timer
:0

416

Chapter 17: WCCP Settings

Add router to group :0
Add cache to group :0
Alloc active caches :0
Bucket reassignment :0
Allocated blocks
:4
Service Group ident. :512,1,29, 1,6,17, 8080,0,0,0,0,0,0,0
Home Routers
:10.25.36.47
Multicast TTL
:1
Forwarding type
:GRE
Returning type
:GRE
Assignment type
:hash
Hotspots announced :0
Assignment state
:idle
Designated Cache
:10.25.36.48
Announcement key # :2
Cache view change # :9
Router View Changed :0
Recent hit count
:0
Primary hit count
:0
Alternate hit count :0
Total ip payload bytes redirected:0
Total gre payload bytes redirected:0

Service Group Status
Through the CLI, you can view the output of the show wccp status command. The
output is repeated for each service group.
SGOS> show wccp status
;WCCP Status
;Version 2

Number of GRE redirected packets: 0
Number of Layer 2 redirected packets: 0
Service group: 9
State: Ready
Number of Here_I_Am sent: 514
Number of I_See_You received: 502
Number of Redirect_Assign sent: 2
Router IP: 10.25.36.47
Cache IP: *10.25.36.48

417

Volume 5: Advanced Networking

418

Appendix A: Using Policy to Manage Forwarding

After ICP, forwarding, and the SOCKS gateways are configured, use policy to
create and manage forwarding rules. Forwarding, ICP, and SOCKS gateway
rules should go in the layer of the Forwarding Policy file or the VPM
Policy file (if you use the VPM).
The separate layer is provided because the URL can undergo URL
rewrites before the request is fetched. This rewritten URL is accessed as a
server_url and decisions about upstream connections are based on the
rewritten URL, requiring a separate layer. All policy commands allowed in the
layer are described below.
Table A–1 Policy Commands Allowed in the Layer

Forward

Description

Conditions
client_address=

Tests the IP address of the client. Can also be used in
and layers.

client.host=

Tests the hostname of the client (obtained through RDNS).
Can also be used in , , and
layers.

client.host.has_name=

Tests the status of the RDNS performed to determine
client.host. Can also be used in , , and
layers.

client.protocol=

Tests true if the client transport protocol matches the
specification. Can also be used in and
layers.

date[.utc]=

Tests true if the current time is within the
startdate..enddate range, inclusive. Can be used in all
layers.

day=

Tests if the day of the month is in the specified range or an
exact match. Can be used in all layers.

has_client=

has_client= is used to test whether or not the current
transaction has a client. This can be used to guard triggers
that depend on client identity.

hour[.utc]=

Tests if the time of day is in the specified range or an exact
match. Can be used in all layers.

im.client=

Tests the type of IM client in use. Can also be used in
, , and layers.

im.message.reflected=

Tests whether IM reflection occurred. Can also be used in
and layers.

419

Volume 5: Advanced Networking
Table A–1 Policy Commands Allowed in the Layer (Continued)

Forward

Description

minute[.utc]=month[.utc]=

Tests if the minute of the hour is in the specified range or
an exact match. Can be used in all layers.

proxy.address=

Tests the IP address of the network interface card (NIC) on
which the request arrives. Can also be used in
and layers.

proxy.card=

Tests the ordinal number of the network interface card
(NIC) used by a request. Can also be used in and
layers.

proxy.port=

Tests if the IP port used by a request is within the specified
range or an exact match. Can also be used in and
layers.

server_url[.case_sensitive|.no_
lookup]=

Tests if a portion of the requested URL exactly matches the
specified pattern.

server_url.address=

Tests if the host IP address of the requested URL matches
the specified IP address, IP subnet, or subnet definition.

server_url.domain[.case_sensitive]
[.no_lookup]=

Tests if the requested URL, including the domain-suffix
portion, matches the specified pattern.

server_url.extension[.case_
sensitive]=

Tests if the filename extension at the end of the path
matches the specified string.

server_url.host.has_name=

Tests whether the server URL has a resolved DNS
hostname.

server_url.host[.exact|.substring|
.prefix|.suffix|.regex][.no_lookup
]=

Tests if the host component of the requested URL matches
the IP address or domain name.

server_url.host.is_numeric=

This is true if the URL host was specified as an IP address.

server_url.host.no_name=

This is true if no domain name can be found for the URL
host.

server_url.host.regex=

Tests if the specified regular expression matches a
substring of the domain name component of the requested
URL.

server_url.is_absolute=

Tests whether the server URL is expressed in absolute
form.

server_url.path[.exact|.substring|
.prefix|.suffix|.regex]
[.case_sensitive]=

Tests if a prefix of the complete path component of the
requested URL, as well as any query component, matches
the specified string.

server_url.path.regex=

Tests if the regex matches a substring of the path
component of the request URL.

server_url.port=

Tests if the port number of the requested URL is within the
specified range or an exact match.

420

Appendix A: Using Policy to Manage Forwarding
Table A–1 Policy Commands Allowed in the Layer (Continued)

Forward

Description

server_url.query.regex=

Tests if the regex matches a substring of the query string
component of the request URL.

server_url.regex=

Tests if the requested URL matches the specified pattern.

server_url.scheme=

Tests if the scheme of the requested URL matches the
specified string.

socks=

This condition is true whenever the session for the current
transaction involves SOCKS to the client.

socks.version=

Switches between SOCKS 4/4a and 5. Can also be used in
and layers.

streaming.client=

yes | no. Tests the user agent of a Windows, Real Media,

or QuickTime player.
time[.utc]=

Tests if the time of day is in the specified range or an exact
match. Can be used in all layers.

tunneled=

yes | no. Tests TCP tunneled requests, HTTP CONNECT
requests, and unaccelerated SOCKS requests

weekday[.utc]=

Tests if the day of the week is in the specified range or an
exact match. Can be used in all layers.

year[.utc]=

Tests if the year is in the specified range or an exact match.
Can be used in all layers.

Properties
access_server()

Determines whether the client can receive streaming
content directly from the OCS. Set to no to serve only
cached content.

ftp.transport()

Determines the upstream transport mechanism.
This setting is not definitive. It depends on the capabilities
of the selected forwarding host.

forward()

Determines forwarding behavior.
There is a box-wide configuration setting
(config>forwarding>failure-mode) for the forward
failure mode. The optional specific settings can be used to
override the default.

forward.fail_open()

Controls whether the ProxySG appliance terminates or
continues to process the request if the specified
forwarding host or any designated backup or default
cannot be contacted.

http.refresh.recv.timeout()

Sets the socket timeout for receiving bytes from the
upstream host when performing refreshes. Can also be
used in layers.

421

Volume 5: Advanced Networking
Table A–1 Policy Commands Allowed in the Layer (Continued)

Forward

Description

http.server.connect_attempts()

Sets the number of attempts to connect performed peraddress when connecting to the upstream host.

http.server.recv.timeout()

Sets the socket timeout for receiving bytes from the
upstream host. Can also be used in layers.

icp()

Determines when to consult ICP. The default is yes if ICP
hosts are configured and if no forwarding host or SOCKS
gateway is identified as an upstream target.

im.transport()

Sets the type of upstream connection to make for IM
traffic.

integrate_new_hosts()

Determines whether to add new host addresses to health
checks and load balancing. The default is no. If it is set to
yes, any new host addresses encountered during DNS
resolution of forwarding hosts are added to health checks
and load balancing.

reflect_ip()

Determines how the client IP address is presented to the
origin server for explicitly proxied requests. Can also be
used in layers.

socks_gateway()

The socks_gateway() property determines the gateway
and the behavior of the request if the gateway cannot be
contacted.
There is a box-wide configuration setting for the SOCKS
failure mode. The optional specific settings can be used to
override the default.

socks_gateway.fail_open()

Controls whether the ProxySG terminates or continues to
process the request if the specified SOCKS gateway or any
designated backup or default cannot be contacted.

streaming.transport()

Determines the upstream transport mechanism. This
setting is not definitive. The ability to use
streaming.transport() depends on the capabilities of
the selected forwarding host.

trace.request()

Determines whether detailed trace output is generated for
the current request. The default value is no, which
produces no output

trace.rules()

Determines whether trace output is generated that shows
each policy rule that fired. The default value of no
suppresses output.

trace.destination()

Used to change the default path to the trace output file. By
default, policy evaluation trace output is written to an
object in the cache accessible using a console URL of the
following form:
http://ProxySG_ip_address:8082/Policy/
Trace/path

422

Appendix A: Using Policy to Manage Forwarding
Table A–1 Policy Commands Allowed in the Layer (Continued)

Forward

Description

Actions
notify_email()

Sends an e-mail notification to the list of recipients
specified in the Event Log mail configuration. Can be used
in all layers.

notify_snmp()

The SNMP trap is sent when the transaction terminates.
Can be used in all layers.

log_message

Writes the specified string to the event log.

Definitions
define server_url.domain condition
name

Binds a user-defined label to a set of domain suffix
patterns for use in a condition= expression.

423

Volume 5: Advanced Networking

424

Glossary

A
access control list—Allows

or denies specific IP addresses access to a server.

access log—A list of all the requests sent to a ProxySG. You can read an access
log using any of the popular log-reporting programs. When a client uses HTTP
streaming, the streaming entry goes to the same access log.
account—A

named entity that has purchased the ProxySG or the Entitlements
from Blue Coat.
activation code—A

string of approximately 10 characters that is generated and
mailed to customers when they purchase the ProxySG.

active content stripping—Provides a way to identify potentially dangerous mobile

or active content and scripts, and strip them out of a response.
active content types—Used in the Visual Policy Manager. Referring to Web
Access policies, you can create and name lists of active content types to be
stripped from Web pages. You have the additional option of specifying a
customized message to be displayed to the user
administration access policy—A

policy layer that determines who can access the
ProxySG to perform administrative tasks.

administration authentication policy—A

policy layer that determines how
administrators accessing the ProxySG must authenticate.
AJAX—Acronym

for Asynchronous JavaScript and XML, the technology used
for live updating of Web objects without having to reload the entire page.

Application Delivery Network (ADN)—A

WAN that has been optimized for
acceleration and compression by Blue Coat. This network can also be secured
through the use of appliance certificates. An ADN network is composed of an
ADN manager and backup ADN manager, ADN nodes, and a network
configuration that matches the environment.
ADN backup manager—Takes over for the ADN manager in the event it becomes
unavailable. See ADN manager.
ADN manager—Responsible for publishing the routing table to SG Clients (and
to other ProxySG appliances).
ADN optimize attribute—Controls whether to optimize bandwidth usage when
connecting upstream using an ADN tunnel.
A record—The central records of DNS, which

link a domain or subdomain to an
IP address. An A record can correspond to a single IP address or many IP
addresses.

asx rewrite—Allows you to rewrite URLs and then direct a client's subsequent
request to the new URL. One of the main applications of ASX file rewrites is to
provide explicit proxy-like support for Windows Media Player 6.4, which
cannot set explicit proxy mode for protocols other than HTTP.

425

Volume 5: Advanced Networking

audit—A

log that provides a record of who accessed what and how.

authenticate-401 attribute—All transparent and explicit requests received on the port
always use transparent authentication (cookie or IP, depending on the
configuration). This is especially useful to force transparent proxy authentication
in some proxy-chaining scenarios
authenticated content—Cached content that requires authentication at the origin
content server (OCS). Supported authentication types for cached data include
basic authentication and IWA (or NTLM).
authentication—Allows you to verify the identity of a user. In its simplest form, this

is done through usernames and passwords. Much more stringent authentication
can be employed using digital certificates that have been issued and verified by a
Certificate Authority. See also basic authentication, proxy authentication, and SSL
authentication.
authentication realm—Authenticates

and authorizes users to access SG services
using either explicit proxy or transparent proxy mode. These realms integrate
third-party vendors, such as LDAP, Windows, and Novell, with the Blue Coat
operating system.

authorization—The

permissions given to an authenticated user.

B
bandwidth—The

amount of data you can send through a network or modem
connection, usually measured in bits per second (bps).

bandwidth class—A defined

unit of bandwidth allocation.

bandwidth class hierarchy—A gouping of bandwidth classes into a tree structure
that specifies the relationship among different classes. You create a hierarchy by
creating at least one parent class and assigning other classes as its children.
bandwidth gain—Bandwidth

gain is a calculation of the savings that occur when
bandwidth is not consumed as a result of some form of optimization.
For example, bandwidth gain for active sessions is calculated by subtracting the
number of client bytes from the number of server bytes and dividing the result by
the number of server bytes.
(Client Bytes - Server Bytes) / Server Bytes

bandwidth management—Classify,

control, and, if needed, limit the amount of
bandwidth used by network traffic flowing in or out of a ProxySG.

basic authentication—The

standard authentication for communicating with the
target as identified in the URL.

BCAAA—Blue Coat Authentication and Authorization Agent. Allows SGOS 5.x to
manage authentication and authorization for IWA, CA eTrust SiteMinder realms,
Oracle COREid, Novell, and Windows realms. The agent is installed and
configured separately from SGOS 5.x and is available from the Blue Coat Web site.
BCLP—Blue

Coat Licensing Portal.

byte-range support—The

ability of the ProxySG to respond to byte-range requests
(requests with a Range: HTTP header).

426

C
cache—An

"object store," either hardware or software, that stores information
(objects) for later retrieval. The first time the object is requested, it is stored,
making subsequent requests for the same information much faster.

A cache helps reduce the response time and network bandwidth consumption on
future, equivalent requests. The ProxySG serves as a cache by storing content
from many users to minimize response time and prevent extraneous network
traffic.
cache control—Allows

you to configure which content the ProxySG stores.

cache efficiency—A tab found on the Statistics pages of the Management Console
that shows the percent of objects served from cache, the percent loaded from the
network, and the percent that were non-cacheable.
cache hit—Occurs when the ProxySG receives a request for an object and can serve

the request from the cache without a trip to the origin server.
cache miss—Occurs

when the ProxySG receives a request for an object that is not
in the cache. The ProxySG must then fetch the requested object from the origin
server.

cache object—Cache contents includes all objects currently stored by the ProxySG.
Cache objects are not cleared when the ProxySG is powered off.
Certificate Authority (CA)—A

trusted, third-party organization or company that
issues digital certificates used to create digital signatures and public key/private
key pairs. The role of the CA is to guarantee that the individuals or company
representatives who are granted a unique certificate are who they claim to be.

child class (bandwidth gain)—The child of a parent class is dependent on that parent
class for available bandwidth (they share the bandwidth in proportion to their
minimum/maximum bandwidth values and priority levels). A child class with
siblings (classes with the same parent class) shares bandwidth with those siblings
in the same manner.
cipher suite—Specifies the algorithms used to secure an SSL connection. When a
client makes an SSL connection to a server, it sends a list of the cipher suites that it
supports.
client consent certificates—A certificate that indicates acceptance or denial of
consent to decrypt an end user's HTTPS request.
client-side transparency—A

way of replacing the ProxySG IP address with the Web
server IP address for all port 80 traffic destined to go to the client. This effectively
conceals the ProxySG address from the client and conceals the identity of the
client from the Web server.

concentrator—A

ProxySG, usually located in a data center, that provides access to
data center resources, such as file servers.
content filtering—A way of controlling which content is delivered to certain users.
ProxySG appliances can filter content based on content categories (such as
gambling, games, and so on), type (such as http, ftp, streaming, and mime type),
identity (user, group, network), or network conditions. You can filter content
using vendor-based filtering or by allowing or denying access to URLs.

427

Volume 5: Advanced Networking

D
default boot system—The system that was successfully started last time. If a system
fails to boot, the next most recent system that booted successfully becomes the
default boot system.
default proxy listener—See

proxy service (default).

denial of service (DoS)—A

method that hackers use to prevent or deny legitimate
users access to a computer, such as a Web server. DoS attacks typically send many
request packets to a targeted Internet server, flooding the server's resources and
making the system unusable. Any system connected to the Internet and equipped
with TCP-based network services is vulnerable to a DoS attack.
The ProxySG resists DoS attacks launched by many common DoS tools. With a
hardened TCP/IP stack, the ProxySG resists common network attacks, including
traffic flooding.

destination objects—Used

in Visual Policy Manager. These are the objects that
define the target location of an entry type.

detect protocol attribute—Detects the protocol being used. Protocols that can be
detected include: HTTP, P2P (eDonkey, BitTorrent, FastTrack, Gnutella), SSL, and
Endpoint Mapper.
diagnostic reporting—Found in the Statistics pane, the Diagnostics tab allows you to

control whether Daily Heartbeats and/or Blue Coat Monitoring are enabled or
disabled.
directives—Commands used in installable lists to configure forwarding and
SOCKS gateway.
DNS access—A

policy layer that determines how the ProxySG processes DNS

requests.
domain name system (DNS)—An

Internet service that translates domain names into

IP addresses.
dynamic bypass—Provides a maintenance-free method for improving performance
of the ProxySG by automatically compiling a list of requested URLs that return
various kinds of errors.
dynamic real-time rating (DRTR)—Used

in conjunction with the Blue Coat Web Filter
(BCWF), DRTR (also known as dynamic categorization) provides real-time analysis
and content categorization of requested Web pages to solve the problem of new
and previously unknown uncategorized URLs—those not in the database.
When a user requests a URL that has not already been categorized by the BCWF
database (for example, a brand new Web site), the ProxySG dynamic
categorization service analyzes elements of the requested content and assigns a
category or categories. The dynamic service is consulted only when the installed
BCWF database does not contain category information for an object.

E
early intercept attribute—Controls

whether the proxy responds to client TCP
connection requests before connecting to the upstream server. When early
intercept is disabled, the proxy delays responding to the client until after it has
attempted to contact the server.

428

ELFF-compatible format—A

log type defined by the W3C that is general enough to
be used with any protocol.
emulated certificates—Certificates

that are presented to the user by the ProxySG
when intercepting HTTPS requests. Blue Coat emulates the certificate from the
server and signs it, copying the subjectName and expiration. The original
certificate is used between the ProxySG and the server.

encrypted log—A

log is encrypted using an external certificate associated with a
private key. Encrypted logs can only be decrypted by someone with access to the
private key. The private key is not accessible to the ProxySG.

EULA—End

user license agreement.

event logging—Allows you to specify the types of system events logged, the size of

the event log, and to configure Syslog monitoring. The ProxySG can also notify
you by email if an event is logged. See also access logging.
explicit proxy—A configuration in which the browser is explicitly configured to
communicate with the proxy server for access to content. This is the default for
the ProxySG and requires configuration for both the browser and the interface
card.
extended log file format (ELFF)—A variant of the common log file format, which has
two additional fields at the end of the line—the referer and the user agent fields.

F
fail open/closed—Failing

open or closed applies to forwarding hosts and groups
and SOCKS gateways. Fail open or closed applies when health checks are
showing sick for each forwarding or SOCKS gateway target in the applicable failover sequence. If no systems are healthy, the ProxySG fails open or closed,
depending on the configuration. If closed, the connection attempt simply fails.
If open, an attempt is made to connect without using any forwarding target (or
SOCKS gateway). Fail open is usually a security risk; fail closed is the default if no
setting is specified.

filtering—See

content filtering.

forward proxy—A

proxy server deployed close to the clients and used to access
many servers. A forward proxy can be explicit or transparent.

FTP—See

Native FTP and Web FTP.

G
gateway—A

device that serves as entrance and exit into a communications

network.

H
hardware serial number—A string that uniquely identifies the ProxySG; it is assigned

to each unit in manufacturing.
health check tests—The method of determining network connectivity, target
responsiveness, and basic functionality. The following tests are supported:

429

Volume 5: Advanced Networking



ICMP



TCP



SSL



HTTP



HTTPS



Group



Composite and reference to a composite result



ICAP



Websense



DRTR rating service

health check type—The kind of device or service the specific health check tests. The
following types are supported:



Forwarding host and forwarding group



SOCKS gateway and SOCKS gateway group



CAP service and ICAP service group



Websense off-box service and Websense off-box service group



DRTR rating service



User-defined host and a user-defined composite

heartbeat—Messages

sent once every 24 hours that contain the statistical and
configuration data for the ProxySG, indicating its health. Heartbeats are
commonly sent to system administrators and to Blue Coat. Heartbeats contain no
private information, only aggregate statistics useful for pre-emptively diagnosing
support issues.
The ProxySG sends emergency heartbeats whenever it is rebooted. Emergency
heartbeats contain core dump and restart flags in addition to daily heartbeat
information.

host affinity—The

attempt to direct multiple connections by a single user to the
same group member. Host affinity is closely tied to load balancing behavior; both
should be configured if load balancing is important.

host affinity timeout—The host affinity timeout determines how long a user remains

idle before the connection is closed. The timeout value checks the user's IP
address, SSL ID, or cookie in the host affinity table.

I
inbound traffic (bandwidth gain)—Network

packets flowing into the ProxySG.
Inbound traffic mainly consists of the following:


430

Server inbound: Packets originating at the origin content server (OCS) and
sent to the ProxySG to load a Web object.



Client inbound: Packets originating at the client and sent to the ProxySG
for Web requests.

installable list—A

list of configuration parameters that can be created using a text
editor (either Blue Coat or another text editor) or through the CLI inline
commands. The list can then be downloaded to the ProxySG from an HTTP server
or locally from your PC. Configurations that can be created and installed this way
include the SG Client, archiving, forwarding hosts, SOCKS gateways, ICP, policy
files, and exceptions.
integrated host timeout—An

integrated host is an origin content server (OCS) that
has been added to the health check list. The host, added through the
integrate_new_hosts property, ages out of the integrated host table after
being idle for the specified time. The default is 60 minutes.

intervals—Time

period from the completion of one health check to the start of the
next health check.

IP reflection—Determines how the client IP address is presented to the origin server

for explicitly proxied requests. All proxy services contain a reflect-ip attribute,
which enables or disables sending of client's IP address instead of the IP address
of the ProxySG.
issuer keyring—The keyring used by the ProxySG to sign emulated certificates. The

keyring is configured on the appliance and managed through policy.

L
licensable component (LC)—(Software)

A subcomponent of a license; it is an option
that enables or disables a specific feature.

LCAMS—License

Configuration and Management System.

license—Provides

both the right and the ability to use certain software functions
within a ProxyAV (or ProxySG) appliance. The license key defines and controls
the license, which is owned by an account.

listener—The service that is listening on a specific port. A listener can be identified

by any destination IP/subnet and port range. Multiple listeners can be added to
each service.
live content—Also

called live broadcast. Used in streaming, it indicates that the
content is being delivered fresh.

LKF—License

key file.

load balancing—A

way to share traffic requests among multiple upstream systems
or multiple IP addresses on a single host.

local bypass list—A

list you create and maintain on your network. You can use a
local bypass list alone or in conjunction with a central bypass list.

local policy file—Written by enterprises (as opposed to the central policy file written

by Blue Coat); used to create company- and department-specific advanced
policies written in the Blue Coat Policy Language (CPL).

431

Volume 5: Advanced Networking

log facility—A

separate log that contains a single logical file and supports a single
log format. It also contains the file’s configuration and upload schedule
information as well as other configurable information such as how often to rotate
(switch to a new log) the logs at the destination, any passwords needed, and the
point at which the facility can be uploaded.

log format—The type of log that is used: NCSA/Common, SQUID, ELFF,
SurfControl, or Websense.

The proprietary log types each have a corresponding pre-defined log format that
has been set up to produce exactly that type of log (these logs cannot be edited). In
addition, a number of other ELFF type log formats are also pre-defined (im, main,
p2p, ssl, streaming). These can be edited, but they start out with a useful set of log
fields for logging particular protocols understood by the ProxySG. It is also
possible to create new log formats of type ELFF or Custom which can contain any
desired combination of log fields.
log tail—The access log tail shows the log entries as they get logged. With high
traffic on the ProxySG, not all access log entries are necessarily displayed.
However, you can view all access log information after uploading the log.

M
MACH5—SGOS

5 MACH5 Edition.

Management Console—A

graphical Web interface that lets you to manage,
configure, monitor, and upgrade the ProxySG from any location. The
Management Console consists of a set of Web pages and Java applets stored on
the ProxySG. The appliance acts as a Web server on the management port to serve
these pages and applets.

management information base (MIB)—Defines

the statistics that management systems
can collect. A managed device (gateway) has one or more MIBs as well as one or
more SNMP agents, which implements the information and management
functionality defined by a specific MIB.

maximum object size—The

maximum object size stored in the ProxySG. All objects
retrieved that are greater than the maximum size are delivered to the client but are
not stored in the ProxySG.

Media Access Control (MAC) address—A

unique value associated with a network
adapter; also known as hardware address or physical address. For the ProxySG, it
is a hardware address that is stored in each network card (such as an SSL
accelerator card or a Quad GigE Fiber LX card) on the ProxySG. The MAC
address uniquely identifies an adapter on a LAN and is a 12-digit hexadecimal
number (48 bits in length).
MIME/FILE type filtering—Allows

organizations to implement Internet policies for
both uploaded and downloaded content by MIME or FILE type.
multi-bit rate—The capability of a single stream to deliver multiple bit rates to
clients requesting content from ProxySG appliances from within varying levels of
network conditions (such as different connecting bandwidths and traffic).
multicast—Used

in streaming; the ability for hundreds or thousands of users to
play a single stream.

432

multicast aliases—Used

in streaming; a streaming command that specifies an alias
for a multicast URL to receive an .nsc file. The .nsc files allows the multicast
session to obtain the information in the control channel
multicast station—Used in streaming; a defined location on the proxy where the
Windows Media player can retrieve streams. A multicast station enables multicast
transmission of Windows Media content from the cache. The source of the
multicast-delivered content can be a unicast-live source, a multicast (live) source,
and simulated live (video-on-demand content converted to scheduled live
content).
multimedia content services—Used

in streaming; multimedia support includes Real
Networks, Microsoft Windows Media, Apple QuickTime, MP3, and Flash.

N
name inputing—Allows a ProxySG to resolve host names based on a partial name
specification. When a host name is submitted to the DNS server, the DNS server
resolves the name to an IP address. If the host name cannot be resolved, Blue Coat
adds the first entry in the name-inputing list to the end of the host name and
resubmits it to the DNS server
native FTP—Native

FTP involves the client connecting (either explicitly or
transparently) using the FTP protocol; the ProxySG then connects upstream
through FTP (if necessary).

NCSA common log format—Blue

Coat products are compatible with this log type,
which contains only basic HTTP access information.

network address translation (NAT)—The process of translating private network (such
as intranet) IP addresses to Internet IP addresses and vice versa. This
methodology makes it possible to match private IP addresses to Internet IP
addresses even when the number of private addresses outnumbers the pool of
available Internet addresses.
non-cacheable objects—A number of objects are not cached by the ProxySG because
they are considered non-cacheable. You can add or delete the kinds of objects that
the appliance considers non-cacheable. Some of the non-cacheable request types
are:



Pragma no-cache, requests that specify non-cached objects, such as when
you click refresh in the Web browser.



Password provided, requests that include a client password.



Data in request that include additional client data.



Not a GET request.

.nsc file—Created

from the multicast station definition and saved through the
browser as a text file encoded in a Microsoft proprietary format. Without an .nsc
file, the multicast station definition does not work.

433

Volume 5: Advanced Networking

NTP—To

manage objects in an appliance, a ProxySG must know the current
Universal Time Coordinates (UTC) time. By default, the ProxySG attempts to
connect to a Network Time Protocol (NTP) server to acquire the UTC time. The
ProxySG includes a list of NTP servers available on the Internet, and attempts to
connect to them in the order they appear in the NTP server list on the NTP tab.

O
object (used in caching)—An

object is the item that is stored in an appliance. These
objects can be frequently accessed content, content that has been placed there by
content publishers, or Web pages, among other things.

object (used in Visual Policy Manager)—An

object (sometimes referred to as a
condition) is any collection or combination of entry types you can create
individually (user, group, IP address/subnet, and attribute). To be included in an
object, an item must already be created as an individual entry.

object pipelining—This

patented algorithm opens as many simultaneous TCP
connections as the origin server will allow and retrieves objects in parallel. The
objects are then delivered from the appliance straight to the user's desktop as fast
as the browser can request them.

Online Certificate Status Protocol (OCSP)— An Internet protocol used for obtaining the

revocation status of an X.509 digital certificate. OCSP was created as an
alternative to certificate revocation lists (CRL), specifically addressing certain
problems associated with using CRLs in a public key infrastructure (PKI). OCSP
servers are called OCSP responders due to the request/response nature of these
messages.
origin content server (OCS)—Also

called origin server. This is the original source of
the content that is being requested. An appliance needs the OCS to acquire data
the first time, to check that the content being served is still fresh, and to
authenticate users.

outbound traffic (bandwidth gain)—Network packets flowing out of the ProxySG.
Outbound traffic mainly consists of the following:



Client outbound: Packets sent to the client in response to a Web request.



Server outbound: Packets sent to an OCS or upstream proxy to request a
service.

P
PAC (Proxy AutoConfiguration) scripts—Originally created by Netscape, PACs are a
way to avoid requiring proxy hosts and port numbers to be entered for every
protocol. You need only enter the URL. A PAC can be created with the needed
information and the local browser can be directed to the PAC for information
about proxy hosts and port numbers.
packet capture (PCAP)—Allows

filtering on various attributes of the Ethernet frame
to limit the amount of data collected. You can capture packets of Ethernet frames
going into or leaving a ProxySG.

434

parent class (bandwidth gain)—A

class with at least one child. The parent class must
share its bandwidth with its child classes in proportion to the minimum/
maximum bandwidth values or priority levels.

passive mode data connections (PASV)—Data connections initiated by an FTP client to

an FTP server.
pipelining—See

object pipelining.

policies—Groups

of rules that let you manage Web access specific to the needs of
an enterprise. Policies enhance ProxySG feature areas such as authentication and
virus scanning, and let you control end-user Web access in your existing
infrastructure.

policy-based bypass list—Used in policy. Allows a bypass based on the properties of
the client, unlike static and dynamic bypass lists, which allow traffic to bypass the
appliance based on destination IP address. See also dynamic bypass.
policy layer—A

collection of rules created using Blue Coat CPL or with the VPM.

pragma: no cache (PNC)—A

metatag in the header of a request that requires the
appliance to forward a request to the origin server. This allows clients to always
obtain a fresh copy.

proxy—Caches

content, filters traffic, monitors Internet and intranet resource
usage, blocks specific Internet and intranet resources for individuals or groups,
and enhances the quality of Internet or intranet user experiences.
A proxy can also serve as an intermediary between a Web client and a Web server
and can require authentication to allow identity-based policy and logging for the
client.
The rules used to authenticate a client are based on the policies you create on the
ProxySG, which can reference an existing security infrastructure—LDAP,
RADIUS, IWA, and the like.

Proxy Edition—SGOS

5 Proxy Edition.

proxy service—The proxy service defines the ports, as well as other attributes. that
are used by the proxies associated with the service.
proxy service (default)—The default proxy service is a service that intercepts all
traffic not otherwise intercepted by other listeners. It only has one listener whose
action can be set to bypass or intercept. No new listeners can be added to the
default proxy service, and the default listener and service cannot be deleted.
Service attributes can be changed.
ProxySG—A

Blue Coat security and cache box that can help manage security and
content on a network.

public key certificate—An

electronic document that encapsulates the public key of
the certificate sender, identifies this sender, and aids the certificate receiver to
verify the identity of the certificate sender. A certificate is often considered valid if
it has been digitally signed by a well-known entity, which is called a Certificate
Authority (such as VeriSign).

public virtual IP (VIP)—Maps multiple servers to one IP address and then propagates
that information to the public DNS servers. Typically, there is a public VIP known
to the public Internet that routes the packets internally to the private VIP. This
enables you to “hide” your servers from the Internet.

435

Volume 5: Advanced Networking

R
real-time streaming protocol (RTSP)—A

standard method of transferring audio and
video and other time-based media over Internet-technology based networks. The
protocol is used to stream clips to any RTP-based client.

reflect client IP attribute—Enables the sending of the client's IP address instead of the
SG's IP address to the upstream server. If you are using an application delivery
network (ADN), this setting is enforced on the concentrator proxy through the
Configuration > App. Delivery Network > Tunneling tab.
registration—An

event that binds the appliance to an account, that is, it creates the
Serial#, Account association.

remote authentication dial-in user service (RADIUS)—Authenticates

user identity via

passwords for network access.
Return to Sender (RTS)—A way of allowing outgoing TCP packets to use the same
network interface on which the corresponding incoming TCP packets arrived.
The destination Media Acess Control (MAC) address for the outgoing packets is
the same as the source MAC address of the incoming packets. See also Media
Access Control (MAC) address.
reverse proxy—A proxy that acts as a front end to a small number of predefined
servers, typically to improve performance. Many clients can use it to access the
small number of predefined servers.
routing information protocol (RIP)—Designed

to select the fastest route to a
destination. RIP support is built into ProxySG appliances.

router hops—The
RTS—See

number of jumps a packet takes when traversing the Internet.

Return to Sender.

S
secure shell (SSH)—Also

known as Secure Socket Shell. SSH is an interface and
protocol that provides strong authentication and enables you to securely access a
remote computer. Three utilities—login, ssh, and scp—comprise SSH. Security via
SSH is accomplished using a digital certificate and password encryption.
Remember that the Blue Coat ProxySG requires SSH1. A ProxySG supports a
combined maximum of 16 Telnet and SSH sessions.

serial console—A

third-party device that can be connected to one or more Blue
Coat appliances. Once connected, you can access and configure the appliance
through the serial console, even when you cannot access the appliance directly.
server certificate categories—The hostname in a server certificate can be categorized

by BCWF or another content filtering vendor to fit into categories such as
banking, finance, sports.
server portals—Doorways

that provide controlled access to a Web server or a
collection of Web servers. You can configure Blue Coat appliances to be server
portals by mapping a set of external URLs onto a set of internal URLs.

436

server-side transparency—The ability for the server to see client IP addresses, which

enables accurate client-access records to be kept. When server-side transparency
is enabled, the appliance retains client IP addresses for all port 80 traffic to and
from the ProxySG. In this scheme, the client IP address is always revealed to the
server.
service attributes—Define the parameters, such as explicit or transparent, cipher
suite, and certificate verification, that the ProxySG uses for a particular service.
sibling class (bandwidth gain)—A

bandwidth class with the same parent class as

another class.
signed system image—Cryptographically

signed with a key known only to Blue
Coat, and the signature is verified when the image is downloaded to the system.

simple network management protocol (SNMP)—The standard operations and
maintenance protocol for the Internet. It consists of a set of standards for network
management, including an application layer protocol, a database schema, and a
set of data objects. In SNMP, the available information is defined by management
information bases (MIBs), which describe the structure of the management data.
simulated live—Used

in streaming. Defines playback of one or more video-ondemand files as a scheduled live event, which begins at a specified time. The
content can be looped multiple times, or scheduled to start at multiple start times
throughout the day.

SmartReporter log type—A

proprietary ELFF log type that is compatible with the
SmartFilter SmartReporter tool.

SOCKS—A

proxy protocol for TCP/IP-based networking applications that allows
users transparent access across the firewall. If you are using a SOCKS server for
the primary or alternate forwarding gateway, you must specify the appliance’s ID
for the identification protocol used by the SOCKS gateway. The machine ID
should be configured to be the same as the appliance’s name.

SOCKS proxy—A generic way to proxy TCP and UDP protocols. The ProxySG
supports both SOCKSv4/4a and SOCKSv5; however, because of increased
username and password authentication capabilities and compression support,
Blue Coat recommends that you use SOCKS v5.
splash page—The custom message page that displays the first time you start the
client browser.
split proxy—Employs

co-operative processing at the branch and the core to
implement functionality that is not possible in a standalone proxy. Examples of
split proxies include:


Mapi Proxy



SSL Proxy

SQUID-compatible format—A

log type that was designed for cache statistics and is
compatible with Blue Coat products.
squid-native log format—The

Squid-compatible format contains one line for each

request.
SSL authentication—Ensures

that communication is with “trusted” sites only.
Requires a certificate issued by a trusted third party (Certificate Authority).

437

Volume 5: Advanced Networking

SSL client—See

SSL device profile.

SSL device profile—Used to determine various SSL parameters for outgoing HTTPS
connections. Specifically, its role is to:



Identify the SSL protocol version that the ProxySG uses in negotiations
with origin servers.



Identify the cipher suites used.



Determine which certificate can be presented to origin servers by
associating a keyring with the profile.

SSL interception—Decrypting

SSL connections.

SSL proxy—A proxy that can be used for any SSL traffic (HTTPS or not), in either
forward or reverse proxy mode.
static route—A manually-configured route that specifies the transmission path a
packet must follow, based on the packet’s destination address. A static route
specifies a transmission path to another network.
statistics—Every

Blue Coat appliance keeps statistics of the appliance hardware
and the objects it stores. You can review the general summary, the volume,
resources allocated, cache efficiency, cached contents, and custom URLs generated
by the appliance for various kinds of logs. You can also check the event viewer for
every event that occurred since the appliance booted.

stream—A flow of a single type of data, measured in kilobits per second (Kbps). A
stream could be the sound track to a music video, for example.
SurfControl log type—A proprietary log type that is compatible with the SurfControl
reporter tool. The SurfControl log format includes fully-qualified usernames
when an NTLM realm provides authentication. The simple name is used for all
other realm types.
syslog—An

event-monitoring scheme that is especially popular in Unix
environments. Most clients using Syslog have multiple devices sending messages
to a single Syslog daemon. This allows viewing a single chronological event log of
all of the devices assigned to the Syslog daemon. The Syslog format is: “Date Time
Hostname Event.”
system cache—The software cache on the appliance. When you clear the cache, all
objects in the cache are set to expired. The objects are not immediately removed
from memory or disk, but a subsequent request for any object requested is
retrieved from the origin content server before it is served.

T
TCP window size—The number of bytes that can be buffered before the sending host

must wait for an acknowledgement from the receiving host.
time-to-live (TTL) value—Used

in any situation where an expiration time is needed.
For example, you do not want authentication to last beyond the current session
and also want a failed command to time out instead of hanging the box forever.
traffic flow (bandwidth gain)—Also

referred to as flow. A set of packets belonging to
the same TCP/UDP connection that terminate at, originate at, or flow through the
ProxySG. A single request from a client involves two separate connections. One of

438

them is from the client to the ProxySG, and the other is from the ProxySG to the
OCS. Within each of these connections, traffic flows in two directions—in one
direction, packets flow out of the ProxySG (outbound traffic), and in the other
direction, packets flow into the ProxySG (inbound traffic). Connections can come
from the client or the server. Thus, traffic can be classified into one of four types:


Server inbound



Server outbound



Client inbound



Client outbound

These four traffic flows represent each of the four combinations described above.
Each flow represents a single direction from a single connection.
transmission control protocol (TCP)—TCP, when used in conjunction with IP (Internet

Protocol) enables users to send data, in the form of message units called packets,
between computers over the Internet. TCP is responsible for tracking and
handling, and reassembly of the packets; IP is responsible for packet delivery.
transparent proxy—A configuration in which traffic is redirected to the ProxySG
without the knowledge of the client browser. No configuration is required on the
browser, but network configuration, such as an L4 switch or a WCCP-compliant
router, is required.
trial period—Starting

with the first boot, the trial period provides 60 days of free
operation. All features are enabled during this time.

U
unicast alias—Defines

an name on the appliance for a streaming URL. When a
client requests the alias content on the appliance, the appliance uses the URL
specified in the unicast-alias command to request the content from the origin
streaming server.
universal time coordinates (UTC)—A ProxySG must know the current UTC time. By
default, the appliance attempts to connect to a Network Time Protocol (NTP)
server to acquire the UTC time. If the ProxySG cannot access any NTP servers,
you must manually set the UTC time.
URL filtering—See

content filtering.

URL rewrite rules—Rewrite

the URLs of client requests to acquire the streaming
content using the new URL. For example, when a client tries to access content on
www.mycompany.com, the ProxySG is actually receiving the content from the
server on 10.253.123.123. The client is unaware that mycompany.com is not
serving the content; however, the ProxySG access logs indicate the actual server
that provides the content.

W
WCCP—Web Cache Communication Protocol. Allows you to establish redirection
of the traffic that flows through routers.

439

Volume 5: Advanced Networking

Web FTP—Web

FTP is used when a client connects in explicit mode using HTTP
and accesses an ftp:// URL. The ProxySG translates the HTTP request into an
FTP request for the OCS (if the content is not already cached), and then translates
the FTP response with the file contents into an HTTP response for the client.
Websense log type—A

Blue Coat proprietary log type that is compatible with the
Websense reporter tool.

X
XML responder—HTTP
XML requestor—XML

440

XML service that runs on an external server.

realm.

Index

A
Active Sessions
ADN inbound connections 55
active sessions
ProxyClient 296
ADN history (ProxyClient) 295
ADN manager, defining 30
Application Delivery Network (ADN)
ADN History, reviewing 54
ADN manager, defining 30
basic setup 30
byte-cache
dictionary, manually resizing 64
statistics, reviewing 57
byte-cache configuration, viewing 77
CLI syntax 70
combined deployment, configuring 44
compression, using 27
configuration, viewing 76
connections deployments 34
connections, securing 49
deployment 24
device security, setting 47
devices, authorizing 51
dictionary
disk space, changing 68
dynamic 69
invalid value 68
manual sizing 68
dictionary sizing
byte-caching tab, resizing from 68
messages 66
new peers, ranking 66
peers, manually sizing 66
peers, ranking 65
statistics tab, resizing from 67
statistics, viewing 67
troubleshooting 65
understanding 64
explained 18
explicit deployment

configuring 38
destination port, preservingexplicit
deployment
destination port, preserving for ADN
41
load balancing 41
managing server subnets 38
health metrics, reviewing 57
History/Stats/Health Metrics 54
inbound connections, active sessions 55
network
constructing 30
optimizing 24
securing 46
network elements 19
network elements, example 21
policy gestures available for use with 72
security settings, configuring 47
Security, using 28
statistics, viewing 57
test adn
error codes 75
explict test, success 74
failure 75
success 73
transparent ADN, test adn successful 74
transparent deployment
configuring 34
load balancing 35
troubleshooting 73
tunnel
optimization, understanding 60
parameters, setting 60
attack-detection
client
block-action, explained 82
connection-limit, explained 82
creating and editing 81
failure-limit, explained 82
global defaults 80
global defaults, changing 80

441

Volume 5: Advanced Networking

unblock-time, explained 82
warning-limit, explained 82
configuration, viewing 82
mode, entering 80
server
add or remove server from group 84
configuration, viewing 84
configuring 83
creating 83
editing 84
hostname, explained 84
request-limit, explained 84
authentication, device. See device authentication.
116

B
Background 347
bandwidth management
allocating bandwidth 94
allocation examples 106
class hierarchies 96
creating classes 99
deleting bandwidth-classes 101
editing classes 101
enabling or disabling 99
flow classification 98
maximum bandwidth 95
minimum bandwidth 95
overview 94
policy examples 106
priority levels 95
viewing configurations 101
BWM, see bandwidth management
byte-cache dictionary, manually resizing 64

C
Client Manager
changing 313
ProxyClient 175
combined deployment
configuring for ADN 44
configuration, ADN, troubleshooting 76
connections, securing for ADN 49
Content filtering
Blue Coat Web Filter
configuring (ProxyClient) 233

442

ProxyClient, about 196
ProxyClient, configuring 231
CPL
enabling ICP 159
RADIUS policies, creating 170

D
D range multicast address, explained 127
Data Collector, ProxyClient 319
default sequence
deleting hosts or groups 151
device authentication
appliance certificates, about 116
cipher suites, changing 124
cipher suites, default 117
CLI syntax 124
device ID, setting 123
overview 116
platforms supported 118
ssl device profile, creating 122
device security
ADN, setting for 47
devices
ADN authorization 51
dictionary sizing
troubleshooting 65
directives
forwarding, available 144
forwarding, using 144
SOCKS gateways, available 337
DNS 373
background resolution 347
health check tests, editing 373
document
conventions 14
Do-Not-Fragment, see PMTU
DRTR service configuration, deleting hosts or
groups 151

E
event log
notifications, health checks 357
explicit deployment
ADN server subnets, managing. 38
ADN, configuring for 38
load balancing for ADN network 41

Index

external services
health checks tests 353

hosts
fail open/closed 146, 339
load balancing
understanding 133
load balancing and host affinity, using
together 134
policy commands in forward layer 419
policy, managing with 419
statistics, locating 143
understanding 133

F
failover
configuring, overview 126
group secret 127
master, explained 126
multicast address, using 127
priority ranges 127
statistics page, viewing 128
troubleshooting 128
VRRP, using with 125
failover group
configuring as session monitor 168
Forwarding 366
forwarding
CLI, configuring through 141
configuring 136
default sequence, configuring 141
default sequence, understanding 140
directives
available 144
host
fail open/closed 146, 339
installable list
creating 150
host timeout values 146, 339
using 144
DNS resolution, using 347
global defaults
configuring 139
load balancing and host affinity,
configuring 139
group
health checks tests, editing 369
groups
configuring 137
load balancing and host affinity,
configuring 138
health checks 366
host
configuring 136
load balancing and host affinity,
configuring 137
TCP health check 366

G
Group Policy Object (GPO) distribution,
ProxyClient 285

H
health checks
about 350
authentication server, editing 377
authentication servers, external 377
categories 346
CLI 404
copy or delete user-defined health checks
395
edit authentication server health checks
378
edit default notifications for a targeted
health check 364
edit default notifications globally 364
edit defaults for a targeted health check
360
edit defaults globally 360
edit DNS server health checks 375
edit forwarding groups and SOCKS
groups 369
edit forwarding hosts and SOCKS
gateway health checks 370
edit ICAP and Websense groups 384
edit ICAP service and content filtering
health checks 382
edit user-defined composite health checks
394
edit user-defined host health checks 390
enable or disable a health check 356
composite and group tests 388
content filtering 380

443

Volume 5: Advanced Networking

copying 395
default settings 355
default settings, changing 357
deleting 395
disable 355
DNS resolution,background 347
DNS server 373
enable 355
external services tests 353
forwarding 366
group tests 353
HTTP/HTTPS tests 352
ICAP group tests, editing 383
ICMP test 351
naming conventions 350
notifications 356
explicit, configuring 362
global, configuring 361
notifications, configuring 361
overview 346
policy, understanding 403
severity 357
SNMP traps 356
SOCKS gateways 366
SSL test 351
state, viewing 397
TCP socket test 351
tests 351
types
user-defined composite 350
user-defined host 350
user-defined
about 386
composite checks, creating 388
host checks, creating 388
user-defined, composite, about 387
user-defined, copying 395
user-defined, deleting 395
virus scanning 380
virus scanning and content filtering, editing
380
Websense off box, editing 383
hide tray icon (ProxyClient) 281
home router
version 2 configuration 411

444

host affinity
forwarding
global defaults, configuring 139
group, configuring 138
host, configuring 137
load balancing, using with 134
SOCKS gateways
configuring 329
groups, configuring 331
HTTP
health checks test 352
user-defined health check tests, using with
386
HTTPS
health checks test 352
user-defined health check tests, using with
386

I
ICMP
health check test 351
user-defined health check tests, using with
386
ICMP broadcast echo
configuring 406
ICMP error message
ICMP host unreachable 407
ICMP timestamp echo
configuring 406
ICP
creating an installable list for 154
enabling through CPL 159
hierarchy 153
icp_access_domain directive 156
icp_access_ip directive 157
installable list, creating through Management
Console 158
restricting access 156
installable list
ICP 154
SOCKS gateways 337
integrated host, timeout interval 146, 339

L
load balancing
forwarding

Index

global defaults, configuring 139
group, configuring 138
host, configuring 137
host affinity, using with 134
SOCKS gateways
configuring 329
groups, configuring 331
understanding 133
location awareness, ProxyClient
about 182
configuring 225
examples 184

M
multicast
D range address, explained 127
failover, using with 127
multicast, troubleshooting 128

N
notifications
default 356
e-mail 356
event logging 356
snmp 356

P
password
with RIP 166
PMTU
enabled by default 407
overview 407
policy
bandwidth management examples 106
proxies
setting up 13
ProxyClient
active sessions 296
ADN features, about 192
ADN manager, about 175
CIFS cache, changing location of 324
Client Manager, about 175
Client Manager, changing 313
Data Collector utility 319
deployment overview 205
Group Policy Object (GPO) distribution 285

hide Start menu option 281
hide tray icon 281
history statistics 293
installing interactively 268
installing silently 273
Internet gateways 193
licensing 181
location awareness
about 182
configuring 225
examples 184
manager listening mode 208
object cache, about 192
reflect client IP 194
registry settings 311
requirements 182
troubleshooting
acceleration 306
Web filtering 307
tunnel listening mode 209
uninstalling 325
Web filtering
categories 240
categories (policy) 242
categories (system and default) 246
category rulebase 247
configuring 231
enabling BCWF 233
HTTPS 250
on license expiration 250
Safe Search 250
ProxyClientSetup.exe 207
ProxyClientSetup.msi 207
ProxySG
configuration file, example 415
WCCP configuration file, creating 415

R
RADIUS
policies, creating 170
RADIUS session monitor
cluster, configuring 168
configuring 169
configuring failover group 168
reflect client IP address
ProxyClient 194

445

Volume 5: Advanced Networking

reflect ip address attribute, ProxyClient 194
registry settings (ProxyClient) 311
RFC-1323
configuring 406
RIP
configuring 161
definition of 161
installing configuration file 162
parameters 164
ProxySG-specific RIP parameters 165
using passwords with 166
routing information protocol, see RIP

S
severity, options 357
SNMP
Blue Coat MIB 356
health checks 356
notifications 356
SOCKS gateways
CLI, configuring through 334
configuring 328
default sequence
creating 334
understanding 333
directives
available 337
installable list, creating 342
using 337
DNS resolution, using 347
global defaults, configuring 332
group
health checks tests, editing 369
groups, configuring load balancing and host
affinity 331
groups, creating 330
health checks 366
identification (Ident) protocol 342
installable list, creating 337
load balancing and host affinity, configuring
329
statistics, locating 336
TCP health check 366
SSL
health checks test 351
ssl device profile

446

understanding 116
statistics
failover page, viewing 128
forwarding 143
health checks 397
ProxyClient history 293
SOCKS gateways 336

T
TCP
health checks test 351
user-defined health check tests, using with
386
TCP Connection Forwarding
about 85
CLI commands 92
configuring 90
deployment 90
TCP NewReno
configuring 406
TCP/IP
configuration, showing 408
ICMP broadcast echo 406
ICMP timestamp echo 406
overview 405
PMTU, configuring 407
RFC-1323 406
test adn
error codes 75
explicit test, success 74
failure 75
no upstream connection 74
troubleshooting 73
using 73
transparent deployment
ADN load balancing 35
ADN, configuring for 34
troubleshooting
ADN 73
ADN dictionary sizing 68
failover 128
ICMP host unreachable error message 407

V
virtual IPs
creating 409

Index

understanding 409
VRRP, failover, using with 125

W
WCCP
configuration, viewing 416
configuring 411
enable 414

router configuration, initial 411
service group status, viewing 414, 417
settings 411
settings, understanding 411
settings, viewing 415
statistics, viewing 416
Web Cache Control Protocol, see WCCP

447

Document Path: ["167-blue-coat-instruction-proxysg.pdf"]

e-Highlighter

Click to send permalink to address bar, or right-click to copy permalink.

Un-highlight all Un-highlight selectionu Highlight selectionh