Showing results for 
Search instead for 
Did you mean: 

Web Protection: Configuring McAfee Client Proxy (MCP) for Web Hybrid

Web Protection: Configuring McAfee Client Proxy (MCP) for Web Hybrid


This document has been written in order to guide in the deployment of the McAfee Client Proxy (MCP). This document has been written primarily for Web Gateway deployments but some of the content will include other products that are commonly used. For those unfamiliar, McAfee client proxy (MCP) is an application that is installed or deployed via ePO on the client workstations. MCP is used to force workstation traffic to the proxies defined in MCP's settings. MCP is also used to forward user authentication information. This authentication information is included in encrypted HTTP headers with each request.



Deployment options

The McAfee client proxy can be used a multitude of different ways. Below are the most common scenarios for its use.


MCP always active/redirecting (Web Gateway and Web Gateway Cloud Service)

In this scenario, it is assumed that you have Web Gateway and the Web Gateway Cloud Service. This will allow you to protect the users with the on-premise Web Gateway (in the network), and when they are off the network, they will be protected by the Web Gateway Cloud Service. Note that this scenario could also apply if you always want to redirect to your Web Gateway (whether user is on or off premise) or always want to redirect to the Cloud Service


In network: MCP Active

Outside network: MCP Active

Network Detection settings: Always redirecting (ePO/ePO Cloud), Corporate Detection unchecked (Control Console)



MCP redirection only on premise

In this scenario we assume a Web Gateway only scenario, you are not using the Web Gateway Cloud Service. MCP will only be active when the users are in the network and will redirect them to your local web gateway. Outside of the network, MCP will stand down.


In network: MCP Active

Outside network: MCP Inactive

Network Detection settings: Always redirecting (ePO/ePO Cloud), Corporate Detection unchecked (Control Console)



MCP redirection only off premise

In this scenario we assume that you are using MCP only to redirect users, when they are outside your network. For example to make sure that laptop users still get filtering when through the Web Gateway Cloud when they take their laptops home. When the users are on premise, they might be filtered by a Web Gateway in your network, but you do not have MCP redirect the users to it.


In network: MCP Inactive

Outside network: MCP Active

Network Detection settings: Redirect network traffic when... (ePO/ePO Cloud), Corporate Detection checked (Control Console)



How MCP Works (Technical Details)

Below is a description of how the McAfee client proxy will check to see whether or not it should be redirecting traffic to the proxies specified in the configuration.


  1. Checks if a proxy server can be contacted, top down until it receives first response.
  2. Checks if the corporate network can be reached. All servers are contacted at once, to prevent any long delays failing down the list.
  3. Checks if there is a captive portal, common in hotel rooms or Internet cafes, which requires user interaction prior to gaining Internet access .


Corporate detection / Traffic redirection settings

Corporate detection (as referred to in SaaS) or Traffic redirection settings (as referred to in ePO), specifies what resources MCP should check for to see if it should redirect traffic. Typically if you do enable corporate detection, you should specify your ePO server, or another server using a port other than 80 or 443.

Detection on

If corporate detection is on, then MCP will attempt to reach the listed network servers or ports. If MCP is able to reach these specified server and ports, then MCP will stand down.


Below screenshots show equal settings between ePO and the SaaS console:





Detection off

If corporate detection if off, then this means that MCP will always be attempting to redirect traffic to the specified proxy servers (assuming all health checks pass).


Below screenshots show equal settings between ePO and the SaaS console:



Proxy check

MCP will attempt to contact the specified proxy servers in order to determine if it is reachable. If not, MCP will stand down.

Captive check

In some cases, the above health checks could be false positives. In certain cases users may be accessing the internet via their hotel room, which often require a login of sorts. This final check will help make sure that access to the internet is valid and the proxy redirection will occur properly.




Prior to deploying MCP it is expected that you have the following setup and ready.


