Documentation | Support

Go to the table of contents Go to the previous page Go to the next page View or print as PDF
Content Gateway Troubleshooting : Websites that have difficulty transiting Content Gateway
Websites that have difficulty transiting Content Gateway
Content Gateway Troubleshooting | Forcepoint Web Security | v8.4.x, v8.5.x | 29-Apr-2022
This article lists sites and applications that do not work as expected with Content Gateway and offers appropriate PAC file entries, bypass rules, filtering rules, and other solutions to provide access to those resources.
 
* 
Important 
It is up to you to determine and apply the solution that is best for your deployment and security environment.
Background
Because of the way some sites package content or use (or misuse) the HTTP/HTTPS protocols, those sites have difficulty transiting Content Gateway (and most other proxy servers).
When access to those sites is required, Content Gateway provides several ways to specify sites that will bypass the proxy, including static and dynamic bypass rules, and, when HTTPS is enabled, SSL Incident rules.
In addition, depending on how Content Gateway is deployed in the network, sites can be bypassed with a PAC file entry (explicit proxy deployments with most Windows clients), or via the Access Control List (ACL) on the router or switch (transparent proxy deployments).
In addition, sites that host applications that do not properly negotiate proxy user authentication are also a problem. When use of those applications is a requirement, it is possible to create a proxy filtering rule that identifies the application through the User-Agent field of the HTTP header and allows the application to bypass user authentication.
For more about bypass rules, see Interception Bypass in Content Gateway Manager Help.
For more about SSL incident rules, see Managing HTTPS website access in Content Gateway Manager Help.
For more about bypassing a site using a PAC file, see How do I specify in a PAC file a URL that will bypass Content Gateway?
See your router or switch documentation for information about ACLs.
Default SSL bypass rules
When HTTPS (SSL support) is enabled for HTTPS decryption, inspection, and re-encryption, these Incident list entries are present and enabled by default:
 
URL
Action
Purpose
*.microsoft.com:443
default tunnel
Microsoft Update and Windows Update
*.msn.com:443
default tunnel
Microsoft Update and Windows Update
*.gotomeeting.com:443
default tunnel
Citrix GoToMeeting
*.webex.com:443
default tunnel
Cisco collaboration tools
aus2.mozilla.org:443
default tunnel
Firefox Update
*.blackspider.com:443
default tunnel
Forcepoint Web Security Cloud connection
*.mailcontrol.com:443
default tunnel
Forcepoint Email Security Cloud connection
*.citrixonline.com:443
default tunnel
Citrix collaboration tools
*.expertcity.com:443
default tunnel
Citrix collaboration tool support
*.gotoassist.com:443
default tunnel
Citrix remote assistance tool
*.gofastchat.com:443
default tunnel
Citrix collaboration tool support
*.gotomypc.com:443
default tunnel
Citrix remote PC access tool
*.goview.com:443
default tunnel
Citrix collaboration tool
Sites that have difficulty transiting Content Gateway
*
Microsoft Update
*
WebEx
*
Real Networks Real Player
*
Citrix collaboration products
*
Firefox Update
*
Yahoo! Messenger with Pidgin messaging client
*
Logitech Messenger Agent and VirtualBox
Microsoft Update
Microsoft Update updates the Windows operating system and Microsoft applications, such as Office. The update process runs as a system service and consequently does not use the same certificate trusts as a user.
 
* 
Note 
When Microsoft Update is accessed with HTTP, no special configuration is required. However, because the connection is not secure, this method is not recommended.
To use Microsoft Update with HTTPS when SSL support is enabled, you must bypass the proxy in one of the following ways:
 
PAC file entry:
/* Don't proxy Microsoft Update */
if ((host == "download.microsoft.com") ||
(host == "ntservicepack.microsoft.com") ||
(host == "cdm.microsoft.com") ||
(host == "wustat.windows.com") ||
(host == "windowsupdate.microsoft.com") ||
(dnsDomainIs(host, ".windowsupdate.microsoft.com")) ||
(host == "update.microsoft.com") ||
(dnsDomainIs(host, ".update.microsoft.com")) ||
(dnsDomainIs(host, ".windowsupdate.com")))
{
return 'DIRECT';
}
 
