test

IPsec and IKE Administration Guide

IPsec Tasks

This section provides procedures that enable you to secure traffic between two systems, secure a web server, and set up a virtual private network (VPN). Additional procedures provide keying material, provide SAs, and check that IPsec is working as configured.

Some examples in these procedures use the system names enigma and partym. Substitute the names of your systems for the names enigma and partym.

For information on how to use roles to administer IPsec, see “Role-Based Access Control (Tasks)” in System Administration Guide: Security Services.

How to Secure Traffic Between Two Systems

This procedure assumes the following setup:

  1. On the system console, become superuser or assume an equivalent role.

    Note –

    Logging in remotely exposes security-critical traffic to eavesdropping. Even if you somehow protect the remote login, the security of the system is reduced to the security of the remote login session.

  2. On each system, add the addresses and host name for the other system in the /etc/inet/ipnodes file. The entries for one system must be contiguous in the file.

    If you are connecting systems with IPv4 addresses only, you modify the /etc/inet/hosts file.

    1. On a system that is named partym, type the following in the ipnodes file:


      # Secure communication with enigma 
192.168.116.16 enigma
fec0::10:20ff:fea0:21f6 enigma

    2. On a system that is named enigma, type the following in the ipnodes file:


      # Secure communication with partym 
192.168.13.213  partym
fec0::9:a00:20ff:fe7b:b373 partym

    This step enables the boot scripts to use the system names without depending on nonexistent naming services.

  3. On each system, create the file /etc/inet/ipsecinit.conf.

    You can copy the file /etc/inet/ipsecinit.sample to the file /etc/inet/ipsecinit.conf.

  4. Add the IPsec policy entry to the ipsecinit.conf file.

    1. On the enigma system, add the following policy to the ipsecinit.conf file:


      {laddr enigma raddr partym} ipsec {auth_algs any encr_algs any sa shared}

    2. On the partym system, add the same policy to its ipsecinit.conf file:


      {laddr partym raddr enigma} ipsec {auth_algs any encr_algs any sa shared}

      For the syntax of IPsec policy entries, see the ipsecconf(1M) man page.

  5. On each system, add a pair of IPsec SAs between the two systems.

    You can configure Internet Key Exchange (IKE) to create the SAs automatically. You can also add the SAs manually.

    Note –

    You should use IKE unless you have good reason to generate and maintain your keys manually. IKE key management is more secure than manual key management.

  6. Reboot each system.


    # /usr/sbin/reboot

  7. Verify that packets are being protected. See How to Verify That Packets Are Protected.

Example—Securing Traffic Between Systems Without Rebooting

The following example describes how to test that the traffic between two systems is secure. In a production environment, it is safer to reboot than to run the ipsecconf command.

Instead of rebooting at Step 5 of How to Secure Traffic Between Two Systems, do one of the following options.

Caution – Caution –

Read the warning when you execute the ipsecconf command. A socket that is already latched, that is, the socket is in use, provides an unsecured back door into the system. For more extensive discussion, see Security Considerations for ipsecinit.conf and ipsecconf.

How to Secure a Web Server

