Cannot get WireGuard working without WAN

I followed the Turris guide here: https://doc.turris.cz/doc/en/public/wireguard

This works with a main router.

I tried replicating the set up on a different OpenWrt device set up with only a LAN interface(basically a switch behind a Google WiFi router) and have not had success. The handshake succeeds, but the OpenWrt device seems to not be able to send any data to the peer.

Any ideas?

Did you set up the port forwarding on the google WiFi to direct the traffic to your openwrt router?

Are you sure the handshake is successful? Can you ping from your remote peer to the openwrt drvice? Google WiFi? Internet?

1 Like

Yes. The handshake is definitely successful. Even remotely.

Are you sure? It can appear to be handshaking but not actually working. The way to find out for sure is to issue the following command on your OpenWrt router after WG has been running for 1 minute or longer (so you can see if you get persistent handshakes, just the initial one, or none):

wg show

Please post the output here (for all output, redact private information like the public/private keys, public IPs, etc. -- make it clear what you've redacted to avoid confusion, and please do not redact/change RFC1918 IP addresses).

Also post the contents of the following files:
/etc/config/network
/etc/config/firewall

1 Like

I forgot to ask for some other information:

complete wg configuration from your mobile device (redact details as necessary)

results of ping tests from your mobile device (download a network utility/ping app if you don't have one already):

  • ping your OpenWrt wg interface IP address
  • ping your OpenWrt router LAN IP address
  • ping your main router's LAN IP address
  • ping an internet IP address (8.8.8.8 is a good one)
  • ping an internet domain name (google.com)
1 Like

I think the issue here is that the router is not acting as a router but as a dumb switch. WireGuard is a layer 3 VPN, not layer 2.

wg show is what shows a successful handshake

Relevant configuration is something like this:

config interface 'wg0'
	option proto 'wireguard'
	list addresses '192.168.2.1/24'
	option private_key 'x'
	option listen_port '51820'

config wireguard_wg0
	option public_key 'x'
	option description 'x'
	list allowed_ips '192.168.2.0/24'

config route
	option target '192.168.1.1'
	option netmask '255.255.255.0'
	option interface 'wg0'
	option gateway '192.168.1.1'

config zone
	option name 'WireGuard'
	option network 'WireGuard wg0'
	option input 'ACCEPT'
	option forward 'ACCEPT'
	option masq '1'
	option output 'ACCEPT'

config forwarding
	option dest 'lan'
	option src 'WireGuard'

config forwarding
	option dest 'WireGuard'
	option src 'lan'

I repeat, this thing does not route in any meaningful way. The LAN interface (br-lan in reality) is set to a DHCP client.

You've still left out a lot of the information that I had requested... it's really hard to help without that information.

You might consider changing this from a dumb AP mode device to a standard router (NAT+firewall) in a double NAT configuration and then just allowing forwarding from wg > wan. This works well in my experience.

This is incorrect. If you are trying to pass an entire subnet, you need to address the tunnel devices differently. Otherwise, only specify a single /32 IP from 192.168.2.0/24 for peers.

:+1:

1 Like

WireGuard app on Android shows:

Interface:
Addresses: 192.168.2.2/24
DNS: 192.168.1.1

Peer:
Allowed IPs: 0.0.0.0/0
Endpoint: the WAN IP followed by the port.

edit: As far as pings go to any WAN location, no dice. There's no traffic to any WAN location.

edit2: There is traffic to 192.168.1.148 (The switched Archer) but not to 192.168.1.1(the main router).

Is there a reason that you are providing such sparse details? it would be so much easier to understand what does and does not work if you would post the entire contents of the firewall and network config files, the output of wg show, and details about which ping tests actually work. It could also be useful to understand exactly how things are connected (sounds like LAN-LAN for the main router-OpenWrt connection) and if there is a reason you need it to be in a dumb ap type config.

That said, based on the extremely limited info you've provided, you need to change your android peer to 192.168.2.2/32. This should exactly match the address of the wg peer config as @lleachii suggested for the OpenWrt side.

Hmm? Here's the full output:

config interface 'loopback'
        option ifname 'lo'
        option proto 'static'
        option ipaddr '127.0.0.1'
        option netmask '255.0.0.0'

config globals 'globals'
        option ula_prefix 'fd5d:8d28:bca3::/48'

config interface 'lan'
        option type 'bridge'
        option ifname 'eth1.1'
        option proto 'dhcp'

config switch
        option name 'switch0'
        option reset '1'
        option enable_vlan '1'

config switch_vlan
        option device 'switch0'
        option vlan '1'
        option ports '0t 1 2 3 4 5'
        option vid '1'

config switch_vlan
        option device 'switch0'
        option vlan '2'
        option ports '6t'
        option vid '2'

config interface 'wg0'
        option proto 'wireguard'
        option private_key 'x'
        option listen_port '51820'
        list addresses '192.168.2.1/24'

config wireguard_wg0
        option public_key 'x'
        option description 'x'
        list allowed_ips '192.168.2.0/24'

config route
        option target '192.168.1.1'
        option gateway '192.168.1.1'
        option interface 'wg0'
        option netmask '255.255.255.0'




-------------------------------------

root@OpenWrt:~# cat /etc/config/firewall

config defaults
        option syn_flood '1'
        option input 'ACCEPT'
        option output 'ACCEPT'
        option forward 'REJECT'

config zone
        option name 'lan'
        list network 'lan'
        option input 'ACCEPT'
        option output 'ACCEPT'
        option forward 'ACCEPT'

config zone
        option name 'wan'
        list network 'wan'
        list network 'wan6'
        option input 'REJECT'
        option output 'ACCEPT'
        option forward 'REJECT'
        option masq '1'
        option mtu_fix '1'

config forwarding
        option src 'lan'
        option dest 'wan'

config rule
        option name 'Allow-DHCP-Renew'
        option src 'wan'
        option proto 'udp'
        option dest_port '68'
        option target 'ACCEPT'
        option family 'ipv4'

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 src_ip 'fc00::/6'
        option dest_ip 'fc00::/6'
        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
        option path '/etc/firewall.user'

config zone
        option name 'WireGuard'
        option network 'WireGuard wg0'
        option input 'ACCEPT'
        option forward 'ACCEPT'
        option masq '1'
        option output 'ACCEPT'

config forwarding
        option dest 'lan'
        option src 'WireGuard'

config forwarding
        option dest 'WireGuard'
        option src 'lan'

I wonder if I should get rid of those useless rules. They do nothing AFAIK.

ummmmm...

list allowed_ips '192.168.2.2/32'

Is your peer a VPN?

Nonetheless, you haven't edited it. So why haven't you fixed it yet?

The peer is a phone.

1 Like

OK, then....

What you showed of the phone config looks OK.

That allowed_ips line seems bogus. I tested on my home internet connection. Now I get no signal.

edit: Now I get why. 192.168.2.0/24 is perfectly acceptable. The phone sets it to 192.168.2.2

Network topology:

All my posted configs are for the TP-LINK.

If you can't get this to work with the current topology, start fresh and do the double-nat configuration -- I'm doing that and it works perfectly.

Since this is not working, I think proxy ARP is the only choice left.

The Google Wifi does not support adding static routes.

Unless there is a reason you must run the OpenWrt router in dumb ap mode, I will again point out that configuring the OpenWrt router as a normal NAT+firewall device (i.e. default) behind your primary router (Google Wifi) will work really well. This is, as I mentioned before, what I do.

You will connect a cable between your Google Wifi (LAN) and your OpenWrt (WAN), set a static IP or a static DHCP assignment for the OpenWrt WAN (on the Google Wifi subnet) and configure port forwarding for your WG port. Configure WireGuard on your OpenWrt device, open the port in the firewall, and configure a wg zone in the firewall. Allow forwarding from WG > WAN and you're done. I can guarantee that this method works as long as you configure it properly.

This route has to be wrong:

  • for a network, the target should be 192.168.1.0 (the Network Address), this explains why there is no traffic to 192.168.1.148
  • a target being the router, in a route - makes no sense
  • a route and its network cannot exist on on the same broadcast domain...it can, but then you're routing LAN traffic to the router...so...
  • where does 192.168.1.0/24 exist!?!?
  • you don't need to specify a gateway on a Layer 3 tunnel (except in some protocols where the "onlink" option is specified)

:question:

Just to be sure, are you are issuing normal DHCP to the OpenWrt (i.e. DNS servers and gateway)?