Re: [Design] [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.

Do you need help?

In addition to our free technical library, Pantek provides professional IT services to companies who utilize Open Source software: Learn more about Pantek's Technical Support offerings Place an order for 24/7/365 Technical Support here Learn more about Pantek, who we are, and what we do Chat with a Live Operator Related lists.freeswan.org Links 1998-fall 1998-spring 1998-summer 1998-winter 1999-winter announce briefs bugs design freeswan-list hipsec ietf-sectest users users-admin Request more information about Pantek

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/

Do you need more help?

In addition to our free technical library, Pantek provides professional IT services to companies who utilize Open Source software: Learn more about Pantek's Technical Support offerings Place an order for 24/7/365 Technical Support here Learn more about Pantek, who we are, and what we do Chat with a Live Operator Related lists.freeswan.org Links 1998-fall 1998-spring 1998-summer 1998-winter 1999-winter announce briefs bugs design freeswan-list hipsec ietf-sectest users users-admin Request more information about Pantek