ISAserver.org - March 2010 Newsletter

-------------------------------------------------------
ISAserver.org Monthly Newsletter of March 2010
Sponsored by: Wavecrest Computing
<http://www.wavecrest.net/searchad/ISA/ioe_isa_general.html?utm_source=isaserver_org&utm_medium=email&utm_campaign=ioe_apr10>

-------------------------------------------------------

Welcome to the ISAserver.org newsletter by Debra Littlejohn Shinder, MVP. month we will bring you interesting and helpful information on the world of Windows Networking. We want to know what all *you* are interested in hearing about. Please send your suggestions for future newsletter content to dshinder@isaserver.org

1. What about Parallel Deployments of TMG and UAG?
--------------------------------------------------------------

In just about any profession, the members of that profession work with a subject or technology on such a regular basis that over time, they take for granted the terminology and all of the "obvious" facts that they know about that subject and forget that not everyone thinks of things in the same way, and that not everyone understands the concepts in the same way as they do. There is nothing "bad" about that, and it makes the practitioner more efficient in his day to day work. However, it does create some problems when that person forgets that not everyone has the same insights and experiences that he (or she) does.

What brought this up? Over the last few months, since taking over the ISAserver.org newsletter, I've been receiving many questions from viewers on both TMG and UAG and when to select one over the other, and if running both, where to put the TMG and the UAG devices. When I hear these questions, I usually quickly reply with "You can use a back to back configuration, or a parallel configuration, depending on what you need" and then leave it at that. The problem is that most people have not had to deal with the issue before and many of them do not know what I mean and what the details of each configuration might look like.

Let us say that you have decided to use both TMG and UAG. You are going to use TMG for outbound access control and web anti-malware, and also take advantage of the Network Inspection System (NIS) to protect your Microsoft assets from zero-day threats. You should use UAG for inbound access control and remote access for most of your remote access clients. However, you also want to use TMG as a remote access VPN server, because the UAG only supports SSTP, and you still need to support PPTP and L2TP/IPsec for your down-level clients.

What's the best network topology for this configuration? If you have an existing firewall, the best solution is to put the TMG firewall in parallel with the existing firewall so that the TMG firewall has an IP address on the same network ID as the existing firewall's external interface. The TMG firewall will handle outbound connections from the corpnet and a handful of inbound remote access VPN client connections. The UAG could also be placed parallel to the existing firewall and the TMG firewall – but why not take some of the processor load off the UAG and put it behind either the existing firewall or the TMG firewall?

In general, I would recommend that you place it behind the existing network firewall and then on that firewall, enable inbound TCP port 443, if you do not plan to deploy DirectAccess. If you do plan to use DirectAccess, you will need to put the UAG parallel with the existing firewall and the TMG firewall, because of the public address requirements for DirectAccess.

Note:
This is not a hard and fast requirement, because you can use public addresses behind a firewall, but I suspect there is an entire generation of firewall admins out there who do not realize that firewalls do not have to perform NAT.

A question you might ask (if we remove the DirectAccess requirement from the equation) is: "why not put the UAG in parallel even when it is only active in SSL VPN mode? It has the TMG firewall on it to protect itself and the network, so that should work, right?" Indeed, it should. The TMG firewall on the UAG server will protect the UAG firewall itself from attack, and it will prevent attackers from compromising the UAG server to access resources behind the UAG server, acting in a limited capacity as a network firewall (since it is not performing outbound access control, the TMG on the UAG server could not be considered a true network firewall in this context).

UAG is edge-ready, and you can place it on the edge if you like, but since the UAG has so much work to do already with encryption and decryption of SSL (and potentially IPsec sessions), a better idea is to take the heat off of the TMG component and lend those cycles to the SSL session component by putting the UAG server behind a firewall.

