This article applies to:
- WebMarshal
- Java
- Shockwave Flash
- Multimedia applications (Windows Media Player, RealPlayer, Quicktime, and others)
Question:
- Why does some web content fail to load when the browser is set to use WebMarshal?
Information:
WebMarshal is an authenticating proxy server that works with the HTTP, HTTPS and passive FTP protocols. WebMarshal listens only on the ports you configure in the Proxy Ports and Authentication window. Many multimedia applications use custom protocols and ports by default (not HTTP). The custom protocols are designed for efficiency and good user experience.
In a secured network, most ports are closed at the firewall, so applications cannot make direct outbound connections. In order to retrieve content, they must be set up to send requests through WebMarshal on the ports where it listens. Also, the content servers must be able to return content through one of the supported protocols.
Helper applications such as Java, Flash, and multimedia players can have problems retrieving content for a number of reasons, including:
- WebMarshal rules
- Incorrect proxy settings
- Issues with proxy authentication
- Protocol redirection problems
The remainder of this article provides some suggestions for debugging these issues. Some of the WebMarshal features described are available in version 6.9 or above.
1. WebMarshal Rules
Before investigating settings, make sure that the content is not being blocked by a WebMarshal rule. Check for blocked items in the Active Sessions window of the WebMarshal Console. Note that rule behavior can differ based on a combination of the user and/or workstation, server URL, file name, or content type.
2. Proxy settings
Applications such as Java Runtime Environment and Windows Media Player have their own settings for proxy usage. Generally you can and should set these applications to use the browser proxy settings for HTTP.
Ensure that you have the latest version of the software, and check that HTTP proxy settings are configured to use the browser settings (or manually configured to use WebMarshal).
- Tip: To determine whether the application is actually connecting to WebMarshal, enable full proxy logging for a particular client computer, and check the logs. Note that the Active Sessions listing does not show connection attempts that failed authentication, and it may not show every file associated with a successful session. Full logging consumes extra resources, so be sure to disable full logging as soon as you are finished with testing.
3. Proxy authentication
- If WebMarshal is set to use IP based authentication, you can skip this section.
Applications that recognize the proxy server and port settings might not be able to authenticate using the supported methods. In most cases when WebMarshal is set to require account authentication, the method used is Windows Authentication, also known as NTLM.
If you have checked that the application uses the browser's proxy settings, you can remove the need for authentication using the WMProxyLogon application, or the Authentication Bypass Cache. Both of these methods link a workstation to a user temporarily. With WMProxyLogon, any rules that apply for the user will be applied to all requests from the workstation. The Bypass Cache is more flexible and granular, but it requires advanced setup.
- Tip: To quickly determine whether these methods will help, run WMProxyLogon on the client workstation and then use the browser or player to access the content. When testing is complete, exit from WMProxyLogon using the icon in the system tray.
- You can also bypass authentication using the global proxy bypass list (WebMarshal Console > Tools > Global settings > Proxy Settings > Proxy Bypass List). However this option does not allow rule based control, and it requires each URL to be manually entered.
For more details of authentication bypass setup, see the following Trustwave Knowledgebase articles:
- Q12734: Configuring the Authentication Bypass Cache
- Q14348: Configuring Authentication Bypass with WMProxyLogon
4. Protocol redirection
Many multimedia applications use custom protocols and ports by default (not HTTP). Examples of other media protocols are RTSP and MMS. To control these applications with a HTTP filter such as WebMarshal, you close the custom ports at the network edge.
For a list of some media applications/protocols and their custom ports, see Q12021. For general information about streaming media with WebMarshal, see Q12421.
- When you request content, the application first attempts to make a connection on the custom port.
- If this attempt fails, the application falls back to one or more other methods and ports. HTTP or HTTPS is usually the last choice.
- Some media players, in particular Flash based players, first attempt a direct HTTP connection (on port 80) even if a HTTP proxy is configured.
- In nearly every case the player will eventually use the HTTP proxy.
- You may need to set up proxy authentication bypass as described in section 3 above.
- To determine whether the application is actually connecting to WebMarshal, enable full proxy logging for a particular client computer, and check the logs. Note that the Active Sessions listing does not show connection attempts that failed authentication, and it may not show every file associated with a successful session. Be sure to disable full logging as soon as you are finished with testing.
Additional issues
In a very small number of cases, applications or media content sites might not use the WebMarshal proxy. Possible reasons for the problem include:
- A misconfigured server or applet that does not implement the recommended redirections
- An application or protocol that does not define a fallback to HTTP
- An application that has no capability to use a proxy
To analyze this possibility:
- Determine the port or range that the application uses.
- Use software such as Wireshark to set up a packet capture from the client computer, or monitor your network router or firewall in real time.
- Configure full logging in WebMarshal logs.
- Attempt the connection.
- Remember that in many cases it is normal for an application to attempt a direct connection before contacting the proxy, and the fallback process can take a noticeable time (up to 30 seconds is reasonable for debugging purposes).
If you see only connection attempts directly from the client computer to a remote address, you may wish to contact the owners of the content site to report the issue and ask for more information. If access to the content is essential, you might have to open the required ports outbound from your firewall to the specific sites involved. In this case access would not be controlled by WebMarshal.
Any decision on such action is your responsibility. You should carefully evaluate the need and risk.