Status: Up and running for 2 hours , basic setup as Gateway, static leases, OpenVPN client (on PIA) with Policy Based Routing up and running, 2,4GHz, 5Ghz, USB storage NAS working with errors and OpenVPN server working, Wireguard working (no need for script any more)
Errors: 1. Since the introduction of ksmbd, I cannot save to an ntfs partition on the routers USB drive: wrong parameter.
2. DNS leak see: http://svn.dd-wrt.com/ticket/6020
Otherwise build is fine
Resolved: 1. Pushed DNS servers from VPN provider are used starting with build 41120, if you do not want that, add the following to the Additional Config of the VPN client:
pull-filter ignore "dhcp-option DNS"
2. Build 41174 has an improved VPN Policy Based Routing, it is now possible to use the VPN route command i.e. to route a DNS server via the VPN (in this way you will get rid of the DNS leak), see: https://svn.dd-wrt.com/ticket/6815#comment:1 , and for DNS leaks the second posting of this thread: https://forum.dd-wrt.com/phpBB2/viewtopic.php?t=318662 3. Another improvement on PBR is that local routes are now copied over to the alternate routing table so there is communication if you have unbridged VAP's and you can set the router's IP on PBR.
See: https://svn.dd-wrt.com/ticket/6821#comment:3 4. Starting with build 41174, the PBR has become more versatile, you can now use " from [IP address] to [IP address] ", so if you enter the following in the PBR field:
192.168.1.124 to 18.104.22.168 #ipleak.net, it will only route IP address 22.214.171.124 (which is ip leak.net) from my IP address 192.168.1.124 via the VPN everything else from this IP address will route via the WAN (this is just an example).
Although this command itself supports routing per port this is however only available starting from K 4.17 so we have to rely on scripting for per port routing until then.
5. New OpenVPN TLS ciphers are added in 41308 see: https://svn.dd-wrt.com/changeset/41308 6. Starting with build 41304 you can now choose which TLS Key you want to use: TLS Auth or the newer/better TLS Crypt. See https://svn.dd-wrt.com/ticket/6845#comment:17 7. Builds from 41786 onwards, when using an OVPN server to connect to your local LAN clients, access might be prevented because of a patch which should solve a recent vulnerability ( see: https://svn.dd-wrt.com/ticket/6928)
This can be mitigated with the following firewall rule:
iptables -t nat -I POSTROUTING -o br0 -s $(nvram get openvpn_net)/$(nvram get openvpn_tunmask) -j MASQUERADE
When using WireGuard you can run into the same trouble,i.e. not being able to access your local LAN clients. For WireGuard this is the workaround:
iptables -t nat -I POSTROUTING -o br0 -s $(nvram get oet1_ipaddr)/$(nvram get oet1_netmask) -j MASQUERADE
This method described above also has security and logging concerns as all traffic has the same source address (your router)
An alternate method is using the following rule but it only works if the VPN or Wireguard interface is up and if your VPN or Wireguard interface goes down you have to reapply or run a continuous script checking/applying:
iptables -t raw -I PREROUTING -i br0 -d $(nvram get openvpn_net)/$(nvram get openvpn_tunmask) -j ACCEPT
iptables -t raw -I PREROUTING -i br0 -d $(nvram get oet1_ipaddr)/$(nvram get oet1_netmask) -j ACCEPT
This rule can expose your LAN side to the CVE attack, but if you have your IOT things separated and tight control over your LAN you should be good, if your LAN is hacked you have got bigger problems.
Builds starting with 41813 have an option button in OpenVPN and Wireguard for disabling the CVE-patch 14899
Status: Up and running for 2,5 hours, Gateway/WiFi AP, static leases in file dnsmasq.common, 2,4GHz N/G mixed dynamic, 5Ghz AC/N-mixed VHT80, one VLAN on either band, JFFS on thumb drive shared as JFFS2 over samba, no QoS, IPv4 & IPv6
Briks DLink DIR-825b!
Allows choosing of FW but doesn't upload; no answer from DIR.
No SSH, no Telnet and even no connection via Serial!
Glad to have tested on a non-productive device. Sad that this test-device has passed.