Re-adding the ML that I removed from my response by mistake On Mon, May 7, 2018 at 3:12 PM, ѽ҉ᶬḳ℠ <[email protected]> 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.
_______________________________________________ WireGuard mailing list [email protected] https://lists.zx2c4.com/mailman/listinfo/wireguard
