Tom Shinder’s ISA Server Questions of the Week – 10/14/2002

Tom Shinder’s ISA Server Questions of the Week

10/14/2002

In this week’s question of the week we cover:

QUESTION: Microsoft Exchange in a Private Address DMZ

I have read the following articles.

http://www.isaserver.org/pages/article.asp?id=351

http://www.isaserver.org/pages/article.asp?id=358 

I am trying to setup an environment for the Back to Back ISA Servers using Private IP in DMZ. Microsoft Exchange Server 2000 will be placed in the DMZ. Microsoft Exchange 2000 Server will be a stand alone Exchange Server without Front End and Back End solutions. Front End and Back End solutions are very expensive to implement. The Exchange Server in the DMZ will be functioning as an email server (just for emails). No corporate data will be stored in the Exchange Server.

The Active Directory of the Exchange Server has no relationship with the Private LAN. Private LAN has NT Servers as domain controllers AD in DMZ: companyname.com

Question:

1) How do I setup an environment to let the Internal LAN users to access Exchange Server in the DMZ? Have you ever tested out this configuration?

2) I follow the Offline folder concept in article 351. I have installed Firewall Client in my test PC. I have create a Protocol Definition for the Outbound Exchange RPC for Outbound TCP 135 with secondary connection of TCP 1025 – 65534. I am using the offline options.

a) After I open up the OWA to send “Email 1” to another user, I close the web browser.

b) Then, I open Microsoft Outlook to check emails (via the offline folder). I can see “Email 1”. All the emails are pulled down to the client PC.

c) I close Microsoft Outlook. If I go back to OWA to check emails, I notice that I can’t see “Email 1” anymore. It seems that the data is pulled to the Offline folder. Please help.

Question: Is it supposed to be in this manner? I thought that the OWA will also display all the emails that the users sent and received. OWA seems to be empty. Please advise.

You can publish Microsoft Exchange Server on both private and public address DMZs without any problems. I prefer private address DMZs because they are more secure and allow you to completely leverage all the inbound and outbound access controls provided by ISA Server. Public address DMZs depend on simple packet filters on the external ISA Server for inbound and outbound access control.

Internal network clients can access the Exchange Server using an IMAP or POP3/SMTP. Outbound Exchange RPC connections are problematic, and require you to configure an RPC Protocol Definition and install the Firewall client on the internal network clients. Inbound access to the Exchange server through the external ISA Server is easy; just create an Exchange RPC protocol rule on the external ISA Server. I do not recommend that you allow you internal network clients to loop back through the external interface of the ISA Server. Not only would it place extra stress on the external ISA Server, I don’t believe it would work.

However, it sounds like you configured the RPC Protocol Definition described in http://www.isaserver.org/pages/article.asp?id=351 and that it works for you. Very good!

The key question here is why put the Exchange Server on the DMZ? If the server needs to be accessed by internal and external network clients, and those clients have accounts in the domain, why not just put it on the internal network, or on a private address DMZ segment on the internal network? I discuss in great detail how to configure private address DMZ segments in ISA Server and Beyond.

I’m not sure why the OWA connection doesn’t show the email. It could be that the internal network Outlook client was configured as a POP3 client and is using a local .pst file instead of being connected to the Exchange Server. If you see the mail in the Exchange RPC or IMAP session, then you know the mail is still in the message store.

As always, its vital that you always test your Web Publishing Rules from an external network client. If you’re testing from an internal network client, you may be introducing other factors into the equation that do not apply when external users access your published site.

I have been expecting the article about “Destination Sets” lately and there it showed. Actually you were right that most of us find it difficult to understand what is meant by Destination Sets. Well, I have made my way through that section, and everything seems fine so far. I have done miracles so far on ISA, I really love that baby. But there is this rather small-big issue that I have not been able to settle yet.

You sure know that emails are the most lethal weapons these days. If you can not control them, you are either out of business or you just have nightmares during the day. I have just shifted to a new company lately, and since two months I have been studying their emailing habits and I can tell you, it is way out of control. First, I ensured that we have stable email server that could send and receive in any circumstances and secured it behind Mr. ISA. Now comes the difficult part, “What needs to be done is to stop users from using free based emails; like hotmail, yahoo and stuff. To tell you the truth, I have prepared a Destination Set especially for that, it is working but what I did was specify the URLs that either Hotmail or Yahoo uses. What I am looking for is:

“Does ISA understand if I only put the word “mail”, “webmail” to stop all the sites that contains those following words?” Like for example, if it does understand what I need then it will be able to stop sites like www.reddifmail.com or www.icredimail.com or www.thisiscyberia.com/webmail

I know this is hard to ask either from you or Mr. Bill Gates but if we did not ask then Enhancements would have not existed nor Service Packs. Finally I would like to thank you for reading my email and looking forwardto hearing from you, or Mr. Bill Gates

