OpenVPN policy routing guide?

[jackoboy9]

So my nat-start file is as follows:

chmod a+rx /jffs/scripts/*

#!/bin/sh

delay 2

touch /tmp/000nat-start

ip rule del fwmark 0x1000
ip rule add fwmark 0x1000 table 111 prio 9991
ip route flush cache

iptables -t mangle -D PREROUTING -i br0 -p tcp -m multiport --dport 35000 -j MARK --set-mark 0x1000/0x1000
iptables -t mangle -A PREROUTING -i br0 -p tcp -m multiport --dport 35000 -j MARK --set-mark 0x1000/0x1000

touch /tmp/000nat-stop

and the system log in my AC68U is...

...
Aug  1 00:00:28 start_nat_rules: apply the nat_rules(/tmp/nat_rules_eth0_eth0)!
Aug  1 00:00:28 custom script: Running /jffs/scripts/nat-start
Aug  1 00:00:29 start_nat_rules: apply the nat_rules(/tmp/nat_rules_eth0_eth0)!
Aug  1 00:00:29 custom script: Running /jffs/scripts/nat-start
Aug  1 00:00:30 kernel: nf_conntrack_rtsp v0.6.21 loading
Aug  1 00:00:30 kernel: nf_nat_rtsp v0.6.21 loading
Aug  1 00:00:31 rc_service: udhcpc 518:notify_rc start_upnp
Aug  1 00:00:31 rc_service: waitting "stop_upnp" via udhcpc ...
Aug  1 00:00:31 miniupnpd[512]: shutting down MiniUPnPd
Aug  1 00:00:32 ddns update: ez-ipupdate: starting...
Aug  1 00:00:32 miniupnpd[694]: HTTP listening on port 50449
Aug  1 00:00:32 miniupnpd[694]: Listening for NAT-PMP/PCP traffic on port 5351
Aug  1 00:00:32 ddns update: connected to nwsrv-ns1.asus.com (103.10.4.108) on port 80.
Aug  1 00:00:33 ddns update: Asus update entry:: return: HTTP/1.1 200 OK^M Date: Sat, 17 Dec 2016 19:08:47 GMT^M Server: Apache^M Content-Length: 0^M Connection: close^M Content-Type: text/html^M ^M
Aug  1 00:00:33 ddns update: retval= 0, ddns_return_code (,200)
Aug  1 00:00:33 ddns update: asusddns_update: 0
Aug  1 00:00:34 ddns: ddns update ok
Aug  1 00:00:34 ntp: start NTP update
Aug  1 00:00:34 openvpn-routing: Refreshing policy rules for client 1
Dec 17 19:08:49 rc_service: ntp 697:notify_rc restart_upnp
Dec 17 19:08:49 miniupnpd[694]: shutting down MiniUPnPd
Dec 17 19:08:49 miniupnpd[717]: HTTP listening on port 54367
Dec 17 19:08:49 miniupnpd[717]: Listening for NAT-PMP/PCP traffic on port 5351
Dec 17 19:08:50 openvpn-routing: Allow WAN access to all VPN clients
Dec 17 19:08:50 rc_service: ntp 697:notify_rc restart_diskmon
Dec 17 19:08:50 disk_monitor: Finish
Dec 17 19:08:51 openvpn-routing: Refreshing policy rules for client 2
Dec 17 19:08:51 openvpn-routing: Allow WAN access to all VPN clients
Dec 17 19:08:51 openvpn-routing: Refreshing policy rules for client 3
Dec 17 19:08:51 openvpn-routing: Allow WAN access to all VPN clients
Dec 17 19:08:52 openvpn-routing: Refreshing policy rules for client 4
Dec 17 19:08:52 openvpn-routing: Allow WAN access to all VPN clients
Dec 17 19:08:52 openvpn-routing: Refreshing policy rules for client 5
Dec 17 19:08:52 disk monitor: be idle
Dec 17 19:08:52 openvpn-routing: Allow WAN access to all VPN clients
Dec 17 19:08:52 rc_service: udhcpc 518:notify_rc start_vpnclient1
Dec 17 19:08:54 openvpn[827]: OpenVPN 2.3.12 arm-unknown-linux-gnu [SSL (OpenSSL)] [LZO] [EPOLL] [MH] [IPv6] built on Nov 11 2016
Dec 17 19:08:54 openvpn[827]: library versions: OpenSSL 1.0.2j  26 Sep 2016, LZO 2.08
Dec 17 19:08:54 openvpn[828]: WARNING: No server certificate verification method has been enabled.  See http://openvpn.net/howto.html#mitm for more info.
Dec 17 19:08:54 openvpn[828]: NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
Dec 17 19:08:54 openvpn[828]: Control Channel Authentication: using 'static.key' as a OpenVPN static key file
Dec 17 19:08:54 kernel: * Make sure sizeof(struct sw_struct)=160 is consistent
Dec 17 19:08:54 openvpn[828]: Attempting to establish TCP connection with [AF_INET]172.111.148.2:80 [nonblock]
Dec 17 19:08:55 kernel: sizeof forward param = 160
Dec 17 19:08:55 openvpn[828]: TCP connection established with [AF_INET]172.111.148.2:80
Dec 17 19:08:55 openvpn[828]: TCPv4_CLIENT link local: [undef]
Dec 17 19:08:55 openvpn[828]: TCPv4_CLIENT link remote: [AF_INET]172.111.148.2:80
Dec 17 19:08:55 openvpn[828]: WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this
Dec 17 19:08:58 openvpn[828]: [PureVPN] Peer Connection Initiated with [AF_INET]172.111.148.2:80
Dec 17 19:08:59 rc_service: udhcpc 518:notify_rc start_firewall
Dec 17 19:08:59 dhcp client: bound 82.46.206.72 via 82.46.206.1 during 427386 seconds.
Dec 17 19:09:00 start_nat_rules: apply the nat_rules(/tmp/nat_rules_eth0_eth0)!
Dec 17 19:09:00 custom script: Running /jffs/scripts/nat-start
Dec 17 19:09:01 openvpn[828]: TUN/TAP device tun11 opened
Dec 17 19:09:01 openvpn[828]: do_ifconfig, tt->ipv6=0, tt->did_ifconfig_ipv6_setup=0
Dec 17 19:09:01 openvpn[828]: /usr/sbin/ip link set dev tun11 up mtu 1500
Dec 17 19:09:01 openvpn[828]: /usr/sbin/ip addr add dev tun11 172.111.148.131/26 broadcast 172.111.148.191
Dec 17 19:09:02 openvpn[828]: updown.sh tun11 1500 1560 172.111.148.131 255.255.255.192 init
Dec 17 19:09:02 rc_service: service 1221:notify_rc updateresolv
Dec 17 19:09:02 rc_service: waitting "start_firewall" via  ...
Dec 17 19:09:06 openvpn-routing: Configuring policy rules for client 1
Dec 17 19:09:06 openvpn-routing: Creating VPN routing table
Dec 17 19:09:06 openvpn-routing: Removing route for 0.0.0.0/1 to tun11 from main routing table
Dec 17 19:09:06 openvpn-routing: Removing route for 128.0.0.0/1 to tun11 from main routing table
Dec 17 19:09:06 openvpn-routing: Adding route for 192.168.1.0/25 to 104.31.18.30 through VPN client 1
Dec 17 19:09:06 openvpn-routing: Adding route for 192.168.1.0/25 to 104.31.19.30 through VPN client 1
Dec 17 19:09:06 openvpn-routing: Completed routing policy configuration for client 1
Dec 17 19:09:06 openvpn[828]: Initialization Sequence Completed
Dec 17 19:09:15 crond[446]: time disparity of 726908 minutes detected
Dec 17 19:09:22 dropbear[1349]: Password auth succeeded for 'admin' from 192.168.1.114:52856

Yet, the torrent client (using port 35000) is not showing the VPN IP but is hsowing my ISP's IP.

 

[jkau]

I am having an issue with OpenVPN, Policy based routing:

Recently, after subscribing to a VPN service, I added on the router an OpenVPN client with a policy for routing one device (IP address) through the VPN. I do not want to use the VPN for everything, just some devices.

I followed the provider’s guidelines. It worked well with one OpenVPN client.

The problems began when adding a second client, different destination, a policy for a different device. When turned on, devices not intended for using the VPN loose internet connection. The device specified for routing through the second client follows incorrectly the first rule. It is a mess!

Relevant settings:

Accept DNS Configuration: Exclusive
Redirect Internet traffic: Policy Rules
Block routed clients if tunnel goes down: Yes

The UI allows up to five OpenVPN clients.

Does anybody have experience with this and may help? In my view it is a bug.

 

[Martineau]

I am having an issue with OpenVPN, Policy based routing:

Recently, after subscribing to a VPN service, I added on the router an OpenVPN client with a policy for routing one device (IP address) through the VPN. I do not want to use the VPN for everything, just some devices.

I followed the provider’s guidelines. It worked well with one OpenVPN client.

The problems began when adding a second client, different destination, a policy for a different device. When turned on, devices not intended for using the VPN loose internet connection. The device specified for routing through the second client follows incorrectly the first rule. It is a mess!

Relevant settings:

Accept DNS Configuration: Exclusive
Redirect Internet traffic: Policy Rules
Block routed clients if tunnel goes down: Yes

The UI allows up to five OpenVPN clients.

Does anybody have experience with this and may help? In my view it is a bug.

It is possible to run multiple VPN client concurrently...four definitely works i.e. VPN Clients 1 thru' 4, but sometimes when adding VPN Client 5, then I have observed strange behaviour but this may be due to my custom environment/configuration/scripts.

I did try to write a crude multiple VPN Client checker, so running this may give you an idea what is wrong:
Multiple VPN clients active for different devices