Error on FreeBSD: route: writing to routing socket: File exists

[yurivict]

I am getting these errors on FreeBSD 10.3:

Tue Jun  7 01:07:18 2016 TUN/TAP device /dev/tun0 opened
Tue Jun  7 01:07:18 2016 do_ifconfig, tt->ipv6=0, tt->did_ifconfig_ipv6_setup=0
Tue Jun  7 01:07:18 2016 /sbin/ifconfig tun0 10.8.0.6 10.8.0.5 mtu 1500 netmask 255.255.255.255 up
Tue Jun  7 01:07:18 2016 /sbin/route add -net 59.53.72.34 192.168.5.1 255.255.255.255
add net 59.53.72.34: gateway 192.168.5.1
Tue Jun  7 01:07:18 2016 /sbin/route add -net 0.0.0.0 10.8.0.5 128.0.0.0
add net 0.0.0.0: gateway 10.8.0.5
Tue Jun  7 01:07:18 2016 /sbin/route add -net 128.0.0.0 10.8.0.5 128.0.0.0
add net 128.0.0.0: gateway 10.8.0.5
Tue Jun  7 01:07:18 2016 /sbin/route add -net 59.53.72.34 192.168.5.1 255.255.255.255
route: writing to routing socket: File exists
add net 59.53.72.34: gateway 192.168.5.1 fib 0: route already in table
Tue Jun  7 01:07:18 2016 ERROR: FreeBSD route add command failed: external program exited with error status: 1
Tue Jun  7 01:07:18 2016 /sbin/route add -net 10.8.0.0 10.8.0.5 255.255.255.0
add net 10.8.0.0: gateway 10.8.0.5
Tue Jun  7 01:07:18 2016 Initialization Sequence Completed

[Gert Döring]

It fails adding the host route for the VPN gateway via the LAN gateway

Tue Jun 7 01:07:18 2016 /sbin/route add -net 59.53.72.34 192.168.5.1 255.255.255.255

... which is weird, unless you have two OpenVPN instances running at the same time - in which case, you shouldn't be using --redirect-gateway / --redirect-private.

How does your routing table look like when you do "netstat -rn" while OpenVPN is not running?

(In any case it's just a warning, so while I would be curious why it is happening, it shouldn't be interfering with your usage of OpenVPN)

[yurivict]

# netstat -rn

Routing tables

Internet:
Destination        Gateway            Flags      Netif Expire
0.0.0.0/1          10.8.0.5           UGS        tun0
default            192.168.5.1        UGS         sk0
1.1.0.0/24         link#5             U          tap0
1.1.0.1            link#5             UHS         lo0
1.1.1.0/24         link#6             U          tap1
1.1.1.1            link#6             UHS         lo0
1.1.2.0/24         link#7             U          tap2
1.1.2.1            link#7             UHS         lo0
1.1.7.0/24         link#8             U          tap7
1.1.7.1            link#8             UHS         lo0
1.1.15.0/24        link#9             U         tap15
1.1.15.1           link#9             UHS         lo0
10.8.0.0/24        10.8.0.5           UGS        tun0
10.8.0.5           link#10            UH         tun0
10.8.0.6           link#10            UHS         lo0
59.53.72.34/32     192.168.5.1        UGS         sk0
127.0.0.1          link#4             UH          lo0
128.0.0.0/1        10.8.0.5           UGS        tun0
192.168.5.0/24     link#3             U           sk0
192.168.5.100      link#3             UHS         lo0

[yurivict]

Well, since OpenVPN is a security software warnings should be treated somewhat like errors. -)

[Gert Döring]

this "netstat -rn" output is while openvpn is running, and is not interesting - I need to see it while OpenVPN is *not* running.

And there's a reason why we treat warnings as warnings: because some people's setups are sufficiently complicated that the alternative would be "openvpn is not working at all" - which would happen to you if we treat this as *error*.

[yurivict]

# netstat -rn
Routing tables

Internet:
Destination        Gateway            Flags      Netif Expire
default            192.168.5.1        UGS         sk0
1.1.0.0/24         link#5             U          tap0
1.1.0.1            link#5             UHS         lo0
1.1.1.0/24         link#6             U          tap1
1.1.1.1            link#6             UHS         lo0
1.1.2.0/24         link#7             U          tap2
1.1.2.1            link#7             UHS         lo0
1.1.7.0/24         link#8             U          tap7
1.1.7.1            link#8             UHS         lo0
1.1.15.0/24        link#9             U         tap15
1.1.15.1           link#9             UHS         lo0
127.0.0.1          link#4             UH          lo0
192.168.5.0/24     link#3             U           sk0
192.168.5.100      link#3             UHS         lo0

[Gert Döring]

If this is the routing table with no VPN active, I would say "you are running more than one OpenVPN process at the same time" (one for tap0, one for tap1, etc.) and two of them are trying to install the host route that you get the warning about.

As I said, if you run multiple openvpn clients, using --redirect-gateway on more than one instance will cause conflicts - and this is what you are seeing.

If you run only one instance, you should not see the warning about "route already exists".

[yurivict]

The tapN ones aren't VPNs. They are ssh tunnels to VMs.

[yurivict]

But I see your point. My setup isn't simple. This confuses OpenVPN.

[Gert Döring]

Actually, I think I see the issue:

Tue Jun 7 01:07:18 2016 /sbin/route add -net 59.53.72.34 192.168.5.1 255.255.255.255
add net 59.53.72.34: gateway 192.168.5.1
Tue Jun 7 01:07:18 2016 /sbin/route add -net 59.53.72.34 192.168.5.1 255.255.255.255
route: writing to routing socket: File exists
add net 59.53.72.34: gateway 192.168.5.1 fib 0: route already in table

openvpn tries to install the host route *twice*, and the second one obviously fails (unrelated to the tap adapters, sorry, that got me confused).

So, why is it doing that? Do you have "route" statements for the vpn gateway in your config?

[yurivict]

I generated .ovpn using the "streisand" project: ​https://github.com/jlund/streisand . I don't think it is doing anything out of the ordinary.

It has one route statement:

route 59.53.72.34 255.255.255.255 net_gateway

[Gert Döring]

This route statement is what is causing the warning/error - it installs a route that will also be installed as a (documented) side effect of "redirect-gateway def1". It is not needed, so it should not be there - read: it's a bug in streisand.

OTOH as it says, it's a warning... and this is the reason why: we don't know if anyone else has already set up such a route (for whatever reason), so we log the fact, and see if it works anyway.

[yurivict]

I see. So every streisand user will have the same problem.

[Gert Döring]

will see the same warning, unless the underlying OS just accepts duplicate routes as "it's the same as we already have, so just fine" - yes.