Vpn log section show just habitual advises to allow forward in firewall. Others errors are about slow initialization of services, that are working well (wifi driver, doh bootstrap, etc).
I was thinking to leave router-vpn as a basic protection, and handle the load by devices. So the option to turn off Full Cone NAT is not an option, I should prefer to turn off router-vpn, but if I can keep both it's better.
Note: I tried also to connect my Android via wgserver, instead of wifi, and he see the lan but stuck like wifi on wan. Maybe log say anything, but this scenario reduces a lot what to be considered.
Sorry for english, I didn't use translator this time
Edit: just now I was noticed that another Windows in my network was not working. I can see just a different age, in short, 2 devices wifi5 has the issue while 2 devices wifi6 hasn't.
I found an absurde solution: start openvpn, then return to wireguard, without any other change or reboot!
For sure, turn off full cone nat then restart wg, worked more times, even 12 hours later and a scheduled reboot in the middle. But a few minutes ago i was thinking to use wg just in devices, and openvpn in router, then i seen a bad speedtest and back to wireguard.
If anyone know this issue, please help me. As it is gone, it can come back without an apparent reason.
MT3000 firmware 4.8.1, and wgclient is in policy mode.
Yes, full cone nat is the only change I made recently, before that vpn always worked with all other options enabled. I also switched to private NextDNS, entering it as static on dnscrypt, according to their guide, but I don't think it's relevant.
Also, in those 16 hours I tried to remove that one option, full cone nat, I had to restart the wg tunnel but then it worked. Reinstalling the full cone nat and restarting the wg tunnel, the old devices no longer detected the internet. Until I started openvpn for the first time and went back to wg, it probably forced an adjustment.
I have noticed that many things on this router work better when active on reboot, especially vpn, and maybe full cone nat should be activated before the first wgclient activation.
As mentioned, it's working now, so pings would work too, and probably going to and from openvpn fixed the wrong line in some .conf, so it's useless to show you them.
Being on Android, I didn't think about Termux in that half day, and about the other Windows I learned about it when I was already thinking about openvpn. But I'm not asking for you to be able to reproduce it, I think it's one of those things that happens by statistics, among the billions of variables now far away from machine language.
What I can tell you is that Android was showing the network with ! i.e. it was not detecting the internet already while connecting to wifi ... and I think it is no different from your multiwan, it should be based on pings to the ip's, generally if it does not resolve the names it does not show the !
Anyway, for the dns, I set the nextdns doh from your gui, then modified the 4 lines given by nextdns.io to enter as static the private and replace the name in the active list. The vpn has only the first tunnel active in policy mode (no policies yet) in failover with nordvpn, the other settings are default and of course I tried different servers.
If you can't think of anything, I'll use the same method next time ... I once unblocked Netflix the same way, it had crashed from my router, even changing ip, I logged in with nordvpn and it worked from home after that. And they had recommended it to me on Reddit, it's a common method.
Android checks network connectivity by accessing a built-in domain name, which is similar to visiting a website.
Therefore, we cannot be sure if the issue is due to DNS or network connectivity.
As far as I know, the only thing that enables OpenVPN will affect WireGuard is that when enable the OpenVPN, the dnsmasq services (DNS proxy services) will be restarted as well.
Thus, we suspect this is a DNS-related problem.
However, as it is functioning normally now, you can use it as normal.
If similar issues arise in future, please try the above tests again and let us know.
We will be glad to provide further assistance.
Well, it is strange that the dns works for two devices yes and two no, and that a restart does more than a reboot. It's true that android uses the dns, I asked Gemini, but it's a google dot com search address, which you find cached for sure, so many times I had the dns blocked on android, while changing configuration to the router, but google would reach it and do searches as well. And just a dnscrypt-proxy restart would clear the exception by clearing the cache, so it would confirm an IP problem.
Anyway, really, these are things that happen, there's even a joke: three engineers are on a broken-down car, the mechanical one checks the engine, the electronic one checks the ECU, the IT one gets off and on! Even these small devices have an OS written at a mid-level with C, to take advantage of 64-bit sets, then they use packages based on high-level libraries, of course a lot of these things happen, with valid nonsense solutions, the important thing is that a gust of wind sweeps them away and they go back to stable regime.