Now the next question might be: "Why put it behind the existing firewall? Why not put the UAG server behind the TMG firewall? Wouldn't that be more secure since the TMG firewall in general is going to be more secure than the typical commercial 'hardware' firewall?". Again, you are correct. However, the TMG firewall is performing outbound access control in this scenario, which means it will be handling a large number of outbound connections that need to be examined with NIS and the Web anti-malware features. In addition, if your organization wants to actually be secure, instead of just "toying" with the idea of security, you are going to have to use outbound SSL to SSL bridging (sometime referred to as HTTPSi). A large number of processor cycles are required to do all these things, so why not let the existing firewall (which is probably not doing much other than "opening a port") handle the port filtering for the UAG server? No reason at all – and that is what I would recommend.

Of course, there are many other approaches you can take, and if you have an existing firewall that actually does something more than act as a packet filtering router, you might want to consider other deployment options.

I hope that this brief discussion gave you a better idea of what I mean when I recommend a parallel configuration. I asked Tom about this to see if he was in agreement with my interpretation and he said yes, but that he might not be quite so reasonable when referring to the existing firewall and that you should yank the existing firewall and put another TMG firewall in its place. I am not quite as intense as Tom is on this issue, so I will leave the decision about the existing firewall up to you!

Until next month! - Deb.
dshinder@isaserver.org

=======================
Quote of the Month - "A computer once beat me at chess, but it was no match for me at kick boxing." – Emo Philips
=======================

2. ISA Server 2006 Migration Guide - Order Today!
--------------------------------------------------------------

Dr. Tom Shinder's best selling books on ISA Server 2000 and 2004 were the "ISA
Firewall Bibles" for thousands of ISA Firewall administrators. Dr. Tom and his
illustrious team of ISA Firewall experts now present to you , ISA Server 2006
Migration Guide
<http://www.amazon.com/exec/obidos/ASIN/1597491993/isaserver1-20/>. This book
leverages the over two years of experience Tom and his team of ISA Firewall
experts have had with ISA 2006, from beta to RTM and all the versions and builds
in between. They've logged literally 1000's of flight hours with ISA 2006 and
they have shared the Good, the Great, the Bad and the Ugly of ISA 2006 with
their no holds barred coverage of Microsoft's state of the art stateful packet
and application layer inspection firewall.

Order your copy of ISA Server 2006 Migration Guide
<http://www.amazon.com/exec/obidos/ASIN/1597491993/isaserver1-20/>. You'll be
glad you did.

3. ISAserver.org Learning Zone Articles of Interest
--------------------------------------------------------------

* Installing and Configuring the Email Hygiene Solution on the TMG 2010 Firewall - Part 4: Configuring Virus and Content Filtering
<http://www.isaserver.org/tutorials/Installing-Configuring-Email-Hygiene-Solution-
TMG-2010-Firewall-Part4.html>

* Microsoft Forefront TMG – Webserver Load Balancing
<http://www.isaserver.org/tutorials/Microsoft-Forefront-TMG-Webserver-Load-Balancing.html>

* TMG Enterprise Arrays Explained
<http://www.isaserver.org/tutorials/TMG-Enterprise-Arrays-Explained.html>

* Celestix MSA Security Appliance Voted ISAserver.org Readers' Choice Award Winner - Hardware Appliances
<http://www.isaserver.org/news/ISAserver-Readers-Choice-Award-Hardware-Appliances-Celestix-MSA-Security-Appliance-Jan10.html>

* Installing and Configuring the Email Hygiene Solution on the TMG 2010 Firewall -
Part 3: Configuring Antispam Policy
<http://www.isaserver.org/tutorials/Installing-Configuring-Email-Hygiene-Solution-TMG-2010-Firewall-Part3.html>

* Installing and Configuring the E-mail Hygiene Solution on the TMG 2010 Firewall – Part 2: E-Mail Policy
<http://www.isaserver.org/tutorials/Installing-Configuring-Email-Hygiene-Solution-TMG-2010-Firewall-Part2.html>

4. ISA/TMG/UAG Content of the Month
---------------------------------------------------------------

