I’ve gone over the differences in Server and Web Publishing Rules and how they behave depending on whether there is a ROUTE or NAT Network Rule connecting the source and destination ISA Firewall Networks. However, when something is worth communicating, its worth communicating over and over and by different authors. This helps get the word out and keeps the issue alive so that we don’t forget how things work and don’t make mistakes in the future.

Philipp Sand, an ISA Firewall support specialist for Microsoft did a great job describing how publishing rules work in ROUTE and NAT relationships. He also provides some nice tips on how to use the command line tool fwengmon to troubleshoot ISA Firewall configuration issues.

Check out Philipp’s article at:

https://blogs.technet.com/isablog/archive/2008/06/...s.aspx

HTH,

Tom

Thomas W Shinder, M.D.
Site: http://www.isaserver.org/
Blog: http://blogs.isaserver.org/shinder/
GET THE NEW BOOK! Go to http://tinyurl.com/2gpoo8
Email: tshinder@isaserver.org
MVP — Microsoft Firewalls (ISA)

I was recently helping out a client with setting up a new ISA firewall into a Windows Server 2008 domain. Things were going smoothly except for WPAD. We had configured a wpad entry on this client’s DNS server and configured the Web Proxy clients to autodetect their configuration settings. The problem was that the clients were not getting their settings from the ISA firewall.

My first thought was that perhaps there was something wrong with the clients and they weren’t getting the wpad information from the ISA firewall. So we set up a DHCP server with a WPAD entry and tested the clients with that. It worked. So apparently there was nothing wrong with the clients. I then used NetMon 3 to check if the wpad DNS queries were going to the DNS server (I should have done this first instead of messing around with DHCP servers.). The packet trace showed that the DNS queries were going to the DNS server, but the DNS server indicated that it had no records for that wpad.domain.com

We knew that there was a record for WPAD in the DNS server because we created it and saw it there. We even restarted the DNS service. Then bam! It occurred to me — this is a Windows Server 2008 DNS server. Windows Server 2008 DNS servers have a default block list that prevents them from responding to queries for ISATAP and WPAD. You have to configure the Windows Server 2008 DNS server to answer these queries using the dnscmd command line tool.

We got this fixed and the DNS queries for WPAD started working again.

Just another day in the life of an ISA firewall consultant who isn’t used to all the new features in Windows Server 2008

For more information on this, check out:

http://technet.microsoft.com/en-us/library/cc44151...).aspx

HTH,

Tom

Thomas W Shinder, M.D.
Site: http://www.isaserver.org/
Blog: http://blogs.isaserver.org/shinder/
GET THE NEW BOOK! Go to http://tinyurl.com/2gpoo8
Email: tshinder@isaserver.org
MVP — Microsoft Firewalls (ISA)

There are some things in life that no matter how hard you try to figure out, you can never make sense of them. I ran into one of these issues last weekend when trying to figure out why some people seem to think that a unihomed IAG wouldn’t be as popular as a unihomed ISA Firewall.

I was thinking of conversations I’ve had with the IAG marketing and technical folks and on multiple occasions I’ve asked about support for a unihomed configuration in future versions of the IAG product. I’ve been told that this is an interesting idea, but that there didn’t seem to be much interest in the unihomed configuration and thus they weren’t sure if it was worthwhile to officially support a unihomed IAG. However, this isn’t to say that such support wouldn’t be included, but that no hard and fast decisions have been made in this area.

As you can imagine, I found this to be a jaw-dropping response given my experience with trying to get people to not deploy unihomed ISA firewalls. No interest in the unihomed configuration? How could that be? We’ve been trying to over 8 years to go people to drop the unihomed configuration for the various versions of the ISA Firewall, but I’m sad to say that I suspect that close to, or over, 50% of ISA firewall deployments use the unihomed configuration. This in spite of the fact that we have pushed extraordinarily hard for people to use the full firewall configuration of the ISA firewall for over the years.

