OpenWrt 19.07 OpenVPN client does not pass configuration parameters to UP/ROUTE-UP scripts

Hi All!

I was unable to set up my VPN routing because OpenVPN tunnels are not working correctly on a stable build 19.07
That is all because some of the most important configuration parameter to be passed to UP/ROUTE-UP scripts are ignored.

According to OpenVPN manual the following parameters SHOULD be passed (in deed many times more, but these parameters are critical for my routing config):

dev
ifconfig_local
ifconfig_remote
route_vpn_gateway

After setting up my 'up' and 'route-up' scripts I figured out that some of parameters are lost somewhere.
The most important parameters like $ifconfig_remote and $route_vpn_gateway are lost or ignored along the way.

After a little digging and logging I can confirm that only a subset of mandatory parameters are passed to UP/ROUTE-UP scripts (see log below).
.

Please advice me how to deal with this mess.

.
My script is configured as follows:
This script works fine on other systems (Ubuntu, AdvancedTomato), but not on stable build OpenWRT 19.07.

...
route-noexec
route-delay 2
script-security 2
up /etc/openvpn/pbr-ovpn-up.sh
route-up /etc/openvpn/pbr-ovpn-up.sh
...

A small sample from the syslog (I have dumped env variables from the script to the syslog):

...
Sat Apr 17 19:45:57 2021 user.notice pbr-ovpn-up [31764]: dev='tun0'
Sat Apr 17 19:45:57 2021 user.notice pbr-ovpn-up [31764]: dev_type='tun'
Sat Apr 17 19:45:57 2021 user.notice pbr-ovpn-up [31764]: ifconfig_broadcast='10.8.0.255'
Sat Apr 17 19:45:57 2021 user.notice pbr-ovpn-up [31764]: ifconfig_local='10.8.0.3'
Sat Apr 17 19:45:57 2021 user.notice pbr-ovpn-up [31764]: ifconfig_netmask='255.255.255.0'
Sat Apr 17 19:45:57 2021 user.notice pbr-ovpn-up [31764]: link_mtu='1574'
Sat Apr 17 19:45:57 2021 user.notice pbr-ovpn-up [31764]: proto_1='tcp-client'
Sat Apr 17 19:45:57 2021 user.notice pbr-ovpn-up [31764]: script_context='init'
Sat Apr 17 19:45:57 2021 user.notice pbr-ovpn-up [31764]: script_type='route-up'
Sat Apr 17 19:45:57 2021 user.notice pbr-ovpn-up [31764]: tun_mtu='1500'
...
Sat Apr 17 19:45:55 2021 user.notice pbr-ovpn-up [31637]: dev='tun0'
Sat Apr 17 19:45:55 2021 user.notice pbr-ovpn-up [31637]: dev_type='tun'
Sat Apr 17 19:45:55 2021 user.notice pbr-ovpn-up [31637]: ifconfig_broadcast='10.8.0.255'
Sat Apr 17 19:45:55 2021 user.notice pbr-ovpn-up [31637]: ifconfig_local='10.8.0.3'
Sat Apr 17 19:45:55 2021 user.notice pbr-ovpn-up [31637]: ifconfig_netmask='255.255.255.0'
Sat Apr 17 19:45:55 2021 user.notice pbr-ovpn-up [31637]: link_mtu='1574'
Sat Apr 17 19:45:55 2021 user.notice pbr-ovpn-up [31637]: proto_1='tcp-client'
Sat Apr 17 19:45:55 2021 user.notice pbr-ovpn-up [31637]: script_context='init'
Sat Apr 17 19:45:55 2021 user.notice pbr-ovpn-up [31637]: script_type='up'
Sat Apr 17 19:45:55 2021 user.notice pbr-ovpn-up [31637]: tun_mtu='1500'
1 Like
1 Like

I have such a record in the syslog:

Sat Apr 17 19:45:55 2021 daemon.notice openvpn(vul_fra_client2)[31499]: PUSH: Received control message: 'PUSH_REPLY,route-gateway 10.8.0.1,topology subnet,ping 10,ping-restart 120,socket-flags TCP_NODELAY,ifconfig 10.8.0.3 255.255.255.0,peer-id 0'

I see the gateway address of 10.8.0.1 passed to client by by the server.
But I see neither ifconfig_remote nor route_vpn_gateway environment variables are passed to the script...

UPDATE:
According to OpenVPN official documentation (environment variables section):

route_vpn_gateway:
The default gateway used by --route options, as specified in either the --route-gateway option or the second parameter to --ifconfig when --dev tun is specified.

And I have a record in the syslog with a 'route-gateway' option passed to client:

openvpn(client2)[31499]: PUSH: Received control message: 'PUSH_REPLY,route-gateway 10.8.0.1,topology subnet,ping 10,ping-restart 120,socket-flags TCP_NODELAY,ifconfig 10.8.0.3 255.255.255.0,peer-id 0

As we can see 'route-gateway' directive was passed to client but was NOT re-transmitted to the UP scrips as a 'route_vpn_gateway' environment variable.

It's a bug.

UPDATE 2:
Filed a bug to the bugtracker of 'packages':

2 Likes