After my experience with DirectAccess last month, I realized that not everyone has a DirectAccess guru "on staff" at home to help out with questions regarding design, planning, deployment and configuration. This got me thinking about the best path the typical person can take to start the journey toward deploying DirectAccess. As people learn new technologies in a variety of ways, there's no single best method. However, there is a process that Tom has come up with, which I think would work for the majority of admins who are interested in deploying DirectAccess:

* First, do the step by step lab. After all, the "proof in the pudding" is in the eating. If you can make DirectAccess work in your test lab, then you can be confident that it is going to work on your production environment. You can find the step by step lab guide over here <http://technet.microsoft.com/en-us/library/ee861167.aspx>

* After you get your hands dirty with the step by step lab guide, it is time to learn about the technologies that you were working with. The next step is to read the Forefront UAG DirectAccess design guide, which you can find here <http://technet.microsoft.com/en-us/library/ee406191.aspx>

* The design guide will talk about a number of things you need to consider for your DirectAccess deployment and it will mention a number of options you have. However, the Design Guide will not show you how to do those things. In order to learn the procedures required to make DirectAccess happen, you will need to read the Forefront UAG DirectAccess deployment guide here <http://technet.microsoft.com/en-us/library/dd857320.aspx>

* Finally, after doing the lab and reading the guides, go back and do the lab again. You will find that the concepts you have learnt will now come to life when you go back to the lab. You will also be in a good position to test out the new things you have learnt.

There are plenty of moving parts, but they are parts you already work with every day. There is no better time than the present to get started, because we believe DirectAccess is the future of remote access, and a fine future it is!

5. Tip of the Month
--------------------------------------------------------------

The TMG firewall includes the ISP redundancy feature that allows you to use multiple ISPs to connect to the Internet. If one of the ISPs fails, the connections will automatically fail over to the surviving ISP. In addition, if both ISPs are up and running, the ISP redundancy feature will allow you to load balance the outgoing connections between the two available ISPs.

The only downside is that you only get to use two ISPs. If you have more than two, you will have to deploy another TMG firewall or TMG firewall array to support that third ISP (which sounds like an interesting idea for an article – I will think about how that might work and get back to you on that).

Before you run out and deploy ISP Redundancy, here are some things you should know:

* The source and destination TMG Networks must have a NAT relationship.

* Each ISP must be connected to the TMG firewall on a different network. That is to say, the default gateways used to connect to each of the ISP connections must be on different network IDs. If you're using DHCP on the external interface, then you need to configure the routing table manually to add these default gateways.

* The connections to the ISPs must be configured on NICs that are part of the default External Network. You can not associate the ISP connections with NICs that are part of another type of external Network. Remember, the definition of the default External Network is that the IP addresses assigned to the Network are not part of the definition on any other TMG firewall Network.

* The DNS servers assigned to the NICs that connect to the ISPs can not be on the same network IDs as the NICs themselves. This should not be a problem, since you rarely (if ever) would want to put an external DNS server address in the configuration of any of the interfaces used by the TMG firewall.

* Network offload processing needs to be the same on both NICs (if you are using two NICs instead of one). If the settings are not the same, the TMG firewall will automatically disable offload processing on both NICs.

"Hey Deb! Why do you call them NICs? Microsoft calls them adapters.' That's a good question. I guess it is because, back when I first got into the business, they were all network interface cards that we had to install in an expansion slot – no built-in Ethernet ports back then – and also because I do not find most NICs to be very "adaptive."

6. ISA/TMG/IAG/UAG Links of the Month
--------------------------------------------------------------

* The Path to DirectAccess – Part 1: Choosing the DirectAccess Platform
<http://blog.msedge.org.uk/2010/01/path-to-directaccess-part-1-choosing.html>

* Generating a TMG HTTPS Inspection Certificate Using a Windows Server 2008 Certificate Authority
<http://blog.msedge.org.uk/2010/01/generating-tmg-https-inspection.html>

* Using the Windows Command-line FTP Client with Forefront Threat Management Gateway (TMG) 2010
<http://tmgblog.richardhicks.com/2010/03/18/using-the-windows-command-line-ftp-client-with-forefront-threat-management-gateway-tmg-2010/>

