Debugging and Troubleshooting

A router between this machine and the destination of the packet (in this case the router 62.4.10.15) does not seem to be able to handle the UDP packet size of the IKE packet. This behavior is mostly seen on connections involving lots of NAT and possible bad ISPs with tunnels within tunnels, for instance using PPTP over PPPoE. Adding another layer of packets (IPsec) then finally causes this problem. You can try to play with MTU sizes, or talk to the ISP that owns that particular router and ask for advice.

104 "GroupVPN" #1: STATE_MAIN_I1: initiate

003 "GroupVPN" #1: received Vendor ID payload [draft-ietf-ipsec-nat-t-ike-00] 106 "GroupVPN" #1: STATE_MAIN_I2: sent MI2, expecting MR2

003 "GroupVPN" #1: ignoring unknown Vendor ID payload [da8e937880010000]

003 "GroupVPN" #1: ignoring unknown Vendor ID payload [404bf439522ca3f6]

003 "GroupVPN" #1: received Vendor ID payload [XAUTH]

003 "GroupVPN" #1: NAT-Traversal: Result using draft-ietf-ipsec-nat-t-ike- 00/01: i am NATed

108 "GroupVPN" #1: STATE_MAIN_I3: sent MI3, expecting MR3 004 "GroupVPN" #1: STATE_MAIN_I4: ISAKMP SA established 117 "GroupVPN" #2: STATE_QUICK_I1: initiate

010 "GroupVPN" #2: STATE_QUICK_I1: retransmission; will wait 20s for response

This is an example of an incoming client that tries to negotiate an XAUTH connection, but Openswan has not been configured with leftxauthserver=yes and rightxauthclient=yes. In this case, Openswan was talking to a SonicWALL machine and XAUTH was not supposed to be negotiated.

023 authentication method disagrees with "ian-nikita", which is also for an unspecified peer

This is a situation where the administrator tried to load more than one connection without uniquely identifying them. That is, you are using multiple connections with right=%any and the same authentication method, so that Pluto is not able to distinguish for which of those two connections an incoming connection is intended. The second connection that coincides with the first connection is refused by Pluto. This often happens if you use multiple PSK-based connections on dynamic IP addresses. You will have to use leftid= and rightid= options to clearly distinguish

these connections, for example leftid=@YourName and rightid=@theirname.

Common Kernel-Related Error Messages

If the NAT-T patch fails with something like:

1 out of 2 hunks FAILED -- saving rejects to file include/net/sock.h.rej 1 out of 3 hunks FAILED -- saving rejects to file net/ipv4/udp.c.rej

you are trying to patch the kernel with the KLIPS NAT-T patch, but the kernel contains conflicting NETKEY code. This is either because there is a NETKEY backport in your kernel (such as RHEL3 and Debian/Woody), or this is Openswan 2.3.x, which did not automatically pick the proper 2.4/2.6 NAT-T patch.

You can try to override the automatic detection using make nattpatch24 or make nattpatch26. If your kernel contains NETKEY code, it should always try the 26 version of the patch. The 24 version is only for 2.4 kernels without the NETKEY backport.

Aug 8 19:37:51 kbantoft pluto[3154]: "kb-to-bp-38" #3: sent QI2, IPsec SA established {ESP=>0x489df436 <0xb7093be3 NATOA=0.0.0.0}

Aug 8 19:38:16 kbantoft pluto[3154]: packet from ##.##.109.70:4500: recvfrom ##.##.109.70:4500 has no Non-ESP marker

Aug 8 19:39:01 kbantoft last message repeated 14 times

286

Chapter 12

This was a NAT-Traversal bug in the NETKEY code that was fixed in Linux kernel 2.6.8.1.

003 ERROR: "cm-vpn" #13: netlink write() of XFRM_MSG_ALLOCSPI message for Get SPI esp.0@192.168.0.13 failed. Errno 111: Connection refused

This kernel has no support for XFRM_USER. Recompile the kernel with CONFIG_XFRM_USER.

Unable to handle kernel NULL pointer dereference at virtual address 000000ec d08bdcf6

*pde = 00000000 Oops: 0002

CPU: 0

EIP: 0010:[<d08bdcf6>] Not tainted

Using defaults from ksymoops -t elf32-i386 -a i386 EFLAGS: 00010246

eax: 00000000 ebx: cd675f68 ecx: 00000000 edx: cd675f04 esi: 00000000 edi: cd675f14 ebp: cf003000 esp: cd675ef4 ds: 0018 es: 0018 ss: 0018

Process snmpd (pid: 2436, stackpage=cd675000)

