Blue Coat® Systems
ProxySG® Appliance
5.4.x Upgrade/Downgrade Feature Change Reference
Version SGOS 5.4.x
Blue Coat SGOS 5.4.x Upgrade/Downgrade Feature Change Reference
Contact Information
Americas:
Blue Coat Systems Inc.
410 North Mary Ave
Sunnyvale, CA 94085-4121
Rest of the World:
Blue Coat Systems International SARL
3a Route des Arsenaux
1700 Fribourg, Switzerland
http://www.bluecoat.com/support/contactsupport
http://www.bluecoat.com
For concerns or feedback about the documentation:
documentation@bluecoat.com
Copyright© 1999-2011 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™, ProxyOne™, CacheOS™, SGOS™, SG™,
Spyware Interceptor™, Scope™, ProxyRA Connector™, ProxyRA Manager™, Remote Access™ and MACH5™ are trademarks of Blue
Coat Systems, Inc. and CacheFlow®, Blue Coat®, Accelerating The Internet®, ProxySG®, WinProxy®, PacketShaper®, PacketShaper
Xpress®, PolicyCenter®, PacketWise®, AccessNow®, Ositis®, Powering Internet Management®, The Ultimate Internet Sharing
Solution®, Cerberian®, Permeo®, Permeo Technologies, Inc.®, and the Cerberian and Permeo logos are registered trademarks of Blue
Coat Systems, Inc. All other trademarks contained in this document and in the Software are the property of their respective owners.
BLUE COAT SYSTEMS, INC. AND BLUE COAT SYSTEMS INTERNATIONAL SARL (COLLECTIVELY “BLUE COAT”) DISCLAIM 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,
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.
America’s:
Blue Coat Systems, Inc.
410 N. Mary Ave.
Sunnyvale, CA 94085
Document Number: 231-03034
Document Revision: SGOS 5.4.3—07/2011
ii
Rest of the World:
Blue Coat Systems International SARL
3a Route des Arsenaux
1700 Fribourg, Switzerland
Contents
Chapter 1: Before You Start
About the Document Organization.................................................................................................. 7
Related Blue Coat Documentation ................................................................................................... 8
Chapter 2: Deprecation Notices
Deprecation Notices ........................................................................................................................... 9
About CPL Deprecations............................................................................................................. 9
CPL Deprecations in SGOS 5.4 ................................................................................................... 9
Command Deprecation ............................................................................................................... 9
............................................................................................................................................................. 10
Chapter 3: Feature-Specific Upgrade Behavior
Access Logging.................................................................................................................................. 15
ADN .................................................................................................................................................... 17
New System Defaults................................................................................................................. 17
Upgrading Using the Breadth-First Approach ...................................................................... 19
Upgrading Using the Rolling Approach................................................................................. 21
Open ADN and Closed ADN ................................................................................................... 23
Byte Caching ............................................................................................................................... 25
DSCP ............................................................................................................................................ 26
TCP Window Size....................................................................................................................... 26
Archiving/Storage............................................................................................................................ 27
Attack Detection................................................................................................................................ 27
Licensing ............................................................................................................................................ 27
Registering a License ................................................................................................................. 27
User License Limits .................................................................................................................... 28
Networking........................................................................................................................................ 28
CIFS .............................................................................................................................................. 29
Trusted Destination IP............................................................................................................... 30
WCCP........................................................................................................................................... 31
Adapters ...................................................................................................................................... 33
Software Bridging....................................................................................................................... 33
Hardware Bridging .................................................................................................................... 35
Reflect Client IP .......................................................................................................................... 36
Management Services....................................................................................................................... 36
Browser Configuration Instruction Page ................................................................................ 36
New Landing Page..................................................................................................................... 37
iii
Blue Coat SGOS 5.4.x Upgrade/Downgrade Feature Change Reference
SNMP Console............................................................................................................................ 37
Proxy Services ................................................................................................................................... 37
Accessing Proxy Settings .......................................................................................................... 38
Bypass Lists................................................................................................................................. 38
Restricted Intercept .................................................................................................................... 39
New Services............................................................................................................................... 39
Other Services Framework Changes ....................................................................................... 40
Upgrade/Rollback Behavior .................................................................................................... 40
ProxyClient And Client Manager................................................................................................... 43
SSL....................................................................................................................................................... 43
CA Certificate Lists .................................................................................................................... 44
Device Profiles ............................................................................................................................ 44
SSL-Verify Server ....................................................................................................................... 45
SSL Detection .............................................................................................................................. 45
Instant Messaging............................................................................................................................. 45
Streaming Media............................................................................................................................... 46
New Syntax for Caching Objects ............................................................................................. 46
WM-HTTP Streaming Media Proxy ........................................................................................ 46
WM-RTSP Streaming Media Proxy ......................................................................................... 47
Content Filtering ............................................................................................................................... 47
Blue Coat DRTR ......................................................................................................................... 47
SmartFilter Database Selection................................................................................................. 48
Authentication................................................................................................................................... 48
LDAP............................................................................................................................................ 49
Encrypted Passwords ................................................................................................................ 49
Hexadecimal Encoding in Policy Substitution Realm .......................................................... 50
Authorization and Proxy-Authorization HTTP Headers Are Writable ............................ 50
SSH Console................................................................................................................................ 50
Certificate Realms ...................................................................................................................... 51
SiteMinder ................................................................................................................................... 51
User Management ...................................................................................................................... 52
Permitted Errors, Guest Authentication, and Default Groups............................................ 53
Configuration Options .............................................................................................................. 53
New Realms ................................................................................................................................ 54
RADIUS Realms ......................................................................................................................... 55
COREid Authentication ............................................................................................................ 55
IWA Realms ................................................................................................................................ 55
Upgrading the BCAAA Authentication Service.................................................................... 56
BCAAA Upgrade/Downgrade Process.................................................................................. 57
Kerberos Constrained Delegation............................................................................................ 59
iv
Contents
Web Content Scanning (ICAP) ....................................................................................................... 60
Cache-Hit Behavior.................................................................................................................... 60
Cached Objects ........................................................................................................................... 60
Secure ICAP ................................................................................................................................ 62
ICAP Feedback ........................................................................................................................... 63
ICAP Scanning............................................................................................................................ 64
Forwarding and SOCKS Gateways................................................................................................ 65
Health Checks ................................................................................................................................... 66
HTTP Proxy ....................................................................................................................................... 69
Policy/VPM....................................................................................................................................... 69
QoS ............................................................................................................................................... 69
Revocation Checks on Certificates........................................................................................... 70
Content-Type Matching ............................................................................................................ 71
File Extension Objects................................................................................................................ 71
SSL Forward Proxy Object Renamed ...................................................................................... 71
Proxy Forwarding ...................................................................................................................... 72
Authentication ............................................................................................................................ 72
New User Login Address Object ............................................................................................. 72
Statistics.............................................................................................................................................. 73
Upgrade.............................................................................................................................................. 73
Chapter 4: FIPS Upgrade Information
Configuration Files ........................................................................................................................... 75
Signed Archive Configurations ...................................................................................................... 75
DRTR Connections ........................................................................................................................... 76
SSL....................................................................................................................................................... 76
v
Blue Coat SGOS 5.4.x Upgrade/Downgrade Feature Change Reference
vi
Chapter 1: Before You Start
This document describes how upgrading to, or downgrading from, this release
impacts existing features. It also describes important upgrade and downgrade
rules. Blue Coat® strongly recommends that you read this document before
attempting to upgrade to SGOS 5.4 from previous SGOS operating systems.
Before upgrading, you should refer to the following documents:
❐
Blue Coat Upgrade/Downgrade Guide
❐
Blue Coat SGOS 5.4.x Release Notes
These documents are available here:
https://bto.bluecoat.com/documentation/pubs/view/SGOS%205.4.x
Existing features and policies might not perform as with previous versions, and
upgrading to this version might require some additional configuration tuning.
About the Document Organization
This document is organized for easy reference and is divided into the following
sections and chapters:
Table 1–1
Document Organization
Chapter Title
Description
Chapter 1 – Upgrading Overview
This chapter discusses SGOS 5.x upgrades, related
Blue Coat documentation, and documentation
organization and conventions.
Chapter 2 – Upgrade Behavior, General
This chapter discusses general upgrade issues,
including the required upgrade path and licensing.
Chapter 3 – Upgrade Behavior, Specifics
This chapter identifies new behaviors in SGOS 5.x
and discusses any upgrade/downgrade issues.
Chapter 4 – FIPS Upgrade Information
This chapter includes information pertaining to
Federal Information Processing Standards (FIPS)
implementations. It covers upgrade/downgrade
issues related to FIPS mode.
7
Blue Coat SGOS 5.4.x Upgrade/Downgrade Feature Change Reference
Related Blue Coat Documentation
❐
Blue Coat SGOS 5.4.x Upgrade/Downgrade Feature Change Reference
❐
Blue Coat ProxySG QSG
❐
The 11-volume Blue Coat ProxySG Configuration and Management Guide Suite
includes the following documents:
•
Volume 1: Getting Started
•
Volume 2: Proxies and Proxy Services
•
Volume 3: Web Communication Proxies
•
Volume 4: Securing the Blue Coat ProxySG Appliance
•
Volume 5: Advanced Networking
•
Volume 6: The Visual Policy Manager and Advanced Policy
•
Volume 7: Managing Content
•
Volume 8: Access Logging
•
Volume 9: Managing the Blue Coat ProxySG Appliance
•
Volume 10: Content Policy Language Guide
•
Volume 11: Command Line Interface Reference
Document Conventions
The following section lists the typographical and Command Line Interface (CLI)
syntax conventions used in this manual.
Table 1–2 Typographic Conventions
Conventions
Definition
Italics
The first use of a new or Blue Coat-proprietary term.
Courier font
Command-line interface 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
Text that must be entered as shown.
{ }
One of the parameters enclosed within the braces must be supplied.
[ ]
Encompasses one or more optional parameters.
|
This pipe character delineates options in a mandatory or optional list.
For example:
configure {terminal | network url}
8
Chapter 2: Deprecation Notices
This chapter discusses configuration option and CPL deprecations in SGOS
5.4.x.
Topics in this Chapter
This chapter includes information about the following topics:
❐
"Deprecation Notices" on page 9
Deprecation Notices
This section discusses deprecations in SGOS 5.4:
❐
"About CPL Deprecations" on page 9
❐
"CPL Deprecations in SGOS 5.4" on page 9
❐
"Command Deprecation" on page 9
About CPL Deprecations
Deprecation warnings are issued for CPL syntax that will abandoned in the
next major SGOS release.
CPL Deprecations in SGOS 5.4
This section discusses CPL commands that are deprecated in SGOS 5.4.
will not be supported in the next major SGOS release.
❐
icp
❐
socks.allow_compression
and socks_gateway.request_compression
SOCKS compression is deprecated. Refer to Volume 5: Advanced Networking
for instructions on how to configure and use the new Application Delivery
Network features.
❐
Use of ttl(0) is deprecated. Instead, use 'ttl( auto )'
❐
patience_page;
use one of the following:
•
response.icap_feedback.interactive( patience_page[,
•
response.icap_feedback.interactive( no )
❐
force_patience_page has been replaced by
response.icap_feedback.force_interactive
❐
category.dynamic.mode
delay] )
has been replaced by webpulse.categorize.mode
Command Deprecation
show ip-rts table
is no longer available.
9
Blue Coat SGOS 5.4.x Upgrade/Downgrade Feature Change Reference
Note: If the latest release does boot successfully, the ProxySG appliance
might attempt to boot to an earlier image. This can lead to a downgrade
without warning.
10
Chapter 3: Feature-Specific Upgrade Behavior
This chapter provides critical information about how specific features are
affected by upgrading to or downgrading from SGOS 5.4 and provides actions
administrators must or are recommended to take as a result of upgrading. If a
specific feature is not mentioned, there are no known upgrade or downgrade
issues. This chapter assumes you are upgrading to SGOS 5.4 from a supported
direct-upgrade version. SGOS 5.4.x supports direct upgrade from the latest
available releases of SGOS 4.x, 5.2.x, and 5.3.x. At the time of this writing, those
releases are 4.3.x, 5.2.5.x, and 5.3.2.x.
For information about upgrades and downgrades for MACH5 and Proxy
Editions, see the Blue Coat SGOS 5.4.x Upgrade/Downgrade Feature Change
Reference.
The upgrade and downgrade information is organized by component.
Table 3–1
Feature/
Component
Upgrade Impact by SGOS version
See
Upgrade impact for SGOS
Version
4.3.x
5.2.5.x
5.3.2.x
Access Logging
"Access Logging" on page 15
x
x
Application
Delivery
Network (ADN)
"New System Defaults" on
page 17
x
x
x
• "Upgrading Using the
Breadth-First Approach"
on page 19
x
x
x
x
x
x
• "Upgrading Using the
Rolling Approach" on
page 21
"Open ADN and Closed
ADN" on page 23
Archiving/
Storage
"Byte Caching" on page 25
x
"DSCP" on page 26
x
"TCP Window Size" on page
26
x
"Archiving/Storage" on
page 27
x
x
x
11
Blue Coat SGOS 5.4.x Upgrade/Downgrade Feature Change Reference
Feature/
Component
See
Upgrade impact for SGOS
Version
4.3.x
Authentication
Content
Filtering
12
5.2.5.x
5.3.2.x
• "LDAP" on page 49
x
x
x
• "Encrypted Passwords"
on page 49
x
x
x
• "Hexadecimal Encoding
in Policy Substitution
Realm" on page 50
x
x
x
• "Authorization and
Proxy-Authorization
HTTP Headers Are
Writable" on page 50
x
x
x
• "SSH Console" on page 50
x
x
• "Certificate Realms" on
page 51
x
x
• "SiteMinder" on page 51
x
x
• "User Management" on
page 52
x
x
• "Permitted Errors, Guest
Authentication, and
Default Groups" on page
53
x
• "Configuration Options"
on page 53
x
x
• "New Realms" on page 54
x
x
• "RADIUS Realms" on
page 55
x
x
• "COREid Authentication"
on page 55
x
x
• "Upgrading the BCAAA
Authentication Service"
on page 56
x
x
x
• "Kerberos Constrained
Delegation" on page 59
x
x
x
• "Blue Coat DRTR" on
page 47
x
x
x
• "SmartFilter Database
Selection" on page 48
x
x
Chapter 3: Feature-Specific Upgrade Behavior
Feature/
Component
See
Upgrade impact for SGOS
Version
4.3.x
5.2.5.x
5.3.2.x
Forwarding/
SOCKS
Gateways
"Forwarding and SOCKS
Gateways" on page 65
x
x
Health Checks
"Health Checks" on page 66
x
x
HTTP
"HTTP Proxy" on page 69
ICAP
• "Cache-Hit Behavior" on
page 60
x
• "Cached Objects" on page
60
x
• "Secure ICAP" on page 62
x
x
• "ICAP Feedback" on page
63
x
x
• "ICAP Scanning" on page
64
x
x
Instant
Messaging
"Instant Messaging" on page
45
x
x
Licensing/
Upgrading
"Registering a License" on
page 27
x
"User License Limits" on
page 28
x
x
• "Browser Configuration
Instruction Page" on page
36
x
x
x
• "New Landing Page" on
page 37
x
x
x
• "SNMP Console" on page
37
x
x
• "CIFS" on page 29
x
x
Management
Services
Networking
Downgrade Impact
x
x
13
Blue Coat SGOS 5.4.x Upgrade/Downgrade Feature Change Reference
Feature/
Component
See
Upgrade impact for SGOS
Version
4.3.x
Policy
5.2.5.x
• "Trusted Destination IP"
on page 30
x
x
• "WCCP" on page 31
x
x
x
• "WCCP and Packet
Forwarding and Packet
Return" on page 31
x
x
x
• "Adapters" on page 33
x
x
• "Software Bridging" on
page 33
x
• "Hardware Bridging" on
page 35
x
x
• "Reflect Client IP" on
page 36
x
x
• "QoS" on page 69
x
x
• "Revocation Checks on
Certificates" on page 70
x
x
• "Content-Type Matching"
on page 71
x
x
• "File Extension Objects"
on page 71
x
x
• "SSL Forward Proxy
Object Renamed" on page
71
x
x
• "Proxy Forwarding" on
page 72
ProxyClient
14
5.3.2.x
x
x
• "Authentication" on page
72
x
x
• "New User Login
Address Object" on page
72
x
x
"ProxyClient And Client
Manager" on page 43
x
x
Chapter 3: Feature-Specific Upgrade Behavior
Feature/
Component
See
Upgrade impact for SGOS
Version
4.3.x
Proxy Services
5.2.5.x
5.3.2.x
• "Accessing Proxy
Settings" on page 38
x
• "Bypass Lists" on page 38
x
• "Restricted Intercept" on
page 39
x
• "New Services" on page
39
x
x
x
• "Other Services
Framework Changes" on
page 40
x
x
x
• "CA Certificate Lists" on
page 44
x
x
• "Device Profiles" on page
44
x
x
• "SSL-Verify Server" on
page 45
x
x
• "SSL Detection" on page
45
x
x
Statistics
"Statistics" on page 73
x
Streaming
Media
• "New Syntax for Caching
Objects" on page 46
x
x
• "WM-HTTP Streaming
Media Proxy" on page 46
x
x
• "WM-RTSP Streaming
Media Proxy" on page 47
x
x
SSL
Access Logging
Impact: 5.4.3.2, 5.4.3.3 Upgrades
This change impacts LDAPv2 users. In SGOS5.4.3.3 and later, the cs-username
field of the access log reports firstname%20lastname, instead of
firstname.lastname as in pervious releases.
To revert to the prior behavior (firstname.lastname), enter the following CLI
command:
#(config) security legacy-relative-usernames enable
Impact: 4.3.x, 5.2.x Upgrades
15
Blue Coat SGOS 5.4.x Upgrade/Downgrade Feature Change Reference
In SGOS 5.2.2, a new field has been added to the default streaming log format:
s-session-id. This field can be used to identify playspurts from the same client
session and is supported for all streaming protocols:
16
❐
Windows Media over RTSP
❐
Real Media over RTSP
❐
QuickTime over RTSP
Chapter 3: Feature-Specific Upgrade Behavior
❐
MMS
❐
HTTP
Upon upgrade, the default streaming log format changes to the new log format. If
you have modified the default streaming log format prior to upgrade, those
changes will be preserved.
Related Documentation
Volume 8: Access Logging
ADN
Impact: 5.2.x and 5.3.x Upgrades
The Application Delivery Network (ADN) is aimed at enhancing the experience
of users in WAN environments. Blue Coat offers two approaches to upgrading
and securing your network and if you have SGOS 5.1.3.3 or later, both approaches
allow you to keep the network in operation during the upgrade.
Note: If you are configuring a new ADN installation, you do not need to
worry about keeping a network in operation and secure; no live traffic is
going through the ADN nodes. You can choose either approach discussed
below or you can create your own custom approach.
❐
Breadth-first: This is the operation-centric approach, where each operation is
done on each ADN node before the next operation is started. For more
information, see "Upgrading Using the Breadth-First Approach" on page 19.
❐
Rolling: This is the device-centric configuration, where a set of operations is
done to a specific device before you move to the next device. The rolling
approach works best when there's a clear separation of roles; for example, you
have dedicated managers, concentrators, and branches. You don't have ADN
nodes that function as both managers and concentrators. The recommended
upgrade order for the rolling approach is to upgrade the ADN managers first,
then the concentrators, and the branches last. This method allows a staged
deployment. For more information, see "Upgrading Using the Rolling
Approach" on page 21.
New System Defaults
Impact: All Upgrades
If you upgraded from SGOS 5.1.4 or earlier—where secure ADN was not
supported—you must manually enable secure ADN post-upgrade.
The backwards-compatible ADN manager runs on the existing plain ADN
manager port. This manager can handle ADN nodes running SGOS 5.4.x, SGOS
5.3.x, SGOS 5.2.x, SGOS 5.1.4, and SGOS 5.1.3.
SGOS 5.4 introduces the Open ADN feature. After you upgrade, your existing
settings will be in Closed ADN mode. For more information, see"Open ADN and
Closed ADN" on page 23.
17
Blue Coat SGOS 5.4.x Upgrade/Downgrade Feature Change Reference
❐
Security settings:
•
Authentication and authorization are disabled until a valid profile is
selected.
•
ADN routing and tunnel connection requests are unauthenticated.
•
All ADN protocol messaging and compressed application data are
transferred in plaintext.
•
SSL Device Profile: None.
The device profile must be configured on the ADN managers before any
outbound connections can be set to a secure mode on any ADN node.
The profile also must be configured on all concentrators before securing
any outbound tunnel connections.
•
Authorization: Disabled.
Authorization can be enabled only if Validate ADN Peer IDs is enabled in the
selected device profile (Configuration > ADN > General > Device Security).
•
Manager Listening Mode: Plain-Only.
The Manager Listening Mode on the ADN managers can be set to Secureif all ADN nodes secure their routing connections.
only
•
Tunnel listening mode: Plain-Only.
Tunnel listening mode on a concentrator can be set to Secure-only if all
branches connect to the concentrator through secure connections.
•
❐
Manager settings:
•
18
Secure-outbound: None.
Pending-peers: Enabled
Chapter 3: Feature-Specific Upgrade Behavior
Upgrading Using the Breadth-First Approach
If you upgrade from SGOS 4.3.x, the settings are as described above. From an
ADN perspective, SGOS 4.3.x upgrades are treated as a new installation.
The breadth-first approach requires that you do certain operations on each node
before moving to the next node.
Note: When upgrading to SGOS 5.4.x, backward compatibility is guaranteed
only for devices running SGOS 5.2.x. Downgrading to SGOS 5.1.x is not
supported.
The overview for configuration is as follows:
1. Upgrade all ADN nodes to the latest SGOS release, including the latest patch
version.
2. On each ADN node, configure the device authentication profile.
Security parameters switch to authentication defaults after the device is
configured with the device authentication profile:
a. Device-auth-profile: Set to the desired profile.
b. Authorization: Enabled
c. Manager-listening-mode: Both.
d. Tunnel-listening-mode: Both.
e. Secure-outbound: Secure-Proxies.
Note: If you are upgrading a network with live ADN traffic, reset secureoutbound to None to avoid potential ADN service outages. Otherwise,
continue with the procedures below.
For more information, refer to “Device Authentication” and “Configuring an
Application Delivery Network” in Volume 5: Advanced Networking.
3. Pre-configure the approved-peers list on each ADN manager if you use a
Closed ADN network.
If a backup manager exists, the backup manager should be added to the
approved-peers list on the ADN manager; in that case, the ADN manager
should be added to the approved-peers list on the backup manager.
19
Blue Coat SGOS 5.4.x Upgrade/Downgrade Feature Change Reference
4. Enable outbound security on each ADN node:
a. Secure-outbound: This setting can be configured to Routing-only, Secureproxies, or All.
When routing connection security is enabled, each node reconnects to the
ADN managers using the secure protocol.
•
If the secure-outbound option is set to Secure-proxies, all future
outbound secure-proxy connections are secured.
•
If Secure-outbound is set to All, all future outbound connections are
secured. Existing non-secure-proxy connections are upgraded to
secure mode automatically. This is the most secure mode, allowing all
ADN plain listeners to be disabled.
Configure secure-outbound to at least Routing-only. If the routing managers
are also branch nodes, configure secure-outbound to Secure-proxies or All.
5. Tighten up security by shutting down any unneeded plain (unsecured)
listeners on each node:
a. Manager-listening-mode: Configure this setting to Secure-only on each
ADN manager.
This setting can be selected only if the secure-outbound option is anything
other than None on the ADN nodes. Note that you cannot select this option
if you have ProxyClients on the network.
b. Tunnel-listening-mode: configure tunnel listening mode to Secure-only
on each node.
Tunnel listening mode can be set to Secure-only on each node if no other
ADN branches or ProxyClients attempt to connect to this concentrator
through plain (unsecured) tunnel connections.
For more information, refer to “Configuring an Application Delivery
Network” in Volume 6: VPM and Advanced Policy Tasks.
20
Chapter 3: Feature-Specific Upgrade Behavior
Upgrading Using the Rolling Approach
If you upgrade from SGOS 4.3.x, the settings are as described in the previous
section. From an ADN perspective, SGOS 4.3.x upgrades are treated as a new
installation.
The rolling approach requires that you complete all pertinent operations on each
node before configuring the next node.
Note: When upgrading to SGOS 5.3.x, backward compatibility is guaranteed
only for devices running SGOS 5.2.x. Downgrading to SGOS 5.1.x is not
supported.
ADN Manager Upgrade
Complete each step below for the ADN manager and backup ADN manager:
1. Upgrade the appliances to the latest release of SGOS, including the most
recent patch version.
2. Configure the device authentication profile.
Security parameters switch to authentication defaults after the device is
configured with the device authentication profile:
•
Device-auth-profile: Set to the desired profile.
•
Authorization: Enabled.
•
Manager-listening-mode: Both.
•
Tunnel-listening-mode: Both.
•
Secure-outbound: Secure-Proxies.
Note: If you are upgrading a network with live ADN traffic, reset secureoutbound to None to avoid potential ADN service outages.
For more information, refer to “Device Authentication” and “Configuring an
Application Delivery Network” in Volume 4: Securing the Blue Coat ProxySG
Appliance.
3. Configure the Manager-listening-mode to Secure-only.
Note: Do not do this step until all nodes have been upgraded and the
secure-outbound option has been set to secure routing connections. If you
attempt to do this step before configuring all other nodes, the nodes fail to
connect to the secure manager port.
21
Blue Coat SGOS 5.4.x Upgrade/Downgrade Feature Change Reference
This setting can be selected only if the secure-outbound option is anything
other than None on the ADN nodes. Note that you cannot select this option if
you have ProxyClients on the network.
4. Configure the approved-peers list, if authorization is enabled, to avoid
potential temporary ADN service outage on a node.
For more information, refer to “Configuring an Application Delivery Network” in
Volume 6: The Visual Policy Manager and Advanced Policy.
ADN Node Upgrade
Avoid making changes to ADN configuration on any ADN nodes until both
managers have been upgraded and configured.
Note: The recommended approach to upgrading the ADN nodes is to
configure all concentrators first, followed by the branch appliances.
The overview for upgrading one ADN node is as follows:
1. Upgrade the appliance to the latest version of SGOS, including all patch
releases.
2. Bring up the ADN node and complete basic ADN configuration. For more
information, refer to Volume 5: Advanced Networking.
3. Configure the device authentication profile.
Security parameters switch to authentication defaults after the device is
configured with the device authentication profile:
•
Device-auth-profile: Set to the desired profile.
•
Authorization: Enabled.
•
Manager-listening-mode: Both.
•
Tunnel-listening-mode: Both.
•
Secure-outbound: Secure-Proxies.
Note: If you are upgrading a network with live ADN traffic, reset secureoutbound to None to avoid potential ADN service outages.
For more information, refer to Volume 4: Securing the Blue Coat ProxySG
Appliance.
22
Chapter 3: Feature-Specific Upgrade Behavior
Enabling the Secure-Outbound Security Option
This setting can be configured to Routing-only, Secure-proxies, or All.
❐
When routing connection security is enabled, each node reconnects to the
ADN managers using the secure protocol.
❐
If the secure-outbound option is set to Secure-proxies, all future outbound
secure-proxy connections are secured.
❐
If Secure-outbound is set to All, all future outbound connections are secured.
Existing non-secure-proxy connections are upgraded to secure mode
automatically. This is the most secure mode, allowing all ADN plain listeners
to be disabled.
Setting Tunnel Listening Mode to Secure-Only
The tunnel listening mode can be set to secure-only if no other ADN branches or
ProxyClients attempt to connect to this concentrator through plain (unsecured)
tunnel connections.
For more information, refer to “Configuring an Application Delivery Network” in
Volume 5: Advanced Networking.
Open ADN and Closed ADN
Impact: 5.2.x and 5.3.x Upgrades
After upgrading to SGOS 5.4, the ADN manager and backup manager, if any,
have new configuration options that enable you to configure new types of ADN
networks referred to as Open ADN and Closed ADN. A brief description follows:
❐
Open — An ADN peer is allowed to form a tunnel connection with any other
ADN peer. Open ADN works with transparent tunnels only.
Open ADN is further divided into managed and unmanaged, as follows:
❐
•
Open, managed ADN is an ADN in which there is a primary ADN manager
and optionally a backup ADN manager.
•
Open, unmanaged ADN is an ADN in which there is no ADN manager
Closed — (Consistent with earlier versions of SGOS.) ADN nodes can
establish accelerated tunnel connections only with peers in its ADN. In this
configuration, you must configure a Primary ADN manager and, optionally, a
Backup ADN Manger to manage ADN membership. The ADN manager(s)
can be ADN nodes or they can be dedicated ProxySG appliances. In a closed
ADN every ADN peer must connect to the ADN manager(s) in order to
become part of the ADN.
23
Blue Coat SGOS 5.4.x Upgrade/Downgrade Feature Change Reference
Following is a brief discussion of how to locate these options on your ADN
managers:
1. Log in to the primary ADN manager or backup ADN manager’s Management
Console as an administrator.
2. Click Configuration > ADN > General.
Notice that in the Primary ADN Manager and Backup ADN Manager
sections, you now have the option to select None. Selecting None for primary
and backup ADN networks enables an Open, unmanaged ADN network.
Note there are many deployments—including ProxyClient deployments and
any deployment that requires explicit tunnels—that cannot be used in an
Open, unmanaged, ADN network.
3. Click Configuration > ADN > Manager.
Notice the check box Allow transparent connections only within this managed
network. This option—which is available only on the primary and backup
ADN manager—determines whether or not the ADN network is Open or
Closed, as follows:
•
Selecting the check box means you are configuring a Closed ADN
network.
•
Clearing the check box means you are configuring an Open, managed
ADN network.
Information for Upgrading From Any SGOS Version
Because all SGOS versions after 5.1.1 support an ADN manager and backup
manager, after you upgrade, these settings are preserved and you have a
managed ADN network (upon upgrade).
Note: If you upgrade an unconfigured ProxySG to SGOS 5.4—in particular, if its
ADN managers are unconfigured—after upgrading, they default to None. All
network traffic bypasses ADN on this ProxySG in this case. To avoid this
situation, make sure you configure a primary ADN manager and, optionally, a
backup ADN manager on every peer before you upgrade it.
Information for Upgrading from SGOS 4.3.x
Because SGOS 5.1.3 and earlier (including all SGOS 4.x releases) do not support
secure ADN, the configuration options related to authenticated peers do not exist.
After upgrading, these peers cannot be part of a secure ADN network until you
upgrade them to SGOS 5.1.4 or later. You can then configure them as part of a
Closed ADN network if you wish.
24
Chapter 3: Feature-Specific Upgrade Behavior
Downgrading an ADN Network
To downgrade your network, reverse the steps you did to upgrade. Note that any
attempt to enable tunnel security on a down-versioned branch fails and the
connection is closed.
Policy
❐
To support Application Delivery Networks (ADN):
adn.server.optimize(yes|no|byte_cache|compress)
adn.server.optimize[optimization-settings](yes|no)
adn.server.optimize.inbound(yes|no|byte_cache|compress)
adn.server.optimize.inbound[optimization-settings](yes|no)
adn.server.optimize.outbound(yes|no|byte_cache|compress)
adn.server.optimize.outbound[optimization-settings](yes|no)
adn.connection.dscp(dscp_value)
The following CPL syntax is being deprecated in favor of the ADN tunnel
properties:
socks.allow_compression(yes|no)
socks_gateway.request_compression(yes|no|default)
You can use the deprecated syntax, but you will receive a warning.
Note: If you use SOCKS compression, convert the configuration from
SOCKS to ADN. At this point the improved compression and much more
flexible ADN policy becomes available.
Related Documentation
For more information about configuring ADN networks, see Chapter 2,
Configuring an Application Delivery Network, in Volume 5: Advanced Networking.
Byte Caching
Impact: 5.2.x Upgrades
Starting with SGOS 5.3, the byte cache is not cleared when the software or
hardware is reset; it has a persistent byte cache.
Blue Coat recommends that before downgrading to SGOS 5.2.x, you should clear
the byte cache with the clear-cache byte-cache CLI command. If you do not
clear the byte cache, this, the persistent byte cache will be preserved after
downgrading.
Because 5.3 and later do not support the byte cache protocol used in earlier SGOS
versions, ProxySG devices running 5.3 or later that connect to ProxySGs running
5.2 or 5.1 will be limited to gzip compression only.
Related Documentation
Volume 5: Advanced Networking
25
Blue Coat SGOS 5.4.x Upgrade/Downgrade Feature Change Reference
DSCP
Impact: 5.2.x and 5.3.x Upgrades
On a new or upgraded system, the Differentiated Services Code Point (DSCP)
values that network devices use to identify traffic to be handled with higher or
lower priority, is not changed.
On an ADN network, per-hop behavior for an ADN packet cannot be set
separately. However, DSCP behavior changes when both the branch and data
center nodes are upgraded; the adn.connection.dscp property then takes effect
and controls the DSCP value sent and received in the ADN tunnel. When both the
branch and data center nodes are upgraded, the server.connection.dscp setting
(which is set on the branch) is enforced on the data center node.
The values for adn.connection.dscp and server.connection.dscp are
configurable.
Downgrade Behavior
The adn.connection.dscp property is ignored.
Related Documentation
Volume 6: The Visual Policy Manager and Advanced Policy
Volume 10: Content Policy Language Guide
TCP Window Size
Impact: 5.2.x Upgrades
SGOS 5.3 and later offer a new option for ADN Tunnel TCP Window Size:
Automatically adjusted. The ADN window size is adjusted in the Configuration > ADN
> Tunneling > Network tab.
The existing ADN window size setting is preserved upon upgrading to 5.3 or
later, as follows:
❐
If the window size was set to the default value (64K) in a pre-5.3 version, the
Automatically adjusted setting will be selected after upgrading to 5.3 or later.
❐
If the window size was manually set to a different value in a pre-5.3 version,
this value will be entered into the Manual override field.
Related Documentation
❐
26
Volume 5: Advanced Networking
Chapter 3: Feature-Specific Upgrade Behavior
Archiving/Storage
Impact: 4.3.x, 5.2.x Upgrades
Starting with SGOS 5.3, you can create a signed archive. A signed archive is one
that is cryptographically signed with a key known only to the signing entity—the
digital signature guarantees the integrity of the content and the identity of the
originating device. You can then use a trusted CA Certificate List (CCL) to verify
the authenticity of the archive.
On an upgrade to SGOS 5.3 or later, new archive configuration options will be
available, but will be disabled by default. These options are available in the
Configuration > General > Archive tab.
When downgrading to a pre-5.3 version, the signed archive configuration will be
disabled, and the system will default to the original archive format. If a protocol
other than TFTP or FTP was configured for archiving the configuration, the
protocol will default to FTP. Signed configurations cannot be directly loaded by
the downgraded system. However, it would be possible to extract the
configuration.txt file from the signed archive and attempt to load that
configuration.
Related Documentation
Volume 1: Getting Started
Attack Detection
After upgrading to SGOS 5.x from 4.x, the Attack Detection connection limit
counts connections in all TCP states. In SGOS 4.x, the Attack Detection connection
limit only counts established connections. In SGOS 5.x connections in all TCP
states are counted. After upgrading, clients that used to work fine might now hit
the Attack Detection connection limit. Therefore, before upgrading plan for the
correct Attack Detection connection limit.
Licensing
Registering a License
Impact: 4.3.x Upgrades
The licensing register-hardware command and the License Warning tab attempt to
request the software license as well as the hardware license after successful
hardware registration.
Similarly, the licensing request-key and corresponding Maintenance > Licensing >
Install > Request key attempt to register the hardware before requesting the license
key if the hardware has not already been registered.
27
Blue Coat SGOS 5.4.x Upgrade/Downgrade Feature Change Reference
User License Limits
Impact: 4.3.x Upgrades
Starting with SGOS 5.2.x, the number of users is enforced through model
licensing. If you have more connections than your license permits, you can
determine the overflow behavior. Connections beyond the limits can be bypassed,
queued (waiting for a connection to drop off), or the licensed-user limit can be
ignored. The default value is none.
Downgrade Behavior
On a downgrade to a version earlier than SGOS 5.2.x, the licensed-user limit
overflow option is not available.
Related Documentation
Volume 2: Proxies and Proxy Services
Networking
Refer to the following sections for upgrade/downgrade issues related to items on
the Configuration > Network page:
28
❐
"CIFS" on page 29
❐
"Trusted Destination IP" on page 30
❐
"WCCP" on page 31
❐
"Adapters" on page 33
❐
"Software Bridging" on page 33
❐
"Hardware Bridging" on page 35
Chapter 3: Feature-Specific Upgrade Behavior
CIFS
This section discusses the new the CIFS proxy and its enhancements.
❐
"Introducing the CIFS Proxy"
❐
"Overlapping Opens"
❐
"Browsing Performance"
Introducing the CIFS Proxy
Impact: All 4.x Upgrades
The CIFS proxy enables the ProxySG to improve performance, reduce bandwidth,
and apply basic policy checks to clients using the CIFS protocol. 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.
Systems that are upgraded from versions of SGOS that do not have a CIFS proxy
behave the same as new systems in that they receive a default set of CIFS services
and settings. Existing services listening on the default CIFS TCP ports are not
overwritten.
Downgrading to SGOS 4.x has no effect on the box, except that the CIFS proxy is
not available. The next time the upgrade is done, the settings from the previous
upgrade still exist.
Related Documentation
Volume 2: Proxies and Proxy Services
Overlapping Opens
Impact: All Upgrades
For applications such as Microsoft Word and Microsoft Excel, the ProxySG now
improves access times when these applications open the same file multiple times,
even if the end user opens the file only once (a type of file contention referred to
as "overlapping opens").
Browsing Performance
Impact: All Upgrades
Two new CIFS proxy options improve the user's experience when browsing
remote folders in Windows Explorer:
❐
Remote Storage Optimization: Enabled by default. When enabled, Windows
Explorer modifies the icons of uncached folders on remote servers, indicating
to users that the contents of the folder have not yet been cached by the Proxy
SG. See Figure 3–1.
29
Blue Coat SGOS 5.4.x Upgrade/Downgrade Feature Change Reference
Uncached
Data
Cached Data
(no icon)
Figure 3–1
❐
CIFS Remote Storage Optimization Explorer Icon
Suppress Folder Customization: Disabled by default. When a remote folder is
customized (for example, the style of icon and the display of folder contents as
icons or thumbnails), Windows Explorer checks for desktop.ini file inside the
folder to determine how to display its contents. On slow links, however, the
extra transactions required by this check result in sluggish performance. To
speed the display of remote folders, enable Suppress Folder Customization to
skip the extra transactions and always display remote folders in the default
view.
Trusted Destination IP
Impact: 4.3.x Upgrades
If, in your environment, a client can provide a destination IP address that the
ProxySG appliance cannot determine or if the ProxySG determines an incorrect IP
address, you can tell the ProxySG appliance to trust the client-provided IP
address and not perform a DNS lookup. This can improve performance (but
potentially cause a security concern). This setting can be configured in the
Configuration > Proxy Settings > General tab.
Downgrade Behavior
On a downgrade to versions earlier than SGOS 5.2.x, the trusted destination IP
address option is not available.
Related Documentation
Volume 2: Proxies and Proxy Services
30
Chapter 3: Feature-Specific Upgrade Behavior
WCCP
This section discusses the following topics:
❐
❐
❐
"WCCP and Interface Configuration" on page 31
"WCCP and Service Passwords" on page 31
"WCCP and Packet Forwarding and Packet Return" on page 31
WCCP and Interface Configuration
Impact: Downgrades from 5.4
There are no upgrade issues for this feature.
If you downgrade to an SGOS version earlier than 5.4, there are no issues if the
WCCP configuration has defined its interfaces with physical interfaces in the
form:
Interface adapter:interface
For example, Interface 0:0
However, there are downgrade issues if you defined VLAN interfaces in the form:
Interface adapter:interface.vlan_id
If you configure WCCP with virtual interfaces, after downgrading, WCCP is
disabled due to errors in parsing the WCCP configuration.
All references to VLAN interfaces will need to be removed from the WCCP
configuration and it will need to be reinstalled. This will interrupt WCCP
functionality but if the WCCP configuration is moving from a VLAN deployment
to a non-VLAN deployment, there is no guarantee that the WCCP router is
configured to support the non-VLAN deployment.
In most cases, reconfiguration will be required on the WCCP router after
downgrading.
WCCP and Service Passwords
Impact: Downgrades from 5.4
There are no upgrade issues for this feature.
In SGOS 5.4 and later, WCCP service passwords are encrypted. If you configure a
WCCP service in SGOS 5.4 or later and downgrade to SGOS 5.3 or earlier, the
WCCP service is invalid because the password is encrypted.
To avoid this issue, remove the WCCP service password before you downgrade.
WCCP and Packet Forwarding and Packet Return
Impact: All Upgrades
SGOS 5.4 and later enable you to configure WCCP options using the Management
Console: Configuration > Network > WCCP. On-line help is available to assist you
with WCCP configuration options.
31
Blue Coat SGOS 5.4.x Upgrade/Downgrade Feature Change Reference
In addition, SGOS 5.4 and later support the following combinations of packet
forwarding and return options:
Packet forwarding
Packet return
GRE
GRE
L2
GRE
L2
L2
Note: SGOS versions before 5.4 only. If L2 redirection was used in earlier SGOS
releases to forward packets from the router to the ProxySG, the ProxySG did
not always treat those packets as arriving by WCCP, so static and dynamic
bypass never attempted to use WCCP packet return. In those configurations,
IP Forwarding had to be enabled so packets were properly returned to the
router. Otherwise, the traffic was dropped.
In SGOS 5.4 and later, this is no longer the case. WCCP packet return is always
used to return bypassed traffic received by WCCP, and so it is not necessary to
enable IP Forwarding.
To view your choices in the SGOS 5.4 or later Management Console, click
Configuration > Network > WCCP, select the Enable WCCP check box, and click New.
In the New Service dialog, notice that if you select GRE for Forwarding Type, the
Returning Type is assumed to be GRE also. However, if you choose L2 for
Forwarding Type, you can choose either L2 or GRE for Returning Type.
Downgrade Behavior
Downgrades: After upgrading from an earlier SGOS version to SGOS 5.4, you
have the option of choosing L2 packet forwarding and GRE packet return. This
combination should resolve issues related to certain routers that did not support
L2 packet return.
The combination of L2 packet forwarding and GRE packet return is not supported
in SGOS versions earlier than 5.4; in addition, the returning-type command used
in the inline command that configures the ProxySG on downgrade is also not
supported. Both cases result in an invalid WCCP configuration after
downgrading.
To avoid problems, do any of the following:
32
❐
If you configured WCCP in the Management Console, before downgrading,
set Forwarding Type and Returning Type to the same value. This causes the
returning-type command to be omitted from the inline command and
enables you to use the downgraded WCCP configuration.
❐
If you configured WCCP settings using the CLI, remove the returning-type
commands from the inline command; otherwise, after downgrading, your
WCCP configuration will not be accepted because returning-type is not
supported in SGOS versions earlier than 5.4.
Chapter 3: Feature-Specific Upgrade Behavior
Adapters
Impact: 4.3.x, 5.2.x Upgrades
Any IP addresses assigned to network interfaces or VLANs while in SGOS 5.3 or
later will be lost upon downgrading to earlier versions. This is not an issue when
upgrading.
Software Bridging
Impact: 4.3.x Upgrades
Changes to bridging in SGOS 5.4 or later include:
❐
Bridges are not configured during initial configuration of the system.
❐
A bridge is now considered to be a set of assigned interfaces and does not
have an IP address. All interface configuration is done using the #(config)
interface command.
❐
Interfaces are no longer identified by ports.
❐
Interface configuration is no longer done in the bridge editing submode.
Upgrade Behavior
The bridge-related settings have been migrated from previous SGOS releases to
SGOS 5.4 or later. The behavior changes include:
❐
IP address, subnet: These have been moved to the lowest numbered interface
attached to the bridge.
❐
mtu-size: On upgrade, mtu-size from an SGOS 4.3.x bridge is reflected to all
the interfaces that belong to the bridge on SGOS 5.1.3 or later.
❐
accept-inbound. On upgrade, accept inbound settings from an SGOS 4.3.x
bridge are reflected to all the interfaces that belong to the bridge on SGOS
5.1.3 or later. In SGOS 5.x, it has been renamed reject-inbound.
❐
speed: Speed is upgraded for both software and hardware bridges. For
hardware bridges, the speed from the first port of a hardware bridge on SGOS
4.3.x is copied onto both interfaces belonging to the hardware bridge on SGOS
5.1.3 or later for a software bridge, speed is copied over from each port of a
software bridge on SGOS 4.3.x to the corresponding interface of the software
bridge on SGOS 5.1.3 or later.
❐
half-duplex/full-duplex: Duplex (half-duplex/full-duplex) is upgraded for
both software and hardware bridges.For hardware bridges, the duplex from
the first port of a hardware bridge on SGOS 4.3.x is copied onto both interfaces
belonging to the hardware bridge on SGOS 5.1.3. For a software bridge,
duplex is copied over from each port of a software bridge on SGOS 4.3.x to the
corresponding interface of the software bridge on SGOS 5.1.3 or later.
33
Blue Coat SGOS 5.4.x Upgrade/Downgrade Feature Change Reference
❐
link-autosense: Link-autosense is upgraded for both software and hardware
bridges. For hardware bridges, the link-autosense, if set on the first port of a
hardware bridge on SGOS 4.3.x, is reflected onto both interfaces belonging to
the hardware bridge on SGOS 5.1.3 or later. For software bridges, linkautosense, if set for a particular port of a software bridge on SGOS 4.3.x, is
reflected to the corresponding interface of the software bridge on SGOS 5.1.3
or later.
❐
static-fwtable-entry: Static forwarding entries are migrated from each of the
individual ports on SGOS 4.3.x to the corresponding interfaces on SGOS 5.1.3
or later.
❐
instructions (PAC Files): For hardware bridges, instructions from an SGOS
4.3.x bridge are automatically upgraded onto the first interface of the
hardware bridge in SGOS 5.1.3. For software bridges, instructions from an
SGOS 4.3.x bridge are upgraded onto an interface with an IP address that
belongs to that bridge in SGOS 5.1.3 or later.
If a software bridge was created in SGOS 4.2, that software bridge remains after
an upgrade; the interfaces are attached to this software bridge on a best-effort
basis. For example, if the bridge configuration is:
bridge "bg0"
❐
interface 0:0
❐
interface 3:0
0:0 is not part of a hardware bridge, while 3:0 is part of a hardware bridge
In this case, 3:0 is reassigned to the hardware bridge, and bridge "bg0" is left with
one interface. If both interfaces are part of a hardware bridge, software bridge bg0
remains with no interface assigned to it.
34
Chapter 3: Feature-Specific Upgrade Behavior
Downgrade Behavior
❐
For downgrades to SGOS 4.3.x, previously existing SGOS 4.3.x settings are
preserved; if the system was a new SGOS 5.x installation before the
downgrade, the defaults are used.
❐
For downgrades to SGOS 5.2/5.3 settings are preserved, except for the
programmable bridge functionality described in "Hardware Bridging" below.
Related Documentation
❐
Volume 1: Getting Started
Hardware Bridging
Impact: All Upgrades
Blue Coat offers two types of programmable bridge cards, some sold as hardware
bridges others as regular Network Interface Cards (NICs).
For SGOS 4.2.3 or later and SGOS 5.x upgrades, software bridges can be lost if
they were created on a programmable card prior to upgrade.
Cards that were sold as bridges remain hardware bridges on upgrade and are
configured to fail open. Cards that were sold as NICs might have had software
bridges configured; if so, that configuration is lost on an upgrade.
You can recreate software bridges by either setting one of the pre-configured
bridges to fail open or fail closed or by creating a software bridge and attaching
the interfaces. Note that you must disable the automatically created hardware
bridge before creating the software bridge.
Downgrade Behavior
Downgrade behavior depends upon the type of programmable card you
originally purchased. Regardless of configuration, the card returns to its original
sold-as configuration (either a bridge or a NIC).
Related Documentation
❐
The option card instructions that shipped with your option card.
35
Blue Coat SGOS 5.4.x Upgrade/Downgrade Feature Change Reference
Reflect Client IP
Impact: 4.3.x, 5.2.x Upgrades
After upgrading to 5.3 or later, the reflect client IP system setting will be disabled
unless all of the proxy services have enabled the Reflect Client IP setting. This
setting can be enabled in the Configuration > Proxy Settings > General tab.
Upon upgrading to 5.3 or later, policy will be created for the services that have
client IP reflection enabled. For example, if the HTTP and FTP proxies have client
IP reflection enabled, the following policy is created:
define condition __ReflectClientIPUpgrade
service.name="HTTP"
service.name="FTP"
end condition __ReflectClientIPUpgrade
<Proxy>
condition= __ReflectClientIPUpgrade
reflect_ip(client)
; Rule 1
Management Services
The ProxySG ships with management services (consoles) that are designed to
manage communication with the ProxySG.
This section discusses the following topics:
❐
❐
❐
"Browser Configuration Instruction Page" on page 36
"New Landing Page" on page 37
"SNMP Console" on page 37
Browser Configuration Instruction Page
Impact: All Upgrades
After upgrading to SGOS 5.4, the Browser Configuration page (which provided
instructions on how to configure clients to explicitly proxy traffic to the ProxySG)
is no longer available. To configure an explicit proxy, you must perform one of the
following tasks:
❐
Manually configure each user’s browser to use the ProxySG’s IP address in
the proxy server configuration.
If you choose this option, you can skip the remainder of this section.
❐
Use a Proxy Auto-Configuration (PAC) file to allow access to the Management
Console.
Two PAC files ship with the ProxySG:
•
Default PAC file: http[s]://sg_host-name-or-ip:8082/proxy_pac_file
•
Accelerated PAC file: http[s]://sg_host-name-or-ip:8082/
accelerated_pac_base.pac
Only the accelerated_pac_base.pac file can be edited. Any text editor can be
used to edit and customize the accelerated PAC file to meet your needs. After
editing the file, you can load a PAC file only using the inline-acceleratedpac CLI command.
36
Chapter 3: Feature-Specific Upgrade Behavior
Deprecated CLI command:
SGOS#(config interface interface_number) instructions {accelerated-pac |
default-pac | proxy}
New Landing Page
Impact: All Upgrades
When you first log in to the Management Console, a new page Statistics > Summary
displays. The Summary page visually demonstrates the overall performance and
efficiency of your network; it displays the role of the ProxySG in boosting the
performance of traffic within your network using its acceleration, optimization,
policy control, and caching techniques.
This page, designed for SGOS 5.4, is discussed in more detail in the on-line help
provided with it.
If you roll back from SGOS 5.4 to an earlier version, this page does not display; the
system defaults to the previous landing page.
SNMP Console
Impact: 4.3.x, 5.2.x Upgrades
SGOS 5.3 offers a console service for SNMP in the Configuration > Services >
Management Services tab. When upgrading a default SNMP service will be created
in the services framework, with a listener on the standard SNMP port (161). If
SNMP was enabled at the time of upgrade, the listener will be enabled.
When downgrading to a pre-5.3 version, the ProxySG will revert to using the old
SNMP configuration (the one that was used before SGOS 5.3). The services
framework will produce three debug exceptions which will generate event log
entries, but not cause any operational problems.
Related Documentation
Volume 2: Proxies and Proxy Services
Proxy Services
Blue Coat has two types of services: proxy services, used to communicate with
other systems and management services, used to communicate with the ProxySG.
Proxy services define the ports and addresses where a ProxySG listens for
incoming requests.
The following topics in this section discuss changes in SGOS 5.4 to the
Configuration > Services > Proxy Services > Proxy Services tab:
❐
❐
❐
❐
❐
❐
"Accessing Proxy Settings" on page 38
"Bypass Lists" on page 38
"Restricted Intercept" on page 39
"New Services" on page 39
"Other Services Framework Changes" on page 40
"Upgrade/Rollback Behavior" on page 40
37
Blue Coat SGOS 5.4.x Upgrade/Downgrade Feature Change Reference
Accessing Proxy Settings
Impact: 4.3.x Upgrades
Starting in SGOS 5.1, the Configuration > Services module was reworked for
increased functionality, and proxy settings have moved from the Services tab to
the Proxy Settings tab.
Bypass Lists
Impact: 4.3.x Upgrades
If you upgrade to SGOS 5.x from SGOS 4.3.x, entries from the central and local
bypass lists are migrated to the static bypass list. Because the static bypass list
does not support listing gateways, any central or local bypass entries that
included a gateway are converted to static route entries in the static route table.
The converted static route entries are appended after the existing static route
entries. Duplicate static route entries are silently ignored.
All traffic leaving the ProxySG appliance is affected by the static route entries
created from the SGOS 4.3.x bypass lists, not just traffic that matches that
particular bypass list entry.
Several parameters of bypass lists are renamed in SGOS 5.x:
❐
❐
is now server-threshold. This contains the
maximum number of client entries for a particular server before all client
entries are collapsed into a wildcard entry that bypasses all clients going to
that particular server. The default value remains at 16; the range is 1 to 256.
server_bypass_threshold
max_dynamic_bypass_entry
is now max-entries. This defaults to 10000; the
valid range is 100 to 50000.
❐
dynamic_timeout is now timeout. This defaults to 60 minutes and has a range
between 1 and 86400 minutes.
Downgrade Behavior
SOGS 5.x settings are not copied back to SGOS 4.3.x on a downgrade. Previously
existing SGOS 4.3.x settings will be used, or default settings are used if no
previous SGOS 4.3.x configuration exists.
CLI commands that are no longer used in SGOS 5.x include:
# show bypass-list
#(config) bypass-list central-path url
#(config) bypass-list local-path url
#(config) bypass-list no central-path
#(config) bypass-list no local-path
#(config) bypass-list no notify
#(config) bypass-list no subscribe
#(config) bypass-list notify
#(config) bypass-list poll-now
#(config) bypass-list subscribe
#(config) inline bypass-list central eof-marker
#(config) inline bypass-list local eof-marker
#(config) load bypass-list central
#(config) load bypass-list local
38
Chapter 3: Feature-Specific Upgrade Behavior
Related Documentation
Volume 1: Getting Started, Chapter 3
Restricted Intercept
Impact: 4.3.x Upgrades
With SGOS 5.2.x, a new tab has been added to the Configuration > Services menu.
Restricted Intercept allows you to create a list of IP addresses that are intercepted,
while allowing all other IP addresses to be bypassed. The Restricted Intercept List
is useful in a rollout, prior to full production, where you only want to intercept a
subset of the clients. After you are in full production mode, you can disable the
Restricted Intercept List.
The Restricted Intercept List is also useful when troubleshooting an issue, because
you can reduce the set of systems that are intercepted.
On a downgrade to SGOS 5.2 or earlier versions, the restricted intercept list is not
available.
Related Documentation
❐
Volume 1: Getting Started
❐
Volume 6: The Visual Policy Manager and Advanced Policy
❐
Volume 10: Content Policy Language Guide
New Services
The following new services are available in SGOS 5.4 and later:
❐
There are new options for HTTP services, Explicit HTTP, External HTTP, and
Internal HTTP. Explicit HTTP and External HTTP are available under the
Standard node while Internal HTTP is available under the Intranet node.
Older SGOS versions have one service, named HTTP, that has multiple
listeners.
For upgrade/downgrade behavior, see "Upgrade/Downgrade Impact of
HTTP Proxy Services" on page 42.
❐
The VNC and Citrix-ICA service now include additional ports in their
definitions.
❐
The Shell service has been consolidated into the Remote Login/Shell service.
❐
There is a new service in the Encrypted service group called Other SSL.
39
Blue Coat SGOS 5.4.x Upgrade/Downgrade Feature Change Reference
Note: The preceding proxy service changes are not made as part of your
upgrade. After you upgrade, the services are the same as they were in the
earlier SGOS version.
To use the new services after you upgrade, see "Upgrade/Downgrade Impact
of HTTP Proxy Services" on page 42.
Be aware that creating the new services can have downgrade impacts that are
discussed in "Upgrade/Rollback Behavior" on page 40.
Other Services Framework Changes
This section discusses other changes to the services framework:
❐
Reverse-proxy is removed from the list of pre-created service groups under
Configuration > Services > Proxy Services> Proxy Services. When upgrading to 5.4,
if the Reverse-proxy service group is empty, it is deleted from the service group
listing. If Reverse-proxy service group is not empty, the Reverse-proxy service
group remains. However, it is listed under the Custom service groups list in the
Management Console.
When downgrading from 5.4, the Reverse-proxy service group should display
in the predefined service group list.
❐
You can select from a list to intercept/bypass traffic at the service level. With
this change you can now intercept/bypass at the service group level, listener
level and at the service level.
❐
All proxy services can be temporarily disabled by clicking Configuration >
Services > Proxy Services > Proxy Services and selecting the Temporarily bypass all
proxy services check box. This causes transparent proxy connections to be
bypassed and all explicit proxy connections to be rejected.
The equivalent CLI command follows:
#(config proxy-services) force-bypass enable
Note that this option changes the bypass statement to red, to highlight its use.
This feature is intended as panic button and should be used only as an interim
solution while application-breaking problems are repaired.
Note: Downgrading to a version that does not support force bypass while
running in bypass mode will result in restoration of proxy services.
Upgrade/Rollback Behavior
This section discusses the upgrade/rollback impact of changes to the services
framework:
❐
❐
❐
40
"Upgrade Behavior for 4.3.x Upgrades" on page 41
"General Services Framework Upgrade/Rollback Impact" on page 41
"Upgrade/Downgrade Impact of HTTP Proxy Services" on page 42
Chapter 3: Feature-Specific Upgrade Behavior
Upgrade Behavior for 4.3.x Upgrades
Impact: 4.3.x Upgrades
Starting in SGOS 5.1, the services framework (the infrastructure used to manage
proxy services) has been improved to, among other things, support multiple
listeners and ports for each service.
Changes in services include:
❐
Multiple listeners per service: A proxy service is comprised of one or more
listeners. Each listener can be configured to intercept a particular destination
IP subnet and port range. This provides considerable power in intercepting
specific application data streams and protocols on the network.
❐
Port ranges: A listener can now contain a port range. Since a service can have
multiple listeners, many port ranges can be used for a particular service.
❐
Subnet ranges: A listener can match:
•
All traffic
•
Only traffic that is not destined to the SG appliance (Transparent)
•
Traffic specifically destined to the SG appliance (Explicit)
•
Traffic destined to a particular IP address or subnet
❐
Default service: The default service matches all TCP traffic not otherwise
matched by other service listeners. This provides the option to intercept all
TCP traffic on the network so it can be accelerated and controlled by enforcing
company policy on the traffic.
❐
Service names in policy: Each proxy service now requires a name. This name
can contain spaces and can be used as a token in policy. This provides an easy
mechanism to identify particular traffic flows in policy.
❐
Static bypass: The static bypass is now configured under the Proxy Services
and bypasses both TCP and UDP traffic.
❐
Separation of console and proxy services: The management and proxy
services are now configured using different commands.
•
To configure a management service from the CLI, use the managementservices command.
•
To configure a proxy service from the CLI, use the proxy-services
command.
The services have separate Management Console pages (Configuration >
Services > Proxy Services, Configuration > Services > Management Services).
General Services Framework Upgrade/Rollback Impact
Impact: 4.3.x Upgrades
On upgrade to 5.4, the old services configuration is upgraded to the new service
framework. The new services name contains the old services type and generates a
name with one of the following formats:
41
Blue Coat SGOS 5.4.x Upgrade/Downgrade Feature Change Reference
❐
If more than one service with identical properties exists, one service is created
with multiple listeners when upgraded. For example, Yahoo IM has two
service ports in SGOS 4.2, one on 5050 and one on 5101. Instead of creating
two services, one service is created with two listeners.
❐
If multiple proxies of the same type exist, the upgrade uses the format
proxy_name-number. For example, if you had two HTTP services, the new
names are HTTP-1 and HTTP-2.
❐
On upgrade, only new SGOS 5.x services are added. Services that were
purposefully deleted in SGOS 4.3.x are not re-added in the upgrade.
Most attributes directly translate to the new services framework. The exceptions
are:
❐
The tunnel proxy attribute detect protocol is preserved on upgrade; the default
behavior on a new system is disabled.
❐
The transparent and explicit attributes are removed.
❐
The send-client-ip attribute in SGOS 4.2 maps directly to reflect-client-ip in SGOS
5.x.
Upgrade/Downgrade Impact of HTTP Proxy Services
Impact: All Upgrades
This section discusses the upgrade/downgrade impact of changes to HTTP proxy
services. You can upgrade to SGOS 5.4 and downgrade without issues, provided
you have only the HTTP proxy service.
Be aware of the following:
❐
When you upgrade to SGOS 5.4 or later, the new services are not created. To
create the new services after upgrading, you have the following options:
•
Recommended:
•
Delete the existing HTTP service. (Click Configuration > Proxy Services.
In the right pane, under Standard, delete HTTP.)
Failure to delete the services first results in errors such as Listener
Conflict.
•
Import the new services.
For more information, see Volume 2: Proxies and Proxy Services.
•
Use restore-defaults command. Be aware this command affects all SGOS
services, not only Proxy Services.
If you use the restore-defaults command after upgrading to SGOS 5.4—
or if you import the new HTTP proxy services after you upgrade—and
then downgrade to SGOS 5.3.x or 5.2.x, explicit proxy connections on port
80 are not properly directed to the Explicit HTTP service.
Workaround: Delete the Internal HTTP service.
For more information, see Volume 11: Command Line Interface Reference.
42
Chapter 3: Feature-Specific Upgrade Behavior
Related Documentation
Volume 2: Proxies and Proxy Services
Volume 11: Command Line Interface Reference
ProxyClient And Client Manager
Impact: 4.3.x Upgrades
In SGOS the ProxyClient was introduced. The ProxyClient enables users to benefit
from accelerated application delivery directly to their desktops. This allows
mobile users or users in small branch offices—where it might not be costjustifiable to deploy an acceleration gateway—to have improved networked
application access. You can access the configuration options in the Configuration >
ProxyClient tab.
Impact: 5.2.x and 5.3.x Upgrades
If the ProxyClient was configured before you upgraded, there is no impact.
If you configure the ProxyClient after you upgrade, additional validation is
performed to make sure you configure the options correctly. For more
information, see Chapter 12, Accelerating and Controlling Micro-Branch and
Mobile User Connections (ProxyClient), in Volume 5: Advanced Networking.
If you downgrade SGOS after you have configured the ProxyClient, the
configuration options revert to their earlier format. No configuration options are
changed.
To use the ProxyClient, one ProxySG appliance must be configured as the Client
Manager. Upgrading the Client Manager to SGOS 5.4 does not upgrade installed
clients. Upgrading the ADN manager or the ADN data center concentrators has
no effect on clients as long as the client-related settings are not changed.
When upgrading from SGOS 4.3.x, you must install the client license and
configure the ADN Manager and Client Manager as discussed in the chapter on
the ProxyClient in Volume 4: Securing the Blue Coat ProxySG Appliance.
Related Documentation
❐
Volume 5: Advanced Networking
❐
Blue Coat ProxyClient Release Notes
SSL
The SSL module (Configuration > SSL) includes the following changes in default
behavior:
❐
"CA Certificate Lists" on page 44
❐
"Device Profiles" on page 44
❐
"SSL-Verify Server" on page 45
❐
"SSL Detection" on page 45
43
Blue Coat SGOS 5.4.x Upgrade/Downgrade Feature Change Reference
CA Certificate Lists
Impact: 4.3.x, 5.2.x Upgrades
In SGOS 5.3.x, the SSL Proxy trusts all client Certificate Authority certificates in
the CA Certificate List (CCL); previously, the default was to trust none. When
upgrading from 4.2.x or 5.2.x, the default will be set to all, allowing policies that
require client certificates to function properly after upgrade.
If you upgrade from SGOS 5.2 to 5.3 or later, downgrade back to 5.2 and then
modify CCLs, and then upgrade back to 5.3 or later, the changes made to CCLs in
5.2 will not be reflected. You will have to change the CCL configuration manually
to reflect 5.2 changes.
Related Documentation
Volume 2: Proxies and Proxy Services
Device Profiles
Impact: 4.3.x, 5.2.x Upgrades
Starting in SGOS 5.3.1, authentication realms use device profiles for managing the
SSL connection instead of the SSL client. If a realm has the verify server flag set to
off, a new SSL device profile, default-no-verify, will be created during the
upgrade process. If the verify server flag is on, the default SSL device profile will
be used.
The components listed below now use the default SSL device profile for
managing the SSL connection instead of using the SSL client.
•
Secure access log uploads
•
Secure image downloads
•
Secure URL database downloads
•
Secure heartbeats
•
Secure archives use the default device profile, but you can pick an
alternate profile, if you prefer.
•
Authentication realms that speak SSL to the authentication servers use the
default device profile. If you prefer, you can pick another profile.
Deprecated CLI
The following CLI commands are deprecated in realms with SSL support:
ssl-verify-server
ssl-verify-agent
In 5.3.x or later, the following CLI command should be used:
ssl-device-profile <profile-name>
Related Documentation
Volume 4: Securing the Blue Coat ProxySG Appliance, Appendix C
44
Chapter 3: Feature-Specific Upgrade Behavior
SSL-Verify Server
Impact: 4.3.x Upgrades
In SGOS 5.2.x, server certificates are verified by default. The ssl-verify-server
attribute under HTTP and the corresponding CLI and Management Console
commands have been removed.
If you are upgrading from SGOS 4.2.3 or later and have this flag set to no, policy is
generated to restore pre-upgrade server certificate verification behavior. If the
ssl-verify server attribute was set to yes in SGOS 4.2.3, no policy is generated.
Generated policy is visible in the VPM as a new Server Certificate Validation object
and negated version of Request Forwarded object.
SSL Detection
Impact: 4.3.x Upgrades
Starting in SGOS 5.2.x, options to set the SSL protocol detection for HTTP
CONNECT, SOCKS, and TCP Tunnels are no longer available.
If these attributes were set to no in SGOS 4.3.x, policy is generated to maintain the
pre-upgrade SSL detection behavior. If those attributes were set to yes in SGOS
4.3.x, no policy is generated.
Generated policy is visible in the VPM as a new Disable SSL detection object. Note
that this VPM object is meant to accommodate upgrade scenarios only.
The preferred way to control SSL detection and protocol detection in general is by
using the per-service attribute for protocol detection under Configuration > Services
> Proxy Services.
Related Documentation
Volume 2: Proxies and Proxy Services
Instant Messaging
Impact: All Upgrades
Instant Messaging support is configured in the Configuration > Proxy Settings > IM
Proxies tab.
In SGOS 5.3 and earlier, some unsupported IM traffic is denied, some tunneled
and some correctly processed by policy. On upgrade to 5.4, by default, the
ProxySG blocks connections for all unsupported Yahoo and MSN IM clients. The
ProxySG also provides the option to tunnel all unsupported Yahoo and MSN IM
clients. Refer to the SGOS 5.4 Release Notes for a list of currently supported IM
versions.
On downgrade, unsupported IM traffic might be denied, tunneled or partially
processed by policy depending on the configurations in the downgraded SGOS
version.You must manually edit or delete policy entries that contain the policy
conditions new to SGOS 5.4.
SGOS 5.4 also provides new options to support AIM 6.8 as an explicit proxy
configuration. AIM 6.8 connections require a keyring and a signed certificate. The
certificate must be installed on the ProxySG and is used by the AIM proxy service
45
Blue Coat SGOS 5.4.x Upgrade/Downgrade Feature Change Reference
to communicate with the AIM client. The signed certificate on the AIM proxy
must bear the same hostname that is on the Inbound SSL Device Profile; The AIM
6.8 client accepts certificates signed by rapidssl.com CA and Thawte.
All SSL Layer policies can be applied to IM 6.8 traffic. VPM additions in the Action
column of the Web Access Layer are:
❐
IM User Agent Unsupported
❐
Tunnel/Do Not Tunnel IM Traffic
On downgrade, AIM 6.8 clients with an explicit proxy configuration that bear the
hostname that was on the Inbound SSL Device Profile, will not be able to login.
Without an explicit proxy configuration AIM 6.8 traffic will be treated in the same
way as HTTPS traffic.
Streaming Media
Refer to the following sections for changes to Streaming Media in the Configuration
> Proxy Settings tab:
❐
❐
❐
"New Syntax for Caching Objects" on page 46
"WM-HTTP Streaming Media Proxy" on page 46
"WM-RTSP Streaming Media Proxy" on page 47
New Syntax for Caching Objects
Impact: 4.3.x, 5.2.x Upgrades
Starting with SGOS 5.3 the mms://localhost/file.wmv syntax is no longer used for
caching objects. This optimization was only useful on reverse proxies, when
multiple hostnames or IP addresses in the request URL would all resolve to one of
the ProxySG appliance’s IP addresses.
Previously cached objects under mms://localhost/file.wmv are not usable. New
client requests that would have previously used the cached copy now cause the
appliance to fetch file.wmv and cache it mms://host_or_ip>/file.wmv, where host
or ip is based on the server URL returned by policy; it might be the same as the
client’s request URL.
WM-HTTP Streaming Media Proxy
Impact: 4.3.x, 5.2.x Upgrades
Changes implemented in the wm-http streaming media proxy in 5.3 and later,
may cause protocol dialect incompatibility issues if a ProxySG running 5.3 or later
forwards traffic to a ProxySG running older SG versions, and the upstream SG has
a non-default (0 is the default) max-fast-bandwidth configuration setting for
Windows Media clients. In such a situation, client HTTP requests fail for live or
video-on-demand streaming; this is not an issue for RTSP requests.
There are several workarounds (in order of preference):
46
❐
Upgrade the ProxySG running the older SG version to version 5.4.
❐
Reset max-fast-bandwidth to 0 on the upstream ProxySG running a pre-5.3
version.
Chapter 3: Feature-Specific Upgrade Behavior
❐
Disable http-handoff on the upstream ProxySG running a pre-5.3 version.
❐
Disable http-handoff on the downstream ProxySG running version 5.4.
WM-RTSP Streaming Media Proxy
Impact: All Upgrades
WM-RTSP has the option of fast-caching content from the streaming server. With
fast-caching, the WM client can request the streaming server to deliver the
streaming content at a rate faster than the streaming rate of the content.
In the case of MBR VOD content, fast- caching content to the local cache of the
Windows Media client impacts playback quality. To maintain smooth streaming
of MBR VOD content, you might need to disable the fast-caching ability of the
Windows Media client.
By default, fast-caching is enabled on the ProxySG. The VPM or CPL to configure
policy for disabling fast caching are:
❐
Disable Fast-Caching in Windows Media Client is
streaming.fast_cache(no).
❐
Do No Disable Fast-Caching in Windows Media Client
streaming.fast_cache(yes).
❐
The default value is Do No disable Fast-Caching in Windows Media Client or
streaming.fast_cache(yes).
mapped to CPL as
is mapped to CPL as
Related Documentation
Volume 3: Web Communication Proxies
Content Filtering
This section contains information pertaining to the Configuration > Content Filtering
tab.
Blue Coat DRTR
Impact: All Upgrades
In SGOS 5.4, the name DRTR is replaced by WebPulse in the Management Console.
The functionality is not changed, though there is a change in CPL Syntax.
Deprecated CPL Syntax:
category.dynamic.mode(none
| realtime | background | default)
Replacement CPL Syntax:
webpulse.categorize.mode(none
| realtime | background | default)
Impact: 4.3.x, 5.2.x Upgrades
Starting with SGOS 5.3, secure DRTR connections are available on the ProxySG.
This feature is disabled on an upgrade from pre-5.3 versions.
47
Blue Coat SGOS 5.4.x Upgrade/Downgrade Feature Change Reference
If secure DRTR connections was enabled in 5.3 and the device is then
downgraded, the device will use unsecured DRTR connections in the
downgraded version.
Related Documentation
Volume 7: Managing Content, Chapter 2
SmartFilter Database Selection
Impact: 4.3.x, 5.2.x Upgrades
Beginning with SGOS 5.3 offers two database editions for SmartFilter: XL and SL.
The XL edition is the default, and is compatible with SmartFilter 4.2 or later. The
XL edition provides a number of new categories, as well as some changes to
existing categories that are not available in the SL edition.
When you upgrade from pre-5.3 versions that only supported the SL database
edition, the default changes to the XL database edition. To defer policy changes,
re-select the SL edition database.
When downgrading to 5.2.1 or earlier or 4.2.5 or earlier versions, the ProxySG will
use the SL database. When downgrading to 5.2.2.5-5.2.2.7 or 4.2.6.1-4.2.6.2
(precisely), the ProxySG will use the XL database.
Note that any time the database is changed — whether by user gesture or
downgrade/upgrade — there will be no immediate change in behavior. When the
database edition has been changed, the next subsequent download will always be
a full-size download; incremental download between SL and XL editions is not
possible.
Related Documentation
Volume 7: Managing Content, Chapter 2
Authentication
Refer to the following sections for authentication-related upgrade/downgrade
considerations in the Configuration > Authentication tab:
❐
❐
❐
❐
❐
❐
❐
❐
❐
❐
❐
❐
48
"LDAP" on page 49
"Encrypted Passwords" on page 49
"Hexadecimal Encoding in Policy Substitution Realm" on page 50
"Authorization and Proxy-Authorization HTTP Headers Are Writable" on
page 50
"SSH Console" on page 50
"Certificate Realms" on page 51
"SiteMinder" on page 51
"User Management" on page 52
"Permitted Errors, Guest Authentication, and Default Groups" on page 53
"Configuration Options" on page 53
"New Realms" on page 54
"RADIUS Realms" on page 55
Chapter 3: Feature-Specific Upgrade Behavior
❐
❐
❐
❐
"COREid Authentication" on page 55
"IWA Realms" on page 55
"Upgrading the BCAAA Authentication Service" on page 56
"Kerberos Constrained Delegation" on page 59
LDAP
Impact: All Upgrades
❐
LDAP group check performance improvement: On upgrade to SGOS 5.4, existing
realms will be set to use LDAP compares instead of LDAP searches, so that
existing installations do not change.
Newly created realms will be set to use LDAP searches because searches result
in fewer queries to the LDAP server and therefore perform about the same, or
faster, than compares.
❐
Processing LDAP Attributes Locally: When you downgrade to an earlier SGOS
release, policy compilation errors will occur because the feature is engaged by
writing policy that takes advantage of the new triggers or substitution
variables.
❐
See "Configuration Options" on page 53 for CLI changes.
Encrypted Passwords
Impact: All Upgrades
Although the format of encrypted passwords has changed in SGOS 5.3, the
normal upgrade/downgrade process handles the encrypted passwords without a
problem. However, if you save the configuration with the show conf command
before upgrading to SGOS 5.3, and then later replay the saved configuration after
upgrading, encrypted passwords in that saved configuration won’t work.
Likewise, if you save the configuration in 5.3, downgrade to a pre-5.3 version, and
replay the configuration, the encrypted passwords won’t work in the earlier
version.
To avoid this potential problem, Blue Coat recommends that you generate a new
output after upgrading or downgrading. This is a recommended best
practice, since a show conf generated on one version can have unexpected results
when replayed on a different version.
show conf
49
Blue Coat SGOS 5.4.x Upgrade/Downgrade Feature Change Reference
Hexadecimal Encoding in Policy Substitution Realm
Impact: All Upgrades
In SGOS 5.4 or later, you can use a new CPL modifier that takes existing
substitutions and encodes them in hexadecimal. (Configuration > Authentication
> Policy Substitution.)
The new modifier can be formatted in any of the following ways:
variable_name:encode_hex(separator)
variable_name:encode_hex
Examples follow:
Modifier string
Value
How it is evaluated
$(session.username:
encode_hex)
*#911#
2A2439313124
0x$(session.username:
encode_hex( 0x))
*#911#
0x2A 0x24 0x39 0x31
0x31 0x24
After downgrading from SGOS 5.4, the modifier does not exist.
Authorization and Proxy-Authorization HTTP Headers Are Writable
Impact: All Upgrades
In SGOS versions earlier than 5.4, the Authorization and Proxy-Authorization
HTTP headers were read-only for security reasons. Starting with SGOS 5.4, the
headers are writable and Blue Coat has determined the security impact is
minimal.
You can also control the upstream authorization headers using
server.authenticate.basic which allows substitutions for the username and
password.
SSH Console
Impact: 4.3.x, 5.2.x Upgrades
SGOS 5.3 generates SSH client keys that are different from those generated in
earlier versions. For example, if you upgrade to 5.3, regenerate the SSH client
keys, and then downgrade to a pre-5.3 version, the keys in the two versions will
be different. This is only a problem if an SSH client had permanently added a
client key to its local host key file. In this case, SSH clients who were connecting to
a 5.2 system would need to remove and re-add the key when connecting to the 5.3
system (and vice versa).
Related Documentation
Volume 2: Proxies and Proxy Services
50
Chapter 3: Feature-Specific Upgrade Behavior
Certificate Realms
Impact: 4.3.x, 5.2.x Upgrades
Beginning with SGOS 5.3, certificate realms configured with local authorization
will have a default authorization user name of $(cs-username) to correspond to
the relative user name they currently are using. Certificate realms configured with
LDAP or no authorization will default to using the fully qualified domain name
as the authorization user name.
On an upgrade to SGOS 5.4, the substitutions for the Username Attribute,
Container Attribute List, and Base DN will be merged into a Username
Substitution and a Full Username Substitution. A best effort will be made to
create new substitutions that mimic the old behavior. The original settings will be
preserved, but unavailable on a new system.
Downgrade Behavior
A system that has a certificate realm configured for an earlier release, will revert
to that earlier configuration on a downgrade. A certificate realm that was never
configured on an earlier release will have default entries for the basic Username
settings.
Related Documentation
Volume 4: Securing the Blue Coat ProxySG Appliance
SiteMinder
Impact: 4.3.x, 5.2.x Upgrades
SGOS 5.3 and later include the ability to set the SiteMinder authorization realm
and to determine the authorization username.
After the upgrade, existing SiteMinder realms will default to authorizing against
themselves and will use the fully qualified domain name as the authorization user
name.
When downgrading to a version earlier than SGOS 5.3, the new SiteMinder
authorization configuration will be ignored and the SiteMinder realm will
authorize against itself.
Related Documentation
Volume 4: Securing the Blue Coat ProxySG Appliance, Chapter 12
51
Blue Coat SGOS 5.4.x Upgrade/Downgrade Feature Change Reference
User Management
Impact: 4.3.x Upgrades
Starting with SGOS 5.2, management of users who authenticate to the ProxySG
appliance is enhanced. Previously, users were authenticated without a concept of
logging in or logging out of the SG appliance.
A user is considered logged in when first authenticated to the SG appliance,
allowing different ways of managing users and controlling access to resources. A
login is the combination of a unique IP address with a unique username in a
unique realm. For a specific realm, a user is only considered to be logged in once
from a given workstation, even if using multiple user agents.
You can browse the users logged into the SG appliance. You can also filter the
displayed users by username pattern, by IP address subnet, and by realm.
Prior to SGOS 5.2, a single cache credentials value determined how long
credentials, surrogate credentials (authentication cookie or IP address), and
authorization data were trusted. With SGOS 5.2.1 and higher, three refresh times
are available.
Prior to SGOS 5.2, one-time passwords only could be used once; to mimic that
behavior, set the credential refresh time for the realm to 1.
Policy
❐
user.login.log_out(yes)
❐
user.login.log_out_other(yes)
❐
client.address.login.log_out_other(yes)
❐
user.login.count
❐
client.address.login.count
❐
user.login.time
❐
user.login.address
❐
authenticate.authorization_refresh_time(x)
❐
authenticate.credential_refresh_time(x)
❐
authenticate.surrogate_refresh_time(x)
❐
authenticate.credentials.address(x.x.x.x)
Downgrade
If the new features are specified in policy, the policy fails to compile on a
downgrade.
52
Chapter 3: Feature-Specific Upgrade Behavior
Permitted Errors, Guest Authentication, and Default Groups
Impact: 4.2.x Upgrades
Through policy, you can configure several new features in authentication:
❐
Attempt user authentication while permitting specific authentication or
authorization errors.
❐
Allow a user to log in as a guest user.
❐
Set up default groups with any realm, allowing you to assign users to groups
and use those groups in reporting and subsequent authorization decisions.
Policy
New policy gestures include:
❐
authenticate.tolerate_error
❐
authorize.tolerate_error
❐
user.authentication_error
❐
user.authorization_error
❐
authenticate.guest
❐
authorize.add_group
❐
user.is_guest
Before SGOS 4.2, the "authenticated" condition evaluated to true only if both
authentication and authorization succeeded. It now indicates whether the user is
authenticated. If the authentication realm supports split authentication and
authorization or is a valid authorization realm, it is possible for authentication to
succeed and authorization to fail.
Upon downgrade, if the new features are specified in policy, the policy fails to
compile because those features do not exist in earlier versions.
Configuration Options
Impact: All Upgrades
CLI Changes
The CLI command spoof-authentication has been replaced with serverauthentication, for all authentication realms that support BASIC credentials. The
functionality is unchanged; this command enables or disables the forwarding of
BASIC credentials of the authenticated user to the origin content server or to the
proxy for authentication. In the LDAP realm, the CLI command now is:
SGOS#(config ldap realm_name) server-authentication{none| origin| proxy}
Impact: 4.3.x Upgrades
Starting in SGOS 5.2.x, a number of realm configuration options have been
enhanced and reorganized.
❐
Cache Credentials has been replaced by separate refresh times that better
manage how credentials, surrogate credentials, and authorization data is
managed.
53
Blue Coat SGOS 5.4.x Upgrade/Downgrade Feature Change Reference
•
Credential Refresh
•
Surrogate Refresh
•
Authorization Refresh
•
Inactivity Timeout
These settings are all initialized with the value from the original Cache
Credentials setting.
❐
The global virtual URL has been replaced; each realm must set its virtual URL
separately.
❐
The global setting to determine whether cookies used in authentication are
persistent cookies or session cookies has been replaced. Each realm now
manages this setting separately.
CLI Changes
❐
In each realm, the CLI command cache-duration has been replaced with
commands to set the refresh time for credentials, surrogates and authorization
data.
❐
The majority of global transparent-proxy-auth commands (all except
method) have been replaced with equivalent settings in each realm.
Upgrade Behavior
❐
Each realm that does not have an existing virtual URL is set to the default
virtual URL.
❐
Each realm’s cookie behavior (persistent or session cookies) is inherited from
the old global option.
Downgrade Behavior
New settings are ignored and the Cache Credentials value is set to the Surrogate
Refresh time.
Related Documentation
Volume 4: Securing the Blue Coat ProxySG Appliance
New Realms
Impact: 4.3.x Upgrades
Beginning with SGOS 5.2.x, two new realms are supported: XML and Novell
Single Sign-On (SSO).
❐
54
Novell SSO—This realm is an authentication mechanism that provides single
sign-on authentication for users who authenticate against a Novell eDirectory
server. The mechanism uses the Novell eDirectory Network Address
attribute to map the user's IP address to an LDAP Fully Qualified Domain
Name (FQDN).
Chapter 3: Feature-Specific Upgrade Behavior
❐
XML— This realm allows you to integrate SGOS with the authentication/
authorization protocol if you are using an authentication or authorization
protocol that is not natively supported by Blue Coat. This realm requires that
you create an XML realm responder to handle XML requests, which requires
knowledge of the SOAP protocol. To this end, a SOAP appendix has been
created in Volume 4: Securing the Blue Coat ProxySG Appliance.
Downgrade Behavior
The Novell SSO and the XML realms are supported in SGOS 4.2.4.x and later. If
you downgrade to a version that does not support the realm, the realm and its
settings are not available.
Related Documentation
Volume 4: Securing the Blue Coat ProxySG Appliance
RADIUS Realms
Impact: 4.3.x Upgrades
In SGOS 5.2.2 and later, RADIUS realms can specify the character set to encode
the user's credentials with when communicating with the RADIUS server.
A character set is a Multipurpose Internet Mail Extension (MIME) charset name.
Any of the standard charset names for encodings commonly supported by Web
browsers can be used. The default is Unicode:UTF8.
Downgrade Behavior
If you downgrade to a previous release then the credentials are sent as UTF8
encoded.
COREid Authentication
Impact: 4.3.x, 5.2.x Upgrades
In SGOS 5.3, the Oracle COREid 6.5 WebGate server software is upgraded to
Oracle COREid 7.0. Because of the change in version, the single sign-on feature
might stop working even if the IPValidation value in the WebGate configuration
file (WebGateStatic.lst) is later set to false. The workaround is to uninstall and
reinstall the Oracle COREid 7.0 WebGate software, and set IPValidation to false.
Then restart the COREid Access server and the IIS server.
IWA Realms
Impact: All Upgrades
In SGOS 5.4 and later, the Integrated Windows Authentication (IWA) realm
replaces the (Windows NT LAN Manager (NTLM) realm. IWA is a Microsoftproprietary authentication suite that allows Windows clients (running on
Windows 2000 and later) to automatically choose between using Kerberos and
challenge/response authentication, as appropriate.
55
Blue Coat SGOS 5.4.x Upgrade/Downgrade Feature Change Reference
When an IWA realm is used and a resource is requested by a client from the
ProxySG, the appliance contacts the client's domain account to verify the client's
identity and request an access token. The access token is generated by the domain
controller (in case of IWA authentication) or a Kerberos server (in the case of
Kerberos authentication) and passed to the ProxySG, which then validates the
user’s credentials.
In SGOS 5.4 and later, Kerberos authentication is supported for explicit proxy
connections using Internet Explorer 7 and later and Firefox 2 and later.
A sample procedure follows:
1. Click Configuration > Authentication > IWA > IWA Realms.
2. If you have not already done so, create an IWA realm.
3. Click Configuration > Authentication > IWA > IWA Servers.
4. Make sure the Allow Kerberos Credentials check box is selected.
5. Set up BCAAA to run as a domain user.
6. Set up your DNS servers to resolve a host name to the ProxySG’s primary IP
address.
7. Use a command similar to the following to register the domain name of the
ProxySG against the user running BCAAA:
setspn -A http/sg_hostname BCAA_netbios_user_name
8. Configure the Internet Explorer or Firefox proxy server to connect to the host
name of ProxySG (not its IP address).
9. Set up policy to authenticate with the IWA realm.
Upgrading the BCAAA Authentication Service
SGOS 5.4.x uses BCAAA version 130.
Impact: All Upgrades
The following list describes the platforms that BCAAA can run on to support the
specified authentication method (these are not supported directory services):
❐
Integrated Windows Authentication: Windows® Server 2008 (32-bit and 64bit), Windows® Server 2003 (32-bit), and Windows® 2000 Server
❐
Oracle COREid version 6.5 and 7.0: Windows Server 2000 and 2003 (32-bit)
❐
CA eTrust SiteMinder version 5.5 and 6.0: Windows Server 2000 and 2003 (32bit) or Solaris 5.8 or 5.9
❐
Windows SSO: Windows Server 2000, 2003 (32-bit), and Windows Server 2008
(32-bit and 64-bit)
❐
Novell SSO: Windows Server 2000, 2003 (32-bit), and Windows Server 2008
(32-bit and 64-bit)
The only supported directory service operating systems for the preceding
authentication methods are:
❐
56
Windows Server 2000
Chapter 3: Feature-Specific Upgrade Behavior
❐
Windows Server 2003
❐
Solaris 5.8 and 5.9 (SiteMinder and COREid only)
Important:
The BCAAA service cannot be installed on Windows NT or on
Windows Vista.
BCAAA is distributed as a zip file or UNIX shell script, to be installed on a
Microsoft® Windows® system or a Solaris™ system. The zip file to download the
BCAAA service is posted on the software download page at
http://download.bluecoat.com/release/SGOS5_4/index.html.
BCAAA Upgrade/Downgrade Process
Before upgrading to, or downgrading from, SGOS 5.4.x, you must first install the
BCAAA version required for the release you are migrating to.
WARNING:
If you do not install the compatible BCAAA version before
upgrading or downgrading, authentication will fail and you will not be able to
reach the BCAAA server to download a compatible version.
Before upgrading or downgrading SGOS, complete the following steps:
1. Identify the BCAAA release required for the SGOS version you are migrating
to.
2. Download and install the BCAAA installation package required for your
release.
Note: The BCAAA upgrade/downgrade process does not disable the
BCAAA version required for the current SGOS release. For example, if you are
running SGOS 5.4.2.2 with BCAAA version 130 and then install BCAAA
version 120 so that you can downgrade to SGOS 4.2.10.1, SGOS 5.4.2.2
continues to use BCAAA version 130 until you have downgraded.
3. Upgrade or downgrade your SGOS image.
To view the complete upgrade process, refer to the 5.4.x Upgrade/ Downgrade
Guide available at https://bto.bluecoat.com/documentation/pubs/view/
SGOS%205.4.x.
To download and install the BCAAA Service:
1. Navigate to the following BlueTouch Online page:
57
Blue Coat SGOS 5.4.x Upgrade/Downgrade Feature Change Reference
https://bto.bluecoat.com/download/product/17
2. Click the BCAAA link for the SGOS release you want to upgrade to.
3. Review the download agreement.
4. To accept and continue, click I agree and wish to download this software.
5. Click Download Now and save the file.
6. Locate the saved BCAAA zip file.
7. Extract the files.
8. Double click the BCAAA .exe file.
The BCAAA installation wizard displays.
9. Follow the steps in the installation wizard.
Using Multiple Versions of the BCAAA Service
You can run multiple versions of the BCAAA service. Depending on the versions of
BCAAA that you want to run, you might have to install different versions of the service.
Each version of the BCAAA service that you want to run must reside on your system.
Note: You cannot use an older version or a newer version than your proxy
expects. For example, you must install BCAAA version 120 for SGOS 4.2.3.x or
higher and SGOS 5.2.1 or higher.
Table 3–2 Supported Versions of the BCAAA Service
58
SGOS Version
BCAAA Version Supported
SGOS 3.2.6
Upgrade to BCAAA version 99 or higher
SGOS 4.1.x
Upgrade to BCAAA version 99 or higher
SGOS 4.2
100 (Download from:
http://download.bluecoat.com/release/SGOS4/index.html
SGOS 4.2.2
110 (Download from
http://download.bluecoat.com/release/SGOS4/index.html
SGOS 4.2.x, where
x>=3
120 Download from
http://download.bluecoat.com/release/SGOS4/index.html
SGOS 5.1.1
SGOS 5.1.2
100 (Download from
http://download.bluecoat.com/release/SGOS5/index.html)
SGOS 5.1.3
SGOS 5.1.4
110 (Download from
http://download.bluecoat.com/release/SGOS5/index.html)
SGOS 5.2.x
120 (Download from
http://download.bluecoat.com/release/SGOS5_2/index.html)
SGOS 5.3.x
120 (Download from
http://download.bluecoat.com/release/SGOS5_3/index.html)
Chapter 3: Feature-Specific Upgrade Behavior
Table 3–2 Supported Versions of the BCAAA Service (Continued)
SGOS Version
BCAAA Version Supported
SGOS 5.4.1
130 (Download from
http://download.bluecoat.com/release/SGOS5_4/index.html)
Install the lowest version of the BCAAA service first and the highest version of
BCAAA last, allowing each version to uninstall the previous version. This leaves
behind the bcaaa.ini and bcaaa-nn.exe files for each version.
The BCAAA upgrade/downgrade process does not disable the BCAAA version
required for the current SGOS release. For example, if you are running SGOS
5.4.2.2 with BCAAA version 130 and then install BCAAA version 120 so that you
can downgrade to SGOS 4.2.10.1, SGOS 5.4.2.2 continues to use BCAAA version
130 until you have downgraded. This BCAAA installation process leaves behind
the bcaaa.ini and bcaaa-nn.exe files for the version currently running.
Notes
❐
Only one listening port is used, no matter how many versions you are
running. The BCAAA service hands off the connection to the appropriate
BCAAA version.
❐
Installation instructions for BCAAA are located in Volume 4: Securing the Blue
Coat ProxySG Appliance, accessible through WebPower account access.
❐
The BCAAA service cannot be installed on Windows NT, Windows 2008, and
Windows Vista.
❐
The firewall on Windows systems must be disabled for the BCAAA service to
work. If the firewall is enabled, the SG appliance won't be able to connect to
BCAAA.
Related Documentation
Volume 4: Securing the Blue Coat ProxySG Appliance
Kerberos Constrained Delegation
Impact: All Upgrades
Kerberos constrained delegation is a new feature in SGOS 5.4. This feature enables
you to allow users that have been authenticated by the ProxySG in any realm be
reliably authenticated to an origin content server using Kerberos.
An IWA realm must be created to handle the Kerberos constrained delegation,
and the realm must be enabled using policy.
To enable constrained delegation support, you must configure it in the same way
as a new installation.
Important:
To use Kerberos constrained delegation, you must upgrade to
BCAAA version 130 or later. For more information, see "Upgrading the
BCAAA Authentication Service" on page 56.
59
Blue Coat SGOS 5.4.x Upgrade/Downgrade Feature Change Reference
Any configured spoofing will continue to work on upgrades. While the
configuration command has been renamed, the underlying registry value is
unchanged.
Downgrade Impact
If the new policy (in CPL or the VPM) uses the new constrained delegation
properties, spoofing property or Authorization Header rewrites, it will fail to
compile on the downgraded version. These need to be removed before
downgrading.
Any configured spoofing will continue to work on downgrades. While the
configuration command has been renamed, the underlying registry value is
unchanged.
Related Documentation
Volume 4: Securing the Blue Coat ProxySG Appliance, Chapter 18.
Web Content Scanning (ICAP)
See the following sections for information related to changes to the Configuration >
External Services page:
❐
❐
❐
❐
❐
"Cache-Hit Behavior" on page 60
"Cached Objects" on page 60
"Secure ICAP" on page 62
"ICAP Feedback" on page 63
"ICAP Scanning" on page 64
Cache-Hit Behavior
The virus_detected policy condition now generates an event log for cache hits,
cache misses, and non-cacheable objects when a virus is found. If this behavior is
not needed in your environment, you can create an access-log facility to report the
URL, client IP address, and the virus-detected fields. The s-action access-logging
field identifies the type of action taken to process the request and can distinguish
between cache hits and cache misses. Reporter can be used to generate various
reports.
Downgrade Behavior
If you downgrade to a version lower than SGOS 5.2.x, the virus_detected policy
condition is available for cache-miss transactions only.
Related Documentation
Volume 2: Proxies and Proxy Services
Cached Objects
Impact: All Upgrades
60
Chapter 3: Feature-Specific Upgrade Behavior
Objects (except replacement objects from the ICAP server) that are cached under
earlier SGOS releases SGOS 4.3.x, SGOS 5.2.x, and SGOS 5.3.x) remain usable on
upgrade to SGOS 5.4.
On a downgrade, objects cached under SGOS 5.3.x or later are not usable on
earlier SGOS versions. Unusable objects are fetched again from the Origin
Content Server (OCS.)
Related Documentation
Volume 2: Proxies and Proxy Services
61
Blue Coat SGOS 5.4.x Upgrade/Downgrade Feature Change Reference
Secure ICAP
Impact: 4.3.x, 5.2.x Upgrades
SGOS 5.3 and later support secure ICAP connections. On upgrade from a pre-5.3
SGOS version:
❐
The settings for insecure scanning will be inherited.
❐
When upgrading the SG will inspect the service URL:
icap://<ICAP serverIP>:<port>.
❐
If a port number is specified in the service URL, it will be stripped from the
URL and saved in the registry as “port.” The service URL becomes:
icap://<ICAP Service IP>
❐
If a port number is not present in the service URL, the value 1344 will be saved
in the registry as “port.”
Downgrade Behavior
Before downgrading to a pre-5.3 SGOS version, it’s important to disable all secure
ICAP settings:
❐
In the Edit ICAP Service dialog box, clear the check box This service supports
secure ICAP connections.
❐
Remove all policy rules containing request.icap_service.secure_connection.
The following problems will occur if you do not disable the secure ICAP settings:
❐
Policy compilation will fail if it contains the rule
request.icap_service.secure_connection. You will need to manually fix this
by deleting the rules.
❐
The ICAP service URL will contain the URL without the port number. This
isn’t a problem if the default port (1344) is used. If a non-default port is used,
you will need to manually re-enter the port number.
Related Documentation
Volume 7: Managing Content, Chapter 3
62
Chapter 3: Feature-Specific Upgrade Behavior
ICAP Feedback
Impact: 4.3.x Upgrades
In SGOS 5.2.x and later, the ICAP Feedback tab allows you to select either patience
pages or data trickling. Data trickling allows some or most of the HTTP object
data to continue to the client while the ICAP scan occurs. This is primarily
designed for non-interactive (non-Web browser based) HTTP traffic. For
interactive (browser-based) traffic, you can employ data trickling or patience
pages.
❐
For a non-interactive client, feedback is set to none.
❐
For an interactive client:
•
If no ICAP RESPMOD service is found in a pre-SGOS 5.2.x configuration,
interactive feedback is set to none.
•
If an ICAP RESPMOD service is found in a pre-SGOS 5.2 configuration
and all ICAP RESPMOD services were set to patience-page, interactive
feedback is set to patience-page. The delay is set to the minimum of the
delays configured on all ICAP services.
To set patience-page feedback in the upgraded system, enable patience
page for each ICAP service prior to the upgrade. Alternatively, use the CLI
to do this after upgrading.
❐
VPM: Any existing ICAP Patience Page objects are converted into the Return
ICAP Feedback object. The Interactive section within the Return ICAP
Feedback object is derived from the older ICAP Patience Page object.
❐
VPM: Existing older versions of the ICAP Request Service objects and ICAP
Response Service objects with the option "Use ICAP request/response service"
selected are upgraded to the newer version of ICAP Request/Response
Service object with the same option selected.
❐
VPM: Older version of the ICAP Request Service objects and ICAP Response
Service objects with the option Do not use any ICAP service selected are
upgraded to the newer version of the ICAP Request/Response Service object
with the same option selected.
Downgrade Behavior
❐
VPM: Any existing Return ICAP Feedback objects are converted into ICAP
Patience Page objects and the Interactive section within the Return ICAP
Feedback object is used to create the ICAP Patience Page object.
❐
VPM: Any existing newer version of the ICAP Request Service objects and
ICAP Response Service objects with the option Use ICAP request/response
service selected are downgraded to the older version of ICAP Request/
Response Service object with the same option and the service selected is the
same as the first item selected in the pre-downgrade object.
63
Blue Coat SGOS 5.4.x Upgrade/Downgrade Feature Change Reference
❐
VPM: Any existing newer version of the ICAP Request Service objects and
ICAP Response Service objects with the option Do not use any ICAP service
selected are downgraded to the older version of the ICAP Request/Response
Service object with the same option selected.
Deprecated CLI
The following command has been deprecated for ICAP.
SGOS# (config icap services service_name) patience-page seconds
Deprecated Policy
The following policy has been deprecated for ICAP.
Table 3–3 Deprecated Policy
Deprecated Policy
Replacement Policy
patience_page(delay)
response.icap_feedback.interactive(patie
nce_page, 10)
patience_page(no)
response.icap_feedback.interactive(no)
force_patience_page(yes)
response.icap_feedback.force_interactive
(yes)
force_patience_page.useragent (yes)
response.icap_feedback.force_interactive
.user-agent (yes)
force_patience_page[useragent, extension, contenttype](yes)
response.icap_feedback.force_interactive
[user-agent, extension, contenttype](yes)
force_patience_page(useragent, extension)
response.icap_feedback.force_interactive
(user-agent, extension)
VPM-Specific Deprecated Objects: The ICAP Patience Page object generates
patience_page( )
Related Documentation
Volume 6: The Visual Policy Manager and Advanced Policy
ICAP Scanning
Impact: 4.3.x Upgrades
In new SGOS 5.2.x and later installations, you can no longer create ICAP services
named fail_open and fail_closed. If you are upgrading, you can continue to use
the names.
In CPL, you can continue to have ICAP services named fail_open and
fail_closed as long as those names are either the only service specified or not the
last service named if more than one service is specified in a failover sequence. To
specify a service named fail_over or fail_closed as the last service in a
sequence, you must follow the sequence with a failure behavior directive.
64
Chapter 3: Feature-Specific Upgrade Behavior
For example:
response.icap_service(first_service, fail_open, fail_closed)
Here, fail_open is interpreted as a service name (since it is not the last token) and
fail_closed is taken as a failure directive, since it is the last token.
Before downgrading, change any ICAP failover sequence containing more than
one service to a sequence of one service. A policy syntax error is generated if
policy contains an ICAP failover sequence of more than one service or group.
Related Documentation
❐
Volume 6: The Visual Policy Manager and Advanced Policy
❐
Volume 7: Managing Content
❐
Volume 10: Content Policy Language Guide
Forwarding and SOCKS Gateways
Impact: 4.3.x Upgrades
In SGOS 5.2 and later, support for groups (including load balancing and host
affinity) has been added to the SOCKS gateways in the Configuration > Forwarding
tab. In addition, some changes were made to the forwarding group structure to
match the new SOCKS gateway groups.
Note: The retention of deprecated CLI and installable list commands and
command options ensures that older configurations continue to work after an
upgrade. The upgrade introduces new capabilities without removing older
ones.
The new load balancing and host affinity capabilities in the forwarding and
SOCKS gateways are disabled by default after an upgrade. The other setting
for host affinity will be none in all cases.
Changes to Forwarding and SOCKS Gateways
On upgrade, the forwarding and SOCKS gateway configurations are updated to
match the new forwarding/SOCKS behavior.
❐
Empty groups are allowed, can be created, and are not automatically deleted.
❐
Hosts can become members of more than one group.
❐
Load balancing and host affinity commands have been changed.
❐
Many CLI commands have been deprecated in favor of commands that better
reflect the new functionality.
❐
Directives have been changed to match the new CLI.
After an upgrade, SOCKS gateway group names may be used in the socks_gateway
policy. The introduction of new forwarding host or group names or new SOCKS
gateway or group names into policy can cause problems when downgrading as
the policy might not compile.
65
Blue Coat SGOS 5.4.x Upgrade/Downgrade Feature Change Reference
In SGOS 5.2 and later, when you create a forwarding alias, a socks gateway, or a
health check through the CLI or the Management Console, you can use any
printable character in the name except for back quotes (`), colons (:), double
quotes ("), and spaces. Use of non-ASCII characters are legal.
On an upgrade, previously created alias names are transformed into legal alias
names, using the following mappings:
❐
` becomes '
❐
: becomes %
❐
" becomes =
❐
space becomes _
For example, if you used a string such as http://example.com as a forwarding
alias, the alias is transformed to http%//example.com after upgrade.
If your VPM policy references a forwarding alias or socks gateway alias that
contains one of the four illegal characters, a warning message will display when
you attempt to install VPM policy after the upgrade. To fix the problem, edit each
forwarding and SOCKS gateway object to delete the old, invalid alias name and
replace it with the modified alias name.
If you created custom CPL code and this code contains a <Forward> layer that
references forwarding or socks gateway aliases, edit the CPL code, replacing the
old, invalid alias name with the modified alias name.
On downgrade, the system reverts to the configuration that existed prior to the
upgrade. Any changes to the configuration are lost on downgrade.
Related Documentation
Volume 5: Advanced Networking
Health Checks
Impact: 4.3.x Upgrades
Starting in 5.2, health checks are now automatically created and deleted for
forwarding hosts and groups, SOCKS gateways and groups, ICAP servers and
service groups, Websense off-box servers and service groups, and DRTR. You can
create additional health checks for any target host or create composite health
checks that merge the results of other health checks. All health checks are now
individually configurable. Policy conditions allow the state of any health check to
be used in policy.
Health checks are subject to forwarding and SOCKS gateway policy when
appropriate. SSL certificate policy affects certain types of health checks.
Changes
❐
66
Health checks for the ICAP and Websense off-box services are no longer
optional, but are automatically created and deleted as the service is created
and deleted. You cannot create health checks for these services.
Chapter 3: Feature-Specific Upgrade Behavior
❐
Health check names have changed, with each health check type having a
different prefix.
❐
External services and external service group names are now limited to 64
characters each. If an old name exceeds 64 characters, the service or service
group continues to function normally but no corresponding health check is
created.
❐
Although health checks were used for DRTR in previous releases, they were
hidden. The DNS resolution for DRTR is checked according to the site's timeto-live value.
❐
Health checks have vastly changed functionality so CLI commands in
previous versions do not work, and there is no backward compatibility. See
"Deprecated CLI" on page 68 for more information.
Upgrade Behavior
After an upgrade, examine the new health checks and the configuration and
ensure that the health checks are properly configured and succeeding. Check that
the results of the upgrade are satisfactory. Note that any health check can be
disabled if necessary.
❐
Forwarding hosts and SOCKS gateways have health checks created that are
based on the previous global health check configuration settings. New health
checks are created for any forwarding groups that previously existed.
❐
ICAP and Websense off-box services that had health checks before the
upgrade have health checks created that are based on the previous settings for
that health check.
❐
New health checks are created on upgrade for any ICAP or Websense off-box
service groups.
❐
User-defined health checks from previous versions are converted to the new
user-defined health checks on upgrade.
In SGOS 5.2 and higher, when you create a health check through the CLI or the
Management Console, you can use any printable character in the name except for
back quotes (`), colon (:), double quotes ("), and spaces. Note that non-ASCII
characters are legal.
On an upgrade from SGOS 4.2.x, previously created alias names are transformed
into legal alias names, using the following mappings:
❐
` becomes '
❐
: becomes %
❐
" becomes =
❐
space becomes _
For example, if you used a string such as http://example.com as a forwarding
alias, the alias is transformed to http%//example.com after upgrading from 4.2.x to
5.2/5.3.
67
Blue Coat SGOS 5.4.x Upgrade/Downgrade Feature Change Reference
If the SGOS 4.2.x VPM policy references a forwarding alias or socks gateway alias
that contains one of the four illegal characters, you will see warning messages the
next time you try to install VPM policy after the upgrade. To fix the problem, edit
each forwarding and SOCKS gateway object to delete the old, invalid alias name
and replace it with the transformed alias name.
If you created custom CPL code and this code contains a <Forward> layer that
references forwarding or socks gateway aliases, edit the CPL code, replacing the
old, invalid alias name with the transformed alias name.
Downgrade Behavior
❐
The system reverts to the configuration that existed prior to this upgrade. Any
changes to the configuration are lost on downgrade.
❐
Policy that contains new health check types does not compile.
Policy
New policy conditions include:
❐
is_healthy.alias = yes | no
❐
health_check = yes | no | alias
Deprecated CLI
SGOS#(config health-check) forwarding
SGOS#(config health-check) socks-gateways
New CLI
SGOS#(config health-check) copy source-alias target-alias
SGOS#(config health-check) create {composite alias_name | http
alias_name url | https alias_name url | icmp alias_name hostname| ssl
alias_name hostname [port]| tcp alias_name hostname [port]}
SGOS#(config health-check) default e-mail {healthy {enable |disable} |
report-all-ips {enable | disable} | sick {enable | disable}}
SGOS#(config health-check) default event-log {healthy {enable
|disable} | report-all-ips {enable | disable} | sick {enable |
disable}}
SGOS#(config health-check) default failure-trigger {none | count}
SGOS#(config health-check) default interval {healthy seconds| sick
seconds}
SGOS#(config health-check) default snmp {healthy {enable |disable} |
report-all-ips {enable | disable} | sick {enable | disable}}
SGOS#(config health-check) default threshold {healthy count |
response-time milliseconds | sick count}
SGOS#(config health-check) delete alias_name
SGOS#(config health-check) disable {healthy alias_name | sick
alias_name}
SGOS#(config health-check) edit composite_health_check
SGOS#(config health-check) edit health_check_type
SGOS#(config health-check) enable alias_name
SGOS#(config health-check) exit
68
Chapter 3: Feature-Specific Upgrade Behavior
SGOS#(config health-check) perform-health-check alias_name
SGOS#(config health-check) view {configuration | quick-statistics |
statistics}
HTTP Proxy
Impact: Downgrades
Beginning in SGOS 5.4.3.7, the max-cache-size value is stored in 64-bits and this
field supports a value of up to 8448MB (8.25GB). In earlier SGOS versions the
value was stored in 32 bits and the maximum supported value was 2047MB (2GB
approx.).
Because the value is now stored in 64-bits, when you downgrade from SGOS
5.4.3.7 to an earlier SGOS version that stores this value in the 32-bit format, the
max-cache size value is reset to the default value of 1024MB.
This option can be configured using the Do not cache objects larger than [ ] megabytes
in the Configuration > Proxy Settings > HTTP Proxy > Policies tab or using the ProxySG
CLI.
Policy/VPM
The changes discusses changes to Policy and the Visual Policy Manager (VPM):
❐
❐
❐
❐
❐
❐
❐
❐
"QoS" on page 69
"Revocation Checks on Certificates" on page 70
"Content-Type Matching" on page 71
"File Extension Objects" on page 71
"SSL Forward Proxy Object Renamed" on page 71
"Proxy Forwarding" on page 72
"Authentication" on page 72
"New User Login Address Object" on page 72
QoS
Impact: 4.3.x Upgrades
Beginning with SGOS 5.1, the ProxySG appliance supports Quality of Service
(QoS) detection, which is becoming a more prevalent control point for network
layer traffic. Previously, the QoS information was lost or not detected when the
ProxySG terminated the client connection and issued a new connection to the
server. QoS support allows you to create policy to examine the Type of Service
(ToS) fields in the IP header to determine the QoS of the bits.
Policy matches are based on Differentiated Services Code Point (DSCP) values,
which network devices use to identify traffic to be handled with higher or lower
priority.
In SGOS 5.2.x, the following VPM objects and CPL gestures were added to
support QoS:
69
Blue Coat SGOS 5.4.x Upgrade/Downgrade Feature Change Reference
server.connection.dscp=
client.connection.dscp=
server.connection.dscp( )
client.connection.dscp( )
adn.connection.dscp( )
The following objects have been added to VPM to support QoS:
❐
Client Connection DSCP Trigger
❐
Server Connection DSCP Trigger
❐
Set Client Connection DSCP (Action)
❐
Set Server Connection DSCP (Action)
❐
Set ADN Connection DSCP
(Source)
(Destination)
(Action)
Related Documentation
❐
ADN and DSCP: "DSCP" on page 26
❐
Volume 6: The Visual Policy Manager and Advanced Policy
Revocation Checks on Certificates
Impact: 4.3.x, 5.2.x Upgrades
In addition to the “no revocation” and “revocation check” actions available in
previous versions, SGOS 5.3 adds two new actions on the client/server certificate
validation object in the VPM: Use only OCSP revocation check (checks the certificate
through Online Certificate Status Protocol) and Use OCSP revocation check if
available otherwise use local (checks the certificate through OCSP if available,
otherwise checks it against a locally installed revocation list).
When upgrading the VPM to 5.3 or later:
❐
Do not check certificate revocation
❐
Also check certificate revocation gets
available otherwise use local action.
remains unchanged.
converted to the Use OCSP revocation check if
When downgrading the 5.3 or later VPM to earlier versions:
70
❐
Do not check certificate revocation
❐
Use only local certificate revocation check”
revocation.
remains unchanged.
converts to Also check certificate
Chapter 3: Feature-Specific Upgrade Behavior
❐
Use OCSP revocation check if available otherwise use local”
certificate revocation.
converts to Also check
❐
Use only OCSP revocation check converts to Do not check certificate revocation since
earlier releases didn’t offer OCSP.
Related Documentation
Volume 6: The Visual Policy Manager and Advanced Policy, Chapter 3
Content-Type Matching
Impact: 4.3.x, 5.2.x Upgrades
Starting in SGOS 5.3, the policy when using HTTP MIME Type objects specifies an
exact match on content type. The generated CPL code for this is:
response.header.Content-Type=”application/x-sh( |\t)*($|;)”
In earlier versions, there wasn’t a straightforward way to specify an exact match
on content type for HTTP MIME Type objects in the VPM. For example, blocking
on content-type “application/x-sh” would block “application-x-shar” and
“application/x-shockwave.” The CPL code for this was:
response.header.Content-Type=”application/x-sh”.
After upgrading to 5.3, the policy will be unaffected unless it is modified with the
Install Policy button in the VPM; in this case, it will automatically be updated to
the new format (which performs an exact match on content type). When
downgrading from 5.3, the next time policy is installed in VPM, the generated
CPL will revert to the old format (which does a wildcard type of match).
File Extension Objects
Impact: All Upgrades Except 5.3.2
Support for the following file extensions has been added in the Destination column
of the Web Content Layer and Web Access Layer.
•
.xlb — Excel Worksheet (Microsoft)
•
.xld — Excel Dialog (Microsoft)
•
.xll — Excel Add-in (Microsoft)
•
.xlk — Excel Backup (Microsoft)
•
.dif — Data Interchange Format
SSL Forward Proxy Object Renamed
Impact: 4.3.x Upgrades
In SGOS 5.2.2, the Add SSL Forward Proxy object is renamed to Enable HTTPS
Interception to better reflect the object’ s function. In addition, the HTTPS Interception
on Exception object is used to intercept SSL traffic if there is an exception, such as a
certificate error or policy denial. This differs from the HTTPS Intercept object, which
intercepts all HTTPS traffic.
71
Blue Coat SGOS 5.4.x Upgrade/Downgrade Feature Change Reference
Proxy Forwarding
Impact: 5.2.x and 5.3.x Upgrades (MACH5 Edition license only)
If you are upgrading from a 5.x version earlier than 5.2.4.8 or 5.3.x earlier than
5.3.2.1. This section is relevant to you.
The MACH5 Edition license supports Proxy Forwarding. You can configure
forwarding hosts and forwarding groups and apply related policy using the VPM.
The CLI commands for proxy forwarding are also available.
The Statistics > Health Checks tab displays the automatically created health checks
for the forwarding hosts and groups.
Note: Upgrading from 4.x to 5.x MACH 5 edition license is not possible.
Before downgrading from 5.4 to a version of SG 5.2.x before 5.2.4.8 or a version of
SG 5.3 before 5.3.2.1 all forwarding configuration and policy should be manually
disabled. Downgrade from MACH5 edition to SG 4.x is not permitted.
Authentication
Impact: All Upgrades
Addition of a VPM action in the pre-created object list under Web Authentication
Layer is Do not Authenticate (Forward Credentials) whereby credentials will be
forwarded to upstream proxies instead of being authenticated on the ProxySG.
The CPL action for this command maps to authenticate (no,
upstream_authentication).
This action disables authentication on the proxy for the matching transaction, but
allows any existing credentials in the request to be sent upstream. Use of this
action is limited to proxy-chaining configurations where the upstream proxy is
authenticating the user.
Alternatively, the Do not Authenticate action disables authentication on the proxy
for the matching transaction and blocks existing credentials in the request from
being sent upstream.
Related Documentation
Volume 6: The Visual Policy Manager and Advanced Policy
New User Login Address Object
Impact: 4.3.x Upgrades
Starting in SGOS 5.2, a new subnet mask field allows you to specify a subnet of
addresses to match in addition to single IP addresses. This lets you match against
all machines on a particular subnet, rather than specific individual machines.
On an upgrade, existing User Login Address objects are treated as if no subnet
mask was specified. User Login Address objects created with a subnet mask are
not supported if the ProxySG is downgraded to a previous release without this
functionality.
Related Documentation
Volume 6: The Visual Policy Manager and Advanced Policy
72
Chapter 3: Feature-Specific Upgrade Behavior
Statistics
Impact: 4.3.x Upgrades
❐
Persistent bandwidth statistics are not preserved on upgrade from SGOS 4.3.x.
These statistics are now computed differently.
❐
Persistent statistics are kept differently in SGOS 5.x and SGOS 4.3.x. Statistics
are imported on first upgrade. After that, SGOS 5.x statistics show gaps when
SGOS 4.3.x is running and vice versa.
Related Documentation
Volume 9: Managing the Blue Coat ProxySG Appliance
Upgrade
Impact: 4.3.x, 5.2.x Upgrades
Beginning with SGOS 5.3, Blue coat offers the option of using signed system images
when upgrading. This option can be selected in the Maintenance > Upgrade tab. A
signed system image is one that is cryptographically signed with a key known
only to Blue Coat, and the signature is verified when the image is downloaded to
the system. Blue Coat is currently providing signed and unsigned images for
SGOS releases 5.3 and later. At some point, only signed images will be offered.
When upgrading from a pre-5.3 version, you will need to upgrade to an unsigned
version of 5.3 before upgrading to a signed version of a later release.
Related Documentation
Volume 9: Managing the Blue Coat ProxySG Appliance
73
Blue Coat SGOS 5.4.x Upgrade/Downgrade Feature Change Reference
74
Chapter 4: FIPS Upgrade Information
This chapter covers information pertaining to Federal Information Processing
Standards (FIPS) implementations. It covers upgrade/downgrade issues
related to FIPS mode.
Topics in this Chapter
The following topics are discussed in this chapter:
❐
"Configuration Files" on page 75
❐
"Signed Archive Configurations" on page 75
❐
"DRTR Connections" on page 76
❐
"SSL" on page 76
Note: The information in this chapter is applicable to all 4.x, 5.1 and 5.2
upgrades.
Configuration Files
FIPS mode devices will not accept old configuration files (unless they are
manually pasted through the CLI).
Signed Archive Configurations
On an upgrade to SGOS 5.4 in non-FIPS mode, the new archive configuration
options will be available, but will be disabled by default. On entry to FIPS
mode, unsigned configuration archives will be disabled. You will need to
create/select the appropriate keyrings and CCLs for signing and verifying the
archive.
When downgrading to a pre-5.3 version, the signed archive configuration will
be disabled. The system will default to the original archive format. If a protocol
other than TFTP or FTP was configured for archiving the configuration, the
protocol will default to FTP. Signed configurations cannot be directly loaded by
the downgraded system. However, it would be possible to extract the
configuration.txt file from the signed archive and attempt to load that
configuration.
Related Documentation
Volume 1: Getting Started, Chapter 5
75
Blue Coat SGOS 5.4.x Upgrade/Downgrade Feature Change Reference
DRTR Connections
When upgrading, secure DRTR connections are disabled in non-FIPS mode
devices. If the device is put into FIPS mode, secure connections will be enabled
and cannot be disabled.
If the device is then downgraded to a pre-5.3 version, it will use unsecured DRTR
connections.
Related Documentation
Volume 7: Managing Content, Chapter 2
SSL
In SGOS 5.3 and later, the following applications are subject to FIPS compliance:
❐
Authentication realms that use SSL with the authentication servers
❐
URL database downloads over SSL
❐
Image downloads over SSL
❐
Secure heartbeats
❐
Secure access log uploads
Upon upgrading, the above applications will use the SSL device profile instead of
the SSL client. After entering the FIPS mode of operation, the “default” SSL device
profile will be created as FIPS compliant and will thus allow only FIPS-compliant
SSL versions, ciphers, and so forth.
Related Documentation
❐
76
FIPS documentation