Teacher's Pet: The Right Answers for GroupWise Remote
Articles and Tips: article
01 May 2004
It's 10 p.m and you've just arrived at the hotel after a long flight. You still have to check your e-mail and respond to some important messages about an appointment tomorrow morning with a highprofile customer. You boot your laptop, connect to the hotel's Internet connection and fire up your VPN client. After several unsuccessful attempts to connect, you call your company's 24x7 helpdesk. They tell you that there is a network problem preventing you from connecting. So you launch your browser and begin checking your e-mail through GroupWise WebAccess. Then, you start mumbling, "There must be a better way to still use the GroupWise client without the overhead of a VPN client." Imagine how productive you'd be with a consistent messaging environment wherever you needed access to your mailbox. No more calls to the helpdesk when you can't connect to your VPN. Then suddenly, you realize that you just dozed off and your browser session has timed out. So you log back in and resume your work still muttering, "There must be a better way." Well, there is.
In today's world, users need access to applications from anywhere, often at any time. Many times these applications are Web enabled so you just need a browser for access. Novell GroupWise is the leader in browser-based access to e-mail from a wide variety of devices. However, there are situations where you need access to your GroupWise account while using the power of the full GroupWise client. You can enhance productivity dramatically by providing users the ability to access their GroupWise mailbox from any Internet connection. Users gain tremendous time savings by not having to fuss about what configuration option to select, know if they need a VPN client, or worry about how secure a particular connection is.
This article outlines a simple solution that empowers your users to get their jobs done literally anytime from anywhere. It gives them access to their mailbox using the full GroupWise client (which is now supported on Windows, Macintosh and Linux) from any Internet connection in a fast, secure and reliable manner. (For information on the benefits of this solution see Happy GroupWise Mobile Users.)
Architecture
You may need to modify this design to meet your company's needs. It is important to understand that from a GroupWise perspective, the most reliable, secure and the fastest remote solution is to ensure that the user's GroupWise client is talking directly to their "owning" Post Office Agent (POA). (By "remote" I mean the GroupWise client running in Cache or Remote modes.)
So just how do you do this? You could simply open ports on your company firewall directly to the GroupWise post office servers. However, for many organizations, this is a major security "no-no." GroupWise provides an alternative: running a second POA against each of your post offices. GroupWise has supported this for years. This second POA would exist, or run inside your company's Demilitarized Zone (DMZ), the area between two firewalls. (All Web and application servers should reside in the DMZ for security purposes.) This is the POA through which your remote and cache users would be connected to their "owning" POA. This solves the problem of needing and supporting a VPN client on each user's PC. (See Figure 1.)
Figure 1
The POAs running on the server in your company's DMZ require access to the post office message store located on your company backbone. This is accomplished by opening port 524 (Novell Core Protocol) from the GroupWise DMZ server to your backbone GroupWise server(s). As the POA on the DMZ server loads, it authenticates to the GroupWise server on the backbone (SERVER1, SERVER2, etc.) where it then accesses the post office message store. (The message store refers to where a user's e-mail is stored on the server.)
GroupWise Proxy Server Concepts
Beginning with GroupWise 6, Novell introduced a new setting on the POA object called the Proxy Server Address. This is used by the GroupWise client and other POAs when they need to redirect a GroupWise client to the user's owning post office.
The Proxy Server address does not point to a traditional HTTP or FTP proxy server such as BorderManager. It represents a public class IP address or DNS name that is publicly accessible from an Internet connection. The device that has this public IP address would be configured to take data that hits it on a unique port and send it to the particular POA for which you defined the Proxy Server address. In GroupWise 6.0 you must have a unique Proxy Server address for every post office for which you want to enable this solution.
GroupWise 6.5 allows you to define an Internet Proxy Client/Server port for each post office. This allows you to use the same Proxy Server address for each post office, and then assign a unique Internet Proxy Client/Server port per POA. Figure 2 shows a GroupWise 6.5 POA with the Proxy Server address and Internet Proxy Client/Server port values entered.
Figure 2: Define the Proxy address and port that are used as an alternate address to connect to the post office.
As shown in Figure 2, the GroupWise client can connect to eraff3.eraff.com on port 1667 and find its POA. That's the beauty of this solution. The client and all other POAs in the GroupWise system now have two addresses that represent a particular post office.
So when you're sitting in your hotel room and launch the GroupWise client, it will try first to connect to the TCP/IP address. If this fails, the client will try the Proxy Server address. When the GroupWise client is connected through either IP address, the mailbox is synchronized. Figure 3 shows the GroupWise client connection log rolling over to the proxy address and beginning to synchronize.
Figure 3: The GroupWise client rolls over the Proxy Server address and begins to synchronize.
How the Client Knows Where to Connect
Now consider this: you have a workstation onto which you have just installed the GroupWise client for the first time. You want the client to be able to connect no matter where the user is located. This saves the user from getting a confusing prompt asking for an IP address and port and prevents a help desk call. So how is this accomplished?
When you install the GroupWise client there are two settings in the SETUP.CFG file that can be very helpful. They are the "DefaultIPAddress=x.x.x.x" and the "DefaultIPPort=xxxx" values. When the client is installed, these two settings are written to the Windows registry under HKLM\SOFTWARE\ Novell\GroupWise\ Client\5.0\. These registry keys are used by the GroupWise client to tell it where to connect if it doesn't know where to find a POA. In essence, they replace NGWNAMESERVER which the client will not try if these two registry settings are present. This provides a way to point your GroupWise clients directly to a post office Proxy Server address and Internet Proxy Client/Server port for all of your GroupWise clients. In other words, the value that you define for the DefaultIPAddress in your SETUP.CFG should usually be the DNS name that resolves to your Proxy Server address. The DefaultIPPort value would be port 1677, which one of your POA agents running in your DMZ needs to be listening to. When the user connects, (in Cache, Remote or Online modes) if this POA is not their owning post office, then the POA will simply redirect them to the proper IP address and port depending on where they are connecting from. You don't need to configure anything on the client; it simply knows where to connect and is redirected if needed. (For information on how the POA knows where to redirect the user see POA Redirect Algorithm.)
Hint: You can easily check the post office redirection links through the HTTP interface of the 6.5.x POA. Figure 4 shows the redirection table of a POA. Notice the Proxy address and port definition that the POA knows about.
Figure 4: GroupWise 6.5.1 POA displays a redirection table through the HTTP interface. Note the proxy server address and port for each post office in the GroupWise system.
Setting up the Solution
The solution is set up in three phases:
PHASE 1 Document Your Solution
PHASE 2 Configure Your Network Infrastructure
PHASE 3 Configure and Load the Second POA
Documenting Your Solution
First, lay out the design of your GroupWise remote solution. Spend some time on it by giving yourself a few days to think it over and sleep on it. Then review it with others. It's important you have a solid design before going to the next phase. You won't want to change your design mid-way through which may require your network infrastructure team to re-do firewall configurations or open different ports, etc. Consider the following points when designing and documenting your solution:
How will you design your DMZ infrastructure?
What network devices must communicate to your GroupWise DMZ server(s)?
What will the public IP address be for the Proxy Server address?
What ports will be used for the Internet Proxy Client/Server port on each POA?
How will the GroupWise DMZ Server connect to the various post office directories on the backbone?
What user names and passwords will the DMZ POAs use to authenticate to the backbone servers?
What file system rights must users have?
What will the DMZ POA startup files be named? (I use DMZ_postofficename.POA.)
Where will the /home- switch point in the DMZ POA startup file?
What other startup switches should be in the DMZ POA startup file?
Will LDAP authentication be enabled? If you do use LDAP authentication, then the POAs in the DMZ must be able to access your LDAP servers on the correct IP address and LDAP port. The way the DMZ POAs access these LDAP servers may be through different IP addresses than those which your backbone POAs use.
Hint: If so, define the proper IP address(es) in the DMZ POA startup file.
Take the time to ensure you answer the preceding questions and understand exactly what your network infrastructure will look like before you start setting it up. Create a table like the one shown in Figure 5 to document your IP addresses and ports.
Configuring Your Network Infrastructure
Network infrastructure setup consists of opening various ports from the Internet, using Network Address Translation (NAT) to get the data into your DMZ server, and opening port 524 into your backbone GroupWise servers.
Make sure your infrastructure is properly set up before you start configuring and loading POAs in the DMZ. A simple telnet session can verify which ports are open. You can also use the GWIP.NLM utility from a NetWare server to validate that you have connectivity on certain ports. Make sure that port 524 is open from the GroupWise DMZ server to the backbone post office servers. Download the GWIP tool from http://download.novell.com/Download?buildid=P3aa978kWeY~. You can also use TCPCON on NetWare to verify which ports are listening on which IP addresses.
Configuring and Loading the Second POA
This phase is broken down into three tasks:
1 Create the second POA object for each post office
From ConsoleOne, create a new POA object under each post office for which you want to enable this solution. Name the POA object "POA_RMT" to distinguish it as the one that handles the remote/cache users.
Configure this POA with the proper settings. The only thing this POA will do is handle remote requests. (Don't enable ANY other services.) The following lists the information on each tab of a GroupWise 6.5 POA and the recommended settings. Note: If a particular setting is not listed, it's either irrelevant at this point or the default setting is preferred.
Identification
Description: "***DMZ*** Live Remote POA" (I use the asterisks (*) to indicate that I'm looking at the POA in the DMZ and not the production backbone POA.)
Agent Settings
Message File Processing: Off
Message Handler Threads: 12
Enable TCP/IP (for Client/Server): checked
TCP Handler Threads: 32
Max Physical Connection: 1024
Max App Connections: 2048
Enable Caching: unchecked
Enable IMAP: unchecked
Enable CAP: unchecked
Enable SNMP: unchecked
HTTP User Name: <<your monitor user name>>
HTTP Password: <<your monitor password>>
Network Address
TCP/IP Address: leave blank
Proxy Server Address: leave blank
IPX/SPC Address: leave blank
Message Transfer Port: 0
HTTP: 16x1
Note: Refer to your table (like Figure 5) for your correct HTTP port for each POA.
Local Intranet Client/Server: 16x7
Note: Refer to your table (like Figure 5) for your correct port for each POA.
Internet Proxy Client/Server: 0
Note: This is defined on your main POA object.
IMAP: 143
CAP: 1026
Figure 5: Documenting your IP address and port layout prior to beginning setup may alleviate several headaches later on.
You may want to enable SSL on the Local Intranet Client/Server port. This enables the GroupWise 6.5 client to use SSL to communicate with the POA. It's optional; if you leave it disabled, the GroupWise client will use its native encryption to encrypt the data stream between the client and the POA.
QuickFinder
Enable QuickFinder Indexing: unchecked
Maintenance
Enable Automatic Database Recovery: unchecked
Maintenance Handler Threads: 0
Perform User Upkeep: unchecked
Generate Address Book for Remote: unchecked
Figure 6: The post offices for which you're installing the agents are not defined during the GroupWise 6.5 Agent installation because customized POA startup files are built later.
Log Settings
Log File Path: \\ServerName\volume\poa_logs\xxx (xxx is the post office name)
Logging Level: Verbose
Max Log File Age: 30
Max Log Disk Space: 0
Scheduled Events
There should be NO scheduled events checked.
SSL Settings
This setting is optional. If you want to enable SSL between the client and the POA, you need to set up SSL on the POA. Be aware, this will cause some overhead. Refer to the Novell online documentation for information on how to enable SSL at the POA level at www.novell.com/documentation/lg/gw65/index.html.
2 Install the GroupWise Agent Code
To install the GroupWise agent code, run the Agent installation from your Software Distribution Directory (SDD) \AGENTS folder. You don't need to define which post offices you're installing the agents for at this point. Just leave that option blank and continue the installation as shown in Figure 6. You'll then build your customized POA startup files based on the STRTUPUS.POA file explained under Task 3 below.
3 Configure Each POA Startup File
You must configure a few settings via the POA startup file. Build your POA startup file from the STRTUPUS.POA file that was installed during the Agent installation. The required POA startup switches are below:
home-\\x.x.x.x\volume\podir
Note: This switch points to the post office directory on your backbone server.
/name-POA_RMT /user-.userID.ou.ou.o /password-yoursecretpassword /port-xxxx
Note: I've seen the second POAs C/S port get lost and default back to 1677. By using the port switch the POA will always load with the correct proxy port active.
/noada /nogwchk /nomtp
Note: You may need to use the /ip- switch if your DMZ server is multi-homed and you need the POA to bind to a single IP address. If you use the /ip- switch, all ports (C/S, HTTP, IMAP, CAP) will only be available via this IP address.
Q and A
Q: Can I load one POA for all backbone post offices in the DMZ?
A: No. It is a one-to-one relationship.
Q: What about password guessing?
A: I STRONGLY recommend that you enable some level of intruder detection. You can do this in two ways: 1 Enable intruder detection at the post office level.
2 If you're using LDAP authentication, leverage the eDirectory intruder detection settings.
Q: How do I resolve the 8200 and 8209 errors on the DMZ POA server?
A: Enable the Minshall algorithm. For information on the Minshall algorithm, read the "Interactive Data Flow" section of the July 2002 Novell AppNote entitled Tuning the NetWare 6 TCP/IP Stack via SET Parameters. Read it online at http://developer.novell.com/research/appnotes/2002/july/02/a020702.htm.
Q: How many POAs can I load on one server?
A: Because these POAs are strictly dealing with client connections, I would allow for up to eight post office agents per NetWare server. This may sound odd, but my experience has been that this setup will run fine.
Summary
This solution does not require any configuration on the user's part. It's transparent to them. You have a very reliable, fast and secure solution for all of your remote and cache users. Their GroupWise client will always know where to connect. Users will be much more productive on the road and your help desk calls from GroupWise remote users will significantly drop. It's a win-win situation.
Now it's 7 a.m. the next morning in your hotel room and you need to check your e-mail once more before that early appointment with that high-profile customer. You boot up your laptop, connect to the hotel's Internet connection and fire up your GroupWise client. You automatically connect, and soon your GroupWise client is synchronized with your GroupWise mailbox on the server back at the office. Now you have access to the full power of your GroupWise client...from around the world.
POA Redirect Algorithm
When a GroupWise POA receives a client connection either in Client/Server (C/S), Remote or Cache modes it may redirect the user to their owning post office if necessary. There are cases when the POA must redirect the user to the Proxy Server address of their post office rather than the traditional TCP/IP address. Below is how the POA accomplishes the redirect.
The GroupWise client connects to a particular POA.
Note: The workstation IP address and GroupWise UserID are included in the encrypted TCP data portion of the TCP packet that the client sends to the POA.
Using the UserID, the POA validates that it is a valid GroupWise user.
If it is a user on this particular post office, the POA starts the authentication process and a redirect doesn't occur.
If the user is known in the GroupWise system but resides in a different post office, then the POA runs the redirect algorithm as follows:
First, the POA looks in the TCP data portion of the packet that it received from the client.
The POA then compares the IP address found in the TCP data portion of the packet (which the GroupWise client placed there) with the source IP address found in the IP header of the received frame.
If the two IP addresses are different, then the POA knows that this frame or packet came through a device that did Network Address Translation (NAT) on the packet. Usually, this means that the user is not on your company network and needs to be redirected to the Proxy Server address and Internet Proxy C/S port of the userHOPfs owning POA. Then the POA gives the client the correct IP address and port where it can connect.
If the two IP addresses are the same, then the POA recognizes that the user has direct access to it through IP routing, etc., and redirects the client to the TCP/IP address of their owning post office and not the Proxy IP address and port.
Happy GroupWise Mobile Users
There are many benefits to implementing this type of a remote solution for your GroupWise system. This all helps to ensure that your GroupWise users are happy with your solution to provide remote or cache access from any Internet connection. Below are a few of the advantages of implementing this type of solution:
Users can run in Cache or Remote mode from anywhere they have an Internet connection (hotel, home, Wi-fi hotspot, cellular wireless, etc.).
No VPN client is required to set up and maintain.
No configuration changes need be made by the users as they travel to and from the office or use various methods to connect to the Internet.
The service is extremely reliable and stable.
It is the fastest remote solution available for GroupWise.
Helpdesk calls regarding remote issues significantly drop.
Addressing Security Concerns
This solution enables a GroupWise client to connect directly to a POA that has access to the user's message store. We're concerned with what crosses the Internet from the GroupWise client to the POA. Out of the box, GroupWise encrypts and compresses ALL data between a GroupWise client and the POA. You don't have to set that up; it's already in place, and can't be removed. (For more information on how a GroupWise system is secured, see TID2954214 online at http://support.novell.com/cgi-bin/search/searchtid.cgi?/2954214.htm.)
Remember that you can set up your own level of security between the client and the POA with GroupWise 6.5 and later. To do this, generate your own SSL certificate and enable it on the post office Client/Server (C/S) port. (NOTE: When you enable this level of encryption, there is additional overhead on all C/S traffic.)
Attempts to breach a POA's C/S port are intercepted since the POA simply drops any connection that doesn't originate from a GroupWise client and contain the proprietary encrypted and compressed algorithms needed to communicate with a POA.
You may ask, "What about Denial of Service (DoS) attacks?" If a connection is made to a GroupWise POA's C/S port and the POA does not receive encrypted proprietary client data, then the POA drops the connection. If a DoS attack is launched against your system, it won't have any effect on your main production GroupWise POAs. They continue to work without interruption. For a short moment the DMZ POA uses the TCP Handler threads to figure out if invalid data is hitting its C/S port. The only effect your remote and cache users may feel during that short moment is a slower connection as the attack takes place.
* 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.