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

Other configuration possibilities

- -

This document describes various options for FreeS/WAN configuration which -are less used or more complex (often both) than the standard cases described -in our config and -quickstart documents.

- -

Some rules of thumb about configuration

- -

Tunnels are cheap

- -

Nearly all of the overhead in IPsec processing is in the encryption and -authentication of packets. Our performance -document discusses these overheads.

- -

Beside those overheads, the cost of managing additional tunnels is -trivial. Whether your gateway supports one tunnel or ten just does not -matter. A hundred might be a problem; there is a section on this in the performance -document.

- -

So, in nearly all cases, if using multiple tunnels gives you a reasonable -way to describe what you need to do, you should describe it that way in your -configuration files.

- -

For example, one user recently asked on a mailing list about this network -configuration:

-
        netA---gwA---gwB---netB
-                            |----netC
-
-   netA and B are secured netC not.
-   netA and gwA can not access netC
- -

The user had constructed only one tunnel, netA to netB, and wanted to know -how to use ip-route to get netC packets into it. This is entirely -unnecessary. One of the replies was:

-
  The simplest way and indeed the right way to
-  solve this problem is to set up two connections:
-
-        leftsubnet=NetA
-        left=gwA
-        right=gwB
-        rightsubnet=NetB
-  and
-        leftsubnet=NetA
-        left=gwA
-        right=gwB
-        rightsubnet=NetC
- -

This would still be correct even if we added nets D, E, F, -... to the above diagram and needed twenty tunnels.

- -

Of course another possibility would be to just use one tunnel, with a -subnet mask that includes both netB and netC (or B, C, D, ...). See next -section.

- -

In general, you can construct as many tunnels as you need. Networks like -netC in this example that do not connect directly to the gateway are fine, as -long as the gateway can route to them.

- -

The number of tunnels can become an issue if it reaches 50 or so. This is -discussed in the performance document. -Look there for information on supporting hundreds of Road Warriors from one -gateway.

- -

If you find yourself with too many tunnels for some reason like having -eight subnets at one location and nine at another so you end up with -9*8=72 tunnels, read the next section here.

- -

Subnet sizes

- -

The subnets used in leftsubnet and rightsubnet can -be of any size that fits your needs, and they need not correspond to physical -networks.

- -

You adjust the size by changing the subnet -mask, the number after the slash in the subnet description. For -example

- - -

As an example of using these in connection descriptions, suppose your -company's head office has four physical networks using the address ranges:

-
-
192.168.100.0/24
-
development
-
192.168.101.0/24
-
production
-
192.168.102.0/24
-
marketing
-
192.168.103.0/24
-
administration
-
- -

You can use exactly those subnets in your connection descriptions, or use -larger subnets to grant broad access if required:

-
-
leftsubnet=192.168.100.0/24
-
remote hosts can access only development
-
leftsubnet=192.168.100.0/23
-
remote hosts can access development or production
-
leftsubnet=192.168.102.0/23
-
remote hosts can access marketing or administration
-
leftsubnet=192.168.100.0/22
-
remote hosts can access any of the four departments
-
- -

or use smaller subnets to restrict access:

-
-
leftsubnet=192.168.103.0/24
-
remote hosts can access any machine in administration
-
leftsubnet=192.168.103.64/28
-
remote hosts can access only certain machines in administration.
-
leftsubnet=192.168.103.42/32
-
remote hosts can access only one particular machine in - administration
-
- -

To be exact, 192.68.103.64/28 means all addresses whose top 28 bits match -192.168.103.64. There are 16 of these because there are 16 possibilities for -the remainingg 4 bits. Their addresses are 192.168.103.64 to -192.168.103.79.

- -

Each connection description can use a different subnet if required.

- -

It is possible to use all the examples above on the same FreeS/WAN -gateway, each in a different connection description, perhaps for different -classes of user or for different remote offices.

- -

It is also possible to have multiple tunnels using different -leftsubnet descriptions with the same right. For -example, when the marketing manager is on the road he or she might have -access to:

-
-
leftsubnet=192.168.102.0/24
-
all machines in marketing
-
192.168.101.32/29
-
some machines in production
-
leftsubnet=192.168.103.42/32
-
one particular machine in administration
-
- -

This takes three tunnels, but tunnels are cheap. If the laptop is set up -to build all three tunnels automatically, then he or she can access all these -machines concurrently, perhaps from different windows.

- -

Other network layouts

- -

Here is the usual network picture for a site-to-site VPN::

-
     Sunset==========West------------------East=========Sunrise
-           local net       untrusted net       local net
- -

and for the Road Warrior::

-
                                           telecommuter's PC or
-                                           traveller's laptop
-     Sunset==========West------------------East
-         corporate LAN     untrusted net
- -

Other configurations are also possible.

- -

The Internet as a big subnet

- -

A telecommuter might have:

-
     Sunset==========West------------------East ================= firewall --- the Internet
