Making WebEx Work With An Enterprise Proxy

As an administrator of enterprise systems you expect products/software you deploy and maintain to just work but we don’t live in a perfect world and the occasional bug will happen. One such bug caused me and my colleagues trouble for nearly 6 years and since I am positive others are having this issue (as proof by a simple Google search) I wanted to provide a work around that have proved successful for us.

In my early days at JTV I deployed Microsoft’s ISA product for our browsing proxies and have since upgraded to the new version, Threat Management Gateway (TMG). This solution has worked fairly well for all but one application, WebEx, which would prompt for authentication credentials continuously. My fix on Windows system was to install the ISA/TMG firewall client and configure Java to use a “Direct Connection”. There is no equivalent software for the MAC and despite creating proxy rules to let a MAC users system browse the internet freely without authentication their problem still persisted.

With a rise in the number of MAC users at JTV and a corporate decision to use WebEx for conferencing with an international office the pressure was on to make WebEx work for MAC users and I was granted time to research and fix the issue. Knowing that the old tricks I had tried would not work I had to look in another place and found the issue to be with the Proxy PAC file we use to instruct our clients on how to access network resources through the proxy. The PAC file is java script that a client (browser) executes with each request to determine how to access the requested resource; the script is processed in order. Take this simple script as an example.

function FindProxyForURL(url, host)
{
        // Direct connections to non-FQDN hosts
        if (isPlainHostName(host)) ||
           (host == "127.0.0.1") ||
           (host == "example.local") ||
           (shExpMatch(host, "jtv.com")) ||
           (isInNet(host, "192.168.0.0", "255.255.0.0")) ||
           (isInNet(host, "10.0.0.0", "255.0.0.0")))
        {
           return "DIRECT"
	}
	else
        {
          return "PROXY proxy.example.local:8080"
        }
}

The script in this example should send any traffic not specifically excluded to the proxy defined at the end of the script and as you can see no traffic going to the WebEx domains are excluded. While reviewing the proxy logs I was seeing traffic to WebEx domains when MAC users attempted to establish a WebEx connection yet there were no errors and the session never connected. A packet capture revealed that after this initial burst traffic to WebEx the WebEx client was trying to make a direct connection and was trying to bypass the proxy entirely; direct connections to the internet are not allowed in our environment so there is no way this would ever work. Researching this problem on the internet I kept reading that the function isInNet() is known to not work with some versions of Java and it’s called a few times in our PAC file. Since we already know the PAC file is processed serially I thought if I sent WebEx traffic to the proxy before calling isInNet() in the script that would solve my problem and testing proved that had been the culprit all along. Here is an example PAC file that’s also been re-worked a bit by my coding genius of a boss that solved this issue:

function FindProxyForURL(url, host) {
	if (isPlainHostName(host))
	{
		return "DIRECT";
	}
	host = host.toLowerCase();
// Work around bug in unknown piece of MacOSX or cisco Meeting Center
	if (shExpMatch(host, "*.webex.com"))
	{
		return "PROXY proxy.example.local:8080";
	}
// If specific URL needs to bypass proxy, send traffic direct.
	if ( shExpMatch(host, "*.example.local") ||
	     host == "jtv.com" ||
	     host == "127.0.0.1")
	{
		return "DIRECT";
	}
// If IP address is internal or hostname resolves to internal IP, send direct.
	var resolved_ip = dnsResolve(host);
	if (
		isInNet(host, "10.0.0.0",  "255.0.0.0") ||
		isInNet(resolved_ip, "192.168.0.0",  "255.255.0.0")
	   )
	{
		return "DIRECT";
	}
// All other traffic uses below proxies, in fail-over order.
	return "PROXY proxy.example.local:8080";
}

After making this change all of our WebEx/Proxy issues were solved which for me was much cause for celebration since this had been an issue for 6 years that I, a dedicated Windows guy, had blamed on the MAC for not being fully Enterprise ready but as it turns in out in this particular case that’s not the issue. It is worth mentioning that as with most Java applications only Basic proxy authentication is supported so if you’re in an environment does not allow authentication packets to be sent in clear text (which I hope that’s the case for everyone) you must create a proxy rule that allows traffic to *.webex.com to pass without requiring authentication else you will get the dreaded authentication loop. I can also confirm this fix also works for Windows clients as well and there is no need for the ISA/TMG firewall client any longer to overcome this issue.

I sincerely hope this helps others in the community that have been battling this issue; I have yet to see any single post that puts all of this together in one place specifically as it relates to WebEx; only pleas for help from users having the same issue.

-Kevin N.

This entry was posted in Systems & Infrastructure. Bookmark the permalink.

4 Responses to Making WebEx Work With An Enterprise Proxy

  1. Kevin says:

    Thanks for the info. I was having the same issue and this fixed it.

  2. ILovFriday says:

    So happy I was able to help!

  3. forum says:

    An interesting discussion is worth comment. There’s no doubt that that you should write more about this subject, it might not be a taboo matter but usually people don’t talk about such subjects.
    To the next! Kind regards!!

  4. Keyword2 says:

    Hey there! This post could not be written any better!
    Reading through this post reminds me of my old room
    mate! He always kept talking about this. I
    will forward this write-up to him. Pretty sure he will have a good read.
    Thanks for sharing!

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s