This file is part of the documentation for the Linux FreeS/WAN project.
See the documentation index or project home page for more information.

FreeS/WAN FAQ

This is a collection of questions and answers, mostly taken from the FreeS/WAN mailing list.

Contributions are welcome. Please send them to the 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 ipsec barf from both gateways. Without full information, we cannot diagnose a problem.

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:
Setup
intitial setup and basic testing, to make sure everything is installed and working.
Configuration
configuration for actual use, including advanced options.
Troubleshooting
finding and fixing various problems
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:

ping from x.y.z.2 to a.b.c.2 or vice versa
Succeeds if tunnel is working. This is the only valid test of the tunnel.
ping from gate2 to a.b.c.2 or vice versa
Does not use tunnel. gate2 is not on protected subnet.
ping from gate1 to x.y.z.2 or vice versa
Does not use tunnel. gate1 is not on protected subnet.
ping from gate1 to gate2 or vice versa
Does not use tunnel. Neither gate is on a protected subnet.

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.

TCPdump on the gateway shows strange things

Do not attempt to look at IPSEC packets by running monitoring tools on the IPSEC gateway machine. That machine is mangling the packets for IPSEC, and possibly for firewall or NAT purposes as well. The internals of that machine's IP stack are not at all what the monitoring tool expects.

tcpdump becomes confused and can do almost anything: produce believable but incorrect output, produce utter nonsense, crash, ... Other monitoring tools based on the same library behave in much the same way.

To examine IPSEC packets reliably, 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:

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
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.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.

Note that nothing on either subnet needs to change. This lets you test most of your IPSEC setup before connecting to the insecure Internet.

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.

Single DES is insecure.

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.
  • If a 3DES implementation exists but your vendor cannot sell it to you because of export laws, consider complaining to one or more of:
    • the vendor
    • your own government, especially any branch concerned with citizen's privacy and/or protection of communication infrastructure
    • the local embassy of the nation which restricts export to you
Consider using FreeS/WAN instead. PCs are cheap and we deliver 3DES now.
Click below to go to: