WG endpoint node exit to inet and DNS resolver

[ѽ҉ᶬḳ℠]

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

I am utilizing unbound as DNS resolver on the endpoint node and thus in 
the resolv.conf the nameserver reads 127.0.0.1. The lan peers are not 
local on the endpoint node but connecting remotely over inet. Thus was 
my question whether WG has a mechanism to tell the lan peers to use 
their own DNS resolver or the DNS resolver of the endpoint node. 
Understanding now each WG uses its own resolver setup. Perhaps got 
confused with the WG's Android app requiring the input for setting a DNS 
resolver.

>
>     forwarding is enabled in the kernel. Currently I am trying to set
>     it up  with the name space solution
>     (https://www.wireguard.com/netns/
>     <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.

The name space solution did not work out. eth0 (and its public ip)  
vanished into the namespace (physical), suppose that is intended (by the 
way of the tutorial). Subsequent inet connection is gone (till netds del 
physical) and thus the endpoint is not accessible anymore remotely over 
the inet. Maybe I am missing something, that is way I set it up:

# The loopback network interface
auto lo wg0 eth0
iface lo inet loopback

# The primary network interface
allow-hotplug eth0
iface eth0 inet static
     address <endpoint node public ip>
     netmask 255.255.255.255
     broadcast <endpoint node public ip>
     network <endpoint node public ip>
     gateway <ISP gateway ip>
     # dns-* options are implemented by the resolvconf package, if installed

iface wg0 inet static
     address 192.168.120.1
     pre-up ip netns add physical
     pre-up ip link set eth0 netns physical
     pre-up ip -n physical addr add 192.168.12.52/24 dev eth0
     pre-up ip -n physical link add wg0 type wireguard
     pre-up ip -n physical link set wg0 netns 1
     pre-up wg setconf wg0 /etc/wireguard/wg0.conf
     up ip link set wg0 up
     post-up ip route add <ISP gateway ip> dev wg0
     post-up ip route add default via <ISP gateway ip>  dev wg0
     post-up sysctl -w net.ipv4.ip_forward=1

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

Worked my way through a lot of those and haven't got it working, that 
being the cause of initiating the submission to the mailing list.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4174 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.zx2c4.com/pipermail/wireguard/attachments/20180507/e5de4999/attachment.p7s>