x3mRouting x3mRouting ~ Selective Routing for Asuswrt-Merlin Firmware

  • ATTENTION! You'll notice a Prefix dropdown when you create a thread. If your post applies to one of the topics listed, please use that Prefix for your post. When browsing the thread list you can use the Prefix to filter the view.
  • ATTENTION! As of November 1, 2020, you are not able to reply to threads 6 months after the thread is opened if there are more than 500 posts in the thread.
    Threads will not be locked, so posts may still be edited by their authors.
    Just start a new thread on the topic to post if you get an error message when trying to reply to a thread.

tejesh83

Occasional Visitor
Hello, great tool although I'm not using it as I'm using dnsmasq on my phone to do more or less the same thing but instead of a vpn it's using specific smartdns to access geographically restricted library of some video services, I'm only having trouble with amazon video which still detects I'm not in the US. I was wondering if anyone could share the list of servers used to bypass this ?thanks again

This is the JSON file of Amazon server's Xentrk's script uses. Most of us in the US found that the GLOBAL list works best, but I use both US and GLOBAL lists.
 

tejesh83

Occasional Visitor
The rules get applied when the VPN status is "route-up" and the rules get removed at "route-pre-down" when the VPN is started or stopped. They also get reapplied during a firewall restart or when nat-start is run. This should cover most situations that I am aware of.

Here is how the route-up entry looks in system log:
Code:
openvpn-event[4216]: Running /jffs/scripts/x3mRouting/vpnclient2-route-up tun12 1500 1584 10.37.0.6 10.37.0.5

Next time it happens, enter the following command to display the PREROUTING IPTABLES Chains for the mangle table to confirm if the rules exist or not:

Code:
iptables -nvL PREROUTING -t mangle --line

Try turning the VPN on/off and use the command above to verify if the rules are being applied properly.

I did have an issue with my private IP one time where I had issues everytime the certificate lease got renewed. I can't recall the fix. I think they gave me a new IP.

I noticed the issue again today and confirmed that vpnclient1-route-up did run from the syslog. I checked the PREROUTING IPTABLES Chains, but the rules appear to be fine:
Code:
iptables -nvL PREROUTING -t mangle --line
Chain PREROUTING (policy ACCEPT 64M packets, 64G bytes)
num   pkts bytes target     prot opt in     out     source               destination         
1     161M  187G BWDPI_FILTER  udp  --  eth0   *       0.0.0.0/0            0.0.0.0/0           
2      62M   72G BWDPI_FILTER  udp  --  eth0   *       0.0.0.0/0            0.0.0.0/0           
3     235K   47M MARK       all  --  br0    *       0.0.0.0/0            0.0.0.0/0            match-set AMAZON_US dst MARK or 0x8000
4        0     0 MARK       all  --  br0    *       0.0.0.0/0            0.0.0.0/0            match-set NETFLIX dst MARK or 0x8000
5    1021K  375M MARK       all  --  br0    *       0.0.0.0/0            0.0.0.0/0            match-set GOOGLE dst MARK or 0x8000
6    34792 5627K MARK       all  --  br0    *       0.0.0.0/0            0.0.0.0/0            match-set FACEBOOK dst MARK or 0x8000
7     105K 9631K MARK       all  --  br0    *       0.0.0.0/0            0.0.0.0/0            match-set AMAZON_GLOBAL dst MARK or 0x8000
8     203K   28M MARK       all  --  br0    *       0.0.0.0/0            0.0.0.0/0            match-set AMAZON_AS16509 dst MARK or 0x8000
9    1838K  467M MARK       all  --  br0    *       0.0.0.0/0            0.0.0.0/0            match-set NETFLIX_CUSTOM dst MARK or 0x8000
10    139K   28M MARK       all  --  br0    *       0.0.0.0/0            0.0.0.0/0            match-set AMAZON_AS14618 dst MARK or 0x8000
11    170K   24M MARK       all  --  br0    *       0.0.0.0/0            0.0.0.0/0            match-set AMAZON_CUSTOM dst MARK or 0x8000

However, when I checked RPDB, I discovered the WAN mask prio 9990 was missing:
Code:
ip rule
0:    from all lookup local
10001:    from 192.168.1.1 lookup main
10002:    from all to 8.8.8.8 lookup main
10003:    from all to 8.8.4.4 lookup main
10004:    from 192.168.1.138 lookup main
10005:    from 192.168.1.233 lookup main
10006:    from 192.168.1.187 lookup main
10007:    from 192.168.1.10 lookup main
10101:    from 192.168.1.1/24 lookup ovpnc1
32766:    from all lookup main
32767:    from all lookup default

When I reran nat-start, the 9990 prio was added back, and my firetv started playing videos again:
Code:
ip rule
0:    from all lookup local
9990:    from all fwmark 0x8000/0x8000 lookup main
10001:    from 192.168.1.1 lookup main
10002:    from all to 8.8.8.8 lookup main
10003:    from all to 8.8.4.4 lookup main
10004:    from 192.168.1.138 lookup main
10005:    from 192.168.1.233 lookup main
10006:    from 192.168.1.187 lookup main
10007:    from 192.168.1.10 lookup main
10101:    from 192.168.1.1/24 lookup ovpnc1
32766:    from all lookup main
32767:    from all lookup default