Existing Software

    • ePolicy Orchestrator (ePO) 4.6.1+ - This makes it easier for deploying the MCP software (via the McAfee Agent). This is optional if you are not deploying using ePO.
    • McAfee Agent - If the McAfee Agent is installed on the workstation then this allows ePO to distribute the MCP software. This is optional if you are not deploying using ePO.
    • Web Gateway Cloud Service UI - This is optional if you are not using the Web Gateway Cloud Service. This could be ePO Cloud (newer customers or migrated customers) or the legacy Control Console.
    • McAfee Web Gateway - You must be able to access the Web Gateway user interface in order to add rules and also change settings.
    • Supported workstation to run MCP - Supported environments for McAfee Client Proxy -



    • Shared key/Secret key
      • The shared key or secret key is used by MCP to encrypt the authentication information, which is then decrypted by the Web Gateway or Web Gateway Cloud Service when it receives a users request.
      • Where it's obtained:
        • Web Gateway Cloud Service UI (ePO Cloud/Control Console)
          • NOTE:  If utilizing the Web Gateway Cloud Service, the shared key file must be generated from within the Cloud Service UI, not the Web Gateway UI.
        • Web Gateway UI
      • When it's needed: Depending on your deployment, the shared key file needs to be imported into ePO and/or Web Gateway.
    • McAfee Client Proxy aka MCP (extension and software)
      • Components:
        • Client - Piece that is installed on the client machine
        • Server - Piece that is used on ePO to manage MCP related policies and software
      • Where it's obtained:
      • Why it's needed: To deploy and configure on the client workstations.
    • OPG file (if not using ePO, created in SaaS console): The OPG file is the configuration file for MCP. It tells MCP what proxies to use, as well as other settings.



Configuring the Web Gateway Cloud Service (WGCS)

This section is optional if you do not use the Web Gateway Cloud. For configuring the WGCS all that is required is to obtain the shared key / secret key. This will be used in later steps to configure the MCP policy.


IMPORTANT: If you are configuring the secret key for the first time, it is important that you remember that password that you configure.



In ePO Cloud you'll need to duplicate the default MCP policy and set the shared secret in the Client Configuration:



The customer ID in ePO Cloud is located on the Web Protection > Getting Started Page:



Configuring Web Gateway

In Web Gateway we need to import the authentication ruleset and import the secret key (use the same credentials that were used in the Web Gateway Cloud Service if you have it).


Importing the ruleset

Go to Policy > Rule Sets > Add > Rule Set from Library > [Find "Authentication with McAfee Client Proxy"], import it. Disable it or modify the ruleset criteria to only apply to a specific test workstation.



Configuring the shared key

Go to Policy > Settings > Engines > Authentication > MCP


If you have the Web Gateway Cloud Service use the Customer ID and Secret Key as specified in the SaaS console.  The SaaS Secret Key value should be placed in the MWG Shared password field.


If you do not have the Web Gateway Cloud Service, you can specify any Customer ID and Shared password (Ex Customer ID=1111111111). Be sure to remember the credentials you enter, these are used by MCP and MWG to encrypt/decrypt header information.




Further Considerations

Support Doc: Authentication Examples by Deployment Method:



Configuring ePO and Deploying MCP

