https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=287653
Bug ID: 287653
Summary: if_ovpn can't be pre-configured with ifconfig; can't
be assigned to fib
Product: Base System
Version: 14.2-STABLE
Hardware: amd64
OS: Any
Status: New
Severity: Affects Many People
Priority: ---
Component: kern
Assignee: [email protected]
Reporter: [email protected]
root@kama-gw:/usr/local/etc/openvpn # ifconfig ovpn0 destroy
ifconfig: interface ovpn0 does not exist
root@kama-gw:/usr/local/etc/openvpn # openvpn --config openvpn.conf
2025-06-19 15:06:19 Note: --cipher is not set. OpenVPN versions before 2.5
defaulted to BF-CBC as fallback when cipher negotiation failed in this case. If
you need this fallback please add '--data-ciphers-fallback BF-CBC' to your
configuration and/or add BF-CBC to --data-ciphers.
2025-06-19 15:06:19 WARNING: file '/usr/local/etc/openvpn/keys/server.key' is
group or others accessible
2025-06-19 15:06:19 OpenVPN 2.6.14 amd64-portbld-freebsd14.2 [SSL (OpenSSL)]
[LZO] [LZ4] [PKCS11] [MH/RECVDA] [AEAD] [DCO]
2025-06-19 15:06:19 library versions: OpenSSL 3.0.12 24 Oct 2023, LZO 2.10
2025-06-19 15:06:19 DCO version: FreeBSD 14.0-RELEASE #0
releng/14.0-n265380-f9716eee8ab4: Fri Nov 10 05:57:23 UTC 2023
[email protected]:/usr/obj/usr/src/amd64.amd64/sys/GENERIC
2025-06-19 15:06:19 Diffie-Hellman initialized with 4096 bit key
2025-06-19 15:06:19 DCO device ovpn0 opened
2025-06-19 15:06:19 /sbin/ifconfig ovpn0 192.0.2.1/24 mtu 1400 up
2025-06-19 15:06:19 Socket Buffers: R=[42080->42080] S=[9216->9216]
2025-06-19 15:06:19 UDPv4 link local (bound): [AF_INET][undef]:1194
2025-06-19 15:06:19 UDPv4 link remote: [AF_UNSPEC]
2025-06-19 15:06:19 MULTI: multi_init called, r=256 v=256
2025-06-19 15:06:19 IFCONFIG POOL IPv4: base=192.0.2.2 size=253
2025-06-19 15:06:19 Initialization Sequence Completed
root@kama-gw:/usr/local/etc/openvpn # /sbin/ifconfig ovpn0 create fib 56
root@kama-gw:/usr/local/etc/openvpn # openvpn --config openvpn.conf
2025-06-19 15:08:53 Note: --cipher is not set. OpenVPN versions before 2.5
defaulted to BF-CBC as fallback when cipher negotiation failed in this case. If
you need this fallback please add '--data-ciphers-fallback BF-CBC' to your
configuration and/or add BF-CBC to --data-ciphers.
2025-06-19 15:08:53 WARNING: file '/usr/local/etc/openvpn/keys/server.key' is
group or others accessible
2025-06-19 15:08:53 OpenVPN 2.6.14 amd64-portbld-freebsd14.2 [SSL (OpenSSL)]
[LZO] [LZ4] [PKCS11] [MH/RECVDA] [AEAD] [DCO]
2025-06-19 15:08:53 library versions: OpenSSL 3.0.12 24 Oct 2023, LZO 2.10
2025-06-19 15:08:53 DCO version: FreeBSD 14.0-RELEASE #0
releng/14.0-n265380-f9716eee8ab4: Fri Nov 10 05:57:23 UTC 2023
[email protected]:/usr/obj/usr/src/amd64.amd64/sys/GENERIC
2025-06-19 15:08:53 Diffie-Hellman initialized with 4096 bit key
2025-06-19 15:08:53 Failed to create interface ovpn0 (SIOCSIFNAME): File exists
(errno=17)
2025-06-19 15:08:53 dco_set_ifmode: failed to set ifmode=00008002: Device busy
(errno=16)
2025-06-19 15:08:53 DCO device ovpn0 already exists, won't be destroyed at
shutdown
2025-06-19 15:08:53 /sbin/ifconfig ovpn0 192.0.2.1/24 mtu 1400 up
ifconfig: in_exec_nl(): Empty IFA_LOCAL/IFA_ADDRESS
ifconfig: ioctl (SIOCAIFADDR): Invalid argument
2025-06-19 15:08:53 FreeBSD ifconfig failed: external program exited with error
status: 1
2025-06-19 15:08:53 Exiting due to fatal error
root@kama-gw:/usr/local/etc/openvpn #
you can't pre-create it at all actually.. even if you don't assign it to a fib
you still get:
ifconfig: in_exec_nl(): Empty IFA_LOCAL/IFA_ADDRESS
ifconfig: ioctl (SIOCAIFADDR): Invalid argument
as if its looking for a tunnel/ptp specification:
root@kama-gw:/usr/local/etc/openvpn # ifconfig ovpn0
ovpn0: flags=1008011<UP,POINTOPOINT,MULTICAST,LOWER_UP> metric 0 mtu 1400
options=80000<LINKSTATE>
groups: openvpn
fib: 56
nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
Somehow openvpn is able to create this interface not as a pointtopoint link:
root@kama-gw:~ # ifconfig ovpn0
ovpn0: flags=1008003<UP,BROADCAST,MULTICAST,LOWER_UP> metric 0 mtu 1400
options=80000<LINKSTATE>
inet 192.0.2.1 netmask 0xffffff00 broadcast 192.0.2.255
groups: openvpn
nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
There's no documentation for it man 4 ovpn just a summary
and I was just barely able to piece together something that kinda works...
server:
ca /usr/local/etc/openvpn/keys/ca.crt
cert /usr/local/etc/openvpn/keys/server.crt
key /usr/local/etc/openvpn/keys/server.key
dh /usr/local/etc/openvpn/keys/dh.pem
mode server
server 192.0.2.0 255.255.255.0
port 1194
dev ovpn0
dev-type tun
persist-key
persist-tun
verb 3
tls-server
proto udp4
keepalive 10 60
ping-timer-rem
data-ciphers AES-256-GCM:AES-128-GCM:ChaCha20-Poly1305
# data-ciphers-fallback ChaCha20-Poly1305
allow-compression no
topology subnet
tun-mtu 1400
explicit-exit-notify 1
client:
ca /usr/local/etc/openvpn/keys/ca.crt
cert /usr/local/etc/openvpn/keys/server.crt
key /usr/local/etc/openvpn/keys/server.key
dh /usr/local/etc/openvpn/keys/dh.pem
client
dev ovpn0
dev-type tun
verb 3
proto udp
script-security 2
remote aa.bb.cc.dd 1194
persist-key
persist-tun
proto udp4
tun-mtu 1400
route-nopull
really not sure how its creating that interface (I can reproduce it with
ifconfig but if there's a way please let me know)
As near as I can tell, this won't even work unless you're using topology subnet
(this is why its not using POINTTOPOINT mode when it creates the interface
itself,
if I can't create this interface without ifconfig then it might as well not
exist because I need to assign it to a FIB. If you ask OpenVPN I'm sure they'll
say "well there's bind-dev, just create a VRF" which I can't do here...
I noticed the other day that the wireguard-tools or whatever provides that
command line tool the configuration format has an option for "Table" but it
doesn't work with FIB... maybe that should be separate issue
I would just use racoon but I can't figure out NAT-T I don't know why I just
can't.
I feel like I read somewhere that somebody really didn't like the idea of a
layer 3 bridge, and thus it never came to fruition in FreeBSD, to be honest it
was kind of a pissy conversation and it left a bad taste in my mouth. Maybe
what I took away from that conversation was misled, but it just seems like if
it were meant to be then it would already be.. on the other hand it's
essentially just a 'dumb' bridge, and the functionality to associate an
interface to a particular routing table is already in place, so essentially it
needs to implement only addm and deletem and those hooks should ensure that all
devices that are enslaved by the bridge are assigned to the FIB associated with
the VRF; and this is essentially just VRF-lite. I started to make something
with Claude a while ago:
https://gist.github.com/paigeadelethompson/5410597d92ce5c8be1cbdb48207ba473
It does compile / load and I believe you can even enslave interfaces but I
don't recall if it actually does anything besides that. Also VNI probably
doesn't need to be there since VRF-lite, not full MPLS VRF; maybe the thing to
do would be to reinvent this concept, and call it a VGW. I'd have to guess that
the reason it hasn't been done already though is just either simply because it
doesn't add enough value, or because of the ambiguity surrounding VRF-lite
(whether or not it is officially a concept) and I doubt anybody is in a hurry
to implement full stack MPLS.
But what about SRv6? I've been looking at it a lot lately and it sounds like it
could be essentially what I would want out of full MPLS. I haven't been able to
find much in terms of people discussing this for FreeBSD, this dead link that
I'd really like to read but can't:
https://www.mail-archive.com/freebsd-net%40freebsd.org/msg61360.html
It's a pretty big topic though there's several endpoint types that come with
it. I wanna say it makes more sense to me, just because MPLS seems like a
relatively proprietary concept that afaik not even OpenBSD has completely
covered and their coverage is pretty substantial, but I just think in terms of
things like VRFs, SRv6 has a couple of things:
- End.T
- End.DT6
- End.DT4
there's a lot more described on slide 18:
https://www.segment-routing.net/images/201901-SRv6.pdf
I'd really like to see this get done, but I think the thing I'm getting at is
maybe a VRF isn't what FreeBSD needs, even if it is VRF-lite just because I
feel like it's bound to become an antiquated concept sooner rather or perhaps
even later. On the other hand, it could just be reinvented (call it a VGW) and
then it will be a concept unique (like FIB) to FreeBSD even though it's really
just VRF-lite.... I'll do the work and submit it but I'm not gonna bother if
it's not something that will be well received and I'd much rather talk about
SRv6 in any case.
--
You are receiving this mail because:
You are the assignee for the bug.
