Re: Getting "write: address family not supported by protocol family" when using Restic over Tailscale

To: Greg Troxel <gdt%lexort.com@localhost>
Subject: Re: Getting "write: address family not supported by protocol family" when using Restic over Tailscale
From: Matti Andreas Kähäri <andreas.kahari%abc.se@localhost>
Date: Sun, 18 Oct 2026 18:55:15 +0200

On Sun, Oct 18, 2026 at 12:13:57PM -0400, Greg Troxel wrote:
> Matti Andreas Kähäri <andreas.kahari%abc.se@localhost> writes:
> 
> > This is the network configuration for the guests as seen with "virsh
> > net-edit default":
> >
> > <network>
> >   <name>default</name>
> >   <uuid>9aee69db-b83c-4d96-9f79-1155b3a71030</uuid>
> >   <forward mode='nat'/>
> >   <bridge name='virbr0' stp='on' delay='0'/>
> >   <mac address='52:54:00:ce:24:79'/>
> >   <ip address='192.168.122.1' netmask='255.255.255.0'>
> >     <dhcp>
> >       <range start='192.168.122.100' end='192.168.122.200'/>
> >     </dhcp>
> >   </ip>
> > </network>
> >
> > What else can I tell you?  I have most centainly failed (not declined)
> > to undrestand, so please enlighten me about what further info I should
> > supply, and how.
> 
> Run ifconfig on the guest, and on the host.  There are (at least) two
> ways to provide networking to guests.  One is to bridge the guests
> (virtual) network interface to the (real) network interface of the host.
> Then the guest appears to be on the same LAN segment as the host, probably
> gets an address from the same DHCP sever, probably uses the same router,
> etc.
> 
> The other approach is to make the host a router, and to do
> forwarding/nat and maybe firewall.
> 
> I'm not familiar with KVM specifically and more importantly the
> management practices surrounding it; I mostly use Xen.   But reading
> your xml, it says "nat" and there's an address 192.168.122.1 which is
> probably for the hosts virtual interface that's on the same virtual
> ethernet as the guest, and probably the guest does DHCP to a server on
> the host and gets an address within 100-200.

I believe that's how it works, yes.

> Using ifconfig, or however Linux spells that, will tell you what
> interfaces there are and what addresses are on them.
> 
> This is probably not your problem, but I think it's always good to
> understand your network topology.

The default libvirt network is NAT: virbr0 on the host is 192.168.122.1:

$ ifconfig virbr0
virbr0    Link encap:Ethernet  HWaddr 52:54:00:CE:24:79
          inet addr:192.168.122.1  Bcast:192.168.122.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:15864743 errors:0 dropped:0 overruns:0 frame:0
          TX packets:20216576 errors:0 dropped:14 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:10945398326 (10.1 GiB)  TX bytes:34680245425 (32.2 GiB)

On the NetBSD guest:

eeyore% ifconfig
wm0: flags=0x8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
        capabilities=0x2bf80<TSO4,IP4CSUM_Rx,IP4CSUM_Tx,TCP4CSUM_Rx>
        capabilities=0x2bf80<TCP4CSUM_Tx,UDP4CSUM_Rx,UDP4CSUM_Tx,TCP6CSUM_Tx>
        capabilities=0x2bf80<UDP6CSUM_Tx>
        enabled=0
        ec_capabilities=0x7<VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU>
        ec_enabled=0x2<VLAN_HWTAGGING>
        address: 52:54:00:b3:bf:04
        media: Ethernet autoselect (1000baseT full-duplex)
        status: active
        inet6 fe80::5054:ff:feb3:bf04%wm0/64 flags 0 scopeid 0x1
        inet 192.168.122.132/24 broadcast 192.168.122.255 flags 0
lo0: flags=0x8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 33624
        status: active
        inet6 ::1/128 flags 0x20<NODAD>
        inet6 fe80::1%lo0/64 flags 0 scopeid 0x2
        inet 127.0.0.1/8 flags 0
tun0: flags=0x51<UP,POINTOPOINT,RUNNING> mtu 1280
        status: active
        inet6 fd7a:115c:a1e0::b831:4b3d/48 ->  flags 0
        inet 100.119.75.59/32 ->  flags 0

> 
> >> > eeyore% tailscale ping disco                                     
> >> > pong from disco (100.102.136.126) via XXX.255.241.178:14032 in 5ms  
> >> >
> >> > Here, eeyore is the NetBSD system, and disco is the NAS,
> >> > "XXX.255.241.178" is the visible IP of my home router, but since I'm
> >> > behind a CG-NAT, I see a 100-something address on my router's actual WAN
> >> > interface.
> >> 
> >> But not "ping", only "tailscale ping", which implies that your routing
> >> tables aren't set up right, and there is some tailscale wrapper that is
> >> [speculating now] doing some LD_PRELOAD of libc to replace the
> >> networking syscall functions with somethingelse.
> >
> > Sure, I can ping:
> >
> > eeyore% ping -c 4 disco
> > PING disco.my-ts-domain.ts.net (100.102.136.126): 56 data bytes
> > 64 bytes from 100.102.136.126: icmp_seq=0 ttl=64 time=6.108598 ms
> > 64 bytes from 100.102.136.126: icmp_seq=1 ttl=64 time=6.227608 ms
> > 64 bytes from 100.102.136.126: icmp_seq=2 ttl=64 time=5.782858 ms
> > 64 bytes from 100.102.136.126: icmp_seq=3 ttl=64 time=5.395658 ms
> >
> > ----disco.my-ts-domain.ts.net PING Statistics----
> > 4 packets transmitted, 4 packets received, 0.0% packet loss
> > round-trip min/avg/max/stddev = 5.395658/5.878680/6.227608/0.372874 ms
> 
> Is that going through tailscale, or not?   In a normal VPN, there's a
> route into a VPN interface for things reachable via the VPN.  tailscale
> appears to have a different plan?
> 
> traceroute will likely shed light on this.

