Hello! As title says, there’s a setting in the router that blocks LAN from connecting to same Wireguard VPN server the router is connected to.
I can reach all Internet addresses from LAN except the public ip of the Wireguard server.
Running tcpdump on router shell clearly shows that router returns ICMP device unreachable to LAN host when ICMP ping attempt to Wireguar public ip is done.
I need router and LAN hosts to be able to connect to same Wireguard server. This isn’t a problem for other gl-inet devices where I’ve been testing OpenWRT from scratch.
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.
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
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
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
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?
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.
