how FS is supposed to deal with problems further down the stack

also sprach John S. Denker <[email protected]> [2003.03.08.1727 +0100]:
> I'm promoting this to the design list.

k.

> 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?

maybe we should start discussing what is the ideal situation.

let's look at a standard routing table. imagine with have a host with
two legs, and on each side there's a trust relationship with another
host. one of these exports a subnet:

subnet ---- host A ---- internet ---- router ---- main host ---- host B

subnet:    10.0.0.0/8
host A:    1.2.3.4/32
router:    2.3.4.1/32
main host: 2.3.4.5/32 (eth0) and 192.168.1.1/32 (eth1)
host B:    192.168.1.2/32

here's the routing table of the main host, ipsec0=eth0, ipsec1=eth1:

  destination  mask    gateway     interface
  ------------------------------------------
  1.2.3.4      /32     2.3.4.1     ipsec0
  192.168.1.2  /32     0.0.0.0     ipsec1
  2.3.4.0      /28     0.0.0.0     eth0
  2.3.4.0      /28     0.0.0.0     ipsec0
  192.168.1.0  /24     0.0.0.0     eth1
  192.168.1.0  /24     0.0.0.0     ipsec1
  10.0.0.0     /8      2.3.4.1     ipsec0
  0.0.0.0      /0      2.3.4.1     eth0

note the order of the interfaces for similar routing entries, eth
before ipsec.

okay, let's ifdown eth0, the routing table will the look like:

  destination  mask    gateway     interface
  ------------------------------------------
  1.2.3.4      /32     2.3.4.1     ipsec0
  192.168.1.2  /32     0.0.0.0     ipsec1
  2.3.4.0      /28     0.0.0.0     ipsec0
  192.168.1.0  /24     0.0.0.0     eth1
  192.168.1.0  /24     0.0.0.0     ipsec1
  10.0.0.0     /8      2.3.4.1     ipsec0

note that the eth0 entries are gone, but ipsec0 stayed.

i now ifup the interface again:

  destination  mask    gateway     interface
  ------------------------------------------
  1.2.3.4      /32     2.3.4.1     ipsec0
  192.168.1.2  /32     0.0.0.0     ipsec1
  2.3.4.0      /28     0.0.0.0     ipsec0
  2.3.4.0      /28     0.0.0.0     eth0
  192.168.1.0  /24     0.0.0.0     eth1
  192.168.1.0  /24     0.0.0.0     ipsec1
  10.0.0.0     /8      2.3.4.1     ipsec0
  0.0.0.0      /0      2.3.4.1     ipsec0

and now we have a problem. the routing entries for the 2.3.4/28 net
have switched, and the default route is now dev ipsec0.

in none of these cases was /usr/lib/ipsec/_updown ever called!
it seems to be only called whenever a route is up'd or down'd with
ipsec auto.

i do know what messes up the default route. my dhclient-script just
adds a default route without the dev argument to /sbin/route. changing
that so that dev $interface is appended actually fixes the default
route problem, i can ping the outside world... but all my tunnels are
dead, and apparently irrevivably.

trying to be smart, i do this:

  route del default
  route del -net 2.3.4.0 netmask 255.255.255.240 dev eth0
  route del -net 2.3.4.0 netmask 255.255.255.240 dev ipsec0
  route add -net 2.3.4.0 netmask 255.255.255.240 dev ipsec0
  route add -net 2.3.4.0 netmask 255.255.255.240 dev eth0
  route add default gw 2.3.4.1 dev eth0

now the routing table looks like it did before, and normal connections
work. however, IPsec connections don't anymore.

so i try:

  ipsec auto --up connectionname

to restore the connection with 1.2.3.4, but i get:

  003 ERROR: "connectionname" #804: sendto on eth0 to 1.2.3.4:500 failed in quick_outI1. Errno 22: Invalid argument
  112 "connectionname" #804: STATE_QUICK_I1: initiate
  010 "connectionname" #804: STATE_QUICK_I1: retransmission; will wait 20s for response
  003 ERROR: "connectionname" #804: sendto on eth0 to 1.2.3.4:500 failed in quick_outI1. Errno 22: Invalid argument
  010 "connectionname" #804: STATE_QUICK_I1: retransmission; will wait 40s for response
  003 ERROR: "connectionname" #804: sendto on eth0 to 1.2.3.4:500 failed in quick_outI1. Errno 22: Invalid argument
  031 "connectionname" #14: max number of retransmissions (2) reached STATE_QUICK_I1
  000 "connectionname" #14: starting keying attempt 2 of at most 3, but releasing whack

and it won't work until i restart Pluto. ipsec auto {delete,add,up}
doesn't work either, and neither does {unroute,route,up}, i always get
the same error 22 as above.

so how should it be?

we have two options: ifdown causes all tunnels to be teared down and
ifup causes them to be re-established. this is ugly and expensive.

the other option is: ifdown goes unnoticed, FreeS/WAN does nothing. if
the tunnel stays down for too long, the SAs are going to die. tough
luck. but if the ifup happens within seconds afterwards, the tunnels
should just be able to live on.

now i have been trying to hack this to oblivion but i am still stuck
at one point that i can't figure out: why in the world don't the
tunnels work anymore once i tore down the interface, brought it back
up, and then manually restored the routing table to its original
(working) state? answer that question for me and i'll continue diving
into the depths of this problem.

cheers,

-- 
martin;              (greetings from the heart of the sun.)
  \____ echo mailto: !#^."<*>"|tr "<*> mailto:" net@madduck
 
note: the pgp.net keyservers and their mirrors are broken!
get my key here: http://people.debian.org/~madduck/gpg/330c4a75.asc
 
there's someone in my head but it's not me.
                        -- pink floyd, the dark side of the moon, 1972

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQE+bI87IgvIgzMMSnURAjzZAKC+gLT5D2V1+c/aKIizmjPIiJUTYgCgrpip
gUkB8VfOWxgcUht58EsBsAw=
=rtV2
-----END PGP SIGNATURE-----