44

I have a VM with IP address 192.168.0.192 running postgreSQL.

If I specify

listen_addresses = '*'

then I can connect from another VM at 192.168.0.191 and from localhost.

But I can't seem to use a list to tell postgreSQL to use those two addresses. If I change listen_addresses to a list:

listen_addresses = '192.168.0.191, localhost'

then I can no longer connect from 192.168.0.191.

I notice that almost all examples on stackexchange set listen_addresses to '*'. Is this because the list form does not work?

zabouti
  • 543
  • 1
  • 4
  • 4

4 Answers4

63

Yes, listen_addresses can be set to a list of addresses on the local host to bind to for listening.

In your example:

listen_addresses = '192.168.0.191, localhost'

If the local machine has IP 192.168.0.192, you should specify that IP, not the remote host 192.168.0.191 IP. PostgreSQL cannot bind to the IP address of a remote host.

You're not saying "who is allowed to connect", you're saying "which interfaces should PostgreSQL accept connections on". The "who's allowed to connect" bit is next, and is configured in pg_hba.conf.

So: Try '192.168.0.192, localhost'. Or just *, since you probably actually want to listen on all network interfaces.

Craig Ringer
  • 56,343
  • 5
  • 158
  • 190
  • 1
    It works. So is there any practical difference between the list and '*'? – zabouti Aug 20 '13 at 03:37
  • 14
    @zabouti Sure. If your server has (say) two external network interfaces, you can tell PostgreSQL to only bind on one of them, so it's not even possible to make a TCP connection to Pg on the other. It's mostly an extra level of security for a system that has multiple interfaces to different security domains. Quite handy in combination with VLANs, virtual switches, etc. The most common use is setting it to localhost so that TCP/IP connections are not possible from any external network interface, only the loopback address. – Craig Ringer Aug 20 '13 at 04:03
  • 1
    @CraigRinger: a very good answer! – francs Feb 25 '14 at 05:27
  • @CraigRinger you should add those comments to your answer. That's very useful information. – João Portela Dec 18 '14 at 10:57
  • 1
    Yeah I think the comment might be even better than the answer. Rock on Craig! – Darth Egregious Oct 07 '15 at 18:58
  • Also, you need to restart postgresql after changing listen_addresses. – mivk Sep 09 '17 at 16:09
  • hmm, why this not works to me, when I add some another host or IP ? only * works for me. Postgre12 – andrew Oct 29 '22 at 20:52
6

I've found that instead of using localhost it needs to be 127.0.0.1 if you're specifying any other addresses as well.

So in my case of listening on the Docker host IP address as well as localhost, but not the external IP, this doesn't work (I get a connection refused from inside my Docker containers):

listen_addresses = '172.17.0.1, localhost'

But this does:

listen_addresses = '172.17.0.1, 127.0.0.1'
VirtualWolf
  • 61
  • 1
  • 4
1

The entry 0.0.0.0 allows listening for all IPv4 addresses and :: allows listening for all IPv6 addresses. If the list is empty, the server does not listen on any IP interface at all, in which case only Unix-domain sockets can be used to connect to it.

walid redwan
  • 11
  • 1
0

For security reason we need to add IP addresses that will be bound to the socket.

For example, when we use 'localhost' we will bind two addresses 127.0.0.1 and ::1 both are the loopback addresses for IPv4 and IPv6, respectively. Therefore, the postgresql service will be available in the localhost.

But, Teo if I want to connect to this service remotely from the same network or from an external network?

In that case, we need to add our ip that has access to those networks. Usually the IP of our main interface. For example, if your interface enp2s0 has the inet 192.168.0.20 then we can configure the postgresql.conf like this:

listen_addresses = '192.168.0.20, 127.0.0.1'

This configuration will support IPv4, if you also need to support IPv6, then add the inet6 of your main interface.

So, to summarize, listen_addresses controls which interfaces accept connection attempts. This help prevent repeated malicious connection requests on insecure network interfaces.

Teocci
  • 101
  • 2