but for some reason it's not working. Perhaps I need to change the interface names to suit my setup ?
During my search on this topic, I've also found this customized script for IPVanish from eibgrad, which is supposedly allowing some IPs to 'bypass' the VPN and access internet in standard way - which would be very useful for me as well.
THe screenshot shows all the options I see..
I have no way to enter my login credentials, CA cert etc.
Do you have any idea why the VPN is dropping so much ?
This is my first paid VPN provider, so I'm not sure if this is normal. But for a paid subscription I'd expect the service to be 99% reliable.
well, I am running the Firmware: DD-WRT v24-sp2 (10/10/09) vpn. All the downloads on the site are from 2009.. so I am not sure if there's a newer version ?
The following "kill switch" will prevent all clients on the private network from accessing the WAN should the VPN drop.
Code:
WAN_IF="$(ip route | awk '/^default/{print $NF}')"
iptables -I FORWARD -i br0 -o $WAN_IF -m state --state NEW -j REJECT --reject-with icmp-host-prohibited
iptables -I FORWARD -i br0 -p tcp -o $WAN_IF -m state --state NEW -j REJECT --reject-with tcp-reset
As far as IPVanish, I see no reason they should require scripting to manage the OpenVPN client. Maybe years ago that was necessary, but not today. Because if you used the OpenVPN GUI, you could also use the policy based routing field to specify which source IPs you want to use the VPN. All others would only use the WAN. A lot simpler than having to learn all the details and modifications in that IPVanish script.
I also have a new script on PasteBin that automatically manages a kill switch based on the contents of the policy based routing field. The script reads the contents of policy based routing field and assumes all those IPs should also be prevented from accessing the WAN. So now you don't need to know anything about how to block the WAN should the VPN go down. It's all done for you, automatically.
The following "kill switch" will prevent all clients on the private network from accessing the WAN should the VPN drop.
Code:
WAN_IF="$(ip route | awk '/^default/{print $NF}')"
iptables -I FORWARD -i br0 -o $WAN_IF -m state --state NEW -j REJECT --reject-with icmp-host-prohibited
iptables -I FORWARD -i br0 -p tcp -o $WAN_IF -m state --state NEW -j REJECT --reject-with tcp-reset
As far as IPVanish, I see no reason they should require scripting to manage the OpenVPN client. Maybe years ago that was necessary, but not today. Because if you used the OpenVPN GUI, you could also use the policy based routing field to specify which source IPs you want to use the VPN. All others would only use the WAN. A lot simpler than having to learn all the details and modifications in that IPVanish script.
I also have a new script on PasteBin that automatically manages a kill switch based on the contents of the policy based routing field. The script reads the contents of policy based routing field and assumes all those IPs should also be prevented from accessing the WAN. So now you don't need to know anything about how to block the WAN should the VPN go down. It's all done for you, automatically.
eibgrad, I haven't been able to test that this works. when I pasted the code snipped into firewall rulesin my dd-wrt and rebooted I still get vpn traffic with no issue but I lost webgui on that router. any advice?
How are folks testing to see if this works? I assume if I disable OpenVPN in the GUI, this won't be a good "simulation" of a disconnect.
Would killing the openvpn process work? I'm not sure that's really the best option - since in a normal disconnect I'd have openvpn still running (presumably) but no connection to the VPN itself.
The following "kill switch" will prevent all clients on the private network from accessing the WAN should the VPN drop.
Code:
WAN_IF="$(ip route | awk '/^default/{print $NF}')"
iptables -I FORWARD -i br0 -o $WAN_IF -m state --state NEW -j REJECT --reject-with icmp-host-prohibited
iptables -I FORWARD -i br0 -p tcp -o $WAN_IF -m state --state NEW -j REJECT --reject-with tcp-reset
As far as IPVanish, I see no reason they should require scripting to manage the OpenVPN client. Maybe years ago that was necessary, but not today. Because if you used the OpenVPN GUI, you could also use the policy based routing field to specify which source IPs you want to use the VPN. All others would only use the WAN. A lot simpler than having to learn all the details and modifications in that IPVanish script.
I also have a new script on PasteBin that automatically manages a kill switch based on the contents of the policy based routing field. The script reads the contents of policy based routing field and assumes all those IPs should also be prevented from accessing the WAN. So now you don't need to know anything about how to block the WAN should the VPN go down. It's all done for you, automatically.
I also have a new script on PasteBin that automatically manages a kill switch based on the contents of the policy based routing field. The script reads the contents of policy based routing field and assumes all those IPs should also be prevented from accessing the WAN. So now you don't need to know anything about how to block the WAN should the VPN go down. It's all done for you, automatically.
Thank you for all your hard work. I have pasted this in my firewall scripts and will see how it works. Every night my VPN connection drops some time while I'm sleeping. I don't know if there is some sort of server reset or disconnect from IPVanish, or if it it just coincidence. I will see tomorrow morning if it happens again. Hopefully the IPs in my pbr fields will not be allowed on the WAN.
How are folks testing to see if this works? I assume if I disable OpenVPN in the GUI, this won't be a good "simulation" of a disconnect.
Would killing the openvpn process work? I'm not sure that's really the best option - since in a normal disconnect I'd have openvpn still running (presumably) but no connection to the VPN itself.
Ideas please!
I go to the Services->VPN tab, and then intentionally alter the VPN Server IP/Name by one character.
Throw in an extra letter or number, click save and then apply settings. It'll attempt to reconnect to the VPN at the new (most likely broken) address.
When I know the killswitch is working, I change it back, click save and apply settings again, and you're back in business.
WAN_IF="$(ip route | awk '/^default/{print $NF}')"
iptables -I FORWARD -i br0 -o $WAN_IF -m state --state NEW -j REJECT --reject-with icmp-host-prohibited
iptables -I FORWARD -i br0 -p tcp -o $WAN_IF -m state --state NEW -j REJECT --reject-with tcp-reset
I'm new to these iptables commands and I'm curious about how this works. If your router rebooted, couldn't the non-VPN connection get interpreted as the connection you want, and connecting to the VPN end up being the NEW state? Resulting in the opposite of what you're going for?
I'm trying to accomplish something similar to what people have described but am failing miserably.
My VPN is setup and working (OpenVPN, PIA).
The kill switch kindly provided by eibgrad works perfectly as expected however:
I’m trying to add two external /24 IP ranges that should never go over the VPN. Before applying the kill switch I’d add the following to the openvpn options
