Name: SG

Text: Volume 3: Proxies and Proxy Services

Contact Information
Blue Coat Systems Inc.
420 North Mary Ave
Sunnyvale, CA 94085-4121
http://www.bluecoat.com/support/contact.html
[email protected]
http://www.bluecoat.com
For concerns or feedback about the documentation: [email protected]

Copyright© 1999-2007 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™, RA Connector™, RA Manager™, Remote Access™ 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®, Permeo®, Permeo Technologies, Inc.®, and the Permeo logo 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-02839
Document Revision: SGOS 5.x 03/2007

ii

Contents
Contact Information

Chapter 1: About Proxies and Proxy Services
Creating or Enabling a Proxy Service...............................................................................................................9
Configuring Proxies ..........................................................................................................................................10
About This Book ................................................................................................................................................10
Document Conventions....................................................................................................................................10
About Procedures.......................................................................................................................................11
Illustrations .................................................................................................................................................11
Chapter 2: About Console Services
About Console Services ....................................................................................................................................13
Notes on Managing the HTTP Console .........................................................................................................15
Managing the HTTPS Console (Secure Console)..........................................................................................15
Selecting a Keyring ....................................................................................................................................15
Selecting an IP Address.............................................................................................................................16
Enabling the HTTPS Console Service .....................................................................................................16
Managing the SSH Console .............................................................................................................................18
Managing the SSH Host ............................................................................................................................18
Managing SSH Client Keys.......................................................................................................................18
Notes on Managing the Telnet Console .........................................................................................................21
Chapter 3: About Proxy Services
Understanding a Proxy Listener .....................................................................................................................23
Proxy Services ....................................................................................................................................................23
Understanding Multiple Listeners ..........................................................................................................26
About Service Attributes...........................................................................................................................27
Understanding Access Logging with Proxy Services ...........................................................................28
Creating or Editing a Proxy Service ........................................................................................................28
Viewing the Proxy Services ......................................................................................................................30
Bypass List..........................................................................................................................................................30
Adding Static Bypass Entries ...................................................................................................................30
Using Policy to Configure Dynamic Bypass ..........................................................................................31
Chapter 4: Managing the CIFS Proxy
About CIFS .........................................................................................................................................................35
About the Blue Coat CIFS Proxy Solution .....................................................................................................35
Caching Behavior .......................................................................................................................................36
Authentication ............................................................................................................................................36

iii

Volume 3: Proxies and Proxy Services

Policy Support ............................................................................................................................................ 37
Access Logging........................................................................................................................................... 37
WCCP Support ........................................................................................................................................... 37
Configuring the SG CIFS Proxy ...................................................................................................................... 37
About Windows Security Signatures...................................................................................................... 37
Configuring CIFS Proxy Services ............................................................................................................ 39
Configuring the CIFS Proxy ..................................................................................................................... 41
Enabling CIFS Access Logging ................................................................................................................ 42
Reviewing CIFS Protocol Statistics.......................................................................................................... 42
Reference: Equivalent CIFS Proxy CLI Commands..................................................................................... 45
Reference: Access Log Fields........................................................................................................................... 46
Reference: CPL Triggers, Properties, and Actions ....................................................................................... 48
Triggers........................................................................................................................................................ 48
Properties and Actions:............................................................................................................................. 49
Chapter 5: Managing the DNS Proxy
Creating or Editing a DNS Proxy Service...................................................................................................... 51
Creating a Resolving Name List ..................................................................................................................... 53
Chapter 6: Managing the Endpoint Mapper and MAPI Proxies
Section A: The Endpoint Mapper Proxy Service
About RPC ......................................................................................................................................................... 56
About the Blue Coat Endpoint Mapper Proxy Solution.............................................................................. 56
Policy Support ............................................................................................................................................ 57
Access Logging........................................................................................................................................... 57
Configuring the SG Appliance Endpoint Mapper Service ......................................................................... 57
Reviewing Endpoint Mapper Proxy Statistics .............................................................................................. 59
Reference: Equivalent Endpoint Mapper Proxy CLI Commands.............................................................. 59
Reference: Access Log Fields........................................................................................................................... 59
Reference: CPL Triggers, Properties, and Actions ....................................................................................... 60
TCP Tunneling Triggers............................................................................................................................ 60
Properties and Actions .............................................................................................................................. 61
Section B: The MAPI Proxy
About MAPI....................................................................................................................................................... 62
About the Blue Coat MAPI Solution .............................................................................................................. 62
Batching....................................................................................................................................................... 63
Keep-Alive .................................................................................................................................................. 63
Supported Servers...................................................................................................................................... 64
Access Logging........................................................................................................................................... 64
More Conceptual Reference ..................................................................................................................... 64
Configuring the SG MAPI Proxy .................................................................................................................... 64
About the MAPI Service ........................................................................................................................... 64
Configuring the MAPI Proxy ................................................................................................................... 64

iv

Contents

Reviewing MAPI Statistics .............................................................................................................................. 65
Reference: Equivalent MAPI Proxy CLI Commands................................................................................... 66
Reference: Access Log Fields........................................................................................................................... 66
Chapter 7: Managing the FTP Proxy
Understanding FTP........................................................................................................................................... 69
Passive Mode Data Connections ............................................................................................................. 69
Understanding IP Reflection for FTP...................................................................................................... 70
Configuring the SG Appliance for Native FTP Proxy ................................................................................. 71
Creating or Editing the FTP Service........................................................................................................ 71
Configuring the FTP Proxy ...................................................................................................................... 73
Configuring FTP Clients ........................................................................................................................... 74
Configuring FTP Connection Welcome Banners.......................................................................................... 75
Viewing FTP Statistics ...................................................................................................................................... 76
Chapter 8: Managing the HTTP Proxy
Section A: Creating an HTTP Proxy Service
Section B: Overview: Configuring HTTP Proxy Performance
Understanding Default HTTP Proxy Policy .......................................................................................... 83
HTTP Proxy Acceleration Profiles........................................................................................................... 83
Byte-Range Support................................................................................................................................... 83
Refresh Bandwidth .................................................................................................................................... 84
Compression............................................................................................................................................... 84
Section C: Configuring the HTTP Proxy
Setting Default HTTP Proxy Policy ................................................................................................................ 86
Customizing the HTTP Proxy Profile ............................................................................................................ 88
Using the Normal Profile.......................................................................................................................... 89
Using the Portal Profile............................................................................................................................. 89
Using the Bandwidth Gain Profile .......................................................................................................... 89
Understanding HTTP Proxy Profile Configuration Components ............................................................. 89
Configuring the HTTP Proxy Profile ...................................................................................................... 92
Configuring HTTP for Bandwidth Gain........................................................................................................ 93
Understanding Byte-Range Support....................................................................................................... 94
Understanding Revalidate Pragma-No-Cache...................................................................................... 95
Configuring Refresh Bandwidth for the HTTP Proxy................................................................................. 95
Understanding Tolerant HTTP Request Parsing.......................................................................................... 96
Understanding HTTP Object Types ............................................................................................................... 97
Understanding HTTP Compression............................................................................................................... 97
Understand Compression Behavior........................................................................................................ 98
Compression Exceptions........................................................................................................................... 99
Configuring Compression ...................................................................................................................... 100
Notes .......................................................................................................................................................... 103

v

Volume 3: Proxies and Proxy Services

Section D: Viewing HTTP/FTP Statistics
HTTP/FTP History Statistics ................................................................................................................. 105
Section E: Using Explicit HTTP Proxy with Internet Explorer
Disabling the Proxy-Support Header........................................................................................................... 109
Enabling or Disabling NTLM Authentication for Internet Explorer Clients ......................................... 110
Using Web FTP................................................................................................................................................ 111
Chapter 9: Creating and Editing an HTTPS Reverse Proxy Service
Section A: Configuring the HTTPS Reverse Proxy
Section B: Configuring HTTP or HTTPS Origination to the Origin Content Server
Creating Policy for HTTP and HTTPS Origination ................................................................................... 119
Chapter 10: Managing Shell Proxies
Customizing Policy Settings for Shell Proxies ............................................................................................ 121
Conditions................................................................................................................................................. 121
Properties .................................................................................................................................................. 122
Actions....................................................................................................................................................... 122
Boundary Conditions for Shell Proxies ................................................................................................ 122
Understanding Telnet Shell Proxies...................................................................................................... 123
Shell History Statistics .................................................................................................................................... 127
Viewing Shell History Statistics .................................................................................................................... 128
Chapter 11: Managing a SOCKS Proxy
Creating or Editing a SOCKS Proxy Service ............................................................................................... 129
Configuring the SOCKS Proxy...................................................................................................................... 131
Using Policy to Control the SOCKS Proxy .................................................................................................. 132
Viewing SOCKS History Statistics ............................................................................................................... 132
Viewing SOCKS Clients.......................................................................................................................... 133
Viewing SOCKS Connections ................................................................................................................ 133
Viewing SOCKS Client and Server Compression Gain Statistics .................................................... 134
Chapter 12: Managing the SSL Proxy
Understanding the SSL Proxy ....................................................................................................................... 137
Determining What HTTPS Traffic to Intercept ................................................................................... 138
Managing Decrypted Traffic .................................................................................................................. 138
Using the SSL Proxy with ADN Optimization ........................................................................................... 139
Section A: Intercepting HTTPS Traffic
Setting Up the SSL Proxy in Transparent Proxy Mode ............................................................................. 140
Setting Up the SSL Proxy in Explicit Proxy Mode ..................................................................................... 142
Creating an Issuer Keyring for SSL Interception ................................................................................ 143
Using Client Consent Certificates.......................................................................................................... 143
Downloading an Issuer Certificate........................................................................................................ 144

vi

Contents

Section B: Configuring SSL Rules through Policy
Using the SSL Intercept Layer....................................................................................................................... 147
Using the SSL Access Layer........................................................................................................................... 149
CPL in the SSL Intercept Layer ..................................................................................................................... 151
CPL in the SSL Layer ...................................................................................................................................... 152
Notes ................................................................................................................................................................. 153
Section C: Viewing SSL Statistics
SSL History Statistics ...................................................................................................................................... 154
Unintercepted SSL Data.......................................................................................................................... 154
Unintercepted SSL Clients...................................................................................................................... 155
Unintercepted SSL Bytes......................................................................................................................... 155
Section D: Advanced Topics
Creating an Intermediate CA using OpenSSL ............................................................................................ 157
Installing OpenSSL ................................................................................................................................. 157
Creating a Root Certificate ..................................................................................................................... 157
Modifying the OpenSSL.cnf File ........................................................................................................... 158
Signing the SG CSR.................................................................................................................................. 158
Importing the Certificate into the SG Appliance................................................................................. 159
Creating an Intermediate CA using Microsoft Server 2003 (Active Directory) ..................................... 159
Chapter 13: Managing the TCP Tunneling Proxy
TCP-Tunnel Proxy Services Supported ....................................................................................................... 163
Creating or Editing a TCP-Tunnel Proxy Service....................................................................................... 163
Appendix A: Glossary
Appendix B: Explicit and Transparent Proxy
Understanding the Explicit Proxy ......................................................................................................... 175
Understanding the Transparent Proxy ................................................................................................. 175
Creating an Explicit Proxy Server................................................................................................................. 176
Using the SG Appliance as an Explicit Proxy ...................................................................................... 176
Configuring Adapter Proxy Settings .................................................................................................... 177
Transparent Proxies ........................................................................................................................................ 177
Configuring Transparent Proxy Hardware ......................................................................................... 177
Configuring IP Forwarding ........................................................................................................................... 179
Index

vii

Volume 3: Proxies and Proxy Services

viii

Chapter 1: About Proxies and Proxy Services

A proxy 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 serves 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, as
discussed in Volume 5: Securing the Blue Coat SG Appliance.
Proxies have two major components:


The proxy service needs to be created or enabled and various attributes set, such as
whether you want the proxy to use explicit or transparent mode



The proxy itself needs to be configured to intercept the traffic desired. You can
configure it in reverse or forward mode.

Creating or Enabling a Proxy Service
Services are created through the Configuration > Services menu. Blue Coat has two
types of services: console services, used to communicate with the SGappliance, and
proxy services, used to communicate with other systems.
Console services are discussed further in Chapter 2: "About Console Services" on page
13.
For a list of available proxy services and proxies, see Chapter 3: "About Proxy
Services" on page 23.
One of the first decisions you make when configuring a proxy is whether the proxy or
proxy service will use explicit or transparent attributes.
Explicit/Transparent proxy specifies the mode the client requests get to the proxy.


Explicit—The default, requiring software configuration for both browser and
service. This service attribute sends requests explicitly to a proxy instead of to the
origin content servers.



Transparent—Requires a bridge, such as that available in the SG appliance; a
Layer-4 switch, or a WCCP-compliant router. You can also transparently redirect
requests through an SG appliance by setting the workstation’s gateway to the
appliance IP address. This service attribute sends requests to the proxy without the
client or server being aware of it.
Some software configuration on the SG appliance is also required to allow the
appliance to know what traffic to intercept.

You might configure both proxy types, depending on the services you require. For
information on understanding explicit and transparent proxies and the configuration
requirements, see Appendix B: "Explicit and Transparent Proxy" on page 175.

9

Volume 3: Proxies and Proxy Services

Configuring Proxies
After you have created or enabled the proxy services you need, the next step is to
configure the proxy that will use that service. Some proxy services require little
configuration; others, such as the SSL proxy, require configuration depending on what
you want to do and also require policy to be configured to work effectively.

About This Book
This book deals with the following topics:


Chapter 2: "About Console Services" on page 13



Chapter 3: "About Proxy Services" on page 23



Chapter 4: "Managing the CIFS Proxy" on page 35



Chapter 5: "Managing the DNS Proxy" on page 51



Chapter 6: "Managing the Endpoint Mapper and MAPI Proxies" on page 55



Chapter 7: "Managing the FTP Proxy" on page 69



Chapter 8: "Managing the HTTP Proxy" on page 77



Chapter 9: "Creating and Editing an HTTPS Reverse Proxy Service" on page 113



Chapter 10: "Managing Shell Proxies" on page 121



Chapter 11: "Managing a SOCKS Proxy" on page 129



Chapter 12: "Managing the SSL Proxy" on page 137



Chapter 13: "Managing the TCP Tunneling Proxy" on page 163



Appendix A: "Glossary" on page 167



Appendix B: "Explicit and Transparent Proxy" on page 175

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

Command line text that appears on your administrator workstation.

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.

{}

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.

10

Volume 3: Proxies and Proxy Services

12

Chapter 2: About Console Services

The SG appliance ships with four consoles designed to manage communication with
the system:


HTTP and HTTPS Consoles: These consoles are designed to allow you access to the
Management Console. The HTTPS Console is created and enabled by default; the
HTTP Console is created by default but not enabled because it is less secure than
HTTPS.



SSH Console: This console is created and enabled by default, allowing you access
to the CLI using an SSH client.



Telnet Console: This console not created because the passwords are sent
unencrypted from the client to the SG appliance. You must create and enable the
console before you can access the appliance through a Telnet client (not
recommended).

Table 2-1. Console Services
Console Service

Default Port

Status

Configuration Discussed

HTTP-Console

8081

Disabled

“Notes on Managing the HTTP Console” on page
15.

HTTPS-Console

8082

Enabled

“Managing the HTTPS Console (Secure
Console)” on page 15.

SSH-Console

22

Enabled

“Managing the SSH Console” on page 18.

Telnet-Console



Not Created

“Notes on Managing the Telnet Console” on page
21.

About Console Services
Console services are used to manage the SG appliance. As such, bypass entries are
ignored for connections to console services.
The basic procedure for creating or editing a console service is shown below.
To edit or create a console service:
1.

Select Configuration > Services > Console Services.

13

Chapter 2: About Console Services

Relevant CLI Syntax to Create/Edit a Console Service:


To enter configuration mode for the service:
SGOS(config) console-services
SGOS(config console-services) create {https-console | http-console |
ssh-console | telnet-console} console_name
SGOS(config console-services) edit console_name



The following subcommands are available:
SGOS (config name) add {all | proxy-ip_address} port_number {enable |
disable}
SGOS (config console_name) disable {all | proxy-ip_address}
port_number
SGOS (config console_name) enable {all | proxy-ip_address} port_number
SGOS (config console_name) exit
SGOS (config console_name) remove {all | proxy-ip_address} port_number
SGOS (config console_name) view

Notes on Managing the HTTP Console
The default HTTP Console is already configured; you only need to enable it.
You can create and use more than one HTTP Console as long as the IP address and the
port do not match the existing HTTP Console settings.
To create a new HTTP Console service or edit an existing one, see “About Console
Services” on page 13.

Managing the HTTPS Console (Secure Console)
The HTTPS Console provides secure access to the Management Console through the
HTTPS protocol.
You can create multiple management HTTPS consoles, allowing you to simultaneously
access the Management Console using any IP address belonging to the SG appliance as
well as any of the appliance’s virtual IP (VIP) addresses. The default is HTTPS over port
8082.
Creating a new HTTPS Console port requires three steps, discussed in the following
sections:


Selecting a keyring (a keypair and a certificate that are stored together)



Selecting an IP address and port on the system that the service will use, including
virtual IP addresses



Enabling the HTTPS Console Service

Selecting a Keyring
The SG appliance ships with a default keyring that can be reused with each console that
you create. You can also create your own keyrings.
To use the default keyring, accept the default keyring through the Management Console.
If using the CLI, the default keyring is automatically used for each new HTTPS Console
that is created.To use a different keyring you must edit the console service and select a
new keyring using the attribute keyring command.

15

Volume 3: Proxies and Proxy Services

Note: When using certificates for the HTTPS Console or for HTTPS termination services
that are issued by Certificate Signing Authorities that are not well-known, see Chapter 9:
"Creating and Editing an HTTPS Reverse Proxy Service" on page 113.

If you get “host mismatch” errors or if the security certificate is called out as invalid,
create a different certificate and use it for the HTTPS Console.
For information on creating a keypair and a certificate to make a keyring, see Chapter 9:
"Creating and Editing an HTTPS Reverse Proxy Service" on page 113.

Selecting an IP Address
You can use any IP address on the SG appliance for the HTTPS Console service, including
virtual IP addresses. To create a virtual IP address, refer to Volume 6: Advanced Networking.

Enabling the HTTPS Console Service
The final step in editing or creating an HTTPS Console service is to select a port and
enable the service.
To create or edit an HTTPS Console port service:
1.

Select Configuration > Services > Console Services.

2.

Do one of the following:


To create a new HTTPS Console service, see “About Console Services” on page 13.



To edit the configuration of an existing HTTPS Console service, highlight the
HTTPS Console and click Edit.

16

Chapter 2: About Console Services

Notes on Managing the Telnet Console
The Telnet console allows you to connect to and manage the SG appliance using the
Telnet protocol. Remember that Telnet is an insecure protocol and therefore should be
used only in very secure environments. By default, the Telnet Console is not created.
Blue Coat Systems recommends against using Telnet because of the security hole it
creates.
Note: If you do enable the Telnet console, be aware that you cannot use Telnet
everywhere in the CLI. Some modules, such as SSL, respond with the error message:
Telnet sessions are not allowed access to ssl commands.

By default a Telnet shell proxy service exists on the default Telnet port (23). Since only one
service can use a specific port, you must delete the shell service if you want to create a
Telnet console. Be sure to apply any changes before continuing. If you want a Telnet shell
proxy service in addition to the Telnet console, you can re-create it later on a different port.
For information on the Telnet service, see Chapter 10: "Managing Shell Proxies" on page
121.
To create a new Telnet console service or edit an existing one, see “About Console
Services” on page 13.
Note: To use the Telnet shell proxy (to communicate with off-proxy systems) and
retain the Telnet Console, you must either change the Telnet shell proxy to use a
transparent Destination IP address, or change the destination port on either the Telnet
Console or Telnet shell proxy. Only one service is permitted on a port. For more
information on the Telnet shell proxy, see Chapter 10: "Managing Shell Proxies" on
page 121.

21

Volume 3: Proxies and Proxy Services

22

Chapter 3: About Proxy Services

Proxy services define the ports and addresses where the SG appliance listens for
incoming requests. A variety of attributes for each service can be defined. Each service
can be applied to all IP addresses or limited to a specific set of addresses and port
combinations. A number of default services are predefined. Additional services can be
defined on other ports.
After setting up and enabling the proxy service, the next step is to configure the proxy
for your environment. If necessary, you can configure bypass lists for transparent proxy
environments.
This chapter discusses:


“ Understanding a Proxy Listener” on page 23



“ Proxy Services” on page 23



“Bypass List” on page 30

Understanding a Proxy Listener
A proxy listener is the location where the SG listens for traffic for a specific service. A
proxy listener can be identified by any destination IP/subnet and port range, and
multiple listeners can be added for each service.
Note: A proxy listener should not be confused with the default proxy listener, a
service that intercepts all traffic not otherwise intercepted by other listeners.

Four settings are available (some settings are not available for some proxy listeners):


: All IP addresses are intercepted.



: Only connections to destination addresses that do not belong to the
SG appliance are intercepted



: Only destinations addresses that match one of the IP addresses on the
SG appliance are intercepted.



Specific IP address or subnet: Only destination addresses matching the IP address
and subnet are intercepted.

Proxy Services
The following table lists the default SG appliance services and their default listeners. If
you have an upgraded appliance, all services existing before the upgrade are
preserved.
Note: Console services, used to manage the SG appliance, are not discussed in this
chapter. For information on the four console services—HTTP, HTTPS, SSH, and
Telnet—see Chapter 2: "About Console Services" on page 13.

23

Volume 3: Proxies and Proxy Services

Table 3-1. Proxy Name and Listeners
Service Name

Proxy

Destination
IP Address

Port Range

Configuration Discussed

AOL-IM

AOL-IM



5190

Volume 4: Web Communication
Proxies: Chapter 2: "Managing
Instant Messaging Protocols" on
page 9

CIFS

CIFS



445, 139

Chapter 4: "Managing the CIFS
Proxy" on page 35

Citrix ICA

TCP-Tunnel



1494

Chapter 13: "Managing the TCP
Tunneling Proxy" on page 163

DNS

DNS



53

Chapter 5: "Managing the DNS
Proxy" on page 51

Endpoint
Mapper

Endpoint
Mapper



135

Chapter 6: "Managing the
Endpoint Mapper and MAPI
Proxies" on page 55

FTP

FTP



21

Chapter 7: "Managing the FTP
Proxy" on page 69

HTTP

HTTP



80



8080

Chapter 8: "Managing the HTTP
Proxy" on page 77

HTTPS

SSL



443

Chapter 12: "Managing the SSL
Proxy" on page 137

IMAP

TCP-Tunnel



143

Chapter 13: "Managing the TCP
Tunneling Proxy" on page 163

IMAPS

TCP-Tunnel



993

Chapter 13: "Managing the TCP
Tunneling Proxy" on page 163

Kerberos

TCP-Tunnel



88

Chapter 13: "Managing the TCP
Tunneling Proxy" on page 163

LDAP

TCP-Tunnel



389

Chapter 13: "Managing the TCP
Tunneling Proxy" on page 163

LPD

TCP-Tunnel



515

Chapter 13: "Managing the TCP
Tunneling Proxy" on page 163

Lotus Notes

TCP-Tunnel



1352

Chapter 13: "Managing the TCP
Tunneling Proxy" on page 163

MMS

MMS



1755

Volume 4: Web Communication
Proxies: Chapter 3: "Managing
Streaming Media" on page 33

MS SQL Server

TCP-Tunnel



1433

Chapter 13: "Managing the TCP
Tunneling Proxy" on page 163

24

Chapter 3: About Proxy Services

Table 3-1. Proxy Name and Listeners (Continued)
Service Name

Proxy

Destination
IP Address

Port Range

Configuration Discussed

MS Terminal
Services

TCP-Tunnel



3389

Chapter 13: "Managing the TCP
Tunneling Proxy" on page 163

MSN-IM

MSN-IM



1863, 6891

Volume 4: Web Communication
Proxies: “Chapter 2: Managing
Instant Messaging Protocols” on
page 9

MySQL

TCP-Tunnel



3306

Chapter 13: "Managing the TCP
Tunneling Proxy" on page 163

NFS

TCP-Tunnel



2049

Chapter 13: "Managing the TCP
Tunneling Proxy" on page 163

Novell
GroupWise

TCP-Tunnel



