Asuswrt-Merlin Netflix through VPN settings

[Martineau]

Now, it works as you said. many thanks @Martineau

Unfortunately, if you are using ARM routers with the TrendMicro EULA activated you will need to apply this (2015 post ??!!)

https://www.snbforums.com/threads/port-forward-while-using-vpn-client.28014/#post-215624

as your 'fwmark' rules are always inserted/managed due to a status change in the VPN client connection.

Unsurprisingly, RMerlin's /usr/sbin/vpnrouting.sh script also manages the creation of the RPDB rules dynamically, based on the status of the VPN Client connection (UP/DOWN.)

However, since v380_68 (e.g. v360.68_2) you will now need to manually set 'Log verbosity (0-11, default=3)=4' for each VPN Client to see them logged in Syslog.

In my opinion there is no technical reason why RMerlin can't assist advanced users by patching /usr/sbin/vpnrouting.sh to include and manage the RPDB 'fwmark' rules by assigning them to the (currently) unused priority slots within his reserved RPDB rule range
e.g.

ip rule

0: from all lookup local
10000: from all fwmark 0x7000 lookup main
10100: from all fwmark 0x1000 lookup ovpnc1
10300: from all fwmark 0x2000 lookup ovpnc2 
10500: from all fwmark 0x3000 lookup ovpnc3
10700: from all fwmark 0x4000 lookup ovpnc4
10900: from all fwmark 0x5000 lookup ovpnc5

as follows:

Spoiler: Patch to manage fwmark RPDB rules in /usr/sbin/vpnrouting.sh

@@ -63,6 +65,16 @@
   fi
  done
  IFS=$OLDIFS
+ ########################################################################################## Martineau Hack 1 of 5
+ if [ $(ip rule | grep -c "from all fwmark 0x7000 lookup main") -eq 0 ];then
+  ip rule add from 0/0 fwmark 0x7000 table 254 prio 10000
+  logger -st "($(basename $0))" $$  "Martineau Adding WAN0 RPDB fwmark rule 0x7000 prio 10000"
+ fi
+ if [ $(ip rule | grep -c "from all fwmark 0x"$VPN_UNIT"000") -eq 0 ];then
+  ip rule add from 0/0 fwmark "0x"$VPN_UNIT"000" table 11$VPN_UNIT prio "10"$((VPN_UNIT*2-1))"00"
+  logger -st "($(basename $0))" $$  "Martineau Adding VPN"$VPN_UNIT "RPDB fwmark rule 0x"$VPN_UNIT"000 prio 10"$((VPN_UNIT*2-1))"00"
+ fi
+ ################################################################################################################
 }
 
 purge_client_list(){
@@ -71,9 +83,15 @@
  do
   if [ $PRIO -ge $START_PRIO -a $PRIO -le $END_PRIO ]
   then
+   ########################################################################################## Martineau Hack 2 of 5
+   if [ $PRIO -eq 10000 ];then
+    logger -st "($(basename $0))" $$ "Martineau Skipping deletion of rule" $PRIO "unoffically reserved for WAN fwmark 0x7000"
+   else
    ip rule del prio $PRIO
    my_logger "Removing rule $PRIO from routing policy"
   fi
+   ################################################################################################################
+  fi
  done
 }

This modification does not undermine the stability nor integrity of the firmware, it simply becomes another optional feature that lies benignly dormant until triggered (like most of the more advanced features of the firmware.)

NOTE: Anyone can apply the patch although you will then need to remember to check all future Rmerlin firmware releases to see if RMerlin has (surreptitiously) updated /usr/sbin/vpnrouting.sh.

 

[Jack Yaz]

Unfortunately, if you are using ARM routers with the TrendMicro EULA activated you will need to apply this (2015 post ??!!)

https://www.snbforums.com/threads/port-forward-while-using-vpn-client.28014/#post-215624

as your 'fwmark' rules are always inserted/managed due to a status change in the VPN client connection.

Unsurprisingly, RMerlin's /usr/sbin/vpnrouting.sh script also manages the creation of the RPDB rules dynamically, based on the status of the VPN Client connection (UP/DOWN.)