A secure web server allows web clients to talk to the web service. On a secure web server, traffic that is not web traffic must pass security checks. The following procedure includes bypasses for web traffic. In addition, this web server can make nonsecured DNS client requests. All other traffic requires ESP with Blowfish and SHA algorithms. Other traffic also uses a shared SA for outbound traffic. Shared SAs reduce the number of SAs that must be generated.

  1. On the system console, become superuser or assume an equivalent role.

    Note –

    Logging in remotely exposes security-critical traffic to eavesdropping. Even if you somehow protect the remote login, the security of the system is reduced to the security of the remote login session.

  2. Determine which services need to bypass security policy checks.

    For a web server, these services include TCP ports 80 (HTTP) and 443 (Secure HTTP). If the web server provides DNS name lookups, the server might also need to include port 53 for both TCP and UDP.

  3. Create a file in the /etc/inet directory for the web server policy. Give the file a name that indicates its purpose, for example IPsecWebInitFile. Type the following lines in this file:


    # Web traffic that web server should bypass.
	{lport  80 ulp tcp dir both} bypass {}
	{lport 443 ulp tcp dir both} bypass {}

	# Outbound DNS lookups should also be bypassed.
	{rport 53 dir both} bypass {}

	# Require all other traffic to use ESP with Blowfish and SHA-1.
	# Use a shared SA for outbound traffic, in order to avoid a
	# large supply of security associations.
	{} permit {encr_algs blowfish encr_auth_algs sha}
	{} apply {encr_algs blowfish encr_auth_algs sha sa shared}

    This configuration enables only secure traffic to access the system, with the bypass exceptions that are described in Step 2.

  4. Read the file that you created in Step 3 into the /etc/inet/ipsecinit.conf file.


    # vi  /etc/inet/ipsecinit.conf 
 :r IPsecWebInitFile
 :wq!

  5. Protect the IPsecWebInitFile file with read-only permissions.


    # chmod 400 IPsecWebInitFile

  6. Secure the web server without rebooting. Choose one of the following options.

    • If you are using IKE for key management, stop and restart the in.iked daemon.


      # pkill in.iked
# /usr/lib/inet/in.iked

    • If you are manually managing keys, use the ipseckey and ipsecconf commands.


      # ipseckey -f /etc/inet/secret/ipseckeys 
# ipsecconf -a /etc/inet/IPsecWebInitFile

      If you have existing entries in the ipsecinit.conf file, the file generates errors when read again.

    Caution – Caution –

    Read the warning when you execute the ipsecconf command. A socket that is already latched, that is, the socket is in use, provides an unsecured back door into the system. For more extensive discussion, see Security Considerations for ipsecinit.conf and ipsecconf. The same warning applies to restarting the in.iked daemon.

    You can also reboot. Rebooting ensures that the IPsec policy is in effect on all TCP connections. At reboot, the TCP connections use the policy in the IPsec policy file.

    The web server now allows only web-server traffic, as well as outbound DNS requests and replies. No other services work without enabling IPsec on a remote system.

  7. (Optional) To enable a remote system to communicate with the web server for nonweb traffic, put the following policy in a remote system's ipsecinit.conf file.

    A remote system can communicate securely with the web server for nonweb traffic only when their IPsec policies match.


    # Communicate with web server about nonweb stuff
#
{saddr webserver} permit {encr_algs blowfish encr_auth_algs sha}
{saddr webserver} apply {encr_algs blowfish encr_auth_algs sha sa shared}

How to Set Up a Virtual Private Network (VPN)

This procedure shows you how to set up a VPN by using the Internet to connect two networks within an organization. The procedure then shows you how to secure the traffic between the networks with IPsec.

This procedure extends the procedure, How to Secure Traffic Between Two Systems. In addition to connecting two systems, you are connecting two intranets that connect to these two systems. The systems in this procedure function as gateways.

This procedure assumes the following setup:

For a description of VPNs, see Virtual Private Networks. The following figure describes the VPN that this procedure configures.

Diagram shows details of VPN between Europe and California offices.

This procedure uses the following configuration parameters.

Parameter 

Europe 

California 

System name 

enigma 

partym 

System intranet interface 

hme1 

hme1 

System Internet interface 

hme0 

hme0 

System intranet address, also the -point address in Step 8

10.16.16.6 

10.1.3.3 

System Internet address, also the -taddr address in Step 8

192.168.116.16 

192.168.13.213 

Name of Internet router 

router-E 

router-C 

Address of Internet router 

192.168.116.4 

192.168.13.5 

Tunnel name 

ip.tun0

