Creating and Testing a Custom Policy

The following example explains how to create and test a custom IP Security (IPSec) policy called Lockdown, which will secure communication between two Windows 2000 servers that aren't part of a Win2K domain. You need two Win2K systems--any platform will do. In the example, the first system is A and the second system is B. You might not have access to a Certificate Authority (CA), so specify preshared key authentication, although it's the least secure authentication method. (If you do have a CA, you can select the Certificate option in step 11 and pick a CA from the drop-down list.) You'll select Encapsulating Security Payload (ESP) mode to encrypt all packets between the two systems, and you'll define a filter that secures traffic between only these two systems. This example assumes that both systems have a static IP address and that neither system accepts remote connections.

This process is lengthy and detailed, so fill your coffee cup before you start. Fortunately, you can take advantage of Win2K's many IPSec wizards, so make sure the Use Add Wizard option is selected on all the windows in which it appears. You need to create this Lockdown policy on both machines so that you can test whether the policy works. Here's the step-by-step procedure.

1. On system A, start Microsoft Management Console (MMC) and load the IP Security Policy Management snap-in for the local computer.
2. Right-click IP Security Policies on Local Machine, and click Create IP Security Policy.
3. On the welcome screen of the IP Security Policy Wizard, click Next.
4. Type Lockdown as the name of the policy, and click Next.
5. Clear the Activate the default response rule check box, and click Next.
6. Confirm that the Edit Properties check box is selected, and click Finish.
7. On the Lockdown Properties window, confirm that the <Default Response> rule check box is cleared. Confirm that the Use Add Wizard check box (in the lower right corner of the screen) is selected, and click Add to start the Security Rule Wizard.
8. Click Next to advance to the next screen of the Security Rule Wizard.
9. Select the This rule does not specify a tunnel check box, and click Next.
10. Select the Local area network (LAN) check box, and click Next.
11. On the Edit Authentication Method Properties dialog box, which Figure A shows, select Use this string to protect the key exchange (preshared key), enter lockdown as the string, and click OK.
12. On the IP Filter List dialog box, click Add.
13. Name the filter Orange, confirm that Use Add Wizard is selected, and click Add to start the IP Filter Wizard.
14. Click Next.
15. Leave My IP Address as the Source address, and click Next.
16. Choose A specific IP Address from the Destination address drop-down list, enter the other computer's IP address, and click Next.
17. On the IP Protocol Type window, leave Any as the protocol type, and click Next.
18. On the Completing the IP Filter Wizard window, confirm that the Edit Properties check box is cleared, and click Finish.
19. Click Close to return to the IP Filter List window.
20. Select the radio button next to the Orange filter, and click Next.
21. On the Filter Action window, confirm that Use Add Wizard is selected, and click Add.
22. Click Next.
23. Name the Filter Action Orange Juice, and click Next.
24. On the Filter Action General Options window, select Negotiate security, and click Next.
25. Select Do not communicate with computers that do not support IPSec, and click Next.
26. Select High (Encapsulated Secure Payload), and click Next.
27. On the Completing the IP Security Filter Action Wizard window, confirm that Edit Properties is cleared and click Finish.
28. Select the Orange Juice radio button, and click Next.
29. On the Completing the New Rule Wizard window, confirm that Edit Properties is cleared, and click Finish.
30. On the Lockdown Properties window, confirm that the new Orange filter is selected. Click Close to complete the policy.
31. Repeat the procedure on system B. Be sure that you enter system A's IP address in step 15.

TESTING YOUR IPSEC POLICY
To test the policy, assign the Lockdown policy on each machine. After you activate the policy, restart the IPSec Policy Agent to ensure that it loads the new policy. To monitor the success and failure of IPSec key exchanges between systems A and B, enable logon and logoff auditing and look for event IDs 541, 542, and 543 in the Security log. These events contain text similar to "IKE security association established" or "IKE security association ended," as well as the endpoint TCP/IP addresses (e.g., source and destination IP addresses). These event records can also help you troubleshoot connections. (For more information about troubleshooting IPSec connections, see Zubair Ahmad, "Troubleshooting IP Security Problems," http://www.win 2000mag.com/, InstantDoc ID 7831.)

On system A, open a command prompt and ping system B by address. If you correctly created the policy, you'll see four Negotiating IP Security responses, which Figure B shows. On system A, repeat the ping to system B. The second ping should produce four successful ping replies because the first ping created an SA between systems A and B. On system B, ping system A by address to verify that the Lockdown policy is working in both directions.

The IP Security Monitor, which Figure C shows, is a handy tool that monitors active IPSec connections on the local machine. Start the monitor with the Ipsecmon command, which you can run from the command line. After the Lockdown policy is working, running Ipsecmon on system A will display the SA to system B, and vice versa. When you browse shares or copy files between the two systems, Ipsecmon will increment the amount of authenticated data sent and received on each system. If you see Ipsecmon incrementing sent and received bytes, your policy is working--please accept my congratulations.