Thomas Shinder Blog

All Blogs  »  Thomas Shinder Blog  »  Archive: 2006

Customizing HTML Forms for ISA 2006 Firewalls

I’ve been seeing a lot of questions on how to customize the forms for ISA 2006 firewall, now that forms customization is fully supported (something which was not the case for ISA 2004 firewalls).

Good news! There is an excellent article on the Microsoft Web site on how to do this. Check out the article at:

http://www.microsoft.com/technet/isa/2006/html_for...s.mspx

HTH,

Tom

Thomas W Shinder, M.D.
Site: www.isaserver.org

Blog: http://blogs.isaserver.org/shinder/
Book: http://tinyurl.com/3xqb7

Email: tshinder@isaserver.org

MVP — Microsoft Firewalls (ISA)

New Proxy Support in WiredRed’s e/pop Web and Video Conferencing Alleviates Common Barriers to Connectivity

San Diego, CA (PRWEB) November 14, 2006 — WiredRed®, a technology leader in real-time communications software, today announced that e/pop® Web and Video Conferencing now offers expanded support for Microsoft ISA Firewalls, which limits web browsing to http 1.1. Many web and IP video conferencing services and software have trouble traversing older proxies and those with no proxy client, resulting in failed conference connections. By supporting more proxy and firewall configurations, e/pop is able to deliver more reliable conference connections so that virtually anyone who can browse the web can host or attend online meetings.

According to WiredRed’s Founder and CTO, Allen Drennan, e/pop’s new ‘Get Connected’ feature expands the web conferencing market to those who have been hindered by proxies in the past. It also expands the market for IP video conferencing because e/pop runs over existing networks without the need for dedicated lines, multiplexers (MUXs), session border controllers and other expensive equipment.

For more information: http://www.prweb.com/releases/2006/11/prweb477094.htm

The ISA Firewall’s Web Proxy Feature

I don’t spend a lot of time discussing the ISA Firewall’s Web proxy feature set because I spend most of my time writing about the ISA Firewall’s firewall capabilities so as to disabuse the pot-head network guys who think that the ISA Firewall is a “proxy server”, as if they even understood what a proxy server was. So, in spit of my jihad against the hardware firewall infidels, I think I should give some time to some of the Web proxy features that are useful but don’t get discussed much.

For example, did you know that you could configure the ISA firewall to use a backup route if the primary connection attempt fails? You can configure the ISA firewall to use a upstream Web proxy server if its currently using a direct connection to reach Web sites, or if the ISA firewall is already using an upstream Web proxy server, you can configure it to use another Web proxy server, or use a direct connection (via its default gateway).

Something I noticed a few years ago is that if you configured the clients to be Web proxy clients using the autoconfiguration script, you could have them automatically use their default gateway configuration if the Web proxy went down but configuring the Web proxy settings on the ISA firewall. I haven’t tried this for a few years but I’m sure it still works in ISA 2004 and ISA 2006.

Another thing you can do is Web proxy chaining. This a neat setup where you set up a chain of ISA firewalls, all of which perform Web caching. The goal is to have each downstream ISA firewall member in the chain be able to leverage the cache of the ISA firewalls upstream in the chain.

For example, suppose you have the following:

  • 100 small branch offices with 1.5Mbps site to site VPN links to 10 regional offices
  • 10 regional offices with 15Mbps site to site VPN links to the central office
  • 1 central office with a 50Mbps link to the Internet

All Internet connections for all offices are made through the central office Internet connection. All Web sites accessed by the central office users are cached on the main office ISA firewall array.

Connections made from the regional offices are also made through the regional office ISA firewalls. If the content requested is already in cache, its served from the regional office ISA Web cache. If the content isn’t cached at the regional office ISA firewall, then the connection request is sent to the central office ISA firewall array. If the content is cached on the central office ISA firewall array, then its returned from the central office ISA firewall array cache to the regional office ISA firewall, which puts it in its cache, and then returns the content to the user. If the content is not cached on the central office array, then the central office array retrieves the web content, put its in it’s cache, and then returns it to the regional office, which then put it in it’s cache and then returns to the content to the user who requested the information.

As you can see, from the above, the cache content can get very large at the main office array, since both users at the central office and the regional offices is cached on the central office array. The regional offices benefit from this cache, which is larger than the caches at any of the regional offices, and they access the cached content fast than if they had to go directly to the Internet.

The same applies to the branch offices. Requests for Web content go first to the branch office ISA firewall. If the content is in the branch office ISA firewall cache, then its returned from the branch office ISA firewall cache to the client. However, if the content is not contained on the branch office ISA firewall cache, the request is sent to the regional office ISA firewall. If the content is contained in the regional office cache, then it’s returned to the branch office firewall, where it is cached and returned to the client.

If the content is not contained on the regional office cache, then the request is forwarded to the central office ISA firewall array. If the content is contained in the central office cache, it is returned to the regional office ISA Firewall and is cached there, and then returned to the branch office ISA Firewall, which then caches it and returns the content to the client. If the content is not contained in the central office array, the central office array will retrieve the content, put it in its cached, return it to the regional office ISA Firewall, which will put it in its cache, and then regional office ISA Firewall returns the content to the branch office ISA Firewall, which then caches the content and returns it to the client making the request.

The end result of this Web proxy chained configuration is that the total amount of bandwidth required on the central office Internet connections. In addition, the clients at end point benefit from cached content from requests made by other clients on the network by bringing cached content closer to them.

I’ll do an article in the near future on how to create Web proxy chaining arrays to show you how all these Web proxy stuff works.

HTH,

Tom

Thomas W Shinder, M.D.
Site: www.isaserver.org

Blog: http://blogs.isaserver.org/shinder/
Book: http://tinyurl.com/3xqb7

Email: tshinder@isaserver.org

MVP — Microsoft Firewalls (ISA)

Multiple WAN Connections and ISA 2006 EE Firewall Arrays

Something that comes up a lot is how can you leverage multiple ISP connections with the ISA Firewall. As you may already know, the ISA firewall doesn’t support multiple gateways or policy based routing, so you need to put another device in front of the ISA firewall that supports multiple WAN interfaces. You need to be careful when choose such as device, because if you want to support publishing rules, you’ll need a device that will support DNS in a way that while fail over the incoming connections.

In spite of our lack of support for multiple gateways, I got to thinking about a possibility after listening to the Web cast on how Microsoft uses the ISA firewall to protect the Microsoft corporate network. What goes me to thinking about this was the discussion regarding the new CARP algorithm and how it load balances connections based on FQDN and not the entire URL. I discussed this in a blog post last weekend if you want to check that out.

Since all requests and responses for a particular Internet host are now assigned to the same ISA Firewall array member, it might be possible to connect each array member to a different ISP, or a subset of array members to different ISPs. This would theoretically increase overall throughput if we can reach the point where the CARP algorithm becomes statistically significant, because all connections will, over time, be evenly distributed across all array members, and hence, across all ISPs server those array members.

So, if we had an ISA Firewall array of 4 members, and two members are connected to ISP1 and two members are connected to ISP2, then the aggregate throughput through the array will be the bandwidth available on ISP1 + ISP2. If each ISP provided 15Mbps, then total outbound bandwidth available to the array would be 30Mps.

There are some limitations to this configuration that I can think of right now:

  • This works only for outbound Web proxy. It will not work for Web Publishing Rules
  • If one of the links goes down, all Internet hosts serviced by those array members will be unreachable. CARP will not remove these array members from the array membership list because the machines are still online.
  • While CARP will, over time, provide outbound bandwidth equal to the aggregate provided by all ISPs, these is a statistical phenomenon only. You will not see this bandwidth aggregation in real time

There may be more limitations that I haven’t considered, and there might be solutions for some of these problems. For example, it might be possible to write a script that tests the integrity of the ISP connection and if the connections goes down, then the Firewall service could be disabled. This should be enough to remove the ISA Firewall Array members using that ISP from the array membership list. The script could also detect when the gateways are active again, and restart the Firewall service, which would place the array members back on the array membership list.

This should also work with NLB enabled on the internal interfaces. Of course, NLB could not be enabled on the external interfaces because the external interface addresses would be on different network IDs for the array members using different ISPs.

I put these ideas out here for discussion. I have no idea if it would work and if anyone would want to try this. But maybe someone will be able to add to these ideas and come up with some creative ways to solve the problem of multiple WAN links without having to buy another device to put in front of the ISA Firewall array

HTH,

Tom

Thomas W Shinder, M.D.
Site: www.isaserver.org

Blog: http://blogs.isaserver.org/shinder/
Book: http://tinyurl.com/3xqb7

Email: tshinder@isaserver.org

MVP — Microsoft Firewalls (ISA)

