The script actually loaded and worked again(plex connected) this time. Still the other problem with the whole machine over the wan.
One thing I've noticed is for the times the script loads properly, it takes several minutes (literally) for the router to boot up. Is this to be expected?
Anyway, I used the kill/restart openvpn command and then ran the other ones.
The script actually loaded and worked again(plex connected) this time. Still the other problem with the whole machine over the wan.
One thing I've noticed is for the times the script loads properly, it takes several minutes (literally) for the router to boot up. Is this to be expected?
Anyway, I used the kill/restart openvpn command and then ran the other ones.
Its not not normal for me, no.
What it's doing is starting the VPN, then the script kills it, and starts its own instance that it can control - so, you could expect longer than it was before, but not minutes unless something else is going on.
Looking over the logs....looks like DNS is having trouble with resolving.
Cannot resolve host address: uswdc1-ovpn-udp.pointtoserver.com
Just to test - can you try the IP instead?
if that works better, ill think it out.
Also - it looks like its using the WAN as the default for table 200.
add_rule -i vlan2 <-- here; thats why the machine is talking over the WAN
here it should be using tun0 instead
Did you add the "route-noexec" directive to the openvpn config? You need to add that to redirect the gateway.
I will say that i have a concern that "ip rule show" isn't showing anything... not sure what that means, or will mean.
I did not add the route noexec command, didn't know I was supposed to.
Instruction #5 in the script.
Basically it means you toggle the way the rules work.
If you DON'T add the route-noexec directive then all traffic will go over VPN by default and you use the rules to send specified traffic over the WAN.
If you DO add the route-noexec directive, then all traffic will go over the WAN by default and you use the rules to send specified traffic over the VPN.
They way I modified the script for you - I make the assumption that the directive is used. I thought I made that part clear when we talked about how I modified it. Sorry if it wasn't clear enough.
Thisis actually encouraging news, since you said the traffic for the machine was going over the WAN - it means that the rules made the machine use the alternate routing table as expected [although the rules in the table were wrong]
This is assuming that the devices that did not have rules were still communicating over the VPN.
They way I modified the script for you - I make the assumption that the directive is used. I thought I made that part clear when we talked about how I modified it. Sorry if it wasn't clear enough.
I know you said it would work the opposite of what I was used to, but I thought you had modified the script in a way that it was the default. Didn't know I had to use the route-noexec command. Probably should have removed the word "optional" from Instruction #5.
Anyway, It did boot up much faster using the IP for the vpn server. However, the route-noexec command didn't change anything. The entire machine still connected over the ISP.
Anyway, It did boot up much faster using the IP for the vpn server. However, the route-noexec command didn't change anything. The entire machine still connected over the ISP.
The iptables look perfect as far as i can tell.
Traffic to plex.tv is being marked with 2, while the rest of that machine traffic is marked with a 1.
It does show at least some traffic went over the vpn, how certain are you that it didnt work?
If that's not working for you... I'm out of ideas.
The only thing i see missing is the output of "ip show rule" - so there is one thing that I could change in the monitoring script for you - but that wont change the routing, it'd just be a little faster.
You said you were using the basic script previously? that only uses ip rules - so seems like rules work, even if the output isnt there,
You could also add the firewall script to block that machine from talking over the wan interface - this would make it easy to see if its talking on the vpn.
Maybe eibgrad can see something in there that I cannot.
I say it did not work because when I go to any "whats my IP" type site it shows my ISP.
I never used the basic script, I previously used the advanced script, but the only time it worked for me was when eibgrad first posted it. I suspect that when he upgraded it to create "tun0" and block incoming traffic is when it stopped working.
If I add the firewall script to block that machine from talking over the wan, then it will also prevent plex from connecting right?
If I add the firewall script to block that machine from talking over the wan, then it will also prevent plex from connecting right?
No.
An exception is added to the firewall to allow plex traffic through.
When you add a rule, it is marked as a 1. This means it runs over the VPN.
All Plex traffic is marked with a 2, this tells it to go over the WAN, and also there is a rule in the killswitch to allow traffic marked with the 2.
The blocking rules are evaluated in order, and since the 2 is evaluated first it is allowed through the WAN, even though its from the machine that is only allowed to use VPN.
Quote:
when he upgraded it to create "tun0" and block incoming traffic is when it stopped working
Have you tried not using tun0? There's a line you can comment out to continue with the default.
Just comment out the CONFIG_SECURE_FIREWALL option.
Okay so I ran the script and firewall together as you said, adding in a rule for 1 other device and adding that IP to the firewall as well. Everything seems to be working as it should. I'll now have to go back and add rules for the other devices.
I believe you said there is a killswitch built in to the firewall script as well? I will test that as well to make sure it is functioning.
So as soon as I added the rules for the other 3 devices and added their IPs to the firewall script I got the endless cycle of not being able to resolve again. I tried switching to the servers IP address and got an endless cycle of reconnecting- tls error. I wound up having to reset to factory defaults again and start from scratch so I'm back to my old method again. I ran the codes from telnet before I reset, but don't know it will tell you anything.
I believe I've finally found the problem w/ using domain names.
It had nothing to do /w dnsmasq (at least not directly). It was a case of the "ROUTE_DNS_THRU_VPN" setting being enabled. Given this was placed at the top of the script (in the handle_openvpn_routes function), it had the potential to fail DNS queries because DNS resolution was occurring across the tunnel before the tunnel was completely ready to accept traffic (maybe due missing firewall rules, timing of other events, whatever). So I moved things around so that all the rules are added before dealing w/ any of the routing changes/additions.
I suppose there's still the potential for dnsmasq being a problem if it's in an interim state. But so far in my testing, these latest changes seem to have been sufficient. I did the same thing w/ the tomato scripts and it fixed the problem there as well.
All scripts have been updated to reflect these changes.
Hello @Eibgrad,
Would it be possible for you to develop a dd-wrt script based on 0.1.7 advanced version for tomato? I got dnsmasq and ipset working on dd-wrt, so it would be great being able to try an ipset based advanced script for it. Is there any particular reason, except people having to compile its own xt_set.ko module, for not providing ipset based sh for dd-wrt?
I believe I've finally found the problem w/ using domain names.
It had nothing to do /w dnsmasq (at least not directly). It was a case of the "ROUTE_DNS_THRU_VPN" setting being enabled. Given this was placed at the top of the script (in the handle_openvpn_routes function), it had the potential to fail DNS queries because DNS resolution was occurring across the tunnel before the tunnel was completely ready to accept traffic (maybe due missing firewall rules, timing of other events, whatever). So I moved things around so that all the rules are added before dealing w/ any of the routing changes/additions.
I suppose there's still the potential for dnsmasq being a problem if it's in an interim state. But so far in my testing, these latest changes seem to have been sufficient. I did the same thing w/ the tomato scripts and it fixed the problem there as well.
All scripts have been updated to reflect these changes.
Hello @Eibgrad,
Would it be possible for you to develop a dd-wrt script based on 0.1.7 advanced version for tomato? I got dnsmasq and ipset working on dd-wrt, so it would be great being able to try an ipset based advanced script for it. Is there any particular reason, except people having to compile its own xt_set.ko module, for not providing ipset based sh for dd-wrt?
Thank you
When I developed those scripts, I spent a lot of time making sure they worked flawlessly (or as close as humanly possible) so ppl could rely on them. Over the years, there's simply been too many half-baked scripts floating around that come up short here or there. So I wanted a *definitive* set of scripts that would stand the test of time.
So with that in mind, my thinking has always been to keep things as generic as possible so it works on virtually every dd-wrt/tomato build, and NOT delve into questionable areas like ipset. Esp. when I had the option to tell ppl to move to Tomato (at least in some cases) if you need that feature. Last thing I want to do is make the scripts less reliable because I'm monkeying around w/ something I can't count on being there!
So could I build a version based on dd-wrt and ipset using the same methodology? I suppose, provided I have a compatible router. I didn't look all that closely at those modules as far as compatibility. And I don't know how long it might take either. Let me look into it.
I perfectly understand and thank you in advance for your help, and for if and when you'll be able to look into it.
# 1. add/modify rules to/in script for rerouting purposes; alternatively,
# rules may be imported from filesystem using extension .rule:
# /jffs/myrules.rule
# /jffs/myrules2.rule
Is there any specific syntax for the myrules.rule? I could export ip addresses I got with ipset+dnsmasq (only ipv4 of course), rename and batch modify the file for your script.
# 1. add/modify rules to/in script for rerouting purposes; alternatively,
# rules may be imported from filesystem using extension .rule:
# /jffs/myrules.rule
# /jffs/myrules2.rule
Is there any specific syntax for the myrules.rule? I could export ip addresses I got with ipset+dnsmasq (only ipv4 of course), rename and batch modify the file for your script.
The syntax is exactly the same as they appear in the add_rules function of the script.
All it does it read them from a file rather than the script.
I managed to use your script for ip addresses, but there's no way to account every single ip used by Netflix, and using domain names (which is also not recommended as per your instructions) will fail.
Chain OUTPUT (policy ACCEPT 25755 packets, 4241K bytes)
pkts bytes target prot opt in out source destination
Chain POSTROUTING (policy ACCEPT 68463 packets, 23M bytes)
pkts bytes target prot opt in out source destination
Output from "ip route show table main":
0.0.0.0/1 via 10.16.0.1 dev tun1
default via 192.168.178.1 dev vlan2
10.16.0.0/16 dev tun1 proto kernel scope link src 10.16.0.4
127.0.0.0/8 dev lo scope link
128.0.0.0/1 via 10.16.0.1 dev tun1
169.254.0.0/16 dev br0 proto kernel scope link src 169.254.255.1
192.168.2.0/24 dev br0 proto kernel scope link src 192.168.2.1
192.168.178.0/24 dev vlan2 proto kernel scope link src 192.168.178.30
<vpn_public_ip> via 192.168.178.1 dev vlan2
Output from "ip route show table 100":
default dev vlan2 scope link
Output from "ip rule list":
0: from all lookup local
100: from all fwmark 0x1 lookup 100
32766: from all lookup main
32767: from all lookup default
I haven't enough experience to solve this problem by myself, but I guess marked packets are not being correctly routed to wan gateway...