Any ideas why prio 9990 is getting dropped and not added back when my VPN client connection drops and restarts?

Thanks for the help!
 

Xentrk

Part of the Furniture
I noticed the issue again today and confirmed that vpnclient1-route-up did run from the syslog. I checked the PREROUTING IPTABLES Chains, but the rules appear to be fine:
Code:
iptables -nvL PREROUTING -t mangle --line
Chain PREROUTING (policy ACCEPT 64M packets, 64G bytes)
num   pkts bytes target     prot opt in     out     source               destination   
1     161M  187G BWDPI_FILTER  udp  --  eth0   *       0.0.0.0/0            0.0.0.0/0     
2      62M   72G BWDPI_FILTER  udp  --  eth0   *       0.0.0.0/0            0.0.0.0/0     
3     235K   47M MARK       all  --  br0    *       0.0.0.0/0            0.0.0.0/0            match-set AMAZON_US dst MARK or 0x8000
4        0     0 MARK       all  --  br0    *       0.0.0.0/0            0.0.0.0/0            match-set NETFLIX dst MARK or 0x8000
5    1021K  375M MARK       all  --  br0    *       0.0.0.0/0            0.0.0.0/0            match-set GOOGLE dst MARK or 0x8000
6    34792 5627K MARK       all  --  br0    *       0.0.0.0/0            0.0.0.0/0            match-set FACEBOOK dst MARK or 0x8000
7     105K 9631K MARK       all  --  br0    *       0.0.0.0/0            0.0.0.0/0            match-set AMAZON_GLOBAL dst MARK or 0x8000
8     203K   28M MARK       all  --  br0    *       0.0.0.0/0            0.0.0.0/0            match-set AMAZON_AS16509 dst MARK or 0x8000
9    1838K  467M MARK       all  --  br0    *       0.0.0.0/0            0.0.0.0/0            match-set NETFLIX_CUSTOM dst MARK or 0x8000
10    139K   28M MARK       all  --  br0    *       0.0.0.0/0            0.0.0.0/0            match-set AMAZON_AS14618 dst MARK or 0x8000
11    170K   24M MARK       all  --  br0    *       0.0.0.0/0            0.0.0.0/0            match-set AMAZON_CUSTOM dst MARK or 0x8000

However, when I checked RPDB, I discovered the WAN mask prio 9990 was missing:
Code:
ip rule
0:    from all lookup local
10001:    from 192.168.1.1 lookup main
10002:    from all to 8.8.8.8 lookup main
10003:    from all to 8.8.4.4 lookup main
10004:    from 192.168.1.138 lookup main
10005:    from 192.168.1.233 lookup main
10006:    from 192.168.1.187 lookup main
10007:    from 192.168.1.10 lookup main
10101:    from 192.168.1.1/24 lookup ovpnc1
32766:    from all lookup main
32767:    from all lookup default

When I reran nat-start, the 9990 prio was added back, and my firetv started playing videos again:
Code:
ip rule
0:    from all lookup local
9990:    from all fwmark 0x8000/0x8000 lookup main
10001:    from 192.168.1.1 lookup main
10002:    from all to 8.8.8.8 lookup main
10003:    from all to 8.8.4.4 lookup main
10004:    from 192.168.1.138 lookup main
10005:    from 192.168.1.233 lookup main
10006:    from 192.168.1.187 lookup main
10007:    from 192.168.1.10 lookup main
10101:    from 192.168.1.1/24 lookup ovpnc1
32766:    from all lookup main
32767:    from all lookup default

Any ideas why prio 9990 is getting dropped and not added back when my VPN client connection drops and restarts?

Thanks for the help!
Thanks for the feedback. That gives me something to go on. There was a recent update where the fwmark got removed when specifying the 'del' parm and not other routing rules existed that used the fwmark.

EDIT:
1) Are you using Option 2 of x3mRouting - OpenVPN Client GUI, OpenVPN Event & x3mRouting.sh Script or just option 3?
2) What is the result of
Code:
grep VERS /jffs/scripts/x3mRouting/x3mRouting.sh
 
Last edited:

tejesh83

Occasional Visitor
Thanks for the feedback. That gives me something to go on. There was a recent update where the fwmark got removed when specifying the 'del' parm and not other routing rules existed that used the fwmark.

EDIT:
1) Are you using Option 2 of x3mRouting - OpenVPN Client GUI, OpenVPN Event & x3mRouting.sh Script or just option 3?
2) What is the result of
Code:
grep VERS /jffs/scripts/x3mRouting/x3mRouting.sh

1) I use just option 3
2) script version is 2.3.6
 

CannaLucente

