Before getting into the actual configuration of IPSec policies, you should also have an awareness of a key determination protocol called OAKLEY. Basically, OAKLEY is the one on each computer that works in conjunction with ISAKMP and is responsible for generating and managing the authenticated keys that are ultimately used to secure IPSec communications.
Now that that’s all settled, lets take a look at actually setting up IPSec policies. Actually, before we get there, you should have an awareness of the three IPSec policies that exist by default, and what they means. Found in the Computer Configuration section of group policy under \Windows Settings\Security Settings\IPSec Policies, the there policies that exist are Client (Respond Only), Secure Server (Require Security), and Server (Request Security). Note that none of the policies are assigned by default, and that only one IPSec policy can be assigned on a system at any given point in time. The default policies:
Client (Respond Only) – As the name suggests, this policy is meant for client systems primary. This policy outlines that IPSec security should only be used in response to a request by a server. As such, a client with this policy assigned will make all requests unsecured, but if a server requests security, is capable of responding using IPSec security.
Server (Request Security) – This policy, meant mainly for servers, will request that a client use a secured connection if assigned. The caveat here is that the server will only ask. If a client is not capable of using security (or has no policy configured), it will still allow unsecured communication. Think of this policy as provided best-effort IPSec security.
Server (Require Security) – Again a policy meant for servers, this one is a little harsh, and probably won’t meet your needs. If configured, this server requires IPSec security from all connections, right from the get-go. Make an unsecured request and you won’t be asked, informed, or otherwise – you’ll simply be denied.