In most situations, however, FreeS/WAN supports road warrior connections just fine.
@@ -721,7 +744,7 @@ . We hope this will go some distance toward creating a secure Internet, an environment where message privacy is the default. See our history and politics of cryptography section -for discussion +for discussion.Both systems pick up the authentication information they need from the DNS (domain name service), the service they already use to look up IP addresses. Of course the @@ -731,8 +754,9 @@ encrypt, and encrypt whatever they can. Whether they also accept unencrypted communication is a policy decision the administrator can make.
-A draft document giving most of the -details of how we plan to implement this is available.
+A draft document giving most of the details of how we plan to +implement this has been posted to the mailing list. See +links below.
Only one current product we know of implements a form of opportunistic encryption. Secure sendmail will automatically encrypt server-to-server mail transfers whenever possible.
@@ -873,8 +897,12 @@Any of those will have a list of other "munitions" mirrors.
The two archives use completely different search engines. You might -want to try both.
+ The two archives use completely different search engines. You might +want to try both. +More recently we have expanded to five lists, each with its own +archive. See details elsewhere in the +documentation.
More information on this and other mailing lists.
For distributions which do not include FreeS/WAN and are not Redhat -6.x (which we develop and test on), there is additional information in -our compatibility section.
+(which we develop and test on), there is additional information in our compatibility section.We would appreciate hearing of other distributions using FreeS/WAN.
We would appreciate hearing of other products using FreeS/WAN.
If you have not done this before, you will need to read the Kernel HowTo.
Most users should run the most stable available series of Linux -production kernels. At time of writing (February -2001), we recommend the 2.2 series for most users. The latest version -is 2.2.18.
+Many users can continue to run kernels from the 2.2 series of Linux +production kernels.
+At time of writing (June 2001), the latest version is 2.2.19. If +you are going to use a 2.2 kernel, we strongly recommend + upgrading to 2.2.19 since:
+ On the other hand, 2.4 has new firewalling code called
+ The new 2.4 series of kernels began in January 2001 and are currently
+(early June) at 2.4.5. FreeS/WAN is known to work on 2.4.5.
+ 2.4 has new firewalling code called
netfilter. This may provide good reasons to move to 2.4, especially
on for gateway machines. At time of writing (February 2001, shortly after the release of
-2.4), no more 2.3 kernels are being produced and the 2.5 series has not
-been started yet, so just now development kernels are not an issue. No
-doubt a 2.5 series will be started in the next few months. At time of writing, no more 2.3 kernels are being produced and the
+2.5 series has not been started yet, so just now development kernels
+are not an issue. No doubt a 2.5 series will be started in the next few
+months. Development kernels are not intended for production use
. They change often and include new code which has not yet been
thoroughly tested. This regularly breaks things, including
@@ -1472,7 +1515,7 @@
Of course any status information at this point should be
uninteresting since you have not yet configured connections. See the following section for information on
configuring connections. Alternately, you might want to look at background material on the
@@ -1965,14 +2008,6 @@
been removed in FreeS/WAN 1.9. However, if the other end of the tunnel
is an older version, the restriction will still apply there, so some
caution is still required. The conn %default section shipped in our example file
-includes parameters for manual keying. These are completely
- insecure, intended only for testing. We recommend you leave
-these in place during testing since it is sometimes useful to be able
-to test with manual keying. Once testing is done, however, delete the
-test keys or ensure that they are commented out with # characters.
-Production use of manual keying is not recommended, but is possible
-and is described in a later section. Edit our example connection to match what you want to do. Rename it
appropriately for the connection you would like to build:
@@ -2038,9 +2073,9 @@
The file syntax allows names to be used, but this creates an
additional risk. If someone can subvert the DNS service, then they can
redirect packets whose addresses are looked up via that service. Many of the variables in this file come in pairs such as
-"leftsubnet: and "rightsubnet", one for each end of the connection.
-The variables on the left side are: Many of the variables in this file come in pairs such as
+"leftsubnet: and "rightsubnet", one for each end of the connection. The
+variables on the left side are:2.0.x should still work
@@ -1182,10 +1225,10 @@
for use by kernel developers. By convention, production kernels have an
even second digit in the version number (2.0, 2.2, 2.4) and development
kernels have an odd digit there (2.1, 2.3, 2.5).
-Links to other sections
+Where to go from here
Editing a connection description
For some applications, you may want to create two connections, one to
protect traffic from the subnet behind left and another to protect
traffic from the left gateway itself. This takes two connection
- descriptions.
This section is currently just a placeholder for the opportunistic -encryption documentation I'll write when the design has solidified -somewhat.
-Release 1.4 had the first experimental code to support fetching -public key information from the other system's DNS entries. Even in -1.6, this is still experimental code. You cannot trust it for -production use until
-The relevant lines in the config file would look like this:
+ We use the term opportunistic encryption + for encryption which does not rely on any pre-arranged connection, +hence does not require that the administrators of the two gateways +involved communicate with each other (for example, to exchange keys) +before their systems can create a secure connection. +The idea is that each gateway check the destinations of outgoing +packets, see if an encrypted connection is possible and, if so, take +the opportuntity to encrypt. The opportunity will exist whenever the +admins on both ends have set their systems up for opportunistic +encryption.
+This makes encryption the default behaviour, and could greatly +increase the overall security of the Internet if it were widely enough +adopted. See our documents:
+The gateways must be able to authenticate each other for IPSEC to +be secure. For opportunistic encryption, we rely on the domain name +system, DNS, to provide the RSA keys needed +for this authentication. Note, that currently this is not entirely +secure because the DNS mechanism it relies on is not fully +secure. Eventually, as secure DNS becomes +widely deployed, this will change.
+The main documentation items so far are:
+Note that both software and documentation for this are changing +quickly. You may want the latest snapshot for opportunism experiments.
+We do not yet recommend this code for production use +. You should still protect your critical data with explicitly +configured IPSEC tunnels, rather than relying on opportunistic for +everything at this stage.
+Opportunism requires that the gateway systems be able to fetch +public keys, and other IPSEC-related information, from each other's DNS +(domain name service) records.
+DNS is a distributed database that maps names to IP addresses and +vice versa. A system named gateway.example.com with IP address +10.20.30.40 should have at least two DNS records:
+The capitalised strings after IN indicate the type of record. +Possible types include:
+There are two ways to handle this, depending on whether or not you +control the reverse lookup (in-addr.arpa.) sections of the DNS files +for your gateway. You must have control of the reverse DNS information +for clients or this cannot work at all.
++40.30.20.10.in-addr.arpa. IN KEY 0x4200 4 1 AQNJjkKlIk9...nYyUkKK8 ++ This allows lookups on the IP address of the gateway to retrieve the +key. +
A client that wishes to be protected by Opportunistic Encryption +must include a special TXT record in its reverse-map. If you control +the gateway's reverse map, example client records would look like this:
++42.42.42.10.in-addr.arpa. IN PTR deepthought.example.com. +42.42.42.10.in-addr.arpa. IN TXT "X-IPsec-Server(10)=10.20.30.40 AQNJjkKlIk9...nYyUkKK8" ++ which can also be written as just: +
+42.42.42.10.in-addr.arpa. IN PTR deepthought.example.com. + IN TXT "X-IPsec-Server(10)=10.20.30.40 AQNJjkKlIk9...nYyUkKK8" ++ This provides the IP address of the security gateway and the public +key which the gateway will use to authenticate itself. This is the +preferred variant. Using it, the remote system does one lookup and gets +everything it needs for IKE negotiations. +
However, suppose a friend over at example.org will let you put +things in their maps. That will allow you to set your gateway up to +handle opportunistic connections for which it is the initiator.
+You still need to be able to put data in the reverse map for your +clients. However, that data is slightly different:
++42.42.42.10.in-addr.arpa. IN PTR deepthought.example.com. + IN TXT "X-IPsec-Server(10)=something.example.org" ++ Over at example.org, your friend inserts these lines in the DNS data +files: +
+something.example.org. IN A 10.20.30.40 + IN KEY 0x4200 4 1 AQNJjkKlIk9...nYyUkKK8 ++ Your gateway must identify itself in IKE as something.example.org, not +as gateway.example.com. You set that up via leftid= or +rightid= entries in +ipsec.conf(5). +
With this arrangement, the remote gateway does two lookups. First +it does a reverse lookup on the client IP address and finds the gateway +name "something.example.org". Then it looks up that name to get the IP +address and key for the gateway.
+
leftid=@gateway.example.com
leftrsasigkey=%dns
@@ -2603,13 +2787,13 @@
Testing with tcpdump
To verify that all is working, run tcpdump(8) on a machine which
can listen to the traffic between the gateways.
- This really has to be done from a third machine, not from one of
-the gateways. On the gateways you'll see packets at intermediate stages
-of processing and the result will be confusing. Also, both tcpdump(8)
-and nmap(8) use the libpcap library. Some versions of that library
-(e.g. the ones that shipped with Redhat 5) do not recognise ipsec?
-devices and will generate "bad physical medium" error messages if you
-try to use it with them.
+ This is most easily done from a third machine, rather than from one
+of the gateways. On the gateways you may see packets at intermediate
+stages of processing and the result may be confusing.
+ If the results make no sense at all, or you see "bad physical
+medium" error messages, you probably have an outdated version of
+tcpdump(8) that does not handle IPSEC at all. See our
+FAQ.
The packets should, except for some of the header information, be
utterly unintelligible. The output of good encryption looks exactly
like random noise.
@@ -3085,12 +3269,12 @@
what type of software is sending the messages. If the settings are
"daemon.error" as in our example, then syslogd treats the messages as
error messages from a daemon.
-Note that Pluto does not currently pay
+
Note that Pluto does not currently pay
attention to this variable. The variable controls setup messages only.
"yes" is strongly recommended for production use so that the keying @@ -3227,6 +3411,47 @@ functionality. You cannot use them as gateways with a subnet behind them. To get that functionality, you must upgrade to Windows 2000 server or the commercially available PGP products.
++Subject: Re: linux-ipsec: IPSec packets not entering tunnel? + Date: Mon, 20 Nov 2000 + From: Justin Guyett <jfg@sonicity.com> + +On Mon, 20 Nov 2000, Claudia Schmeing wrote: + +> Right Left +> "home" "office" +> 10.92.10.0/24 ---- 24.93.85.110 ========= 216.175.164.91 ---- 10.91.10.24/24 +> +> I've created all four tunnels, and can ping to test each of them, +> *except* homegate-officenet. + +I keep wondering why people create all four tunnels. Why not route +traffic generated from home to 10.91.10.24/24 out ipsec0 with iproute2? +And 99% of the time you don't need to access "office" directly, which +means you can eliminate all but the subnet<->subnet connection. ++ and FreeS/WAN technical lead Henry Spencer's comment: +
+> I keep wondering why people create all four tunnels. Why not route +> traffic generated from home to 10.91.10.24/24 out ipsec0 with iproute2? + +This is feasible, given some iproute2 attention to source addresses, but +it isn't something we've documented yet... (partly because we're still +making some attempt to support 2.0.xx kernels, which can't do this, but +mostly because we haven't caught up with it yet). + +> And 99% of the time you don't need to access "office" directly, which +> means you can eliminate all but the subnet<->subnet connection. + +Correct in principle, but people will keep trying to ping to or from the +gateways during testing, and sometimes they want to run services on the +gateway machines too. + +
FreeS/WAN allows a single gateway machine to build tunnels to many others. There may, however, be some problems for large numbers as @@ -3534,31 +3759,46 @@
ipsec setup restart
Again, this breaks any existing connections.
Sometimes you will want to create a tunnel without encryption. The -IPSEC protocols provide two ways to do this, either using -AH without ESP or using ESP with null -encryption. With Linux FreeS/WAN, these are currently supported for -manually keyed connections, but not with automatic keying, so we'll -look at other solutions here.
+Sometimes you might want to create a tunnel without encryption. +Often this is a bad idea, even if you have some data which need not be +private. See this discussion.
+The IPSEC protocols provide two ways to do build such tunnels,
+ + Linux FreeS/WAN allows AH-only for manually keyed connections, but not +with automatic keying, and does not support null encryption, so we'll +look at other solutions here.One situation in which this comes up is when otherwise some data would be encrypted twice. Alice wants a secure tunnel from her machine to Bob's. Since she's behind one security gateway and he's behind another, part of the tunnel that they build passes through the tunnel that their site admins have built between the gateways. All of Alice and Bob's messages are encrypted twice.
-There are several ways to handle this.
+There are several ways to handle this.
Note that if Alice and Bob want end-to-end security, they must +build a tunnel end-to-end between their machines or use some other +end-to-end tool such as PGP or SSL that suits their data. The only +question is whether the admins build some special unencrypted tunnel +for those already-encrypted packets.
The various components of Linux FreeS/WAN are of course documented @@ -3802,16 +4042,20 @@ must allow UDP 500 and at least one of AH or ESP on the interface that communicates with the other gateway.
The preceeding paragraph deals with packets addressed to or sent -from your gateway. It is a separate policy decision whether to -permit such packets to pass through the gateway so that +
The preceeding paragraph deals with packets addressed to or +sent from your gateway. It is a separate policy decision whether +to permit such packets to pass through the gateway so that client machines can build end-to-end IPSEC tunnels of their own. This may not be practical if you are using NAT (IP masquerade) on your gateway, and may conflict with some corporate security policies. Other than that, it is likely a good idea.
+It is possible to use firewall rules to restrict UDP 500, ESP and AH - packets so that these packets are accepted only from known gateways. +
It is possible to use firewall rules to restrict UDP 500, ESP and +AH packets so that these packets are accepted only from known gateways. This is not strictly necessary since FreeS/WAN will discard packets from unknown gateways. You might, however, want to do it for any of a number of reasons. For example:
@@ -3857,7 +4101,7 @@ which can affect the operation of FreeS/WAN or of diagnostic tools commonly used with it. These are discussed below.ICMP is the Internet C +
ICMP is the Internet C ontrol Message Protocol. It is used for messages between IP implementations themselves, whereas IP used is used between the clients of those implementations. ICMP is, @@ -3969,9 +4213,15 @@ Here you have a choice of techniques depending on whether you want to make your client subnet visible to clients on the other end:
We recommend not trying to build IPSEC connections which pass @@ -4220,7 +4465,7 @@ # or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License # for more details. # -# RCSID $Id: firewall.html,v 1.10.2.3 2001/03/15 00:12:35 henry Exp $ +# RCSID $Id: firewall.html,v 1.16 2001/05/02 20:56:27 sandy Exp $ # check interface version case "$PLUTO_VERSION" in @@ -4311,7 +4556,7 @@ only to known receivers) -
Those scripts were based on David Ranch's scripts for his "Trinity OS" for setting up a secure Linux. Check his -home page for the latest version and for information on his +home page for the latest version and for information on his book on securing Linux. If you are going to base your firewalling on Ranch's scripts, we recommend using his latest version, and sending him any IPSEC modifications you make for incorporation into later @@ -4373,9 +4618,9 @@
Other man pages are on
@@ -4399,7 +4644,7 @@From a message posted to the mailing list Jan 14 2000 by Pluto +
From a message posted to the mailing list Jan 14 2000 by Pluto developer Hugh Redelmeier:
Until ipsec auto and whack/pluto get fixed: @@ -4423,6 +4668,33 @@ Various error messages from Pluto are discussed in the FAQ and the ipsec_pluto(8) man page. +Using GDB on Pluto
+ You may need to use the GNU degugger, gdb(1), on Pluto. This should be +necessary only in unusal cases, for example if you encounter a problem +which the Pluto developer cannot readily reproduce or if you are +modifying Pluto. +Here are the Pluto developer's suggestions for doing this:
++Can you get a core dump and use gdb to find out what Pluto was doing +when it died? + +To get a core dump, you will have to set dumpdir to point to a +suitable directory (see ipsec.conf(5)). + +To get gdb to tell you interesting stuff: + $ script + $ cd dump-directory-you-chose + $ gdb /usr/local/lib/ipsec/pluto core + (gdb) where + (gdb) quit + $ exit + +The resulting output will have been captured by the script command in +a file called "typescript". Send it to the list. + +Do not delete the core file. I may need to ask you to print out some +more relevant stuff. +ifconfig reports for KLIPS debugging
From a mail message from our KLIPS developer:
@@ -5041,7 +5313,7 @@man 8 ipsec_tncfgPluto key and connection management daemon
-Pluto is our key management and negotiation +
Pluto is our key management and negotiation daemon. It lives in the pluto directory, along with its low-level user utility, whack.
There are no subdirectories. Documentation is a man page, @@ -5101,11 +5373,11 @@ patchers and commenters there, especially the ones quoted below but also various contributors we haven't quoted.
Implemented parts of the IPSEC Specification
-In general, do not expect Linux FreeS/WAN to do everything yet. This -is a work-in-progress and some parts of the IPSEC specification are -not yet implemented.
+In general, do not expect Linux FreeS/WAN to do everything yet. +This is a work-in-progress and some parts of the IPSEC specification +are not yet implemented.
In Linux FreeS/WAN
-Things we do, as of version 1.9:
+Things we do, as of version 1.9:
All combinations of implemented transforms are supported. Note that -some form of authentication is recommended whenever encryption is used.
+some form of packet-level authentication is required whenever +encryption is used. Without it, the encryption will not be +secure.
Things we deliberately omit which are required in the RFCs are:
Since these are the only encryption algorithm and DH group the RFCs -require, it is possible in theory to have a standards-conforming +
Since these are the only encryption algorithms and DH group the +RFCs require, it is possible in theory to have a standards-conforming implementation which will not interpoperate with FreeS/WAN. Such an implementation would be inherently insecure, so we do not consider this a problem. Anyway, most implementations sensibly include more secure -options as well, so dropping single DES and Group 1 does not greatly -hinder interoperation in practice.
+options as well, so dropping null encryption, single DES and Group 1 +does not greatly hinder interoperation in practice.We also do not implement some optional features allowed by the RFCs:
Things we don't yet do, as of version 1.9:
+Things we don't yet do, as of version 1.91:
We expect eventually to do it using DNS. The newer versions of BIND provide much of what we need but they are not yet widespread and our code to communicate with them is not ready.
+Update: As of 1.91, we have beta-testable code for +opportunistic encryption. See our configuration +document.
No optional additional authentication transforms are currently implemented and we do not forsee a need to add any soon.
+To fully comply with the RFCs, it is not enough just to accept only +packets which survive any firewall rules in place to limit what IPSEC +packets get in, and then pass KLIPS authentication. That is what +FreeS/WAN currently does.
+We should also apply additional tests, for example ensuring that +all packets emerging from a particular tunnel have sourcen and +destination addresses that fall within the subnets defined for that +tunnel, and that packets with those addresses that did not emerge from +the appropriate tunnel are disallowed.
+This will be done as part of the KLIPS rewrite currently in +progress. See these links and the + design mailing list for discussion.
We use PF-key Version Two for communication between the KLIPS kernel code and the Pluto Daemon. PF-Key v2 is defined by @@ -5270,34 +5557,37 @@ not yet doing much upward communication from kernel to user space. This will change, but is not at the top of our priority list.
PF-Key came out of Berkeley Unix work and is used in the various BSD -IPSEC implementations. We assume also in This means there is some hope -of porting our Pluto(8) to one of the BSD distributions or running -their photurisd(8) on Linux if you prefer Photuris - key management over IKE.
-It is, however, more complex than that. The three PF-Key -implementations we have looked at -- ours, OpenBSD and KAME -- all -have extensions beyond the RFC, and the extensions are different. -There have been discussions aimed at sorting out the differences, -perhaps for a version three PF-Key spec. All players are in favour of -this, but everyone involved is busy and it is not clear whether or -when these discussions might bear fruit.
+PF-Key came out of Berkeley Unix work and is used in the various +BSD IPSEC implementations, and in Solaris. This means there is some +hope of porting our Pluto(8) to one of the BSD distributions, or of +running their photurisd(8) on Linux if you prefer +Photuris key management over IKE.
+It is, however, more complex than that. The PK-Key RFC deliberately +deals only with keying, not policy management. The three PF-Key +implementations we have looked at -- ours, OpenBSD and KAME -- all have +extensions to deal with security policy, and the extensions are +different. There have been discussions aimed at sorting out the +differences, perhaps for a version three PF-Key spec. All players are +in favour of this, but everyone involved is busy and it is not clear +whether or when these discussions might bear fruit.
We develop and test on:
+We develop and test on:
This is what we recommend.
Consider upgrading to the 2.2 kernel series. If you want to stay -with the 2.0 series, then we strongly recommend 2.0.38. It has some -security patches not present in earlier 2.0 kernels.
+with the 2.0 series, then we strongly recommend 2.0.39. Some useful +security patches were added in 2.0.38.Various versions of the code have run at various times on most -2.0.xx kernels, but the current version is tested only on 2.0.38 and is -unlikely to compile on older kernels. Some of our patches for older -kernels are shipped in 2.0.37 and later, so they are no longer provided -in FreeS/WAN.
+2.0.xx kernels, but the current version is only lightly tested on +2.0.39, and not at all on older kernels. +Some of our patches for older kernels are shipped in 2.0.37 and +later, so they are no longer provided in FreeS/WAN. This means recent +versions of FreeS/WAN will probably not compile om anything earlier +than 2.0.37.
We suggest the latest 2.2 kernel (2.2.18 at time of writing) for -production use.
-We develop and test on Redhat 5.2 for 2.0 kernels, and on Redhat -6.1 for 2.2, so minor changes may be required for other distributions.
+We suggest the latest 2.2 kernel or 2.4 (2.2.19 or 2.4.5 at time of +writing) for production use.
+We develop and test on Redhat 6.1 for 2.2 kernels, and on Redhat +7.1 for 2.4, so minor changes may be required for other distributions.
There are some problems with FreeS/WAN on Redhat 7.0, but they are soluble.
@@ -5353,8 +5642,8 @@ Check the mailing list archive for more recent news.SuSE 6.3 and later versions, at least in Europe, ship with FreeS/WAN - included.
+SuSE 6.3 and later versions, at least in Europe, ship with +FreeS/WAN included.
Here are some notes for an earlier SuSE version.
Date: Mon, 30 Nov 1998 @@ -5697,9 +5986,8 @@ made, but at time of writing (February 2001), the job is not complete. For more recent information, check the mailing list . -In short, Linux currently has both IPv6 support and IPSEC support, -but the two do not work together yet. We, and others, -are working on integrating them, but it is a substantial job.
+The first release of Linux IPv6 with FreeS/WAN support is now + available.
IPv6 background
IPv6 has been specified by an IETF working group. The group's page lists over 30 RFCs to date, and @@ -5788,40 +6076,50 @@ those formats. See this list of patches and add-ons .
Interoperability problems
-The IPSEC RFCs are complex and include a number of optional +
The IPSEC RFCs are complex and include a number of optional features. There is considerable opportunity for even two correct, standard-conforming, implementations to disagree on details in a way that blocks interoperation. Of course, misinterpretations of the standards and implementation or configuration errors on either end can also foul things up.
That said, FreeS/WAN interoperates successfully with many other - implementations. There is a list in another - section.
+ implementations. There is a list below.Known areas where problems may appear are:
In practice, it is sometimes a problem. Some implementations -default to aggressive mode unless you configure them for main mode.
-In principle this should not be a problem since main mode support +is required in all implementations and aggressive mode is optional. + In practice, it is sometimes a problem. Some implementations default +to aggressive mode unless you configure them for main mode.
+You can turn PFS off in FreeS/WAN with the pfs=no setting in ipsec.conf(5), but if possible we suggest you enable it on the other end instead. That is more secure.
+The general rule is that to interoperate with FreeS/WAN, the other implementation should be configured for:
@@ -5831,34 +6129,39 @@This is possible for most implementations.
-Linux FreeS/WAN does not support DES transforms. Neither Pluto's -IKE connections nor KLIPS' IPSEC connections can use DES. Since -DES is insecure we do not, and will not at any future time, provide -it.
+Linux FreeS/WAN does not support single DES transforms. Neither +Pluto's IKE connections nor KLIPS' IPSEC connections can use DES. Since DES is insecure we do not, and will not at any +future time, provide it.
DES is, unfortunately, a mandatory part of the IPSEC standard. Despite that, we will not implement DES. We believe it is more important to provide security than to comply with a standard -which has been subverted into allowing weak algorithms. See our -history and politics section for discussion.
-Some implementations may offer DES as the default. In such cases we +which has been subverted into allowing weak +algorithms. See our history and politics + section for discussion.
+Some implementations may offer DES as the default. In such cases we urge you to change them to Triple DES. If this is not possible, for example because export laws prevent your vendor from offerring you adequate crytography, we urge -you to complain vigorously to
+you to complain vigorously to one or more of:In the meanwhile, use FreeS/WAN to get strong crypto until the laws -are fixed.
+Consider using FreeS/WAN instead. PCs are cheap and we deliver 3DES +now.
FreeS/WAN does have DES code in it as a sort of historical accident, since we need it to implement our default (currently, our only) block cipher, Triple DES. However, since DES is insecure, we do not -provide any interface to that code and, as a matter of policy, will -provide no help to anyone who may wish to use it.
+provide any interface to that code. +As a matter of project policy, we will not help anyone subvert +FreeS/WAN to provide insecure DES encryption +.
The FreeS/WAN team does not have the resources to test with
anything like the full range of other IPSEC
@@ -6023,7 +6326,7 @@
I've attached some ipsec barf output - pluto still complains a few times,
but it gets there :-)
- A later message from Ian: A later message from Ian: Some messages from the mailing list:
This configuration is provided as-is and with no assistance or guarantee
that it works whatsover. In particular your attention is drawn to the versions
@@ -6101,6 +6404,19 @@
| 7500 Series
Nortel (Bay Networks) Contivity switch
+ There is one known issue in FreeS/WAN-to-Contivity interoperation.
+Recent versions of FreeS/WAN no longer support DH group 1 for key
+exchange. Older versions of Contivity software support nothing else.
+Group 2 was added in more recent releases. So:
+
+
+ We recommend using the latest Contivity release.
+
Subject: Contivity Extranet Switch
Date: Fri, 11 Jun 1999
@@ -6507,6 +6823,13 @@
HowTo for connecting FreeS/WAN and this product can be downloaded
from the vendor's site or browsed at a VPN mailing list
site.
Subject: linux-ipsec: Identification through other than IP number
Date: Tue, 13 Apr 1999
@@ -7140,8 +7463,9 @@
of both domains or consider setting up WINS service(s).
We suspect that in some cases it may be more complex than that. See
-the discussion of Linux services and Windows 2000 below
-.
+the discussion of Linux services and Windows 2000
+ below and the Interop HowTo documents listed
+above.
Windows 2000 ships with an IPSEC implementation built in. There may be restrictions. We have had mailing list reports that only the server @@ -7211,16 +7535,9 @@ http://www.sandelman.ottawa.on.ca/linux-ipsec/html/2001/02/msg00195.html
As for IPSEC interoperation between Windows 2000 and FreeS/WAN, -there are some web sites:
-As for IPSEC interoperation between Windows 2000 and FreeS/WAN, +there are several web sites listed under Interop +HowTo documents above.
Here is a discussion from the mailing list:
From: "Jean-Francois Nadeau" <jna@microflex.ca> Subject: Win2000 IPsec interop. in tunnel mode @@ -7358,19 +7675,18 @@ general-purpose digital computers.
So by the end of the war, Allied code-breakers were expert at large-scale mechanised code-breaking. The payoffs were enormous.
America's NSA, for example, is said to be both @@ -7391,7 +7707,7 @@ electronic mail, or tapping into the huge volumes of data on new media such as fiber optics or satellite links. None of these targets existed in 1950. All of them can be attacked today, and almost certainly are -being attacked on a large scale.
+being attacked.The Ultra story was not made public until the 1970s. Much of the recent history of codes and code-breaking has not been made public, and some of it may never be. Two important books are:
@@ -7423,20 +7739,26 @@ networking becoming ubiquitous, cryptography is now important to almost everyone. Among the developments since the 1970s:This has led to a complex ongoing battle between various mainly government groups wanting to control the spread of crypto and various @@ -7497,14 +7819,20 @@ communication systems, but that it is an activity of the investigative authorities and intelligence services of many countries with governments of different political signature. Even if -they have nothing on the scale of Echelon, most or all intelligence -agencies and police forces certainly have some interception -capability. +they have nothing on the scale of Echelon, most intelligence agencies +and police forces certainly have some interception capability. +
-Mary had cryptography -Her keys were in escrow -And everything that Mary said -The feds were sure to know + Mary had cryptography + Her keys were in escrow + And everything that Mary said + The feds were sure to know+ (If anyone knows the origin of that ditty, let +let me know so I can credit the author.)
There is an excellent paper available on Risks of Escrowed Encryption, from a group of cryptographic luminaries which included our project leader.
@@ -7916,14 +8248,18 @@FreeS/WAN does not support escrowed encryption, and never will.
Various governments, and some vendors, have also made persistent -attempts to convince people that weak systems are sufficient for some -data, that strong cryptography should be reserved for cases where the -extra overheads are justified. This is nonsense.
+attempts to convince people that: +Weak systems touted include:
For example, suppose public key operations use use 1% of the time +in a hybrid system and you triple the cost of public key operations. +The cost of symmetric cipher operations is unchanged at 99% of the +original total cost, so the overall effect is a jump from 99 + 1 = 100 +to 99 + 3 = 102, a 2% rise in system cost.
In short, there has never been any technical reason to use inadequate ciphers. The only reason there has ever been for @@ -8634,7 +8972,7 @@ Multicast is not yet supported, though there are Internet Draft documents for that.
IPSEC creates secure tunnels through untrusted networks -. Sites connected by these tunnels form VPNs, Virtual +. Sites connected by these tunnels form VPNs, Virtual Private Networks.
IPSEC gateways can be installed wherever they are required.
Where appropriate, IPSEC can provide authentication without +
Where appropriate, IPSEC can provide authentication without encryption. One might do this, for example:
Authentication has lower overheads than encryption.
+The protocols provide four ways to build such connections, using +either an AH-only connection or ESP using null encryption, and in +either manually or automatically keyed mode. FreeS/WAN supports only +one of these, manually keyed AH-only connections, and we do not +recommend using that. Our reasons are discussed under +Resisting traffic analysis a few sections further along.
Originally, the IPSEC encryption protocol ESP @@ -8712,7 +9056,7 @@
Other variants are allowed by the standard, but not much used:
+Other variants are allowed by the standard, but not much used:
There are fairly frequent suggestions that AH be dropped entirely + Some of these variants cannot be used with FreeS/WAN because we do not +support ESP-null and do not support automatic keying of AH-only +connections. +
There are fairly frequent suggestions that AH be dropped entirely from the IPSEC specifications since ESP and null encryption can handle that situation. It is not clear whether this will occur. My guess is that it is unlikely.
@@ -8770,13 +9114,12 @@ useful intelligence from encrypted traffic without breaking the encryption. For example, an eavesdropper might deduce something interesting merely by knowing that your CEO was exchanging email with a -particular venture capital firm. Or that all the CEO's mail this week -went to a firm of bankruptcy trustees and a half dozen executive -recruiting agencies. +particular venture capital firm, or that the CEO was talking to a firm +of bankruptcy trustees and a half dozen executive recruiting agencies.Except in the simplest cases, traffic analysis is hard to do well. It requires both considerable resources and considerable analytic skill. However, intelligence agencies of various nations have been -doing it for centuries and most of them are likely quite good at it by +doing it for centuries and many of them are likely quite good at it by now. Various commercial organisations, especially those working on "targeted marketing" may also be quite good at analysing certain types of traffic.
@@ -9206,13 +9549,10 @@ may choose to support additional algorithms in either category.The authentication algorithms are the same ones used in the IPSEC authentication header.
-We do not implement single DES since DES is - insecure. Instead we provide triple DES or 3DES +
We do not implement single DES since DES is +insecure. Instead we provide triple DES or 3DES . This is currently the only encryption algorithm supported.
-We do implement null encryption, but it is disabled by default. You -can enable it in the IPSEC part of kernel configuration if required. -We would suggest, however, that if you need only authentication, you -should use AH rather than ESP with null encryption.
+We do not implement null encryption since it is obviously insecure.
IPSEC can connect in two modes. Transport mode is a host-to-host connection involving only two machines. In tunnel mode, the IPSEC @@ -9273,11 +9613,11 @@ are stored with the connection definitions in /etc/ipsec.conf.
Manual keying is useful for debugging since it allows you to test the KLIPS kernel IPSEC code -without the Pluto daemon doing key negotiation.
+without the Pluto daemon doing key negotiation.In general, however, automatic keying is preferred because it is more secure.
In automatic keying, the Pluto daemon +
In automatic keying, the Pluto daemon negotiates keys using the IKE Internet Key Exchange protocol. Connections are automatically re-keyed periodically.
This is considerably more secure than manual keying. In either case @@ -9289,7 +9629,7 @@ two admins make changes. Moreover, they have to communicate the new keys securely, perhaps with PGP or SSH . This may be possible in some cases, but as a general solution it is -expensive, bothersome and unreliable. Far better to let +expensive, bothersome and unreliable. Far better to let Pluto handle these chores; no doubt the administrators have enough to do.
Also, automatic keying is inherently more secure against an attacker @@ -9359,7 +9699,7 @@ Linux FreeS/WAN might be a good project for a volunteer. The likely starting point would be the OpenBSD photurisd code.
SKIP is yet another key management protocol, +
SKIP is yet another key management protocol, developed by Sun. At one point it was fairly widely used, but our current impression is that it is moribund, displaced by IKE. Sun now (as of Solaris 8.0) ship an IPSEC implementation using IKE. We have no @@ -9379,7 +9719,8 @@
Archives of these lists are available via the +web interface.
Note that these use different search engines. Try both.
+Note that these use different search engines. Try both.
+Archives of the new lists are available via the +web interface.
There are several other lists related to FreeS/WAN:
Before using these, check the mailing list for news of newer versions and to see whether they have been incorporated into more recent versions of FreeS/WAN.
+Note: At one point the way PGP generates RSA keys +and the way FreeS/WAN checks them for validity before using them were +slightly different, so quite a few PGP-generated keys would be rejected +by FreeS/WAN, confusing users no end. This is fixed in 1.9.
A set of PKIX patches were recently announced on the mailing list:
Subject: a different PKIX patch. @@ -9612,6 +9976,8 @@
These patches are for older versions of FreeS/WAN and will likely not work with the current version. Older versions of FreeS/WAN may be @@ -9665,7 +10031,7 @@
Vendors using FreeS/WAN in turnkey firewall or VPN products are -listed in our introduction.
+listed in our introduction.Other vendors have Linux IPSEC products which, as far as we know, do not use FreeS/WAN
For more information, see the
NIST AES home page or the
Block Cipher Lounge AES page. For code and benchmarks see
@@ -10811,7 +11177,7 @@
and a fragment carries information on where it starts within that 64K
and how long it is. The "ping of death" delivers fragments that say,
for example, that they start at 60K and are 20K long. Attempting to
-re-assemble thse without checking for overflow can be fatal.
+re-assemble these without checking for overflow can be fatal.
The two example attacks discussed were both quite effective when
@@ -11211,9 +11577,8 @@
come from one IP address, that of its Internet interface. It then gets
all the replies, does some table lookups and more header rewriting,
and delivers the replies to the appropriate client machines. To use masquerade with Linux FreeS/WAN, you must set
- leftfirewall=yes and/or rightfirewall=yes in the connection
- description in /etc/ipsec.conf. For information on using masquerade with Linux FreeS/WAN, see our
+ firewall document and the FAQ and.
NOTE: US citizens or residents are asked not to post code - to the list, not even one-line bug fixes. The project cannot - accept code which might entangle it in US export restrictions.
-For more detail, see our document on this and other -mailing lists.
+Setting up for opportunistic encryption is described in our + configuration document.
FreeS/WAN has been tested on multiprocessor Intel Linux and worked there. Note, however, that we do not test this often and have never -tested on multiprocessor machines of other architectures.
+tested on multiprocessor machines of other architectures. + +Released versions of FreeS/WAN generally run on whatever production +kernels were current at the time of the release. For example, FreeS/WAN +1.91 runs on kernel 2.2.19 or 2.4.5. Often they will run on slightly +earlier or later kernels as well, but we test on the current production +kernels, so those are strongly recommended.
+The kernel is under active development and it is not uncommon for +changes to appear that cause problems for FreeS/WAN. For example, 2.4.6 +or 2.4.7 may have changes that break FreeS/WAN 1.91. Or not; you can't +tell in advance. 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 top 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 todo list. In the +meanwhile, you have two choices: either stick with a slightly older +kernel, or fix the problem yourself and send us a patch.
+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 (when they appear) the 2.5 series of development kernels. We'd +rather work on developing the FreeS/WAN code than on chasing these +moving targets.
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.
For more information and the latest version, see the GMP home page.
++> 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. +
See also this mailing list message.
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
@@ -12880,7 +13310,7 @@
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
+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
@@ -12962,6 +13392,77 @@
Note that nothing on either subnet needs to change. This lets you
test most of your IPSEC setup before connecting to the insecure
Internet. Here is a mailing list message with more detail. It is often useful in debugging to test things one at a time: Other possibilities: One common configuration error is forgetting that you need
+auto=add to load the connection description on the receiving end
+so it recognises the connection when the other end asks for it. Some possibile problems are discussed in out
+interoperation document.
+ Here is one of Claudia's messages on the topic: From Pluto programmer Hugh Redelmeier: The match involves the left, right,
-leftsubnet and rightsubnet parameters and 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. 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>
@@ -13185,13 +13722,91 @@
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.
Here is one of Claudia's messages explaining the problem: See also Connection names in Pluto error
+messages. Another FAQ section describes how to deal with
- systems that attempt to use single DES. Our interoperation document has suggestions for
+ how to deal with systems that attempt to use single DES. For the "ignoring delete SA Payload" message, see also the
+discussion below of cleaning up dead tunnels. A mailing list message on the topic from Pluto developer Hugh
+Redelmeier: Another useful command here is 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.
+
+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
@@ -13010,13 +13511,18 @@
UDP port 500 packets used in key negotiation.
-
IPSEC works, but connections using compression fail
@@ -13110,6 +13616,37 @@
Since the above message was written, we have modified the updown
script to provide a better diagnostic for this problem. Check
/var/log/messages.
+ipsec_setup: Fatal error, kernel appears to lack
+KLIPS
+ This message indicates an installation failure. The kernel you are
+running does not contain the KLIPS (kernel IPSEC) code.
+
+> 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.
+
Connection names in Pluto error messages
@@ -13152,11 +13689,11 @@
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.
-
+Pluto: ... no suitable connection ...
+ This is similar to the no connection known
+ error, but occurs at a different point in Pluto processing.
+
+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.
+
+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.
- 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
@@ -13204,7 +13819,7 @@
FreeS/WAN does not support that. (see below for
DES problems)
- A more detailed explanation, from Pluto programmer Hugh Redelmaier:
+ A more detailed explanation, from Pluto programmer Hugh Redelmeier:
Background:
@@ -13375,6 +13990,54 @@
This problem is also discussed in this FAQ under the heading
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.
+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.
+
+| 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.
+
Can I ...
Can I reload connection info without restarting?
@@ -13403,6 +14066,8 @@
There may be more bits to look for, depending on what you are trying
to do.
+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
@@ -13482,24 +14147,27 @@
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 only two solutions to this problem.
+There are several solutions to this problem.
Copying the TOS information from the encapsulated packet to the +outer header reveals the TOS information to an eavesdropper. It is not +clear whether or how an attacker could use this information, but since +we do not have to give it to him, our default is not to.
+See ipsec.conf(5) for +more on the hidetos= parameter.
+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 ++
+> 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. ++
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.
-I have to talk to .... which offers only DES. How do I do this?
- Ask the device vendor for the triple DES upgrade.
-These exist for many IPSEC devices. If no cipher stronger than DES is
-available, we recommend you not use that IPSEC implementation.
-
If a 3DES implementation exists but your vendor cannot sell it to -you because of export laws, consider complaining to one or more of:
-Consider using FreeS/WAN instead. PCs are cheap and we deliver 3DES -now.
-As a matter of project policy, we will not help anyone subvert -FreeS/WAN to provide insecure DES encryption -.
-If you want to interoperate with an IPSEC implementation which +offers only DES, see our interoperation document.
+As a matter of policy, the list needs to be open to -non-subscribers. Project management feel strongly that maintaining this -openness is more important than blocking 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, @@ -13621,10 +14420,19 @@ 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 -or unsubscribing:
+You have various options other than just putting up with the spam, +filtering it yourself, or unsubscribing:
For information on tracking down spammers, see these HowTos, or the Sputum - site.
+ 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:
@@ -13739,5 +14548,5 @@
John Gilmore
founder sponsor, FreeS/WAN project
-