IPSec Plugin |
![]() ![]() ![]()
If you received the plugin as a zipped archive, then extract it with Info-Zip's UNZIP.EXE (or PKUNZIP.EXE using the -d option). After installation the new binary file is demand-loaded by the host application when needed. Please consult the host product documentation for possible extra installation guidelines and IPSec options.
For OS/2, the FreeS/WAN IKE Server ("Pluto") has been ported under the GNU Public License to be compatible with the InJoy IPSEC plugin. To install Pluto:
To make administrative tasks more easy Injoy IPSec plugin operates in terms of SA bundles rather then individual SAs. Each bundle determines all information critical to support the IPSec protocol between two IPSec endpoints. Each SA bundle must be defined in a separate section of the ipsec.cfg file.
Notice, the entry names in ipsec.cfg are not significant, but only used for logging.
Example of a section in ipsec.cfg:
Characters following ';' are comments and skipped by the IPSec Plugin. For further explanation of the attributes, refer to the: Description of IPSec attributes.
(*) Note: Since the encapsulated header is not processed by the Internet routers, only the endpoints of the tunnel (the gateways) need to have globally assigned addresses; the hosts in the intranets behind them can be assigned private addresses, for example 10.x.x.x. NAT processing is not applied to IPSec traffic so both tunnel endpoints can use private addresses as if they were global. This technique dramatically extends the address-space available for the VPN.
The diagrams and text below describe the basic cases. The legend for the
diagrams is: This scenario represents the simplest case of providing end-to-end security between 2 hosts across the Internet (or an Intranet).
Config for Host 1
Config for Host 2
Note: mode can be tunnel on both sides but it has no special meaning. Gateway to Gateway connection. This scenario illustrates simple virtual private networks support.
Config for Security Gateway 1
Config for Security Gateway 2
It is possible to define additional (nested) SA bundle directly between Host 1 and Host 2. First example ( Host to host connection) describes how to setup such bundle. This scenario covers the situation where a remote host (Host 1) uses the Internet to reach an organization's firewall (Gateway 2) and to then gain access to some server or other machine (Host 2). The remote host could be a mobile host (Host 1) dialing up to a local PPP/ARA server on the Internet and then crossing the Internet to the home organization's firewall (Gateway 2).
Config for Host 1
Config for Security Gateway 2
This example extends the previous scenario ( Host to gateway connection) with an additional SA bundle defined between Host 1 and Host 2.
First, the outgoing traffic from Host 1 to Host 2 will be processed by the IPSec Plugin, according to the SA bundle "first" and after that according to the SA bundle "second". Incoming traffic from Host 2 will be processed in reverse order. For correct operation of the IPSec Plugin, Host 1 must define the "first" bundle prior to the "second". In other words, the order of appearence in the ipsec.cfg file strongly defines the order of IPSec processing.
Config for Host 1
Config for the Security Gateway 2
Config for Host 1
A pluto daemon and another IKE daemon (for example, another instance of pluto) must convince each other that they are who they are supposed to be before any negotiation can succeed. This authentication is accomplished by using secrets that have been shared beforehand (manually). There are other techniques, but they have not been implemented in pluto. The file isecrets.cfg is used to keep preshared secret keys for authentication with other IKE daemons. The file is a sequence of entries and include directives. Here is an example.
# sample isecrets.cfg file for 10.1.0.1 Each entry in the file is a list of indices, followed by a secret. To authenticate a connection between two hosts, the first entry that has both endpoints (hosts) as indices is used. Authentication requires that both systems find the identical secrets (the secret is not actually transmitted by the protocol). By requiring both addresses in the index list, we make the same entry suitable for both systems so verbatim copying can be used. This naturally extends to larger groups sharing the same secret. An index is an IP address (other kinds may come). It may be written in the familiar dotted quad form or as a domain name to be looked up. In many cases it is a bad idea to use domain names because the name server may not be running or may be insecure. A secret is a sequence of characters, delimited by the double-quote character ("). The sequence cannot contain a newline or double-quote. Strictly speaking, the secret is actually the sequence of bytes that is used in the file to represent the sequence of characters (excluding the delimiters). The first index of an entry must start in the first column of its line. Subsequent indices and the secret are separated by whitespace. A newline is taken as whitespace, but every line of an entry except the first must be indented. Whitespace at the end of a line is ignored. At the start of line or after whitespace, # and the following text up to the end of the line is treated as a comment. Within entries, all lines must be indented (including comments; blank lines cannot appear). Outside entries, no line may be indented (this is to make sure that the file layout reflects its structure). Between entries, the file may contain an include directive. This causes the contents of the named file to be processed before continuing with the current file. The include directive is a line that starts with the word include, followed by whitespace, followed by the filename (which must not contain whitespace). See also comments about special meaning of addresses "0.0.0.0" and "127.0.0.1" in the "Configuring Dynamic IP address support (Road Warrior case)" section. It is recommended to start the IKE server (i.e. Pluto) at system startup, or more importantly, before the InJoy host product. To start Pluto, issue the following command:
To switch on full debugging, issue the following command:
For any IKE Server (incl. Pluto), it is important that the UDP Port 500 is accessible and not occupied by another service. Note that all interoperation between Pluto and Injoy IPSec plugin is automatic and no additional preparation (except that documented above) is needed. For example, you need not use the whack utility shipped with Pluto to define or control SA bundles descriptions. If you wish to restart Pluto without restarting the InJoy host product, or if Pluto was started after host product, then the utility pinit must be used to "refresh" Pluto.. All additional details about Pluto IKE Server functionality can be found in the original Pluto documentation.
Current solution is that one connection may be defined for the IP address 0.0.0.0. On getting a connection request from an address not recognized, the Pluto server tries to authenticate it using the secret for 0.0.0.0. If this succeeds, a connection is created to the unrecognised address. This implies that all Road Warriors connecting to a Pluto server must share the same connection description and the same secret. As an example, please look at the "Host to gateway connection" diagram in the "Typical scenarios" section and assume that host-1 uses the InJoy Dialer with dynamic IP addressing. First it is needed to modify the 2 configuration files on the gateway PC, in order to support the remote road warriors. Security Gateway 2 isecrets.cfg: 0.0.0.0 195.97.161.40 "password" Security Gateway 2 ipsec.cfg:
Now it is needed to configure IPSec for the road warrior host (i.e. the Injoy Dialer). InJoy will report the server assigned IP address to the IPSec plugin at ISP connect time, requiring 0.0.0.0 in the ipsec.cfg file for Host 1:
Immediately following a dialer connection, the IP address in the inner tables of IPSec will be automaticaly updated. The solution for Pluto is equally simple. Simply specify an entry in the isecrets.cfg file with the address of "127.0.0.1" and the address will be replaced (internally - not in the file) to the actual server assigned address. Example: Host 1 isecrets.cfg: 195.97.161.40 127.0.0.1 "password" In this scenario, the address 195.97.161.40 belongs to the IPSec gateway, while e.g. the dynamic IP address 195.97.161.1 could be assigned to the Road Warrior. Logically the 0.0.0.0 entry in ipsec.cfg and the 127.0.0.1 entry in isecrets.cfg will be replaced with the 195.97.161.1 address.
This utility instructs the Injoy IPSec plugin to initialize Pluto with parameters known only by the plugin. If Pluto was started before the host application, IPSec will initialize Pluto automatically, but if Pluto was restarted after the host application you need to invoke pinit.exe. This utility dumps the current SA bundles table in the following format:
All auditable events are logged to ipsec.log and pluto.log The format of messages in ipsec.log is: [Time of message][Prefix][SA bundle name][Message] The following table shows the possible prefixes for ipsec.log messages:
All errors can be viewed in the output window of the host application.
To make sure that IPSec connections are secure, an operator must check
for the existence of errors in ipsec.log on a regular basis. You can see examples of ipsec.log messages below:
For more information about pluto.log, refer to the Pluto documentation.
|