Skip this if you are not using ePO to deploy MCP (read this instead - How to implement McAfee Client Proxy without ePolicy Orchestrator -, How to manually load a policy into McAfee Client Proxy - Prior to working with MCP you must deploy the software to the workstations you wish to have MCP do its thing.


Installing MCP extensions (ePO Package)

In the MCP download, there should be a number of folders, Client, Documentation, and Server. The "Server" folder contains the ePO extension that will allow us to manage the MCP software once its deployed. Without this installed ePO will not know how to manage the MCP software.


To install the extension login to ePO, navigate to Menu > Software > Extensions, then click "Install Extension" in the bottom left corner.




Installing MCP software into the Master Repository

The "Client" folder should contain a number of folders, underneath you should find one called "Signed_Package", this contains the software package we need to check-in to ePO.


To check-in the package, login to ePO, navigate to Menu > Software > Master Repository, then click "Check In Package". Then browse for the file in the "Signed_Package" folder.




Create a deploy software task for MCP

In order to begin deploying the software you must have the McAfee agent installed on the workstations. This will assist in installing the software.


In order to install the software to the workstations in your environment, a software task will need to be created. This task can be applied to a group of workstations, or a single workstation.


Login to ePO, navigate to Menu > System > System Tree.


Select a workstation or group of workstations to apply a task.


Once the workstations are selected, click Actions > Agent > Run Client Task Now, this will open a new dialog (see below).


7.3.1_epo-deploy.png 7.3.2_epo-deploy.png



Configure MCP Policy

Now that MCP has been deployed to the workstation you can configure a policy for it.


With ePO

Login to ePO, navigate to Menu > Policy > Policy Catalog, then select "McAfee Client Proxy" from the "Product" dropdown.




Click edit for the "My Default" policy. This will be the policy that is pushed out to the clients.


8.1.1a_epo-mcp-policy.png 8.1.3a_epo-mcp-policy.png 8.1.4a_epo-mcp-policy.png


Without ePO (with Control Console)

In order to configure the MCP policy within the SaaS console, you must navigate to Web Protection > Policies > McAfee Client Proxy Policies, then click New/Edit to configure a policy for download and use within MCP.


2.1.0_saas-policy-settings.png 8.2.1y_saas-policy-settings.png  8.2.2_saas-policy-settings.png8.2.3_saas-policy-settings.png 8.2.4y_saas-policy-settings.png


Deploy MCP Policy

In order for your settings to take effect on MCP you must push them to the client, this is easiest done with ePO.


With ePO

To deploy the policy, you will need the McAfee Agent installed on the workstation as well as the MCP software. Assuming all of the prerequisites are met, then it is just a matter of waking up the agents.


9.1.0a_epo-deploy-policy.png 9.1.1x_epo-deploy-policy.png



The MCP policy file should now be on the workstation, and the configuration should be active. To verify, check you can check the McAfee Agent page or registry:


9.2.0x_agent_about.png 9.2.1b_regedit_about.png


Without ePO

To deploy the policy without ePO check out the KB article on the matter: How to manually load a policy into McAfee Client Proxy -




Below is a list of common items that you may want to check for when using MCP.


Checking policy version

It is always a good idea to check the policy version in ePO, to make sure it is the same version that is on the client. If the client is not receiving the most up to date policy file, then they could be being directed to old proxies, or bypasses may not take effect as expected.


In ePO

To check the version information in ePO simply navigate to the MCP policy. This can be found by navigating to Menu > Policy > Policy Catalog, then select "McAfee Client Proxy" from the "Product" dropdown, then select your policy. In the bottom left corner there is an "Actions" button, this will allow you to export the policy or view the version. See screenshots below:


On the client

Once you have checked the policy version in ePO, you should check the version on the client. This can be done in the McAfee Agent about page, or from the registry. See screenshots below:




How to view McAfee Client Proxy Status without the McAfee Agent -


Log locations


# MCP Log Files:

-Mcp.log (McAfee Client Proxy main log file):

   %ALLUSERSPROFILE%\McAfee\MCP\Logs (WinXP/Vista/Win7)

   C:\Documents and settings\All Users\Application Data\McAfee\MCP\Logs (WinXP)

   C:\ProgramData\McAfee\MCP\Logs (Vista/Win7)


-Mcp.log.1 (McAfee Client Proxy rollover log file):

   %ALLUSERSPROFILE%\McAfee\MCP\Logs (WinXP/Vista/Win7)

   C:\Documents and settings\All Users\Application Data\McAfee\MCP\Logs (WinXP)

   C:\ProgramData\McAfee\MCP\Logs (Vista/Win7)


# MCP Policy Files (from client and ePO):

-MCPPolicy.opg (Current policy file (protected by access protection))

   %ALLUSERSPROFILE%\McAfee\MCP\Policy (WinXP/Vista/Win7)

   C:\Documents and settings\All Users\Application Data\McAfee\MCP\Policy (WinXP)

   C:\ProgramData\McAfee\MCP\Policy (Vista/Win7)

-MCPPolicy.opg (Temporary policy file (protected by access protection))

   %ALLUSERSPROFILE%\McAfee\MCP\Policy\Temp (WinXP/Vista/Win7)

   C:\Documents and settings\All Users\Application Data\McAfee\MCP\Policy\Temp (WinXP)

   C:\ProgramData\McAfee\MCP\Policy\Temp (Vista/Win7)



Group related features and off-network problems

McAfee Client Proxy sends group information to the proxy it is communicating to. In some cases a user may be apart of a large number of groups (which are not important for web filtering) OR MCP may not be able to determine the groups.


Group inclusion/exclusion

MCP has options to include important groups, or discard insignificant groups. This is configured in the "Client Configuration" section of the policy.


Some companies create special group memberships which grant you specific types of access to the internet. So if "jsmith" is apart of "Internet Relaxed Users", then he receives different filtering from "jdoe" who is apart of "Internet Strict Users".


To check the groups of a user one can run the command "whoami /groups" or "gpresult /R /SCOPE USER":


>whoami /groups





Group Name





BUILTIN\Certificate Service DCOM Access

BUILTIN\Pre-Windows 2000 Compatible Access



NT AUTHORITY\Authenticated Users

NT AUTHORITY\This Organization


VEGAS\Internet Relaxed Users <------------- INTERESTED GROUP

VEGAS\Group Policy Creator Owners

VEGAS\Domain Admins

VEGAS\Enterprise Admins

VEGAS\Schema Admins

VEGAS\Denied RODC Password Replication Group



The below screenshot shows an example of inclusion, whereby we instruct MCP to only send groups which start with "VEGAS\Internet", using the regular expression "VEGAS\\Internet.*" in the filter.




The below screenshot shows an example of exclusion, whereby we instruct MCP to discard groups which start with "BUILTIN\", "NT AUTHORITY\", and "LOCAL", using the regular expressions of "BUILTIN\\.*", "NT AUTHORITY\\.*", and "LOCAL" in the filter.




Groups are not sent by MCP

As stated, MCP will forward group membership information to the proxies that are configured in the policy. If the user has not logged into the corporate network recently, then MCP may not be able to resolve the users' group memberships. This can cause issues for the relying proxy if it performs filtering based on group membership.


To resolve this, one must perform a group lookup based on the username given by MCP. See the following modified MCP ruleset from .


For more information see: Web Gateway: Unable to filter on Active Directory groups after Client Proxy user disconnects from domain -




By reading this article you should now understand the use cases for MCP, how to deploy and configure the policy and troubleshoot MCP.




2017-12-08 - Cleanup verbiage, more revisions required

2015-01-09 - Updated groups section to include notes about group inclusion/exclusion.

2014-12-30 - Modified "further considerations" text. Added references to group membership lookup ruleset from authentication examples by deployment guide.

2013-06-26 - Initial release.

Labels (1)

You now have two options when defining how MCP uses the proxy list defined in the policy.

1) First available: Each proxy is tried in order top down, until one of them can be reached. If none can be reached MCP deactivates itself and will try again later. If a proxy becomes inoperative, the next one on the list is tried. MCP will not try the previous proxies again unless there is a network configuration change on the client, or none of the proxies can be reached.

