Bug 276838

As discussed on IRC, there are good chances that this is MTU related.

If `mssfix` is in use, this will cap TCP packet size to "small enough so outside UDP packets do not need to be fragmented".  This works both sides, so it's enough if one end does `mssfix`.

As of today, kernel openvpn does not seem to support `mssfix`, so if *both* ends use DCO, no MSS manipulations are done, and you need to reduce interface MTU (`tun-mtu 1400`) to get the same effect.

Now, why outside fragmentation breaks with IPv6 is another of these questions - it shouldn't break, it is tested here in my FreeBSD 14 / DCO test scenario, but for example `pf(4)` needed to be told to leave IPv6 fragments alone in earlier versions (not sure about 14).

(In reply to Gert Doering from comment #1)
Thank you for your excellent guidance. Indeed, setting "tun-mtu 1400" on the server fixed the issue. 
As discussed on IRC, I will leave this PR open as a precaution. Perhaps mssfix will come to FreeBSD DCO at some point or it will get solved differently.

Comment 3 Kristof Provost 2024-03-21 07:28:36 UTC

I am unable to reproduce any such issue testing locally. Over an IPv6 tunnel I manage to transmit arbitrary sized ping requests, and I also see no issues transmitting a large (1MB) file.

Patch for reference:

diff --git a/tests/sys/net/if_ovpn/if_ovpn.sh b/tests/sys/net/if_ovpn/if_ovpn.sh
index bbaffa0bce73..0ec2563cf355 100644
--- a/tests/sys/net/if_ovpn/if_ovpn.sh
+++ b/tests/sys/net/if_ovpn/if_ovpn.sh
@@ -308,10 +308,28 @@ atf_test_case "4in6" "cleanup"
                keepalive 100 600
        "

+       dd if=/dev/random of=test.img bs=1024 count=1024
+       cat test.img | jexec a nc -N -l 1234 &
+
        # Give the tunnel time to come up
        sleep 10

        atf_check -s exit:0 -o ignore jexec b ping -c 3 198.51.100.1
+
+       # MTU sweep
+       for i in `seq 1000 1500`
+       do
+               atf_check -s exit:0 -o ignore jexec b \
+                   ping -c 1 -s $i 198.51.100.1
+       done
+
+       rcvmd5=$(jexec b nc -N -w 3 198.51.100.1 1234 | md5)
+       md5=$(md5 test.img)
+
+       if [ $md5  != $rcvmd5 ];
+       then
+               atf_fail "Transmit corruption!"
+       fi
 }

 4in6_cleanup()

In my case, the limits for the successful "ping  -4 -s $size remote_IP" are:
- in IPv6 tunnel, $size is limited to 1400
- in IPv4 tunnel $size limit is 1412
It was tested between FreeBSD stable/14 running OpenVPN 2.6.10 with DCO and FreeBSD CURRENT running OpenVPN 2.6.9 as a client. 

It's not the case though. The problem I faced was too large TCP segments that couldn't pass the tunnel thus preventing SSH sessions from being established over tunnel.

Comment 5 commit-hook 2024-03-22 08:37:35 UTC

A commit in branch main references this bug:

URL: https://cgit.FreeBSD.org/src/commit/?id=e08b44339b65a6aa7df4a58d0b1f471ba16da410

commit e08b44339b65a6aa7df4a58d0b1f471ba16da410
Author:     Kristof Provost <kp@FreeBSD.org>
AuthorDate: 2024-03-21 07:38:45 +0000
Commit:     Kristof Provost <kp@FreeBSD.org>
CommitDate: 2024-03-22 08:00:05 +0000

    if_ovpn tests: test large packets in IPv6 tunnel

    There's a report of MTU issues over IPv6 DCO tunnels.
    Extend the 4in6 test to send a series of pings with different sizes, as
    well as transfer a large file.

    No issues were found, but we may as well extend the test case.

    PR:             276838

 tests/sys/net/if_ovpn/if_ovpn.sh | 18 ++++++++++++++++++
 1 file changed, 18 insertions(+)

In bug 280036 the reporter complains about apparent data corruption which I can easily reproduce. 
Clearly, the FreeBSD implementation of OpenVPN --mssfix is broken in case ovpn(4) is deployed at both ends. Setting "tun-mtu 1400" on the OpenVPN server works as a workaround.

I was wrong in comment #6 connecting two bugs, and since, presumably, what was reported here wasn't a bug, but the issue with IPv6 fragmented packets, perhaps it's the right time to close this PR.