Router as Wireguard client blocks LAN reachability to same Wireguard server the router is connected to

arkanoid87 · 2022-06-28T12:47:10.202Z

The server has no “LAN” interface. Please consider that the server is not a gl-inet device.

The LAN client connected to gl-inet device can’t ping server’s wireguard ip nor server’s Internet public ip, and so it’s local wireguard interface fails to initialize handshake. On the other hand, it can reach the rest of Internet. I can assure that the routing table of the LAN host is routing Wireguard subnet ip’s to the gl-inet device as default route (gateway) if the Wireguard interface fails to initialize.

Gl-Inet router, on the other hand, can ping both server’s Wireguard interface ip and Internet public ip from ssh root shell.

What’s the design/idea behind this network configuration? It’s not what a Wireguard interface does by default, nor how the implementation of Wireguard on other consumer-grade router works. Seems like a sort of L3 site-to-site thing but not sure.

Augustus_Meyer · 2022-06-29T15:01:29.823Z

I just wanted to file same/similar bug. I have AR750S, set up as wg-client. Connected to ISPs router, connected to public webserver, also running wg-server. My PC, connected to AR750S via wifi, can reach all domains on web, besides my wg-(web/mail-)server. Which is unfortunate, because I have to disable VPN when trying to retreive the email from my server. However, I can reach my server from the AR750S. This ONLY happens, when I have VPN-policies enabled, i.e. only one domain to be tunneled via VPN. No problem, when VPN-policies disabled.

May be, this helps for diagnostics, when VPN-policies enabled:
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
default * 128.0.0.0 U 0 0 0 wg0
default 192.168.1.1 0.0.0.0 UG 0 0 0 eth0.2
my.private.wg.server 192.168.1.1 255.255.255.255 UGH 0 0 0 eth0.2
128.0.0.0 * 128.0.0.0 U 0 0 0 wg0
192.168.1.0 * 255.255.255.0 U 0 0 0 eth0.2
192.168.8.0 * 255.255.255.0 U 0 0 0 br-lan

Augustus_Meyer · 2022-07-01T08:25:52.460Z

More details anout this bug to be found here:

Wrong iptables for wg, accessing servers IP Technical Support for Routers

Some additions to my last msgs here: Doing more research, I noticed a serious bug regarding the fw: Trying to access my email (POP) server, which is also on the wg-server, I noticed following wrong rules: First rule is already wrong: Thu Jun 30 15:52:27 2022 kern.warn kernel: [454382.914405] TRACE: mangle:FORWARD:rule:5 IN=br-lan OUT=wg0 MAC=xx:xx:xx:xx:xx:xx:xx:xx:37:0a:44:93:08:00 SRC=192.168.8.221 DST=my.wg.server.ip LEN=52 TOS=0x00 PREC=0x00 TTL=127 ID=6125 DF PROTO=TCP SPT=50866 DPT=11…

arkanoid87 · 2022-07-01T09:10:38.188Z

the problem I detect does not depend on VPN-policies.

It seems a routing problem or firewall issue. Router just refuse to route packets from LAN to WAN if destination address is equal to the remote endpoint of the wireguard server the gl-inet is connected to

hilll · 2022-07-13T06:10:50.867Z

hello, Could you please send some screenshots, how to operate the wg?

gongloo · 2022-07-31T15:17:57.995Z

I’m seeing the same issue. Any updates?

hilll · 2022-08-01T07:04:53.861Z

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

Augustus_Meyer · 2022-08-01T07:43:09.524Z

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.

hilll · 2022-08-02T09:08:48.078Z

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

akneen · 2022-08-29T06:01:59.204Z

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.

alzhao · 2022-08-29T11:13:04.711Z

akneen:

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.

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.

akneen · 2022-08-31T02:00:25.584Z

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.

arkanoid87 · 2022-10-10T17:35:16.075Z

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.

alzhao · 2022-10-13T09:34:28.624Z

Wireguar client AXT1800 firmware 4.1
Wireguard server AR750 firmwware 3.203

It just ping fine.

image1457×377 39.4 KB

arkanoid87 · 2023-07-31T11:36:21.961Z

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.

hansome · 2023-08-01T10:07:20.177Z

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.

smart5538 · 2023-09-06T19:09:31.118Z

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

smart5538 · 2023-10-19T12:53:03.978Z

Since 4.4.6 everything is working fine and you don’t have to delete the route, as it is no longer there. Thanks!

arkanoid87 · 2024-01-10T17:57:43.695Z

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

hansome · 2024-01-11T03:22:22.764Z

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”?