Forget about WireGuard until the connectivity is fixed.
# Client
ping openwrt_ip
nmap -sU -p 51820 openwrt_ip
# OpenWrt
tcpdump -vni any icmp
tcpdump -vni any udp port 51820
1 Like
From Windoze
> ping 192.168.1.1
Pinging 192.168.1.1 with 32 bytes of data:
Reply from 192.168.1.1: bytes=32 time=52ms TTL=64
Reply from 192.168.1.1: bytes=32 time=1ms TTL=64
Reply from 192.168.1.1: bytes=32 time=49ms TTL=64
Reply from 192.168.1.1: bytes=32 time=53ms TTL=64
Ping statistics for 192.168.1.1:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 1ms, Maximum = 53ms, Average = 38ms
> nmap -sU -p 51820 192.168.1.1
Starting Nmap 7.80 ( https://nmap.org ) at 2021-01-28 20:02 W. Europe Standard Time
Nmap scan report for OpenWrt.home (192.168.1.1)
Host is up (0.034s latency).
PORT STATE SERVICE
51820/udp open|filtered unknown
MAC Address: <> (Xiaomi Electronics,co.)
Nmap done: 1 IP address (1 host up) scanned in 1.73 seconds
On openwrt
tcpdump -vni any udp port 51820
tcpdump: listening on any, link-type LINUX_SLL (Linux cooked v1), capture size 262144 bytes
20:02:18.837924 IP (tos 0x0, ttl 42, id 56092, offset 0, flags [none], proto UDP (17), length 28)
192.168.1.151.56330 > 192.168.1.1.51820: UDP, length 0
20:02:18.837924 IP (tos 0x0, ttl 42, id 56092, offset 0, flags [none], proto UDP (17), length 28)
192.168.1.151.56330 > 192.168.1.1.51820: UDP, length 0
20:02:19.038399 IP (tos 0x0, ttl 59, id 17401, offset 0, flags [none], proto UDP (17), length 28)
192.168.1.151.56331 > 192.168.1.1.51820: UDP, length 0
20:02:19.038399 IP (tos 0x0, ttl 59, id 17401, offset 0, flags [none], proto UDP (17), length 28)
192.168.1.151.56331 > 192.168.1.1.51820: UDP, length 0
Do I understand correctly, that it sees the outgoing packets from my client?
1 Like
Good, keep tcpdump running and try to connect the WireGuard client using the endpoint IP 192.168.1.1 and port 51820.
If you see no tcpdump output, then there's a problem with the WireGuard client software or config.
1 Like
Thanks everyone for all the detailed debugging steps.
I added a new peer, configured my Android client -- saw a flurry of activity the yielded a handshake!
Still no dice on my Windoze, but will debug that later. Strange though as my other tunnels work fine on windoze.
Final wrapping up questions.
1 -- Are my firewall rules ok?
config defaults
option input 'ACCEPT'
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'
option network 'lan vpn'
config zone 'wan'
option name 'wan'
option input 'REJECT'
option output 'ACCEPT'
option forward 'REJECT'
option masq '1'
option mtu_fix '1'
option network 'wan wan6'
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 'wg'
option input 'ACCEPT'
option forward 'ACCEPT'
option output 'ACCEPT'
option masq '1'
config rule 'wg'
option name 'Allow-WireGuard'
option src 'wan'
option dest_port '51820'
option proto 'udp'
option target 'ACCEPT'
config forwarding
option dest 'wan'
option src 'lan'
I would ideally like to move the vpn interface into wg zone and then add some logging down the line.
I feel really silly. I had to add AllowedIPs = 0.0.0.0/0 to my Windoze client config, and I now have a handshake.
There is no need to masquerade the wg zone. Other than that the config is fine. If you move the vpn interface to wg zone, you'll need to add forwardings to lan and wan zones.
2 Likes
This topic was automatically closed 0 minutes after the last reply. New replies are no longer allowed.