Event ports with Firebird 1.0.3 and firewall setup

Question

I use Firebird 1.0.3 within a legacy LAN application, which includes parts (processes) that have to be notified about database events; it's running on Windows8.

With CurrPorts, I observe ibserver.exe listening on 3050/tcp and some established connections with [SERVERIP]:3050 as one address pair. So far so good, this behaviour I expected. What I can only guess is, how the other connections (with pattern [SERVER-P]:[port X]-[CLIENT-IP]:[port Y]) get established. The ports X and Y are of course dynamic ports. I guess that for each event notification line

• Firebird server opens a socket with dynamic port number on request by its client
• Firebird passes the port number to the clients and then
• the client has now to create a socket (dynamic port) and calls connect

...but I want to have a clear understanding of it, because I have to set up firewall rules.

Is it enough to enable Firebird (ibserver.exe) on application level on the server machine?

(Changing firebird version and overall architecture is currently not an option.)

Answer 1

By default Firebird uses a random port for events. This doesn't work well with firewalls, so Firebird also offers an option to use a fixed port, using the RemoteAuxPort setting in firebird.conf. This option was added in Firebird 1.5, see the Firebird 1.5 release notes. Migrating from Firebird 1.0 to Firebird 1.5 should be relatively easy (migrating to more recent versions like Firebird 2.5 might be more work).

For details look at the section Common Problems: Firewalls in The Power of Firebird Events by Milan Babuškov:

The client has a regular connection to Firebird server at its port (3050 by default, but can be changed). When it is registering for events, it sends the request over that connection. The server opens another connection at some random port (4012 for example) and sends that port number to the client. The client then connects to that port.

[...]

When client registers for events, the server opens a random port (ex. 6023) and sends that info to the client. This is where the problem becomes evident: the client tries to connect to that port (6023) on the firewall (as it “sees” the firewall as a server). Since the port is completely random, there are certainly no forwarding rules for that port on the firewall, so connection is denied. Using this setup, there is no way to make it work, short of forwarding all the traffic (all ports) to Firebird server, which is the exact thing we wish to avoid by placing the firewall in front.