Development discussion of WireGuard
 help / color / mirror / Atom feed
From: ѽ҉ᶬḳ℠ <vtol@gmx.net>
To: wireguard <wireguard@lists.zx2c4.com>
Subject: Re: WG endpoint node exit to inet and DNS resolver
Date: Mon, 7 May 2018 19:43:03 +0200	[thread overview]
Message-ID: <82e934fc-39f1-86ba-8fcb-4bf745206cd6@gmx.net> (raw)
In-Reply-To: <CAKXLc7cC7V7z2GTZr4q0rM4Ju8q9e7u50OkNRCbTsoYiaSskhg@mail.gmail.com>

[-- 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 --]

      reply	other threads:[~2018-05-07 17:40 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-05-07 11:21 ѽ҉ᶬḳ℠
     [not found] ` <CAHLp1Yk-33m1X5nkoVA7ofA8=h7uTdXP9x+DWmFzHkxAhq-g_g@mail.gmail.com>
     [not found]   ` <586e6364-d143-2b9b-8ea0-940072a9db9a@gmx.net>
2018-05-07 13:23     ` Christophe-Marie Duquesne
2018-05-07 15:19       ` ѽ҉ᶬḳ℠
2018-05-07 13:26 ` Kalin KOZHUHAROV
2018-05-07 17:43   ` ѽ҉ᶬḳ℠ [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=82e934fc-39f1-86ba-8fcb-4bf745206cd6@gmx.net \
    --to=vtol@gmx.net \
    --cc=wireguard@lists.zx2c4.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).