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.)
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.
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.)
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
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.
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.
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.
How the Client Knows Where to Connect
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 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.)
TIP 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.
Setting up the Solution
Documenting Your Solution
You can use gwip.nlm to verify connectivity on certain ports. support.novell.com/ servlet/filedownload/ pub/gwip.exe
TIP 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
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:
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://support.novell.com/servlet/filedownload/pub/gwip.exe. You can also use TCPCON on NetWare to verify which ports are listening on which IP addresses.
Configuring and Loading the Second POA
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.
1 Create the second POA object for each post office
1 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.
2 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.
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.
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.
2 Install the GroupWise Agent Code
3 Configure Each POA Startup File
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.
1 The GroupWise client connects to a particular POA.
2 Using the UserID, the POA validates that it is a valid GroupWise user.
3 If it is a user on this particular post office, the POA starts the authentication process and a redirect doesn't occur.
4 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: