[Openswan dev] bug in using KEY RR for OE in openswan-2 and remaining bugs in/proc filesystem for unload/reload of ipsec.o on Openswan-2 head on 2.4.25

[Paul Wouters]

I'm using HEAD Openswan-2 and I've been trying to test 2.4.25 with the
latest sprintf fixes. I tried using OE and KEY RR (not TXT RR).

Pluto never finds the KEY RR record in the reverse:

 ping admin.xtdnet.nl
Mar 30 11:26:19 fw-500me pluto[3005]: can not use our IP (193.110.157.22:TXT) as identity: no TXT RR found for us
ping: unknown host admin.xtdnet.nl
[root at fw-500me openswan-2]# Mar 30 11:26:29 fw-500me pluto[3005]: can not use our hostname (@fw-500me.eushow.xelerance.com:TXT) as identity: no TXT RR found for us
Mar 30 11:26:39 fw-500me pluto[3005]: can not use our IP (193.110.157.22:KEY) as identity: no KEY RR found for us
 
[root at fw-500me openswan-2]# host -t key 22.157.110.193.in-addr.arpa
22.157.110.193.in-addr.arpa has key 16896 4 1 AQPKOS3m1rn/9GiPrKXKRFQ2U0189YX7god+N5U/Evq8FNZikhfdbJoR +6Ko0kFzTFss7TGpbDuM1NySTfG2X5gU9lKsbHsuDlmobPSHPN7px11G fuL073freT70TG4ytu1NZD46SNQpjp0zCUtt5cOhXQrZFFkmqvDhtro4 jnb719eWxM3gfuTR8ttYYbN+4qgI6ZQbwYvjaXf335ZfXy0CCoHCQSJE VDWO+/kKaxPaVnkyLAEMdstfMZ03H0Yvnz4LdifNg8NE4AaQKl5yYkSt KPYyKz2dxC10AmKcz9ue+9V4mxvd8dBYB8lwG6LXdGCIOhAsiA6s0nVt +4FScYDm965UnQ0UWqIVaUNIISltYD8F

Putting the nameserver in the clear policy and restarting helped:

 ping admin.xtdnet.nl
PING admin.xtdnet.nl (193.110.157.7) 56(84) bytes of data.
Mar 30 11:30:15 fw-500me pluto[3407]: can not use our IP (193.110.157.22:TXT) as identity: no TXT RR found for us
Mar 30 11:30:15 fw-500me pluto[3407]: can not use our hostname (@fw-500me.eushow.xelerance.com:TXT) as identity: no TXT RR found for us
Mar 30 11:30:15 fw-500me pluto[3407]: using our IP (193.110.157.22:KEY) as identity!
Mar 30 11:30:15 fw-500me pluto[3407]: found KEY RR but not TXT RR for 193.110.157.22.Mar 30 11:30:15 fw-500me pluto[3407]: "private-or-clear#0.0.0.0/0"[1] ...193.110.157.76===193.110.157.7/32 #1: initiating Main Mode
Mar 30 11:30:15 fw-500me pluto[3407]: "private-or-clear#0.0.0.0/0"[1] ...193.110.157.76===193.110.157.7/32 #1: transition from state STATE_MAIN_I1 to state STATE_MAIN_I2
Mar 30 11:30:16 fw-500me pluto[3407]: "private-or-clear#0.0.0.0/0"[1] ...193.110.157.76===193.110.157.7/32 #1: transition from state STATE_MAIN_I2 to state STATE_MAIN_I3
Mar 30 11:30:16 fw-500me pluto[3407]: "private-or-clear#0.0.0.0/0"[1] ...193.110.157.76===193.110.157.7/32 #1: Peer ID is ID_IPV4_ADDR: '193.110.157.76'
Mar 30 11:30:16 fw-500me pluto[3407]: "private-or-clear#0.0.0.0/0"[1] ...193.110.157.76===193.110.157.7/32 #1: transition from state STATE_MAIN_I3 to state STATE_MAIN_I4
Mar 30 11:30:16 fw-500me pluto[3407]: "private-or-clear#0.0.0.0/0"[1] ...193.110.157.76===193.110.157.7/32 #1: ISAKMP SA established
Mar 30 11:30:16 fw-500me pluto[3407]: "private-or-clear#0.0.0.0/0"[1] ...193.110.157.76===193.110.157.7/32 #2: initiating Quick Mode RSASIG+ENCRYPT+TUNNEL+PFS+DONTREKEY+OPPORTUNISTIC+failurePASS {using isakmp#1}
64 bytes from admin.xtdnet.nl (193.110.157.7): icmp_seq=1 ttl=62 time=1248 ms
64 bytes from admin.xtdnet.nl (193.110.157.7): icmp_seq=2 ttl=62 time=252 ms
64 bytes from admin.xtdnet.nl (193.110.157.7): icmp_seq=3 ttl=62 time=14.9 ms
Mar 30 11:30:17 fw-500me pluto[3407]: "private-or-clear#0.0.0.0/0"[1] ...193.110.157.76===193.110.157.7/32 #2: transition from state STATE_QUICK_I1 to state STATE_QUICK_I2
Mar 30 11:30:17 fw-500me pluto[3407]: "private-or-clear#0.0.0.0/0"[1] ...193.110.157.76===193.110.157.7/32 #2: sent QI2, IPsec SA established {ESP=>0x4ef5e845 <0x4aebf5b1}
64 bytes from admin.xtdnet.nl (193.110.157.7): icmp_seq=4 ttl=62 time=14.6 ms
64 bytes from admin.xtdnet.nl (193.110.157.7): icmp_seq=5 ttl=64 time=15.5 ms

