What's new

Selective routing not working for RT-AC68U

  • 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!

bigjess007

New Around Here
I have a RT-AC68U running the latest Merlin Firmware (380.68_4) and am attempting to use selective routing to get certain traffic (Netflix) to route straight to WAN bypassing VPN (as all traffic is tunneled through a VPN).

I started in the Selective Routing with Asuswrt-Merlin thread reading through it and trying the scripts. I always end up getting the error "iptables: No chain/target/match by that name".

Late in that thread, there are posts stating several folks who have RT-AC68U's are getting the same error and it appears that it may be because of this model router. There was a post that redirected to the thread Using ipset to selectively route domains to a VPN client? that had the same error as me. Working through that thread, it appears that user may have resolved their error as well, however I still cannot get this working.

So I am starting a new thread cause I need to get this working and can't.

Here are my scripts:
nat-start that is in /jffs/scripts/
Code:
#!/bin/sh
/jffs/scripts/Netflix.sh
ip rule del prio 9990
ip rule add from 0/0 fwmark 0x7000 table main prio 9990
iptables -t mangle -D PREROUTING -m set --match-set Netflix dst -j MARK --set-mark 0x7000/0x7000
iptables -t mangle -A PREROUTING -m set --match-set Netflix dst -j MARK --set-mark 0x7000/0x7000

The Netflix.sh script:
Code:
#!/bin/sh
ipset create Netflix hash:net family inet hashsize 1024 maxelem 65536
ipset add Netflix 108.175.32.0/20
****************truncated, see next post for all the ip's added****************

The Netflix script runs fine when I run it manually. When I run nat-start manually I get the "iptables: No chain/target/match by that name."

There were several requests in the threads asking for additional information to troubleshoot, so I've tried to include everything I've found:

ip rule
Code:
0:      from all lookup local
9990:   from all fwmark 0x7000 lookup main
32766:  from all lookup main
32767:  from all lookup default

iptables -t mangle -nvL
Code:
Chain PREROUTING (policy ACCEPT 159M packets, 147G bytes)
 pkts bytes target     prot opt in     out     source               destination
  61M   71G CONNMARK   all  --  eth0   *       0.0.0.0/0            0.0.0.0/0            CONNMARK restore mask 0x7

Chain INPUT (policy ACCEPT 65M packets, 73G bytes)
 pkts bytes target     prot opt in     out     source               destination

Chain FORWARD (policy ACCEPT 94M packets, 74G bytes)
 pkts bytes target     prot opt in     out     source               destination
 300K   20M QOSO0      all  --  *      eth0    0.0.0.0/0            0.0.0.0/0  

Chain OUTPUT (policy ACCEPT 40M packets, 13G bytes)
 pkts bytes target     prot opt in     out     source               destination
  36M   12G QOSO0      all  --  *      eth0    0.0.0.0/0            0.0.0.0/0  

Chain POSTROUTING (policy ACCEPT 133M packets, 86G bytes)
 pkts bytes target     prot opt in     out     source               destination
  61M   67G QOSO0      all  --  *      br0     0.0.0.0/0            0.0.0.0/0  

Chain QOSO0 (3 references)
 pkts bytes target     prot opt in     out     source               destination
  97M   79G CONNMARK   all  --  *      *       0.0.0.0/0            0.0.0.0/0            CONNMARK restore mask 0x7
    0     0 RETURN     all  --  *      *       0.0.0.0/0            0.0.0.0/0            connmark match ! 0x0/0xff00
    8   799 CONNMARK   tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcp dpt:80 connbytes 0:524287 connbytes mode bytes connbytes direction both CONNMARK set-return 0x1/0x7
   57 55196 CONNMARK   tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcp dpt:443 connbytes 0:524287 connbytes mode bytes connbytes direction both CONNMARK set-return 0x1/0x7
    0     0 CONNMARK   tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcp dpt:80 connbytes 524288 connbytes mode bytes connbytes direction both CONNMARK set-return 0x4/0x7
   48  2674 CONNMARK   tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcp dpt:443 connbytes 524288 connbytes mode bytes connbytes direction both CONNMARK set-return 0x4/0x7
 581K  274M CONNMARK   all  --  *      *       0.0.0.0/0            224.0.0.0/4          CONNMARK set-return 0x6/0x7
  60M   67G CONNMARK   all  --  *      *       0.0.0.0/0            192.168.15.0/24      CONNMARK set-return 0x6/0x7
  36M   12G CONNMARK   all  --  *      *       0.0.0.0/0            0.0.0.0/0            CONNMARK set-return 0x4/0x7

