Configuring windows PCs to use IPSec

Using windows server 2008 and windows 7 / vista, it actually becomes quite easy to secure internal traffic using IPSec. This is quite a good security feature to implement, since it’s no longer the case that internal traffic can be sent in cleartext, considering most attacks happen on the inside due to disgruntled employees, browser attacks and so on. In this article, I’ll explain how to use Windows Firewall with Advanced Security (WFAS) to secure communication between two internal PCs (a client and webserver).

The easiest way I found of doing this is by using a Connection Security Rule enforcing an isolation policy. This means that only encrypted traffic will be allowed to reach the server. Any traffic that is not encrypted and authenticated will result in the client’s browser showing the “Internet Explorer cannot display this page”

I’m assuming you already have a webserver and a client PC joined to the domain. In my case the nodes have the IPs:

Web Server : 10.91.2.58

Windows 7 Client : 10.91.2.57

First step is to define this Connection Security Rule and push it out to all involved parties via GPO.

On the domain controller:

• Open “Active Directory Users and Computers”. Here, you can create an Organizational Unit and move the webserver and client computer objects to this OU
• Start > Run > gpmc.msc. Here. expand your domain and find the newly created OU. Right click and use the “Create a GPO in this domain, and link it here”

 

Edit the created GPO, and navigate to Computer Configuration > Windows Settings > Security Secttings > Windows Firewall With Advanced Security > WFAS – LDAP… > Connection Security Rules. Right click on the right plane and select “new rule”

• Select “Isolation” as a rule type
• Select “require authentication for inbound and outbound connections” as a requirement. This is the most stringent requirement that can be set.
• Select an appropriate authentication method. In this case, I will setup a pre-shared key method for brevity, but not that in production this is not a good idea because the pre-shared key is stored in cleartext on the PCs (yea… brilliant idea Microsoft…). So in this case I chose “Advanced” and hit the “customize” button where we can use a Preshared Key as the first authentication method:

• Select the appropriate profile and name
• At this stage the wizard quits, but the rule will apply for any any all communications. This may not be ideal. In fact in my case I would like to restrict the scope of this rule so only communication between my client and server is protected. So right click on the rule, select properties and use the “computers” tab to enter the IP addresses as different endpoints:

**** Now we’re done.

On the webserver and client:

• Run gpudate or similarly ensure the computers update their group policy. If you open WFAS on the machine, you should see the Connection Security Rule in place:

On the client, now try to open a browser and navigate to the internal website. The website should load successfully:

if you open the WFAS and expand “Monitoring > Security Associations” you should see an entry under both “Main Mode” and “Quick Mode”

That confirms you’re using IPSec. Also, running a packet capture to double check, we see no HTTP, just IPSec 🙂

 

Some troubleshooting tips and misc notes:

• During my setup, I also tried manually configuring the connection rule on the server and client. When I tested this, it was not working. When checking the Monitoring > Security Associations I noticed that while I had an entry in the “Main Mode” folder, I did not have an entry in “Quick mode”. As any good firewall administrator will tell you, that’s a sign that the two Connection Security Rules on the server and client are different. It turn out that windows 7 ultimate can define what protocol and ports to use in the rule, while Windows Server 2008 cannot (2008 R2 can):

Turns out I had selected “protocol type” as TCP out of habit. Since this did not match what I had defined on the server, the IPSec failed. Since the server did not support this, I had to change it back to “Any”. This highlights why it’s better to define the connection security rules via GPO rather than manually.

• I struggled a bit with the relationship between the “encrypt” action in the inbound / outbound rules and the connection security rules.

After some testing of these, it turns out that:

-  The connection security rules are “enablers”

-  The inbound / outbound rules are “enforcers”

So, strictly speaking only security connection rules are required to setup an IPSec relationship, since if there are no such rules the computer is unable to actually make an IPSec connections .You can then use the inbound/outbound rules to enforce your policy, for example allowing unencrypted communication only to certain PCs, and forcing encryption to all the rest.