Netgear WNDR3700 V4
DD-WRT v3.0-r42925 std (04/18/20)
Linux 3.18.140-d4 #76331 Sat Apr 18 05:41:17 +04 2020 mips
GUI install over r42912
Uptime 6:05
#
everything working very well for me. samba is good and
both units OVPN servers with new ovpn 2.4.9 is all good
AND yea, the EA8500 in r42925 directory is r42926
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 95.85.16.212 #ipleak.net, it will only route IP address 95.85.16.212 (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).
See: https://svn.dd-wrt.com/ticket/6822
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:
Code:
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:
Code:
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:
OpenVPN server:
Code:
iptables -t raw -I PREROUTING -i br0 -d $(nvram get openvpn_net)/$(nvram get openvpn_tunmask) -j ACCEPT
WireGuard:
Code:
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
Router: Netgear R7800
Firmware: DD-WRT v3.0-r42926 std (04/18/20)
Kernel: Linux 4.9.219 #539 SMP Tue Apr 14 00:38:01 +03 2020 armv7l
Status: Working
Reset: No
Previous: 42847
Errors: No
Temperatures : CPU 58.588 °C / ath0 55 °C / ath1 53 °C
New : OpenVPN 2.4.9 arm-unknown-linux-gnu
Working very well :
Router mode : DHCP
SFE Enable STP Disable
DNSMasq
Cache DNSSEC data
Validate DNS Replies (DNSSEC)
Check unsigned DNS replies
Local DNS
No DNS Rebind
ath0, ath1
Vpn (OpenVPN Client)
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
Router: TL-WDR3600 v1
Firmware: tl-wdr3600_us-webflash.bin (v3.0-r42925 std)
Kernel: Linux 3.10.108-d10 #44678 Sat Apr 18 03:19:15 +04 2020 mips
Status: working
Reset: No
Notes on configuration:
Client
Errors:
1. 5Ghz wireless light is not on (2.4Ghz light works)
Router: DIR-825 rev B1
Firmware: dir825-firmware.bin (v3.0-r42925 std)
Kernel: Linux 3.10.108-d10 #44676 Sat Apr 18 03:05:48 +04 2020 mips
Status: Working
Reset: No
Notes on configuration:
DNSMasq
Virtual wireless with bridging x2
multiple DHCP server
Briks DLink DIR-825b!
Recovery Mode:
Allows choosing of FW but doesn't upload; no answer from DIR.
Putty:
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.
ervau
Issues/Errors: In every build after r42847 wireless TX Power is limited to 16dBm. I tried with different Regulatory Domain without success. Back to r42847 and TX Power is OK - 21dBm.