ip.tun0

  1. On the system console on one of the systems, become superuser or assume an equivalent role.

    Note –

    Logging in remotely exposes security-critical traffic to eavesdropping. Even if you somehow protect the remote login, the security of the system is reduced to the security of the remote login session.

  2. Turn off IP forwarding. Choose one of the following options:

    • On IPv4 networks, use this syntax:


      # ndd -set /dev/ip ip_forwarding 0

    • On IPv6 networks, use this syntax:


      # ndd -set /dev/ip6 ip6_forwarding 0

    Turning off IP forwarding prevents packets from being forwarded from one network to another network through this system. For a description of the ndd command, see the ndd(1M) man page.

  3. Turn on IP strict destination multihoming. Choose one of the following options:

    • On IPv4 networks, use this syntax:


      # ndd -set /dev/ip ip_strict_dst_multihoming 1

    • On IPv6 networks, use this syntax:


      # ndd -set /dev/ip6 ip6_strict_dst_multihoming 1

    Turning on IP strict destination multihoming ensures that packets for one of the system's destination addresses arrive at the correct destination address.

    When you use the ndd command to turn off IP forwarding and turn on IP strict destination multihoming, fewer packets flow all the way through the system. When strict destination multihoming is enabled, packets that arrive on a particular interface must be addressed to one of the local IP addresses of that interface. All other packets, even ones addressed to other local addresses of the system, are dropped.

  4. Disable most network services, and possibly all network services, by doing the following substeps, as needed:

    1. Edit the inetd.conf file to remove all but essential services. Then, force the inetd daemon to reread the inetd.conf file.


      # pkill -HUP inetd
      Note –

      The VPN router should allow very few incoming requests. You need to disable all processes that accept incoming traffic. For example, you might comment out lines in the inetd.conf file, you might kill SNMP, and so on. Alternatively, you can use techniques that are similar to the techniques in How to Secure a Web Server.

    2. If the inetd.conf file has not been edited to remove all but essential services, kill the the inetd daemon.


      # pkill inetd

    3. Disable other Internet services, such as SNMP, NFS, and so on, by typing the appropriate commands. For example, the following commands kill the NFS service and the mail service:


      # /etc/init.d/nfs.server stop
# /etc/init.d/sendmail stop

      The disabling of network services prevents IP packets from doing any harm to the system. For example, an SNMP daemon, a telnet connection, or an rlogin connection could be exploited.

  5. On each system, add a pair of SAs between the two systems.

    Configure IKE to manage the keys for the SAs. Use one of the procedures in Configuring IKE (Task Map) to configure IKE for the VPN.

    If you have an overriding reason to manually manage the keys, see How to Manually Create IPsec Security Associations.

  6. On each system, edit the /etc/inet/ipsecinit.conf file to add the VPN policy.

    1. For example, on the enigma system, type the following entries into the ipsecinit.conf file:


      # LAN traffic can bypass IPsec.
   {laddr 10.16.16.6 dir both} bypass {}

# WAN traffic uses ESP with 3DES and MD5.
   {} ipsec {encr_algs 3des encr_auth_algs md5}

    2. On the partym system, type the following entries into the ipsecinit.conf file:


      # LAN traffic can bypass IPsec.
   {laddr 10.1.3.3 dir both} bypass {}

# WAN traffic uses ESP with 3DES and MD5.
   {} ipsec {encr_algs 3des encr_auth_algs md5}

    The ipsec entry prevents remote systems from sending clear packets. The bypass entry allows nodes that are part of the LAN to treat the VPN router as if the router were part of the LAN.

  7. (Optional) For a higher level of security, remove the LAN bypass entry.

    The entry in the ipsecinit.conf file would appear similar to the following:


    # All traffic uses ESP with 3DES and MD5.
   {} ipsec {encr_algs 3des encr_auth_algs md5}

    Each system on the LAN would then need to activate IPsec to communicate with the VPN router.

  8. On each system, configure a secure tunnel, ip.tun0.

    The tunnel adds another physical interface from the IP perspective. Type the following three ifconfig commands to create the point-to-point interface:


    # ifconfig ip.tun0 plumb

# ifconfig ip.tun0 system1-point system2-point \
tsrc system1-taddr tdst system2-taddr encr_algs 3DES encr_auth_algs MD5

# ifconfig ip.tun0 up

    1. For example, on the enigma system, type the following commands:


      # ifconfig ip.tun0 plumb

