connecting to dynamic dns

[Nikos Mavrogiannopoulos]

On Tue, Dec 2, 2014 at 1:58 PM, David Woodhouse <dwmw2 at infradead.org> wrote:
> On Tue, 2014-12-02 at 13:39 +0100, Nikos Mavrogiannopoulos wrote:
>> On Tue, Dec 2, 2014 at 1:04 PM, David Woodhouse <dwmw2 at infradead.org> wrote:
>> > So yeah, this looks like a sane approach.
>> > Is it forbidden to set X-CSTP-DynDNS on a full-tunnel configuration?
>>
>> Not currently, but I should do it. By full tunnel I suppose you mean
>> providing a defaultroute right?
>
> Right. In that case, your local routing setup on the client is still
> going to be sending everything except the *old* server IP down the
> tunnel. Including packets to the new server IP. So that's never going to
> work.

Thinking about it, that looks like a limitation of the client on
routing to the new IP, so dyndns should probably be disabled on the
client if present under such a scenario. However, I see it's quite
complex to determine when a default route is set. I could provide a
patch over the current one which adds that check.

> (This changes if we switch to using SO_BINDTODEVICE like Android does,
> instead of playing with the routing table. But that's complex.)

Interesting. That could also lift the limitation above. However, we
can think about it when there is a use for it.

> You also can't use X-CSTP-DynDNS if the DNS configuration you are
> pushing to the client is asking it to use a DNS server *on* the VPN for
> looking up the hostname of the server. Since you say it's working for
> you, you evidently aren't doing that, which is nice for you. But let's
> make sure it's a forbidden combination too.

That is tricky. I don't think I should ban it from the server, because
the DNS even if set could return an IP that is not in the lan. In any
case, the server doesn't have all the information to make that
decision, so I'll leave that as a configuration issue to be resolved
by the administrators that take advantage of that option.

regards,
Nikos