However, since v380_68 (e.g. v360.68_2) you will now need to manually set 'Log verbosity (0-11, default=3)=4' for each VPN Client to see them logged in Syslog.

In my opinion there is no technical reason why RMerlin can't assist advanced users by patching /usr/sbin/vpnrouting.sh to include and manage the RPDB 'fwmark' rules by assigning them to the (currently) unused priority slots within his reserved RPDB rule range
e.g.

ip rule

0: from all lookup local
10000: from all fwmark 0x7000 lookup main
10100: from all fwmark 0x1000 lookup ovpnc1
10300: from all fwmark 0x2000 lookup ovpnc2
10500: from all fwmark 0x3000 lookup ovpnc3
10700: from all fwmark 0x4000 lookup ovpnc4
10900: from all fwmark 0x5000 lookup ovpnc5

as follows:

Spoiler: Patch to manage fwmark RPDB rules in /usr/sbin/vpnrouting.sh

@@ -63,6 +65,16 @@
   fi
  done
  IFS=$OLDIFS
+ ########################################################################################## Martineau Hack 1 of 5
+ if [ $(ip rule | grep -c "from all fwmark 0x7000 lookup main") -eq 0 ];then
+  ip rule add from 0/0 fwmark 0x7000 table 254 prio 10000
+  logger -st "($(basename $0))" $$  "Martineau Adding WAN0 RPDB fwmark rule 0x7000 prio 10000"
+ fi
+ if [ $(ip rule | grep -c "from all fwmark 0x"$VPN_UNIT"000") -eq 0 ];then
+  ip rule add from 0/0 fwmark "0x"$VPN_UNIT"000" table 11$VPN_UNIT prio "10"$((VPN_UNIT*2-1))"00"
+  logger -st "($(basename $0))" $$  "Martineau Adding VPN"$VPN_UNIT "RPDB fwmark rule 0x"$VPN_UNIT"000 prio 10"$((VPN_UNIT*2-1))"00"
+ fi
+ ################################################################################################################
 }
 
 purge_client_list(){
@@ -71,9 +83,15 @@
  do
   if [ $PRIO -ge $START_PRIO -a $PRIO -le $END_PRIO ]
   then
+   ########################################################################################## Martineau Hack 2 of 5
+   if [ $PRIO -eq 10000 ];then
+    logger -st "($(basename $0))" $$ "Martineau Skipping deletion of rule" $PRIO "unoffically reserved for WAN fwmark 0x7000"
+   else
    ip rule del prio $PRIO
    my_logger "Removing rule $PRIO from routing policy"
   fi
+   ################################################################################################################
+  fi
  done
 }

This modification does not undermine the stability nor integrity of the firmware, it simply becomes another optional feature that lies benignly dormant until triggered (like most of the more advanced features of the firmware.)

NOTE: Anyone can apply the patch although you will then need to remember to check all future Rmerlin firmware releases to see if RMerlin has (surreptitiously) updated /usr/sbin/vpnrouting.sh.

Isn't this what pull/merge requests on GitHub exist for?

 

[Martineau]

Isn't this what pull/merge requests on GitHub exist for?

RMerlin does not condone use of fwmarks (except of course for his own 'NAT Loopback' fwmark 0x8000 implementation).

He has previously rejected the proposed change on the basis that is too much additional work, should the upstream code change whereby Asus may suddenly decide to hijack his current RPDB rule 10000-20000 range, and also decide to use his routing tables 111-115 etc.

As there is no rule against posting code to educate (and clearly this is an alternative method to be considered by the OP) , this is what I have done, and as @john9527 actually posted a 'like' yesterday, perhaps he might wish to apply the patch in his fork.

Oh and by the way here is @RMerlin's most recent statement (in response to my formal query) on his preferred method for submitting firmware enhancement requests and musings on the way forward for the future of GitHub:

https://www.snbforums.com/threads/s...on-on-asuswrt-merlin.39824/page-3#post-332840

"The two ways I would suggest for enhancement requests:

1) Start a new thread here for the specific enhancement. It allows to provide some back and forth discussion, and also involve feedback from other users.

