Kaip nustatyti, kad VPN klientas pasiektų nuotolinį VPN serverį?

Dear TEN, Would you please record a screen video to show me how do you set on the router and how to reproduce this issue. Then send it to my email box. samcudy.com
I will check and try to find a solution.

Adding to the urgency of my and others’ reports below, on firmware 2.4.7 I have found the “VPN kill switch” to fail contrary to its name and purpose, leaking local IP after WireGuard drops, which as you know may put users in serious jeopardy.

@Dear TEN,
We will follow it, please wait patiently.
“WireGuard VPN with kill switch does NOT (re)connect automatically indeed (i.e. stays red) on current firmware https://www.cudy.com/cdn/shop/files/WR3000E-R53-2.4.7-20250528-182254-sysupgrade.zip in WISP mode after reboot(s) or when host WiFi comes up (again).
Cf. Evian’s requests currently at the bottom of https://www.cudy.com/de-de/blogs/faq/wie-stelle-ich-den-vpn-client-ein-um-auf-einen-remote-vpn-server-zugreifen?page=5#Comments-589223624948
From the web interface which most clients should not (have to) access, VPN can be made connect (turn green) by manual iterations through toggling it off, saving, waiting, then toggling VPN on again, saving again (steps possibly required repeatedly), or comes on again (then) automatically after running Diagnostics:
This behavior suggests there may be a timing issue of VPN initially failing e.g. because WISP (or generally WAN) isn’t fully up yet for a WireGuard tunnel to establish, then staying disconnected because it may not be retrying (frequently enough, or at all).
If auto-connect can’t be made more reliable, dedicated buttons to (re)connect VPN and show details of its log and status would at least help admins recover.
As a defense against leakage, of course enabling “VPN kill switch” often isn’t optional.”

WireGuard VPN with kill switch does NOT (re)connect automatically indeed (i.e. stays red) on current firmware https://www.cudy.com/cdn/shop/files/WR3000E-R53-2.4.7-20250528-182254-sysupgrade.zip in WISP mode after reboot(s) or when host WiFi comes up (again).
Cf. Evian’s requests currently at the bottom of https://www.cudy.com/de-de/blogs/faq/wie-stelle-ich-den-vpn-client-ein-um-auf-einen-remote-vpn-server-zugreifen?page=5#Comments-589223624948
From the web interface which most clients should not (have to) access, VPN can be made connect (turn green) by manual iterations through toggling it off, saving, waiting, then toggling VPN on again, saving again (steps possibly required repeatedly), or comes on again (then) automatically after running Diagnostics:
This behavior suggests there may be a timing issue of VPN initially failing e.g. because WISP (or generally WAN) isn’t fully up yet for a WireGuard tunnel to establish, then staying disconnected because it may not be retrying (frequently enough, or at all).
If auto-connect can’t be made more reliable, dedicated buttons to (re)connect VPN and show details of its log and status would at least help admins recover.
As a defense against leakage, of course enabling “VPN kill switch” often isn’t optional.

@Dear Khisamov,
Our technical support has contacted you via email. Please check.

“Hello,
We are using Cudy M3000 routers with firmware version 2.4.8 and have encountered the following issues:
No Option for Bulk Subnet Entry:
There is currently no way to add multiple subnets in bulk — each one has to be entered manually. This becomes very inefficient when dealing with a large number of subnets.
Is there any method to simplify this process (e.g. import from file, support for subnet ranges, etc.)? Are there any plans to introduce such functionality in future firmware updates?
Unable to Delete Subnet – Duplicate Error:
When attempting to delete a previously added subnet, we receive an error stating that duplicates exist, even though the subnet was added only once.
This prevents us from removing or modifying the entry. Could you advise on how to resolve this issue, and whether it is expected to be fixed in an upcoming release?
Looking forward to your assistance.”