iptables -t mangle -nvL PREROUTING --line
Code:
Chain PREROUTING (policy ACCEPT 159M packets, 147G bytes)
num   pkts bytes target     prot opt in     out     source               destination
1      61M   71G CONNMARK   all  --  eth0   *       0.0.0.0/0            0.0.0.0/0            CONNMARK restore mask 0x7

iptables -nvL PREROUTING --line -t mangle
Code:
Chain PREROUTING (policy ACCEPT 159M packets, 147G bytes)
num   pkts bytes target     prot opt in     out     source               destination
1      61M   71G CONNMARK   all  --  eth0   *       0.0.0.0/0            0.0.0.0/0            CONNMARK restore mask 0x7
 
Last edited:
continuing....

iptables --verbose -t mangle -vL PREROUTING
Code:
Chain PREROUTING (policy ACCEPT 159M packets, 147G bytes)
 pkts bytes target     prot opt in     out     source               destination 
  61M   71G CONNMARK   all  --  eth0   any     anywhere             anywhere             CONNMARK restore mask 0x7
libiptc vlibxtables.so.7. 3776 bytes.
Table `mangle'
Hooks: pre/in/fwd/out/post = 0/138/1d0/300/430
Underflows: pre/in/fwd/out/post = a0/138/268/398/4c8
Entry 0 (0):
SRC IP: 0.0.0.0/0.0.0.0
DST IP: 0.0.0.0/0.0.0.0
Interface: `eth0'/XXXXX...........to `'/................
Protocol: 0
Flags: 00
Invflags: 00
Counters: 61436962 packets, 71420644854 bytes
Cache: 00000000
Target name: `CONNMARK' [48]

Entry 1 (160):
SRC IP: 0.0.0.0/0.0.0.0
DST IP: 0.0.0.0/0.0.0.0
Interface: `'/................to `'/................
Protocol: 0
Flags: 00
Invflags: 00
Counters: 159009945 packets, 147030282635 bytes
Cache: 00000000
Target name: `' [40]
verdict=NF_ACCEPT

Entry 2 (312):
SRC IP: 0.0.0.0/0.0.0.0
DST IP: 0.0.0.0/0.0.0.0
Interface: `'/................to `'/................
Protocol: 0
Flags: 00
Invflags: 00
Counters: 64915956 packets, 73121408540 bytes
Cache: 00000000
Target name: `' [40]
verdict=NF_ACCEPT

Entry 3 (464):
SRC IP: 0.0.0.0/0.0.0.0
DST IP: 0.0.0.0/0.0.0.0
Interface: `'/................to `eth0'/XXXXX...........
Protocol: 0
Flags: 00
Invflags: 00
Counters: 311042 packets, 20543112 bytes
Cache: 00000000
Target name: `' [40]
verdict=1552

Entry 4 (616):
SRC IP: 0.0.0.0/0.0.0.0
DST IP: 0.0.0.0/0.0.0.0
Interface: `'/................to `'/................
Protocol: 0
Flags: 00
Invflags: 00
Counters: 93651982 packets, 73836762794 bytes
Cache: 00000000
Target name: `' [40]
verdict=NF_ACCEPT

Entry 5 (768):
SRC IP: 0.0.0.0/0.0.0.0
DST IP: 0.0.0.0/0.0.0.0
Interface: `'/................to `eth0'/XXXXX...........
Protocol: 0
Flags: 00
Invflags: 00
Counters: 35651816 packets, 11787443589 bytes
Cache: 00000000
Target name: `' [40]
verdict=1552

Entry 6 (920):
SRC IP: 0.0.0.0/0.0.0.0
DST IP: 0.0.0.0/0.0.0.0
Interface: `'/................to `'/................
Protocol: 0
Flags: 00
Invflags: 00
Counters: 39723987 packets, 12596687846 bytes
Cache: 00000000
Target name: `' [40]
verdict=NF_ACCEPT

Entry 7 (1072):
SRC IP: 0.0.0.0/0.0.0.0
DST IP: 0.0.0.0/0.0.0.0
Interface: `'/................to `br0'/XXXX............
Protocol: 0
Flags: 00
Invflags: 00
Counters: 60820043 packets, 66865604594 bytes
Cache: 00000000
Target name: `' [40]
verdict=1552

Entry 8 (1224):
SRC IP: 0.0.0.0/0.0.0.0
DST IP: 0.0.0.0/0.0.0.0
Interface: `'/................to `'/................
Protocol: 0
Flags: 00
Invflags: 00
Counters: 133376054 packets, 86433463753 bytes
Cache: 00000000
Target name: `' [40]
verdict=NF_ACCEPT

Entry 9 (1376):
SRC IP: 0.0.0.0/0.0.0.0
DST IP: 0.0.0.0/0.0.0.0
Interface: `'/................to `'/................
Protocol: 0
Flags: 00
Invflags: 00
Counters: 0 packets, 0 bytes
Cache: 00000000
Target name: `ERROR' [64]
error=`QOSO0'