Tailscale in-kernel tun mode is a normal VPN with a normal route.
("tailscale ping" is a separate thing: it probes at the Tailscale layer
to show whether the path is direct or relayed, which is why I used it.)

eyore% netstat -rn -f inet
Routing tables

Internet:
Destination        Gateway            Flags    Refs      Use    Mtu Interface
default            192.168.122.1      UG          -        -      -  wm0
100.77.195.15      100.119.75.59      UHS         -        -      -  tun0
100.79.217.34      100.119.75.59      UHS         -        -      -  tun0
100.83.76.79       100.119.75.59      UHS         -        -      -  tun0
100.100.100.100    100.119.75.59      UHS         -        -      -  tun0
100.102.136.126    100.119.75.59      UHS         -        -      -  tun0
100.108.126.65     100.119.75.59      UHS         -        -      -  tun0
100.119.75.59      127.0.0.1          UGHS        -        -  33624  lo0
100.120.131.84     100.119.75.59      UHS         -        -      -  tun0
100.124.10.43      100.119.75.59      UHS         -        -      -  tun0
100.126.220.114    100.119.75.59      UHS         -        -      -  tun0
127/8              127.0.0.1          UGRS        -        -  33624  lo0
127.0.0.1          lo0                UHl         -        -  33624  lo0
192.168.122/24     link#1             UC          -        -      -  wm0
192.168.122.132    link#1             UHl         -        -      -  lo0
192.168.122.1      52:54:00:ce:24:79  UHL         -        -      -  wm0

eeyore% route get 100.102.136.126
   route to: disco
destination: disco
 local addr: eeyore
  interface: tun0
      flags: 0x845<UP,HOST,DONE,STATIC>
 recvpipe  sendpipe  ssthresh  rtt,msec    rttvar  hopcount      mtu     expire
       0         0         0         0         0         0         0         0 

eeyore% traceroute -I 100.102.136.126
traceroute to 100.102.136.126 (100.102.136.126), 64 hops max, 40 byte packets
 1  disco (100.102.136.126)  59.473 ms  5.571 ms  5.499 ms

> >> > I found a similar report from April in the pkgsrc-users list:
> >> > https://mail-index.netbsd.org/pkgsrc-users/2026/04/28/msg042883.html
> >> >
> >> > There, it was rsync, not restic, that triggered the error.
> >> 
> >> Gueesing, this is probably a bug in tailscale.
> >
> > Possibly, or in Go on NetBSD.
> 
> Fair point, likelihood hard to assess.
> 
> >> > I can actually see some 500 (Internal Server Error) responses, and
> >> > looking at the NAS logs, these corresponds to errors saying "Post
> >> > request put error: unexpected EOF" (and the same, but with "rcat error"
> >> > in place of "put error").
> >> >
> >> > It's "rclone serve restic" listening on the NAS.
> >> 
> >> Is it run under tailscale, or does tailscale work differently there?
> >
> > On the NAS, Tailscale is running.  The rclone service listens to all
> > available addresses of the system, including the Tailscale addresses.
> 
> "tailscale addresses" means what?  Is there some part of RFC1918 address
> space assigned (in your setup) to tailscale?  Do they work with real
> syscalls, and no wrappers?  Why is that different on your netbsd kvm
> guest?

Tailscale hands out addresses from 100.64.0.0/10, the CG-NAT range, and
that is the 100.x.y.z address I mean by "Tailscale addresses". Every
node gets one on a virtual interface (tailscale0 on the Linux NAS, I
believe), and the rclone server binds to all addresses on the machine,
including that one.  Nothing "runs under Tailscale". Tailscale
provides a VPN (a tun interface plus routes), and programs like rclone
just use it through normal sockets, with no wrapper involved. (There is
a userspace-networking mode where that isn't the case, but I'm not
using it, since plain ping and routing work as usual.)

The failure shows up with large uploads, and the symptoms (unexpected
EOF on the server, 500 errors) look like a connection being cut
mid-transfer, so MTU/MSS is my next suspect.  Tailscale's tun MTU is
1280, and the path from the guest through NAT adds another layer.

... but will have leave this here for now and power down my NetBSD
experiment until next weekend.

Take care,
Andreas

Follow-Ups:
- Re: Getting "write: address family not supported by protocol family" when using Restic over Tailscale
  - From: Matti Andreas Kähäri

References:
- Getting "write: address family not supported by protocol family" when using Restic over Tailscale
  - From: Andreas Kähäri
- Re: Getting "write: address family not supported by protocol family" when using Restic over Tailscale
  - From: Greg Troxel
- Re: Getting "write: address family not supported by protocol family" when using Restic over Tailscale
  - From: Chavdar Ivanov
- Re: Getting "write: address family not supported by protocol family" when using Restic over Tailscale
  - From: Matti Andreas Kähäri
- Re: Getting "write: address family not supported by protocol family" when using Restic over Tailscale
  - From: Greg Troxel
- Re: Getting "write: address family not supported by protocol family" when using Restic over Tailscale
  - From: Matti Andreas Kähäri
- Re: Getting "write: address family not supported by protocol family" when using Restic over Tailscale
  - From: Greg Troxel

Prev by Date: Re: Getting "write: address family not supported by protocol family" when using Restic over Tailscale
Next by Date: Re: Getting "write: address family not supported by protocol family" when using Restic over Tailscale
Previous by Thread: Re: Getting "write: address family not supported by protocol family" when using Restic over Tailscale
Next by Thread: Re: Getting "write: address family not supported by protocol family" when using Restic over Tailscale
Indexes:

Home | Main Index | Thread Index | Old Index