# ifconfig ip.tun0 10.16.16.6 10.1.3.3   \
tsrc 192.168.116.16 tdst 192.168.13.213 \
encr_algs 3DES encr_auth_algs MD5

# ifconfig ip.tun0 up

    2. On the partym system, type the following commands:


      # ifconfig ip.tun0 plumb

# ifconfig ip.tun0 10.1.3.3 10.16.16.6  \
tsrc 192.168.13.213 tdst 192.168.116.16 \
encr_algs 3DES encr_auth_algs MD5

# ifconfig ip.tun0 up

    The policy that is passed to the ifconfig commands must be the same as the policy in the ipsecinit.conf file. Upon reboot, each system uses the policy in its ipsecinit.conf file.

  9. On each system, turn on IP forwarding for the hme1 and ip.tun0 interfaces. Choose one of the following options:

    • On IPv4 networks, use this syntax:


      # ndd -set /dev/ip hme1:ip_forwarding 1
# ndd -set /dev/ip ip.tun0:ip_forwarding 1

    • On IPv6 networks, use this syntax:


      # ndd -set /dev/ip6 hme1:ip6_forwarding 1
# ndd -set /dev/ip6 ip.tun0:ip6_forwarding 1

    IP forwarding means that packets that arrive from somewhere else can be forwarded. IP forwarding also means that packets that leave this interface might have originated somewhere else. To successfully forward a packet, both the receiving interface and the transmitting interface must have IP forwarding turned on.

    Because the hme1 interface is inside the intranet, IP forwarding must be turned on for hme1. Because ip.tun0 connects the two systems through the Internet, IP forwarding must be turned on for ip.tun0.

    The hme0 interface has its IP forwarding turned off to prevent an outside adversary from injecting packets into the protected intranet. The outside refers to the Internet.

  10. On each system, ensure that routing protocols do not advertise the default route within the intranet.


    # ifconfig hme0 private

    Even if hme0 has IP forwarding turned off, a routing protocol implementation might still advertise the interface. For example, the in.routed protocol might still advertise that hme0 is available to forward packets to its peers inside the intranet. Setting the interface's private flag prevents these advertisements.

  11. Manually, add a default route over hme0.

    The default route should be a router with direct access to the Internet.


    # pkill in.rdisc
# route add default router-on-hme0-subnet

    1. For example, on the enigma system, add the following route:


      # pkill in.rdisc
# route add default 192.168.116.4

    2. On the partym system, add the following route:


      # pkill in.rdisc
# route add default 192.168.13.5

      Even though the hme0 interface is not part of the intranet, hme0 does need to reach across the Internet to its peer system. To find its peer, hme0 needs information about Internet routing. The VPN system appears to be a host, rather than a router, to the rest of the Internet. Therefore, you can use a default router or run the router discovery protocol to find a peer system. For more information, see the route(1M) and in.routed(1M) man pages.

  12. Ensure that hme0 uses the default route after a reboot by creating a defaultrouter file.

    Put the IP address of hme0's default router in the /etc/defaultrouter file. This step prevents the in.rdisc daemon from being started at reboot.

    1. For example, on the enigma system, add the Internet router for enigma in the /etc/defaultrouter file.


      # vi /etc/defaultrouter

192.168.116.4 router-E

    2. Add the partym system's Internet router in partym's /etc/defaultrouter file.


      # vi /etc/defaultrouter

192.168.13.5 router-C

  13. On each system, prevent routing from occurring early in the boot sequence, thus reducing vulnerability.


    # touch /etc/notrouter

  14. Ensure that the VPN starts after a reboot by editing the /etc/hostname.ip.tun0 file.


    system1-point system2-point tsrc system1-taddr \
tdst system2-taddr encr_algs 3des encr_auth_algs md5 up

    1. For example, on the enigma system, add the following lines to the hostname.ip.tun0 file:


      10.16.16.6 10.1.3.3 tsrc 192.168.116.16 \
tdst 192.168.13.213 encr_algs 3DES encr_auth_algs MD5 up

    2. On the partym system, add the following lines to the hostname.ip.tun0 file:


      10.1.3.3 10.16.16.6 tsrc 192.168.13.213 \
