09.03.2008
L2TP/IPsec in Pictures - ISA Server 2006 - Part 2 - VPN Technologies and VPN Solutions

In Part 1, I've mentioned the modern secure VPN Technology words. In this part, we will start a general discussion about VPN technologies and VPN solutions. Since there is a lot to talk about, it will be impossible to speak about every feature, so some aspects may be omitted. Not many pictures will be used in this part (a general discussion).

On the VPN Consortium site there is a white paper discussing three major VPN technologies: trusted VPNs, secure VPNs, and hybrid VPNs. Please follow the bellow link if you want to find out more about them:
VPN Technologies: Definitions and Requirements

Since it's out of the scope of this article we will not explain all three VPN technologies. Instead we will focus on secure VPNs.

Today, high-bandwidth Internet connections are quite cheap. Therefore it has become very popular for road-warriors and branch offices to be securely connected to their HQ through the use of secure VPNs. Even more, in order to increase work productivity, remote working might be seen as a solution, so secure VPN comes once again into action. And not to forget, the parteners/contractors/suppliers which may require site-to-site connectivity or remote access.

Thus, you will end-up with some "basic" needs to address: an insecure path (the Internet) and different security challenges generated by the remote sites or remote clients. See Figure1.

Figure1: Possible Scenarios 

The insecure path: attackers are assumed to have the ability to capture, read, modify, delete or replay messages sent between the communicating hosts.
If we want to securely move sensitive traffic over Internet, messages must be encrypted and integrity protected, and the communicating devices/users must authenticate themselves using strong authentication methods.

