Joined: 08 May 2018 Posts: 14213 Location: Texas, USA
Posted: Sun Dec 29, 2019 9:40 Post subject:
NTP must be enabled and GTK set to an interval to avoid those error messages... otherwise, they are trivial unless you use a function or feature that requires the timer to be working.
Wi-fi stability depends on how your device is configured. "Auto" channel and plain "Mixed" wireless mode is junk. Use the wikis and the sticky at the top of the forum
Status: Up and running for 8 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, OpenVPN server and WireGuard working.
Otherwise build is fine (this actually is build 41813 which has the radio button in the OpenVPN server GUI fixed for disabling the CVE 14899 patch)
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. Starting with build 41664 no problems with GTK renewal and authenticating problems, unbridged VAP works, for bridged VAP's this is still needed:
sleep 20; stopservice nas; wlconf eth1 down; wlconf eth2 down; wlconf eth1 up; wlconf eth2 up; startservice nas
8. 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
Asus RT-AC3100 Gateway/AP/OpenVPN Client File: asus_rt-ac3100-firmware.trx
Kernel: Linux 4.4.207 #585 SMP Sun Dec 29 15:04:45 +04 2019 armv7l
Status: Running for 45 minutes
This is build 41813. Applied update, disabled OVPN fix, rebooted (OVPN client being used to connect 2 sites and CVE fix breaks that configuration).
All appears working (SNMP changed indexes) and will report back in 2 days regarding 5 GHz connectivity.