## Troubleshooting

Also see Frequently Asked Questions and Where to Go for More Information.

### Is Intel® Packet Protect running?

Run the Intel Packet Protect Monitor:

> From the Start menu, select: Programs > Packet Protect > Packet Protect Monitor.

On a system running Windows NT, where the Policy Agent has been manually shut off, it is automatically started when the Monitor program is started. You can also check Intel Packet Protect by going to the Services control panel and look for the Intel Policy Agent. Its status should be "running".

On a system running Windows 98 and Windows ME, follow the instructions in Turn Security On.

### Intel Packet Protect doesn't start automatically upon startup

At the computer, make sure that Intel Packet Protect is started as a service. See Turn Security On.

### Communication fails

If an Intel Packet Protect system cannot communicate with another system, check the following:

- Verify that each system's basic security settings are set to allow communication. If the systems are using advanced security settings, verify that the systems have matching rules. The rules must allow for a match between ESP and AH settings for the security action.

- If using pre-shared keys, verify that each system is set up to use the same pre-shared key when communicating with each another. Note that pre-shared keys are case-sensitive.

- At the client, verify that Intel Packet Protect is running. Click the Start button on the taskbar, select Settings > Control Panel. Double-click Services and verify that Intel® Policy Agent is started.

- Make sure the policy allows communication with the DNS. For further information see Common Security Exceptions.

- Check the Intel Packet Protect Log file. See Viewing the log entries in Windows 98 and Windows ME and Viewing the log entries in Windows NT

If these steps do not resolve the issue, you will need to either reboot the system (necessary with Windows 98 and Windows ME), or temporarily stop and then restart the Intel Policy Agent process (rebooting the system is not necessary).

### Communication fails between Intel Packet Protect and Windows 2000 IPSec

Some versions of Windows 2000 are using DES policies instead of 3DES. If the server has Intel Packet Protect installed, and the rule used involve only 3DES (in various combinations) there will be no communication between Windows 2000 clients and the Intel Packet Protect server. To enable the use of 3DES you have to install the Windows 2000 High Encryption Pack. This is available from the Microsoft support site: http://www.microsoft.com/windows2000/downloads/recommended/encryption/.

If you make a change to the system policy, communication to systems running Windows 2000 may fail. This will only happen if certificates are installed and unused (Windows 2000 does not support Entrust* certificates). To correct this situation, you must temporarily stop and then restart the Intel Policy Agent process.

#### Communication fails after changing the system policy

Communication may fail between Intel Packet Protect and systems running Windows 2000 when the following conditions are met:

- You make a change to the system policy that affects one or more systems that are using pre-shared keys.

- Those systems are running Windows 2000 IPSec as client (respond-only).

- The system on which you are making the system policy change has Entrust*/Entelligence* certificate support installed and enabled.

- Communication (e.g., file transfer) is occurring from the time the policy change is made until a few seconds after the Packet Protect restart message closes.

To correct this problem:

1. Stop the communication attempt.

2. Stop Intel Packet Protect.

3. Re-start Intel Packet Protect.

4. Resume communications.

To avoid this problem in the future, make sure to stop all traffic before system policy changes are made, and until a few seconds after the Packet Protect restart message closes.

### Communication fails when passing through a firewall

Depending on the type of firewall, IPSec may affect the deployment in different ways:

- Some firewalls block outside-in traffic without performing network address translation (NAT). These firewalls can sometimes be configured to allow IPSec traffic to flow from within the network.

- Proxy-enabled firewalls use a variety of protocols to forward traffic, such as HTTP, Telnet, FTP, SOCKS, and other application proxies. With these firewalls, IPSec cannot be used to protect traffic end to end. IPSec can be used within the local LAN, but all outside traffic will remain unprotected.

- If a gateway or firewall is present, performing network address translation, IPSec cannot be applied because IPSec packets are encrypted and integrity-protected, making address and port substitution impossible.

The effects of IPSec on firewall policies vary greatly on the type and goals of the firewalls. Refer to your firewall vendor for information on IPSec support.

### Communication fails after installing an additional network adapter

NOTE: This condition occurs only when using Windows NT.

After the system has re-started:

1. Open the control panel and select "Services"

2. Ensure that "Intel Policy Agent" has NOT re-started.

3. Open Network Properties, open the Adapters tab, select an Intel PRO/100 adapter.

4. Click the Update button, enter the path to the software, and continue.

5. Close the Network Properties window and select reboot when the option is given.

You can avoid this problem when setting up other multi-adapter systems by following the installation instructions in the Set Up Adapters section.

### Failures reported in the Intel Packet Protect Audit Log

See the Event Logging section.

### Multicast, Broadcast, and IGMP traffic isn't protected

Multicast traffic is always unprotected when you use Intel Packet Protect because of IPSec standards. In addition, IGMP traffic is unprotected. The side effect of that is that the machine will still accept packets from unauthenticated users. This may lead to a possible misuse.

### Certificate Installation Fails ("Missing KMPAPI32.DLL" message)

If you get a "Missing KMPAPI32.DLL" error message during Intel Packet Protect certificate support installation, you will need to download and install the Entrust* EntrustIPSec* Negotiator* Toolkit:

1. Using your Internet web browser, go to http://www.entrust.com/developer/ipsec/

2. Select "Download".

3. Enter your member ID and PIN if necessary.

4. Select a download location on your hard drive.

5. Using the Windows Explorer, find and run the EntrustIPSec installer program.

6. After installation, go to the directory c:\Program Files\Entrust Toolkit\IPSec\Lib\ and move "KMPAPI32.DLL" to C:\Windows\System\. (Windows NT users: move the file to C:\WinNT\System32\)

7. Re-start the Intel Packet Protect certificate support installation.

### Problems during Certificate Installation process

If you have problems logging in to Entrust/Entelligence, it may be due to an improper setting in the Entrust .INI file:

1. Using a text editor, open /Winnt/entrust.ini

2. Locate the tag "FipsMode".

3. Set the value to 0.

4. Save and close the file.

If you get an error message, "Intel Packet Protect Credential Store (CS) component problem: failed to get the subject name in the certificate", it could be due to a duplicate conflicting profile name. To resolve this, log out of Entrust/Entelligence, then start up the Certificate Installer again.

If you cancel the Intel Packet Protect Certificate Support installation process before it completes, all currently configured rules will be lost. You can however recover the default rule:

1. Open the Intel Packet Protect utility.

2. Click on the Recreate Default Rule button under the Security tab.

You can then re-enter your customized rules that were deleted.

### I changed the IP address or name of a computer, now it can't communicate on the network

If you have custom rules, there may be other systems in the network that have an old IP address or computer name for the changed system in their rules. These rules must be modified to reflect the IP address/computer name change.

### I think some transmitted information is unprotected and it shouldn't be

- Is Packet Protect running?

- Make sure the IPSec option in PROSet is enabled.

- Check the security action settings of both systems to make sure they match. Also try to determine which rule is being applied to the communication. If the rule is set to allow the communication if the rule fails, the systems will transmit data "in the clear" (without security).

- When a system begins communication with another system, the first few seconds are allowed in the clear if the rule being used is a fallback clear setting or if there are no matching rules and the behavior is Secure Initiator or Secure Responder.

- Check the Security Exceptions tab to make sure that communication is not taking place over unprotected ports.

Copyright © 2002 Intel Corporation. Legal Information