adding ipv6 causing client access to be unreliable?

[Brock Palen]

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)]

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]

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.