-         home network      untrusted net        corporate network
- -

This can be described as a special case of the general subnet-to-subnet -connection. The subnet on the right is 0.0.0.0/0, the whole Internet.

- -

West (the home gateway) can have its firewall rules set up so that only -IPsec packets to East are allowed out. It will then behave as if its only -connection to the world was a wire to East.

- -

When machines on the home network need to reach the Internet, they do so -via the tunnel, East and the corporate firewall. From the viewpoint of the -Internet (perhaps of some EvilDoer trying to break in!), those home office -machines are behind the firewall and protected by it.

- -

Wireless

- -

Another possible configuration comes up when you do not trust the local -network, either because you have very high security standards or because your -are using easily-intercepted wireless signals.

- -

Some wireless networks have built-in encryption called WEP, but its security is dubious. It is a fairly -common practice to use IPsec instead.

- -

In this case, part of your network may look like this:

-
          West-----------------------------East == the rest of your network
-     workstation   untrusted wireless net
- -

Of course, there would likely be several wireless workstations, each with -its own IPsec tunnel to the East gateway.

- -

The connection descriptions look much like Road Warrior descriptions:

- - -

The rightsubnet= parameter might be set in any of several -ways:

-
-
rightsubnet=0.0.0.0/0
-
allowing workstations to access the entire Internet (see above)
-
rightsubnet=a.b.c.0/24
-
allowing access to your entire local network
-
rightsubnet=a.b.c.d/32
-
restricting the workstation to connecting to a particular server
-
- -

Of course you can mix and match these as required. For example, a -university might allow faculty full Internet access while letting student -laptops connect only to a group of lab machines.

- -

Choosing connection types

- -

One choice you need to make before configuring additional connections is -what type or types of connections you will use. There are several options, -and you can use more than one concurrently.

- -

Manual vs. automatic keying

- -

IPsec allows two types of connections, with manual or automatic keying. -FreeS/WAN starts them with commands such as:

-
        ipsec manual --up name
-        ipsec auto --up name
- -

The difference is in how they are keyed.

-
-
Manually keyed connections
-
use keys stored in ipsec.conf.
-
Automatically keyed connections
-
use keys automatically generated by the Pluto key negotiation daemon. - The key negotiation protocol, IKE, must - authenticate the other system. (It is vulnerable to a man-in-the-middle attack if used - without authentication.) We currently support two authentication - methods: - -

A third method, using RSA keys embedded in X.509 certtificates, is provided by - user patches.

-
-
- -

Manually keyed connections provide -weaker security than automatically keyed -connections. An opponent who reads ipsec.secrets(5) gets your encryption key -and can read all data encrypted by it. If he or she has an archive of old -messages, all of them back to your last key change are also readable.

- -

With automatically-(re)-keyed connections, an opponent who reads -ipsec.secrets(5) gets the key used to authenticate your system in IKE -- the -shared secret or your private key, depending what authentication mechanism is -in use. However, he or she does not automatically gain access to any -encryption keys or any data.

- -

An attacker who has your authentication key can mount a man-in-the-middle attack and, if that -succeeds, he or she will get encryption keys and data. This is a serious -danger, but it is better than having the attacker read everyting as soon as -he or she breaks into ipsec.secrets(5).. Moreover, the keys change often so -an opponent who gets one key does not get a large amount of data. To read all -your data, he or she would have to do a man-in-the-middle attack at every key -change.

- -

We discuss using manual keying in production below, -but this is not recommended except in special circumstances, -such as needing to communicate with some implementation that offers no -auto-keyed mode compatible with FreeS/WAN.

- -

Manual keying may also be useful for testing. There is some discussion of -this in our FAQ.

- -

Authentication methods for auto-keying

- -

The IKE protocol which Pluto uses to negotiate connections between -gateways must use some form of authentication of peers. A gateway must know -who it is talking to before it can create a secure connection. We support two -basic methods for this authentication:

- - -

There are, howver, several variations on the RSA theme, using different -methods of managing the RSA keys:

- - -

Public keys in ipsec.conf(5) -give a reasonably straightforward method of specifying keys for explicitly -configured connections.

- -

Putting public keys in DNS allows us to support opportunistic encryption. Any two -FreeS/WAN gateways can provide secure communication, without either of them -having any preset information about the other.

- -

X.509 certificates may be required to interface to various PKIs.

- -

Advantages of public key methods

- -

Authentication with a public key method -such as RSA has some important advantages -over using shared secrets.

- - -

There is also a disadvantage:

- - -

This is partly counterbalanced by the fact that the key is never -transmitted and remains under your control at all times. It is likely -necessary, however, to take account of this in setting security policy. For -example, you should change gateway keys when an administrator leaves the -company, and should change them periodically in any case.

- -

Overall, public key methods are more secure, more easily managed -and more flexible. We recommend that they be used for all -connections, unless there is a compelling reason to do otherwise.

- -

