The question on how to handle DirectAccess clients and Internet security for those clients is always a popular topic. As I’ve mentioned many times in this blog, the overall threat and management profile of the DirectAccess client should be little different than a client that is on the intranet.
However, there is one major difference between the intranet client and the DirectAccess client – and that’s an Internet gateway that protects the client from Internet threats with URL filtering and web antimalware.
With this in mind, the following question is topical and I’ll use it to drive the discussion.
====================================================================
“UAG providing direct access over HTTPS to a large set of demo computers in retail stores. They are a wireless ISP so all the computers in the offices are connected directly to the Internet, rather than a corporate network. We are using DA to manage group policy on the demo boxes to ensure they are tightly locked down.
We have a need to also provide some sort of content filtering/web site blocking on these boxes. One thought is to leverage UAG to act as a filtering proxy server for these boxes. The customer is concerned about using UAG “normally” because traffic would then flow across the DA/HTTPs link which would be the slowest option and may impact the performance of these demo boxes. Thus they would like to configure their UAG box to act as a proxy server out on the Internet with some authentication for clients to connect.
So my questions to the group are:
- Is this totally crazy?
- Can this be done in a supported way?
- Is there a better way for them to do this”
====================================================================
First we have to get clear on the scenario. It sounds like these machines are configured as DirectAccess clients and are configured to use IP-HTTPS to connect to the UAG DirectAccess servers. It’s not clear why this is being used instead of 6to4 – maybe there is a device in the path between these DirectAccess clients that blocks IPv4 Protocol 41. What it appears they want to do is provide some gateway based security for these clients. The proposed idea is to use the UAG DirectAccess server as an outbound proxy for the DirectAccess clients. There are two problems with this possible solution:
- It’s not supported
- It won’t work
Given those two facts, we need to think of some other way to enable Internet gateway security for these clients. This is what I’d propose:
- Enable force tunneling on the clients – this will force all traffic, including Internet bound traffic, through the DirectAccess tunnels
- Consider configuring the browsers on the DirectAccess clients to use a web proxy. You can configure the proxy address in the UAG DirectAccess wizard
- Consider configuring the DirectAccess clients to “bounce” off the UAG DirectAccess server to reach the Internet
- If the second option is chosen, then configure the UAG DirectAccess servers with a gateway address that will force the outbound connections through a URL filtering and antivirus gateway
The figure below shows what the request path would look like when you configure the DirectAccess clients to use a Web proxy. Note in this scenario that you can have the outbound connection use a different gateway to the Internet than the one used by the DirectAccess server itself.
The figure below shows what it looks like when you configure the DirectAccess clients to “bounce off” the UAG DirectAccess server. The difference in this case is that the web filtering gateway is most likely going to be in a DMZ. You will need to be careful here, because the DirectAccess server can only have a single default gateway, which means that the web filtering gateway is going to need to be in the DirectAccess request/response path between the DirectAccess client and server. In the figure below, you can see that the outbound connections are leaving through the same firewall that they DirectAccess tunnel connections came in through.
If you want to see how this configuration works in a test lab, then check the Force Tunneling Test Lab Guide. You can find a complete list of Test Lab guides at http://social.technet.microsoft.com/wiki/contents/articles/test-lab-guides.aspx
HTH,
Tom
Tom Shinder
tomsh@microsoft.com
Principal Knowledge Engineer, Microsoft DAIP iX/Identity Management/ICG
Anywhere Access Group (AAG)
The “Edge Man” blog : http://blogs.technet.com/tomshinder/default.aspx
Follow me on Twitter: http://twitter.com/tshinder
Facebook: http://www.facebook.com/tshinder
Yuri Diogenes and I have worked together on a number of projects over the years – last year we published three new books on TMG, UAG and Forefront Security for Exchange. You can find more information on these books on Yuri’s blog at http://blogs.technet.com/b/yuridiogenes/archive/2010/07/08/new-forefront-books-by-microsoft-press.aspx