Occasional Visitor
Hi, I am using option 3 which works well (while I couldn't make option 2 work).
Is there a way to know which routing rules I have activated? Something similar to LISTSTATS (which, rather than showing me all the IPSETs, it shows me all the routing rules).
I have tried ip rule but it only shows me the rules I can see in the UI.

I have tried iptables -nvL PREROUTING -t mangle --line but it shows me this:

Chain PREROUTING (policy ACCEPT 107K packets, 64M bytes)
num pkts bytes target prot opt in out source destination


I would have expected to find the rule I have configured for Amazon...
x3mRouting 1 0 AMAZON aws_region=US,CA,AP,CN,EU,SA,GLOBAL

Thanks!
 
Last edited:

Xentrk

Part of the Furniture
1) I use just option 3
2) script version is 2.3.6
Once in awhile, I would get a duplicate ip rule for OVPC1. I suspect the issue is too many processes of x3mRouting.sh running at the same time. Code has been updated to prevent this. The first run of x3mRouting.sh in nat-start has to complete before the subsequent one can start and so on. I also changed the way the fwmarks are created and added additional logging to prevent the issue.

I did multiple reboots and bounced VPN clients and didn't have any issues.

I placed the code in a test branch for now. Copy and paste into SSH session to update x3mRouting.sh.

Code:
curl -fsL --retry 3 --connect-timeout 3 -o "/jffs/scripts/x3mRouting/x3mRouting.sh" https://raw.githubusercontent.com/Xentrk/x3mRouting/test/x3mRouting.sh

Run it for a few days and monitor.
 

Xentrk

