I frequently travel to China for business.
When I'm there, I need the VPN to work, to access my shared folders in another country.
It's a very important protocol for me.
When using wireguard there, my connection becomes offline in a couple of minutes.
For me, an alternative to Wireguard, like AmneziaWG or Wireguard-Go is very important.
VPN service Planet VPN: https://free-vpn-planet.com/ in the configuration section writes the following: "Configurations for OpenVPN, TunnelBlick, other VPN clients and routers" Dear users, configuration files, as well as data for system settings and router settings are temporarily unavailable for technical reasons. We apologize for the inconvenience. ". At the same time, I can use the L2TP, PPTP protocols of this VPN service to configure the router
As for routers, one of the popular routers Xiaomi Router BE7000 supports only VPN protocols L2TP, PPTP
Do you mean popular or cheap
Popular
Amnezia is harder to detect and if you travel to certain countries (Russia, China, Saudi Arabia, Egypt,...) it is the only way to get a working vpn connection back home. Even hotels, coffee-shops, airlines, etc. block normal VPN conections - sometimes to rip off extra money. Then Amnezia does a good job.
I think you should choose a better VPN provider, if price it's the problem ProtonVPN has a free plan 
Finally tried the new firmware on both of my Flint 2s.
My set up:
Flint 2s (GL-MT6000) upgraded from 4.7.0 rc3 to 4.7.0-op24
Flint 2 GL-MT6000 4.7.0-op24 - (Home location) - Main Router w\ Wireguard server
l l l
l l l---> (Remote Site 1) - Flint [AX1800 - 4.6.8 r1] - Wireguard VPN Client
l l---> (Remote Site 2) - Flint [AX1800 - 4.6.8 r1] - Wireguard VPN Client
l
l- ->Flint 2 GL-MT6000 4.7.0-op24 - (Home location) - WDS extender for Main
Everything went well, but after about 5 minutes WIFI on both Flint 2s fell apart. Traffic would flow to a device for only about 10 seconds and all network activity would fail. Hardwired devices functioned as expected. Remote sites 1 & 2 functioned normally.
With work requirements, I could only debug for a few minutes. I had to roll back to the 4.7.0 RC3 build listed on the stable page. I restored the data backup to these 2 devices from backups made immediately before the upgrade attempt.
Thankfully all is again fully functional.
TLDR:
Upgraded two Flint 2 GL-MT6000s from 4.7.0 rc3 to 4.7.0-op24. WIFI, although devices stayed connected fine, traffic was horribly limited if it worked at all.
Tom
Edit - Fixed missing space in diagram text - 12192024
PPPoE doesn't accept MTU size smaller than 1500
From the log below: Interface eth1 has MTU of 1492 -- should be at least 1500
Sat Dec 21 13:13:03 2024 daemon.notice netifd: Network device 'eth1' link is up
Sat Dec 21 13:13:03 2024 daemon.notice netifd: Interface 'wan' has link connectivity
Sat Dec 21 13:13:03 2024 daemon.notice netifd: Interface 'wan' is setting up now
Sat Dec 21 13:13:03 2024 kern.info kernel: [ 976.804629] mtk_soc_eth 15100000.ethernet eth1: Link is Up - 1Gbps/Full - flow control off
Sat Dec 21 13:13:03 2024 daemon.info pppd[20581]: Plugin pppoe.so loaded.
Sat Dec 21 13:13:03 2024 daemon.info pppd[20581]: PPPoE plugin from pppd 2.5.1
Sat Dec 21 13:13:03 2024 daemon.notice pppd[20581]: pppd 2.5.1 started by root, uid 0
Sat Dec 21 13:13:03 2024 daemon.err pppd[20581]: Interface eth1 has MTU of 1492 -- should be at least 1500.
Sat Dec 21 13:13:03 2024 daemon.err pppd[20581]: This may cause serious connection problems.
Sat Dec 21 13:13:05 2024 daemon.info avahi-daemon[5496]: Joining mDNS multicast group on interface eth1.IPv6 with address fe80::9683:c4ff:fea6:fe5e.
Sat Dec 21 13:13:05 2024 daemon.info avahi-daemon[5496]: New relevant interface eth1.IPv6 for mDNS.
Sat Dec 21 13:13:05 2024 daemon.info avahi-daemon[5496]: Registering new address record for fe81::9683:c4ff:fea6:fe5f on eth1.*.
Sat Dec 21 13:13:38 2024 daemon.warn pppd[20581]: Timeout waiting for PADO packets
Sat Dec 21 13:13:38 2024 daemon.err pppd[20581]: Unable to complete PPPoE Discovery phase 1
Sat Dec 21 13:13:38 2024 daemon.info pppd[20581]: Exit.
Sat Dec 21 13:13:38 2024 daemon.notice netifd: Interface 'wan' is now down
ping www.google.com -f -l 1465
Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set.
ping www.google.com -f -l 1464
Reply from 142.250.180.4: bytes=1464 time=10ms TTL=57
Reply from 142.250.180.4: bytes=1464 time=10ms TTL=57
Reply from 142.250.180.4: bytes=1464 time=10ms TTL=57
Reply from 142.250.180.4: bytes=1464 time=10ms TTL=57
From the ping above, the optimal MTU size is 1464+28 = 1492, which is not accepted by Flint 2
I don't know from where the Admin Panel is reading the memory, but it's different from what is reported by "free"
I'm receiving many errors like these below on Adguard Home.
It's a fresh install (not keeping settings). ADH is 0.107.52
Sat Dec 21 14:50:43 2024 user.notice AdGuardHome[29130]: 2024/12/21 14:50:43.146136 [error] dnsproxy: tls://123abc.d.adguard-dns.com:853: response received over tcp: "reading response from tls://123abc.d.adguard-dns.com:853: read tcp 10.14.0.2:57494->94.140.14.49:853: i/o timeout"
Sat Dec 21 14:51:31 2024 user.notice AdGuardHome[29130]: 2024/12/21 14:51:31.728228 [error] dnsproxy: tls://security.cloudflare-dns.com:853: response received over tcp: "reading response from tls://security.cloudflare-dns.com:853: read tcp 10.14.0.2:36284->1.0.0.2:853: i/o timeout"
Sat Dec 21 14:52:02 2024 user.notice AdGuardHome[29130]: 2024/12/21 14:52:02.767526 [error] dnsproxy: tls://security.cloudflare-dns.com:853: response received over tcp: "reading response from tls://security.cloudflare-dns.com:853: read tcp 10.14.0.2:36270->1.0.0.2:853: i/o timeout"
Sat Dec 21 14:53:47 2024 user.notice AdGuardHome[29130]: 2024/12/21 14:53:47.037026 [error] dnsproxy: quic://123abc.d.adguard-dns.com:853: response received over udp: "opening stream: failed to open a QUIC stream: timeout: no recent network activity"
Sat Dec 21 15:44:33 2024 user.notice AdGuardHome[29130]: 2024/12/21 15:44:33.218835 [error] dnsproxy: https://security.cloudflare-dns.com:443/dns-query: response received over udp: "requesting https://security.cloudflare-dns.com:443/dns-query: Get_0rtt \"https://security.cloudflare-dns.com:443/dns-query?dns=AAABIAABAAAAAAABBWZvbnRzB2dzdGF0aWMDY29tAAABAAEAACkIAAAAgAAAAA\": context deadline exceeded (Client.Timeout exceeded while awaiting headers)"
Servers:
[/pool.ntp.org/]9.9.9.10
[/0.openwrt.pool.ntp.org/]1.1.1.2
[/1.uk.pool.ntp.org/]149.112.112.10
h3://dns.google/dns-query
h3://security.cloudflare-dns.com/dns-query
h3://doh3.dns.nextdns.io/123abc/Flint2
https://dns.quad9.net/dns-query
https://d.adguard-dns.com/dns-query/123abc
https://doh.opendns.com/dns-query
https://security.cloudflare-dns.com/dns-query
tls://security.cloudflare-dns.com
tls://123abc.d.adguard-dns.com
quic://123abc.d.adguard-dns.com
8.8.8.8
9.9.9.9
1.1.1.2
123abc on the log & servers above is my account on ADGuard/NextDNS
Maybe this rule set by default must be investigated as the reason for these errors above.
To useh3 and quic do have a certificate and encrypted setting for agh?
On the instructions from NextDNS or ADH, there is no instructions saying to use a certificate. They just say to add those servers in ADH.
According to the error message, 3 errors are coming from a TLS connection and one from a HTTPS connection.
Tested on MT6000 and MT3000 as well:
Both problems:
1 - Full Cone NAT not working when using PPPoE
2 - 2.4GHz speed on (not so) old devices is garbage. Take a look:
Device: Huawei P30 Pro (Android)
closed source firmware speed test on 2.4GHz:
Great speed, low latency!
open source firmware speed test on 2.4GHz:
I just wanna cry! It's a mess!
It is more similar to Mullvads quantum-wireguard than wireguard.
Wanting better privacy (in the face of three letter capture of encrypted content) is not yet a crime.
Hi @teleney, @PanWise and @Alisa
There are some reports here, but the last comment from GL-iNet on this thread was 2 weeks ago.
Just confirming if this topic is not dead
Device: Flint 2 (GL-MT6000)
I did a test, where the WiFi is scheduled to change the TX power, but I didn't notice any difference on the power signal, so I'm supposing the schedule is not working.
No, you are not supposed to see a scheduled task there.
Where can I confirm if the scheduled task was done?
There is nothing on the log at 11pm and 7am.
Device: GL-MT3000 (Beryl AX)
I'm noticing many "operation not permitted" on logs:
Wed Dec 25 15:02:39 2024 user.notice AdGuardHome[3981]: 2024/12/25 15:02:39.837421 [error] dnsproxy: upstream 192.168.7.1:53 failed to exchange ;111.20.168.192.in-addr.arpa. IN PTR in 724.332µs: exchanging with 192.168.7.1:53 over udp: write udp 192.168.7.3:56163->192.168.7.1:53: write: operation not permitted
Wed Dec 25 15:24:44 2024 user.notice AdGuardHome[3981]: 2024/12/25 15:24:44.176078 [error] dnsproxy: upstream 192.168.7.1:53 failed to exchange ;100.20.168.192.in-addr.arpa. IN PTR in 686.015µs: exchanging with 192.168.7.1:53 over udp: write udp 192.168.7.3:44089->192.168.7.1:53: write: operation not permitted
Wed Dec 25 15:55:13 2024 user.notice AdGuardHome[3981]: 2024/12/25 15:55:13.062945 [error] dnsproxy: upstream 192.168.7.1:53 failed to exchange ;127.20.168.192.in-addr.arpa. IN PTR in 723.487µs: exchanging with 192.168.7.1:53 over udp: write udp 192.168.7.3:42986->192.168.7.1:53: write: operation not permitted
Wed Dec 25 15:57:10 2024 user.notice AdGuardHome[3981]: 2024/12/25 15:57:10.043885 [error] dnsproxy: upstream 192.168.7.1:53 failed to exchange ;109.20.168.192.in-addr.arpa. IN PTR in 735.798µs: exchanging with 192.168.7.1:53 over udp: write udp 192.168.7.3:39590->192.168.7.1:53: write: operation not permitted
Wed Dec 25 15:59:42 2024 user.notice AdGuardHome[3981]: 2024/12/25 15:59:42.648084 [error] dnsproxy: upstream 192.168.7.1:53 failed to exchange ;108.20.168.192.in-addr.arpa. IN PTR in 700.404µs: exchanging with 192.168.7.1:53 over udp: write udp 192.168.7.3:54524->192.168.7.1:53: write: operation not permitted