tdst 192.168.116.16 encr_algs 3DES encr_auth_algs MD5 up

  15. On each system, create a file that configures some VPN parameters at boot time. Name the file /etc/rc3.d/S99vpn_setup.

    On each system, turn on IP forwarding for the hme1 and ip.tun0 interfaces. Choose one of the following options:

    • On an IPv4 network, type the following lines in the file:


      ndd -set /dev/ip hme1:ip_forwarding 1
ndd -set /dev/ip ip.tun0:ip_forwarding 1
ifconfig hme0 private
in.routed

    • On an IPv6 network, type the following lines in the file:


      ndd -set /dev/ip6 hme1:ip6_forwarding 1
ndd -set /dev/ip6 ip.tun0:ip6_forwarding 1
ifconfig hme0 private
in.routed

    You can also manually add routes in the /etc/rc3.d/S99vpn_setup file, instead of using the in.routed protocol.

  16. On each system, run a routing protocol.


    # in.routed

How to Generate Random Numbers

If you are entering keys manually, the keying material should be random. The format for keying material is hexadecimal.

If your site has a random number generator, use that generator. Otherwise, you can use the od command with the /dev/random Solaris device as input. For more information, see the od(1) man page.

  1. Generate random numbers in hexadecimal format.


    % od -x|-X -A n file
    -x

    Displays the octal dump in hexadecimal format. Hexadecimal format is useful for keying material. The hexadecimal is printed in 4-character chunks.

    -X

    Displays the octal dump in hexadecimal format. The hexadecimal is printed in 8-character chunks.

    -A n

    Removes the input offset base from the display.

    file

    Serves as a source for random numbers.

    For example, the following commands print hexadecimal numbers.


    % od -X -A n /dev/random | head -2
         d54d1536 4a3e0352 0faf93bd 24fd6cad
         8ecc2670 f3447465 20db0b0c c83f5a4b
% od -x -A n /dev/random | head -2
         34ce 56b2 8b1b 3677 9231 42e9 80b0 c673
         2f74 2817 8026 df68 12f4 905a db3d ef27

  2. Combine the output to create a key of the appropriate length.

    Remove the spaces between the numbers on one line to create a 32-character key. A 32-character key is 128 bits. For a security parameter index (SPI), you can use an 8-character key.

How to Manually Create IPsec Security Associations

Although manual management of IPsec security associations (SAs) is not recommended for security reasons, you can do so. The following procedure works with the procedure, How to Secure Traffic Between Two Systems. You first create SAs with the ipseckey command. You then place the keying material in the ipseckeys file.

  1. Generate the keying material for the SAs.

    You need three hexadecimal random numbers for outbound traffic, and three hexadecimal random numbers for inbound traffic. Therefore, one system needs to generate the following numbers:

    • Two hexadecimal random numbers as the value for the spi keyword. One number is for outbound traffic. One number is for inbound traffic. Each number can be up to eight characters long.

    • Two hexadecimal random numbers for the MD5 algorithm for AH. Each number must be 32 characters long. One number is for dst enigma. One number is for dst partym.

    • Two hexadecimal random numbers for the 3DES algorithm for ESP. For a 192-bit key, each number must be 48 characters long. One number is for dst enigma. One number is for dst partym.

    If you have a random number generator at your site, use the generator. You can also use the od command. See How to Generate Random Numbers for the procedure.

  2. On the system console on one of the systems, become superuser or assume an equivalent role.

    Note –

    Logging in remotely exposes security-critical traffic to eavesdropping. Even if you somehow protect the remote login, the security of the system is reduced to the security of the remote login session.

  3. Enable the ipseckey command mode:


    # ipseckey

>

    The > prompt indicates that you are in ipseckey command mode.

  4. If you are replacing existing SAs, flush the current SAs.


    > flush
>

    To prevent an adversary from having time to break your SAs, you need to replace the keying material.

    Note –

    You must coordinate key replacement on communicating systems. When you replace the SAs on one system, the SAs must also be replaced on the remote system.

  5. To create SAs, type the following command.

    You also use this syntax to replace SAs that you have just flushed.


    > add protocol spi random-hex-string \