What does a unihomed ISA firewall do? Not much. It does forward and reverse Web proxy. Sure, it does add some security to inbound connections, and some to outbound connections if you can prevent users from bypassing the unihomed ISA Firewall since you can’t force it to be in the path (a single NIC prevents you from forcing the unihomed ISA Firewall from being in the path between source and destination). The unihomed ISA firewall does some caching too, as well as SSL termination and initiation.

So, given how popular the unihomed ISA Firewall is, what does the IAG do that the ISA firewall doesn’t do that prevents it from being as popular in a unihomed configuration? As an SSL VPN gateway, the vast majority of the work performed by the IAG is reverse Web proxy. While no caching is done, there is advanced URL inspection as well as advanced authentication support. But for the most part, the IAG is an advanced reverse Web Proxy device, similar to the unihomed ISA Firewall.

Given that multihoming the ISA firewall is often a deployment blocker, why isn’t multihoming the IAG a deployment blocker? Or maybe the IAG people aren’t really attuned to this issue as the ISA firewall people have been over the years, but instead are leveraging the experience of the Whale people, who had the Air Gap or eGap appliances. 

If they had been paying attention to the unihomed ISA firewall experiences over almost the last decade, they would realize that requiring the IAG to be multihomed could represent a deployment blocker in many environments. At the very least, you significantly increase the customer base by enabling the application administrator the ability to introduce a unihomed IAG because the application administrator doesn’t have to deal with the “network guys”, who are often just outsourced Cisco teams who manage the edge router or firewall, and the internal network routers and switches.

It’s our firm opinion here at ISAserver.org that enabling unihomed support for the IAG and its successors will significantly increase the number of people who will deploy the IAG and its successors, and that whatever development and testing efforts that go into unihomed support will more than pay for themselves over the sales lifetime of IAG and future related products.

HTH,

Tom

Thomas W Shinder, M.D.
Site: http://www.isaserver.org/
Blog: http://blogs.isaserver.org/shinder/
GET THE NEW BOOK! Go to http://tinyurl.com/2gpoo8
Email: tshinder@isaserver.org
MVP — Microsoft Firewalls (ISA)

In a perfect world where we could deploy least privilege to all communications moving through the Forefront TMG firewall, the TMG firewall would not be a member of the domain, yet we would have all the security features and capabilities that we have with a domain joined TMG firewall. However, that’s not the case now, nor do I believe it will it be the case in the near future, including the RTM release of the Forefront TMG.

So, when deciding about what the more secure solution is, you have to take in account the entire security picture, and then choose the option that affords you the most overall security. You can’t just look at one issue, deem that issue “unsecure” and then ignore the loss of security when you don’t consider the entire list of security features and capabilities when you dismiss a single configuration option as unsecure.

For example, some consider the domain member Forefront TMG firewall to be unsecure. However, that’s because they’re looking at only a single factor. If the “expert” who made this offhand assessment were to assess the entire security configuration, he might decide that domain membership is actually an overall more secure configuration.

Consider the following information in the Forefront TMG Help File that can be found at http://technet.microsoft.com/en-us/library/cc44166...).aspx  :

• When access rules require internal clients to authenticate for outbound access, Forefront TMG can authenticate domain user accounts against an Active Directory directory service domain controller. Web proxy requests in a workgroup environment can be authenticated against a RADIUS server.
• Firewall client requests automatically include user credentials. To authenticate these requests, Forefront TMG should belong to a domain. In a workgroup environment, you can authenticate requests with user accounts that are mirrored to accounts stored in the local Security Accounts Manager (SAM) on the Forefront TMG server, but this requires some administrative overhead for secure management.
• To authenticate inbound requests to internal Web servers using domain account credentials or certificate authentication, Forefront TMG must belong to a domain. In a workgroup environment, a RADIUS or SecurID server can be used for authentication.
• To authenticate virtual private network (VPN) requests using domain account credentials or certificates, Forefront TMG must belong to a domain. In a workgroup environment, a RADIUS server can be used for authentication.
• You can configure VPN client user mapping to map users of operating systems other than Microsoft Windows to domain user accounts. User mapping is only supported when Forefront TMG is installed in a domain.
• In a domain, you can lock down the Forefront TMG server using Group Policy, rather than by configuring only a local policy.
• In a domain environment, if Active Directory is compromised, for example by an internal attack, the firewall can also be compromised, because a user with Domain Administrator rights can administer every domain member, including the server running Forefront TMG. Similarly if the firewall is compromised, the domain in which Forefront TMG is located is also at risk. By default, the Domain Admins group is in the Administrators group on the Forefront TMG server.

