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.