Is SKIP Working?

Once you have configured and enabled SKIP, you cab determine that it is working properly. If the configurations on the systems do not match (that is, the encryption algorithms used), it will appear as if the other part of the communication equation does not exist. SKIP silently drops the packets. skiplog will log this event.

To verify that SunScreen SKIP is operating properly on your system, complete one or more of the following procedures:

1. Ping the remote system.

   The remote system must have SunScreen SKIP enabled and be using the same key and traffic encryption algorithms as your system.

   If you have the remote site's certificate, you can immediately start sending encrypted IP. Otherwise, SKIP will need to fetch the remote machine's certificate. By default, this is done by asking the remote site for its certificate over a clear channel. If you have configured other hosts to act as key servers, they will be asked for the certificate. See the D pages for skipd and skipd.conf for details. If there are no problems at the remote site, you receive replies when you ping.

   ---

   Note -

   The initial ping can fail because the key manager's computation may exceed the time-out value of some of the IP protocols, such as ping.

   ---

2. Run snoop on your local system or a sniffer to see that packets are being encrypted.

If encryption is not taking place between your system and a system on your authorized systems list or you cannot connect to that system, check the following items.

• Is SKIP enabled? Check the Access Control button. Set it to enabled.

• Verify that a certificate exists for each system you wish to communicate with on your authorized systems list. Use the skipdb command to check for the certificate of the remote system by dumping the database to the screen. Try to restart the key manager by using the skipd_restart command.

• Verify that SKIP is installed, configured, enabled, and has the certificate of the remote system.

• Verify the key ID of the remote system in the log file /var/log/skipd.log to see if the key manager has set the key ID to what you think it should be. If it is not the correct key ID, get certificates for the correct key ID.

• Verify that both machines have the same key encryption, traffic encryption, and authentication algorithms. You can check which ACL entry will be used when communicating with a remote host by using skiphost hostname/IP address command. This command will check default entries, as well as network entries.

• Certificate discovery protocol (CDP) works by sending UDP requests to port 1640 of the server. If you are connecting through a firewall, check with your system administrator that UDP messages are allowed to pass on port 1640. These ports are required for CDP. As a workaround, you can manually distribute keys. Also, make sure that the SKIP protocol 57 (decimal number) and the SKIP Version 1 protocol 79 (decimal number) are permitted to pass through the firewall.

• Some routers also filter packets. Check on the router and its configuration.

• Verify that the CDP server specified in skipd.conf is correct and has been authorized in skiptool. If the cdp_server entry is = or @, it is specifying the tunnel address or host address, respectively.

• SKIP requires that machine clocks be synchronized within one hour. Marke sure they are sysnchronized. Messages in /var/log/skipd.log will indicate this situation. You can use the UNIX command rdate(1M) to synchronize the clocks.

• If the skiplocal -x command has been used to communicate key IDs when one or both of the systems have multiple keys or multiple network interfaces, the key ID may have been bound to the wrong network interface or local key ID. Use skiptool or skiphost to add the remote host after verifying key IDs over the telephone.

• Use skiplog to verify configuration mismatches.