2) Start an entry on Github's issue tracker.

At this point, I'd be more in favour of the first method. The Github issue tracker is itself an... issue, as I was mentionning in my post."

Do keep up.

 

[Jack Yaz]

Do keep up.

Thanks. I ask a question and you launch into a tirade of "I'm better than you".

 

[Odkrys]

Unfortunately, if you are using ARM routers with the TrendMicro EULA activated you will need to apply this (2015 post ??!!)

https://www.snbforums.com/threads/port-forward-while-using-vpn-client.28014/#post-215624

Hmm. I have never experienced this though I use Ai-Protection's 3 network protection features.
I added several mangle PREROUTING rules to use udp transparent proxy 3 months ago and these were solid.

If the routing suddenly fails then this previously was due to the (RT-AC56U/RT-AC68U etc. ) TrendMicro DPI engine flushing the

iptables -t mangle PREROUTING

 

[Martineau]

Hmm. I have never experienced this though I use Ai-Protection's 3 network protection features.
I added several mangle PREROUTING rules to use udp transparent proxy 3 months ago and these were solid.

There is a recent thread discussing that the TrendMicro signature apparently no longer automatically refreshes

https://www.snbforums.com/threads/r...380-68-is-available.40761/page-17#post-347005

which I believe may have been one of the original causes of the firewall being randomly reset overnight -perhaps this is now significant?

Also I understand that recent forum posts discussing QOS tweaks via the GUI also causes the firewall to be reset?

I haven't accepted the TrendMicro EULA so I too haven't seen any of my custom '-t nat mangle PREROUTING' rules going AWOL, although I do have my VPN restart check enabled (just in case) in nat-start

My point is that you should safeguard against the situation where the VPN connection is still UP but your expected Selective Routing fwmark tagging is suddenly no longer being applied, hence the cautionary advisory post.

 

[Martineau]

Thanks. I ask a question and you launch into a tirade of "I'm better than you".

Tirade!??

NO idea why you would personally feel it necessary to post in such an irrational manner to besmirch my forum contribution, but regrettably if I don't reply then it would be perceived (incorrectly) that I accept your spiteful statement as being intentionally true.

However, you are of course entitled to your opinion, although I must confess I would prefer it if you could limit your unsavoury comments to criticising my posted technical solutions/scripts rather than me personally.

If I may, I would like to point out that the number of times I have provided you with highly technical (bespoke) solutions to your forum help-request posts far outweighs the number of times you have reciprocated - would you not agree?

Consequently I would have to concur that this indisputable fact simply, yet dramatically, establishes publically, some truth in your own observation regarding the difference between our IT skill levels.

So thank you for callously benefiting from my technical input, yet unfathomably and discourteously attacking me after I calmly explained in detail the factual basis behind my post.

Regards,

 

[RMerlin]

Folks, please keep this on topic, and move personal issues to PMs. Thank you.

 

[john9527]

In my opinion there is no technical reason why RMerlin can't assist advanced users by patching /usr/sbin/vpnrouting.sh to include and manage the RPDB 'fwmark' rules by assigning them to the (currently) unused priority slots within his reserved RPDB rule range
e.g.

ip rule

0: from all lookup local
10000: from all fwmark 0x7000 lookup main
10100: from all fwmark 0x1000 lookup ovpnc1
10300: from all fwmark 0x2000 lookup ovpnc2
10500: from all fwmark 0x3000 lookup ovpnc3
10700: from all fwmark 0x4000 lookup ovpnc4
10900: from all fwmark 0x5000 lookup ovpnc5

I've been playing a bit with this. Found one required change....you need to provide the appropriate masks when creating the ip rules or else the QoS marks will prevent a match.

 

[st3v3n]

Thank you, RMerlin (Folks, Gents) & john9527, for your dedication to keeping an eye on all threads, and particularly VPN; it still manages to confound so many (like me). My years spent lurking & listening to everyone has increased my understanding. All tips, advice & wisdom shared on this complex issue really is helpful. (Peace)

 

[Martineau]