* Forefront Threat Management Gateway (TMG) 2010 and Windows Firewall Integration
<http://tmgblog.richardhicks.com/2010/03/11/forefront-threat-management-gateway-tmg-2010-and-windows-firewall-integration/>

* Forefront TMG 2010's Malware Inspection HTML page Progress Notification and Opera
<http://www.carbonwind.net/blog/post/Forefront-TMG-2010e28099s-Malware-Inspection-HTML-page-Progress-Notification-and-Opera.aspx>

7. Blog Posts
--------------------------------------------------------------

* Using Microsoft Forefront TMG 2010 as a Secure Web Gateway <http://blogs.isaserver.org/shinder/2010/03/16/using-microsoft-forefront-tmg-2010-as-a-secure-web-gateway/>

* UAG DirectAccess Dispels Common Networking Phobias <http://blogs.isaserver.org/shinder/2010/03/12/uag-directaccess-dispels-common-networking-phobias/>

* What Happened to FWENGMON <http://blogs.isaserver.org/shinder/2010/03/11/what-happened-to-fwengmon/>

* UAG DirectAccess Forum Now Online <http://blogs.isaserver.org/shinder/2010/03/11/uag-directaccess-forum-now-online/>

* Understanding the Re-Injection Mechanism Improvement on Forefront TMG <http://blogs.isaserver.org/shinder/2010/03/08/understanding-the-re-injection-mechanism-improvement-on-forefront-tmg/>

* Forefront Edge Content Newsletter March 2010 <http://blogs.isaserver.org/shinder/2010/03/08/forefront-edge-content-newsletter-march-2010/>

* Why Split Tunneling Isn't an Issue in DirectAccess <http://blogs.isaserver.org/shinder/2010/03/03/why-split-tunneling-isnt-an-issue-in-directaccess/>

* Tweaking DirectAccess Group Policy Objects <http://blogs.isaserver.org/shinder/2010/03/01/tweaking-directaccess-group-policy-objects/>

* TMG in Common Criteria Evaluation <http://blogs.isaserver.org/shinder/2010/03/01/tmg-in-common-criteria-evaluation/>

* Superflow for Troubleshooting Forefront TMG Installation <http://blogs.isaserver.org/shinder/2010/03/01/superflow-for-troubleshooting-forefront-tmg-installation/>

8. Ask Sgt Deb
--------------------------------------------------------------

* QUESTION:

Hi Deb,

I have been reading about the TMG firewall's Network Inspection System and I am pretty impressed at the level of security it can provide my primarily Microsoft network. Seems like NIS can protect us from exploits against Microsoft systems faster and earlier than any other firewall on the market today. That is pretty cool, but we already have another firewall in place. I am wondering whether there is a way to leverage the NIS database and engine and apply it to my existing firewall or proxy system.

Thanks! - Benny.

* ANSWER:

Hi Benny,

That is a good question. First, for those of you who do not know about the NIS, you can find excellent information about it in the NIS whitepaper here http://download.microsoft.com/download/F/4/0/F40887FD-648B-40E1-B79B-AAE43CEDCA4C/NIS%20in%20TMG%20Whitepaper.docx. NIS is designed to help protect you against those nasty zero day exploits that are so problematic for non-TMG firewalls. But that's the point of using the TMG as your outbound access firewall - to get the benefits of the TMG firewall's entire protection suite. For this reason, you need to make sure that the TMG firewall is an inline device.

Does that mean you need to replace your current firewall? Of course not. TMG firewalls are not about "rip and replace." TMG firewalls are about protection. Go ahead and leave your current firewall in place, but make sure that the TMG firewall is an inline firewall for all outbound access. You can leverage the Web proxy client and Firewall client (TMG client) configuration to help get around routing issues, so that you do not need to make your client systems use the TMG firewall as their default gateway and you do not need to configure your network so that the TMG firewall is the route of last resort for your network. That is the beauty of the web proxy and Firewall client (TMG client) configurations - take advantage of them!

* QUESTION:

Hi Deb,

