> There are no "clients inside a WG tunnel", only traffic inside the tunnel :-D

Sure, till the point where you got a VPN inet gateway scenario with a wg 
endpoint node to route other wg peers through to the inet. Most of those 
VPN apps offering these days split DNS such as clients (routed peers) to 
opt for their own DNS resolver or the endpoint node's (gateway) resolver 
or even set a totally different external public upstream resolver (e.g. 
such as to be specified in the WG Android app)

> On a standard linux, this is controlled by /etc/resolv.conf whether or
> not there is VPN.
> /etc/resolv.conf can be (mis-)managed by dhcp clients and other daemons.

Maybe a misunderstanding, it is not about controlling/manipulating a 
peer's resolv.conf or the DNS resolver of a peer but rather using it.

> Not sure what you want to do here... 

A VPN inet gateway (wg endpoint node) to route other wg (remote) peers 
through to the inet.

> Assuming your other end of the WG tunnel is say 192.168.120.1, then
> you should add it as a default gw (and it should route your packets).
> ip route add default via 192.168.120.1
> (no need for `dev wg0` at the end I think)
>
> Kalin.

The gateway on the client side (wg remote peer to be routed to the inet) 
is set to the subnet ip of the server/gateway (wg endpoint node peer 
handling the routing) and that is working fine for the subnet machines 
on the client side having a route to the gateway. However the route to 
the inet is dead ended at endpoint node (gateway).

Default routing on the gateway (endpoint node) is though eth0 via the 
IPS's specified gateway, no issues there. Added the IPS's gateway as 
route to wg on the gateway but no inet for the routed peers. Perhaps a 
ip rule adding a routing table to wg will sort it. The namepsace 
solution somehow did not work out.