Static bypass rule:
Not recommended due to the number of IP address ranges used by Microsoft and the dynamic nature of that IP address set.
SSL incident rule:
The rules that are included in the Incident List by default are sufficient.
Alternatively, you can disable Microsoft Update and use Windows Update instead. Windows Update only updates the operating system and doesn't have problems transiting the proxy.
If you elect to use Windows Update:
1.
Add the URL to the Scanning: Never Scan list (in the Web Security module of Forcepoint Security Manager).
2.
In the Content Gateway manager, go to Configure > Protocols > HTTP > Timeouts, and make sure that the Keep-Alive Timeouts value is set to 60.
On Windows 7 systems, to repair Microsoft Windows error 80072F8F, navigate to Start > Control Panel > Troubleshooter > System and Security and select Fix problem with Windows Update.
WebEx
WebEx does not support HTTPS connections through a proxy. Use one of the following bypass methods.
 
PAC file entry:
if (shExpMatch(url, "*.webex.com/*"))
{
return "DIRECT";
}
 
Static bypass rule:
This method requires creation of several bypass rules, one for each current IP address range. For each IP address range:
Rule Type: Bypass
Source IP: (empty)
Destination IP: <IP address range>
The list of IP addresses for Cisco Unified MeetingPlace version 8.5 is:
64.68.96.0/19 (CIDR) or 64.68.96.0 - 64.68.127.255 (net range)
66.114.160.0/20 (CIDR) or 66.114.160.0 - 66.114.175.255 (net range)
66.163.32.0/20 (CIDR) or 66.163.32.0 - 66.163.47.255 (net range)
209.197.192.0/19 (CIDR) or 209.197.192.0 - 209.197.223.255 (net range)
208.8.81.0/24 (CIDR) or 208.8.81.0 - 208.8.81.255 (net range)
210.4.192.0/20 (CIDR) or 210.4.192.0 - 210.4.207.255 (net range)
62.109.192.0/18 (CIDR) or 62.109.192.0 - 62.109.255.255 (net range)
173.243.0.0/20 (CIDR) or 173.243.0.0 - 173.243.15.255 (net range)
114.29.192.0/19 (CIDR) or 114.29.192.0 - 114.29.223.255 (net range)
More more information, see below.
SSL incident rule:
Add:
URL *.webex.com TUNNEL
Troubleshooting: If after adding a bypass, the connection still fails, in some cases the WebEx site responds with an IP address or a domain name that doesn't match *.webex.com. You can work around the problem by examining the inbound_access.log to find the unresolved connection and then add the IP address or domain name as an exception using the option employed above.
 
* 
Note 
When Content Gateway is on an appliance, this procedure requires the assistance of Technical Support.
To find the name of the WebEx site:
1.
On the Content Gateway host, change directory to /opt/WCG/sxsuite/log and open or view inbound_access.log.
2.
Most often, the unresolved CONNECT will be in close proximity to a successful *.webex.com connect, so start by searching for webex.com. A successful tunnel connection looks similar to:
CONNECT cisco.webex.com:443 HTTP/1.0
CONNECT nsj1msccl01.webex.com:443 HTTP/1.1
(tunneled SSL connection to nsj1msccl01.webex.com:443)
(tunneled SSL connection to cisco.webex.com:443)
3.
From this location scan downward for a URL that has the CONNECT status, but does not indicate that the connect was tunneled or successfully fetched content with a GET. This unresolved traffic might look similar to:
CONNECT 66.114.169.162:443 HTTP/1.1
CONNECT 66.114.169.162:443 HTTP/1.1
4.
Add the domain name or IP address to the incident list or bypass list.
WebEx domain, IP addresses, and ports (19-Feb-2013):
World Wide URL domain exception = *.webex.com
IP addresses and ranges:
*
64.68.96.0/19 (CIDR) or 64.68.96.0 - 64.68.127.255 (net range)
*
66.114.160.0/20 (CIDR) or 66.114.160.0 - 66.114.175.255 (net range)
*
66.163.32.0/20 (CIDR) or 66.163.32.0 - 66.163.47.255 (net range)
*
209.197.192.0/19 (CIDR) or 209.197.192.0 - 209.197.223.255 (net range)
*
208.8.81.0/24 (CIDR) or 208.8.81.0 - 208.8.81.255 (net range)
*
210.4.192.0/20 (CIDR) or 210.4.192.0 - 210.4.207.255 (net range)
*
62.109.192.0/18 (CIDR) or 62.109.192.0 - 62.109.255.255 (net range)
*
173.243.0.0/20 (CIDR) or 173.243.0.0 - 173.243.15.255 (net range)
*
114.29.192.0/19 (CIDR) or 114.29.192.0 - 114.29.223.255 (net range)
Ports that need to be open to clients (Internet):
TCP 80 Client Access
TCP 443 Client Access
TCP 8554 Audio Streaming Client Access
TCP/UDP 53 DNS
UDP 7500 Audio Streaming
UDP 7501 Audio Streaming
UDP 9000 VOIP/Video
UDP 9001 VOIP/Video
For the most up to date information, see Customer Network to Cisco WebEx Cloud IP Ranges for Firewall Settings.
Real Networks Real Player
When the following combined conditions are true, Real Networks Real Player fails to stream content:
1.
Content Gateway is deployed as an explicit proxy.
2.
Content Gateway is the only path to the Internet.
3.
User authentication is NTLM.
By default, Real Player uses the RTSP or PNA protocols to stream media, both of which bypass Content Gateway. However, when Content Gateway is the only path to the Internet, Real Player uses HTTP to transit Content Gateway. Unfortunately, Real Player doesn't handle NTLM authentication properly and the connection fails. (For related information, see Microsoft knowledge base article
http://support.microsoft.com/kb/288734).
To work around the problem, add an Allow rule to filter.config that identifies the Real Player application and allows Real Player traffic to bypass authentication:
1.
In the Content Gateway manager, go to Configure > Security > Access Control > Filtering and click Edit File.
2.
Add the following filtering rule:
Rule Type = Allow
Primary Destination Type = dest_domain
Primary Destination Value = .
User-Agent = realplayer
3.
Click Add. The new rule appears in the table at the top of the page. It should have the format:
Rule Type=Allow , dest_domain=. , User-Agent=realplayer
4.
Click Apply and then Close.
Citrix collaboration products
Citrix collaboration products do not support HTTPS connections through a proxy. Connections require proxy bypass rules.
To create proxy bypass rules, you will need a list of the current Citrix URL ranges. Go to these sites for additional information.
*
Optimal Firewall Configuration
*
Whitelisting and LogMeIn
If Content Gateway is a transparent proxy with WCCP routers or switches, add the Citrix IP address ranges to the WCCP Access Control List (ACL).
 
