Re: [Users] temporary wild-side problems cause long-term conn problems

Stephen J. Bevan wrote:

 > to try and alleviate some of the DHCP related problems: install a
 > dhcpcd.exe script that stops/starts FreeS/WAN as appropriate i.e. stop
 > it on a "down", restart it on a "new" and start it on an "up" if it
 > isn't running.  This is a heavy-handed approach but it does at least
 > keep the routing and eroutes consistent and ensure that connections
 > are re-negotiated on an address change.

Yes, that is heavy-handed.

It is particularly distasteful on a system with
multiple interfaces (eth0, eth1, ...).  If there
is a DHCP failure or other low-level problem with
eth0, that shouldn't force me to restart _all_ the
connections including the ones using eth1.

Let's look at the documentation e.g. 
http://www.freeswan.org/freeswan_trees/freeswan-1.99/doc/intro.html

It says:
>>> Road Wariors who get their addresses via DHCP may have a problem.
>>>  FreeS/WAN can quite happily build and use a tunnel to such an 
>>> address, but when the DHCP lease expires, FreeS/WAN does not know
>>>  that. The tunnel fails, and the only recovery method is to tear
>>> it down and re-build it.

There is AFAICT no other documentation dealing with
these issues.

1) My observations indicate that in the quoted doc
passage, the last part of the second sentence is
wrong.  It appears that FreeS/WAN _does_ notice;
it reacts (IMHO over-reacts) by wiping out the
eroutes.  And Martin Krafft observes additional
damage to the main routing table (although it's
not yet obvious whether this is being caused by
FreeS/WAN or the DHCP client daemon, or perhaps
something else).

2) IMHO the documented behavior (not noticing) would
be suboptimal but preferable to the current behavior,
at least in the case of a temporary failure, because
it would produce automatic, immediate recovery from
a temporary failure.

Note that following a temporary wild-side problem,
FreeS/WAN does not restore the eroutes when the
IPsec SA is re-keyed nor even when the ISAKMP SA
is re-keyed.  So the third sentence of the doc
passage quoted above is not kidding:  you are
indeed required to completely tear down the conn
and re-build it.  This is suboptimal;  see
item (4) below.

3) IMHO it is not optimal to put the solution in
dhcpcd-eth0.exe, because we are dealing with a wide
class of wild-side problems that includes but is
not limited to DHCP issues.  Consider for example
the case of inserting a PCMCIA card that uses a
fixed (non-DHCP) address.

Additional complexities arise because some people run
dhclient (from ISC), some run dhcpcd, and some run
pump (from redhat).

Note that dhcpcd does not even call dhcpcd-eth0.exe
at the time the problem begins (expiration), but
only at the time the problem ends (new grant).
That means that your ability to do good things
(e.g. routing traffic through a secondary interface)
is severely compromised.

This would seem to be a reason for preferring the
ultra-flexible dhclient over dhcpcd, which is in
turn preferable over pump.

We also need to distinguish
  -- DHCP address _rotation_, i.e. getting a new
     and different wild-side addr via DHCP
  -- Simple DHCP expiration, in which case we can
     at least hope that we will get a renewal of
     the old address (no rotation) at a later time.
     This can happen due to transient network
     failure or transient DHCP server failure.

4) IMHO it would be nice for FreeS/WAN to provide
something more than a three-sentence mention of the
problem in the introductory documentation.  How about:
  -- Treating temporary problems as non-events, not
     requiring rekeying or anything else.  Rekeying is
     expensive and should be avoided whenever possible.
  -- For events that do require rekeying, making _all_
     the right things (including route and eroute
     restoration) happen at the time SA rekeying comes
     due (if not sooner) if the interface is usable at
     that time [as opposed to requiring somebody to
     issue whack commands to tear down and re-build
     the conn].
  -- Providing actual code to deal with events that do
     not involve SA lifetimes, e.g. card insertion or
     first-time DHCP grant, and to avoid waiting for an
     SA lifetime in any case.  Preferably code that
     does not disturb connections on eth1 when dealing
     with a problem on eth0.  This will require nontivial
     code in ipsec auto:
	ipsec auto --revive-all-conns-on-ifc eth0
     plus some hooks in various places  to invoke it.
  -- Explaining, in the step-by-step instructions, e.g. 
http://www.freeswan.org/freeswan_trees/freeswan-1.99/doc/quickstart-configs.html#qc.rw.client
     how and where to install the necessary hooks.
  -- Unless/until these events can be handled, mentioning
     the situation in the BUGS file.

See also the discussion of "routing below the tunnel layer"
in the klips-ng design documents.  The version dated November
2001 can be found at:
   http://www.sandelman.ottawa.on.ca/SSW/freeswan/klips2req/