Follow Techotopia on Twitter

On-line Guides
All Guides
eBook Store
iOS / Android
Linux for Beginners
Office Productivity
Linux Installation
Linux Security
Linux Utilities
Linux Virtualization
Linux Kernel
System/Network Admin
Programming
Scripting Languages
Development Tools
Web Development
GUI Toolkits/Desktop
Databases
Mail Systems
openSolaris
Eclipse Documentation
Techotopia.com
Virtuatopia.com

How To Guides
Virtualization
General System Admin
Linux Security
Linux Filesystems
Web Servers
Graphics & Desktop
PC Hardware
Windows
Problem Solutions
Privacy Policy

  




 

 

6.4. IPsec Host-to-Host Configuration

IPsec can be configured to connect one desktop or workstation to another by way of a host-to-host connection. This type of connection uses the network to which each host is connected to create the secure tunnel to each other. The requirements of a host-to-host connection are minimal, as is the configuration of IPsec on each host. The hosts need only a dedicated connection to a carrier network (such as the Internet) and Red Hat Enterprise Linux to create the IPsec connection.

The first step in creating a connection is to gather system and network information from each workstation. For a host-to-host connection, you need the following information:

  • The IP address for both hosts

  • A unique name to identify the IPsec connection and distinguish it from other devices or connections (for example, ipsec0)

  • A fixed encryption key or one automatically generated by racoon

  • A pre-shared authentication key that is used to initiate the connection and exchange encryption keys during the session

For example, suppose Workstation A and Workstation B want to connect to each other through an IPsec tunnel. They want to connect using a pre-shared key with the value of foobarbaz and the users agree to let racoon automatically generate and share an authentication key between each host. Both host users decide to name their connections ipsec0.

The following is the ifcfg file for Workstation A for a host-to-host IPsec connection with Workstation B (the unique name to identify the connection in this example is ipsec0, so the resulting file is named /etc/sysconfig/network-scripts/ifcfg-ipsec0):

DST=X.X.X.X
TYPE=IPSEC
ONBOOT=yes
IKE_METHOD=PSK

Workstation A would replace X.X.X.X with the IP address of Workstation B, while Workstation B replaces X.X.X.X with the IP address of Workstation A. The connection is set to initiate upon boot-up (ONBOOT=yes) and uses the pre-shared key method of authentication (IKE_METHOD=PSK).

The following is the content of the pre-shared key file (called /etc/sysconfig/network-scripts/keys-ipsec0) that both workstations need to authenticate each other. The contents of this file should be identical on both workstations and only the root user should be able to read or write this file.

IKE_PSK=foobarbaz

ImportantImportant
 

To change the keys-ipsec0 file so that only the root user can read or edit the file, perform the following command after creating the file:

chmod 600 /etc/sysconfig/network-scripts/keys-ipsec0

To change the authentication key at any time, edit the keys-ipsec0 file on both workstations. Both keys must be identical for proper connectivity.

The next example shows the specific configuration for the phase 1 connection to the remote host. The file is named X.X.X.X.conf (X.X.X.X is replaced with the IP address of the remote IPsec router). Note that this file is automatically generated once the IPsec tunnel is activated and should not be edited directly.

;
remote X.X.X.X
{
        exchange_mode aggressive, main;
        my_identifier address;
        proposal {
                encryption_algorithm 3des;
                hash_algorithm sha1;
                authentication_method pre_shared_key;
                dh_group 2 ;
        }
}

The default phase 1 configuration file created when an IPsec connection is initialized contains the following statements used by the Red Hat Enterprise Linux implementation of IPsec:

remote X.X.X.X

Specifies that the subsequent stanzas of this configuration file applies only to the remote node identified by the X.X.X.X IP address.

exchange_mode aggressive

The default configuration for IPsec on Red Hat Enterprise Linux uses an aggressive authentication mode, which lowers the connection overhead while allowing configuration of several IPsec connections with multiple hosts.

my_identifier address

