connection rejected by remote interface when trying to connect over obdc administrator

[Markus Baldasty]

Basically having the following issue:

The firebird database is located on a remote windows server. The client configured in a way that we target the IP Address  + port of the router and then get forwarded to the correct address + port. Upon trying to connect we get the following error "connection rejected by remote interface".

As I tried to do that with PHP PDO before and was under the impression it could be on php end I tried it via the windows ODBC Data Source Administrator. Same issue.

I set up a test environment between two windows pcs in our own intranet and enabled port forwarding on them to replicate the forward: it works without issues (one runs firebird 3.0 the other one firebird 4.0, both 64 bit).

We connected to the pc in question over teamviewer to investigate. The firebird instance there is also the 3.0. Everything seems to be identical.
Upon researching I found the following SO thread: https://stackoverflow.com/questions/70168293/trying-to-connect-to-firebird-4-0-from-remote-always-generate-error-connection.

I updated the firebird config accordingly by setting 
AuthServer=Srp256,Srp,Legacy_auth

AuthClient=Srp256,Srp,Legacy_auth

UserManager=Srp,Legacy_UserManager

WireCrypt=Enabled

The pc got restarted then, sadly we are still facing the same issue there.

Yes, the address we target seems to be correct. Upon changing the port / address we get the error that establishing a connection failed.

Anybody got any ideas?

[Dimitry Sibiryakov]

'Markus Baldasty' via firebird-support wrote 16.11.2022 14:03:
> Yes, the address we target seems to be correct. Upon changing the port / address
> we get the error that establishing a connection failed.
>
> Anybody got any ideas?

If you have access to a Linux box you can use traceroute, nmap or
tcptraceroute utilities to trace blocking host.
Perhaps this thread also can help:
https://serverfault.com/questions/49235/traceroute-tcp-equivalent-for-windows

--
WBR, SD.

[Markus Baldasty]

Hmm, not quite sure what I have gained from that :D
We mainly use macs, so I could run that quickly.

nmap -Pn --traceroute -p *endport* *ipaddress*

resolves to the *ipaddress* within 10 hops in roughly 4 seconds, so that seems to be ok. 

[Dimitry Sibiryakov]

'Markus Baldasty' via firebird-support wrote 16.11.2022 14:34:
> We mainly use macs, so I could run that quickly.
>
> nmap -Pn --traceroute -p *endport* *ipaddress*
>
> resolves to the *ipaddress* within 10 hops in roughly 4 seconds, so that seems
> to be ok.

In this case you can rule out firewall and network issues and check
firebird.log on server as well as the real version of used Firebird client.
Use isql for test, it can cut off ODBC and PDO issues.

--
WBR, SD.

[Markus Baldasty]

log dont have anything of significance in it, some errors that are not related to the connection attempt (thrown by internal ips).
By client version you mean the fbclient.dll file version?

isql you mean trying to connect from our pc to the remote database?

[Dimitry Sibiryakov]

'Markus Baldasty' via firebird-support wrote 16.11.2022 15:16:
> By client version you mean the fbclient.dll file version?

Yes. And it is better to look at it when it really loaded into application
using ProcessExplorer.

> isql you mean trying to connect from our pc to the remote database?

Yes. Isql is better for tests because it is guaranteed to use native Firebird
library and has handy SHOW VERSION command.

--
WBR, SD.

[Markus Baldasty]

hmmm. from centos using isql I am not sure if i am doing sth wrong or if it fails on the connection.

isql serverIp:Port username password.

is that setup correct? Because it seems I cant find an example with a port

[Dimitry Sibiryakov]

'Markus Baldasty' via firebird-support wrote 16.11.2022 15:24:
> from centos using isql I am not sure if i am doing sth wrong or if it fails on
> the connection.
>
> isql serverIp:Port username password.
>
> is that setup correct? Because it seems I cant find an example with a port

No. It completely different from what is described in Firebird Quick Start
Guide. Perhaps you mixed up Firebird's isql and ODBC's isql. Unfortunately these
utilities has the same name.

--
WBR, SD.

[Markus Baldasty]

Are we talking about using the firebird isql now or the odbc one? :D
I am confused right now

[Dimitry Sibiryakov]

'Markus Baldasty' via firebird-support wrote 16.11.2022 15:31:
> Are we talking about using the firebird isql now or the odbc one? :D
> I am confused right now

When you diagnose Firebird connection issues you must use Firebird's isql
first. And only if it works well you can go further testing other tools: ODBC,
PDO, etc.

--
WBR, SD.

[Markus Baldasty]

got it.
And got "Statement failed. SQLSTATE = 08004 connection rejected by remote interface"