PAC file entry:
Add entries for the Citrix URLs in the exceptions block of your PAC file.
 
A separate line is required for each distinct IP address range.
 
if (shExpMatch(url, "Citrix Collaboration IP address"))
{
return "DIRECT";
}
 
where "Citrix Collaboration IP address" is replaced by an IP address range from the Citrix list.
 
Static bypass rule:
For each Citrix IP address range, add a rule like:
 
Rule Type: bypass
Source IP: (empty)
Destination IP: IP address range or CIDR of one of the Citrix ranges
 
Repeat for each range.
 
Firefox Update
The Firefox Update site does not support HTTPS connections through a proxy.
 
PAC file entry:
if (shExpMatch(url, aus2.mozilla.org))
{
return "DIRECT";
}
 
Static bypass rule:
Add:
Rule Type: Bypass
Source IP: (empty)
Destination IP: IP address range of Firefox Update
SSL incident rule:
Add:
URL aus2.mozilla.org TUNNEL
Yahoo! Messenger with Pidgin messaging client
When the Pidgin messaging client is used with Yahoo! Messenger, the SSL connection is blocked. Traffic can be permitted by adding one or two rules to the SSL Incident list.
The message traffic cannot be meaningfully scanned, therefore it is recommended that you add the URL to the Scanning: Never Scan list (in the Web Security module of Forcepoint Security Manager).
 
PAC file entry:
if (shExpMatch(url, scsa.msg.yahoo.com)) ||
(shExpMatch(url, filetransfer.msg.yahoo.com))
{
return "DIRECT";
}
 
To prevent file transfers, remove "filetransfer.msg.yahoo.com" from the above code.
 
SSL incident rule:
Add:
URL scsa.msg.yahoo.comTUNNEL
URL filetransfer.msg.yahoo.com TUNNEL
 
Or, to block filetransfers, make the filetransfer rule BLACKLIST.
Logitech Messenger Agent and VirtualBox
These sites do not handle proxy NTLM authentication and require a filter.config authentication bypass rule.
1.
In Content Gateway Manager, go to Configure > Security > Access Control > Filtering and click Edit File.
2.
Add the following filtering rule:
Rule Type = Allow
Primary Destination Type = dest_domain
Primary Destination Value = (enter the appropriate value)
.logitech.com
.virtualbox.org
3.
Click Add. The new rule appears in the table at the top of the page. It should have the format:
Rule Type=Allow , dest_domain=value-you-entered
4.
Click Apply and then Close.

Go to the table of contents Go to the previous page Go to the next page View or print as PDF
Content Gateway Troubleshooting : Websites that have difficulty transiting Content Gateway
Copyright 2022 Forcepoint. All rights reserved.