OpenVPN broken after upgrade to 11.0-RELEASE

After the upgrade to 11.0-RELEASE my openvpn setup seems to be broken.

I'm using OpenVPN with the topology subnet config directive, which should make it possible for clients to ping each other. My setup worked fine in 10.2-RELEASE. The first client can connect and send traffic. Subsequent client can connect, but not send traffic.

Looks like the problem is the misconfiguration of the tunnel interface by openvpn. The tunnel is configured as a PtP connection between two ip's. While in topology subnet mode, this should not happen.

root@troopy:~ # ifconfig tun0
tun0: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> metric 0 mtu 1500
        inet6 fe80::d0fe:8c25:1941:a1c3%tun0 prefixlen 64 scopeid 0x4
        inet -->  netmask 0xffffff00
        nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
        groups: tun
        Opened by PID 900

Server Config file:
port 1194
proto udp
dev tun
ca ca.crt
cert troopy.crt
key troopy.key
dh dh1024.pem
topology subnet
ifconfig-pool-persist ipp.txt
keepalive 30 120
user nobody
group nobody
status openvpn-status.log
verb 3

Routing tables

Destination        Gateway            Flags     Netif Expire
default            185.x.24.21        UGS      vtnet0          link#2             UH          lo0        UGS         lo0        link#4             UHS         lo0        link#4             UH         tun0
185.x.24.0/24     link#1             U        vtnet0
185.x.24.21       link#1             UHS         lo0

root@troopy:~ # openvpn --version
OpenVPN 2.3.12 amd64-portbld-freebsd11.0 [SSL (OpenSSL)] [LZO] [MH] [IPv6] built on Oct  5 2016
library versions: OpenSSL 1.0.2j-freebsd  26 Sep 2016, LZO 2.09
Just to confirm, after upgrading to 11.0-RELEASE, did you reinstall all ports/packages?
Yes I did. I used pkg-static upgrade -f.

root@troopy:~ # openvpn --version
OpenVPN 2.3.12 amd64-portbld-freebsd11.0 <snip>
So got some more info. If I stop openvpn, I see this error in the /var/log/messages:
Oct 13 17:12:25 troopy openvpn[28730]: /sbin/ifconfig tun0 destroy
Oct 13 17:12:25 troopy openvpn[28730]: FreeBSD 'destroy tun interface' failed (non-critical): external program exited with error status: 1

After a fresh start, this caught my attention:
Oct 13 17:14:05 troopy openvpn[28786]: /sbin/ifconfig tun0 mtu 1500 netmask up

Am I correct that this is not the right ifconfig command in topology subnet mode ? Where is the second ip ( 'coming' from ?
I am having a similar issue. My Openvpn is configured as a subnet topology of so .1 is the server and .2 to .14 are client addresses obtained on a first come first served basis. No ccd and the Freebsd 11 install is from fresh.

Connecting on as the first user provides me with the IP of .2 and there are no issues connecting between server which is .1 and client which is .2, however, should a third client connect and obtain .3 then this client has no connectivity.

I have a noticed a change in that on Freebsd 11, when creating a tunnel with ifconfig, it now appears to create the tunnel route on the loopback interface, such that when i try to ping out from .1 to say .3, i reach the time to live exceeded as it sees the route on lo0.

PING ( 56 data bytes
36 bytes from localhost ( Redirect Host(New addr:
Vr HL TOS Len ID Flg off TTL Pro cks Src Dst
4 5 00 0054 9f6e 0 0000 40 01 0000

36 bytes from localhost ( Redirect Host(New addr:
Vr HL TOS Len ID Flg off TTL Pro cks Src Dst
4 5 00 0054 9f6e 0 0000 3f 01 0000

On Freebsd 10, a netstat -arn shows this. UGS tun0 link#6 UHS lo0 link#6 UH tun0

On Freebsd 11, a netstat -arn shows this. UGS lo0 link#4 UHS lo0 link#4 UH tun0

Even if you create the tunnel interface manually, outside of OpenVPN, on both FreeBSD 10 and 11, I get the same routing results as above.

Similar problem here. Looks like routing is not working properly. But intersting part is pings randomly access some machines and other not.

#openvpn --version
OpenVPN 2.3.12 amd64-portbld-freebsd11.0 [SSL (OpenSSL)] [LZO] [PKCS11] [MH] [IPv6] built on Oct 17 2016
library versions: OpenSSL 1.0.2j 26 Sep 2016, LZO 2.09
Originally developed by James Yonan
Copyright (C) 2002-2010 OpenVPN Technologies, Inc. <>
Compile time defines: enable_crypto=yes enable_crypto_ofb_cfb=yes enable_debug=yes enable_def_auth=yes enable_dlopen=unknown enable_dlopen_self=unknown enable_dlopen_self_static=unknown enable_fast_install=needless enable_fragment=yes enable_http_proxy=yes enable_iproute2=no enable_libtool_lock=yes enable_lzo=yes enable_lzo_stub=no enable_management=yes enable_multi=yes enable_multihome=yes enable_pam_dlopen=no enable_pedantic=no enable_pf=yes enable_pkcs11=yes enable_plugin_auth_pam=yes enable_plugin_down_root=yes enable_plugins=yes enable_port_share=yes enable_selinux=no enable_server=yes enable_shared=yes enable_shared_with_static_runtimes=no enable_silent_rules=no enable_small=no enable_socks=yes enable_ssl=yes enable_static=yes enable_strict=no enable_strict_options=no enable_systemd=no enable_win32_dll=yes enable_x509_alt_username=no with_crypto_library=openssl with_gnu_ld=yes with_mem_check=no with_plugindir='$(libdir)/openvpn/plugins' with_sysroot=no

In my case vpn network on FreeBSD goes to em1, when on old was connected to tun0.
#netstat -arn4
Routing tables
Destination        Gateway            Flags     Netif Expire
default            XXX.XXX.XXX.XXX    UGS         em0         link#2             U           em1           link#2             UHS         lo0         UGS         em1         link#4             UHS         lo0         link#4             UH         tun0          link#3             UH          lo0
XXX.XXX.XXX.XXY/YY link#1             U           em0
AAA.AAA.AAA.AAA    link#1             UHS         lo0
Interesting is that udp packages works when client as for internal DNS - client gets answers even error.
Oct 21 09:12:50 dnsmasq[14868]: query[A] from
Oct 21 09:12:50 dnsmasq[14868]: cached is
Oct 21 09:12:50 dnsmasq[14868]: failed to send packet: No route to host
I have temporary solved a problem by doing this:

service openvpn start
route del
route add -net [B]-ifp tun0[/B]

now route is with tun0 and clients have access to internal network. This does not answer question why openvpn does not set proper interface to route.

I found something in here
( new 2.4 : - unrelated )
Last edited:
Yeah, the same as .

I've changed the running script /usr/local/etc/rc.d/openvpn .
The next to last line has been change as follow.
command_args="--cd ${dir} --daemon ${name} --config ${configfile} --writepid ${pidfile}; sleep 3; route del; route add -ifp tun0"
It works for startup and service openvpn [start|restart] comamnd as well.