Skip to main content


Why You Should Consider Using IPsec Now

Published: February 16, 2011

Author: Rodrigo Immaginario, Microsoft MVP - Enterprise Security: Engineering

You may have heard the use of Internet Protocol security (IPsec) with virtual private network (VPN) connections, but have you heard of using IPsec transport mode? 

Security projects based solely on perimeter protection are no longer sufficient. Given the diversity of scenarios, clients, and devices, we need to expand our project security to address several factors, including:

  • Remote access - Customers with remote access
  • Partner access  - Access local and remote computers that are not part of their field
  • Wireless access - Access to data anywhere in the enterprise
  • Network - Allow network access only to computers registered;

One of the first experiences I had with IPsec was through a 2005 project at the where I work. We needed a solution to improve our security on the local area network (LAN). Toward this, the project needed to address the following requirements: 

  • Only trusted machines have access to data on your Servers
  • Restricted access to some servers and services 
  • Some servers and services restricted to a group of users / computers
  • Low budget (there was no budget for replacement of network assets, if we chose 802.1x security options)

We decided to implement a Server and Domain Insulation solution based on IPsec in order to achieve the following objectives: 

  • Unknown (untrusted) machines get no access to our data
  • Encryption of sensitive data (Optional feature)
  • Policy-based centralization
  • Transparent to the user 

It is true that with Windows Server 2003, it can be complex to develop a project based on IPsec policies. This is primarily due to the configuration of policies without a user-friendly interface. However this problem has been eliminated with changes on since Windows Server 2008. Several issues that could cause problems, or generate more implementation effort, have been resolved in the newest iteration of the operating system. 

In comparison with Windows Server 2003, the number of policies required to use IPsec in Windows Server 2008 have been greatly reduced. In addition, the following factors improve functionality of IPsec with Windows Server 2008: 

  • Integration with Windows Firewall with Advanced Security
  • Best performance for fallback, Windows Vista and later send both connection, IPsec and in-IPsec. 

The example that follows illustrates the differences between IPsec scripts for Windows Server 2003 and Windows Server 2008: 

IPsec script – Windows Server 2003:

pushd ipsec static
set store location=local
# Actions
add filteraction name="Block" description="Block Access" action=block
add filteraction name="Allow" description="Allow Access" action=permit
add filteraction name="Secure" description="Allow inbound connections with IPsec, Allow outbound connections clear" soft=yes action=negotiate qmsecmethods="ESP[None,SHA1] ESP[3DES,SHA1]"
# Exception
add filterlist name="Exception" description="Computer out of IPsec Policy"
add filter filterlist="Exception" srcaddr=any dstaddr=x.x.x.x description="Computer I" protocol=any srcport=0 dstport=0
# Domain Controllers
add filterlist name="Domain Controllers" description="Domain Controllers"
add filter filterlist="Domain Controllers" srcaddr=any dstaddr=x.x.x.x description="DC-01" protocol=any srcport=0 dstport=0
# Secure Network
add filterlist name="Secure Network" description="Secure Network"
add filter filterlist="Secure Network" srcaddr=any dstaddr=any description="Secure Network" protocol=any srcport=0 dstport=0
# Enable PING
add filterlist name="Enable PING" description="Enable PING"
add filter filterlist="Enable PING" srcaddr=any dstaddr=me description="Enable PING" protocol=ICMP
# Create Policy
add policy name="IPSEC Policy" description="IPsec Policy" activatedefaultrule=no mmlifetime=180 assign=no pollinginterval=60 mmsecmethods="3DES-SHA1-2 3DES-MD5-2 DES-SHA1-1 DES-MD5-1"
# Add Rules
add rule name="Secure Network" policy="IPsec Policy" filterlist="Secure Network" filteraction="Secure" rootca="C=BR, O=XXX, CN=XXXXX"
add rule name="Enable PING" policy="IPsec Policy" filterlist="Enable PING" filteraction="Allow" rootca="C=BR, O=XXX, CN=XXXXX"
add rule name="Domain Controllers" policy="IPsec Policy" filterlist="Domain Controllers" filteraction="Allow" rootca="C=BR, O=XXX, CN=XXXXX"
add rule name="Exception" policy="IPsec Policy" filterlist="Exception" filteraction="Allow" rootca="C=BR, O=XXX, CN=XXXXX"
# Turn on
set policy name=”IPsec Policy" assign=YES

IPsec script – Windows Server 2008

netsh advfirewall consec add rule name="Secure Network" endpoint1=any endpoint2=any action=requireinrequestout auth1=computercert auth1ca="C=BR, O=XXX, CN=XXXXX "

netsh advfirewall consec add rule name="Domain Controllers" endpoint1=any endpoint2=x.x.x.x,y.y.y.y action=noauthentication

netsh advfirewall consec add rule name="Exception" endpoint1=any endpoint2=x.x.x.x action=noauthentication

And the future of IPsec?

You’ve likely already heard of Internet Protocol version 6 (IPv6), and probably know that on February 3, 2011, the last IPv4 address blocks have been allocated by APNIC to the regional number authorities, meaning that the internet is now officially out of available IPv4 addresses.

One of the new connectivity features in Windows 7 and Windows Server 2008 R2 is DirectAccess, which enables remote users to securely access corporate resources and sites without connecting through a VPN.

With DirectAccess, we can say that we are taking the first step toward the use of IPv6. In fact, DirectAccess is nothing more than a set of policies using an IPv6 infrastructure secured with IPsec. Of course, this is a generalization, and there are other technologies [Name Resolution Policy Table (NRPT), Teredo, 6to4, ISATAP, etc.] that are necessary for DirectAccess to work. Nonetheless, DirectAccess is one of the first features to demonstrate the power of IPv6 and how various parameters change with with this protocol. 

Using DirectAccess requires the following:

  • Digital certificate infrastructure/public key infrastructure (PKI) (or Kerberos)
  • Windows 7 for client computers (computers must be part of the domain)
  • Windows Server 2008 R2 for servers 
  • IPv6

**If you use theForefront Unified Access Gateway (UAG) you can extend the solution and enable access to non DA/IPv6 servers, like Windows 2003.

DirectAccess has benefits for end users and network administrators: 

For end users:

  • Configurations are not necessary. Computers connected to the user Internet will have “always on” access to the internal network. 
  • You do not need doors opened for access, the network firewall you're using, as is necessary for a VPN connection 

For system administrators: 

  • Domain policies are applied in remote computers 
  • Support for Network Access Protection (NAP)
  • Management of remote machines 

Are you ready?

About the Author

Rodrigo Immaginario photoRodrigo Immaginario has worked in the computer science field since 1994, specializing in security solutions for Microsoft environments including those involving IPsec, Hyper-V, and DirectAccess. His certifications include Certified Information Systems Security Professional (CISSP) and Microsoft Certified Systems Engineer (MCSE) in Security. He has been a Microsoft Most Valuable Professional MVP since 2004.

He is currently Chief Information Officer at the Universitario Vila Velha in Brazil and he developed a post-graduate course in Microsoft .NET.  

Microsoft Security Newsletter

Sign up for a free monthly roundup of security news, bulletins, and guidance for IT pros and developers.