This section discusses a number of issues which have three things in common:
Grouping them here lets us provide the explanations some users will need without unduly complicating the main text.
Opportunistic encryption requires that the gateway systems be able to fetch public keys, and other IPsec-related information, from each other's DNS (Domain Name Service) records.
DNS is a distributed database that maps names to IP addresses and vice versa. We give only a brief overview here. For much more detail, see:
A system named gateway.example.com with IP address 10.20.30.40 should have at least two DNS records:
These problems are caused by various devices along the way mis-handling either packet fragments or path MTU discovery.
IPsec makes packets larger by adding an ESP or AH header. This can tickle assorted bugs in fragment handling in routers and firewalls, or in path MTU discovery mechanisms, and cause a variety of symptoms which are both annoying and, often, quite hard to diagnose.
An explanation from project technical lead Henry Spencer:
The problem is IP fragmentation; more precisely, the problem is that the second, third, etc. fragments of an IP packet are often difficult for filtering mechanisms to classify. Routers cannot rely on reassembling the packet, or remembering what was in earlier fragments, because the fragments may be out of order or may even follow different routes. So any general, worst-case filtering decision pretty much has to be made on each fragment independently. (If the router knows that it is the only route to the destination, so all fragments *must* pass through it, reassembly would be possible... but most routers don't want to bother with the complications of that.) All fragments carry roughly the original IP header, but any higher-level header is (for IP purposes) just the first part of the packet data... so only the first fragment carries that. So, for example, on examining the second fragment of a TCP packet, you could tell that it's TCP, but not what port number it is destined for -- that information is in the TCP header, which appears in the first fragment only. The result of this classification difficulty is that stupid routers and over-paranoid firewalls may just throw fragments away. To get through them, you must reduce your MTU enough that fragmentation will not occur. (In some cases, they might be willing to attempt reassembly, but have very limited resources to devote to it, meaning that packets must be small and fragments few in number, leading to the same conclusion: smaller MTU.)In addition to the problem Henry describes, you may also have trouble with path MTU discovery.
By default, FreeS/WAN uses a large MTU for the ipsec device. This avoids some problems, but may complicate others. Here's an explanation from Claudia:
Here are a couple of pieces of background information. Apologies if you have seen these already. An excerpt from one of my old posts: An MTU of 16260 on ipsec0 is usual. The IPSec device defaults to this high MTU so that it does not fragment incoming packets before encryption and encapsulation. If after IPSec processing packets are larger than 1500, [ie. the mtu of eth0] then eth0 will fragment them. Adding IPSec headers adds a certain number of bytes to each packet. The MTU of the IPSec interface refers to the maximum size of the packet before the IPSec headers are added. In some cases, people find it helpful to set ipsec0's MTU to 1500-(IPSec header size), which IIRC is about 1430. That way, the resulting encapsulated packets don't exceed 1500. On most networks, packets The MTU can be changed with an overridemtu= statement in the config setup section of ipsec.conf.5.
Here is an example of the difficulty of diagnosing an MTU-related problem, from the mailing list:
Date: Mon, 3 Apr 2000 From: "Michael H. Warfield" <email@example.com> Paul Koning wrote: > Chris> It appears that the Osicom router discards IP > Chris> fragments... > Amazing. A device that discards fragments isn't a router, it's at > best a boat anchor. It may not be exactly what it appears. I ran into a similar problem with an ISDN link a while ago giving similar symptoms. Turned out that the device was negotiating an MTU that it really couldn't handle and the device in front of it (a Linux box with always defragment enabled) was defragmenting the huge IPSec datagrams and then refragmenting them into hunks that the ISDN PPP thought it could handle but couldn't. Problem was solved by manually capping the MTU on the ISDN link to a smaller value. I gave the FreeSwan guys a hard time until tracking it down since FreeSwan was the only thing that appeared to be able to tickle the bug. Nothing else seemed to be broken. What it really was that MTU discovery was avoiding the problem on normal links and it was only the IPsec tunnels that were creating huge datagrams that went through the defragment/refragment process. Point here is that it "appeared" as though the ISDN link was failing to handle fragments when it was really a configuration error and a software bug resulting in a bad MTU that was really the culprit. So it may not be that the router is not handling fragments. It may be that it's missconfigured or has some other bug that only FreeSwan is tripping over.