Typically, through the use of encryption we want to achieve confidentiality for our data, so an atacker cannot read the information sent. Another form of confidentiality that might be desired is traffic flow confidentiality, an attacker might perform traffic analysis(message length, reveal communicating parties' identities, frequency of transmission).

We understand by integrity: connectionless integrity(proof of the fact that data has not been altered in transit) and data origin authentication(proof that the data was sent by the correct peer).
Since every packet sent can be subject to manipulation from an attacker, integrity needs to be provided per packet.

Packet replay can be used by attackers to gain control of a communication channel. The attacker will capture and record traffic between hosts, analyze the packets and maybe modify some of them. Then the attacker will send these packets back into the data stream in order to hijack the session.
Packet replay is often used by attackers to become authenticated by an unsuspecting host.

An attacker will try weakening the protection afforded for the communication channel. The protocols must not be susceptible to version rollback. The attacker, if possible, will make the talking parties to use weaker crytographic algorithms.

A modern secure VPN technology must be able to defeat these attacks. Throughout these series we will see how L2TP/IPsec stands up against these threats.

A modern secure VPN technology should be an Industry standard-based technology, an Internet Standard, an open standard that has been under intense scrutinity from the Internet community.

A modern enterprise-class VPN solution should be able to deal with the scenarios presented in Figure1.
In order to do that, a VPN solution might incorporate multiple secure VPN technologies like  "pure" IPsec, L2TP/IPsec or SSL VPN.
Each of the remote sites or remote clients can represent a security challenge, generating various threats for the HQ network, thus different authentication methods, levels of protection or security policies for traffic entering and exiting the HQ network may be needed. 

Before you purchase a VPN solution you must carefully analyze your needs, present needs and future needs. You are about to take a very important decision. It can turn into an irreversible one. Let's start a general discussion about various features of a VPN solution that you might need.

A modern enterprise-class VPN solution should provide features like interoperability, flexibility, scalability, availability, access/connectivity from anywhere, performance, support for various crytographic algorithms, a certain level of certification, controlled access/protection out-of-the-box, advanced logging and reporting. Also it should be easy to implement, to use and to maintain.

- Interoperability: a critical feature. For example, when you need to connect to a partner's network, you will very likely need to interoperate with a VPN gateway from another vendor for site-to-site connectivity. If you have multiple branch offices, it may be possible to use for them or for some of them a VPN solution from another vendor. Also, you may need to provide remote access for some contractors, customers or so which are not using the same OS as your VPN clients. You should not lock yourself using a single proprietary implementation that does not include VPN clients for various Operating Systems. Your VPN solution should include an Industry standard secure VPN technology for remote access too.

- Flexibility: this term is somehow ambiguous. The level of flexibility will typicalliy be achieved by a VPN solution by incorporating the features discussed here. Flexible to support various scenarios(site-to-site and remote access), topologies(mesh or hub-to-spoke), access from various places(from behind restrictive firewalls), scalability, easy to use and so on.

- Scalability: your VPN solution may need to scale both vertically and horizontally. To address a high number of VPN clients and site-to-site connections, dependending on the solution you have opted, you can upgrade hardware components(replace CPU, add more RAM, upgrade NICs), distribute VPN sessions across multiple appliances for load balancing or both. You may build yourself an appliance(if you are using an ISA Server 2006: buy the hardware, install the Windows 2003 OS and so on) or opt for a "hardware appliance" (this does not necessary means an appliance from Cisco, Juniper and so on, you can buy an ISA 2006 appliance from Celestix for example).

- Availability: a single point of failure can be inacceptable if VPN connections are critical for your business. If so, you need to distribute VPN sessions across multiple appliances for failover.

- Access/connectivity from anywhere: your road-warriors must be able to connect virtually from anywhere: behind broken NAT devices, behind restrictive firewalls. A single secure VPN technology for remote access like L2TP/IPsec will not handle all these. You need SSL-based remote access too. The term SSL VPN may be ambiguous, some vendors do not offer full network access.

- Performance: very likely you will opt for an integrated security and VPN solution, which will serve as a firewall, IDP/IPS, network antivirus and VPN server. You need to make sure you will not suffer from performance degradation. The firewall might perform stateful packet inspection, application inspection, the VPN server will serve both VPN clients and site-to-site connections.

- Support for various crytographic algorithms: you need to think about present and future needs regarding the use of crytographic algorithms. Performance, security strength and interoperability are key words. Diffie-Hellman 1024 MODP Group or 1024-bit RSA keys offer only 80 bits of security. 80 bits of security are not considered adequate beyond year 2010. Using Diffie-Hellman 2048 MODP Group or 2048-bit RSA keys will enable you to benefit from 112-bits of security, the security strenght of 3DES. For AES, larger keys are needed, which are more resource-intensive to process. Instead, you may consider using Diffie-Hellman ECP Groups (computational speed and efficiency) and ECDSA signatures(smaller signatures, less bandwidth,computational speed and efficiency). The attacks over SHA-1 might make you migrate to the SHA-2 family of hash functions. Additionally you may want to provide overall security consistent with the AES, thus to achieve say 128 bits of security. Regarding the use of AES with IPsec, you need to evaluate the modes of AES (say AES-CBC, AES-CTR, AES-GCM).

- A certain level of certification: you may be interested to search for the FIPS 140-2 Level(cryptographic module certification), Common Criteria certificate(The Evaluation Assurance Level achieved) or to see if the product has received various logos from VPNC. Some vendors are members of the VPNC.
Follow this link to start searching for FIPS 140-2 certificates.
Follow this link to see the FIPS 140-1 and FIPS 140-2 Vendor List
Follow this link to start searching for Common Criteria certificates.
Follow this link to see the VPNC members.
Follow this link to see various VPNC logos and products that have passed various tests(likeBasic Interoperability or AES Interoperability for IPsec, or SSL Portal or SSL File Access for SSL VPN).
Follow this link to see VPNC Members Supported Features for IPsec (VPN clients for various Operating Systems, L2TP/IPsec support, IKE v1 or IKE v2 support, authentication with X.509 certificates, QoS, AES encryption, Diffie-Hellman MODP Group 14 and so on).
Follow this link to see VPNC Members Supported Features for SSL (remote access, SSL Portal, SSL Exchange, Active Directory and/or Radius client authentication, Full network access with SSL plug-in and so on).
Follow this link to see the VPNC Documentation Profiles for IPsec Interoperability.
Regarding ISA Server, follow this link to learn more about the Evaluation Assurance Level. Microsoft is a member of VPNC. ISA Server 2006 was tested for VPNC Basic Interoperability Test and has "passed all tests in both directions with all other participants". Follow this link to see Microsoft's validated FIPS 140-1 and FIPS 140-2 cryptographic modules.

- Controlled Access/Protection out-of-the-box: once you enable the VPN server for remote acces and start creating site-to-site connections, all these must not translate into drilling security holes into your network. For example, on ISA Server 2006, once you've enabled VPN remote access, VPN clients can connect but cannot access anything, a very good security practice as opposed to the allow all by default practice(low security). You have to start creating access rules, allowing only needed traffic(per protocol). And you can do that granular, per user or per group. Controlled-access is critical, but it's only a part of the equation. VPN clients or remote sites can represent an access path for viruses, worms, spyware, keyloggers or Trojan horses into your network. Your application servers are also exposed. A simple stateful packet filtering firewall cannot provide an adequate level of protection for your applications. A traditional signatures-based IDS/IPS(integrated with the VPN server) will offer protection out-of-the-box for known attacks using a database of signatures(some vendors offer more complete and updated database signatures). But this does not protect you against 0-days attacks. Your VPN server may be integrated with a truly application-layer firewall. For example, you may have a web application used between sites or by your VPN clients. On a simple stateful packet filtering firewall this will translate into "open TCP port 80". Indeed, the port is "open" because the firewall will never know if port 80 is used for HTTP traffic. Instead, an application-layer firewall isn't really concerned about ports. With an application-layer firewall you are allowing access per protocols rather than per ports. An application firewall will recongnize if port 80 is really used by HTTP traffic. You may configure your application firewall to block known attacks using signatures(signatures inspection). All requests/responses except the ones containing attacks are allowed. This is known as a negative security model. What about unknown attacks, 0-day attacks ? A positive security model might help here. A positive security model denies everything by default while allows only requests/responses known to be good/valid. For example it can do that using strict-policies. For the best security you should use both models. An application firewall may deliver out-of-the-box protection at a touch of the button if it comes with default policies(negative and/or positive models) for popular applications. So you will not have to analyze those applications in order to figure out what means good traffic and what means bad traffic.

- Advanced logging and reporting: you will need to carefully monitor your VPN users activity. Live monitoring and detailed reports are desired.

- Easy to implement, to use and to maintain: either that you plan a new VPN solution or upgrade an old one, the VPN solution should be easy to implement. Since you are likely to face various scenarios, it should have a simple interface, tasks and configuration should be automated as much as possible saving time and money. Needing too much steps to complete a simple task will increase the likeliness of configuration errors which may translate into possible security holes. The level of expertise needed will increase the costs. Also the VPN users should have a pleasent VPN experience. The VPN clients/connections(you might use clientless VPN remote access sometimes) should be easy to use in order not to cause frustration, not to affect work productivity and to lower the number of support calls. Maintaining the VPN solution should be done without administrative overhead, again saving costs. The VPN solution should not require highly trained network administrators just to make sure it is up and running.

There are certain aspects that will contribute to the final decision. The next two important "features" will influence the decision of buying a VPN solution: the "emotional" factor and the cost.

-The "emotional" factor: there is no secret, unless people want to keep it secret, that everybody has certain feelings about vendors and their products. Mixed feelings, good and bad feelings. Feelings that can be based on people's experiences or just on people's feelings. When feelings are based on people's experiences, then they can represent valid and solid arguments regarding the selection of a certain product from a certain vendor. But when feelings are just based on feelings, rational decisions are in danger.
A company can build in time a strong relationship with a vendor. An upgrade decision, such as upgrading an ISA Server 2004 to an ISA Server 2006, may appear natural. The company will like to continue with a product that proved to be an excellent solution for its needs. The company also may consider that it can reduce costs, because the transition should be easier.
A company may use various products from a vendor: switches, routers, wireless access points, firewalls, IDS/IPS and so on. Again it may seem natural to keep things "contigous" and also use a VPN solution from the same vendor based on the confidence gained through the use of various products.
A company has used for a long time with success open source solutions. When upgrading or implementing a new VPN solution would seem natural to continue this benefic tradition. Popular IPsec based implementations (say Openswan) are available, or if connectivity represents an issue, OpenVPN (SSL VPN) may be the answer. The solution can be built from scratch. Already built ones are available with commercial support, with various features, say the pfSense project or maybe Vyatta OFR (remote access available only on the Glendale alpha release as writing this), just to name a few. You can find out more about using a Linux L2TP/IPsec VPN server from Jacco de Leeuw's Web Site.
A company may have migrated away from products used in the past(say new switches or routers from another vendor). This migration was a real success and confidence is high. The company also plans to replace its current firewall, so using an integrated firewall/VPN from this vendor may once again appear a natural decison.
A company may have had a bad experience in the past with a certain product or various products from a vendor. So it would seem a rational decision to stay away from that vendor's products.
Without contesting these decisions, a deeper analyze is required. You should always be in touch with the latest innovations and listen what the "rest" has to say and to offer. Another vendor may have the upper hand in terms of  technology. Using a new VPN solution from another vendor can be scarry, but it can turn into a success story. It may outperform the current vendor's solution so you will end-up with a superior solution which will lower the TCO and increase productivity. The past is past and things may have changed. The painful experience from the past could have been just an accident or the guilty vendor may have learnt from its mistakes.

-The cost: can be a tricky factor. The initial cost of acquisition may be low, but the TCO can prove to be significant. And vice-versa. There are many factors that will influence the initial cost of acquisition or the TCO. We have already discussed many of them above. It will always be about what you are going to get versus what are you going to give up. Although many vendors claim that you can have all the above features and much more, assuming that this is true, it will come at a price that your budget cannot afford. So you will have to decide which features are most important for your company for present and for future. If you currently decide to opt for a solution that does not offer, say SSL VPN, because you don't really need that now, thus saving some money(you have just a few VPN clients using L2TP/IPsec which works great) and in the future due to connectivity issues, you may need SSL VPN remote access, your current decision can prove a costly one (if you are locked using a VPN solution that will require a new infrastructure in order to integrate SSL VPN). Also, when choosing an integrated security and VPN solution, you will want to benefit from all the levels of protection at maximum. The vendor may claim that is has the best-of-breed IDP/IPS, application-layer firewall, antivirus and so on. In reality, it may have the best-of-breed IDS/IPS, a medium antivirus and a poor application-layer firewall. You will have to decide which features are the most important for you and choose the most balanced solution for your needs.

As shown in Figure1, there are some security challenges that must be handled accordingly.

Regarding the remote sites, if all the sites in a VPN are owned by the same company, the VPN may be thought of as an intranet, if the various sites are owned by different companies, the VPN may be thought of as an extranet. So, it should be noted that a site can be in an intranet and in an extranet in the same time, a local site can be connected to a remote site representing a branch office of the same company and to a remote site representing a partener's office. Therefore, very likely, different policies will be applied for the communications between the sites(different level of trust). Only certain traffic and resources will be made available for the communications between the local site and the partner's site. Deep traffic inspection may be applied for this scenario. Also, even when the sites belong to the intranet, say two branch offices and the local HQ site, this does not automatically mean that the same policies will be applied for the communication between HQ and branch 1 office, and between HQ and branch 2 office, branch 1 may need access to different resources located on the HQ than branch 2. The branch offices may have their own local security policies(including physical security), thus they can generate various threats for the HQ site. So it is critical to achieve granular controlled access to resources. Various level of traffic inspection are needed, simple stateful packet inspection only offering little protection for applications.

Regarding the VPN clients, there are multiple types of VPN clients: employees working on the road, employees working at home, some partners/consultants and so on. In order not to create security holes, again strict controlled access and deep traffic inspection are needed. You can't allow a VPN user connecting from home to have full access to the corporate network and pass traffic without being inspected by the firewall. However, since all these users are away for some periods of time, the machines they use(laptops), cannot be verified by the network admins to ensure they follow some policies like having the systems patched, the personal antivirus updated and active along with a firewall running and so on. So it will appear the need for endpoint compliance. VPN quarantine can solve this problem, by placing the VPN clients on a special network with limited access while the health state of their machine is checked. If they pass the checks, they are released from this special network and allowed to access the permitted resources. If they fail these tests, they must update their machines(install the latest patches, latest antivirus signatures). Also in this way split tunneling can be easily avoided. Some VPN quarantine solutions really work in practice and are easy to use, other are complete nightmares(Microsoft's VPN-Q). Fortunetely for ISA there are third-party VPN quarantine solutions like Winfrasoft VPN-Q 2006 or Quarantine Security Suite(QSS) .

