This is a collection of questions and answers, mostly taken from the FreeS/WAN mailing list. See the project web page for more information. All the FreeS/WAN documentation is online there.
Contributions to the FAQ are welcome. Please send them to the project mailing list.
Use the mailing list for problem reports, rather than mailing developers directly. This gives you access to more expertise, including users who may have encountered and solved the same problems.
This may also be important in relation to various crypto export laws. For example, a US citizen who provides technical assistance to foreign cryptographic work might be charged under the arms export regulations. Such a charge would be easier to defend if the discussion took place in public, e.g. on a mailing list, than if it were done in private mail.
The standard subnet-to-subnet tunnel protects traffic only between the subnets. To test it, you must use pings that go from one subnet to the other.
For example, suppose you have:
subnet a.b.c.0/24 | eth1 = a.b.c.1 gate1 eth0 = 1.2.3.4 | ~ internet ~ | eth0 = 4.3.2.1 gate2 eth1 = x.y.z.1 | subnet x.y.z.0/24
and the connection description:
conn abc-xyz left=1.2.3.4 leftsubnet=a.b.c.0/24 right=4.3.2.1 rightsubnet=x.y.z.0/24
You can test this connection description only by sending a ping that will actually go through the tunnel. Assuming you have machines at addresses a.b.c.2 and x.y.z.2, pings you might consider trying are:
Only the first of these is a useful test of this tunnel. The others do not use the tunnel. Depending on other details of your setup and routing, they:
If required, you can of course build additional tunnels so that all the machines involved can talk to all the others. See multiple tunnels in the configuration document for details.
One common reason for this behaviour is a firewall dropping the UDP port 500 packets used in key negotiation.
> When I activate one manual tunnels it works, but when I try to activate > another tunnel, it gives an error message... > tunnel_2: Had trouble writing to /dev/ipsec SA:tun0x200@202.103.5.63 -- > SA already in use. Delete old one first. Please read the "Using manual keying in production" discussion in config.html, specifically the part about needing a different spi (or spibase) setting for each connection.
At one point, this problem was quite severe. On more recent systems, the problem has been solved. The version of tcpdump shipped with Redhat 6.2, for example, understands IPSEC well enough to be usable on a gateway. If in doubt about your version of tcpdump, you can get the latest version from tcpdump.org.
Even if you have aversion of tcpdump that works on gateways however, the most certain way to examine IPSEC packets is to look at them on the wire. For security, you need to be certain, so we recommend doing that. To do so, you need a separate sniffer machine located between the two gateways. This machine can be routing IPSEC packets, but it must not be an IPSEC gateway.
A common test setup is to put a machine with dual Ethernet cards in between two gateways under test. The central machine both routes packets and provides a place to safely run tcpdump or other sniffing tools. What you end up with looks like:
subnet a.b.c.0/24 | eth1 = a.b.c.1 gate1 eth0 = 192.168.p.1 | | eth0 = 192.168.p.2 route/monitor box eth1 = 192.168.q.2 | | eth0 = 192.168.q.1 gate2 eth1 = x.y.z.1 | subnet x.y.z.0/24
With p and q any convenient values that do not interfere with other routes you may have. The ipsec.conf(5) file then has, among other things:
conn abc=xyz left=192.168.p.1 leftnexthop=192.168.p.2 right=192.168.q.1 rightnexthop=192.168.q.2Once that works, you can remove the "route/monitor box", and connect the two gateways to the Internet. The only parameters in ipsec.conf(5) that need to change are the four shown above. You replace them with values appropriate for your Internet connection, and change the eth0 IP addresses and the default routes on both gateways.
Note that nothing on either subnet needs to change. This lets you test most of your IPSEC setup before connecting to the insecure Internet.
Single DES is insecure.
If a 3DES implementation exists but your vendor cannot sell it to you because of export laws, consider complaining to one or more of:
As a matter of project policy, we will not help anyone subvert FreeS/WAN to provide insecure DES encryption.
On the other hand, it is a priority for some users and user-contributed patches are available to add X.509 certificate support to FreeS/WAN now. See the patches section of our web references document for details.
FreeS/WAN is intended to run on all CPUs Linux supports . As of June 2000, we know of it being used in production on x86, ARM, Alpha and MIPS. It has also had successful tests on PPC and SPARC, though we don't know of actual use there. Details are in our compatibility document.
FreeS/WAN has been tested on multiprocessor Intel Linux and worked there. Note, however, that we do not test this often and have never tested on multiprocessor machines of other architectures.
If no match is found, it emits the above error message.
The message can also occur when an appropriate description exists but Pluto has not loaded it. Use an auto=add statement in the connection description, or an ipsec auto --add <conn_name> command, to correct this.
An explanation from the Pluto developer:
| Jul 12 15:00:22 sohar58 Pluto[574]: "corp_road" #2: cannot respond to IPsec | SA request because no connection is known for | 216.112.83.112/32===216.112.83.112...216.67.25.118 This is the first message from the Pluto log showing a problem. It means that PGPnet is trying to negotiate a set of SAs with this topology: 216.112.83.112/32===216.112.83.112...216.67.25.118 ^^^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^ ^^^^^^^^^^^^^ client on our side our host PGPnet host, no client None of the conns you showed look like this. Use ipsec auto --status to see a snapshot of what connections are in pluto, what negotiations are going on, and what SAs are established. The leftsubnet= (client) in your conn is 216.112.83.64/26. It must exactly match what pluto is looking for, and it does not.