Menu
What's new
By:
Filters Better Search

Redirect Internet traffic misbehaving

  • SNBForums Code of Conduct

    SNBForums is a community for everyone, no matter what their level of experience.

    Please be tolerant and patient of others, especially newcomers. We are all here to share and learn!

    The rules are simple: Be patient, be nice, be helpful or be gone!

canufrank

canufrank

Occasional Visitor
If I set 'Redirect Internet traffic' to No, all my devices are connecting through the VPN.
As expected, when set to All Traffic, traffic also uses the VPN connection.
Only when set to Policy Rules do my clients revert back to my ISP.
Am I missing the meaning of this setting?
 
Most tunnel providers will push a route that will automatically redirect traffic. Check the OpenVPN documentation, there's a setting to ignore routes pushed by the provider.
 
Thanks Eric. I thought that the GUI setting might be adding 'route-nopull' for me. Can you tell me what the GUI setting actually does, and how it differs from what 'Policy Rules' does?

edit: Changing references to 'route no-pull'.
 
Last edited:
canufrank said:
Thanks Eric. I thought that the GUI setting might be adding 'route-nopull' for me. Can you tell me what the GUI setting actually does, and how it differs from what 'Policy Rules' does?

edit: Changing references to 'route no-pull'.
Click to expand...

It adds "redirect-gateway def1".
 
OK, I've added a rule and can see it (1201: from 192.168.0.46 lookup vpn1 [where vpn1=111]).
I have no other modifications to rules or tables. Yet the machine has no connectivity at all. The table looks like:
Code: 
frank@AC68U:/tmp/home/root# ip route show table vpn1
104.175.4.1 dev eth0  scope link
192.168.0.0/24 dev br0  proto kernel  scope link  src 192.168.0.1
104.175.4.0/22 dev eth0  proto kernel  scope link  src 104.175.4.xxx
127.0.0.0/8 dev lo  scope link
prohibit default

The VPN is working AFAIK because I can get connectivity by pointing the machine at another table. e.g.:
Code: 
ip rule add fwmark 16 table 11 prio 1100
ip route add default via $(ifconfig tun11| grep -o "addr:.* P" |tr -d "a-zP :") dev tun11 table 11
echo 0 > /proc/sys/net/ipv4/conf/tun11/rp_filter
iptables -t mangle -I PREROUTING -s 192.168.0.46 -j MARK --set-mark 16

I assume it is the 'prohibit default', but wonder what in my config is causing the issue with table 111?

Edit: It does appear to be prohibit default. The following also restores connectivity:
Code: 
ip route del table 111
ip route add default via $tun_ip dev tun11 table 111

Again, I want to know where my config might be messed up.
 
Last edited:
The 'prohibit default' is added when you have Block routed clients if tunnel goes down set to Yes and the system thinks the tunnel is down.
 
OK, if that rule works for others, is there another reason that my routed client is getting no connectivity with what I think it is a default config? Note: the tunnel is definitely up.
 