2) Lowest latency: The client will try all proxies in the list and choose the one with the fastest response time. In all SaaS environments it is recommended to use this option and list each of the SaaS datacenters by name rather than using the anycast address. Again MCP will only reevaluate the selected proxy if the current proxy becomes unavailable or if there is a network configuration change on the client.

There may be situations in a hybrid environment where you do not want MCP to use the lowest latency path because the lowest latency path may be to an MWG accessible only via an expensive WAN link. This situation can be handled with a single MCP policy by using the network protection features of the web gateway do deny access to the proxy port for source IPs that are on the other side of those expensive links.

For example imagine if you have an internal network with locations in Tokyo, Sydney and New York and all three are connected by WAN links and you have gateways in New York and Tokyo and you have mobile users that travel to all three sites. When in Tokyo you want the user to use lowest latency of Tokyo gateway or cloud, when in Sydney you want them to use cloud, even if Tokyo MWG is lower latency, and when in New York you want them to use the lowest latency of New York gateway or cloud. Simply use network protection rules on the New York gateway to only allow New York address space to use the New York proxy and Tokyo address space to use the Tokyo proxy.

Then your MCP policy can be the same for all mobile users:

Choose Lowest latency path from:

New York MWG IP

Tokyo MWG IP

Tokyo SaaS Datacenter

