From 9790537d64272aed35fda336ef18fac1fccd960d Mon Sep 17 00:00:00 2001 From: Rene Mayrhofer Date: Tue, 30 Jan 2007 12:25:57 +0000 Subject: - New upstream release. --- doc/src/faq.html | 2770 ------------------------------------------------------ 1 file changed, 2770 deletions(-) delete mode 100644 doc/src/faq.html (limited to 'doc/src/faq.html') diff --git a/doc/src/faq.html b/doc/src/faq.html deleted file mode 100644 index f62fc1c88..000000000 --- a/doc/src/faq.html +++ /dev/null @@ -1,2770 +0,0 @@ - - - - FreeS/WAN FAQ - - - - - -

FreeS/WAN FAQ

- -

This is a collection of questions and answers, mostly taken from the -FreeS/WAN mailing list. See the project web site 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.

-
- -

Index of FAQ questions

- -
- -

What is FreeS/WAN?

- -

FreeS/WAN is a Linux implementation of the IPsec protocols, providing security services -at the IP (Internet Protocol) level of the network.

- -

For more detail, see our introduction document or -the FreeS/WAN project web site.

- -

To start setting it up, go to our quickstart -guide.

- -

Our web links document has information on IPsec for other systems.

- -

How do I report a problem or seek help?

- -
-
Read our troubleshooting document.
-

It may guide you to a solution. If not, see its -problem reporting section.

- -

Basically, what it says is give us the output from ipsec -barf from both gateways. Without full information, we cannot -diagnose a problem. However, ipsec barf produces a lot of output. -If at all possible, please make barfs accessible via the web or -FTP rather than sending enormous mail messages.

-
- -
Use the users 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.
    • -
  • It is more likely to get a quick response. Developers may get behind on - email, or even ignore it entirely for a while, but a list message (given - a reasonable Subject: line) is certain to be read by a fair number of - people within hours.
    • -
  • It may also be important because of cryptography export laws. 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 on a public mailing list than if - it were done in private mail.
    • -
-
- -
Try irc.freenode.net#freeswan.
- -
-

FreeS/WAN developers, volunteers and users can often be found there. -Be patient and be -prepared to provide lots of information to support your question.

- -

If your question was really interesting, and you found an answer, -please share that with the class by posting to the -users mailing list. That way others with the -same problem can find your answer in the archives.

-
- -
Premium support is also available.
-
-

See the next several questions.

-
-
- -

Can I get ...

- -

Can I get an off-the-shelf system that includes -FreeS/WAN?

- -

There are a number of Linux distributions or firewall products which -include FreeS/WAN. See this list. Using one -of these, chosen to match your requirements and budget, may save you -considerable time and effort.

- -

If you don't know your requirements, start by reading Schneier's Secrets and Lies. That gives the best overview -of security issues I have seen. Then consider hiring a consultant (see next -question) to help define your requirements.

- -

Can I hire consultants or staff who know -FreeS/WAN?

- -

If you want the help of a contractor, or to hire staff with FreeS/WAN -expertise, you could:

- - -

For companies offerring support, see the next question.

- -

Can I get commercial support?

- -

Many of the distributions or firewall products which include FreeS/WAN -(see this list) come with commercial -support or have it available as an option.

- -

Various companies specialize in commercial support of open source -software. Our project leader was a founder of the first such company, Cygnus -Support. It has since been bought by Redhat. Another such firm is Linuxcare.

- -

Release questions

- -

What is the current release?

- -

The current release is the highest-numbered tarball on our distribution site. Almost -always, any of the mirrors will have the -same file, though perhaps not for a day or so after a release.

- -

Unfortunately, the web site is not always updated as quickly as it should -be.

- -

When is the next release?

- -

We try to do a release approximately every six to eight weeks. -

- -

If pre-release tests fail and the fix appears complex, or more generally -if the code does not appear stable when a release is scheduled, we will just -skip that release.

- -

For serious bugs, we may bring out an extra bug-fix release. These get -numbers in the normal release series. For example, there was a bug found in -FreeS/WAN 1.6, so we did another release less than two weeks later. The -bug-fix release was called 1.7.

- -

Are there known bugs in the current release?

- -

Any problems we are aware of at the time of a release are documented in -the BUGS file for that release. You should also look at -the CHANGES file.

- -

Bugs discovered after a release are discussed on the mailing lists. The easiest way to check for any problems -in the current code would be to peruse the -List In Brief.

- -

Modifications and contributions

- -

Can I modify FreeS/WAN to ...?

- -

You are free to modify FreeS/WAN in any way. See the discussion of licensing in our introduction document.

- -

Before investing much energy in any such project, we suggest that you

- - -

This may prevent duplicated effort, or lead to interesting -collaborations.

- -

Can I contribute to the project?

-In general, we welcome contributions from the community. Various contributed -patches, either to fix bugs or to add features, have been incorporated into -our distribution. Other patches, not yet included in the distribution, are -listed in our web links section. - -

Users have also contributed heavily to documentation, both by creating -their own HowTos and by posting things on the -mailing lists which I have quoted in these HTML -docs.

- -

There are, however, some caveats.

- -

FreeS/WAN is being implemented in Canada, by Canadians, largely to ensure -that is it is entirely free of export restrictions. See this discussion. We cannot accept code -contributions from US residents or citizens, not even one-line bugs -fixes. The reasons for this were recently discussed extensively on the -mailing list, in a thread starting here.

- -

Not all contributions are of interest to us. The project has a set of -fairly ambitious and quite specific goals, described in our introduction. Contributions that lead toward -these goals are likely to be welcomed enthusiastically. Other contributions -may be seen as lower priority, or even as a distraction.

- -

Discussion of possible contributions takes place on the design mailing list.

- -

Is there detailed design documentation?

-There are: - - -

The only formal design documents are a few papers in the last category -above. All the other categories, however, have things to say about design as -well.

- -

Will FreeS/WAN work in my environment?

- -

Can FreeS/WAN talk to ...?

- -

The IPsec protocols are designed to support interoperation. In theory, any -two IPsec implementations should be able to talk to each other. In practice, -it is considerably more complex. We have a whole interoperation document devoted to this problem.

- -

An important part of that document is links to the many user-written HowTos on interoperation -between FreeS/WAN and various other implementations. Often the users know -more than the developers about these issues (and almost always more than me -:-), so these documents may be your best resource.

- -

Can different FreeS/WAN versions talk to each -other?

- -

Linux FreeS/WAN can interoperate with many IPsec implementations, -including earlier versions of Linux FreeS/WAN itself.

- -

In a few cases, there are some complications. See our interoperation document for details.

- -

Is there a limit on throughput?

- -

There is no hard limit, but see below.

- -

Is there a limit on number of tunnels?

- -

There is no hard limit, but see next question.

- -

Is a ... fast enough to handle FreeS/WAN with my -loads?

- -

A quick summary:

-
-
Even a limited machine can be useful
-
A 486 can handle a T1, ADSL or cable link, though the machine may be - breathing hard.
-
A mid-range PC (say 800 MHz with good network cards) can do a lot of - IPsec
-
With up to roughly 50 tunnels and aggregate bandwidth of 20 Megabits - per second, it willl have cycles left over for other tasks.
-
There are limits
-
Even a high end CPU will not come close to handling a fully loaded - 100 Mbit/second Ethernet link. -

Beyond about 50 tunnels it needs careful management.

-
-
- -

See our FreeS/WAN performance document for -details.

- -

Will FreeS/WAN work on ... ?

- -

Will 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. Also, some -distributions or products come with FreeS/WAN -included.

- -

Will FreeS/WAN run on non-Intel CPUs?

- -

FreeS/WAN is intended to run on all CPUs Linux supports. -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.

- -

Will FreeS/WAN run on multiprocessors?

- -

FreeS/WAN is designed to work on any SMP architecture Linux supports, and -has been tested successfully on at least dual processor Intel architecture -machines. Details are in our compatibility document.

- -

Will FreeS/WAN work on an older kernel?

- -

It might, but we strongly recommend using a recent 2.2 or 2.4 series -kernel. Sometimes the newer versions include security fixes which can be -quite important on a gateway.

- -

Also, we use recent kernels for development and testing, so those are -better tested and, if you do encounter a problem, more easily supported. If -something breaks applying recent FreeS/WAN patches to an older kernel, then -"update your kernel" is almost certain to be the first thing we suggest. It -may be the only suggestion we have.

- -

The precise kernel versions supported by a particular FreeS/WAN release -are given in the README file of that release.

- -

See the following question for more on kernels.

- -

Will FreeS/WAN run on the latest kernel -version?

- -

Sometimes yes, but quite often, no.

- -

Kernel versions supported are given in the README -file of each FreeS/WAN release. Typically, they are whatever production -kernels were current at the time of our release (or shortly before; we might -release for kernel n just as Linus releases n+1). Often -FreeS/WAN will work on slightly later kernels as well, but of course this -cannot be guaranteed.

- -

For example, FreeS/WAN 1.91 was released for kernels 2.2.19 or 2.4.5, the -current kernels at the time. It also worked on 2.4.6, 2.4.7 and 2.4.8, but -2.4.9 had changes that caused compilation errors if it was patched with -FreeS/WAN 1.91.

- -

When such changes appear, we put a fix in the FreeS/WAN snapshots, and -distribute it with our next release. However, this is not a high priority for -us, and it may take anything from a few days to several weeks for such a -problem to find its way to the top of our kernel programmer's To-Do list. In -the meanwhile, you have two choices:

- - -

We don't even try to keep up with kernel changes outside the main 2.2 and -2.4 branches, such as the 2.4.x-ac patched versions from Alan Cox or the 2.5 -series of development kernels. We'd rather work on developing the FreeS/WAN -code than on chasing these moving targets. We are, however, happy to get -patches for problems discovered there.

- -

See also the Choosing a kernel section -of our installation document.

- -

Will FreeS/WAN work on unusual network -hardware?

- -

IPsec is designed to work over any network that IP works over, and -FreeS/WAN is intended to work over any network interface hardware that Linux -supports.

