Problems with OpenVPN (new instance) and changes to the routing table

[vielhak]

Hi,

I have a stable working S2S OpenVPN tunnel with the new instance method.
The problem is when I try to add / remove routes on the client side the main routing table is reloaded and the routes for the openvpn client are lost!

After starting the openvpn client side the (shortened) routing table looks like:

Code Select Expand

Internet:
Destination        Gateway            Flags         Netif Expire
10.0.0.0/8         172.17.166.37      UGS          ovpnc1
127.0.0.1          link#4             UH              lo0
172.16.0.0/12      172.17.166.37      UGS          ovpnc1
172.17.4.0/24      link#1             U              igb0
172.17.4.1         link#4             UHS             lo0
172.17.166.37      link#11            UH           ovpnc1
172.17.166.38      link#4             UHS             lo0

If I now add a local route, e.g. 192.168.0.0/24 via 172.17.4.100. The routing table changes to:

Code Select Expand

nternet:
Destination        Gateway            Flags         Netif Expire
127.0.0.1          link#4             UH              lo0
172.17.4.0/24      link#1             U              igb0
172.17.4.1         link#4             UHS             lo0
172.17.166.37      link#11            UH           ovpnc1
172.17.166.38      link#4             UHS             lo0
192.168.0.0/24     172.17.4.100       UGS            igb0

The OpenVPN process is still running and even the keepalives are working, so there is no restart of the VPN connection.
But the main routing table is now missing the route for 10.0.0.0/8 and 172.16.0.0/12 (which is configured via OpenVPN server config (CSO)).

If I add these routes manually with

Code Select Expand

route add 10.0.0.0/8 172.17.166.37
route add 172.26.0.0/12 172.17.166.37everything is working again (an OpenVPN restart obviously works,too).

Is it a bug that the ovpnc-routes are cleared from the routing when editing the table?

[vielhak]

We did a few more tests. With a classic OpenVPN all routes (including the ovpnc routes) stay in place after /usr/local/etc/rc.routing_configure:

Code Select Expand

root@OPNsense:~ # netstat -rn -4|wc -l
      25     
root@OPNsense:~ # /usr/local/etc/rc.routing_configure
Setting up routes...done.
Setting up gateway monitor...done.
Configuring firewall.......done.
root@OPNsense:~ # netstat -rn -4 | wc -l
      25     
root@OPNsense:~ #

Using OpenVPN Instance method;

Code Select Expand

root@OPNsense:~ # netstat -4 -rn | wc -l
      25     
root@OPNsense:~ # /usr/local/etc/rc.routing_configure
Setting up routes...done.
Setting up gateway monitor...done.
Configuring firewall.......done.
root@OPNsense:~ # netstat -4 -rn | wc -l
      22     
root@OPNsense:~ # pluginctl -s openvpn restart
Service `openvpn[95c5c62f-4134-48d1-be28-03720aa2ed02]' has been restarted.
Service `openvpn[cb360e70-8d4e-46b6-ad6f-57582d92a44f]' has been restarted.
root@OPNsense:~ # netstat -4 -rn | wc -l
      25     
root@OPNsense:~ #
As you can see, with the new instance method there are 3 routes which are lost after calling /usr/local/etc/rc.routing_configure:

Code Select Expand

# netstat -4 -rn | grep ovpnc
10.0.0.0/8         172.17.166.25      UGS          ovpnc3
172.16.0.0/12      172.17.166.25      UGS          ovpnc3
172.17.166.25      link#17            UH           ovpnc3
192.168.0.0/16     172.17.166.25      UGS          ovpnc3

I think, this should not happen and is a bug!?

[vielhak]

After some more testing; the problem is in /usr/local/etc/inc/system.inc:

Code Select Expand

..
            $cmd[] = exec_safe('%s', $rtent['network']);
            if (!empty($rtent['disabled'])) {
                mwexec('/sbin/route delete ' . join(' ', $cmd), true);
                continue;
            }
..
The code only checks if there is a route to e.g. 10.0.0.0/8 which is disabled and if so, it deletes it from the routing table.
It does not consider if the disabled route is to another gateway than the route which is in place. Because we had another circuit in the past there were routes to

Code Select Expand

10.0.0.0/8         
172.16.0.0/12     
192.168.0.0/16     
over another gateway which are disabled in the configuration.
After deleting the obsolete (disabled) routes, everything is working with the new OpenVPN instances, too.
These disabled routes were not in place on my testing device (with the old OpenVPN method), so therefore it was working.
Nevertheless, one could argue about whether this is a bug or a misconfiguration ;) In any case, it now works for us without any restrictions and that's enough for now. Maybe this will help someone with similar problems.