Configuring Exchange RPC Publishing in a Back to Back ISA Server Environment

Configuring Exchange RPC Publishing in a Back to Back ISA Server Environment

By Thomas W Shinder

A couple of week’s ago I did an article on Exchange Server RPC publishing. If you missed that article, check it out at http://www.isaserver.org/pages/articles.asp?art=327 In that article, I described the advantages of using Exchange RPC publishing over the typical SMTP/POP3/IMAP publishing setup. The biggest advantage is that your users can access Exchange using Outlook 2000/XP from remote sites in the same way they do from the internal network. Your roaming notebook users will love you!

A few of you wrote to me about whether this would work in a back to back ISA Server firewall configuration. The short answer is YES! You can setup a back to back ISA Server firewall configuration and publish your Exchange Server using Exchange RPC publishing rules.

In this article I’ll describe a test network configuration and how each firewall and the Exchange Server is configured. Using this approach, I hope you’ll be able to replicate the configuration in your own test lab, and then generalize what you learn from this lab to your production network. If you don’t have a test lab, do what so many of us do: Use VMware (www.vmware.com) and create a lab on a single machine!

The figure below describes the basic interface configuration on each of the players. Starting from the top, there’s the External ISA Server, the Internal ISA Server and finally the Exchange Server.

Let’s look at each of the server’s more closely:

IP Address: 10.0.0.2/24

DG: 10.0.0.1

DNS: 10.0.0.2

WINS: 10.0.0.2

DNS Service installed

WINS Service installed

Active Directory installed

NetBIOS Name: CLIENTDC

FQDN: CLIENTDC.internal.net

The Exchange Server is also the domain controller in the Windows 2000 domain. Since this is the only server in the domain, DNS must be configured on this machine. The machine is configured to use itself as it own DNS and WINS server, and its interface is configured to dynamically register itself in the DNS. I highly recommend you configure DNS first before running dcpromo.

Notice that I’ve configured the DNS server on this machine to accept dynamic updates. As you might know, DDNS can sometimes cause problems with VPN connections. The reason for this is that the ISA Server will register itself in the DDNS using its VPN interface IP address.

These issues won’t affect us today because we’re not configuring a VPN, but its something to keep in mind for the future.

The NetBIOS name of the Exchange Server is CLIENTDC. The domain name is internal.net. It’s an excellent idea to keep the DNS host name and the NetBIOS name the same; you can run into all sorts of problems when you disjoint your NetBIOS and DNS host naming schemes. This is a bit problematic when you use illegal characters like underscores ( _ ) in your NetBIOS names, but I know you would never do that since you knew a changeover to DNS would be inevitable .

Your DNS infrastructure is especially important when designing this kind of solution for Exchange RPC publishing. The reason is that you want to use the same name for both internal and external network access. For example, if the user connected to the Exchange Server using the name clientdc.internal.net on the internal network, you want the client to be able to connect to the machine using the same name from an external network location.

A split DNS configuration is the best way to configure your infrastructure when you use the same domain name for internal and external network resources. With the split DNS configuration, you use the same domain name for your internally and externally accessible network resources. The difference is that internal network clients use DNS containing only internal network addresses, and external network clients use DNS servers containing external network addresses. These external network addresses are those addresses you use in your Web and Server Publishing Rules. One good place to put this publicly available DNS server is on a DMZ segment between your ISA Servers in the back to back configuration.

IP Address: 10.0.0.1/24

DG: None

DNS: 10.0.0.2

WINS: 10.0.0.2

IP Address: 10.0.200.2/24

DG: None

DNS: 10.0.0.2

WINS: 10.0.0.2

DNS Service NOT installed

WINS Service NOT installed

Active Directory NOT installed

NetBIOS Name: ISAINT

FQDN: ISAINT.internal.net

There really isn’t anything tricky about the ISA Server configuration for the internal ISA Server. Note that you need to make the external interface of the internal ISA Server use the internal interface of the external ISA Server as its default gateway! This is commonly overlooked, so make sure you don’t overlook it.

Its worth pointing out that you should create a Client Address Set that contains the IP addresses of the servers you intend to publish. The reason is that most of us want to control outbound access by user/group membership. This works fine when you have the firewall client installed or are using the Web Proxy client configuration, but none of the published servers should have the firewall client installed. You should never, NEVER install the firewall client on a domain controller or an Exchange Server. OK – you can do so if you wish, but you’ll be on the Web boards asking questions why things aren’t working if you do .

Actually, you can install the Firewall client on published servers. Sometimes you need to do this for special purpose Server Publishing situations. But even if you do have the firewall client installed on published servers, you typically don’t have logged users logged onto those servers. To get around that problem, just create a client address set and allow outbound access for the set.

You do not need to enable IP Routing for this publishing solution to work. It just enabled it so I could test access to the Internet using ping and tracert. You can forego this setting, or turn off IP Routing on the ISA Server after you’ve done your testing.

I left the default Site and Content Rule in place because I was lazy . However, it’s always a good idea to whack or change the default Site and Content Rule. Chaning the default Site and Content Rule prevents anonymous requests from going through the ISA Server. For example, if you’re not using the Default Site and Content Rule, you can create an “all open” Site and Content rule that applies only to the Exchange Server (as defined in a Client Address Set).

Again, I can’t stress enough how important it is that you don’t install other network services on the ISA Server unless you have a very compelling reason to do so. Its not that things won’t work if you do, but it makes the configuration more complex and less secure. Remember that each service you add to the ISA Server creates a new portal or vector of attack for Internet scum.

IP Address: 10.0.200.1/24

DG: None

DNS: None

WINS: None

IP Address: 192.168.1.33/24

DG: 192.168.1.7

DNS: 192.168.1.185

WINS: None

DNS Service NOT installed

WINS Service NOT installed

Active Directory NOT installed

NetBIOS Name: ISAEXT

FQDN: ISAEXT.internal.net

The IP addressing configuration for the external interface allowed the external ISA Server to integrate with the network I was working on at the time. The default gateway on the external interface would in practice be the remote router at your ISP or at your own gateway. In this case, 192.168.1.7 is actually an ISA Server on the local network which connects to the Internet. Same is true for the DNS server setting on the external interface; that DNS server is an internal server configured to resolve Internet host names.

The Protocol Rule for HTTP/HTTPS/DNS Query/DNS Zone Transfer/SMTP allows the internal network Exchange Server to resolve Internet MX domain names and send outbound SMTP messages. There’s actually in no reason for the HTTP rules. I just thought it would be nice to browse from the Exchange Server.

The Site and Content Rule can be changed so that only the external interface of the internal ISA Server is allowed access to All sites. This is a similar situation as we ran into with the internal ISA Server. You can make changes depending on the level of outbound access control you desire.

The external ISA Server is not a member of the internal network domain. If you were to make the external ISA Server a member of the internal network domain, you would break the security zone created for the DMZ segment and put your internal network under increased risk. Just make the machine a member of a workgroup and make sure to disable the server service.

The Outlook client computer should be able to connect to the Exchange Server regardless if the machine is connected to the internal network or at a remote location. Again, the key to this working is a well-planned and implemented name resolution architecture. Check out the previous article on Exchange RPC publishing to see how to configure the client to connect to the published Exchange Server.