Re-adding the ML that I removed from my response by mistake

On Mon, May 7, 2018 at 3:12 PM, ѽ҉ᶬḳ℠ <vtol@gmx.net> wrote:

Thank you for the instant response.

Wireguard does not mess with the DNS (afaik) so whatever is already configured on the client is used.

Had hoped there would a way for the clients to utilize the endpoint node's DNS resolver.

There are many ways to do that. You could setup post-up scripts that modify resolv.conf when the wg interface is up. You could run a caching dns server on your lan that talks to your gateway dns resolver.

If you want to route ipv4 traffic of "clients" through your "server" (using quotes here because wireguard is peer to peer, so it does not really makes sense to say that), you probably need to enable ipv4 forwarding in the kernel, and have postrouting rules that look like "iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE".

forwarding is enabled in the kernel. Currently I am trying to set it up with the name space solution (https://www.wireguard.com/netns/) which perhaps do not require iptable rules, at least there is no mentioning of it.

I have not played with netns, so I cannot comment on that.

Being a of peer-to-peer concept WG is then not really suited as VPN gateway?

It certainly is suited for tunneling all traffic through the tunnel. There are a few blog posts around describing how to do this.