Wireguard server not working

Hello
I am trying to get a wireguard server working on an openwrt AP but I can't figure out what I am doing wrong.
I've got the following configurations:
Server:

TunSafe client config:
[Interface]
PrivateKey = <Client's private key>
DNS = 192.168.0.1
Address = 192.168.0.2/24

[Peer]
PublicKey = <Server's public key>
AllowedIPs = 0.0.0.0/0
Endpoint = :23516
PersistentKeepalive = 25

Network diagram:
New%20Bitmap%20Image

I forwarded the port on the ISP equipment on both sides.
From openwrt I can see that the server is receiving the handshake requests but nothing is sent back.
Does anyone know what is wrong with this setup ?

In your config use 192.168.0.2/32 as your IP. Otherwise, it believe that the network is all at the OpenWrt.

Also, did you enable masquerading of traffic exiting the WG interface/zone?

I'm not familiar with the TunSafe client, but I don't see any problems with that.

Configuring 192.168.0.2/24 on the wireguard interface doesn't affect the AllowedIPs settings. But it should add the route 192.168.0.0/32 instead of 192.168.0.0/24 on the interface. It might not make any difference since a default route is added on the interface anyway. But if there is another less specific route that includes the 192.168.0.0/24 subnet then adding a more specific route will make a difference.

Anyway, I would tripple check the keys and the firewalls.

So I enabled masquerading on the firewall zone and got the client to connect to the server but no traffic goes through the tunnel.
Server:

Client:

You should run a package capture software (wireshark/tcpdump) on the wireguard interface(s) capturing any packets and on the LAN interfaces capturing the wireguard packets on UDP port 23516. It should show at which point the packets are blocked or disappears for other reasons.

BTW I wouldn't enable masquerade on the wireguard interface unless it's at the edge between my network and a network I don't control such as a anonymizing VPN service (or the Internet). And the masquerade doesn't seem to solve the problem anyway.

If they're helpful, my own configs are here and include a working WG server config.

If you compare yours to mine, you might spot something that points you in the right direction.

EDIT: corresponding client config is:

[Interface]
PrivateKey = <Client's private key>
Address = 192.168.99.3/32

[Peer]
PublicKey = <Server's public key>
AllowedIPs = 0.0.0.0/0,::/0
Endpoint = <redacted>:52000

You set "IP Adresses" of the Wireguard interface to the whole range of your local network (/24 range), I believe even both of your local networks. This is not what you are supposed to do there. You are supposed to give the Wireguard interface its own IP*. This would be an address outside of your local network and it is usually never used directly, it servers as a routing destination. Wireguard tunnel form their own "local network" amongst their peers, so the wireguard interface's IP should be in the same range but vary between all peers -- something like 192.168.16.1 on the "server" and 192.168.16.2 for another peer, etc.

The network ranges accessible to the Wireguard interface are defined in the "peers" section, i.e., the ranges that can be routed to the peer, and the peer is allowed to access. You can narrow these ranges down to single IPs, your local network range, or you can open it up completely (as you did with "0.0.0.0", and this implies that the peer knows what he will route.)

*) Although it is distinctly possible, and even the prime example in their Quick Start document, the Wireguard documentation is a bit fuzzy on when and why to use IP ranges for Wireguard's own address. I never bothered, but it would be interesting to know what the purpose would be.

2 Likes

I had recently some problems with atom cpus, they will take something like 500+ seconds to establish a connection because of crng not being ready, meaning not so much entropy available

1 Like

I agree, it's fuzzy; but I leaned about the Cryptokey Routing regarding the subnets reading this section...and trial and error of mis-numbering a peers vs the router that can access all devices. :smile:

So if you address a router with /24, you have to use routes less than that to adress each peer (hence using /32 works).

2 Likes

Though using /24 on the wireguard interface doesn't affect the crypto routing which is set up with allowedips. By having /24 on the interface you only affect normal routing since it adds a route to the /24.

1 Like