Its very true that email is the ticking time bomb for your organization. I would say that it’s the one place users are most likely to violate network usage policy. For some reason, users have a very personal attachment to their email, and feel their corporate email boxes are completely their own and therefore you have no right, as the network administrator and protector of network security, to prevent them from importing any virus or worm they want via email.

Its obvious that you can’t put up with that! For SMTP servers, you can implement antivirus solutions like GFI’s MailSecurity. This powerful tool can be installed on SMTP relays or on the Exchange Server itself, and it uses multiple virus checkers and advanced exploit detection.

Protecting against Web mail viruses is more complicated. You’ve done a good thing already by creating Destination Sets and blocking access sites contained in those sets. The big challenge when creating Destination Sets to block access to Web mail is finding out the FQDNs used by the Web mail sites out there. You can review your Web Proxy logs and get an idea of what sites users are abusing.

Destination Sets are a good first step, but your primary goal is to prevent viruses and worms from entering your network via Web mail. If users are able to find Web mail sites that you haven’t blocked yet, they’ll be able to import security exploits into your network! Sure, you can fire them after they’ve compromised company secrets by allowing a hacker to install a backdoor into your network, but it’s a lot better to prevent these things from happening in the first place.

The good news is that GFI has another product, called ISA Server DownloadSecurity, that will examine the HTTP traffic and looks for viruses, worms and other dangerous payload. When download security examines the HTTP traffic, you don’t have to worry about users bring in nasties into your network, because DownloadSecurity will catch the attachments before they can pass through the ISA Server.

Regarding your question on whether ISA Server will recognize keywords such as “mail”, etc. The answer is NO. ISA Server will only block what you have in your Destination Sets, although you can include wildcards in your Destination Sets entries.

In Regards to your Article on how to configure the SMTP filter with 2 servers, I also read that there is another (more difficult) scenario which I have.

I’m running ISA and Exchange 5.5 on the same server and I could not find any workaround in the forums, besides for the Exchange 2000 which has an Virtual SMTP server.

Exchange 5.5 does not have a virtual SMTP server, do I have to uninstall the Internet mail connector and install IIS Virtual SMTP? what would then receive the mail? I can´t configure a specific IPs on the Internet Connector on 5.5 because it doesn’t have that option.

I wonder if it’s possible to make my configuration work?

The ISA Server Message Screener requires Internet Information Server 5.0. You don’t mention if your Exchange 5.5 Server is installed on Windows NT 4.0 or Windows 2000. If its installed on a Windows NT 4.0 machine, then you won’t be able to install the Message Screener  on the same machine as the Exchange 5.5 server.

If the Exchange 5.5 Server is installed on a Windows 2000 Server, you may be able to get it to work. However, I have never tried this type of installation, so I can’t tell you for sure if it would work or not. If you do try it, make sure that you bind multiple IP addresses to the Exchange Server’s interface, because you do not want the Exchange Server and the IIS SMTP service listening on the same IP address.

You need to configure a remote domain in the IIS SMTP service and configure it to relay to the IP address used by the Exchange Server. This might work, because the Exchange Server won’t be involved with the Message Screener; all it will do it accept mail relayed to it from the IIS 5.0 SMTP service. However, there may be hidden issues that will prevent this from working. The only way to know is to configure this scenario in your test lab and see what happens.

A better solution, if you don’t have any other Windows 2000 Servers around to act as an SMTP relay, is to configure the Message Screener on the ISA Server itself. You can install the Message Screener on the ISA Server and it will filter for keywords, attachment and domain names in the same way it does when you install it on an SMTP relay on the internal network. You can even use the Message Screener on the ISA Server itself to screen both incoming and outgoing mail. However, the Message Screener won’t be able to distinguish between incoming and outgoing, so the same rules will apply in both directions.

When configuring the Message Screener on the ISA Server, you have to pay special attention to the configuration of the SMTP service, or you could end up not receiving any incoming or sending any outgoing mail! Make sure that socket pooling is disabled, and double check that inappropriate relay is disabled. The details of this configuration are included in the new ISA Server and Beyond book.

I have just read your article regarding FTP and ISA. At the bottom you have mentioned to get full FTP functionality, you said “Therefore, if you require FTP uploads to a web site or a FTP server, you will have to configure as a SecureNAT or Firewall Client, in addition to making it a Web Proxy client. Note that you do not need to disable the machine from being a Web Proxy client; just add one of the other client types to the configuration”

How do you actually add the other client types to the configuration?

If the machine is configured as only a Web Proxy client, then you can’t do FTP uploads. The Web Proxy service only allow FTP downloads. That explains why you can’t upload when you publish FTP sites on the internal network using Web Publishing Rules. Its generally an excellent idea to prevent external users from uploading to FTP servers since FTP is an inherent unsecure protocol.

