OpenVPN Split tunnel routing

Hi, We’ve been running VyOS and OpenVPN for a long time.
We’ve recently moved to the latest 1.5 rolling release and we’ve found the routing behavior seems to have changed slightly.

If we use the OpenVPN community client or Tunnelblick to connect to the split tunneled gateway, then everything works as expected.
If we use the OpenVPN connect client with the same client ovpn file then the client connects but the routing fails to work and a message on the vpn client appears as;
“exception parsing IPv4 route: [route] [] [] [][0]: tun_prop_route_error: route destinations other than vpn_gateway or net_gateway are not supported”

For whatever reason the openvpn connect client was working on a 1.4 rolling release release but not on 1.5 rolling release.

What setting in Vyos controls this behavior so that the Vyos OpenVPN gateway is compatible with the OpenVPN Connect client? (we are routing different subnets through the gateway)


This thread may be helpful:
It contains some good debugging steps you could follow, especially comparing the generated OpenVPN config between the VyOS versions (look in /run/openvpn/*.conf).
Good luck!

we are using a new version of openvpn , this is 2.6.3 .if it possible to share full configuration from this device . it would be helpful .

thanks guys, If I look at the /run/openvpn/vtun0.conf file, the line corresponding to the message above is;

push "route 0"

and the section of the /config/config.boot file that this relates to looks like this;

server {
       push-route {
      subnet ""
      topology "subnet"

so I now take a look at what appears to be some of the code relating to OpenVPN Connect Client v3 which includes the error I’m getting specifically on the v3 client;

 // Check the target of a route.
    // Return true if route should be added or false if route should be excluded.
    static bool route_target(const Option &o, const size_t target_index)
        if (o.size() >= (target_index + 1))
            const std::string &target = o.ref(target_index);
            if (target == "vpn_gateway")
                return true;
            else if (target == "net_gateway")
                return false;
                throw tun_prop_route_error("route destinations other than vpn_gateway or net_gateway are not supported");
            return true;

there seems to be multiple references on the net that the Connect v3 client may have issues unless the option to the openvpn server can be specified as;

push "route vpn_gateway"

And I guess that would match to the code of the v3 client?
Any thoughts before I waste any more time on this?
How would I force the “vpn_gateway” option into the command syntax of VyOS into the config.boot file?
It would take me several hours where I could recreate a minimal config to demonstrate the issue again (using a config I could share), but happy to do this if its the only way to resolve this.

Take a look at the openvpn-option configuration option. You can use this to force a statement into the generated OpenVPN config file.

based on this theard , I think you have a similar issues :

Pushed route not adding - OpenVPN Support Forum

Could you try replace this command on /run/openvpn/vtun0.conf ?

push "route"

restart the openvpn process and tell us if it works for you .

thanks guys,
I modified the /run/openvpn/vtun0.conf file as per below and things work!

$ sudo su -
# vi /run/openvpn/vtun0.conf
push "route 0"
to be;
push "route"
# reset openvpn interface vtun0

and then things work as expected on both OpenVPN Connect v3 client and OpenVPN Community Client
I also found that changing the line to this also worked on both clients;

push "route vpn_gateway 0"

So what needs to change on VyOS configuration interface to allow this change to persist as when VyOS is rebooted, the /run/openvpn/vtun0.conf is recreated?

(I didn’t realise the file could be modified directly like this and openvpn restarted independently, so this is great from a trouble shooting perspective)
thanks again.


I would like to recommend open a bug report , also we are going to need the full configuration to replicate and applied the appropriate configuration :

so our developers can solved it in the code.

Thanks, I did attempt to create a logon on the dev.vyos site (as it doesn’t appear to use SSO with the forum) but waiting on my account to be “approved”.

Incidentally @marc_s , you can’t set custom routes via the openvpn-option as openvpn-option is only for options on the openvpn binary when it starts up and the routing is not part of that. (I think).

I had a look at the source code and the file that triggers this behavior seems to be;
So to create a usable patch file;

# cp /usr/share/vyos/templates/openvpn/server.conf.j2 /usr/share/vyos/templates/openvpn/
# vi /usr/share/vyos/templates/openvpn/
modify line 82;
push "route {{ route | address_from_cidr }} {{ route | netmask_from_cidr }} {{ subnet | first_host_address ~ ' ' ~ route_config.metric if route_config.metric is vyos_defined }}"
push "route {{ route | address_from_cidr }} {{ route | netmask_from_cidr }} {{ 'vpn_gateway' ~ ' ' ~ route_config.metric if route_config.metric is vyos_defined }}"

then generate a patch file;

# diff -u /usr/share/vyos/templates/openvpn/server.conf.j2 /usr/share/vyos/templates/openvpn/ > /config/RoutePatchFile

so now when you want to apply that patch file (say after each VyOS update - until this gets incorporated into the build);

patch /usr/share/vyos/templates/openvpn/server.conf.j2 </config/RoutePatchFile

and the thing works as expected now for both the community edition and the Connect v3 client.
When my dev account is approved, I’ll open up a ticket and suggest the patch file.

Hope this helps others who might not be familiar with linux patch/diff commands (I had to Google!)


Good work with the patch @vy-testing, that’s much better than mucking about with openvpn-option anyway. The man pages for OpenVPN says that pushing routes is possible using a command line option (--push option), but that’s a moot point given your patch makes it possible to fix this transparently.