16.05.2008
 Updated 27.08.2008
Vyatta VC4 Remote Access VPN - Part 2: "L2TP/IPsec?" - My Two Cents

On 26.08.2008, on the Vyatta Users Forum, an announce was made, that a Security Reference document is available for download at http://www.vyatta.org/documentation.

Within that document, Chapter 4 Remote Access VPN overview, section Remote Access VPN configuration, topic Remote Access VPN Deployment Issues, L2TP/IPsec part, Vyatta documented the described bellow issue.

Vyatta provide a solution using iptables for Glendale(VC4).
Starting with Hollywood(VC4.1), the bellow described issue can be addressed directly from the CLI, a configuration example being presented.

Vyatta kept their word, and both documented and addressed the bellow described issue.

For doing that, three big Hip Hip Hoorays from me today for Vyatta in the security area.

I know this is not what you are expecting to be: configuring L2TP/IPsec on Vyatta VC4.
And I must say that there would not be any article about configuring L2TP/IPsec on Vyatta VC4.
I do not have anything against Vyatta. I actually used to like Vyatta. I suppose this is obvious due to the amount of articles I wrote about Vyatta describing how to do various things.

This week I was taking a closer look at Vyatta's VC 4.0.2 new L2TP/IPsec VPN remote access functionality.
According to the Release Notes, new in Vyatta VC 4.0.2 is the Remote Access VPN, PPTP and L2TP/IPsec VPN tunnels are available.

For people wanting a secure VPN technology, L2TP/IPsec can be a solution.
So it's nice to see Vyatta incorporating L2TP/IPsec into its product. L2TP/IPsec is "an Internet Official Protocol Standards":
http://www.ietf.org/rfc/rfc3193.txt

People would choose L2TP/IPsec because it offers strong authentication and encryption.
Security issues that might appear when for example, you use group pre-shared keys for IKE authentication, are documented within RFC3193.

However, Vyatta's L2TP/IPsec implementation appears to be affected by security issues. There is no official public statement yet, so no conclusions can be drawn.

This has nothing to do with the L2TP/IPsec protocol, it's only about Vyatta's L2TP/IPsec implementation.

I posted a couple of questions and thoughts on Vyatta's forum, and a Vyatta employee answered:
http://vyatta.org/forum/viewtopic.php?t=413

Interesting Vyatta seems to acknowledge there is a security issue, but does not recognize in clear that there is a problem with its implementation:
http://vyatta.org/forum/viewtopic.php?t=413

"You are right that this is a security risk that should be documented so that a user can make an informed decision as to what solution is best for his/her environment.
Also, in the next release, we plan to extend the firewall capability so that a user can define such a firewall rule to minimize this particular risk. Or better yet, we could automatically add such a rule when L2TP is configured. "

So what's happening ?

When you configure, I do not know how to say it, so: "what Vyatta calls L2TP VPN remote access functionality", in fact, by default, you allow L2TP/IPsec connections and also the creation of naked L2TP tunnels (PPP encryption is not used, data traffic goes in clear).

Thus, if any of your VPN clients wants, he/she can establish only an L2TP tunnel instead of an L2TP/IPsec connection and there is nothing you can do about that from the CLI.

Of course, Vyatta says you can address this issue outside of the CLI. But in order to do that, you need to know about this issue, and also to know how to fix it.
How I ran into it ?
Actually I was aware of the fact that such a thing might be possible. However, I was pretty confident that Vyatta will do things correctly.
Jacco de Leeuw wrote about the posibility of L2TP packets flowing unprotected by IPsec between the server and the clients on his super web site(Openswan+L2TP), and he does not look happy at all about it:
http://www.jacco2.dds.nl/networking/freeswan-l2tp.html
Since I was writing an article about Vyatta(uses Openswan and xl2tpd) and L2TP/IPsec, I wanted to test this and see if I can establish an L2TP tunnel in clear. And surprise(at least for me).
Unlike with products from other vendors, with Vyatta, the system might be open and things exposed, but I think it's absurd to claim that everybody should know what's under the hood.

And here is where Vyatta made the first mistake:

 - They were aware of this fact (by the way, where is the secure by design approach ?):
http://vyatta.org/forum/viewtopic.php?t=413
"I tested this scenario some months ago, and if I recall correctly, you should be able to achieve the filtering you want by using the iptables "policy" match extension module."

 - And although Vyatta VC4 was released on 21.04.2008, until 14.05.2008 when I posted on their forums about this issue, I was not aware of any official public evidence about this issue from Vyatta(I might be wrong here, there are many web pages on the Internet, so please Vyatta correct me). What I'm aware of, and acknowledged by Vyatta, is that the Vyatta_CommandRef_VC4.0.2_v01.pdf does not mention anything about this issue.