- -

If you have working IP on some unusual interface -- perhaps Arcnet, Token -Ring, ATM or Gigabit Ethernet -- then IPsec should "just work".

- -

That said, practice is sometimes less tractable than theory. Our testing -is done almost entirely on:

- - -

If you have some other interface, especially an uncommon one, it is -entirely possible you will get bitten either by a FreeS/WAN bug which our -testing did not turn up, or by a bug in the driver that shows up only with -our loads.

- -

If IP works on your interface and FreeS/WAN doesn't, seek help on the mailing lists.

- -

Another FAQ section describes MTU problems. -These are a possibility for some interfaces.

- -

Will FreeS/WAN work on a VLAN (802.1q) network?

- -

- Yes, FreeSwan works fine, though some network drivers have problems - with jumbo sized ethernet frames. If you used interfaces=%defaultroute - you do not need to change anything, but if you specified an interface - (eg eth0) then remember you must change that to reflect the VLAN - interface (eg eth0.2 for VLAN ID 2). -

-

- The "eepro100" module is known to be broken, use the e100 driver - for those cards instead (included in 2.4 as 'alternative driver' for - the Intel EtherExpressPro/100. -

-

- You do not need to change any MTU setting (those are workarounds - that are only needed for buggy drivers) -

- -

This FAQ contributed by Paul Wouters.

- -

Does FreeS/WAN support ...

- -

For a discussion of which parts of the IPsec specifications FreeS/WAN does -and does not implement, see our compatibility -document.

- -

For information on some often-requested features, see below.

- -

Does FreeS/WAN support site-to-site VPN -(Virtual Private Network) -applications?

- -

Absolutely. See this FreeS/WAN-FreeS/WAN -configuration example. -If only one site is using FreeS/WAN, there may be a relevant HOWTO on our -interop page. -

- -

Does FreeS/WAN support remote users connecting to a -LAN?

- -

Yes. We call the remote users "Road Warriors". Check out our -FreeS/WAN-FreeS/WAN -Road Warrior Configuration Example.

- -

If your Road Warrior is a Windows or Mac PC, you may need to -install an IPsec implementation on that machine. -Our interop page lists many available brands, -and features links to several HOWTOs. - - -

Does FreeS/WAN support remote users using -shared secret authentication?

- -

Yes, but there are severe restrictions, so we -strongly recommend using RSA keys for - authentication - -instead.

- -

See this FAQ question.

- -

Does FreeS/WAN support wireless networks?

- -

Yes, it is a common practice to use IPsec over wireless networks because -their built-in encryption, WEP, is -insecure.

- -

There is some discussion in -our advanced configuration document. See also the -WaveSEC site.

- -

Does FreeS/WAN support X.509 or other PKI -certificates?

- -

Vanilla FreeS/WAN does not support X.509, but Andreas Steffen -and others have provided a popular, well-supported X.509 patch.

- - - -

-Linux FreeS/WAN features -Opportunistic Encryption, an alternative -Public Key Infrastructure based on Secure DNS. -

- -

Does FreeS/WAN support user authentication (Radius, -SecureID, Smart Card...)?

- -

Andreas Steffen's X.509 patch (v. 1.42+) supports Smart Cards. The patch -does not ship with vanilla FreeS/WAN, but will be incorporated into -Super FreeS/WAN -2.01+. The patch implements the PCKS#15 -Cryptographic Token Information Format Standard, using the OpenSC smartcard -library functions.

- -

Older news:

- -

A user-supported patch to FreeS/WAN 1.3, for smart card style -authentication, is available on -Bastiaan's site. -It supports skeyid and ibutton. -This patch is not part of Super FreeS/WAN.

- -

For a while progress on this front was impeded by a lack of standard. -The IETF working group -has now nearly completed its recommended solution to the problem; meanwhile -several vendors have implemented various things.

- - - -

Of course, there are various ways to avoid any requirement for user -authentication in IPsec. Consider the situation where road warriors build -IPsec tunnels to your office net and you are considering requiring user -authentication during tunnel negotiation. Alternatives include:

- - -

If either of those is trustworthy, it is not clear that you need user -authentication in IPsec.

- - -

Does FreeS/WAN support NAT traversal?

- -

Vanilla FreeS/WAN does not, but thanks to Mathieu Lafon and -Arkoon Network Security, there's a patch to support this.

- - - -

The NAT traversal patch has some issues with PSKs, so you may wish to -authenticate with RSA keys, or X.509 (requires a patch which is also -included in Super FreeS/WAN). Doing the latter also has -advantages when dealing with large numbers of clients who may be behind NAT; -instead of having to make an individual Roadwarrior connection for each -virtual IP, you can use the "rightsubnetwithin" parameter to specify a range. -See -these -rightsubnetwithin instructions. -

- - -

Does FreeS/WAN support assigning a "virtual identity" to -a remote system?

- -

Some IPsec implementations allow you to make the source address on packets -sent by a Road Warrior machine be something other than the address of its -interface to the Internet. This is sometimes described as assigning a virtual -identity to that machine.

- -

FreeS/WAN does not directly support this, but it can be done. See this FAQ question.

- -

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. 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. -See this discussion.

- -

If you want to interoperate with an IPsec implementation which offers only -DES, see our interoperation document.

- -

Does FreeS/WAN support AES encryption?

- -

AES is a new US government block cipher standard to replace the obsolete -DES.

- -

At time of writing (March 2002), the FreeS/WAN distribution does not yet -support AES but user-written patches are -available to add it. Our kernel programmer is working on integrating those -patches into the distribution, and there is active discussion of this on the -design mailimg list.

- -

Does FreeS/WAN support other encryption -algorithms?

- -

Currently triple DES is the only cipher -supported. AES will almost certainly be added (see previous question), and it -is likely that in the process we will also add the other two AES finalists -with open licensing, Twofish and Serpent.

- -

We are extremely reluctant to add other ciphers. This would make both use -and maintenance of FreeS/WAN more complex without providing any clear -benefit. Complexity is emphatically not desirable in a security product.

- -

Various users have written patches to add other ciphers. We provide links to these.

- -

Can I ...

- - -

Can I use policy groups along with -explicitly configured connections?

- -

Yes, you can, so long as you pay attention to the selection rule, -which can be summarized "the most specific -connection wins". We describe the rule in our -policy groups document, -and provide a more technical explanation in -man ipsec.conf. -

- -

A good guideline: If you have a regular connection defined in -ipsec.conf, ensure that a subset of that connection -is not listed in a less restrictive policy group. Otherwise, -FreeS/WAN will use the subset, with its more specific source/destination -pair.

- -

Here's an example. Suppose you are the system administrator at 192.0.2.2. -You have this connection in ipsec.conf: -ipsec.conf: - -

conn net-to-net
-    left=192.0.2.2           # you are here
-    right=192.0.2.8
-    rightsubnet=192.0.2.96/27
-    ....
-
- -

If you then place a host or net within rightsubnet, -(let's say 192.0.2.98) in private-or-clear, you may find -that 192.0.2.2 at times communicates in the -clear with 192.0.2.98. That's consistent with the rule, but may be -contrary to your expectations.

- -

On the other hand, it's safe to put a larger subnet in a less -restrictive policy group file. If private-or-clear -contains 192.0.2.0/24, then the more specific net-to-net -connection is used for any communication to 192.0.2.96/27. The -more general policy applies only to communication with hosts or subnets in -192.0.2.0/24 without a more specific policy or connection.

- - -

Can I turn off policy groups?

- -

Yes. Use these -instructions.

- - - -

Can I reload connection info without restarting?

- -

Yes, you can do this. Here are the details, in a mailing list message from -Pluto programmer Hugh Redelmeier:

-
| How can I reload config's without restarting all of pluto and klips?  I am using
-| FreeSWAN -> PGPNet in a medium sized production environment, and would like to be
-| able to add new connections ( i am using include config/* ) without dropping current
-| SA's.
-| 
-| Can this be done?
-| 
-| If not, are there plans to add this kind of feature?
-
-        ipsec auto --add whatever
-This will look in the usual place (/etc/ipsec.conf) for a conn named
-whatever and add it.
-
-If you added new secrets, you need to do
-        ipsec auto --rereadsecrets
-before Pluto needs to know those secrets.
-
-| I have looked (perhaps not thoroughly enough tho) to see how to do this:
-
-There may be more bits to look for, depending on what you are trying
-to do.
- -

Another useful command here is ipsec auto --replace -<conn_name> which re-reads data for a named connection.

- -

Can I use several masqueraded subnets?

- -

Yes. This is done all the time. See the discussion in our setup document. The only restriction is -that the subnets on the two ends must not overlap. See the next question.

- -

Here is a mailing list message on the topic. The user incorrectly thinks -you need a 2.4 kernel for this -- actually various people have been doing it -on 2.0 and 2.2 for quite some time -- but he has it right for 2.4.

-
Subject: Double NAT and freeswan working :)
-   Date: Sun, 11 Mar 2001
-   From: Paul Wouters <paul@xtdnet.nl>
-
-Just to share my pleasure, and make an entry for people who are searching
-the net on how to do this. Here's the very simple solution to have a double
-NAT'ed network working with freeswan. (Not sure if this is old news, but I'm
-not on the list (too much spam) and I didn't read this in any HOWTO/FAQ/doc
-on the freeswan site yet (Sandy, put it in! :)
-
-10.0.0.0/24 --- 10.0.0.1 a.b.c.d  ---- a.b.c.e {internet} ----+
-                                                              |
-10.0.1.0/24 --- 10.0.1.1 f.g.h.i  ---- f.g.h.j {internet} ----+
-
-the goal is to have the first network do a VPN to the second one, yet also
-have NAT in place for connections not destinated for the other side of the
-NAT. Here the two Linux security gateways have one real IP number (cable
-modem, dialup, whatever.
-
-The problem with NAT is you don't want packets from 10.*.*.* to 10.*.*.*
-to be NAT'ed. While with Linux 2.2, you can't, with Linux 2.4 you can.
-
-(This has been tested and works for 2.4.2 with Freeswan snapshot2001mar8b)
-
-relevant parts of /etc/ipsec.conf:
-
-        left=f.g.h.i
-        leftsubnet=10.0.1.0/24
-        leftnexthop=f.g.h.j
-        leftfirewall=yes
-        leftid=@firewall.netone.nl
-        leftrsasigkey=0x0........
-        right=a.b.c.d
-        rightsubnet=10.0.0.0/24
-        rightnexthop=a.b.c.e
-        rightfirewall=yes
-        rightid=@firewall.nettwo.nl
-        rightrsasigkey=0x0......
-        # To authorize this connection, but not actually start it, at startup,
-        # uncomment this.
-        auto=add
-
-and now the real trick. Setup the NAT correctly on both sites:
-
-iptables -t nat -F
-iptables -t nat -A POSTROUTING -o eth0 -d \! 10.0.0.0/8 -j MASQUERADE
-
-This tells the NAT code to only do NAT for packets with destination other then
-10.* networks. note the backslash to mask the exclamation mark to protect it
-against the shell.
-
-Happy painting :)
-
-Paul
- -

Can I use subnets masqueraded to the same -addresses?

- -

No. The notion that IP addresses are unique is one of the -fundamental principles of the IP protocol. Messing with it is exceedingly -perilous.

- -

Fairly often a situation comes up where a company has several branches, -all using the same non-routable -addresses, perhaps 192.168.0.0/24. This works fine as long as those nets -are kept distinct. The IP masquerading on -their firewalls ensures that packets reaching the Internet carry the firewall -address, not the private address.

- -

This can break down when IPsec enters the picture. FreeS/WAN builds a -tunnel that pokes through both masquerades and delivers packets from -leftsubnet to rightsubnet and vice versa. For this to -work, the two subnets must be distinct.

- -

There are several solutions to this problem.

- -

Usually, you re-number the subnets. Perhaps the Vancouver -office becomes 192.168.101.0/24, Calgary 192.168.102.0/24 and so on. -FreeS/WAN can happily handle this. With, for example -leftsubnet=192.168.101.0/24 and -rightsubnet=192.168.102.0/24 in a connection description, any -machine in Calgary can talk to any machine in Vancouver. If you want to be -more restrictive and use something like -leftsubnet=192.168.101.128/25 and -rightsubnet=192.168.102.240/28 so only certain machines on each -end have access to the tunnel, that's fine too.

- -

You could also split the subnet into smaller ones, for -example using 192.168.1.0/25 in Vancouver and -rightsubnet=192.168.0.128/25 in Calgary.

- -

Alternately, you can just give up routing directly to -machines on the subnets. Omit the leftsubnet and -rightsubnet parameters from your connection descriptions. Your -IPsec tunnels will then run between the public interfaces of the two -firewalls. Packets will be masqueraded both before they are put into tunnels -and after they emerge. Your Vancouver client machines will see only one -Calgary machine, the firewall.

- -

Can I assign a road warrior an address on my net (a -virtual identity)?

- -

Often it would be convenient to be able to give a Road Warrior an IP -address which appears to be on the local network. Some IPsec implementations -have support for this, sometimes calling the feature "virtual identity".

- -

Currently (Sept 2002) FreeS/WAN does not support this, and we have -no definite plans to add it. The difficulty is that is not yet a standard -mechanism for it. There is an Internet Draft for a method of doing it using -DHCP which looks promising. FreeS/WAN may support that in -a future release.

- -

In the meanwhile, you can do it yourself using the Linux iproute2(8) -facilities. Details are in this -paper.

- -

Another method has also been discussed on the mailing list.:

- - -

For example, you might have:

-
-
leftsubnet=a.b.c.0/25
-
head office network
-
rightsubnet=a.b.c.129/32
-
extruded to a road warrior. Note that this is not in a.b.c.0/25
-
a.b.c.0/24
-
whole network, including both the above
-
- -

You then set up routing so that the office machines use the IPsec gateway -as their route to a.b.c.128/25. The leftsubnet parameter tells the road -warriors to use tunnels to reach a.b.c.0/25, so you should have two-way -communication. Depending or your network and applications, there may be some -additional work to do on DNS or Windows configuration

- -

Can I support many road warriors with one -gateway?

- -

Yes. This is easily done, using

-
-
either RSA authentication
-
standard in the FreeS/WAN distribution
-
or X.509 certificates
-
requires Super FreeS/WAN or a patch.
-
- -

In either case, each Road Warrior must have a different key or -certificate.

- -

It is also possible using pre-shared key authentication, -though we don't recommend this; see the -next question for details.

- -

If you expect to have more than a few dozen Road Warriors connecting -simultaneously, you may need a fairly powerful gateway machine. See our -document on FreeS/WAN performance.

- -

Can I have many road warriors using shared secret -authentication?

- -

Yes, but avoid it if possible.

- -

You can have multiple Road Warriors using shared secret authentication -only if they all use the same secret. You must also -set:

- -

   uniqueids=no
- -

in the connection definition.

- - -

Why it's less secure:

- - -

This is a designed-in limitation of the IKE key negotiation protocol, not a problem with -our implementation.

- -

We very strongly recommend that you avoid using shared secret -authentication for multiple Road Warriors. Use RSA authentication -instead.

- -

The longer story: When using shared secrets, the protocol requires -that the responding -gateway be able to determine which secret to use at a time when all it knows -about the initiator is an IP address. This works fine if you know the -initiator's address in advance and can use it to look up the appropiriate -secret. However, it fails for Road Warriors since the gateway cannot know -their IP addresses in advance.

- -

With RSA signatures (or certificates) the protocol is slightly different. -The initiator provides an identifier early in the exchange and the responder -can use that identifier to look up the correct key or certificate. See above.

- -

Can I use Quality of Service routing with -FreeS/WAN?

- -

From project technical lead Henry Spencer:

-
> Do QoS add to FreeS/WAN?
-> For example integrating DiffServ and FreeS/WAN?
-
-With a current version of FreeS/WAN, you will have to add hidetos=no to
-the config-setup section of your configuration file.  By default, the TOS
-field of tunnel packets is zeroed; with hidetos=no, it is copied from the
-packet inside.  (This is a modest security hole, which is why it is no
-longer the default.)
-
-DiffServ does not interact well with tunneling in general.  Ways of
-improving this are being studied.
- -

Copying the TOS (type of service) -information from the encapsulated packet to the outer header reveals the TOS -information to an eavesdropper. This does not tell him much, but it might be -of use in traffic analysis. Since we do -not have to give it to him, our default is not to.

- -

Even with the TOS hidden, you can still:

- - -

See ipsec.conf(5) for more on -the hidetos= parameter.

- - -

Can I recognise dead tunnels and shut them -down?

- -

There is no general mechanism to do this is in the IPsec protocols.

- -

From time to time, there is discussion on the IETF Working Group mailing list of adding a "keep-alive" mechanism -(which some say should be called "make-dead"), but it is a fairly complex -problem and no consensus has been reached on whether or how it should be -done.

- -

The protocol does have optional delete-SA messages -which one side can send when it closes a connection in hopes this will cause -the other side to do the same. FreeS/WAN does not currently support these. In -any case, they would not solve the problem since:

- - -

However, connections do have limited lifetimes and you can control how -many attempts your gateway makes to rekey before giving up. For example, you -can set:

-
conn default
-        keyingtries=3
-        keylife=30m
- -

With these settings old connections will be cleaned up. Within 30 minutes -of the other end dying, rekeying will be attempted. If it succeeds, the new -connection replaces the old one. If it fails, no new connection is created. -Either way, the old connection is taken down when its lifetime expires.

- -

Here is a mailing list message on the topic from FreeS/WAN tech support -person Claudia Schmeing:

-
You ask how to determine whether a tunnel is redundant:
-
-> Can anybody explain the best way to determine this. Esp when a RW has
-> disconnected? I thought 'ipsec auto --status' might be one way.
-
-If a tunnel goes down from one end, Linux FreeS/WAN on the
-other end has no way of knowing this until it attempts to rekey.
-Once it tries to rekey and fails, it will 'know' that the tunnel is 
-down.
-
-Because it doesn't have a way of knowing the state until this point, 
-it will also not be able to tell you the state via ipsec auto --status.
-
-> However, comparing output from a working tunnel with that of one that
-> was closed 
-> did not show clearly show tunnel status.
-
-If your tunnel is down but not 'unrouted' (see man ipsec_auto), you
-should not be able to ping the opposite side of the tunnel. You can
-use this as an indicator of tunnel status.
-
-On a related note, you may be interested to know that as of 1.7, 
-redundant tunnels caused by RW disconnections are likely to be 
-less of a pain. From doc/CHANGES:
-
-    There is a new configuration parameter, uniqueids, to control a new Pluto
-    option:  when a new connection is negotiated with the same ID as an old
-    one, the old one is deleted immediately.  This should help eliminate
-    dangling Road Warrior connections when the same Road Warrior reconnects. 
-    It thus requires that IDs not be shared by hosts (a previously legal but
-    probably useless capability).  NOTE WELL:  the sample ipsec.conf now has
-    uniqueids=yes in its config-setup section.
-
-
-Cheers,
-
-Claudia
- -

Can I build IPsec tunnels over a demand-dialed -link?

- -

This is possible, but not easy. FreeS/WAN technical lead Henry Spencer -wrote:

-
> 5. If the ISDN link goes down in between and is reestablished, the SAs
-> are still up but the eroute are deleted and the IPsec interface shows
-> garbage (with ifconfig)
-> 6. Only restarting IPsec will bring the VPN back online.
-
-This one is awkward to solve.  If the real interface that the IPsec
-interface is mounted on goes down, it takes most of the IPsec machinery
-down with it, and a restart is the only good way to recover. 
-
-The only really clean fix, right now, is to split the machines in two: 
-
-1. A minimal machine serves as the network router, and only it is aware
-that the link goes up and down. 
-
-2. The IPsec is done on a separate gateway machine, which thinks it has
-a permanent network connection, via the router.
-
-This is clumsy but it does work.  Trying to do both functions within a
-single machine is tricky.  There is a software package (diald) which will
-give the illusion of a permanent connection for demand-dialed modem
-connections; I don't know whether it's usable for ISDN, or whether it can
-be made to cooperate properly with FreeS/WAN. 
-
-Doing a restart each time the interface comes up *does* work, although it
-is a bit painful.  I did that with PPP when I was running on a modem link;
-it wasn't hard to arrange the PPP scripts to bring IPsec up and down at
-the right times.  (I'd meant to investigate diald but never found time.)
-
-In principle you don't need to do a complete restart on reconnect, but you
-do have to rebuild some things, and we have no nice clean way of doing
-only the necessary parts.
- -

In the same thread, one user commented:

-
Subject: Re: linux-ipsec: IPsec and Dial Up Connections
-   Date: Wed, 22 Nov 2000
-   From: Andy Bradford <andyb@calderasystems.com>
-
-On Wed, 22 Nov 2000 19:47:11 +0100, Philip Reetz wrote:
-
-> Are there any ideas what might be the cause of the problem and any way
-> to work around it.
-> Any help is highly appreciated.
-
-On my laptop, when using ppp there is a ip-up script in /etc/ppp that 
-will be executed each time that the ppp interface is brought up.  
-Likewise there is an ip-down script that is called when it is taken 
-down.  You might consider custimzing those to stop and start FreeS/WAN 
-with each connection.  I believe that ISDN uses the same files, though 
-I could be wrong---there should be something similar though.
- -

Can I build GRE, L2TP or PPTP tunnels over IPsec?

- -

Yes. Normally this is not necessary, but it is useful in a few special -cases. For example, if you must route non-IP packets such as IPX, you -will need to use a tunneling protocol that can route these packets. IPsec -can be layered around it for extra security. Another example: you -can provide failover protection for high availability (HA) environments by -combining IPsec with other tools. Ken Bantoft describes one such setup in -Using FreeS/WAN with Linux-HA, GRE, -OSPF and BGP for enterprise grade VPN solutions.

- -

GRE over IPsec is covered as part of -that document. - -Here are links to other GRE resources. - -Jacco de Leuw has created -this page on L2TP over IPsec -with instructions for FreeS/WAN and several other brands of IPsec software. -

- -

Please let us know of other useful links via the -mailing lists. - - -

... use Network Neighborhood (Samba, NetBIOS) over IPsec?

- -

Your local PC needs to know how to translate NetBIOS names to IP addresses. -It may do this either via a local LMHOSTS file, or using a local or remote -WINS server. The WINS server is preferable since it provides a centralized -source of the information to the entire network. To use a WINS server over -the VPN -(or any IP-based network), you must enable "NetBIOS over TCP".

- -

Samba can emulate a WINS server -on Linux.

- -

-See also several discussions in our -September -2002 Users archives

- - -

Life's little mysteries

- -

FreeS/WAN is a fairly complex product. (Neither the networks it runs on -nor the protocols it uses are simple, so it could hardly be otherwise.) It -therefore sometimes exhibits behaviour which can be somewhat confusing, or -has problems which are not easy to diagnose. This section tries to explain -those problems.

- -

Setup and configuration of FreeS/WAN are covered in other documentation -sections:

- - -

However, we also list some of the commonest problems here.

- -

I cannot ping ....

- -

This question is dealt with in the advanced configuration section 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 = 192.0.2.8
-             |
-
-       ~ internet ~
-
-             |
-      eth0 = 192.0.2.11
-         gate2
-      eth1 = x.y.z.1
-              |
-       subnet x.y.z.0/24
- -

and the connection description:

-
conn abc-xyz
-     left=192.0.2.8
-     leftsubnet=a.b.c.0/24
-     right=192.0.2.11
-     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:

- - -

In some cases, you may be able to get around this. For the example network -above, you could use:

-
        ping -I a.b.c.1 x.y.z.1
- -

Both the adresses given are within protected subnets, so this should go -through the tunnel.

- -

If required, you can build additional tunnels so that all the machines -involved can talk to all the others. See multiple tunnels in the advanced -configuration document for details.

- -

It takes forever to ...

- -

Users fairly often report various problems involving long delays, -sometimes on tunnel setup and sometimes on operations done through the -tunnel, occasionally on simple things like ping or more often on more complex -operations like doing NFS or Samba through the tunnel.

- -

Almost always, these turn out to involve failure of a DNS lookup. The -timeouts waiting for DNS are typically set long so that you won't time out -when a query involves multiple lookups or long paths. Genuine failures -therefore produce long delays before they are detected.

- -

A mailing list message from project technical lead Henry Spencer:

-
> ... when i run /etc/rc.d/init.d/ipsec start, i get:
-> ipsec_setup: Starting FreeS/WAN IPsec 1.5...
-> and it just sits there, doesn't give back my bash prompt.
-
-Almost certainly, the problem is that you're using DNS names in your
-ipsec.conf, but DNS lookups are not working for some reason.  You will
-get your prompt back... eventually.  But the DNS timeouts are long.
-Doing something about this is on our list, but it is not easy.
- -

In the meanwhile, we recommend that connection descriptions in ipsec.conf(5) use numeric IP addresses -rather than names which will require a DNS lookup.

- -

Names that do not require a lookup are fine. For example:

- - -

These are fine. The @ sign prevents any DNS lookup. However, do not -attempt to give the gateway address as left=camelot.example.org. -That requires a lookup.

- -

A post from one user after solving a problem with long delays:

-
Subject: Final Answer to Delay!!!
-   Date: Mon, 19 Feb 2001
-   From: "Felippe Solutions" <felippe@solutionstecnologia.com.br>
-
-Sorry people, but seems like the Delay problem had nothing to do with
-freeswan.
-
-The problem was DNS as some people sad from the beginning, but not the way
-they thought it was happening. Samba, ssh, telnet and other apps try to
-reverse lookup addresses when you use IP numbers (Stupid that ahh).
-
-I could ping very fast because I always ping with "-n" option, but I don't
-know the option on the other apps to stop reverse addressing so I don't use
-it.
- -

This post is fairly typical. These problems are often tricky and -frustrating to diagnose, and most turn out to be DNS-related.

- -

One suggestion for diagnosis: test with both names and addresses if -possible. For example, try all of:

- - -

If these behave differently, the problem must be DNS-related since the -three commands do exactly the same thing except for DNS lookups.

- -

I send packets to the tunnel with route(8) but they -vanish

- -

IPsec connections are designed to carry only packets travelling between -pre-defined connection endpoints. As project technical lead Henry Spencer put -it:

- -
- IPsec tunnels are not just virtual wires; they are virtual wires with - built-in access controls. Negotiation of an IPsec tunnel includes - negotiation of access rights for it, which don't include packets to/from - other IP addresses. (The protocols themselves are quite inflexible about - this, so there are limits to what we can do about it.)
- -

For fairly obvious security reasons, and to comply with the IPsec RFCs, KLIPS drops any packets it receives that are -not allowed on the tunnels currently defined. So if you send it packets with -route(8), and suitable tunnels are not defined, the packets -vanish. Whether this is reported in the logs depends on the setting of -klipsdebug in your ipsec.conf(5) file.

- -

To rescue vanishing packets, you must ensure that suitable tunnels for -them exist, by editing the connection descriptions in ipsec.conf(5). For example, supposing -you have a simple setup:

-
         leftsubnet -- leftgateway === internet === roadwarrior
- -

If you want to give the roadwarrior access to some resource that is -located behind the left gateway but is not in the currently defined left -subnet, then the usual procedure is to define an additional tunnel for those -packets by creating a new connection description.

- -

In some cases, it may be easier to alter an existing connection -description, enlarging the definition of leftsubnet. For example, -instead of two connection descriptions with 192.168.8.0/24 and 192.168.9.0/24 -as their leftsubnet parameters, you can use a single description -with 192.168.8.0/23.

- -

If you have multiple endpoints on each side, you need to ensure that there -is a route for each pair of endpoints. See this example.

- -

When a tunnel goes down, packets vanish

- -

This is a special case of the vanishing packet problem described in the -previous question. Whenever KLIPS sees packets for which it does not have a -tunnel, it drops them.

- -

When a tunnel goes away, either because negotiations with the other -gateway failed or because you gave an ipsec auto --down command, -the route to its other end is left pointing into KLIPS, and KLIPS will drop -packets it has no tunnel for.

- -

This is a documented design decision, not a bug. FreeS/WAN must not -automatically adjust things to send packets via another route. The other -route might be insecure.

- -

Of course, re-routing may be necessary in many cases. In those cases, you -have to do it manually or via scripts. We provide the ipsec auto ---unroute command for these cases.

- -

From ipsec_auto(8):

- -
- Normally, pluto establishes a route to the destination specified for a - connection as part of the --up operation. However, the route and only - the route can be established with the --route operation. Until and unless - an actual connection is established, this discards any packets sent - there, which may be preferable to having them sent elsewhere based on a - more general route (e.g., a default route).
- -
- Normally, pluto's route to a destination remains in place when a --down - operation is used to take the connection down (or if connection setup, or - later automatic rekeying, fails). This permits establishing a new - connection (perhaps using a different specification; the route is altered - as necessary) without having a ``window'' in which packets might go - elsewhere based on a more general route. Such a route can be removed - using the --unroute operation (and is implicitly removed by ---delete).
- -

See also this mailing list message.

- -

The firewall ate my packets!

- -

If firewalls filter out:

- - -

then IPsec cannot work. The first thing to check if packets seem to be -vanishing is the firewall rules on the two gateway machines and any other -machines along the path that you have access to.

- -

For details, see our document on firewalls.

- -

Some advice from technical lead Henry Spencer on diagnosing such -problems:

-
> > Packets vanishing between the hardware interface and the ipsecN interface
-> > is usually the result of firewalls not being configured to let them in...
-> 
-> Thanks for the suggestion. If only it were that simple! My ipchains startup
-> script does take care of that, but just in case I manually inserted rules 
-> accepting everything from london on dublin. No difference.
-
-The other thing to check is whether the "RX packets dropped" count on the
-ipsecN interface (run "ifconfig ipsecN", for N=1 or whatever, to see the
-counts) is rising.  If so, then there's some sort of configuration mismatch
-between the two ends, and IPsec itself is rejecting them.  If none of the
-ipsecN counts is rising, then the packets are never reaching the IPsec
-machinery, and the problem is almost certainly in firewalls etc.
- -

Dropped connections

- -

Networks being what they are, IPsec connections can be broken for any -number of reasons, ranging from hardware failures to various software -problems such as the path MTU problems discussed elsewhere in the FAQ. Fortunately, various diagnostic -tools exist that help you sort out many of the possible problems.

- -

There is one situation, however, where FreeS/WAN (using default settings) -may destroy a connection for no readily apparent reason. This occurs when -things are misconfigured so that two -tunnels from the same gateway expect the same subnet on the -far end.

- -

In this situation, the first tunnel comes up fine and works until the -second is established. At that point, because of the way we track connections -internally, the first tunnel ceases to exist as far as this gateway is -concerned. Of course the far end does not know that, and a storm of error -messages appears on both systems as it tries to use the tunnel.

- -

If the far end gives up, goes back to square one and negotiates a new -tunnel, then that wipes out the second tunnel and ...

- -

The solution is simple. Do not build multiple conn descriptions -with the same remote subnet.

- -

This is actually intended to be a feature, rather than a bug. Consider the -situation where a single remote system goes down, then comes back up and -reconnects to the gateway. It is useful to have the gateway tear down the old -tunnel and recover resources when the reconnection is made. It recognises -that situation by checking the remote subnet for each tunnel it builds and -discarding duplicates. This works fine as long as you don't configure -multiple tunnels with the same remote subnet.

- -

If this behaviour is inconvenient for you, you can disable it by setting -uniqueids=no in ipsec.conf(5).

- - -

Disappearing %defaultroute

- -

When an underlying connection (eg. ppp) goes down, FreeS/WAN will not -recover properly without a little help. Here are the symptoms that FreeS/WAN -user Michael Carmody noticed: -

-> After about 24 hours the freeswan connection takes over the default route.
-> 
-> i.e instead of deafult gateway pointing to the router via eth0, it becomes a 
-> pointer to the router via ipsec0.
- 
-> All internet access is then lost as all replies (and not just the link I 
-> wanted) are routed out ipsec0 and the router doesn't respond to the ipsec 
-> traffic.
-
- -

If you're using a -FreeS/WAN 2.x/KLIPS system, simply re-attach the IPsec virtual -interface with ipsec tnconfig command such as:

-
    ipsec tnconfig --attach --virtual ipsec0 --physical ppp0
-

In your command, name the physical and virtual interfaces as they -appear paired on your system during regular uptime. For a system with several -physical/virtual interface pairs on flaky links, you'll need more than -one such command. -If you're using FreeS/WAN 1.x, you must restart FreeS/WAN, which is more time -consuming.

- -

-Here -is a script which can help to automate the process of FreeS/WAN restart at -need. -It could easily be adapted to use tnconfig instead.

- -

TCPdump on the gateway shows strange things

- -As another user pointed out, keeping the connect -

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.

- -

See our testing document for more -detail.

- -

Traceroute does not show anything between the -gateways

- -

As far as traceroute can see, the two gateways are one hop apart; the data -packet goes directly from one to the other through the tunnel. Of course the -outer packets that implement the tunnel pass through whatever lies between -the gateways, but those packets are built and dismantled by the gateways. -Traceroute does not see them and cannot report anything about their path.

- -

Here is a mailing list message with more detail.

-
Date: Mon, 14 May 2001
-To: linux-ipsec@freeswan.org
-From: "John S. Denker" <jsd@research.att.com<
-Subject: Re: traceroute: one virtual hop
-
-At 02:20 PM 5/14/01 -0400, Claudia Schmeing wrote:
->
->> > A bonus question: traceroute in subnet to subnet enviroment looks like:
->> > 
->> > traceroute to andris.dmz (172.20.24.10), 30 hops max, 38 byte packets
->> > 1  drama (172.20.1.1)  0.716 ms  0.942 ms  0.434 ms
->> > 2  * * *
->> > 3  andris.dmz (172.20.24.10)  73.576 ms  78.858 ms  79.434 ms
->> > 
->> > Why aren't there the other hosts which take part in the delivery during 
->    * * * ?
->
->If there is an ipsec tunnel between GateA and Gate B, this tunnel forms a 
->'virtual wire'.  When it is tunneled, the original packet becomes an inner 
->packet, and new ESP and/or AH headers are added to create an outer packet 
->around it. You can see an example of how this is done for AH at 
->doc/ipsec.html#AH . For ESP it is similar.
->
->Think about the packet's path from the inner packet's perspective.
->It leaves the subnet, goes into the tunnel, and re-emerges in the second
->subnet. This perspective is also the only one available to the
->'traceroute' command when the IPSec tunnel is up.
-
-Claudia got this exactly right.  Let me just expand on a couple of points:
-
-*) GateB is exactly one (virtual) hop away from GateA.  This is how it
-would be if there were a physically private wire from A to B.  The
-virtually private connection should work the same, and it does.
-
-*) While the information is in transit from GateA to GateB, the hop count
-of the outer header (the "envelope") is being decremented.  The hop count
-of the inner header (the "contents" of the envelope) is not decremented and
-should not be decremented.  The hop count of the outer header is not
-derived from and should not be derived from the hop count of the inner header.
-
-Indeed, even if the packets did time out in transit along the tunnel, there
-would be no way for traceroute to find out what happened.  Just as
-information cannot leak _out_ of the tunnel to the outside, information
-cannot leak _into_ the tunnel from outside, and this includes ICMP messages
-from routers along the path.
-
-There are some cases where one might wish for information about what is
-happening at the IP layer (below the tunnel layer) -- but the protocol
-makes no provision for this.  This raises all sorts of conceptual issues.
-AFAIK nobody has ever cared enough to really figure out what _should_
-happen, let alone implement it and standardize it.
-
-*) I consider the "* * *" to be a slight bug.  One might wish for it to be
-replaced by "GateB GateB GateB".  It has to do with treating host-to-subnet
-traffic different from subnet-to-subnet traffic (and other gory details).
-I fervently hope KLIPS2 will make this problem go away.
-
-*) If you want to ask questions about the link from GateA to GateB at the
-IP level (below the tunnel level), you have to ssh to GateA and launch a
-traceroute from there.
- -

Testing in stages

- -

It is often useful in debugging to test things one at a time:

- - -

FreeS/WAN releases are tested for all of these, so you can be reasonably -certain they can do them all. Of course, that does not mean they -will on the first try, especially if you have some unusual -configuration.

- -

The rest of this section gives information on diagnosing the problem when -each of the above steps fails.

- -

Manually keyed connections don't work

- -

Suspect one of:

- - -

One manual connection works, but second one -fails

- -

This is a fairly common problem when attempting to configure multiple -manually keyed connections from a single gateway.

- -

Each connection must be identified by a unique SPI value. For automatic connections, these -values are assigned automatically. For manual connections, you must set them -with spi= statements in ipsec.conf(5).

- -

Each manual connection must have a unique SPI value in the range 0x100 to -0x999. Two or more with the same value will fail. For details, see our doc -section Using manual keying in -production and the man page ipsec.conf(5).

- -

Manual connections work, but automatic keying -doesn't

- -

The most common reason for this behaviour is a firewall dropping the UDP -port 500 packets used in key negotiation.

- -

Other possibilities:

- - -

IPsec works, but connections using compression -fail

- -

When we first added compression, we saw some problems:

- - -

We have not seen either problem in some time (at least six months as I -write in March 2002), but if you have some unusual configuration then you may -see them.

- -

Small packets work, but large transfers -fail

- -

If tests with ping(1) and a small packet size succeed, but tests or -transfers with larger packet sizes fail, suspect problems with packet -fragmentation and perhaps path MTU -discovery.

- -

Our troubleshooting document covers -these problems. Information on the underlying mechanism is in our background document.

- -

Subnet-to-subnet works, but tests from the gateways -don't

- -

This is described under I cannot ping... above.

- -

Compilation problems

- -

gmp.h: No such file or directory

- -

Pluto needs the GMP (GNU

- -

Multi-Precision) library for the large -integer calculations it uses in public key -cryptography. This error message indicates a failure to find the library. You -must install it before Pluto will compile.

- -

The GMP library is included in most Linux distributions. Typically, there -are two RPMs, libgmp and libgmp-devel, You need to install both, -either from your distribution CDs or from your vendor's web site.

- -

On Debian, a mailing list message reports that the command to give is -apt-get install gmp2.

- -

For more information and the latest version, see the GMP home page.

- -

... virtual memory exhausted

- -

We have had several reports of this message appearing, all on SPARC Linux. -Here is a mailing message on a solution:

-
> ipsec_sha1.c: In function `SHA1Transform':
-> ipsec_sha1.c:95: virtual memory exhausted
-
-I'm seeing exactly the same problem on an Ultra with 256MB ram and 500
-MB swap.  Except I am compiling version 1.5 and its Red Hat 6.2.
-
-I can get around this by using -O instead of -O2 for the optimization
-level.  So it is probably a bug in the optimizer on the sparc complier. 
-I'll try and chase this down on the sparc lists.
- -

Interpreting error messages

- -

route-client (or host) exited with status -7

- -

Here is a discussion of this error from FreeS/WAN "listress" (mailing list -tech support person) Claudia Schmeing. The "FAQ on the network unreachable -error" which she refers to is the next question below.

-
> I reached the point where the two boxes (both on dial-up connections, but
-> treated as static IPs by getting the IP and editing ipsec.conf after the
-> connection is established) to the point where they exchange some info, but I
-> get an error like "route-client command exited with status 7 \n internal
-> error".
-> Where can I find a description of this error?
-
-In general, if the FAQ doesn't cover it, you can search the mailing list 
-archives - I like to use
-http://www.sandelman.ottawa.on.ca/linux-ipsec/
-but you can see doc/mail.html for different archive formats.
-
-
-Your error comes from the _updown script, which performs some
-routing and firewall functions to help Linux FreeS/WAN. More info
-is available at doc/firewall.html and man ipsec.conf. Its routing
-is integral to the health of Linux FreeS/WAN; it also provides facility
-to insert custom firewall rules to be executed when you create or destroy
-a connection.
-
-Yours is, of course, a routing error. You can be fairly sure the routing 
-machinery is saying "network is unreachable". There's a FAQ on the 
-"network is unreachable" error, but more information is available now; read on.
-
-If your _updown script is recent (for example if it shipped with 
-Linux FreeS/WAN 1.91), you will see another debugging line in your logs 
-that looks something like this:
-
-> output: /usr/local/lib/ipsec/_updown: `route add -net 128.174.253.83 
-> netmask 255.255.255.255 dev ipsec0 gw 66.92.93.161' failed
-
-This is, of course, the system route command that exited with status 7, 
-(ie. failed). Man route for details. Seeing the command typed out yields 
-more information. If your _updown script is older, you may wish to update 
-it to show the command explicitly.
-
-Three parameters fed to the route command: net, netmask and gw [gateway] 
-are derived from things you've put in ipsec.conf.
-
-Net and netmask are derived from the peer's IP and mask. In more detail:
-
-You may see a routing error when routing to a client (ie. subnet), or 
-to a host (IPSec gateway or freestanding host; a box that does IPSec for
-itself). In _updown, the "route-client" section  is responsible to set up 
-the route for IPSec'd (usually, read 'tunneled') packets headed to a 
-peer subnet. Similarly, route-host routes IPSec'd packets to a peer host
-or IPSec gateway.
-
-When routing to a 'client', net and netmask are ipsec.conf's left- or 
-rightsubnet (whichever is not local). Similarly, when routing to a 
-'host' the net is left or right. Host netmask is always /32, indicating a 
-single machine.
-
-Gw is nexthop's value. Again, the value in question is left- or rightnexthop,
-whichever is local. Where left/right or left-/rightnexthop has the special 
-value %defaultroute (described in man ipsec.conf), gw will automagically get
-the value of the next hop on the default route.
-
-Q: "What's a nexthop and why do I need one?"
-
-A: 'nexthop' is a routing kluge; its value is the next hop away
-   from the machine that's doing IPSec, and toward your IPSec peer. 
-   You need it to get the processed packets out of the local system and 
-   onto the wire. While we often route other packets through the machine 
-   that's now doing IPSec, and are done with it, this does not suffice here. 
-   After packets are processed with IPSec, this machine needs to know where 
-   they go next. Of course using the 'IPSec gateway' as their routing gateway 
-   would cause an infinite loop! [To visualize this, see the packet flow 
-   diagram at doc/firewall.html.] To avoid this, we route packets through 
-   the next hop down their projected path.
-
-Now that you know the background, consider:
-1. Did you test routing between the gateways in the absence of Linux
-   FreeS/WAN, as recommended? You need to ensure the two machines that
-   will be running Linux FreeS/WAN can route to one another before trying to 
-   make a secure connection.
-2. Is there anything obviously wrong with the sense of your route command?
-
-Normally, this problem is caused by an incorrect local nexthop parameter.
-Check out the use of %defaultroute, described in man ipsec.conf. This is
-a simple way to set nexthop for most people. To figure nexthop out by hand,
-traceroute in-the-clear to your IPSec peer. Nexthop is the traceroute's 
-first hop after your IPSec gateway.
- -

SIOCADDRT:Network is unreachable

- -

This message is not from FreeS/WAN, but from the Linux IP stack itself. -That stack is seeing packets it has no route for, either because your routing -was broken before FreeS/WAN started or because FreeS/WAN's changes broke -it.

- -

Here is a message from Claudia suggesting ways to diagnose and fix such -problems:

-
You write,
-> I have correctly installed freeswan-1.8 on RH7.0 kernel 2.2.17, but when 
-> I setup a VPN connection with the other machine(RH5.2 Kernel 2.0.36 
-> freeswan-1.0, it works well.) it told me that 
-> "SIOCADDRT:Network is unreachable"!  But the network connection is no 
-> problem.
-
-Often this error is the result of a misconfiguration. 
-
-Be sure that you can route successfully in the absence of Linux
-FreeS/WAN. (You say this is no problem, so proceed to the next step.)
-
-Use a custom copy of the default updownscript. Do not change the route 
-commands, but add a diagnostic message revealing the exact text of the 
-route command. Is there a problem with the sense of the route command
-that you can see? If so, then re-examine those ipsec.conf settings
-that are being sent to the route command. 
-
-You may wish to use the ipsec auto --route and --unroute commands to 
-troubleshoot the problem. See man ipsec_auto for details.
- -

Since the above message was written, we have modified the updown script to -provide a better diagnostic for this problem. Check -/var/log/messages.

- -

See also the FAQ question route-client (or host) -exited with status 7.

- -

ipsec_setup: modprobe: Can't locate module -ipsec

- -

ipsec_setup: Fatal error, kernel appears to lack -KLIPS

- -

These messages indicate an installation failure. The kernel you are -running does not contain the KLIPS (kernel -IPsec) code.

- -

Note that the "modprobe: Can't locate module ipsec" message appears even -if you are not using modules. If there is no KLIPS in your kernel, FreeS/WAN -tries to load it as a module. If that fails, you get this message.

- -

Commands you can quickly try are:

-
-
uname -a
-
to get details, including compilation date and time, of the currently - running kernel
-
ls /
-
ls /boot
-
to ensure a new kernel is where it should be. If kernel compilation - puts it in / but lilo wants it in - /boot, then you should uncomment the - INSTALL_PATH=/boot line in the kernel - Makefile.
-
more /etc/lilo.conf
-
to see that lilo has correct information
-
lilo
-
to ensure that information in /etc/lilo.conf has been - transferred to the boot sector
-
- -

If those don't find the problem, you have to go back and check through the -install procedure to see what was missed.

- -

Here is one of Claudia's messages on the topic:

-
> I tried to install freeswan 1.8 on my mandrake 7.2 test box. ...
-
-> It does show version and some output for whack.
-
-Yes, because the Pluto (daemon) part of ipsec is installed correctly, but
-as we see below the kernel portion is not.
-
-> However, I get the following from /var/log/messages:
-> 
-> Mar 11 22:11:55 pavillion ipsec_setup: Starting FreeS/WAN IPsec 1.8...
-> Mar 11 22:12:02 pavillion ipsec_setup: modprobe: Can't locate module ipsec
-> Mar 11 22:12:02 pavillion ipsec_setup: Fatal error, kernel appears to lack
-> KLIPS.
-
-This is your problem. You have not successfully installed a kernel with
-IPSec machinery in it. 
-
-Did you build Linux FreeS/WAN as a module? If so, you need to ensure that 
-your new module has been installed in the directory where your kernel 
-loader normally finds your modules. If not, you need to ensure
-that the new IPSec-enabled kernel is being loaded correctly.
-
-See also doc/install.html, and INSTALL in the distro.
- -

ipsec_setup: ... failure to fetch key for ... from -DNS

- -

Quoting Henry:

-
Note that by default, FreeS/WAN is now set up to
-     (a) authenticate with RSA keys, and
-     (b) fetch the public key of the far end from DNS.
-Explicit attention to  ipsec.conf will be needed if you want
-to do something different.
- -

and Claudia, responding to the same user:

-
You write,
-
->       My current setup in ipsec.conf is leftrsasigkey=%dns I have 
-> commented this and authby=rsasig out. I am able to get ipsec running, 
-> but what I find is that the documentation only specifies for %dns are 
-> there any other values that can be placed in this variable other than 
-> %dns and the key? I am also assuming that this is where I would place 
-> my public key for the left and right side as well is this correct?
-
-Valid values for authby= are rsasig and secret, which entail authentication
-by RSA signature or by shared secret, respectively. Because you have 
-commented authby=rsasig out, you are using the default value of authby=secret. 
-
-When using RSA signatures, there are two ways to get the public key for the
-IPSec peer: either copy it directly into *rsasigkey= in ipsec.conf, or
-fetch it from dns. The magic value %dns for *rsasigkey parameters says to 
-try to fetch the peer's key from dns.
-
-For any parameters, you may find their significance and special values in
-man ipsec.conf. If you are setting up keys or secrets, be sure also to
-reference man ipsec.secrets.
- -

ipsec_setup: ... interfaces ... and ... share -address ...

- -

This is a fatal error. FreeS/WAN cannot cope with two or more interfaces -using the same IP address. You must re-configure to avoid this.

- -

A mailing list message on the topic from Pluto developer Hugh -Redelmeier:

-
| I'm trying to get freeswan working between two machine where one has a ppp
-| interface.
-| I've already suceeded with  two machines with ethernet ports but  the ppp
-| interface is causing me problems.
-|  basically when I run ipsec start  i get
-| ipsec_setup: Starting FreeS/WAN IPsec 1.7...
-| ipsec_setup: 003 IP interfaces ppp1 and ppp0 share address 192.168.0.10!
-| ipsec_setup: 003 IP interfaces ppp1 and ppp2 share address 192.168.0.10!
-| ipsec_setup: 003 IP interfaces ppp0 and ppp2 share address 192.168.0.10!
-| ipsec_setup: 003 no public interfaces found
-|
-| followed by lots of cannot work out interface for connection messages
-|
-| now I can specify the interface in ipsec.conf to be ppp0 , but this does
-| not affect the above behaviour. A quick look in server.c indicates that the
-| interfaces value  is not used but some sort of raw detect happens.
-|
-| I guess I could prevent the formation of the extra ppp interfaces or
-| allocate them different ip but I'd  rather not. if at all possible. Any
-| suggestions please.
-
-Pluto won't touch an interface that shares an IP address with another.
-This will eventually change, but it probably won't happen soon.
-
-For now, you will have to give the ppp1 and ppp2 different addresses.
- -

ipsec_setup: Cannot adjust kernel flags

- -

A mailing list message form technical lead Henry Spencer:

-
> When FreeS/WAN IPsec 1.7 is starting on my 2.0.38 Linux kernel the following
-> error message is generated:
-> ipsec_setup: Cannot adjust kernel flags, no /proc/sys/net/ipsec directory!
-> What is supposed to create this directory and how can I fix this problem?
-
-I think that directory is a 2.2ism, although I'm not certain (I don't have
-a 2.0.xx system handy any more for testing).  Without it, some of the
-ipsec.conf config-setup flags won't work, but otherwise things should
-function.
- -

You also need to enable the /proc filesystem in your kernel -configuration for these operations to work.

- -

Message numbers (MI3, QR1, et cetera) in Pluto -messages

- -

Pluto messages often indicate where Pluto is in the IKE protocols. The -letters indicate Main mode or Quick mode -and Initiator or Responder. The numerals -are message sequence numbers. For more detail, see our IPsec section.

- -

Connection names in Pluto error messages

- -

From Pluto programmer Hugh Redelmeier:

-
| Jan 17 16:21:10 remus Pluto[13631]: "jumble" #1: responding to Main Mode from Road Warrior 130.205.82.46
-| Jan 17 16:21:11 remus Pluto[13631]: "jumble" #1: no suitable connection for peer @banshee.wittsend.com
-| 
-|     The connection "jumble" has nothing to do with the incoming
-| connection requests, which were meant for the connection "banshee".
-
-You are right.  The message tells you which Connection Pluto is
-currently using, which need not be the right one.  It need not be the
-right one now for the negotiation to eventually succeed!  This is
-described in ipsec_pluto(8) in the section "Road Warrior Support".
-
-There are two times when Pluto will consider switching Connections for
-a state object.  Both are in response to receiving ID payloads (one in
-Phase 1 / Main Mode and one in Phase 2 / Quick Mode).  The second is
-not unique to Road Warriors.  In fact, neither is the first any more
-(two connections for the same pair of hosts could differ in Phase 1 ID
-payload; probably nobody else has tried this).
- -

Pluto: ... can't orient connection

- -

Older versions of FreeS/WAN used this message. The same error now gives -the "we have no ipsecN ..." error described just below.

- -

... we have no ipsecN interface for either end of -this connection

- -

Your tunnel has no IP address which matches the IP -address of any of the available IPsec interfaces. Either you've -misconfigured the connection, or you need to define an appropriate -IPsec interface connection. interfaces=%defaultroute works -in many cases.

- -

A longer story: Pluto needs to know whether it is running on -the machine which the -connection description calls left or on right. It -figures that out by:

- - -

Normally a match is found. Then Pluto knows where it is and can set up -other things (for example, if it is left) using parameters such as -leftsubnet and leftnexthop, and sending its outgoing -packets to right.

- -

If no match is found, it emits the above error message.

- -

Pluto: ... no connection is known

- -

This error message occurs when a remote system attempts to negotiate a -connection and Pluto does not have a connection description that matches what -the remote system has requested. The most common cause is a configuration -error on one end or the other.

- -

Parameters involved in this match are left, right, -leftsubnet and rightsubnet.

- -

The match must be exact. For example, if your left subnet -is a.b.c.0/24 then neither a single machine in that net nor a smaller subnet -such as a.b.c.64/26 will be considered a match.

- -

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

Pluto: ... no suitable connection ...

- -

This is similar to the no connection known error, -but occurs at a different point in Pluto processing.

- -

Here is one of Claudia's messages explaining the problem:

-
You write,
-
-> What could be the reason of the following error? 
-> "no suitable connection for peer '@xforce'"
-
-When a connection is initiated by the peer, Pluto must choose which entry in 
-the conf file best matches the incoming connection. A preliminary choice is 
-made on the basis of source and destination IPs, since that information is 
-available at that time. 
-
-A payload containing an ID arrives later in the negotiation. Based on this
-id and the *id= parameters, Pluto refines its conn selection. ...
-
-The message "no suitable connection" indicates that in this refining step,
-Pluto does not find a connection that matches that ID.
-
-Please see "Selecting a connection when responding" in man ipsec_pluto for
-more details.
- -

See also Connection names in Pluto error -messages.

- -

Pluto: ... no connection has been -authorized

- -

Here is one of Claudia's messages discussing this problem:

-
You write,
-
->  May 22 10:46:31 debian Pluto[25834]: packet from x.y.z.p:10014: 
->  initial Main Mode message from x.y.z.p:10014 
-                            but no connection has been authorized
-
-This error occurs early in the connection negotiation process,
-at the first step of IKE negotiation (Main Mode), which is itself the 
-first of two negotiation phases involved in creating an IPSec connection.
-
-Here, Linux FreeS/WAN receives a packet from a potential peer, which 
-requests that they begin discussing a connection.
-
-The "no connection has been authorized" means that there is no connection 
-description in Linux FreeS/WAN's internal database that can be used to 
-link your ipsec interface with that peer.
-
-"But of course I configured that connection!" 
-
-It may be that the appropriate connection description exists in ipsec.conf 
-but has not been added to the database with ipsec auto --add myconn or the 
-auto=add method. Or, the connection description may be misconfigured.
-
-The only parameters that are relevant in this decision are left= and right= .
-Local and remote ports are also taken into account -- we see that the port 
-is printed in the message above -- but there is no way to control these
-in ipsec.conf.
-
-
-Failure at "no connection has been authorized" is similar to the
-"no connection is known for..." error in the FAQ, and the "no suitable
-connection" error described in the snapshot's FAQ. In all three cases,
-Linux FreeS/WAN is trying to match parameters received in the
-negotiation with the connection description in the local config file.
-
-As it receives more information, its matches take more parameters into 
-account, and become more precise:  first the pair of potential peers,
-then the peer IDs, then the endpoints (including any subnets).
-
-The "no suitable connection for peer *" occurs toward the end of IKE 
-(Main Mode) negotiation, when the IDs are matched.
-
-"no connection is known for a/b===c...d" is seen at the beginning of IPSec 
-(Quick Mode, phase 2) negotiation, when the connections are matched using
-left, right, and any information about the subnets.
- -

Pluto: ... OAKLEY_DES_CBC is not -supported.

- -

This message occurs when the other system attempts to negotiate a -connection using single DES, which we do not -support because it is insecure.

- -

Our interoperation document has suggestions for how to deal with systems that attempt to use -single DES.

- -

Pluto: ... no acceptable transform

- -

This message means that the other gateway has made a proposal for -connection parameters, but nothing they proposed is acceptable to Pluto. -Possible causes include:

- - -

A more detailed explanation, from Pluto programmer Hugh Redelmeier:

-
Background:
-
-When one IKE system (for example, Pluto) is negotiating with another
-to create an SA, the Initiator proposes a bunch of choices and the
-Responder replies with one that it has selected.
-
-The structure of the choices is fairly complicated.  An SA payload
-contains a list of lists of "Proposals".  The outer list is a set of
-choices: the selection must be from one element of this list.
-
-Each of these elements is a list of Proposals.  A selection must be
-made from each of the elements of the inner list.  In other words,
-*all* of them apply (that is how, for example, both AH and ESP can
-apply at once).
-
-Within each of these Proposals is a list of Transforms.  For each
-Proposal selected, one Transform must be selected (in other words,
-each Proposal provides a choice of Transforms).
-
-Each Transform is made up of a list of Attributes describing, well,
-attributes.  Such as lifetime of the SA.  Such as algorithm to be
-used.  All the Attributes apply to a Transform.
-
-You will have noticed a pattern here: layers alternate between being
-disjunctions ("or") and conjunctions ("and").
-
-For Phase 1 / Main Mode (negotiating an ISAKMP SA), this structure is
-cut back.  There must be exactly one Proposal.  So this degenerates to
-a list of Transforms, one of which must be chosen.
-
-In your case, no proposal was considered acceptable to Pluto (the
-Responder).  So negotiation ceased.  Pluto logs the reason it rejects
-each Transform.  So look back in the log to see what is going wrong.
- -

rsasigkey dumps core

-A comment on this error from Henry: -
On Fri, 29 Jun 2001, Rodrigo Gruppelli wrote:
-> ...Well, it seem that there's
-> another problem with it. When I try to generate a pair of RSA keys,
-> rsasigkey cores dump...
-
-*That* is a neon sign flashing "GMP LIBRARY IS BROKEN".  Rsasigkey calls
-GMP a lot, and our own library a little bit, and that's very nearly all it
-does.  Barring bugs in its code or our library -- which have happened, but
-not very often -- a problem in rsasigkey is a problem in GMP.
- -

See the next question for how to deal with GMP errors.

- -

!Pluto failure!: ... exited with ... signal 4

- -

Pluto has died. Signal 4 is SIGILL, illegal instruction.

- -

The most likely cause is that your GMP -(GNU multi-precision) library is compiled for a different processor than what -you are running on. Pluto uses that library for its public key -calculations.

- -

Try getting the GMP sources and recompile for your processor type. Most -Linux distributions will include this source, or you can download it from the -GMP home page.

- -

ECONNREFUSED error message

- -

From John Denker, on the mailing list:

-
1)  The log message
-  some IKE message we sent has been rejected with 
-  ECONNREFUSED (kernel supplied no details)
-is much more suitable than the previous version.  Thanks.
-
-2) Minor suggestion for further improvement: it might be worth mentioning
-that the command
-  tcpdump -i eth1 icmp[0] != 8 and icmp[0] != 0
-is useful for tracking down the details in question.  We shouldn't expect
-all IPsec users to figure that out on their own.  The log message might
-even provide a hint as to where to look in the docs.
- -

Reply From Pluto developer Hugh Redelmeier

-
Good idea.
-
-I've added a bit pluto(8)'s BUGS section along these lines.
-I didn't have the heart to lengthen this message.
- -

klips_debug: ... no eroute!

- -

This message means KLIPS has received a -packet for which no IPsec tunnel has been defined.

- -

Here is a more detailed duscussion from the team's tech support person -Claudia Schmeing, responding to a query on the mailing list:

-
> Why ipsec reports no eroute! ???? IP Masq... is disabled.
-
-In general, more information is required so that people on the list may
-give you informed input. See doc/prob.report.
- -

The document she refers to has since been replaced by a section of the troubleshooting -document.

-
However, I can make some general comments on this type of error.
-
-This error usually looks something like this (clipped from an archived
-message):
-
-> ttl:64 proto:1 chk:45459 saddr:192.168.1.2 daddr:192.168.100.1
-> ... klips_debug:ipsec_findroute: 192.168.1.2->192.168.100.1
-> ... klips_debug:rj_match: * See if we match exactly as a host destination
-> ... klips_debug:rj_match: ** try to match a leaf, t=0xc1a260b0
-> ... klips_debug:rj_match: *** start searching up the tree, t=0xc1a260b0
-> ... klips_debug:rj_match: **** t=0xc1a260c8
-> ... klips_debug:rj_match: **** t=0xc1fe5960
-> ... klips_debug:rj_match: ***** not found.
-> ... klips_debug:ipsec_tunnel_start_xmit: Original head/tailroom: 2, 28
-> ... klips_debug:ipsec_tunnel_start_xmit: no eroute!: ts=47.3030, dropping.
-
-
-What does this mean?
-- --------------------
-
-"eroute" stands for "extended route", and is a special type of route 
-internal to Linux FreeS/WAN. For more information about this type of route, 
-see the section of man ipsec_auto on ipsec auto --route.
-
-"no eroute!" here means, roughly, that Linux FreeS/WAN cannot find an 
-appropriate tunnel that should have delivered this packet. Linux 
-FreeS/WAN therefore drops the packet, with the message "no eroute! ...
-dropping", on the assumption that this packet is not a legitimate 
-transmission through a properly constructed tunnel.
-
-
-How does this situation come about?
-- -----------------------------------
-
-Linux FreeS/WAN has a number of connection descriptions defined in 
-ipsec.conf. These must be successfully brought "up" to form actual tunnels.
-(see doc/setup.html's step 15, man ipsec.conf and man ipsec_auto 
-for details).
-
-Such connections are often specific to the endpoints' IPs. However, in 
-some cases they may be more general, for example in the case of 
-Road Warriors where left or right is the special value %any.
-
-When Linux FreeS/WAN receives a packet, it verifies that the packet has
-come through a legitimate channel, by checking that there is an
-appropriate tunnel through which this packet might legitimately have
-arrived. This is the process we see above.
-
-First, it checks for an eroute that exactly matches the packet. In the 
-example above, we see it checking for a route that begins at 192.168.1.2
-and ends at 192.168.100.1. This search favours the most specific match that
-would apply to the route between these IPs. So, if there is a connection 
-description exactly matching these IPs, the search will end there. If not, 
-the code will search for a more general description matching the IPs.
-If there is no match, either specific or general, the packet will be
-dropped, as we see, above.
-
-Unless you are working with Road Warriors, only the first, specific part 
-of the matching process is likely to be relevant to you.
-
-
-"But I defined the tunnel, and it came up, why do I have this error?"
-- ---------------------------------------------------------------------
-
-One of the most common causes of this error is failure to specify enough
-connection descriptions to cover all needed tunnels between any two 
-gateways and their respective subnets. As you have noticed, troubleshooting
-this error may be complicated by the use of IP Masq. However, this error is
-not limited to cases where IP Masq is used. 
-
-See doc/configuration.html#multitunnel for a detailed example of the 
-solution to this type of problem.
- -

The documentation section she refers to is now here.

- -

... trouble writing to /dev/ipsec ... SA already in -use

- -

This error message occurs when two manual connections are set up with the -same SPI value.

- -

See the FAQ for One manual connection works, but -second one fails.

- -

... ignoring ... payload

- -

This message is harmless. The IKE protocol provides for a number of -optional messages types:

- - -

An implementation is never required to send these, but they are allowed -to. The receiver is not required to do anything with them. FreeS/WAN ignores -them, but notifies you via the logs.

- -

For the "ignoring delete SA Payload" message, see also our discussion of -cleaning up dead tunnels.

- -

unknown parameter name "rightcert"

- -

This message can appear when you've upgraded an X.509-enabled -Linux FreeS/WAN with a vanilla Linux FreeS/WAN. To use your X.509 configs -you will need to overwrite the new install with -Super FreeS/WAN, or add the -X.509 patch by hand. -

- -

Why don't you restrict the mailing lists to reduce -spam?

- -

As a matter of policy, some of our mailing lists -need to be open to non-subscribers. Project management feel strongly that -maintaining this openness is more important than blocking spam.

- - -

This has been discussed several times at some length on the list. See the -list archives. Bringing the topic up again is -unlikely to be useful. Please don't. Or at the very least, please don't -without reading the archives and being certain that whatever you are about to -suggest has not yet been discussed.

- -

Project technical lead Henry Spencer summarised one discussion:

- -
- For the third and last time: this list *will* *not* do address-based - filtering. This is a policy decision, not an implementation problem. The - decision is final, and is not open to discussion. This needs to be - communicated better to people, and steps are being taken to do -that.
- -

Adding this FAQ section is one of the steps he refers to.

- -

You have various options other than just putting up with the spam, -filtering it yourself, or unsubscribing:

- - -

A number of tools are available to filter mail.

- - -

If you use your ISP's mail server rather than running your own, consider -suggesting to the ISP that they tag suspected spam as this ISP does. They -could just refuse mail from dubious sources, but that is tricky and runs some -risk of losing valuable mail or senselessly annoying senders and their -admins. However, they can safely tag and deliver dubious mail. The tags can -greatly assist your filtering.

- -

For information on tracking down spammers, see these HowTos, or the Sputum site. Sputum have a Linux -anti-spam screensaver available for download.

- -

Here is a more detailed message from Henry:

-
On Mon, 15 Jan 2001, Jay Vaughan wrote:
-> I know I'm flogging a dead horse here, but I'm curious as to the reasons for
-> an aversion for a subscriber-only mailing list?
-
-Once again:  for legal reasons, it is important that discussions of these
-things be held in a public place -- the list -- and we do not want to
-force people to subscribe to the list just to ask one question, because
-that may be more than merely inconvenient for them.  There are also real
-difficulties with people who are temporarily forced to use alternate
-addresses; that is precisely the time when they may be most in need of
-help, yet a subscribers-only policy shuts them out.
-
-These issues do not apply to most mailing lists, but for a list that is
-(necessarily) the primary user support route for a crypto package, they
-are very important.  This is *not* an ordinary mailing list; it has to
-function under awkward constraints that make various simplistic solutions
-inapplicable or undesirable. 
-
-> We're *ALL* sick of hearing about list management problems, not just you
-> old-timers, so why don't you DO SOMETHING EFFECTIVE ABOUT IT...
-
-Because it's a lot harder than it looks, and many existing "solutions"
-have problems when examined closely.
-
-> A suggestion for you, based on 10 years of experience with management of my
-> own mailing lists would be to use mailman, which includes pretty much every
-> feature under the sun that you guys need and want, plus some.  The URL for
-> mailman...
-
-I assure you, we're aware of mailman.  Along with a whole bunch of others,
-including some you almost certainly have never heard of (I hadn't!).
-
-> As for the argument that the list shouldn't be configured to enforce
-> subscription - I contend that it *SHOULD* AT LEAST require manual address
-> verification in order for posts to be redirected.
-
-You do realize, I hope, that interposing such a manual step might cause
-your government to decide that this is not truly a public forum, and thus
-you could go to jail if you don't get approval from them before mailing to
-it?  If you think this sounds irrational, your government is noted for
-making irrational decisions in this area; we can't assume that they will
-suddenly start being sensible.  See above about awkward constraints.  You
-may be willing to take the risk, but we can't, in good conscience, insist
-that all users with problems do so. 
-
-                                                          Henry Spencer
-                                                       henry@spsystems.net
- -

and a message on the topic from project leader John Gilmore:

-
Subject: Re: The linux-ipsec list's topic
-   Date: Sat, 30 Dec 2000
-   From: John Gilmore <gnu@toad.com>
-
-I'll post this single message, once only, in this discussion, and then
-not burden the list with any further off-topic messages.  I encourage
-everyone on the list to restrain themself from posting ANY off-topic
-messages to the linux-ipsec list.
-
-The topic of the linux-ipsec mailing list is the FreeS/WAN software.
-
-I frequently see "discussions about spam on a list" overwhelm the
-volume of "actual spam" on a list. BOTH kinds of messages are
-off-topic messages.  Twenty anti-spam messages take just as long to
-detect and discard as twenty spam messages.
-
-The Linux-ipsec list encourages on-topic messages from people who have
-not joined the list itself.  We will not censor messages to the list
-based on where they originate, or what return address they contain.
-In other words, non-subscribers ARE allowed to post, and this will not
-change.  My own valid contributions have been rejected out-of-hand by
-too many other mailing lists for me to want to impose that censorship
-on anybody else's contributions.  And every day I see the damage that
-anti-spam zeal is causing in many other ways; that zeal is far more
-damaging to the culture of the Internet than the nuisance of spam.
-
-In general, it is the responsibility of recipients to filter,
-prioritize, or otherwise manage the handling of email that comes to
-them.  It is not the responsibility of the rest of the Internet
-community to refrain from sending messages to recipients that they
-might not want to see.  If your software infrastructure for managing
-your incoming email is insufficient, then improve it.  If you think
-the signal-to-noise ratio on linux-ipsec is too poor, then please
-unsubscribe.  But don't further increase the noise by posting to the
-linux-ipsec list about those topics.
-
-        John Gilmore
-        founder & sponsor, FreeS/WAN project
- - -- cgit v1.2.3