From aa0f5b38aec14428b4b80e06f90ff781f8bca5f1 Mon Sep 17 00:00:00 2001 From: Rene Mayrhofer Date: Mon, 22 May 2006 05:12:18 +0000 Subject: Import initial strongswan 2.7.0 version into SVN. --- doc/adv_config.html | 1232 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 1232 insertions(+) create mode 100644 doc/adv_config.html (limited to 'doc/adv_config.html') diff --git a/doc/adv_config.html b/doc/adv_config.html new file mode 100644 index 000000000..4b779c753 --- /dev/null +++ b/doc/adv_config.html @@ -0,0 +1,1232 @@ + + + +Introduction to FreeS/WAN + + + + +Contents +Previous +Next +
+

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-s +hared 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.

+
+Contents +Previous +Next + + -- cgit v1.2.3