Also the VPN remote access requires another level of authentication: user authentication. In the case of site-to-site connections, machine-level authentication may be enough, the VPN gateways authenticate themselves through credentials stored securely within the devices without any user input, for example using digital signatures(the private key corresponding to the public key from the certificate is stored and protected within the machine). In addition the VPN server is placed into a secure physical location and unauthorized access is prevented(isolation).

However, since VPN users are mobile users, physical security becomes a relative term.
From the VPN client's point of view, the VPN server requires machine-level authentication, the VPN client needs to be sure that the other end of the connection is indeed the VPN server. From the VPN server's point of view, machine-level authentication might not be enough. From the VPN server's perspective machine-level authentication provides information only about the endpoint (machine) from which the connection originates. But the VPN server has no information about the user using that remote machine, thus the VPN server cannot be sure if indeed the authorized user is trying to establish the connection. The remote machine can be a laptop located in various places where the level of physical and network security is relatively low, say at home. In order to make sure that the correct user is trying to establish the VPN connection some user input is required. Also, alone, the user-level authentication(such as information provided directly to the VPN server, say an user name and a password) might not be enough from the VPN server's perspective. The VPN server will have no information about the particular machine the user is using. The company may allow access only from approved machines.

Therefore, from the VPN server's perspective, in order to make sure that the authorized user is trying to establish the VPN connection from the authorized machine, both levels of authentication, user and machine, are needed.

