From aaa0331ecf95ced1e913ac9be50168cf0e7cbb82 Mon Sep 17 00:00:00 2001 From: Rene Mayrhofer Date: Tue, 30 Jan 2007 12:21:07 +0000 Subject: [svn-upgrade] Integrating new upstream version, strongswan (2.8.2) --- doc/faq.html | 2339 ---------------------------------------------------------- 1 file changed, 2339 deletions(-) delete mode 100644 doc/faq.html (limited to 'doc/faq.html') diff --git a/doc/faq.html b/doc/faq.html deleted file mode 100644 index b0fed502e..000000000 --- a/doc/faq.html +++ /dev/null @@ -1,2339 +0,0 @@ - - - -Introduction to FreeS/WAN - - - - -Contents -Previous -Next -
-

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 Q -uick 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
-
-Contents -Previous -Next - - -- cgit v1.2.3