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 --]
prev parent 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).