In othger words, 

bug #1: Pluto never recovers from initial DNS failures that are a result of 
        failed OE connections to that nameserver.


Restarting gave another odd problem:

ipsec_setup: Starting Openswan IPsec cvs2002Mar12_01:19:03...
ipsec_setup: Using /lib/modules/2.4.25/kernel/ipsec.o
ipsec_setup: modprobe: Can't locate module af_key
ipsec_setup: kernel appears to lack KLIPS
 
 service ipsec start
ipsec_setup: Starting Openswan IPsec cvs2002Mar12_01:19:03...
ipsec_setup: insmod: a module named ipsec already exists
ipsec_setup: Using /lib/modules/2.4.25/kernel/ipsec.o
ipsec_setup: modprobe: Can't locate module af_key
ipsec_setup: kernel appears to lack KLIPS
[root at fw-500me ipsec]# Mar 30 11:34:18 fw-500me ipsec_setup: Starting Openswan IPsec cvs2002Mar12_01:19:03...
Mar 30 11:34:18 fw-500me ipsec_setup: insmod: a module named ipsec already exists
Mar 30 11:34:18 fw-500me ipsec_setup: Using /lib/modules/2.4.25/kernel/ipsec.o
Mar 30 11:34:18 fw-500me ipsec_setup: modprobe: Can't locate module af_key
Mar 30 11:34:18 fw-500me ipsec_setup: kernel appears to lack KLIPS

 lsmod
Module                  Size  Used by    Not tainted
ipsec                 288352   0  (unused)
8139too                15304   2
mii                     3592   0  [8139too]
crc32                   3680   0  [8139too]

Unloading the module didn't help. I cannot restart it anymore.

Worse:

 lsmod|grep ipsec
ipsec                 288352   0

 ls -l /proc/net |grep ipsec
dr-xr-xr-x    7 root     root            0 Mar 30 11:32 ipsec
lrwxrwxrwx    1 root     root           16 Mar 30 11:37 ipsec_eroute -> ipsec/eroute/all
lrwxrwxrwx    1 root     root           16 Mar 30 11:37 ipsec_klipsdebug -> ipsec/klipsdebug
lrwxrwxrwx    1 root     root           13 Mar 30 11:37 ipsec_spi -> ipsec/spi/all
lrwxrwxrwx    1 root     root           16 Mar 30 11:37 ipsec_spigrp -> ipsec/spigrp/all
lrwxrwxrwx    1 root     root           11 Mar 30 11:37 ipsec_tncfg -> ipsec/tncfg
lrwxrwxrwx    1 root     root           13 Mar 30 11:37 ipsec_version -> ipsec/version

 cd /proc/net/ipsec
[root at fw-500me ipsec]# ls
klipsdebug

 cat klipsdebug
debug_tunnel=00000000.
debug_xform=00000000.
debug_eroute=00000000.
debug_spi=00000000.
debug_radij=00000000.
debug_esp=00000000.
debug_rcv=00000000.
debug_pfkey=00000000.

All the /proc/net/ipsec/ entries, apart from klipsdebug, are missing!

It seems something is still going wrong with the /proc filesystem on 2.4.25,
after we unload and load the ipsec.o module.

I will double check this with the latest FreeS/WAN cvs as well.

Paul