Specs
Server
- Environment: FreeBSD (FreeNAS Jail)
- Postgresql version: 9.4
- Listening_address: '*'
- Listening_port: 8096
- pg_hba.conf entry: host all all 0.0.0.0/0 md5
Client
- Environment: Linux Ubuntu 16.0.4 LTS
- Postgresql version: 9.6
Issue
I am trying to host my company's database on a server which can be accessed by employees remotely. The employee environments will vary between Linux flavors and Windows. My test environment is with a Linux client. So far, I have been unable to successfully connect the client to the server.
What I've Tried
I created a postgresql password file, ".pgpass" with the pertinent information entered in the format host:port:database:username:password
.
When I runpsql -h host -p port -U username database
from the client, I receive a timeout error. However, when I run the same command on the server, it prompts me for my password and I am connected to my database.
Questions
What am I doing wrong here? Am I missing a step, or is there an issue with the different versions of postgresql? Does the problem lie in the difference between the Linux and BSD environments?
--EDIT--
Exact Error Message
psql: could not connect to server: Connection timed out
Is the server running on host "host.domain.com" (###.###.###.###) and accepting
TCP/IP connections on port [port]?
pg_hba.conf
# TYPE DATABASE USER ADDRESS METHOD
# "local" is for Unix domain socket connections only
local all all trust
# IPv4 local connections:
host all all 127.0.0.1/32 trust
# IPv6 local connections:
host all all ::1/128 trust
# IPv4 remote connections:
host all all 0.0.0.0/0 md5
pg_hba.conf
file, with IP addresses masked. It sounds like you may be confused and thinking that.pgpass
is server-side configuration. It is not. It is a saved-password file for the client.psql
command line with the addition of-W
which created a password prompt. After entering the password, the result is the same; the connection times out. The server is listening on the specified port.Connection refused
, and if the IP address was incorrect you should be gettingNo route to host
.Connection timed out
on the other hand indicates that the packets send to the server are silently lost without any error message being sent back with an error code. Possibly an administrator thought debugging network problems was too easy and configured a firewall to drop all error messages used for debugging. I would inspect a packet capture from both ends of the connection to find additional information.