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.
- Which version of MCP you are unsing?
- Which proxy port are you using?
- Any other McAfee security products installed on your endpoint?
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?