You can only run the upscript from inside openvpn
As there is nothing to delete that is the normal output of the down script.
I will send you a down script with debugging enabled shortly
1 Like
ovpn-pbr-down:
#!/bin/sh
# Table number
TABLE=101
DEBUG=; set -x; # uncomment/comment to enable/disable debug mode
{
# Start script cleaning up
ip route flush table $TABLE
while ip rule delete from 0/0 to 0/0 table $TABLE; do true; done
# restart routing optional
service network restart
} 2>&1 | logger $([ ${DEBUG+x} ] && echo '-p user.debug') \
-t $(echo $(basename $0) | grep -Eo '^.{0,23}')[$$] &
view output with:
logread | grep -E 'openvpn|debug'
Make sure if you copy files or edit from windows you do not introduce Windows style linefeeds (CR), a common problem which result in scripts not functioning
1 Like
Ok, so here is the relevant part of the client config:
pull-filter ignore "redirect-gateway"
# redirect-gateway def1
data-ciphers AES-256-GCM:AES-128-GCM:AES-128-CBC
data-ciphers-fallback AES-128-CBC
route-up /etc/openvpn/ovpn-pbr-up
down /etc/openvpn/ovpn-pbr-down
and here is the output grabbed upon client disconnection:
daemon.err openvpn(my_client)[27819]: event_wait : Interrupted system call (fd=-1,code=4)
daemon.notice openvpn(my_client)[27819]: TCP/UDP: Closing socket
daemon.notice openvpn(my_client)[27819]: /usr/libexec/openvpn-hotplug route-pre-down my_client tun0 1500 0 192.168.10.50 255.255.255.0 init
daemon.notice openvpn(my_client)[27819]: Closing TUN/TAP interface
daemon.notice openvpn(my_client)[27819]: net_addr_v4_del: 192.168.10.50 dev tun0
daemon.notice openvpn(my_client)[27819]: /usr/libexec/openvpn-hotplug down my_client tun0 1500 0 192.168.10.50 255.255.255.0 init
daemon.notice openvpn(my_client)[27819]: SIGTERM[hard,] received, process exiting
user.debug ovpn-pbr-down[28119]: + ip route flush table 101
user.debug ovpn-pbr-down[28119]: ip: can't send flush request: Operation not permitted
user.debug ovpn-pbr-down[28119]: + ip rule delete from 0/0 to 0/0 table 101
user.debug ovpn-pbr-down[28119]: ip: RTNETLINK answers: Operation not permitted
user.debug ovpn-pbr-down[28119]: + service network restart
user.debug ovpn-pbr-down[28119]: /etc/rc.common: /lib/functions/procd.sh: line 54: can't create /var/lock/procd_network.lock: Permission denied
There is something wrong with access restrictions it seems, no idea what.
Have you tried to reboot?
So, same errors, even after the reboot. However, the pbr seems working! Could such errors compromise anything?
No I do not think it compromises anything but still wondering what causes it.
Anyway glad it is working 
1 Like
Me too. It's quite annoying seeing this error. Would you mind suggesting how I could investigate further?
I will let you know if I come up with something
1 Like
Thank you once again for your precioius help!
Hello @egc, I'm sorry for writing another time about this topic, but I'm facing a little issue with this configuration. I followed this guide to set up a another VPN Server: https://openwrt.org/docs/guide-user/services/vpn/openvpn/server, that should run along with the point-to-point client of this forum topic. (Note that I had to set:
uci add_list firewall.lan.device="tun+"
Not sure if it can be a problem with the client). The point-to-point client was using tun0, however when I restarted openvpn with service openvpn restart, the client started using tun1, since tun0 has been already used by the VPN server. This completely broke the routing with the custom script. The problem persists even if I manually restart the point-to-point client.
Is there a way to take this situation into account programmatically? Please, feel free to skip this question, since it's just a temporary workaround while waiting to rely on pbr.
Of course that is a problem if you are running more than one tun interface e.g. running an OpenVPN server and OpenVPN client, tun+ means all tunX interfaces.
I personally use tun1 for my OpenVPN client and tun2 for my OpenVPN server.
Meaning in the OpenVPN client config you specify: dev tun1 and for the OpenVPN server you specify: dev tun2.
The firewall rules have to be changed accordingly
1 Like
Thank you again for your help, @egc
1 Like
Hello again @egc, excuse me if I take advantage of this topic again. Finally, I fixed the incompatibility and I installed pbr-luci-app. However, now I can't see tun1 interface in the available interfaces in pbr:
From ifconfig, I see that tun1 is running properly, but it is not listed in the Interface dropdown list.
As you might remember, I followed this guide to set up the OpenVPN client. Since I'm on the Snapshot version of OpenWRT, I did not set up an explicit OpenVPN interface, but I just attached tun0 to the WAN covered devices.
Is there a way make pbr manage this traffic?
Yes the PBR package looks at the interfaces which are set up with uci so you have to add an interface e.g. in etc/config/network:
config interface 'vpn_tun1'
option proto 'none'
option device 'tun1'
... aaand it works, thank you! I'm going to summarize here all the settings, for those who might be interested in the whole picture.
OpenVPN client config
client
dev tun1
remote <SERVER IP> 1194 tcp
# filter out settings pushed by the Server
pull-filter ignore "redirect-gateway"
# redirect-gateway def1
# fallback for OpenVPN Servers with old cyphers
data-ciphers AES-256-GCM:AES-128-GCM:AES-128-CBC
data-ciphers-fallback AES-128-CBC
Network:
config interface 'OpenVPN'
option proto 'none'
option device 'tun1'
Firewall:
config zone
option name 'wan'
option input 'REJECT'
option output 'ACCEPT'
option forward 'REJECT'
option masq '1'
option mtu_fix '1'
list network 'wan'
list network 'wan6'
list network 'OpenVPN'
pbr:
config policy
option name 'Route_all_to_OpenVPN'
option src_addr '192.168.1.100'
option interface 'OpenVPN'
In pbr, you might want to set:
config pbr 'config'
...
option strict_enforcement '0'
in order to fallback to WAN when the tunnel is not available. Otherwise the traffic is not routed anywhere.
Thanks again to @egc for the help!
1 Like
Hello, I've noticed that DNS requests are resolved locally instead of being sent through the tunnel. It's fine for my case. Out of curiosity: how can I route DNS requests through the tunnel as well? Probably, it's something at the VPN config level.
This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.