Part of the Furniture
Hi, I am using option 3 which works well (while I couldn't make option 2 work).
Is there a way to know which routing rules I have activated? Something similar to LISTSTATS (which, rather than showing me all the IPSETs, it shows me all the routing rules).
I have tried ip rule but it only shows me the rules I can see in the UI.

I have tried iptables -nvL PREROUTING -t mangle --line but it shows me this:

Chain PREROUTING (policy ACCEPT 107K packets, 64M bytes)
num pkts bytes target prot opt in out source destination


I would have expected to find the rule I have configured for Amazon...
x3mRouting 1 0 AMAZON aws_region=US,CA,AP,CN,EU,SA,GLOBAL

Thanks!
It is working for me. I suspect the GLOBAL region on it's own may cover all the other regions. I have to go back and confirm though on the AWS site. The iptables command you list is the right one.

Code:
# x3mRouting 1 0 AMAZON aws_region=US,CA,AP,CN,EU,SA,GLOBAL
(x3mRouting): 10768 Starting Script Execution 1 0 AMAZON aws_region=US,CA,AP,CN,EU,SA,GLOBAL
(x3mRouting): 10768 IPSET created: AMAZON hash:net family inet hashsize 1024 maxelem 65536
(x3mRouting): 10768 Selective Routing Rule via WAN created for AMAZON fwmark 0x8000/0x8000
(x3mRouting): 10768 iptables -t mangle -D PREROUTING -i br0 -m set --match-set AMAZON dst -j MARK --set-mark 0x8000/0x8000 2>/dev/null added to /jffs/scripts/x3mRouting/vpnclient1-route-up
(x3mRouting): 10768 iptables -t mangle -A PREROUTING -i br0 -m set --match-set AMAZON dst -j MARK --set-mark 0x8000/0x8000 added to /jffs/scripts/x3mRouting/vpnclient1-route-up
(x3mRouting): 10768 iptables -t mangle -D PREROUTING -i br0 -m set --match-set AMAZON dst -j MARK --set-mark 0x8000/0x8000 2>/dev/null added to /jffs/scripts/x3mRouting/vpnclient1-route-pre-down
(x3mRouting): 10768 sh /jffs/scripts/x3mRouting/x3mRouting.sh 1 0 AMAZON aws_region=US,CA,AP,CN,EU,SA,GLOBAL added to /jffs/scripts/nat-start
(x3mRouting): 10768 Completed Script Execution

# iptables -nvL PREROUTING -t mangle --line
Chain PREROUTING (policy ACCEPT 72 packets, 19744 bytes)
num   pkts bytes target     prot opt in     out     source               destination
<snip>
19       4   314 MARK       all  --  br0    *       0.0.0.0/0            0.0.0.0/0            match-set AMAZON dst MARK or 0x8000
 

CannaLucente

Occasional Visitor
It is working for me. I suspect the GLOBAL region on it's own may cover all the other regions. I have to go back and confirm though on the AWS site. The iptables command you list is the right one.

Thank you. I have tried again and now I can see them and it's working for Amazon.

Code:
[email protected]:/jffs/scripts/x3mRouting# x3mRouting 1 0 AMAZON aws_region=EU,US,CA,AP,CN,GLOBAL,SA
(x3mRouting): 18309 Starting Script Execution 1 0 AMAZON aws_region=EU,US,CA,AP,CN,GLOBAL,SA
(x3mRouting): 18309 IPSET created: AMAZON hash:net family inet hashsize 1024 maxelem 65536
(x3mRouting): 18309 Selective Routing Rule via WAN created for AMAZON fwmark 0x8000/0x8000
(x3mRouting): 18309 iptables -t mangle -D PREROUTING -i br0 -m set --match-set AMAZON dst -j MARK --set-mark 0x8000/0x8000 2>/dev/null added to /jffs/scripts/x3mRouting/vpnclient1-route-up
(x3mRouting): 18309 iptables -t mangle -A PREROUTING -i br0 -m set --match-set AMAZON dst -j MARK --set-mark 0x8000/0x8000 added to /jffs/scripts/x3mRouting/vpnclient1-route-up
(x3mRouting): 18309 iptables -t mangle -D PREROUTING -i br0 -m set --match-set AMAZON dst -j MARK --set-mark 0x8000/0x8000 2>/dev/null added to /jffs/scripts/x3mRouting/vpnclient1-route-pre-down
(x3mRouting): 18309 sh /jffs/scripts/x3mRouting/x3mRouting.sh 1 0 AMAZON aws_region=EU,US,CA,AP,CN,GLOBAL,SA added to /jffs/scripts/nat-start
(x3mRouting): 18309 Completed Script Execution
[email protected]:/jffs/scripts/x3mRouting# liststats
AMAZON - 2225
[email protected]:/jffs/scripts/x3mRouting# iptables -nvL PREROUTING -t mangle --line
Chain PREROUTING (policy ACCEPT 2890 packets, 746K bytes)
num   pkts bytes target     prot opt in     out     source               destination
1       20  5981 MARK       all  --  br0    *       0.0.0.0/0            0.0.0.0/0            match-set AMAZON dst MARK or 0x8000

I am very new to the Unix world and find it very interesting and a big thank you to you guys developing these great tools!

Now I need to sort out Disney+... let's see if I manage to do it myself :)

Thanks again!
 

tejesh83

Occasional Visitor
Once in awhile, I would get a duplicate ip rule for OVPC1. I suspect the issue is too many processes of x3mRouting.sh running at the same time. Code has been updated to prevent this. The first run of x3mRouting.sh in nat-start has to complete before the subsequent one can start and so on. I also changed the way the fwmarks are created and added additional logging to prevent the issue.

I did multiple reboots and bounced VPN clients and didn't have any issues.

I placed the code in a test branch for now. Copy and paste into SSH session to update x3mRouting.sh.

Code:
curl -fsL --retry 3 --connect-timeout 3 -o "/jffs/scripts/x3mRouting/x3mRouting.sh" https://raw.githubusercontent.com/Xentrk/x3mRouting/test/x3mRouting.sh

Run it for a few days and monitor.

Thanks Xentrk!

I download the test branch:
grep VERS /jffs/scripts/x3mRouting/x3mRouting.sh
# VERSION=2.3.8 TEST


However, when bouncing the VPN client, the issue still occurs; prio 9990 is missing from RPDB. Rerunning nat-start adds the missing entry to RPDB to correct the issue.

I played around with it a couple more times, and it appears, when switching off the VPN client, the prio 9990 entry in RPDB remains. But when switching on the VPN client, the prio 9990 entry is removed. In the syslog, I can see an entry from x3mvpnrouring.sh where it appears the rule is being deleted, but no corresponding entry where it is readded.

"Oct 21 10:06:36 (x3mvpnrouting.sh): 26671 Deleting fwmark 0x8000/0x8000"

Oct 21 10:06:35 openvpn-routing: Configuring policy rules for client 1
Oct 21 10:06:35 openvpn-routing: Creating VPN routing table (mode 3)
Oct 21 10:06:35 openvpn-routing: Removing rule 10001 from routing policy
Oct 21 10:06:35 openvpn-routing: Removing rule 10002 from routing policy
Oct 21 10:06:35 openvpn-routing: Removing rule 10003 from routing policy
Oct 21 10:06:35 openvpn-routing: Removing rule 10004 from routing policy
Oct 21 10:06:35 openvpn-routing: Removing rule 10005 from routing policy
Oct 21 10:06:35 openvpn-routing: Removing rule 10006 from routing policy
Oct 21 10:06:35 openvpn-routing: Removing rule 10101 from routing policy
Oct 21 10:06:35 openvpn-routing: Adding route for 192.168.1.1 to through WAN
Oct 21 10:06:35 openvpn-routing: Adding route for 192.168.1.1/24 to through VPN client 1
Oct 21 10:06:35 openvpn-routing: Adding route for to 8.8.8.8 through WAN
Oct 21 10:06:35 openvpn-routing: Adding route for to 8.8.4.4 through WAN
Oct 21 10:06:35 openvpn-routing: Adding route for 192.168.1.138 to through WAN
Oct 21 10:06:36 openvpn-routing: Adding route for 192.168.1.233 to through WAN
Oct 21 10:06:36 openvpn-routing: Adding route for 192.168.1.187 to through WAN
Oct 21 10:06:36 openvpn-routing: Tunnel re-established, restoring WAN access to clients
Oct 21 10:06:36 openvpn-routing: Completed routing policy configuration for client 1
Oct 21 10:06:36 custom_script: Running /jffs/scripts/openvpn-event (args: tun11 1500 1557 10.125.0.226 10.125.0.225)
Oct 21 10:06:36 (updown-dns.sh): 26654 Starting script execution
Oct 21 10:06:36 (updown-dns.sh): 26654 Ending script execution
Oct 21 10:06:36 (x3mvpnrouting.sh): 26671 Removing rule 10001 from routing policy
Oct 21 10:06:36 (x3mvpnrouting.sh): 26671 Removing rule 10002 from routing policy
Oct 21 10:06:36 (x3mvpnrouting.sh): 26671 Removing rule 10003 from routing policy
Oct 21 10:06:36 (x3mvpnrouting.sh): 26671 Removing rule 10004 from routing policy
Oct 21 10:06:36 (x3mvpnrouting.sh): 26671 Removing rule 10005 from routing policy
Oct 21 10:06:36 (x3mvpnrouting.sh): 26671 Removing rule 10006 from routing policy
Oct 21 10:06:36 (x3mvpnrouting.sh): 26671 Removing rule 10101 from routing policy
Oct 21 10:06:36 (x3mvpnrouting.sh): 26671 Deleting fwmark 0x8000/0x8000
Oct 21 10:06:36 (x3mvpnrouting.sh): 26671 x3mRouting Checking Custom fwmark/bitmask
Oct 21 10:06:36 (x3mvpnrouting.sh): 26671 ip rule add from 192.168.1.1 table main priority 10001
Oct 21 10:06:36 openvpn-routing: Adding route for 192.168.1.1 to through WAN
Oct 21 10:06:36 (x3mvpnrouting.sh): 26671 ip rule add from 192.168.1.1/24 table ovpnc1 priority 10101
Oct 21 10:06:36 openvpn-routing: Adding route for 192.168.1.1/24 to through VPN client 1
Oct 21 10:06:36 (x3mvpnrouting.sh): 26671 ip rule add to 8.8.8.8 table main priority 10002
Oct 21 10:06:36 openvpn-routing: Adding route for to 8.8.8.8 through WAN
Oct 21 10:06:36 (x3mvpnrouting.sh): 26671 ip rule add to 8.8.4.4 table main priority 10003
Oct 21 10:06:36 openvpn-routing: Adding route for to 8.8.4.4 through WAN
Oct 21 10:06:36 (x3mvpnrouting.sh): 26671 ip rule add from 192.168.1.138 table main priority 10004
Oct 21 10:06:36 openvpn-routing: Adding route for 192.168.1.138 to through WAN
Oct 21 10:06:36 (x3mvpnrouting.sh): 26671 ip rule add from 192.168.1.233 table main priority 10005
Oct 21 10:06:36 openvpn-routing: Adding route for 192.168.1.233 to through WAN
Oct 21 10:06:36 (x3mvpnrouting.sh): 26671 ip rule add from 192.168.1.187 table main priority 10006
Oct 21 10:06:36 openvpn-routing: Adding route for 192.168.1.187 to through WAN
Oct 21 10:06:36 x3mRouting: Configuring policy rules for client 1
Oct 21 10:06:36 (x3mvpnrouting.sh): 26671 Completed routing policy configuration for client 1
Oct 21 10:06:36 openvpn-event[26648]: Running /jffs/scripts/x3mRouting/vpnclient1-route-up tun11 1500 1557 10.125.0.226 10.125.0.225
Oct 21 09:06:36 ovpn-client1[26316]: Initialization Sequence Completed
 

Xentrk

Part of the Furniture
Thanks Xentrk!

I download the test branch:
grep VERS /jffs/scripts/x3mRouting/x3mRouting.sh
# VERSION=2.3.8 TEST


However, when bouncing the VPN client, the issue still occurs; prio 9990 is missing from RPDB. Rerunning nat-start adds the missing entry to RPDB to correct the issue.

I played around with it a couple more times, and it appears, when switching off the VPN client, the prio 9990 entry in RPDB remains. But when switching on the VPN client, the prio 9990 entry is removed. In the syslog, I can see an entry from x3mvpnrouring.sh where it appears the rule is being deleted, but no corresponding entry where it is readded.

"Oct 21 10:06:36 (x3mvpnrouting.sh): 26671 Deleting fwmark 0x8000/0x8000"

Oct 21 10:06:35 openvpn-routing: Configuring policy rules for client 1
Oct 21 10:06:35 openvpn-routing: Creating VPN routing table (mode 3)
Oct 21 10:06:35 openvpn-routing: Removing rule 10001 from routing policy
Oct 21 10:06:35 openvpn-routing: Removing rule 10002 from routing policy
Oct 21 10:06:35 openvpn-routing: Removing rule 10003 from routing policy
Oct 21 10:06:35 openvpn-routing: Removing rule 10004 from routing policy
Oct 21 10:06:35 openvpn-routing: Removing rule 10005 from routing policy
Oct 21 10:06:35 openvpn-routing: Removing rule 10006 from routing policy
Oct 21 10:06:35 openvpn-routing: Removing rule 10101 from routing policy
Oct 21 10:06:35 openvpn-routing: Adding route for 192.168.1.1 to through WAN
Oct 21 10:06:35 openvpn-routing: Adding route for 192.168.1.1/24 to through VPN client 1
Oct 21 10:06:35 openvpn-routing: Adding route for to 8.8.8.8 through WAN
Oct 21 10:06:35 openvpn-routing: Adding route for to 8.8.4.4 through WAN
Oct 21 10:06:35 openvpn-routing: Adding route for 192.168.1.138 to through WAN
Oct 21 10:06:36 openvpn-routing: Adding route for 192.168.1.233 to through WAN
Oct 21 10:06:36 openvpn-routing: Adding route for 192.168.1.187 to through WAN
Oct 21 10:06:36 openvpn-routing: Tunnel re-established, restoring WAN access to clients
Oct 21 10:06:36 openvpn-routing: Completed routing policy configuration for client 1
Oct 21 10:06:36 custom_script: Running /jffs/scripts/openvpn-event (args: tun11 1500 1557 10.125.0.226 10.125.0.225)
Oct 21 10:06:36 (updown-dns.sh): 26654 Starting script execution
Oct 21 10:06:36 (updown-dns.sh): 26654 Ending script execution
Oct 21 10:06:36 (x3mvpnrouting.sh): 26671 Removing rule 10001 from routing policy
Oct 21 10:06:36 (x3mvpnrouting.sh): 26671 Removing rule 10002 from routing policy
Oct 21 10:06:36 (x3mvpnrouting.sh): 26671 Removing rule 10003 from routing policy
Oct 21 10:06:36 (x3mvpnrouting.sh): 26671 Removing rule 10004 from routing policy
Oct 21 10:06:36 (x3mvpnrouting.sh): 26671 Removing rule 10005 from routing policy
Oct 21 10:06:36 (x3mvpnrouting.sh): 26671 Removing rule 10006 from routing policy
Oct 21 10:06:36 (x3mvpnrouting.sh): 26671 Removing rule 10101 from routing policy
Oct 21 10:06:36 (x3mvpnrouting.sh): 26671 Deleting fwmark 0x8000/0x8000
Oct 21 10:06:36 (x3mvpnrouting.sh): 26671 x3mRouting Checking Custom fwmark/bitmask
Oct 21 10:06:36 (x3mvpnrouting.sh): 26671 ip rule add from 192.168.1.1 table main priority 10001
Oct 21 10:06:36 openvpn-routing: Adding route for 192.168.1.1 to through WAN
Oct 21 10:06:36 (x3mvpnrouting.sh): 26671 ip rule add from 192.168.1.1/24 table ovpnc1 priority 10101
Oct 21 10:06:36 openvpn-routing: Adding route for 192.168.1.1/24 to through VPN client 1
Oct 21 10:06:36 (x3mvpnrouting.sh): 26671 ip rule add to 8.8.8.8 table main priority 10002
Oct 21 10:06:36 openvpn-routing: Adding route for to 8.8.8.8 through WAN
Oct 21 10:06:36 (x3mvpnrouting.sh): 26671 ip rule add to 8.8.4.4 table main priority 10003
Oct 21 10:06:36 openvpn-routing: Adding route for to 8.8.4.4 through WAN
Oct 21 10:06:36 (x3mvpnrouting.sh): 26671 ip rule add from 192.168.1.138 table main priority 10004
Oct 21 10:06:36 openvpn-routing: Adding route for 192.168.1.138 to through WAN
Oct 21 10:06:36 (x3mvpnrouting.sh): 26671 ip rule add from 192.168.1.233 table main priority 10005
Oct 21 10:06:36 openvpn-routing: Adding route for 192.168.1.233 to through WAN
Oct 21 10:06:36 (x3mvpnrouting.sh): 26671 ip rule add from 192.168.1.187 table main priority 10006
Oct 21 10:06:36 openvpn-routing: Adding route for 192.168.1.187 to through WAN
Oct 21 10:06:36 x3mRouting: Configuring policy rules for client 1
Oct 21 10:06:36 (x3mvpnrouting.sh): 26671 Completed routing policy configuration for client 1
Oct 21 10:06:36 openvpn-event[26648]: Running /jffs/scripts/x3mRouting/vpnclient1-route-up tun11 1500 1557 10.125.0.226 10.125.0.225
Oct 21 09:06:36 ovpn-client1[26316]: Initialization Sequence Completed
Okay. I suspected that was the program where the issue was. That code is used in options 1 and 2 but not option 3. Option 1 is the LAN Client Routing and option 2 is x3mRouting.sh with the modified GUI Screen. I'll do a deep dive to see where the issue is.
 

Kingp1n

Very Senior Member
@Xentrk


I can never get your script to run together with unbound.

I do use the internal "VPN option" available within unbound.

However, when its all setup Disney + throws error 83. I've since uninstalled unbound, restarted router and Disney + keeps throwing error 83:

"Something went wrong. Please try again. If the problem persists, visit the Disney+ Help Center (Error Code 83)."

I also tried to uninstall your script, reboot router (again) re-install script and I'm still getting the 83 error.

Any ideas on how to get your script to work with Disney or back to my previous setup when Disney was working ?

Update: Disney + finally came up. Now to figure out why I can't use it with unbound.
 
Last edited:

Xentrk

Part of the Furniture
Thanks Xentrk!

I download the test branch:
grep VERS /jffs/scripts/x3mRouting/x3mRouting.sh
# VERSION=2.3.8 TEST


However, when bouncing the VPN client, the issue still occurs; prio 9990 is missing from RPDB. Rerunning nat-start adds the missing entry to RPDB to correct the issue.

I played around with it a couple more times, and it appears, when switching off the VPN client, the prio 9990 entry in RPDB remains. But when switching on the VPN client, the prio 9990 entry is removed. In the syslog, I can see an entry from x3mvpnrouring.sh where it appears the rule is being deleted, but no corresponding entry where it is readded.

"Oct 21 10:06:36 (x3mvpnrouting.sh): 26671 Deleting fwmark 0x8000/0x8000"

Oct 21 10:06:35 openvpn-routing: Configuring policy rules for client 1
Oct 21 10:06:35 openvpn-routing: Creating VPN routing table (mode 3)
Oct 21 10:06:35 openvpn-routing: Removing rule 10001 from routing policy
Oct 21 10:06:35 openvpn-routing: Removing rule 10002 from routing policy
Oct 21 10:06:35 openvpn-routing: Removing rule 10003 from routing policy
Oct 21 10:06:35 openvpn-routing: Removing rule 10004 from routing policy
Oct 21 10:06:35 openvpn-routing: Removing rule 10005 from routing policy
Oct 21 10:06:35 openvpn-routing: Removing rule 10006 from routing policy
Oct 21 10:06:35 openvpn-routing: Removing rule 10101 from routing policy
Oct 21 10:06:35 openvpn-routing: Adding route for 192.168.1.1 to through WAN
Oct 21 10:06:35 openvpn-routing: Adding route for 192.168.1.1/24 to through VPN client 1
Oct 21 10:06:35 openvpn-routing: Adding route for to 8.8.8.8 through WAN
Oct 21 10:06:35 openvpn-routing: Adding route for to 8.8.4.4 through WAN
Oct 21 10:06:35 openvpn-routing: Adding route for 192.168.1.138 to through WAN
Oct 21 10:06:36 openvpn-routing: Adding route for 192.168.1.233 to through WAN
Oct 21 10:06:36 openvpn-routing: Adding route for 192.168.1.187 to through WAN
Oct 21 10:06:36 openvpn-routing: Tunnel re-established, restoring WAN access to clients
Oct 21 10:06:36 openvpn-routing: Completed routing policy configuration for client 1
Oct 21 10:06:36 custom_script: Running /jffs/scripts/openvpn-event (args: tun11 1500 1557 10.125.0.226 10.125.0.225)
Oct 21 10:06:36 (updown-dns.sh): 26654 Starting script execution
Oct 21 10:06:36 (updown-dns.sh): 26654 Ending script execution
Oct 21 10:06:36 (x3mvpnrouting.sh): 26671 Removing rule 10001 from routing policy
Oct 21 10:06:36 (x3mvpnrouting.sh): 26671 Removing rule 10002 from routing policy
Oct 21 10:06:36 (x3mvpnrouting.sh): 26671 Removing rule 10003 from routing policy
Oct 21 10:06:36 (x3mvpnrouting.sh): 26671 Removing rule 10004 from routing policy
Oct 21 10:06:36 (x3mvpnrouting.sh): 26671 Removing rule 10005 from routing policy
Oct 21 10:06:36 (x3mvpnrouting.sh): 26671 Removing rule 10006 from routing policy
Oct 21 10:06:36 (x3mvpnrouting.sh): 26671 Removing rule 10101 from routing policy
Oct 21 10:06:36 (x3mvpnrouting.sh): 26671 Deleting fwmark 0x8000/0x8000
Oct 21 10:06:36 (x3mvpnrouting.sh): 26671 x3mRouting Checking Custom fwmark/bitmask
Oct 21 10:06:36 (x3mvpnrouting.sh): 26671 ip rule add from 192.168.1.1 table main priority 10001
Oct 21 10:06:36 openvpn-routing: Adding route for 192.168.1.1 to through WAN
Oct 21 10:06:36 (x3mvpnrouting.sh): 26671 ip rule add from 192.168.1.1/24 table ovpnc1 priority 10101
Oct 21 10:06:36 openvpn-routing: Adding route for 192.168.1.1/24 to through VPN client 1
Oct 21 10:06:36 (x3mvpnrouting.sh): 26671 ip rule add to 8.8.8.8 table main priority 10002
Oct 21 10:06:36 openvpn-routing: Adding route for to 8.8.8.8 through WAN
Oct 21 10:06:36 (x3mvpnrouting.sh): 26671 ip rule add to 8.8.4.4 table main priority 10003
Oct 21 10:06:36 openvpn-routing: Adding route for to 8.8.4.4 through WAN
Oct 21 10:06:36 (x3mvpnrouting.sh): 26671 ip rule add from 192.168.1.138 table main priority 10004
Oct 21 10:06:36 openvpn-routing: Adding route for 192.168.1.138 to through WAN
Oct 21 10:06:36 (x3mvpnrouting.sh): 26671 ip rule add from 192.168.1.233 table main priority 10005
Oct 21 10:06:36 openvpn-routing: Adding route for 192.168.1.233 to through WAN
Oct 21 10:06:36 (x3mvpnrouting.sh): 26671 ip rule add from 192.168.1.187 table main priority 10006
Oct 21 10:06:36 openvpn-routing: Adding route for 192.168.1.187 to through WAN
Oct 21 10:06:36 x3mRouting: Configuring policy rules for client 1
Oct 21 10:06:36 (x3mvpnrouting.sh): 26671 Completed routing policy configuration for client 1
Oct 21 10:06:36 openvpn-event[26648]: Running /jffs/scripts/x3mRouting/vpnclient1-route-up tun11 1500 1557 10.125.0.226 10.125.0.225
Oct 21 09:06:36 ovpn-client1[26316]: Initialization Sequence Completed

I was able to duplicate the issue for a VPN interface. Seems to occur for option 1 LAN Client Routing + x3mRouting.sh script from option 3.

I did some reboots and stopped/bounced clients and no issues.

Please download the updated code and advise if issue is fixed.
Code:
curl -fsL --retry 3 --connect-timeout 3 -o "/jffs/addons/x3mRouting/x3mvpnrouting.sh" https://raw.githubusercontent.com/Xentrk/x3mRouting/test/x3mvpnrouting.sh
 

Xentrk

Part of the Furniture
@Xentrk


I can never get your script to run together with unbound.

I do use the internal "VPN option" available within unbound.

However, when its all setup Disney + throws error 83. I've since uninstalled unbound, restarted router and Disney + keeps throwing error 83:

"Something went wrong. Please try again. If the problem persists, visit the Disney+ Help Center (Error Code 83)."

I also tried to uninstall your script, reboot router (again) re-install script and I'm still getting the 83 error.

Any ideas on how to get your script to work with Disney or back to my previous setup when Disney was working ?

Update: Disney + finally came up. Now to figure out why I can't use it with unbound.
dnsmasq needs to remain enabled if using the dnsmasq method. The unbound installer gives the option to use dnsmasq when I last tested with it. Check that the ipset list has contents and the iptables routing rule exists.
 

Kingp1n

Very Senior Member
dnsmasq needs to remain enabled if using the dnsmasq method. The unbound installer gives the option to use dnsmasq when I last tested with it. Check that the ipset list has contents and the iptables routing rule exists.
Thanks for the quick response. I've had dnsmasq enabled within unbound.

I'm using a full time VPN (PIA) and I had setup unbound to use a client vpn connection (VPN 1). I enabled VPN to route DNS queries within unbound.

I'll have to keep looking why the script doesn't bypass the internal VPN setup with unbound.

I'm sure is user error :)
 
Last edited:

tejesh83

Occasional Visitor
Thanks again, Xentrk! That version did the trick. I bounced the vpn client a few times, and all appears to still be working after install.

I'm not sure how or when I installed option 1. AFAIK, I've never used that feature, so maybe I fat fingered something along the way. I've only ever used the default vpn client GUI to whitelist a few LAN clients and DNS destinations.

After confirming your change above worked, I decided to wipe and reinstall x3mRouting, in case there were any other gremlins I forgot about. All good now, and I'm not seeing any calls to x3mvpnrouting.sh in syslog as expected.
 

Xentrk

Part of the Furniture
Thanks for the quick response. I've had dnsmasq enabled within unbound.

I'm using a full time VPN (PIA) and I had setup unbound to use a client vpn connection (VPN 1). I enabled VPN to route DNS queries within unbound.

I'll have to keep looking why the script doesn't bypass the internal VPN setup with unbound.

I'm sure is user error :)
It's been awhile since I last tested with Unbound. I'll try to carve out some time to test again. Try ASN method for Amazon GLOBAL region to see if that works. It doesn't require dnsmasq. Or do an nslookup on a geo location website such as whatismyipaddress.com. Then, load the IP addresses it returns using the manual method e.g. ip=x.x.x.x,x.x.x.x.x
 

Xentrk

Part of the Furniture
Thanks again, Xentrk! That version did the trick. I bounced the vpn client a few times, and all appears to still be working after install.

I'm not sure how or when I installed option 1. AFAIK, I've never used that feature, so maybe I fat fingered something along the way. I've only ever used the default vpn client GUI to whitelist a few LAN clients and DNS destinations.

After confirming your change above worked, I decided to wipe and reinstall x3mRouting, in case there were any other gremlins I forgot about. All good now, and I'm not seeing any calls to x3mvpnrouting.sh in syslog as expected.
Thanks for the feedback. Always good to get another round or two of testing by others. I'll go ahead and prepare to migrate the changes to the master branch.
 

ewokuk

Regular Contributor
Just noticed bbc stopped working today. It has been working fine for the last week, and it was working fine last night. No longer working on chrome or firefox on the pc or on firefox on my phone. Oddly the iplayer app on the tv is still working at the moment but I am guessing that might just be that it is working off a dns cache or something that hasnt expired yet. amazon and netflix are still fine.

Edit: all of a sudden out of nowhere it has started working again without me doing a thing. hmmm
 
Last edited:

Xentrk

Part of the Furniture
Just noticed bbc stopped working today. It has been working fine for the last week, and it was working fine last night. No longer working on chrome or firefox on the pc or on firefox on my phone. Oddly the iplayer app on the tv is still working at the moment but I am guessing that might just be that it is working off a dns cache or something that hasnt expired yet. amazon and netflix are still fine.

Edit: all of a sudden out of nowhere it has started working again without me doing a thing. hmmm
Do you just have option 3 installed - x3mRouting.sh script and openvpn-event?

If it stops working in the future, make sure the iptables rule exists.

iptables -nvL PREROUTING -t mangle --line

Also, check the system log for clues. x3mRouting is very verbose which will help debug.
 

Latest threads

Sign Up For SNBForums Daily Digest

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