Defaultroutepiercing

Defaultroutepiercing

[M. Dietrich]

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

in case i want to use a vpn to route all my traffic through
the tunnel i have a kind of hen&egg problem: how does my
client contact the other side if i switch the default route? 

the demo script adds a route to the other side in the
moment of establishing the connection like this:

	163.172.161.0 via 192.168.0.1 dev wlan0

(assuming 192.168.0.1 is my router). this goes well as long as
the router (or the interface) doesnt change. this is fine for
most VPNs as they fail when the connection is lost.

wireguard is ment for the modern world and survives connection
drops. but the route must be reestablished afterwords in case
router or interface changed.

is there a solution to automate that already? i know this is
not really a wireguard topic as it has to be done near dhcp.

this should have been solved for android already or am i
wrong?

M. Dietrich

[-- Attachment #2: Type: application/pgp-signature, Size: 833 bytes --]

Re: Defaultroutepiercing

[Jason A. Donenfeld]

 Take a look at what wg-quick does to solve this:

https://git.zx2c4.com/WireGuard/tree/src/tools/wg-quick.bash#n162

It uses policy routing, which is much nicer than overriding the default rou=
te.

If, however, you do with to do it the old 0/1, 128/1 way, here's a
script to automate that: https://=D7=90.cc/gvFOR5BO/bash But I'd recommend
doing the trick that wg-quick does.

Re: Defaultroutepiercing

[M. Dietrich]

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

Quotation from Jason A. Donenfeld at Januar 18, 2018 14:02:
>  Take a look at what wg-quick does to solve this:
> 
> https://git.zx2c4.com/WireGuard/tree/src/tools/wg-quick.bash#n162
> 
> It uses policy routing, which is much nicer than overriding the default route.
> 
> If, however, you do with to do it the old 0/1, 128/1 way, here's a
> script to automate that: https://א.cc/gvFOR5BO/bash But I'd recommend
> doing the trick that wg-quick does.

thank you for directing me there - i did not recognize that
wg-quick adds functionality.

using it gives some troubles here with DNS. i use a home grown
script for resolveconf (i do not change the file
/etc/resolv.conf but use dbus to tell dnsmasq the current
nameserver). wg-quick issues a

	[#] resolvconf -a tun.wg0 -m 0 -x

which seems to be wrong, the manpage resolvconf(8) states that the
this parameter is

	interface[.protocol]

why is "tun." prepended?

the command is issued before the routing is configured.
shouldnt the DNS configuration be applied after routing
changes?

M. Dietrich

[-- Attachment #2: Type: application/pgp-signature, Size: 833 bytes --]

Re: Defaultroutepiercing

[Jason A. Donenfeld]

On Thu, Jan 18, 2018 at 3:11 PM, M. Dietrich <mdt@emdete.de> wrote:
>         [#] resolvconf -a tun.wg0 -m 0 -x
>
> which seems to be wrong, the manpage resolvconf(8) states that the
> this parameter is
>
>         interface[.protocol]
>
> why is "tun." prepended?

To hack around incompetence on the part of Debian. They order entries
based on the device prefix.

If you have something custom going on, use PostUp/PostDown or
PreUp/PreDown to call your custom script, instead of using DNS=.

> the command is issued before the routing is configured.
> shouldnt the DNS configuration be applied after routing
> changes?

I can reason about it in both directions. What's your intuition lead
you to the _after_ choice?

Re: Defaultroutepiercing

[M. Dietrich]

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

Quotation from Jason A. Donenfeld at Januar 18, 2018 15:20:
> On Thu, Jan 18, 2018 at 3:11 PM, M. Dietrich <mdt@emdete.de> wrote:
>> why is "tun." prepended?
> To hack around incompetence on the part of Debian. They order entries
> based on the device prefix.

that is what i wanted to work around with my script. it just
checks if the given nameserver is current and applies it. i
found my script called even when in a vpn for the outer
network - that nameserver should never applied.

my check is if the interface is the one of the default route.
only in that case the nameserver will be applied.

> If you have something custom going on, use PostUp/PostDown or
> PreUp/PreDown to call your custom script, instead of using DNS=.

ok. probably the most pragmatic thing to do.

>> the command is issued before the routing is configured.
>> shouldnt the DNS configuration be applied after routing
>> changes?
> I can reason about it in both directions. What's your intuition lead
> you to the _after_ choice?

the defaultroutecheck will fail anyway with your suggestion so
it's not that important anyore. i just thought it's the
natural flow as you need a route to use dns (and i still would
prefere to use DNS= instead of PreUp ;) ).

M. Dietrich

[-- Attachment #2: Type: application/pgp-signature, Size: 833 bytes --]