Configuring VPN Access in a Back to Back ISA Server Environment


Configuring ISA Server 2000 : Building Firewalls for Windows 2000

By Deb and Tom Shinder
 
Amazon.com

 

VPNs have been a topic of growing interest for the last couple years. However, since the tragic events in New York City in September of 2001, the subject has become red-hot. Why? Business and network managers now have a greater awareness that the weakest link in any design, whether it be a network or a business, is too high a level of centralization. Distributed systems are highly fault tolerant and difficult to bring down, while centralized systems can be brought to their knees with a single blow.

 

VPNs allow the corporate workforce to be distributed throughout the globe and yet remain in touch with the corporate network. The cost savings of a well-designed VPN solution can be tremendous. With a well designed and implemented VPN solution, companies do not need to shell out enormous sums of money for office space in very expensive downtown locations for every employee. The best, most productive employees, are able to get their work done at home more quickly and efficiently than they ever could in a harried and socially disorganized office environment.

 

Fortunately, for us ISA Server administrators, ISA Server is up to the task of handling VPN network communications. The VPN Wizards included with ISA Server make configuring a VPN Server a virtual no brainer. The Wizard does the work of configuring packet filters and the Routing and Remote Access Service (RRAS) for you. Just a couple of tweaks to RRAS might be required, and then you’re ready to roll.

