[Openswan Users] tunnel stops working when after EVENT_SA_REPLACE

[Craig Constantine]

Sorry this is long, just trying to explain clearly what I've tried.

My side is Linux Openswan U2.6.22/K2.6.31-19-server (netkey), and 'ipsec 
verify' shows all "OK" (except I have Opp. Enc disabled.)

The tunnel config (this is the only tunnel) is...

conn ext_tunnel
         type=tunnel
         authby=secret
         left=209.255.196.98
         leftsubnet=209.92.146.96/27
         leftnexthop=209.255.196.97
         right=199.234.240.5
         rightsubnet=172.16.36.0/24
         keyexchange=ike
         ike=aes256-sha1-modp1024
         phase2alg=aes256-sha1
         pfs=yes
         auto=start

After an initial 'ipsec auto --up ext_tunnel' things work fine. But 
after a while (something like an hour, but I'm not exactly sure when) I 
can no longer cross the tunnel (eg, an open ssh session becomes non 
responsive, cannot open a new ssh session) When I do 'ipsec auto --up 
ext_tunnel' things come back to life (eg, that open ssh session becomes 
responsive showing everything I typed while it was dead, and new ssh 
sessions can be opened.)

So I thought the problem might be the that other end (CheckPoint NG/AI 
R55) might be initiating the rekey before me. So I added...

         # try to ensure we remain the initiator
         rekeyfuzz=0%
         ikelifetime=3300s
         salifetime=12h

And I see now see regular rekeying...

Mar  1 12:48:35 binkley pluto[18299]: "ext_tunnel" #200: initiating 
Quick Mode PSK+ENCRYPT+TUNNEL+UP+IKEv2ALLOW to replace #183 {using 
isakmp#199 msgid:db103e1b proposal=AES(12)_256-SHA1(2)_160 pfsgroup=no-pfs}
Mar  1 12:48:35 binkley pluto[18299]: "ext_tunnel" #200: ignoring 
informational payload, type IPSEC_RESPONDER_LIFETIME msgid=db103e1b
Mar  1 12:48:35 binkley pluto[18299]: "ext_tunnel" #200: transition from 
state STATE_QUICK_I1 to state STATE_QUICK_I2
Mar  1 12:48:35 binkley pluto[18299]: "ext_tunnel" #200: STATE_QUICK_I2: 
sent QI2, IPsec SA established tunnel mode {ESP=>0xfeb6750d <0xdc656b37 
xfrm=AES_256-HMAC_SHA1 NATOA=none NATD=none DPD=none}
Mar  1 13:20:30 binkley pluto[18299]: "ext_tunnel" #201: initiating Main 
Mode to replace #199
Mar  1 13:20:30 binkley pluto[18299]: "ext_tunnel" #201: transition from 
state STATE_MAIN_I1 to state STATE_MAIN_I2
Mar  1 13:20:30 binkley pluto[18299]: "ext_tunnel" #201: STATE_MAIN_I2: 
sent MI2, expecting MR2
Mar  1 13:20:31 binkley pluto[18299]: "ext_tunnel" #201: transition from 
state STATE_MAIN_I2 to state STATE_MAIN_I3
Mar  1 13:20:31 binkley pluto[18299]: "ext_tunnel" #201: STATE_MAIN_I3: 
sent MI3, expecting MR3
Mar  1 13:20:31 binkley pluto[18299]: "ext_tunnel" #201: Main mode peer 
ID is ID_IPV4_ADDR: '199.234.240.5'
Mar  1 13:20:31 binkley pluto[18299]: "ext_tunnel" #201: transition from 
state STATE_MAIN_I3 to state STATE_MAIN_I4
Mar  1 13:20:31 binkley pluto[18299]: "ext_tunnel" #201: STATE_MAIN_I4: 
ISAKMP SA established {auth=OAKLEY_PRESHARED_KEY cipher=aes_256 
prf=oakley_sha group=modp1024}
Mar  1 13:20:31 binkley pluto[18299]: "ext_tunnel" #201: discarding 
duplicate packet; already STATE_MAIN_I4
Mar  1 13:20:31 binkley pluto[18299]: "ext_tunnel" #201: discarding 
duplicate packet; already STATE_MAIN_I4

But the tunnel still goes dead after the first rekeying. When it is 
dead, I have discovered that my 'ipsec auto --status' shows me what I 
think is a problem:

[excerpt]
000 "ext_tunnel": 
209.92.146.96/27===209.255.196.98<209.255.196.98>[+S=C]---209.255.196.97...199.234.240.5<199.234.240.5>[+S=C]===172.16.36.0/24; 
erouted; eroute owner: #200
000 "ext_tunnel":     myip=unset; hisip=unset;
000 "ext_tunnel":   ike_life: 3300s; ipsec_life: 43200s; rekey_margin: 
540s; rekey_fuzz: 0%; keyingtries: 0
000 "ext_tunnel":   policy: PSK+ENCRYPT+TUNNEL+UP+IKEv2ALLOW+lKOD+rKOD; 
prio: 27,24; interface: eth1;
000 "ext_tunnel":   newest ISAKMP SA: #203; newest IPsec SA: #200;
000 "ext_tunnel":   IKE algorithms wanted: 
AES_CBC(7)_256-SHA1(2)-MODP1024(2); flags=-strict
000 "ext_tunnel":   IKE algorithms found:  AES_CBC(7)_256-SHA1(2)_160-2,
000 "ext_tunnel":   IKE algorithm newest: AES_CBC_256-SHA1-MODP1024
000 "ext_tunnel":   ESP algorithms wanted: AES(12)_256-SHA1(2); 
flags=-strict
000 "ext_tunnel":   ESP algorithms loaded: AES(12)_256-SHA1(2)_160
000 "ext_tunnel":   ESP algorithm newest: AES_256-HMAC_SHA1; pfsgroup=<N/A>
000
000 #203: "ext_tunnel":500 STATE_MAIN_I4 (ISAKMP SA established); 
EVENT_SA_REPLACE in 823s; newest ISAKMP; nodpd; idle; import:admin initiate
000 #200: "ext_tunnel":500 STATE_QUICK_I2 (sent QI2, IPsec SA 
established); EVENT_SA_REPLACE in 33286s; newest IPSEC; eroute owner; 
isakmp#199; idle; import:admin initiate
000 #200: "ext_tunnel" esp.feb6750d at 199.234.240.5 
esp.dc656b37 at 209.255.196.98 tun.0 at 199.234.240.5 tun.0 at 209.255.196.98 
ref=0 refhim=4294901761

I note that the eroute owner is #200, but the newest established SA is 
#203. So it looks like the eroute isn't being updated when the SA is 
rekeyed?? Thoughts?