Unable to communicate via WireGuard tunnel

I'm running OpenWrt 21.02.2 on a Raspberry Pi 4 Model B. I'm trying to connect to a WireGuard instance running on the router from my laptop from the internet.

I have installed and setup WireGuard on the Pi and I have setup a peer for my laptop:

config interface 'VPN'
        option proto 'wireguard'
        option private_key 'xxx'
        list addresses '10.8.0.1'
        option listen_port '51820'

config wireguard_VPN
        option public_key '36kGQ2pyWZhjBclmbCPHiDvrkL1nhIoFA9GoA93AiQM='
        list allowed_ips '10.8.0.100/32'

On the laptop, I have setup a connection to the Pi:

[Interface]
PrivateKey = yyy
Address = 10.8.0.100/32

[Peer]
PublicKey = /0DBGkQ33S1DCK9mz2BG73pA0mLz1oIi0UxY62qQRXA=
AllowedIPs = 10.8.0.0/24
Endpoint = pi.wan.ip:51820

In order for connections from WAN to be able to connect to the WireGuard peer running on the Pi, I created a traffic rule:

config rule
        option target 'ACCEPT'
        option src 'WAN'
        list proto 'udp'
        option dest_port '51820'
        option name 'WireGuard'

On my laptop (not connected to my LAN), I connect to the Pi's public IP address (WAN) and the WireGuard client suggests that a handshake has happened.

WireGuard on the Pi suggests the the laptop peer has connected:

root@Router:~# wg show
interface: VPN
  public key: /0DBGkQ33S1DCK9mz2BG73pA0mLz1oIi0UxY62qQRXA=
  private key: (hidden)
  listening port: 51820

peer: 36kGQ2pyWZhjBclmbCPHiDvrkL1nhIoFA9GoA93AiQM=
  endpoint:laptop.public.ip:63741
  allowed ips: 10.8.0.100/32
  latest handshake: 1 second ago
  transfer: 13.84 KiB received, 596 B sent

I then try to ping the Pi's address on the WireGuard tunnel (10.8.0.1), but it times out. Likewise, if I ping the laptop's IP address on the tunnel from the Pi, it times out, too.

Whilst the laptop was pinging the Pi (via the WG tunnel) I ran tcpdump on the Pi:

root@Router:~# tcpdump -i pppoe-WAN -n udp port 51820
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on pppoe-WAN, link-type LINUX_SLL (Linux cooked v1), capture size 262144 bytes
13:56:20.196054 IP laptop.public.ip.35466 > wan.public.ip.51820: UDP, length 128
13:56:21.197044 IP laptop.public.ip.35466 > wan.public.ip.51820: UDP, length 128
13:56:22.206163 IP laptop.public.ip.35466 > wan.public.ip.51820: UDP, length 128
13:56:23.205949 IP laptop.public.ip.35466 > wan.public.ip.51820: UDP, length 128
13:56:24.217032 IP laptop.public.ip.35466 > wan.public.ip.51820: UDP, length 128
13:56:24.244964 IP wan.public.ip.51820 > laptop.public.ip.35466: UDP, length 32
13:56:25.219094 IP laptop.public.ip.35466 > wan.public.ip.51820: UDP, length 128
13:56:26.219128 IP laptop.public.ip.35466 > wan.public.ip.51820: UDP, length 128
13:56:27.237355 IP laptop.public.ip.35466 > wan.public.ip.51820: UDP, length 128
13:56:28.229029 IP laptop.public.ip.35466 > wan.public.ip.51820: UDP, length 128
13:56:29.229284 IP laptop.public.ip.35466 > wan.public.ip.51820: UDP, length 128

It seems weird that there are just packets from the laptop to the WAN interface for each ping, but there is only one going in the opposite direction.

I also ran tcpdump on the Pi for the WireGuard interface:

root@Router:~# tcpdump -i VPN -n
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on VPN, link-type RAW (Raw IP), capture size 262144 bytes
14:00:59.397340 IP 10.8.0.100 > 10.8.0.1: ICMP echo request, id 62269, seq 372, length 64
14:01:00.399084 IP 10.8.0.100 > 10.8.0.1: ICMP echo request, id 62269, seq 373, length 64
14:01:01.417264 IP 10.8.0.100 > 10.8.0.1: ICMP echo request, id 62269, seq 374, length 64
14:01:02.409126 IP 10.8.0.100 > 10.8.0.1: ICMP echo request, id 62269, seq 375, length 64
14:01:03.419065 IP 10.8.0.100 > 10.8.0.1: ICMP echo request, id 62269, seq 376, length 64
14:01:04.428937 IP 10.8.0.100 > 10.8.0.1: ICMP echo request, id 62269, seq 377, length 64
14:01:05.449141 IP 10.8.0.100 > 10.8.0.1: ICMP echo request, id 62269, seq 378, length 64
14:01:06.449006 IP 10.8.0.100 > 10.8.0.1: ICMP echo request, id 62269, seq 379, length 64
14:01:07.449601 IP 10.8.0.100 > 10.8.0.1: ICMP echo request, id 62269, seq 380, length 64
14:01:08.467419 IP 10.8.0.100 > 10.8.0.1: ICMP echo request, id 62269, seq 381, length 64

Again, it seems weird that there's no replies from 10.8.0.1 (the Pi's WG interface) back to the laptop. Maybe I'm wrong to expect to see the 'pong's from the Pi going back to the laptop in the above.

I've searched extensively on this and I think I've done everything, but I'm clearly missing something.

In case it's of use, here's my WAN config:

config interface 'WAN'
        option proto 'pppoe'
        option username '...'
        option password '..'
        option ipv6 'auto'
        option ip6assign '64'
        option peerdns '0'
        list dns '1.1.1.1'
        list dns '1.0.0.1'
        list dns '2606:4700:4700::1111'
        list dns '2606:4700:4700::1001'
        option device 'eth1'
        list ip6class 'WAN_6'

What are the settings of the vpn zone? uci export firewall
You can also fix a bit the netmasks:

config interface 'VPN'
...
        list addresses '10.8.0.1/24'
[Interface]
...
Address = 10.8.0.100/24
3 Likes

On the Pi you did not set a netmask, so it defaults to /32 and that means the two ends of the tunnel are not in the same subnet. At the Pi, answers to the pings are routed to the wrong place and lost.
Change in the Pi to list addresses 10.8.0.1/24
On your laptop:
tunnel interface IP: 10.8.0.100/24
allowed_ips: at least 10.8.0.1/32, but it needs to cover any and all networks on the other side that you want to reach by VPN, which could be as large as 0.0.0.0/0-- the whole Internet.

2 Likes

On the Pi you did not set a netmask, so it defaults to /32 and that means the two ends of the tunnel are not in the same subnet. At the Pi, answers to the pings are routed to the wrong place and lost.

Ahhhh, I see! That explains it. I thought I understood CIDRs, but clearly I still have some learning to do!

Thanks Both @mk24 @trendy for your rapid replies!

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.