hello, Could you please send some screenshots, how to operate the wg?
I’m seeing the same issue. Any updates?
It not need to use VPN policy, when wireguard client connect to wireguard server ok.
the wireguard client package can reach to the wireguard server.
as:
- wg server, IP is 10.0.0.1
- wg client, IP is 10.0.0.2
in the wireguard client route system. ping 10.0.0.1, have respond， is the wireguard server route system not accept the pkg from 10.0.0.2.
so in the wireguard server route system, config the firewall, accept the pkg. if the wireguard server network interface is: wg0
can execute command:
iptables -I INPUT -i wg0 -j ACCEPT
now, the wireguard server network interface “wg0” can accept the pkg.
int the wireguard client, execute:
ping 10.0.0.1
can get the respond, ping ok
Shure. But this does not fix the bug. I.e. assume, your wg-server is anydomain.com . And it also hosts also your email server, for example. Having a windows PC, connected to glinet-router without wg running, you can easily download your mail from anydomain.com. Which does not work any more, when wg activated on glinet-router, because of wrong routing. Unless you apply your workaround, to modify the config of the email client on your PC. Simple solution to fix this bug would be a special route to anydomain.com to be setup on router, when wg is activated.
when start wg client connect, the glinet-router agent all the LAN ip pkg to wg server(anydomain.com).
not special route to anydomain.com.
the sample way to resolve is: in anydomain.com set firewall, all accept pkg from wg network interface to anydomain.com.
if want to operate special in wg client routing, can reference as command:
ip rule del from all fwmark 0x60000/0x60000 lookup 31
iptables -t mangle -D WG_DDNS -s 192.168.8.0/24 -d 192.168.113.122/32 -i br-lan -j MARK --set-xmark 0x60000/0xffffffff
-s 192.168.8.0/24 — is the lan subnet
-d 192.168.113.122/32 — is the anydomain.com static ip
I’m experiencing this same issue.
As soon as I enable my Wireguard Client in my GL-B1300 to connect to my Wireguard server (in EC2), I’m able to ping the Wireguard interface IP on the EC2 server, but I’m no longer able to access the external public IP on that same EC2 server.
Steps to reproduce:
- confirm able to ping external IP of EC2 server.
- setup wireguard client on GL-B1300, and on EC2 server.
- confirm able to ping internal wireguard (wg0) interface IPs over the wireguard tunnel (from either end).
- devices in the LAN of the GL-B1300 are unable to ping the external IP of the server anymore. (get no route to host errors)
it’s worth noting that the GL-B1300 diagnostics (or via SSH → bash shell on the GL-B1300) IS able to still ping the external IP of the EC2 server regardless of if the wireguard tunnel is connected or not.
this breaks my access to all the other (email, https) hosting I’ve got on that same EC2 server.
has anyone gotten any of the suggested fixes working?
Wrong iptables for wg, accessing servers IP appears to be a duplicate of this same issue.
Have you enabled accessing your service via the Wireguard interface?
For example, if you use Apache or Nginx, you have it listening on some interfaces. You need to add WG Interface.
hi alzhao,
thanks for your suggestion.
yes, I’ve already tried binding nginx to “0.0.0.0”, and (individually) each of the IPs on the EC2 server, including the internal wg0 IP on that end of the wireguard tunnel. It is still unavailable.
it’s worth noting that ICMP Echo Requests (sent from the LAN, to the EC2 server external IP) also fail when the wireguard tunnel is connected.
it feels like an incorrect routing issue when the wireguard tunnel is connected.
I’m also able to confirm that a tcpdunp -qni wg0 doesn’t show any packets coming out of the wireguard tunnel when I’m trying to ping the EC2 external interface from a device in the GL-B1300 LAN (but it’s able to access everything else on the internet) while the wireguard tunnel is connected.
I’m quite surprised this issue has not been solved yet. Even more surprising the issue seems not crystal clear to the staff.
It’s a bad routing rule from LAN zone to WAN toward Wireguard server endpoint public Internet ip when Wireguard is active.
It’s quite trivial to replicate, just connect the router to a wireguard server, connect a PC to lan port, try to ping wireguard server public Internet ip from that PC.
still broken here, even after router upgrade and reset
I decided to turn Wireguard Client completely off on router to let LAN host connect as Wireguard clients to same server.
I’ll replace official OS with OpenWRT ASAP.
Please toggle on this wireguard server option:
And on the wireguard client side, remove the route to the wireguard server public IP.
ip route del 1.2.3.4
It needs to be firmware 4.2.3 and above.
This way the traffic will go via VPN tunnel otherwise it will go via WAN interface which is not allowed by default.
We’ll address this issue in the next firmware.
You can also use this cronjob to delete the route automatically (until it is fixed):
* * * * * (if IP=$(route | grep UGH | awk '{print $1}') && [ -n "$IP" ]; then ip route del "$IP"; fi) >/dev/null 2>&1
Since 4.4.6 everything is working fine and you don’t have to delete the route, as it is no longer there. Thanks! 
3 Likes
18 Months have passed since I opened this ticket, and yet it is not solved in the stable branch of GL-X750 Spitz
I’m running
**Version:** 3.217
**Date Compiled:** 2023-05-08 04:37:48 (UTC+02:00)
**SHA256:** ff062ea6f5f528e7825c690c3bcbf4f768606e944ec5e155cd78567b44fdb22b
Snapshot is:
**Version:** 4.3.7
**Date Compiled:** 2024-01-08 21:26:53 (UTC+01:00)
**SHA256:** 46753b69003255c0c3f144b22587b915beafe9365f0fd53d74a6681dbc7f67e8
On the firmware download page for GL-X750 Spitz (GL.iNet download center) this line appears in the changelog of
**Version:** 3.105
**Date Modified:** 2020-12-14 10:54:07 (UTC+01:00)
**SHA256:** 56641430e71795d9e2d80e7736478d4a5d2a121a4a351cdec3888bbb97a5015d
Important bug fix
…
Fixed the problem that the client of the router cannot access the address of the Wireguard server when using Wireguard client
So you are aware of this since at least 2020-12-14, and today 2024-1-10 your stable branch still blocks secure VPN connection of LAN clients to WireGuard server when router is connected as client to same WireGuard server.
Very disappointed
Yes, that bug is already fixed.
What’s your wireguard server, if it’s a gl.inet one, have you enabled “Allow Remote Access LAN”?
remote server is BSD firewall running on VPS with public IP. Wg network is 10.1.0.0/16. It has dozens of connected peers. Each peer has allowed IP /32, firewall does the forwarding within the WG network only (split tunnel).
local gatway is is GL-X750 Spitz running Version: 3.217. It is 10.1.5.50/16 inside the VPN.
local LAN client is Ubuntu desktop. It is 10.1.6.7/16 inside the VPN.
when I turn on wg client on GL-X750 Spitz, firewall can reach 10.1.5.50 but not 10.1.6.7. When I turn off wg client on GL-X750 Spitz, firewall can reach 10.1.6.7 but not 10.1.5.50.
when I turn on wg client on GL-X750 Spitz, local LAN client (ubuntu desktop) can reach any IP on the Internet EXCEPT the public IP (outside the VPN tunnel!) of the remote wg server.
If I flash the very same GL-X750 Spitz with OpenWRT stable and use the very same wg config applied to original firmware, it works as expected and both LAN client and gateway router can connect to same wg server at the same time, as public IP routing toward the wg server is not disrupted by the gateway.
won’t switch from stable to snapshot to fix a routing problem. I need a stable solution. I’m not a tester but a customer.
I already have a working solution based on custom firmware derived from OpenWRT. It does work, it passes my lab tests, but it’s not the official stable solution from GL.iNet staff, and I well now how modem needs tuning to be stable, and it is.
I’m losing confidence that betting on GL.iNet software was the right thing to do
4.3.7 is the stable firmware. Please give me a final chance.