Regarding the last issue, I would consider the fact that the firewall might be compromised by a compromised domain or enterprise admin account to be the least of my problems should such an event occur. But then again, I have to remain true to least privilege and admit that this does add to the problems of a compromised domain admit account.

However, when looking over the list from the Help file, you can see that domain membership confers a significant amount of security that would be lost, or more difficult to maintain, if the TMG firewall were not a domain member.

HTH,

Tom

Thomas W Shinder, M.D.
Site: http://www.isaserver.org/
Blog: http://blogs.isaserver.org/shinder/
GET THE NEW BOOK! Go to http://tinyurl.com/2gpoo8
Email: tshinder@isaserver.org
MVP — Microsoft Firewalls (ISA)

Jim Harrison pointed out today that your ISA or Forefront TMG firewall performs only as well as the operating system that it runs on. To that end, Jim Harrison points out that Microsoft provides a valuable tool that you can use to determine a variety of performance issues in Windows.

Check it out at:

https://www.microsoft.com/downloads/details.aspx?F...ang=en

HTH,

Tom

Thomas W Shinder, M.D.
Site: http://www.isaserver.org/
Blog: http://blogs.isaserver.org/shinder/
GET THE NEW BOOK! Go to http://tinyurl.com/2gpoo8
Email: tshinder@isaserver.org
MVP — Microsoft Firewalls (ISA)

While deciding how I was going to deal with switching over to a new Exchange setup in our office, I was wondering how I would deal with the fact that I always prefer to keep the Exchange organization separated from the the production domain. I like to keep the Exchange forest separate from our production forest because the users in the Exchange forest aren’t all employees of our business, so I figure it’s safer to put the Exchange Server is in a separate forest and then create a one-way trust between the Exchange forest and our production forest.

The problem is that our inbound ISA Firewall is part of the production domain, so as to allow us to leverage the security advantages of domain membership. Since the ISA Firewall doesn’t belong to the Exchange forest, and the production forest doesn’t trust the Exchange forest, there’s no way that the ISA Firewall can authenticate the Exchange users using it’s own domain membership.

What’s the solution? RADIUS authentication. For the Web Publishing Rules used to support connections to OWA, ActiveSync, and RPC/HTTP to the Exchange 2007 servers, I can use RADIUS authentication. I configure my ISA firewall to connect to an NPS server in the Exchange 2007 organization and authenticate the Exchange users that way. It works a treat!

The primary limitation of using RADIUS authentication over Windows authentication is that you can’t use domain security groups when configuring the ISA firewall’s inbound access in the Web Publishing Rules. That’s not too big of a problem though, since I can control service access on the Exchange Server for who has permission to use a particular Exchange 2007 feature.

Speaking of Exchange, I’ve changed my opinion regarding documentation and management of Exchange 2007. My initial impressions of Exchange 2007 was that it was an installation and configuration nightmare, with poor documentation and fearful drops into the hole known as PowerShell. However, with Exchange 2007 SP1, much of that has changed. The documentation is much better, there’s little need to fall into PowerShell, and when you do, it’s only to do a couple of things and the new documentation makes it easier to deal with PowerShell.

The only complaint I have is that certificate management is still of a problem and more complex than it needs to be. You still need to use PowerShell to request a certificate, and the rationale for why so many SANs entries are required is still missing. There has to be a better way, and there is. Check out the certificate request wizard included with OCS 2007, and you’ll see that there is a very nice wizard that allows you to configure a certificate request that includes the subject name and the SANs. It certainly makes life more pleasant.

