This change allows the OpenVPN DCO tunnel interface to be used with a
non-default FIB akin to tun(4).
Note that using OpenVPN with a non-default FIB either needs a patched
version of OpenVPN or a special updown script, see PR 278295.
Details
Details
- Reviewers
kp
Verified that the test case implemented fails with a vanilla ovpn(4) but succeeds when built with this patch.
Diff Detail
Diff Detail
- Repository
- rG FreeBSD src repository
- Lint
Lint Skipped - Unit
Tests Skipped
Event Timeline
Comment Actions
Hrm, unfortunately, I fail to produce a test case for this using the
if_ovpn.sh approach of OpenVPN server and client in a VNET jail each
as opposed to the client running natively on the host and the server
on another machine. I. e. the ICMP echo reply still ends up in the
expected FIB (or at least somehow at the ping(8) process) with an
unpatched ovpn(4) and the client running in the VNET jail. So this
test setup seems to involve sufficiently different code paths hiding
the problem. Any ideas how to create a test case closer to the native
scenario?
Comment Actions
Okay, I've managed to implement a test case. The problem doesn't surface
in the jailed test environment, even when using a single one two run both
server and client. However, there are others tricky parts and when testing
directly on the host, we suddenly should care about not leaving the tunnel
interfaces behind.
futro242# kyua config
architecture = amd64
execenvs = host jail
parallelism = 1
platform = amd64
test_suites.FreeBSD.allow_devfs_side_effects = true
test_suites.FreeBSD.allow_network_access = true
test_suites.FreeBSD.allow_sysctl_side_effects = true
test_suites.FreeBSD.fibs = 1 2
unprivileged_user = tests
futro242# kldload /boot/kernel/if_ovpn.ko
futro242# kyua test sys/net/if_ovpn/if_ovpn_fib
sys/net/if_ovpn/if_ovpn_fib:fibtun -> failed: 0 != 2 (0 != 2) [23.113s]
Results file id is usr_tests.20261001-210054-940863
Results saved to /root/.kyua/store/results.usr_tests.20261001-210054-940863.db
0/1 passed (0 broken, 1 failed, 0 skipped)
futro242# kldunload if_ovpn.ko
futro242# kldload /tmp/if_ovpn.ko
futro242# kyua test sys/net/if_ovpn/if_ovpn_fib
sys/net/if_ovpn/if_ovpn_fib:fibtun -> passed [12.121s]
Results file id is usr_tests.20261001-210134-622841
Results saved to /root/.kyua/store/results.usr_tests.20261001-210134-622841.db
1/1 passed (0 broken, 0 failed, 0 skipped)
Comment Actions
That test seems to fail for me with failed: 0 != 2 (0 != 2). The ping doesn't find a route:
+ setfib 2 ping -c 3 198.51.100.1 ping: sendto: No route to host ping: sendto: No route to host ping: sendto: No route to host
I'm also rather surprised that you'd see differences between running this jailed and on the host. That certainly needs to be at least understood first.
Comment Actions
Actually, I see odd behavior which seems to be entirely unrelated to
ovpn(4). For example, if I replace 192.168.2.{1,2} with 192.0.2.{1,2},
the sanity ping to 192.0.2.2 before OpenVPN is even started already
fails. I have no idea what could be the reason for that as 192.0.2.1/24
neither collides with my network configuration nor is any firewall
active. Moreover, the existing ovpn(4) tests using 192.0.2.1/24 work
just fine.
That's why I was taking about tricky parts. But then again, I'm not
familiar with kyua(1) and don't know how its allow_network_access
and fibs configuration knobs might interfere for example.
As for the test in turn always succeeding for me when jailed, it's unclear
to me whether FIBs are known to work correctly in jails to begin with.
At least none of the tests in tests/sys/netinet/fibs_test.sh sets up a jail
and based on the code, these tests are expected to run directly on the host.
So overall, I'm apparently hitting a couple of additional problems, which
for the most part seem to be unrelated to ovpn(4), though, and - except for
the missing M_SETFIB() - which for me only surface in the test environment,
not in real world usage. This probably also explains why the new test case
in turn unexpectedly fails for you.