connecting to dynamic dns

[Nikos Mavrogiannopoulos]

On Sat, 2014-11-29 at 15:03 +0000, David Woodhouse wrote:
> > Well, at that point I don't have VPN. The CSTP reconnection occurs when
> > the TCP connection part of the VPN is closed. That can only occur if the
> > server is down, thus the UDP part is also off. Are there servers which
> > forcefully close the CSTP connection but expect the DTLS connection to
> > remain active?
> 
> Well, I'm not sure about 'forcefully close' but it's certainly possible to
> lose the TCP connection for various reasons (packet loss, NAT brokenness,
> etc.) while DTLS is still running.

I find that such a corner case to even bother to handle. Packet loss
would affect both TCP and UDP, and if NAT brokenness would terminate TCP
sessions, I'd expect to affect primarility UDP too.

> Either way, the point is that surely DNS is unlikely to work right. And
> even if it does you may need to run the vpnc-script to set up routes
> correctly for the new server.

As I mentioned before it works :)

> I wonder if the better solution here is a wrapper which will restart the
> connection from scratch... it can keep the same cookie.
> Let the reconnect (to the old IP address) fail. Run vpnc-script to tear
> down the network config. Then where appropriate, do tje DNS lookup again.
> If there's a new address, try to connect to that using the existing
> cookie. Can that work?

I think the openconnect mainloop is the responsible to handle that, but
anyway that's similar to what openwrt is currently doing (without
reusing the cookies). It means however, a very long downtime when the
peer changes IP, since it has have to wait for the timeout of
openconnect which retries for 5 minutes on the same IP, and in addition
termination of the vpn connections (because openconnect has teared down
the network and routes).

I believe a reasonable approach to be to not strive for zero downtime in
the corner cases you mention above (losing the TCP session due to NAT
brokenness, packet loss etc), and handle that use-case. That is, if a
reconnection is prompted by the server terminating the TCP session, it
would mean re-resolving of dns and reconnection.
Now the issues you mentioned:
1. "The new DNS is routed through the VPN": That is a configuration
issue, nothing openconnect can solve.
2. "The name cannot be resolved at all": Fallback to the old one.
3. About the corner cases: the disruption would be insignificant and
temporary (not something like 5 min downtime as it is now).

What do you think of something like the above?

regards,
Nikos