We help IT Professionals succeed at work.

Proxy Forefront TMG

Hi Peeps,

We have an environment with Server 2008R2 and have decomed the old proxy server.

On this we used proxy pac files. We currently have implemented a forefront TMG/UAG solution. the WPAD and Pac scripts seem to give no end of issues.

I wonder is there a way I can get the users systems to operate without this? just route all to the web server directly rather then use these scripts?

the only other consideration is we do use Direct Access connection for machines off site (Road warriors) . they usually have split tunnelling enabled when connecting previously via vpn sessions so not to use our internal proxy services.

I always thought systems could be set to automatically discover and be forced to the proxy\web server gateway. it seems we need all these rules to go here or there in the script files. when its pretty straight forward.  These scripts have issues with multiple browsers and some sites with www root zones rather then A records where there are good delays.

I am not confidant of a managed approach with the contractors as it seems to be try this and that until this works and that breaks.

any advice welcome. I will be seeking another external service providers assistance with this soon as its been going on for far too long.  but hope to find some kind of advice to lead me into the right direction.

points shared if answer/solution offered from multiple sources.

AJ
Comment
Watch Question

Keith AlabasterEnterprise Architect
Top Expert 2008

Commented:
Please clarify -
You have a UAG implementation and - then, on a separate server, you have a TMG server so two different boxes ... or you are talking about a UAG server only (because UAG comes with its own TMG copy which is used to just protect the UAG box itself)?

Author

Commented:
sorry they are the same server.

Keith AlabasterEnterprise Architect
Top Expert 2008

Commented:
OK - so you haven't bought TMG 'as a product', you have purchased UAG.

When Microsoft brought the UAG into its portfolio, their reasoning was to divide the coverage into two. TMG was to be used to cover outbound access with support for application publishing whereas UAG was to focus on replacing inbound access to services - all things remote access in simple terms. However, there was a threat to the UAG box itself so MS installed a local copy of TMG onto the UAG box to mitigate that concern.

What this means is that you shouldn't use the TMG services in the same way that you would if it was purchased and installed on its own server. Everytime UAG is configured (or an aleration is made to its configuration) you have to run a configuration-builder that validates the settings chosen - it also rewrites the TMG rules -every time - to ensure that the TMG is best configured to protect the UAG box whilst allowing the UAG to operate as per the new settings you have entered.

As you can imagine, trying to use this TMG installation as a 'normal' TMG server would be impratical - and unsupported - because changes that YOU made to the TMG config could a) cause problems for the UAG configuration in that UAG services may stop working and b) open up the UAG serveer to security loopholes making it unprotected itself.

People HAVE got this configuration to work in simple scenarios but it is normally painfully slow, a nightmare to administrate and is not a supported endgame. UAG is truly brilliant - as is TMG but they are two different products - and with two different functions. If you think about it, that is why they are sold separately - if you got a full, usable version of TMG (in the normal sense of the product) free with a purchase of UAG licenses, Microsoft would not sell TMG separately as an alternative licensed product - who would ever want just the one product if they could get two?

I will make some changes to my own system (I run two separate servers at home - one for UAG as I use Directaccess also and an internal TMG box for proxy functions) and see what I can do. Have you got a sanitised version of your .pac file you can attach?

Keith

Author

Commented:
Thanks for that info Keith,

The question though (and perhaps I made it not clear) was how I can have my users best access the web. Manual proxy is not something I want to set on their Browsers.

We have a TMG inside and one on the DMZ. UAG is also on DMZ. part of the TMG server.

The issue is we have auto proxy configured by Group Policy and the Proxy pac and wpad files are how the dns is resolved. is there an alternative better solution then using the pac and wpad files?

The websites that are affected are when visited are caused by DNS resolution when the DNS Cache Lookup has the WWW entry as a folder and not a CNAME record.

Im looking to see how people utilise proxy configuration within their environment.

AJ
Enterprise Architect
Top Expert 2008
Commented:
OK - the options are (and each of these can be set by group policy so no mucking about with manual stuff):

1. Set a specific entry into the browser for the name/ip address of the TMG server ( you can actually set two for resilience).
This is the worst option - whilst it is no issue for fixed/dewsktop users, it is a nightmare for laptop users who will need to tick/untick the proxy settings box when ever they are out of the office and want to flick between VPN use and straight internet connections.

2. The Use automatic configuration script option. I find this the best setting as - personally - I find it the most customisable. It involves creating a .pac file and hosting it on any internally accessible web server and here you can decide settings based on a users source ip address, destination web site, type of access, set multiple proxy server entries for resilience etc. No issue for desktop users - and great for laptop users because when they are out and about they will not be able to access the internally .pac file... this means that their browser acts as if no entry was set in the browser proxy box. The entry might be something like http://internal_webserver/proxy.pac

You can see an example of a .pac file in one of my previous solutions
http://www.experts-exchange.com/Networking/Windows_Networking/Q_25769612.html?sfQueryTermInfo=1+10+30+alabast+keith+proxy.pac

3. You can use the Autodetect option (Windows Proxy AutoDetect) which works in a similar fashion but I find painful. Not because it is more difficult to configure but more that if the settings can be located the browser can take quite a while to realise it is not available before continuing.
Again, the settings can be distibuted by group policy or you can use the 252 entry within a DHCP scope and deliver it via DNS.

Option 2 is my preference but others may have different views - at the end of the day it is down to what works best for your business requirements and meets your security policy.

Author

Commented:
Thanks for the detailed info
Keith AlabasterEnterprise Architect
Top Expert 2008

Commented:
No problem :)