WireGuard Server on Flint 2 Not Connecting Externally, Works Locally with 192.168.8.1

Routers VPN, DNS, Leaks
1

Hi GL.iNet community,I'm having trouble connecting my WireGuard client on my mobile device to the WireGuard server running on my GL.iNet Flint 2 (GL-MT6000). The connection works fine when I use the local IP 192.168.8.1:51820 while on the same Wi-Fi network, but it fails when I try to connect externally using my DDNS (xxxxxx.ddns.net:51820 or :51821 after changing the port). The port (51820 or 51821) always shows as closed when tested externally with tools like canyouseeme.org.Here’s the log from my Flint 2 when setting up the wgserver interface:

Fri Aug 15 16:57:30 2025 daemon.notice netifd: Interface 'wgserver' is setting up now
Fri Aug 15 16:57:30 2025 daemon.notice netifd: wgserver (19851): Warning: Section @zone[1] (wan) cannot resolve device of network 'wan6'
Fri Aug 15 16:57:30 2025 daemon.notice netifd: wgserver (19851): Warning: Section @zone[1] (wan) cannot resolve device of network 'wwan'
Fri Aug 15 16:57:30 2025 daemon.notice netifd: wgserver (19851): Warning: Section @zone[1] (wan) cannot resolve device of network 'secondwan'
Fri Aug 15 16:57:30 2025 daemon.notice netifd: wgserver (19851): Warning: Section @zone[2] (guest) cannot resolve device of network 'guest'
Fri Aug 15 16:57:30 2025 daemon.notice netifd: wgserver (19851): Warning: Option 'wgserver'.masq6 is unknown
Fri Aug 15 16:57:30 2025 daemon.notice netifd: wgserver (19851): Warning: Section 'wgserver' has no forward policy specified, using default
Fri Aug 15 16:57:30 2025 daemon.notice netifd: wgserver (19851): Warning: Section 'wgserver' cannot resolve device of network 'wgserver'
Fri Aug 15 16:57:30 2025 daemon.notice netifd: wgserver (19851): Warning: Section 'ovpnserver_drop_leaked_dns' refers to not existing zone 'ovpnserver'
Fri Aug 15 16:57:30 2025 daemon.notice netifd: wgserver (19851): Warning: Section 'wgserver_allow_dns' does not specify a protocol, assuming TCP+UDP
Fri Aug 15 16:57:30 2025 daemon.notice netifd: wgserver (19851): Warning: Section @redirect[0] (GL-) has no target specified, defaulting to DNAT
Fri Aug 15 16:57:30 2025 daemon.notice netifd: wgserver (19851): Warning: Section @redirect[1] (GL-) has no target specified, defaulting to DNAT
Fri Aug 15 16:57:30 2025 daemon.notice netifd: wgserver (19851): Warning: Section @redirect[2] (GL-) has no target specified, defaulting to DNAT
Fri Aug 15 16:57:30 2025 daemon.notice netifd: wgserver (19851): Warning: Section @redirect[3] (GL-) has no target specified, defaulting to DNAT
Fri Aug 15 16:57:30 2025 daemon.notice netifd: wgserver (19851): Warning: Section @redirect[4] (GL-) has no target specified, defaulting to DNAT
Fri Aug 15 16:57:30 2025 daemon.notice netifd: wgserver (19851): Warning: Section @redirect[5] (GL-) has no target specified, defaulting to DNAT
Fri Aug 15 16:57:30 2025 daemon.notice netifd: wgserver (19851): Warning: Section @redirect[6] (GL-) has no target specified, defaulting to DNAT
Fri Aug 15 16:57:30 2025 daemon.notice netifd: wgserver (19851): Warning: Section @redirect[7] (GL-) has no target specified, defaulting to DNAT
Fri Aug 15 16:57:30 2025 daemon.notice netifd: wgserver (19851): Warning: Section @redirect[8] (GL-) has no target specified, defaulting to DNAT

I’ve tried changing the port from 51820 to 51821 in the WireGuard server settings and updated the client accordingly, but the port still appears closed externally. The firewall rule wgserver_allow is set to accept traffic on port 51821 from WAN, and I’ve adjusted the wgserver zone to allow input, but it doesn’t seem to work.I’m using the latest OpenWrt snapshot firmware (21.02 branch), and my setup includes a public IP. I suspect it might be related to the modem/router upstream or an ISP restriction, but I’m not sure. Any advice on how to troubleshoot this or configure the firewall/zones correctly would be greatly appreciated!Thanks in advance!

2

Please check How to troubleshoot WireGuard
Most likely it's an ISP issue.

2 Likes
3

Unfortunately you can't really test wireguard like this.

  1. Most scanners rely on icmp replies, wireguard does not respond, and also does not tcp where tcp is prone to sent a icmp reply.

  2. since the site does not make a handshake and wireguard only reacts on a working handshake, it will appear closed but it still can be open.

Best is to check to the handshake data inside the gl firmware, make the config as simple as possible for the server, if there was a preshared key remove it, and then check if you see a handshake session.

1 Like