Oh, I do miss being able to see mailbox statistics in the console. That’s something that needs to be fixed. Maybe in SP2? Or Exchange 2009?

HTH,

Tom

Thomas W Shinder, M.D.
Site: http://www.isaserver.org/
Blog: http://blogs.isaserver.org/shinder/
GET THE NEW BOOK! Go to http://tinyurl.com/2gpoo8
Email: tshinder@isaserver.org
MVP — Microsoft Firewalls (ISA)

In a recent blog post I mentioned that I had softened a bit on my stance regarding the configuration where the ISA Firewall was placed in a forest different from the user forest. In the past I really didn’t think about the core advantage of putting the ISA Firewall in a different forest. The key issue is that putting the ISA Firewall in a different forest from the user forest is least privilege. Since least privilege should guide all your network and computer security decisions, and in order to be consistent, I had to change my opinion regarding the value of putting the ISA Firewall in a trusting forest of its own.

However, you do need to be aware of another security issue when the ISA firewall (and the Forefront TMG firewall) is in a separate forest. That issue is that you cannot take advantage of user (client) certificate authentication at the ISA Firewall. Given how important user certificate authentication is in creating secure Web Publishing Rules, you need to take this into consider.

Security decisions have to be made within the entire security context and how decisions result in the overall security posture of the solution. The miniscule amount of security gained by putting the ISA Firewall in a trusting forest is far overshadowed by the significant security gains you get with user certificate authentication.

Given the relative advantages and disadvantages from a security viewpoint, it’s clear that making the ISA Firewall a member of the user domain is a far more secure solution.

HTH,

Tom

Thomas W Shinder, M.D.
Site: http://www.isaserver.org/
Blog: http://blogs.isaserver.org/shinder/
GET THE NEW BOOK! Go to http://tinyurl.com/2gpoo8
Email: tshinder@isaserver.org
MVP — Microsoft Firewalls (ISA)

While reading over the Forefront TMG firewall release notes this morning, I found several interesting issues that you should be aware of when testing the Forefront TMG on your network.

• In previous versions of the ISA Firewall you had the option to force 128bit encryption on Web Publishing Rules. This option is removed and this requirement is always enforced on the Forefront TMG firewall. This is a function of Windows Server 2008
• The TMG Beta 1 trial version is limited to 300 licensed users. However, it’s not stated how these users are enumerated by the TMG firewall. Is it IP addresses? AD User accounts that authenticate to the TMG firewall? Something else? I’ll try to find out.
• RDP is the recommended mode of remote administration. I agree with this completely and never understood why anyone would want to use the remote console.
• Reporting is only available if you use local SQL logging. That means no reports if you use .txt file logging or off-box SQL server
• TCP port 8008 is used by the local Web server on the TMG firewall for SQL reporting services, so you must not configure any listeners to use that port
• When you view the site to site VPN configuration settings after creating a Remote Site Network, the Apply and Discard buttons will appear, even if you didn’t make any changes. You can click Discard since no actual changes are made when you just view the settings
• The beta 1 of the TMG firewall must be a domain member. No workgroup configs are supported in the Beta 1

I thought these were interesting and also important, as you might run into some strange problems if you’re not aware of these issues and limitations in the beta 1 of the Forefront TMG firewall.

HTH,

Tom

Thomas W Shinder, M.D.
Site: http://www.isaserver.org/
Blog: http://blogs.isaserver.org/shinder/
GET THE NEW BOOK! Go to http://tinyurl.com/2gpoo8
Email: tshinder@isaserver.org
MVP — Microsoft Firewalls (ISA)

I’ve done a few articles on this blog on my switch to Verizon Business FiOS, so I thought I’d include some information that other’s who are considering moving to this service will find helpful.

