Hello all, quick question. My current McAfee Client Proxy policy has the following traffic redirection setting:
Now based on the wording of the options, it seems my choices are either
1. Have MCP agent try to send traffic to the proxy ONLY when users are not at work, OR
2. Have MCP agent try to send traffic to the proxy ALL of the time (when users are at work AND when users are offsite)
These two options leave me wondering if there's anyway I can only have traffic forwarded when users are onsite. MWG is primarily to meter user's bandwidth usage so while users are at home with their laptops, I'd not want to police that (not just yet anyway). Is there any way I can achieve onsite only traffic redirection? (I'm also asking because I've seen where a user's laptop always tries to make TCP connections to proxy and so sometimes causes issues.)
You can use the first option and setup as example google.com on port 80. When it's reachable the MCP wont redirect traffic. What means when user is at home the traffic is not redirected.
Requirement: direct access to google.com:80 should be blocked in your office. (you can use any other services on the internet)
This is a good idea. I'm going to try it out with the public IP addresses of some of our hosted sites. Those are completely blocked from inside (inside uses the private address) but available form outside. I think trying to actually load the HTTPS page via its IP address will fail so I hope MCP agent just needs the IP address to do a basic response.
you may can do this with time based rules in the Firewall?
So, if MCP is not able to connet to a Proxy it will disable itself automatically. Maybe time based rules will really help.
Always redirect means that MCP will redirect always assuming the proxy is reachable.
If you put in a hostname like proxy.kbolt.com, then they will likely not be able to reach that DNS name from home (unless you have it on public DNS).
So I'd suggest configuring it with Always Redirect and just specify the proxy hostname. I suggest hostname because failure to resolve in DNS is quick, where as failure to connect to an IP (SYN SYN SYN) is a bit slower.
So if a PC is off of the corporate network, the MCPservice.exe will be unable to contact the proxy server (e.g. proxy.kbolt.com) and will then allow all traffic to flow as normal, sans proxy. This is what I initially thought would happen with MCP, and based on some TCP dumps I captured with a laptop on and then off the corporate network it does seem to be the case. However, I've found the odd one or two exceptions where the attempt to connect to the proxy seems to take a long time before failing. I'll consider your suggestion of using the proxy's hostname and push that to a test group. Thank you for the feedback.
In the off-network tcpdumps, did you just see SYN SYN SYN (a connection attempt, but it failed) or did you see the three way handshake? If you saw the handshake, then some network device must be taking the handshake (like a captive portal).
Using the DNS name should fail faster than using an IP as mentioned above because only your corp network should resolve proxy.kbolt.com (I'd guess).
Just some other questions.
If you are using SaaS proxies (maybe) take a look at https://trust.mcafee.com.
SANS Proxy -> do you mean the McAfee SaaS proxies?
We are using MCP at several customers. I saw your problem with slow proxy selection with older MCP versions and many proxy entries in the policy. But this is also fixed with newer versions. So, your problem looks unusual.
Our latest tests are showing, MCP is really disabling itself automatically if no configured proxy system is available. Also, if the user enters a proxy in the browser settings, MCP disables itself automatically and absolutely fast.
Just another question. Are you using Interface Bonding with your internal McAfee Proxy systems?
Download the new ePolicy Orchestrator (ePO) Support Center Extension which simplifies ePO management and provides support resources directly in the console. Learn more about ePO Support Center