L2TP/IPsec provides clean and separated user and machine authentication. Machine-level authentication is straightforward through IKE(pre-shared keys, digital signatures). The user-level authentication is represented by PPP authentication(CHAP, MS-CHAP, various EAP methods).

When selecting a VPN solution and/or VPN technology, it is very important to see if they have support for various authentication methods, thus to achieve flexibility. The authentication methods used provide different levels of assurance for both machine and user authentication, levels of assurance that can be considered acceptable in certain situations while in other situations regarded as inappropriate.

Talking about machine-level authentication for L2TP/IPsec, there are two common authentication methods: pre-shared keys and certificate authentication.

It must be noted that pre-shared keys are not really an authentication method. As its name suggests, it's achieved using a secret shared between the communicating hosts. It cannot be proven that the remote machine is indeed a specific machine, since the pre-shared key does not uniquely identify it. If only two hosts know this shared secret (the two gateways creating the site-to-site connection), it may function as an effective shared secret keeping in mind the above mentioned weakness. Even worst, in case of remote-access scenarios, the pre-shared key will transform into group pre-shared key (IKE Main Mode). In this case, neither the client nor the server identifies itself during IKE phase I. It is only known that both parties are a member of the group with knowledge of the pre-shared key.  This opens the posibility of a man-in-the-middle attack from inside(any user with access to the group pre-shared key). This scenarios is advertise in RFC3193 Securing L2TP using IPsec, an "Internet Official Protocol Standards" . Also an attacker that, somehow, manages to find out the pre-shared key, can perform the MITM attack, pretending to be the VPN server. In that case, it cannot be said if it was an external attacker or someone from the VPN clients group.
In addition, if weak pre-shared keys are used(too short, guessable), an attacker without knowledge of the pre-shared key, can use an active MITM attack and then, while being offline, attempt to guess or brute-force the pre-shared key.
Also, the distribution of the pre-shared key, the way it's stored on the machines can affect the level of assurance of this authentication method, assuming that for some people this authentication method may have any level of assurance in practice(real world scenarios). One may argue that a trust relationship was built, if you do not trust the people, you should not give them VPN remote access, thus do not give them the pre-shared key. Regarding this so called trust relationship, as said before, you cannot really trust someone who has not really proven his/her identity, therefore you cannot create a real secure channel for communications.RFC2408 Internet Security Association and Key Management Protocol (ISAKMP) states that:
"1.5.3 ISAKMP Requirements
Strong authentication MUST be provided on ISAKMP exchanges.  Without being able to authenticate the entity at the other end, the Security Association (SA) and session key established are suspect.  Without authentication you are unable to trust an entity's identification, which makes access control questionable.  While encryption (e.g. ESP) and integrity (e.g.  AH) will protect subsequent communications from passive eavesdroppers, without authentication it is possible that the SA and key may have been established with an adversary who performed an active man-in-the-middle attack and is now stealing all your personal data."
You can think about pre-shared keys in this way(it may be not the best analogy from some points of view): you have an office and this office has a door which is locked. In order to enter this office, people need to unlock the door. You distribute them keys to open the lock. Since you need more keys for your people, you duplicate the original key and give these keys to the people. Since all the keys are the same, you cannot say who opened the door on a monday morning at 09:12, thus no endpoint (machine) origination. You have little control on how well protected is this key by your people, loss or theft can occur. Also the duplication and distribution process can represent a weak point where an attack can occur. Depending on the lock, the key can be easy or complicated to forge (pre-shared key length and complexity). In case a key is lost or stolen, you cannot simply revoke that key, you need to change the lock(modify the pre-shared key on the server) and acknowledge all the people using the old keys that they are no longer valid. The time needed for making the new key available(duplicate the new key, distribute it to the people), would block office access, people cannot enter the office (connect to the VPN server). A skillful attacker, might manage to duplicate a key without the knowledge of the owner. And with this key, he/she would enter the office(successfully establish a VPN connection). Since all the keys are the same and do not identify in any way the owner(the machine in case of IKE), it will be very difficult to locate from which person and how the key was copied (from which machine was the pre-shared key obtained and how did that happen).