Defines the identification method to be used when authenticating nodes. Red Hat Enterprise Linux uses IP addresses to identify nodes.

encryption_algorithm 3des

Defines the encryption cipher used during authentication. By default, Triple Data Encryption Standard (3DES) is used.

hash_algorithm sha1;

Specifies the hash algorithm used during phase 1 negotiation between nodes. By default, Secure Hash Algorithm version 1 is used.

authentication_method pre_shared_key

Defines the authentication method used during node negotiation. Red Hat Enterprise Linux by default uses pre-shared keys for authentication.

dh_group 2

Specifies the Diffie-Hellman group number for establishing dynamically-generated session keys. By default, the 1024-bit group is used.

The /etc/racoon/racoon.conf files should be identical on all IPsec nodes except for the include "/etc/racoon/X.X.X.X.conf" statement. This statement (and the file it references) is generated when the IPsec tunnel is activated. For Workstation A, the X.X.X.X in the include statement is Workstation B's IP address. The opposite is true of Workstation B. The following shows a typical racoon.conf file when IPsec connection is activated.

# Racoon IKE daemon configuration file.
# See 'man racoon.conf' for a description of the format and entries.

path include "/etc/racoon";
path pre_shared_key "/etc/racoon/psk.txt";
path certificate "/etc/racoon/certs";

sainfo anonymous
{
	pfs_group 2;
	lifetime time 1 hour ;
	encryption_algorithm 3des, blowfish 448, rijndael ;
	authentication_algorithm hmac_sha1, hmac_md5 ;
	compression_algorithm deflate ;
}
include "/etc/racoon/X.X.X.X.conf"

This default racoon.conf file includes defined paths for IPsec configuration, pre-shard key files, and certificates. The fields in sainfo anonymous describe the phase 2 SA between the IPsec nodes — the nature of the IPsec connection (including the supported encryption algorithms used) and the method of exchanging keys. The following list defines the fields of phase 2:

sainfo anonymous

Denotes that SA can anonymously initialize with any peer insofar as the IPsec credentials match.

pfs_group 2

Defines the Diffie-Hellman key exchange protocol, which determines the method in which the IPsec nodes establish a mutual temporary session key for the second phase of IPsec connectivity. By default, the Red Hat Enterprise Linux implementation of IPsec uses group 2 (or modp1024) of the Diffie-Hellman cryptographic key exchange groups. Group 2 uses a 1024-bit modular exponentiation that prevents attackers from decrypting previous IPsec transmissions even if a private key is compromised.

lifetime time 1 hour

This parameter specifies the life cycle of an SA and can be quantified either by time or by bytes of data. The Red Hat Enterprise Linux implementation of IPsec specifies a one hour lifetime.

encryption_algorithm 3des, blowfish 448, rijndael

Specifies the supported encryption ciphers for phase 2. Red Hat Enterprise Linux supports 3DES, 448-bit Blowfish, and Rijndael (the cipher used in the Advanced Encryption Standard, or AES).

authentication_algorithm hmac_sha1, hmac_md5

Lists the supported hash algorithms for authentication. Supported modes are sha1 and md5 hashed message authentication codes (HMAC).

compression_algorithm deflate

Defines the Deflate compression algorithm for IP Payload Compression (IPCOMP) support, which allows for potentially faster transmission of IP datagrams over slow connections.

To start the connection, either reboot the workstation or execute the following command as root on each host:

/sbin/ifup ipsec0

To test the IPsec connection, run the tcpdump utility to view the network packets being transfered between the hosts (or networks) and verify that they are encrypted via IPsec. The packet should include an AH header and should be shown as ESP packets. ESP means it is encrypted. For example:

17:13:20.617872 pinky.example.com > ijin.example.com: \
	    AH(spi=0x0aaa749f,seq=0x335): ESP(spi=0x0ec0441e,seq=0x335) (DF)

 
 
  Published under the terms of the GNU General Public License Design by Interspire