Last edited:
This is the syslog after turning client1 on:
Code: 
Jan  8 16:33:14 rc_service: httpd 498:notify_rc start_vpnclient1
Jan  8 16:33:14 kernel: tun: Universal TUN/TAP device driver, 1.6
Jan  8 16:33:14 kernel: tun: (C) 1999-2004 Max Krasnyansky <maxk@qualcomm.com>
Jan  8 16:33:14 openvpn[3054]: OpenVPN 2.3.7 arm-unknown-linux-gnu [SSL (OpenSSL)] [LZO] [EPOLL] [MH] [IPv6] built on Jul 16 2015
Jan  8 16:33:14 openvpn[3054]: library versions: OpenSSL 1.0.2d 9 Jul 2015, LZO 2.08
Jan  8 16:33:14 openvpn[3055]: NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
Jan  8 16:33:14 openvpn[3055]: Socket Buffers: R=[122880->131072] S=[122880->131072]
Jan  8 16:33:14 openvpn[3055]: UDPv4 link local: [undef]
Jan  8 16:33:14 openvpn[3055]: UDPv4 link remote: [AF_INET]172.98.67.55:1194
Jan  8 16:33:14 openvpn[3055]: TLS: Initial packet from [AF_INET]172.98.67.55:1194, sid=b43b5da2 a4c0a388
Jan  8 16:33:14 openvpn[3055]: WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this
Jan  8 16:33:14 openvpn[3055]: VERIFY OK: depth=1, C=US, ST=OH, L=Columbus, O=Private Internet Access, CN=Private Internet Access CA, emailAddress=secure@privateinternetaccess.com
Jan  8 16:33:14 openvpn[3055]: Validating certificate key usage
Jan  8 16:33:14 openvpn[3055]: ++ Certificate has key usage  00a0, expects 00a0
Jan  8 16:33:14 openvpn[3055]: VERIFY KU OK
Jan  8 16:33:14 openvpn[3055]: Validating certificate extended key usage
Jan  8 16:33:14 openvpn[3055]: ++ Certificate has EKU (str) TLS Web Server Authentication, expects TLS Web Server Authentication
Jan  8 16:33:14 openvpn[3055]: VERIFY EKU OK
Jan  8 16:33:14 openvpn[3055]: VERIFY OK: depth=0, C=US, ST=CA, L=LosAngeles, O=Private Internet Access, OU=Private Internet Access, CN=Private Internet Access, name=Private Internet Access, emailAddress=secure@privateinternetaccess.com
Jan  8 16:33:15 openvpn[3055]: Data Channel Encrypt: Cipher 'BF-CBC' initialized with 128 bit key
Jan  8 16:33:15 openvpn[3055]: Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Jan  8 16:33:15 openvpn[3055]: Data Channel Decrypt: Cipher 'BF-CBC' initialized with 128 bit key
Jan  8 16:33:15 openvpn[3055]: Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Jan  8 16:33:15 openvpn[3055]: Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 2048 bit RSA
Jan  8 16:33:15 openvpn[3055]: [Private Internet Access] Peer Connection Initiated with [AF_INET]172.98.67.55:1194
Jan  8 16:33:17 openvpn[3055]: SENT CONTROL [Private Internet Access]: 'PUSH_REQUEST' (status=1)
Jan  8 16:33:17 openvpn[3055]: PUSH: Received control message: 'PUSH_REPLY,redirect-gateway def1,dhcp-option DNS 209.222.18.222,dhcp-option DNS 209.222.18.218,ping 10,comp-lzo no,route 10.182.1.1,topology net30,ifconfig 10.182.1.6 10.182.1.5'
Jan  8 16:33:17 openvpn[3055]: Options error: option 'redirect-gateway' cannot be used in this context ([PUSH-OPTIONS])
Jan  8 16:33:17 openvpn[3055]: Options error: option 'dhcp-option' cannot be used in this context ([PUSH-OPTIONS])
Jan  8 16:33:17 openvpn[3055]: Options error: option 'dhcp-option' cannot be used in this context ([PUSH-OPTIONS])
Jan  8 16:33:17 openvpn[3055]: Options error: option 'route' cannot be used in this context ([PUSH-OPTIONS])
Jan  8 16:33:17 openvpn[3055]: OPTIONS IMPORT: timers and/or timeouts modified
Jan  8 16:33:17 openvpn[3055]: OPTIONS IMPORT: LZO parms modified
Jan  8 16:33:17 openvpn[3055]: OPTIONS IMPORT: --ifconfig/up options modified
Jan  8 16:33:17 openvpn[3055]: TUN/TAP device tun11 opened
Jan  8 16:33:17 openvpn[3055]: TUN/TAP TX queue length set to 100
Jan  8 16:33:17 openvpn[3055]: do_ifconfig, tt->ipv6=0, tt->did_ifconfig_ipv6_setup=0
Jan  8 16:33:17 openvpn[3055]: /usr/sbin/ip link set dev tun11 up mtu 1500
Jan  8 16:33:17 openvpn[3055]: /usr/sbin/ip addr add dev tun11 local 10.182.1.6 peer 10.182.1.5
Jan  8 16:33:20 openvpn-routing: Configuring policy rules for client 1
Jan  8 16:33:20 openvpn-routing: Creating VPN routing table
Jan  8 16:33:20 openvpn-routing: Removing rule 1201 from routing policy
Jan  8 16:33:20 openvpn-routing: Added 192.168.0.46 to 0.0.0.0 through VPN to routing policy
Jan  8 16:33:20 openvpn-routing: Tunnel re-established, restoring WAN access to clients
Jan  8 16:33:20 openvpn-routing: Completed routing policy configuration
Jan  8 16:33:20 custom script: Running /jffs/scripts/openvpn-event (args: )
Jan  8 16:33:20 openvpn[3055]: Initialization Sequence Completed
and some settings:
 