Regarding the machine authentication method with certificates, this is indeed an authentication method and should stop the MITM attack.  The digital certificate will bind together a public key with an identity(the name of the machine in this case). The certificate will be digitally signed by a Certificate Authority. The certificates will be used to exchange the public keys. Because the certificate is signed by a Certificate Authority which both machines trust, the certificate can be used to verify that the public key belongs to the remote machine.

The use of digital certificates would require a PKI. For some reasons, some folks, like to give to the PKI a bombastic and complex meaning. In reality is not that complicated to build your own PKI(keeping in mind that depending on which CA is used and how is the PKI implemented, it will provide different levels of assurance). The CA from Windows Server 2003 is easy to use, either as a Standalone or Enterprise CA. It comes with templates for various certificates(web server, computer, user and so on). Certificates are easy to issue, to revoke. Also certificates are easy to store/import/export on Windows-based machines providing flexibility, you can choose if a private key will be or not exportable. Many of the processes are automated, requiring few skills from administrators. The certificates can be easily protected when the private key is exported. If you search the Internet, you will find step-by-step tutorials with pictures about how to install, configure the CA or to issue/obtain various certificates from the CA.
You do not need to spend any money on Microsoft's CA if you want to have your own CA. You can easily use OpenSSL. Again if you search the Internet you will find plenty of detailed tutorials about how to create your own CA with OpenSSL, issue various certificates types for various scenarios, revoke certificates and so on.
Some products(VPN solutions) come with an integrated CA.

If a certificate uniquely identifies a single machine(as it should), endpoint origination (machine) is possible. Now, assuming that appropiate logging is in place, you can verify from which machine on a monday morning 09:12, a successful IKE phase I was completed. If a certificate is lost or stolen, you can simply revoke that certificate and publish the new CRL in order to make people/machines aware of the fact that this specific certificate is no longer valid, without having to rebuild everything. This is a scalable and easy to manage solution.

