Chapter 12
The behavior of rpm can also bite you. If installing a new RPM of a major new version, check for
.rpmnew and .rpmsave files being created when you run the update command.
If you switched from KLIPS to NETKEY, you might suddenly be seeing ICMP redirect messages. This is because NETKEY does not use a separate virtual ipsecX interface like KLIPS. So now if you receive a packet on an interface through an IPsec tunnel, and the decrypted packet has to go back out over the same interface, it will send an ICMP redirect packet. Worse, it even sends these if such an IP address would fall outside the netmasks involved. In other words, the redirect packet can be completely bogus. Thankfully, you can disable ICMP redirect packets using:
# echo "0" > /proc/sys/net/ipv4/conf/all/send_redirects
Or you can add an entry into /etc/sysctl.conf:
net.ipv4.conf.all.send_redirects = 0
Path MTU discovery with NETKEY is broken, so lowering the MTU on the machine that you just upgraded will not help, since the other end is still talking to a broken Path MTU discovery machine. But once you lower the MTU on the remote end, Path MTU failure does not matter, since the MTU is now small enough not to trigger the need for Path MTU discovery. So once you lower the MTU on the remote machine, the one you did not change, then suddenly things start working again. This is a bit counterintuitive.
Another issue to be aware of is how the internal matching of IPsec policies within the kernel stacks works. While KLIPS sorts its tunnels like a routing table, meaning it uses the most specific match first, NETKEY matches based on destination for the incoming packets, and based on source for the outgoing packets. As a result NETKEY does a strange match of most generic first. This causes problems for a setup where a local IP range from a teleworker (such as 192.168.1.0/24) is part of a bigger range from the entire company (such as 192.168.0.0/16). With KLIPS, you can define one normal tunnel for this setup; with NETKEY you need to poke holes in the policies on the teleworker side to avoid having your local IP range considered as on the other end of the tunnel.
conn bypass left=192.168.1.1
rIf you have another systemight=1.2.3.4 type=passthrough
authby=never
auto=route
If you see many hanging ip xfrm state processes in D state, then you have a bad combination of Openswan and NETKEY. Openswan switched from using the external setkey command to using the ip xfrm command as of version 2.3.1. However NETKEY had a bug in the xfrm code, which was fixed in Linux kernel 2.6.11.7. Either downgrade Openswan or upgrade the kernel. Or change the _realsetup program to override the test for the ip xfrm capability.
Using tcpdump to Debug IPsec
As an example, let us assume that we have an Openswan-Openswan connection, where we have got IKE working fine, so we see an IPsec SA established, but when we try to use this IPsec connection, all packets seem to get lost.
289
Debugging and Troubleshooting
We will use tcpdump to look at the network, but one could also use ethereal or tethereal in more or less the same way, since they also use libpcap, and therefore use the same expressions.
In general, tcpdump needs to run as root. Some distributions have customized versions of tcpdump, including options that mean the opposite from those in the official tcpdump package from tcpdump.org. If an option does not work for you, and the man page is no help, try to install tcpdump and libpcap from the original source yourself.
In our examples, we will assume that eth0 is the internal interface, and eth1 is the external interface. If PPPoE or PPTP is involved, then one should dump on the ppp0 interface rather than the eth1 interface: this will permit the selection expressions to work. tcpdump can decode PPPoE or PPTP packets, but cannot select based upon the encapsulated UDP port numbers within these packets.
The first thing to do is to observe the initiator's startup. If there is a NAT involved, remember that the system behind NAT always needs to be initiator—we will call this system sg1. After all, that machine cannot be reached behind its NAT. (Using port forwarding makes things immensely more complex and prone to failure.)
The ipsec auto –replace connname command removes any previous state, and reloads the definition of the conn from /etc/ipsec.conf. This is how it should look:
#ipsec auto --replace sg1--sg2-net
#ipsec auto --up sg1--sg2-net
104 "sg1--sg2-net" #796: STATE_MAIN_I1: initiate
003 "sg1--sg2-net" #796: received Vendor ID payload [Dead Peer Detection] 106 "sg1--sg2-net" #796: STATE_MAIN_I2: sent MI2, expecting MR2
108 "sg1--sg2-net" #796: STATE_MAIN_I3: sent MI3, expecting MR3 004 "sg1--sg2-net" #796: STATE_MAIN_I4: ISAKMP SA established 117 "sg1--sg2-net" #797: STATE_QUICK_I1: initiate
004 "sg1--sg2-net" #797: STATE_QUICK_I2: sent QI2, IPsec SA established
{ESP=>0xaa6fa19a |
<0xa2f3b68d xfrm=3DES_0-HMAC_SHA1 NATD=none |
|
DPD=enabled} |
|
|
There are four possible failures here: |
|
|
|
|
|
Symptom |
|
Typical Cause |
|
|
|
Situation A No messages are ever received |
Usually due to a firewall, some other blockage, or because the |
|
(only STATE_MAIN_I1) |
responder is not running (and ICMP messages are blocked by |
|
|
|
an overzealous system administrator). |
Situation B Message MI2 is repeated (MR1 |
Often due to failure to authenticate, but can also be due to a |
|
and MR2 are received) |
firewall on port 4500, when NAT-T is involved. |
|
Situation C QUICK mode initiates, but |
Often due to a mis-matched policy. |
|
never completes |
|
|
Situation D All of the IKE messages occur, |
Can be due to a number of things, including: firewalled ESP |
|
but traffic does not flow. |
packets, firewalled port 4500 packets, Path MTU issues, local |
|
|
|
or remote system misconfiguration such as a missing ip |
|
|
command, errors from the _updown scripts, miscompiled |
|
|
kernel modules, and so on. Apart from firewall and MTU |
|
|
issues, all these problems should clearly show up in the log |
|
|
files on either the initiator or the responder. |
|
|
|
290 |
|
|