On Tue, 2014-12-02 at 14:05 +0100, Nikos Mavrogiannopoulos wrote: > > 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. Attached both patches. The first patch is identical to the one previously sent, and the second disables dyndns if split_includes is empty, i.e., server asks for default route. regards, Nikos -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Re-resolve-when-reconnecting-CSTP-and-the-X-CSTP-Dyn.patch Type: text/x-patch Size: 4982 bytes Desc: not available URL: <http://lists.infradead.org/pipermail/openconnect-devel/attachments/20141202/c3ab3d53/attachment-0002.bin> -------------- next part -------------- A non-text attachment was scrubbed... Name: 0002-Ignore-a-server-which-identifies-as-DynDNS-but-asks-.patch Type: text/x-patch Size: 873 bytes Desc: not available URL: <http://lists.infradead.org/pipermail/openconnect-devel/attachments/20141202/c3ab3d53/attachment-0003.bin>