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

1. when the interface goes down, FS un-eroutes all the conns.
2. in the main routing table (as opposed to the eroute table) the routes remain, routing packets into ipsec0
3. when the interface comes back, FS doesn't restore the eroutes.

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

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

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