Wireguard configuration - Understanding IP's and ports

spyking · January 28, 2021, 2:07pm

Sorry for yet another WG configuration post, but I couldn't wrap my head around it after reading multiple other threads. Please do correct me if my terminology is wrong!

My setup is quite basic - my Openwrt box is bridged to my ISPs NT box, so WAN is managed via PPOE.

My LAN subnet is 192.168.1.0/24

# /etc/config/network
config interface 'lan'
        option type 'bridge'
        option ifname 'eth0.1'
        option proto 'static'
        option ipaddr '192.168.1.1'
        option netmask '255.255.255.0'
        option ip6assign '60'

I've setup a new WG interface, and have it configured to reside in the 192.168.9.0/24 subnet, and added a peer which is mean to be my "road-warrior" device. I would like this device to be able to communicate with devices in my LAN, so have added this interface to my LAN zone, and allowed incoming traffic on the defined port.

# /etc/config/firewall
config zone
        option name 'lan'
        option input 'ACCEPT'
        option output 'ACCEPT'
        option forward 'ACCEPT'
        option network 'lan WG_TUN'

config rule
        option name 'Allow-Wireguard-Inbound'
        option target 'ACCEPT'
        option src '*'
        option proto 'udp'
        option dest_port '51820'

As I understood, this peer will be assigned the address 192.168.9.2 and all traffic will be routed through the default gateway (WG_TUN) because of the /32 CIDR

# /etc/config/network
config interface 'WG_TUN'
        option proto 'wireguard'
        option private_key 'xx1'
        option listen_port '51820'
        list addresses '192.168.9.1/24'

config wireguard_WG_TUN
       option public_key 'xx4'
       option description 'R-W'
       option preshared_key 'xx3'
       list allowed_ips '192.168.9.2/32'

To test my setup, I am trying to connect via a temporary hostspot.

[Interface]
PrivateKey = xx4
Address = 192.168.9.2/32

[Peer]
PublicKey = xx1
PresharedKey = xx3
AllowedIPs = 0.0.0.0/0,::/0
Endpoint = my.host.name:51820

But now, I can't seem to connect/handshake with this setup, and am kinda at a dead end on how to debug this.

[TUN] [Tun.Home] Binding v4 socket to interface 32 (blackhole=false)
[TUN] [Tun.Home] Setting device v4 addresses
[TUN] [Tun.Home] Listening for UAPI requests
[TUN] [Tun.Home] Startup complete

My client logs suggest that it's unable to find my "server" to complete the handshake.
Hints on how to proceed?

krazeh · January 28, 2021, 2:20pm

Does your openwrt box have a public IP? Does 'my.host.name' as used in the peer endpoint config resolve correctly?

spyking · January 28, 2021, 2:26pm

Yes, I've set up a ddns and my client can ping said hostname. I also tried connecting from within my LAN to test, by setting the endpoint to 192.168.1.1:51820 but still no dice..

krazeh · January 28, 2021, 2:29pm

Try changing src in the 'Allow-Wireguard-Inbound' rule from '*' to 'wan' (make sure it mirrors the zone name exactly).

Did you get any different output on the client when you tried connecting within your LAN?

trendy · January 28, 2021, 2:34pm

Make sure the keys are correct. They should be ending in =
The public key of the server must be in the peer section on the client config.
The public key of the client must be in the peer section on the OpenWrt config.
Also what is the output of wg show ?

spyking · January 28, 2021, 2:44pm

# wg show
interface: WG_TUN
  public key: <snip>=
  private key: (hidden)
  listening port: 51820

peer: <snip>=
  preshared key: (hidden)
  allowed ips: 192.168.9.2/32

# ifconfig WG_TUN
WG_TUN    Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
          inet addr:192.168.9.1  P-t-P:192.168.9.1  Mask:255.255.255.0
          UP POINTOPOINT RUNNING NOARP  MTU:1420  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

Double checked keys, but if my keys were wrong, wouldn't I see some traffic on the interface first before a rejection? How can I if my device is receiving any packets on 51820?

Nope, also of interest is the interface doesn't seem to show any traffic.

General question - am I going about my interface IP scheme correctly? i.e my WG_TUN in it's own .9.1/24 subnet?

trendy · January 28, 2021, 2:58pm

If you don't have this under a peer, it means there was never a handshake

  latest handshake: 4 seconds ago
  transfer: 11.77 KiB received, 25.87 KiB sent
  persistent keepalive: every 25 seconds