1677

Chapter 13: "Managing the TCP
Tunneling Proxy" on page 163

Novell NCP

TCP-Tunnel



524

Chapter 13: "Managing the TCP
Tunneling Proxy" on page 163

Oracle

TCP-Tunnel



1521, 1525

Chapter 13: "Managing the TCP
Tunneling Proxy" on page 163

POP3

TCP-Tunnel



110

Chapter 13: "Managing the TCP
Tunneling Proxy" on page 163

POP3S

TCP-Tunnel



995

Chapter 13: "Managing the TCP
Tunneling Proxy" on page 163

RTSP

RTSP



554

Volume 4: Web Communication
Proxies: “Chapter 3: Managing
Streaming Media” on page 33

Shell

TCP-Tunnel



514

Chapter 13: "Managing the TCP
Tunneling Proxy" on page 163

SMTP

TCP-Tunnel



25

Chapter 13: "Managing the TCP
Tunneling Proxy" on page 163



1080

Chapter 11: "Managing a SOCKS
Proxy" on page 129

SOCKS

SSH

TCP-Tunnel



22

Chapter 13: "Managing the TCP
Tunneling Proxy" on page 163

Sybase SQL

TCP-Tunnel



1498

Chapter 13: "Managing the TCP
Tunneling Proxy" on page 163

Telnet

Telnet



23

Chapter 10: "Managing Shell
Proxies" on page 121

VNC

TCP-Tunnel



5900

Chapter 13: "Managing the TCP
Tunneling Proxy" on page 163

25

Volume 3: Proxies and Proxy Services

Table 3-1. Proxy Name and Listeners (Continued)
Service Name

Proxy

Destination
IP Address

Port Range

Configuration Discussed

XWindows

TCP-Tunnel



6000-6002

Chapter 13: "Managing the TCP
Tunneling Proxy" on page 163

Yahoo-IM

Yahoo-IM



5050, 5101

Volume 4: Web Communication
Proxies: “Chapter 2: Managing
Instant Messaging Protocols” on
page 9

Default (Listens
on all
unattended
ports)

TCP-Tunnel





Chapter 13: "Managing the TCP
Tunneling Proxy" on page 163

The HTTPS Reverse Proxy service is also available but not created by default. When
created, it defaults to an destination IP address on port 443. For information on
configuring the HTTPS Reverse Proxy, see Chapter 9: "Creating and Editing an HTTPS
Reverse Proxy Service" on page 113.

Understanding Multiple Listeners
A listener identifies network traffic based on a destination IP address criterion, a
destination port or port range and an action to perform on that traffic. Multiple listeners
can be defined for a proxy service or console service. Each service has a set of default
actions to apply to the traffic identified by the listeners it owns.
The destination IP address of a connection can match multiple proxy service listeners.
Multiple matches are resolved using the most-specific match algorithm used by routing
devices. A listener is more specific if it has a larger Destination IP subnet prefix. For
example, the subnet 10.0.0.0/24 is more specific than 10.0.0.0/16, which is more specific
than 10.0.0.0/8.
When a new connection is established, the SG appliance first finds the most specific
listener Destination IP. If a match is found, and the destination Port also matches, the
connection is then handled by that listener. If the destination Port of the listener with the
most specific Destination IP does not match, the next most-specific Destination IP is
found; this process continues until either a complete match is found or no more matching
addresses are found.
For example, assume the following services were defined:
Table 3-2. Example Configuration for Most Specific Match Algorithm
Proxy Service

Listener

Service Name

Proxy

Destination IP Address

Port Range

New York Data Center

HTTP

10.167.10.0/24

80

New York CRM

HTTP

10.167.10.2/32

80

HTTP Service

HTTP



80

26

Chapter 3: About Proxy Services

An HTTP connection initiated to server 10.167.10.2 could match any of the three listeners
in the above table. The most specific match algorithm finds that a listener in the New York
CRM service is the most specific and since the destination port of the connection and the
listener match, the connection is handled by this service.
The advantage of the most specific match algorithm becomes evident when at some later
point another server is added in the New York Data Center subnet. If that server needs to
be handled by a different service than the New York Data Center service, a new service
with a listener specific to the new server would be added. The administrator does not
need to be concerned about rule order in order to intercept traffic to this particular server
using the new, most specific service listener.

About Service Attributes
The service attributes define the default parameters the SG appliance uses for a particular
service.
The following table describes the attributes for a proxy service; however, depending on
the protocol, not all attributes are available for each proxy type.
Table 3-3. Service Attributes
Attribute

Description

Authenticate-401

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.

CA-Cert List
Detect Protocol

CA Certificate List used for verifying client certificates.
Detects the protocol being used. Protocols that can be detected include:
HTTP, P2P (eDonkey, BitTorrent, FastTrack, Gnutella), SSL, and Endpoint Mapper.

Early Intercept

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.

Use ADN

Controls whether ADN is enabled for a specific service. Enabling ADN does not
guarantee the connections are accelerated by ADN. The actual enable decision is
determined by ADN routing (for explicit deployment) and network setup (for
transparent deployment).

Forward Client Cert

When used with the verify-client attribute, puts the extracted client certificate
information into a header that is included in the request when it is forwarded to the
OCS. The name of the header is Client-Cert. The header contains the certificate serial
number, subject, validity dates and issuer (all as name=value pairs). The actual
certificate itself is not forwarded.

Optimize Bandwidth

Controls whether to optimize bandwidth usage when connecting upstream using an
ADN tunnel.

Reflect Client IP

Enables the sending of the client's IP address instead of the SG appliance'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. For more information, refer to Volume 6:
Advanced Networking.

SSL Versions

Allows you to select which versions of SSL you want to support. The default is to
support SSL v2, v3, and TLS. This attribute is available for HTTPS Reverse Proxy.

27

Volume 3: Proxies and Proxy Services

Table 3-3. Service Attributes (Continued)
Attribute

Description

Verify Client

Requests and validates the SSL client certificate. This attribute is available for HTTPS
Reverse Proxy.

Understanding Access Logging with Proxy Services
The access log has one field that contains the service name.


x-service-name (ELFF token) service.name (CPL token)

The name of the

service used to intercept this connection.
Note: The x-service-name field replaces the s-sitename field. The s-sitename field

can still be used for backward compatibility with squid log formats, but it has no CPL
equivalent.

Creating or Editing a Proxy Service
The basic procedure for creating or editing a proxy service is shown below. For additional
information on managing a specific proxy, including the proxy service and the proxy
configuration, see:


Chapter 4: "Managing the CIFS Proxy" on page 35



Chapter 5: "Managing the DNS Proxy" on page 51



Chapter 6: "Managing the Endpoint Mapper and MAPI Proxies" on page 55



Chapter 7: "Managing the FTP Proxy" on page 69



Chapter 8: "Managing the HTTP Proxy" on page 77



Chapter 9: "Creating and Editing an HTTPS Reverse Proxy Service" on page 113



Chapter 10: "Managing Shell Proxies" on page 121



Chapter 11: "Managing a SOCKS Proxy" on page 129



Chapter 12: "Managing the SSL Proxy" on page 137



Chapter 13: "Managing the TCP Tunneling Proxy" on page 163

To edit or create a proxy service:
1.

Select Configuration > Services > Proxy Services.

2.

To edit a specific proxy service, highlight the service and click Edit.

3.

To create a new proxy service, click New.
Note: If you only want to change the proxy’s behavior from bypass (the default) to
intercept, go to the Action column of the Proxy Services pane, select the service whose
behavior you want to change, and select Intercept from the drop-down list. You do
not need to enter New/Edit mode to change this setting.

28

Volume 3: Proxies and Proxy Services

Relevant CLI Syntax to Create/Edit a Proxy Service:


To enter configuration mode for the service:
SGOS#(config) proxy-services
SGOS#(config proxy-services) create service-type service-name
SGOS#(config proxy-services) edit service-name



The following subcommands are available:
SGOS#(config service-name) add {transparent | explicit | all |
ip_address | ip_address/subnet-mask} {port | first_port-last_port}
[intercept | bypass]
SGOS#(config service-name) attribute {authenticate-401 | adn-optimize
| ccl | cipher-suite | detect-protocol | early-intercept | forwardclient-cert | keyring | reflect-client-ip | ssl-versions | use-adn |
verify-client}
SGOS#(config
ip_address |
SGOS#(config
ip_address |

service-name) bypass {transparent | explicit | all |
ip_address/subnet-mask} {port | first_port-last_port}
service-name) intercept {transparent | explicit | all |
ip_address/subnet-mask} {port | first_port-last_port}

SGOS#(config service-name) remove {transparent | explicit | all |
ip_address | ip_address/subnet-mask} {port | first_port-last_port}

Viewing the Proxy Services
The Proxy Services pane in the Configuration > Services tab contains the list of all services
created on the appliance. You can sort the list several ways:


Using the Display Filter at the top of the pane. The drop-down list contains the
various proxy names and the bypass/intercept actions. You can select the item you
want to filter on.



Clicking the appropriate column title at the top of the table to sort on the column you
want.

Bypass List
The bypass list contains IP addresses/subnet masks of client and server workstations.
Used only in a transparent proxy environment, the bypass list allows the SG appliance to
skip processing requests sent from specific clients to specific servers. The list allows traffic
between protocol incompliant clients and servers to pass through the SG appliance
without a disruption in service.
Note: This prevents the appliance from enforcing any policy on these requests and
disables any caching of the corresponding responses. Because bypass entries bypass Blue
Coat policy, use bypass sparingly and only for specific situations.

Adding Static Bypass Entries
You can add entries to prevent the requests from specified systems from being intercepted
by the SG appliance.
Note: Dynamic bypass cannot be configured through the Management Console. It can

only be configured through policy or the CLI. For more information, see “ Using Policy to
Configure Dynamic Bypass” on page 31.

30

Volume 3: Proxies and Proxy Services

For a configured period of time, further requests for the error-causing URLs are sent
immediately to the origin content server (OCS), bypassing the SG appliance. The amount
of time a dynamic bypass entry stays in the list and the types of errors that cause the SG
appliance to add a site to the list, as well as several other settings, are configurable from
the CLI.
Once the dynamic bypass timeout for a client and server IP address entry has ended, the
SG appliance removes the entry from the bypass list. On the next client request for the
client and server IP address, the SG appliance attempts to contact the OCS. If the OCS still
returns an error, the entry is once again added to the local bypass list for the configured
dynamic bypass timeout. If the entry does not return an error, the request is handled in the
normal manner.

Notes


Dynamic bypass entries are lost when the SG appliance is restarted.



No policy enforcement occurs on client requests that match entries in the dynamic or
static bypass list.



If a site that requires forwarding policy to reach its destination is entered into the
bypass list, the site is inaccessible.

Configuring Dynamic Bypass
Dynamic bypass is disabled by default. Enabling and fine-tuning dynamic bypass is a
two-step process:


Set the desired dynamic bypass timeout and threshold parameters.



Use policy (recommended) or the CLI to enable dynamic bypass and set the types of
errors that cause dynamic bypass to add an entry to the bypass list.

Adding Dynamic Bypass Parameters to the Local Bypass List
The first step in configuring dynamic bypass is to set the server-threshold,
max-entries, or timeout values.
Note: This step is optional because the SG appliance uses default configurations if you
do not specify them. Use the default values unless you have specific reasons for changing
them. Contact Blue Coat Technical Support for detailed advice on customizing these
settings.


The server-threshold value defines the maximum number of client entries before
the SG appliance consolidates client–server pair entries into a single server entry that
then applies to all clients connecting to that server. The range is 1 to 256. The default is
16. When a consolidation occurs, the lifetime of the consolidated entry is set to the
value of timeout.



The max-entries defines the maximum number of total dynamic bypass entries. The
range is 100 to 50,000. The default value is 10,000. When the number of entries exceeds
the max-entries value, the oldest entry is replaced by the newest entry.



The timeout value defines the number of minutes a dynamic bypass entry can remain
unreferenced before it is deleted from the bypass list. The range is 1 to 86400. The
default value is 60.

32

Chapter 3: About Proxy Services

Enabling Dynamic Bypass and Specifying Triggers
Enabling dynamic bypass and specifying the types of errors that causes a URL to be
added to the local bypass list are done with the CLI. You cannot use the Management
Console.
Using policy to enable dynamic bypass and specify trigger events is better than using the
CLI, because the CLI has only a limited set of responses. For information on available CLI
triggers, refer to the Volume 12: Blue Coat SG Appliance Command Line Reference. For
information on using policy to configure dynamic bypass, refer to the Volume 11: Blue Coat
SG Appliance Content Policy Language Guide.
Bypassing Connection and Receiving Errors
In addition to setting HTTP code triggers, you can enable connection and receive errors
for dynamic bypass.
If connect-error is enabled, any connection failure to the origin content server (OCS),
including timeouts, inserts the OCS destination IP address into the dynamic bypass list.
If receive-error is enabled, when the cache does not receive an HTTP response on a
successful TCP connection to the OCS, the OCS destination IP address is inserted into the
dynamic bypass list. Server timeouts can also trigger receive-error. The default timeout
value is 180 seconds, which can be changed (refer to Volume 2: Getting Started).
Related CLI Syntax to Enable Dynamic Bypass and Trigger Events


To enter configuration mode for the service:
SGOS#(config) proxy-services
SGOS#(config proxy-services) dynamic-bypass



The following subcommands are available:
SGOS#(config dynamic-bypass) {enable | disable}
SGOS#(config dynamic-bypass) max-entries number
SGOS#(config dynamic-bypass) server-threshold number
SGOS#(config dynamic-bypass) trigger {all | connect-error | non-http |
receive-error | 400 | 403 | 405 | 406 | 500 | 502 | 503 | 504}
SGOS#(config dynamic-bypass) timeout minutes
#(config dynamic-bypass) no trigger {all | connect-error | non-http |
receive-error | 400 | 403 | 405 | 406 | 500 | 502 | 503 | 504}
SGOS#(config dynamic-bypass) clear
SGOS#(config dynamic-bypass) view

33

Volume 3: Proxies and Proxy Services

34

Chapter 4: Managing the CIFS Proxy

This chapter discusses the Common Internet File System (CIFS) protocol and describes
how to configure the services and proxy on the SG appliance.
Note: The CIFS protocol is based on the Server Message Block (SMB) protocol used for
file sharing, printers, serial ports, and other communications. It is a client-server,
request-response protocol.

About CIFS
CIFS allows computers to share files and printers, supports authentication, and is
popular in enterprises because it supports all Microsoft operating systems, clients, and
servers.
File servers make file systems and other resources (printers, mailslots, named pipes,
APIs) available to clients on the network. Clients have their own hard disks, but they
can also access shared file systems and printers on the servers.
Clients connect to servers using TCP/IP. After establishing a connection, clients can
send commands (SMBs) to the server that allows them to access shares, open files, read
and write files— the same tasks as with any file system, but over the network.
CIFS is beneficial because it is generic and compatible with the way applications
already share data on local disks and file servers. More than one client can access and
update the same file, while not compromising file-sharing and locking schemes.
However, the challenge for an enterprise is that CIFS communications are inefficient
over low bandwidth lines or lines with high latency, such as in enterprise branch
offices. This is because CIFS transmissions are broken into blocks of data (typically close
to 64 KB). The client must stop and wait for each block to arrive before requesting the
next block. Each stop represents time lost instead of data sent. Therefore, users
attempting to access, move, or modify documents experience substantial, workprohibiting delays.

About the Blue Coat CIFS Proxy Solution
The CIFS proxy on the SG appliance combines the benefits of the CIFS protocol with the
abilities of the SG appliance to improve performance, reduce bandwidth, and apply
basic policy checks. This solution is designed for branch office deployments because
network administrators can consolidate their Windows file servers (at the core office)
instead of spreading them across the network.

35

Chapter 4: Managing the CIFS Proxy

Server Authentication
Permissions set by the origin content server (OCS) are always honored. Requests to
open a file are forwarded to the OCS; if the OCS rejects the client access request, no
content is served from the cache.
Note: NTLM/IWA authentication requires that the client knows what origin server it

is connecting to so it can obtain the proper credentials from the domain controller.

Proxy Authentication
The SG appliance cannot issue a challenge to the user over CIFS, but it is able to make
use of credentials acquired by other protocols if IP surrogates are enabled.

Policy Support
The CIFS proxy supports the proxy, cache, and exception policy layers. However,
the SMB protocol can only return error numbers. Exception definitions in the forms of
strings cannot be seen by an end user. See “Reference: CPL Triggers, Properties, and
Actions” on page 48 for supported CPL triggers and actions.

Access Logging
By default, the SG appliance uses a Blue Coat-derived CIFS access log format.
date time c-ip r-ip r-port x-cifs-method x-cifs-server x-cifs-share
x-cifs-path x-cifs-orig-path x-cifs-client-bytes-read
x-cifs-server-bytes-read x-cifs-bytes-written x-cifs-file-type
s-action cs-username cs-auth-group s-ip

For a reference list and descriptions of used log fields, see “Reference: Access Log
Fields” on page 46.

WCCP Support
If WCCP is deployed for transparency, you must configure WCCP to intercept TCP
ports 139 and 445.

Configuring the SG CIFS Proxy
This section contains the following sub-sections:


“About Windows Security Signatures” on page 37



“Configuring CIFS Proxy Services” on page 39



“Configuring the CIFS Proxy” on page 41



“Reviewing CIFS Protocol Statistics” on page 42

About Windows Security Signatures
Security signatures prevent the CIFS proxy from providing its full acceleration
capabilities. Additionally, security signatures require a considerable amount of
processing on both clients and servers. As their benefits are often superseded by linklayer security measures, such as VPNs and restricted network topology, the benefits are
minimal and the drawbacks are high. The CIFS proxy requires that security signatures
are disabled.

37

Volume 3: Proxies and Proxy Services

2.

Configure the CIFS proxy options:
a.

Read ahead: Enabled by default, which reduces the latency of the

connection. The SG appliance might partially cache a requested object (the
part directly requested and viewed by the client). When Read ahead is
enabled, the appliance attempts to anticipate what block of data (up to 64K)
might be requested next, fetches it, and caches it.
If applications are performing a large amount of non-sequential file access,
disabling Read Ahead reduces the amount of unnecessary data being fetched
into the cache.
b.

Write behind: Enabled by default. This option applies to when clients
attempt to write to a file on the core server. Without the CIFS proxy, a client
would experience substantial latency as it sends data chunks and waits for
the acknowledgement from the server to write the next data chunks. With
this option enabled the branch SG appliance is viewed by the client as the
file server; the appliance constantly sends approval to the client and allows
the client to write data while on the back end takes advantage of the
compressed TCP connection and sends the data to the core server.

A reason for disabling this option is the risk of data loss if the link from the
branch to the core fails. There is no way to recover queued data if such a link
failure occurs.
c.

Directory Cache Time: This option determines how long directory

information is kept in cache. Changes made to a directory by clients not
using the SG appliance are not visible to SG clients if they occur within this
time interval. The default cache time is 30 seconds. Blue Coat recommends
keeping this value low to ensure clients have access to the most current
directory information; however, you can set it longer if your applications
use CIFS to access files. For example, the cache responds faster if it knows
directory X does not contain the file and so moves on to directory Y, which
reduces the number of round trips to the file server.
3.

If you changed any options, click Apply.

Enabling CIFS Access Logging
By default, the SG appliance is configured to use the Blue Coat CIFS access log format.
Access Logging is enabled on the Configuration > Access Logging > General page.
For information about access log customization, refer to Volume 9: Access Logging.

Reviewing CIFS Protocol Statistics
After CIFS traffic begins to flow through the SG appliance, you can review the statistics
page and monitor results in various CIFS categories. The presented statistics are
representative of the client perspective.
To review CIFS statistics:
1.

From the Management Console, select Statistics > CIFS History.

42

Volume 3: Proxies and Proxy Services

SGOS#(config service-name) view

Reference: Access Log Fields
The default Blue Coat CIFS Access Log fields are:


c-ip: IP address of the CIFS client.



c-port: The CIFS client port TCP connection.



cs-auth-group: One group that an authenticated user belongs to. If a user belongs
to multiple groups, the group logged is determined by the Group Log Order
configuration specified in VPM. If the Group Log Order is not specified, an
arbitrary group is logged. Note that only groups referenced by policy are
considered.



cs-username: Relative username of a client authenticated to the proxy (for
example: not fully distinguished).



r-ip: IP address from the outbound server URL.



r-port: Port from the outbound server URL, typically 139 or 445.



s-action: The logging action (or flow) being one of the following:



ALLOWED: CIFS operation passed the policy checkpoint and was also successful.



DENIED: CIFS operation failed the policy checkpoint.



ERROR: CIFS operation resulted in an error on the server; typically associated
with NT (x-cifs-nt-error-code) or DOS error (x-cifs-dos-error-code, xcifs-dos-error-class).



FAILED: CIFS operation was successful on the server but failed on the proxy for
some internal reason.



SUCCESS: CIFS operation was successful on the server (did not go through
policy checkpoint).



s-ip: IP address of the appliance on which the client established its connection.



x-cifs-client-bytes-read: Total number of bytes read by a CIFS client from the
associated resource. For OPEN/CLOSE, it is the total for that specific file. For
MOUNT/UNMOUNT, the total for all files accessed in that share. For LOGON/LOGOFF,
the total for all files accessed in that session. For CONNECT/DISCONNECT, the total
for all files accessed during that connection.



x-cifs-client-write-operations: Total number of client write operations for
this particular resource. The scope is the same as x-cifs-client-readoperations.



x-cifs-client-other-operations: Total number of client operations that are not
reads or writes for this particular resource. The scope is the same as x-cifsclient-read-operations. MOUNT/UNMOUNT might also include operations not
tied to a specific open file.



x-cifs-bytes-written: Total number of bytes written to the associated resource.



x-cifs-dos-error-class: DOS error class generated by server, in hexadecimal.



x-cifs-dos-error-code: DOS error code generated by server, in hexadecimal.

46

Chapter 4: Managing the CIFS Proxy



x-cifs-error-cod: CIFS error code generated by server. If the error code is in NT
format, it is a single hexadecimal number of the form 0xNNNNNNNN. If the error code
is in DOS format, it is two hexadecimal numbers of the form 0xNN/0xNNNN. The
first number is the DOS error class, and the second is the DOS error code. This field
is a combination of the x-cifs-nt-error-code, x-cifs-dos-error-class, and
x-cifs-dos-error-code.



x-cifs-fid: Numeric ID representing a CIFS resource.



x-cifs-file-size: Size in bytes of CIFS resource.



x-cifs-file-type: The type of file that was opened or closed. Values are file,
directory, pipe, or other. It is only valid if x-cifs-method is OPEN, CLOSE,
CLOSE_ON_UNMAP, CLOSE_ON_LOGOFF, CLOSE_ON_DISCONNECT, or
CLOSE_ON_PASSTHRU.



x-cifs-method: The method associated with the CIFS request. The list of CIFS

methods are:


CONNECT: For TCP-level connect from client to CIFS server.



DISCONNECT: For TCP-level connection shutdown.



LOGON: For SESSION_SETUP_ANDX SMB command.



LOGOFF: For LOGOFF_ANDX SMB command.



LOGOFF_ON_PASSTHRU: For removal of cached session from proxy upon
PASSTHRU.



LOGOFF_ON_DISCONNECT: For removal of cached session from proxy upon

DISCONNECT.


MAP: For TREE_CONNECT SMB command.



UNMAP: For TREE_DISCONNECT SMB command.



UNMAP_ON_LOGOFF: For removal of cached share from proxy upon LOGOFF.



UNMAP_ON_PASSTHRU: For removal of cached share from proxy upon PASSTHRU.



UNMAP_ON_DISCONNECT: For removal of cached share from proxy upon
DISCONNECT.



DELETE: For path-based DELETE and DELETE_DIRECTORY SMB commands.



DELETE_ON_CLOSE: For delete-on-close action done on a CIFS resource.



LIST: For enumerating contents of a directory.



OPEN: For opening a CIFS resource.



RENAME: For renaming a CIFS resource.



CLOSE: For closing a CIFS resource.



CLOSE_ON_UNMAP: For removal of cached file from proxy upon UNMAP.



CLOSE_ON_LOGOFF: For removal of cached file from proxy upon LOGOFF.



CLOSE_ON_PASSTHRU: For removal of cached file from proxy upon PASSTHRU.



CLOSE_ON_DISCONNECT: For removal of cached file from proxy upon
DISCONNECT.



PASSTHRU: For connections which Blue Coat is unable to handle:

47

Volume 3: Proxies and Proxy Services





Client or server does not support NTLM 0.12 dialect.



Security signatures are enabled.



Client or server does not support Unicode characters.



The SESSION_SETUP_ANDX SMB request is malformed (with unknown
word count).



Header portion of some SMB command is malformed.



NETBIOS header is malformed.

OPEN_STATS: Log the same fields as CLOSE for gathering time-based activity

information on open files. This occurs on a 5 minute interval if there was
activity on the file within that interval.


x-cifs-nt-error-code: CIFS error code generated by server, in hexadecimal.



x-cifs-orig-path: Original path name of resource to be renamed.



x-cifs-orig-unc-path: UNC path of original path name of resource to be

renamed.


x-cifs-path: CIFS resource name as specified in the UNC path.



x-cifs-server: CIFS server as specified in the UNC path.



x-cifs-server-bytes-read: Total number of bytes read from CIFS server from

the associated resource.


x-cifs-server-operations: Total number of server operations for this particular
resource. The scope is the same as x-cifs-client-read-operations.



x-cifs-share: CIFS share name as specified in the UNC path.



x-cifs-tid: ID representing instance of an authenticated connection to server

resource.



x-cifs-uid: ID representing an authenticated user instance.
x-cifs-unc-path: CIFS path of form \\server\share\path where path might be

empty.


x-client-connection-bytes: Number of bytes sent to and received from the

client.


x-server-connection-bytes: Number of bytes sent to and received from the

server. If ADN is used for the server connection, this is the number of bytes before
ADN compression is applied.


x-server-adn-connection-bytes: Number of bytes sent to and received from the
server-side ADN peer if ADN is used for the server connection. If ADN is not used,
this is displayed as "-".

Reference: CPL Triggers, Properties, and Actions
The following CPL applies to CIFS policy:

Triggers


attribute.=, has_attribute.=



client.address=, client.host=, client.host.has_name=

48

Chapter 4: Managing the CIFS Proxy



client.protocol=smb



content_management=no



condition=



date[.utc]=, day=, hour=, minute=, month=, weekday=, year=, time=



has_client=



proxy.address=, proxy.port=, proxy.card=



raw_url=



release.*=



server_url=



socks.accelerated=smb



tunneled=



url=smb://:/



user.*=, group=, realm=, authenticated=

Properties and Actions:


action()



access_log.*(), log.*(), log_message(), notify_email(),
notify_snmp()



authenticate.*()



allow, deny, deny.*(), exception.*(), force_deny.*(),
force_exception.*()



bypass_cache()



detect_protocol(smb), force_protocol(smb)



forward(), forward.fail_open(), socks_gateway(),
socks_gateway.fail_open()



limit_bandwidth(smb)



reflect_ip()



rewrite(url), rewrite(url.host), set(url.port)



trace.*()

49

Volume 3: Proxies and Proxy Services

50

Chapter 5: Managing the DNS Proxy

When a DNS proxy service is enabled, it listens on port 53 for both explicit and
transparent DNS domain query requests. By default, the service is created but not
enabled.
The DNS does a lookup of the DNS cache to determine if requests can be answered. If
yes, the SG appliance responds. If not, the DNS forwards the request to the DNS server
list configured on the SG appliance. (To configure the DNS server list, see Configuration
> Network > DNS.)
Note: The SG appliance is not a DNS server. It does not do zone transfers, and
recursive queries are forwarded to other name servers.

For information on managing DNS name servers, refer to Volume 2: Getting Started.
Through policy, you can configure the list of resolved domain names (the resolving name
list) the DNS uses. The domain name in each query received by the SG appliance is
compared against the resolving name list. Upon a match, the appliance checks the
resolving list. If a domain name match is found but no IP address was configured for
the domain, the appliance sends a DNS query response containing its own IP address.
If a domain name match is found with a corresponding IP address, that IP address is
returned in a DNS query response. All unmatched queries are sent to the name servers
configured on the SG appliance.
This chapter discusses:


“Creating or Editing a DNS Proxy Service”



“ Creating a Resolving Name List” on page 53

Creating or Editing a DNS Proxy Service
To create or edit a DNS proxy service:
1.

Select Configuration > Services > Proxy Services.

2.

To edit a specific proxy service, highlight the service and click Edit.

3.

To create a new proxy service, click New.

Note: If you only want to change the proxy’s behavior from bypass (the default) to
intercept, go to the Action column of the Proxy Services pane, select the service whose
behavior you want to change, and select Intercept from the drop-down list. You do
not need to enter New/Edit mode to change this attribute.

51

Chapter 5: Managing the DNS Proxy

Relevant CLI Syntax to Create/Edit a DNS Proxy Service


To enter configuration mode for the service:
SGOS#(config) proxy-services
SGOS#(config proxy-services) create dns service-name
SGOS#(config proxy-services) edit service-name



The following subcommands are available:
SGOS#(config service-name) add {transparent | explicit | all |
ip_address | ip_address/subnet-mask} {port | first_port-last_port}
[intercept | bypass]
SGOS#(config service-name) attribute reflect-client-ip {enable |
disable}
SGOS#(config service-name) bypass {transparent | explicit | all |
ip_address | ip_address/subnet-mask} {port | first_port-last_port}
SGOS#(config service-name) exit
SGOS#(config service-name) intercept {transparent | explicit | all |
ip_address | ip_address/subnet-mask} {port | first_port-last_port}
SGOS#(config service-name) remove {transparent | explicit | all |
ip_address | ip_address/subnet-mask} {port | first_port-last_port}
SGOS#(config service-name) view

Creating a Resolving Name List
You can create the resolving name list that the DNS proxy uses to resolve domain names.
This procedure can only be done through policy. (For a discussion on using the layer, refer to Volume 11: Blue Coat SG Appliance Content Policy Language Guide .)
Each name resolving list entry contains a domain-name matching pattern. The matching
rules are:


test.com matches only test.com and nothing else.



.test.com matches test.com, www.test.com and so on.



“.” matches all domain names.

An optional IP address can be added, which allows the DNS proxy to return any IP
address if the DNS request's name matches the domain name suffix string (domain.name).
To create a resolving name list, create a policy, using the layer, that contains
text similar to the following:

dns.request.name=www.example.com dns.respond.a(vip)
-or
dns.request.name=.example.com dns.respond.a(vip)
-or
dns.request.name=www.example.com dns.respond.a(10.1.2.3)
Note: You can also create a resolving name list using VPM. For more information on
using the DNS-Proxy layer in VPM, refer to Volume 2: Getting Started.

53

Volume 3: Proxies and Proxy Services

54

Chapter 6: Managing the Endpoint Mapper and MAPI Proxies

This chapter discusses the Endpoint Mapper and MAPI proxy solutions, and describes
how to configure the services and proxy configuration.
The Endpoint Mapper and MAPI proxies are similar in that they accelerate Microsoft
applications across a WAN; however, there are key differences.
This chapter contains the following sections:


Section A: "The Endpoint Mapper Proxy Service" on page 56.



Section B: "The MAPI Proxy" on page 62.

55

Volume 3: Proxies and Proxy Services
Section A: The Endpoint Mapper Proxy Service

Section A: The Endpoint Mapper Proxy Service
This section discusses the Microsoft Remote Procedure Call (RPC) protocol and describes
how to configure the Endpoint Mapper proxy service on the SG appliance.

About RPC
The Microsoft RPC protocol functions across a client/server model where one application
requests a service from another application. The requesting program is the client; the
providing service is the server. RPC allows an application on one host (the client) to
request and thereby cause an application on another host (the server) to execute an action
without the requirement of explicit code. For example: MAPI traffic.
Typically, RPC communications occur when the client contacts the Endpoint Mapper
service on that client host to determine how to contact the server. The client provides the
RPC service identifier and the Endpoint Mapper service returns the IP and port the client
uses to contact the server. Then, the client makes a new TCP connection to that IP and port
and sends its RPC request.
The challenges occur when these communications occur between branch offices and
servers located in core locations. The user experience is poor because of low available
bandwidth or high latency lines.

About the Blue Coat Endpoint Mapper Proxy Solution
The Endpoint Mapper proxy intercepts an RPC client request for a particular RPC service.
The Endpoint Mapper proxy looks up the request in its local database, and if there is a
match it replies to the client the port number the RPC service is listening on. If it is not in
the database, it forwards the request up to the server. The server responds with the port
number the service is listening on, and the Endpoint Mapper proxy populates its internal
database. It then creates a secondary listener on that RPC port and server IP address, and
responds to the RPC client with the port number. When the RPC client connects to the
service, the Endpoint Mapper proxy secondary service intercepts the request and tunnels
it.
Substantial performance increase occurs because:


The SG appliance caches server information, negating the requirement to connect to
an upstream server for repeated requests.



The SG appliance at the branch compresses RPC traffic and sends it over the TCP
connection to the core SG appliance, which decompresses the data before sending it to
the RPC server.

The Endpoint Mapper proxy can be deployed in both transparent and explicit modes.
Intercepting RPC traffic is part of the complete solution that includes the MAPI proxy
("Section B: The MAPI Proxy" on page 62).
Note: Only Microsoft RPC version 5.0 is supported. Unsupported Microsoft RPC version
traffic is passed through the SG appliance without processing.

56

Chapter 6: Managing the Endpoint Mapper and MAPI Proxies

Section A: The Endpoint Mapper Proxy Service
Result: The Endpoint Mapper service is configured and appears in Management Console.
RPC traffic is intercepted.

Reviewing Endpoint Mapper Proxy Statistics
After RPC traffic begins to flow through the SG appliance, you can review the statistics
page and monitor results in various categories. The presented statistics are representative
of the client perspective.

Statistic URL Pages
Endpoint Mapper proxy statistics pages are viewable from Management Console URLs.
Statistics
This page displays various, more granular connection and byte statistics.
https://SG_IP_address:8082/epmapper/statistics

Detailed Statistics
This page displays specific client-to-server connection and file information and statistics.
https://SG_IP_address:8082/epmapper/detailed-statistics

Reference: Equivalent Endpoint Mapper Proxy CLI Commands
The Management Console procedures in this section have the following equivalent CLI
command roots:


To enter configuration mode for the service:
SGOS#(config) proxy-services
SGOS#(config proxy-services) create endpoint-mapper service-name
SGOS#(config proxy-services) edit service-name



The following subcommands are available:
SGOS#(config service-name) add {all | ip_address | ip_address/subnetmask} {port | first_port-last_port} [intercept | bypass]
SGOS#(config service-name) attribute {adn-optimize {enable | disable}|
reflect-client-ip {enable | disable}}
SGOS#(config service-name) bypass {all | ip_address | ip_address/
subnet-mask} {port | first_port-last_port}}
SGOS#(config service-name) exit
SGOS#(config service-name) intercept {all | ip_address | ip_address/
subnet-mask} {port | first_port-last_port}}
SGOS#(config service-name) remove {all | ip_address | ip_address/
subnet-mask} {port | first_port-last_port}
SGOS#(config service-name) view

Reference: Access Log Fields
The default SG appliance Endpoint Mapper Access Log fields are:


date: GMT Date in YYYY-MM-DD format.



time: GMT time in HH:MM:SS format.

59

Volume 3: Proxies and Proxy Services
Section A: The Endpoint Mapper Proxy Service


cs-bytes, sr-bytes, rs-bytes, sc-bytes: Standard ELFF format. The total RPC

byte counts in the specified direction (client-server).


cs-method: Request method used from client to appliance.



time-taken: Time taken (in milliseconds) to process the request.



c-ip: IP address of the RPC client.



s-action: The logging action (or flow) being one of the following:



ALLOWED: Endpoint operation passed the policy checkpoint and was also
successful.



DENIED: Endpoint operation failed the policy checkpoint.



FAILED: Endpoint operation was successful on the server but failed on the proxy
for some internal reason.



TUNNELED: Traffic was tunneled.



cs-uri-scheme: Scheme from the log URL.



cs-host: Hostname from the client's request URL. If URL rewrite policies are used,

this field's value is derived from the log URL.


cs-port: Port used from the client to the appliance.



cs-username: Relative username of a client authenticated to the proxy (for example:
not fully distinguished).



s-supplier-ip: IP address of the upstream host (not available for a cache hit).



s-supplier-name: Hostname of the upstream host (not available for a cache hit).



s-supplier port: Port number of the upstream host (not available for a cache hit).



r-supplier-ip: IP address used to contact the upstream host (not available for a

cache hit).


r-supplier-name: Hostname used to contact the upstream host (not available for a

cache hit).


r-supplier port: Port used to contact the upstream host (not available for a cache

hit).


sc-filter-result: Content filtering result: Denied, Proxied, or Observed.



sc-filter-category: Content filtering category.



s-ip: IP address of the appliance on which the client established its connection.



s-sitename: Service used to process the transaction.

Reference: CPL Triggers, Properties, and Actions
The following SG appliance CPL is supported in the Endpoint Mapper proxy service:


allow/deny

TCP Tunneling Triggers


Client: client.address, client.host, client.host.has_name, client protocol
(recognizes epmapper token).

60

Chapter 6: Managing the Endpoint Mapper and MAPI Proxies

Section A: The Endpoint Mapper Proxy Service


Date/Time: date[.utc], day, hour, minute, month, weekday, year, time



Proxy: proxy.address, proxy.port, proxy.card



has_client



url

Properties and Actions


allow/deny



trace



log_message



notify_email, notify_snmp



reflect_ip



access_log



forward



socks_gateway

61

Volume 3: Proxies and Proxy Services
Section B: The MAPI Proxy

Section B: The MAPI Proxy
This section discusses the Messaging Application Programing Interface (MAPI) protocol
and describes how to configure the services and proxy on the SG appliance.

About MAPI
MAPI is the protocol used by Microsoft Outlook (client) to communicate with Microsoft
Exchange (server), most commonly for e-mail applications. MAPI itself is based on the
Microsoft Remote Procedure Call (RPC).
Because MAPI is based on RPC, it suffers from the same performance inherent with RPC
communications. Microsoft Outlook is the most common enterprise e-mail application. As
enterprises continue to trend toward consolidating servers, which requires more WAN
deployments (branch and remote locations), e-mail application users experience
debilitating response times for not only sending and receiving mail, but accessing
message folders or changing calendar elements. This is because MAPI RPC transmissions
are broken into blocks of data (no more than 32 KB). The client must stop and wait for each
block to arrive before requesting the next block. Each stop represents time lost instead of
data sent.

About the Blue Coat MAPI Solution
The MAPI proxy is similar to and actually works in conjunction with the Endpoint
Mapper proxy in that it intercepts and accelerates RPCs; however, MAPI is always
deployed transparently and does not listen on a specific port or port range. Instead, when
configured to do so, the Endpoint Mapper proxy hands off Outlook/Exchange traffic to the
MAPI proxy (but the Endpoint Mapper proxy functionality is still required to make an
RPC connection).
The MAPI proxy itself is a split proxy, which is only viable in a deployment that consists of
a branch proxy and core proxy. A split proxy employs co-operative processing at the
branch and the core to implement functionality that is not possible in a standalone proxy.
In the case of the MAPI Proxy, cooperation exists between the branch SG appliance and
the core SG appliance to reduce the number of RPCs sent across the WAN.
The TCP connection between the branch and core proxies makes use of byte caching for
acceleration (compression).

62

Volume 3: Proxies and Proxy Services
Section B: The MAPI Proxy

Supported Servers
The MAPI proxy supports:


MAPI 2000 (Outlook/Exchange 2000).



MAPI 2003—Tunneled over TCP. The Batching and Keep-Alive features are not
available.

Access Logging
The MAPI proxy uses a default access log format. Data includes user actions, data lengths
(bytes), and RPC data.
date, time, c-ip, c-port, r-ip, r-port, x-mapi-user, x-mapi-method,
cs-bytes, sr-bytes, rs-bytes, sc-bytes, x-mapi-sc-rpc-count, x-mapisr-rpc-count, x-mapi-rs-rpc-count, x-mapi-sc-rpc-count, s-action, csusername, cs-auth-group, s-ip

For MAPI-specific descriptions, see “Reference: Access Log Fields” .

More Conceptual Reference


“About RPC” on page 56.



Volume 6: Advanced Networking.

Configuring the SG MAPI Proxy
This section contains the following sub-sections:


“Configuring the SG Appliance Endpoint Mapper Service” on page 57.



“Reviewing Endpoint Mapper Proxy Statistics” on page 59.

About the MAPI Service
By default (upon upgrade and on new systems), the SG appliance has an Endpoint
Mapper proxy service configured on port 135. The service is also configured to listen to all
IP addresses, but is set in Bypass mode. As the MAPI proxy processes RPC
communication as well, it uses the Endpoint Mapper proxy service. See "Section A: The
Endpoint Mapper Proxy Service" on page 56.

Configuring the MAPI Proxy
The MAPI Proxy options concern Batching, Handoff, and Keep-Alive features. This
section describes these options and why they might require changing based on your
branch deployment.
To view/change the MAPI Proxy configuration options:
1.

In the Management Console, select Configuration > Proxy Settings > MAPI Proxy.

64

Volume 3: Proxies and Proxy Services
Section B: The MAPI Proxy
To review MAPI statistics:
1.
2.

From the Management Console, select Statistics > MAPI History.
View statistics:
a.

b.

3.

Select a statistic category tab:


MAPI Clients Bytes Read: The total number of bytes read by MAPI clients.



MAPI Clients Bytes Written: The total number of bytes written by MAPI clients.



MAPI Clients: The total number of connected MAPI clients.

The graphs display three time metrics: the previous 60 minutes, the previous
24 hours, and the previous 60 days. Roll the mouse over any colored bar to
view the exact metric.

(Optional) You can change the scale of the graph to display the percentage of bar
peaks to display.

Reference: Equivalent MAPI Proxy CLI Commands
The Management Console procedures in this chapter have the following equivalent CLI
command roots:
SGOS#(config) mapi


The following subcommands are available:
SGOS#(config mapi) handoff (enable | disable}
SGOS#(config mapi) batching {enable | disable}
SGOS#(config mapi) keep-alive {enable | disable}
SGOS#(config mapi) keep-alive interval [minutes 1-60]
SGOS#(config mapi) keep-alive duration [hours 1-72]
SGOS#(config mapi) {view | exit}

Reference: Access Log Fields
The default MAPI Access Log fields are:
"date time c-ip c-port r-ip r-port x-mapi-user "\
"x-mapi-method cs-bytes sr-bytes rs-bytes sc-bytes "\
"x-mapi-cs-rpc-count x-mapi-sr-rpc-count "\
"x-mapi-rs-rpc-count x-mapi-sc-rpc-count "\
"s-action cs-username cs-auth-group s-ip"


cs-bytes, sr-bytes, rs-bytes, sc-bytes: Standard ELFF format. The total RPC

byte counts in the specified direction (client-server).


x-mapi-method: The end-user operation, one of:



STARTUP: The start of a MAPI session. A single user can have more than one active
MAPI sessions for a single instance of Outlook.



SHUTDOWN: The end of a MAPI session.



SEND: Outlook is sending an e-mail (with or without attachments) to Exchange
and the SG appliance is batching the contents.



FETCH: Outlook is fetching an e-mail (with or without attachments) to Exchange
and the SG appliance is batching the contents.

66

Chapter 6: Managing the Endpoint Mapper and MAPI Proxies

Section B: The MAPI Proxy





KEEP_ALIVE_STARTUP: A keep-alive session started.



KEEP_ALIVE_SHUTDOWN: A keep-alive session ended.



KEEP_ALIVE_NEGOTIATE: Messages were sent to query the state of the Inbox
during a keep-alive session.



KEEP_ALIVE_FETCH: An e-mail (with or without attachments) was fetched during
a keep-alive session.

x-mapi-user-dn: The full user domain name gathered from the MAPI negotiation of

user credentials between Outlook and Exchange.


x-mapi-user: A shortened form of the user domain name.



s-action:



ALLOWED: The traffic was permitted through.



SUCCESS: The traffic was successfully proxied, but was not subject to policy.



DENIED: The traffic was denied by policy.



SERVER_ERROR: The traffic was dropped because of an error communicating with

the server.


FAILED: The traffic was dropped because of an error when handling the messages
sent by the client. Or an internal problem with the MAPI proxy.



BATCHED: The traffic was batched.



TUNNELED: The traffic was tunneled to the Exchange server for one of two reasons:



The MAPI traffic is encrypted; therefore, the SG appliance cannot batch
messages or attachments and thus cannot provide WAN optimization benefits.



The MAPI proxy could not connect upstream through an Application
Delivery Network (ADN) tunnel.



x-cs-mapi-rpc-count: The number of RPCs sent from the client to the proxy.



x-sr-mapi-rpc-count: The number of RPCs sent from the proxy to the server.



x-rs-mapi-rpc-count: The number of RPCs sent from the server to the proxy.



x-sc-mapi-rpc-count: The number of RPCs sent from the proxy to the client.

67

Volume 3: Proxies and Proxy Services

68

Chapter 7: Managing the FTP Proxy

