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

Get the Book!

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:

Details of the Exchange Server

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.

NOTE:

If you would like more information on how to configure a domain controller in general, check out my article on installing ISA Server on a domain controller at http://www.isaserver.org/pages/articles.asp?art=17

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.

NOTE:

For more information on this issue and some possible fixes, check out:

Q289735

Q246804

Q292822

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 .

DNS Configuration for Support the Exchange Server RPC Publishing Rule

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.

Details of the Internal ISA Server

Internal Interface:

IP Address: 10.0.0.1/24

DG: None

DNS: 10.0.0.2

WINS: 10.0.0.2

 

External Interface:

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

ISA Server Configuration:

  • A protocol Rule was created to allow outbound HTTP/HTTPS/DNS Query/DNS Zone Transfer/SMTP
  • A client address set was created that included the IP address of the Exchange Server (10.0.0.2) and outbound access to this protocol rule was allowed to this client address set
  • IP Routing was enabled so that I could test network integrity by ping through both ISA Server to an Internet host
  • The Default Site and Content Rule was left in place
  • The ISA Server was installed in Integrated mode as a stand-alone ISA Server (not an enterprise array member)
  • The internal ISA Server is a member of the of the Windows 2000 domain (internal.net)
  • An Exchange RPC Server Publishing Rule was created using the 10.0.200.2 for the external interface address and 10.0.0.2 as the address for the internal network server
  • The RPC filter was enabled
  • 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).

    NOTE:

    The RPC filter must be enabled! If things don’t work for you, it might be that you were messing around with the ISA Server and disabled the RPC filter. Double check that the filter is enabled!

    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.

    Details of the External ISA Server

    Internal Interface:

    IP Address: 10.0.200.1/24

    DG: None

    DNS: None

    WINS: None

     

    External Interface:

    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

    ISA Server Configuration:

  • A protocol Rule was created to allow outbound HTTP/HTTPS/DNS Query/DNS Zone Transfer/SMTP
  • A client address set was created that included the IP address of the external interface of the internal ISA Server (10.0.200.2) and outbound access to this protocol rule was allowed to this client address set
  • IP Routing was enabled so that I could test network integrity by pinging through both ISA Server to an Internet host
  • The Default Site and Content Rule was left in place
  • The ISA Server was installed in Integrated mode as a stand-alone ISA Server (not an enterprise array member)
  • The external ISA Server is a stand-alone server and is not a member of any domain
  • An Exchange RPC Server Publishing Rule was created using the 192.168.1.33 for the external interface address and 10.0.200.2 as the address for the internal network server
  • The RPC filter was enabled
  • 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.

    NOTE:

    For more information on how to secure the ISA Server, check out these two articles:

    http://www.isaserver.org/pages/articles.asp?art=13

    http://www.isaserver.org/pages/articles.asp?art=14

    Get the Book!

    Notes on Client Settings

    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.

    I hope you found this article helpful or at least interesting. If you have any questions or comments on what you’ve read here, let me know! Write to me at [email protected] and I do my best to answer the question. Please put the name of the article in the subject line of the email so that I know it refers to this article. Thanks! –Tom.

    Leave a Comment

    Your email address will not be published. Required fields are marked *

    This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

    Scroll to Top