Posted: Fri Jun 21, 2019 15:22 Post subject: VPN Kill Switch
I'm trying to setup a VPN kill switch in my dd-wrt. I've found a few solutions online. I'm hoping someone can help me learn which one is a better path and why
Go to the Administration > Commands section and paste in the following script:
Option 1:
Quote:
iptables -I FORWARD -i br0 -o vlan2 -j DROP
Option 2:
Quote:
iptables -I FORWARD -i br0 -o `nvram get wan_iface` -j DROP
Option 3:
Quote:
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
Joined: 18 Mar 2014 Posts: 3647 Location: Netherlands
Posted: Fri Jun 21, 2019 16:29 Post subject:
They are all the same for most modern routers vlan2 is the WAN interface but older routers use vlan1
Therefore option 1 is not recommended
The difference between option 2 and 3 is the way the WAN interface is determined, options 2 is the "normal" one but theoretically there could be setups where that does not work so theoretically option 3 is the best
DROP is just dropping the packets, REJECT is gracefullly letting the clients know that there is no route, some older applications do not time out and in that case REJECT is the gracefull option.
state NEW is the more accurate as it only blocks the outgoing new connections
My favourite kill switch:
Code:
iptables -I FORWARD -i br0 -o $(nvram get wan_iface) -m state --state NEW -j REJECT
But all will work (if you have a modern router with vlan2 as the WAN)
It is all a matter of opinion and there are also more like:
Code:
iptables -I FORWARD -s 192.168.0.0/16 -o $(nvram get wan_iface) -m state --state NEW -j REJECT
Usefull if you have more subnets and bridges as the rules we discussed only blocks traffic on br0
@egc does a very good job explaining it, but here's my take as well (esp. since I wrote the third option).
The first and second options are effectively the same, however, the first option *assumes* the WAN network interface is vlan2, which might not always be the case (for example, it might be vlan1 w/ some older routers), while the second option tries to determine the WAN's network interface name dynamically. So of those two, the second option is preferred.
That said, the use of the nvram variable wan_iface to determine the WAN's network interface name is itself not 100% reliable. In the case of client mode, it would likely fail. That's where the third option (the one I wrote ) is better. It parses the actual routing table to find the WAN's network interface.
Also, the third option offers the advantage of being able to support port forwarding to those same clients over the WAN because it's checking the state of the connection. But that comes at the price of *maybe* some client at bootup, before the firewall is completely established (there's always a small window of opportunity, perhaps just a couple seconds, where the WAN is up but the firewall lags) to get a connection started. And using the third option would NOT stop that connection from continuing.
So unless you need port forwarding to those same clients, the following is probably the most complete and simplest solution.
IOW, other than the router itself, *everything* is denied access to the WAN. The private network (br0), and guest or IOT networks you later define (e.g., br1, br2), any additional VAPs (e.g., wl0.1), etc., all are denied access, both outbound and inbound (for remote access purposes), at all times.
I should add that, as @egc suggests, there is no one perfect solution that will work in absolutely every case.
For example, if you decide to use PBR (policy based routing) w/ the OpenVPN client, then obviously only *some* clients should be denied access to the WAN, specifically, those listed in the PBR field. That creates the need for a more complex kill switch that can discriminate among those using and NOT using the VPN. For that reason, I wrote the following script a few years ago to make it much simpler to manage a kill switch while using PBR.
Interesting thread.
My VPN provider recommends Option 1.
I often alter the VPN server chosen to access different countries eg BBC iPlayer on UK servers.
Recently I misspelt the VPN server name in my EA8500 setup.
The VPN failed to connect successfully, but I still had internet access.
I tested the Option 3 Simplified version with a deliberate server typo > no internet = works great! _________________ ------------------------------------
Linksys EA8500 DD-WRT r40672 (Gateway + OpenVPN Client)
Linksys WRT1900ACv1 DD-WRT r40672 (AP)
Photos: https://www.flickr.com/photos/nickant44/albums
Interesting thread.
My VPN provider recommends Option 1.
I often alter the VPN server chosen to access different countries eg BBC iPlayer on UK servers.
Recently I misspelt the VPN server name in my EA8500 setup.
The VPN failed to connect successfully, but I still had internet access.
I tested the Option 3 Simplified version with a deliberate server typo > no internet = works great!
If you know for sure the WAN's network interface name (and a dump of ifconfig will tell you, it's the one w/ the public IP), then you can simplify the kill switch even further and just specify it directly.
OK, but I'm not entirely sure about this.
ifconfig only on my Linux PC.
Can't really interpret the info.
My ISP provides a static IP for me.
The server IP address will change depending upon which VPN server I'm connected to.
Are you referring to the VLAN IP address ie router IP?
Maybe for dummies like me it's best that the firewall rule complete these enquiries dynamically as it does in Option 3 Simplified. _________________ ------------------------------------
Linksys EA8500 DD-WRT r40672 (Gateway + OpenVPN Client)
Linksys WRT1900ACv1 DD-WRT r40672 (AP)
Photos: https://www.flickr.com/photos/nickant44/albums
