WG endpoint node exit to inet and DNS resolver

WG endpoint node exit to inet and DNS resolver

[ѽ҉ᶬḳ℠]

[-- Attachment #1: Type: text/plain, Size: 1033 bytes --]

4.9.0-6-amd64 #1 SMP Debian 4.9.88-1 as WG endpoint node
WG 0.0.20180420-1
DHCP no
Firewall off (both server and client)
wg-quick not utilized

Which DNS resolver is utilized by the clients inside a WG tunnel, the 
client's resolver or the server's? And can this be tweaked in WG?

---

Clients are connecting to the endpoint node and subnets each end are 
reachable through the tunnel. The traffic to the inet from the WG 
however is not escaping via the server's default route. Added the IPS's 
gateway node (81.x.x.x) to the WG iface but that did not provide inet 
connection for the connected clients.

Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use 
Iface
0.0.0.0         81.x.x.x    0.0.0.0         UG    0      0 0 eth0
81.x.x.x    0.0.0.0         255.255.255.255 UH    0      0 0 wg0
192.168.120.0   0.0.0.0         255.255.255.0   U     0 0        0 wg0





[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4174 bytes --]

Re: WG endpoint node exit to inet and DNS resolver

[Christophe-Marie Duquesne]

[-- Attachment #1: Type: text/plain, Size: 1486 bytes --]

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.

[-- Attachment #2: Type: text/html, Size: 2619 bytes --]

Re: WG endpoint node exit to inet and DNS resolver

[Kalin KOZHUHAROV]

On Mon, May 7, 2018 at 1:21 PM, =D1=BD=D2=89=E1=B6=AC=E1=B8=B3=E2=84=A0 <vt=
ol@gmx.net> wrote:
> 4.9.0-6-amd64 #1 SMP Debian 4.9.88-1 as WG endpoint node
> WG 0.0.20180420-1
> DHCP no
> Firewall off (both server and client)
> wg-quick not utilized
>
> Which DNS resolver is utilized by the clients inside a WG tunnel, the
> client's resolver or the server's? And can this be tweaked in WG?
>
There are no "clients inside a WG tunnel", only traffic inside the tunnel :=
-D
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.
For most boxes I use dnscache running on 127.0.0.1 and I do
occasionally configure it to forward queries to another cache (so
/etc/resolv.conf is never touched).


> Clients are connecting to the endpoint node and subnets each end are
> reachable through the tunnel. The traffic to the inet from the WG however=
 is
> not escaping via the server's default route. Added the IPS's gateway node
> (81.x.x.x) to the WG iface but that did not provide inet connection for t=
he
> connected clients.
>
> Kernel IP routing table
> Destination     Gateway         Genmask         Flags Metric Ref    Use
> Iface
> 0.0.0.0         81.x.x.x    0.0.0.0         UG    0      0 0 eth0
> 81.x.x.x    0.0.0.0         255.255.255.255 UH    0      0 0 wg0
> 192.168.120.0   0.0.0.0         255.255.255.0   U     0 0        0 wg0
>
Not sure what you want to do here...
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.

Re: WG endpoint node exit to inet and DNS resolver

[ѽ҉ᶬḳ℠]

[-- Attachment #1: Type: text/plain, Size: 2965 bytes --]


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



[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4174 bytes --]

Re: WG endpoint node exit to inet and DNS resolver

[ѽ҉ᶬḳ℠]

[-- Attachment #1: Type: text/plain, Size: 1884 bytes --]


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




[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4174 bytes --]