Last edited:
First thing I'd try is working on eliminating the options error messages. I also use PIA and don't see anything like that as I come up (actually, you can leave the entire Custom Configuration section blank as the defaults will work fine)

I can't see your settings (for some reason you can't link to a OneDrive image from the forum).
 
Well, I added 3 lines back to my config:
Code: 
auth-nocache
script-security 2
#route-up /mnt/sda1/routeup.sh
routeup.sh simply reads:
Code: 
#!/bin/sh

dbg=
logger -t " $(basename $0)[$$]" " Skipping $0"
return 0

a whole bunch of other stuff
With the route-up script disabled, syslog reads:
Code: 
Jan  8 19:12:49 openvpn[913]: SENT CONTROL [Private Internet Access]: 'PUSH_REQUEST' (status=1)
Jan  8 19:12:49 openvpn[913]: PUSH: Received control message: 'PUSH_REPLY,redirect-gateway def1,dhcp-option DNS 209.222.18.222,dhcp-option DNS 209.222.18.218,ping 10,comp-lzo no,route 10.103.1.1,topology net30,ifconfig 10.103.1.6 10.103.1.5'
Jan  8 19:12:49 openvpn[913]: OPTIONS IMPORT: timers and/or timeouts modified
Jan  8 19:12:49 openvpn[913]: OPTIONS IMPORT: LZO parms modified
Jan  8 19:12:49 openvpn[913]: OPTIONS IMPORT: --ifconfig/up options modified
Jan  8 19:12:49 openvpn[913]: OPTIONS IMPORT: route options modified
Jan  8 19:12:49 openvpn[913]: OPTIONS IMPORT: --ip-win32 and/or --dhcp-option options modified
Jan  8 19:12:49 openvpn[913]: TUN/TAP device tun11 opened
Jan  8 19:12:49 openvpn[913]: TUN/TAP TX queue length set to 100
Jan  8 19:12:49 openvpn[913]: do_ifconfig, tt->ipv6=0, tt->did_ifconfig_ipv6_setup=0
Jan  8 19:12:49 openvpn[913]: /usr/sbin/ip link set dev tun11 up mtu 1500
Jan  8 19:12:49 openvpn[913]: /usr/sbin/ip addr add dev tun11 local 10.103.1.6 peer 10.103.1.5
Jan  8 19:12:51 openvpn[913]: /usr/sbin/ip route add 172.98.67.96/32 via 104.175.4.1
Jan  8 19:12:51 openvpn[913]: /usr/sbin/ip route add 0.0.0.0/1 via 10.103.1.5
Jan  8 19:12:51 openvpn[913]: /usr/sbin/ip route add 128.0.0.0/1 via 10.103.1.5
Jan  8 19:12:51 openvpn[913]: /usr/sbin/ip route add 10.103.1.1/32 via 10.103.1.5
Jan  8 19:12:51 openvpn-routing: Configuring policy rules for client 1
Jan  8 19:12:51 openvpn-routing: Creating VPN routing table
Jan  8 19:12:51 openvpn-routing: Removing route for 10.103.1.1 to tun11 from routing tables
Jan  8 19:12:51 openvpn-routing: Removing route for 0.0.0.0/1 to tun11 from routing tables
Jan  8 19:12:51 openvpn-routing: Removing route for 128.0.0.0/1 to tun11 from routing tables
Jan  8 19:12:51 openvpn-routing: Removing rule 1201 from routing policy
Jan  8 19:12:51 openvpn-routing: Added 192.168.0.46 to 0.0.0.0 through VPN to routing policy
Jan  8 19:12:51 openvpn-routing: Tunnel re-established, restoring WAN access to clients
Jan  8 19:12:51 openvpn-routing: Completed routing policy configuration
Jan  8 19:12:51 custom script: Running /jffs/scripts/openvpn-event (args: )
Jan  8 19:12:51 openvpn[913]: Initialization Sequence Completed
Jan  8 19:13:12 crond[502]: time disparity of 537312 minutes detected
With the route-up script enabled, syslog reads:
Code: 
Jan  8 19:08:19 openvpn[901]: SENT CONTROL [Private Internet Access]: 'PUSH_REQUEST' (status=1)
Jan  8 19:08:19 openvpn[901]: PUSH: Received control message: 'PUSH_REPLY,redirect-gateway def1,dhcp-option DNS 209.222.18.222,dhcp-option DNS 209.222.18.218,ping 10,comp-lzo no,route 10.183.1.1,topology net30,ifconfig 10.183.1.6 10.183.1.5'
Jan  8 19:08:19 openvpn[901]: OPTIONS IMPORT: timers and/or timeouts modified
Jan  8 19:08:19 openvpn[901]: OPTIONS IMPORT: LZO parms modified
Jan  8 19:08:19 openvpn[901]: OPTIONS IMPORT: --ifconfig/up options modified
Jan  8 19:08:19 openvpn[901]: OPTIONS IMPORT: route options modified
Jan  8 19:08:19 openvpn[901]: OPTIONS IMPORT: --ip-win32 and/or --dhcp-option options modified
Jan  8 19:08:19 openvpn[901]: TUN/TAP device tun11 opened
Jan  8 19:08:19 openvpn[901]: TUN/TAP TX queue length set to 100
Jan  8 19:08:19 openvpn[901]: do_ifconfig, tt->ipv6=0, tt->did_ifconfig_ipv6_setup=0
Jan  8 19:08:19 openvpn[901]: /usr/sbin/ip link set dev tun11 up mtu 1500
Jan  8 19:08:19 openvpn[901]: /usr/sbin/ip addr add dev tun11 local 10.183.1.6 peer 10.183.1.5
Jan  8 19:08:21 openvpn[901]: /usr/sbin/ip route add 172.98.67.79/32 via 104.175.4.1
Jan  8 19:08:21 openvpn[901]: /usr/sbin/ip route add 0.0.0.0/1 via 10.183.1.5
Jan  8 19:08:21 openvpn[901]: /usr/sbin/ip route add 128.0.0.0/1 via 10.183.1.5
Jan  8 19:08:21 openvpn[901]: /usr/sbin/ip route add 10.183.1.1/32 via 10.183.1.5
Jan  8 19:08:21  routeup.sh[1016]:  Skipping /mnt/sda1/routeup.sh
Jan  8 19:08:21 openvpn[901]: Initialization Sequence Completed
Jan  8 19:08:45 crond[501]: time disparity of 537308 minutes detected
The obvious difference being that if I specify a route-up script, openvpn-routing (and /jffs/scripts/openvpn-event) are never run. Consequences include the inability of the routed machine to connect to anything outside the router.
 
