OpenBSD route command incorrectly issued

[mikejuni]

I'm using GIT master version of OpenVPN as a server, noted a difference between the route commands issued from GIT master and 2.9.10 (in OpenBSD ports).

My server configuration (part that is relevant) is similar to this:

server 192.168.56.192 255.255.255.192

In 2.9.10, the route added, as shown in route show, is similar to this:

Network            Gateway           Iface
192.168.56.192/26  192.168.56.193    tun0
192.168.56.193     192.168.56.193    tun0

However, in GIT master, the first route (for the segment) is not put in correctly, instead I will see:

Network            Gateway           Iface     Metric
192.168.56.193     192.168.56.193    tun0      1
192.168.56.193     192.168.56.193    tun0      8

Thus it introduces issue that even though connection is established, I could not ping from the OpenVPN client to the server. I tried with both 2.3.6 client (on a OpenWRT) and OpenVPN Connect iOS.

[mikejuni]

Sorry in the bug report I mistakenly put in 2.9.10, it should be 2.3.10

[Gert Döring]

Can you show the actual route commands from the openvpn logs, please? I'm not acutely aware of any OpenBSD related changes in our sources between 2.3.x and git master.

Could you please also try compiling 2.3.x from source, instead of using the distribution-provided package? One possible reason for the difference could be that OpenBSD is patching OpenVPN (to fix the problem), but has never sent back the necessary change - so the package works, but "compile from upstream source" will have the same problem in 2.3.x and git master...

Obviously, this needs to work, but I need to understand what is happening first.

[Gert Döring]

And: which version of OpenBSD?

[mikejuni]

I'm using 5.9-stable version of OpenBSD. Per OpenBSD webcvs the only patch that I think may be relevant is this one:

​http://cvsweb.openbsd.org/cgi-bin/cvsweb/ports/net/openvpn/patches/patch-src_openvpn_tun_c?rev=1.8&content-type=text/x-cvsweb-markup&hideattic=1

You can see all the changes here:

​http://cvsweb.openbsd.org/cgi-bin/cvsweb/ports/net/openvpn/patches/?hideattic=1#dirlist

Don't really have time to compile again from source yet will try to do it asap.

[Gert Döring]

still waiting for the logs...

[moviuro]

The exact same issue happens on FreeBSD 11.0-RELEASE-p3. Here are the logs:

​http://sprunge.us/OCYM

Only IPv4 is affected, it seems. The "fix" consists of:

route delete 10.21.0.0/24
route add 10.21.0/24 -iface tun0

EDIT:

# #Starting service
# service openvpn start
Starting openvpn.
# netstat -rnfinet
Routing tables

Internet:
Destination        Gateway            Flags     Netif Expire
default            151.80.43.254      UGS         em0
10.10.10.1         link#3             UH          lo1
10.10.10.2         link#3             UH          lo1
10.10.10.3         link#3             UH          lo1
10.10.10.5         link#3             UH          lo1
10.10.20.1         link#4             UH          lo2
10.10.30.1         link#5             UH          lo3
10.10.30.3         link#5             UH          lo3
10.10.30.4         link#5             UH          lo3
10.10.30.5         link#5             UH          lo3
10.10.30.18        link#5             UH          lo3
10.10.30.77        link#5             UH          lo3
10.10.30.78        link#5             UH          lo3
10.10.40.1         link#6             UH          lo4
10.10.40.40        link#6             UH          lo4
10.10.40.53        link#6             UH          lo4
10.21.0.0/24       10.21.0.1          UGS         lo0 # BROKEN !
10.21.0.1          link#9             UHS         lo0
10.21.0.2          link#9             UH         tun0
10.30.0.0/24       10.21.0.2          UGS        tun0
[...]

[Gert Döring]

Replying to moviuro:

The exact same issue happens on FreeBSD 11.0-RELEASE-p3. Here are the logs:

please do not mix different operating system ports together - since the original poster never sent logs, and there is no "lo0" in his output, how can you be sure "it is the same issue"?

The FreeBSD one is (surprise) tracked in a ticket that has "FreeBSD" in its title :-) - namely #425

[Gert Döring]

I was sorely tempted to just close this, as "without an openvpn.log" it is very very hard to see what openvpn is doing, and what the expected behaviour should be.

I had a suspicion and my crystall ball is back from repairs, so I went and tested topology subnet, and lo and behold, the subnet route is indeed missing (which my buildbots didn't show, due to a supernet route being in place).

This happens both in git master and in 2.3.13, but the openvpn port in OpenBSD ports has a fix similar to what we do on other BSDs - add the "topology subnet" subnet route to the local interface. It will eventually get hit by the FreeBSD issue fixed in #481 and #425 (as soon as OpenBSD adjusts their routing tables to point "my ip" to lo0), so I'm porting over the FreeBSD fix.

(As a side note, the OpenBSD change in the port is way too intrusive for a "just for the ports" fix - why join OpenBSD and NetBSD when they are not that similar here?)

[Gert Döring]

So, patch is on the list:

Date: Wed, 9 Nov 2016 21:19:32 +0100
From: Gert Doering <gert@…>
To: openvpn-devel@…
Subject: [Openvpn-devel] [PATCH] Repair topology subnet on OpenBSD

​https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg12983.html

I have tested this on OpenBSD 4.9 and OpenBSD 6.0, but would appreciate if someone from the OpenBSD camp would test this as well and report back.

[Gert Döring]

commit 7f444dee52321c0f0294e99695150a7f69522715 (master)
commit ceac73b04fe9b70ed798afc07ddb9737c97b7a5d (release/2.3)
Author: Gert Doering
Date: Wed Nov 9 21:19:32 2016 +0100

Repair topology subnet on OpenBSD

Trac: #710
Signed-off-by: Gert Doering <gert@…>
Acked-by: David Sommerseth <davids@…>
Message-Id: <20161109201932.80991-1-gert@…>
URL: ​https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg12983.html
Signed-off-by: David Sommerseth <davids@…>

patch is in, will be in 2.4_beta1 and 2.3.14.

Closing this ticket, nothing more to do here :-)

(OpenBSD folks: when upgrading your port to 2.3.14, throw out the tun.c patch you have there - not needed any longer)