One VPN problem that seems to vex many of our www.isaserver.org visitors is how to allow external network VPN clients access to an internal network. In this article, we’ll tackle this problem and cover the following issues:

  • Configuring the Internal ISA Server

  • Configuring the External ISA Server

  • Configuring the VPN client computer

  • As you’ll see, allowing your external network VPN clients access to your internal network through a back to back ISA Server configuration is quite easy; once you know how.
     

     

    Configuring the Internal ISA Server

    In a back to back ISA Server configuration, the ISA Server with an interface in the DMZ and an interface on the internal corporate network is considered the internal ISA Server. This ISA Server will act as the end point for the final VPN link for external network VPN clients and allow them access to resources on the internal network.

    Interface configuration is straightforward:

     

    Internal interface:

    IP address: address valid on the network segment the interface is connected to

    Subnet Mask: mask appropriate for network segment that interface is connected to

    Default Gateway: NONE!

    DNS Server: address of DNS server on the internal network

    WINS Server: address of WINS server on the internal network

    Note: Adapter will dynamically register with internal DNS server

    NetBIOS over TCP/IP is enabled

     

    External interface:

    IP address: address valid on the network segment the interface is connected to

    Subnet Mask: mask appropriate for network segment that interface is connected to

    Default Gateway: IP address of the internal interface of the external ISA Server

    DNS Server: address of DNS server on the internal network

    WINS Server: NONE!

    Note: Adapter will NOT dynamically register with internal DNS server

    NetBIOS over TCP/IP is disabled

     

    While the interface configuration is simple, you have to prepare the network to support the VPN servers and clients. I recommend that you install one or more DNS servers on your internal network that can resolve Internet host names. This can be accomplished by ensuring that the Root Hints file is primed on the DNS server, and that the ISA Servers in the path to the Internet have access policies enabled so that the DNS server has access to both TCP and UDP port 53 outbound. Jim Harrison has a number of excellent articles in the Learning Zone to help you with network configuration. Also, check out my article there on a simple ISA Server work.

     

    Note:

    I recommend that you disable recursion on your internal network DNS servers, and instead configure the DNS servers to use your ISP’s DNS server as a forwarder. The reason for this is that your ISP’s DNS servers have a much larger cache than your own DNS server can ever have. Using your ISP’s DNS server will significantly improve the performance of DNS queries.

     

    While a lot of texts and advice out there states you do not need a WINS server on your internal network, you’ll probably want to install one and configure your servers to be WINS clients if you wish to support the browser service for your VPN clients. However, if you do not need to support the dreaded browser service for your VPN clients, then there is no compelling reason to install a WINS server on your internal network (with the exception being you have NetBIOS dependent applications or services.)

     

    In the environment we’re covering here, the internal ISA Server is a member of the internal network Windows 2000 domain. We will not cover issues involved with making the internal ISA Server a domain controller, because its assumed that if you have taken the time and money to put together a back to back ISA Server configuration, then you do not want to mess up your configuration by making the internal ISA Server a domain controller. If you want to know more about configuring the ISA Server as a domain controller, check out this article.
     

     

    Configuring the VPN Server

    ISA Server makes it easy to configure the VPN Server. Just perform the following steps:

    1. Open the ISA Management console and drill down to the Network Configuration node.

    2. Right click on the Network Configuration node and click All VPN Client Connections.

    3. The Welcome to the ISA Virtual Private Network Configuration Wizard appears. Click Next.

    1. On the Completing the ISA VPN Server Configuration Wizard page, click the Details button and read what the Wizard will do to your machine. After reading the details, click Back. Then click the Finish button.

    2. If RRAS isn’t already started, the Wizard will start the server for you. It will also configure packet filters to allow inbound PPTP and L2TP/IPSec connections.

    That’s it! The Wizard quickly and painlessly configured both RRAS and ISA Server to allow inbound VPN calls. However, your work isn’t completely done from the VPN/RRAS viewpoint. While the Wizard does an admirable job, it might not get everything right or the way you want it when it comes to configuring the VPN server. You should go to the RRAS console and check out your configuration. If you need some help, check out http://www.isaserver.org/shinder/tutorials/configuring_ISA_for_inbound_VPN.htm.

     

    One other thing you might want to do is configure a DNS server publishing rule on the internal ISA Server, if you wish the DMZ hosts to use a DNS server on your internal network. This is not required by the back to back ISA Server VPN configuration, but it’s something you should think about.

     

    Another important consideration is how you configure remote access permissions for your VPN server. Will access be controlled by policy or by account configuration? If you have a mixed mode Active Directory domain, then you don’t have the choice to allow access by policy and you must configure accounts to have access. If you have a native mode domain, you can choose to use RRAS policy to control access. Remember, the only reason to run in mixed mode is if you have Windows NT 4.0 BDC in your domain. If you don’t, then switch on over to native mode pronto!
     

     

    Configuring the External ISA Server

    The ISA Server that interfaces with the untrusted network (the Internet) and the DMZ segment is the external ISA Server. The external ISA Server is the first point of attack for Internet intruders, as well as everyone else. This machine should be configured as either a stand-alone server in a workgroup, or as a member of a domain that is accessible from the DMZ segment. You want this machine to have nothing to do with the authentication environment for your internal network.

     

    Like the internal ISA Server, interface configuration is straightforward:

     

    Internal interface:

    IP address: address valid on the DMZ segment

    Subnet Mask: mask appropriate for the DMZ segment

    Default Gateway: NONE!

    DNS Server: variable

    WINS Server: variable

    Note: Adapter will NOT dynamically register with DNS server

    NetBIOS over TCP/IP is enable or disabled – depends on requirements

     

    External interface:

    IP address: according to your ISP

    Subnet Mask: according to your ISP

    Default Gateway: Assigned by your ISP, or your router connecting to the Internet

    DNS Server: address of DNS server of your ISP

    WINS Server: NONE!

    Note: Adapter will NOT dynamically register with internal DNS server

    NetBIOS over TCP/IP is disabled

     

    Notice that some of the settings on the internal interface of the external ISA Server are variable. The reason for this is that you may or may not have a dedicated name resolution scheme that you use for your DMZ segment. If you have a public DNS server, there’s a good chance that you are running a DNS server on the DMZ. If that’s the case, you might want to include that DNS server’s address on the internal interface of the ISA Server. If you are hosting public DNS services on your internal network, then enter the address of the external interface IP address on the internal ISA Server. The NetBIOS interface should generally be disabled on both interfaces of the external ISA Server. However, if you require file and printer sharing and the Microsoft client on the internal interface, you’ll have to leave this on. I recommend turning it off to protect your external ISA Server.

     

    Note:

    Keep in mind that when a user VPNs into the external ISA Server that this use will be directly connected to your DMZ segment. You want to make sure that the user does not have permissions to access anything on the DMZ segment using the credentials supplied by the VPN client. Create a group on the external ISA Server that has very limited access permissions.
     

     

    Notes on VPN Server Configuration

    You can read details on how to configure the VPN server at the link near the top of this article, but there are some things I think are worth pointing out here. First, make sure you configure an IP address range for the VPN clients to use on the external ISA Server. Its very unlikely that there will be a DHCP server on the DMZ segment, so you’ll need to create an address pool for the VPN clients. The internal ISA/VPN Server can assign addresses obtained from a DHCP server, since it’s likely that you’ll be running DHCP on the internal network.

     

    You do have the option is letting the “assign via DHCP option” stay as it is. If you do not have a DHCP server, the VPN clients will be assigned autonet addresses in the 169.254.0.0/16 range. However, this may mess up your routing configuration, especially when the clients create a connection to the internal ISA Server. I recommend you do not depend on autonet addresses.

     

    If you want to use L2TP/IPSec, all machines participating in the VPN link must have a machine certificate trusted by both machines. The easiest way to do this is to have all machines belong to the same domain and configure a Group Policy that autoenrolls domain members and assigns them a machine certificate.

     

    If you have machines that are not domain members (such as laptops), they can be assigned machine certificates by using the Web browser interface to the Microsoft certificate server. When you install the Microsoft Certificate Server, make sure you install it as a Standalone Root server, or else you will not have the option to use the browser to assign client machine certificates.

     

    Of course, you always have the option of using a 3rd party client certificate. You can install the 3rd party certificates on the clients using the method described by the vendor.

     

    Note:

    PPTP VPN servers do not require certificates, but there are important configuration options regarding authentication. For a high level of security, you should enable only EAP/TLS and Microsoft CHAP v2. This might create problems with your downlevel Windows clients, so make sure to check up on the latest updates to DUN for your downlevel Windows clients. Also, keep in mind that no Windows client other than Windows 2000 and Windows XP can use L2TP/IPSec.
     

     

    Configuring the Client Connections

    When you configure the VPN client connections, keep in mind what you’re trying to accomplish. The goal is to create a pass-through VPN link. The first connection is to the external ISA/VPN server, and the second connection passes through the first VPN connection to create the link to the internal VPN server. That’s why it’s called a pass-though VPN link!

     

    Go to the VPN client computer to create the first link (this example uses a Windows 2000 client):

    1. Right click the My Network Places icon on the desktop and click Properties.

    2. In the Network and Dial-up Connections window, double click on the Make New Connection icon.

    3. Click Next on the Welcome to the Network Connection Wizard page.

    4. On the Network Connection Type page, select the Connect to a private network through the Internet option. Click Next.

    1. On the Public Network page, select the appropriate option for your environment. If the client uses an always-on, directly connected link to the Internet, use the Do not dial the initial connection option. If the client needs to make a modem dial-up connection, select the Automatically dial this initial connection option and select the ISP/modem DUN connectoid from the list. In this example the client is directly connected to the Internet. Click Next.

    2. On the Destination Address page, type in the FQDN or IP address of the external interface of the external ISA Server. Click Next. (note in this example I’m using a private address for demonstration purposes only. You will use a public address in your production environment).

    1. On the Connection Availability page, select the option that fits your security environment best. I always go with Only for myself for security reasons. Click Next.

    1. On the Completing the Network Connection Wizard page, name the connection. In this example, we’ll call it VPNEXTERNAL.

     

    Now let’s configure the second VPN link that connects the client to the internal VPN server:

    1. Right click the My Network Places icon on the desktop and click Properties.

    2. In the Network and Dial-up Connections window, double click on the Make New Connection icon.

    3. Click Next on the Welcome to the Network Connection Wizard page.

    4. On the Network Connection Type page, select the Connect to a private network through the Internet option. Click Next.

    5. On the Public Network page, select the Automatically dial this initial connection and select the name of the DUN connectoid used to connect to the external ISA/VPN server. Click Next.

    1. On the Destination Address page, type in the IP address of the external interface of the internal ISA Server. Click Next. (note in this example I’m using a private address because the DMZ is a private address DMZ segment. While you do have the option to create a public address DMZ segment in a back to back configuration, public address DMZs are not the preferred back to back DMZ configuration using two ISA Servers).

    1. On the Connection Availability page, select the option that fits your security environment best. I always go with Only for myself for security reasons. Click Next.

    2. On the Completing the Network Connection Wizard page, name the connection. In this example, we’ll call it VPNINTERNAL.

    That’s all there is to it! You’ll see your links in the Network and Dial-up Connections window.

     

     

    Double click on the VPNINTERNAL link. In the Connect dialog box, click Connect. After you establish the first connection, you will see the dialog box for the second VPN link. Click enter the appropriate credentials and click Connect.

     

     

    After the second VPN link is established, you’ll be informed for your success:

     

     

    You can go to the RRAS consoles of both the ISA/VPN machines and see the connections:
     

     

    VPNEXTERNAL RRAS Console


     

     

    VPNINTERNAL RRAS Console

     

    You’ll notice that we have L2TP/IPSec connections here. The VPN server always negotiates with the VPN client as to the type of VPN link to create. L2TP/IPSec is used preferentially, but if such a link cannot be created, PPTP will be used instead.

     

    In Windows 2000, you can do some very crude monitoring of your L2TP/IPSec connections using the ipsecmon console. From the Run command, type ipsecmon and click OK. You’ll see your connections appear in the console. Note the policy used is the default L2TP/IPSec policy. This policy is created automatically and you cannot view it in the IPSec policy MMC console. There are some tricks you can use to create other IPSec policies, but we’ll discuss those at another time J .

     


     

    Notes on VPN Client Configuration

    While configuring the VPN client connections is easy, there are some issues with these connections of which you should be aware. The biggest problem that you’ll come up against is the dreaded browser service. This service allows users to browse for internal network resources by using the My Network Places applet.

     

    If the VPN client machine is not a member of the internal network domain, you can forget about having the domain appear in the browse list. I’ve tried every way you can think of, including WINS servers and LMHOSTS entries with the dom:domainname entry but it just doesn’t seem to work! It’s pretty bizarre, because the VPN client will be assigned the WINS server address to query for the segment and domain master browser, so it should work. You can confirm the WINS server assignment by doing an ipconfig /all on the client after the link is established.

     

    You will see the domain appear in the browse list if you configure the client to be a member of the domain. However, you must log onto the domain for this to work. The users need to select the Log on using dial-up connection option:

     

     

    After they click OK, they need to select the link used to connect to the internal network. They’ll see the following and they need to select the DUN connectoid that links to the internal VPN server:

     

     

    The user is asked for credentials. They should enter the credentials for the connection and click Connect. You can make this easier by having the machine remember the credentials. They will be asked a second or third time for credentials, depending on whether they need to establish a dial-up link to their ISP. Once the link to the internal ISA/VPN Server is established, they will be logged on and have access to the desktop.

     

    No matter how you cut it, accessing resources via the browser service is going to be slow. If there is a way to optimize this service, its beyond me. However, this isn’t all bad, because the browser service can be a tremendous security risk since it allows anyone to look around for “interesting stuff” on your internal network. Its best to disable the browser service if you can and make users connect to resources using a UNC path.

     

    Conclusion

    Setting up the back to back ISA/VPN server is relatively simple once you get all the steps down. The biggest problems are related to certificate assignments and the browser service. The certificate assignment process can be solved, but there doesn’t appear to be any fix for the performance problems with the browser service. As with any VPN roll out, make sure you have your routing infrastructure, WINS and DNS configurations in place and working before you start configuring your VPNs. If you name resolution and routing infrastructure isn’t in place an working, you will have many inexplicable problems that will be difficult to troubleshoot, and Jim and I will tell you to fix that first J .

     

    For more details on ISA Server configuration, make sure to check out the Learning Zone. Also, you must get the book! Thanks! -Tom.

    Leave a Comment

    Your email address will not be published.

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

    Scroll to Top