Your router's clock isn't set. Double check NTP and DNS settings.
Yes @RMerlin with the good date and time it works fine now ! don't know why the date reset to 2018 after the update...
Thank you very much for your work and help !
Your router's clock isn't set. Double check NTP and DNS settings.
DNS mode disabled. If I set Custom to 1.1.1.1 then Cloudflare DNS gets correctly set. If I set Custom to 8.8.8.8 then the reported DNS is the VPN DNS?!If that client is set to use the VPN and you have DNS mode set to Exclusive, then this is working as intended.
- NOTE: closed down the Issue tracker on Github, as 90%
of it was people asking for technical support,
or failing to use the supplied submission form.
- CHANGED: Re-disabled jitterentropy-rngd on non-HND
models. It kept using CPU time every two
seconds and had a very marginal impact on
the entropy pool (which it never could push
above the target threshold of 1024).
- CHANGED: Moved the "Redirect Internet traffic" setting on
the OpenVPN Client page to the Network Settings
section to increase its visibility, as too many
users are forgetting to configure it.
- CHANGED: Display "Internet traffic not redirected" instead
of "Public IP Unknown" on the OpenVPN Client
status display when Redirect Internet traffic
is set to "No".
- FIXED: Only the first OpenVPN client would be used if
you had multiple clients connected and the first
one had a Redirect Internet set to "No". Now,
setting this to "No" means that client's routing
table will no longer get a default gateway
configured, allowing traffic to be processed
by other RPDB tables if there wasn't a matching
route within that client's table.
- FIXED: IPV6-compatible DNSFilter servers weren't
properly configured in dnsmasq.
- FIXED: DNSFilter client rules may get corrupted after a
reboot.
Check what DNS server your VPN provider uses - some of them actually use 8.8.8.8.DNS mode disabled. If I set Custom to 1.1.1.1 then Cloudflare DNS gets correctly set. If I set Custom to 8.8.8.8 then the reported DNS is the VPN DNS?!
Put the kettle on...386.3_2 is now available.
There goes my 14 days... updating in 5!Put the kettle on...
APs updated, will do the Router later tonight.
That is what I was thinking maybe they use the same servers. Or maybe the VPN provider redirects queries bound for 8.8.8.8 by substituting its own dns. I honestly don't know if this is possible though.Check what DNS server your VPN provider uses - some of them actually use 8.8.8.8.
@RMerlin , I understand you are a wizard and all but is it truly August 8th where you are?Asuswrt-Merlin 386.3 is now available for all supported model. This release introduces major changes to OpenVPN client handling, and also introduces the ability to generate QR Codes to make it easier to connect your mobile clients to your Wifi network.
August 8th 386.3_2 is now available.
Code:- NOTE: closed down the Issue tracker on Github, as 90% of it was people asking for technical support, or failing to use the supplied submission form. - CHANGED: Re-disabled jitterentropy-rngd on non-HND models. It kept using CPU time every two seconds and had a very marginal impact on the entropy pool (which it never could push above the target threshold of 1024). - CHANGED: Moved the "Redirect Internet traffic" setting on the OpenVPN Client page to the Network Settings section to increase its visibility, as too many users are forgetting to configure it. - CHANGED: Display "Internet traffic not redirected" instead of "Public IP Unknown" on the OpenVPN Client status display when Redirect Internet traffic is set to "No". - FIXED: Only the first OpenVPN client would be used if you had multiple clients connected and the first one had a Redirect Internet set to "No". Now, setting this to "No" means that client's routing table will no longer get a default gateway configured, allowing traffic to be processed by other RPDB tables if there wasn't a matching route within that client's table. - FIXED: IPV6-compatible DNSFilter servers weren't properly configured in dnsmasq. - FIXED: DNSFilter client rules may get corrupted after a reboot.
NOTE: On first boot with 386.3, you must either force-refresh the browser page (shift-reload), or clear your browser cache. Failure to do so will prevent the new QR codes from being properly displayed, due to an old cached CSS.
The highlights of this release:
- QR Codes can now be generated both on the Network Map (first index page of the webui), and on the Guest Network page. QR Codes are supported by iOS as well as most modern Android mobile devices (see your device's documentation for more information on how to use it) making it easier to connect to a Wifi network.
- Introducing VPN Director, which replaces the previous per-client Policy routing rules with a centrally managed page. More details in the Wiki: https://github.com/RMerl/asuswrt-merlin.ng/wiki/VPN-Director.
- OpenVPN routing handling was rewritten, allowing the implementation of VPN Director, but also bringing additional fixes and improvements. Routes are now created by the firmware itself rather than by the OpenVPN process.
- OpenVPN DNS handling was revised, resolving various quirks and issues related to it
- Improved OpenVPN kill switch behavior, it can now be used with clients set to route All traffic through
- Component updates: nano (5.7), curl (7.76.1), dnsmasq (2.85-openssl), openvpn (2.5.3), getdns (1.7.0), stubby (0.4.0)
Please review the Changelog for more details.
Please keep discussions to this specific release. This thread will be locked after a while once the release feedback has died down.
Downloads are here.
Changelog is here.
Check this out: announcement-running-asuswrt-merlin-and-forks-on-non-asus-devices-is-illegalR7000 router successfully running 384.19. Any subsequent versions will install and then tend to have at least daily LAN/Wifi disconnect on each version. I did a dirty flash first for each version I upgraded to and had reboot issues. Then performed a system default for each version and formatted the JFFS partition multiple times. In all versions past 384.19 I get random disconnects. Only way to fix is to reboot the router. Any assistance would be greatly appreciated. I am running CFE 1.3.0.7. Thanks John
Aside from the (perhaps not to you at the time) obvious that running one vendors firmware on another vendors hardware is legally frowned upon; you wont get support if you do decide to pursue that path. At least not in any vendor specific, public forum.R7000 router successfully running 384.19. Any subsequent versions will install and then tend to have at least daily LAN/Wifi disconnect on each version. I did a dirty flash first for each version I upgraded to and had reboot issues. Then performed a system default for each version and formatted the JFFS partition multiple times. In all versions past 384.19 I get random disconnects. Only way to fix is to reboot the router. Any assistance would be greatly appreciated. I am running CFE 1.3.0.7. Thanks John
Check what DNS server your VPN provider uses - some of them actually use 8.8.8.8.
I use NordVPN. They offer the following DNS's: 103.86.96.100 and 103.86.99.100.That is what I was thinking maybe they use the same servers. Or maybe the VPN provider redirects queries bound for 8.8.8.8 by substituting its own dns. I honestly don't know if this is possible though.
Welcome To SNBForums
SNBForums is a community for anyone who wants to learn about or discuss the latest in wireless routers, network storage and the ins and outs of building and maintaining a small network.
If you'd like to post a question, simply register and have at it!
While you're at it, please check out SmallNetBuilder for product reviews and our famous Router Charts, Ranker and plenty more!