The easy info first: the router is behind an isp router (fritzbox). Without intentional port forwarding the router is not exposed to the internet. The setting is for easy remote access within the home network.
Neither Lan, wifi1 or wifi2 are forwarded to wg0 but to wan instead. Does the wireguard interface intercepts also the whole traffic from the other interfaces as well? My intention was to send the traffic down the tunnel for connected interfaces. By the way: If I connect wifi1 to wg0 thats is working correctly with full internet access incl. DNS.
@vgaetera: I read the page but do not understand how to establish the right route. I tried to activate a route exclusively for wg0 but its not working. Maybe thats because of the interception of the wg interface? A guide for my example would be extremly helpful with additional explanation why the setting has to be that way for learning highly appreceated.
The kernel maintains a routing table which contains instructions for where to send traffic. Essentially, the kernel controls everything.
Other processes can hook into the kernel to modify the routing table. WireGuard is one such process. With your original configuration, WireGuard was telling the kernel "modify the routing table so that everything (0.0.0.0/0) goes via wg0".
From the OpenWRT command line, route -n will show you the routes known to the kernel. That may help you to see the internal logic behind the answer to the question "where do I send this?".
OK, I hope I am makeing progress and learning with VPN and wireguard and openwrt.
Installing vpn-policy-routing and using the command uci set network.@wireguard_wg0[0].route_allowed_ips='0'
is freeing my wan/lan/wifi2.
Luci shows
wan/eth0.2/192.168.0.1 set as default gateway. That's the gateway from my isp route in my home network. So LAN and all devices connected / routed to wan work like charm.
For testing and conveniance a set up 3 wifi zones. the first (wifi1) routed to wg0, a the second (wifi1a) and third (wifi2) to wan.
As wlan1/wifi2 is my open 5G wifi it routes always to wan. wlan0 is / shall be my VPN wifi so is is routed wg0.
If I route it to my second zone it is open like wifi2. That is working. Thanx so far.
But if I try to set up the connection of wlan0/wifi1 to wg0 internet is blocked. VPN-Policy-Routing shows wg0/X.X.X.16 as gateway. That is the IP from my wg client. the wg server has 10.0.0.1. Under a full wireguard set up, I had to add a static route from X.X.X.16 to X.X.X.1 before it was working correctly. Now this is not working anymore. With or wihout static route. I read https://forum.openwrt.org/t/solved-site-to-site-vpn-with-wireguard-and-openwrt/72764/21 but could not understand how to adopt this to my problem.
The wireguard server shows the connection, but no real traffic.
If the issue persists, collect the diagnostics and post it to pastebin.com redacting the private parts:
ubus call system board; uci show network; uci show firewall; uci show dhcp; \
uci show vpn-policy-routing; /etc/init.d/vpn-policy-routing support; wg show; \
ip address show; ip route show table all; ip rule show; iptables-save; \
head -v -n -0 /etc/resolv.* /tmp/resolv.* /tmp/resolv.*/*
Thanx for the suggestion and help. I did it as described but it looks like a step back. wifi2 - the free wifi - doesn't allow any connections anymore and wifi1 - set as wireguard tunnel - connects but doesn't allow any internet traffic.
May I also ask for a favor: I would appreciate any explanation for changes to better understand why the change is necessary and maybe how to identify the error. (and to avoid need for help next time as I (and outher readers) hopefully better understand the problems.)
But the response times and quality of support here is awsome!!
Weird, perhaps it's related to some hardware-specific wireless issues.
Try to disable extra Wi-Fi interfaces/SSIDs, save the changes and restart the router.
Test Wi-Fi interfaces separately, only enabling one at a time.
uci set dhcp.lan.force="1"
uci set dhcp.wifi1.force="1"
uci set dhcp.wifi2.force="1"
uci set dhcp.wifi1a.force="1"
uci commit dhcp
/etc/init.d/dnsmasq restart
Are you connecting to your own VPN server, or a commercial VPN provider?
Bridging is the recommended method to attach a wireless interface to a network.
Masquerading helps to resolve routing issues.
Routing policy should be applied to the source subnet.
After letting rest my device for some hours its working normal now. If no device was connected over some hours it takes some time before internet is available after connection. I will have a look.
It's my private server within my home network. Access over DynDNS provider and forwarded ports on my ISP router.
What else to tell:
After establishing the vpn routing:
PBR showed an error with the wireguard gateway X.X.X.16 (I'm still uncertain, shouldn't it be the X.X.X.1 address
from the wireguard server subnet? After disabling the routing policy, the error disappeared, but nevertheless, internet was not accessible all the time with the wireguard wifi network.
Then we should also check the server side, post to pastebin.com redacting the private parts:
ip address show; ip route show table all; ip rule show; \
sudo wg show; sudo iptables-save; sudo nft list ruleset; \
sysctl net 2> /dev/null | grep -e forward
Make sure to apply these workarounds on the client side:
Add 1: Handshake worked
Add 2: Using my S10 (not parallel to the openwrt device we are talking about) with the wireguard app is working with the same credentials perfectly.
Disable the WG zone masquerading on both client and server.
Add the client side subnet to the peer's allowed IPs on the server.
Temporarily disable MWAN, PBR and GL.iNet-specific firewall scripts on the server.
Disabling masquerading was easy - but no effect, Same for the subnet.
I am a bit reluctant to change firewall script on the server.
As it is working with my mobile phone and laptop without any problem, the
wrong setting must be on the client side of the wireguard settings in my openwrt travel router?
I am still struggling that a pure wireguard setting is working with a static rule from my peer IP X.X.X.16 to the wireguard server IP X.X.X1. With PBR enabled, the wg standard gateway is X.X.X.16 and I can not change this to X.X.X.1.
Currently this looks like a server side problem.
But it's a headache to troubleshoot GL.iNet devices.
There's quite a lot of customization compared to the vanilla OpenWrt.
It's difficult to analyze and predict the possible implications.
Try to isolate the issue by redirecting all traffic from the client to the tunnel.