For internal clients that need to upload to external sites, you need to configure the client as an SecureNAT and/or Firewall client. Note that these client types are not mutually exclusive and you can configure the same machine as a SecureNAT, Firewall and Web Proxy client. How communications are handled depends on the services you’re accessing and how the ISA Server is configured.

To configure a machine as a Firewall client, just install the Firewall client software onto the machine. If the machine is configured as both a Firewall and Web Proxy client, all HTTP requests and FTP request sent by the browser will be handled by the Web Proxy service. All other TCP and UDP requests will be handled by the Firewall service, except for those requests directed to an IP address in the LAT. In that case, the request is sent directly to the LAT host and bypasses the Firewall service completely.

You can configure the machine as a SecureNAT client by using a default gateway on that client which can route Internet bound requests to the internal interface of the ISA Server. If the machine is configured as a Web Proxy, Firewall and SecureNAT client, the SecureNAT client configuration will handle all non-TCP/UDP requests, such as IMCP ping, tracert and PPTP connections. Note that there are exceptions to these rules, depending on how the ISA Server is configured. One thing there is no exception to is the fact that Firewall client only handles TCP and UDP requests, and only the SecureNAT client can handle non-TCP/UDP requests.

I’ve been spending a lot of my time reading through your articles on isaserver.org website – and I must say I’ve learned a lot!! Thank you. I really hope you can help me with my problem.

We’ve got an application we are running at our Technikon called GUICAT. The application was never intended to run accross different networks. (each site should have its own server and clients connecting to the server – all within the same network). But to save costs, one of our other learning institutions is hosting the server part of the app and we are connecting to it via the GUICAT client. Now, for this work, you need to basically open communication between a subnet of your local network (which has routable internet addresses) and the server. Using Gauntlet firewall, it works like a charm. Simply put a rule in specifying to open all TCP port between the subnet on our local network and the one IP address on the outside. No problem.

But, on ISA it doesn’t work. Since Gauntlet purely routes the packet from the internal IP to the external server and back, no NAT happens. Basically they are talking as if no firewall are between them (only routing happens). I’ve put a packet sniffer between the machines and they are talking fine. I know that ISA works differently. First requests get passed to ISA, and then ISA probably changes the request to use its outside interface IP address. The problem that I am having is that I can’t get any communication back from the external server. I’ve got Protocol Rules and IP Packet Filters in place to allow the various communication between the boxes (In and outbound), but it doesn’t work. I think that the NAT is the problem and the packets don’t know how to come back. Is there a way to basically tell ISA, that if you receive requests from a certain IP or Subnet, to just route it through to the destination and vice versa. This should be possible because I am using routable internet addresses on my inside network.

PLEASE HELP!!!

Waiting for your sound advice.

As you’ve learned, ISA Server does not support static NAT mappings. The Windows 2000 RRAS NAT service allows you to map an IP address on the external interface of the RRAS NAT server and all packets received on that address are forwarded to the server on the internal network. This is very convenient if you don’t want to control the traffic that moves to the server from the external network, but it’s an immanently unsecure configuration.

You should not be wasting those public IP addresses on a LAT segment! The ISA Server will always use NAT between the LAT hosts and the external networks. What you need to do is renumber your internal network to use private addresses and then use the public addresses on a DMZ segment or on the external interface of the ISA Server.

Now, the solution to your problem is that you need to find out what protocols are required by your application. The first place to check is with the vendor of the product. It’s the vendor’s responsibility to have complete documentation on what protocols are used by their product. However, in the real world developers don’t document their applications very well, and when the developer leaves, he often takes the secrets with him.

If that happens, you have figure it out for yourself. The tools for your investigation are Network Monitor or any other network analyzer, the Firewall log, the packet filter log, and sometimes the Web Proxy log. You need to generate traffic from an external network client to the server on the internal network. At first, all the traffic will be blocked at the external interface of the ISA Server. When you get your initial information, you’ll create Protocol Definitions and Server Publishing Rules and then test again. You create more definitions and rules and test again. You’ll need to run the network monitor on the ISA Server and the internal server and the external client.

The worst case scenario is that your application will require secondary connections. In that case you’ll have to make the internal network server a Firewall client and then configure a wspcfg.ini file. If that happens, you should check out Jim Harrison’s excellent article on the Firewall client and the firewall client configuration files.

I hope you found these questions are answers helpful. Even if I didn’t get a chance to answer your question, hopefully you’ve learned something here that you can apply to your ISA Server network configuration. Each week I receive hundreds of questions to [email protected] and I can only answer a few of them. If you have a question, please feel free to write to me, but make sure you post your question on the ISAServer.org Message Boards too!

If you would like us to email you when Tom Shinder releases another article on ISAserver.org, subscribe to our ‘Real-Time Article Update’ by clicking here. Please note that we do NOT sell or rent the email addresses belonging to our subscribers; we respect your privacy!