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