What is the output of iptables-save -c | grep 51820 ?

spyking · January 28, 2021, 3:00pm

Nope, no handshakes.

# iptables-save -c | grep 51820
[0:0] -A zone_wan_input -p udp -m udp --dport 51820 -m comment --comment "!fw3: Allow-Wireguard-Inbound" -j ACCEPT

Not sure how I can look at firewall logs to check if there is some incoming traffic hitting this port.

krazeh · January 28, 2021, 3:01pm

That means there isn't (or at least isn't hitting the rule).

trendy · January 28, 2021, 3:13pm

Verify that you are indeed resolving to the right address.
From the client (if I understand correctly, it is a linux) post the following:
ip -4 addr; ip -4 ro; ip -4 ru; ping -c 3 192.168.9.1

ergamus · January 28, 2021, 3:18pm

You mentioned road warrior, so I'm guessing you'll be securely connection back to your LAN with the internet through the wireguard tunnel. I think you should specify source zone WAN in that rule, since hosts within the lan network can already communicate with the server (the router) regardless.

spyking · January 28, 2021, 3:25pm

Yep, I have now updated my rule to

config rule
        option name 'Allow-Wireguard-Inbound'
        option target 'ACCEPT'
        option src 'wan'
        option proto 'udp'
        option dest_port '51820'

From within my LAN, devices can ping the WG_TUN interface. I'm on a Win box, but FWIW

> 
Wireless LAN adapter Wi-Fi:

   Connection-specific DNS Suffix  . : home
   Link-local IPv6 Address . . . . . : fe80::7ed3:164c:3e7a:4500%32
   IPv4 Address. . . . . . . . . . . : 192.168.1.125
   Subnet Mask . . . . . . . . . . . : 255.255.255.0
   Default Gateway . . . . . . . . . : 192.168.1.1

> ping 192.168.9.1

Pinging 192.168.9.1 with 32 bytes of data:
Reply from 192.168.9.1: bytes=32 time=31ms TTL=64
Reply from 192.168.9.1: bytes=32 time=37ms TTL=64
Reply from 192.168.9.1: bytes=32 time=28ms TTL=64
Reply from 192.168.9.1: bytes=32 time=21ms TTL=64

Ping statistics for 192.168.9.1:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 21ms, Maximum = 37ms, Average = 29ms

Testing from inside LAN

Is this correct?
-- On client, change EndPoint to 192.168.1.1:51820
But still no handshake. I also tried looking at LUCI's real-time traffic graphs, but don't see anything w.t.r this port.

ergamus · January 28, 2021, 3:28pm

What does the ip link output of the wg interface on the client show? Sending packets, status UP?

Wireguard is designed to be secure by being opaque to attackers, which means even if there is a pub/priv key mismatch, it won't do absolutely anything. No return packet, no error, won't even process it.

spyking · January 28, 2021, 3:36pm

I'm on Windows, so not sure how to look up details, but from the adapter details, I can see it's up, sending traffic, but not receiving anything --

EDIT: When checking from Android, had a similar situation, sending packets, but nothing received.

Meanwhile on the opewrt box, the interface is silent with no TX or RX packets..

ergamus · January 28, 2021, 3:39pm

Can you check if the wg port is actually listening on OpenWRT (netstat -ul)? Also ps should reveal at least one wg kernel thread ([wg-crypt-*]).

trendy · January 28, 2021, 3:40pm

I would suggest to start it from scratch.
Use either the automated script or take the step by step server guide.

spyking · January 28, 2021, 3:43pm

# ps | grep wg
 9524 root         0 IW<  [wg-crypt-WG_TUN]

# netstat -l -n -p | grep -e "^udp\s.*\s-$"
udp        0      0 0.0.0.0:51820           0.0.0.0:*                           -
udp        0      0 :::51820                :::*                                -

Yes, guess that is the sane option now

spyking · January 28, 2021, 6:10pm

Started from scratch, read up a bit more - but still no luck.
But, I know enough to start becoming dangerous

Before I continue though - my ISP requires vlan tagging, could that be playing foul here?

My LAN is bound to eth0.1 and wan to eth0.6

# /etc/config/network
config interface 'wan'
        option proto 'pppoe'
        option ipv6 'auto'
        option ifname 'eth0.6'

