Posted: Mon Mar 29, 2021 20:28 Post subject: DD-WRT OpenVPN client kill switch possible?
Hello,
I have a linksys flashed dd-wrt router(Firmware: DD-WRT v3.0-r44715 mega (11/03/20), but it's not a specific question for linksys, so i assumed it was a more general question.
Before i posted i searched, but i could not find info overhere...if there is, sorry.
I would like to know if there is an OpenVPN command to have a mechanism with OpenVPN client, like "killswitch" via the "additional config" section.
In the normal settings it does not exist, that is why i'm asking.
AFAIK, there is no OpenVPN option for these purposes. At least not one that would work w/ the router. OpenVPN does support the block-local argument w/ the redirect-gateway directive for these purposes, but that has two problems; 1) it's NOT relevant when using PBR (policy based routing) and 2) it would prevent communications between the router and the LAN, not just LAN devices being denied access to the WAN. It's really meant for a standalone OpenVPN client, NOT one that is acting as a gateway for other LAN clients.
I only mention it because some ppl might be tempted to use it.
A kill switch is pretty simple if you're NOT using PBR.
Using forum search for all terms "openvpn client kill switch", results listed as topics, yielded 116 matches.
Believe me, i did find the most of them as well, but i was not sure if firewall rules were needed, because with Wireguard there is a convenient "killswitch" button available.
So i hoped it could be done with some extra command in "additional config section".
AFAIK, there is no OpenVPN option for these purposes. At least not one that would work w/ the router.
Hmmmm...i think you anwered my question.
But still, i ask myself why with Wireguard it's possible.
and with OpenVPN not?
AFAIK, WG itself has no kill switch either. It's being managed solely by the router on your behalf. But in the case of the OpenVPN client, being older, a kill switch was never added (maybe it should be).
I get same thing 2days ago: OpenVpn drop and it revert back to the isp. So indeed a killswitch setting is quite needed. So i spend the morning reading on it from many post and diff config. So far, for my take :
here is the start of it in the syslog:
Code:
Mar 30 05:07:25 DDc7 daemon.err openvpn[1174]: TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Mar 30 05:07:25 DDc7 daemon.err openvpn[1174]: TLS Error: TLS handshake failed
Mar 30 05:07:25 DDc7 daemon.notice openvpn[1174]: SIGUSR1[soft,tls-error] received, process restarting
Mar 30 05:07:30 DDc7 daemon.warn openvpn[1174]: NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
Mar 30 05:07:30 DDc7 daemon.notice openvpn[1174]: Outgoing Control Channel Authentication: Using 384 bit message hash 'SHA384' for HMAC authentication
Mar 30 05:07:30 DDc7 daemon.notice openvpn[1174]: Incoming Control Channel Authentication: Using 384 bit message hash 'SHA384' for HMAC authentication
Mar 30 05:07:30 DDc7 daemon.notice openvpn[1174]: TCP/UDP: Preserving recently used remote address: [AF_INET]1xx.xxx.xxx.xxx:1194
Mar 30 05:07:30 DDc7 daemon.warn openvpn[1174]: --mtu-disc is not supported on this OS
Mar 30 05:07:30 DDc7 daemon.notice openvpn[1174]: UDP link local: (not bound)
Mar 30 05:07:30 DDc7 daemon.notice openvpn[1174]: UDP link remote: [AF_INET]1xx.xxx.xxx.xxx:1194
Mar 30 05:08:30 DDc7 daemon.err openvpn[1174]: TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Egc did good explanation: If you don't pass all the traffic, then it's policybr.. a table where you put the ip you don't want to pass by the vpn. It's just better to plug your ip camera or other stuff in the isp router at this point.. or as many router are availalbe now, 1 for local and firewalled and 1 for the vpn net.
So each ip will have their own rule.
https://forum.dd-wrt.com/phpBB2/viewtopic.php?t=318882
for the drop vs reject explanation:
https://forum.dd-wrt.com/phpBB2/viewtopic.php?t=320223
Then before adding the rule : ip rule show / ip route show table 11
and after , with a reboot : iptables -vnL FORWARD
that show the diff and if it's properly apply.
For openvpn client - if no policy stuff, dd-wrt have a build-in watchdog active. For wireguard it's not imbeded and to run script and so.. you need to add a usb drive , then activate/format as Jffs and then put the script on it.
The 1 liner do work for most, but some router might not get the proper info.
Code:
iptables -I FORWARD -s 192.168.1.64/26 -o $(get_wanface) -m state --state NEW -j REJECT
And as with some revision wlan.. or so adressing change from time to time on firmware, the wan_iface is less solid than the iproute pulling the info.
WAN_IF="$(ip route | awk '/^default/{print $NF}')"
So as from 2017 and still used on nord and proton:
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
But it only give new connection.
Without the state new: it's active for all connection and espacially those already up.. and those the should not be anymore if the Vpn disconnect:
and still used on nord and proton:
If using the wifi .. it seem it might not work and a different one is neede, but only see that from 10nov17. as no wlan is called and only the bridge..
iptables -I FORWARD -i br0 -o br0 -j REJECT
It it helps i use this script in the command (save firewall)
iptables -I FORWARD -i br0 -o `nvram get wan_iface` -j DROP
It blocks vpn drop bypasses 100% of the time but if your ip changes it will cause the internet to drop until you renew DHCP and restart the openvpn (disable openvpn, apply, enabled openvpn, apply).
Joined: 08 May 2018 Posts: 14249 Location: Texas, USA
Posted: Thu Apr 15, 2021 16:25 Post subject:
@DDWRTaway: I removed the thread you neutered since you failed to restore your posts and I've unlocked your other thread. Please do not cross-post in the future per forum rules and guidelines. Thank You.
Missed this earlier... There is no such thing as a "reject with udp reset." UDP is connectionless, so there is nothing to reset. This is a long-standing (years) error in the Nord VPN instructions for dd-wrt. Just drop the "--reject-with..." part on that command if you really want all three. Note that when iptables encounters a malformed command line, it does nothing, so this third firewall rule is actually a no-op. No firewall entry is created.
That said, I'm on the verge myself of moving away from using three iptables commands like this, because I have many copies for different interfaces and source subnets due to heavy PBR use and running three VPN clients (OpenVPN + two wireguard). The massive firewall appears to be hurting my OpenVPN speed. (Tentative conclusion... need to explore.) _________________ 2x Netgear XR500 and 3x Linksys WRT1900ACSv2 on 53544: VLANs, VAPs, NAS, station mode, OpenVPN client (AirVPN), wireguard server (AirVPN port forward) and clients (AzireVPN, AirVPN, private), 3 DNSCrypt providers via VPN.
Any build after 46340 should include OpenVPN client Kill switch in the ovpn client section. _________________ Netgear R7800 PPPoE Main Router
Network IPV4 - Isolated Vlan's with IoT Devices. Unifi AC-Pro x 3 AP's, Router Wi-Fi Disabled. OVPN Server With Paid Commercial Wireguard Client's. Gateway Mode, DNSMasq, Static Leases & DHCP, Pi-Hole DNS & Running Unbound.
No one can build you the bridge on which you, and only you, must cross the river of life!