FRONTBASE TECHNICAL NOTES
FRONTBASE TECHNICAL NOTES

FrontBase, Firewalls and Ports

By: Tom Hume,July 27, 2001

Content

Connecting to databases using FBManager through a firewall
Connecting with client software such as a WebObjects application
Configuring the database: Using the invocation option -port
Debugging problems
Known issues
More information

Introduction

A firewall could be described as a system or group of systems that enforces an access control policy between two networks. The firewall usually has two basic mechanisms; one that exists to block traffic, and the other that exists to permit traffic. It is important to recognize that the firewall's configuration, as a mechanism for enforcing policy, imposes that policy on everything behind it.

Some people actually try to get real work done over the Internet, and others have sensitive or proprietary data they must protect! Usually, a firewall's purpose is to keep would be hackers out of your network and away from your data whilst allowing you to get your job done. A firewall provides not only real security; it also often plays an important role as a security blanket for management.

Often a question for developers is "How do I make my web server act as a front-end for a database that lives on my private network?" The following technical note seeks to explain the potential issues with using firewalls and the FrontBase database server. In general, FrontBase makes no use of special ports or does other things that may cause security concerns.

Connecting to databases using FBManager through a firewall

One may need to use FBManager in FrontBase from a machine outside a firewall. Some understanding of the FrontBase processes and ports is required in this context. FBManager communicates with the FBExec process on port 20020 so this port would have to be opened or tunnelled through a firewall for FBManager to work properly. Once FBManager contacts FBExec and the user attempts to make a database connection, FBManager has to be able to reach whatever port the database in question is running on. In typical use, the database starts up on a random available port. When a client needs to access a database, FBExec is asked to supply the port number that the database is using. So if you have a firewall you need to know which port number to open. This default behaviour would make it rather difficult to tunnel through firewalls. However, the database can be started on a specific port explicitly using the -port=12345 command-line option. This is described below in "Configuring the database".

Connecting with client software such as a WebObjects application

Perhaps you need to access a FrontBase database with the EOModeler from WebObjects through a firewall. Again, you need to know which port number you will have to tunnel so the above considerations apply to other client environments as well. Of course, if all FrontBase processes also reside behind the firewall there is no issue.

Configuring the database: Using the invocation option -port

Syntax: -port=<port_number>

A FrontBase database communicates with clients using BSD style sockets, requiring the clients to know the so called port number before a connection can be made. Clients will communicate with the FBExec process to get the port number of a given FrontBase database. A FrontBase database will normally acquire a port number from the host operating system, but, for example, in setups with a firewall, static and known port numbers may have to be used. By using the -port option, a FrontBase database can be directed to use a specific port number.

Debugging problems

When debugging firewall problems, it is often useful to use Telnet to confirm that the firewall is behaving as expected. One should be able to Telnet from outside the firewall to the IP and port opened and succeed (e.g. "telnet db_host 55555"). If that fails, the problem is likely to be with the actual firewall.

>

Known issues

One may encounter an issue where the FB Manager connection seems to time out and produces a "Database Not Running" error message. The problem could be caused by your firewall environment and the way FB communicates with FBExec. If your client machines are behind a NAT system the IP connections allocated are timed out after an idle time by the NAT process. If the connection to FBExec and the FrontBase server is cut off by your NAT, the FrontBase client won't be able to reconnect to the database because it needs the connection to FBExec in order to know the database port and this connection will have broken.

N.B. The NAT (Network Address Translation) system provides a way to share an IP address for multiple machines and is often use with a firewall and is often built into routers.

More information

The FrontBase Users Guide available @ FrontBase

Please mail us at support@frontbase.com

Firewalls Mailing list This firewalls mailing list is a forum for firewall administrators and implementers which is rich with relevant information.

Firewall HOWTO Describes exactly what is needed to build a firewall, particularly using Linux.