Configuring the ISA Firewall with a WAP enabled NAT Device in Front of it

One question that comes up from time to time refers to how to configure the ISA firewall when there is a NAT device in front of the ISA firewall that also acts as a WAP. The questions vary from “should I create a separate network for the wireless clients” to “the DHCP server on the WAP doesn’t work for clients behind the ISA firewall”.

This is sort of an unusual situation, because the ISA firewall is an enterprise firewall that sells for enterprise firewall prices. Putting a NAT device with a co-located WAP on it isn’t something an enterprise would typically do because of the security implications of this sort of configuration.

The first thing to keep in mind is that the NAT/WAP device should be physically separated from all ISA firewall protected networks. One of the more common nightmare scenarios is where I see the ISA firewall deployed by those who are testing it on their home networks is when the ISA firewall’s external interface, and all the LAN computers, are all connected to Ethernet ports on the NAT/WAP device. This provides no physical segmentation at all and such a configuration is to be abhorred, even if you could get it to work.

What you should do in this configuration is to plug the ISA firewall’s external interface into the NAT/WAP device’s LAN interface, or plug the ISA Firewall’s external interface and the NAT/WAP device’s LAN interface into a common switch that is not connected to the internal network. (this gives you more flexibility for your DMZ and doesn’t require a cross-over cable). Then plug the ISA Firewall’s internal interface and the ISA Firewall protected hosts into another switch. In this way you get physical segmentation.

As for the WAP, it’s not much use for your LAN clients and you should consider wireless hosts connected to that NAT/WAP device as untrusted hosts in a DMZ segment. While it is possible to create rules to allow communications between the wireless host in this DMZ and the internal network behind the ISA firewall, such rules would be unwise. Instead, if you have hosts that need to connect from the DMZ segment, configure them as VPN clients and require a VPN connection in order to allow access to the internal network behind the ISA firewall.

As for DHCP services, use the DHCP server on the NAT/WAP device only for the untrusted wireless hosts. For hosts behind the ISA Firewall, configure a DHCP server behind the ISA Firewall, or if you don’t have another server (an unlikely event) configure the ISA Firewall as a DHCP server and configure the appropriate rules to allow DHCP requests from internal to local host and DHCP replies from local host to internal.

HTH,

Tom

Thomas W Shinder MD, MVP

tshinder@isaserver.org

ISA 2006 Firewall VHD Available for Download

The Microsoft VHD Test Drive Program provides customers with an enhanced server-based software evaluation experience that’s faster, better supported and more flexible. You can now access the entire catalog of pre-configured Microsoft and partner products and solutions in the VHD format and start evaluating and testing today from www.microsoft.com/vhd.

ISA Server 2006 provides security for corporate applications accessed over the Internet by pre-authenticating users before they gain access to published servers, inspecting even encrypted traffic at the application layer in a stateful manner, and providing automated publishing tools. In addition, by providing HTTP compression, caching of content including software updates, and site-to-site VPN capabilities integrated with application-layer filtering, ISA Server 2006 enables you to securely expand corporate networks.

ISA Server 2006 also enables you to manage and protect your network with a hybrid proxy-firewall architecture, deep content inspection, granular policies, and comprehensive alerting and monitoring capabilities.

This download helps you test and evaluate how ISA Server 2006 can help you with your concerns about the security, performance, manageability, or reduced cost of network operations. ISA Server 2006 is an integrated edge security gateway that helps protect your IT environment from Internet-based threats while providing your users fast and secure remote access to applications and data. ISA Server 2006 can help you securely publish content for remote access, Connect and secure branch offices, and defend against external and internal web-based threats.

This fully functional pre-configured VHD provides you a trial software will automatically expire after 30 days.

This is a preconfigured virtual machine contained within the Virtual Hard Disk (VHD) format. Virtual Server 2005 R2 is required to run this VHD. Please refer to the system requirements section for more details

Download at:

http://www.microsoft.com/downloads/details.aspx?fa...ang=en

HTH,

Tom

Thomas W Shinder, M.D.
Site: www.isaserver.org

Blog: http://blogs.isaserver.org/shinder/
Book: http://tinyurl.com/3xqb7

Email: tshinder@isaserver.org

MVP — Microsoft Firewalls (ISA)

Microsoft Windows Server 2003 R2 Enterprise Edition VHD