It must be noted that the value of a certificate may vary. If an attacker can easily obtain one from the CA, the certificate will have a low value. So the certificate enrollment process must be strictly controlled. In certain common situations, the terms machine certificates and user certificates can have ambiguous meanings. In reality the same certificate will be used for both machine and user authentication(not very smart). It's labeled as machine certificate because it's stored within the machine (Computer Store - Windows OS) while it is also stored in the User Store(Windows OS). In fact, in practice, a "machine certificate", can have its EKU set to Client Authentication (1.3.6.1.5.5.7.3.2). Such a certificate may be defined by some people as a "user" certificate. Even more, in practice, a VPN server may use such a certificate(which EKU's does not contain Server Authentication (1.3.6.1.5.5.7.3.1)) for IKE authentication. Therefore, both the machine and user certificate enrollment processes must be strictly controlled.
In addition, the way the private key is stored and protected on the machine is critical. If it's properly done, an attacker may have to steal the entire machine. Maybe a laptop would be easy to steal in certain situations. However it would be also easy to notice that the laptop is missing and then to revoke the certificate. This is true as long as the laptop is "physically" stolen. But what if the machine is "virtually" stolen ?
Assuming the attacker has physical access(ambiguous meaning) to the machine for a certain amount of time, it can transform the physical machine into a virtual machine(cold clone, see VMware Converter for example). Some may argue that additional measures can be taken (WinMagic, TrueCrypt). New attacks are found, see Cold Boot Attacks on Encryption Keys.

The MITM attack posibility when certificates authentication is used exists in practice, see this post, by Thor Lancelot Simon. Although that post is old, Windows XP SP2 VPN L2TP/IPsec clients are still susceptible to the MITM attack. I have installed SP3 (RC2) and haven't noticed a fixed VPN client like the new one from Windows Vista or Windows 2008 Server. Maybe, after a long time, Microsoft will fix this.
The idea is that every VPN client has a certificate from the CA which also issued the VPN server certificate, so when connecting to the VPN server and receiving the VPN server's certificate, the Windows XP VPN L2TP/IPsec client will only check if the certificate was issued by the trusted CA. It does not check and cannot be configured to check if indeed the certificate identifies the server, if the name on the certificate belongs to the VPN server. Only trusting the CA is not enough. The identity of the server must be verified. That's what digital certificates do, they bind together a public key with an identity, the name of the server in this case. Even worst, the VPN client cannot be configured from which CA to accept the VPN server certificate.
Some may say that since certificates are issued to trusted machines by a private CA and the user authentication method used is also mutual(the server is authenticated one more time) this would provide for them a good level of assurance. However, in case of remote access, the VPN client does not know if the remote peer is indeed the VPN server, or someone (another VPN client) maquerading the VPN server.

Thus, any VPN user can impersonate the VPN server.
Therefore, the desired secure and authenticated channel established in IKE phase I will become suspect. This channel is used to negotiate the IPsec SAs, and data will be protected(confidentiality, integrity and anti-replay attack) by IPsec ESP.
In case of ISA Server 2006 (its VPN functionality is handled through Windows 2003 RRAS), L2TP/IPsec site-to-site VPN connections, you cannot specify either to check the name of the remote VPN gateway from the certificate. Only in case of IPsec tunnel mode site-to-site connections, you can select which CA issued the certificate.

Let's examplify a little bit this MITM aspect with the L2TP/IPsec VPN client from Windows Vista.
As said before, Vista and Windows Server 2008 include a VPN L2TP/IPsec client that will verify VPN server's name from the certificate, if "Verify the Name and Usage attributes of the server's certificate" is checked. See Figure2.

Figure2: Vista L2TP/IPsec VPN Client Verify Server's certificate

If the name of the server to which the VPN client connects, see Figure3, does not match the one from the VPN server's certificate, the connection will fail, see Figure4.

Figure3: Vista L2TP/IPsec VPN Connection: Specify Server's Name

Figure4: Vista L2TP/IPsec VPN Connection Failed

The log shows that the name of the certificate was incorrect, instead of "isamain.carbonwind.net", the certificates was issued to "owa.carbonwind.net", and error "CERT_E_CN_NO_MATCH" appears, see Figure5.

Figure5: Vista Log VPN: Server's Certificate Name Error

It would be interesting to see what this "name of the server's certificate" means. For example, the log from Figure5, was generated using for the server a certificate which "Subject"'s field contains the CN(Common Name) "owa.carbonwind.net". It does not contain the X509v3 extension "Subject Alternative Name". So it looks that Vista verified if the CN from the certificate matches the one to which the VPN client connects.
I've generated another certificate with the CN set to "vpn.carbonwind.net" and "Subject Alternative Name" to DNS Name "attack.carbonwind.net", see Figure6. If the name of the server to which the VPN client connects is "vpn.carbonwind.net", the connection fails with the error from Figure5. If the name of the server to which the VPN client connects is "attack.carbonwind.net", the connection succeeds.

Figure6: Certificate "Subject Alternative Name"

In addition Vista checks the EKU field on the VPN server's certificate. It appears that if the EKU field does not contain Server Authentication (1.3.6.1.5.5.7.3.1), the connection will fail, the log showing "CERT_E_WRONG_USAGE" error, see Figure7. Also Vista accepts a VPN server certificate which does not contain the EKU field, the log saying "CertFindExtension failed with 0. This is OK as it means all Key usages are valid", see Figure8.

Figure7: Vista Log VPN: Server's Certificate EKU Error

Figure8: Vista Log VPN: Server's Certificate No EKU

If something or not is achieved through this second check(EKU), depends on the certificates used by clients.
We will see all these later, in detail. We'll analyze(in pictures) the machine authentication methods, certificates and CAs.

What must be noted is that with Vista or Windows Server 2008 L2TP/IPsec VPN Clients, the MITM posibility is eliminated. And that is not all about the server side when talking about a secure VPN solution, the VPN client plays an important role too.
Also it appears that with Windows 2008, in case of L2TP/IPsec site-to-site connections, it is possible to check "Verify the Name and Usage attributes of the server's certificate", see Figure9. As writing this part I have not tested yet this to see hwo it works. As said before, in case of ISA Server 2006 (its VPN functionality is handled through Windows Server 2003 RRAS), is not possible to perform this check.

Figure9: Windows Server 2008 RRAS Demand-Dial Interface

What would be the reasons behind the MITM attack from another VPN client(inside attack) or from an attacker that, somehow, manages to steal a certificate for machine authentication ?
The other VPN client can use its VPN credentials(machine and user) to steal something for example.
L2TP/IPsec provides two level of authentication, so the attacker(external) needs the user's credentials in order to connect to the VPN server(user-level authentication), it's not enough to have only the machine's credentials.
With ISA Server 2006, access to resources is controlled per user.
Thus, a VPN user with restricted access can try to steal the credentials of another user in order to elevate his/her permissions and gain access to prohibited resources.
An outside attacker can also try to steal some user credentials in order to successfully connect to the VPN server and access some data.

Therefore it can be said that access control (at the user level) is as strong as the user authentication method used.
Interesting or not, an user may have no access to a certain resource while is located on the internal network of his/her company, but may gain access to this resources through VPN, in case an "allow all" policy is in place.

If the user authentication method is a password-based authentication method, then it should prevent off-line dictionary attacks.
One may argue that this is not anymore the case(L2TP/IPsec) since the user authentication information is protected by IPsec ESP, thus is transmited over a secure and authenticated channel. This would be true only if the IKE MITM attack is not possible(someone is not masquerading the VPN server).

Depending on the user authentication method used, the server can be once again authenticated (mutual authentication, thus to attempt to stop the MITM attack) or only the VPN user will be authenticated.
For example MS-CHAPv2 provides mutual authentication, the server authenticates the client and vice-versa. However, dictionary attacks are not prevented in this authentication method. And the server will be authenticated only after the client has sent its authentication information(the server sends a response, either Success or Failure along with a response value based on which the client will authenticate the server, see Cryptanalysis of Microsoft's PPTP Authentication Extensions (MS-CHAPv2)). So the attacker would have the information needed to perform an off-line dictionary attack.
To resist dictionary attacks, strong password must be chosen. In practice, typically user-chosen passwords are unlikely to be strong. See Figure10, a Wireshark capture for a L2TP/IPsec connection, showing the MS-CHAPv2 authentication in clear (ESP encryption set to null).

Figure10: Wireshark Capture L2TP/IPsec MS-CHAPv2 in Clear

Very likely, the user's credentials might be Active Directory credentials. So if an attacker manages to discover these credentials will gain access to other resources.

Interesting, with Vista and as I can see, the new Windows XP SP3 (RC2), Microsoft proposes PEAP/EAP-MSCHAPv2 for user authentication. Since this method only requires a certificate on server's side, the VPN users need only their user names and passwords. This time, the VPN client first check server's identity, examines the server certificate, name and which CA issue it. If they do not match with the ones from its configuration, the connection will be terminated. If they matched, the client sends the user authentication information, which is protected by the TLS tunnel. So in case, that somehow, the machine authentication is compromised, and an attacker mounts a MITM attack, user's credentials should be protected against a dictionary attack. Note that the server certificate used for machine authentication and the one used for user authentication can be different. See Figure11, a Wireshark capture for a L2TP/IPsec connection, showing the PEAP/EAP-MS-CHAPv2 authentication in clear (ESP encryption set to null).

Figure11: Wireshark Capture L2TP/IPsec PEAP/EAP-MS-CHAPv2 in Clear

For this authentication method to be effective, additional configuration step are needed on the client side, so that the VPN client really checks the server's identity. The CA which issued the server's certificate and the name of the server from the certficate must be configured (also is not a good idea to let the user authorize the server, example: the name from the certificate does not match the one configured, but the client can decide to connect anyway). See Figure12 and Figure13.

Figure12: Vista VPN Client Configure PEAP/EAP-MS-CHAPv2

Figure13: XP SP3(RC2) VPN Client Configure PEAP/EAP-MS-CHAPv2

What PEAP/EAP-MS-CHAPv2 cannot do is to protect the passwords from being used in an inappropiate way. A strong password policy might be in place. But users can choose poor passwords (gue55myP@$$W0RD is long enough, contains upper case and special characters, numbers, but is guessable). They can write down on a piece of paper the credentials and left this paper on a desk, stick it on the monitor and so on. Shoulder surfing may be used to steal the credentials too.
Mitigation of credential compromise is difficult.

So if a higher level of assurance is needed for user authentication, the VPN solution must be able to provide it.

One such method of authentication may be EAP-TLS, where certificates are used for user authentication. The certificate can be stored on a smart card. In this way two-factor authentication for user-level can be achieved: something you have (the smart card) and something you know (the PIN which enables you to access the certificate stored on the smart card).
If proper smart cards are used, the certificate will be well protected.
If the smart card is stolen, it will be easy to notice that it's missing. In addition the attacker will have to find out the PIN too.

We will analyze later in these series various authentication methods with plenty of pictures along the explanations.

With ISA Server 2006, various authentication methods for both machine and user authentication are provided. ISA will be able to authenticate directly the users(including Active Directory credentials) or use a RADIUS server.
For machine-level authentication pre-shared keys(useful for testing) or certificates can be used.
For user-level authentication, you can have methods like PAP, CHAP, MS-CHAP, MS-CHAPv2, EAP-TLS or RSA SecurID Authentication.

ISA will offer many of the features discussed above(with the help of third-party addons). One big miss will be the lack of SSL VPN.
IAG 2007 combined with ISA Server 2006, a powerful appliance, can offer both SSL and IPsec VPN. In addition, everything is taken into another dimension compared with the standalone ISA. Since it's out of the scope of this article we won't start a discussion about Intelligent Application Gateway 2007. If you want you can find more about it reading its datasheet . I just want to say that it is really an outstanding product.

Windows Server 2008 offers SSTP for SSL VPN remote access.
Also with Windows Server 2008, Microsoft brings support for Suite B Cryptography. AES is here, as well as ECDSA, SHA-2 family or ECDH. So the "adequate security margin" AES can be used for VPN connections. And we along with Microsoft can start dreaming a dream named XSL (I can't resist throwing this one in).
It must be noted that indeed Windows Server 2008 looks shiny.
I can't stop wonder why (or maybe I can, it's so "nice" to be ambiguous) Microsoft came with AuthIP, instead of adopting IKEv2, an "Internet Official Protocol Standards" (STD 1).

So it can be said that:
Wait a minute!
What about PPTP ?
You've talked about IPsec, L2TP/IPsec, SSL based VPNs, but not a single word about PPTP ?
Haven't you read the VPN FAQs from Microsoft ?
Microsoft says it "provides a good level of security".
First I would like to mention that in the VPNC whitepaper from above, PPTP does not appear in the list of supported Secure VPN Technologies by VPNC. And that Microsoft's PPTP has been analyzed by internationally renowned security experts like Bruce Schneier, see Cryptanalysis of Microsoft's PPTP Authentication Extensions (MS-CHAPv2).
ASLEAP is a tool, created by Joshua Wright, that can be used to recover passwords from PPTP transactions. You may also like to read:
 - Exploiting known security holes in Microsoft's PPTP Authentication Extensions (MS-CHAPv2) by Jochen Eisinger
 - NIST Special Publication 800-77 - Guide to IPsec VPNs :  Chapter 5. Alternatives to IPsec - 5.1 Data Link Layer VPN Protocols

PPTP is described in RFC2637 Point to Point Tunneling Protocol, RFC3078 MMPE, Microsoft Point to Point Encryption, RFC3079 Deriving Keys for use with MPPE.
Please note that every of these RFCs does “not specify an Internet standard of any kind”.
This means that PPTP is *not* an Internet Standard.
I'm not sure what exactly a "good level of security" means in Microsoft's VPN FAQs, please note that in other article Microsoft itself states that "PPTP provides only per-packet data confidentiality", same comments in this article too.
PPTP's "features" include:
- authentication vulnerable to offline dictionary attacks.
- low protection for user authentication information.
- no integrity per packet :connectionless integrity(proof of the fact that data has not been altered in transit) and data origin authentication(proof that the data was sent by the correct peer).
- questionable protection against version rollback attacks(all the VPN clients must support MS-CHAPv2, or the new PEAP/EAP-MS-CHAPv2 for the mitigation of the dictionary attacks).
- a questionable level of confidentiality: the encryption protocol is only as secure as the passwords, passwords chosen by users. Also PPTP offers at its best, in theory, RC4 with 128 bits keys, as we are are in year 2008 and AES is here for quite a while.
- additional information sent in clear, information like the private IP addresses used by the VPN client and the VPN server(it is very likely that the VPN client will receive an IP address from the internal network, thus the private subnet used on this internal network can be seen without any effort by an attacker), the internal IP addresses of the internal DNS and WINS servers (if any). See Figure14 and Figure15 , this time I haven't disabled the confidentiality(like in case of the L2TP/IPsec pictures, where encryption was set to null).

Figure14: Wireshark Capture PPTP server's private IP address

Figure15: Wireshark Capture PPTP client's received settings 

- the posibility to create other holes: if the credentials used are Active Directory credentials, then access to other resources can be "granted" in case these credentials become compromised due to PPTP's poor authentication method.

While knowing that security is always a compromise between what you are going to get and what you are going to give up, acknowledging the benefits of PPTP, it still looks like a too big compromise has to be made. PPTP is easy to use, requires no PKI(authentication based on users' passwords), it's up and running in a second. On the other side, is "the security model it uses" that kills it (there are certain aspects that can't be fixed). PPTP has problems with the "P" from the word VPN.
The definition of strong passwords in the real world in relationship with people is something relative (we've discussed that).
And, Bill Gates himself says that we can't rely anymore on passwords (what we must heavily do in case of PPTP), read this and this.
In order to mitigate the dictionary attacks, the new PEAP/EAP-MS-CHAPv2 can be used. But still a certificate is needed on server's side. And the VPN clients must use Vista or XP SP3.
In practice, the use of EAP-TLS is out of discussion, because it would require a PKI, and this is the number one reason to use PPTP over L2TP/IPsec.

Regarding that VPN FAQs, I must say I have recently read some really good docs on Microsoft's site, and reading this VPN FAQs is very unpleasent.
I can't stop noticing how Microsoft contradicts itself. For example, in this VPN FAQs, PPTP appears to be very "agile" and passes through most of the NAT devices without any modification on the client or server side unlike L2TP/IPsec which needs NAT-T on the client and server side, thus I'm under the impression that connectivity is another advantage for PPTP.
However, in a Cable Guy article, The Secure Socket Tunneling Protocol, there are in a generous way presented numerous connectivity problems of PPTP, and I find out that the NAT device must be able to translate the GRE traffic and that PPTP has problems with firewalls, NAT devices and Web proxies.
Also in this article Microsoft says that the NAT device needs an editor for PPTP traffic.
That's weird.
So where is the truth ?

Anyway, it can be said that:

- The strength of the authentication methods for both user and machine authentication, the level of protection (confidentiality, integrity, replay-attack protection, version rollback protection, protection and prevention against the modification of the protections suites) along with the cryptographic algorithms used will dictate the strength of the secure VPN technology.

- The level of controlled access to resources, the level of protection(antivirus, IDS/IPS, stateful packet filtering, deep application inspection), the level of endpoint compliance, the VPN clients used along with the VPN technology used and how was this VPN technology implemented will dictate the security of the VPN solution.

In Part 3, we will start to build the L2TP/IPsec puzzle. With some easy shots, following some Wireshark captures, and step-by-step, analyze deeper and deeper the traffic flow.