Stack: cd675f04 cd675f64 cfe43800 cf154ea0 da0110e9 00000000 00000000 00000000 000089f0 cf003000 cd675f54 cd675f54 c021ec5f cf003000 cd675f54 000089f0 00000000 000089f0 00000001 00000000 c021ee8a cd675f54 000089f0 00000020

Call Trace: [<c021ec5f>] [<c021ee8a>] [<c0216576>] [<c0144ef9>] [<c010729b>]

Code: ff 0d ec 00 00 00 0f 94 c0 84 c0 75 0a b8 fa ff ff ff e9 fd

There was a conflict between KLIPS and the net-snmpd package if both used SIOCDEVPRIVATE. This has been fixed, so if you see this error you are running an old version of Openswan and you should upgrade.

Various KLIPS kernel panics on a multi-processor SMP machine (or a Pentium-IV with hyperthreading)

When forwarding between tunnels on two (or more) ipsecX interfaces, KLIPS locks up the kernel and everything is frozen until you hit the reset button. This bug is only triggered when a packet comes in on one ipsecX interface, and goes out another ipsecX interface, which is quite rare. There is also still a bug with a missing spinlock() call, but this has been difficult to track down. This bug is present at least up to Openswan 2.4.4.

Jul 2 15:57:30 xenu pluto[29579]: "BRU" #3: ERROR: netlink response for Add SA [e-mail].158 included errno 12: Cannot allocate memory

Old versions of NETKEY contained some bad memory allocation code for decompressing compressed packets. This has been fixed in recent 2.6 kernels. Either upgrade your kernel or add compress=no (on both ends!) as a workaround to disable compression.

003 "north-pole" #3: ERROR: netlink_get_spi for [e-mail] failed with errno 22: Invalid argument

A race condition in the netlink_get_spi function. Notably the RHEL3 kernel, which contains an old NETKEY backport, still features this bug. A workaround for this was released in Openswan 2.3.2. A configuration workaround exists by disabling compression on both ends of the connection using compress=no. Note that setting compress to no only causes Openswan to not advertise the compress capability. It will still respond to requests for compression, so if you keep seeing this error even though you have disabled compression on this end, the other end is still asking for it.

Apr 27 01:05:22 south-park pluto[3448]: "phenome--extrude" #3: ERROR: netlink response for Add SA esp.98650ce8@213.84.21.108 included errno 38: Function not implemented

287

Debugging and Troubleshooting

This error is returned when the kernel's crypto API functions are needed, but not loaded. Either the kernel is compiled without crypto API support, or the modules failed to load. Try:

# modprobe aes_i586 des sha1

For a list of crypto API ciphers, see /lib/modules/`uname -r`/kernel/crypto.

Common Errors when Upgrading

There are some common errors people run into when upgrading from an old FreeS/WAN or Super FreeS/WAN to Openswan, or when upgrading from Openswan 1 to Openswan 2.

"We only support version 2 of ipsec.conf"

If your ipsec.conf does not start with a line "version 2", then Openswan 2 will not start because it assumes an old version 1 configuration file is actually used. Apart from adding this line, you should remove the following two lines:

plutoload=

plutostart=

If you are not using Opportunistic Encryption, add the following line after the config setup and

config default sections:

include /etc/ipsec.d/examples/no_oe.conf

If in this upgrade you also switched from KLIPS to NETKEY, you should be aware that you just lost your ipsecX interfaces. This will require a rewrite of your firewall and NAT rules. If you see errors similar to:

May 31 14:56:09 NoordWest pluto[13329]: "thuis-best" #4: ERROR: netlink response for Add SA esp.b11cbf@193.111.228.3 included errno 2: No such file or directory

then some of the NETKEY modules might have failed to (automatically) load. You can modprobe these modules manually:

# modprobe af_key esp4 ah4 ipcomp xfrm4_tunnel

If you are going to upgrade, first stop Openswan. Since the locations of some lock and pid files have changed, a newer version of Openswan will not be able to stop an older version of Openswan that is still running. If you have already installed the new version, you will have to manually kill the processes. Look for processes with 'pluto' in the name. For the new installed version, you should first run the initscript with 'stop' to clean up the dirty run and pid files, otherwise when you start you will see the following error:

# service ipsec start

ipsec_setup: Openswan IPsec apparently already running, start aborted

Once you have killed all processes, check /var/run and remove the files related to Pluto or IPsec.

Also be careful not to install two versions in different locations. Most distributions will put the package in /usr, while your own compile will put things in /usr/local. However /usr will appear in your path first.

288