Vyatta claimes it cares about security, if so why did they not make this issue public starting with the release of Glendale Alpha, and say: "look guys, due to the tight schedule we cannot make available a fix from the CLI, but you can do this and that yourself".
Why when I search the bugzilla(https://bugzilla.vyatta.com/) with the L2TP keyword, I can't find anything about this issue ?
Why they are not saying in the realese notes that the naked L2TP tunnels are available by default when configuring L2TP/IPsec?
Where is at least the common sense ?
How long should take until some official documents discussing this problem will be available ?
We are already talking about months (since Glendale was released) and over three weeks from the release of Vyatta VC4.

And things do not stop here: let me assume that both L2TP/IPsec and L2TP co-exist by default. And I have the flexibility to choose what I need. OK, right now outside of the CLI.
This is one aspect, the question is: do they overlap ?
http://vyatta.org/forum/viewtopic.php?t=413
And Vyatta avoids to answer this question.
If they do overlap, then what an attacker can do ?
If I use the default settings, to what exactly am I exposed, or maybe I'm not exposed to anything, but how should I know that, who can certify this ?
Another question Vyatta avoids to answer: is Vyatta's L2TP/IPsec implementation RFC compliant ?
http://vyatta.org/forum/viewtopic.php?t=413
If the answer is yes, how can I be sure this is true ?
And why, if for example I establish one L2TP/IPsec connection and one naked L2TP tunnel behind same NAT device (due to the NAT process, the two connections appear to have the same source IP, which makes things pretty interesting), Vyatta VC4 answers with ESP packets to my data packets from the naked L2TP tunnel ?
http://www.ietf.org/rfc/rfc3193.txt
"When a packet arrives from a tunnel which requires security, L2TP
MUST:

[1] Check to ensure that the packet was decrypted and/or
authenticated by IPsec. Since IPsec already verifies that the
packet arrived in the correct SA, L2TP can be assured that the
packet was indeed sent by a trusted peer and that it did not
arrive in the clear.

[2] Verify that the IP addresses and UDP port values in the packet
match the socket information which was used to setup the L2TP
tunnel. This step prevents malicious peers from spoofing packets
into other tunnels."
Obviously the naked tunnel does not require security, so the reply packets should be inside the naked L2TP tunnel, according to the co-existance non-overlapping theory.
Does this breaks the RFC compliancy ?
http://vyatta.org/forum/viewtopic.php?t=413
Vyatta does not answer either.

When I've said that "the "vpn l2tp" command does not truly enable VPN functionality", Vyatta's answer was:
http://vyatta.org/forum/viewtopic.php?t=413
"Of course, and some people will say that PPTP does not truly enable VPN functionality (rightly so given their concerns). And yet other people will say "I don't want any of these, just give me ssh tunnels!", which is also entirely valid if that's best for their environments."
I was referring to the fact that naked L2TP tunnels are available by default along with L2TP/IPsec connections and that the naked L2TP tunnels are established over the Internet, an insecure path. Thus secure VPNs are needed. I was thinking on "some people"'s definition and requirements of secure VPNs, and particularly on this VPNC's white paper:
http://www.vpnc.org/vpn-technologies.html
Also I was thinking on the unknown security implications of the co-existance theory.

Maybe nothing can stop someone from calling L2TP a VPN protocol, but in the end the only thing that matters is if indeed L2TP is a VPN protocol or not.
Market shares do not make L2TP a VPN protocol.

Security by obscurity does not function, why can't Vyatta answer straight ?
In the end this draws the conclusions for now (Vyatta's answer):
http://vyatta.org/forum/viewtopic.php?t=413
"We will provide the information so that users will be able to make informed decisions as to what the best solution is for their particular environments."
So till now and till who knows when, I can use it on my own risk although Vyatta knew about it long time ago ?
Luckily for me I did not replace my home firewall with a Vyatta machine as I was thinking about for some time. For sure this would not happen in the future. I have my own testing procedure that I follow. I might be subjective, and I'm aware of this fact.

The worst thing is that Vyatta does not have a reputation in the security area, it's actually trying to build one. There are many companies out there trying to do the same thing.
What makes the difference ? 
"Maybe" quality and secure by design products. 
Nothing new for me. I do not need Vyatta to answer to my above questions. I can answer myself to them.

My final two cents: make sure that the VPN implementations of the product you use are RFCs(" Internet Official Protocol Standards") compliant. This would give you the confidence that you are using secure protocols, protocols that have been under intense scrutinity from the Internet community.
Some vendors achieve various certifications for their products too.