src addr dst addr2 \
protocol-prefix_alg protocol-algorithm  \
protocol-prefixkey random-hex-string-of-algorithm-specified-length
    random-hex-string

    Specifies a random number of up to eight characters in hexadecimal format. Precede the characters with 0x. If you enter more numbers than the security parameter index (SPI) accepts, the system ignores the extra numbers. If you enter fewer numbers than the SPI accepts, the system pads your entry.

    protocol

    Specifies either esp or ah.

    addr

    Specifies the IP address of one system.

    addr2

    Specifies the IP address of the peer system of addr.

    protocol-prefix

    Specifies one of encr or auth. The encr prefix is used with the esp protocol. The auth prefix is used with the ah protocol. The option encr_auth_alg is used with the esp protocol.

    protocol-algorithm

    Specifies an algorithm for ESP or AH. Each algorithm requires a key of a specific length.

    Authentication algorithms include MD5 and SHA. Encryption algorithms include 3DES and AES.

    random-hex-string-of-algorithm-specified-length

    Specifies a random hexadecimal number of the length that is required by the algorithm. For example, the MD5 algorithm requires a 32-character string for its 128-bit key. The 3DES algorithm requires a 48-character string for its 192-bit key.

    1. For example, on the enigma system, type the following commands to protect outbound packets. Use the random numbers that you generated in Step 1.


      > add esp spi 0x8bcd1407 \
src 192.168.116.16 dst 192.168.13.213 \
encr_alg 3DES \
encrkey d41fb74470271826a8e7a80d343cc5aae9e2a7f05f13730d

> add ah spi 0x18907dae \
src 192.168.116.16 dst 192.168.13.213 \
auth_alg MD5 \
authkey e896f8df7f78d6cab36c94ccf293f031

>
      Note –

      The peer system must use the same keying material.

    2. Still in ipseckey command mode on the enigma system, type the following commands to protect inbound packets:


      > add esp spi 0x122a43e4 \
src 192.168.13.213 dst 192.168.116.16 \
encr_alg 3des \
encrkey dd325c5c137fb4739a55c9b3a1747baa06359826a5e4358e

> add ah spi 0x91825a77 \
src 192.168.13.213 dst 192.168.116.16 \
auth_alg md5 \
authkey ad9ced7ad5f255c9a8605fba5eb4d2fd

>
      Note –

      The keys and SPI can be different for each SA. You should assign different keys and a different SPI for each SA.

  6. To exit ipseckey command mode, press Control-D or type quit.

  7. To ensure that the keying material is available to IPsec at reboot, add the keying material to the /etc/inet/secret/ipseckeys file.

    The lines of the /etc/inet/secret/ipseckeys file are identical to the command line language.

    1. For example, the /etc/inet/secret/ipseckeys file on the enigma system would appear similar to the following:


      # ipseckeys - This file takes the file format documented in 
#   ipseckey(1m).
#   Note that naming services might not be available when this file
#   loads, just like ipsecinit.conf.
#
# for outbound packets on enigma
add esp spi 0x8bcd1407 \
   src 192.168.116.16 dst 192.168.13.213  \
   encr_alg 3DES \
   encrkey  d41fb74470271826a8e7a80d343cc5aae9e2a7f05f13730d
#
add ah spi  0x18907dae \
   src 192.168.116.16 dst 192.168.13.213 \
   auth_alg MD5  \
   authkey  e896f8df7f78d6cab36c94ccf293f031
#
# for inbound packets
add esp spi 0x122a43e4 \
   src 192.168.13.213 dst 192.168.116.16 \
   encr_alg 3DES \
   encrkey dd325c5c137fb4739a55c9b3a1747baa06359826a5e4358e
