Using the ICAP plugin on the ISA server has some inherent limitations, mainly you can't do SSL decryption/scanning.
The approach to have MWG first, then place ISA inline as a default gateway has challenges that you have discovered.
Have you tried to setup ISA as a Next-Hop proxy instead of as a transparent gateway?
I have not tried that, but I will. Thanks!
I built up a test ISA server last night and tried to discover exactly what ISA can use in the headers. What I discovered was, ISA doesn't do much.
1) MWG can send "X-Forwarded-For: 22.214.171.124" headers to ISA, but ISA has no ability to do anything with them. There is a plugin you can buy that will decode and use them, but the price tag is probably cost prohibitive. (winfrasoft.com)
2) MWG can send usernames and groups in a header to ISA, but again, ISA can do nothing with them.
So that idea is out.
That leaves you with using MWG as an ICAP server to ISA or Using MWG as the Next-Hop proxy from ISA.
Needs the ICAP plugin that we provide, but I don't like this method because:
* It makes 2 requests to MWG for every one request to ISA. One to do the URL filtering and one to do the Malware scanning.
* It cannot use SSL scanning.
I like this method the best and have used it before. You setup Web chaining from ISA to MWG as a next hop proxy.
* Still needs the plugin to put X-Forwarded-For:, X-Authenticated-Users and X-Authenticated-Groups Headers into the request, but MWG can parse those and apply policy based on those values.
* ISA does the authentication and just sends the names/groups to MWG.
* It's a cleaner method.
The only caveat is people with ISA servers usually intercept the web traffic as a default route to 80/443 because ISA thinks it's a firewall. This causes problems with Next-Hop proxies because ISA doesn't re-assemble the request for the next upstream exactly like it should. (It puts an IP address in the request instead of the host name) This can break some sites and wreaks havoc on SSL decryption.
If you do this, make sure you are using explicit proxy from the client to ISA, then ISA can forward the request properly to MWG. You are using an explicit proxy to MWG anyway, so it's just a different IP address in the browser.
I'm now using the method of ISA->MWG with MWG as the next hop proxy to ISA and using the ISA plugin. ISA is my firewall, so I'm routing MWG via its default gateway, back to ISA. ISA has a rule to allow all traffic from the IP of the MWG so it can pass this traffic off to the web. I did have to setup a 2nd specific rule to allow just HTTPS (SSL) traffic from the MWG trough ISA. The rule I had setup that allowed "all protocols" didn't seem to like SSL traffic.
My only isue now is that I'm getting random promts for authentication from ISA when my users are browsing the web. They can cancel the authentication request and all is well, but it's a pain. I don't think this is from the original pass through ISA as the clients proxy because this is the way I always had them connecting before McAfee. My guess is it is happening on the 2nd pass back trough ISA from MWG, but I'm not sure why at this point.
The best news is that my bandwidth managing software on ISA now works again as well as both my ISA and MWG rules.
There should be no authentication turned on MWG at all. The authentication should be entirely on ISA and passed to MWG in the headers. If that is the case currently, then I cannot explain why you are getting sporadic prompts. It is likely with the second loop from MWG to the internet, but not really sure. Make sure you have rules positioned at the top of the lists that allow all traffic from MWG out. It may be below the other rules and the proxy rules are intercepting it inadvertantly.
I also didn't explain how the headers are used in MG to make policy decisions on, so here is some more information:
Configure the plugin to include the headers:
Now you need rules on the MWG to read those headers so you can use them later:
These rules are attached.
At the end of these rules, you have 3 variables that can be used to make rules with:
So you can have rules elsewhere that can use conditions like:
User-Defined.X-Authenticated-User equals "user1"
User-Defined.X-Authenticated-Groups matches *Domain Users*
String.ToIP (User-Defined.X-Forwarded-For) is in range 192.168.2.0/24
NextHop from ISA.zip 1.4 K
Erik - Thanks for the great information on using ISA with MWG7 as a next hop proxy. This seems to be working great. I did find that when logging into sites like facebook.com that switch to https for the login, that ISA seems to lose the authentication. If I check the "Require all users to authenticate" box on the Internal network in ISA, then it seems to be happy. I know I turned this off many years ago, but I'm not sure why. I'm sure I'll find out soon!
Since I'm not an ISA expert, I turned on the "Require all users to authenticate" also.
My guess is there is a rule that defines "http" as a protocol with your authentication turned on, but not one for "https". I don't know enough about ISA to know how to do that, but it seems that you should be able to add another rule to do so.