Posted: Sun Aug 29, 2021 3:28 Post subject: OpenVPN routing for older DD-WRT routers with OpenVPN 2.4
Hello.
I finally figured out a bunch of things.
If you have a newer OpenVPN server with an older DD-WRT OpenVPN client, you'll bump into the tls-crypt vs tls-auth issue. The older DDWRT config system doesn't know how to configure tls-crypt. It will default to tls-auth and your client will never finish the connection. Here is how you can fix it. In the older clients, the server shows up as openvpnserver and the client as openvpn. But if you do a killall, both will shut down.
Administration -> Commands => Save Startup
Code:
sleep 20
sed -i "s/tls-auth/tls-crypt/" /tmp/openvpncl/openvpn.conf
PID=`ps | grep "openvpn --" | grep -v grep| cut -f1 -d\ `
if [ "$PID" != "" ] ; then kill -9 $PID ; fi
openvpn --config /tmp/openvpncl/openvpn.conf --route-up /tmp/openvpncl/route-up.sh --route-pre-down /tmp/openvpncl/route-down.sh --daemon
If you're having trouble getting the packets to flow, the automatic routing isn't as great in the older routers. So you'll need the following:
You'll notice I've used tun+ instead of a numbered value. This is because you might be running both client and server at once. Also, there is no guarantee that this is the only tunnel in use. But tun+ will accept all tunnels.
Joined: 18 Mar 2014 Posts: 12889 Location: Netherlands
Posted: Sun Aug 29, 2021 6:43 Post subject:
Very old clients do not have tls-crypt that was added almost two years ago in build 41304 (page 20 of the OpenVPN server setup guide)
New clients and server can handle tls-auth so you can also use that or better upgrade, older clients also have security issues.
Your firewall rules open up the clients firewall something you can do if you trust your VPN provider for 100%, something I do not, so perhaps not very safe to use.
Older clients had the firewall open and that has been corrected some time ago.
By default the OpenVPN clients firewall is closed (Inbound firewall on TUN is checked/enabled) by disabling this you can open up the firewall for your client e.g. if you want a site-to-site setup.
Posted: Sun Sep 05, 2021 3:11 Post subject: I'm the vpn provider. :)
You're right. I supply the VPN server. So I've opened it up on the r33555. I also did not have the tun firewall enabled. But I needed the rule anyway.
However, I've noticed that I'm still having a problem with packet flow in the r47206 build that I'm using. I'll have to test it out.
But I did want to point out that I have the tun firewall item turned off on that one too. I'm going to test this out. I think it might have to do with something in the firewall nat tables?
Is there another table I should look in?
P.S. Notice the RETURN before the last 2 MASQUERADES. I did not enter this. DD-WRT did. Do you know if this is fixed in a later build?
Code:
Chain POSTROUTING (policy ACCEPT 116 packets, 7456 bytes)
pkts bytes target prot opt in out source destination
1 84 MASQUERADE all -- * tun1 0.0.0.0/0 0.0.0.0/0
685 51898 SNAT all -- * vlan2 192.168.139.0/24 0.0.0.0/0 to:XXXXXXXXXX
0 0 SNAT all -- * vlan2 10.60.6.0/24 0.0.0.0/0 to:XXXXXXXXXX
0 0 SNAT all -- * vlan2 10.48.70.0/24 0.0.0.0/0 to:XXXXXXXXXX
0 0 RETURN all -- * br0 0.0.0.0/0 0.0.0.0/0 PKTTYPE = broadcast
0 0 MASQUERADE all -- * br0 192.168.139.0/24 192.168.139.0/24
0 0 MASQUERADE all -- * vlan2 10.60.60.0/24 0.0.0.0/0
Code:
Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
0 0 ACCEPT all -- tun1 * 0.0.0.0/0 0.0.0.0/0 state NEW
Code:
Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
0 0 ACCEPT all -- tun1 * 0.0.0.0/0 0.0.0.0/0 state NEW