#
add ah spi  0x91825a77 \
   src 192.168.13.213 dst 192.168.116.16 \
   auth_alg MD5  \
   authkey  ad9ced7ad5f255c9a8605fba5eb4d2fd

    2. Protect the file with read-only permissions.


      # chmod 400 /etc/inet/secret/ipseckeys

  8. Repeat Step 2 through Step 7 on the partym system. Use the same keying material that was used on enigma.

    The keying material on the two systems must be identical. As shown in the following example, only the comments in the ipseckeys file differ. The comments differ because dst enigma is inbound on the enigma system, and outbound on the partym system.


    # partym ipseckeys file
#
#for inbound packets
add esp spi 0x8bcd1407 \
   src 192.168.116.16 dst 192.168.13.213  \
   encr_alg 3DES \
   encrkey  d41fb74470271826a8e7a80d343cc5aae9e2a7f05f13730d
#
add ah spi  0x18907dae \
   src 192.168.116.16 dst 192.168.13.213 \
   auth_alg MD5  \
   authkey  e896f8df7f78d6cab36c94ccf293f031
#
# for outbound packets
add esp spi 0x122a43e4 \
   src 192.168.13.213 dst 192.168.116.16 \
   encr_alg 3DES \
   encrkey dd325c5c137fb4739a55c9b3a1747baa06359826a5e4358e
#
add ah spi  0x91825a77 \
   src 192.168.13.213 dst 192.168.116.16 \
   auth_alg MD5  \
   authkey  ad9ced7ad5f255c9a8605fba5eb4d2fd

How to Verify That Packets Are Protected

To verify that packets are protected, test the connection with the snoop command. The following prefixes can appear in the snoop output:

Note –

You must be superuser or have assumed an equivalent role to read the snoop output. You must have access to both systems to test the connection.

  1. On one system, such as partym, become superuser.


    % su 
Password: Type root password
#

  2. In a terminal window, begin to snoop the packets from a remote system, such as the enigma system.


    # snoop -v enigma
Using device /dev/hme (promiscuous mode)

  3. In another terminal window, remotely log in to the enigma system. Provide your password. Then, become superuser, and send a packet from the enigma system to the partym system.


    % rlogin enigma
Password: Type your password
% su 
Password: Type root password
# ping partym

  4. In the snoop window on the partym system, you should see output that is similar to the following:


    IP:   Time to live = 64 seconds/hops
IP:   Protocol = 51 (AH)
IP:   Header checksum = 4e0e
IP:   Source address = 192.168.116.16, enigma
IP:   Destination address = 192.168.13.213, partym
IP:   No options
IP:
AH:  ----- Authentication Header -----
AH:
AH:  Next header = 50 (ESP)
AH:  AH length = 4 (24 bytes)
AH:  <Reserved field = 0x0>
AH:  SPI = 0xb3a8d714
AH:  Replay = 52
AH:  ICV = c653901433ef5a7d77c76eaa
AH:
ESP:  ----- Encapsulating Security Payload -----
ESP:
ESP:  SPI = 0xd4f40a61
ESP:  Replay = 52
ESP:     ....ENCRYPTED DATA....

ETHER:  ----- Ether Header -----
ETHER:
ETHER:  Packet 20 arrived at 9:44:36.59
ETHER:  Packet size = 98 bytes
ETHER:  Destination = 8:0:27:aa:11:11, Sun
ETHER:  Source      = 8:0:22:aa:22:2, Sun
ETHER:  Ethertype = 0800 (IP)
ETHER:
IP:   ----- IP Header -----
IP:
IP:   Version = 4
IP:   Header length = 20 bytes
IP:   Type of service = 0x00
IP:         xxx. .... = 0 (precedence)
IP:         ...0 .... = normal delay
IP:         .... 0... = normal throughput
IP:         .... .0.. = normal reliability
IP:         .... ..0. = not ECN capable transport
IP:         .... ...0 = no ECN congestion experienced
IP:   Total length = 84 bytes
IP:   Identification = 40933
IP:   Flags = 0x4
IP:         .1.. .... = do not fragment
IP:         ..0. .... = last fragment
IP:   Fragment offset = 0 bytes
IP:   Time to live = 60 seconds/hops
IP:   Protocol = 51 (AH)
IP:   Header checksum = 22cc
…