Denver SaaS Datacenter 1

Denver SaaS Datacenter 2

London SaaS Datacenter

Amsterdam SaaS Datacenter

Sydney SaaS Datacenter



Hi Jon Scholten,

MCP redirection only off premise. In this scenario users will be redirected to get filtering through the SaaS Web Protection when they are off premise.

I have query here:

  1. What if i don't have a SaaS Web Protection? Still i want to filter my user traffic when they are off premise. How I can achieve?

Please let me know.



Hi Prasanth,

What's your means for filtering them off premise? Are you going to route them over the internet to your publicly available MWG? If so that's possible but it must be done carefully to avoid an open proxy on the internet.

Or do you have something like SiteAdvisor to filter them while they are out of the office?

Best Regards,



Hi Jon Scholten,

Thanks for the reply.

if i want to filter the off premise users, i need to route them to my DMZ and i need to place a MWG in DMZ with proxy open ports?

No I don't have any SiteAdvisor.

Hi Prasanth,

Thats correct.

Best Regards,


Hi Jon Scholten,

I have got a small query, if i want to filter the off premise users, i need to route them to my DMZ and i need to place a MWG in DMZ with proxy open ports, so what if I place my McAfee web gateway in LAN and NAT the IP address and port from my DMZ firewall, will this work?

kindly clarify?




hi Jon Scholten,

Can you please clarify on this?



Tomato/tomato? They both sound the same.


Hi Jon Scholten,

I mean if I place my MWG in LAN and NAT the IP address & port on the firewall, can i filter  the off premieres traffic?


Yes, that is how you would do it.

Just port forward 9090 (or port of your choice) from the external IP to MWG's internal IP. You would not want to put one of the MWG NICs directly onto the internet. (you need to take extra precautions if you did that with firewall rules.)

One thing to point out that Jon also mentioned is you want to make sure the rules only allow authenticated traffic, so it's not an open proxy for the world.

And make sure you have rules that prevent proxying to your inside IP addresses (,,, etc). You don't want people coming in from the outside to you internal systems.


Are there restrictions on the characters than can be used in the Customer ID or password for CustomerInfo.xml?

Hi Kbolt,

I believe early on there was but those issues should have been resolved. Let me know if you're seeing otherwise.

Best Regards,


I attempted to use an underscore in my Customer ID. after importing the CustomerInfo.xml into a policy and deploying it to MCP endpoints, no custom HTTP headers were seen coming from the MCP endpoints based on my tcpdump captures from a test endpoint and from MWG appliance.


Is there any way to explicitly exclude an exe from having its traffic forwarded to MWG? Or specific traffic?

HI Kbolt,

That should be done in the bypass lists, you can do it by process name, domain name, ip, or port.

Best Regards,



Thank you, Jon. I assume you mean the bypass lists inside MWG's rulesets where whitelists can be created to stop the cycle upon seeing certain criteria, or is there a bypass list to consider in the creation of an MCP policy within EPO?

In the MCP Policy is what I meant. See above this is where you can create list of IP's, domains, ports or processes.


