Hi Willow,
Okay, let's start ;)
First, though, let me ask you a question. You wrote:
when you try to set a VPN tunnel to the ISP you can do it in 3 ways
Why would you want to set up a VPN tunnel to the ISP? What kind of traffic would be tunneled across it? I am asking because usually, you want an ISP to provide you with basic (or native) internet (IP) connectivity. The VPN types we're discussing (PPTP, L2TP, GRE, IPsec) are add-ons to the basic connectivity, and you cannot have these VPN types without the basic connectivity. So if your ISP gives you this basic connectivity, there's no specific need to do additional tunneling unless you have some special need for that - and I am asking what that special need is supposed to be.
if it`s through the phone provider (i.e. copper-lines going to DSLAM and then to an NGN all-IP network) you will need to set up a PPPoe dialer
Customarily, we do not consider PPPoE to be a VPN. Of course it shares traits of a VPN as it involves tunneling PPP frames in Ethernet frames, but because the Ethernet part of this tunneling is outside the client's reach (with DSL routers, the Ethernet network isn't there anymore as they already have the DSL interface integrated), it merely becomes a mandatory - almost a legacy - part of all the overhead. So from the common client's point of view, there is no VPN to PPPoE because there is no "native connectivity" over the underlying Ethernet infrastructure - the Ethernet isn't anywhere in direct client's reach.
and once you needed a PPTP dialer.
This surprises me. PPTP assumes that the basic connectivity is already in place. PPTP cannot provide basic IP connectivity itself - on the contrary, it relies on it. So if you have a basic connectivity, what would you need PPTP toward your ISP for?
if your provider is the cable company (mpls) you can either dial up with PPTP or L2TP
Same as before. It is possible that I am not familiar with the way your providers offer internet connectivity, but of one thing I am certain: Both PPTP and L2TP need a working IP connectivity between your client software and the remote access server beforehand. Would that connectivity not suffice for accessing the internet?
what I get from this is that a layer 2 PPP is required for authentication, that is what enables the ISP to know who is trying to connect and to bill them accordingly.
Basically, yes. Providers have been accustomed to PPP since the times of old analog dialups and ISDNs, and when broadband technologies came in, PPP was just adapted to be used over them. This allowed providers to largely keep all the access, authentication and billing infrastructure unchanged - and compatible with different ways of client accessing the provider's network.
so an L2TP dialer would form a L2TP tunnel, but what will PPTP form? an regular unsecured GRE tunnel? if so, how is it considered a VPN?
L2TP will form an L2TP tunnel carrying either PPP or Ethernet frames (these are the most common frame types carried over L2TP). PPTP will form a GRE tunnel carrying PPP frames. Both L2TP and PPTP are unsecured tunnels and they would need IPsec for their protection.
A VPN does not necessarily include encryption. That is an added quality but not a prerequisite. VPN is a generic name for a network that, from your viewpoint, operates as a dedicated network just for you and no one else, while in reality, it runs over a shared infrastructure. Even an Ethernet VLAN is a form of VPN. There are several categories of VPNs but from the security standpoint, there are two major categories: Secure VPNs and Trusted VPNs. Secure VPNs are all those technologies that employ encryption mechanisms (IPsec, SSL, ...). Trusted VPNs are those technologies where, by the nature of how the VPNs operate, your data cannot leak out, and you trust your provider of this technology that he won't misconfigure things or sniff your data illegally (MPLS VPNs, Frame Relay PVCs, ...).
you said it is not common to see a PPTP tunnel with IPsec covering it, so when a client dials through a PPTP client-software - is IPsec only added at the ISP or already at the client`s end? since PPTP is end-to-end but unsecured AND is considered a VPN - where is it added?
Nowhere. PPTP is an unsecured VPN. It was commonly used to access internal company networks by a home teleworker or a travelling employee, but it was not encrypted. That does not prevent it from being classified as a VPN - it's just not a secure VPN. That's one of the reasons it is now completely replaced by different technologies.
If you think that having an unencrypted VPN is something unimaginable, think again :) Telnet, POP3, IMAP, HTTP, FTP, SNMPv1/v2... - all these protocols and more are unencrypted and carry all information, including passwords and sensitive data, unprotected. IP protocols were originally designed with a belief that the network user (or an administrator) is not malicious :)
I think I got a little confused by the client-side, trying to establish a VPN to the ISP
Well, to simplify it, out of all technologies you have been asking about, you're only using PPPoE for accessing the ISP and gaining access to internet. You do not ordinarily use PPTP or L2TP to access the internet; instead, you use PPTP or L2TP to access some private network across the existing internet connection. You are usually not creating a VPN to your ISP; you are creating a VPN across your ISP to some other location that is accessible through your ISP.
I was reading your replay and assumed the packet-structure examples you gave (question 5) refers to "GRE over IPsec". if so, how come in the "transport mode" the outer header is a GRE header? isn`t the routing done with an IPsec IP header in "GRE over IPsec" (as you showed in tunnel mode)?
That is because the IPsec transport mode maintains the original IP header along with all original addressing and stuff. The only thing that is changed is the Protocol field that obviously needs to be rewritten to indicate the presence of the AH/ESP. IPsec transport mode implicitly assumes that a direct connectivity already exists between the communicating stations that want to protect their communication by IPsec, so there is no reason to add another IP header with some other addresses.
In other words, if the end hosts whose traffic is being IPsec-protected are also the IPsec tunnel endpoints then they can use IPsec transport mode. Otherwise, if the traffic between two end hosts is IPsec-encrypted and decrypted by other devices on the path (such as home routers), IPsec will need to run in tunnel mode.
on the same note, can you please draw the structure of an "IPsec over Gre" packet same way you did to "GRE over IPsec", i.e. tunnel/transport modes?
This order of encapsulation is used extremely rarely, mostly because there is no reason to add a GRE encapsulation onto an IPsec-protected packet that is itself fully capable of being routed across the network. I can draw the structure of such packets but it's more of an academic exercise, as you won't be seeing such packets out in the wild.
IPsec over GRE, Tunnel mode:
GRE tunnel IP header | GRE header | IPsec tunnel IP header | ESP/AH | Original IP packet
IPsec over GRE, Transport mode:
GRE tunnel IP header | GRE header | Original IP header | ESP/AH | Original IP packet's payload
also, what is the point of using an AH-IPsec, if AH does not encrypt? what is the purpose of this tunnel? how is it different from a plain regular GRE tunnel? when should I use a tunnel that only authenticates?
Originally, perhaps in the good Unix way of having a tool do just one thing but do it perfectly, IPsec had split the problem of comprehensive data transmission security into different protocols, each taking care of just a selected aspect of security. To provide for confidentiality, IPsec used ESP. To provide for integrity and anti-replay, IPsec used AH. If you wanted to implement just a part of these security aspects, you used only the corresponding protocol. If you wanted all of it, you used both ESP and AH at the same time.
The authentication and anti-replay in AH make sure that the protected packets are received exactly as they have been sent - that is, no one has modified their contents, no one has spoofed these packets in the name of the original sender, and no one has captured these packets and re-sent them repeatedly to cause some action to be repeated. In other words, AH protects the integrity and un-repeatibility of these packets including their outer headers.
Obviously, just as you are asking, the added value of AH protection alone was rather small. With AH, there was a guarantee that the packets have not been modified, spoofed or repeated while in transit, but their contents were still unprotected and readable by anyone having access to the transmission path. In addition, while the AH protection also covered the outer packet's header contents which could be perceived a good thing, this made AH immediately incompatible with NAT boxes that by definition modify the outer header's address fields.
So as time passed, ESP was extended with the ability to not only provide for confidentiality but also for data integrity and anti-replay, and AH became obsolete. Nowadays, Cisco ASA firewalls do not even support AH (I am not sure if they ever supported it). Simply put, AH was a design choice that once appeared to be sensible but turned out otherwise.
Best regards,
Peter