Blue Coat supports accessing FTP origin content servers over HTTP (Web FTP) as well
as supporting native FTP proxy.
Web FTP is used when a client connects in explicit mode using HTTP and accesses an
ftp:// URL. The SG appliance translates the HTTP request into an FTP request for the
origin content server (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.
Native FTP involves the client connecting (either explicitly or transparently) using FTP;
the SG appliance then connects upstream through FTP (if necessary).

Understanding FTP
With Blue Coat’s implementation of FTP, you can control how the SG appliance
responds to FTP client requests. You can also control which IP addresses are used.
This section discusses:


“Passive Mode Data Connections” on page 69



“Understanding IP Reflection for FTP” on page 70

Passive Mode Data Connections
Data connections initiated by an FTP server to an FTP client at the port and IP address
requested by the FTP client are known as PORT or active connections. This connection
method is used when the FTP server can connect directly to the FTP client.
Data connections initiated by an FTP client to an FTP server at the port and IP address
requested by the FTP server are known as passive mode data connections. This type of
connection is useful in situations where an FTP server is unable to make a connection to
an FTP client because the client is located behind a firewall or other similar device
where outbound connections from the client are allowed, but inbound connections to
the client are blocked.
Using passive mode data connections (which can set through the Management Console
or the CLI) allows administrators to select how the SG appliance responds to a request
from an FTP client for a passive mode data connection (PASV command).
Some FTP clients do not open a passive mode data connection to an IP address that is
different from the IP address used for the control connection.
Disabling PASV on the SG appliance servicing requests from this type of FTP client
might provide a more acceptable response to the end user.
When PASV is disabled, some FTP clients try a PORT command automatically, which
allows requests to be received when the client doesn't allow PASV connections to a
different IP address.
Note: some clients might display an error when PASV is disabled on the SG
appliance, requiring you to manually request PORT mode.

69

Volume 3: Proxies and Proxy Services

The FTP client software controls any messages displayed to the end user as a result of this
response from the SG appliance.

Understanding IP Reflection for FTP
IP reflection determines how the client IP address is presented to the origin server for all
requests. The FTP service uses a Reflect Client IP attribute that enables or disables sending
of client's IP address instead of sending the SG appliance's IP address by default when
connecting to the OCS.
IP reflection in policy and the corresponding attribute in services can be used for FTP
control connections to the OCS; certain deployments are subject to limitations. The client
and server-side policies are:


ftp.match_client_data_ip(yes)—The SG appliance always reflects the IP address
that the client originally attempts to connect to on the client-side control connection.
The ftp.match_client_data_ip(yes) property allows you to also use that same
client IP address when making an active data connection back to the client. This is
independent of whether reflect_ip() or ftp.match_server_data_ip() is in use
on the server side.



reflect_ip( )—Controls whether to do IP reflection for server-side control

connections. This can also be enabled using the Reflect Client IP attribute.


ftp.match_server_data_ip(yes)—Matches the source IP address of the PASV data
connection with the source IP address of the SG appliance control connection (server
side). Note that the reflect_ip( ) policy must be set for
ftp.match_server_data_ip(yes) to be meaningful.

The following points describe the various data flow scenarios:


Outbound client data connection (SG appliance to client)—When the client issues a
PORT command, the appliance opens a data connection to the FTP client with the
source IP address of whatever destination IP address the client used when opening
the control connection.



Inbound client data connection (client to SG appliance)—When the client issues a
PASV command, the appliance returns the IP address and port to which client makes
a data connection.


Explicit—The SG appliance returns the destination IP address of the control
connection; this can be a physical or virtual IP address.



Transparent—The SG appliance returns the IP address of the physical adapter on
which the control connection arrived.

Note: For information on using transparent or explicit proxies, see Appendix B:
"Explicit and Transparent Proxy" on page 175.


Outbound server data connection (SG appliance to FTP server)—When the SG
appliance issues a PASV command upstream, the server returns an IP address and
port to connect to. The appliance then opens a data connection to the server with the
same source IP address it used to open the control connection. This address is defined
by the reflect_ip property.



Inbound server data connection (FTP server to SG appliance)—When the SG
appliance issues a PORT command, the appliance provides the IP address and port
number to which the server makes a data connection.

70

Chapter 7: Managing the FTP Proxy



The SG appliance sends the control connection’s source IP address if that IP is a
local appliance (virtual or physical) IP address; or



The SG appliance sends the IP address of the physical adapter that was used to
make the outgoing control connection.

FTP Server Notes


IIS and WS_FTP servers do not support PASV data connections with a source IP
address that is different from the source IP address of the control connection.



IIS and WS_FTP servers do not support ACTIVE data connections with a destination
IP address that differs from the source IP address of the control connection.

Notes


Internet Explorer does not support proxy authentication for native FTP.



The SG appliance FTP proxy does not support customized exception text; that is, you
can use policy to deny requests, but you can't control the text sent in the error
message.

Configuring the SG Appliance for Native FTP Proxy
This section discusses:


“Creating or Editing the FTP Service”



“Configuring the FTP Proxy” on page 73



“Configuring FTP Clients” on page 74

Creating or Editing the FTP Service
An FTP service is created by default, but it is in bypass mode. The service is not
functioning until it is in intercept mode.
Note: Web FTP requires an HTTP service, not an FTP service. For information on
configuring an HTTP proxy service, see “Chapter 8: Managing the HTTP Proxy” on page
77.

To create or edit an FTP proxy service:
1.

From the Management Console, select Configuration > Services > Proxy Services.

2.

To edit an existing FTP proxy service, highlight the service and click Edit. To create a
new proxy service, click New.
Note: If you only want to change the proxy’s behavior from bypass (the default) to
intercept, go to the Action column of the Proxy Services pane, select the service whose
behavior you want to change, and select Intercept from the drop-down list. You do
not need to enter New/Edit mode to change this attribute.

71

Volume 3: Proxies and Proxy Services

2.

Select Allow caching of FTP objects. The default is enabled.

3.

Determine the amount of time in percentage of how long since the object was last
modified. The default is 10%.

4.

Enter an amount, in hours, that the object remains in the cache before becoming
eligible for deletion. The default is 24 hours.

5.

Select Allow use of PASV mode to clients. The default is enabled, allowing data
connections to be initiated by an FTP client to an FTP server at the port and IP address
requested by the FTP server.

Related CLI Syntax to Configure the FTP Proxy
SGOS#(config)
SGOS#(config)
SGOS#(config)
SGOS#(config)

ftp
ftp
ftp
ftp

login-syntax (raptor | checkpoint}
passive-mode {enable | disable}
no welcome-banner
welcome banner

SGOS#(config) caching
SGOS#(config caching) max-cache-size number8
SGOS#(config caching) ftp
SGOS#(config caching ftp) enable
SGOS#(config caching ftp) type-m-percent number
SGOS#(config caching ftp) type-n-initial number
Note: Neither proxy authentication for transparent FTP nor proxy chaining are
supported with the Checkpoint syntax.

Configuring FTP Clients
if you want to configure an FTP client to explicitly proxy to the SG appliance, complete
the following steps.
Note: The steps below are for a WSFtp client. Other clients vary.


Enable firewall.



Select USER with no logon unless you are doing proxy authentication. In that case,
select USER [email protected] fireID and specify a proxy username and password.

Example
The illustration demonstrates a WSFtp client configuration.

74

Volume 3: Proxies and Proxy Services

Related CPL Syntax to Create Policy that Overrides the Default Banner

ftp.welcome_banner("message")

If entering text that spans more than one line, use $(crlf) for line breaks.

Viewing FTP Statistics
See Chapter 8: "Managing the HTTP Proxy" on page 77 for information about viewing
the FTP statistics.

76

Chapter 8: Managing the HTTP Proxy

By default, an HTTP proxy service, with both explicit and transparent attributes set, is
enabled on port 80. To change the attributes of the proxy service or create new HTTP
proxy services, see “Creating or Editing a Proxy Service” on page 28.
The HTTP proxy is the first line of defense for the SG appliance, controlling all traffic
that arrives on port 80 . To control that traffic and improve performance, you can:


Set default caching policies to configure the length of time an object or negative
response is cached, whether objects are always revalidated before being served,
whether server certificates are verified by default, and how headers are parsed. For
more information, see “Understanding Tolerant HTTP Request Parsing” on page
96.



Configure the HTTP proxy as a server accelerator. For more information, see
“Customizing the HTTP Proxy Profile” on page 88.



Set a limit to the maximum bandwidth the SG appliance is allowed to use for
refreshing objects in the background. For more information, see “Setting Default
HTTP Proxy Policy” on page 86.



Compress and decompress content. For more information, see “Understanding
HTTP Compression” on page 97.

Note: Use of the compression feature is a trade-off among three resources: server-side
bandwidth, client side-bandwidth, and CPU. If server-side bandwidth is expensive
compared to CPU, always request compressed content from the origin content server
(OCS). If CPU is comparatively expensive, then the SG appliance should ask the server
for the compression formats that the client asked for and forward whatever the server
returns.

The HTTP proxy is designed to control Web traffic, providing:


Security



Authentication



Virus Scanning and Patience Pages



Performance


Default HTTP Proxy Policy



HTTP Proxy Caching Profiles



Byte-Range Support



Refresh Bandwidth



Compression

77

Volume 3: Proxies and Proxy Services

This chapter discusses:


“Creating an HTTP Proxy Service” on page 79



“Overview: Configuring HTTP Proxy Performance” on page 83



“Configuring the HTTP Proxy” on page 86



“Viewing HTTP/FTP Statistics” on page 105



“Using Explicit HTTP Proxy with Internet Explorer” on page 109

78

Chapter 8: Managing the HTTP Proxy

Section A: Creating an HTTP Proxy Service

Section A: Creating an HTTP Proxy Service
Two HTTP services exist by default and are enabled, one with explicit and transparent
attributes on port 80 and one with explicit attributes on port 8080. You can change the
attributes or create other HTTP ports if needed. For example, if you configure SSL proxy
functionality, you must create a separate HTTP service to allow the browser to issue HTTP
CONNECT requests to the SG appliance for HTTPS content. The SG appliance detects the
presence of the SSL protocol and enables SSL Proxy functionality for such connections.
For more information on SSL proxy functionality, see “Managing the SSL Proxy” on page
137.
To create or edit an HTTP proxy service:
1.

From the Management Console, select Configuration > Services > Proxy Services.

2.

To edit an existing HTTP proxy service, highlight the service and click Edit. To create a
new proxy service, click New.
Note: If you only want to change the proxy’s behavior from bypass (the default) to
intercept, go to the Action column of the Proxy Services pane, select the service whose
behavior you want to change, and select Intercept from the drop-down list. You do
not need to enter New/Edit mode to change this attribute.

79

Chapter 8: Managing the HTTP Proxy

Section A: Creating an HTTP Proxy Service
a.

Select the Authenticate 401 checkbox if you want all transparent and explicit
requests received on the port to 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.

b.

Select the Detect Protocol checkbox to automatically detect the protocol being
used. Note that this breaks connections that do not have the client send
information first, but expect the server to respond on connection. It also can
add significant delay if the client does not send specific information, and only
after timing out does it treat the traffic as unknown.

c.

Reflect Client IP: Enables or disables sending of client's IP address instead of

the SG appliance's IP address.
d. Early intercept: This option cannot be changed when creating or editing an
HTTP proxy service.
e.

Enable ADN: Controls whether ADN is enabled for a specific service. Enabling

ADN does not guarantee the connections are accelerated by ADN. The actual
enable decision is determined by ADN routing (for explicit deployment) and
network setup (for transparent deployment)
f.

The Optimize Bandwidth checkbox is selected by default if you enabled ADN
optimization during initial configuration. You should de-select the checkbox
if you are not configuring ADN optimization.

6.

To create a new listener, click New; if you edit an existing listener, click Edit.

7.

Select a Destination IP address from the drop-down menu.

8.

In the Port Range field, enter the ports on which the service should listen. The default
ports for HTTP are 80 and 8080.

9.

Select the default behavior for the service: Bypass tells the service to ignore any traffic.
Intercept configures the service to intercept the traffic that is being proxied.

10. Click OK.
Relevant CLI Syntax to Create/Edit an HTTP Proxy Service:


To enter configuration mode for the service:
SGOS#(config) proxy-services
SGOS#(config proxy-services) create http service-name
SGOS#(config proxy-services) edit service-name



The following subcommands are available:
SGOS#(config service-name) add {transparent | explicit | all |
ip_address | ip_address/subnet-mask} {port | first_port-last_port}
[intercept | bypass]
SGOS#(config service-name) attribute {authenticate-401 {enable |
disable} | adn-optimize {enable | disable} | detect-protocol {enable |
disable} | reflect-client-ip {enable | disable} | use-adn {enable |
disable}
SGOS#(config service-name) bypass {transparent | explicit | all |
ip_address | ip_address/subnet-mask} {port | first_port-last_port}
SGOS#(config service-name) exit
SGOS#(config service-name) intercept {transparent | explicit | all |
ip_address | ip_address/subnet-mask} {port | first_port-last_port}
SGOS#(config service-name) remove {transparent | explicit | all |
ip_address | ip_address/subnet-mask} {port | first_port-last_port}

81

Volume 3: Proxies and Proxy Services
Section A: Creating an HTTP Proxy Service
SGOS#(config service-name) view

82

Chapter 8: Managing the HTTP Proxy

Section B: Overview: Configuring HTTP Proxy Performance

Section B: Overview: Configuring HTTP Proxy Performance
You can configure HTTP proxy performance through setting:


Default HTTP Proxy Policy



HTTP Proxy Acceleration Profiles



Byte Range



Refresh Bandwidth



Compression

Each of these topics is discussed below.

Understanding Default HTTP Proxy Policy
You can configure global defaults that determine HTTP proxy caching policy, such as the
maximum size of cacheable objects, the length of time that negative responses remain in
the cache, whether SGOS revalidates each object before serving it, whether the server
certificate is verified by default, and how headers are parsed.
For information about setting default policy for HTTP proxy caching, see “Understanding
Tolerant HTTP Request Parsing” on page 96.

HTTP Proxy Acceleration Profiles
You have a choice of three profiles to use for the SG appliance:


Normal (the default setting) acts as a client accelerator, and is used for enterprise
deployments



Portal acts as a server accelerator, and is used for Web hosting



Bandwidth Gain is used for ISP deployments

For information on HTTP profiles, see “Customizing the HTTP Proxy Profile” on page 88.

Byte-Range Support
If a client makes a request using the Range: HTTP header, SGOS serves the requested
portions of the file from the cache if byte-range support is enabled (the default). If byte
range support is disabled, all such requests are forwarded to the origin content server and
the response is not cached. For information on using byte-range support to determine
how SGOS handles byte-range requests, see “Configuring HTTP for Bandwidth Gain” on
page 93.

83

Volume 3: Proxies and Proxy Services
Section B: Overview: Configuring HTTP Proxy Performance

Refresh Bandwidth
Refresh bandwidth refers to server-side bandwidth used for all forms of asynchronous
refresh activity. The default configuration is to allow the SG appliance to manage refresh
bandwidth. The SG appliance manages the bandwidth in order to preserve the maximum
freshness of accessed objects. However, sometimes the automatic refresh bandwidth
amount is too high. It is not unusual for refresh bandwidth to spike up occasionally,
depending on access patterns at the time. If necessary, you can impose a limit on refresh
bandwidth. To limit the refresh bandwidth to a specified amount, you must disable
automatic management of the bandwidth and explicitly set a bandwidth limit. Setting the
refresh bandwidth amount too low can lower the estimated freshness of objects in the
cache. If you set the refresh bandwidth amount to zero, the SG appliance does not do
active refresh at all.
For information about configuring refresh bandwidth, see “Configuring Refresh
Bandwidth for the HTTP Proxy” on page 95.

Compression
Compression is disabled by default. If compression is enabled, the HTTP proxy forwards
the supported compression algorithm (either deflate or gzip) from the client’s request
(Accept-Encoding: request header) to the server as is, and attempts to send compressed
content to client whenever possible. This allows SGOS to send the response as is when the
server sends compressed data, including non-cacheable responses. Any unsolicited
encoded response is forwarded as is to the client.
For more information on compression, see “Understanding HTTP Compression” on page
97.
Related CLI Syntax to Configure HTTP:
SGOS#(config) http


The following subcommands are available:
SGOS#(config) http [no] add-header client-ip
SGOS#(config) http [no] add-header front-end-https
SGOS#(config) http [no] add-header via
SGOS#(config) http [no] add-header x-forwarded-for
SGOS#(config) http [no] byte-ranges
SGOS#(config) http [no] cache authenticated-data
SGOS#(config) http [no] cache expired
SGOS#(config) http [no] cache personal-pages
SGOS#(config) http [no] force-ntlm
SGOS#(config) http ftp-proxy-url root-dir
SGOS#(config) http ftp-proxy-url user-dir
SGOS#(config) http [no] parse meta-tag {cache-control | expires |
pragma-no-cache}
SGOS#(config) http [no] persistent client
SGOS#(config) http [no] persistent server
SGOS#(config) http [no] persistent-timeout client num_seconds
SGOS#(config) http [no] persistent-timeout server num_seconds
SGOS#(config) http [no] pipeline client {requests | redirects}
SGOS#(config) http [no] pipeline prefetch {requests | redirects}
SGOS#(config) http [no] proprietary-headers bluecoat

84

Chapter 8: Managing the HTTP Proxy

Section B: Overview: Configuring HTTP Proxy Performance
SGOS#(config) http receive-timeout client num_seconds
SGOS#(config) http receive-timeout refresh num_seconds
SGOS#(config) http receive-timeout server num_seconds
SGOS#(config) http [no] revalidate-pragma-no-cache
SGOS#(config) http [no] strict-expiration refresh
SGOS#(config) http [no] strict-expiration serve
SGOS#(config) http [no] strip-from-header
SGOS#(config) http [no] substitute conditional
SGOS#(config) http [no] substitute ie-reload
SGOS#(config)
SGOS#(config)
SGOS#(config)
SGOS#(config)
SGOS#(config)
SGOS#(config)
SGOS#(config)
SGOS#(config)

http
http
http
http
http
http
http
http

[no] substitute if-modified-since
[no] substitute pragma-no-cache
[no] tolerant-request-parsing
upload-with-pasv disable
upload-with-pasv enable
version {1.0 | 1.1}
[no] www-redirect
[no] xp-rewrite-redirect

85

Chapter 8: Managing the HTTP Proxy

Section C: Configuring the HTTP Proxy
3.

In the Cache negative responses for field, enter the number of minutes SGOS stores
negative responses. The default is 0, meaning that the SG appliance does not cache
negative responses and always attempts to retrieve the object.
The OCS might send a client error code (4xx HTTP response) or a server error code
(5xx HTTP response) as a response to some requests. If the SG appliance is configured
to cache such negative responses, it returns that response in subsequent requests for
that page or image for the specified number of minutes. If it is not configured, which
is the default, the SG appliance attempts to retrieve the page or image every time it is
requested.
If you enter a number of minutes into this field, then the response times improve, but
you could receive negative responses to requests that might otherwise have been
served for that period of time.

4.

To always verify that each object is fresh upon access, select the Always check with
source before serving object checkbox. Enabling this setting has a significant impact
on performance because HTTP proxy revalidates requested cached objects with the
OCS before serving them to the client, resulting in a negative impact on response
times and bandwidth gain. Therefore, do not enable this configuration unless
absolutely required.

5.

If you communicate with an origin content server (OCS) through HTTPS and want
the OCS certificate to be verified, be sure that Verify server certificate for secure
connections is selected.

6.

The default is to parse HTTP meta tag headers in HTML documents if the MIME type
of the object is text/HTML. The function of all meta tags is same as the corresponding
HTTP headers.
To disable meta-tag parsing, deselect the checkbox for:


Parse “cache-control” meta tag

The following sub-headers are parsed when this checkbox is selected: private,
no-store, no-cache, max-age, s-maxage, must-revalidate, proxyrevalidate.

7.



Parse “expires” meta tag



Parse “pragma-no-cache” meta tag

Click OK; click Apply.

Tips on Parsing Meta Tags


If ICAP response modification is occurring, the response body modified by the ICAP
server is not parsed.



Relevant HTTP meta tags must appear within the first 256 bytes of HTTP object body.
If the meta tag does not appear within the first 256 bytes, it is ignored.

Tips on Using Meta Tags With Policy


The following CPL properties can be used in the layer to control meta tag
processing for HTTP proxy, HTTP refresh, and HTTP pipeline transactions:
http.response.parse_meta_tag.Pragma.no-cache(yes|no)
http.response.parse_meta_tag.Cache-Control(yes|no)
http.response.parse_meta_tag.Expires(yes|no)



VPM support for this feature is not available.

87

Volume 3: Proxies and Proxy Services
Section C: Configuring the HTTP Proxy
Related CLI Syntax to Set HTTP Proxy Default Policy


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



The following subcommands are available:
SGOS#(config caching) always-verify-source
SGOS#(config caching) max-cache-size megabytes
SGOS#(config caching) refresh automatic
SGOS#(config caching) refresh bandwidth kbps
SGOS#(config) http parse meta-tag {cache-control | expires | pragmano-cache}

Customizing the HTTP Proxy Profile
You can select from among three profiles for the HTTP proxy, depending on your needs,
and you can also create a customized profile from the three available.
The three profiles are:


Normal, which acts as a client-accelerator and is used for enterprise deployments



Portal, which acts as a server accelerator and is used for Web-hosting



Bandwidth, which is used for ISP deployments

The table below shows the configuration for each profile.
Table 8-1. Normal, Portal, and Bandwidth Gain Profiles
Configuration

Normal
Profile

Portal
Profile

Bandwidth
Gain

Pipeline embedded objects in client requests

Enabled

Disabled

Disabled

Pipeline embedded objects in prefetch requests

Enabled

Disabled

Disabled

Pipeline redirects for client requests

Enabled

Disabled

Disabled

Pipeline redirects for prefetch requests

Enabled

Disabled

Disabled

Cache expired objects

Enabled

Disabled

Enabled

Bandwidth Gain Mode

Disabled

Disabled

Enabled

Substitute GET for IMS (if modified since)

Disabled

Enabled

Enabled

Substitute GET for PNC (Pragma no cache)

Disabled

Enabled

Does not change

Substitute GET for HTTP 1.1 conditionals

Disabled

Enabled

Enabled

Substitute GET for IE (Internet Explorer) reload

Disabled

Enabled

Does not change

Never refresh before expiration

Disabled

Enabled

Enabled

Never serve after expiration

Disabled

Enabled

Does not change

88

Chapter 8: Managing the HTTP Proxy

Section C: Configuring the HTTP Proxy
When an SG appliance is first manufactured, it is set to a Normal profile. Depending on
your needs, you can use the Bandwidth Gain profile or the Portal profile. You can also
combine needed elements of all three profiles.

Using the Normal Profile
Normal is the default profile and can be used wherever the SG appliance is used as a
normal forward proxy. This profile is typically used in enterprise environments, where the
freshness of objects is more important than controlling the use of server-side bandwidth.
The Normal profile is the profile that most follows the HTTP standards concerning object
revalidation and staleness. Additionally, prefetching (pipelining) of embedded objects
and redirects is enabled, which reduces response time for clients.

Using the Portal Profile
When configured as a server accelerator, the SG appliance improves object response time
to client requests, scalability of the origin content server (OCS) site, and overall Web
performance at the OCS. A server accelerator services requests meant for an OCS as if it is
the OCS itself.
Because an OCS can actually consist of many servers—a single Web server or an entire
server farm—OCSs are identified by domain name or IP address. To the SG appliance, the
domain name or IP address is treated as the OCS, regardless of how many back-end Web
servers might be installed.

Using the Bandwidth Gain Profile
The Bandwidth-Gain profile is useful wherever server-side bandwidth is an important
resource. This profile is typically used in Internet Service Provider (ISP) deployments. In
such deployments, the freshness of the object is not as important as controlling the use of
server-side bandwidth. The Bandwidth-Gain profile enables various HTTP configurations
that can increase page response times and the likelihood that stale objects are served, but
that reduces the amount of server-side bandwidth required.

Understanding HTTP Proxy Profile Configuration Components
Table 8-2 gives a definition of the customizable HTTP proxy profile settings. Both the
Management Console field and CLI (config) command text is included.
Table 8-2. Description of Profile Configuration Components
Management Console
Checkbox Field

CLI (config)
Command

Definition

Pipeline embedded objects in
client request

http [no] pipeline
client requests

This configuration item applies only to HTML
responses. When this setting is enabled, and the object
associated with an embedded object reference in the
HTML is not already cached, HTTP proxy acquires
the object’s content before the client requests the
object. This improves response time dramatically. If
this setting is disabled, HTTP proxy does not acquire
embedded objects until the client requests them.

89

Volume 3: Proxies and Proxy Services
Section C: Configuring the HTTP Proxy
Table 8-2. Description of Profile Configuration Components (Continued)
Management Console
Checkbox Field

CLI (config)
Command

Definition

Pipeline redirects for client
request

http [no] pipeline
client redirects

When this setting is enabled, and the response of a
client request is one of the redirection responses (such
as 301, 302, or 307 HTTP response code), then HTTP
proxy pipelines the object specified by the Location
header of that response, provided that the redirection
location is an HTML object. This feature improves
response time for redirected URLs. If this setting is
disabled, HTTP proxy does not pipeline redirect
responses resulting from client requests.

Pipeline embedded objects in
prefetch request

http [no] pipeline
prefetch requests

This configuration item applies only to HTML
responses resulting from pipelined objects. When this
setting is enabled, and a pipelined object’s content is
also an HTML object, and that HTML object has
embedded objects, then HTTP proxy also pipelines
those embedded objects. This nested pipelining
behavior can occur three levels deep at most. If this
setting is disabled, HTTP proxy does not engage in
nested pipelining behavior.

Pipeline redirects for prefetch
request

http [no] pipeline
prefetch
redirects

When this setting is enabled, HTTP proxy pipelines
the object specified by a redirect location returned by
a pipelined response. If this setting is disabled, HTTP
proxy does not try to pipeline redirect locations
resulting from a pipelined response.

Substitute Get for IMS

http [no]
substitute ifmodified-since

If the time specified by the If-Modified-Since:
header in the client’s conditional request is greater
than the last modified time of the object in the cache, it
is a strong indication that the copy in the cache is
stale. If so, HTTP proxy does a conditional GET to the
OCS, based on the last modified time of the cached
object.
To control this aspect of the SGOS treatment of the
If-Modified-Since: header, disable the
Substitute Get for IMS setting. When this setting is
disabled, a client time condition greater than the last
modified time of the object in the cache does not
trigger revalidation of the object.
However, not all objects necessarily have a lastmodified time specified by the OCS.

90

Chapter 8: Managing the HTTP Proxy

Section C: Configuring the HTTP Proxy
Table 8-2. Description of Profile Configuration Components (Continued)
Management Console
Checkbox Field

CLI (config)
Command

Definition

Substitute Get for HTTP 1.1
conditionals

http [no]
substitute
conditional

HTTP 1.1 provides additional controls to the client
over the behavior of caches concerning the staleness
of the object. Depending on various CacheControl: headers, the SG appliance can be forced to
consult the OCS before serving the object from the
cache. For more information about the behavior of
various Cache-Control: header values, refer to
RFC 2616.
If the Substitute Get for HTTP 1.1 Conditionals setting
is enabled, HTTP proxy ignores the following CacheControl: conditions from the client request:
• "max-stale" [ "=" delta-seconds ]
• "max-age" "=" delta-seconds
• "min-fresh" "=" delta-seconds
• "must-revalidate"
• "proxy-revalidate"

