@Riley_S Thanks for sharing the update! Good to know the issue with WireGuard VPN connectivity has been identified and a beta fix is available. I’ll wait for the official firmware release to ensure full stability and support.

  @Riley_S 

Riley_S wrote

This Article Applies to:

• Archer BE230 V1/V1.2,
• Archer BE3600 V1.26/V1.6

 

Issue Description/Phenomenon:

• When the router turns on the VPN Client function and connects to the Wireguard VPN, the wireless client that is selected to connect to the VPN will not be able to access the Internet.

 

Available Solutions:

       (1) The problem phenomenon has been identified, and the beta link is temporarily provided to solve it: 

 

Firmware Download Link BE230v1 v1.2.1 Build 20250805-rel55794

 

Note: 

• After updating to this version of the beta firmware, it will not be possible to downgrade to the earlier version.
• There will be an official firmware fix for this issue in the future. If you are not comfortable using a beta firmware, please wait for the official fix or contact our support teams for assistance.
• Pre-release and Beta firmware should be used at your own discretion. We cannot guarantee the functionality of features or technical support for Pre-Release or Beta Firmware.

The Beta still does not solve it for me, heck I even cannot connect to router for both WireGuard and OpenVPN. I have downloaded the generated file, scan the QR still no avail.

and worse cannot re-install the stable firmware stuck on the Beta.

I've just been debugging exactly this issue. I set up a WireGuard VPN server on my TP-Link router to access my home network remotely. It worked fine on my phone but my Windows laptop had a frustrating combination of issues.

After debugging I found three separate problems all hitting at once.

Symptoms:

ping 192.168.0.1 (router) → "General Failure" when on VPN

ping 8.8.8.8 → worked fine

nslookup google.com → timed out

Browsing websites → failed completely

The three root causes

1. Missing DNS No DNS = line in the [Interface] section, so all name resolution leaked outside the tunnel.

2. LAN subnet not routed through the tunnel Windows keeps a more specific route for your local subnet (192.168.0.0/24) via your physical Wi-Fi/Ethernet adapter, which overrides the VPN tunnel for that range even when AllowedIPs = 0.0.0.0/0 is set. This is why the router was unreachable over VPN but 8.8.8.8 worked fine.

3. MTU mismatch WireGuard adds ~60 bytes of overhead per packet. The default MTU of 1500 is too large, causing large packets (like HTTPS handshakes) to be silently dropped. Small packets like ping and DNS work fine, but browsing fails. You can confirm this with: ping -f -l 1400 8.8.8.8 — if you see "Packet needs to be fragmented but DF set", MTU is the problem.

The fix — final working config:

[Interface]

PrivateKey = xxxxxx

Address = 10.5.5.3/32

DNS = 192.168.0.1

MTU = 1420 [Peer]

PublicKey = xxxxxx

AllowedIPs = 0.0.0.0/0,

192.168.0.0/24

Endpoint = your.endpoint.ip:51820

PersistentKeepalive = 25

Key changes from a default config: Added DNS = 192.168.0.1 (use your router's actual LAN IP) Added 192.168.0.0/24 to AllowedIPs to force LAN traffic through the tunnel Added MTU = 1420 to account for WireGuard overhead.

Hope this saves someone the debugging time!