Using shared secrets in production

- -

Generally, public key methods are preferred for reasons given above, but -shared secrets can be used with no loss of security, just more work and -perhaps more need to take precautions.

- -

What I call "shared secrets" are sometimes also called "pre-shared keys". -They are used only for for authentication, never for encryption. Calling them -"pre-shared keys" has confused some users into thinking they were encryption -keys, so I prefer to avoid the term..

- -

If you are interoperating with another IPsec implementation, you may find -its documentation calling them "passphrases".

- -

Putting secrets in ipsec.secrets(5)

- -

If shared secrets are to be used to authenticate communication for the Diffie-Hellman key exchange in the IKE protocol, then those secrets must be stored -in /etc/ipsec.secrets. For details, see the ipsec.secrets(5) man page.

- -

A few considerations are vital:

- - -

Each line has the IP addresses of the two gateways plus the secret. It -should look something like this:

-
        10.0.0.1 11.0.0.1 : PSK "jxTR1lnmSjuj33n4W51uW3kTR55luUmSmnlRUuWnkjRj3UuTV4T3USSu23Uk55nWu5TkTUnjT"
- -

PSK indicates the use of a -pre-shared key. The quotes -and the whitespace shown are required.

- -

You can use any character string as your secret. For security, it should -be both long and extremely hard to guess. We provide a utility to generate -such strings, ipsec_ranbits(8).

- -

You want the same secret on the two gateways used, so you create a line -with that secret and the two gateway IP addresses. The installation process -supplies an example secret, useful only for testing. You must change -it for production use.

- -

File security

- -

You must deliver this file, or the relevant part of it, to the other -gateway machine by some secure means. Don't just FTP or -mail the file! It is vital that the secrets in it remain secret. An -attacker who knew those could easily have all the data on your "secure" -connection.

- -

This file must be owned by root and should have permissions -rw-------.

- -

Shared secrets for road warriors

- -

You can use a shared secret to support a single road warrior connecting to -your gateway, and this is a reasonable thing to do in some circumstances. -Public key methods have advantages, discussed above, -but they are not critical in this case.

- -

To do this, the line in ipsec.secrets(5) is something like:

-
        10.0.0.1 0.0.0.0 : PSK "jxTR1lnmSjuj33n4W51uW3kTR55luUmSmnlRUuWnkjRj3UuTV4T3USSu23Uk55nWu5TkTUnjT"
-where the 0.0.0.0 means that any IP address is acceptable. - -

For more than one road warrior, shared secrets are not -recommended. If shared secrets are used, then when the responder -needs to look up the secret, all it knows about the sender is an IP address. -This is fine if the sender is at a fixed IP address specified in the config -file. It is also fine if only one road warrior uses the wildcard -0.0.0.0 address. However, if you have more than one road warrior -using shared secret authentication, then they must all use that wildcard and -therefore all road warriors using PSK autentication must use the same -secret. Obviously, this is insecure.

- -

For multiple road warriors, use public key -authentication. Each roadwarrior can then have its own identity (our -leftid= or rightid= parameters), its own public/private -key pair, and its own secure connection.

- -

Using manual keying in production

- -

Generally, automatic keying is preferred -over manual keying for production use -because it is both easier to manage and more secure. Automatic keying frees -the admin from much of the burden of managing keys securely, and can provide -perfect forward secrecy. This is discussed in -more detail above.

- -

However, it is possible to use manual keying in production if that is what -you want to do. This might be necessary, for example, in order to -interoperate with some device that either does not provide automatic keying -or provides it in some version we cannot talk to.

- -

Note that with manual keying all security rests with the -keys. If an adversary acquires your keys, you've had it. He or she -can read everything ever sent with those keys, including old messages he or -she may have archived.

- -

You need to be really paranoid about keys if you're going -to rely on manual keying for anything important.

- - -

Linux FreeS/WAN provides some facilities to help with this. In particular, -it is good policy to keep keys in separate files so you can -edit configuration information in /etc/ipsec.conf without exposing keys to -"shoulder surfers" or network snoops. We support this with the -also= and include syntax in ipsec.conf(5).

- -

See the last example in our examples file. In the -/etc/ipsec.conf conn samplesep section, it has the line:

-
        also=samplesep-keys
- -

which tells the "ipsec manual" script to insert the configuration -description labelled "samplesep-keys" if it can find it. The /etc/ipsec.conf -file must also have a line such as:

-
include ipsec.*.conf
- -

which tells it to read other files. One of those other files then might -contain the additional data:

-
conn samplesep-keys
-  spi=0x200
-  esp=3des-md5-96
-  espenckey=0x01234567_89abcdef_02468ace_13579bdf_12345678_9abcdef0
-  espauthkey=0x12345678_9abcdef0_2468ace0_13579bdf
- -

The first line matches the label in the "also=" line, so the indented -lines are inserted. The net effect is exactly as if the inserted lines had -occurred in the original file in place of the "also=" line.

