| ||||||
Search Microsoft.com for: |
Chapter 9 - Coexistence with Microsoft Proxy ServerBy Kostya Ryvkin, Dave Houde, Tim Hoffman Chapter 9 from MCSE: Implementing and Supporting Microsoft Proxy Server 4.0, published by Prentice Hall This chapter tells you about Proxy Server connectivity issues. We will see how to integrate a Proxy Server computer with a Remote Access Server (RAS) using Point-to-Point Tunneling Protocol (PPTP). We will discuss different scenarios where PPTP enabled computers coexist with Proxy Server. If your network uses Exchange for messaging and you are not sure if it will still work after you install Proxy Server, this chapter will give you the answer. Here also we will point out different scenarios to allow you to accomplish this goal. We will also look at how Proxy Server works with SQL Server, FTP servers, and Telnet servers. You will learn what a "demilitarized zone" is (in the Information Technology context) and will be able to plan sophisticated network configurations with Proxy Server in a mixed environment Proxy Server and the Point-to-Point Tunneling Protocol How Does PPTP Work? Why Can't WSP Clients Use PPTP? Proxy Server and Exchange Server Installing Exchange Server on the Internal Network Putting Exchange Server on the Proxy Server Computer Microsoft SQL Server and Proxy Server FTP Server Behind Proxy Server Non-Windows Servers Behind the Proxy Server Other Internet Services Behind Proxy Server At the end of this chapter you will be able to:
Proxy Server and the Point-to-Point Tunneling ProtocolToday, many companies utilize the Internet not only for the purpose of gaining access to the information it contains, but also to provide network connections to employees who are out of the office or on the road. It has always been the case that utilizing the public Internet is a much cheaper form of connecting remote locations than using dedicated direct links or long distance phone lines. However, there have always been concerns about transferring confidential or secret information though the public Internet. The solution to this problem is to create a Virtual Private Network based on encrypted tunnels provided by the PPTP. The idea behind PPTP is based on the encapsulation and encryption of IP packets into a secured tunnel. A tunnel is nothing more that an idea of sending streams of encapsulated packets in secured envelopes that cannot be easily decrypted. Even if somebody captures such an envelope during its travel through the Internet, its contents will not make sense. A reasonable question in this case is, "How can I combine Microsoft Proxy Server features with the advantages of PPTP?" To answer this question, let's first look at PPTP operation and architecture. How Does PPTP Work?Point-to-Point Tunneling Protocol is a network protocol that provides a secure way to transfer data from a remote client to a private server or network by creating a Virtual Private Network (VPN) across TCP/IP-based data networks. The networking technology of PPTP was created as an extension of the Point-to-Point Protocol (PPP) referred to in RFC 1171. PPTP is a network protocol that encapsulates PPP packets into IP datagrams for transmission over the Internet or other public TCP/IP-based networks. PPTP can also be used in private LAN-to-LAN networking. The PPTP encapsulation technique is based on the Internet standard GRE (Generic Routing Encapsulation), which allows tunneling of protocols over the Internet. (For more information about this you may review RFC 1701 and RFC 1702. You can find RFCs at http://www.cis.ohio-state.edu/rfc/ or http://www.rfc-editor.org. ) A typical PPTP scenario assumes the remote client already has an Internet connection from its local Internet Service Provider (ISP). Clients may use computers running Windows NT Server or Workstation version 4.0, dial-up networking, and the remote access protocol PPP to connect to an ISP. Being connected to the Internet, the client makes a second dial-up networking call over the Internet connection. Data sent, using this second connection, is in the form of IP datagrams that contain PPP packets. This second call actually creates a virtual private networking (VPN) connection to a PPTP server on the private enterprise LAN - this is referred to as a tunnel. Let's see how the PPTP client creates a packet to send to the PPTP server. For the purpose of our discussion, let's assume that the PPTP client is connected to the Internet using a LAN adapter (the situation changes slightly if the PPTP client uses a communication device such as modem). The process of encapsulating the data in the PPTP datagrams is illustrated in Figure 9.1. Figure 9.1: PPTP concepts. As you can see, when the application on the PPTP client computer sends a packet to the PPTP server, the data is first encapsulated in the IP datagram using the private IP address - the one that was assigned when the PPTP connection was established. Then the IP packet gets encapsulated into the PPP packet and is encrypted through the PPTP and GRE modules. The encrypted data is then inserted into the IP datagram once more. In this case the real, globally routable IP address is used. The packet is, then, transmitted over the Internet. On the receiving end, the PPTP server reverses the procedure. It receives the packet from the routing network and sends it across the private network to the destination computer. The PPTP server does this by processing the PPTP packet to obtain the private network computer name or address information in the encapsulated PPP packet. The key point of this is that packets travel through the Internet in the PPTP tunnel - even if a third party computer in the Internet captures the packet, it will not be able to use the data inside it. Now that we have a basic idea of how PPTP works, let's ask ourselves a question: "How does this technology work when we add Proxy Server to the picture?" Let's look at what combinations of Proxy Server and PPTP are possible? Why Can't WSP Clients Use PPTP?Although you can install PPTP client software on a WinSock client computer, there is no way to make the WSP client redirect PPTP packets though the Microsoft Proxy Server services. The main reason for this is found in the WinSock Proxy Client architecture. When a WinSock Proxy client receives a call from an application, it knows the call needs to be forwarded to a specific IP address and to a specific port. However, the WinSock Proxy client software tricks the application by intercepting packets on the TCP layer and sending them to the Proxy Server's WinSock Proxy service. Looking at PPTP encapsulation once more, we see the data has to cross the TCP layer twice. Since the WinSock Proxy Client software intercepts the packet on the first pass, this data passes the TCP layer only once. There is a workaround for this issue. If you want a PPTP client or PPTP server to reside in you internal network, you should enable IP forwarding on the Proxy Server computer to let packets reach your internal PPTP client or server. Of course this will also create a significant security problem, since now your internal network is visible from the Internet. You can increase security by enabling packet filters. Microsoft Proxy Server contains predefined packet filters "PPTP call" and "PPTP receive." They should be added to the configuration in order to permit outbound and inbound PPTP connections, respectively. Since your PPTP enabled computer is on the internal network, you should create a static filter that allows packets to travel to your PPTP enabled computer (see Figure 9.2). Here, a packet filter for the internal PPTP server is created. The PPTP server is located in the internal network and has an IP address of 195.209.225.15. Note that this IP address should be routable from the Internet. In other words, you cannot use an IP address from the private address space (internal network) here. Figure 9.2: Creating a PPTP filter for an internal host. There is a limitation in MS Proxy filtering, however. If you try to set up a custom filter for any computer on your internal network, you will get the message shown in Figure 9.3. This happens when you create a packet filter for an internal IP address (one that is in the LAT). To solve this problem, you will have to exclude the IP address of that computer from LAT. When you put a PPTP client or server on the internal network, you must keep in mind that, if IP routing on this computer is enabled, packets from the external network can reach other computers in your internal network. This of course makes the foregoing solution less desirable. Figure 9.3: Invalid local host message. Running PPTP on the ServerIt is more desirable to run PPTP server on the Proxy Server. To do this, you should install Routing and Remote Access Server (RRAS) on the Proxy Server computer. If, however, you install the software in the incorrect order, some services may not start or may fail to function properly. Let's review the recommended installation sequence. To install RRAS server and Proxy Server on one computer, do the following:
After all the software is installed, you should check that IP forwarding is disabled in the TCP/IP properties dialog box. If IP forwarding is enabled, your internal network is accessible from the Internet, which could be a serious security problem. Additionally, you should enable packet filtering and create static packet filters for "PPTP Call" if your computer acts as a PPTP client; and "PPTP Receive" if your computer is a PPTP Server (see Figure 9.4). There are a couple of other alternative solutions to integrate Microsoft Proxy Server 2.0 and RRAS. These solutions utilize RRAS packet filtering capabilities instead of Proxy Server packet filtering. RRAS packet filtering is beyond the scope of this book. You can find more information regarding this by referring to the RRAS documentation and Microsoft Knowledge Base article 169548 Using Proxy Server with Routing and Remote Access. http://support.microsoft.com/default.aspx?scid=KB;en-us;169548&sd=tech Figure 9.4: PPTP packet filters. Study Break Testing the Deployment of Proxy Server and the PPTP-Enabled RAS Server
To configure the Proxy Server computer to pass PPTP requests:
Proxy Server and Exchange ServerIt is impossible today to think of an organization that is connected to the Internet but has no e-mail connectivity. E-mail is still the most commonly used service on the Internet. Many software vendors have developed e-mail server software that allows you to send and receive e-mail messages from the Internet. Microsoft Exchange Server is one of the tools that offers e-mail functionality in addition to other powerful features such as scheduling, storage services, and corporate document flow. The reasonable question at this point is: "How does Exchange Server operate in a Proxy Server environment and what are the configuration steps to make it work?" This question becomes rather difficult when you consider that Exchange Server integrates several different messaging protocols (for example, SMTP, POP3, IMAP4, LDAP, and NNTP). There are three methods that can be used to allow Exchange Server to coexist with Proxy Server:
Each solution requires not only installation of the corresponding software products, but also a sophisticated configuration or IP addressing scheme, DNS records, IP routing, and packet filtering. Installing Exchange Server on the Internal NetworkIf you decide to install an Exchange computer on the internal network behind the Proxy Server you must use server proxying. Server proxying gives you the ability to listen for the inbound packets destined for a computer located on the internal network (behind the Proxy Server computer). Proxy Server forwards all incoming requests to the internal computer (see Figure 9.5). In this scenario, the Internet hosts think that Exchange Server is running on the same computer as the Proxy Server computer while, in fact, Proxy Server listens for connections on behalf of the internal server. The Exchange Server computer does not have to have an IP address visible from the Internet - it is treated like a normal WinSock client. In order to make the Exchange Server work behind Proxy Server, you need to perform the following steps:
Putting Exchange Server on the Proxy Server ComputerYou can install Exchange Server on the Proxy Server computer. In this case, Exchange Server is able to serve all client requests from both the internal and external networks. However, if Proxy Server packet filtering is enabled, all communications with Internet mail clients and servers are blocked. In the previous scenario, we solved the packet filtering issue by enabling the dynamic packet filtering on the Proxy Server computer. Dynamic packet filtering, however, allows WinSock Proxy clients to connect to the Internet when the requests are going through the Proxy Server service software. If you install Exchange Server on the Proxy Server computer, Proxy Server services are not involved when attempting to communicate with the Internet and dynamic packet filtering will not work. To prevent Exchange Server communications from being blocked by Proxy Server, static filters must be configured and enabled. Exchange Server running on the Proxy Server computer requires two types of static filters: static filters for the client side (so Exchange Server can connect to other mail servers in the Internet) and static filters for the server side (so Internet servers are able to connect to Exchange Server). You need to create static packet filtering for outbound SMTP, POP3, and INETD access. You can do this by choosing the corresponding predefined static filters in the Packet Filter Properties dialog box. You also need to create custom static packet filters for inbound access for SMTP, POP3, and LDAP using the description shown in Table 9.1. Table 9.1 Static Filters For Use With Microsoft Exchange Server
Study Break Adding Predefined Packet Filters To add predefined packet filters for Exchange-to-Internet-host communication:
To add predefined packet filters for Internet-host-to-Exchange communication:
In addition to creating the static packet filters, you may want to change the MX record in DNS point to the Proxy Server external interface. Exchange Server in Front of or in Parallel with the Proxy Server Another option of integrating Exchange Server with Proxy Server is to put Exchange Server outside the local LAN (on the external network). In this case, no specific configuration to the Exchange Server or to Proxy Server is required. You can also install Exchange Server in parallel with the Proxy Server and disable IP forwarding on the Exchange Server computer to prevent it from routing packets between the internal and external LAN. (When we say "in parallel," we mean the Exchange Server will have a network adapter that connects to the external network as well as one that connects to the internal network.) This could potentially decrease the load on Proxy Server since local clients are not required to pass it to reach the Exchange Server. You should remember that, when the Exchange Server is installed in front of or in parallel with the Proxy Server, the Exchange Server does not benefit from any of the network protection afforded by Proxy Server. Microsoft SQL Server and Proxy ServerIf you want Microsoft SQL Server to coexist with Proxy server and respond to external requests, you again have different methods. The first and easiest is to install SQL on the same computer where Proxy Server resides. Another method is to set up SQL Server as a WinSock Proxy client and put it on the internal network. In order to make SQL Server visible from the external network, you need to configure SQL Server to use TCP/IP sockets in its SQL Net Library. Proxy Server must use IP Address under the WinSock Proxy client configuration (as we did with the Exchange Server). You must install WinSock Proxy Client software on the SQL Server computer and add the SQL Server computeršs IP address to the Proxy Server's Local Address Table if it is not already there. If Packet Filtering is enabled on the Proxy Server, Dynamic Packet Filtering of Microsoft Proxy Server packets should also be selected. The next step is to create the WSPCFG.INI file on the computer running SQL Server. The file should look like the following: [sqlservr] ServerBindTCPPorts=1433 Persistent=1 KillOldSession=1 Place the WSPCFG.INI file in the same folder as the Sqlservr.exe file. By default this is the C:\Mssql\Binn folder. The last step is to restart SQL Server computer. After you complete the preceding steps, your SQL Server should be accessible to external SQL clients using TCP/IP (clients must be configured to use TCP/IP as their default network library ‹ this is accomplished with the SQL Server Client Network Utility that is installed with SQL Server). You must point SQL clients to the Proxy Serveršs external interface instead of the SQL Server. Other Internet Services Behind Proxy ServerFTP Server Behind Proxy ServerIf you have an FTP server you can place it behind Proxy Server as well. Before we begin our configuration discussion, let's take a brief look at how FTP works. FTP uses two separate TCP connections to communicate between the client and server: a control connection and a data transfer connection. The control connection starts the communication between the FTP client and the FTP server; it is maintained for the duration of the FTP session. The control connection uses port 21 on the server and an open port that is greater than 1023 on the client. The data connection (server port 20) exists only when there is data to be transferred between the client and the server. The data transfer connection closes each time a data transfer is completed. The control connection remains open. You can configure an FTP service to work with Proxy Server to handle incoming Internet client requests. For the FTP service that is provided with Microsoft Internet Information Server 3.0, for example, you should create a Wspcfg.ini file with the settings below and place it in the directory that contains the inetinfo.exe file. Note that you should place the WSPCFG.INI file on the FTP server computer, not on the Proxy Server computer. [INETINFO] ServerBindTcpPorts=21 LocalBindTcpPorts=20 Persistent=1 KillOldSession=1 ForceCredentials=1 The ForceCredentials line is used to specify the user under whom the FTP service interacts with Proxy Server. You should use the Credtool utility found on your client machine in the \MSPCLNT directory to specify the user credentials. Credentials should be specified for the account that is used for inetinfo, which is the ftp service executable. The proper syntax is: credtool.exe w n inetinfo c username domain password where:
In addition, if packet filtering is enabled, you must create a static packet filter definition on the Proxy Server computer providing the WinSock Proxy service, with the parameters from Table 9.2. Table 9.2 Static Filters For Use With FTP
Finally, in order for Internet users to be able to access your internal FTP by Fully Qualified Domain Name (FQDN), you will have to create an A or CNAME record for your FTP server which points to the proxy serveršs external address. Non-Windows Servers Behind the Proxy ServerNon-Windows servers cannot use the WinSock Proxy client and therefore cannot benefit from Proxy Server's reverse hosting and server proxying. The only exceptions to this rule are HTTP servers that can use Proxy Server's Web publishing features and other services that are simply relayed by the third party software installed on the Proxy Server computer (for example, SMTP). In this case, it is reasonable to ask "How can non-windows servers coexist with Proxy Server?" One of the most popular solutions to this problem is the creation of a so-called demilitarized zone (DMZ). This approach provides a secure way for a non-Windows server to publish to the Internet and, at the same time, be available for internal clients. The basic idea of the DMZ is to create a third zone in your network that will be accessible to both local and Internet users (see Figure 9.7). Technically, the DMZ is part of your local area network, but it has valid globally routable Internet addresses. The address space of the DMZ is excluded from the LAT and DMZ is essentially outside your network. The DMZ is routable from the Internet though Proxy Server and can be protected by Proxy Server filtering capabilities. Since servers in the DMZ are not necessarily WinSock-complaint, dynamic packet filters will not work. You must create static filters to allow Internet access to those servers. Note that the routing tables are set so that the DMZ servers can speak to computers in the internal network and vice-versa. Communications from the internal network to the Internet and from the Internet to the internal network must go through the Proxy Server services since the local network is assigned IP addresses that are not directly visible from the Internet. To implement a demilitarized zone:
Figure 9.7: Demilitarized zone. Enabling Packet Filtering makes this configuration more secure. Unfortunately, the non-Windows servers in the DMZ do not benefit from dynamic filtering so you will have to create static filters for each of the ports you would like to open for each server. If, for example, you have a Unix-based telnet server in the DMZ at IP address 209.13.15.1, you would need to create the following static filter:
You can, of course, change these settings to limit access to specific machines or change the port for different services. SummaryIn this chapter we discussed how Microsoft Proxy Server could coexist with other applications in the network. We mentioned that Proxy Server allows you to implement Point-to-Point Tunneling Protocol to provide secure access to your network from the Internet. We discussed different varieties of PPTP and Proxy Server coexistence. You can install a PPTP server or client on the internal network, but you have to enable IP forwarding and ensure that your PPTP-enabled computer is visible from the Internet. The reason for this unsecured solution is that PPTP requests cannot be redirected by the WinSock client software and therefore cannot take advantage of Proxy server proxying. In this scenario, you may want to increase security by implementing Proxy packet filtering. Another option is to install PPTP software along with the RRAS software on the Proxy Server computer. This provides a more secure solution for your network. We also discussed how an Exchange Server could coexist with Proxy Server. We saw there were several ways to accomplish this. If you install Exchange Server in your internal network, you can take advantage of the WinSock Proxy service server hosting. The key point in this scenario is the creation of wspclnt.ini files. These files are placed in the directories that contain the Exchange Server executable files. They redirect WinSock requests and remote them to Proxy Server. Don't forget that you need to modify your DNS settings to direct Internet clients to the Proxy Server external interface. In this case, Proxy Server acts on behalf of Exchange Server. In this scenario you can also take advantage of dynamic packet filtering. Alternatively, you may want to consider installing Exchange Server on the Proxy Server computer itself, or install Exchange Server in parallel with the Proxy Server computer. These solutions will also work, but they don't provide the attendant security advantages of putting the Exchange Server behind Proxy Server. We also looked at how other applications and services can be used in conjunction with Proxy Server. You saw, for example, that SQL server and FTP server can be put behind Proxy without losing their functionality. Finally, we provided you with guidelines to allow non-Windows servers to coexist with Proxy Server by introducing the concept of a "demilitarized zone." About the AuthorsKOSTYA RYVKIN, DAVE HOUDE, and TIM HOFFMAN, all MCSEs and MCTs (Microsoft Certified Trainers), are training specialists and consultants with Alida Connection, a Microsoft Certified Solutions Provider based in Nashua, NH. We at Microsoft Corporation hope that the information in this work is valuable to you. Your use of the information contained in this work, however, is at your sole risk. All information in this work is provided "as -is", without any warranty, whether express or implied, of its accuracy, completeness, fitness for a particular purpose, title or non-infringement, and none of the third-party products or information mentioned in the work are authored, recommended, supported or guaranteed by Microsoft Corporation. Microsoft Corporation shall not be liable for any damages you may sustain by using this information, whether direct, indirect, special, incidental or consequential, even if it has been advised of the possibility of such damages. All prices for products mentioned in this document are subject to change without notice. |