Run the Intel Packet Protect Monitor:
Select Start > Programs > Packet Protect > Packet Protect Monitor.
On a system running Windows NT, the Policy Agent has been manually shut off, it is automatically started when the Monitor program is started.
On a system running Windows 98, follow the instructions in Turn Security On.
At the computer, make sure that Intel Packet Protect is started as a service. See Turn Security On.
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.
If these steps do not resolve the issue, you will need to either reboot the system (necessary with Windows 98), or temporarily stop and then restart the Intel Policy Agent process without rebooting.
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 doing 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.
Multicast traffic is always unprotected when you use Intel Packet Protect because of IPSec standards. In addition, IGMP traffic is unprotected.
In order to perform certificate installation, you must first install Entrust/Entelligence*. If this is not done first, you will get a "Missing KMPAPI32.DLL" error message. Use the Entrust/Desktop Designer to install Entrust/Entelligence. The installer will give you several installation options. Be sure to select "IPSEC" in the "Engines" category.
This will enable IPSec and properly copy over the KMPAPI32.DLL file. Additional details at http://www.entrust.com/entelligence/new/desktop.htm
This DLL must be placed in the \Winnt\system32 directory.
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:
Using a text editor, open /Winnt/entrust.ini
Locate the tag "FipsMode".
Set the value to 0.
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 certificate installation before it completes, all currently configured rules will be lost. You can however recover the default rule:
Open the Intel Packet Protect utility.
Click on the Recreate Default Rule button under the Security tab.
You can then re-enter your customized rules that were deleted.
If you have custom rules, there may be other systems in the network that have an old IP address or DNS name of a system in their rules. These rules must be modified to reflect the IP address/DNS name change.
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).
Check the default behavior. If both systems use Secure Responder or No Security, they will always communicate in the clear. If none of the rules applies to the communication, the communication is unprotected if the default behavior is Secure Initiator or Secure Responder.
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.
If you are running Windows NT and it is acting sluggish or erratic, and has been running for many days or weeks without a reboot, try the following.
Press Ctrl-Alt-Delete.
The Windows NT Security panel appears.
Select Task Manager.
Select the Processes tab.
(NOTE: If you do not see a column labeled "VM Size," choose the
View menu, then Select Columns. In the Select Columns dialog box, select
Virtual Memory Size. Close the dialog box.)
Examine the VM usage for the "pagent" process. Normal VM usage is 3,000 - 5,000 Kbytes.
If virtual memory usage is over 10,000 Kbytes, you must either reboot the system, or temporarily stop and then restart the Intel Policy Agent process without rebooting.
Close the Windows NT Security panel.
To restart the Policy Agent in Windows 98, you must reboot the system.
If an IPSec enabled client needs to communicate with a server that has a combination of IPSec enabled and non-IPSec adapters, the client must have an explicit rule in the IPSec Policy that allows communication to the server with no security:
destination work group = <server's non-ipsec ip address>
security action = allow communication in the clear
Copyright © 2000, Intel Corporation. All rights reserved.
Intel Corporation assumes no responsibility for errors or omissions in this document. Nor does Intel make any commitment to update the information contained herein.
* Other product and corporate names may be trademarks of other companies and are used only for explanation and to the owners' benefit, without intent to infringe.