- -

Variables set here are:

-
-
spi
-
A number needed by the manual keying code. Any 3-digit hex number - will do, but if you have more than one manual connection then - spi must be different for each connection.
-
esp
-
Options for ESP (Encapsulated - Security Payload), the usual IPsec encryption mode. Settings here are - for encryption using triple DES and authentication using MD5. Note that encryption without - authentication should not be used; it is insecure.
-
espenkey
-
Key for ESP encryption. Here, a 192-bit hex number for triple - DES.
-
espauthkey
-
Key for ESP authentication. Here, a 128-bit hex number for MD5.
-
- -

Note that the example keys we supply are -intended only for testing. For real use, you should go to -automatic keying. If that is not possible, create your own keys for manual -mode and keep them secret

- -

Of course, any files containing keys must have 600 -permissions and be owned by root.

- -

If you connect in this way to multiple sites, we recommend that you keep -keys for each site in a separate file and adopt some naming convention that -lets you pick them all up with a single "include" line. This minimizes the -risk of losing several keys to one error or attack and of accidentally giving -another site admin keys which he or she has no business knowing.

- -

Also note that if you have multiple manually keyed connections on a single -machine, then the spi parameter must be different for each one. -Any 3-digit hex number is OK, provided they are different for each -connection. We reserve the range 0x100 to 0xfff for manual connections. Pluto -assigns SPIs from 0x1000 up for automatically keyed connections.

- -

If ipsec.conf(5) contains keys -for manual mode connections, then it too must have permissions -rw-------. We recommend instead that, if you must manual keying in -production, you keep the keys in separate files.

- -

Note also that ipsec.conf is -installed with permissions rw-r--r--. If you plan to use manually -keyed connections for anything more than initial testing, you must:

- - -

We recommend the latter method for all but the simplest configurations.

- -

Creating keys with ranbits

- -

You can create new random keys with the -ranbits(8) utility. For example, -the commands:

-
      umask 177
-      ipsec ranbits 192  > temp
-      ipsec ranbits 128 >> temp
- -

create keys in the sizes needed for our default algorithms:

- - -

If you want to use SHA instead of MD5, that requires a 160-bit key

- -

Note that any temporary files used must be kept -secure since they contain keys. That is the reason for the -umask command above. The temporary file should be deleted as soon as you are -done with it. You may also want to change the umask back to its default value -after you are finished working on keys.

- -

The ranbits utility may pause for a few seconds if not enough entropy is -available immediately. See ipsec_ranbits(8) and random(4) for details. You -may wish to provide some activity to feed entropy into the system. For -example, you might move the mouse around, type random characters, or do -du /usr > /dev/null in the background.

- -

Setting up connections at boot time

- -

You can tell the system to set up connections automatically at boot time -by putting suitable stuff in /etc/ipsec.conf on both systems. The relevant -section of the file is labelled by a line reading config setup.

- -

Details can be found in the ipsec.conf(5) man page. We also -provide a file of example configurations.

- -

The most likely options are something like:

-
-
interfaces="ipsec0=eth0 ipsec1=ppp0"
-
Tells KLIPS which interfaces to use. Up to four interfaces numbered - ipsec[0-3] are supported. Each interface can support an arbitrary - number of tunnels. -

Note that for PPP, you give the ppp[0-9] device name here, not the - underlying device such as modem (or eth1 if you are using PPPoE).

