On 2023-01-04, Lars Bonnesen <lars.bonne...@gmail.com> wrote: > Thanks for your replies. It has been Xmas and I have been delayed, but I > have now read up upon it. I am going for the tpmr(4). We are going to > replicate a lot of live data from Site1 to Site2, and my experiences with > OpenVPN is that it is great, but not high performing. So I have established > a WireGuard connection with one OBSD on each site, and I am planning to > tunnel tpmr through this - I guess that tpmr itself is not encrypted in any > way?
Trying to give an idea of how it fits together as from this I think you're missing one piece. tpmr(4) itself is a special type of bridge device; you add two layer2 (ethernet-like) interfaces to it and it shuffles network frames between them. So there's no *concept* of encryption in tpmr(4), it isn't at that layer of processing. wg(4) is a layer3 type of interface, not layer2, you can't attach it directly to tpmr. For your use-case you need a layer2 tunnel interface, for example egre(4), etherip(4), eoip(4) etc. [Choosing between them: If you only have one such tunnel between a pair of IP addresses then etherip is sufficient. If you have multiple (say, several ethernet segments via individual eth-tpmr-tunnel combinations) then you'll need one of the other types which also has a tunnel id to distinguish them; packet size overheads are slightly higher for those.] That tunnel interface is configured with endpoint IP addresses. Those can either be normal externally routable addresses (either unencrypted or protected by IPsec in 'transport' mode i.e. each packet just has the encr/auth overhead and not an extra IP header), *or* you can use internal addresses provided by a separate VPN tunnel (wg, openvpn, IPsec in 'tunnel' mode, ...); the latter will likely have more bytes overhead per packet. Check the manual for the tunnel interface that you use as there are sysctls that must be set. And when testing, make sure to use a variety of packet sizes to make sure they all make it through correctly and you don't have MTU blackhole-related problems. -- Please keep replies on the mailing list.
