adding ipv6 causing client access to be unreliable?

38 views
Skip to first unread message

Brock Palen

unread,
Jan 3, 2026, 5:29:36 PMJan 3
to bareos-users
We were modernizing some and rolling out ipv6
The bareos server always had ipv6 but it was not part of DNS nor allowed through the firewall.

After adding it to DNS and opening up the firewall clients that connect directly over the wan (not over the VPN or local network) all use client initiated connections.

They should show up even trigger backups but if you do:

status client=<client>

A large fraction would fail and drop the connection and come back later.

Telling bareos director to only listen on ipv4 things started working again.

I’m guessing I have created some sort of resolution/routing loop, and were actaully ok with ipv4 just more curious as rolling out ipv6 for our mail and everything else has been a learning experience.


Brock Palen
bro...@mlds-networks.com
www.mlds-networks.com
Websites, Linux, Hosting, Joomla, Consulting



Bruno Friedmann (bruno-at-bareos)

unread,
Jan 5, 2026, 3:24:04 AMJan 5
to bareos-users
Hi, Just for information, I'm  using ipv6 since years (>5) here on my network, and I've started 2 years ago to only use ipv6 for the backup, so bareos here is using 100% of the time ipv6.
So for most of the task it works well, but I don't use the client initiated feature.

I might give it a try next week-end ...

Brock Palen

unread,
Jan 29, 2026, 3:48:39 PMJan 29
to Bruno Friedmann (bruno-at-bareos), bareos-users
So opening this back up, I don’t think it’s IPv6 related at all.

I have disabled ipv6 for the director and storage. I have confirmed they are not listening using netstat I also removed the AAAA DNS record for the server.

Clients using configs like:
Client {
Name = sue-hp-touch-fd
FDport = 9102
Address = 192.168.10.6
#Address = 192.168.67.21
Catalog = myth_catalog
Password = “<snip>"
Connection From Client To Director = yes
Heartbeat Interval = 60
}



setdebug level=1000 trace=1 dir

I’m getting errors like:
myth-dir (500): lib/crypto_openssl.cc:1544-0 SSL_get_error() returned want-read
myth-dir (500): lib/crypto_openssl.cc:1544-0 SSL_get_error() returned want-read
myth-dir (500): lib/crypto_openssl.cc:1544-0 SSL_get_error() returned want-read
myth-dir (800): dird/job.cc:732-0 JobMonitorWatchdog 0x565b9f0369e0 called

When I do

status client=<client>

For clients that use client initiated connection. Ironically their jobs still run, but status fails and just hangs, and I have to break out of bconsole using Ctl+C

I have been using this for years I have tried giving the client a valid IP on the local network (even though that’s not the hots address) and random addreses. Behavior is the same.

Machines that don’t use this or are on the same local LAN work fine. It’s only the road warriors. It’s more annoying but I don’t htink it’s expected behavior.

Details:
*status client=sue-hp-touch-fd
Connecting to Client sue-hp-touch-fd at 192.168.10.6:9102
Probing client protocol... (result will be saved until config reload)
Handshake: Immediate TLS, Encryption: TLS_CHACHA20_POLY1305_SHA256 TLSv1.3

<hang>




Brock Palen
bro...@mlds-networks.com
www.mlds-networks.com
Websites, Linux, Hosting, Joomla, Consulting



> --
> You received this message because you are subscribed to the Google Groups "bareos-users" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to bareos-users...@googlegroups.com.
> To view this discussion visit https://groups.google.com/d/msgid/bareos-users/f45c79ae-c09e-477d-983f-525fad705cb9n%40googlegroups.com.


Bruno Friedmann (bruno-at-bareos)

unread,
Feb 4, 2026, 10:51:59 AM (9 days ago) Feb 4
to bareos-users
Hi Brock,

We use that feature all the time here to backup remote worker, and it works. But beware only when there's no jobs running, (otherwise it would need another connection which doesn't exists).
Would that make sense in your case ?

Brock Palen

unread,
Feb 5, 2026, 2:57:17 PM (8 days ago) Feb 5
to Bruno Friedmann (bruno-at-bareos), bareos-users
I have tried both clients with jobs already running and ones that don’t and the hang is reliable.

Up until recently I could check the status of any client initiated connection without issue. If this isn’t a problem for others this is a head scratcher about my site (other than enabling IPv6 on the WAN address of the NAT) what hange might have impacted baroes.


Brock Palen
bro...@mlds-networks.com
www.mlds-networks.com
Websites, Linux, Hosting, Joomla, Consulting



> To view this discussion visit https://groups.google.com/d/msgid/bareos-users/ddb950cf-fab8-4bba-8bd8-7becd4bac142n%40googlegroups.com.

Sebastian Sura