-
-
interfaces=%defaultroute
-
Alternative setting, useful in simple cases. KLIPS will pick up both - its interface and the next hop information from the settings of the - Linux default route.
-
forwardcontrol=no
-
Normally "no". Set to "yes" if the IP forwarding option is disabled - in your network configuration. (This can be set as a kernel - configuration option or later. e.g. on Redhat, it's in - /etc/sysconfig/network and on SuSE you can adjust it with Yast.) Linux - FreeS/WAN will then enable forwarding when starting up and turn it off - when going down. This is used to ensure that no packets will be - forwarded before IPsec comes up and takes control.
-
syslog=daemon.error
-
Used in messages to the system logging daemon (syslogd) to specify - 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 attention to this variable. The variable controls setup messages - only.

-
-
klipsdebug=
-
Debug settings for KLIPS.
-
plutodebug=
-
Debug settings for Pluto.
-
... for both the above DEBUG settings
-
Normally, leave empty as shown above for no debugging output.
- Use "all" for maximum information.
- See ipsec_klipsdebug(8) and ipsec_pluto(8) man page for other options. - Beware that if you set /etc/ipsec.conf to enable debug output, your - system's log files may get large quickly.
-
dumpdir=/safe/directory
-
Normally, programs started by ipsec setup don't crash. If they do, by - default, no core dump will be produced because such dumps would contain - secrets. If you find you need to debug such crashes, you can set - dumpdir to the name of a directory in which to collect the core - file.
-
manualstart=
-
List of manually keyed connections to be automatically started at - boot time. Useful for testing, but not for long term use. Connections - which are automatically started should also be automatically - re-keyed.
-
pluto=yes
-
Whether to start Pluto when ipsec - startup is done.
- This parameter is optional and defaults to "yes" if not present. -

"yes" is strongly recommended for production use so that the keying - daemon (Pluto) will automatically re-key the connections regularly. The - ipsec-auto parameters ikelifetime, ipseclifetime and reykeywindow give - you control over frequency of rekeying.

-
-
plutoload="reno-van reno-adam reno-nyc"
-
List of tunnels (by name, e.g. fred-susan or reno-van in our - examples) to be loaded into Pluto's internal database at startup. In - this example, Pluto loads three tunnels into its database when it is - started. -

If plutoload is "%search", Pluto will load any connections whose - description includes "auto=add" or "auto=start".

-
-
plutostart="reno-van reno-adam reno-nyc"
-
List of tunnels to attempt to negotiate when Pluto is started. -

If plutostart is "%search", Pluto will start any connections whose - description includes "auto=start".

-

Note that, for a connection intended to be permanent, both - gateways should be set try to start the tunnel. This allows - quick recovery if either gateway is rebooted or has its IPsec - restarted. If only one gateway is set to start the tunnel and the other - gateway restarts, the tunnel may not be rebuilt.

-
-
plutowait=no
-
Controls whether Pluto waits for one tunnel to be established before - starting to negotiate the next. You might set this to "yes" -
    -
  • if your gateway is a very limited machine and you need to - conserve resources.
    • -
  • for debugging; the logs are clearer if only one connection is - brought up at a time
    • -
- For a busy and resource-laden production gateway, you likely want "no" - so that connections are brought up in parallel and the whole process - takes less time.
-
- -

The example assumes you are at the Reno office and will use IPsec to -Vancouver, New York City and Amsterdam.

- -

Multiple tunnels between the same two -gateways

- -

Consider a pair of subnets, each with a security gateway, connected via -the Internet:

-
         192.168.100.0/24           left subnet
-              |
-         192.168.100.1
-         North Gateway
-         101.101.101.101            left
-              |
-         101.101.101.1              left next hop
-         [Internet]
-         202.202.202.1              right next hop
-              |
-         202.202.202.202            right
-         South gateway
-         192.168.200.1
-              |
-         192.168.200.0/24           right subnet
- -

A tunnel specification such as:

-
conn northnet-southnet
-      left=101.101.101.101
-      leftnexthop=101.101.101.1
-      leftsubnet=192.168.100.0/24
-      leftfirewall=yes
-      right=202.202.202.202
-      rightnexthop=202.202.202.1
-      rightsubnet=192.168.200.0/24
-      rightfirewall=yes
-will allow machines on the two subnets to talk to each other. You might test -this by pinging from polarbear (192.168.100.7) to penguin (192.168.200.5). - -

However, this does not cover other traffic you might want to -secure. To handle all the possibilities, you might also want these -connection descriptions:

-
conn northgate-southnet
-      left=101.101.101.101
-      leftnexthop=101.101.101.1
-      right=202.202.202.202
-      rightnexthop=202.202.202.1
-      rightsubnet=192.168.200.0/24
-      rightfirewall=yes
-
-conn northnet-southgate
-      left=101.101.101.101
-      leftnexthop=101.101.101.1
-      leftsubnet=192.168.100.0/24
-      leftfirewall=yes
-      right=202.202.202.202
-      rightnexthop=202.202.202.1
- -

Without these, neither gateway can do IPsec to the remote subnet. There is -no IPsec tunnel or eroute set up for the traffic.

- -

In our example, with the non-routable 192.168.* addresses used, packets -would simply be discarded. In a different configuration, with routable -addresses for the remote subnet, they would be sent -unencrypted since there would be no IPsec eroute and there would be -a normal IP route.

- -

You might also want:

-
conn northgate-southgate
-      left=101.101.101.101
-      leftnexthop=101.101.101.1
-      right=202.202.202.202
-      rightnexthop=202.202.202.1
- -

This is required if you want the two gateways to speak IPsec to each -other.

- -

This requires a lot of duplication of details. Judicious use of -also= and include can reduce this problem.

- -

Note that, while FreeS/WAN supports all four tunnel types, not all -implementations do. In particular, some versions of Windows 2000 and the -freely downloadable version of PGP provide only "client" 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.

- -

One tunnel plus advanced routing

-It is also possible to use the new routing features in 2.2 and later kernels -to avoid most needs for multple tunnels. Here is one mailing list message on -the topic: -
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.
- - - -

An Opportunistic Gateway

- -

Start from full opportunism

- -

Full opportunism -allows you to initiate and receive opportunistic connections on your -machine. The remaining instructions in this section assume -you have first set up full opportunism on your gateway using -these instructions. -Both sets of instructions require mailing DNS records to your ISP. Collect -DNS records for both the gateway (above) and the -subnet nodes (below) before contacting your ISP.

- - -

Reverse DNS TXT records for each protected machine

- -

You need these so that your Opportunistic peers can: -

- -

On the gateway, generate a TXT record with: -

    ipsec showhostkey --txt 192.0.2.11
-

Use your gateway address in place of 192.0.2.11.

- -

You should see (keys are trimmed for clarity throughout our example):

-
    ; RSA 2048 bits  gateway.example.com   Sat Apr 15 13:53:22 2000
-    IN TXT  "X-IPsec-Server(10)=192.0.2.11" " AQOF8tZ2...+buFuFn/"
- -

This MUST BE the same key as in your gateway's TXT record, or nothing -will work.

- -

In a text file, make one copy of this TXT record for each subnet - node:

-
    ; RSA 2048 bits  gateway.example.com   Sat Apr 15 13:53:22 2000
-    IN TXT  "X-IPsec-Server(10)=192.0.2.11" " AQOF8tZ2...+buFuFn/"
-                                                                                
-    ; RSA 2048 bits  gateway.example.com   Sat Apr 15 13:53:22 2000
-    IN TXT  "X-IPsec-Server(10)=192.0.2.11" " AQOF8tZ2...+buFuFn/"
-                                                                                
-    ; RSA 2048 bits  gateway.example.com   Sat Apr 15 13:53:22 2000
-    IN TXT  "X-IPsec-Server(10)=192.0.2.11" " AQOF8tZ2...+buFuFn/"
- -

Above each entry, insert a line like this:

-
    98.2.0.192.in-addr.arpa. IN PTR arthur.example.com.
- -

It must include:

- - -

The result will be a file of TXT records, like this:

-
    98.2.0.192.in-addr.arpa. IN PTR arthur.example.com.
-    ; RSA 2048 bits  gateway.example.com   Sat Apr 15 13:53:22 2000
-    IN TXT  "X-IPsec-Server(10)=192.0.2.11" " AQOF8tZ2...+buFuFn/"
-                                                                                
-    99.2.0.192.in-addr.arpa. IN PTR ford.example.com.
-    ; RSA 2048 bits  gateway.example.com   Sat Apr 15 13:53:22 2000
-    IN TXT  "X-IPsec-Server(10)=192.0.2.11" " AQOF8tZ2...+buFuFn/"
-                                                                                
-    100.2.0.192.in-addr.arpa. IN PTR trillian.example.com.
-    ; RSA 2048 bits  gateway.example.com   Sat Apr 15 13:53:22 2000
-    IN TXT  "X-IPsec-Server(10)=192.0.2.11" " AQOF8tZ2...+buFuFn/"
- - -

Publish your records

- -

Ask your ISP to publish all the reverse DNS records you have collected. -There may be a delay of up to 48 hours as the records propagate.

- - -

...and test them

- -

Check a couple of records with commands like this one:

- -
    ipsec verify --host ford.example.com
-    ipsec verify --host trillian.example.com
- -

The verify command checks for TXT records for both the -subnet host and its gateway. You should see output like:

-
    ...
-    Looking for TXT in reverse map: 99.2.0.192.in-addr.arpa [OK]
-    ...
-    Looking for TXT in reverse map: 11.2.0.192.in-addr.arpa   [OK]
-    ...
-    Looking for TXT in reverse map: 100.2.0.192.in-addr.arpa [OK]
-    ...
-    Looking for TXT in reverse map: 11.2.0.192.in-addr.arpa   [OK]
-    ...
-

No Configuration Needed

- -

FreeS/WAN 2.x ships with a built-in, automatically -enabled OE connection conn packetdefault -which applies OE, if possible, to all outbound traffic routed -through the FreeS/WAN box. - -The -ipsec.conf(5) manual -describes this connection in detail. -While the effect is much the same as private-or-clear, -the implementation is different: notably, it does not use policy -groups.

- -

You can create more complex OE configurations -for traffic forwarded through a FreeS/WAN box, as explained in our -policy groups document, -or disable OE using -these instructions.

- - - -

Extruded Subnets

- -

What we call extruded subnets are a -special case of VPNs.

- -

If your buddy has some unused IP addresses, in his subnet far off at the -other side of the Internet, he can loan them to you... provided that the -connection between you and him is fast enough to carry all the traffic -between your machines and the rest of the Internet. In effect, he "extrudes" -a part of his address space over the network to you, with your Internet -traffic appearing to originate from behind his Internet gateway.

- -

As far as the Internet is concerned, your new extruded net is behind your -buddy's gateway. You route all your packets for the Internet at large -out his gateway, and receive return packets the same way. You route your -local packets locally.

- -

Suppose your friend has a.b.c.0/24 and wants to give you a.b.c.240/28. The -initial situation is:

-
    subnet           gateway          Internet
-  a.b.c.0/24    a.b.c.1    p.q.r.s
-where anything from the Internet destined for any machine in a.b.c.0/24 is -routed via p.q.r.s and that gateway knows what to do from there. - -

Of course it is quite normal for various smaller subnets to exist behind -your friend's gateway. For example, your friend's company might have -a.b.c.16/28=development, a.b.c.32/28=marketing and so on. The Internet -neither knows not cares about this; it just delivers packets to the p.q.r.s -and lets the gateway do whatever needs to be done from there.

- -

What we want to do is take a subnet, perhaps a.b.c.240/28, out of your -friend's physical location while still having your friend's gateway route -to it. As far as the Internet is concerned, you remain behind that -gateway.

-
    subnet           gateway          Internet       your gate  extruded
-
-  a.b.c.0/24   a.b.c.1     p.q.r.s              d.e.f.g         a.b.c.240/28                
-
-                           ========== tunnel ==========
- -

The extruded addresses have to be a complete subnet.

- -

In our example, the friend's security gateway is also his Internet -gateway, but this is not necessary. As long as all traffic from the Internet -to his addresses passes through the Internet gate, the security gate could be -a machine behind that. The IG would need to route all traffic for the -extruded subnet to the SG, and the SG could handle the rest.

- -

First, configure your subnet using the extruded addresses. Your security -gateway's interface to your subnet needs to have an extruded address -(possibly using a Linux virtual -interface, if it also has to have a different address). Your gateway -needs to have a route to the extruded subnet, pointing to that interface. The -other machines at your site need to have addresses in that subnet, and -default routes pointing to your gateway.

- -

If any of your friend's machines need to talk to the extruded subnet, -they need to have a route for the extruded subnet, pointing at his -gateway.

- -

Then set up an IPsec subnet-to-subnet tunnel between your gateway and his, -with your subnet specified as the extruded subnet, and his subnet specified -as "0.0.0.0/0".

- -

The tunnel description should be:

-
conn extruded
-        left=p.q.r.s
-        leftsubnet=0.0.0.0/0
-        right=d.e.f.g
-        rightsubnet=a.b.c.0/28
- -

If either side was doing firewalling for the extruded subnet before the -IPsec connection is set up, you'll need to poke holes in your -firewall to allow packets through. -

- -

And it all just works. Your SG routes traffic for 0.0.0.0/0 -- that is, -the whole Internet -- through the tunnel to his SG, which then sends it -onward as if it came from his subnet. When traffic for the extruded subnet -arrives at his SG, it gets sent through the tunnel to your SG, which passes -it to the right machine.

- -

Remember that when ipsec_manual or ipsec_auto takes a connection down, it -does not undo the route it made for that connection. This lets you -take a connection down and bring up a new one, or a modified version of the -old one, without having to rebuild the route it uses and without any risk of -packets which should use IPsec accidentally going out in the clear. Because -the route always points into KLIPS, the packets will always go there. Because -KLIPS temporarily has no idea what to do with them (no eroute for them), they -will be discarded.

- -

If you do want to take the route down, this is what the "unroute" -operation in manual and auto is for. Just do an unroute after doing the -down.

- -

Note that the route for a connection may have replaced an existing -non-IPsec route. Nothing in Linux FreeS/WAN will put that pre-IPsec route -back. If you need it back, you have to create it with the route command.

- -

Road Warrior with virtual IP address

- -

Please note that Super -FreeS/WAN now features DHCP-over-IPsec, which is an alternate procedure -for Virtual IP address assignment. -

- -

Here is a mailing list message about another way to configure for road -warrior support:

-
Subject: Re: linux-ipsec: understanding the vpn
-   Date: Thu, 28 Oct 1999 10:43:22 -0400
-   From: Irving Reid <irving@nevex.com>
-
->  local-------linux------internet------mobile
->  LAN        box                         user
->  ...
-
->  now when the mobile user connects to the linux box
->  it is given a virtual IP address, i have configured it to
->  be in the 10.x.x.x range. mobile user and linux box 
->  have a tunnel between them with these IP addresses.
-
->   Uptil this all is fine.
-
-If it is possible to configure your mobile client software *not* to
-use a virtual IP address, that will make your life easier. It is easier
-to configure FreeS/WAN to use the actual address the mobile user gets
-from its ISP.
-
-Unfortunately, some Windows clients don't let you choose.
-
->  what i would like to know is that how does the mobile
->  user communicate with other computers on the local
->  LAN , of course with the vpn ?
-
->   what IP address should the local LAN 
->  computers have ? I guess their default gateway 
->  should be the linux box ? and does the linux box need
->  to be a 2 NIC card box or one is fine.
-
-As someone else stated, yes, the Linux box would usually be the default
-IP gateway for the local lan.
-
-However...
-
-If you mobile user has software that *must* use a virtual IP address,
-the whole picture changes. Nobody has put much effort into getting
-FreeS/WAN to play well in this environment, but here's a sketch of one
-approach:
-
-Local Lan 1.0.0.0/24
-    |
-    +- Linux FreeS/WAN 1.0.0.2
-    |
-    | 1.0.0.1
- Router
-    | 2.0.0.1
-    |
-Internet
-    |
-    | 3.0.0.1
-Mobile User
-      Virtual Address: 1.0.0.3
-
-Note that the Local Lan network (1.0.0.x) can be registered, routable
-addresses.
-
-Now, the Mobile User sets up an IPSec security association with the
-Linux box (1.0.0.2); it should ESP encapsulate all traffic to the
-network 1.0.0.x **EXCEPT** UDP port 500. 500/udp is required for the key
-negotiation, which needs to work outside of the IPSec tunnel.
-
-On the Linux side, there's a bunch of stuff you need to do by hand (for
-now). FreeS/WAN should correctly handle setting up the IPSec SA and
-routes, but I haven't tested it so this may not work...
-
-The FreeS/WAN conn should look like:
-
-conn mobile
-        right=1.0.0.2
-        rightsubnet=1.0.0.0/24
-        rightnexthop=1.0.0.1
-        left=0.0.0.0  # The infamous "road warrior"
-        leftsubnet=1.0.0.3/32
-
-Note that the left subnet contains *only* the remote host's virtual
-address.
-
-Hopefully the routing table on the FreeS/WAN box ends up looking like
-this:
-
-% netstat -rn
-Kernel IP routing table
-Destination     Gateway      Genmask         Flags   MSS Window  irtt Iface
-1.0.0.0         0.0.0.0      255.255.255.0   U      1500 0          0 eth0
-127.0.0.0       0.0.0.0      255.0.0.0       U      3584 0          0 lo
-0.0.0.0         1.0.0.1      0.0.0.0         UG     1500 0          0 eth0
-1.0.0.3         1.0.0.1      255.255.255.255 UG     1433 0          0 ipsec0
-
-So, if anybody sends a packet for 1.0.0.3 to the Linux box, it should
-get bundled up and sent through the tunnel. To get the packets for
-1.0.0.3 to the Linux box in the first place, you need to use "proxy
-ARP".
-
-How this works is: when a host or router on the local Ethernet segment
-wants to send a packet to 1.0.0.3, it sends out an Ethernet level
-broadcast "ARP request". If 1.0.0.3 was on the local LAN, it would
-reply, saying "send IP packets for 1.0.0.3 to my Ethernet address".
-
-Instead, you need to set up the Linux box so that _it_ answers ARP
-requests for 1.0.0.3, even though that isn't its IP address. That
-convinces everyone else on the lan to send 1.0.0.3 packets to the Linux
-box, where the usual FreeS/WAN processing and routing take over.
-
-% arp -i eth0 -s 1.0.0.3 -D eth0 pub
-
-This says, if you see an ARP request on interface eth0 asking for
-1.0.0.3, respond with the Ethernet address of interface eth0.
-
-Now, as I said at the very beginning, if it is *at all* possible to
-configure your client *not* to use the virtual IP address, you can avoid
-this whole mess.
- -

