Some additions to my last msgs here:
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 g…
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=110 SEQ=235051918 ACK=0 WINDOW=8192 RES=0x00 SYN URGP=0 OPT (020405640103030201010402) MARK=0xe3f00
Thu Jun 30 15:52:30 2022 kern.warn kernel: [454385.969623] TRACE: filter:ROUTE_POLICY:rule:1 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=6156 DF PROTO=TCP SPT=50866 DPT=110 SEQ=235051918 ACK=0 WINDOW=8192 RES=0x00 SYN URGP=0 OPT (020405640103030201010402) MARK=0xe3f00
THIS DOES NOT WORK. Packets to wg-servers public adrs can not be routed thru tunnel. Must be outside of wg-tunnel. As I wrote in linked thread, only noticed when VPN-policies used.
Any comments from GLi ? At least, confirmation of bug will be appreciated. I think, I gave sufficient, detailed info. Recreation of bug should be easy.
I think this exit regardless of the vpn policy. When you connect to the wg server, you cannot access the public IP of the server from the wg tunnel.
Can you help to double confirm this relate to vpn policy?
I have no problem, when vpn_policy switched off. When I switch on following policy, I can not access my wg server.
I’m running into the same thing, and also found it is irrespective of VPN policy being enabled.
August 1, 2022, 7:04am
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.
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:
can get the respond, ping ok
August 29, 2022, 6:03am
this appears to be a duplicate of this similar issue:
Router as Wireguard client blocks LAN reachability to same Wireguard server the router is connected to
I’m experiencing this same issue on a GL-B1300 with the most recent v3.212 firmware.
I only notice this when I enable “Block Non-VPN Traffic”
Does anyone have a workaround for this? I need to enable “Block Non-VPN Traffic” and I need to be able to access the WAN address of my WG server.
I simply run “official” openwrt on my router, avoiding the more or less “messy” fiddling around with firewall and “route” settings, required for wg, which I consider the reason for the wg issue(s). I use simple and clean private iptables rules instead.
October 10, 2022, 10:20am
“Block Non-VPN Traffic”
You don’t have to enable this for most of the cases.
I need to not leak any connections, but also, I need any new connections from the router’s clients to my VPN’s server to come through the tunnel and not via the public address of my router.
October 13, 2022, 9:35am
You do not need to enable “Block Non-VPN Traffic”.
You just need to leave vpn enabled and your client should not leak.
The “Block Non-VPN traffic” remove route from lan to wan directly.