On Sun, Oct 18, 2026 at 06:55:17PM +0200, Kusalananda Kähäri wrote: > On Sun, Oct 18, 2026 at 12:13:57PM -0400, Greg Troxel wrote: > > Matti Andreas Kähäri <[email protected]> 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
Just a tiny data point: Setting the MTU to osmething slightly lower than 1280, for example 1200, on the tun0 interface in NetBSD seems to avoid the issue. I don't really see this as a "solution". It's a work-around. Andreas