Entry 10 (1552):
SRC IP: 0.0.0.0/0.0.0.0
DST IP: 0.0.0.0/0.0.0.0
Interface: `'/................to `'/................
Protocol: 0
Flags: 00
Invflags: 00
Counters: 96782901 packets, 78673591295 bytes
Cache: 00000000
Target name: `CONNMARK' [48]

Entry 11 (1712):
SRC IP: 0.0.0.0/0.0.0.0
DST IP: 0.0.0.0/0.0.0.0
Interface: `'/................to `'/................
Protocol: 0
Flags: 00
Invflags: 00
Counters: 0 packets, 0 bytes
Cache: 00000000
Match name: `connmark'
Target name: `' [40]
verdict=RETURN

Entry 12 (1912):
SRC IP: 0.0.0.0/0.0.0.0
DST IP: 0.0.0.0/0.0.0.0
Interface: `'/................to `'/................
Protocol: 6
Flags: 00
Invflags: 00
Counters: 8 packets, 799 bytes
Cache: 00000000
Match name: `tcp'
Match name: `connbytes'
Target name: `CONNMARK' [48]

Entry 13 (2176):
SRC IP: 0.0.0.0/0.0.0.0
DST IP: 0.0.0.0/0.0.0.0
Interface: `'/................to `'/................
Protocol: 6
Flags: 00
Invflags: 00
Counters: 57 packets, 55196 bytes
Cache: 00000000
Match name: `tcp'
Match name: `connbytes'
Target name: `CONNMARK' [48]

Entry 14 (2440):
SRC IP: 0.0.0.0/0.0.0.0
DST IP: 0.0.0.0/0.0.0.0
Interface: `'/................to `'/................
Protocol: 6
Flags: 00
Invflags: 00
Counters: 0 packets, 0 bytes
Cache: 00000000
Match name: `tcp'
Match name: `connbytes'
Target name: `CONNMARK' [48]

Entry 15 (2704):
SRC IP: 0.0.0.0/0.0.0.0
DST IP: 0.0.0.0/0.0.0.0
Interface: `'/................to `'/................
Protocol: 6
Flags: 00
Invflags: 00
Counters: 48 packets, 2674 bytes
Cache: 00000000
Match name: `tcp'
Match name: `connbytes'
Target name: `CONNMARK' [48]

Entry 16 (2968):
SRC IP: 0.0.0.0/0.0.0.0
DST IP: 224.0.0.0/240.0.0.0
Interface: `'/................to `'/................
Protocol: 0
Flags: 00
Invflags: 00
Counters: 581603 packets, 274483947 bytes
Cache: 00000000
Target name: `CONNMARK' [48]

Entry 17 (3128):
SRC IP: 0.0.0.0/0.0.0.0
DST IP: 192.168.15.0/255.255.255.0
Interface: `'/................to `'/................
Protocol: 0
Flags: 00
Invflags: 00
Counters: 60238428 packets, 66591114167 bytes
Cache: 00000000
Target name: `CONNMARK' [48]

Entry 18 (3288):
SRC IP: 0.0.0.0/0.0.0.0
DST IP: 0.0.0.0/0.0.0.0
Interface: `'/................to `'/................
Protocol: 0
Flags: 00
Invflags: 00
Counters: 35962758 packets, 11807934552 bytes
Cache: 00000000
Target name: `CONNMARK' [48]

Entry 19 (3448):
SRC IP: 0.0.0.0/0.0.0.0
DST IP: 0.0.0.0/0.0.0.0
Interface: `'/................to `'/................
Protocol: 0
Flags: 00
Invflags: 00
Counters: 4 packets, 205 bytes
Cache: 00000000
Target name: `' [40]
verdict=RETURN

Entry 20 (3600):
SRC IP: 0.0.0.0/0.0.0.0
DST IP: 0.0.0.0/0.0.0.0
Interface: `'/................to `'/................
Protocol: 0
Flags: 00
Invflags: 00
Counters: 0 packets, 0 bytes
Cache: 00000000
Target name: `ERROR' [64]
error=`ERROR'

