Since Microsoft Proxy Server is actually two separate servers, it's important that you understand what it takes for clients to connect to each server. A client application is any Internet application, such as an FTP client like WS_FTP, a web browser such as Netscape, or Internet Explorer, or a newsgroup reader such as WINVN. These clients would normally use a direct Internet connection obtained through such connectors as the Win95 Network Dialer, or Trumpet WinSock in the case of Windows for Workgroups environments. Obviously when in a proxy environment, these clients will connect to Microsoft Proxy Server and Microsoft Proxy Server will in turn connect to the outside world for these clients. This chapter covers how to correctly configure clients to talk to Microsoft Proxy Server.
The majority of this chapter deals with the Windows 95 environment, although Microsoft Proxy Server can be accessed by other environments such as Windows for Workgroups, UNIX, or even Macintosh systems. From a users standpoint, Windows NT 4.0 workstation is nearly identical to Windows 95. Any client that adheres to CERN-compliant proxy standards, no matter what platform they run on, can access the Web Proxy side of Microsoft Proxy Server over a TCP/IP network. The WinSock Proxy server side of Microsoft Proxy Server does require special client software to be installed on each workstation before clients requiring WinSock Proxy access will function correctly.
As with many configuration elements, Web Proxy configuration is globally handled by Windows 95. True Windows 95 applications will draw from global settings set within Control Panel for their own operation. For example, true Windows 95 communication programs, such as Qmodem Pro for Windows 95, will use the internal telephony settings set within Control Panel for its own configuration. Qmodem Pro will use modem configuration, dialing configuration, and port configuration information set by Windows 95 for its own operation. True Windows 95 Internet clients will likewise draw from Internet settings set through Control Panel for their settings.
The Internet icon in Control Panel is the gateway to configuring most internal Windows 95 Internet settings. Don't have the Internet icon in your Control Panel, you say? Well, you won't unless you have installed some version of Internet Explorer. Installing Internet Explorer 3.0 will add the Internet control applet to the system. Internet Explorer is Microsoft's core Internet application, and any updates to the Windows 95 Internet control applet will be released with new versions of Internet Explorer. Even if you choose to use another browser such as Netscape as your default browser, you should always obtain the latest version of Internet Explorer to ensure that you have the most recent core Internet features available to Windows 95.
Other applications that do not get any of their Internet configuration from the internal settings of Windows 95 will have to be configured separately. This chapter covers how to set up Netscape Navigator for Web Proxy communication.
Once Internet Explorer has been installed into a Windows 95 or Windows for Workgroups system, the Internet icon will be available in the Control Panel. Settings made through this control applet will be held in the Windows 95 registry and can be manually edited if you happen to be any good at dealing with the registry (ah, for the bygone days of text based INI files. . . ). This section will detail how to correctly configure the internal Internet setting of Windows 95 through the Internet control applet. Figure 11.1 shows this applet:
This chapter will not detail all the settings that can be configured through the Internet control applet, just the ones that deal with setting up Web Proxy communication. Many of the settings in this control applet are designed specifically for Internet Explorer, and others are used by different Internet applications, such as Microsoft's E-mail and Newsgroup clients. The Connection tab will be covered here.
Keep in mind that configuring these Web Proxy settings only affects those applications that can communicate via a CERN-compliant proxy. This is a specialized form of communication and must be a built in feature of each Internet client application you use to be of any value. Figure 11.2 shows the Connection tab of the Internet control applet.
The Connection tab controls how clients will gain access to the Internet. On this tab is the Connect to the Internet as needed check box. This is also known as AutoDial, and when checked, and an existing Network Dialing entry is indicated, Windows 95 will automatically initiate a dial out to the indicated provider whenever an Internet client attempts to contact a server that is not within the local TCP/IP subnet. When a workstation will be connecting to the Internet through a proxy, this check box should not be checked. If it is, Windows 95 will always prompt the user with the Dial-Up Networking dialog box whenever a client attempts to contact an outside server. This happens even when the workstation is configured to connect through a proxy. Kinda strange, I know. You'd think the proxy configuration would take precedence over the demand dial, but that's not the case.
When the Connect through a proxy server check box is checked, the Settings button will become available. This is the check box that enables Web Proxy communication. If you have installed the WinSock Proxy client software, this may have automatically been checked and correctly configured. This will be covered shortly.
Clicking the Settings button will produce the dialog box shown in Figure 11.3.
This is the most important configuration dialog box for controlling Web Proxy communication. As you can see in Figure 11.3, a Web Proxy server at 220.200.200.1 is indicated and all protocols are set to communicate with the same proxy server through port 80.
The address of available Web Proxy servers can be indicated either by Internet name such as mydomain.com or by direct IP address such as 220.200.200.1. There are benefits and drawbacks to both forms of addressing.
If a verbose Internet name is used to indicate proxy location, there should be some form of name resolution capability on the internal network. Microsoft NT networks can use WINS, (Windows Internet Name Service), and/or DNS, (Domain Name System, Server, or Service, depending on who you talk to) to resolve names to addresses. When verbose names are used, changing actual locations of proxy servers is simple, as far as reconfiguring client workstations goes. All that needs to be done is to alter the address associated with the proxy server name in either the WINS or DNS database. Workstations will automatically resolve the name to a new address once the name server has been updated.
Using verbose names also allows WINS or DNS servers to automatically cascade client access to a group of proxy servers. The nature of name resolution under WINS or DNS makes it possible to associate a group of servers with a single name, such as proxies.com. When clients access proxies.com as a single entity, the name server will rotate which member of the group has its IP address resolved for the group name. In this manner, a name server can spread out the proxy load evenly among a group of servers. Chapter 9, "Concepts and Realities of Name Resolution with Proxy Server," deals with name resolution issues in greater detail.
A name server is not absolutely required for verbose naming of proxy servers to work correctly. If no internal name resolution server can be found by a workstation, it will rely on an internal configuration file called HOSTS. as a last resort for name to IP pairing. The format of this file is very simple. It is a standard text file found in the \WINDOWS directory. Its format is such that each line of the file indicates a single name to IP pairing. The IP address is indicated first and the name is indicated second. At least one space must separate the two bits of information. A sample of this file can be found in the \WINDOWS directory under the name HOSTS.SAM. Consult this file for more details of using local name resolution.
Local name resolution will add more work than it saves. If proxy locations ever change on a LAN, the network administrator will need to manually edit the HOSTS. file of all workstations requiring notification of new proxy location. Local name resolution will also not provide cascading of a group of proxy servers as an actual name server will.
If proxy location is indicated as an actual IP address, no name resolution needs to be present on the network, but it does mean that each workstation will need to be manually altered if proxy location changes. Using an IP address also ensures consistent performance should the LAN name server go down for any reason.
The Use the same proxy server for all protocols check box allows you to indicate that a single proxy server should be used for all protocols (such as HTTP, FTP, and Gopher). You can leave this check box unchecked and manually indicate different proxy servers for each protocol. It's up to you as network administrator to properly arrange multiple proxy servers in the most efficient manner. Keep in mind that the FTP protocol is the most bandwidth demanding protocol because it normally deals with transferring large files. If you want to ensure that web clients have smooth Internet access, it might be a good idea to set a proxy server to handle all FTP requests, leaving other proxy servers to handle HTTP (web) requests.
The SOCKS protocol is slightly different. A SOCKS host is a network host which controls outside Internet access when clients must pass through a network firewall. Normally, communications with a SOCKS host happens on port 1080.
Under default circumstances, all communication with a proxy server will take place over port 80. Unless you have a server application on a workstation which is also listening to port 80, you should not have to change the port that clients communicate with the proxy server on. If you happen to have an Internet type server application running, such as a personal web server or the like, you will need to make sure there is no port conflict. The Microsoft Proxy Server can be configured to listen to a port other than 80, but this causes more confusion than it solves and must be done through the Windows NT registry. There is no simple way of altering which port the Microsoft Proxy Server proxy listens to. It's far easier to alter any personal servers that might be running on a few workstations on the LAN to listen to another port.
As you can see in Figure 11.3, clients on this workstation will be communicating with the Internet through a single proxy located at 220.200.200.1. Again, the address is meaningless and just happens to be the address I chose for the NT server on my LAN. I would have been better off had I chosen one of the reserved IP subnets that the InterNic has set aside for private TCP/IP LANs. Consult Chapter 6, "Configuring Proxy Server," for more information on which subnets have been set aside for private LAN use.
The bottom part of the proxy settings dialog box allows you to set local exception to proxy use. You can indicate which types of addresses will not be passed to the proxy server. The names can be indicated as IP address or verbose Internet names. Asterisks can be used to set ranges. Some examples are: *.netscape.com, *.netscape.*, www.*, 209.*, 209.176.*, and www.microsoft.com/sitebuilders. Any address matching an indicated value will only be attempted as a local contact and not passed to the proxy server. Separate entries with a semicolon (;).
The last check box, Do not use proxy server for local (intranet) addresses should be checked by default. It controls whether or not clients should go through the proxy server even when attempting to contact an Internet type server on the LAN. When checked, the proxy server will not be contacted for local attempts. When not checked, the proxy server will handle both local and remote contacts. The proxy server can be used to control the flow of intranet traffic well as Internet traffic.
Once all settings have been configured, click OK until you have returned to the Control Panel. Close the Control Panel. Proxy clients which rely on Windows 95 to issue out Internet configuration information should now be able to contact any proxy server(s) on your network.
Netscape can be easily configured to communicate with the Internet over the Microsoft Proxy Server proxy server. This section covers how to set up Netscape 3.0 for proxy communication, although the same principles apply to configuring previous versions of Netscape as well. To start, you should have the latest version of Netscape Navigator installed. Once installed, you should start the Navigator. By default, Netscape Navigator will try to contact home.netscape.com when it starts. If you have the Connect to the Internet as needed check box in the Internet control panel, Dial-Up Networking may start to make the Internet connection for you. Make sure you cancel the connection attempt.
To get to the proxy configuration area of the Netscape options, follow these steps:
There are three main options on the proxies tab of Network Preferences. The definition of each option is as follows:
The Manual Proxy Configuration option should be selected. Once it is selected, you can click the View button on this tab to further configure proxy locations in the same manner you configure the global Windows 95 proxy settings. Figure 11.5 shows the Manual Proxy Configuration dialog box.
You can see in the figure that I am using the verbose name of the NT machine running Microsoft Proxy Server. I use WINS on my internal network and so can use the names of servers and workstations on my network for address configuration.
Just as with the global Windows 95 proxy configuration, all proxies should be set to communicate over port 80 unless there is an important reason to alter this port. If you have multiple proxy servers on your network, you can set each protocol to talk to a different proxy server. In Figure 11.5 you can see that all protocols are set to communicate with the proxy server running on "Controller 4.0". Microsoft Proxy Server does not provide SOCKS protocol proxying at this time. It may in future releases of the software.
You can also configure a list of domains that Netscape should not use the proxy to contact. These are entered in a similar manner to the way exclusions are entered in the global Windows 95 proxy configuration; however, Netscape is slightly more limited. You can only enter full domain names such as www.micrsoft.com to exclude from proxy contact. No wildcards can be used to configure partial domain names as they can in global Windows 95 proxy configuration.
Once you have configured all necessary settings on the proxies tab, click OK and Netscape should now correctly communicate with the Internet through your proxy server.
There has been a nagging bug in the beta version of Microsoft Proxy Server that is supposed to have been fixed for release. This bug is one that causes Netscape to display FTP downloaded files as plain text in the display area. This is caused by Netscape assuming that all information it receives to be an HTTP document. A supposed workaround for this is to hold the shift key down while clicking an FTP file link. This will force Netscape to save the link as a file. This workaround only partially worked for me, saving only the first few bytes of files and then aborting the transfer. I mention it here in case you might have better luck than me with this bug, should it still be present in the release version of Microsoft Proxy Server in some form.
Unlike proxy support, which must be internally supported by clients, the WinSock Proxy server side of Microsoft Proxy Server will allow most standard non-proxy Internet client applications to access the Internet through Microsoft Proxy Server. In order for this to happen though, special WinSock Proxy client software must be installed on workstations before non-proxy Internet clients will be able to see the outside Internet.
It is for this reason that currently, only Windows NT, Windows 95, and Windows for Workgroups environments are supported. This means that network workstations of other operating systems, such as UNIX or Macintosh, will only be able to use the Microsoft Proxy Server Web Proxy for outside communications. Internet clients on these other types of operating systems must support CERN-compliant proxy communication to contact the outside Internet.
When Microsoft Proxy Server is installed, a shared resource is created on the server called MSPCLNT (Microsoft Proxy Client). This shared resource will contain the WinSock Proxy client setup files for all flavors of Windows NT (Alpha, Intel, for example), Windows 95, and Windows for Workgroups. Client workstations can connect to this shared resource and run the SETUP.EXE program and install WinSock Proxy support. Figure 11.6 shows this shared resource in the Network Neighborhood.
The SETUP.EXE found in the root of the MSPCLNT share can be executed for all platforms. The specific operating system will automatically be detected and the correct sub-installation routine started. On the Microsoft Proxy Server machine, the directory for the MSPCLNT share is \MSP\CLIENTS.
Another minor bug I have found in Microsoft Proxy Server that I am not certain has been fixed before final release is a bug dealing with installation. Most Windows 95 installation routines can be executed directly through the Network Neighborhood without the need of actually mapping a drive letter to a particular shared resource. With the Microsoft Proxy Server WinSock Proxy client installation, you might find that the installation routine fails about 50 percent of the time if you run it directly from the Network Neighborhood. I have had near 100 percent installation success from mapping the MSPCLNT to a drive letter then running SETUP.EXE from that drive letter via the Windows 95 Explorer or from a command prompt. If you can't get the WinSock Proxy client installation routine to work through Network Neighborhood, try mapping the MSPCLNT to a drive letter and executing it from that network connection.
When Microsoft Proxy Server is installed, it examines the local network and creates some configuration files that are then used by network workstations. The important files to understand are MSPCLNT.INI and MSPLAT.TXT. If your Microsoft Proxy Server configuration changes slightly, you can manually modify these two files and save yourself from having to run through the Microsoft Proxy Server installation routine just to change a few settings. Making changes to the MSPLAT.INI file can be done manually through the internal LAT editor that is accessed through the configuration interface for the WinSock Proxy.
The MSPCLNT.INI file looks like this:
[Internal] scp=9 Build=1.0.193.3 [RAPLAYER] RemoteBindUdpPorts=6970-7170 [Master Config]Path1=\\CONTROLLER 4.0\mspclnt\ [Servers Ip Addresses] Addr1=220.200.200.1 [Servers Ipx Addresses] Addr1=02020202-00400526bfe8 [Common] Port=1745 Configuration Refresh Time (Hours)=6 Set Browsers to use Proxy=1 Re-check Inaccessible Server Time (Minutes)=10 Inaccessible Servers Give Up Time (Minutes)=2 WebProxyPort=80
WWW-Proxy="CONTROLLER 4.0"
The definition of the important INI lines are as follows:
If your Microsoft Proxy Server configuration changes slightly, you can edit the MSPCLNT.INI file manually and then rerun the WinSock Proxy client installation routine on client workstations to update them. Or, this INI file is also found on local workstations in the \MSPCLNT directory (default directory). The simplest way of making minor changes is to edit the INI file on the server then copy it down to workstations in their \MSPCLNT directory.
The second file that can be manually edited is the MSPLAT.TXT file. This file contains the local address table. The local address table is a table of IP address ranges that indicate which IP addresses are local to the private LAN. The MSPLAT.TXT file looks like this:
10.0.0.0 10.255.255.255 172.16.0.0 172.31.255.255 192.168.0.0 192.168.255.255 220.200.200.0 220.200.200.255 127.0.0.0 127.255.255.255
224.0.0.0 255.255.255.254
Each line of this file indicates a range of IP addresses that can be reached on the local network segment. Any address outside of these ranges will be considered an outside Internet address and when accessed by an Internet client, the request will be remoted to the WinSock Proxy server. If you need to indicate an address of a single machine, use the machine's address as the starting and ending address, as can be seen on the second line of the above example. These address ranges are normally set up automatically when Microsoft Proxy Server is installed and the administrator selects to load the LAT from the internal NT routing table. However, if you need to add a range after installation, simply edit this file and copy it down to client workstations in the \MSPCLNT directory.
Keep in mind that the local WinSock Proxy client software itself determines whether or not an Internet request is a local or remote request. Once it determines that, it will either keep the request local by passing it off to the original WinSock DLL of the system, or remoting the request to the WinSock Proxy server through the control channel port. The MSPLAT.TXT file is periodically updated by the WinSock Proxy client software on the time frame set in the MSPCLNT.INI file via the Configuraion Refresh Time (Hours) element.
If you are using a dedicated Internet connection, the address of the NIC providing this access should be indicated in the MSPLAT.TXT file as a local address.
The following section details the installation process for the WinSock Proxy client software. To begin installation, execute SETUP.EXE found in the root of the MSPCLNT share from either the Network Neighborhood or from a mapped drive letter to that share. After clicking Continue at the license dialog box the first setup dialog box appears. Figure 11.7 shows the initial setup dialog box.
By default, the WinSock Proxy client software will be installed into C:\MSPCLNT. This can be changed by clicking the Change Folder button and then selecting a new target directory. Once you have selected the correct target directory or accepted the default directory, click the Start button to begin the installation.
There are no other steps to the installation. Once the start button has been selected, the WinSock Proxy client will be installed, and the original DLLs will be replaced with the WinSock Proxy DLLs. The system will need to be restarted after the WinSock Proxy client has been installed before WinSock Proxy clients can access the WinSock Proxy server.
As already mentioned, the WinSock Proxy client software draws configuration information from data files stored in the \MSPCLNT directory on each workstation. These files can be manually edited if Microsoft Proxy Server's location changes, or the network is expanded to include a wider range of addresses. The easiest way to reconfigure the WinSock Proxy client for novice users is for the network administrator to simply make the appropriate changes to the WinSock Proxy server (by reinstalling it or using the internal LAT editor) and then users can reinstall their client from the MSPCLNT share on the server. Figure 11.8 shows the setup dialog box when the WinSock Proxy installation is rerun on a system with the WinSock Proxy client already installed.
The first two selections, Add/Remove and Reinstall, are nearly identical. I have no idea why Microsoft has chosen to have two options that do the same thing. The only difference is that Add/Remove will allow you to rerun the installation and choose a different target directory and Reinstall will rerun the installation using the existing target directory.
The Remove All button will remove the WinSock Proxy client completely from they system. Keep in mind that proxy configuration is separate from the WinSock Proxy client, and removing the WinSock Proxy client in no way affects the settings for proxy communication. Once the WinSock Proxy client has been removed, the system has to be restarted.
In order for the WinSock Proxy client software to do its magic, it must supersede the internal WinSock DLLs of an operating system. When the WinSock Proxy client is installed, the existing Winsock.dll (for 16-bit clients) and Wsock32.dll (for 32-bit clients) files are renamed and the WinSock Proxy client DLLs are copied over in their place. In this manner, the WinSock Proxy client will always receive any Internet type requests. If the request is for a machine that can be found on the local network, the replacement WinSock Proxy WinSocks will simply forward the request to the original WinSock DLLs for normal handling. If the request is found to be a remote request, the WinSock Proxy WinSocks will contact the WinSock Proxy server through the control channel port, and a socket will be established between WinSock Proxy client and WinSock Proxy server as though the Internet client were talking to the actual Internet target server directly.
In original configurations, the winsock.dll file is found in the \WINDOWS directory and the wsock32.dll file is found in the \WINDOWS\SYSTEM directory. When the WinSock Proxy client software is installed, the original winsock.dll is renamed _msrws16.dll and the original wsock32.dll file is renamed _msrws32.dll. The directory locations stay the same. You can manually uninstall the WinSock Proxy client by deleting the replacement DLLs and renaming the original DLLs back to their original names. Be very careful not to delete the original DLLs.
One of the major drawbacks to the WinSock Proxy client software is that it is difficult to deactivate for short periods of time if you want to access the Internet directly from a dialup connection from a local workstation. If the WinSock Proxy client can contact the WinSock Proxy server, it will always use that connection over a locally established connection. There are some Internet clients that simply do not take kindly to having their packets forwarded so they have to have a locally-established connection. The work around for this is to do a little copying of DLL files back and forth when needed. Unfortunately, the winsock.dll and wsock32.dll files will be locked open if they have been used and cannot be overwritten, so you will need to boot to DOS in order to copy over them.
If the WinSock Proxy client software cannot connect to the WinSock Proxy server, it will allow a local Internet connection to function normally, but there will be a nagging delay between request and contact. The WinSock Proxy client will always try to contact the WinSock Proxy server on all Internet requests so the delay in response may be too annoying to accept.
Microsoft seems to be vacillating back and forth on what programs store configuration data in the registry and which still use the old-fashioned INI files. The WinSock Proxy client relies exclusively on INI files to store configuration data. As already mentioned, the MSPCLNT.INI file found in the \MSPCLNT directory is the primary configuration file, but some WinSock Proxy settings are held in the SYSTEM.INI file found in the \WINDOWS directory. The following entries are added to the SYSTEM.INI file upon WinSock Proxy client installation.
[Microsoft Proxy Service] Ini File Path=C:\mspclnt\mspclnt.ini Configuration Location=C:\mspclnt\ Security32=secur32.dll Security16=security.dll Disable=0
The Ini File Path entry indicates where the WinSock Proxy client can find MSPCLNT.INI. The Configuration Location entry indicates where the WinSock Proxy client can find the MSPLAT.TXT file for determining which requests are to be kept local and which requests are to be forwarded to the WinSock Proxy server. The Security16 and Security32 entries point to the security DLL files the WinSock Proxy client should call on when attempting to get authorization from the WinSock Proxy server for a user to access a given protocol. The WinSock Proxy server can be configured to limit access to any protocol based on standard NT username and password. Without the security DLL files, the WinSock Proxy client will be denied access to the WinSock Proxy server.
An additional INI directive can be added. This directive is:
Disabled=1
When present, this is supposed to turn off the WinSock Proxy client and return the TCP/IP operation of the system to normal. The system will have to be restarted before the changes will take affect.
After the WinSock Proxy client software is installed, a new control applet will be present in the Control Panel of all Windows systems (WFWG, Win95, and Winnt Workstation 3.51/4.0). This control applet is called WSP Client and can be used to quickly turn on and off the WinSock Proxy client software redirector. Figure 11.9 shows this control applet.
To enable or disable the WinSock Proxy client, simply check or uncheck the Enable WinSock Proxy Client check box. The system will need to be restarted after the client software status has been changed.
The WinSock Proxy server which the workstation communicates with can be quickly changed as well by indicating a difference machine named in the Configuration Location field. The machine name listed here must be a NetBios machine name and not a DNS host name. Once a new machine has been indicated, the Update Now button will force the workstation to contact the new WinSock Proxy server and download a fresh set of configuration files from it. The workstation should not need to be restarted after changing the WinSock Proxy server that it communicates with but its always a good idea to restart after any significant configuration change has been made.
Installing the WinSock Proxy client under Windows 3.11 (and Workgroups) is done in a similar fashion to setting up the WinSock Proxy client under Windows 95. The same SETUP.EXE can be run from the MSPCLNT share on the server, and the installed file arrangement is the same. Once the appropriate files have been installed, the installation routine will present the dialog box shown in Figure 11.10.
At this stage, you can indicate the name of the group to add to the system for the Microsoft Proxy Server client. The installation routine only adds one file, SETUP1.EXE to this group. If you prefer, you can simply add this entry to the MAIN group or to the Accessories group.
You do not need to have TCP/IP for Windows 3.11 installed in order for the WinSock Proxy client to work. The WinSock Proxy client can operate over an IPX connection on Windows 3.11 workstations with some limited functionality. For complete functionality, you should obtain TCP/IP for Windows 3.11. Support for the TCP/IP protocol under Windows 3.11 can be downloaded from ftp.microsoft.com in the \softlib\mslfiles directory as TCP32B.EXE. At present, this archive contains the latest TCP/IP support files for Windows 3.11.
Reinstallation of the WinSock Proxy client is similar to reinstalling the client under Windows 95, except the Add/Remove option is not available. Figure 11.11 shows the setup dialog box when running SETUP.EXE from the MSPCLNT share when the WinSock Proxy client is already installed.
The Reinstall option will reinstall the client in the default, directly using the settings found from the server. The Remove All option will remove the WinSock Proxy client from the system. The system will need to be rebooted after the client is removed.
Unlike proxy settings in Windows 95, Windows 3.11 does not have a global control panel for controlling proxy communication. Each individual client (such as Netscape Navigator, and Internet Explorer 2.0) will need to be configured independently for proxy communication.
Very little if any extra configuration should need to be done to Internet clients that will use the WinSock Proxy server. These applications will operate without any problems. They will assume they are talking directly to a server on the Internet, when in reality they are talking to the WinSock Proxy server that is talking to the target Internet server for them. The WinSock Proxy server will simulate the operation of the remote server in every way, and the client application will never know the difference.
The only exception to this comes with FTP clients. Normally, FTP clients send out requests over port 21 and receive information back from a target server over port 23. In order to operate correctly with the WinSock Proxy server, FTP clients must be able to do something called PASV Mode, which is sometimes called Passive Transfers. PASV mode is an alteration to normal FTP communication where the client tells the server which port to respond back on. This allows FTP clients to correctly communicate over such things as firewalls. A firewall is designed to prevent unauthorized inbound connections over known ports, such as FTP port 23. By having the client tell a remote server which port to respond on, the firewall will allow the return connection. The following is a short connection log made by WS_FTP32, a very popular FTP client. This log shows how PASV mode is established.
WINSOCK.DLL: Microsoft Windows Sockets Version 1.1. WS_FTP32 951229, Copyright _ 1994-1995 John A. Junod. All rights reserved. - - connecting to 205.199.96.2 ... Connected to 205.199.96.2 port 21 220 slc.axxis.com FTP server (Version wu-2.4(4) Fri Mar 10 12:53:25 MST 1995) ready. USER anonymous 331 Guest login ok, send your complete e-mail address as password. PASS xxxxxx 230 Guest login ok, access restrictions apply. PWD 257 "/" is current directory. SYST 215 UNIX Type: L8 Version: BSD-199306 Host type (2): UNIX (standard) PASV 227 Entering Passive Mode (205,199,96,2,8,164) connecting to 205.199.96.2:2212 - - connecting to 205.199.96.2 ... Connected to 205.199.96.2 port 2212 LIST 150 Opening ASCII mode data connection for /bin/ls. Received 375 bytes in 0.5 secs, (8241.76 bps), transfer succeeded
226 Transfer complete.
You can see that once the client has logged in to the server, it sends the PASV command to the server. The server then lets the client indicate which port further communication should take place over, in this case, port 2212. Once the handshake is complete, the FTP client and FTP server begin normal operation.
Without enabling PASV mode, FTP clients can still connect to FTP servers, but full data transfers will abort with odd errors as the WinSock Proxy server steps over the data flowing back from the FTP server.
Enabling PASV mode is a simple task with WS_FTP32. This is done by altering the Advanced Settings for any given Session Profile. Figure 11.12 shows an average WS_FTP32 session profile with the advanced settings opened.
Sessions under WS_FTP32 can be set up normally, as though the workstation would be directly connected to the Internet. The only difference is that the Passive transfers check box must be checked. Make sure you don't alter the default outbound port (Remote Port setting). If this is changed, the WinSock Proxy server will not correctly see the connection attempt and/or deny access permission based on the security settings for another protocol.
All other major Internet applications, such as SMTP and POP3 (e-mail) clients, and NNTP (newsgroup readers) clients should not need any extra configuration. Simply configure them as though the workstation would be directly connected to the Internet, and they will operate as normal through the WinSock Proxy server.
Web browsers such as Netscape Navigator and Internet Explorer can use the WinSock Proxy server also. They are not confined to using the Web Proxy server for their access. The major benefit in letting web browsers use the proxy server over the WinSock Proxy server is that the proxy server provides caching features that help increase performance. The WinSock Proxy server provides no caching services for any protocol it supports.
In order to force a web browser to use the WinSock Proxy server, simply turn off proxy communication support for the browser. The WinSock Proxy client will then receive the browser's traffic and handle it accordingly. The WinSock Proxy server comes preconfigured to handle HTTP requests over port 80.
Wait a minute though, if the proxy server listens to port 80 requests, and the WinSock Proxy server also listens to port 80 requests, how does Microsoft Proxy Server determine which server is being called upon? It's a simple enough answer. When a proxy client attempts to contact the proxy server, it does so by directing its request specifically to the IP address of the proxy server over port 80. In this request is a standardized data format containing information on which Internet server the proxy server is supposed to contact and exactly what the proxy server is supposed to retrieve. When a non-proxy browser requests data over port 80, it is doing so by directing the request to an IP beyond the WinSock Proxy server. The data format of such a request is different than the data format used under proxy communications. This is how the two servers maintain separate operation while still listening to the same port.
Setting up proxy and WinSock Proxy clients is a relatively simple process, once you understand the principles of what's going on. The flexibility Microsoft Proxy Server offers to small and medium businesses is amazing. Until now, Windows users had very few options when it came to accessing the Internet. They either had to have a local dial out connection, or have a permanent connection to their machine. Some smaller companies have produced applications which provide similar functionality to Microsoft Proxy Server, but at a poorer performance and with a lesser degree of flexibility. Microsoft Proxy Server allows network administrators to set up client workstations in about five minutes with very little configuration needed for individual applications.