[Markus Baldasty]

I try to get access over teamview atm but can this really be down due to differentiating fbclient versions? from 3.0.8 to 3.0.10 like used in our experimental setup there were no issues

[Dimitry Sibiryakov]

'Markus Baldasty' via firebird-support wrote 16.11.2022 16:08:
> I try to get access over teamview atm but can this really be down due to
> differentiating fbclient versions? from 3.0.8 to 3.0.10 like used in our
> experimental setup there were no issues

As Mark already said, the error can be raised if client and server has
incompatible wire encryption or auth plugin settings. Between 3.0.8 and 3.0.10
perhaps Srp was deprecated in favor of Srp256 and in any case client of version
2.5 (if occasionally found) cannot do Srp at all.

--
WBR, SD.

[Markus Baldasty]

So, back with some new informations:
ISQL Version: WI-V3.0.8.33535 Firebird 3.0
Server version:
Firebird/Windows/AMD/Intel/x64 (access method), version "WI-V3.0.8.33535 Firebird 3.0"
Firebird/Windows/AMD/Intel/x64 (remote server), version "WI-V3.0.8.33535 Firebird 3.0/tcp (terminal)/P15:C"
Firebird/Windows/AMD/Intel/x64 (remote interface), version "WI-V3.0.8.33415 Firebird 3.0 HQbird/tcp (terminal)/P15:C"
on disk structure version 12.0

is the output of firebird isql show versions command.
Out of curiosity I pulled the database in question to or local setup: it works.

Another thing that comes to mind:
We connect to the remote server over an ip and port, that server / router (whatever you want to call it) then forwards to correct internal ip + port.
Is it possible the internal firewall filters some relevant packages?

[Dimitry Sibiryakov]

'Markus Baldasty' via firebird-support wrote 17.11.2022 11:06:
> ISQL Version: WI-V3.0.8.33535 Firebird 3.0
> Server version:
> Firebird/Windows/AMD/Intel/x64 (access method), version "WI-V3.0.8.33535
> Firebird 3.0"
> Firebird/Windows/AMD/Intel/x64 (remote server), version "WI-V3.0.8.33535
> Firebird 3.0/tcp (terminal)/P15:C"
> Firebird/Windows/AMD/Intel/x64 (remote interface), version "WI-V3.0.8.33415
> Firebird 3.0 HQbird/tcp (terminal)/P15:C"
> on disk structure version 12.0
>
> is the output of firebird isql show versions command.

So isql is connected successfully. BTW, you didn't mention that you used
client from HQBird. It may make difference.

--
WBR, SD.

[Mark Rotteveel]

On 16-11-2022 14:03, 'Markus Baldasty' via firebird-support wrote:
> Yes, the address we target seems to be correct. Upon changing the port /
> address we get the error that establishing a connection failed.
>
> Anybody got any ideas?

What is the exact connection string your using from PDO? And are you
using PDO Firebird or PDO ODBC?

Mark

--
Mark Rotteveel

[Markus Baldasty]

Didnt know that until as well until now.
That is why it fails I guess?
As my knowledge about firebird is... very limited. :D

[Dimitry Sibiryakov]

'Markus Baldasty' via firebird-support wrote 17.11.2022 11:44:
> Didnt know that until as well until now.

You didn't know what you installed?..

> That is why it fails I guess?

I don't know what modifications are made in HQBird for auth settings. It is
possible that they raised defaults to Srp256 for security reason while
problematic server is limited to Srp.

--
WBR, SD.

[marblsy]

Just to clarify it (because I am lost right now):
It is still possible to connect via the normal firebird driver from our end to the firebird database that is installed on the remote server even if they use HQBird, right?

Regarding your answer: Wouldnt that mean that they cant log on themselves anymore as well? Because that works (when I log on to their windows instance via teamviewer and connect to the db with ODBC Data Resource it get a successful connection as well).

Can I configure our end in some way to allow the connection?

[Dimitry Sibiryakov]

'marblsy' via firebird-support wrote 17.11.2022 11:59:
> It is still possible to connect via the normal firebird driver from our end to
> the firebird database that is installed on the remote server even if they use
> HQBird, right?

Dunno. Ask HQBird support.

> Regarding your answer: Wouldnt that mean that they cant log on themselves
> anymore as well? Because that works (when I log on to their windows instance via
> teamviewer and connect to the db with ODBC Data Resource it get a successful
> connection as well).

If they use HQBird client with HQBird server, why they wouldn't be able to
connect?

--
WBR, SD.

[marblsy]

yep, last part makes sense :D Thanks for the help