iptables --version
Code:
iptables v1.4.14
 
continuing...

ipset -L
Code:
Name: Netflix
Type: hash:net
Revision: 6
Header: family inet hashsize 1024 maxelem 65536
Size in memory: 9556
References: 0
Number of entries: 173
Members:
198.38.110.0/24
198.38.121.0/24
174.129.0.0/16
50.19.128.0/17
45.57.4.0/24
23.246.51.0/24
23.246.20.0/24
45.57.49.0/24
54.242.0.0/15
198.38.100.0/24
52.95.245.0/24
184.73.0.0/16
45.57.20.0/24
52.200.0.0/13
52.2.0.0/15
54.240.8.0/21
198.38.124.0/24
75.101.128.0/17
23.246.15.0/24
54.240.32.0/20
198.38.113.0/24
54.90.0.0/15
23.22.0.0/15
23.246.42.0/24
52.0.0.0/15
23.246.22.0/24
23.246.49.0/24
198.38.98.0/24
45.57.23.0/24
198.45.49.0/24
23.246.31.0/24
45.57.62.0/24
198.38.108.0/24
23.246.25.0/24
54.174.0.0/15
23.246.30.0/24
198.38.111.0/24
107.22.0.0/16
23.246.56.0/24
45.57.63.0/24
54.234.0.0/15
107.21.128.0/17
45.57.60.0/24
23.246.46.0/24
52.20.0.0/14
23.246.29.0/24
54.144.0.0/14
52.86.0.0/15
69.53.225.0/24
204.236.224.0/19
54.221.0.0/16
45.57.55.0/24
198.45.56.0/24
45.57.45.0/24
23.246.23.0/24
45.57.56.0/24
45.57.22.0/24
54.89.0.0/16
45.57.36.0/24
54.88.0.0/16
184.72.64.0/19
54.172.0.0/15
198.38.101.0/24
23.246.2.0/24
45.57.14.0/24
184.72.96.0/19
192.173.64.0/18
45.57.19.0/24
45.57.16.0/24
107.21.64.0/18
54.84.0.0/15
198.38.115.0/24
45.57.59.0/24
34.224.0.0/12
54.240.48.0/23
52.44.0.0/15
23.246.48.0/24
50.16.0.0/16
54.236.64.0/18
198.38.99.0/24
45.57.5.0/24
107.23.128.0/17
198.38.119.0/24
45.57.3.0/24
23.246.27.0/24
198.38.97.0/24
45.57.21.0/24
23.246.54.0/24
54.237.0.0/16
45.57.1.0/24
45.57.44.0/24
216.182.224.0/21
45.57.42.0/24
198.45.48.0/24
198.38.118.0/24
54.236.0.0/18
198.38.96.0/24
54.208.0.0/15
107.21.0.0/18
54.156.0.0/14
54.226.0.0/15
54.224.0.0/15
198.45.48.0/20
23.246.50.0/24
107.20.0.0/16
184.72.128.0/17
52.54.0.0/15
54.240.30.0/23
50.17.0.0/16
23.246.28.0/24
23.246.7.0/24
198.38.112.0/24
54.236.128.0/17
23.246.36.0/24
198.38.116.0/24
45.57.11.0/24
45.57.58.0/24
50.19.0.0/17
52.70.0.0/15
54.198.0.0/16
23.246.24.0/24
198.38.109.0/24
35.153.0.0/16
37.77.184.0/21
54.87.0.0/16
198.38.96.0/19
23.246.0.0/18
54.160.0.0/14
198.38.117.0/24
54.86.0.0/16
23.246.6.0/24
54.204.0.0/15
54.210.0.0/16
52.72.0.0/15
198.38.114.0/24
45.57.37.0/24
72.44.32.0/19
45.57.48.0/24
23.246.52.0/24
23.246.26.0/24
52.90.0.0/15
54.164.0.0/15
204.236.192.0/18
45.57.17.0/24
54.211.0.0/16
216.182.232.0/21
45.57.15.0/24
54.196.0.0/15
67.202.0.0/18
23.246.58.0/24
198.38.125.0/24
23.246.14.0/24
35.168.0.0/13
23.246.55.0/24
54.152.0.0/16
23.246.47.0/24
23.246.17.0/24
54.166.0.0/15
54.80.0.0/14
23.246.16.0/24
107.23.0.0/17
34.192.0.0/12
45.57.18.0/24
45.57.54.0/24
52.4.0.0/14
108.175.32.0/20
23.246.57.0/24
45.57.2.0/24
23.20.0.0/15
45.57.0.0/17
23.246.3.0/24
198.38.120.0/24
54.92.128.0/17
 
