Novell's Border Services
Articles and Tips:
01 May 1997
Because customers expect to find a company's uniform resource locator(URL) next to its telephone number, most companies are connecting theircorporate network or intranet to the Internet, despite some well-justifiedconcerns about doing so. These concerns stem from the fundamentally disparatenature of networks and intranets versus the Internet. Whereas networks andintranets are secure, manageable, and reliable, the Internet is insecure,unmanageable, and unreliable. These incongruities can cause problems, particularlyin the areas of security, management, and performance, at theborder--thepoint at which a network or an intranet meets the Internet.
Most border solutions address only one of these problems. For example,firewalls alleviate security concerns without improving the performanceof a company's Internet connection. Similarly, high-speed routers addressperformance issues but do little to alleviate security concerns, offeringpacket-filtering capabilities that are difficult to configure and, if configured incorrectly, could leave your network or intranet more vulnerable than ever.Worse yet, because each border solution has its own management utility,managing the border can be tedious and time-consuming. In short, to meetyour needs at the border, you have to purchase, install, and manage a numberof separate products.
Until now, that is: Now you can meet all of your needs at the borderwith just one product: Novell's border services.
Novell's border services (which had not been officially named when thisarticle went to press) is one product that offers the capabilities of severalproducts. Novell's border services consists of an integrated set of NetWareLoadable Modules (NLMs) that address security, performance, and connectivityproblems at the border.
Because Novell's border services is fully integrated with Novell DirectoryServices (NDS), you can manage all of these capabilities with one utility:Novell's border services includes a snap-in module for the NetWare Administrator(NWADMIN) utility, the GUI utility used to manage IntranetWare and NetWare4.1x.
With this snap-in module, you can use the NWADMIN utility to configurerules that allow your border server to screen traffic between your networkor intranet and the Internet based on source and destination IP addresses,source and destination port numbers, URL, and time of day. You can alsouse the NWADMIN utility to view access control logs, to configure a hierarchicalcaching system that increases the speed at which users access World-WideWeb (WWW) files, and to create a virtual private network (VPN). In short,to solve the many problems associated with the border, you need to purchase,install, and manage only one product--Novell's border services.
SECURITY PATROL AT THE BORDER
When companies decide to connect their network or intranet to the Internet,their most pressing concern is usually security. How can you protect yournetwork or intranet from the Internet, which is inherently insecure? Themost common solution is to funnel traffic that passes over the border througha single point and to screen traffic at that point by filtering packetsand monitoring protocol handshaking from the network layer to the applicationlayer of the Open Systems Interconnection (OSI) model. The higher the OSIlayer at which a screening system filters packets, the higher the levelof protection the system provides.
Novell's border services offers a single point through which to funneltraffic at the border. This product also screens packets from the networklayer of the OSI model (for all incoming and outgoing packets, regardlessof the protocol used) to the application layer (for outgoing HyperText TransportProtocol, or HTTP, packets only). Specifically, Novell's border servicesincludes the following components to screen traffic traveling to and fromthe Internet:
NetWare MultiProtocol Router (MPR), which screens all incoming and outgoing packets and operates at the network layer of the OSI model
Circuit-level gateways for IP and IPX, which screen outgoing packets and operate at the session layer of the OSI model
HTTP proxy, which screens outgoing HTTP packets and operates at the application layer of the OSI model
NETWARE MPR
As a software-based router with packet-filtering capabilities, NetWareMPR is the first line of defense for your network or intranet. Using theFILTCFG NLM, a DOS command-line utility, you can configure NetWare MPR toscreen incoming and outgoing packets based on the following:
The packet's source and destination IP addresses
The packet's source and destination port numbers
Protocol
NetWare MPR extracts this information from each packet's TCP/IP headerand determines whether to accept or deny that packet based on the screeningrules you have configured.
Although you can configure NetWare MPR to screen traffic up through theapplication layer of the OSI model, the higher the level at which NetWareMPR screens traffic, the more complex the screening rules must be. The morecomplex the screening rules, the more difficult NetWare MPR is to configure.
Fortunately, Novell's border services includes circuit-level gatewaysand an HTTP proxy, which can screen traffic at the higher OSI layers. Youcan use the familiar NWADMIN utility to configure screening rules for theseborder services components.
CIRCUIT-LEVEL GATEWAYS
If you configure the WWW browsers on your clients to access your borderserver, you can then configure screening rules to control users' accessto the Internet through the IP/IP or IPX/IP gateway. (For information aboutconfiguring a browser to access your border server, see "ConfiguringWorld-Wide Web Browsers.")
The IPX/IP gateway provides protocol translation for IPX clients, whichenables them to access the Internet (and TCP/IP intranet servers) withoutrunning TCP/IP. To use the IPX/IP gateway, IPX clients must run the enhancedborder services WINSOCK.DLL file.
In addition to performing protocol translation, the IPX/IP gateway establishesa connection to the Internet on behalf of the client, ensuring that thereis no direct contact between the Internet host and the client. The IP/IPgateway performs a similar service for IP clients. Because the gateways--notthe client--establish the connection to the Internet, all packets that passthrough the gateways appear to have originated from the gateways ratherthan from the clients, shielding your network or intranet clients from untrustedhosts. (Novell's border services also includes components that translateIP addresses. For information about these components, see "Hide!")
Although hiding clients' IP addresses is a valuable service, it is notthe primary service performed by the gateways: Their primary service isto allow you to control users' access to TCP/IP hosts on an intranet orthe Internet.
The IP/IP and IPX/IP gateways accept a client's request to establisha connection to an intranet or Internet host, determine if the client isauthorized to make the requested connection, and (if the client is authorized)establish that connection. These gateways establish or refuse to establisha connection based on the information you configure in the NWADMIN utility. (See Figure 1.)
Figure 1: You use the Rule Definition screen in the NWADMIN utility to create outgoing rules for the circuit-level gateways and the HTTP proxy.
To configure outgoing rules for the gateways (and the HTTP proxy), youwould complete the following steps:
Launch the NWADMIN utility, and double-click the Border Server object in the NDS tree.
On the Setup screen, click the Outgoing Rules button.
The Outgoing Rules screen displays a list of rules you have already configured. To add a rule, click the Add icon on the left-hand side of the Rules box.
On the Rule Definition screen, you can create a rule by completing all or some of the fields. (See Figure 1.)
Configuring Access Control Rules
In contrast to configuring rules for packet-filtering routers, configuringrules for Novell's circuit-level gateways is relatively simple. For example,suppose that you wanted to configure a rule to ensure that none of the usersin the Everyone group could access FTP sites from 9 a.m. to 5 p.m. Mondaythrough Friday. To make this rule, you would access the Rule Definitionscreen in the NWADMIN utility and click the Deny option in the Action field.(See Figure 1.)
Next, you would select the Specified option in the Source box and clickthe". . ."button in this box. Among other options, the".. ."button allows you to select a source IP address by clicking aUser or Group object in the NDS tree. In this case, you would click theEveryone Group object in your NDS tree.
You would then use your mouse to point, click, and block out the hoursbetween 9 a.m. and 5 p.m. Monday through Friday in the Time Constraint box. (See Figure 1.) Finally, you would click Protocolin the Access Specification box and select FTP. By completing these fewsteps, you would have created a rule.
Making the Rule Stick
The next time Fred, a member of the Everyone group, logged in to thenetwork and tried to access an FTP server between 9 a.m. and 5 p.m., thefollowing chain of events would occur:
Fred would enter a URL that included a host name in his WWW browser.The browser would ask the enhanced WINSOCK.DLL file on Fred's Windows clientto resolve the host name by finding the IP address of the requested FTPserver. The WINSOCK.DLL file would pass the browser's request to the IPX/IPgateway on the border server, and the gateway would resolve the host nameand return the IP address (130.57.2.6, for example) to Fred's client. Theclient, in turn, would send the IP address to the browser, which would askthe WINSOCK.DLL file to establish a connection with the FTP port at IP address130.57.2.6.
Next, the WINSOCK.DLL file would access the border server running theIPX/IP gateway and ask the gateway to establish a connection with IP address130.57.2.6. The gateway would then check NDS to determine whether Fred wasauthorized to make this connection.
Because Fred was a member of the Everyone group, which was restrictedfrom accessing FTP sites between 9 a.m. and 5 p.m. Monday through Friday,the gateway would deny Fred's request. However, if Fred requested the sameconnection at 5:05 p.m., the gateway would establish a connection to IPaddress 130.57.2.6.
The circuit-level gateways impose restrictions when a connection is beingestablished, but after the connection has been established, the gatewaysdo not perform packet filtering. For example, if Fred waited until 5:05p.m. to request a connection to an FTP site and the gateway establisheda connection to IP address 130.57.2.6, Fred could download any files hewanted. Although the gateways do not allow you to control which files userscan access, Novell's HTTP proxy enables you to do just that.
HTTP PROXY
With Novell's HTTP proxy, you can create rules that filter packets afterthe circuit-level gateway has established a connection between a clientand an intranet or Internet host. The HTTP proxy checks the URL a user hasentered and uses the rules you configured in the NWADMIN utility to determinewhether to permit or deny access to the host associated with that URL.
Both the circuit-level gateways and the HTTP proxy consult NDS to determinewhether to accept or deny packets. For example, suppose that you wantedto create a rule similar to the FTP rule in the previous example: You wantedto restrict access to all WWW sites that contain pornographic material,preventing users from accessing these sites between 9 a.m. and 5 p.m. Mondaythrough Friday.
To create such a rule, you would follow basically the same steps outlinedin the previous example, except you would click the URL option in the AccessSpecification box on the Rule Definition screen. This option enables youto specify entire URLs, domain names within URLs, or categories of URLsto which you want to restrict access. In this case, you would select categoriesof URLs from Microsystems' CyberNOT List. (See Figure2.)
Figure 2: You can use the CyberNOT List screen to restrict users' access to particular WWW pages or sites.
Using CyberNOT List
CyberNOT List organizes WWW sites according to the material they contain--materialthat many companies might not want their users to access during workinghours. For example, your company might want to restrict access to racistor militant material.
When you install Novell's border services, you load a file that containsa version of Microsystems' CyberNOT List into NDS. During the installationprocess, you are also given the option to run Microsystems' registrationprogram. If you register to use CyberNOT List, Microsystems provides youwith a key that unlocks the complete CyberNOT List file and enables yourborder server to periodically access Microsystems' parent database, whichthen automatically updates the file.
To configure a rule that restricts users from accessing WWW sites thatcontain pornographic material, you would select the relevant categoriesin CyberNOT List. (See Figure 2.) The HTTP proxywould then compare a URL entered by a user against the list of WWW sitesidentified in the CyberNOT database. If the HTTP proxy found the completeURL or detected a pattern in the URL that matched a pattern in the CyberNOTdatabase, the proxy would send a message to the user's WWW browser, indicatingthat access to the requested URL was denied.
After you created a rule such as the one described above, you would clickOK. The Outgoing Rules screen would reappear, displaying the results ofthe rule you just created.
Enabling the Log Rule Hit Option
In addition to configuring rules, you can enable the Log Rule Hit optionon the Rule Definition screen in the NWADMIN utility. When you enable thisoption, you can view an access control log that lists all of the trafficthat Novell's circuit-level gateways and HTTP proxy have handled duringthe dates you specify.
The access control log displays information about each packet exchange,such as the date and time each packet passed through the gateways or proxy,whether the packet was accepted or denied, the network or intranet user'sIP address, the URL this user entered, and the protocol that was used. Ifyou highlight an entry, the access control log also displays the rule thegateway or proxy used to determine whether to accept or deny the packet.
Can I Have That in Cache, Please?
Not only does the HTTP proxy improve security, but it also enhances performanceby caching frequently accessed WWW files. Basically, the HTTP proxy storesrequested WWW files in cache. When a WWW browser requests one of these filesagain, the proxy can return the file directly--without having to retrievethat file from the file's home server. Using the NWADMIN utility, you canconfigure the HTTP proxy to provide one or both of the following services:
Normal caching, orpassive caching
HTTP acceleration, orreverse caching
Passive Caching
If a user's WWW browser has been configured touse Novell's HTTP proxy, passive caching accelerates the user's access tofiles on WWW servers. (See "Configuring World-Wide Web Browsers.") With passive caching, the browser does not contacta WWW server directly; instead, the browser sends a user's file requestto the HTTP proxy. (See Figure 3.)
Figure 3: With passive caching, a WWW browser on your network or intranet sends a user's request for a file that resides on an Internet server to your HTTP proxy, which checks its cache for the file. If the file is in cache, the proxy returns the file to the browser without having to retrieve the file from the Internet server. If the file is not in cache, the proxy retrieves the file from the Internet, stores a copy of the file in cache, and returns this file to the browser.
The HTTP proxy, in turn, contacts the appropriate HTTP, FTP, or Gopherserver, retrieves the requested file (if this file is not in cache), storesa copy of the file in cache (assuming the file can be cached), and returnsthe file to the WWW browser. (For information about how the HTTP proxy decideswhich files to cache, see "Do You Want Thatin Cache?")
To enable passive caching using the NWADMIN utility, you would completethe following steps:
Launch the NWADMIN utility, and double-click the Border Server object in the NDS tree.
Click the Proxy Cache Services option on the Setup screen, and then click the Web Proxy Cache button.
Click the Enable HTTP Proxy option on the Web Proxy Cache screen, and enter the port number (usually 8080) the border server uses for HTTP packets originating from your network or intranet.
After you enable the HTTP proxy, it performs passive caching, actingas a server to a client's WWW browser and as a client to a remote WWW server.If a client's browser is configured to use the HTTP proxy, the followingchain of events would occur when this client requested a file that resideson a remote WWW server:
The HTTP proxy would receive the file request and check its cache forthe file. If this file were stored in cache, the proxy would return thefile to the browser--without consuming bandwidth on your Internet connectionor intranet by retrieving this file from the file's home server.
If the requested file were not stored in cache, the HTTP proxy couldsend the file request to other servers with a cache on your network or intranet(assuming you had configured the proxy to do so). You could configure theproxy cache to be part of a hierarchical cache system by selecting the Advancedoption, which you can access from the Web Proxy Cache screen in the NWADMINutility. You could then link this proxy cache to the proxy cache on otherlocal servers to further prevent file requests from consuming bandwidth.
If the requested file were stored in cache on one of these local servers,the HTTP proxy would retrieve this file and return it to the WWW browser.If the requested file were stored in cache on more than one local server,the proxy would retrieve this file from cache on the nearest local server(the server that is the fewest hops away on your network or intranet) andreturn the file to the browser.
If the requested file were not stored in a cache on a local server, theHTTP proxy would retrieve this file from the file's home server, store acopy of this file in cache, and return the file to the WWW browser. In thisway, the proxy would reduce the number of file requests sent over the Internetor intranet to WWW servers, thereby conserving bandwidth and acceleratingusers' access to WWW files.
Reverse Caching
You can also configure the HTTP proxy to performreverse caching, which means that the proxy stores in cache a copy of filesresiding on your local WWW servers. Then when a WWW browser on the Internetrequests a file that resides on one of these servers, the proxy can retrievethe file from its cache. (See Figure 4.) In this way, the proxy shields your local WWW servers from the Internet andconserves bandwidth by reducing the number of file requests sent over yournetwork or intranet.
Figure 4: With reverse caching, a WWW browser on the Internet sends a request for a file that resides on your local HTTP server to your HTTP proxy, which checks its cache for the file. If the file is in cache, the proxy returns the file to the browser without having to access your local HTTP server. If the file is not in cache, the proxy retrieves the file from your local HTTP server, stores a copy of the file in cache, and returns this file to the browser.
To enable reverse caching using the NWADMIN utility, you would completethe following steps:
Launch the NWADMIN utility, and double-click the Border Server object in the NDS tree.
Click the Proxy Cache Services option on the Setup screen, and then click the Web Proxy Cache button.
Click the Enable HTTP Accelerator option on the Web Proxy Cache screen.
If you enabled the HTTP accelerator, the HTTP proxy would act as a clientto a local WWW server and as a server to a WWW browser on the Internet.The next time a browser on the Internet requested a file that resided onone of your local WWW servers, the following chain of events would occur:
The HTTP proxy would receive the file request and check its cache forthe file. If this file were stored in cache, the proxy would return thefile to the WWW browser without accessing your local WWW server. If thefile were not stored in cache, the proxy would retrieve this file from yourlocal WWW server and return the file to the browser.
Second-Generation Technology
Although Novell's border services is a new product, its proxy cache isbased on proven technology--the architecture of the Harvest Web Proxy Cache.The Harvest Web Proxy Cache was jointly developed by the Universities ofColorado and Southern California and was later transferred to the NationalLaboratory for Advanced Network Research (NLANR), which renamed the cachetechnologySquid. Squid is second-generation technology that exceedsthe capabilities of the CERN caching technology (developed at the EuropeanLaboratory for Particle Physics) on which Squid is based.
The computer science departments at the Universities of Colorado andSouthern California report that Squid provides access to Internet data fourto 10 times faster than a client's browser could access the data on itsown. As an IntranetWare implementation of the UNIX-based Squid, Novell'sproxy cache promises the same increase in performance, which, in turn, promisesan increase in user productivity.
CONNECTIVITY AT THE BORDER
In addition to addressing security and performance concerns, Novell'sborder services addresses connectivity issues. As mentioned earlier, NetWareMPR enables you to attach an IPX-based network to the IP-based Internet.In addition, Novell's border services includes NetWare Connect, a server-basedremote communications platform. NetWare Connect enables remote users todial in and access your network or intranet from the Internet and enableslocal users to dial out and access the Internet using a modem pool.
Tunneling Across Enemy Lines
Novell's border services also addresses more sophisticated connectivityissues. Specifically, the product includes a configuration tool that allowsyou to create a virtual private network (VPN). A VPN encrypts all data thatpasses through it, enabling you to securely and cost-effectively connectyour corporate office and branch offices over Internet lines.
A VPN is like a secret tunnel across enemy lines through which you cansecurely transmit data. The data remain invisible to everyone but the userswho are authorized to see the data.
Figure 5 shows how a VPN created with Novell'sconfiguration tool works. Suppose that you wanted to create a VPN over Internetlines, connecting a corporate office in California and a branch office inIowa. Of course, you would first need to get an account with an Internetservice provider (ISP) and configure the border servers in California (CA-MC)and Iowa (IA-MC) to connect to the Internet (by performing the correct TCP/IPbinds, for example).
Figure 5: Encrypting and decrypting data sent over a VPN
After you connected the offices, CA-MC and IA-MC would need to find outa few things about each other before they could exchange data across a VPNtunnel. Among other things, CA-MC and IA-MC would need to learn each other'spublic IP addresses, and they would need to share a secret, as explainedin the next section.
Master and Slave Members
CA-MC and IA-MC would gather the information they needed during the VPNconfiguration process, which begins when you decide which border serverwill be the master member of the VPN and which border server will be theslave member. Although there is little difference between the master andslave members, the master member does have a few key responsibilities. Forexample, the master member is responsible for synchronizing the VPN membersand selecting the parameters that will be used to generate the shared secret.Specifically, the master member specifies the Diffie-Hellman parametersused to generate public and private Diffie-Hellman keys from which the sharedsecret is derived. (Diffie-Hellman is a public-key encryption algorithmnamed after Whitfield Diffie and Martin Hellman, who proposed the algorithm.)
Novell recommends that you select the border server at your corporateoffice to serve as the master member. After you chose the master member,you could configure the VPN. In this case, you would begin the configurationprocess by running the VPNCFG NLM on CA-MC.
During this configuration process, CA-MC would gather or generate thefollowing information:
Its public IP address
Its VPN tunnel IP address
Public and private RSA key pair
Diffie-Hellman parameters
Public and private Diffie-Hellman keys
IP Address
The VPNCFG NLM would prompt you to enter the publicIP address of CA-MC. The public IP address, which is the IP address thatany Internet user would use to contact the border server, must be a registeredIP address.
The VPNCFG NLM would also prompt you to enter the IP address associatedwith the VPN tunnel. This IP address does not have to be a registered IPaddress. Instead, you could arbitrarily assign the VPN tunnel an IP addressand use that same subnet number for all members of the VPN. For example,using 130.57.1.x as the subnet number, you could assign 130.57.1.1 to CA-MCand 130.57.1.2 to IA-MC as the VPN tunnel IP addresses.
RSA Key Pair
CA-MC would create a digital signature and use itto sign any data CA-MC sent to IA-MC. IA-MC could then read the signatureto verify that CA-MC had sent the data and that the data had not been modified.To this end, CA-MC would generate a public and private RSA key pair andsend its public RSA key out-of-band to IA-MC. (Out-of-band is explainedin the next section.) IA-MC would then use CA-MC's public RSA key to authenticatethe information received from CA-MC.
Diffie-Hellman Parameters and Keys
CA-MC would generate the parametersthat it would then use to generate the public and private Diffie-Hellmankeys used to create a shared secret. (For information about how a sharedsecret is created, see the "Shhh! It's a Secret" section.) CA-MC would store the private Diffie-Hellman key and send boththe public Diffie-Hellman key and the Diffie-Hellman parameters to IA-MC.
Out-of-Band Verification
Ultimately, you would send the following information to the IA-MC administratorvia e-mail or on a floppy diskette via regular mail:
CA-MC's public RSA key
Diffie-Hellman parameters
To ensure that this information safely reached the IA-MC administrator,CA-MC would generate a message digest, which is a summary of the entiremessage. The message digest is a string of hexadecimal numbers totaling16 bytes and basically summarizes the information generated by the mastermember during the configuration process. The message digest is used forout-of-band verification, which occurs after the administrator of the slavemember receives the e-mail message or floppy diskette from you, the administratorof the master member.
In this example, when the IA-MC administrator received the floppy disketteyou sent, he would run the VPNCFG NLM and, when prompted, identify IA-MCas a slave member. This NLM would then prompt the IA-MC administrator toverify the legitimacy of the floppy diskette.
To verify that the floppy diskette came from CA-MC and that it had notbeen modified en route, the IA-MC administrator would call you and readthe message digest aloud: If the message digest he received matched theone you sent, both you and the IA-MC administrator would know the floppydiskette was legitimate, and the IA-MC administrator could continue theconfiguration process.
Storing Slave Information
To continue the configuration process, IA-MC would store CA-MC's publicRSA key and use this key from now on to verify CA-MC's digital signature.IA-MC would also use CA-MC's Diffie-Hellman parameters to generate its ownpublic and private Diffie-Hellman keys. IA-MC would then store its own privateDiffie-Hellman key, and place its public Diffie-Hellman key and its publicIP address on a floppy diskette, which the IA-MC administrator would sendto you. To ensure that this information safely reached you, IA-MC wouldalso generate a message digest.
When you received the floppy diskette, you would need to launch the NWADMINutility and click the Border Server object in the NDS tree. Then you wouldclick the VPN button to access the VPN Member screen, on which you wouldadd IA-MC as a VPN member.
The NWADMIN utility would first prompt you to verify the legitimacy ofthe floppy diskette. To verify that the diskette came from IA-MC and thatthe diskette had not been modified en route, you would call the IA-MC administratorand read the message digest aloud: If the message digest you received matchedthe message digest the IA-MC administrator sent, both of you would knowthe floppy diskette was legitimate and unchanged, and you could continuethe configuration process.
CA-MC would then store IA-MC's public IP address and public Diffie-Hellmankey in the master configuration table. After IA-MC's configuration informationhad been saved, you would activate the Resynchronize command in the NWADMINutility to send the master configuration table--signed with CA-MC's digitalsignature--to all VPN members (in this case, only IA-MC). Both CA-MC andIA-MC would then have stored their own private Diffie-Hellman keys and wouldhave access to each other's public IP addresses and public Diffie-Hellmankeys by way of the master configuration table.
Shhh! It's a Secret
Finally, the VPN members would have the information they needed to createa shared secret: CA-MC would use its own private Diffie-Hellman key andIA-MC's public Diffie-Hellman key to generate the shared secret; likewise,IA-MC would use its own private Diffie-Hellman key and CA-MC's public Diffie-Hellmankey to generate the same shared secret.
Having established a shared secret, CA-MC and IA-MC could exchange dataacross a VPN tunnel. If CA-MC were to send the data, CA-MC would randomlygenerate an encrypted key and would then encrypt this data. Novell, whichuses the RC2 algorithm for encryption, uses 128-bit keys for versions ofits border services product sold within the United States and 40-bit keysfor versions sold outside the United States. (The U.S. government does notallow the export of RC2 encryption that uses more than 40-bit keys.)
Next, CA-MC would encrypt the randomly generated, encrypted key usingthe shared secret. When IA-MC received the data, it would use the sharedsecret to decrypt CA-MC's randomly generated, encrypted key and would thendecrypt the data using this key. (See Figure 5.) Finally, IA-MC would send the data to the appropriate site on its networkin unencrypted form. At this point, packets originating from the VPN wouldappear to be normal packets.
CONCLUSION
Secure and cost-effective connectivity between corporate and branch offices,caching frequently accessed WWW files for enhanced performance, and packetfiltering from the network to the application layer of the OSI model--Novell'sborder services has it all. Its components (NetWare MPR, the circuit-levelgateways, the HTTP proxy, NetWare Connect, and the VPN configuration tool,to name a few) address the security, performance, and connectivity issuesmost companies face when they connect their network or intranet to the Internet.
In addition, all of these components can be managed using the NWADMINutility. And unlike other solutions, which typically solve only one border-relatedproblem, Novell's border services has a modular design that lends itselfto future enhancements:"In subsequent releases of the product,"says Kevin Rose, product manager of the Novell Internet Products division,"you can expect to see more and more services deployed at the border."
For more information about Novell's Border Services, visit Novell's WWWsite (http://www.novell.com/ear/products/newprods/border.html). You can also call 1-800-NETWARE or 1-801-861-5588.
Linda Boyer works for Niche Associates, which specializes in technicalwriting.
NetWare Connection, May 1997, pp.25[shy ]36.
Configuring World-Wide Web Browsers
You can configure clients' World-Wide Web (WWW) browsers to access HyperText Transport Protocol (HTTP), FTP, and Gopher files through your border server. The steps you take to configure a WWW browser vary, depending on the browser; but in each case, you must specify the uniform resource locator (URL) and port number (usually 8080) the browser should use to access the HTTP proxy component of Novell's border services, as the following examples indicate.
CONFIGURING NETSCAPE NAVIGATOR
Launch Netscape Navigator, and select Network from the Options menu. Then select Proxies.
Click the View button, and complete the HTTP Proxy, FTP Proxy, and Gopher Proxy fields by entering the HTTP proxy's URL without http://. For example, if the proxy's complete URL were http://wwwcache.novell.com, you would enter wwwcache.novell.com in each of the fields.
In the Port field, enter the port number the WWW browser should use to access the HTTP proxy.
CONFIGURING MICROSOFT INTERNET EXPLORER
Right-click the Internet icon on your Windows 95 desktop, and select Properties.
Select the Connection tab, and then select the option to connect through a proxy server.
Click the Settings button, and complete the HTTP, FTP, and Gopher fields by entering the proxy's URL without http://. Then enter a colon and the port number the browser should use to access the HTTP proxy. For example, if the proxy's URL were http:// wwwcache.novell.com and the port number were 8080, you would enter wwwcache.novell.com:8080 in each of the fields.
Hide!
If you have assigned unregistered IP addresses to your network or intranet clients, these IP addresses can cause problems at the border when you decide to connect your clients to the Internet: Only clients with registered IP addresses can connect to the Internet. One possible, albeit horrifying, solution is to change the IP address on every client. A far more convenient solution is to use the IP Network Address Translator (NAT) included with Novell's border services.
The IP NAT maps all of the IP addresses on your network or intranet to one registered IP address. In addition to providing an easy way of connecting clients with unregistered IP addresses to the Internet, this solution also hides these clients from the Internet: All packets, regardless of their actual source IP address, appear to Internet users to have originated from the same registered IP address.
The IPX Address Mapping Gateway, which is also included with Novell's border services, offers a similar capability: This gateway maps the IPX addresses on your network or intranet to one registered IPX address. You can then connect to global IPX networks, such as AT&T WorldNet Intranet Connect Service (formerly known as AT&T NetWare Connect Services), without having to assign a new IPX address to every client.
Do You Want That in Cache?
The HyperText Transport Protocol (HTTP) proxy will not cache files that match one or more of the following criteria:
The file's uniform resource locator (URL) matches patterns you specified in the NetWare Administrator (NWADMIN) utility as non-cacheable
The file's HTTP headers include a cache directive or time-to-live (TTL) tag that indicates the file is non-cacheable
SPECIFYING NON-CACHEABLE FILES IN THE NWADMIN UTILITY
To specify non-cacheable files, complete the following steps:
Launch the NWADMIN utility, and double-click the Border Server object in the Novell Directory Services (NDS) tree.
Click the Proxy Cache Services option on the Setup screen, and then click the Web Proxy Cache button.
Click the Advanced button on the Web Proxy Cache screen, and specify exact URLs, substrings within URLs, or IP address domains associated with files that you do not want stored in cache.
You could specify as non-cacheable any files associated with URLs linking to programs that generate documents dynamically. For example, you could specify Common Gateway Interface (CGI) programs (usually identified by the "cgi-bin" substring in a URL) as non-cacheable. Then if one of your users entered http://www.xyz. com/cgi-bin in his or her World-Wide Web (WWW) browser, the HTTP proxy would not check its cache. Instead, the proxy would retrieve the associated file directly from the file's home server.
HTTP 1.1 CACHE DIRECTIVES
In addition, the HTTP proxy will not cache a file that contains a no-cache directive in the file's HTTP header. Every HTTP request from a browser and every response from a server consists of a start line, one or more HTTP headers, an empty line identifying the end of the headers, and a message containing the actual file.
Among the hundreds of possible HTTP headers are cache-control directives, which are flags that tell a proxy whether to cache all, some, or none of a message. A no-cache directive indicates that either all or part of the message should not be stored in cache.
TTL TAGS
The HTTP proxy also recognizes HTTP headers that indicate the age of a file. The proxy uses these headers to ensure that files stored in cache are up-to-date. For example, a file could include an Expires header indicating the file's expiration date. If a cached file included an Expires header that contained the date 5/15/97 and a user requested this file on 5/16/97, the proxy would discard the expired file in cache, retrieve the latest version of the file from the file's home server, and store a copy of this version in cache.
Some HTTP headers indicate only the date a file was last modified. In this case, the proxy assigns the file a TTL tag, based on information you configure in the NWADMIN utility. For example, you could configure the proxy to assign TTL tags by adding to a file's retrieval date half the time elapsed since the file was last modified.
Suppose that a file's HTTP header indicated the file was last modified on 5/1/97 and you specified in the NWADMIN utility that the HTTP proxy should assign a TTL tag based on half the time elapsed since the file was last modified. If the proxy retrieved the file on 5/5/97 (four days since the date it was last modified), the proxy would assign a TTL tag of 5/7/97, adding two days, or half the number of days elapsed since the file was last modified.
The HTTP proxy also assigns a TTL tag (based on the information you configure in the NWADMIN utility) for files with HTTP headers that specify neither an expiration date nor the date last modified, and the proxy assigns a TTL tag for FTP and Gopher files, which have no means of specifying either of these dates.
* Originally published in Novell Connection Magazine
Disclaimer
The origin of this information may be internal or external to Novell. While Novell makes all reasonable efforts to verify this information, Novell does not make explicit or implied claims to its validity.