Posted: Thu Mar 08, 2018 7:56 Post subject: Sending some Ips over VPN, and some bypassing...
I know this is beating a horse. Have read backwards and tried to figure this out but must ask for expert advice...
I have a DD-WRT router. Works great. An older Buffalo DD-WRT and am considering upgrading to a Linksys flashed with DD-WRT.
Problem is, we have Hulu, Netflix, and other services that barf on running VPN. A well known and oft discussed problem. I do not care if the TV side of my network runs over VPN or not. I have other devices I want to run over VPN.
I also cannot assign a static IP inside my subnet from the ROku based TV. But I can assign a static IP within the DHCP range to the TV.
Having said that... what I thought would be possible is, or rather... is it possible to direct some devices go through the VPN and other devices to bypass the VPN and go straight out which this latter would satisfy the complaints by Netflix, Hulu and similar entities? Can anyone point to how to accomplish this?
Actually, now that I think of it... is there a way to assign IPs that will NOT be routed thru the VPN?
Reason for asking is... the two devices that I do NOT want to go thru the VPN cannot be assigned static IPs. They can only request DHCP addresses. Which means they would automatically go thru the VPN. Is there a way to have a device that I can force to have its DHCP address assigned in DD-WRT, but then force it to NOT go through VPN?
So if you want to route just one client (e.g. 192.168.1.89) then fill in: 192.168.1.89/32 in the PBR field
Thank you for your reply. Much appreciate your expertise I have been reading.
So here is the $64 question. How do I route an IP to NOT go out the VPN? If I can statically assign a device to an IP which of course can do... how can I force it to NOT use the VPN but instead, go directly out? tx
Thankx for all the replies and guidance. I have worked to apply the information and it appears to be working.
One additional question on all this. The script that is recommended to resolve the default clients in the PBR field can not communicate with the local net... need to ask who is running this script? Has it worked for you? Is it trusted? Etc etc...
Tho it looks good. Needed to ask. Much appreciated all the replies. Always learning more and more...
egc wrote:
One more remark, by default clients placed in the PBR field can not communicate with your local net work (it can be considered a bug).
@Eibgrad made a script to resolve this see: https://www.dd-wrt.com/phpBB2/viewtopic.php?t=314148
OpenVPN set up and has been working A-ok. Have found under this setup Hulu fails (proxy complaint… waiting for Netflix to re-complain as it did 3-4 days ago, a well known problem I have read when running a VPN.
Ok, then followed directions here to split things up. To force some IPs over the VPN and others to run regular out the WAN. To do that I assigned 4 MAC addresses/IPs in static leases, outside the DHCP pool.
Then added these IPs to the PBR field. Restarted (a zillion times).
VPN works. The assigned IPs to the static leases work out the VPN. But…
.. the unassigned IPs fail. They cannot see anything on the internet.
I’ve combed over the set up, resetting everything, checking my work. No go. The unassigned IPs simply will not work when an IP is added to the PBR.
Of note, I added the IP as is, and then added the IP with CIDR notation, both. No go.
Am stuck. Will keep at it but, ideas anyone? I can taste it working, but am missing something of course. Sigh. Help?
And as a note.. I have not tried to use either script yet as I need to make sure the function of placing IPs in the PBR get pushed out the VPN, and everything else is pushed out the standard WAN, works. Just want to make sure that framework works before I double down and then it become harder to troubleshoot. Am studying your scripts and descriptions as well, but focusing on the primary method first. Which as described is not working yet for me, sigh.
eibgrad wrote:
All the information in this thread is good, but I thought I'd throw in a few clarifications.
You don't *have* to use CIDR notation. Not unless perhaps you ran out of storage in the GUI or nvram. We only *suggest* it as a convenience. And the only reason it's a convenience is because the router only implements PBR w/ a single orientation; once you add anything to the PBR field, only those source IPs use the VPN, all other use the WAN.
That's all well and good, but there's the case where the user only wants one or two devices to use the WAN. And it would be *convenient* to just specify those in the PBR field. But it just doesn't have that capability. You're only option is to work w/ the one orientation available; list everything *but* the one or two devices you want routed over the WAN in the PBR field. And now the use of CIDR notation becomes convenient since it vastly reduces the number of source IP you need to specify in the PBR field.
FWIW, I have a full PBR replacement script that supports either orientation. It detects which gateway (WAN or VPN) is the default, then interprets the PBR rules as exceptions that should be routed over the other gateway, thus solving this particular problem (or at least annoyance). It also fixes numerous other bugs (like the table 10 problem w/ missing routes). I did this purposely to avoid having to install and manage multiple scripts.
It even has the ability to implement PBR based on network interfaces, or even destination IPs, not just source IP. I suppose the GUI could have embraced that as well, but it just didn't. The intent was to keep things simple.
I also have a second script that uses a different PBR technique (based on marking packets) that allows a much finer grained control over what is and isn't routed over the WAN or VPN (protocol, ports, etc.), not just source IP.
Like the other script, it incorporates the same bug fixes.
Normally I don't push these scripts all that much on dd-wrt users, mostly because I'd prefer users stick w/ the GUI whenever possible, even if things sometimes get a little awkward (e.g., this issue of having to add long lists of source IP into PBR). But in some cases, you have no other choice than to implement your own solutions (or borrow them from others) via scripting. So at least you have other options available when the GUI falls short.