One of the features in ISA Server 2006 is the ability to block traffic based on URL or Domain name. This means that traffic can be blocked for a particular website from ISA Server without disrupting the general Internet access rule.

I’ve compiled some Domain Name Sets and URL Sets from the Internet and zipped them for easy availability for ISA administrators. Download the ZIP file and extract it. Under Network Objects in the Toolbox tab, right click URL Sets and click Import. Choose a single XML file from the unzipped folder of URLs. Once you have imported all XMLs, follow the same procedure for Domain Name Sets.

The next step is to create a rule which denies traffic to the websites which are listed in the XML files that we imported. Start by creating a new rule. I’ve named my rule as “Block Custom Sites”.

In the Access Rule, choose “Deny”.

Under protocols, choose HTTP and HTTPS.

Under Sources, choose Internal and VPN Clients.

Under Destinations, choose the XML lists that we imported. You can add multiple XML files.

Remember to shift the rule that we created to the top of all rules and we are done.

I thought that this might be easy since all that may be required would be allow the IPSec and IKE Client traffic through a rule in ISA. But no it did not work.

To allow a CISCO client via IPSec/UDP to connect through an ISA 2006 firewall, I had to create custom protocol as under:

Port Number: 500
Protocol Type: UDP
Direction: Send Receive

Port Number: 4500
Protocol Type: UDP
Direction: Send Receive

Port Number: 10000
Protocol Type: UDP
Direction: Send Recieve

I added all the ports in one custom protocol defination without Secondary Connections and then added an Access Rule to allow traffic from Internal to External for the above created custom protocol. Problem solved and the connections were now possible.

Recently I came across a situation in a company which ran ISA Firewall where the Outlook clients were not able to connect to external POP3/SMTP servers. The implementation of the firewall was being done by one of my friends and he was stuck up with this problem.

Upon further discussions with him, I came to know that the clients were using the ISA Firewall client. The ISA Firewall machine was not a member of the domain – which is a good sign. There was a rule configured which allowed DNS, POP3 and SMTP protocols from the Internal network to the External networks. The rule was enabled for all Authenticated Users.

So far so good. Everything seems to be in place and configured right. But what is stopping this traffic?
The problem was the default Firewall Client settings. In the application settings of the Firewall Client settings, OUTLOOK was set to Disable. Modified the value to 0, refreshed the Firewall Client and attempted a connection. BINGO! Everything was working fine now and a treat from my friend was due.

Yesterday I had a visit a client site for whom I support Exchange 2003 servers. They have an ISA 2000 setup and now want to migrate to ISA 2004/2006. The challenge was – how to do it. Even before that, they wanted to try out the publishing of Exchange Server’s Outlook Web Access over SSL from ISA 2004.

So, a new server was setup which had the ISA 2004 configured and which could talk to the current network so that the traffic from ISA can flow to Exchange server and vice-versa. The challenge was that their current FQDN did not point to the real IP which was set on the external interface of ISA.

In order to over come that situation where ISA would show a URL error, I set the client machine’s host header entry (which was outside the network) to point to the real IP of the new ISA server’s external interface. Next setup was to configure the new ISA to allow SSL Bridging between ISA and Exchange and configure it to use Forms Based Authentication (FBA).

After configuration of the above, I tried to access the FQDN from an external client and nothing happened. That was bad!!

ISA denied the request until I enabled “Require All Users to Authenticate” check box (which is not mandatory). This time I was happy to see the OWA screen on the client. But my worries did not end there. If I tried to login, OWA would not open the Inbox. Obviously the next step was to verify if ISA was able to authenticate the user credentials against Active Directory. Yes, checking the monitoring logs should that it could. So what was missing???

After some more hair pulling, analysis and some more hair pulling the loophole was found. ISA was not able to redirect the request to the Exchange Server for some reason. Added a host entry with the internal IP address of Exchange Server on the ISA Server and tried it once again.

Voila! We are there. Now the clients can enjoy their secure Outlook Web Access solution. Yes, the migration of ISA is still pending — but that’s a different story.