For now, I'm working around the issue by having openvpn-event invoke my script:
Code: 
#!/bin/sh

    myrouteup=/mnt/sda1/routeup.sh
    log(){ /usr/bin/logger -s -t " $(basename $0)[$$]" "   " "$@"; }

    if [ -c /dev/net/tun ]; then
        if [ -s $myrouteup ]; then
            log "Running $myrouteup by proxy"
            $myrouteup
        else
            log "Cannot find $myrouteup"
        fi
    else
        log "Tunnel down- nop"
    fi

return 0
 
route-up replaces a script that is generated by openvpn itself. The proper way to handle it is with an openvpn-event script as you found (which passes the tunnel id as a parameter and sets an environment variable you can query, script_type, that defines what event is happening). You should check who's calling openvpn-event though, otherwise your script will get called multiple times

EDIT: Here's a section of my openvpn-event script.....

Code: 
# Determine caller
P1=$1
case "$P1" in
        "tun11")
                vpn_name="client1"
                ;;
        "tun12")
                vpn_name="client2"
                ;;
        "tun21")
                vpn_name="server1"
                ;;
        "tun22")
                vpn_name="server2"
                ;;
        *)
                vpn_name=""
                ;;
esac
 
# Call appropriate script based on script_type
vpn_script_name="vpn$vpn_name-$script_type"
 