Dynamic Network Interfaces

- -

Sometimes you have to cope with a situation where the network interface(s) -aren't all there at boot. The common example is notebooks with PCMCIA.

- -

Basics

- -

The key issue here is that the config setup section of the -/etc/ipsec.conf configuration file lists the connection between -ipsecN and hardware interfaces, in the interfaces= variable. At -any time when ipsec setup start or ipsec setup restart -is run this variable must correspond to the current real -situation. More precisely, it must not mention any hardware -interfaces which don't currently exist. The difficulty is that an ipsec -setup start command is normally run at boot time so interfaces that are -not up then are mis-handled.

- -

Boot Time

- -

Normally, an ipsec setup start is run at boot time. However, if -the hardware situation at boot time is uncertain, one of two things must be -done.

- - -

Change Time

- -

When the hardware *is* in place, IPsec has to be made aware of it. Someday -there may be a nice way to do this.

- -

Right now, the way to do it is to fix the /etc/ipsec.conf file -appropriately, so interfaces reflects the new situation, and then -restart the IPsec subsystem. This does break any existing IPsec -connections.

- -

If IPsec wasn't brought up at boot time, do

-
        ipsec setup start
-while if it was, do -
        ipsec setup restart
-which won't be as quick. - -

If some of the hardware is to be taken out, before doing that, amend the -configuration file so interfaces no longer includes it, and do

-
        ipsec setup restart
- -

Again, this breaks any existing connections.

- -

Unencrypted tunnels

- -

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:

-
-
using ESP with null encryption
-
not supported by FreeS/WAN
-
using AH without ESP
-
supported for manually keyed connections
-
possible with explicit commands via ipsec_whack(8) (see this list - message)
-
not supported in the ipsec_auto(8) scripts.
-
-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.

- - -

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.

- - -- cgit v1.2.3