I've been playing a bit with this. Found one required change....you need to provide the appropriate masks when creating the ip rules or else the QoS marks will prevent a match.

It probably would make logical sense to apply the same mask to the 'ip rule' as used in the ' iptables' tagging rule just to be consistent - and of course everybody loves consistent code.

Personally I haven't previously needed to enable QoS in anger, so perhaps I (and others) have just been lucky in that the QoS marks have never been applied and the 'ip rule' without the mask just worked?.

Having said that I did recently test/enable QoS as I was intrigued (and subsequently highly impressed) by @FreshJR's script, but I'd have to report that I didn't notice that the lack of the 'ip rule' mask caused any unexpected Selective Routing fwmark tagging failures with basic Adaptive QoS enabled (either with or without @FreshJR's script enabled)

So Adaptive QoS is now ON

MARK=0x1000 is apparently set correctly by iptables rule for Selective Port Routing 80,443 via the VPN Client 1 tunnel (fwmark 0x1000) from nominated device 10.88.8.111:

RT-AC68U kern.warn kernel: TAGVPN1  IN=br0 OUT= MAC=xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx SRC=10.88.8.111 DST=xxx.xxx.xxx.xxx LEN=52 TOS=0x00 PREC=0x00 TTL=128 ID=3839 DF PROTO=TCP SPT=59381 DPT=80 WINDOW=65535 RES=0x00 SYN URGP=0 MARK=0x1000

but if QoS fwmark is then subsequently applied before hitting the RPDB rule...??

RT-AC68U kern.warn kernel: VPN1 Post IN= OUT=eth0 SRC=10.88.8.114 DST=xxx.xxx.xxx.xxx LEN=48 TOS=0x00 PREC=0x00 TTL=127 ID=14002 PROTO=UDP SPT=51150 DPT=3478 LEN=28 MARK=0x45800000

???

 

[Odkrys]

Unfortunately, if you are using ARM routers with the TrendMicro EULA activated you will need to apply this (2015 post ??!!)

https://www.snbforums.com/threads/port-forward-while-using-vpn-client.28014/#post-215624

Now I know, whats you said... I don't know why fwmark rules broke after restart firewall.

@RMerlin @Martineau what is difference between 1 and 2 ?

1. VPN client1 start with openvpn-event scripts which call vpnclient1-route-up (fwmark routing rules).
2. After 1, service restart_firewall and run sh vpnclient1-route-up.

They look exactly same to me. But the fwmark rules don't work.

#!/bin/sh

# Is the actual VPN client UP....well is there a route to the VPN? or does folder /etc/openvpn/clientx exist?
# If so then selective routing tagging will be broken until the '-t mangle PREROUTING' chain is reinstated for the VPN Client
VPN_LIST="1 2"
for VPNID in $VPN_LIST
do
VPNROUTE=`ip route show | grep -i -a "dev tun1"$VPNID`
logger -s -t "($(basename $0))" $$ "Checking if VPN Client$VPNID is UP...."$VPNROUTE
if [ "$VPNROUTE" != "" ];then
logger -s -t "($(basename $0))" $$ "**Warning VPN Client$VPNID is UP.... restarting VPN Client$VPNID"
service restart_vpnclient$VPNID
sleep 30 # Delay starting the second VPN client just to keep the syslog entries separate for easier debugging
fi
done

This nat-start script make it work properly

 

[Martineau]

Now I know, whats you said... I don't know why fwmark rules broke after restart firewall.

@RMerlin @Martineau what is difference between 1 and 2 ?

If you are referring to this code

VPN_LIST="1 2"

it simply means that it will only check if VPN Clients 1 and 2 are UP.

Not all routers/firmware support 5 VPN Clients , but for those that do, it should be changed:

VPN_LIST="1 2 3 4 5"

In terms of speed they should (in theory) possibly be different, given that RMerlin assigns them to different CPUs.

 

[Odkrys]

If you are referring to this code

No ;

1. VPN client1 start with openvpn-event scripts which call vpnclient1-route-up (fwmark routing rules).

2. After 1, service restart_firewall and run sh vpnclient1-route-up.

 

[Martineau]

No ;

