Posted: Sat Mar 10, 2018 18:24 Post subject: Figured out the block...
Ok, I finally figured out what was allowing VPN side to work, but blocking access to the nonVPN traffic. It was a killswitch (by sploit) script that had been left in the firewall. It was blocking nonVPN traffic. Had to comb over each setting and finally came across this, something that was tested a couple weeks ago.
So, now that I have that solved... anyone know of a killswitch for VPN traffic side stuff, but leave the nonVPN traffic alone? tx all. Continue leaning which is most excellent.
Thank you, yet again. I believe I am sorting out the functionality, finally. Am most appreciative of your and everyone's assistance in my next and next, and next questions.
Hopefully these exchanges will help someone else.
Where I am at now is... I believe I have managed the VPN v. WAN environment now. And am sorting out verifying things are working as well as can be expected, given the challenges that services like Hulu, Netflix, and so on, present. I am figuring out workaround, finally. With ya'll's assistance.
Note that I am rendering all this on older Buffalo routers, just to see how this can work, before I choose whether I dig into a more current Linksys router, and whether I pay to have it flashed with DD-WRT as well. At this point am not sure I will proceed. The problems being thrown up by Hulu, Netflix, and other vendors, grrrr. Not sure if it is worth it now.
But I have learned from everyone in this thread. Oh, and believe I have the killswitch now working too. And look, I know this is overstating it, but I do appreciate everyone's help in this. The learning aspect, the knowledge aspect of this... appreciated more than I could express.
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.
eibgrad,
Question for you. This script looks interesting, and I see that it fixes the table 10 problem that's been hounding me. Does it work on the latest beta builds? I've had to revert to build 441 to even get PBR to work at all. After 441, PBR seems to be broken - non-VPN clients cannot access the Internet at all.
Joined: 18 Mar 2014 Posts: 12913 Location: Netherlands
Posted: Tue Mar 20, 2018 16:39 Post subject:
I have been using PBR on all of Kong's recent builds without a problem.
To get my VPN clients local access I use @Eibgrad's script: https://pastebin.com/YwnHLqaa
To get PBR to work be sure to disable SFE (Shortcut Forwarding Engine) on Setup page, and disable your kill switch (@Eibgrad als has a kill switch for PBR)
I have been using PBR on all of Kong's recent builds without a problem.
Forgive me for my ignorance, but I'm not all that familiar with all of the dd-wrt variants out there. Where do I find the "Kong" builds and is there one available for the Asus AC3100?
To get PBR to work be sure to disable SFE (Shortcut Forwarding Engine) on Setup page, and disable your kill switch (@Eibgrad als has a kill switch for PBR)
Perhaps the kill switch is the crux of my problems right now. Would that result in the clients that do not route over the VPN losing connectivity after the router is running for a bit? How do I go about disabling that?
Yes a kill switch just disables all traffic over the WAN interface so disable the kill switch and your non VPN clients will start working.
The kill switch for PBR can be found at: https://pastebin.com/332rk3we (it is the one from @Eibgrad who is the master guru of advanced networking )
But first try without a kill switch to see if it is working
Sorry, but I'm a bit confused. My setup behaves as if I have a kill switch enabled, but I have not installed a script like this to enable it. Here is what I've done so far:
- Factory reset build 441
- Setup router from scratch - All clients routing through WAN okay
- Setup OpenVPN client - All clients routing through VPN okay
- Setup PBR - Works, but those routing to WAN cannot see local routes
- Install @Eibgrad's script: https://pastebin.com/YwnHLqaa - can now route locally
Everything works great for 24 hours or so, then those clients routing over WAN can no longer access the Internet. Suggests a kill switch kicks in, but I haven't installed one? How do I troubleshoot this?
Also, is a Kong build available for my Asus AC3100?
Joined: 18 Mar 2014 Posts: 12913 Location: Netherlands
Posted: Wed Mar 21, 2018 8:50 Post subject:
Kong only makes builds for the asus AC3200 and AC5300.
When a router works and suddenly stops it is very difficult to troubleshoot, could even be a hardware problem.
Is there local access when the WAN stops, run a traceroute/tracert to see where it stops.
You do not have any scripts running, cron jobs, access restrictions?
When the WAN stops what does the status page/WAN shows, do you still have an IP address attached to the WAN? There have been difficulties with WAN DHCP leases.
Just some thoughts, sorry I can not be more helpfull
Thing you can at least try: use the latest build 35384.
Always reset to defaults, most broadcom routers can do erase nvram from telnet, your Asus can probably best be reset by pressing WPS button, power off while holding, power on and release WPS after approx 20sec. But you should research what is the best way to reset, erase nvram can brick some routers. _________________ Routers:Netgear R7000, R6400v1, R6400v2, EA6900 (XvortexCFE), E2000, E1200v1, WRT54GS v1.
Install guide R6400v2, R6700v3,XR300:https://forum.dd-wrt.com/phpBB2/viewtopic.php?t=316399 Install guide R7800/XR500:https://forum.dd-wrt.com/phpBB2/viewtopic.php?t=320614 Forum Guide Lines (important read):https://forum.dd-wrt.com/phpBB2/viewtopic.php?t=324087
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.
I'm trying to use your PBR replacement script. I love the idea and I have high hopes. What I did is I took your script and under Begin Rules:
I left br1 because I want the guest network to bypass the VPN.
I put in my local IP addresses that I want to bypass the VPN.
I added a rule for target.com because I don't want that website to come through the VPN.
I put the entire script into Administration>Commands and Save as a Startup Script.
I deleted all PBR in the VPN and enabled syslogd.
I was using your ovpn-table-10-fix https://pastebin.com/YwnHLqaa but I deleted that. I also deleted a kill switch firewall I was using.
I think it was working for a moment for the hardwired devices. I've lost internet though for the guest network br1. And it looks like it's not rerouting target.com anymore either. Was there anything I missed or did incorrectly?
I'm using kiwisyslog and I was going to paste the syslog information into pastebin. There's a lot of information in the syslog and I'm new to providing syslog data.
Is all of the syslog data okay to provide? Should I be looking for something specific to provide back to you?
Mar 28 23:57:37 sidewalk daemon.err openvpn[1765]: event_wait : Interrupted system call (code=4)
Mar 29 00:39:51 sidewalk daemon.err httpd[1758]: Request Error Code 401: Authorization required. please note that the default username is "root" in all newer releases
)