The new Vyatta VC4 (codename Glendale) incorporates L2TP/IPsec for VPN remote access, and GRE and IPIP tunnels + IPsec for advanced VPN site-to-site connections (the standard IPsec Tunnel Mode site-to-site connections are present too).

The adding of advanced VPN site-to-site connections is quite exciting. And with Vyatta, the excitement does not stop here. Either you are a newbie or an experienced user you will probably have the same desire: to build a quick lab to see how the advanced VPN site-to-site connections behave.
Unlike with other vendors, you have access to a community edition of Vyatta, a loaded edition, not just a stripped down to nothing version.
And with Vyatta you have the chance to build your test lab just the way you like it most: in VMware. Since Vyatta runs in VMware, testing was never so easy before (compared with the testing of proprietary routers). And you can't do a real deployment without doing some tests first.

Actually I cannot stop noticing that Vyatta VC4 becomes an attractive study platform too since it incorporates many features (and we have free access to the loaded community edition). Building a hands-on lab for learning and testing was always quite difficult due to cost issues (the networking equipment is quite expensive). And without a hands-on lab you cannot trully learn something and advance your career. If you buy very cheap devices from various places, they may behave random or die too quickly. However, since Vyatta has the ability to run on ordinary hardware and in VMware, complex network topologies can be easily achieved. Also Vyatta Inc. continues to penetrate the market.
So you have a couple of good reasons to start thinking about adding to your lab some Vyatta OFR machines, either physical or virtual ones (in case you already didn't do so).

But before we start building our VMware lab, let's first discuss about the advanced VPN site-to-site connections and the need for them. If you want to skip this, then go to Part 3.

VPNs are used by companies to:
 -  connect together the offices of the same company (HQs, branch offices, remote offices). These are seen as Intranet VPNs. Popular speaking we are talking about site-to-site VPN connections.
 - connect together their internal network with the outside networks of their partners, suppliers, contractors or customers. These are seen as Extranet VPNs. Again, popular speaking we are referring to site-to-site VPN connections.
 - provide remote access for employees working on the road (road warriors), employees working at home, some customers or contractors just to name a few. This type of VPN is called VPN Remote Access. These above mentioned people are regarded as VPN clients (users).

Various VPN technologies are used to accomplish these needs. Trusted VPNs represent a solution for connecting HQs with branch offices for example (say using Frame Relay circuits).
However this solution is an expensive one.

Internet connections became cheaper and offered high speed connections, so companies took advantage of these aspects and start linking their offices using secure VPN technologies. For example, IPsec-based VPNs are used for connecting remote offices together over the Internet.
Companies deploy IPsec-based VPNs over the Internet because they can achieve confidentiality, authentication and data integrity. So IPsec-based VPNs became very popular.

A traditional implementation is the "IPsec Tunnel Mode" VPN site-to-site connection. This is regarded as a basic VPN site-to-site connection. This "classic" implementation has several serious limitation.
As companies relied more and more on these connections, it appeared the need to pass various traffic types over the "tunnels".
IPsec is regarded as a tunnel between two IPsec peers.
Additional to IP unicast traffic, the companies needed support for IP multicast and broadcast packets or non-IP protocols.
However the "standard" IPsec Tunnel Mode" VPN site-to-site connection cannot handle all these.
Dynamic routing protocols use IP multicast and broadcast packets. Using dynamic IGP routing protocols between sites was not possible if multicast traffic needed to be sent through the IPsec tunnels. There was a big problem with IPsec tunnels and dynamic routing protocols.
Also, in case that at one site a new subnet is added, this new subnet cannot be "discovered" at the other end of the tunnel. Both VPN endpoints need to be reconfigured.
Since networks are dynamic by their nature, dynamic routing protocols provide vital features like "network discovery", optimal routing or the ability to use alternate routes when a link fails.

Let's imagine the following simplified situation: two offices, one using internally IP addresses from the 192.168.10.0/24 subnet and the other from the 192.168.30.0/24 subnet.
When the administrator configures the classic "IPsec Tunnel Mode" VPN site-to-site connection, he/she must carefully specify the local and remote subnets. Failing to do so and the "tunnel" will never come up.
During IKE Phase II, Quick Mode, the VPN peers negotiate local and remote proxy identities.
 - For one side these proxy identities will look like:
     local proxy = 192.168.10.0/24 remote proxy = 192.168.30.0/24
 - For the other side these proxy identities will look like:
     local proxy = 192.168.30.0/24 remote proxy = 192.168.10.0/24
If the negotiations are successful, a Security Database is created.
Based on this Security Database packets can be sent through the "tunnel".
If a packet from a local host, 192.168.10.50 needs to be sent to a remote host 192.168.30.2, the local VPN endpoint checks its Security Database for a match (local proxy = 192.168.10.0/24 remote proxy = 192.168.30.0/24), and then it will forward this packet through the tunnel.
Now, if a new local subnet is added, 192.168.11.0/24, although a "tunnel" exists between the two offices, a packet from 192.168.11.173 cannot be sent to 192.168.10.50, because the Security Database does not permit this.
So make a change to the local VPN gateway and reconfigure the local and remote proxy identities to include the new subnet:
local proxy = 192.168.10.0/23 remote proxy = 192.168.30.0/24
Doing so, it will bring the "tunnel" down, because the other side is configured with the remote proxy = 192.168.10.0/24. Thus IKE Phase II, Quick Mode, will fail.
The remote administrator must make the required changes on his/her VPN gateway.

At a small scale this may work, but not at a bigger one. Also, if many offices are connected together (say office A , office B and office C), in case the tunnel from office A to office B goes down, office A can reach office B through office C. But if it was not instructed to do so, it will not be able to re-route the traffic.

Adding a routing protocol into equation can solve these problems. Running a dynamic routing protocol through the tunnels enables the companies to build the routing table dynamically.
Use OSPF for example to discover the networks behind the "tunnel" endpoints and select a new path in case a link goes down (use routing for resiliency). Thus make VPNs dynamic as the networks they connect. It must be noted that the selection of a new path (failover time) will be as fast as time needed for the routing protocol to detect the dead link and select a new path.

Also it must be noted that only half of the equation was solved. From the security point of view, the firewall rules must be adjusted in order to accommodate the changes. The new remote network was discovered, but firewall rules prevent communications. However, most likely, the hardest part of the equation was solved because having an experienced network administrator to deal with the complexity of IPsec at the branch office is a problem.
But, an intelligent security solution is still desired to solve the rest of the equation or to reduce its complexity.

How to migrate away from the rigid and limited "standard" "IPsec Tunnel Mode" VPN site-to-site connection in case it cannot address the company's needs?

Various approaches can be used.

For example a tunnel and IPsec to protect this tunnel.
The role of the tunnel will be to transport protocols like IP, IPX or AppleTalk and multicast, broadcast and unicast packets. The tunnel will encapsulate them in an IP unicast packet which IPsec can handle.
The resulted IP unicast packet is unprotected, so IPsec's role will be to protect it.

Cisco came up with the idea to use GRE tunnels along with IPsec. Because it lacked security, alone GRE couldn't (it was was never meant to) be part of a VPN solution.
GRE itself can deliver only a VN, but used along with IPsec, the result will be a VPN.
GRE has some unique abilities.
GRE is a Layer-3 transport protocol that can encapsulate IP unicast, multicast, broadcast packets or other protocols, such as AppleTalk, IPX, in an IP unicast packet.
The overhead resulted from the use of GRE tunnels + IPsec is translated into system overhead (the extra encapsulation process) and packet overhead (+4 bytes for the GRE header if IPsec transport mode is used or +24 bytes if tunnel mode is used-the new IP header added after GRE encapsulation is also protected-).
GRE/IPsec can be used in hub and spoke or mesh (partial and full) scenarios.

If you need to pass only IP traffic through the "tunnels", you can use IPIP (IP-in-IP) tunnels. For example, the IP-in-IP tunnel can be used to forward IP multicast traffic, say OSPF multicast packets. The IP multicast packet will be encapsulated into an unicast IP datagram.
IP in IP encapsulation also enables the preservation of IP source routing options or the delivery of a datagram to a mobile node using Mobile IP.
Just like in case of GRE tunnels, the IPIP tunnel itself can deliver only a VN, but used along with IPsec, the result will be a VPN.
It must be noted that this type of tunnel introduces less overhead then the GRE tunnel due to the absence of the 4 byte GRE header.
IPIP/IPsec can be used in hub and spoke and mesh (partial and full) scenarios.

Another tunnel can be the L2TP tunnel.
Like GRE, L2TP has some unique abilities.
The main use of L2TP is to tunnel PPP traffic (Layer 2 data), so in the end L2TP tunnels data that is already in the Point-to-Point Protocol.
L2TP can be run over various networks such as IP, SONET or ATM. However, in order to use IPSec for the protection of the L2TP tunnel, L2TP must be run over IP.
Like GRE, L2TP can be used to carry various traffic like IP multicast packets or non-IP traffic(AppleTalk, IPX).
L2TP is the heavy-weight champ regarding overhead compared to the above other two tunnels. L2TP can be implemented as an UDP-based IP protocol. For example to send an IP packet over the tunnel, the original IP packet is encapsulated in PPP, the PPP packet is encapsulated in L2TP. The L2TP packet is an UDP packet encapsulated in an IP datagram(so we have three more headers added to the orginal packet: PPP(+1 byte), L2TP(+8 bytes), UDP(+8 bytes) + the new IP header).
Like in case of GRE and IPIP tunnels, L2TP itself can deliver only a VN, but secured with IPsec, will become a VPN technology. Actually, L2TP/IPsec is an "Internet Official Protocol Standards" described in RFC3193 .
L2TP/IPsec is widely used for VPN remote access (Microsoft does so and so does the new Vyatta VC4) for very good reasons. This combination adds the level of authentication required in remote access scenarios: user authentication (through PPP authentication). When using L2TP, the VPN client can obtain an IP address from his/her company's internal network which he/she is needing to access. This will allow his/her machine to appear as if it is "on" the corporate network. From a logical point of view, his/her machine is "directly" connected to the company's network. Through the use of PPP IPCP, he/she is provisioned with an IP address, IP addresses for Primary DNS and WINS Servers, IP addresses for Secondary DNS and WINS Servers from the corporate network for his/her VPN connection(PPP adapter). Also through DHCP Options, he/she can get the connection-specific DNS suffix for the PPP adapter. This will enable he/she to resolve single label names without the need of a WINS server(in case the Primary DNS suffix is not set or differs).
Microsoft is a big supporter of L2TP/IPsec for site-to-site VPN connections. However, Microsoft does not seem eager to play the game of dynamic site-to-site VPNs.
L2TP/IPsec can be used in hub and spoke and partial mesh scenarios in case of ISA 2006 Server .

Interesting, although we are talking about site-to-site connections, now IPsec ESP Transport Mode gets a first class ticket.
IPsec ESP Transport Mode is used for host-to-host communications. Since we are using the above tunnels, traffic sent between the sites travels inside these tunnels. So basically we have a point-to-point connection to protect. When the tunnel endpoints addresses are the same with the IPsec peers addresses, IPsec ESP Transport Mode can be used to secure the tunnels(unless, for example in case of GRE and IPIP, the tunnels endpoints are private IP addresses from loopback interfaces and IPsec peers addresses are public IP addresses from physical interfaces).
IPsec ESP Transport Mode is actually desired due to efficiency reasons, the Tunnel Mode will add extra packet overhead(+ 20 bytes for a new IP header). So it will keep the overhead smaller.

As can be seen, although it adds some overhead, the use of these tunnels, in certain situations, will offer benefits that will justify this overhead.

Some people were unhappy with the overhead introduced by the tunnels (most likely with the one introduce by GRE tunnels, since these tunnels were widely used in combination with IPsec for dynamic VPN site-to-site connections).
The solution: keep the Tunnel Mode, set the proxy identities to 0.0.0.0./0 and implement the VPN link as a routable interface. So now the routing and forwarding decision takes place outside of IPsec. And because at the tunnel endpoint a routable interface exists, IP multicast traffic can be sent through the VPN tunnel, so this solution is capable to run dynamic IGP routing protocols (using multicast packets) through the VPN tunnels.
Also this implementation should be easier to configure then, say GRE+IPsec.
The downside would be that it can handle only IP traffic.

Since it's quite hard to visualize the encapsulation procedures for various tunnels + the use of IPsec either in Transport or Tunnel mode, I've used Wireshark , captured some traffic and gathered some pictures in order to see how the packets look on the wire, for the standard IPsec Tunnel Mode site-to-site connection, unprotected GRE and IPIP tunnels, GRE and IPIP tunnels secured with IPsec, L2TP/IPsec, Cisco's SVTI and DMVPN . In order to see inside the IPsec "tunnel", I've set ESP confidentiality to NULL.

In Part 2 we will take a look (with pictures) to all these.