Hi Kristof, I still owe you a proper bug ticket for the issue we shortly talked about in Coimbra. During the winter holidays when I planned to work on "open source things" I fell ill with covid - so that was that. Anyway, the issue is still quite easily reproducible in 14.0-p5. I have this virtual machine at Vultr located in New Jersey that I use as a wireguard (kernel module as standard in releng/14) endpoint for obvious reasons. The uplink has a single public IPv4 and a single public IPv6 address so I use tunnel networks for both protocols and NAT both outbound to the interface address. Wireguard config: ---- [Interface] Address = 192.168.254.1/24,2003:a:d59:3840::1/64 PrivateKey = *** ListenPort = 51820 # PMH [Peer] PublicKey = *** AllowedIPs = 192.168.254.2/32,2003:a:d59:3840::2/128 ---- The client (Mac OS) has 0.0.0.0/0 and ::/0 in its AllowedIPs routing the entire traffic through the tunnel. For IPv4 I use an RFC 1918 network, obviously. For IPv6 I use a GUA /64 from my allocation at home, because ULA are essentially useless the way current desktop OSes treat them. pf NAT config: ---- nat on vtnet0 from 192.168.254.0/24 to any -> 140.82.8.233 nat on vtnet0 from 2003:a:d59:3840::/64 to any -> 2001:19f0:5:2634:5400:3ff:fefa:33f9 pass all no state ---- I am currently sitting behind a local 100 Mbit/s symmetrical uplink. Using Ookla Speedtest I get: Local connection without VPN enabled: 90/90 Mbit/s VPN connection with vtnet0 -rxcsum -txcsum -rxcsum6 -txcsum6: 80/80-ish Mbit/s, no noticeable slowdown VPN connection with vtnet0 without -rxcsum -txcsum -rxcsum6 -txcsum6: 0.3 Mbit/s download while upload seems to be unaffected I can give you root access to the server if required. Kind regards, Patrick
Looks like the bug is addressed directly to Kristof.
Unfortunately, the main problem is that all our NAT implementations do not support offload. Therefore, you need to turn it off.
From an operational point of view understood and perfectly valid. E.g. OPNsense comes with hardware offloading switched off by default. Kristof claimed in private conversation that this *should* work and I promised to file a ticket with a reproducible case.
(In reply to Alexander Fedorov from comment #2) > Unfortunately, the main problem is that all our NAT implementations do not support offload. Iirc. that's the case on ipfw, but not on pf. I fixed a checksum issue in pf many years ago: https://cgit.freebsd.org/src/commit/?id=c110fc49da2995d10d60d908af0838ecb4be9bee (PR 154428, 193579, 198868). > 0.3 Mbit/s download while upload seems to be unaffected From what perspective is that? As in: is the issue with packets the relevant machine sends or receives? Did you tcpdump to confirm that it's a checksum issue?
I encountered the same issue when I was using AppJail apply nat to jail on my hetzner VPS. You can see the full context here: https://github.com/DtxdF/AppJail/issues/8 Just like Patrick M. Hausen's case, the upload speed is been affected but not that much(1659.30Mbps inside jail vs 2853.11Mbps outside jail, 40% slower but still fast enough), but the download speed is disastrous(19.49Mbps inside jail vs 6298.97Mbps outside jail, 323x times slower.)
(In reply to Orville Q. Song from comment #5) After setting hw.vtnet.csum_disable="1" in /boot/loader.conf, the download and upload speeds inside the jail are the same as outside the jail now.