unread,
Feb 6, 2026, 2:45:15 AM (7 days ago) Feb 6
to bareos...@googlegroups.com
Do the clients show up when you do `status dir` ?

*status dir
...
Client Initiated Connections (waiting for jobs):
Connect time        Protocol            Authenticated  Name
====================================================================================================
06-Feb-26 08:40     54                  1  client-initiated-fd
====

If they do, you could try finding out what bareos thinks by starting the
client with debugging enabled, i.e.

bareos-fd -f -d1000

and see what it spits out when you try connecting via the director.  If
the connection does _not_ show up,
you can still do the same and check what the filed says when _it_ tries
to connect.
Similarly you can do
*setdebug dir trace=1 level=1000
To see what the director reports during the connection attempt. Let me
know if something interesting showed up.

Kind Regards
Sebastian Sura

Am 05.02.26 um 20:57 schrieb 'Brock Palen' via bareos-users:
--
Sebastian Sura sebasti...@bareos.com
Bareos GmbH & Co. KG Phone: +49 221 630693-0
https://www.bareos.com
Sitz der Gesellschaft: Köln | Amtsgericht Köln: HRA 29646
Komplementär: Bareos Verwaltungs-GmbH
Geschäftsführer: Stephan Dühr, Jörg Steffens, Philipp Storz

Brock Palen

unread,
Feb 7, 2026, 3:19:23 PM (6 days ago) Feb 7
to Sebastian Sura, bareos...@googlegroups.com
I can’t reliably create the issue on local clients (LAN)
But it’s almost 100% reliable on remote clients, I’ll schedule a time with one of remote people and setup a remote desktop session.


Brock Palen
bro...@mlds-networks.com
www.mlds-networks.com
Websites, Linux, Hosting, Joomla, Consulting



> To view this discussion visit https://groups.google.com/d/msgid/bareos-users/63e00a08-53a1-4062-932e-ee0b138596ad%40bareos.com.

Andreas Rogge

unread,
Feb 10, 2026, 10:54:04 AM (3 days ago) Feb 10
to bareos...@googlegroups.com
Hi Brock,

just a wild guess, but maybe your firewall times out the (idle) tcp
session and both sides (i.e. director and fd) think they are still
connected.
Do you have heartbeat enabled or your system's keepalive timeouts
reconfigured?

Am 07.02.26 um 21:19 schrieb 'Brock Palen' via bareos-users:
--
Andreas Rogge andrea...@bareos.com
Bareos GmbH & Co. KG Phone: +49 221-630693-86
http://www.bareos.com

Brock Palen

unread,
Feb 11, 2026, 5:05:47 PM (2 days ago) Feb 11
to Andreas Rogge, bareos...@googlegroups.com
Firewalll is simple it’s a asus consumer router. Been the same one for a while though I do keep the firmware up to date. But I think it is the router and the obvious issue all along. It’s just weird it’s happening now.

The client config on the director does have Heartbeat set:

Client {
Name = sue-hp-touch-fd
FDport = 9102
Address = 192.168.10.6
Catalog = myth_catalog
Password = “<snip>"
Connection From Client To Director = yes
Heartbeat Interval = 60
}

But it was not set on the clients in the myself.conf

These were all windows clients that worked for many years without issues and still run their normal jobs without issue,
Some are scheudled some use
Run On Incoming Connect Interval

All are still running their jobs. It’s funny though because if a client is idle and I know it’s online and status dir shows it connected, and I do ether:

run <job that runs fine on schedule>
estimate job=<job>

They also hang.


I noticed I was getting stuff stuck in mesage uses when looking at netstat

tcp 0 32 192.168.84.7:9101 <snip>:52371 ESTABLISHED

I looked in the NAT and mapped connections to port 9101 on the baroes server to ones that would work randomly, they had NAT entries the others did not. So it smells like what Hearbeat was setup for.

I did get access to 2 of the remote clients, and added

Heartbeat Interval = 60

To their myself.conf

and am going to see if those clients stay reliable.

If they do and the others don’t (they are not easy to get to update) I’ll try adjusting the TCP Establsihed timeout on the router which is set to 40 minutes to something much higher.

IDK if in a firmware update they adjusted that value or there was a bug so it wasn’t enforced. But I verified I was running this way for the last 3 years without major changes other than enable ipv6 (issue arose after enabling on the local network) and regular updates to the server.

I’ll keep an eye on it and report back so other may find this thread later.

Brock Palen
bro...@mlds-networks.com
www.mlds-networks.com
Websites, Linux, Hosting, Joomla, Consulting



> To view this discussion visit https://groups.google.com/d/msgid/bareos-users/5b3eabc9-bdb9-4069-9394-3c36e2171816%40bareos.com.

Reply all
Reply to author
Forward
0 new messages