temporary wild-side problems cause long-term conn problems

I'm promoting this to the design list.

Perhaps one of the designers could tell us, how
is FreeS/WAN _supposed_ to respond to routing
events "below" the tunnel layer, e.g. eth0 going
down and back up, due to e.g. temporary dhcp
failure or temporary removal of a pcmcia card?

martin f krafft wrote:

 > It just happened again,
 > and I could see from the log that a DHCP failure preceeded this. Since
 > bringing the interface down without stopping FreeS/WAN first yield the
 > same result, I am thinking that this is what happened.
 >
 > However, don't you agree that this is a bug?

Sure, it's a big ugly bug.

Are you running dhcpcd or dhclient?

I just did some playing on a box running dhcpcd and
I observe a _different_ big ugly bug:
  a) when the interface goes down, FS un-eroutes all
     the conns.
  b) in the main routing table (as opposed to the
     eroute table) the routes remain, routing packets
     into ipsec0
  c) when the interface comes back, FS doesn't
     restore the eroutes.

This is 100% reproducible for me.  Hint: dhcpcd -k eth0

It seems to me that (a), (b), and (c) are each
suboptimal separately, and even worse collectively.
-- If we're going to unroute something, unroute ipsec0
(in the main routing table) so that it doesn't ask to
receive packets that it can't possibly handle.
-- If we unroute something, leave enough breadcrumbs
in the forest so that we can restore the routes when
the trouble is over.



> I have a machine that does IPsec with two other static machines, and
> it has a couple of RWs connecting to it. The routing table looks like
> so:
> 
> 111.22.33.444   123.23.34.1     255.255.255.255 UGH 0  0  0 ipsec0
> [...]
> 222.111.44.0    123.23.34.1     255.255.255.0   UG  0  0  0 ipsec0
> [...]
> 123.23.34.0     0.0.0.0         255.255.255.0   U   0  0  0 eth0
> 123.23.34.0     0.0.0.0         255.255.255.0   U   0  0  0 ipsec0
> 0.0.0.0         123.23.34.1     0.0.0.0         UG  0  0  0 eth0
> 
> Every now and then, the machine will somehow replace the default route
> with its ipsec0 equivalent:
> 
> 111.22.33.444   123.23.34.1     255.255.255.255 UGH 0  0  0 ipsec0
> [...]
> 222.111.44.0    123.23.34.1     255.255.255.0   UG  0  0  0 ipsec0
> [...]
> 123.23.34.0     0.0.0.0         255.255.255.0   U   0  0  0 eth0
> 123.23.34.0     0.0.0.0         255.255.255.0   U   0  0  0 ipsec0
> 0.0.0.0         123.23.34.1     0.0.0.0         UG  0  0  0 ipsec0