When you choose Verizon’s business service, you have the option to get static IP addresses. What the Verizon Web site doesn’t tell you is that you don’t need to use their Router or NAT device in order to use these IP addresses. That means you can assign these static IP addresses to the external interfaces of the ISA Firewalls and not need to do anything else in order for them to work.

When you have static IP addresses in the Verizon business plan, you don’t use PPPoE. Its a regular Ethernet connection. Just connect their Ethernet connection (which is bridged to the FiOS network) to the same switch that the external connections on your ISA Firewall’s are connect to, and everything will work fine.

HTH,

Tom

Thomas W Shinder, M.D.
Site: http://www.isaserver.org/
Blog: http://blogs.isaserver.org/shinder/
GET THE NEW BOOK! Go to http://tinyurl.com/2gpoo8
Email: tshinder@isaserver.org
MVP — Microsoft Firewalls (ISA)

I was reminded of this issue recently as part of my ISP switch over in the last month.

For the last four years, we had been using a T1 service with speakeasy.net to support our mail and Web traffic inbound. I figured that it was worth the extra six-hundred dollars a month to get the level of service required to support our mail and Web presence. At the same time, I had been running a Verizon FiOS 15/2 connection to support outbound Internet access and VPN connections.

However, over the three years that we ran the FiOS and T1 concurrently, we found that the fiberoptic link was in fact more reliable than the T1. In fact, it seemed like the T1 would know when I was leaving town, especially when I was going to Las Vegas to have a little work and a little fun, because it would invariably go down during those trips, which lead to 1 to 4 days of hell trying to get things up and running again.

Anyhow, a couple of weeks ago we switched off the T1 and now run exclusively on the FiOS link. We got their business plan, which included 5 static addresses, so I assigned one to the outbound ISA Firewall, and two each for the inbound ISA firewalls (I have two inbound ISA firewalls for redundancy). All was working well. Another nice benefit of moving over to only the FiOS with the business plan is that we would be saving almost 450/mo on the cost.

However, Debi noticed that AT&T’s network wasn’t accepting email from our mail servers. It didn’t matter what the FROM domain was on the messages, the message’s were not delivered to them. I first tested by sending email to my Hotmail, Gmail and Yahoomail accounts, and the messages showed up in the inbox, which I thought was pretty good — I figured that at least one of those provided would “bin” my messages.

What did I need to do? I needed to do one of two things:

• Find out if Verizon had a smart host that I could use
• Find out if Verizon would create a reverse lookup record for my outbound mail server

I called Verizon’s tech support (who are very knowledgeable and helpful) and they said that they didn’t have a smart host that I could use. However, if I wanted to try, I could use the authenticated SMTP server they provide for users’ email applications, and then configure the Exchange Server to send credentials to that machine to use it for outbound relay. The problem, they told me is if you sent too many messages too quickly, the account might be tagged as a spammer and shut down the server. For that reason, they didn’t recommend that I use my personal SMTP account as a smart host.

So, we went with the rDNS record. It was very easy to get this setup. They just wanted to know the IP address that would be the source IP address for outbound SMTP connections and the name my machine sends in the HELO (or EHLO). I use a masquerade name so that the actual machine name isn’t set, but that’s OK because Internet SMTP servers don’t care what the actual machine name is. Within 24 hours the rDNS was in place on Verizon’s DNS servers and outbound mail started working.

Oh, one more thing I had to do. Some spam whackers will use SPF to control spam. It makes sense to use SPF instead of rDNS on MX records, because MX records are designed for inbound mail not outbound mail. SPF is designed to give relevant information on outbound mail. So I also updated my SPF records to support the new configuration.

That’s it. Everything worked and all ISPs are accepting out mail again. Changing ISPs isn’t always fun and it’s never easy, but once everything is in place, everything will work like clockwork again.

HTH,

Tom

Thomas W Shinder, M.D.
Site: http://www.isaserver.org/
Blog: http://blogs.isaserver.org/shinder/
GET THE NEW BOOK! Go to http://tinyurl.com/2gpoo8
Email: tshinder@isaserver.org
MVP — Microsoft Firewalls (ISA)