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 ?
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.
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.
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.
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.