VPN Solutions Lesson 10 April 2004 etoken Certification Course
VPN Overview Lesson 10a April 2004 etoken Certification Course
Virtual Private Network A Virtual Private Network (VPN) is a private data network that uses the public telecommunication infrastructure. VPNs accomplish this by allowing the user to tunnel through the Internet or another public network in a manner that provides the same security and features formerly available only in private networks (leased lines) but cheaper. Privacy is maintained through the use of a tunneling protocol and security procedures Communication across the VPN is encrypted.
How Safe is a Password? One-factor authentication memorized password only seriously weakens VPN system security Typed passwords can be easily copied or hacked Users often select short, easy to remember passwords Passwords seldom changed, often written down and left in easily accessible places Users have difficulty remembering several passwords for different applications and so, use the same password for all their access needs
Using Digital Certificates for Authentication Digital certificates provide a reliable method for verifying the identity of a user. The client presents client certificate to the dial-in server providing strong user authentication via a challenge responese mechanism. The server presents a server certificate to the client provides assurance that the user has reached the server that he/she expected. A chain of thrusted authorities verifies the validity of the certificates. The user s certificate can be stored on the client machine or in an external smartcard. The certificate can be accessed after the user s identification (two factor authentication).
VPN and etoken Using IPSEC Certificates Generated and Stored On etoken Generate an IPSEC certificate with on-board 1024-bit keys created in the etoken keys are secure Two factor authentication in front of the gateway using a PKI certificate. The gateway verifies the authentication in front of the CA After secure authentication, a VPN connection is established using the IPSEC/IKE encryption method Simple integration, the user installs etoken PKI Client, no further configuration is necessary
Firewall gateway Internet Firewall gateway Corporate LAN Encrypted information Decrypted information
Common Uses of VPNs Connect remote users to the Enterprise LAN over the Internet (local ISP). Remote access to corporate resources. Connect branch offices to the corporate LAN (router, dialup). Access to protected resources within the LAN
The Benefits of Using a VPN ISP ISP ISP ISP Low Cost Scalable Flexible Secure ISP ISP ISP
Virtual Private Network Privacy is maintained through: Tunneling protocol Firewall servers User access authentication Data encryption Transit Internetwork Virtual Private Network Logical Equivalent
Tunneling Protocols The tunneling protocol encapsulates the packet in an additional header. The additional header provides routing information so that the encapsulated packet can pass the internetwork. IP Security (IPSec) Tunnel Mode allows IP packets to be encrypted and then encapsulated in IP header to be sent across a corporate IP or public IP network. Layer 2 Tunneling Protocol (L2TP) Allows traffic to be encrypted and then sent through a medium that supports Point-to-Point Datagram delivery, such as: IP, X.25, Frame relay, ATM.
How VPNs work - Tunnel Layer 3 - Network layer IPSec Used for site to site and remote user to site communications Can authenticate and encrypt data 7-Layer OSI Model Application Layer Presentation Layer Session Layer Layer 2 - Data link layer L2TP (EAP-TLS) Used for remote user to site communications L2TP can authenticate only Transport Layer Network Layer Data Link Layer Physical Layer
IPSec Architecture IPSec is defined by the following sets of specifications: Security Associations (SA) Internet Key Exchange (IKE, ISAKMP,OAKLY) Authentication header protocol (AH) Encapsulated security protocol (ESP) Protocol modes. (Transport and tunnel mode) Encryption algorithms
IKE Negotiation Two Phases Phase 1 Negotiate two way SAs Uses certificates or pre-shared secrets Main mode or aggressive mode Phase 2 Negotiate IPSEC (AH, ESP, Tunnel, Transport) Phase 2 always uses quick mode because we are already authenticated
Internet Key Exchange (IKE) Authenticates peers Pre-shared keys Public key cryptography Digital signatures Negotiates policy to protect communication Key exchange Diffie-Hellman IKE 1st IPSec Next
IKE In IP security, there are two types of SAs: IKE SA : used for securing key negotiations. IPSEC SA : used for securing IP data. When two IP entities wish to secure IP data between them, the following will occur: Negotiate IKE SA. Use IKE SA to negotiate IPSEC SA. Use IPSEC SA to encrypt IP data. The IKE SA is long term. It will typically be used to secure many IPSEC SA negotiations.
Key Management
IKE Basic concept in IKE: Security Association (SA). An SA contains all information necessary for two entities to exchange secured messages. Each SA has an identifier, sometimes called an SPI. Example SA: SPI: 12345 Encryption algorithm: DES HMAC algorithm: MD5 Encryption key: 0x65f3dde HMAC key: 0xa3b443d9 Expiry: 15:06:09 13Oct98
IKE The negotiation of IKE SAs is called Phase 1. Phase 1 is authenticated using either PKI or pre-shared secrets. There are two types of Phase 1 negotiations: Main Mode and Aggressive Mode. Aggressive Mode is more efficient (shorter negotiation), but does not provide identity protection. Negotiating IPSEC SAs is called Phase 2. There is only one type of Phase 2 negotiation called Quick Mode.
IKE Phase 1: First Message Pair Phase 1 Main Mode consists of three pairs of messages. Remember: goal is to establish an IKE SA First pair: Negotiation of parameters for the IKE SA: algorithms, authentication type, expiry. Alice We can do 3DES and SHA1, or DES and MD5 Let s do 3DES and SHA1 Bob ISAKMP Policy Tunnel
IKE Phase 1: Second Message Pair Second pair: Exchange of cryptographic data. Goal is to establish a shared secret between two entities: Alice Here s a DH public key, and some random data Here s a DH public key, and some random data Alice and Bob both compute a shared secret which is a function of the DH keys and the random data. Bob Note: the DH key is used only for this exchange, and then thrown away.
Diffie Hellman Internet
IKE Phase 1 Some notes before the third pair of messages: Alice and Bob now have a shared secret, and they can use it to encrypt the third pair of messages. First and second pairs do not provide any authentication. Alice and Bob could be masquerading, or Eve could be attacking using the man-in-the-middle technique. Furthermore, Alice and Bob do not know who they are negotiating with. All they know is an IP address from which the messages are arriving.
IKE Phase 1: Third Message Pair Third pair of messages is encrypted. The goal is to exchange identities, prove the identities, and retroactively authenticate all the previous messages. The authentication can be based on either pre-shared secrets, or on PKI. Example: I m alice@wonderland.com. Here s an HMAC over all the data we exchanged, using our pre-shared secret. Alice I m 204.53.10.4. Here s an HMAC over all the data we exchanged, using our pre-shared secret.. Bob Result of negotiation is a single, bi-directional IKE SA.
IKE Phase 2 Phase 2 is always secured by an IKE SA. The IKE SA provides secrecy, authentication, and data integrity. Remember: The goal is to establish an IPSEC SA. Three messages in Phase 2: Message 1: Suggestion of parameters, and identities for whom we re negotiating. Message 2: Choice of parameters, and HMAC signature on first message. Message 3: HMAC signature on previous messages. HMAC signatures use a key from the IKE SA.
IKE Phase 2 Example Phase 2 (simplified) exchange: Let s do either ESP DES/MD5, or AH SHA1. I m negotiating on behalf of subnets 189.63.71.0 and 204.53.10.0. Here s some random data. Alice Let s use AH SHA1. Here s an HMAC of the previous message using our IKE SA HMAC key. Here s some random data Bob Here s an HMAC of the previous messages using our IKE SA HMAC key.
IKE Phase 2 Remarks: The keys in the resulting IPSEC SA are a function of the IKE SA key and the random data. The result of the negotiation are two uni-directional IPSEC SAs, each with a distinct SPI (SPIs are also part of the negotiation). The SAs can only be used to encrypt IPSEC traffic between the negotiated identities. Identity types are IP addresses, IP ranges, IP subnets.
IPSec Modes (Transport and Tunnel) Transport Mode: Used for Peer to Peer communication security Data is encrypted Tunnel Mode: Used for site-to-site communication security Entire packet is encrypted.
IPSec Overview: Headers Encapsulated Security Payload All Data-Encrypted Router IP HDR AH Data Router Authentication Header Two types: Encapsulated Security Payload (ESP) and Authentication Header (AH) Data integrity no modification of data in transit Origin authentication identifies where data originated AH does not provide confidentiality, industry moving toward ESP which does
AH (Authentication Header) IP Protocol 51 Provides authentication of packets Does not encrypt the payload Transport Mode IP Hdr AH TCP/UDP Data Tunnel Mode New IP Hdr AH Org. IP Hdr TCP/UDP Data
ESP (Encapsulating Security Payload) IP Protocol 50 Encrypts the payload Provides encryption and authentication Transport Mode IP Hdr IP Hdr AH ESP TCP/UDP Data Tunnel Mode New IP Hdr AH ESP Org. IP Hdr TCP/UDP Data
Basic difference between AH and ESP
Layer 2 Tunneling Protocol Combines and extends PPTP and L2F (Cisco supported protocol) Does not include packet authentication, data integrity, or key management Must be combined with IPSec for enterprise-level security Remote L2TP Client Corporate Network L2TP Server Internet ISP L2TP Concentrator
L2TP over IPSEC
L2TP over IPSEC
EAP-TLS Developed by Microsoft Provides strong mutual authentication, credential security, and dynamic keys Requires distribution of certificates to all users as well as RADIUS servers A certificate management infrastructure is required (PKI)
EAP Protocol-overview 802.1X is a transport mechanism. The actual authentication takes place in the EAP-protocol on top of 802.1X. MD5 TLS TTLS PEAP MS-CHAPv2 EAP 802.1X PPP 802.11
Tunneling Protocols For a tunnel to be established, both the tunnel client and the tunnel server have to run the same tunneling protocol. The tunnel client or server uses a tunnel transfer protocol to prepare data for transfer. EAP Extensible Authentication Protocol Extension to PPP that allows the validation of PPP connection through authentication mechanisms. EAP allows the dynamic addition of authentication plug-in modules, at the client and the server. This enables vendors to supply a new authentication scheme at any time. For example: using public key certificates for user authentication.
EAP over 802.1x Extensible Authentication Protocol (RFC 2284) provides an architecture in which several authentication mechanisms can be used EAP-MD5 Username/Password (not safe) EAP-TLS PKI (certificates), strong authentication MS-CHAPv2 Microsoft Username/Password (not safe)
VPN Clients Supported by etoken Check Point SecuRemote Cisco Microsoft Nortel Intel Network Privacy F-Secure SecGO NCP Netscreen Celestix Neoteris Netilla Siemens And more...
etoken for Microsoft VPN Lesson 10d April 2004 etoken Certification Course
Microsoft VPN Windows 2000 remote access provides two different types of remote access connectivity: Dial-up remote access (RAS) Virtual private network (VPN) remote access
Dial-up remote access To gain access to the network with dial-up remote access, a remote access client uses the public telephone network to create a physical connection to a port on a remote access server that sits on the edge of the private network. This is typically done by using a modem or ISDN adapter to dial into your remote access server
Authenticating Dial-up remote access users Secure Mutual authentication is obtained by authenticating both ends of the connection through the encrypted exchange of user credentials. This is possible with the PPP remote access protocol using the EAP-Transport Level Security (EAP-TLS). During mutual authentication, the remote access client authenticates itself to the remote access server, and then the remote access server authenticates itself to the remote access client.
RAS Data Encryption Windows 2000 remote access clients and remote access servers support the Microsoft Point-to-Point Encryption Protocol (MPPE). In order to use MPPE for Data Encryption The authentication protocol must be either EAP-TLS or MS-CHAP MPPE uses the RC4 stream cipher and either 40-bit, 56-bit, or 128-bit secret keys. MPPE keys are generated from the EAP-TLS user authentication process
Virtual private network (VPN) remote access A VPN can provide secure remote access through the Internet, rather than through direct dial-up connections. A VPN client uses an IP internetwork to create an encrypted, virtual, point-to-point connection with a VPN gateway that exists on the edge of the private network. This is typically done by connecting to the Internet first, and then creating the VPN connection..
Windows 2000 supports two types of VPN : Point-to-Point Tunneling Protocol (PPTP) Layer 2 Tunneling Protocol over IP Security (L2TP/IPSec).
PPTP vs. L2TP PPTP requires that the transit internetwork be an IP internetwork. L2TP requires only that the tunnel media provide packet-oriented point-to-point connectivity- NO NAT!!! L2TP provides tunnel authentication, while PPTP does not. PPTP uses PPP encryption and L2TP does not.
Authenticating VPN remote access users Secure Mutual authentication is obtained by authenticating both ends of the connection through the encrypted exchange of user credentials. This is possible with the PPP remote access protocol using the EAP- Transport Level Security (EAP-TLS). Machine authentication is performed as well only when using L2TP over IPSEC
EAP-TLS The Extensible Authentication Protocol (EAP) can be used to provide an added layer of security to VPN technologies such as PPTP and L2TP. EAP allows this functionality through Certificate Authority (CA) and Smart Card technologies, which provide mutual authentication of client and server. The server must be configured to accept EAP authentication as a valid authentication method and have a user certificate (X.509). The client must be configured to use EAP, and either have a Smart Card (with a Smart Card certificate installed).
VPN Data Encryption for PPTP Windows 2000 remote access clients and remote access servers support the Microsoft Point-to-Point Encryption Protocol (MPPE). In order to use MPPE for Data Encryption The authentication protocol must be either EAP-TLS or MS- CHAP MPPE uses the RC4 stream cipher and either 40-bit, 56-bit, or 128-bit secret keys. MPPE keys are generated from the EAP-TLS user authentication process
VPN Data Encryption for L2TP Use IPSec to encrypt the data all the way from the sending computer to the destination computer. This is called end-to-end encryption.
Configure and Enable RRA 1. Right click on the Server Name and choose Configure and Enable Routing and Remote Access.
Routing and Remote Access Setup Wizard 2. Click on Next on the Welcome to the Routing and Remote Access Server Setup Wizard screen. 3. Select Manually configured server, then click Next.
RRAS Wizard 4. Click on Finish. 5. The Routing and Remote Access window will appear, click Yes to start the service.
Change Properties of Server 6. Right click on the Server name (CPVPN (local) in the above window) and choose Properties.
Setting up IP properties 7. Under IP address assignment, select Static address pool. 8. Click on Add button. 9. The New Address Range window appears. Enter a Start IP address and End IP address & click OK to continue
Setting up Security on the Server 10. Next, click the Security tab and click the Authentication Methods button 11. Click to select the Extensible authentication protocol (EAP) check box, and then click OK.
Configuring Routing and Remote Access to Accept EAP The server should have a computer certificate installed. Configure EAP to support public key authentication using smartcards. Start the Routing and Remote Access snap-in.
Configuring Routing and Remote Access to Accept EAP Right-click the server name, click Properties, and click the Security tab. Click Authentication Methods
Configuring Routing and Remote Access to Accept EAP Select Extensible authentication protocol (EAP) and click on EAP Methods.
Enabling EAP in Remote Access Policies Click Edit Profile, and then click the Authentication tab. The following window is displayed: Select the Extensible Authentication Protocol. Select Smartcard or other Certificate. 12. Click Configure. And select the certificate that will be used for the sever side authentication
Changing Ports Properties Next, you will need to configure the PPTP and L2TP ports. 13. In the RRAS interface, right click on Ports, and select Properties.
Configuring the WAN Miniport By default, a computer running Windows 2000 Server and the Routing and Remote Access service is a PPTP and L2TP server with five L2TP ports and five PPTP ports. To create a PPTP-only server, set the number of L2TP ports to zero. To create an L2TP-only server, set the number of PPTP ports to zero.
Configuring the WAN Miniport (PPTP) 14. To configure the PPTP ports, select "WAN Miniport (PPTP)" and click Configure. 15. Because you are not creating server-to-server tunnels with this server, deselect Demand-dial routing connections (inbound and outbound). Increase the number of ports as necessary for your environment (up to 16,384 maximum). In this example, 128 ports are configured. Click OK.
Configuring the WAN Miniport (L2TP) 17. Since you are not using IPSec in this example, there is no need for L2TP ports. Select WAN Miniport (L2TP) and click Configure. Change the number of ports to zero. Click OK. 18. You may receive a notice indicating that current connections might be disconnected. Click Yes because there are no current connections right now. 19. Once back in the Ports Properties dialog, click OK.
Remote Access Logging 20. From the RRAS MMC interface, select Remote Access Logging. 21. Double click on Local File. 22. Select Log authentication requests from the Settings tab. Click OK.
Remote Access Policies 23. From the RRAS MMC interface, select Remote Access Policies. 24. In the right pane, double-click Allow access if dial-in permission is enabled.
Editing User rights 25. Click on Start Administrative Tools Active Directory Users and Computers
Editing User rights 26. Click on the Users folder under your domain name. 27. Right click on the user you want to enable remote access permissions for, and choose Properties. This user should be the same user that you used when you created a certificate with the Active Directory Logon.
Granting Remote Access to a User 28. Click on the Dial-in tab. Select to Allow remote access permissions into your network.
Setting a VPN Client Prerequisites: Windows 2000/XP machine etoken PKI Client 3.51 and up A Certificate stored on the user s etoken The certificate should have a Client Authentication property to be used for MS-VPN authentication. Microsoft CA certificate templates that can be used: SmartCard logon SmartCard user User The following Slides will demonstrate how to enroll Smartcard certificates. Other methods of certificate creation i.e. via MMC are optional as well.
Issuing Smartcard Certificates from Microsoft CA
Enabling the Smartcard Certificate Template on the CA Proper security permissions should be set on the following certificate templates: Smartcard Logon Smartcard User Enrollment Agent Required steps for enabling the templates: Logon with administrator rights to the certification authority (CA) Through Administration Tools, open Certification Authority
Enabling the Smartcard Certificate Template on the CA Enable the certificate templates that are used for Windows logon: In the console tree, click Policy Settings
Enabling the Smartcard Certificate Template on the CA On the Action menu, point at New, and click Certificate to Issue
Enabling the Smartcard Certificate Template on the CA Click on Smartcard User and/or Smartcard Logon and Enrollment Agent certificate templates, and click OK The security setting of a certificate template should be set to read and enroll for the appropriate users
Creating Enrollment Agent Certificate on etoken
Creating Enrollment Agent Certificate on etoken 1. Install etoken PKI Client on the computer from which you will enroll the certificates to the users etokens 2. Logon as the user or administrator who will enroll the certificates 3. Enrollment agent certificate can be issued through the CA enrollment web page or through the Active Directory MMC, using the Certificate Request Wizard
Creating an Enrollment Agent Certificate on an etoken Install the Enrollment Agent certificate on the enrollment agent s etoken Launch URL: http://servername/certsrv, where servername is your CA server At the Welcome window, select Request a Certificate
Creating an Enrollment Agent Certificate on an etoken Select: Submit a certificate request to this CA
Creating an Enrollment Agent Certificate on an etoken Select Advanced Request
Creating an Enrollment Agent Certificate on an etoken Select Certificate Template: Enrollment agent Select CSP: etoken Base Cryptographic provider Select the certificate s Key Size
Creating an Enrollment Agent Certificate on an etoken When prompted insert the etoken password Click OK to set this certificate as the default Enrollment Agent certificate, as displayed below
Creating an Enrollment Agent Certificate on an etoken Now simply click Install this certificate and the Enrollment agent certificate will be stored on the etoken
Enrolling Smartcard Certificates for Users
Enrolling Smartcard Certificates for Users 1. Insert the Enrollment agent etoken to the machine. 2. Insert the user s etoken to the machine as well. 3. Launch URL: http://servername/certsrv, where servername is your CA server. 4. From the Welcome window, select Request a Certificate. - Move to next slide.
Enrolling Smartcard Certificates for Users Select Request a certificate
Enrolling Smartcard Certificates for Users 5. Select Advanced request, click Next.
Enrolling Smartcard Certificates for Users 6. Select Request a certificate for a smartcard on behalf of another user using the Smartcard Enrollment Station, and click Next.
Enrolling Smartcard Certificates for Users 7. Choose the etoken Base Cryptographic Provider.
Enrolling Smartcard Certificates for Users 8. Select the required certificate template Smartcard Logon or Smartcard User 9. In the Certificate Authority field, select CA configured to issue smartcard certificates 10. For the Cryptographic Service Provider, select the etoken Base Cryptographic Service Provider 11. The Administrative Signing Certificate should display the enrollment agent certificate requested in the previous section 12. For the User to Enroll, select the domain user from the list. - Move to next slide.
Enrolling Smartcard Certificates for Users 13. Insert the user s etoken password when prompted. 14. The certificate and keys are generated and stored on the user s etoken.
Enrolling Smartcard Certificates for Users 15. You can now click on View Certificate to check the certificate details, or New User to enroll another user with a different etoken.
Creating a New VPN Connection Network and Dialup Connections Wizard 1. Click on Start Settings Network and Dialup Connections If you have already configured a Network and Dialup Connections, you will see an arrow pointing to the right. Click on Start Settings Network and Dialup Connections Make New Connection, skip to step 3.
Make New Connection 2. Double click on Make New Connection.
New Connection Wizard 3. Click on Next to create a connection. 4. Choose Connect to a private network through the Internet. Choose Next.
Make New Connection 5. Enter the IP address of the computer you are connecting to. 6. To test the connection configuration Choose Do not use my smartcard.
Connection Availability 7. Choose For all users, and click Next. 8. Check the Add a shortcut to my desktop checkbox. Click Finish.
Test the VPN Connection without etoken 9. Double click on Virtual private connection. 10. Enter Password for the User 11. Two Confirmation windows should appear as shown below.
Modify Connection to Use etoken 12. Click on Start Control Panel Network and Dial-up Connections. 13. Right click on the Virtual Private Connection and choose Properties. 14. Click on the Security tab. 15. Click on the Advanced tab
VPN Connection with etoken 1. Double click on Virtual private connection on the desktop. 2. Enter the etoken Password under Smartcard Pin. 3. You may see that it is verifying username and password. 4. It may ask to accept this connection, press OK. This will only appear the first time you use the etoken to login. 5. A Confirmation window should appear, press OK.
Troubleshooting
Event Logging The Windows 2000 Router performs extensive error logging in the system event log. Four levels of logging are available. Take specific steps if an OSPF router is unable to establish an adjacency on an interface. The level of event logging can be set from various places with the Routing and Remote Access snap-in. Logging consumes system resources and should be used sparingly.
Tracing RRAS has an extensive tracing capability that you can use to troubleshoot complex network problems. Tracing records internal component variables, function calls, and interactions. You can enable tracing for each routing protocol by setting the appropriate registry values. Tracing consumes system resources and should be used sparingly. To enable file tracing for each component, you must set specific values within the registry.
Authentication and Accounting Logging RRAS supports the logging of authentication and accounting information for PPP-based connection attempts when Windows authentication or accounting is enabled. The authentication and accounting information is stored in a configurable log file or files. You can configure the type of activity to log and log file settings.
Setting up Event Logging Click the Event Logging tab and choose Log the maximum amount of information. This helps with troubleshooting connection problems. You are now finished configuring the properties of the VPN server. Click OK.
Basic L2TP/IPSec Troubleshooting in Windows If the Virtual Private Network (VPN) client is behind any network device performing Network Address Translation (NAT), the L2TP session fails because encrypted IPSec Encapsulating Security Payload (ESP) packets become corrupted.
Basic L2TP/IPSec Troubleshooting in Windows If a computer certificate is not found, L2TP issues a warning that you do not have a certificate, but it does not know whether the certificate has a properly installed and associated private key for the existing certificate. Internet Key Exchange (IKE) determines this during negotiation. Start the Local Computer Certificates snapin, double-click Certificate, and verify that General indicates "You have a private key that corresponds with this certificate." Also verify that the certificate path is complete, and that the certificate is valid.
Basic L2TP/IPSec Troubleshooting in Windows The client must have a machine certificate whose root certificate authority is the same as the certificate on the gateway certificate. The reason for the certificate failure is noted by IKE in the security log event entry.
Troubleshooting L2TP/IPsec You can verify whether IPSec is succeeding by running Ipsecmon.exe (as local admin) with options set to refresh at one-second intervals. If you see the IPSec SA appear, it indicates that IPSec succeeded, and you may conclude that L2TP is the source of the problem. Use the netdiag /test:ipsec /v /debug command to see the details of IPSec policy (you cannot see the whole policy if a domain administrator has set policy on your local computer).
Troubleshooting L2TP/IPsec IKE may time out during the initial negotiation request if routers in front of the VPN server do not allow UDP port 500 through. It also times out if the VPN server does not have appropriate IPSec policy configured, which usually means that the RRAS server does not have L2TP ports enabled, or that a manual IPSec policy setting is misconfigured. When IKE times out, the audit log shows that peer failed to reply, and that a network capture trace shows ISAKMP UDP packets initiating only from your client. If configured specifically for L2TP, the VPN client responds with the following error message: The security negotiation timed out.
Troubleshooting L2TP/IPsec Microsoft Client (Cont ) Error 792 : Security negotiation timeout
Troubleshooting L2TP/IPsec Microsoft Client Error 789 : Security layer encountered a processing error From Start > Control Panel > Administrative Tools, double-click on Services and verify that the IPSec Policy agent is running.
Troubleshooting L2TP/IPsec Microsoft Client (Cont ) Error 786 : No valid machine certificate This error indicates a problem with the certificate on the local machine. Run mmc and add Certificate/ Computer Account snap-in Navigate going to Console Root -> Certificate (Local Computer) -> Personal -> Certificates and verify that the certificate is valid/ not expired. Make sure that the Trusted Root Certificate under the local computer store contains the root CA certificate
Troubleshooting L2TP/IPsec Microsoft Client (Cont ) Enabling Audit Policy for the local PC in the Local Computer Policy snap-in. In the MMC console, From the left pane expend the tree, then navigate to Computer Configuration > Windows Setting > Security Setting > Local Policies and select Audit Policy. From the list of Attributes displayed in the right pane, modify the following: Audit Logon Events, Audit Object Access. For each attribute check, in the Local Policy setting group box, Success, Failure.
Troubleshooting L2TP/IPsec Microsoft Client (Cont ) Navigate to Computer Management > System Tools > Event Viewer and check for additional information
Troubleshooting L2TP/IPsec Microsoft Client (Cont ) Netdiag utility for network diagnostic (must be installed first) In order to test IPSec parameters, execute the command as follows: netdiag/test:ipsec /v /debug Detailed information can be found at /www.microsoft.com/windows2000/techinfo/reskit/tools/existing/netdiago.asp IP Security Monitor Execute ipsecmon to monitor security connections created by the IPSec policy