However I had some surprises after successfully configuring my first tunnel. Light traffic such as ping would go through without problem. But larger traffic such as rsync transfers or downloading/uploading files would hang endlessly.
At the remote side of the tunnel, I looked with tcpdump at the traffic out of the tun interface. Packets were going through, although packets with a large payload were apparently truncated:
truncated-ip6 - 4 bytes missing truncated-ip - 4 bytes missing
Indeed large packets were 4 bytes shorter than intended both for IPv4 and IPv6 traffic. This sounded a lot like some kind of MTU mismatch in the tunnel itself. Still, both sides of the tunnel were configured with the same MTU. Also, Fastd ensures that both sides use the same MTU during the tunnel creation.
So what is it? I don’t know. I did not investigate further. But I’ve found a workaround.
Once the tunnel is created, I simply reduce the MTU on the entry/client side interface of the tunnel of 4B. That is in the establish script:
mtu=$(("$INTERFACE_MTU" - 4)) ifconfig "$INTERFACE" mtu "$mtu"
That’s still weird though. So I’d like to find some definitive answer as to why this is happening.