1. VPN client1 start with openvpn-event scripts which call vpnclient1-route-up (fwmark routing rules).

2. After 1, service restart_firewall and run sh vpnclient1-route-up.

My wild guess

1. Method; openvpn-event automatically passes command arg parameters to vpnclient1-route-up, which when executing also then has access to the OpenVPN environment and its variables such as 'dev' etc. Also /usr/sbin/vpnrouting.sh will issue 'ip route flush cache' so any new RPDB rules will be activated immediately.

2. Method; Doesn't ?

 

[RMerlin]

RMerlin does not condone use of fwmarks (except of course for his own 'NAT Loopback' fwmark 0x8000 implementation).

And even that one single exception is now hitting a problem. See this recent note Asus added inside rc/qos.c:

       NOTE:
       qos mark bit 8~31 : TrendMicro adaptive qos usage, so ASUS only can use bit 0~7 for different applications
       ex. Traditional qos / bandwidth limiter / Facebook wifi

That's why reserving any mark value for personal use is always a gamble, as Asus can at any time start using them for their own use, causing issues. So I prefer to avoid using them unless absolutely necessary. Now I have to decide what to do with my custom NAT loopback method to avoid clashing with Trend Micro's usage. I might have to simply abandon the mark-based NAT loopback method, because with only 8 bits available for non-TM usage, Asus might every well use any of these 8 bits at any time.

 

[Martineau]

And even that one single exception is now hitting a problem. See this recent note Asus added inside rc/qos.c:

       NOTE:
       qos mark bit 8~31 : TrendMicro adaptive qos usage, so ASUS only can use bit 0~7 for different applications
       ex. Traditional qos / bandwidth limiter / Facebook wifi

That's why reserving any mark value for personal use is always a gamble, as Asus can at any time start using them for their own use, causing issues. So I prefer to avoid using them unless absolutely necessary. Now I have to decide what to do with my custom NAT loopback method to avoid clashing with Trend Micro's usage. I might have to simply abandon the mark-based NAT loopback method, because with only 8 bits available for non-TM usage, Asus might every well use any of these 8 bits at any time.

It does seem that TrendMicro has an unusual relationship with Asus, surely they don't technically have to restrict Asus to 8 bits?

It is indeed an (excessive) luxury to be able to run 5 VPN Clients and my unofficial use of the following fwmarks

0x7000          WAN
0x6000          PPTP/L2TP
0x1000          VPN Client 1
0x2000          VPN Client 2
0x3000          VPN Client 3
0x4000          VPN Client 4
0x5000          VPN Client 5

is most definitely overkill, as most would probably only run one VPN Client anyway.

Surely it isn't breaking any non-disclosure agreement for Asus/TendMicro to agree that they will ensure that there are three bits available for third-party use i.e. one for your NAT loopback implementation and say two for the Selective Routing of ipsets/ports.

I guess having the TrendMicro stuff isn't such a big deal, so there may be a greater userbase 'defecting' to using the firmware fork in the future.

P.S. I'm sure there may be techniques to use tcpdump etc. to track the use of fwmarks.
However, not sure what to make of the weird fwmark I found in my Syslog:
https://www.snbforums.com/threads/a...through-vpn-settings.41047/page-3#post-348575

 

[Rickyrsx]

the problem with Netflix is it uses to many subnets worldwide for one to put them all in a VPN policy rule.
So even though you searched for 5 results you can do the same search over and over and will always get new IP addresses showing up.
I think they add new IP often so you may have it working for a while but then it can stop.
They have a huge network.

I agree with @yorgi that it's impossible to keep up with Netflix. How many IP's can you write rules for? It's better to either give up, go through WAN, or find a VPN that still works with Netflix (for now). I just started using StrongVPN and their servers are very good here in Toronto and Netflix still works, at the moment.

 

[RMerlin]

It does seem that TrendMicro has an unusual relationship with Asus, surely they don't technically have to restrict Asus to 8 bits?