config interface 'lan'
        option type 'bridge'
        option ifname 'eth0.1'
        option proto 'static'
        option ipaddr '192.168.1.1'
        option netmask '255.255.255.0'
        option ip6assign '60'

config device 'lan_dev'
        option name 'eth0.1'

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

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

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

config switch_vlan
        option device 'switch0'
        option vlan '3'
        option ports '1t 6t'
        option vid '4'

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

config interface 'vpn'
        option proto 'wireguard'
        option private_key <ServerPrivateKey>
        option listen_port '51820'
        list addresses '192.168.9.1/24'

config wireguard_vpn 'wgclient'
        option public_key <ClientPubKey>
        option preshared_key <PreSharedKey>
        list allowed_ips '192.168.9.2/32'

# /etc/config/firewall
config zone 'lan'
        option name 'lan'
        option input 'ACCEPT'
        option output 'ACCEPT'
        option forward 'ACCEPT'
        option network 'lan vpn'

config rule 'wg'
        option name 'Allow-WireGuard'
        option src 'wan'
        option dest_port '51820'
        option proto 'udp'
        option target 'ACCEPT'

"Client" side debugging

To confirm everything is working, I'm testing this form a local Windoze box on that is in the LAN.
Configuration used is

[Interface]
PrivateKey = <ClientPrivateKey>
Address = 192.168.9.2/32

[Peer]
PublicKey = <ServerPubKey>
PresharedKey  = <PreSharedKey>
Endpoint = 192.168.1.1:51820

To check sanity again, I tested if the WG interface is pingable from my client

> ping 192.168.9.1

Pinging 192.168.9.1 with 32 bytes of data:
Reply from 192.168.9.1: bytes=32 time=30ms TTL=64
Reply from 192.168.9.1: bytes=32 time=11ms TTL=64
Reply from 192.168.9.1: bytes=32 time=4ms TTL=64
Reply from 192.168.9.1: bytes=32 time=1ms TTL=64

Ping statistics for 192.168.9.1:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 1ms, Maximum = 30ms, Average = 11ms


> Get-NetIPAddress -InterfaceIndex 32 | Format-Table
ifIndex IPAddress                         PrefixLength PrefixOrigin SuffixOrigin AddressState PolicyStore
------- ---------                         ------------ ------------ ------------ ------------ -----------
32      fe80::7dd3:164c:3e7a:4500%32      64 WellKnown    Link         Preferred    ActiveStore
32      192.168.1.151                     24 Dhcp         Dhcp         Preferred    ActiveStore

# Finally, confirm nothing funky is going on here
> tracert 192.168.9.1

Tracing route to 192.168.9.1 over a maximum of 30 hops

  1    20 ms     1 ms     2 ms  192.168.9.1

Trace complete.

"Server" side debugging

$ wg show
interface: vpn
public key: <ServerPubKey>
private key: (hidden)
listening port: 51820

peer: <ClientPubKey>
  preshared key: (hidden)
  allowed ips: 192.168.9.2/32

$ ps | grep wg
15803 root         0 IW<  [wg-crypt-vpn]

I then tried connecting from the client, to see I could see any traffic on the port

# on the lan interface?
$ tcpdump -n -i eth0.1 'port 5180'
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0.1, link-type EN10MB (Ethernet), capture size 262144 bytes

# on the wan interface?
$ tcpdump -n -i eth0.6 'port 5180'
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0.6, link-type EN10MB (Ethernet), capture size 262144 bytes

# Same story with the vpn interface 
$ tcpdump -n -i vpn
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0.6, link-type EN10MB (Ethernet), capture size 262144 bytes

Is there anyway to check what is up by looking at the wireguard logs on the openwrt box?

vgaetera · January 28, 2021, 6:29pm

tcpdump -vni any udp port 51820

spyking · January 28, 2021, 6:37pm

Ah, nice any trick. Still no dice

root@OpenWrt:~# tcpdump -vni any udp port 51820
tcpdump: listening on any, link-type LINUX_SLL (Linux cooked v1), capture size 262144 bytes

Not sure if this is significant, but I'm on OpenWrt 19.07.6 r11278-8055e38794

$ opkg list-installed | grep wireguard
kmod-wireguard - 4.14.215+1.0.20200611-1
luci-app-wireguard - git-21.022.31068-7129723-1
luci-proto-wireguard - git-21.022.31068-7129723-1
wireguard-tools - 1.0.20191226-1

Windows client is on 0.3.4