The Microsoft VHD Test Drive Program provides customers with an enhanced server-based software evaluation experience that’s faster, better supported and more flexible. You can now access the entire catalog of pre-configured Microsoft and partner products and solutions in the VHD format and start evaluating and testing today from www.microsoft.com/vhd.

This download helps you evaluate the new features of Windows Server 2003 R2, the most productive infrastructure platform for powering connected applications, networks, and Web services from the workgroup to the data center. Windows Server 2003 R2 simplifies branch server management, improves identity and access management, reduces storage management costs, provides a rich Web platform.

For more information about Windows Server 2003 R2, please go to www.microsoft.com/WindowsServer.

This is a preconfigured virtual machine contained within the Virtual Hard Disk (VHD) format. Virtual Server 2005 R2 is required to run this VHD. Please refer to the system requirements section for more details

Download the VM at:

http://www.microsoft.com/downloads/details.aspx?fa...ang=en

HTH,

Tom

Thomas W Shinder, M.D.
Site: www.isaserver.org

Blog: http://blogs.isaserver.org/shinder/
Book: http://tinyurl.com/3xqb7

Email: tshinder@isaserver.org

MVP — Microsoft Firewalls (ISA)

CARP and Load Balanced Domains

One thing about this business is that if you think you understand something, you don’t. This fact was highlight for me last night when I viewed a Webcast done by the MS IT team on how Microsoft uses CARP to load balance outbound Web connections through ISA Firewall arrays.

I gave a short overview of how CARP works in ISA Firewall arrays over at http://blogs.isaserver.org/shinder/2006/06/03/can-...other/ and at that time I thought I understood how the CARP algorithm worked to balance outbound connections through the ISA Firewall.

However, I think in the back of my head that was no entirely comfortable with that description, because there were “rumors” that there was some big changes in the CARP algorithm. These changes took place with ISA 2004 SP2, and some of them were described in the ISA 2004 SP2 white paper at http://www.microsoft.com/technet/isa/2004/plan/sp2.mspx

The major change to the CARP algorithm was that instead of the entire URL being used in the hash, only the FQDN is used in the hash. That makes sure that all outbound requests to a particular host is handled by the same array member, which keeps the context of a session to the same external hosts.

However, as pointed out during the Webcast, there still left a problem with a single array member being hammers with too many requests. For example, suppose 10K clients behind the ISA Firewall array want to go to www.microsoft.com/downloads/secfix.asp. All those requests would use www.microsoft.com in the hash and the server responsible for the FQDN would be server 3 in the array, as seen in the figure below. This would lead to server 3 being overwhelmed with traffic while other array members are left relatively unaffected (assuming that we’re using client side CARP — server side CARP would have it’s typical effect on all members of the array, but would not change the load issue for server 3 in this scenario, it would just increase the load on all servers, as it normally does).

So what did I find out during the Webcast? I found out that there were more changes made to the CARP algorithm than what was shared in the SP2 white paper, and represent a very clever, and very powerful change in the CARP load balancing algorithm. The change introduced with SP2 not only takes the destination FQDN into account, but also uses the source IP address.

 When the source IP address is added to the hash calculation, connections to www.microsoft.com/downloads/secfix.asp can be load balanced among multiple array members, as seen in the figure above. This is a much more efficient way to load balancing outbound Web connections through the ISA Firewall array and prevents any server in the array from being overwhelmed with traffic, even when thousands of clients are trying to reach the same destination FQDN.

This is really significant, because it proves that the ISA Firewall array is a much more robust solution than Blue Coat, since Blue Coat has very limited support for redundancy or load balancing. In contrast, Microsoft has been about to get five 9’s uptime for their 70K clients using ISA Firewall arrays at the Microsoft campus and all over the world. Another significant comment made during the Webcast is that Microsoft, one of the most attacked Web sites in the world, do not use “hardware” firewalls in front of the ISA Firewall arrays. Why? Because they’re not required — the ISA firewall is a secure and robust as any hardware firewall.

Lesson learned: don’t buy into the “hardware” sales guy’s BS when he disses the ISA Firewall.

HTH,

Tom

Thomas W Shinder, M.D.
Site: www.isaserver.org

Blog: http://blogs.isaserver.org/shinder/
Book: http://tinyurl.com/3xqb7

Email: tshinder@isaserver.org

MVP — Microsoft Firewalls (ISA)

TechNet Webcast: How Microsoft IT Secures Access to Corporate Resources Using Internet Security and Acceleration (ISA) Server 2006 (Level 300)