Substitute Get for PNC

http [no]
substitute pragmano-cache

Typically, if a client sends an HTTP GET request with
a Pragma: no-cache or Cache-Control: nocache header (for convenience, both are hereby
referred to as PNC), a cache must consult the OCS
before serving the content. This means that HTTP
proxy always re-fetches the entire object from the
OCS, even if the cached copy of the object is fresh.
Because of this, PNC requests can degrade proxy
performance and increase server-side bandwidth
utilization. However, if the Substitute Get for PNC
setting is enabled, then the PNC header from the
client request is ignored (HTTP proxy treats the
request as if the PNC header is not present at all).

Substitute Get for IE reload

http [no]
substitute iereload

Some versions of Internet Explorer issue the
Accept: */* header instead of the Pragma: nocache header when you click Refresh. When an
Accept header has only the */* value, HTTP proxy
treats it as a PNC header if it is a type-N object. You
can control this behavior of HTTP proxy with the
Substitute GET for IE Reload setting. When this
setting is enabled, the HTTP proxy ignores the PNC
interpretation of the Accept: */* header.

Never refresh before
expiration

http [no] strictexpiration refresh

Applies only to cached type-T objects. When this
setting is enabled, SGOS does not asynchronously
revalidate such objects before their specified
expiration time. When this setting is disabled, such
objects, if they have sufficient relative popularity, can
be asynchronously revalidated and can, after a
sufficient number of observations of changes, have
their estimates of expiration time adjusted
accordingly.

91

Volume 3: Proxies and Proxy Services
Section C: Configuring the HTTP Proxy
Table 8-2. Description of Profile Configuration Components (Continued)
Management Console
Checkbox Field

CLI (config)
Command

Definition

Never serve after expiration

http [no] strictexpiration serve

Applies only to cached type-T objects. If this setting is
enabled, an object is synchronously revalidated before
being served to a client, if the client accesses the object
after its expiration time. If this setting is disabled, the
object is served to the client and, depending on its
relative popularity, may be asynchronously
revalidated before it is accessed again.

Cache expired objects

http [no] cache
expired

Applies only to type-T objects. When this setting is
enabled, type-T objects that are already expired at the
time of acquisition is cached (if all other conditions
make the object cacheable). When this setting is
disabled, already expired type-T objects become noncacheable at the time of acquisition.

Enable Bandwidth Gain Mode

bandwidth-gain
{disable | enable}

This setting controls both HTTP-object acquisition
after client-side abandonment and AAR
(asynchronous adaptive refresh) revalidation
frequency.
• HTTP-Object Acquisition
When Bandwidth Gain mode is enabled, if a client
requesting a given object abandons its request, then
HTTP proxy immediately abandons the acquisition
of the object from the OCS, if such an acquisition is
still in progress. When bandwidth gain mode is
disabled, the HTTP proxy continues to acquire the
object from the OCS for possible future requests for
that object.
• AAR Revalidation Frequency
Under enabled bandwidth gain mode, objects that
are asynchronously refreshable are revalidated at
most twice during their estimated time of
freshness. With bandwidth gain mode disabled,
they are revalidated at most three times. Not all
asynchronously refreshable objects are guaranteed
to be revalidated.

Configuring the HTTP Proxy Profile
You can configure the profile using any of the components discussed above.
To configure the HTTP proxy profile:
1.

From the Management Console, select Configuration > Proxy Settings > HTTP Proxy >
Acceleration Profile.

The Acceleration Profile tab displays (Normal is the default profile). Text appears at
the bottom of this tab indicating which profile is selected. If you have a customized
profile, this text does not appear.

92

Volume 3: Proxies and Proxy Services
Section C: Configuring the HTTP Proxy

Understanding Byte-Range Support
If a client requests a byte range using the Range: HTTP header, the SG appliance serves
the requested portions of the file from the cache if byte-range support is enabled (the
default). If byte range support is disabled, all such requests are forwarded in a noncacheable way to the origin content server (OCS).
Byte-range configuration can significantly affect bandwidth gain where heavy use of
range requests is expected. Download managers (such as NetAnts®) typically use byterange requests heavily.
With byte-range support enabled, if the object is already cached and does not need to be
reloaded from the OCS, the SG appliance serves the byte-range request from the cache
only. But if the object is not in the cache, or if a reload of the object is required, SGOS might
treat the byte-range request as if byte-range support is disabled and serve the object from
the cache. It is important to note that HTTP proxy never caches partial objects, even if
byte-range support is enabled.
If byte-range support is disabled, HTTP treats all byte-range requests as non-cacheable.
Such requests are never served from the cache, even if the object exists in the cache. The
client’s request is sent unaltered to the OCS and the response is not cached. Thus a byterange request has no effect on the cache if byte-range support is disabled.
HTTP proxy categorizes the range requests in following three categories when byte-range
support is enabled:


Type-1: 0-N: Range request for first N bytes of the object



Type-2: N-M: Range request from N bytes to M bytes of the object



Type-3: -N: Range request for last N bytes of the object

If the object does not exist in the cache, and a byte-range request is received with the first
range being type-1 or type-2, and the start byte of the first requested range is within 14336
bytes (hard coded threshold), then the entire object is retrieved from the OCS and cached
in the SG appliance. Even though HTTP proxy retrieves the entire object from the OCS, it
sends an appropriate byte-range response to the client. If the object does not exist in the
cache, and if the first range in the request is not of type-1 or type-2, or if the start byte of
the first requested range is beyond 14336 bytes, then the client’s request is sent unaltered
to the OCS and the response is not cached.
If the object exists in the cache, and if a range request with an effective PNC (the PNC
header is not substituted or revalidated—see "Understanding Revalidate Pragma-NoCache" below) is made, and the first range in the request is either type-3 or type-1 or 2
with a start byte offset greater than 14336 bytes, then, even if the object exists in the cache,
the transaction is made non-cacheable (the request is sent to the OCS without any
modification and the response is not cached). If an object exists in the cache and a byterange request is made without the PNC header, then the byte-range response is satisfied
from the cache.
Most download managers make byte-range requests with a PNC header. To serve such
requests from the cache, the revalidate pragma-no-cache option should be configured
along with byte-range support (see “Understanding Revalidate Pragma-No-Cache”
below).
To configure byte-range support:
Note: Enabling or disabling byte-range support can only be configured through the CLI.

94

Chapter 8: Managing the HTTP Proxy

Section C: Configuring the HTTP Proxy
To enable or disable byte-range support, enter one of the following commands at the
(config) command prompt:
SGOS#(config) http byte-ranges
-orSGOS#(config) http no byte-ranges

Understanding Revalidate Pragma-No-Cache
The pragma-no-cache (PNC) header in a client’s request can affect the efficiency of the
proxy from a bandwidth gain perspective (this behavior is described in Table 8-2 in the
Substitute Get for PNC configuration description). If you do not want to completely ignore
PNC in client requests (which you can do by using the Substitute Get for PNC
configuration), you can lower the impact of the PNC by enabling the revalidatepragma-no-cache setting. When the revalidate-pragma-no-cache setting is enabled, a
client’s non-conditional PNC-GET request results in a conditional GET request sent to the
OCS if the object is already in the cache. This gives the OCS a chance to return the 304 Not
Modified response, thus consuming less server-side bandwidth, because it has not been
forced to return full content even though the contents have not actually changed. By
default, the revalidate PNC configuration is disabled and is not affected by changes in the
top-level profile. When the Substitute Get for PNC configuration is enabled (see
“Configuring the HTTP Proxy Profile” on page 92 for configuration information), the
revalidate PNC configuration has no effect.
To configure the revalidate PNC setting:
Note: The revalidate pragma-no-cache setting can only be configured through the CLI.

To enable or disable the revalidate PNC setting, enter one of the following commands at
the (config) command prompt:
SGOS#(config) http revalidate-pragma-no-cache
-orSGOS#(config) http no revalidate-pragma-no-cache

Configuring Refresh Bandwidth for the HTTP Proxy
The SG appliance uses as much bandwidth as necessary for refreshing to achieve the
desired access freshness.
The amount of bandwidth used varies depending on client demands. If you determine
that the SG appliance is using too much bandwidth (by reviewing the logged statistics
and examining current bandwidth used shown in the Refresh bandwidth field), you can
specify a limit to the amount of bandwidth the SG appliance uses to try to achieve the
desired freshness. Be aware, however, that if you limit the amount of bandwidth the SG
appliance can use, you might prohibit the appliance from achieving the desired freshness.
If the refresh bandwidth configuration remains at the recommended default—Let the
ProxySG Appliance manage refresh bandwidth (recommended) in the Management Console
or SGOS#(config caching) refresh automatic in the CLI—then the appliance uses
whatever bandwidth is available in its efforts to maintain 99.9% estimated freshness of the
next access.

95

Chapter 8: Managing the HTTP Proxy

Section C: Configuring the HTTP Proxy
enabled, a request header name is allowed to contain or space characters, and if the
request header line does not contain a colon, then the entire line is taken as the header
name.
A header containing one or more or space characters, and nothing else, is
considered ambiguous. Blue Coat does not know if this is a blank continuation line or if it
is the blank line that signals the end of the header section. By default, an ambiguous blank
line is illegal, and an error is reported. With tolerant request parsing enabled, an
ambiguous blank line is treated as the blank line that ends the header section.
To enable the HTTP tolerant request parsing flag:
Note: This feature is only available through the CLI.

From the (config) prompt, enter the following command to enable tolerant HTTP
request parsing (the default is disabled):
SGOS#(config) http tolerant-request-parsing

To disable HTTP tolerant request parsing:
SGOS#(config) http no tolerant-request-parsing

Understanding HTTP Object Types
HTTP proxy categorizes HTTP objects into three types:


Type-T: The OCS specifies explicit expiration time.



Type-M: Expiration time is not specified; however, the last modified time is specified
by the OCS.



Type-N: Neither expiration nor last modified time has been specified.

The SGOS asynchronous adaptive refresh (AAR) algorithm is normally applied to all
three types of HTTP objects. To maximize the freshness of the next access to objects in the
cache, asynchronous revalidations are performed on those objects in accordance with their
relative popularity and the amount of time remaining before their estimated time of
expiration. Estimated expiration times vary as object content changes are observed during
such asynchronous revalidations. This happens even for type-T objects because the
expiration times of type-T objects are not always perfectly managed by Webmasters of
content servers. However, for situations where such management can be trusted, certain
configuration items exist to reduce speculative revalidation of type-T objects. In the
following section, the terms revalidation and refresh mean the same thing—to assess the
freshness of an object by sending a conditional GET request to the object’s OCS.

Understanding HTTP Compression
Compression reduces a file size but does not lose any data. Whether you should use
compression depends upon three resources: server-side bandwidth, client-side
bandwidth, and SG CPU. If server-side bandwidth is more expensive in your
environment than CPU, always request compressed content from the origin content server
(OCS). However, if CPU is comparatively expensive, the SG appliance should instead be
configured to ask the OCS for the same compressions that the client asked for and to
forward whatever the server returns.

97

Volume 3: Proxies and Proxy Services
Section C: Configuring the HTTP Proxy
The default configuration assumes that CPU is costlier than bandwidth. If this is not the
case, you can change the SG appliance behavior.
Note: Decompression, content transformation, and recompression increases response
time by a small amount because of the CPU overhead. (The overhead is negligible in most
cases.) RAM usage also increases if compression is enabled.

Compression might also appear to adversely affect bandwidth gain. Because compression
results in a smaller file being served to the client than was retrieved by the SG appliance
from the origin content server, bandwidth gain statistics reflect such requests/responses
as negative bandwidth gain.
Compression is disabled by default. If compression is enabled, the HTTP proxy forwards
the supported compression algorithm (gzip and deflate) from the client’s request
(Accept-Encoding: request header) to the server as is, and attempts to send compressed
content to client whenever possible. This allows the SG appliance to send the response as
is when the server sends compressed data, including non-cacheable responses. Any
unsolicited encoded response is forwarded to the client as is.
Note: If compression is not enabled, the SG appliance does not compress the content if
the server sends uncompressed content. However, the appliance continues to uncompress
content if necessary to apply transformations.

Any unsolicited encoded response is forwarded to the client as is.
Compression is controlled by policy only.
You can view compression statistics by going to Statistics > Protocol Details > HTTP/FTP
History > Client Comp. Gain and Server Comp. Gain.
For information on these statistics, see “Viewing HTTP/FTP Statistics” on page 105.

Understand Compression Behavior
The SG compression behavior is detailed in the tables below. Compression increases the
overall percentage of cacheable content, increasing the hit rate in terms of number of
objects served from the cache.
Note: A variant is the available form of the object in the cache—compressed or
uncompressed. The Content-Encoding: header Identity refers to the uncompressed form
of the content.

For cache-hit compression behavior, see Table 8-3 below. For cache-miss compression
behavior, see Table 8-4.

98

Chapter 8: Managing the HTTP Proxy

Section C: Configuring the HTTP Proxy
.

Table 8-3. Cache-Hit Compression Behavior
Accept-Encoding:
in client request

Variant Available when the
Request Arrived

Variant Stored as a
Result of the Request

Content-Encoding: in
SG response

Identity

Uncompressed object

None

Identity

Identity

No uncompressed object

Uncompressed

Identity

gzip compressed
gzip, deflate

Uncompressed object

gzip compressed

gzip

gzip, deflate

Uncompressed object

None

gzip

None

deflate

deflate compressed

deflate

gzip compressed
gzip, deflate

Uncompressed object
deflate compressed

deflate

No uncompressed object
gzip compressed

(This is effectively a cachemiss. The SG appliance
does not convert from gzip
to deflate.)

Table 8-4. Cache-Miss Compression Behavior
AcceptEncoding: in
client request

AcceptEncoding: in SG
request

Content-Encoding:
in server response

Generated
variants

ContentEncoding:
in SG response

Identity

Identity

Identity

uncompressed object

Identity

gzip, deflate

gzip, deflate

Identity

uncompressed object

gzip

gzip-compressed
gzip, deflate

gzip, deflate

gzip

No uncompressed
object

gzip

gzip-compressed
gzip, deflate,
compress

gzip, deflate

gzip

No uncompressed
object

gzip

gzip-compressed
gzip, deflate

gzip, deflate

compress (illegal
response)

compress

compress

Compression Exceptions


The SG appliance issues a transformation_error exception (HTTP response code
403), when the server sends an unknown encoding and the appliance is configured to
do content transformation.



The SG appliance issues an unsupported_encoding exception (HTTP response code
415 - Unsupported Media Type) when the appliance is unable to deliver content due
to configured policy.

99

Chapter 8: Managing the HTTP Proxy

Section C: Configuring the HTTP Proxy
c.

Select the compression options you want to use; click OK.

d. Click OK again; close the VPM window and click Yes in the dialog to save
your changes.
To add or edit server compression:
1.

Create a Web Access Layer:
a.

From the Management Console, select Configuration > Policy > Visual Policy
Manager; click Launch.

2.

b.

Select Policy > Add Web Access Layer from the menu of the Blue Coat VPM
window that appears.

c.

Type a layer name into the dialog that appears and click OK.

Add an Action object:
a.

Right click on the item in the Action column; select Set.

b.

Click New in the Set Action Object dialog that appears; select Set Server HTTP
Compression.

c.

Select compression options; click OK.

d. Click OK again; close the VPM window and click Yes in the dialog to save
your changes.

Using VPM to Set HTTP Compression Levels
You can control the compression level based on any transaction condition (such as the
client IP address, the hostname, request/response headers, and the like).
To set compression levels:
1.

Create a Web Access Layer:


From the Management Console, select Configuration > Policy > Visual Policy
Manager; click Launch.

2.



Select Policy > Add Web Access Layer from the menu of the Blue Coat VPM
window that appears.



Type a layer name into the dialog that appears and click OK.

Add an Action object:


Right click on the item in the Action column; select Set.



Click New in the Set Action Object dialog that appears; select Set HTTP
Compression Level.



Select the compression level needed; click OK.



Click OK again; close the VPM window and click Yes in the dialog to save your
changes.

Using Policy to Configure Compression Behavior
Compression and decompression are allowed if compression is enabled. If compression is
not enabled, neither compression nor decompression are allowed.

101

Volume 3: Proxies and Proxy Services
Section C: Configuring the HTTP Proxy
Policy controls the compression or decompression of content on the SG appliance. If
compression is turned off, uncompressed content is served to the client if a compressed
variant is not available. If decompression is disabled, an uncompressed version is fetched
from the OCS if the variant does not exist and the client requested uncompressed content.
Note: The SG appliance decompresses the content if transformation is to be applied, even
if the compression is not enabled.

You can use server-side or client-side controls to manage compression through policy, as
described in the following table.
Table 8-5. Compression Properties
Compression Properties

Description

http.allow_compression(yes | no)

Allow the SG appliance to compress content on
demand if needed.

http.allow_decompression(yes | no)

Allow the SG appliance to decompress content
on demand if needed.

http.compression_level(low | medium |
high)

Set the compression level to be low (1), medium
(6), or high (9). Low is the default.

http.server.accept_encoding(client)

Turn on only client encodings

http.server.accept_encoding(identity)

Turn off all encodings

http.server.accept_encoding(all)

Turn on all supported encodings, including the
client’s encodings.

http.server.accept_encoding(gzip,
deflate)

Send specific encodings (order sensitive)

http.server.accept_encoding(gzip,
client)

Send specific encodings (order sensitive)

http.server.accept_encoding.gzip(yes |
no)

Add/remove an encoding

http.server.accept_encoding[gzip,
deflate, identity](yes | no)

Add/remove a list of encodings

http.server.accept_encoding.allow
_unknown (yes | no)

Allow/disallow unknown encodings.

http.client.allow_encoding(identity);

Allow no encodings (send uncompressed).

http.client.allow_encoding(client);

Allow all client encodings. This is the default.

http.client.allow_encoding(gzip,
deflate);

Allow fixed set of encodings.

http.client.allow_encoding(gzip,
client);

Allow fixed set of encodings.

http.client.allow_encoding.gzip(yes |
no);

Add/remove one encoding

102

Chapter 8: Managing the HTTP Proxy

Section C: Configuring the HTTP Proxy
Table 8-5. Compression Properties (Continued)
Compression Properties

Description

http.client.allow_encoding[gzip,
deflate, identity](yes | no);

Add/remove list of encodings

Default Behavior
By default, Blue Coat sends the client’s list of the accept encoding algorithms, except for
unknown encodings. If compression is not enabled, the default overrides any configured
CPL policy.
If Accept-Encoding request header modification is used, it is overridden by the
compression related policy settings shown in Table 8-5. The Accept-Encoding header
modification can continue to be used if no compression policies are applied, or if
compression is not enabled. Otherwise, the compression-related policies override any
Accept-Encoding header modification, even if the Accept-Encoding header
modification appears later in the policy file.
Adding encoding settings with client-side controls depend on if the client originally listed
that encoding in its Accept-Encoding header. If so, these encodings are added to the list
of candidates to be delivered to the client. The first cache object with an Accept-Encoding
match to the client-side list is the one that is delivered.
Suggested Settings for Compression


If client-side bandwidth is expensive in your environment, use the following policy:

http.client.allow_encoding(client)
http.allow_compression(yes)



If server-side bandwidth is expensive in your environment, compared to client-side
bandwidth and CPU:
http.server.accept_encoding(all)
http.server.accept_encoding.allow_unknown(no); default
http.allow_compression(yes)
http.allow_decompression(yes)



If CPU is expensive in your environment, compared to server-side and client-side
bandwidth:
http.server.accept_encoding(client);If no content transformation
policy is configured
http.server.accept_encoding(identity);If some content transformation
policy is configured
http.allow_compression(no); default
http.allow_decompression(no); default

Notes


Policy-based content transformations are not stored as variant objects. If content
transformation is configured, it is applied on all cache-hits, and objects might be
compressed all the time at the end of such transformation if they are so configured.

103

Volume 3: Proxies and Proxy Services
Section C: Configuring the HTTP Proxy


The variant that is available in the cache is served, even if the client requests a
compression choice with a higher qvalue. For example, if a client requests Acceptencoding: gzip;q=1, deflate;q=0.1, and only a deflate-compressed object is
available in the cache, the deflate compressed object is served.



The HTTP proxy ignores Cache-Control: no-transform directive of the OCS. To
change this, write policy to disallow compression or decompression if CacheControl: no-transform response header is present.



The SG appliance treats multiple content encoding (gzip, deflate or gzip, gzip) as an
unknown encoding. (These strings indicate the content has been compressed twice.)



The gzip and deflate formats are treated as completely separate and are not converted
from one to the other.



Blue Coat recommends using gzip encoding (or allowing both gzip and deflate)
when using the HTTP compression feature.



If the SG appliance receives unknown content encoding and if content transformation
is configured (such as popup blocking), an error results.



If the origin server provides compressed content with a different compression level
then that specified in policy, the content is not re-compressed.



If the SG appliance compressed and cached content at a different compression level
than the level specified in a later transaction, the content is not re-compressed.



Parsing of container HTML pages occurs on the server side, so pipelining
(prefetching) does not work when the server provides compressed content.



Compressing a zip file breaks some browser versions, and compressing images does
not provide added performance. For a current list of content types that are not
compressed, refer to the Release Notes.



All responses from the server can be compressed, but requests to the server, such as
POST requests, cannot.



Only 200 OK responses can be compressed.

104

Volume 3: Proxies and Proxy Services
Section E: Using Explicit HTTP Proxy with Internet Explorer
3.

Fill in the fields as follows:
a.

Name: Enter a meaningful name.

b.

Show: Select Custom from the drop-down list.

c.

Header Name: Enter Proxy-Support.

d. Make sure the Suppress radio button is selected.
4.

Click OK; click Apply.

To suppress the proxy-support header through CPL:
Use CPL to define the Proxy-Support custom header object and to specify what action to
take. The example below uses Proxy-Support as the action name, but you can choose any
name meaningful to you. The result of this action is to suppress the Proxy-Support header

action.Proxy-Support(yes)
define action Proxy-Support
delete(response.x_header.Proxy-Support)
end action Proxy-Support

Enabling or Disabling NTLM Authentication for Internet Explorer Clients
The following procedure forces Internet Explorer clients explicitly-proxied through an SG
appliance to participate in NTLM authentication. This CLI setting is global, affecting all
clients. You can also use VPM or CPL to provide granular control for NTLM
authentication. (See “To force NTLM authentication through VPM:” on page 110 and “To
force NTLM authentication through CPL:” on page 110.) These commands should only be
used if the proxy-support header is not suitable for the situation.
Note: These procedures can only be done through the CLI.

Do one of the following (note that the default is http no force-ntlm):


To force NTLM authentication for Internet Explorer clients, enter the following
command at the (config) command prompt:
SGOS#(config) http force-ntlm



To disable NTLM authentication for Internet Explorer clients, enter the following
command at the (config) command prompt:
SGOS#(config) http no force-ntlm

To force NTLM authentication through VPM:
To use VPM to force NTLM authentication, create a new Web Access Layer. Then:
1.

Right click in the Action field to see the drop-down list; select Set.

2.

Scroll to the Force NTLM for Server Auth static object; select it.

3.

Click OK.

To force NTLM authentication through CPL:
Global configuration of NTLM authentication behavior is set through the CLI command
http force-ntlm (the default is http no force-ntlm). The
http.force_ntlm_for_server_auth( ) CPL property overrides the global settings for a

particular subset.

110

Chapter 8: Managing the HTTP Proxy

Section E: Using Explicit HTTP Proxy with Internet Explorer
To create a rule to force NTLM authentication for explicitly proxied Internet Explorer
clients, first define the action, then define the rule.
This example implements the following policies:


All clients from the “ForceNTLM_subnet” have Force-NTLM turned on. These clients
do not use the proxy-support header.



Requests for all other hosts have Force-NTLM turned off. These hosts use the proxysupport header.
define subnet ForceNTLM_subnet
10.10.0.0/16
end

client.address=ForceNTLM_subnet http.force_ntlm_for_server_auth(yes)
http.force_ntlm_for_server_auth(no)
end

Using Web FTP
If HTTP is configured to be explicit, Internet Explorer version 6.0 users accessing FTP sites
over HTTP must disable the browser setting Enable folder view for FTP sites. To access this
attribute in Internet Explorer, select Tools > Internet Options, click the Advanced tab,
deselect Enable folder view for FTP sites, and click OK.
For information on using FTP, see “Managing the FTP Proxy” on page 69.

111

Volume 3: Proxies and Proxy Services

112

Chapter 9: Creating and Editing an HTTPS Reverse Proxy
Service

The Blue Coat HTTPS Reverse Proxy implementation:


Combines hardware-based SSL acceleration with full caching functionality.



Establishes and services incoming SSL sessions.



Provides SSL v2.0, SSL v3.0, and TLSv1 protocol support.

Creating an HTTPS reverse proxy is unlike other proxies in that a number of
preliminary steps are required before you can use the proxy.
Preliminary steps include:


Creating or importing a keyring. (Refer to Volume 5: Securing the Blue Coat SG
Appliance for information on creating or importing a keyring.)



(If necessary) Creating Certificate Signing Requests (CSRs) that can be sent to
Certificate Signing Authorities (CAs).



Importing server certificates issued by CA authorities for external use and
associate them with the keyring. (Refer to Volume 5: Securing the Blue Coat SG
Appliance.)
-or-



Creating certificates for internal use and associate them with the keyring.



(Optional, if using server certificates from CAs) Importing Certificate Revocation
Lists (CRLs) so the SG appliance can verify that certificates are still valid.

When these steps are complete, you can configure the HTTPS Reverse Proxy service.
A common scenario in using HTTPS Reverse Proxy, which connects the client to the SG
appliance, is in conjunction with HTTPS origination, which is used to connect the
appliance to the origin content server (OCS). For more information on this option, see
Section B: "Configuring HTTP or HTTPS Origination to the Origin Content Server" on
page 117.
This chapter discusses:


Section A: "Configuring the HTTPS Reverse Proxy"



Section B: "Configuring HTTP or HTTPS Origination to the Origin Content Server"
on page 117

113

Chapter 9: Creating and Editing an HTTPS Reverse Proxy Service

Section A: Configuring the HTTPS Reverse Proxy
3.

Make sure the proxy has a meaningful name

4.

Make sure that HTTPS Reverse Proxy is selected in the Proxy settings drop-down list.
a.

CA Cert List: Use the drop-down list to select any already created list that is

b.

Forward Client Cert: (Should be used with the Verify Client option.) Selecting
this checkbox puts the extracted client certificate information into a header that is
included in the request when it is forwarded to the OCS.

c.

In the Keyring drop-down list, select any already created keyring that is on the
system. The system ships with a default keyring that is reusable for each
HTPPS service.

on the system.

Note: The configuration-passwords-key keyring that shipped with the SG
appliance does not contain a certificate.

The appliance-key keyring does contain a certificate if you have Internet
connectivity, but it cannot be used for purposes other than appliance
authentication. For information about appliance authentication, see Chapter 2 of
Volume 6: Advanced Networking.
d. SSL Versions: Use the drop-down list to select the version to use for this
service. The default is SSL v2/v3 and TLS v1.
e.

Verify Client (Should be used with the Forward Client Certificate option.).

Selecting this checkbox puts the extracted client certificate information into
the Client-Cert header that is included in the request when it is forwarded to
the origin content server. The header contains the certificate serial number,
subject, validity dates, and issuer (all as name=value pairs). The actual
certificate itself is not forwarded.
5.

6.

Select or de-select the checkboxes to configure the TCP/IP settings for your
environment.
a.

Reflect-client-iP: Determines how the client IP address is presented to the
origin server for explicitly proxied requests

b.

Early intercept: This option cannot be changed when creating or editing an
HTTPS Reverse Proxy service.

Select or de-select checkboxes to configure ADN settings for your environment.
a.

Enable ADN: Controls whether ADN is enabled for a specific service. Enabling ADN
does not guarantee the connections are accelerated by ADN. The actual enable
decision is determined by ADN routing (for explicit deployment) and network setup
(for transparent deployment)

b.

The Optimize Bandwidth checkbox is selected by default if you enabled ADN
optimization during initial configuration. You should de-select the checkbox
if you are not configuring ADN optimization.

7.

Click New to add a new listener to the HTTPS Reverse Proxy; click Edit to change the
current settings.

8.

Select a Destination IP address from the drop-down list.

9.

Identify the port where you want this service to listen.

10. Select the default behavior for the service: Bypass tells the service to ignore any traffic.
Intercept configures the service to intercept the traffic that is being proxied.

115

Volume 3: Proxies and Proxy Services
Section A: Configuring the HTTPS Reverse Proxy
11. Click OK.
Relevant CLI Syntax to Create/Edit an HTTPS-Reverse-Proxy Service


To enter configuration mode for the service:
SGOS#(config) proxy-services
SGOS#(config proxy-services) create https-reverse-proxy service-name
SGOS#(config proxy-services) edit service-name



The following subcommands are available:
SGOS#(config service-name) add {transparent | explicit | all |
ip_address | ip_address/subnet-mask} {port | first_port-last_port}
[intercept | bypass]
SGOS#(config service-name) attribute {ccl list_name | cipher-suite
cipher-suite | forward-client-cert {enable | disable}| keyring
keyring_id | reflect-client-ip {enable | disable}| ssl-versions {sslv2
| sslv3 | tlsv1 | sslv2v3 | sslv2tlsv1 | sslv3tlsv1 | sslv2v3tlsv1} |
use-adn {enable | disable}| verify-client {enable | disable}}
SGOS#(config service-name) bypass {transparent | explicit | all |
ip_address | ip_address/subnet-mask} {port | first_port-last_port}
SGOS#(config service-name) exit
SGOS#(config service-name) intercept {transparent | explicit | all |
ip_address | ip_address/subnet-mask} {port | first_port-last_port}
SGOS#(config service-name) remove {transparent | explicit | all |
ip_address | ip_address/subnet-mask} {port | first_port-last_port}
SGOS#(config service-name) view

116

Chapter 9: Creating and Editing an HTTPS Reverse Proxy Service

Section B: Configuring HTTP or HTTPS Origination to the Origin Content Server

Creating Policy for HTTP and HTTPS Origination
Forwarding hosts must be already created on the SG appliance before forwarding policy
can be created.
To create a policy using CPL:

url.host=host_name forward(host_alias)

To create a policy using VPM:
1.

In the VPM module, create a Forwarding layer.

2.

Set the Destination to be the URL of the OCS.
Set the Action to forward to the forwarding host and configure parameters to control
forwarding behavior.

119

Volume 3: Proxies and Proxy Services

120

Chapter 10: Managing Shell Proxies

Shell proxies are those that provide a shell allowing a client to connect to the SG
appliance. In this version, only a Telnet shell proxy is supported.
Using a shell proxy, you can:


terminate a Telnet protocol connection either transparently or explicitly.



authenticate users either transparently or explicitly.



view the access log.



enforce policies specified by CPL.



communicate though an upstream SOCKS gateway and HTTP proxy using the
CONNECT method.

Within the shell, you can configure the prompt and various banners using CPL
$substitutions. You can also use hard-coded text instead of CPL substitutions

(available substitutions are listed in the table below). The syntax for a CPL substitution
is:
$(CPL_property)
Table 10-1. CPL Substitutions for Shell Proxies
Substitution

Description

proxy.name or
appliance.name

Configured name of the SG appliance.

proxy.address

IP address of the appliance on which this connection is
accepted.

proxy.card

Adapter number of the appliance on which this
connection is accepted.

client.protocol

This is "telnet".

client.address

IP address of the client.

proxy.primary_address or
appliance.primary_address

Primary address of the proxy, not where the user is
connected.

release.id

SGOS version.

Customizing Policy Settings for Shell Proxies
To manage a shell proxy through policy, you can use the conditions, properties, and
actions listed below. For information on using CPL to manage shell proxies, refer to
Volume 11: Blue Coat SG Appliance Content Policy Language Guide.

Conditions
• All time and date related triggers

• proxy.address=

121

Volume 3: Proxies and Proxy Services

• All exception related triggers

• proxy.card=

• All server_url triggers

• proxy.port=

• All url triggers

• client.protocol=

• All authentication related triggers

• user-defined conditions

• category=

• client.protocol=telnet

• client.address=

• url.scheme=telnet

Properties
• allow, deny, force_deny

• force_exception(exception_id[, details])

• action.action_name{yes|no)

• forward(alias_list | no)

• All trace() properties

• forward.fail_open(yes | no)

• All access_log() properties

• reflect_ip(auto|no|client|vip|ip-address)

• All log.xxx() properties

• socks_gateway(alias_list | no)

• access_server(yes|no)

• socks_gateway.fail_open(yes | no)

• authenticate.force(yes|no)

• telnet.prompt(no | string)

• authenticate(realm)

• telnet.realm_banner(no | string)

• exception(exception_id[, details])

• telnet.welcome_banner(no | string)

The banner strings support $-sign substitutions.

Actions
:

• rewrite(url.host, host_regex_pattern,
replacement_pattern)

• log_message()

• rewrite(url, url_regex_pattern,
replacement_pattern)

• notify_email(subject, body)

• set(url_port, port_number)

• notify_snmp(message)

Boundary Conditions for Shell Proxies


A hardcoded timeout of five minutes is enforced from the acceptance of a new
connection until destination information is provided using the Telnet command.



If proxy authentication is enabled, users have three chances to provide correct
credentials.



Users are not authenticated until destination information is provided.



Users can only enter up to an accumulated 2048 characters while providing the
destination information. (Previous attempts count against the total number of
characters.)



Connection to an upstream HTTP proxy is not encouraged.

122

Chapter 10: Managing Shell Proxies



If connections from untrustworthy IP address or subnet are not desired, then a
client IP/subnet-based deny policy must be written.

Understanding Telnet Shell Proxies
The Telnet shell proxy allows you to manage a Telnet protocol connection to the SG
appliance. Using the Telnet shell proxy, you can do:


Explicit termination without proxy authentication, where you explicitly connect,
through Telnet, to the SG hostname or IP address. In this case, the SG appliance
provides a shell.



Explicit termination with proxy authentication, where after obtaining the destination
host and port information from user, the SG appliance challenges for proxy
credentials. Once the correct proxy credentials are provided and authenticated, the
appliance makes an upstream connection and goes into tunnel mode. In this case, the
appliance provides a shell.



Transparent termination without proxy authentication, where the SG appliance
intercepts Telnet traffic through an L4 switch, software bridge, or any other
transparent redirection mechanism. From the destination address of TCP socket, the
SG appliance obtains OCS contact information and makes the appropriate upstream
connection, either directly or through any configured proxy. For more information on
configuring a transparent proxy, see Appendix B: "Explicit and Transparent Proxy"
on page 175.



Transparent termination with proxy authentication, where, after intercepting the
transparent connection, the SG appliance challenges for proxy credentials. Once the
correct proxy credentials are provided and authenticated, the SG appliance makes an
upstream connection and goes into tunnel mode.

Once in the shell, the following commands are available:


help: Displays available commands and their effects.



telnet : Makes an outgoing Telnet connection to specified server.

The colon (:) between server and port can be replaced with a space, if preferred.


exit: Terminates the shell session.

Creating a Telnet Shell Proxy Service
On a new system, Telnet proxy service is configured but disabled on port 23. On an
upgrade, a Telnet proxy service is not created.
Note: To use Telnet to manage the SG appliance, create a Telnet-Console rather than a
Telnet service. The Telnet service allows you to use Telnet for outbound connections, and
the appliance functions as Shell proxy in that situation. For more information on the
Telnet-Console, see “ Notes on Managing the Telnet Console” on page 21.

To edit or create a Telnet proxy service:
1.

Select Configuration > Services > Proxy Services.

2.

To edit a specific proxy service, highlight the service and click Edit.

3.

To create a new proxy service, click New.

123

Chapter 11: Managing a SOCKS Proxy

While SOCKS servers are generally used to provide firewall protection to an enterprise,
they also can be used to provide a generic way to proxy any TCP/IP or UDP protocols.
The SG appliance 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.
Note: For Blue Coat compatibility with SOCKS clients, check with customer support.

In a typical deployment, the SOCKS proxy works with the Endpoint Mapper proxy and
MAPI handoff. In this deployment, you will:


Create an Endpoint Mapper proxy at the remote office (the downstream proxy) that
intercepts Microsoft RPC traffic and creates dynamic TCP tunnels. Traffic to port
135 is transparently redirected to this service using bridging or L4 switch or WCCP.
For information on creating and enabling an Endpoint Mapper proxy service, see
“Chapter 6: Managing the Endpoint Mapper and MAPI Proxies” on page 55.



Create any other TCP tunnel proxies you need at the remote office: SMTP, DNS,
and the like. For information on configuring TCP tunnels, see “Chapter 13:
Managing the TCP Tunneling Proxy” on page 163.



Create a SOCKS gateway at the remote office. This SOCKS gateway points to a
SOCKS proxy located at the main office location (the upstream proxy, the core of
the network). For information on creating a SOCKS gateway, refer to Volume 6:
Advanced Networking



Set policy to forward TCP traffic through that SOCKS gateway. You can do this
through the layer using either the VPM or CPL. For more information, see
“Using Policy to Control the SOCKS Proxy” on page 132.

Creating or Editing a SOCKS Proxy Service
To create or edit a SOCKS proxy service:
1.

Select Configuration > Services > Proxy Services.

2.

To edit an existing SOCKS proxy service, highlight the service and click Edit. To
create a new proxy service, click New.

Note: If you only want to change the proxy’s behavior from bypass (the default) to
intercept, go to the Action column of the Proxy Services pane, select the service whose
behavior you want to change, and select Intercept from the drop-down list. You do
not need to enter New/Edit mode to change this attribute.

129

Chapter 11: Managing a SOCKS Proxy

a.

Select the Detect Protocol checkbox to automatically detect the protocol being
used. Note that this breaks connections that do not have the client send
information first, but expect the server to respond on connection. It also can
add significant delay if the client does not send specific information, and only
after timing out does it treat the traffic as unknown.

b.

Reflect Client IP: This option cannot be changed when creating or editing an

SOCKS proxy service.
c.

Early intercept: This option cannot be changed when creating or editing an
SOCKS proxy service.

d.

Enable ADN. Select this checkbox if you want this service to use ADN. Note that
enabling ADN does not guarantee the connections are accelerated by ADN. The actual
enable decision is determined by ADN routing (for explicit deployment) and network
setup (for transparent deployment).

e.

The Optimize Bandwidth checkbox is selected by default if you enabled WAN
optimization during initial configuration. You should de-select the checkbox
if you are not configuring a WAN optimization network.

6.

To create a new listener, click New; if you edit an existing listener, click Edit.

7.

Select a Destination IP address from the drop-down menu. The default is .

8.

In the Port Range field, enter the ports on which the service should listen. The default
port for the SOCKS proxy is 1080.

9.

Select the default behavior for the service: Bypass tells the service to ignore any traffic.
Intercept configures the service to intercept the traffic that is being proxied.

10. Click OK.
Relevant CLI Syntax to Create/Edit a Proxy Service:


To enter configuration mode for the service:
SGOS#(config) proxy-services
SGOS#(config proxy-services) create socks service-name
SGOS#(config proxy-services) edit service-name



The following subcommands are available:
SGOS#(config service-name) add {explicit | ip_address | ip_address/
subnet-mask} {port | first_port-last_port} [intercept | bypass]
SGOS#(config service-name) attribute {adn-optimize {enable | disable}|
detect-protocol {enable | disable} | use-adn {enable | disable}}
SGOS#(config service-name) bypass {explicit | ip_address | ip_address/
subnet-mask} {port | first_port-last_port}
SGOS#(config service-name) intercept {explicit | ip_address |
ip_address/subnet-mask} {port | first_port-last_port}
SGOS#(config service-name) remove {explicit | ip_address | ip_address/
subnet-mask} {port | first_port-last_port}
SGOS#(config service-name) view

Configuring the SOCKS Proxy
Complete the following steps to create a SOCKS proxy and to configure SOCKS-proxy
connection and timeout values.
To create a SOCKS proxy server:
1.

Select Configuration > Proxy Settings > SOCKS Proxy.

131

Chapter 11: Managing a SOCKS Proxy

2.

(Optional) To set the graph scale to a different value, select a value from the Graph
scale should drop-down list.

135

Volume 3: Proxies and Proxy Services

136

Chapter 12: Managing the SSL Proxy

HTTPS traffic poses a major security risk to enterprises. Because the SSL content is
encrypted, it can’t be monitored by normal means, allowing users to bring in viruses,
access forbidden sites, or leak business confidential information over the HTTPS
connection on port 443.
The SSL proxy allows you to intercept HTTPS traffic (in explicit and transparent
modes) so that security measures such as authentication, virus scanning and URL
filtering, and performance enhancements such as HTTP caching can be applied to
HTTPS content. Additionally, the SSL proxy allows you to validate server certificates
presented by various HTTPS sites at the gateway and offers information about the
HTTPS traffic in the access log.

Understanding the SSL Proxy
The SSL Proxy can be used to tunnel or intercept HTTPS traffic. The SSL Proxy tunnels
all HTTPS traffic by default unless there is an exception, such as a certificate error or a
policy denial. In such cases the SSL Proxy intercepts the SSL connection and sends an
error page to the user. The SSL Proxy allows interception of HTTPS traffic for
monitoring reasons as well.
Note:

Some HTTPS traffic, such as financial information, should not be
intercepted.
The SSL proxy can do the following operations while tunneling HTTPS traffic.


Validate server certificates, including revocation checks using Certificate
Revocation Lists (CRLs).



Check various SSL parameters such as cipher and version.



Log useful information about the HTTPS connection.

When the SSL Proxy is used to intercept HTTPS traffic, it can also:


Cache HTTPS content.



Apply HTTP-based authentication mechanism.



Do virus scanning and URL filtering.



Apply granular policy (such as validating mime type and filename extension).

Validating the Server Certificate
The SSL Proxy can do the following checks on server certificates:


Verification of issuer signature.



Verification of certificate dates.



Comparison of hostname in the URL and certificate (intercepted connections only).

137

Volume 3: Proxies and Proxy Services

Hostnames in server certificates are important because the SSL Proxy can identify a
Web site just by looking at the server certificate if the hostname is in the certificate.
Most content-filtering HTTPS sites follow the guideline of putting the name of the site
as the common name in the server's certificate.


Verification of revocation status.
To mimic the overrides supported by browsers, the SSL Proxy can be configured to
ignore failures for the verification of issuer signatures and certificate dates and
comparision of the hostname in the URL and the certificate.

The SG appliance trusts all root CA certificates that are trusted by Internet Explorer and
Firefox. This list is updated to be in sync with the latest versions of IE and Firefox.

Checking CRLs
An additional check on the server certificate is done through Certificate Revocations Lists
(CRLs). CRLs are lists that show which certificates are no longer valid; the CRLs are
created and maintained by Certificate Signing Authorities that issued the original
certificates.
Only CRLs that are issued by a trusted issuer can be used by the ProxySG. The CRL issuer
certificate must exist as CA certificate on the ProxySG before the CRL can be imported.
The ProxySG allows:


One local CRL per certificate issuing authority.



An import of a CRL that is expired; a warning is displayed in the log.



An import of a CRL that is effective in the future; a warning is displayed in the log.

Determining What HTTPS Traffic to Intercept
The SSL proxy tunnels HTTPS traffic by default; it does not intercept HTTPS traffic.
Many existing policy conditions, such as destination IP address and port number can be
used to decide which HTTPS connections to intercept.
Additionally, the SSL proxy allows the hostname in the server certificate to be used to
make the decision to intercept or tunnel the traffic. The server certificate hostname can be
used as is to make intercept decisions for individual sites, or it can be categorized using
any of the various URL databases supported by Blue Coat.
Categorization of server certificate hostnames can help place the intercept decision for
various sites into a single policy rule.
Recommendations for intercepting traffic include:


Intercept Intranet traffic



Intercept suspicious Internet sites, particularly those that are categorized as none in
the server certificate.

Managing Decrypted Traffic
After the HTTPS connection is intercepted, you can do:


Anti-virus scanning over ICAP.



URL filtering (on box and off-box). Blue Coat recommends on box URL/Content
filtering if you use transparent proxy. When the URL is sent off-box for filtering, only
the hostname or IP address of the URL (not the full path) is sent for security reasons.

138

Volume 3: Proxies and Proxy Services
Section A: Intercepting HTTPS Traffic

Section A: Intercepting HTTPS Traffic
Intercepting HTTPS traffic (by decrypting SSL connections at the SG appliance) allows
you to apply security measures like virus scanning and URL filtering.
Configuration to intercept HTTPS traffic requires the following steps:


Determine whether you are using transparent or explicit mode. For information on
explicit versus transparent proxies, see “Explicit and Transparent Proxy” on page 175.



Create an SSL service or HTTP/SOCKS services with protocol detection enabled.,
depending on whether you are using transparent or explicit mode. For more
information on creating an SSL service, skip to “Setting Up the SSL Proxy in
Transparent Proxy Mode” on page 140.



Create or import an issuer keyring, which is used to sign emulated server certificates
to clients on the fly, allowing the SSL proxy to examine SSL content. For more
information on creating an issuer keyring, see “Creating an Issuer Keyring for SSL
Interception” on page 143.



(Optional) Use the Notify User object or client consent certificates to notify users that
their requests are being intercepted and monitored. Whether this is required depends
on local privacy laws. Note that the SG appliance has to decrypt the first request from
the user to issue an HTML notification page. If this is not desirable, use client consent
certificates instead. For more information on configuring the Notify User object, refer
to Volume 7: VPM and Advanced Policy. For information on managing client consent
certificates, see “Using Client Consent Certificates” on page 143.



Download CA certificates to desktops to avoid a security warning from the client
browsers when the SG appliance is intercepting HTTPS traffic. For information, see
“Downloading an Issuer Certificate” on page 144.



Using policy (VPM or CPL), create rules to intercept SSL traffic and to control
validation of server certificates. By default, such traffic is tunneled and not
intercepted. You must create suitable policy before intercepting SSL traffic. For more
information on using policy to intercept SSL traffic, see “Configuring SSL Rules
through Policy” on page 147.



Configure the Blue Coat AV or other third-party ICAP vendor, if you have not already
done this. For more information on ICAP-based virus scanning, refer to Volume 8:
Managing Content.



Configure the Blue Coat Web Filter (BCWF) or a third-party URL-filtering vendor, if
you have not already done this. For more information on configuring BCWF, refer to
Volume 8: Managing Content.



Configure Access Logging. For more information on configuring access logging, refer
to Volume 9: Access Logging.



To customize exception pages (in case of server certificate verification failure), refer to
Volume 7: VPM and Advanced Policy.

Setting Up the SSL Proxy in Transparent Proxy Mode
Proxy services are configured from the Management Console or the CLI. If using SSL
proxy in transparent mode, continue with this section.

140

Volume 3: Proxies and Proxy Services
Section A: Intercepting HTTPS Traffic
a.

The Early Intercept checkbox cannot be changed for the SSL proxy service.

b.

The Reflect Client IP checkbox enables or disables sending of client's IP

address instead of the SG appliance's IP address. Note that this setting is
overruled by policy.
c.

Enable ADN. Select this checkbox if you want this service to use ADN. Note that
enabling ADN does not guarantee the connections are accelerated by ADN. The actual
enable decision is determined by ADN routing (for explicit deployment) and network
setup (for transparent deployment).

d. The Optimize Bandwidth checkbox is selected by default if you enabled WAN
optimization during initial configuration. You should de-select the checkbox
if you are not configuring a WAN optimization network.
6.

To create a new listener, click New; if you edit an existing listener, click Edit.

7.

Select a Destination IP address.

8.

In the Port Range field, enter the ports on which the service should listen. The default
port for SSL is 443.

9.

Select the default behavior for the service: Bypass tells the service to ignore any traffic.
Intercept configures the service to intercept the traffic that is being proxied.

10. Click OK.
Continue with “Creating an Issuer Keyring for SSL Interception” on page 143.
Relevant CLI Syntax to Create/Edit an SSL Proxy Service:


To enter configuration mode for the service:
SGOS#(config) proxy-services
SGOS#(config proxy-services) create service-type service-name
SGOS#(config proxy-services) edit service-name



The following subcommands are available:
SGOS#(config service-name) add {transparent | ip_address | ip_address/
subnet-mask} {port | first_port-last_port} [intercept | bypass]
SGOS#(config service-name) attribute {adn-optimize {enable | disable}
| reflect-client-ip {enable | disable} | use-adn {enable | disable}}
SGOS#(config service-name) bypass {transparent | ip_address |
ip_address/subnet-mask} {port | first_port-last_port}
SGOS#(config service-name) exit
SGOS#(config service-name) intercept {transparent | ip_address |
ip_address/subnet-mask} {port | first_port-last_port}
SGOS#(config service-name) remove {transparent | ip_address |
ip_address/subnet-mask} {port | first_port-last_port}
SGOS#(config service-name) view

Setting Up the SSL Proxy in Explicit Proxy Mode
The SSL Proxy can be used in explicit mode in conjunction with the HTTP Proxy or
SOCKS Proxy. You must create an HTTP Proxy service or a SOCKS Proxy service and use
it as the explicit proxy from desktop browsers. You must also ensure that the detectprotocol attribute is enabled for these services.

142

Volume 3: Proxies and Proxy Services
Section A: Intercepting HTTPS Traffic
something like: “Yes, I agree to SSL interception”. The other certificate has a common
name indicating denial of consent, something like: “No, I do not agree to SSL
interception”.
Policy is installed on the SG appliance to look for these common names and to allow or
deny actions. For example, when the string “Yes, I agree to SSL interception” is seen in the
client certificate common name, the connection is allowed; otherwise, it is denied.
To configure client consent certificates:
1.

Install the issuer of the client consent certificates as a CA certificate.

2.

In VPM, configure the Require Client Certificate object in the Action column of the SSL
Layer.

3.

Configure the Client Certificate object in the Source column to match common names.

Downloading an Issuer Certificate
When the SSL Proxy intercepts an SSL connection, it presents an emulated server
certificate to the client browser. The client browser issues a security pop-up to the enduser because the browser does not trust the issuer used by the SG appliance. This pop-up
does not occur if the issuer certificate used by SSL Proxy is imported as a trusted root in
the client browser's certificate store.
The SG appliance makes all configured certificates available for download via its
management console. You can ask end users to download the issuer certificate through
Internet Explorer or Firefox and install it as a trusted CA in their browser of choice. This
eliminates the certificate popup for emulated certificates.
To download the certificate through Internet Explorer, see "To download a certificate
through Internet Explorer:" on page 144. To download a certificate through Firefox, see
“To download a certificate through Firefox:” on page 146.
To download a certificate through Internet Explorer:
Note: You can e-mail the console URL corresponding to the issuer certificate to end
users so that the end-user can install the issuer certificate as a trusted CA.

1.

Go to Statistics > Advanced.

2.

Select SSL.

3.

Click Download a ProxySG Certificate as a CA Certificate; the list of certificates on the
system display.

4.

Click a certificate (it need not be associated with a keyring); the File Download
Security Warning displays asking what you want to do with the file.

144

Chapter 12: Managing the SSL Proxy

Section B: Configuring SSL Rules through Policy

Section B: Configuring SSL Rules through Policy
SSL interception and access rules, including server certificate validation, are configured
through policy—either VPM or CPL. Note that VPM is much easier to use than CPL. Use
the SSL Intercept Layer to configure SSL interception; use the SSL Access Layer to control
other aspects of SSL communication such as server certificate validation and SSL versions.
To configure SSL rules using CPL, skip to “CPL in the SSL Intercept Layer” on page 151.
This section covers the following topics:


“Using the SSL Intercept Layer” on page 147.



“Using the SSL Access Layer” on page 149



"Using Client Consent Certificates" on page 143

Using the SSL Intercept Layer
The SSL intercept layer allows you to set intercept options:


"To intercept HTTPS content through VPM:" on page 147



"To customize server certificate validation through VPM:" on page 150

For a list of policy conditions, properties, and actions, see “CPL in the SSL Intercept
Layer” on page 151.
Note: For detailed instructions on using VPM, refer to Volume 7: VPM and Advanced

Policy.
To intercept HTTPS content through VPM:
1.

Go to Configuration > Policy > Visual Policy Manager and launch VPM.

2.

From the Policy drop-down menu, select Add SSL Intercept Layer.

3.

Right-click Set in the Action column; the Set Action object displays.

4.

Click New and select Set SSL Forward Proxy object.

147

Chapter 12: Managing the SSL Proxy

Section B: Configuring SSL Rules through Policy
If server certificate validation is enabled, you can determine behavior by selecting
checkboxes to Ignore a hostname mismatch, Ignore certificate expiration, or Ignore
untrusted issuer. These overrides mimic the overrides supported by most browsers.
You can add server certificates to the SG appliance to allow proper validation. For
more information, refer to Volume 5: Securing the Blue Coat SG Appliance.
6.

If you want to check the CA certificate revocation list (CRL) from a Certificate
Authority, verify Also check certification revocation is selected. For information on
using CRL, see “Checking CRLs” on page 138.

CPL in the SSL Intercept Layer
Note: VPM is much easier to use than CPL. All CPL gestures except the
ssl.forward_proxy.server_keyring property, used only for troubleshooting, are

also in VPM.
The following CPL gestures can be used in the SSL Intercept layer:
Note: No authentication-related triggers are allowed in the SSL Intercept layer.

Allowed Properties (allowed in the SSL Intercept layer only):
• ssl.forward_proxy( )

• ssl.forward_proxy.splash_text( )

• ssl.forward_proxy.hostname( )

• trace.destination( )

• ssl.forward_proxy.issuer_keyring( )

• trace.request( )

• ssl.forward_proxy.server_keyring( )

• trace.rules( )

• ssl.forward_proxy.splash_url( )

• ssl.forward_proxy.server_keyring (used for
troubleshooting only)

Allowed Actions
• log_message( )

• notify_snmp( )

• notify_email( )

Allowed Conditions
• category

• proxy.port

• client.address

• server.certificate.hostname

• client.host

• server.certificate.hostname.category

• client.host.has_name

• server.certificate.subject

• client.protocol

• server_url.*

• proxy.address

• url.*

151

Volume 3: Proxies and Proxy Services
Section B: Configuring SSL Rules through Policy
• proxy.card

An example of using CPL to intercept SSL traffic is:
;create list of servers to intercept
define condition server_intercept_list
server.certificate.hostname.category=webmail
server.certificate.hostname=porn.com
server.certificate.hostname.category=gambling
server.certificate.hostname.category=none
end condition server_intercept_list

; value no means tunnel, value https means intercept as forward proxy
condition=server_intercept_list ssl.forward_proxy(https)
ssl.forward_proxy(no)
Note: For detailed instructions on using CPL, including detailed explanations of the
gestures listed here, refer to Volume 11: Blue Coat SG Appliance Content Policy Language
Guide

CPL in the SSL Layer
The following CPL gestures can be used in the SSL layer (called SSL Access layer in VPM):
Allowed Actions (allowed in the SSL layer only)
• server.certificate.
validate(yes | no)

• server.certificate.validate.
check_revocation
(local | no))

• server.certificate.
validate.ignore(hostname_
mismatch | expiration |
untrusted _issuer)

• client.certificate.
validate(yes | no)

• client.certificate.validate.
check_revocation
(local | no)

• client.certificate.
require(yes)

Allowed Conditions and Properties
• client.connection.
negotiated_ssl_version =
(condition)

• client.certificate.
common_name.regex =


• client.certificate.
subject.dn =

• client.certificate.common_
name[.exact|.substring|
.prefix|.suffix] =

• client.certificate.subject
[.exact|.substring|
.prefix|.suffix|.regex] =


• client.certificate.
subject.regex =

• server.certificate.
hostname[.exact|
.substring|.prefix|.suffix]=


• server.certificate.
hostname.regex=


• server.certificate.
hostname. category =


• server.certificate
.hostname.category =!

(condition)

• server.connection.
negotiated_cipher =

• server.connection.
negotiated_cipher.strength =
low | medium | high
| export

152

Chapter 12: Managing the SSL Proxy

Section B: Configuring SSL Rules through Policy
• ssl.proxy_mode=

• client.protocol=
tunneled=

Note: For detailed instructions on using CPL, including detailed explanations of the

gestures listed here, refer to Volume 11: Blue Coat SG Appliance Content Policy Language
Guide.

Notes
Note: Pipelining configuration for HTTP is ignored for HTTPS requests intercepted by

the SSL Proxy. When the SSL Proxy intercepts an HTTPS request, and the response is
an HTML page with embedded images, the embedded images are not pre-fetched by
the SG appliance.


If the SG appliance and the origin content server cannot agree on a common cipher
suite for intercepted connections, the connection is aborted.



Server-Gated Cryptography and step-up certificates are treated just as regular
certificates; special extensions present in these certificates are not be copied into the
emulated certificate. Clients relying on SGC/step-up certificates continue using
weaker ciphers between the client and the SG appliance when the SSL Proxy
intercepts the traffic.

153

Chapter 12: Managing the SSL Proxy

Section D: Advanced Topics

Section D: Advanced Topics
If you use OpenSSL or Active Directory, you can follow the procedures below to manage
your certificates.
For OpenSSL, see "Creating an Intermediate CA using OpenSSL" on page 157; if using
Active Directory, see “Creating an Intermediate CA using Microsoft Server 2003 (Active
Directory)” on page 159.

Creating an Intermediate CA using OpenSSL
This section describes the certificate management when creating an intermediate CA
using OpenSSL.
The overall steps are:


"Installing OpenSSL " on page 157



"Creating a Root Certificate" on page 157



"Modifying the OpenSSL.cnf File " on page 158



"Signing the SG CSR" on page 158



"Importing the Certificate into the SG Appliance" on page 159



"Testing the Configuration" on page 159

Various OpenSSL distributions can be found at http://www.openssl.org.

Installing OpenSSL
Once OpenSSL is installed, you must edit the openssl.cnf file and ensure the
pathnames are correct. By default root certificates are located under ./PEM/DemoCA;
generated certificates are located under /certs.

Creating a Root Certificate
In order to create a root Certificate Authority (CA) certificate, complete the following
steps.
Note: The key and certificate in this example is located at ./bin/PEM/demoCA/
private/

1.

Open a MS-DOS window, and enter:
openssl req -new -x509 -keyout
c:\resources\ssl\openssl\bin\PEM\demoCA\private\
cakey.pem -out
c:\resources\ssl\openssl\bin\PEM\demoCA\private\CAcert.pem

where the root directory for openssl is: \resources\ssl\openssl
openssl req -new -x509 -keyout
c:\resources\ssl\openssl\bin\PEM\demoCA\private\cakey.pem -out
c:\resources\ssl\openssl\bin\PEM\demoCA\private\CAcert.pem
Using configuration from C:\Resources\SSL\OpenSSL\bin\openssl.cnf
Loading 'screen' into random state - done
Generating a 1024 bit RSA private key

157

Volume 3: Proxies and Proxy Services
Section D: Advanced Topics
.....................................+++++
................................................+++++
writing new private key to
'c:\resources\ssl\openssl\bin\PEM\demoCA\private\cakey.pem'
Enter PEM pass phrase:

2.

Type any string more than four characters for the PEM pass phrase.

3.

Enter the certificate parameters, such as country name, common name that are
required for a Certificate Signing Request (CSR).
The private key and root CA are now located under the directory ./PEM/DemoCA/
private

4.

Create a SG keyring.
a.

5.

From the Management Console, select Configuration > SSL > Keyrings.

b.

Click Create; fill in the fields as appropriate.

c.

Click OK.

Create a CSR on the SG appliance.
a.

From the Management Console, select Configuration > SSL > Keyrings.

b.

Highlight the keyring you just created; click Edit/View.

c.

In the Certificate Signing Request pane, click Create and fill in the fields as
appropriate.
Note: Detailed instructions on creating a keyring and a CSR are in Volume 5:
Securing the Blue Coat SG Appliance. They can also be found in the online help.

6.

Paste the contents of the CSR into a text file called new.pem located in the ./bin
directory.

Modifying the OpenSSL.cnf File
Modify the openssl.cnf file to import the openSSL root CA into your browser. If you do
not do this step, you must import he SG appliance certificate into the browser.
1.

In the openssl.cnf file, look for the string basicConstraints=CA, and set it to TRUE.
basicConstraints=CA:TRUE

2.

Save the openSSL.cnf file.

Signing the SG CSR
Open a MS-DOS window and enter:
openssl ca -policy policy_anything -out newcert.pem -in new.pem

The output is:
Using configuration from C:\Resources\SSL\OpenSSL\bin\openssl.cnf
Enter PEM pass phrase:
Check that the request matches the signature
Signature ok
The Subjects Distinguished Name is as follows
countryName
:PRINTABLE:'FR'
stateOrProvinceName
:PRINTABLE:'Paris'

158

Chapter 12: Managing the SSL Proxy

Section D: Advanced Topics
localityName
:PRINTABLE:'Paris'
organizationName
:PRINTABLE:'BlueCoat'
organizationalUnitName:PRINTABLE:'Security Team'
commonName
:PRINTABLE:'ProxySG.bluecoat.com'
emailAddress
:IA5STRING:'[email protected]'
Certificate is to be certified until Sep 27 13:29:09 2006 GMT (365
days)
Sign the certificate? [y/n]:y
1 out of 1 certificate requests certified, commit? [y/n]y
Write out database with 1 new entries
Data Base Updated

This signs the certificate; it can then be imported into the SG appliance.

Importing the Certificate into the SG Appliance
1.

Open the file newcert.pem in a text editor.

2.

Go to the Management Console > Configuration > SSL > SSL Keyrings.

3.

Selecting the keyring used for SSL interception; click Edit/View.

4.

Paste in the contents of the newcert.pem file.

5.

Import the contents of the newcert.pem file into the CA Certificates list.
a.

From the Management Console, select Configuration > SSL > CA Certificates.

b.

Click Import; enter the certificate name in the CA Cert Name field.

c.

Paste the certificate, being sure to include the -----BEGIN CERTIFICATE---and the ----END CERTIFICATE----- statements in the ./bin/PEM/demoCA/
private/CAcert file.

d. Click OK.
Note: Detailed instructions on importing a CA certificate are in Chapter 9:
"Creating and Editing an HTTPS Reverse Proxy Service" on page 113.

Testing the Configuration
Import the root CA into your browser and construct an SSL interception policy.
9ta

Note: Detailed instructions on constructing an SSL interception policy are in
“Configuring SSL Rules through Policy” on page 147.

You should not be prompted for any certificate warning.

Creating an Intermediate CA using Microsoft Server 2003 (Active Directory)
This section describes certificate management when creating an intermediate CA using
Active Directory.
Before you begin:


Make sure the Windows 2003 system is an Active Directory server.



Make sure IIS is installed.

159

Volume 3: Proxies and Proxy Services
Section D: Advanced Topics


Install the "Certificate Services" through the control panel



Select the mode to be Enterprise root CA.

All certificate management is done through the browser using the following URL:
http://@ip_server/CertSrv
You will complete the following steps:


"To install the root CA onto the browser:" on page 160



"To create a SG keyring and certificate signing request:" on page 160



"To sign the SG CSR:" on page 160



"To import the certificate onto the SG appliance:" on page 160



"To test the configuration:" on page 161

To install the root CA onto the browser:
1.

Connect to HTTP://@ip_server/CertSrv

2.

Click Download a CA Certificate.

3.

Click Install this CA Certificate chain.

This installs the root CA onto the browser.
To create a SG keyring and certificate signing request:
1.

From the Management Console, go to SSL > Keyrings.

2.

Create a new keyring. For detailed instructions on creating a new keyring, refer to
Volume 5: Securing the Blue Coat SG Appliance.

3.

Create a Certificate Signing Request (CSR). For detailed instructions on creating a
CSR, refer to Volume 5: Securing the Blue Coat SG Appliance.

4.

Click OK.

To sign the SG CSR:
1.

Connect to http://@ip_server/CertSrv

2.

Select the option Request a certificate.

3.

Select Submit an advanced certificate request and then Submit a certificate request by
using a base 64 encoded …

4.

Paste the contents of the CSR.

5.

Select the Certificate Template Subordinate Certification Authority.
If this template does not exist, connect to the certificate manager tool on the Active
Directory server and add the template.

6.

Click on Submit.

7.

Download the certificate (not the chain) as Base 64 encoded.

8.

Save this file on the workstation as newcert.pem.

To import the certificate onto the SG appliance:
1.

Open the file newcert.pem in a text editor.

160

Chapter 12: Managing the SSL Proxy

Section D: Advanced Topics
2.

Go to the Management Console > Configuration > SSL > SSL Keyrings.

3.

Select the keyring that has the CSR created; click Edit/View.
Note: Make sure this keyring is used as the issuer keyring for emulated certificates.
Use policy or the SSL intercept setting in the Management Console or the CLI.

4.

Paste the contents of the newcert.pem file.

5.

Import the contents of the newcert.pem file into the CA Certificates list.
a.

From the Management Console, select Configuration > SSL > CA Certificates.

b.

Click Import; enter the certificate name in the CA Cert Name field.

c.

Paste the certificate, being sure to include the -----BEGIN CERTIFICATE---and the ----END CERTIFICATE----- statements in the ./bin/PEM/demoCA/
private/CAcert file.

d. Click OK.
Note: Detailed instructions on importing a CA certificate are in Chapter 9:
"Creating and Editing an HTTPS Reverse Proxy Service" on page 113.

To test the configuration:
Import the root CA into your browser and construct a SSL interception policy.
Note: Detailed instructions on constructing an SSL interception policy are in
“Configuring SSL Rules through Policy” on page 147.

You should not be prompted for any certificate warning.

161

Volume 3: Proxies and Proxy Services

162

Chapter 13: Managing the TCP Tunneling Proxy

Tunneling, or port forwarding, is a way to forward TCP traffic. Any application
protocol running over TCP can be tunneled using this service. Client-server
applications carry out any authentication procedures just as they do when TCP
tunneling is not involved.
SGOS uses a tcp:// scheme for TCP-tunnel transactions instead of HTTPS because
SGOS does not actually know that it is HTTPS that is being tunneled.
You can use ADN optimization in conjunction with TCP tunnels to compress and
accelerate the tunneled traffic. Both explicit and transparent TCP tunneling are
supported. Which one you use depends on your needs.


Explicit TCP tunneling allows connections to one of the SG appliance's IP
addresses.



Transparent TCP tunneling allows connections to any IP address other than those
belonging to the SG appliance. TCP tunneling in transparent mode supports
categorization as well as blocking of destination IP address, port, host, and domain.

Note: The TCP-Tunnel service does not support content filtering with Websense offbox

or ICAP.

TCP-Tunnel Proxy Services Supported
A number of proxy services are supported with the TCP-Tunnel proxy. For the most
current list, see Table 3-1: "Proxy Name and Listeners" on page 24.
In addition, the default proxy service (which listens on all ports not assigned to other
services), uses the TCP-Tunnel proxy. The default proxy service has only one listener;
its 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.
To keep the SG appliance from interfering with unassigned traffic, set the behavior to
bypass.
An access log entry is available for every TCP tunnel connection.

Creating or Editing a TCP-Tunnel Proxy Service
1.

Select Configuration > Services > Proxy Services.

2.

To edit a TCP-Tunnel proxy service, highlight the service and click Edit. To create a
new proxy service, click New.
Note: If you only want to change the proxy’s behavior from bypass (the default)
to intercept, go to the Action column of the Proxy Services pane, select the service
whose behavior you want to change, and select Intercept from the drop-down list.
You do not need to enter New/Edit mode to change this attribute.

163

Chapter 13: Managing the TCP Tunneling Proxy

a.

Select the Detect Protocol checkbox to automatically detect the protocol being
used. Note that this breaks connections that do not have the client send
information first, but expect the server to respond on connection. It also can
add significant delay if the client does not send specific information.

b.

Reflect Client IP: Enables or disables sending of client's IP address instead of

the SG appliance's IP address.

6.

c.

Early intercept: 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.

d.

Enable ADN. Select this checkbox if you want this service to use ADN. Note that
enabling ADN does not guarantee the connections are accelerated by ADN. The actual
enable decision is determined by ADN routing (for explicit deployment) and network
setup (for transparent deployment).

e.

The Optimize Bandwidth checkbox is selected by default if you enabled ADN
optimization during initial configuration. You should de-select the checkbox
if you are not configuring ADN optimization.

To create a new listener, click New.
a.

Select a Destination IP address from the drop-down menu.

b.

In the Port Range field, enter the ports on which the service should listen. The
default ports for each service are listed in Table 3-1. "Proxy Name and
Listeners " on page 24.

c.

Select the default action for the service: Bypass tells the service to ignore any
traffic. Intercept configures the service to intercept the traffic that is being
proxied.
If you selected Optimize all other TCP traffic during initial configuration, all
listeners in services that use the TCP-Tunnel proxy intercept traffic. If you did not
select Optimize all other TCP traffic, TCP-Tunnel listeners bypass all traffic by
default.

7.

Click OK; click Apply.

Related CLI Syntax to Create/Edit a Tunneling Proxy Service


To enter configuration mode:
SGOS#(config) proxy-services
SGOS#(config proxy-services) create tcp-tunnel service-name
SGOS#(config proxy-services) edit service-name



The following subcommands are available:
SGOS#(config service-name) add {transparent | explicit | all |
ip_address | ip_address/subnet-mask} {port | first_port-last_port}
[intercept | bypass]
SGOS#(config service-name) attribute {adn-optimize {enable | disable}|
detect-protocol {enable | disable}| early-intercept {enable |
disable}| reflect-client-ip {enable | disable} | use-adn {enable |
disable}}
SGOS#(config service-name) bypass {transparent | explicit | all |
ip_address | ip_address/subnet-mask} {port | first_port-last_port}
SGOS#(config service-name) exit
SGOS#(config service-name) intercept {transparent | explicit | all |
ip_address | ip_address/subnet-mask} {port | first_port-last_port}

165

Volume 3: Proxies and Proxy Services

SGOS#(config service-name) remove {transparent | explicit | all |
ip_address | ip_address/subnet-mask} {port | first_port-last_port}
SGOS#(config service-name) view

If you created a transparent TCP-Tunnel service, the procedure is complete. If you created
an explicit TCP-Tunnel service, you must configure a forwarding destination port.
To configure a forwarding destination port:
1.

Create a forwarding destination port, where the SG appliance directs traffic.
SGOS#(config proxy-services tcp-tunnel) exit
SGOS#(config proxy-services) exit
SGOS#(config) forwarding
SGOS#(config forwarding) create host_alias ip_address tcp=port

2.

(Optional) View the results:
SGOS#(config forwarding) view
Forwarding Groups: (* = host unresolved)
No forwarding groups defined.
Individual Hosts: (* = host unresolved)
Host_Alias 10.25.36.47 tcp=port_number

166

Appendix A: Glossary

Term

Description

ADN Optimize Attribute

Controls whether to optimize bandwidth usage when connecting upstream using an
ADN tunnel.

Asynchronous Adaptive

This allows the ProxySG to keep cached objects as fresh as possible, thus reducing
response times. The AAR algorithm allows HTTP proxy to manage cached objects
based on their rate of change and popularity: an object that changes frequently and/
or is requested frequently is more eligible for asynchronous refresh compared to an
object with a lower rate of change and/or popularity.

Refresh (AAR)

Asynchronous Refresh
Activity

Refresh activity that does not wait for a request to occur, but that occurs
asynchronously from the request.

Attributes (Service)

The service attributes define the parameters, such as explicit or transparent,
cipher suite, and certificate verification, that the SG appliance uses for a
particular service. .

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

authentication

The process of identifying a specific user.

authorization

The permissions given to a specific user.

Bandwidth Gain

A measure of the difference in client-side and server-side Internet traffic expressed in
relation to server-side Internet traffic. It is managed in two ways: you can enable or
disable bandwidth gain mode or you can select the Bandwidth Gain profile (this also
enables bandwidth gain mode)..

Bandwidth Class

A defined unit of bandwidth allocation. An administrator uses bandwidth classes to
allocate bandwidth to a particular type of traffic flowing through the SG appliance.

Bandwidth Class Hierarchy

Bandwidth classes can be grouped together in a class hierarchy, which is 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 to be its
children.

Bandwidth Policy

The set of rules that you define in the policy layer to identify and classify the traffic in
the SG appliance, using the bandwidth classes that you create. You must use policy
(through either VPM or CPL) in order to manage bandwidth.

Bypass Lists

The bypass list allows you to exempt IP addresses from being proxied by the SG

appliance. The bypass list allows either or a specific IP prefix entry for
both the client and server columns. Both UDP and TCP traffic is
automatically exempted.

167

Volume 3: Proxies and Proxy Services

Term

Description

Byte-Range Support

The ability of the ProxySG to respond to byte-range requests (requests with a Range:
HTTP header).

Cache-hit

An object that is in the ProxySG and can be retrieved when an end user requests the
information.

Cache-miss

An object that can be stored but has never been requested before; it was not in the
ProxySG to start, so it must be brought in and stored there as a side effect of
processing the end-user's request. If the object is cacheable, it is stored and served the
next time it is requested.

Child Class (Bandwidth
Gain)

The child of a parent class is dependent upon 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.

Client consent certificates

A certificate that indicates acceptance or denial of consent to decrypt an end user's
HTTPS request.

Compression

An algorithm that reduces a file’s size but does not lose any data. The ability to
compress or decompress objects in the cache is based on policies you create.
Compression can have a huge performance benefit, and it can be customized based
on the needs of your environment: Whether CPU is more expensive (the default
assumption), server-side bandwidth is more expensive, or whether client-side
bandwidth is more expensive.

Default Proxy Listener

See “ Proxy Service (Default)” on page 171.

Detect Protocol Attribute

Detects the protocol being used. Protocols that can be detected include:
HTTP, P2P (eDonkey, BitTorrent, FastTrack, Gnutella), SSL, and Endpoint Mapper.

Directives

Directives are commands that can be used in installable lists to configure forwarding.
See also forwarding Configuration.

Display Filter

The display filter is a drop-down list at the top of the Proxy Services pane that allows
you to view the created proxy services by service name or action.

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.

Emulated Certificates

Certificates that are presented to the user by 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.

ELFF-compatible format

A log type defined by the W3C that is general enough to be used with any protocol.

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 SG appliance.

168

Appendix A: Glossary

Term

Description

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 SG appliance, and requires configuration for both browser
and the interface card.

Fail Open/Closed

Failing open or closed applies to forwarding hosts and groups and SOCKS gateways.
Fail Open/Closed applies when the health checks are showing sick for each
forwarding or SOCKS gateway target in the applicable fail-over sequence. If no
systems are healthy, the SG appliance 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.

Forwarding Configuration

Forwarding can be configured through the CLI or through adding directives to a text
file and installing it as an installable list. Each of these methods (the CLI or using
directives) is equal. You cannot use the Management Console to configure
forwarding.

Forwarding Host

Upstream Web servers or proxies.

forward proxy

A proxy server deployed close to the clients and used to access many servers. A
forward proxy can be explicit or transparent.

Freshness

A percentage that reflects the objects in the ProxySG cache that are expected to be
fresh; that is, the content of those objects is expected to be identical to that on the OCS
(origin content server).

Gateway

A device that serves as entrance and exit into a communications network.

Global Default Settings

You can configure settings for all forwarding hosts and groups. These are called the
global defaults. You can also configure private settings for each individual
forwarding host or group. Individual settings override the global defaults.

FTP

See Native FTP; Web FTP.

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
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.

Inbound Traffic (Bandwidth
Gain)

Network packets flowing into the SG appliance. Inbound traffic mainly consists of
the following:
• Server inbound: Packets originating at the origin content server (OCS) and sent to
the SG appliance to load a Web object.
• Client inbound: Packets originating at the client and sent to the SG

appliance for Web requests.

169

Volume 3: Proxies and Proxy Services

Term

Description

Installable Lists

Installable lists, comprised of directives, can be placed onto the SG appliance in one
of several methods: through creating the list through the SG text editor, by placing
the list at an accessible URL, or by downloading the directives file from the local
system.

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.

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 SG's IP address.

Issuer keyring

The keyring that is used by the SG appliance to sign emulated certificates. The
keyring is configured on the appliance and managed through policy.

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.
Load Balancing

The ability to share traffic requests among multiple upstream targets. Two methods
can be used to balance the load among systems: least-connections or roundrobin.

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 SG appliance. 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
SG appliance, not all access log entries are necessarily displayed. However, you can
view all access log information after uploading the log.

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.

NCSA common log format

A log type that contains only basic HTTP access information.

170

Appendix A: Glossary

Term

Description

Negative Responses

An error response received from the OCS when a page or image is requested. If the
ProxySG is configured to cache such negative responses, it returns that response in
subsequent requests for that page or image for the specified number of minutes. If it
is not configured, which is the default, the ProxySG attempts to retrieve the page or
image every time it is requested.

Native FTP

Native FTP involves the client connecting (either explicitly or transparently) using
the FTP protocol; the SG appliance then connects upstream through FTP (if
necessary).

Outbound Traffic
(Bandwidth Gain)

Network packets flowing out of the SG appliance. 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.

Origin Content Server (OCS)
Parent Class (Bandwidth
Gain)

PASV

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. Data connections initiated by an FTP client to

an FTP server.
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 SG
appliance, which can reference an existing security infrastructure—LDAP, RADIUS,
IWA, and the like.

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.

realms

A realm is a named collection of information about users and groups. The name is
referenced in policy to control authentication and authorization of users for access to
Blue Coat Systems SG services. Multiple authentication realms can be used on a
single SG appliance. Realm services include IWA, LDAP, Local, and RADIUS.

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.

171

Volume 3: Proxies and Proxy Services

Term

Description

Refresh Bandwidth

The amount of bandwidth used to keep stored objects fresh. By default, the ProxySG
is set to manage refresh bandwidth automatically. You can configure refresh
bandwidth yourself, although Blue Coat does not recommend this.

reverse proxy

A proxy that acts as a front-end to a small number of pre-defined servers, typically to
improve performance. Many clients can use it to access the small number of
predefined servers.

rotate logs

When you rotate a log, the old log is no longer appended to the existing log, and a
new log is created. All the facility information (headers for passwords, access log
type, and so forth), is re-sent at the beginning of the new upload.
If you're using Reporter (or anything that doesn't understand the concept of "file,”
such as streaming) the upload connection is broken and then re-started, and, again,
the headers are re-sent.

serial console

A device that allows you to connect to the SG appliance when it is otherwise
unreachable, without using the network. It can be used to administer the SG
appliance through the CLI. You must use the CLI to use a serial console.
Anyone with access to the serial console can change the administrative access
controls, so physical security of the serial console is critical.

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.

Sibling Class (Bandwidth
Gain)

A bandwidth class with the same parent class as another class.

SOCKS Proxy

A generic way to proxy TCP and UDP protocols. The SG appliance 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..

SmartReporter log type

A proprietary ELFF log type that is compatible with the SmartFilter SmartReporter
tool.

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.

SSL

A standard protocol for secure communication over the network. Blue Coat
recommends using this protocol to protect sensitive information.

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.

172

Appendix A: Glossary

Term

Description

static routes

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.

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.

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 SG appliance. A single request
from a client involves two separate connections. One of them is from the client to the
SG appliance, and the other is from the SG appliance to the OCS. Within each of
these connections, traffic flows in two directions—in one direction, packets flow out
of the SG appliance (outbound traffic), and in the other direction, packets flow into
the SG (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.

transparent proxy

A configuration in which traffic is redirected to the SG appliance 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.

Variants

Objects that are stored in the cache in various forms: the original form, fetched from
the OCS; the transformed (compressed or uncompressed) form (if compression is
used). If a required compression variant is not available, then one might be created
upon a cache-hit. (Note: policy-based content transformations are not stored in the
ProxySG.)

Web FTP

Web FTP is used when a client connects in explicit mode using HTTP and
accesses an ftp:// URL. The SG appliance 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 proprietary log type that is compatible with the Websense reporter tool.

173

Volume 3: Proxies and Proxy Services

Term

Description

Wildcard Services

When multiple non-wildcard services are created on a port, all of them must be of the
same service type (a wildcard service is one that is listening for that port on all IP
addresses). If you have multiple IP addresses and you specify IP addresses for a port
service, you cannot specify a different protocol if you define the same port on another
IP address. For example, if you define HTTP port 80 on one IP address, you can only
use the HTTP protocol on port 80 for other IP addresses.
Also note that wildcard services and non-wildcard services cannot both exist at the
same time on a given port.
For all service types except HTTPS, a specific listener cannot be posted on a port if
the same port has a wildcard listener of any service type already present.

174

Appendix B: Explicit and Transparent Proxy

Whether you select explicit or transparent proxy deployment is determined by factors
such as network configuration, number of desktops, desired user experience, and
desired authentication approach.
Note: While you must configure proxying to do authentication, verify the proxy is
configured correctly and is functioning before adding authentication to the mix. Many
network or other configuration problems can appear similar to authentication errors.

Understanding the Explicit Proxy
In an explicit proxy configuration, the client (browser) is explicitly configured to use a
proxy server. The browser is given the IP address and port number of the proxy service
(the SG appliance). It is also possible to configure the browser to download the proxy
settings from a Web server. This is called a Proxy Auto-Configuration (PAC) file. When
a user makes a request, the browser connects to the proxy service and sends the
request. Because the browser knows it is talking to a proxy, the browser provides the
proxy server with the destination server.
The proxy service accepts the explicit connection to it, and fetches the request from the
browser. The request identifies the desired origin content server (OCS) and the resource
on that server. The proxy service uses this information to contact the OCS if necessary.
The disadvantage to explicit proxy is that each desktop must be properly configured to
use the proxy, which might not be feasible in a large organization.
Note: Explicit proxy allows a redundant configuration using IP address failover
among a cluster of machines. For information on creating a redundant configuration for
failover, refer to Volume 6: Advanced Networking.

Understanding the Transparent Proxy
When transparent proxy is enabled, the client (browser) does not know the traffic is
being processed by a machine other than the OCS. The browser believes it is talking to
the OCS, so the request is formatted for the OCS and the proxy determines for itself the
destination server based on information in the request, such as the destination IP
address in the packet, or the Host: header in the request.
To enable the SG appliance to intercept traffic sent to it, you must create a service and
define it as transparent. The service is configured to intercept traffic for a specified port,
or for all IP addresses on that port. A transparent HTTP proxy, for example, typically
intercepts all traffic on port 80 (all IP addresses).
To make sure that the appropriate traffic is directed to the SG appliance, deploy
hardware such as a Layer-4 switch or a WCCP router, or the SG appliance’s software
bridge that can redirect selected traffic to the appliance. Traffic redirection is managed
through polices you create on the redirection device.
For detailed information on explicit proxies, continue with the next section; for detailed
information on transparent proxies, continue with “Transparent Proxies” on page 177.

175

Volume 3: Proxies and Proxy Services

For information on creating an explicit proxy server, regardless of proxy type, continue
with “ Creating an Explicit Proxy Server” on page 176.

Creating an Explicit Proxy Server
If your network does not use transparent proxy, clients on the network must configure
their browsers to use either an explicit proxy server or a Proxy Auto-Configuration (PAC)
file.
Two PAC files ship with the SG appliance:


PAC file.



Accelerated PAC file.

They can be accessed at:


https://SG_IP_Address:8082/accelerated_pac_base.pac



https://SG_IP_Address:8082/proxy_pac_file

They can be edited with any text editor.
The SG appliance generates client instructions that describe how to configure Microsoft
Internet Explorer, Netscape Communicator, and Firefox based on instructions selected by
the SG administrator. You can configure client instructions for each network adapter in the
SG appliance with the Configuration > Network > Adapters > Interface > Settings button.
After selecting client instructions, the SG administrator directs clients to go to the SG
home page and follow the instructions in the Browser Configuration section. The SG
appliance detects the browser installed on the client and displays the appropriate
instructions.

Using the SG Appliance as an Explicit Proxy
To use the SG appliance as an explicit proxy and use services such as SOCKS or FTP, you
must provide custom instructions to clients instructing them how to configure their
browsers to use the SG appliance as a proxy server.
This is a two-step process, requiring that you add the proxy IP address to the browser and
also instruct the SG appliance which adapter interface uses the proxy IP address.
Before the proxy can be used, you must:


Configure the proxy server.



Enable the explicit proxy (whether a service or a server).

The browsers described here are Internet Explorer 6.0 and Firefox 1.5. If you have different
browsers or different versions of Internet Explorer or Firefox, refer to the vendor
documentation for information on configuring proxies.
From Internet Explorer:
1.

Select Tools > Internet Options > Connections > LAN Settings.

2.

Click Use a proxy server.

3.

Enter the IP address and port number for the proxy, or click Advanced to set proxy
server IP addresses and port numbers for services such as HTTP, FTP, and SOCKS.
(Configure HTTPS through the Secure field.)

4.

Click OK to exit the Advanced Settings tab, then continue to click OK until you exit the
Tools menu.

176

Appendix B: Explicit and Transparent Proxy

From Firefox:
1.

Select Tools > Options > Genera l> Connection Settings.

2.

Click Manual proxy configuration.

3.

Enter proxy server IP addresses and port numbers for services such as HTTP, FTP,
SOCKS, and SSL.

4.

Click OK.; click OK again.

Configuring Adapter Proxy Settings
Once the explicit proxy is configured on the browser, decide which adapter interfaces
listen for which service. Each adapter interface can listen for only one IP address; you can
configure multiple proxies on one SG appliance using the same IP address.
To provide configuration instructions on the SG appliance:
1.

Select Configuration > Network > Adapters.

2.

In the Adapter pane, select the adapter you want to use. If an adapter does not exist,
the Adapter pane displays the word Empty.

3.

In the Interface pane, select the correct interface. Click Settings.

4.

Select Using a proxy.

5.

Click OK to close the Settings dialog.

Relevant CLI Syntax to Configure Adapter Proxy Settings
SGOS#(config) interface fast-ethernet interface_#

Transparent Proxies
A transparent proxy can be can be configured several ways:


Through hardware: See “Configuring Transparent Proxy Hardware” on page 177.



Through bridging: “Bridging” on page 178.



Through using the SG appliance as a gateway: See “Configuring IP Forwarding” on
page 179.

In addition to the transparent proxy configuration, you must create a proxy service for the
transparent proxy and enable the service. At this time, you can also set other attributes for
the service, including the destination IP address and port range. For information on
creating or editing a proxy service for transparent configuration, see Chapter 3: "About
Proxy Services" on page 23.

Configuring Transparent Proxy Hardware
For transparent proxy to work, you must use one of the following:


A bridge, either hardware or software



Layer-4 switch



WCCP

177

Volume 3: Proxies and Proxy Services

Bridging
Network bridging through the SG appliance provides transparent proxy pass-through
and failover support. This functionality allows SG appliances to be deployed in
environments where L4 switches and WCCP-capable routers are not feasible options.
The SG appliance provides bridging functionality by two methods:


Software—A software, or dynamic, bridge is constructed using a set of installed
interfaces. Within each logical bridge, interfaces can be assigned or removed. Note
that the adapters must of the same type. Although the software does not restrict you
from configuring bridges with adapters of different types (10/100 or GIGE), the
resultant behavior is unpredictable.
To set up a software bridge, refer to Volume 2: Getting Started.



Hardware—The Blue Coat Pass-Through card is a 10/100 dual interface Ethernet
device that enables a bridge, using its two adapters, so that packets can be forwarded
across it. However, if the system crashes, the Pass-Through card becomes a network:
the two Ethernet cables are connected so that traffic can continue to pass through
without restriction.
When the Pass-Through card is installed on the SG appliance, a bridge is
automatically created and traffic going through the bridge is intercepted according to
the proxy-service setting. Note that:


Forwarding traffic behavior: By default, the bridge forwards packets that are not
to be intercepted.



Proxy request behavior: Requests are proxied on either adapter, so if you connect
one side of the bridge to your Internet connection, there might be a number of
issues.

Configuring a Layer-4 Switch
In transparent proxy acceleration, as traffic is sent to the origin content server, any traffic
sent on port 80 is redirected to the SG appliance by the Layer 4 switch. The benefits to
using a Layer 4 switch include:


Built-in failover protection. In a multi-SG setup, if one appliance fails, the Layer 4
switch can route to the next SG appliance.



Request partitioning based on IP address instead of on HTTP transparent proxying.
(This feature is not available on all Layer 4 switches.)



SG appliance bypass prevention. You can configure a Layer 4 device to always go
through the SG appliance even for requests to a specific IP address.



SG appliance bypass enabling. You can configure a Layer 4 device to never go through
the SG appliance.

For information on configuring a layer-4 switch, refer to the manufacturer’s
documentation.

Configuring a WCCP-Capable Router
WCCP is a Cisco®-developed protocol that allows you to establish redirection of the traffic
that flows through routers.
The main benefits of using WCCP are:


Scalability—With no reconfiguration overhead, redirected traffic can be automatically
distributed to up to 32 SG appliances.

178

Appendix B: Explicit and Transparent Proxy



Redirection safeguards—If no SG appliances are available, redirection stops and the
router forwards traffic to the original destination address.

For information on using WCCP with a SG appliance, refer to Volume 6: Advanced
Networking.

Configuring IP Forwarding
IP Forwarding is a special type of transparent proxy. The SG appliance is configured to act
as a gateway and is configured so that if a packet is addressed to the SG adapter, but not
its IP address, the packet is forwarded toward the final destination. If IP forwarding is
disabled, the packet is rejected as being mis-addressed.
By default, IP forwarding is disabled to maintain a secure network.
Important: When IP forwarding is enabled, be aware that all SG ports are open and all
the traffic coming through them is not subjected to policy, with the exception of the
ports that have explicitly defined through the Configuration > Services > Proxy Services
tab.

To enable IP forwarding:
1.

Select Configuration > Network > Routing > Gateways.

2.

Select the Enable IP forwarding checkbox.

3.

Click OK; click Apply.

Related CLI Syntax to Enable IP Forwarding
SGOS#(config) tcp-ip ip-forwarding enable

179

Volume 3: Proxies and Proxy Services

180

Index

A
accept-encoding request header modification,
troubleshooting 103
active client connections 106
ADN optimization
attribute defined 27
Authenticate-401, attribute defined 27

B
bandwidth gain
additional configurations affecting 93
byte-range support effects 94
revalidate pragma-no-cache effects 95
bandwidth refresh, configuring 95
browser
proxy, configuring for 176
setting for explicit proxies 176
bypass list
overview 30
byte-range support
affecting bandwidth gain 94
configuring 94

C
client consent certificates, using with SSL proxy 143
client-side bandwidth, enhancing 103
compression
behavior 98
boundary conditions 103
cache-control
no-transform directive ignored 104
client-side bandwidth settings 103
configuring 100
configuring through VPM 100
CPL, using with 101
CPU settings 103
exception pages issued 99
HTTP client compression object 100
HTTP compression level, setting 100
HTTP server compression object 100
multiple content encoding 104
policy-based content transformation not stored
103

server-side bandwidth settings 103
variant served 104
compression, overview 97
CPU
enhancing 103

D
DNS-Proxy
overview 51
resolving name list, explained 51
resource record, creating 53
document
conventions 10
dynamic bypass
configuring 32
connection/receiving errors 33
dynamic_timeout value 32
lists, understanding 31
max_dynamic_bypass_entry parameter 32
server_bypass_threshold parameter 32
troubleshooting 32
dynamic_timeout value, using with dynamic bypass
32

E
early intercept defined 27
exceptions
compression 99
explicit proxy
browser settings 176
creating 176
Internet Explorer, using with 109
overview 175
ProxySG, using as proxy server 176
explicit TCP-Tunnel, explained 163

F
FTP
spoofing 70
FTP clients, configuring 74
FTP proxy
configuring 69, 70
IP address 70
virtual IP address 70

181

Volume 3: Proxies and Proxy Services

H

N

HTTP client compression object, using in VPM 100
HTTP proxy
acceleration profile 88
bandwidth gain 93
bandwidth gain profile 89
byte-range support 94
compression 97
compression behavior 98
compression boundary conditions 103
compression, configuring 100
normal profile 89
portal profile 89
profile settings, configuring 92
profile settings, explained 89
range request types 94
revalidate pragma-no-cache 95
tolerant request parsing 96
traffic, controlling 88
HTTP server compression object, using in VPM 100
HTTPS
origination 117
HTTPS Console
creating 16
enabling 16
IP address, selecting 16
keyring, selecting 15
managing 16
HTTPS traffic, intercepting 140

Native FTP
understanding 69
NTLM
explicit proxy, using with Internet Explorer 109
force authentication
enabling through CPL 110
enabling through VPM 110
Internet Explorer, using with 109

I
Internet Explorer, explicit proxy, using with 109
IP forwarding, enabling through Management
Console 179
issuer certificates, downloading for desktops 144

M
Management Console
configuring SSH 18
HTTP Console 15
HTTPS Console 15
importing SSH client keypairs 19
managing 13, 24
Telnet Console 21
max_dynamic_bypass_entry, using with dynamic
bypass 32
meta tags
parsing 87
multiple listeners, best match 26

182

O
objects
served 105
origination, HTTPS 117

P
PAC file, defined 176
policy
bypass list 31
port services
attributes 27
creating/editing 23
HTTPS Console, creating 16
supported 13
Telnet Console, explained 21
prompt, customizing for Telnet 125
proxies
definition 9
explicit, browser settings 176
explicit, creating 176
interface settings 177
setting up 9
SOCKS, configuring through CLI 132
SOCKS, configuring through Management
Console 131
understanding 175
proxy server, using ProxySG as 176
proxy-services
best-match algorithm 26
proxy-support header
disabling through CPL 110
disabling through VPM 109
Internet Explorer, using with 109

R
range request types 94
realm banner, Telnet, customizing for 125
refresh bandwidth, configuring 95
resolving name list, explained 51

Index

revalidate pragma-no-cache
affects on bandwidth gain 95
configuring 95
routing
bypass list 30
policy-based bypass list 31

S
server_bypass_threshold, using with dynamic
bypass 32
server-side bandwidth, enhancing 103
shell proxies
boundary conditions for 122
policy settings, customizing 121
Telnet 123
understanding 121
SOCKS
compression gain statistics 134
connections, viewing 133
SOCKS clients, viewing 133
statistics 133
SOCKS proxy
bind timeout on accept value 132
configuring through CLI 132
configuring through Management Console 131
connection timeout values 132
max-connection values 132
max-idle-timeout value 132
min-idle-timeout 132
SSH
client, managing 18
configuring 18
importing client keypairs 19
SSL Proxy
unintercepted SSL byte statistics 155
unintercepted SSL client statistics 155
unintercepted SSL data statistics 154
SSL proxy
Add Server Certificate object, using 149
Add SSL Forward Proxy object, configuring 147
categorizing hostnames in server certificates 148
client consent certificates, using 143
configuring rules 147
downloading issuer certificates for desktops 144
explicit mode, configuring 142
HTTPS content, intercepting 147
HTTPS traffic, intercepting 140
Server Certificate Category object, using 148

Set Server Certificate Validation object, using 150
SSL Access layer, using 149
SSL Intercept layer, configuring through CPL 151
SSL Intercept layer, using 147
transparent mode, configuring 140
understanding 137
statistics
active client connections 106
HTTP/FTP bytes served 106
objects served 105
SOCKS clients, viewing 133
unintercepted SSL bytes 155
unintercepted SSL clients 155
unintercepted SSL data 154

T
TCP-Tunnel
commands, explicit 166
explicit 163
overview 163
Telnet
banner settings, configuring through CLI 127
banner settings, configuring through
Management Console 125
boundary conditions for Telnet shell proxy 127
settings customizing 125
shell proxy, creating service 123
shell proxy, understanding 123
Telnet Console
error message 21
port service, explained 21
troubleshooting 21
tolerant request parsing, setting through CLI 96
transparent proxy
hardware, configuring 177
IP forwarding 179
IP forwarding, enabling through CLI 179
Layer-4 switch, using with 178
overview 175
troubleshooting
accept-encoding request header modification 103
cache-control no-transform directive ignored. 104
compression choices 104
explicit proxy and Internet Explorer 109
gzip, deflate formats with compression 104
multiple content encoding 104
policy-based content transformations 103
Telnet Console 21

183

Volume 3: Proxies and Proxy Services

W
Web FTP
troubleshooting 111

184

understanding 69
welcome banner, Telnet, customizing for 125

Document Path: ["139-blue-coat-instruction-sg.pdf"]

e-Highlighter

Click to send permalink to address bar, or right-click to copy permalink.

Un-highlight all Un-highlight selectionu Highlight selectionh