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

also sprach John S. Denker <jsd@monmouth.com> [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

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

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

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

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

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

Can we help you?

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

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

_______________________________________________ Users mailing list Users@lists.freeswan.org http://lists.freeswan.org/mailman/listinfo/users

Can't find what you're looking for?

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