In this webcast, we explain how Microsoft IT adopted Microsoft Internet Security and Acceleration (ISA) Server 2006 for secure Web publishing as an alternative to remote access. Join this presentation to learn how Microsoft IT’s deployment of ISA Server 2006, with its many new features, saves the company millions in hardware and personnel resources.
Presenter: John Wohlfert, Systems Engineer, Microsoft IT, Microsoft Corporation
As a systems engineer in the Microsoft IT Windows Network and Infrastructure Services group, John Wohlfert is the lead Microsoft Internet Security and Acceleration (ISA) Server engineer for proxy/firewall. John is responsible for all proxy, firewall, and secure Web publishing servers deployed by Microsoft Global Technology Services. Prior to joining Microsoft in 2002, John worked for Compaq as the senior technical lead of their Global Operations Center. John is a MCSE and MCP.

View the Webcast at: http://www.microsoft.com/events/EventDetails.aspx?...ams%5e

HTH,

Tom

Thomas W Shinder, M.D.
Site: www.isaserver.org

Blog: http://blogs.isaserver.org/shinder/
Book: http://tinyurl.com/3xqb7

Email: tshinder@isaserver.org

MVP — Microsoft Firewalls (ISA)

About Split DNS

QUESTION:

Hello,

I read some of your articles about split DNS and decided to create a test environment in my house to test it. Therefore I got one public IP address from ISP which is now connected to my linksys WRT54G router and built a small internal network hidden behind Nat. Next I registered public domain and so far I keep it in my ISP’s DNS servers. Finally I installed virtual PC and built a few W2k3 virtual severs.

My intend is to use one of them to be a local domain controller and local DNS and other to be public DNS server not connected to my domain which will have port 53 or all ports (DMZ) published outside through my router. The public domain name I registered and local domain name must be the same. As soon as I understand split DNS solution and if the above configuration is possible to exist (with one external IP address and linksys router) I want to configure POP3 and SMTP services on local network and to build a very simple mail system. I need to do it in test/lab environment as one of my friends wants to have it in his company.
He can’t afford to buy ISA so we have to count on the conditions I described above.

I would need to know if it is possible to build at all and if it is how to configure network cards on public DNS server also how to make it provide an information for external users about email services in internal network. I believe that more complex environments are usually easier to configure but the budget is rather small and my knowledge is still apparently not to big
either :)

I would be grateful for any clues,

Regards,

Mateusz

 

ANSWER:

I’m always happy to hear about new split DNS deployments! ISA Firewalls aren’t required for a split DNS. A split DNS is very easy to setup, once you understand why you want to deploy it and get the basics down.

First, if you’re using Windows DNS servers, you will need two DNS servers — one for the private part of the split DNS and another for the public part of the split DNS.

On the private DNS server (which can be your DC), you enter names and private IP addresses that are used by hosts on the internal network to reach servers on the internal network. Internal hosts never use the external DNS server.

On the public DNS server, you enter names and public addresses that are used to reach published resources on your internal network. In the example you give above, you only have one public address, so all names in your public DNS will resolve to the same IP address. You will use that address so that incoming connection that are reversed NATed into your DMZ or internal network are forwarded from that address to the internal address.

External users will never use the internal DNS server and will never have access to the Internal DNS server (unless they’re VPN clients, but that’s another story).

That’s all there is to it! Internal hosts are configured to use the internal DNS server and external hosts are automatically going to use the external DNS server, because you’ve configured your external IP address to be your authoritative DNS server with your domain registrar.

Of course, if you don’t have a dedicated public IP address, this won’t work. In that case, you can use a DDNS provider, such as TZO (www.tzo.com) to provide your public DNS. It will work just the same as if you hosted your own DNS server, but TZO will handle the changes in your public records when your IP address changes.

HTH,

Tom

Thomas W Shinder, M.D.
Site: www.isaserver.org

Blog: http://blogs.isaserver.org/shinder/
Book: http://tinyurl.com/3xqb7

Email: tshinder@isaserver.org

MVP — Microsoft Firewalls (ISA)


Receive all the latest articles by email!

Receive Real-Time & Monthly ISAserver.org article updates in your mailbox. Enter your email below!
Click for Real-Time sample & Monthly sample

Become an ISAserver.org member!

Discuss your ISA Server issues with thousands of other ISA Server experts. Click here to join!

Solution Center