# Check VPN mode
vpn_rgw="vpn_"$vpn_name"_rgw"
VPN_REDIR=$(nvram get $vpn_rgw)

This, for example, could later call a vpnclient1-route-up script (variable vpn_script_name). And I check the policy mode to be able to do different things depending on if policy based routing is turned on.
 
Last edited:
Hi @john9527 , I seem to be getting different behavior than you. If the openvpn-event is called while the client is being started, NO args are being passed. If the client is shutting down, then a single arg is received where the interface is the first word. $(echo $1|cut -d" " -f1). I'm currently testing for a lack of args right now:
Code: 
if [ -c /dev/net/tun -a $# -eq 0 ]; then
   # processing
else
   # tunnel down, or being shut down
fi

I also have some new behavior that is breaking client communications. With no changes made in the UI and all script (including openvpn-event) scrapped, table 111 has grown from the 5 lines posted above to these 10 lines (including a default rule despite such settings as Block Client remaining the same):
Code: 
104.175.4.1 dev eth0  scope link
10.116.1.1 via 10.116.1.5 dev tun11
172.98.67.120 via 104.175.4.1 dev eth0
10.116.1.5 dev tun11  proto kernel  scope link  src 10.116.1.6
192.168.73.0/24 dev br0  proto kernel  scope link  src 192.168.73.1
104.175.4.0/22 dev eth0  proto kernel  scope link  src 104.175.4.205
127.0.0.0/8 dev lo  scope link
0.0.0.0/1 via 10.116.1.5 dev tun11
128.0.0.0/1 via 10.116.1.5 dev tun11
default via 10.116.1.5 dev tun11
config simply reads:
Code: 
auth-nocache
script-security 2
#route-up being called by openvpn-event
I'm perplexed as to what happened. Rebooted a few times with no change.
 
What's NOT happening is that openvpn-routing is accomplishing what it is logging.
Code: 
Jan  8 23:35:55 openvpn-routing: Configuring policy rules for client 1
Jan  8 23:35:55 openvpn-routing: Creating VPN routing table
*** Jan  8 23:35:55 openvpn-routing: Removing route for 10.125.1.1 to tun11 from routing tables
*** Jan  8 23:35:55 openvpn-routing: Removing route for 0.0.0.0/1 to tun11 from routing tables
*** Jan  8 23:35:55 openvpn-routing: Removing route for 128.0.0.0/1 to tun11 from routing tables
Jan  8 23:35:55 openvpn-routing: Removing rule 1101 from routing policy
Jan  8 23:35:55 openvpn-routing: Added 192.168.73.46 to 0.0.0.0 through VPN to routing policy
Jan  8 23:35:55 openvpn-routing: Tunnel re-established, restoring WAN access to clients
Jan  8 23:35:56 openvpn-routing: Completed routing policy configuration
*** Despite the log, these are exactly the entries that are remaining in table 111, plus 2 others that the log doesn't reference.

Update 1: Upgraded firmware to 380.57 (was on AC68U 378.55) with no difference.
Update 2: Factory restored router settings with no difference.
 
Last edited:
Jan 8 23:35:55 openvpn-routing: Configuring policy rules for client 1
Jan 8 23:35:55 openvpn-routing: Creating VPN routing table
*** Jan 8 23:35:55 openvpn-routing: Removing route for 10.125.1.1 to tun11 from routing tables
*** Jan 8 23:35:55 openvpn-routing: Removing route for 0.0.0.0/1 to tun11 from routing tables
*** Jan 8 23:35:55 openvpn-routing: Removing route for 128.0.0.0/1 to tun11 from routing tables

*** Despite the log, these are exactly the entries that are remaining in table 111, plus 2 others that the log doesn't reference.
Click to expand...

Oh yes it is!...... the messages are telling you that it is deleting the entries from table main not table 111 - otherwise if it didn't everything would be routed by VPN Client 1 :eek:

You have already proved that table 111 effectively needs to consist of ONLY one line

Code: 
default   via   xxx.xxx.xxx.xxx   dev   tun11
or in the case when the VPN is not connected and you have explicitly specified to NOT allow use of the WAN
Code: 
prohibit   default

and your routing errors will lie in the comparison between the tun11 entries in these two tables.

Code: 
ip   route   show   table   main

ip   route   show   table   111

I think that is why attempting Selective routing via multiple VPNs may now be broken (by the Kernel) with the unfortunate replication of invalid table main entries by RMerlin's /usr/sbin/vpnrouting.sh script; but how would his script know that it is blindly copying invalid routes?

I suggest you ensure you temporarily have no such /jffs/scrips/openvpn-event script and no directives specified in the VPN Client, and temporarily disable VPN Client 1 'Start with WAN'


Reboot, then check the contents of

ip route show table main
ip route show table 111
ip rule

start the VPN client manually, and recheck

ip route show table main
ip route show table 111
ip rule

Post (redacted) output of the three commands if you need further assistance.

At this point it is best to start adding your desired custom selected routing directives manually via the command line or via a separate script.
 
Last edited:
Martineau said:
the messages are telling you that it is deleting the entries from table main not table 111
Click to expand...
I read the plural 'Removing route from routing tables' to imply multiple tables, especially as the untouched table 111 from earlier yesterday did not have those entries either. I don't know at what point they appeared in said table.
Martineau said:
I think that is why attempting Selective routing via multiple VPNs may now be broken
Click to expand...
I'm only using one VPN- client 1
Martineau said:
My advice is to never create /jffs/scripts/openvpn-event
Click to expand...
I didn't after the factory reset. I still had the issue that the default set of rules was not allowing connectivity by the policy routed client. (As mentioned earlier, I had the inverse issue when using route-up: that the built-in openvpn-routing script and openvpn-event are not run at all. The end result is the same.)

Following are the results of the commands:
Code: 
/tmp/mnt/sda1 # ls /jffs/scripts -la
drwxr-xr-x  2 frank  root  0 Jan  9 02:37 .
drwxr-xr-x  6 frank  root  0 Jan  9 02:56 ..

ip rule (RPDB)
0:   from all lookup local
32766:   from all lookup main
32767:   from all lookup default

ip route show (main)
104.175.4.1 dev vlan2  scope link
192.168.0.0/24 dev br0  proto kernel  scope link  src 192.168.0.1
104.175.4.0/22 dev vlan2  proto kernel  scope link  src 104.175.4.205
127.0.0.0/8 dev lo  scope link
default via 104.175.4.1 dev vlan2

ip route show table 111


ip rule (RPDB)
0:   from all lookup local
1101:   from 192.168.0.46 lookup 111
32766:   from all lookup main
32767:   from all lookup default

ip route show (main)
10.128.1.5 dev tun11  proto kernel  scope link  src 10.128.1.6
104.175.4.1 dev vlan2  scope link
172.98.67.95 via 104.175.4.1 dev vlan2
192.168.0.0/24 dev br0  proto kernel  scope link  src 192.168.0.1
104.175.4.0/22 dev vlan2  proto kernel  scope link  src 104.175.4.205
127.0.0.0/8 dev lo  scope link
default via 104.175.4.1 dev vlan2

ip route show table 111
10.128.1.5 dev tun11  proto kernel  scope link  src 10.128.1.6
104.175.4.1 dev vlan2  scope link
172.98.67.95 via 104.175.4.1 dev vlan2
10.128.1.1 via 10.128.1.5 dev tun11
192.168.0.0/24 dev br0  proto kernel  scope link  src 192.168.0.1
104.175.4.0/22 dev vlan2  proto kernel  scope link  src 104.175.4.205
127.0.0.0/8 dev lo  scope link
0.0.0.0/1 via 10.128.1.5 dev tun11
128.0.0.0/1 via 10.128.1.5 dev tun11
default via 10.128.1.5 dev tun11

You can see above I have 0 user scripts. Fundamentally, if I have 'Block routed clients' set 'On', I shouldn't be seeing the default line in table 111 at all, should I?

Config section of VPN Client1 UI is also empty- displaying for completeness.
Code: 
/tmp/mnt/sda1 # cat /etc/openvpn/client1/config.ovpn
# Automatically generated configuration
daemon
client
dev tun11
proto udp
remote ca-toronto.privateinternetaccess.com 1194
resolv-retry 30
nobind
persist-key
persist-tun
comp-lzo adaptive
script-security 2
route-delay 2
route-up vpnrouting.sh
route-pre-down vpnrouting.sh
verb 3
ca ca.crt
auth-user-pass up
status-version 2
status status 10

# Custom Configuration
 
And now I'm flummoxed.
I reinstated execution of script via openvpn-event trigger, so as to not clobber the route-up vnpnrouting.sh above.
Table 111 appears quite different under 380.57 than 378.55 (eth0 has changed to vlan2); and the default entry remains in opposition to the prohibit that I saw much earlier.
However, the client now appears to be routing properly and is being blocked if the VPN goes down.
(It is not being blocked if the VPN never comes up / is not started with WAN though.)
Thanks all, I'll look again tomorrow with fresher eyes.
 
And now I'm flummoxed.
Click to expand...

Computers eh?:eek:

(It is not being blocked if the VPN never comes up / is not started with WAN though.)
Click to expand...

This appears to me to be a critical bug/regression?.....I'm pretty sure RMerlin in one of the Change logs during the RPDB Policy Rules feature development explicitly fixed this?

i.e.

If for VPN Client 1 you have enabled 'Block routed clients if tunnel goes down' = YES
then when the router is rebooted, then in my opinion table 111 should ALWAYS immediately be populated with just

Code: 
prohibit  default

even if VPN 1 Client 'Start with WAN' = NO, and additionally, the RPDB clients that are defined to use VPN Client 1 should have appropiate rules

Code: 
  1101: from xxx.xxx.xxx.xxx lookup 111
  1102: etc.

in place.

If the above isn't true then xxx.xxx.xxx.xxx is exposed to traffic leaks via the WAN.

However I suspect most users set VPN Client 1 'Start with WAN' = YES, and RPDB table 111 is hopefully ONLY changed to contain

Code: 
default  via  xxx.xxx.xxx.xxx  dev  tun11

after the VPN client is successfully established!

Well at least you now know that Selective Routing does indeed work...now to expand the basic Selective Routing for ports using fwmark tagging!

Good luck
 
You must log in or register to reply here.

Similar threads

D
VPN director issue on RT-AC86U (386.14 Merlin FW)
Replies
9
Views
556
Dome01
D
J
VPN director Multiple OpenVPN clients
Replies
7
Views
532
eibgrad
eibgrad
N
Solved OpenVPN Server split tunnell config
Replies
5
Views
480
elorimer
E
P
Accessing remotly Server While Using VPN on Asus Router with Merlin Firmware
Replies
9
Views
340
eibgrad
eibgrad
G
Using VPN Director to route only torrent traffic through VPN
Replies
9
Views
685
goldnet
G
Similar threads
Thread starter Title Forum Replies Date
K Redirect subdomains to ports Asuswrt-Merlin 8
D Redirect port 443 to 8443 Asuswrt-Merlin 6
L Devices Connect to Wi-Fi but No Internet Asuswrt-Merlin 19
K Solved "Block internet access" does nothing Asuswrt-Merlin 7
Zakalwe Solved RT-AX86U Pro - Using as PPPoE modem with BT Full Fibter internet Asuswrt-Merlin 8
zombeeh8er GT-AX11000 Deauth-ing only 2.4GHz clients, no internet connection on other devices Asuswrt-Merlin 15
R Addition of Block Internet Access Asuswrt-Merlin 5
T Internet connection via ISP despite existing VPN connection in the Asus RT-AC 86U Asuswrt-Merlin 5
E RT AX88U problem with update 3004 388-8-1 and 2: loss of internet access Asuswrt-Merlin 8
J Asus GT-BE98 Pro and Merlin, no internet when VPN disabled Asuswrt-Merlin 4

Similar threads

Latest threads

Support SNBForums w/ Amazon

If you'd like to support SNBForums, just use this link and buy anything on Amazon. Thanks!

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!

Staff online

Members online

Total: 895 (members: 37, guests: 858)
Top