# OpenVPN broken after upgrade to 11.0-RELEASE



## Troopy (Oct 12, 2016)

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
        options=80000<LINKSTATE>
        inet6 fe80::d0fe:8c25:1941:a1c3%tun0 prefixlen 64 scopeid 0x4
        inet 172.16.11.1 --> 172.16.11.2  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
server 172.16.11.0 255.255.255.0
topology subnet
ifconfig-pool-persist ipp.txt
keepalive 30 120
comp-lzo
user nobody
group nobody
persist-key
persist-tun
status openvpn-status.log
verb 3
```


```
Routing tables

Internet:
Destination        Gateway            Flags     Netif Expire
default            185.x.24.21        UGS      vtnet0
127.0.0.1          link#2             UH          lo0
172.16.11.0/24     172.16.11.1        UGS         lo0
172.16.11.1        link#4             UHS         lo0
172.16.11.2        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
```


----------



## SirDice (Oct 12, 2016)

Just to confirm, after upgrading to 11.0-RELEASE, did you reinstall all ports/packages?


----------



## Troopy (Oct 12, 2016)

Yes I did. I used pkg-static upgrade -f. 


```
root@troopy:~ # openvpn --version
OpenVPN 2.3.12 amd64-portbld-freebsd11.0 <snip>
```


----------



## Troopy (Oct 13, 2016)

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 172.16.11.1 172.16.11.2 mtu 1500 netmask 255.255.255.0 up
```

Am I correct that this is not the right ifconfig command in topology subnet mode ? Where is the second ip (172.16.11.2) 'coming' from ?


----------



## breathe51 (Oct 14, 2016)

I am having a similar issue. My Openvpn is configured as a subnet topology of 10.10.30.0/28 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 10.10.32.3 (10.10.32.3): 56 data bytes
36 bytes from localhost (127.0.0.1): Redirect Host(New addr: 10.10.32.1)
Vr HL TOS  Len   ID Flg  off TTL Pro  cks      Src      Dst
 4  5  00 0054 9f6e   0 0000  40  01 0000 127.0.0.1  10.10.32.3

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

On Freebsd 10, a netstat -arn shows this.

10.10.30.0/28      10.10.30.1         UGS        *tun0*
10.10.30.1         link#6             UHS         lo0
10.10.30.2         link#6             UH         tun0

On Freebsd 11, a netstat -arn shows this.

10.10.30.0/28      10.10.30.1         UGS         *lo0*
10.10.30.1         link#4             UHS         lo0
10.10.30.2         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.

Thoughts?


----------



## spag (Oct 20, 2016)

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. <sales@openvpn.net>
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
Internet:
Destination        Gateway            Flags     Netif Expire
default            XXX.XXX.XXX.XXX    UGS         em0
10.0.0.0/8         link#2             U           em1
10.0.0.2           link#2             UHS         lo0
10.44.44.0/24      10.44.44.1         UGS         em1
10.44.44.1         link#4             UHS         lo0
10.44.44.2         link#4             UH         tun0
127.0.0.1          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] dns.msftncss.com from 10.44.44.16
Oct 21 09:12:50 dnsmasq[14868]: cached dns.msftncss.com is 131.102.255.255
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 10.44.44.0/24 10.44.44.1
route add -net 10.44.44.0/24 10.44.44.1 [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 https://community.openvpn.net/openvpn/ticket/425
( new 2.4 : https://github.com/OpenVPN/openvpn/pull/65 - unrelated )


----------



## abychko (Oct 24, 2016)

just the same here on 11.0-RELEASE. added temporarily route commands to the /etc/rc.local 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207831


----------



## IPTRACE (Oct 25, 2016)

Yeah, the same as https://forums.freebsd.org/threads/58189/ .

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 10.10.11.0/24 10.10.11.1; route add 10.10.11.0/24 10.10.11.1 -ifp tun0"
```
It works for startup and `service openvpn [start|restart]` comamnd as well.


----------

