Attached - just copy this in to the firewall section of DD-WRT–> Administration–>Commands.
I also have a cron job that kills the VPN tunnel and starts it back up [runs hourly]… When that happens I found that i needed to clean up my ip rules [view them by cli command “ip rule show”] because the route-up script keeps adding the IPs to be forced through the VPN in the rules list. The rules are checked top to bottom, so the fwmark rule must be listed on top of the IPs that are being sent through the VPN.
To make sure that happened I added the following command to the cron job that restarts the VPN:
ip rule show | awk 'x[substr($0,8)]++ {system("ip rule del " substr($0,8))}'
Nice FOR loop implementation… However, the DNS entries are static (at the time of discovery…) and do not dynamically update; hence the need to stop and restart.
Without converting from Tomato to *WRT, based on my quick perusal, it appears that *WRT firmwares based on kernel 3.1+ DO have ipset…
As an aside, why can’t *WRT firmwares simply implement a ‘script’ page like Tomato does? Using an SCP client (or CLI based commands…) seems so antiquated!
The only reason I would use *WRT (as opposed to Tomato…), that I can see, is the NAT acceleration being a standard feature. Only certain Tomato based firmwares have Nat acceleration (CTF availability…). Have you thought about switching?
That latest script has been in place for less than a day. I added some notification stuff to let me know how often it runs. If it only runs on boot then I agree, it’s not enough. Every hour is overkill, but I could add a call to the FW script from that “vpn restart” job that’s running anyway, or another crown job.
I had seen that link before, but decided I didn’t want to mess with it since I was close in figuring out iptables - thanks to the explanation of your script.
I thought about switching… only when I saw your ipset solution was for Tomato.
My router is a DIR-868L revA. Which is NOT officially supported by WW-DRT, but the latest firmware that doesn’t brick the router is from Aug’2016. I saw that Tomato (shibby) didn’t have the same “limitation” which sounded nice, but the multiwan-138 version (which I think is the latest) was from around the same timeframe, but I don’t need multiwan. And the 132-version (non-multiwan) was from 2015 so it must be missing security updates? …anyway, I’m rambling.
Summary = I don’t know enough to switch, and again I thought I was close with my current setup.
I say that due to the inherent NAT acceleration built in. Tomato allows CTF (acceleration…) but once you enable any sort of the monitoring/qos/bandwidth limiting features, you drop back to CPU acceleration, which basically limits your ingress speed. I have 100meg ingress, so dropping to 35’ish when connected to my VPN seems absurd…
With no scripts GUI page on *WRT, you have to set your scripts using SCP/Telnet and it seems like a hassle. I may switch since I rarely have to mess with my scripts now…
Regardless, I also have 100meg down, and also experience the 35ish after connecting to VPN. Seems like an ok tradeoff considering the protection that comes with it. With that said, if you can sustain faster speeds with the same protection… yes please.
Looks like xwrt doesn’t support my router.
If you switch - i’m interested in hearing the experience.
@AdamSigel said: @JasonMeudt
I believe it has 2-cores:
Regardless, I also have 100meg down, and also experience the 35ish after connecting to VPN. Seems like an ok tradeoff considering the protection that comes with it. With that said, if you can sustain faster speeds with the same protection… yes please.
If you switch - i’m interested in hearing the experience.
There is no ‘real’ need since Toastman’s Tomato version supports CTF… I get the full bandwidth on or off my VPN. If your not getting 100+, on a dual core (even a8 800Mhz…) there is a problem.
Start by disabling all the logging/qos/bandwidth limiting features.
Jason, are you using the new script instead of the one you linked to in your comment? I am using the one from your original comment, with the DNSMasq entry but I am still not seeing my true IP address in the Plex remote access section.
I have the debugging on in the script and am seeing this error, but I’m not sure if its a problem.
insmod: can’t insert ‘/lib/modules/2.6.36.4brcmarm/kernel/net/netfilter/ipset/ip_set_hash_ip.ko’: File exists
Jason, are you using the new script instead of the one you linked to in your comment? I am using the one from your original comment, with the DNSMasq entry but I am still not seeing my true IP address in the Plex remote access section.
I have the debugging on in the script and am seeing this error, but I’m not sure if its a problem.
insmod: can’t insert ‘/lib/modules/2.6.36.4brcmarm/kernel/net/netfilter/ipset/ip_set_hash_ip.ko’: File exists
EDIT: Yes… I am now using it and so far, I like it. Much easier to use…
Original: No… I have been to busy to mess with eibgrad’s script. He admittedly states that it is new, and he wishes that folks would ‘pound’ on it for awhile. He helped me out designing my current script.
As far as your error goes, what router firmware (exactly) and what router (exactly) are you using. I ask in that it may help me determine what may be the error.
Jason, are you using the new script instead of the one you linked to in your comment? I am using the one from your original comment, with the DNSMasq entry but I am still not seeing my true IP address in the Plex remote access section.
I have the debugging on in the script and am seeing this error, but I’m not sure if its a problem.
insmod: can’t insert ‘/lib/modules/2.6.36.4brcmarm/kernel/net/netfilter/ipset/ip_set_hash_ip.ko’: File exists
No… I have been to busy to mess with eibgrad’s script. He admittedly states that it is new, and he wishes that folks would ‘pound’ on it for awhile. He helped me out designing my current script.
As far as your error goes, what router firmware (exactly) and what router (exactly) are you using. I ask in that it may help me determine what may be the error.
Hi, thank you for the reply. I have the Netgear R7000 – Nighthawk AC1900. I am running v3.4-138 AIO-64K of AdvancedTomato.
Ugh, I figured it out. I didn’t realize the myipset at the end of the ipset dnsmasq custom configuration is how the list is identified in the script. I put that back at the end and it works now.
I am still going to watch what happens with that new script but messing with JFFS seems a little scary haha.
@cartman005 said:
Ugh, I figured it out. I didn’t realize the myipset at the end of the ipset dnsmasq custom configuration is how the list is identified in the script. I put that back at the end and it works now.
I am still going to watch what happens with that new script but messing with JFFS seems a little scary haha.
Great! I’m glad you got it.
The JFFS is just DDWRT’s method of storing/running scripts. You use a Tomato based firmware that has a specific GUI for scripts that would preclude you having to use JFFS through an SCP client. (I know… sounds daunting… SCP is just like an FTP client…)
This worked beautifully for me. Thank you so much! I’ve been looking for a solution like this for a long while, but I didn’t know how to implement it myself.
One thing I’ve noticed that I wonder if anyone else has seen/found a solution for: When autoplay begins the next title on Netflix on a Chromecast, it will often give the error We’re having playing this title at the moment.. You then have to manually find the episode and hit play (which works 90%+ of the time, but fails occasionally on the first try).
I suspect there’s still an IP/IP range being missed by the domain names people have suggested, but I’m not sure what it would be.
Edit: I wanted to add, my solution right now is to selectively route all of my Chromecast IPs (which are static) to bypass the VPN - so nothing to/from the Chromecast goes through the VPN. This resolves the issue as far as I can tell.
One thing I’ve noticed that I wonder if anyone else has seen/found a solution for: When autoplay begins the next title on Netflix on a Chromecast, it will often give the error We’re having playing this title at the moment.. You then have to manually find the episode and hit play (which works 90%+ of the time, but fails occasionally on the first try).
Edit: I wanted to add, my solution right now is to selectively route all of my Chromecast IPs (which are static) to bypass the VPN - so nothing to/from the Chromecast goes through the VPN. This resolves the issue as far as I can tell.
I’m voting on a timing issue… I think the ‘response’ time on your setup is allowing ‘old’ IP’s though before IPSET can refresh the internal hash.
While I cannot verify the efficacy, try eibgrad’s latest script (posted above…). He is a guru on these scripts!
@JasonMeudt said:
I get the full bandwidth on or off my VPN. If your not getting 100+, on a dual core (even a8 800Mhz…) there is a problem.
Start by disabling all the logging/qos/bandwidth limiting features.
Hi Jason, I’m paying for 60 Mb/s down, and if I turn the VPN off I always get at least 60 (usually 65). Over the last six months I’ve never had over 20 Mb/s down (usually about 14 Mb/s) with the VPN running.
I just assumed this was the trade-off for using the VPN. However, I just saw your post and was wondering if you had any specifics for settings to help increase speeds. I have QOS turned off. Not sure about logging or any other limiting features though. Any help is much appreciated. I’m running Shibby on a R7000.
Haven’t read through the full thread but hopefully the following is of some help.
In the VPN Client settings of DD-WRT there is a section titled policy based routing. If you type in specific IP address’s or an IP address range here only the specified address will go through the VPN all other traffic will go through the default gateway.
I use this the opposite way that most people do in that I want my entire PLEX server to go through the VPN. In this case I just DNAT commands in the Firewall Rules to forward the ports to my VPN provider and then my VPN provider will forward the ports through to their exit server.
My reasons are that my ISP used double NATing and cannot give me public IP address static or otherwise. With my setup once my DD-WRT router has an internet connection and this can be behind any firewall, router etc doesn’t matter all traffic is encrypted through the VPN and the ports are forwarded through the VPN to the VPN exit server.
@JasonMeudt said:
I get the full bandwidth on or off my VPN. If your not getting 100+, on a dual core (even a8 800Mhz…) there is a problem.
Start by disabling all the logging/qos/bandwidth limiting features.
Hi Jason, I’m paying for 60 Mb/s down, and if I turn the VPN off I always get at least 60 (usually 65). Over the last six months I’ve never had over 20 Mb/s down (usually about 14 Mb/s) with the VPN running.
I just assumed this was the trade-off for using the VPN. However, I just saw your post and was wondering if you had any specifics for settings to help increase speeds. I have QOS turned off. Not sure about logging or any other limiting features though. Any help is much appreciated. I’m running Shibby on a R7000.
Disabling all the logging/qos/bandwidth limiting features is the first stop. Go through all your option screens and turn off anything related to those options and your bandwidth should increase dramatically…