Ah, I see what you mean now. I had to get in touch with the EPO admin to get the necessary permissions to use this list. Thanks for the information. Saving lives.



Here is a feedback after almost 2 years of MCP usage, in the "always redirecting mode" (to on premise web gateways or the Cloud Service).

Important note: we need to use a PAC file in addition to MCP because our users need to be seen from specific public IP addresses for some specific partners (selecting different proxies for different sites is not possible by only using MCP).

Basically, our PAC is sending "DIRECT" (so no explicit proxy) for all sites except a handful.

In short, it is working pretty well except that:

- when choosing "Lowest latency" as the proxy selection option, MCP does NOT connect to the first proxy answering the requests to check latency (which is the way I would have done it), but waits for all proxies to answer before selecting the fastest. This means that you cannot have a very long list of proxies as if only one is not answering, MCP will wait until the request times out before redirecting (making ALL users unable to surf for seconds at browser startup)

- It is not advised to have more than 20 entries in the MCP Policy. So you have to set up a lot of MCP Policies if you have a lot of proxies

- you don't have a "Global Catalog" for all MCP Policies, so when you want to bypass something for everyone, you have to do it in all your policies manually one by one

- you cannot use wildcards in the MCP blacklists or bypasses, you have to use exact matches for domains. For instance, you cannot bypass * or *

- MCP + Cloud filtering heavily relies on DNS requests. If your external DNS requests do not go out on your users' country (i.e. if you use centralized DNS for multiple countries), your users will not be correctly geolocalized, thus will not use the intended Point of Presence

- Skype for Business is not working at all when using MCP + on premise proxies

- Multiple Java based sites / webapps (typically banks apps with Smartcard authentication), interpreting the PAC file, are not working with the MCP interception

- Internet Explorer considers all sites as Intranet, so "Compatibility mode", if not set correctly, may be activated for all sites (internal and external) and breaks a lot of them

- All sites are considered as Intranet by Internet Explorer, which thus applies the "Local intranet" security level to Internet sites. This can be very dangerous as usually the security settings are much lower for this zone.

- MCP logs are only readable by McAfee, since MCP 2.3 (as designed it seems). It was plain text before, so we could use it to debug. It is not possible any more. It should change again when MCP is fully integrated in ENS I guess.

- MCP nor McAfee Client Proxy is not recognized in the McAfee support site as a "Product". You have to open Service Request for Cloud filtering or web gateways to deal with the MCP issues, which is always taking an additional step + delay when you have a MCP issue

- if you have a MCP policy that is too long, a scrollbar will appear in the "MCP About" window, totally hiding the "Status" (you have to "copy to clipboard" and paste to read it...)

That's my 2 cents.

Correct me if you think we have done something better of course.


@Belvincent, great observations.

On your last item, note that you can sometimes click-and-hold on the MCP text and scroll down to see the Status.  Generally once you've scrolled once, you are out of luck.  I only see this on Windows 7 -- on Windows 10 the dialog is tall enough to show the Status line.

I just opened a case to get clarity on subdomain bypass entries and wildcards -- the documentation provides no details.  It seems like a single-level works as a wildcard ( but subdomains ( do not.

The lack of a Global Catalog is a pain with multiple policies.

We have also encountered the issues with Skype for Business and ended up excluding the processes "lync.exe" and "UcMapi.exe" to fix it.

We have had to exclude a number of other apps and website java applets as you noted.

We ended up using MCP to fill a particular use-case, but I am getting close to proposing we go back to proxy.pac for all users and have MCP in place only for mobile (laptop, Surface) users so we can leverage the SaaS filtering for them.  From a desktop perspective, I'm not sure the extra features are worth the extra configuration and work.

You noted you are using a proxy.pac AND the MCP.  How are you making that work? We have always found that setting a proxy.pac in the Internet Options overrides MCP.

MCP can be used in conjunction with proxy pac simply by intercepting the destination port used in the destination proxies specified in the PAC file.

Version history
Revision #:
2 of 2
Last update:
Updated by: