Hi, On Thu, Aug 11, 2022 at 05:25:05PM +0200, Kristof Provost via Openvpn-devel wrote: > On 10 Aug 2022, at 18:32, Gert Doering wrote: > > as promised, here's test results and code review. > > > > Test results: > > > > - running openvpn over TCP gives me a kernel panic - this is not so > > nice... (see attached .png from the vmware console) - userland seems > > to assume "kernel can do TCP", kernel panics on "if !udp, panic()" > > (so intentional panic, not corruption panic). > > > > This is on freebsd git FreeBSD 14.0-CURRENT #1 main-n257130-c0665d5c824 > > I???ve pushed a fix for this panic in > fd6b3bede5a5c210f327e5c9bd3e415ee905048b. > I simply didn???t think that user space might give us a non-UDP > socket, so checking for that and rejecting the peer in that case > fixes the panic. Thanks for finding that.
Always happy to crash other people's software :-)
That said, this seems to imply that FreeBSD DCO is UDP-only today - do
you have plans for TCP as well, or is this something "someone else needs
to contribute"?
For the time being we should add an #ifdef TARGET_FREEBSD check to
dco.c:dco_check_option_conflict_platform() and disable DCO for
--proto tcp.
I thought the function would only get introduced in patch 20/25 of
the big DCO series, but that patch is a bit out of sync - the function
is already there, with Linux specific checks.
> > - running openvpn over UDP has issues with fragmentation - almost all
> > t_client tests that *do* use DCO fail the "big ping" test
> >
> > FAIL: IPv4 ping test (3000 bytes) failed, but should succeed.
> > FAIL: IPv6 ping test (3000 bytes) failed, but should succeed.
> >
> > this is "with no special mtu related options to OpenVPN", so the
> > tun interface is MTU 1500, and the pings are created by
> >
> > fping -b 3000 -C 20 -p 250 -q -C 5 -p 400 10.194.5.1 10.194.0.1
> > fping6 -b 3000 -C 20 -p 250 -q -C 5 -p 400 fd00:abcd:194:5::1
> > fd00:abcd:194:0::1
> >
> > (testing the host "on the p2p link" and "something behind a --route
> > pushed by the server")
>
> I???m failing to reproduce this in my own test setup. With a
> simple ???ping -c 2000??? on a 1500 MTU tunnel I see two layers of
> fragmentation (the ICMP packet gets fragmented before it goes through
> the tunnel, and then the outer UDP packet gets fragmented as well),
> as I???d expect. Traffic flows in both directions. (i.e. the ping
> succeeds).
OK. This is generally good, so I need to find out who is eating my
packets. In my case, I have 3 fragments, which might or might not
cause a difference - and there's stuff in between (FreeBSD 14 client
via FreeBSD 12 pf(4) firewall to FreeBSD 11 [or so] server).
> Is there any documentation on how t_client.sh works? It???s not at all
> clear to me what goes in t_client.in (e.g. in OPENVPN_BASE_P2P).
Basically, t_client is a very basic vehicle to fire up certain
OpenVPN configurations, verify that the expect IPv4 and IPv6 addresses
show up on "a new interface", and that pings to certain destinations
work, with varying packet sizes. It's a bit of a sledge hammer, but
it's good at finding stuff.
My configs have something like this:
CA_CERT="$KEYBASE/ca.crt"
CLIENT_KEY="$KEYBASE/cron2-gentoo-i386.key"
CLIENT_CERT="$KEYBASE/cron2-gentoo-i386.crt"
REMOTE=conn-test-server.openvpn.org
# this is the basic "TLS client" stuff with ca/cert/key
# remove the comp-lzo for DCO tests
OPENVPN_BASE_P2MP="--client --ca $CA_CERT \
--cert $CLIENT_CERT --key $CLIENT_KEY \
--remote-cert-tls server --comp-lzo --verb 3 $OPENVPN_EXTRA_CF"
#
# Test 2: UDP / p2mp tun
# specify IPv4+IPv6 addresses expected from server and ping targets
#
RUN_TITLE_2="udp / p2pm / top net30"
OPENVPN_CONF_2="$OPENVPN_BASE_P2MP --dev tun --proto udp4 --remote $REMOTE
--port 51194"
EXPECT_IFCONFIG4_2="10.194.2.54"
EXPECT_IFCONFIG6_2="fd00:abcd:194:2::100c"
PING4_HOSTS_2="10.194.2.1 10.194.0.1"
PING6_HOSTS_2="fd00:abcd:194:2::1 fd00:abcd:194:0::1"
... so this would connect to a specific UDP instance on the test server,
expect to be assigned these addresses (= this needs adjustment after
the first run, when you know what addresses will be assigned, and it
assumes --ip-pool-persist on the server), and then pings things.
I usually ping "the server IP on that tun" and "a loopback IP on the
server, which is only reachable by means of 'push route...'", so I
can see if push/pull and route installation works.
If you're interested, I can unicast you the full file I use for
my DCO client tests, with different ciphers, some instances with
compression (= does it properly fall back?), some with http/socks
proxy, etc., plus a set of client+ca certificates to run against
our test server.
[..]
> > ... this *does* look correct, but there is never a reply from the other
> > end, so something is not right. Either inside or outside.
>
> Is your server in this scenario a FreeBSD DCO machine, or Linux DCO or
> something else?
> In my setup the server is non-DCO FreeBSD.
FreeBSD 14 DCO -> FreeBSD 13.0 pf(4) firewall -> Internet -> FreeBSD 11.4
If I --disable-dco, the fragmented ping works, so "generally" the
path handles fragments. Something is different with DCO, so I'll do
more tcpdumping tomorrow and see if I can find out.
gert
--
"If was one thing all people took for granted, was conviction that if you
feed honest figures into a computer, honest figures come out. Never doubted
it myself till I met a computer with a sense of humor."
Robert A. Heinlein, The Moon is a Harsh Mistress
Gert Doering - Munich, Germany g...@greenie.muc.de
signature.asc
Description: PGP signature
_______________________________________________ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
