Why L2TP/IPsec ?
Because it's a modern secure VPN technology.
So how L2TP/IPsec as a modern secure VPN technology works for you and your company?

Why ISA Server 2006?
Because it's a VPN solution that offers secure remote access and secure site-to-site connectivity, not just remote access and site-to-site connectivity. Alright, maybe is not quite the latest state-of-the-art VPN solution, but it definetely can help you in not creating a security "hole" through the use of VPN connections. And because it comes from Microsoft (just read the top-right corner of RFC3193 Securing L2TP using IPsec).
With ISA Server 2006, L2TP/IPsec is used for both remote access and site-to-site connections.

On a unsecure path, attackers are assumed to have the ability to capture, read, modify, delete or replay messages sent between the communicating hosts.
Attackers will actively try to make the communicating parties to select different protections suites(say weaker encryption algorithms) than they would normally choose in order to weak the security of the communication channel.

Therefore data confidentiality, data integrity(proof of the fact that the data has not been altered in transit), data origin authentication(proof that the data was sent by the correct party), replay-attack protection and prevention against the modification of the protections suites along with strong authentication methods of the device/user must represent the natural state of being of a secure VPN technology.

The question to ask, how L2TP/IPsec deals with all the above mentioned threats ?

See more about VPN technologies and VPN solutions in Part 2.

We are going to talk about a lot of things. I will try to summarize them in this introduction. As you can see there are no pictures in this first part.

Many people complain that they receive some cryptic messages when they attempt to use their L2TP/IPsec based connection. They search for help and they are instructed to use Wireshark and see how long IKE negotiations go. Additionally, they could look into the Oakley.log.

Very nice, these are very good advices. But in order to be able to "look" you need to understand what's happening and what are you "looking" for.
And that's a problem because IPsec is not a very simple protocol. Not at all.
So they will end-up with other cryptic messages.

Even more, we are talking about L2TP over IPsec, so L2TP comes to the party.

L2TP/IPsec provides two level of authentication, machine(IKE authentication) and user(PPP authentication). So you will be advised to use certificates authentication for both machine and user authentication.
What's the difference between these two level of authentication and what protocols do they use ?
What is a strong authentication method ?
How do these protocols look and work "live on the wire" ?

Add some NAT devices into equation and now you are talking about "IPsec pass-through" and NAT-Traversal support, which are different things.
How does NAT-T look "in action" ?

And the myth land: the cryptographic algorithms. Basically we are talking about hash algorithms(example hash functions), symmetric key algorithms and asymmetric key algorithms(commonly known as public key algorithms).
For what are they used ?
What's their security strength ?
For example, why you should use 3DES in combination with Diffie-Hellman 2048-bit MODP Group ?
In general, the strength of the overall protection is determined by the weakest algorithm and key size.
So it is not recommended to use algorithm suites that combine non-comparable strength algorithms.
However, in practice, assuming that sufficient protection is provided, algorithms of different strengths and key sizes may be used together for reasons like performance or/and interoperability. For example, AES could be the choice over 3DES due to performance issues even if the rest of algorithms does not match AES' strength.
The key length does not automatically give the algorithm's security strength(for both symmetric and asymmetric key algorithms).
According to NIST, the security strength(also known as “bits of security”) represents a number associated with the amount of work (the number of operations) that is required to break a cryptographic algorithm.
Also if you use random number generators whose outputs are not entirely random (can be predicted to some extent), then the overall protection will be weaker than expected. For example the strength of a key derived from a Diffie-Hellman exchange will depend on the strength of the Diffie-Hellman group and the entropy provided by the random number generator used.
So what's the security strength of the protection suite that you are using for your VPN connection ?
There are always people keen to provide romours announcing that a certain algorithm was broken. And other people keen to transform these romours into "news" and rapidly spread them over the Internet.
It is always good for us to wait and let the world's finest cryptographers decide if attacks are real world and practical attacks and how they affect the Internet Protocols that use the broken cryptographic algorithm.
So, for example, you might feel the need to ask, what are the security implications of reduced collision-resistance of common hash algorithms (MD5 and SHA-1) for the IKE and IPsec protocols ? 

Finnally, to put the icing on the cake, learn how to perform a quick penetration test against your VPN server, to see what the attacker might see.

Instead of drawing some general diagrams which will explain IKE, IPsec ESP, L2TP, NAT-T and various authentication protocols, I will explain them on a "live" connection with the help of Wireshark.

Being able to use a network protocol analyzer like Wireshark is an important skill these days. It is crucial to understand the traffic flow, either we are talking about HTTP, FTP, IPsec, SSL/TLS or other protocols. It will help you go a long way in securing and throubleshooting your network.

However, the Oakley.log can provide more information than Wireshark since for example IKE Quick Mode negotiations are encrypted. Also, some ISAKMP Informational Exchange messages are encrypted, so you do not know what message was received or transmited by your VPN client or server. This message can help you find the solution to the problem.
The Oakley.log tells you what's happening under the hood.

Therefore we will take on both: the Wireshark capture and the Oakley.log, separate and side by side.

In Part 2 we will talk a little bit about VPN technologies and VPN solutions, present and future. Windows Server 2008 is knocking on the door.