Keep in mind that the Trend Micro engine is not unique to Asus. Trend Micro licences it to various manufacturers (TP-Link recently got a licence for it). So, I`m not sure what went through Trend Micro's mind when they decided to use so many bits to classify their traffic.

In any case, it's not something I have any control over.

 

[Xentrk]

I agree with @yorgi that it's impossible to keep up with Netflix. How many IP's can you write rules for? It's better to either give up, go through WAN, or find a VPN that still works with Netflix (for now). I just started using StrongVPN and their servers are very good here in Toronto and Netflix still works, at the moment.

Yes, luckily there are providers who can get around the blocks. For those that can't change providers, there is hope!

@Martineau has done a great job helping others do this on the forum. The selective routing ipset examples @Martineau posted in the selective routing thread where ipset mines the ip addresses is the best way I have seen it done in my opinion:

Spoiler: Links to bypass Netflix using IPSET

https://www.snbforums.com/threads/a...through-vpn-settings.41047/page-2#post-348425

Use domain names to lookup the IP addresses, then place the IP address in an IPSET and route that traffic to the WAN. nslookup is one of several methods available to populate the IPSET list. There are a few others as well. Find the domain names being called by looking at dnsmasq.log file when starting up Netflix. It may vary by geo location. For my example, I got them from an old forum posting and have not validated them.

Please note I threw this together in about 20 minutes and have not fully tested it. It needs to be improved to handle IPv6 ip address. But my traffic to whatsmyip.org is going to the WAN.

Create the ipset list for NETFLIX

ipset create NETFLIX hash:net family inet hashsize 1024 maxelem 65536

Script

#!/bin/sh
# Uncomment the line below for debugging
set -xo

# list domains for selective routing
for domain in \
"netflix.com" \
"ichnaea.netflix.com" \
"movies.netflix.com" \
"www.netflix.com" \
"nflxext.com" \
"cdn1.nflxext.com" \
"nflximg.com" \
"nflxvideo.net" \
"ipv4_1.cxl0.c145.sjc002.ix.nflxvideo.net" \
"amazonaws.com" \
"whatsmyip.org"
do
  # extract ip addresses
    for ip in $(nslookup $domain | awk '/^Name:/,0{if (/^Addr/)print $3}'); do
    # add IP address to ipset list NETFLIX
    ipset add NETFLIX `echo $ip | cut -d . -f 1,2`.0.0/16
  done
done

###########################################################
#Create table to contain items added automatically by wan #
###########################################################
ip rule del prio 9990
ip rule add from 0/0 fwmark 0x7000 table main prio 9990
iptables -D PREROUTING -t mangle -m set --match-set NETFLIX dst -j MARK --set-mark 0x7000/0x7000
iptables -A PREROUTING -t mangle -m set --match-set NETFLIX dst -j MARK --set-mark 0x7000/0x7000

One can add this to a cron job to update the ipset list on a periodic basis.

Spoiler: ipset -L NETFLIX

Name: NETFLIX
Type: hash:net
Revision: 6
Header: family inet hashsize 1024 maxelem 65536
Size in memory: 1884
References: 1
Number of entries: 28
Members:
208.64.0.0/16
52.37.0.0/16
52.32.0.0/16
52.40.0.0/16
207.171.0.0/16
23.215.0.0/16
54.187.0.0/16
52.11.0.0/16
72.21.0.0/16
52.88.0.0/16
52.41.0.0/16
52.27.0.0/16
52.39.0.0/16
52.35.0.0/16
52.26.0.0/16
54.68.0.0/16
207.45.0.0/16
69.53.0.0/16
54.69.0.0/16
52.24.0.0/16
52.34.0.0/16
54.201.0.0/16
52.43.0.0/16
52.89.0.0/16
52.42.0.0/16
52.10.0.0/16
54.148.0.0/16

I mined dnsmasq to see what domains are being called. This is what I got (Caveat - this may vary depending on your geo location)

Spoiler: grep | awk | sort dnsmasq file for netflix

netflix.com
www.us-west-2.prodaa.netflix.com
secure.netflix.com
push.prod.netflix.com
push.prod.us-west-2.prodaa.netflix.com
api-global.netflix.com
customerevents.netflix.com
oca-api.netflix.com
anycast.ftl.netflix.com