Help! I am really confused and I need your help. I read your article last month about when to use TMG and when you should use UAG. The problem is that I am not sure what the best way to go is for our company. We are using ISA 2006 now and taking advantage of the Exchange and SharePoint publishing ISA provides. We are also using our ISA firewall array for outbound access control. I took a look at the UAG console and how it approaches publishing and while the portal looks kind of nice, I have to say that the interface is a total mess! I tested SharePoint and Exchange publishing and I have to say that the UAG approach reminds me of a "Rube Goldberg Machine." TMG has such an intuitive and elegant and well thought out interface, and comparing it to the UAG, I feel that the UAG is a giant step backwards.

But from what you said last month, the UAG is the future of Microsoft remote access and I should only use TMG for outbound access. Is that really true? I do not know if I can sell our team on using UAG for Exchange and SharePoint publishing because they are really busy and the UAG interface does not make any sense and the documentation of the options and controls really suck (please pardon my language, I was just frustrated working with UAG recently on a publishing scenario that I could not get to work).

So Deb – please help me and my team!

I owe you - Devin.

* ANSWER:

Do not panic, Devin. It is not that dire or that confusing. From what I hear, you and your team have worked with ISA for a long time and like it. You are using ISA for Exchange and SharePoint publishing and you also use the firewall array for outbound access control. You have checked out UAG and found the interface and methodology to be less than friendly and you want to make the right decision but feel conflicted because of what I wrote last month. Here is my advice to you. Since you like ISA and you and your team are happy with it, and you do not like what you see or do not have the time to come up to speed on UAG, then I would recommend that you go with TMG. The TMG firewall array will give you all the benefits that you had with your ISA firewall array, and more. While there is not much new in the publishing realm, there are many improvements in terms of outbound access control and security, and that is one of your main scenarios.

Now, I have to be frank with you: by not using UAG, you are missing out on the portal experience, and some of the access control and policy based controls you do not get with TMG, but if those are not a priority for you, then TMG is a fine option. Perhaps over time you will have the opportunity to give UAG another chance, and perhaps by that time, the UAG interface will have matured to the level of TMG. We readily admit that the ISA/TMG team have been exceptional within Microsoft in terms of creating one of the most impressive, most intuitive and most powerful user interfaces of any Microsoft product – the remarkable skills required to create the ISA/TMG interface will be hard to replicate, and we at ISAserver.org (not just me) wonder if it will be possible to back-port the clarity of the ISA/TMG interface to UAG.

You might be thinking that you will also lose out on DirectAccess. Well, that's not entirely accurate. You can deploy the Windows DirectAccess using a TMG firewall, as demonstrated in the TMG firewall team blog <http://blogs.technet.com/isablog/archive/2009/09/23/forefront-tmg-and-windows-7-directaccess.aspx>. However, the TMG DirectAccess solution does not include the NAT64/DNS64 solution, so that you will need an entirely IPv6 aware network behind the TMG DirectAccess server. That does not mean you need a native IPv6 network behind the TMG DirectAccess server, as you can take advantage of ISATAP. However, you will miss out on DirectAccess array configuration and some other features that UAG offers. But since you do not mention DirectAccess as one of your requirements, this might not be an issue for you.

Good luck with your deployment. Please let me know how it goes and also let me know if you have any questions about UAG in the future.

Do you have any questions or ideas for content? Email me on dshinder@isaserver.org.

Till next month!

TechGenix Sites
--------------------------------------------------------------

MSExchange.org <http://www.msexchange.org/>
WindowSecurity.com <http://www.windowsecurity.com/>
WindowsNetworking.com <http://www.windowsnetworking.com/>
VirtualizationAdmin.com <http://www.virtualizationadmin.com/>

--
Visit the Subscription Management <http://www.techgenix.com/newsletter/>
section to unsubscribe.
ISAserver.org is in no way affiliated with Microsoft Corp.
http://www.techgenix.com/advert/index.htm for sponsorship
information or contact us at advertising@isaserver.org
Copyright c ISAserver.org 2010. All rights reserved.