Hi all, the problem I'm facing is that my Android WireGuard client is sending a handshake initiation to my OpenWrt WireGuard server but the latter does not accept the handshake if I'm connecting from WAN.
I can see that once I turn on the VPN client on my phone (mobile data connected), the RX and TX values of the WireGuard interface in OpenWrt admin panel start changing which means it's making its way from WAN to the router but still it's unable to establish a connection.
An important fact to mention is that I have a lan/guest setup and I'm currently configuring the WireGuard server in the LAN zone. If I connect my mobile device to the guest network, I can VPN into the LAN with the current configuration and it works flawlessly. Which to me seems like the problem is not from the VPN config but has something to do with firewalls / subnet masks that aren't configured properly on my end...
Here's my firewall config:
config defaults
option input 'REJECT'
option output 'ACCEPT'
option forward 'REJECT'
option synflood_protect '1'
config zone 'lan'
option name 'lan'
option input 'ACCEPT'
option output 'ACCEPT'
option forward 'ACCEPT'
list network 'lan'
list network 'wg0'
config zone 'wan'
option name 'wan'
option input 'REJECT'
option output 'ACCEPT'
option forward 'REJECT'
option mtu_fix '1'
list network 'wan'
list network 'wan6'
option masq '1'
config zone
option name 'wan_vpn'
option input 'REJECT'
option output 'ACCEPT'
option forward 'REJECT'
option mtu_fix '1'
list network 'wan_vpn'
option masq '1'
config zone
option name 'guest'
option input 'ACCEPT'
option output 'ACCEPT'
option forward 'ACCEPT'
list network 'guest'
config rule
option name 'Allow-DHCP-Renew'
option src 'wan'
option proto 'udp'
option dest_port '68'
option target 'ACCEPT'
option family 'ipv4'
option enabled '0'
config rule
option name 'Allow-Ping'
option src 'wan'
option proto 'icmp'
option icmp_type 'echo-request'
option family 'ipv4'
option target 'ACCEPT'
config rule
option name 'Allow-IGMP'
option src 'wan'
option proto 'igmp'
option family 'ipv4'
option target 'ACCEPT'
config rule
option name 'Allow-DHCPv6'
option src 'wan'
option proto 'udp'
option dest_port '546'
option family 'ipv6'
option target 'ACCEPT'
config rule
option name 'Allow-MLD'
option src 'wan'
option proto 'icmp'
option src_ip 'fe80::/10'
list icmp_type '130/0'
list icmp_type '131/0'
list icmp_type '132/0'
list icmp_type '143/0'
option family 'ipv6'
option target 'ACCEPT'
config rule
option name 'Allow-ICMPv6-Input'
option src 'wan'
option proto 'icmp'
list icmp_type 'echo-request'
list icmp_type 'echo-reply'
list icmp_type 'destination-unreachable'
list icmp_type 'packet-too-big'
list icmp_type 'time-exceeded'
list icmp_type 'bad-header'
list icmp_type 'unknown-header-type'
list icmp_type 'router-solicitation'
list icmp_type 'neighbour-solicitation'
list icmp_type 'router-advertisement'
list icmp_type 'neighbour-advertisement'
option limit '1000/sec'
option family 'ipv6'
option target 'ACCEPT'
config rule
option name 'Allow-ICMPv6-Forward'
option src 'wan'
option dest '*'
option proto 'icmp'
list icmp_type 'echo-request'
list icmp_type 'echo-reply'
list icmp_type 'destination-unreachable'
list icmp_type 'packet-too-big'
list icmp_type 'time-exceeded'
list icmp_type 'bad-header'
list icmp_type 'unknown-header-type'
option limit '1000/sec'
option family 'ipv6'
option target 'ACCEPT'
config rule
option name 'Allow-IPSec-ESP'
option src 'wan'
option dest 'lan'
option proto 'esp'
option target 'ACCEPT'
config rule
option name 'Allow-ISAKMP'
option src 'wan'
option dest 'lan'
option dest_port '500'
option proto 'udp'
option target 'ACCEPT'
config include 'pbr'
option fw4_compatible '1'
option type 'script'
option path '/usr/share/pbr/pbr.firewall.include'
config forwarding 'lan_wan'
option src 'lan'
option dest 'wan_vpn'
config forwarding
option src 'guest'
option dest 'wan'
config rule
option name 'Allow-Guest-Input-DHCPv4'
list proto 'udp'
option src 'guest'
option src_port '68'
option dest_port '67'
option target 'ACCEPT'
option family 'ipv4'
config rule 'wg'
option name 'Allow-WireGuard'
option src 'wan'
option proto 'udp'
option target 'ACCEPT'
option src_port '51820'
config redirect
option dest 'lan'
option target 'DNAT'
option name 'test'
list proto 'udp'
option src 'wan'
option src_dport '51820'
option dest_ip '192.168.21.1'
option dest_port '51820'
I'd be thankful for any ideas on how to troubleshoot this or please let me know if you need more logs! Thanks!
I deleted the 2nd rule to no avail. My IP address is static. The first 2 octets for both br-guest and br-lan are 192.168. For the WAN interface it's 109.104
Please connect to your OpenWrt device using ssh and copy the output of the following commands and post it here using the "Preformatted text </> " button:
Remember to redact passwords, MAC addresses and any public IP addresses you may have:
ubus call system board
cat /etc/config/network
cat /etc/config/firewall
wg show
And also, please post the (keys redacted) wireguard config of your remote peer device (Android).
Remove the gateway for both the lan and guest networks.
This peer is wrong. The address allowed ips needs to be a /32 - for example 192.168.9.2/32. Make sure it matches on the remote peer config (interface address).
If you’ve setup PBR, make sure it is properly configured. Or disable for now.
Your wg show indicates that there has never been a successful handshake.
Reboot the router after making the changes and try again. If it doesn’t work, post the latest configs again.
I think this could be another potential problem, not for making a connection but for accessing LAN clients, it looks like you are using a VPN killswitch by disabling LAN > WAN traffic and as the WG server is in the LAN zone you might run into problems.
To test I would disable the OpenVPN client and disable PBR
I tested out all the suggested configurations. After disabling OpenVPN I connect to the WireGuard server seamlessly but when I enable it the issue persists. The intended behavior is that I should be able to VPN into my LAN network and able to access a couple of self-hosted services while at the same time all my traffic to the web is routed through OpenVPN. I'll post my most recent configuration in a bit
@stangri & @egc, I'd use the script but I doubt it might conflict with my current pbr setup:
$ cat /etc/config/pbr
config pbr 'config'
option enabled '1'
option verbosity '2'
option strict_enforcement '1'
option resolver_set 'none'
option ipv6_enabled '0'
option boot_timeout '30'
option rule_create_option 'add'
option procd_reload_delay '1'
option webui_show_ignore_target '0'
list webui_supported_protocol 'all'
list webui_supported_protocol 'tcp'
list webui_supported_protocol 'udp'
list webui_supported_protocol 'tcp udp'
list webui_supported_protocol 'icmp'
list ignored_interface 'wg0'
config policy
option name 'lan range to wan_vpn'
option src_addr '192.168.21.1/24'
option interface 'wan_vpn'
config policy
option name 'guest range to wan'
option interface 'wan'
option src_addr '192.168.41.1/24'
config policy
option name 'wg to wan'
option proto 'udp'
option chain 'output'
option interface 'wg0'
option enabled '0'
Are you aware of a way to route back the traffic coming from WAN (my VPN connection to the WireGuard server) back through WAN through the pbr package (which includes LuCY interface as well through luci-app-pbr)? I was digging in the docs and particularly the Local Wireguard Server + Another VPN Client section but the solution provided (list ignored_interface) didn't work for my case where OpenVPN is the client.
Hey, btw thanks all for the valuable responses! Pinning down the cause of the issue is a huge progress!!
It can be done with the full pbr package but have to do other things now so will answer tomorrow.
But in short, add to the openvpn config: pull-filter ignore redirect-gateway
Now everything will go via the wan unless explicitly set to use the vpn.
You can set the source addresses of all clients you want to use the vpn with cidr notation in the pbr.
Alternatively you can add a script to the pbr with the rule ip rule add sport 51820 table pbr_wan
This will only send the wg port to use the wan everything else will still use the vpn