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. The IPSec Plugin can be used simultaneously from different InJoy products, i.e. the InJoy Dialer, InJoy Connect or the InJoy Firewall. It should be noticed that the last started InJoy product will define the dynamic IP address used for Road Warrior SA's. I.e. if the InJoy Dialer is used as a Road Warrior, the InJoy Firewall should not be subsequently started with IPSec enabled. If it is, the IP address of the InJoy Firewall interface will override the dynamic IP address obtained by the InJoy Dialer. 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. (**) This is an parameter included only for compatibility with certain third party implementations. You should not use this paramter without further guidance from F/X Communications support.
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:
With Pluto 1.1-130 or higher the "--noklips" option can be omitted. To switch on full debugging, issue the following command:
Note 2 dashes (-) before options. 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.
"Road Warrior" is a term for the laptop user who needs to call home base and wants a secure connection. The problem is that configuration files define connections by the IP addresses involved and a Road Warrior's IP address is not known in advance. 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. Road Warrior with subnet behind. ![]() The IPSec Plugin (using Pluto 1.1-130 or newer) supports Road Warriors that act as Gateways for subnets (see picture above). The Security Gateway (on the server side) has a common description for all the remote Road Warriors and accordingly they MUST all use portions of a common subnet. On the server side, you must define the 'remotenet' and 'remotemask' attributes of appropriate size, i.e. with enough addresses to satisfy all the remote Road Warriors. The remote Road Warriors on the other hand, should be configured to use only a portion of the common subnet as their localnet. The address space portion used by the various remote Road Warriors MAY NOT conflict. Below a sample configuration for the corporate server (Gateway on picture): Security Gateway ipsec.cfg:
Road Warrior-1 ipsec.cfg:
Road Warrior-2 ipsec.cfg:
This section describes how to make two IPSec endpoint communicate through a non IPSec capable NAT router. As an IPSec operator, you may need to connect to a VPN server through a Firewall, a NAT gateway or a hardware router that doesn't support IPSec. A typical setup is when NAT prevents one of the Internal computers from securely connecting to an IPSec VPN server on the Internet. The Injoy IPSec solution can work through such a NAT product, but it requires the use of several port mapping rules and it introduces a few limitations. IPSec traffic that carry the AH header cannot be translated when passing through a NAT device. The AH protocol incorporates a cryptographic checksum across the IP addresses that an IP translating gateway cannot correctly regenerate. Thus, all AH traffic will be discarded when reaching a NAT device. IPsec traffic using transport-mode ESP also cannot be reliably NAT translated. Transport mode ESP essentially encrypts everything after the IP header. Since, for example, the TCP and UDP checksums include the IP source and destination addresses, and the TCP/UDP checksum is within the encrypted payload and thus cannot be recalculated after the NAT gateway alters the IP addresses, the TCP/UDP header will fail the checksum test at the remote gateway and the packet will be discarded. The solution is to use ESP in tunnel mode. During the tunneling process, original IP packets are encapsulated inside outer IP packets. The outer packets share the same IP addresses as the original packets. The inner packets are processed by ESP, while the outer encapsulation packets are normal IP. The result is a larger packet that can be changed at the outer level, yet preserving the original packet on the inner level. Imagine an IP packet travelling from an IPSec client downwards these hop's, to a remote IPSec VPN host:
The remote IPSec host must be configured to expect IPSec traffic from addr2, as NAT will make all traffic appear to be coming from that address. When the incoming packet arrives at the remote IPSec host, checksum checking will be performed on the inner packet, it will be decrypted and de-tunnelled. The resulting packet will match the original inner packet, as sent by the IPSec host. IPSec host behind NAT - ipsec.cfg:
isecrets.cfg contains: addr1 addr3 "secret" When configuring the remote IPSec host, SA bundles must be created so they anticipate the NAT address instead of expecting the IPSec host address. Configuring the remote IPSec host - ipsec.cfg:
isecrets.cfg contains: addr2 addr3 "secret" A NAT solution will typically not be able to handle IPSec out of the box. It must be configured to do the following:
Rule 1 and 3 is normally implicit within standard NAT, but it may vary among products. With the InJoy products, the InJoy Firewall component can be configured to pass incoming IPSec/IKE traffic to an internal IPSec host (e.g. 10.1.1.1) through the use of these rules (matching rule 2 and 4 above):
The above rules can be converted to other Firewalls. Verifying the NAT configuration. After finalizing the desired setup, it must first be checked if the IKE servers are able to negotiate. Enable Pluto logging and check if the endpoints appear to be exchanging secrets. The remote IPSec host must install SA bundles with addr2 in the field "Remote gateway (host) ip address" - check ipsec.log to verify that. Also in ipsec.log, the "Remote net" and "Remote net mask" must specify the network that contains addr1. If that doesn't appear to be the case, check the IPSec configuration and verify the NAT port forwarding rules. If however the previous steps appear to be succesful, then try pinging between hosts. If you see ping responses your VPN is functioning.
In the setup described above, there is one important side effect to be
aware of. With IPSec successfully negotiated between the IPSec endpoints,
non IPSec workstations in the local NAT net will NOT be able to connect
to the remote IPSec host. The remote IPSec host expects all traffic coming
from the NAT network to be IPSec'ed and accordingly all non IPSec
traffic will be rejected. If you are using the InJoy NAT, you will see the
following warning in ipsec.log:
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.
|