Firebird 3 Wire Encryption and the VPN Are Two Boundaries

The VPN connects, the client opens a session, and everyone assumes the database connection is secured. Three different things just got conflated. Whether the listener is reachable at all, whether the server accepted the user, and whether Firebird negotiated wire encryption are separate mechanisms with separate evidence. A tunnel answers only the first one, and only for the sources you allowed.

Two boundaries, and they do not overlap

The VPN boundary protects packets between a client and a gateway. Firebird's wire encryption protects the database protocol between the client library and the server process. They can both be present, and neither one substitutes for the other.

If the tunnel terminates before the database host, the traffic beyond it is protected only by what the database session negotiated. That gap is where a review usually finds the surprise. The tunnel diagram ends at a gateway, and the connection carrying your query continues past it. Anyone reading that diagram later inherits the assumption.

Boundary one: who can open the listener

Identify the real server address and the configured port, which is 3050 unless it was changed, then permit only the approved VPN sources at the host and network firewalls. Account for any translation at the VPN gateway, and give the database host a return route to the client pool if the gateway is separate.

Then prove the negative. An external path that should be denied must still be denied, because opening the tunnel does not restrict the Firebird listener by itself.

Boundary two: what Firebird negotiates

Firebird 3 introduced a wire-encryption framework with a server policy that can be disabled, enabled or required. The policy sets the floor. The actual session still depends on the client library loaded by the application and the plugins both sides support.

The Firebird 3 release notes list Arc4 as the default wire-encryption plugin for that release. Arc4 is a historical default, not a modern cipher recommendation, and it is not the same thing as the outer VPN protection.

Authentication is a third variable in the same negotiation. The server accepts a set of authentication plugins, the client library offers some subset, and the two have to overlap.

The Legacy_Auth trap

Supporting Legacy_Auth requires relaxing the server's default required-encryption policy. That is the documented compatibility cost, and it is why turning the policy down to silence a connection error is a security change rather than a fix.

If a client suddenly fails after a server upgrade, compare plugin lists before weakening anything. The failure is usually a negotiation mismatch, and the answer is a supported plugin on both sides.

Check the attachment that matters

On a build that provides the context variable, this query reports the encryption state of the current attachment:

SELECT RDB$GET_CONTEXT('SYSTEM', 'WIRE_ENCRYPTED')
FROM RDB$DATABASE;

Run it through the application's own connection, not through an administrator session on the same server. An encrypted admin attachment says nothing about a different client library's session, and an older build that does not support the variable is not evidence that encryption is off.

Record the client library version, the server build and the result together, because any one of those alone is unreadable.

Grants and the upgrade path

Restricting sources and encrypting transport do not replace authentication or least-privilege grants. Check the ordinary database user's permissions on the objects it actually touches.

Finally, treat a long-lived deployment as a maintenance question. A tunnel does not make an obsolete client library safe indefinitely, and a supported upgrade path is cheaper than discovering that the plugin it needs was removed.