Contributions to the FAQ are welcome. Please send them to the project
mailing list.
Questions
How do I report a problem or seek help?
See our problem reporting document. Basically,
what it says is send the output from
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.
Setup and testing questions
This is covered in some other documents:
However, we also list some of the commonest problems here.
I cannot ping ....
This question is dealt with in the configuration document under the
heading multiple tunnels.
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.
Manual connections work, but automatic keying doesn't
This is covered in our troubleshooting document.
One common reason for this behaviour is a firewall dropping the UDP port 500
packets used in key negotiation.
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.
Even if you can use tcpdump on gateways however, most certain way to examine
IPSEC packets is to look at them on the wire. For this, 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:
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:
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.
One manual connection works, but second one fails
From the mailing list:
> 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
configuration.html, specifically the part about needing a different spi
(or spibase) setting for each connection.
TCPdump on the gateway shows strange things
Attempting to look at IPSEC packets by running monitoring tools on the IPSEC
gateway machine can produce silly results. That machine is mangling the packets
for IPSEC, and possibly for firewall or NAT purposes as well. If the internals
of the machine's IP stack are not what the monitoring tool expects, then the
tool can misinterpret them and produce nonsense output.
Testing network
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
conn abc=xyz
left=192.168.p.1
leftnexthop=192.168.p.2
right=192.168.q.1
rightnexthop=192.168.q.2
Once 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.
Supported features
See also the lists of IPSEC features
supported and not supported in FreeS/WAN, given elsewhere in the
documentation.
Does FreeS/WAN support single DES encryption?
No, single DES is not used either at the IKE
level for negotiating connections or at the IPSEC
level for actually building them.
But isn't DES support part of the IPSEC standard?
Yes, but DES is insecure. As we see it, it is more
important to deliver real security than to comply with a standard which
has been subverted into allowing use of inadequate methods.
I have to talk to .... which offers only DES. How do I do this?
Ask the device vendor for the triple DES upgrade.
These exist for many IPSEC devices. If no cipher stronger than DES is available,
we recommend you not use that IPSEC implementation.
Consider using FreeS/WAN instead. PCs are cheap and we deliver 3DES now.
Does FreeS/WAN support X.509 or other PKI certificates?
FreeS/WAN, as distributed, does not currently support use of
X.509 or other
PKI certificates for authentication of
gateways. We are concentrating on moving toward authentication via
Secure DNS and
opportunistic encryption; X.509 support
is not (or at least definitely not yet) on the priority list.
Does FreeS/WAN run on my version of Linux?
We build and test on Redhat distributions, but FreeS/WAN runs just fine
on several other distributions, sometimes with minor fiddles to adapt to the
local environment. Details are in our
compatibility document.
Click below to go to: