* WG endpoint node exit to inet and DNS resolver
@ 2018-05-07 11:21 ѽ҉ᶬḳ℠
[not found] ` <CAHLp1Yk-33m1X5nkoVA7ofA8=h7uTdXP9x+DWmFzHkxAhq-g_g@mail.gmail.com>
2018-05-07 13:26 ` Kalin KOZHUHAROV
0 siblings, 2 replies; 5+ messages in thread
From: ѽ҉ᶬḳ℠ @ 2018-05-07 11:21 UTC (permalink / raw)
To: wireguard
[-- 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 --]
^ permalink raw reply [flat|nested] 5+ messages in thread
[parent not found: <CAHLp1Yk-33m1X5nkoVA7ofA8=h7uTdXP9x+DWmFzHkxAhq-g_g@mail.gmail.com>]
* Re: WG endpoint node exit to inet and DNS resolver
2018-05-07 11:21 WG endpoint node exit to inet and DNS resolver ѽ҉ᶬḳ℠
[not found] ` <CAHLp1Yk-33m1X5nkoVA7ofA8=h7uTdXP9x+DWmFzHkxAhq-g_g@mail.gmail.com>
@ 2018-05-07 13:26 ` Kalin KOZHUHAROV
2018-05-07 17:43 ` ѽ҉ᶬḳ℠
1 sibling, 1 reply; 5+ messages in thread
From: Kalin KOZHUHAROV @ 2018-05-07 13:26 UTC (permalink / raw)
To: vtol; +Cc: wireguard
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.
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: WG endpoint node exit to inet and DNS resolver
2018-05-07 13:26 ` Kalin KOZHUHAROV
@ 2018-05-07 17:43 ` ѽ҉ᶬḳ℠
0 siblings, 0 replies; 5+ messages in thread
From: ѽ҉ᶬḳ℠ @ 2018-05-07 17:43 UTC (permalink / raw)
To: wireguard
[-- 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 --]
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2018-05-07 17:40 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-05-07 11:21 WG endpoint node exit to inet and DNS resolver ѽ҉ᶬḳ℠
[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 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).