Skip to main content
Question

SSL connection - Failed to connect to [::1]:5432


Marcel.K
Forum|alt.badge.img+11

Hello,

i would like to ask, if somebody is not experiencing that issue, that big environments have issue with SSL connection?

 

we have all in one boxes - VBR, VEM and postgresql is on the same machine

 

at the end of postgresql.conf

 

#------------------------------------------------------------------------------
# CUSTOMIZED OPTIONS
#------------------------------------------------------------------------------

# Add settings for extensions here

ssl = on
ssl_cert_file = 'backup_server.crt'
ssl_key_file = 'backup_server.key'
ssl_ca_file = 'backup_root.crt'

 

in svc_veeambackup.log we see

[02.03.2026 11:40:10.307]    <35>   Error (3)    0: Breaking connector
[02.03.2026 11:40:10.307]    <35> Warning (3)    Failed to obtain connection: [Failed to connect to [::1]:5432]. Attempt 1 of 20.

 

in pg_hba.conf is preferred connextion via ssl

# IPv4 local connections:
hostssl    all             all             127.0.0.1/32            scram-sha-256
host    all             all             127.0.0.1/32            scram-sha-256

 

db=[unknown],user=[unknown],app=[unknown],client=backup-server LOG:  connection received: host=backup port=49486
db=[unknown],user=[unknown],app=[unknown],client=backup-server LOG:  could not accept SSL connection: An established connection was aborted by the software in your host machine.

any experience, why SSL connection is broken?

 

certificates are fine

antivirus excluded from veeam app and postgresql

 

 

10 comments

lukas.k
Forum|alt.badge.img+13
  • Influencer
  • March 2, 2026

Hi ​@Marcel.K,

Are all the Veeam services running? If yes, have you tried to restart the server and see if that helps?

 

That would be the easiest approaches but I’d recommend opening a Veeam support ticket on that to get a proper technical advice.

 

Just some personal note: Since VBEM is used for key restores I’d not recommend that on the same machine as VBR.

 

Best

Lukas


Marcel.K
Forum|alt.badge.img+11
  • Author
  • Veeam Legend
  • March 2, 2026

@lukas.k yes, all veeam services are running and postgresql as well

so Veeam One is not detecting, that is down

after reboot everything is fine, but in few days is down again

my interested point is, that how SSL to database is managing Veeam


Chris.Childerhose
Forum|alt.badge.img+21

If all services are running and you tried rebooting I would contact support as Lukas said.  They will get to the bottom of this quicker for you.


HangTen416
Forum|alt.badge.img+11
  • Influencer
  • March 2, 2026

I may be wrong but it looks like this shows it’s trying to connect using IPv6 so maybe try disabling that and see if it can connect using IPv4?

[02.03.2026 11:40:10.307]    <35> Warning (3)    Failed to obtain connection: [Failed to connect to [::1]:5432]. Attempt 1 of 20.


Chris.Childerhose
Forum|alt.badge.img+21

I may be wrong but it looks like this shows it’s trying to connect using IPv6 so maybe try disabling that and see if it can connect using IPv4?

[02.03.2026 11:40:10.307]    <35> Warning (3)    Failed to obtain connection: [Failed to connect to [::1]:5432]. Attempt 1 of 20.

Good catch on that one, as the PG_HBA conf file above shows IPv4 only.

 
 
 

Marcel.K
Forum|alt.badge.img+11
  • Author
  • Veeam Legend
  • March 2, 2026

Ou, wow ​@HangTen416 

I will try. Many thanks!


Marcel.K
Forum|alt.badge.img+11
  • Author
  • Veeam Legend
  • March 6, 2026

It did not help, I am still trying to figure out ...


eblack
Forum|alt.badge.img
  • Experienced User
  • March 9, 2026

Hi @Marcel.K,

Since disabling IPv6 on the network adapter didn't permanently resolve the issue, Windows might still be prioritizing ::1 for localhost resolution under the hood, or there is a TCP timeout/teardown occurring after a few days of uptime.

Here are a few steps you can take to force the routing and stabilize the connection:

  • Force IPv4 in Veeam DB Config: Run the Veeam Database Configuration Utility (Veeam.Backup.DBConfig.exe) and explicitly set your database server to 127.0.0.1 instead of localhost or the server hostname. This completely bypasses the Windows DNS resolution for localhost and stops Veeam from even attempting the [::1] connection.

  • Add IPv6 Rules to pg_hba.conf: Even if you intend to use IPv4, add the IPv6 loopback rules to your configuration. If Veeam momentarily attempts an IPv6 handshake, this prevents PostgreSQL from rejecting it immediately. hostssl all all ::1/128 scram-sha-256 host all all ::1/128 scram-sha-256

  • Check listen_addresses: In your postgresql.conf, ensure listen_addresses is set to * rather than just localhost to ensure it actively binds to all available IP protocols.

Hope this helps track it down!


Marcel.K
Forum|alt.badge.img+11
  • Author
  • Veeam Legend
  • March 9, 2026

Hi ​@eblack 

thanks for the hints, i really appreciated 

  1. connection change from localhost to loopback
  2. my pg_hba.conf looks now

# IPv4 local connections:
host    all             all             127.0.0.1/32            scram-sha-256
hostssl    all             all             127.0.0.1/32            scram-sha-256
# IPv6 local connections:
host    all             all             ::1/128                 scram-sha-256
hostssl    all             all             ::1/128                 scram-sha-256

  1. i have change back from localhost,hostname to *

lets see at next day :)

 

in point 2 it should be first hostssl?


eblack
Forum|alt.badge.img
  • Experienced User
  • March 9, 2026

Hi ​@eblack 

thanks for the hints, i really appreciated 

  1. connection change from localhost to loopback
  2. my pg_hba.conf looks now

# IPv4 local connections:
host    all             all             127.0.0.1/32            scram-sha-256
hostssl    all             all             127.0.0.1/32            scram-sha-256
# IPv6 local connections:
host    all             all             ::1/128                 scram-sha-256
hostssl    all             all             ::1/128                 scram-sha-256

  1. i have change back from localhost,hostname to *

lets see at next day :)

 

in point 2 it should be first hostssl?

Yes, hostssl should be first. Post reads sequentially from top to bottom and applies the first rule that matches the connection attempt.