Do you need vpn on all devices?
I select device either wan or vpn
Posted a video in this tread:
https://www.snbforums.com/threads/v...ot-work-for-statically-defined-devices.42278/

Maybe it's not what you are looking for but if you only use like Netflix on your smart tv/cast device u can easely put that/those devices outside the vpn connection

This won't work for my application. I need to tunnel everything but Netflix. What's frustrating is all the posts on how to do it and folks getting it to work, but I can't. :(
 
This appears to be a common issue with AC68U users. Did you review the steps posted here?
 
Did you review the steps posted here?
Rappy was doing alot more than I'm doing based on what I read (and my understanding). He is using dnsmasq to get the IP's he wants to route. I already have the IP's and am putting them in the "Netflix" ipset. Then I just want those to route to WAN. Mine seems to be alot simpler and my 2 iptable rules are from the selective routing thread.

This appears to be a common issue with AC68U users.
Which really brings us to the ultimate question: is this a hardware issue that is unfixable, or a firmware issue Merlin possibly could fix.....?
 
Which really brings us to the ultimate question: is this a hardware issue that is unfixable, or a firmware issue Merlin possibly could fix.....?
I have been wondering the same thing. I have tried to help several of the AC68U owners that reported the issue. Does it happen for all build versions?

Perhaps you can try a few other iptables commands to see if you still get the error message.

http://www.thegeekstuff.com/2011/06/iptables-rules-examples/
http://www.thegeekstuff.com/2011/01/iptables-fundamentals/
http://www.thegeekstuff.com/2011/02/iptables-add-rule/
http://www.thegeekstuff.com/2011/03/iptables-inbound-and-outbound-rules/

A reboot will set things back to default if you end up opening up a service to the web by mistake in your testing.

It looks like some of the iptables command got truncated during the copy/paste in the first post.

One thing I noticed is that where your iptables -t mangle -nvL output says CONNMARK, whereas mines says MARK. :confused:

Code:
iptables -t mangle -nvL
Chain PREROUTING (policy ACCEPT 953K packets, 303M bytes)
 pkts bytes target     prot opt in     out     source               destination
58123   58M MARK       all  --  tun11  *       0.0.0.0/0            0.0.0.0/0            MARK xset 0x1/0x7
  922  665K MARK       all  --  tun12  *       0.0.0.0/0            0.0.0.0/0            MARK xset 0x1/0x7
    0     0 MARK       all  --  tun13  *       0.0.0.0/0            0.0.0.0/0            MARK xset 0x1/0x7
    0     0 MARK       tcp  --  br0    *       0.0.0.0/0            0.0.0.0/0            match-set LAN_GW src,dst MARK or 0x7000
    0     0 MARK       tcp  --  br0    *       0.0.0.0/0            0.0.0.0/0            match-set WAN src,dst MARK or 0x7000
33712   12M MARK       tcp  --  br0    *       0.0.0.0/0            0.0.0.0/0            match-set OVPNC1 src,dst MARK or 0x1000
    0     0 MARK       tcp  --  br0    *       0.0.0.0/0            0.0.0.0/0            match-set OVPNC2 src,dst MARK or 0x2000
    0     0 MARK       all  --  br0    *       0.0.0.0/0            67.21.54.54          MARK set 0x2000
    0     0 MARK       all  --  br0    *       0.0.0.0/0            35.164.214.37        MARK set 0x2000
    0     0 MARK       all  --  br0    *       0.0.0.0/0            34.223.213.203       MARK set 0x2000
    0     0 MARK       all  --  br0    *       0.0.0.0/0            34.208.222.87        MARK set 0x200
Remaining content snipped.

I don't use QOS. If you do, try turning it off and see if that helps. Perhaps there is a conflict with the fwmarks?
 
Last edited:
I have been wondering the same thing. I have tried to help several of the AC68U owners that reported the issue. Does it happen for all build versions?

I haven't tried with earlier builds and to an extent I'm kinda limited as to how much I can dork with this as it's live. But if there is a specific suggestion, I'll try. Others seem to have tried with other versions and it didn't work so I'm inclined to say a version change (without a fix) isn't going to fix it....

Perhaps you can try a few other iptables commands to see if you still get the error message.

http://www.thegeekstuff.com/2011/06/iptables-rules-examples/
http://www.thegeekstuff.com/2011/01/iptables-fundamentals/
http://www.thegeekstuff.com/2011/02/iptables-add-rule/
http://www.thegeekstuff.com/2011/03/iptables-inbound-and-outbound-rules/

A reboot will set things back to default if you end up opening up a service to the web by mistake in your testing.

This is over my head. If you give me a specific command, I'm game to try and post the results, but I'm not well versed enough to do this on my own.

It looks like some of the iptables command got truncated during the copy/paste in the first post.

Fixed that sorry, good catch. Was pretty tired and very frustrated trying to get it all together.

One thing I noticed is that where your iptables -t mangle -nvL output says CONNMARK, whereas mines says MARK. :confused:

Have to admit again, have no idea why or what it even means.

I don't use QOS. If you do, try turning it off and see if that helps. Perhaps there is a conflict with the fwmarks?

Don't have QOS on.


TY for suggesting & commenting! I'm all ears. Getting alot of heat to get this working.
 
I haven't tried with earlier builds and to an extent I'm kinda limited as to how much I can dork with this as it's live. But if there is a specific suggestion, I'll try. Others seem to have tried with other versions and it didn't work so I'm inclined to say a version change (without a fix) isn't going to fix it....



This is over my head. If you give me a specific command, I'm game to try and post the results, but I'm not well versed enough to do this on my own.



Fixed that sorry, good catch. Was pretty tired and very frustrated trying to get it all together.



Have to admit again, have no idea why or what it even means.



Don't have QOS on.


TY for suggesting & commenting! I'm all ears. Getting alot of heat to get this working.
Try this test. The first command disables WAN access to the client. The second command re-enables WAN access by removing the previous iptables rule from the chain. The client is still connected to the router. But the first iptables command drops the packets before they can reach the WAN. I tested this using my iPad. No error messages. Change the IP address to match the client you are testing with.

Code:
#Disable WAN access to client with ip address of 192.168.22.153
iptables -I FORWARD -s 192.168.22.153 -j DROP

#Enable WAN access to client with ip address of 192.168.22.153
iptables -D FORWARD -s 192.168.22.153 -j DROP
 

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!
Top